Darren, I mostly agree, but my main point is that all this has been discussed. My presentation from 2 years ago covers exactly these issues.
For example... 22 Jan 2004 - talking about backwards compatibility and its importance http://www.syslog.cc/ietf/autoarc/msg00000.html 3 Feb 2004 - talking about transport ignorance and the need for a TCP mapping: http://www.syslog.cc/ietf/autoarc/msg01038.html 24 Feb 2004 - asking for a seperate doc on relay (to keep docs smaller) http://www.syslog.cc/ietf/autoarc/msg01155.html If I searched a little more through the archives, I would probably find another myriad of postings where others and I cautioned against changing too much. However, the consensus (then and on-list) was that we should add all these bells and whistles. I would definitely appreciate if the WG would result in a (series of) usable document(s). The plain fact, however, is that syslog is working quite well in practice. I have implemented complex syslog senders, relays and clients on Windows and Linux for several years now. My softwares support syslog/udp, syslog/plain tcp, even RFC3195/RAW and partial RFC3195/COOKED. I've written articles on how to encrypt syslog traffic and advised on how to ensure client authentication. I am about to implement native ssl-encryption and authentication in my softwares. I know stock syslogd code on Linux and BSD quite well. I know neither of them does syslog in the way RFC 3164 describes. Most importantly, I've implemented lots of code to tackle all this differences. Of course, my implementations are interoperable with the major other syslogs, like stock syslogd, kiwi syslog on windows and syslog-ng on *nix - both in plain and encrypted modes. I've done extremely simple code as well as high-performance multi-threaded ones (which will show you some weaknesses in the specs you don't see if you only do the simple stuff). And, yes, my software handles DBCS character sets and is able to process very large messages, should there be a need (and there sometimes is a need, even if the WG tends to object this). BTW: I implemented a RFC 3164 mode, and we needed to turn it off by default because almost nothing is compatible with that. I've tried to promote RFC 3195, even written a free-for-all-uses, open-sourced library for that and seen that nobody in the syslog community is interested in any of that. I know that a totally reliable (and thus blocking) transport is not desirable in all cases - it might cause denial of service (just like PIX stalls if it is set to tcp syslog and the syslogd dies - similar fatal cases exist if the *nix system logger stalls). So I have the tendency to think I know at least a little what is needed in syslog. And, yes, I agree that we do not urgently need the truncation bit and some other stuff. BUT... as long as these things are violently requested on the mailing list AND it is concensus that they are needed - how can I keep them out of a WG draft? I'd told Chris in private mail that I would be willing to change syslog-protocol so that it could life within the constraints of RFC 3164 (which does NOT describe what the majority of implementations does!). However, any such effort only makes sense when there is a chance that we get a real discusssion on the list. And especially one that is consistent with the discussion in the meetings. And I begin to strongly doubt that... Rainer > -----Original Message----- > From: Darren Reed [mailto:[EMAIL PROTECTED] > Sent: Wednesday, November 16, 2005 1:24 PM > To: Rainer Gerhards > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: Re: [Syslog] Charter revision / WG obsolete? > > Hi all, > > > If I get the essence in Darren's message right, > > what he is proposing is to create a layered architecture for syslog. > > Yes, by using what's gone before us as the way to start doing that. > > > Please face it: on the WG mailing list, we are pressing for ever and > > ever change. More and more new things. At least in the last > meeting, we > > are trying to conserve as much as possible (which I > personally like). > > This won't go together. > > What I think the WG is lacking is a good long term focus of > objectives. > > I believe this is largely because the group has been meandering along. > > I think we need to refocus by looking at where people are going with > developing syslog protocols and evolve what exists today to meet that. > > > Obviously, I am not participating > > in the meetings for a reason: I simply can not justify > traveling around > > the world for a 30 minute time slot even without a strong > business case. > > I thought that personal participance is not a absolute must > in IETF work > > (though I clearly understand its importance). > > Which is why those who attend the meetings are often involved in more > than a single WG. > > .. > > - we ignore running code and rough consenus existing in practice > > (syslog/tcp) > > My hope is that if we pursue a layered approach will allow us to > easily document a protocol that covers the existing practice in > this area as well as provide a path for future design. > > > Please do not misunderstand me: of course, I am a bit > frustrated about > > that this WG has fundamental problems. I personally doubt > it makes sense > > to continue without solving them. > > Where I think we've gone wrong and I hear indications of "going wrong" > are with people who want to solve their own pet problem - we've lost > sight of the big picture. For example, the different message format > to allow bit-banging for indicate this or that has happened > to the message. > For most people, it does nothing. As too with XML - I'm sure there is > a large contingent of developers out there who balk at any document > that mentions XML, even if its optional. > > I think the WG should remain and has a purpose. At the meeting > Sam Hartman mentioned that we were going nowhere fast and in danger > of being shut down. Apparently this isn't uncommon but I think that > although there problems that they aren't beyond fixing. > > I think the key to achieving a good result has got to be thinking > that it is ok to have lots of small documents rather than just one > big document. If nothing else, it should make the work required > to produce a single one down and therefore more attractive. > > Darren > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
