Subject: RE: [Syslog] Charter revision / WG obsolete?

From: "Rainer Gerhards" <[email-masked]>
Date: Wed, 16 Nov 2005 14:50:45 +0100

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-masked]] 
> Sent: Wednesday, November 16, 2005 1:24 PM
> To: Rainer Gerhards
> Cc: [email-masked]; [email-masked]
> 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/syslog