I could throw in a couple of comments to this thread ... but I think Anton has well summed it up. I, too, vote that we get the current work done. I'd like to begin to fiddle a little on the storage format before the WG can actually look at it - I'll do so via loganalysis, but only after -protocol-03 ;). Hopefully that loganalysis discussion will lead to something that we can eventually reuse later here in the WG.
In fact, I am delighted to see that it seems possible to standardize non-on-the-wire things in a RFC (or at least provide a best practice reference). Honestly, going to another standards body is not an option for me, simply because for all the others you seem to primarily need big money and not tech arguments ;) Big money is out of scope for us ;) As some suggested, we may later be able to integrate those things into another standard, but that needs to be seen when there is time. Again, my mail has become longer than it should: Quick summary: I, too, think we should concentrate on finishing things ASAP, and then look into further work. Rainer > -----Original Message----- > From: Anton Okmianski [mailto:[EMAIL PROTECTED] > Sent: Tuesday, February 10, 2004 11:36 PM > To: 'Chris Lonvick' > Cc: [EMAIL PROTECTED] > Subject: RE: -international: trailer > > Chris: > > Sounds reasonable. Let's get the other stuff completed first. > > Anton. > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of Chris Lonvick > > Sent: Tuesday, February 10, 2004 3:55 PM > > To: Anton Okmianski > > Cc: [EMAIL PROTECTED] > > Subject: RE: -international: trailer > > > > > > Hi Anton, > > > > On Tue, 10 Feb 2004, Anton Okmianski wrote: > > > > > Rainer: > > > > > > I am really struggling with that restriction not to > > standardize syslog > > > storage in IETF. It diminishes the value of the syslog > protocol as > > > people can't write a standard syslog parser. > > > > > > It would be nice if we could find another standards body > > which could > > > be used to address that aspect. I assume log analysis > > mailing list is > > > not affiliated with a standards body, or is it? I wonder if > > there is > > > good precedent out there of two standards bodies working in tandem > > > like this. Maybe W3C? > > > > It may be that the IETF will accept that work. However, it > > outside of our current charter and that's not going to change > > until after we complete the work we have going on in: > > - syslog-protocol > > - syslog-transport > > - syslog-sign > > One could argue that without guidance from these documents, > > the question of storage is rather ambiguous; what are you > > receiving to store and what protection mechanisms are > > available with them. I would also think that if such work is > > undertaken in the future and it finds a problem with one of > > these standards, then the standard may be changed. However, > > at this point, we need to put a stake in the ground and > > complete what's in front of us. > > > > If you really want to find another spot in the IETF, approach > > the OAM Area Directors with a proposal. If you'd like to go > > outside, I'd suggest NRIC or T1M1 (through ATIS). > > > > > > > > Somebody suggested to me an idea that maybe a bit wild, but could > > > address this. A protocol for syslog server to return > > messages it has > > > stored. It could be UDP-based. How much less efficient > > would that be > > > than reading a file? I don't think the difference will be > > huge as I/O > > > will likely be the bigger bottleneck anyway. Essentially, > > the messages > > > could be returned using the same -protocol & -transport > and we just > > > need to add some request/response semantics. This does > > sound pretty > > > wild, but desperate times call for desperate measures :) > > and I thought > > > I would just pass it along. > > > > Actually, I think I'd like to see what comes out of Netconf > > before this WG looks down that path. > > > > Thanks, > > Chris > > > > > > > > Anton. > > > > > > > -----Original Message----- > > > > From: Rainer Gerhards [mailto:[EMAIL PROTECTED] > > > > Sent: Tuesday, February 10, 2004 12:15 PM > > > > To: Andrew Ross; Harrington, David; Anton Okmianski; > > > > [EMAIL PROTECTED] > > > > Subject: RE: -international: trailer > > > > > > > > > > > > Hi All, > > > > > > > > I am a bit sad that I use Andrew's message to say this... > > but Andrew > > > > has just made an important point that enlightens me on David's > > > > thought that those CLRs (crappy little rules [I like > this term]) > > > > really cause trouble. So Andrew please don't take my objection > > > > personally, I see your reasoning behind it... > > > > > > > > ... but this is an excellent sample on how granting one > exception > > > > (the 0x00 case) leads to calls for further exceptions > > (0x0a in this > > > > case). I have to admit I didn't think well enough about this. > > > > > > > > Also, I was technically incorrect in insisting on 0x00 to be too > > > > hard for C. Actually, I worked out a surprisingly easy, > > obvious and > > > > well-known escaping mechanism to handle 0x00 once the message is > > > > received. It looks like I was just too narrow-minded to > > think with > > > > an open enough mind to solve it. Thanks to all who kept > > pushing me > > > > :) > > > > > > > > But, honestly, even if I would not see an easy solution > for the C > > > > case, I think we should follow David's advise and avoid any such > > > > rules (like the 0x00 exception). In the long term, they > > cause more > > > > trouble in the long term than the solve initially. > > > > > > > > So I, too, now vote that we must support any valid UTF-8 > > sequence in > > > > the MSG part, which includes 0x00. If nobody objects, I > > will change > > > > -protocol to specify this. If you have objections, I would > > > > appreciate if you could reply relatively quickly, as I > try to get > > > > -03 out before Seoul. > > > > > > > > Now let me come to the C implementation and other things, like > > > > syslog storage format. As we have discussed on this list, these > > > > things are - at least at first look - not relevant to IETF work. > > > > This is because they simply don't talk about on-the-wire > > protocols. > > > > And only this is scope of the IETF. Anyhow, it would > > definitely be a > > > > positive undertaking to reach concensus among > > implementors how those > > > > things should be addressed. To have a "least common denominator > > > > approach" that customers could expect to be in syslog > > products they > > > > purchase/use. Even for the implementors among us, such an > > > > approach would simplify things when it comes to the parsing > > > > and analysis stage. > > > > > > > > I have talked to Chris as well as Tina Bird, who is the > > moderator of > > > > the loganalysis mailing list > > > > (http://lists.shmoo.com/mailman/listinfo/logan> alysis). We have > > > > agreed that we can move discussion for non-IETF topics over to > > > > loganalysis. The big plus in this is that there are also > > many, many > > > > administrators on the list, so we will most probably > get a lot of > > > > feedback from the end user camp, too. I think this is extremely > > > > valuable. > > > > > > > > I plan, however, to focus just some few days on > -protocol and not > > > > directly start this other discussion. I think this serves our > > > > deadlines (Seoul meeting) better than doing too much in > parallel. > > > > After that, I plan to post an initial message for those > topics on > > > > the loganalysis list. If Chris permits, I would cross-post these > > > > message here to the WG list (together with my whish to > > only reply to > > > > loganalysis;)). > > > > > > > > I hope this is a good proposal, one that will allow us to make > > > > syslog even more interoperable than it is today. > > > > > > > > Rainer > > > > > > > > > -----Original Message----- > > > > > From: Andrew Ross [mailto:[EMAIL PROTECTED] > > > > > Sent: Sunday, February 08, 2004 12:52 AM > > > > > To: Rainer Gerhards; 'Harrington, David'; 'Anton Okmianski'; > > > > > [EMAIL PROTECTED] > > > > > Subject: RE: -international: trailer > > > > > > > > > > > > > > > It is not just the 0x00 that we have to worry about. For > > > > TCP transport > > > > > mappings, we need to have a stream delimiter. Currently it is > > > > > generally agreed that it is LF (0x0A). If we don't escape that > > > > > character, we will have to resort to a byte length > > field. Please > > > > > don't make me have to drag > > > > > out my old Syslog over TCP proposal :-) > > > > > > > > > > Cheers > > > > > > > > > > Andrew > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
