If members of the syslog community want to provide updated information about observed on-the-wire syslog messages, they should feel free to write such an informational document and have it published by the IETF.
However, that is not part of the charter of our work, and should not be a WG item, but an individual draft. There is some question of whether providing such an update might conflict with the IETF efforts to standardize syslog, so the IESG may choose to prevent the publication of such a document within the IETF. Declaring RFC3164 obsolete (or historic) is within the scope of what we are authorized to do as a WG, and that step can be fully independent of an effort to provide updated information about historic/obsolete implementations. dbh > -----Original Message----- > From: Rainer Gerhards [mailto:[EMAIL PROTECTED] > Sent: Friday, December 22, 2006 2:39 AM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: RE: [Syslog] RFC 3164 > > Andrew, Anton, > > I am using Andrew's message to reply to both. I concur with Andrew, > please see below... > > > -----Original Message----- > > From: Andrew Ross [mailto:[EMAIL PROTECTED] > > Sent: Thursday, December 21, 2006 10:53 PM > > To: Rainer Gerhards > > Subject: RE: [Syslog] RFC 3164 > > > > > > Hi Rainer, > > > > Merry Christmas! > > > > Sorry I've been out of the discussion loop for so long, things have > > been > > pretty hectic over here. I know that the new protocols are in good > > hands > > though. > > > > With regard to 3164. I would prefer to obsolete 3164 with a document > > that > > details what is actually seen in real life on the wire. This would > just > > mean > > adding some extra text to the 3164 document and adding in some > examples > > of > > what is seen by different OS senders. Pretty much the research you > > presented > > to the list a while ago. This new document would then obsolete 3164. > > That would actually be my prefferred way to handle things. Other than > Andrew, I think we should remove/change most of the text, as > indeed only > PRI is available on an universal basis. Samples of different message > formats can be used to convey that information. > > > We get asked so often by customers if we are 3164 compliant. We used > to > > explain that 3164 is not really valid, but that didn't satisfy them, > so > > we > > just said "yes, we are compliant" to keep them happy. > > Now to the question "why do that?". Andrew has a very valid > point here. > We experience the same quite often. We even added an option "use RFC > 3164 compatible format" to our product and guess what - it is > turned off > most of the time because RFC 3164 does not describe what receivers and > senders typically do ;). Even if we obsolete 3164 with > -protocol, I know > a lot of folks will come and ask "Hey, do you support the old standard > that most of my other devices use?". They simply will not > care about it > being obsoleted by something different. However, if we go ahead and > crate 3164bis (another informational document), the situation > will IMHO > change. Now there is a newer "standard" (as people perceive > it) for the > "old" syslog. And if that says "You can not trust anything but PRI" I > can "sell" that. Plus, I have a very good point in argumenting why > syslog-protocol is superior. > > I know I am not talking hard technical facts here. I am talking real > life. Most people do not care if a RFC is informational or standards > track. If it is a RFC, it must be something products comply > too. I agree > that implementors should understand the difference. They > (hopefully/probably) do. But do implementors actually decide what to > implement? No - not in my experience. The marketing department tells > them what to do. And customers tell the marketing department. > And guess > what? These customers are the informed masses that do *not* know the > inner workings of the IETF (aka "a RFC is a RFC is a RFC..."). > > Even in a technical context like the IETF I think a little bit of > real-world politics can be considered. It is the key to acceptance of > new standards. > > Rainer > > > > Cheers > > > > Andrew > > > > > > > > > > -----Original Message----- > > From: Rainer Gerhards [mailto:[EMAIL PROTECTED] > > Sent: Thursday, 21 December 2006 8:13 p.m. > > To: [EMAIL PROTECTED] > > Subject: [Syslog] RFC 3164 > > > > > > Hi all, > > > > I just realized that the future of RFC 3164 is not yet publically > > discussed. > > > > RFC 3164 is a well-done work, but we have made much progress in the > > past > > 5 years since it was written. Most importantly, we discovered that > > actual syslog software uses a much different set of formats than > > expected by 3164. This was the source of much discussion > inside the WG > > and we did a lot of testing to confirm the findings. The bottom line > is > > that we now know that 3164 does *not* acurately describe what is > > observed in the wild. Nobody is to blame here - the breadth of > > information we created the past years was simply not available (nor > > were > > the ressources to do the testing) to the orginal authors of > RFC 3164. > > > > Having said that, I think we must do something about the > situation. In > > practice I see more and more vendors claim compliance to RFC 3164. > This > > is kind of funny in itself, because 3164 is just an information > > document, so you can not be compliant to it ;) Anyhow, many vendors > > seem > > to have a wrong impression and use this in their advertising as well > as > > tech support. > > > > I think we should do either one of the following: > > > > 1. create an updated RFC 3164bis > > 2. obsolete RFC 3164 > > > > I personally would tend to 1. - update the document with > what we have > > gained on additional knowledge. I have been told that this would be > > somewhat unusual for the IETF, as 3164 is only informational and > > -transport-protocol will soon set a real standard. So updating > > information on "the past" seems not to be useful. However, I expect > > traditional syslog to stay around for at least another 5 to > 10 years, > > if > > not longer. I would consider it a plus to have a RFC that accurately > > describes the format that we can expect from such a legacy syslog > > sender. Most importantly, it will remove any false secure feeling > about > > format standardization where there is none. > > > > I would appreciate comments on this issue. > > > > Rainer > > > > _______________________________________________ > > 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 > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
