Andrew, Anton,
I am using Andrew's message to reply to both. I concur with Andrew,
please see below...
-----Original Message-----
From: Andrew Ross [mailto:[EMAIL PROTECTED]
Sent: Thursday, December 21, 2006 10:53 PM
To: Rainer Gerhards
Subject: RE: [Syslog] RFC 3164
Hi Rainer,
Merry Christmas!
Sorry I've been out of the discussion loop for so long, things have
been
pretty hectic over here. I know that the new protocols are in good
hands
though.
With regard to 3164. I would prefer to obsolete 3164 with a document
that
details what is actually seen in real life on the wire. This would
just
mean
adding some extra text to the 3164 document and adding in some
examples
of
what is seen by different OS senders. Pretty much the research you
presented
to the list a while ago. This new document would then obsolete 3164.
That would actually be my prefferred way to handle things. Other than
Andrew, I think we should remove/change most of the text, as indeed only
PRI is available on an universal basis. Samples of different message
formats can be used to convey that information.
We get asked so often by customers if we are 3164 compliant. We used
to
explain that 3164 is not really valid, but that didn't satisfy them,
so
we
just said "yes, we are compliant" to keep them happy.
Now to the question "why do that?". Andrew has a very valid point here.
We experience the same quite often. We even added an option "use RFC
3164 compatible format" to our product and guess what - it is turned off
most of the time because RFC 3164 does not describe what receivers and
senders typically do ;). Even if we obsolete 3164 with -protocol, I know
a lot of folks will come and ask "Hey, do you support the old standard
that most of my other devices use?". They simply will not care about it
being obsoleted by something different. However, if we go ahead and
crate 3164bis (another informational document), the situation will IMHO
change. Now there is a newer "standard" (as people perceive it) for the
"old" syslog. And if that says "You can not trust anything but PRI" I
can "sell" that. Plus, I have a very good point in argumenting why
syslog-protocol is superior.
I know I am not talking hard technical facts here. I am talking real
life. Most people do not care if a RFC is informational or standards
track. If it is a RFC, it must be something products comply too. I agree
that implementors should understand the difference. They
(hopefully/probably) do. But do implementors actually decide what to
implement? No - not in my experience. The marketing department tells
them what to do. And customers tell the marketing department. And guess
what? These customers are the informed masses that do *not* know the
inner workings of the IETF (aka "a RFC is a RFC is a RFC...").
Even in a technical context like the IETF I think a little bit of
real-world politics can be considered. It is the key to acceptance of
new standards.
Rainer
Cheers
Andrew
-----Original Message-----
From: Rainer Gerhards [mailto:[EMAIL PROTECTED]
Sent: Thursday, 21 December 2006 8:13 p.m.
To: [EMAIL PROTECTED]
Subject: [Syslog] RFC 3164
Hi all,
I just realized that the future of RFC 3164 is not yet publically
discussed.
RFC 3164 is a well-done work, but we have made much progress in the
past
5 years since it was written. Most importantly, we discovered that
actual syslog software uses a much different set of formats than
expected by 3164. This was the source of much discussion inside the WG
and we did a lot of testing to confirm the findings. The bottom line
is
that we now know that 3164 does *not* acurately describe what is
observed in the wild. Nobody is to blame here - the breadth of
information we created the past years was simply not available (nor
were
the ressources to do the testing) to the orginal authors of RFC 3164.
Having said that, I think we must do something about the situation. In
practice I see more and more vendors claim compliance to RFC 3164.
This
is kind of funny in itself, because 3164 is just an information
document, so you can not be compliant to it ;) Anyhow, many vendors
seem
to have a wrong impression and use this in their advertising as well
as
tech support.
I think we should do either one of the following:
1. create an updated RFC 3164bis
2. obsolete RFC 3164
I personally would tend to 1. - update the document with what we have
gained on additional knowledge. I have been told that this would be
somewhat unusual for the IETF, as 3164 is only informational and
-transport-protocol will soon set a real standard. So updating
information on "the past" seems not to be useful. However, I expect
traditional syslog to stay around for at least another 5 to 10 years,
if
not longer. I would consider it a plus to have a RFC that accurately
describes the format that we can expect from such a legacy syslog
sender. Most importantly, it will remove any false secure feeling
about
format standardization where there is none.
I would appreciate comments on this issue.
Rainer
_______________________________________________
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog
_______________________________________________
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog
