Hi all, the intent is end-to-end. It got mangled during the "name wars" of syslog application/sender/receiver/originator etc. To restore the original meaning, we could do (during auth48 if there is consensus):
### The "sequenceId" parameter tracks the sequence in which the ***originator*** submits ### Anything beyond this is for the next version. I violently object any change that brings us out of the RFC editor publishing queue after we have finally reached this state after years and years... I say this even though I tend to agree to Bazsi on many points. Rainer > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Balazs Scheidler > Sent: Wednesday, July 16, 2008 10:39 AM > To: Chris Lonvick > Cc: [email protected] > Subject: Re: [Syslog] sequenceId and relaying > > On Tue, 2008-07-15 at 11:52 -0700, Chris Lonvick wrote: > > Hi, > > > > Section 5 says: > > Any syslog transport protocol MUST NOT deliberately alter the > syslog > > message. If the transport protocol needs to perform temporary > > transformations at the transport sender, these transformations > MUST > > be reversed by the transport protocol at the transport receiver, > so > > that relay or collector will see an exact copy of the message > > generated by the originator or relay. Otherwise end-to-end > > cryptographic verifiers (such as signatures) will be broken. Of > > course, message alteration might occur due to transmission errors > or > > other problems. Guarding against such alterations is not within > the > > scope of this document. > > > > I think that clearly states that the relay MUST NOT make any changes > to > > the sequenceID nor to any other SD-ID of messages passing through > them. > > > > I disagree, a relay is not merely a transport. If it was it couldn't > drop messages based on filtering, which it is allowed to do. > > In the same paragraph above: "so that _RELAY_ or collector will see an > exact copy of the message generated by the originator or > relay." (emphasis is mine). > > For me, this boils down to: the relay _OR_ collector receive messages > from the transport, and the transport layer may not modify messages. > This I completely agree with, but transport is the layer that adds > framing and pushes a syslog message to the wire. > > If relays are completely disallowed to modify messages then there's no > migration path for the new syslog protocol, we're going to have legacy > syslog messages from existing devices for at least a decade, if relays > are not allowed to change the format to the new protocol style, we'll > never really migrate to syslog-protocol. And there's merit in adding > new > information to the syslog packet as it goes through the relay network. > (for instance another timestamp that can be trusted whereas the > originating timestamp cannot be) > > Also, if the sequenceId is an end-to-end identifier (which it is if > relays are not allowed to change the SD data), then the sequenceId is > not really useful in the collector if one of the relays on the path > drop > messages by intent. > > I think two identifiers are needed: > 1) one for identifying the message hop-by-hop, this is always > increasing > (to determine whether we lost messages because of the transport) > 2) one for identifying the message end-to-end, which is not a sequence > number, but a unique identifier > > Of course I can also live with the idea of using the sequenceId > end-to-end, but I don't see this stated in the RFC. > > > > > Thanks, > > Chris > > > > On Tue, 15 Jul 2008, Balazs Scheidler wrote: > > > > > Dear syslog working group, > > > > > > I'd have a question regarding the syslog-protocol RFCs, more > > > specifically about the "sequenceId" portion of the "meta" > structured > > > data element. > > > > > > The definition of sequenceId states: > > > > > > "7.3.1. sequenceId > > > > > > The "sequenceId" parameter tracks the sequence in which the > syslog > > > application submits messages to the syslog transport for sending. > It > > > is an integer that MUST be set to 1 when the syslog function is > > > started and MUST be increased with every message up to a maximum > > > value of 2147483647. If that value is reached, the next message > MUST > > > be sent with a sequenceId of 1." > > > > > > I see a couple of problems: > > > 1) It is not stated clearly in the RFC, what relays may or may not > do > > > with structured data. > > > 2) By reading the definition above, I understand that each relay > must > > > generate a new sequenceId for every message, e.g. the collector > sees > > > the sequence id generated by the last hop, and not the > sequenceId > > > sent by the originator of the message. > > > 3) if the relay is permitted to change the structured-data portion > > > (and the current sequenceId definition mandates this IMHO), how > > > will this work with things like signed messages? > > > > > > My questions: > > > - Was this the original intent with "sequenceId"? > > > - I think some clarification about the role of relays regarding > > > structured-data handling would be needed in the RFC. > > > > > > -- > > > Bazsi > > > > > > > > > _______________________________________________ > > > Syslog mailing list > > > [email protected] > > > https://www.ietf.org/mailman/listinfo/syslog > > > > > -- > Bazsi > > _______________________________________________ > Syslog mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list [email protected] https://www.ietf.org/mailman/listinfo/syslog
