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 and
[Syslog] RFC 3195bis?
Hi all, now that we obsolete RFC 3164 by -syslog-protocol, the only remaining RFC that is not compatible to the new syslog series is RFC 3195. The questions is now how to proceed here? I am raising this issue because it has some effect on syslog-sign. I would love to see 2k as limit for sign-generated messages, but that means we need to talk about 3195 (which not explicitely supports messages over 1k). IMHO, we should do a 3195bis that updates 3195 to work as a transport mapping with syslog-protocol. After we've done that, we have finally unified all syslog RFCs and do not have any more issues with incompatibilities between them. I think this is something we should do soon. Comments? Rainer PS: I, too, would like to express my seasons greetings to all folks on the list! May you have a great and peaceful xmas time and a good start into the new year. ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] RFC 3195bis?
The Chairs have been discussing this already. We have a candidate to write the update. The length limit in RFC 3195 was constrained by RFC 3164 and we have moved beyond that with the transport IDs which identify realistic maximum lengths. Updating RFC 3195 to have a greater length should not be a problem. HOWEVER... We need to focus on syslog-sign and syslog-device-mib BEFORE doing this. Once we get the shepherding documents for those IDs sent to the IESG _THEN_ we can discuss 3195bis. The problem is that -sign is related (even depending) on 3195. This is why I brought up that issue. Let me explain. syslog-sign recommends 2k for signature and payload blocks. It does so, because it assumes (rightly for the new series) that 2k can be handled by almost every receiver, so there is no problem in using that length. However, if we require that -sign works together with 3195, we must lower this limit to 1k. I would not like to see this happen because 2k makes much sense and is much more efficient. 3195 does not seem as important: - it is due for update - there has only been an extremely limited set of implementations - none of the major vendors has implemented it - there is no (not virtually no!) customer demand for it at the time being (I know this because I have implemented RFC 3195) - the only customer demand comes from IHE, but for IHE it is not usable because it still contains a too-rigid length constraint In short: the current RFC 3195 is not really in use. An updated version may. I think we should not sacrifice the 2k limit for something that is not being used. So my propsal is: we should remove RFC 3195 from syslog-sign as well. It should simply reference -syslog-protocol and its transport mappings. RFC 3195bis will most likely be a transport mapping. Thus, -sign can cover it without specifically mentioning it. This works exactly as the new series is designed. Transports are below -protocol and sign is in the layer above it. So there should be no dependencies between -sign and the actual transports used. If we take that route, we only lose the ability to use -sign *reliably* with RFC 3195 as it is today. Given the fact that nobody is actually using 3195, this is not a huge loss ;). It also finally de-couples -sign from any other transport RFCs - and this was a major intention about the whole effort of the new syslog series. I suggest we all have a look at this slide from 2004: http://www.syslog.cc/ietf/presentat/syslog-protocol-03/img5.html Rainer Thanks, Chris On Fri, 22 Dec 2006, Rainer Gerhards wrote: Hi all, now that we obsolete RFC 3164 by -syslog-protocol, the only remaining RFC that is not compatible to the new syslog series is RFC 3195. The questions is now how to proceed here? I am raising this issue because it has some effect on syslog-sign. I would love to see 2k as limit for sign-generated messages, but that means we need to talk about 3195 (which not explicitely supports messages over 1k). IMHO, we should do a 3195bis that updates 3195 to work as a transport mapping with syslog-protocol. After we've done that, we have finally unified all syslog RFCs and do not have any more issues with incompatibilities between them. I think this is something we should do soon. Comments? Rainer PS: I, too, would like to express my seasons greetings to all folks on the list! May you have a great and peaceful xmas time and a good start into the new year. ___ 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 3195bis?
Hi, I'm OK removing references to RFC 3195 from syslog-sign for the points you mention. I'd welcome other opinions. I agree that RFC 3195 is due for an update but I disagree with most of your other points. A major vendor has found customers requesting it and has implemented it. http://www.cisco.com/en/US/products/ps6441/products_feature_guide09186a00807883c3.html Thanks, Chris On Fri, 22 Dec 2006, Rainer Gerhards wrote: The Chairs have been discussing this already. We have a candidate to write the update. The length limit in RFC 3195 was constrained by RFC 3164 and we have moved beyond that with the transport IDs which identify realistic maximum lengths. Updating RFC 3195 to have a greater length should not be a problem. HOWEVER... We need to focus on syslog-sign and syslog-device-mib BEFORE doing this. Once we get the shepherding documents for those IDs sent to the IESG _THEN_ we can discuss 3195bis. The problem is that -sign is related (even depending) on 3195. This is why I brought up that issue. Let me explain. syslog-sign recommends 2k for signature and payload blocks. It does so, because it assumes (rightly for the new series) that 2k can be handled by almost every receiver, so there is no problem in using that length. However, if we require that -sign works together with 3195, we must lower this limit to 1k. I would not like to see this happen because 2k makes much sense and is much more efficient. 3195 does not seem as important: - it is due for update - there has only been an extremely limited set of implementations - none of the major vendors has implemented it - there is no (not virtually no!) customer demand for it at the time being (I know this because I have implemented RFC 3195) - the only customer demand comes from IHE, but for IHE it is not usable because it still contains a too-rigid length constraint In short: the current RFC 3195 is not really in use. An updated version may. I think we should not sacrifice the 2k limit for something that is not being used. So my propsal is: we should remove RFC 3195 from syslog-sign as well. It should simply reference -syslog-protocol and its transport mappings. RFC 3195bis will most likely be a transport mapping. Thus, -sign can cover it without specifically mentioning it. This works exactly as the new series is designed. Transports are below -protocol and sign is in the layer above it. So there should be no dependencies between -sign and the actual transports used. If we take that route, we only lose the ability to use -sign *reliably* with RFC 3195 as it is today. Given the fact that nobody is actually using 3195, this is not a huge loss ;). It also finally de-couples -sign from any other transport RFCs - and this was a major intention about the whole effort of the new syslog series. I suggest we all have a look at this slide from 2004: http://www.syslog.cc/ietf/presentat/syslog-protocol-03/img5.html Rainer Thanks, Chris On Fri, 22 Dec 2006, Rainer Gerhards wrote: Hi all, now that we obsolete RFC 3164 by -syslog-protocol, the only remaining RFC that is not compatible to the new syslog series is RFC 3195. The questions is now how to proceed here? I am raising this issue because it has some effect on syslog-sign. I would love to see 2k as limit for sign-generated messages, but that means we need to talk about 3195 (which not explicitely supports messages over 1k). IMHO, we should do a 3195bis that updates 3195 to work as a transport mapping with syslog-protocol. After we've done that, we have finally unified all syslog RFCs and do not have any more issues with incompatibilities between them. I think this is something we should do soon. Comments? Rainer PS: I, too, would like to express my seasons greetings to all folks on the list! May you have a great and peaceful xmas time and a good start into the new year. ___ 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 3195bis?
Ah... interesting. I knew that Cisco had something brewing, but I never heared that it was released. I still agree with you that 3195 should not specifically be mentioned by -sign. I assume that implementing 3195bis (when available) is probably not hard if you implemented 3195. Rainer -Original Message- From: Chris Lonvick [mailto:[EMAIL PROTECTED] Sent: Friday, December 22, 2006 5:23 PM To: Rainer Gerhards Cc: [EMAIL PROTECTED] Subject: RE: [Syslog] RFC 3195bis? Hi, I'm OK removing references to RFC 3195 from syslog-sign for the points you mention. I'd welcome other opinions. I agree that RFC 3195 is due for an update but I disagree with most of your other points. A major vendor has found customers requesting it and has implemented it. http://www.cisco.com/en/US/products/ps6441/products_feature_guide09186a 00807883c3.html Thanks, Chris On Fri, 22 Dec 2006, Rainer Gerhards wrote: The Chairs have been discussing this already. We have a candidate to write the update. The length limit in RFC 3195 was constrained by RFC 3164 and we have moved beyond that with the transport IDs which identify realistic maximum lengths. Updating RFC 3195 to have a greater length should not be a problem. HOWEVER... We need to focus on syslog-sign and syslog-device-mib BEFORE doing this. Once we get the shepherding documents for those IDs sent to the IESG _THEN_ we can discuss 3195bis. The problem is that -sign is related (even depending) on 3195. This is why I brought up that issue. Let me explain. syslog-sign recommends 2k for signature and payload blocks. It does so, because it assumes (rightly for the new series) that 2k can be handled by almost every receiver, so there is no problem in using that length. However, if we require that -sign works together with 3195, we must lower this limit to 1k. I would not like to see this happen because 2k makes much sense and is much more efficient. 3195 does not seem as important: - it is due for update - there has only been an extremely limited set of implementations - none of the major vendors has implemented it - there is no (not virtually no!) customer demand for it at the time being (I know this because I have implemented RFC 3195) - the only customer demand comes from IHE, but for IHE it is not usable because it still contains a too-rigid length constraint In short: the current RFC 3195 is not really in use. An updated version may. I think we should not sacrifice the 2k limit for something that is not being used. So my propsal is: we should remove RFC 3195 from syslog-sign as well. It should simply reference -syslog-protocol and its transport mappings. RFC 3195bis will most likely be a transport mapping. Thus, -sign can cover it without specifically mentioning it. This works exactly as the new series is designed. Transports are below -protocol and sign is in the layer above it. So there should be no dependencies between -sign and the actual transports used. If we take that route, we only lose the ability to use -sign *reliably* with RFC 3195 as it is today. Given the fact that nobody is actually using 3195, this is not a huge loss ;). It also finally de-couples - sign from any other transport RFCs - and this was a major intention about the whole effort of the new syslog series. I suggest we all have a look at this slide from 2004: http://www.syslog.cc/ietf/presentat/syslog-protocol-03/img5.html Rainer Thanks, Chris On Fri, 22 Dec 2006, Rainer Gerhards wrote: Hi all, now that we obsolete RFC 3164 by -syslog-protocol, the only remaining RFC that is not compatible to the new syslog series is RFC 3195. The questions is now how to proceed here? I am raising this issue because it has some effect on syslog-sign. I would love to see 2k as limit for sign-generated messages, but that means we need to talk about 3195 (which not explicitely supports messages over 1k). IMHO, we should do a 3195bis that updates 3195 to work as a transport mapping with syslog-protocol. After we've done that, we have finally unified all syslog RFCs and do not have any more issues with incompatibilities between them. I think this is something we should do soon. Comments? Rainer PS: I, too, would like to express my seasons greetings to all folks on the list! May you have a great and peaceful xmas time and a good start into the new year. ___ 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 3195bis?
Much of the reason 3195 is specified is because there is no good alternative. Healthcare has been asking for a stable standard that gets implemented for 4 years now. It is getting hard to justify this allegiance to the syslog community. There are many in the healthcare community that want to define their own transport for security audit events using Web-Services. Please stop the over-analysis, get the standards you have in the queue out, and please get them implemented. John Moehrke GE Healthcare And major contributor to IHE-ATNA, DICOM-Supplement-95, RFC-3881, and BS ISO 27789. http://wiki.ihe.net/index.php?title=ATNA_Profile_FAQ -Original Message- From: Rainer Gerhards [mailto:[EMAIL PROTECTED] Sent: Friday, December 22, 2006 10:38 AM To: Chris Lonvick Cc: [EMAIL PROTECTED] Subject: RE: [Syslog] RFC 3195bis? Ah... interesting. I knew that Cisco had something brewing, but I never heared that it was released. I still agree with you that 3195 should not specifically be mentioned by -sign. I assume that implementing 3195bis (when available) is probably not hard if you implemented 3195. Rainer -Original Message- From: Chris Lonvick [mailto:[EMAIL PROTECTED] Sent: Friday, December 22, 2006 5:23 PM To: Rainer Gerhards Cc: [EMAIL PROTECTED] Subject: RE: [Syslog] RFC 3195bis? Hi, I'm OK removing references to RFC 3195 from syslog-sign for the points you mention. I'd welcome other opinions. I agree that RFC 3195 is due for an update but I disagree with most of your other points. A major vendor has found customers requesting it and has implemented it. http://www.cisco.com/en/US/products/ps6441/products_feature_gu ide09186a 00807883c3.html Thanks, Chris On Fri, 22 Dec 2006, Rainer Gerhards wrote: The Chairs have been discussing this already. We have a candidate to write the update. The length limit in RFC 3195 was constrained by RFC 3164 and we have moved beyond that with the transport IDs which identify realistic maximum lengths. Updating RFC 3195 to have a greater length should not be a problem. HOWEVER... We need to focus on syslog-sign and syslog-device-mib BEFORE doing this. Once we get the shepherding documents for those IDs sent to the IESG _THEN_ we can discuss 3195bis. The problem is that -sign is related (even depending) on 3195. This is why I brought up that issue. Let me explain. syslog-sign recommends 2k for signature and payload blocks. It does so, because it assumes (rightly for the new series) that 2k can be handled by almost every receiver, so there is no problem in using that length. However, if we require that -sign works together with 3195, we must lower this limit to 1k. I would not like to see this happen because 2k makes much sense and is much more efficient. 3195 does not seem as important: - it is due for update - there has only been an extremely limited set of implementations - none of the major vendors has implemented it - there is no (not virtually no!) customer demand for it at the time being (I know this because I have implemented RFC 3195) - the only customer demand comes from IHE, but for IHE it is not usable because it still contains a too-rigid length constraint In short: the current RFC 3195 is not really in use. An updated version may. I think we should not sacrifice the 2k limit for something that is not being used. So my propsal is: we should remove RFC 3195 from syslog-sign as well. It should simply reference -syslog-protocol and its transport mappings. RFC 3195bis will most likely be a transport mapping. Thus, -sign can cover it without specifically mentioning it. This works exactly as the new series is designed. Transports are below -protocol and sign is in the layer above it. So there should be no dependencies between -sign and the actual transports used. If we take that route, we only lose the ability to use -sign *reliably* with RFC 3195 as it is today. Given the fact that nobody is actually using 3195, this is not a huge loss ;). It also finally de-couples - sign from any other transport RFCs - and this was a major intention about the whole effort of the new syslog series. I suggest we all have a look at this slide from 2004: http://www.syslog.cc/ietf/presentat/syslog-protocol-03/img5.html Rainer Thanks, Chris On Fri, 22 Dec 2006, Rainer Gerhards wrote: Hi all, now that we obsolete RFC 3164 by -syslog-protocol, the only remaining RFC that is not compatible to the new syslog series is RFC 3195. The questions is now how to proceed here? I am raising this issue because it has some effect on syslog-sign. I would love to see 2k as limit for sign-generated messages, but that
Re: TransportDomain. Was: Re: [Syslog] Submission ofdraft-ietf-syslog-device-mib-12.txt
I am not convinced that the proposed solutions match the underlying problem.
Syslog:
- can be -protocol or RFC3164 (or RFC3164bis or ...)
- may be signed.
- may be secured with TLS (or SSH or DTLS or ...)
- could run over UDP or TCP (or SCTP or ..)
What we have then done is to bind -protocol to TLS to TCP in a package and asked
IANA for a port number less that 1024 for that combination
So I think that trying to analyse it in terms of, eg, InetAddressType,
InetAddress, InetPortNumber and SyslogEncapsulation won't work.
Tom Petch
- Original Message -
From: Juergen Schoenwaelder [EMAIL PROTECTED]
To: Glenn M. Keeni [EMAIL PROTECTED]
Cc: Wijnen, Bert (Bert) [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Friday, December 22, 2006 10:34 AM
Subject: Re: TransportDomain. Was: Re: [Syslog] Submission
ofdraft-ietf-syslog-device-mib-12.txt
On Fri, Dec 22, 2006 at 11:24:10AM +0900, Glenn M. Keeni wrote:
- How do I find out which encapsulations are supported (plain, beep,
tls, ...)?
That is the problem we are trying to solve.
Can that be done by defining appropriate domains for
syslog transport over TLS
syslog transport over beep etc. ?
Option a):
You use a four tuple consisting of:
(InetAddressType, InetAddress, InetPortNumer, SyslogEncapsulation)
Option b):
You use a three tuple consisting of:
(TransportAddressType, TransportAddress, SyslogEncapsulation)
In both cases, you need to define a TC SyslogEncapsulation which
enumerates the syslog encapsulations (or transport mappings) such as {
other(0), plain(1), tls(2), beep(3), ... }.
InetAddress identifies Internet network layer endpoints while
TransportAddress identifies Internet transport layer endpoints, no
more no less. If you want to move to a two tuple, the only option in
principle is:
Option c):
You use a two tuple consisting of
(SyslogAddressType, SyslogAddress)
where SyslogAddressType combines the address type with the
encapsulation (this is essentially what a TDomain does for SNMP)
/js
--
Juergen Schoenwaelder {International|Jacobs} University Bremen
http://www.eecs.iu-bremen.de/ P.O. Box 750 561, 28725 Bremen, Germany
___
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: TransportDomain. Was: Re: [Syslog] Submission ofdraft-ietf-syslog-device-mib-12.txt
On Fri, Dec 22, 2006 at 07:17:18PM +0100, tom.petch wrote:
I am not convinced that the proposed solutions match the underlying problem.
Syslog:
- can be -protocol or RFC3164 (or RFC3164bis or ...)
- may be signed.
- may be secured with TLS (or SSH or DTLS or ...)
- could run over UDP or TCP (or SCTP or ..)
What we have then done is to bind -protocol to TLS to TCP in a
package and asked IANA for a port number less that 1024 for that
combination
So I think that trying to analyse it in terms of, eg, InetAddressType,
InetAddress, InetPortNumber and SyslogEncapsulation won't work.
I don't get your message - can you enlighten us please?
/js
--
Juergen Schoenwaelder{International|Jacobs} University Bremen
http://www.eecs.iu-bremen.de/ P.O. Box 750 561, 28725 Bremen, Germany
___
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog
