> 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
