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 > > > > > > > > > > > > > > > > > > > > > > > >
