Hi, Comments inline
> -----Original Message----- > From: Anton Okmianski [mailto:[EMAIL PROTECTED] >> Subject: RE: -international: trailer > > 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. I'm not sure I understand why you feel this. Assuming you are parsing what was sent on the wire, that should be standard (to the degree that we standardize it). How an implementation stores it after receipt is implementation-dependent, and probably needs to consider the underlying OS, the expected purposes of stored messages, the language used in the implementation. These should not be of concern to us. If you are interested in trying to standardize a post-storage parser, there is no reason why the implementors cannot reach agreement on a storage format and have it published in the IETF, but the implementation-specific decisions should not affect the on-the-wire designs. > > 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? If you reach agreement and publish an informational RFC, you may be able to convince the WG/IETF to put it on the standards track, if you can show that it would help the industry. > > 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. Let's not try to create a protocol just to standardzie something not directly related to the internet. If you want to develop a parser and have the parser accepted as a "standard" why don't you just develop it as open source, say, on sourceforge? If everybody uses it, it will become a defacto standard. You don't need to make it an IETF standard. > > 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 > > > > > > > > > > > > >
