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 protected] https://www1.ietf.org/mailman/listinfo/syslog
