<inline>
> -----Original Message-----
> From: David Harrington [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, August 15, 2006 11:25 AM
> To: Rainer Gerhards
> Cc: [EMAIL PROTECTED]
> Subject: byte-counting vs special character
>
> Hi Rainer,
>
> [speaking as co-chair]
> Can we change the subject line to "byte-counting vs special character"
> for this topic so it is easier to find comments on this topic as
> compared to other things in the timeline? That will make it nuch
> easier for the chairs.
>
Sure
> This WG has already gotten stuck, and had WG progress stall, trying to
> provide backwards compatibility to a bunch of incompatible
> implementations. I argued on this list before becoming co-chair that
> backwarsd compatibility may not be achieveable for some features and
> we need to stop getting hung up on it. Sometimes to build a good
> standard, you need to choose something that will break some existing
> implementations.
>
> I raised this concern with Chris when I started as co-chair. I do not
> want to see backwards compatibility arguments stall progress again. I
> made sure this was reflected in the timeline, which says that by
> Friday (if you decide to use a special character) you must reach
> consensus on which special character to use.
> [/speaking as co-chair]
As you know, I have originally opted for octet-couting. However, I am
trying to describe what made me think this is a sub-optimal solution. I
think backwards compatibilty can easily be brought in here. However, I
do not think this is a vital point. I can live with octet-couting and
would not object it if it is the WG consensus to use it. So far, I've
not seen a clear consesus for either.
What I would find very unfortunate is using both escapes and
octet-counting (for the reasons outlined in previous mails - gains
nothing, costs many).
To fulfil your requirement, I propse that we use the backslash character
("\") as escape if we should decide to go the "escape way".
> [speaking as contributor]
> I like the argument that the LF solution will not break existing
> implementations, but I would like to know this is actually true. Have
> you actually tested this against multiple implementations, or is it a
> theoretical argument?
No, it's a practical one, but based on plain tcp transport seen in the
wild.
I know for sure that Cisco PIX, syslog-ng, rsyslog,
WinSyslog/MonitorWare and most probably Kiwi syslog support LF as
terminator (Kiwi with a leading CR as Andrew has pointed out). All of
these solutions interop via ssl if used with stunnel.
> I know you have tested a number of other proposed ways of doing things
> against multiple implementations to try to verify backwards
> compatibility. Have you actually tested multiple existing
> implementations with the LF and found that they do continue to work
> without significant problems? Can you tell the WG which ones you have
> tested? Are there implementations that break when using this solution?
>
All quoted above rely on the LF. If it is not present, at least most of
them will merge syslog records (I can not at this moment verify the
later for all one mentioned because I have no lab access).
So far, my understanding was that stunnel is basically compatible to
what -transport-tls specifies. Miao has questions that this morning.
Again, I can not verify at this time (not even having a -transport-tls
implementation at hand). I have asked Miao for details where he sees the
incompatibility. When he replies, his argument might actually settle the
whole issue and proove me wrong.
> In a different message you argue that syslog-sign only needs to
> support -protocol because the implementations will need to have new
> code added anyway, and the added complexity of backwards compatibility
> to rfc3164 implementations is not needed.
I see a big difference here. To support -sign, all new implementations
are needed. -tls (at least in my current view) does not come with this
restriction.
> You only mention one implementation explicitly that provides
> syslog/tls, syslog-ng over stunnel. Would all the other
> implementations need to be modified to support a TLS substrate anyway,
> so it would not make a difference to them which special character was
> chosen or if byte-counting was chosen? Which syslog/tls
> implementations will be impacted by our choice here?
Stunnel is a wrapper. It works with anything that runs on tcp. I have
mentioned syslog-ng because it is the best known (and nothing I am
involved with). All implementations I have quoted work with stunnel and
are interoperable in that way (again, Kiwi only 98% sure).
> Ideally, only the implementations that support a feature need to pay
> the price for the feature.
>
> A syslog message delineator will only be needed in implemntations that
> add support for syslog/tls (or other streams). Whether one supports
> byte-counting or a special character, only implementations that
> support multiple messages in a stream, e.g. syslog/tls, should need to
> be modified to support the choice.
>
> Personally I find the octet-counting cleaner
I have argued much in the same way and still find byte-counting the
technically best solution.
> because previous
> discussions on terminators showed that available implementations are
> highly inconsistent with their special characters.
>
> Since byte-counting happens outside the syslog message, and only for
> syslog in a delimited stream coming in over the syslog/tls port, it
> would not impact existing code, only code that supports syslog/tls.
I think it impacts existing deployed solutions using syslog with
stunnel.
> New syslog/tls code would be needed to extract each "normal" syslog
> message from the stream and then send it on for processing through the
> existing parser.
>
> If message originators start escaping special characters in the
> message content, existing receivers may need to be modified to
> un-escape the characters. Think about applications, such as intrusion
> detection systems, that search for special patterns in syslog content
> - those could be broken by having the content changed by escaping
> characters in the middle of the content.
LF is currently not seen in log files. A problem could occur by escaping
\, but it seems to be seldomly used.
> What happens at a store-then-forward relay? Does the relay store the
> escaped characters or does it un-escape them first? Does it escape
> them again when it forwards the message? Does it escape them if it
> un-escaped them on input? Does it escape them if it did not un-escape
> them on input? What if the sender included some escaped characaters
> (like '\') for other purposes? Should the relay unescape them as well?
> Will it know to re-escape them on output? What should the ultimate
> reciever expect to receive?
>
Existing receivers should never unescape and escape. -transport-tls
receivers MUST unescape and escape the message when forwarding. The
escape is just a transfer encoding, so it is not present in the actual
message.
> Byte-counting looks way less complex to me than choosing a special
> character and escaping/unescaping special characters in the content
> during the sending/forwarding/recieving process. (And my opinion has
> nothing to do with the H**** in my email address.)
>
I agree octet-couting is easier. As I said, it was my preferred
soltution, too. What made me change my mind was backwards compatibility.
The added complexity IMHO is a small price to pay for immediately being
compatible to everything that is deployed today. If I am wrong here
(Miao's answer...), escaping would be a big mistake. Until this is
proven, I stick with it as my preferrence. I do not, however, object
octet-couting if that is consensus.
Rainer
> dbh
>
> > -----Original Message-----
> > From: Rainer Gerhards [mailto:[EMAIL PROTECTED]
> > Sent: Tuesday, August 15, 2006 12:41 AM
> > To: Miao Fuyou
> > Cc: [EMAIL PROTECTED]
> > Subject: RE: [Syslog] timeline
> >
> > Miao,
> >
> > I am actually concerned about backward compatibility with
> > existing code
> > *without* the need to upgrade any of that code. As you know,
> deployed
> > software tends to stick.
> >
> > If we use just LF, existing, deployed technology (e.g. syslog-ng
> with
> > stunnel) would be able to understand a message sent from a "new
> style"
> > syslogd. Having the octet count in front of the message removes that
> > ability, as the old syslogd will no longer see the <pri> at
> > the start of
> > the message.
> >
> > I agree that it is trivial to modify code to take care for the octet
> > counter. But this is not my concern. My concern is that I
> > would like to
> > achive as good as possible compatibility with existing deployed (aka
> > "unmodified") technology. I should have been more specific on that.
> > Sorry for the omission...
> >
> > I am also unaware of any implementation that mandates CR LF over
> just
> > LF. Could you let me know which ones are these?
> >
> > Rainer
> >
> > > -----Original Message-----
> > > From: Miao Fuyou [mailto:[EMAIL PROTECTED]
> > > Sent: Monday, August 14, 2006 7:07 PM
> > > To: Rainer Gerhards
> > > Cc: [EMAIL PROTECTED]
> > > Subject: RE: [Syslog] timeline
> > >
> > >
> > > Hi, Rainer,
> > >
> > > A new implementation could rely on byte-counting only and
> > > then delete LF
> > > from the frame(appplication knows exactly where the LF is),
> > > it may not force
> > > us to use escapes. For LF, I think it is difficult to get
> > > 100% compatibility
> > > for a legacy implementation to comply TLS-transport without
> > > any change to
> > > the code. At least, some imlementation may need to change
> > CR LF to LF
> > > because some implementations use CR LF rather than LF. So, it
> > > may be ok to
> > > add several LOC to delete FRAME-LEN SP from the frame.
> > >
> > > I still prefer byte-counting only to byte-counting+LF even
> > if it is a
> > > feasible tradeoff.
> > >
> > > Miao
> > >
> > > > -----Original Message-----
> > > > From: Rainer Gerhards [mailto:[EMAIL PROTECTED]
> > > > Sent: Monday, August 14, 2006 10:18 PM
> > > > To: Miao Fuyou
> > > > Subject: RE: [Syslog] timeline
> > > >
> > > > We should not go byte-counting + LF. This is the worst choice:
> it
> > > >
> > > > A) breaks compatibility
> > > > B) Forces us to use escapes
> > > >
> > > > So we get the bad of both worlds, without any benefits.
> > > >
> > > > Rainer
> > > >
> > > > > -----Original Message-----
> > > > > From: Miao Fuyou [mailto:[EMAIL PROTECTED]
> > > > > Sent: Monday, August 14, 2006 12:58 AM
> > > > > To: 'Anton Okmianski (aokmians)'; 'David Harrington';
> > > > [EMAIL PROTECTED]
> > > > > Subject: RE: [Syslog] timeline
> > > > >
> > > > >
> > > > > My vote: byte-counting only > byte-counting + LF > LF
> > > >
> > > >
> > >
> > >
> > >
> >
> > _______________________________________________
> > Syslog mailing list
> > Syslog@lists.ietf.org
> > https://www1.ietf.org/mailman/listinfo/syslog
> >
>
>
_______________________________________________
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog
