RE: [logs] idea: let's scare ourselves...

From: Marcus J. Ranum (mjr@private)
Date: Wed Aug 11 2004 - 11:18:36 PDT


Rainer is stepping forward as a messenger; I am going to try to
shoot at the message behind him, but I apologize in advance if
some of my rounds come a little close to the messenger...

Rainer Gerhards wrote:
>I know that you do not believe in RFCs ...

I believe in RFCs, but no longer in the process whereby they are made...

>The draft is soon to be in last call, that means it is on its way to a
>standard-track RFC. 

Hasn't this kind of been going on forever, like most IETF working
groups' efforts??

>At least some of your points HAVE been included
>(like the timestamp, hostname and such). There is a new, layered
>approach which enables syslog to travel over a variety of protocols.
>Thogh not popular in the IETF, this may mean it can also travel over
>non-BEEP TCP IF there is enough voiced demand for this.

Most of the responses I've seen on this list and other places
imply that the universal response to BEEP has been gales
of uprorious laughter, in a Monty-Python-esque sort of way.
I haven't been tracking the IETF's efforts (because I know
that whatever comes out the back end will be overengineered,
overcomplex, barely functional, and will lack the fundamental
property of unity of mechanism with other core systems) - it
sounds like BEEP got stuck into the mix because it was
someone on some committee's brainchild, and now you've
got another layer that makes it an option? Ugh. You
know the old joke  about an elephant being a mouse designed
by a committee? The IETF designs garbage trucks.

As many of the members of this list can attest, there are things
we don't like about syslog. There are things we'd like to see
different. But mostly we'd just like something simple that works.
We don't need BEEP or protocol-over-protocol switching. We'd
like very very few things out of a new syslog:
- year in the date
- send the traffic over a TCP optionally encrypted link

Years in the date do not require a massive standards-track
effort; they require a change to one line of code.

Transmitting the traffic over a better channel requires linking
in a library from among many. Using a totally different communications
mechanism (which is more complex than the entirety of syslog in
and of itself) is utterly silly when there are common mechanisms
in use.

If I *cared* what was going on in the working group, I'd wonder
what the hell they were thinking.

>NOW is the time to make your
>voice heared, because NOW the protocol is under heavy review ...

That's the normal IETF mode, though. RFCs are always under
heavy review until finally comes a day when there is one person
who cares left standing. And then he writes his favorite pet features
into the RFC and nobody cares anymore...

>but
>only few voices are really heared. Honestly, I think it is not helpful
>to say "syslog is bad" and NOT to try to change it. Of course, its
>easier ;) Standards take some time, but the good thing is that without
>standards, we  just have either interop-problems or a monopoly...

Most of us have been doing things to fix the problem. Namely,
not waiting for the standards guys, and just going on and fixing
the problem.

I must disagree utterly with your assumption that the standards
process effectively prevents either interoperation problems or
monopoly. The monopoly issue we need not discuss further,
since the reality there is blindingly obvious. With respect to
interoperability - that is a more interesting problem. The IETF,
in its original concept, was a group that favored "rough consensus
and running code" - which, if you think about it for a second, is
a ratification of installed base and reference implementation.
In a very real sense, the original concept of the IETF (though
its adherents didn't want to recognize it as such) was a ratification
of near monopoly. After all, if you have 2 independent, open,
functional reference implementations, you have (potentially)
an installed base. And, if that installed base is good enough
and solves the right problems, then it will be used. Or it won't.
The history if the IETF is littered with such failures - cases
where the technologist and end-user community took a look
at the results of the IETF's process and shrugged. The
short-lived competition between IETF's privacy-enhanced
effort and PGP is a good example. In a very real sense, the
wide prevalence of Microsoft-dominated single-vendor
standards represents a massive repudiation of IETF's
message and value.

But if we hearken back to the historical roots of the IETF, we
can see that same process functioning in a different context
in the Open Source community. How many more security
practitioners are using syslog-NG right now compared to
the BEEP-based bloat? How many operating system distributions
package or port or RPM syslog-NG? Is this "rough consensus
and working code" or what?

My prediction is that if IETF ever manages to complete
getting a standard out on syslog, it'll be irrelevant and largely
ignored. If it comes out with a bloated overengineered
duplication of existing mechanism like BEEP then it'll
be laughed at, or ignored. Neither is good.

mjr. 

_______________________________________________
LogAnalysis mailing list
LogAnalysis@private
http://lists.shmoo.com/mailman/listinfo/loganalysis



This archive was generated by hypermail 2.1.3 : Wed Aug 11 2004 - 12:06:52 PDT