I would like to add an Issue#9 to Chris list ;) RFC3195/COOKED allows us to specify meta data (like the path element). This is very valuable information. However, it can be forwarded inside a relay chain only if all realys speak COOKED.
Let's take my (somewhat artifical) sample from the issue #8 post: #1 Device -- RFC3164 --> Relay 1 #2 Relay 1 -- 3195/COOKED --> Relay 2 #3 Relay 2 -- RFC3164 --> Relay 3 #4 Relay 3 -- 3195/RAW --> Relay 4 #5 Relay 4 -- 3195/COOKED --> Collector Let's focus on the path element. In this sample, the relay in step #1 can generate all necessary information to create a path element that is correct up to the device. It can also forward it correctly in step #2, so that realy 2 can add its path element. HOWEVER, there is no way to transmit the path in steps #3 & #4. So it is LOST. In step #4, Relay 4 will construct a new path element, but it can only point back to Relay 3 and this will eventually be invalidly be flagged as a device (because there is no iam element in 3195/RAW that can tell the relay differently. That path element will be transmitted in step #5 and the receiving collector can add the fact that it received from Relay 4(acting as a relay). So the resulting path will just be: Device Relay 3 --> Realy Relay 4 --> Collector This is obviously an incorrect and too short path element. I agree that the path will not be correct until either the emiting device itself speaks COOKED or the first relay does. However, I would like to see the path preserved in cases as above. As such, I propose we integrate into some existing/future RFC the ability to transfer metadata over a "plain" syslog packet. It can be done quite simple by just adding an additional cookie, more or less like -sign is done. For example, a packet with tag "syslog " and @#MeTaDaTa at the start of message could carry over the XML otherwise exchanged in COOKED. A rough example might be <121>Oct 10 12:12:12 myhost syslog @#MeTaDaTa <path fromFQDN='lowry.records.example.com' fromIP='10.0.0.50' toFQDN='kurtzman.records.example.com' toIP='10.0.0.51' linkprops='ULRI' pathID='173'><path fromFQDN='screen.lowry.records.example.com' fromIP='10.0.0.47' toFQDN='lowry.records.example.com' toIP='10.0.0.50' linkprops='DLI' pathID='24'></path></path> [Please note: I have not made sure that this fits in 1024 bytes. It should all be on a single "line" without any CRLF (but the mailer breaks it ;)) There are obviously some issues with fragmenting oversize messages. I haven't taken care of this - this can be done once the WG finds it is useful to think in this direction.] For the intial example, it would the final path at the collector at least make look like: Device Device --> Relay Relay 1 --> Relay Realy 4 --> Collector [Relay 4 would be discovered by the collector] Even though there is still something missing, it looks much more correct to me. I specifically propose this as I think legacy syslog will be in relay chains for quite a while and cause us to loose important information for many years. Any comments are highly appreciated ;) Rainer
