Hi, I am concerned about the emphasis on backwards compatibility. The reason people want a standard is that existing server implementations have made different design decisions, and device and application vendors are forced to either interoperate with one vendor-specific server implementation, or need to write code to support different server implementations. Device and application vendors would like one consistent solution that is vendor-neutral so their implementations will interoperate with any standard-compliant server.
If we strive for backwards compatibility, we will end up with a standard that simply rubber-stamps many of the non-interoperable, vendor-specific existing server implementations. We should be striving to produce a standard for syslog that is vendor-neutral and that helps server and equipment/application vendors produce interoperable implementations using one standard syslog specification. I am, however, a strong believer in making it fairly easy for vendors to migrate from their existing vendor-specific non-interoperable implementations to a vendor-neutral interoperable standard, and to make it possible for servers and senders to support both the existing syslog and the new standard for syslog. I believe we should emphasize "ease of migration and co-existence" rather than "backwards compatibility". I suggest changing "The goal of this working group is to address the security and integrity problems of the existing syslog mechanism while not breaking backwards compatibility." To "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." Some charter items could be interpreted as documenting existing practices, rather than documenting an agreed-to standardized approach for these aspects of syslog. I suggest changing > - A standard will be produced that formally documents the syslog > protocol. A mechanism will also be defined in this specification > that will provide a means to convey structured data. > > - A standard will be produced that documents the UDP transport for > syslog. > > - A standard will be produced that documents a mechanism to sign > syslog messages to provide integrity checking and source > authentication. > To " - A document will be produced that describes a standardized syslog protocol. A mechanism will also be defined in this document that will provide a means to convey structured data. - A document will be produced that describes a standardized UDP transport for syslog. - A document will be produced that describes a standardized mechanism to sign syslog messages to provide integrity checking and source authentication." David Harrington [EMAIL PROTECTED] _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
