I think the charter looks good. It describes what the working group has to do and its deliverables. I agree that there is a next level of details that spells out the specifics of how to do it. We had a lot of discussion on this and seem to have come to a consensus, which is something that we should capture. However, the question is if that next level (the "how" in addition to the "what") really belongs in a charter - not sure if the charter would be the right place. -- Alex
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Anton Okmianski (aokmians) Sent: Wednesday, November 23, 2005 9:29 AM To: Chris Lonvick (clonvick); [EMAIL PROTECTED] Subject: RE: [Syslog] Revised proposed charter Chris: This is fine, but does not include all the other specific details we agreed on and as such is not different from what we had before. I think we can focus our efforts better by creating narrower scope. How about limiting backwards compatibility to <PRI> only. Requiring standardization of better time stamp. Support for FQDN, IPv6. MSGID. Internationalization (UTF-8). Etc... I am afraid that if we leave the charter open-ended as before, we will be debating the charter again 2 years from now. Also, sorry if I missed some earlier discussions on signing messages. Proposed charter mentions source authentication. For TCP mappings (such as BEEP), TLS already provides authentication and encryption. SSH transport would provide similar facilities. Is there an overlap here? Is message signing targeted at just UDP transport? Thanks, Anton. > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Chris Lonvick > (clonvick) > Sent: Wednesday, November 23, 2005 12:05 PM > To: [EMAIL PROTECTED] > Subject: [Syslog] Revised proposed charter > > Hi All, > > ==== v2 of proposed charter === > > Syslog is a de-facto standard for logging system events. > However, the protocol component of this event logging system has not > been formally documented. While the protocol has been very useful and > scalable, it has some known security problems which were documented in > RFC 3164. > > 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. > > syslog has traditionally been transported over UDP and this WG has > already defined RFC 3195 for the reliable transport for the syslog > messages. The WG will separate the UDP transport from the protocol so > that others may define additional transports in the future. > > > - 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. > > > === === > > Comments please. > > Thanks, > Chris > > _______________________________________________ > 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 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
