Chris, What I'd like to see happen is for 3195 to be broken up into 2 or more new RFCs, one (or more) which cover the protocol and one which defines their use over BEEP.
i.e. One which covers the COOKED profile, one which covers a RAW profile and one which covers one or both of these over BEEP. We may also choose to add a BSD profile (which is syslog-protocol or an enhanced version of 3164.) That nails down the protocol. Next we move on to defining how the protocol is used. So we describe syslog (COOKED/RAW/BSD) over BEEP/ssh/TLS/UDP/TCP. I think if we evolve that way there is a much better chance of aligning ourselves with what people are doing and want to do without rendering what we've done to the scrap heap completely. It may also be worth taking input from those who have developed or deployed 3195 to understand if there are components of it that did/didn't work. When we get close to getting all of that documentation done, I'd be for advocating that 3195 be moved to "experimental" status, rather than obsolete. For example, chosing this path gives us a syslog-BSD/tcp that should be close enough to what people are doing today with this, bringing together most of these implementations as being RFC compliant. I expect work will be required on both sides to evolve it a little to get there, but I think there's considerable advantage for us and developers if a little work on the part of each party results in RFC compliant software. Sam, do you have any comments on taking this approach with the syslog protocols by the working group ? Cheers, Darren _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
