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 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 > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
