I fully agree with David. That charter would work well and also cover keeping the <PRI>. It would make clear that we are not trying to get full backwards compatibility.
Rainer > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of David B Harrington > Sent: Tuesday, November 22, 2005 12:21 AM > To: 'Chris Lonvick'; [EMAIL PROTECTED] > Subject: RE: [Syslog] New direction and proposed charter > > 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 > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
