Subject: [Syslog] Backward compatibility

From: "Rainer Gerhards" <[email-masked]>
Date: Thu, 17 Aug 2006 05:02:26 +0200

Hi all,

I just would like to refresh your memory about what happened last year.
As David has already pointed out, the WG was stalled on backwards
compatibility issues. Actually, it was nearly torn apart by them.

What happened is very similar to the current discussion:

Last year (and the year before), we have been discussing how syslog
could be improved. We argued about backwards compatibility much in the
same way we do now. The difference was that we did not persist that much
with asking for it. So we moved to a glory new and clean world of
non-backwards compatible but great syslog. We created documents in that
spirit, always knowing that it would be a bad idea to sacrifice any of
the "cleanless" on the altair of legacy syslog. We reached consensus on
list, had wg last call, and were quite happy with the documents.

Then came an IETF meeting where everything should be finalized. We
expected everything would move smoothly. Quite the difference happened.
The documents were violently objected because backwards compatibility
was now considered overly important. Long-term WG members were quite
surprised (to phrase it mildly) and for some weeks it looked like the WG
would be concluded without finishing its goals.

Then, the WG recovered and a new charter was crafted. One of the big
topics in that charter is backwards compatibility. This is, why that
sentence is in the charter:

---
The goal of this working group is to address the security and integrity
problems, and to standardize the syslog protocol, transport, and a
select set of mechanisms in a manner that ######considers the ease of
migration between and the co-existence of existing versions and the
Standard####.
---

I was working hard at this time to get the nonsense backwards
compatibility issues out of the charter that did not exist in realtiy
(because legacy syslog itself was not compatible to it).

Besides being close to concluded, last years compatibility issue caused
loss of considerable  work.

What you now need to consider is that last years backward compatibility
issue was of much less substance than the current one is. What was
considered "legacy standard" was mostly non-existing (I have shown that
in numerous posts). There were (and there are) much less similarity
between different syslogd message formats than there are similarities
between the popular syslog over TCP (over SSL) solutions which are
deployed.

Do not misunderstand me: I like clean solutions, just as I have liked
them last year. My experience, however, generates a big warning alert. I
do *not* once again like to create a set of documents just to get it
objected because it is not compatible to existing technology. This time,
we have a very simple and clean way to introduce it. This time, there is
actually value in doing that. I agree it is not as technically clean as
octet-couting, but it is within acceptable limits (at least mine).
Again, I do not object octect-couting. I just want to make sure that
everybody is aware of the history of this WG when it comes to backwards
compatibility.

What I object is wasting another year just on a simple question like
this one. If we can make sure that won't happen, I am quite happy with
octet-counting. If, however, the I-D's fail either in the next meeting
or last call because of exactly this reason I am more than upset and
would quit any further work on syslog.

Besides octet-counting/LF we should look at other issues in the light of
things that happened. Please see the mailing list archive if you do not
believe what I have written.

Again, I do NOT object octet-couting. I want try to make sure it wont be
the last nail in the coffin of this WG, though.

Thanks,
Rainer

_______________________________________________
Syslog mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/syslog