RE: [Syslog] RFC 3164
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
Consensus - was: Re: [Syslog] RFC 3164 in syslog-sign? (fwd)
Hi, Overwhelming consensus is that references to 3164 will be removed from syslog-sign. Alex, Please start working on this but don't submit any changes until after WGLC is complete on 28 Dec. All: Please continue to review the document and let's get this out the door. Thanks, Chris P.S. - Seasons Greetings to All and my very best wishes to everyone for a happy and prosperous New Year. :-) ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] RFC 3164
Hi, The Chairs have spoken to the author of RFC 3164. The author agrees that it should be OBSOLETED. ;-) I did discuss this with someone who has been trying to de-cruft a lot of ancient RFCs. It is not usual to OBSOLETE an INFORMATIONAL RFC but there's nothing that says that we can't do it. When syslog-protocol gets into the RFC Editors queue, I will tell them to OBSOLETE RFC 3164 with that document. Thanks, Chris On Fri, 22 Dec 2006, Rainer Gerhards wrote: 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
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
RE: [Syslog] RFC 3164 in syslog-sign?
Option 2 may be a better choice for a cohesive set of Syslog specifications. And, a seperated informational document can be included as work item when rechartering to address the 3164 signature issue. Is it possible? The drawback is the implementer has to do something different for -protocol and 3164. Thanks, Miao -Original Message- From: Chris Lonvick [mailto:[EMAIL PROTECTED] Sent: Thursday, December 21, 2006 10:20 AM To: [EMAIL PROTECTED] Subject: [Syslog] RFC 3164 in syslog-sign? Hi, We started syslog-sign before we had Structured Data, and the original author was creating a mechanism that could be used within the RFC 3164 framework. However, times have changed. We now have syslog-protocol with SDs. Does the WG feel that syslog-sign should contain normative information on how to utilize the syslog-sign mechanism in the RFC 3164 format? Answers can be: __ Yes - leave it, it forms a bridge for transition, __ No - take it out, we need to move the world along, __ Maybe - move it to a non-normative appendix Thanks, Chris -- Forwarded message -- Date: Wed, 20 Dec 2006 15:51:25 +0100 From: Rainer Gerhards [EMAIL PROTECTED] To: Chris Lonvick [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: APP-NAME, PROCID and MSGID in syslog sign - was: RE: [Syslog] clonvick WGLC Review of draft-ietf-syslog-sign-20.txt Chris, -Original Message- From: Chris Lonvick [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 20, 2006 3:37 PM To: Rainer Gerhards Cc: [EMAIL PROTECTED] Subject: APP-NAME, PROCID and MSGID in syslog sign - was: RE: [Syslog] clonvick WGLC Review of draft-ietf-syslog-sign-20.txt ---some elided for brevity--- With RFC 3164 syslog, we obviously can not totally be assured that the SD-ID will be valid. But we should keep in mind that we most probably will try to obsolete 3164 either via -protocol or a follow-up RFC. I already questioned the point in supporting this (informational!) document in a new standard. Is this really a wise idea? Rainer ---remainder elided for brevity--- ___ 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
RE: [Syslog] RFC 3164 in syslog-sign?
Chris, I would prefer __ No - take it out, we need to move the world along, as this removes a lot of complexity and guesswork. It will also be cleaner if rfc3164 is actually obsoleted by -syslog-protocol. If that is not WG consensus, I would recommend __ Maybe - move it to a non-normative appendix As a formal note, I am not sure if we can create normative text based on a non-normative document (rfc 3164). This sounds kind of wrong to me... Rainer -Original Message- From: Chris Lonvick [mailto:[EMAIL PROTECTED] Sent: Thursday, December 21, 2006 3:20 AM To: [EMAIL PROTECTED] Subject: [Syslog] RFC 3164 in syslog-sign? Hi, We started syslog-sign before we had Structured Data, and the original author was creating a mechanism that could be used within the RFC 3164 framework. However, times have changed. We now have syslog-protocol with SDs. Does the WG feel that syslog-sign should contain normative information on how to utilize the syslog-sign mechanism in the RFC 3164 format? Answers can be: __ Yes - leave it, it forms a bridge for transition, __ No - take it out, we need to move the world along, __ Maybe - move it to a non-normative appendix Thanks, Chris -- Forwarded message -- Date: Wed, 20 Dec 2006 15:51:25 +0100 From: Rainer Gerhards [EMAIL PROTECTED] To: Chris Lonvick [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: APP-NAME, PROCID and MSGID in syslog sign - was: RE: [Syslog] clonvick WGLC Review of draft-ietf-syslog-sign-20.txt Chris, -Original Message- From: Chris Lonvick [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 20, 2006 3:37 PM To: Rainer Gerhards Cc: [EMAIL PROTECTED] Subject: APP-NAME, PROCID and MSGID in syslog sign - was: RE: [Syslog] clonvick WGLC Review of draft-ietf-syslog-sign-20.txt ---some elided for brevity--- With RFC 3164 syslog, we obviously can not totally be assured that the SD-ID will be valid. But we should keep in mind that we most probably will try to obsolete 3164 either via -protocol or a follow-up RFC. I already questioned the point in supporting this (informational!) document in a new standard. Is this really a wise idea? Rainer ---remainder elided for brevity--- ___ 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
