The IESG has approved the following documents: - 'The syslog Protocol ' <draft-ietf-syslog-protocol-23.txt> as a Proposed Standard - 'Transmission of syslog messages over UDP ' <draft-ietf-syslog-transport-udp-12.txt> as a Proposed Standard These documents are products of the Security Issues in Network Event Logging Working Group. The IESG contact persons are Sam Hartman and Tim Polk. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-syslog-protocol-23.txt Technical Summary This document describes the syslog protocol, which is used to convey event notification messages. This protocol utilizes a layered architecture, which allows the use of any number of transport protocols for transmission of syslog messages. It also provides a message format that allows vendor-specific extensions to be provided in a structured way. This document has been written with the anticipated original design goals for traditional syslog in mind. The reason for a new layered specification has arisen because standardization efforts for reliable and secure syslog extensions suffer from the lack of a standards- track and transport independent RFC. Without this document, each other standard needs to define its own syslog packet format and transport mechanism, which over time will introduce subtle compatibility issues. This document tries to provide a foundation that syslog extensions can build on. This layered architecture approach also provides a solid basis that allows code to be written once for each syslog feature rather than once for each transport. This ballot also includes the UDP transport for syslog. This transport is similar to that used across the internet today. Working Group Summary The working group had consensus to publish these documents as a proposed standard. Protocol Quality This document has been reviewed by Sam Hartman for the IESG. Note to RFC Editor The protocol draft obsoletes RFC 3164 In the protocol draft section 6.4: old: If a syslog application is processing a MSG starting with a BOM, if it contains UTF-8 that is not shortest form it MUST NOT be interpreted as being encoded in UTF-8 for the reasons outlined in [UNICODE-TR36], section 3.1. Guidance about this is given in Appendix A.8. new: If a syslog application is processing a MSG starting with a BOM, if it contains UTF-8 that is not shortest form it MUST be discarded for the reasons outlined in [UNICODE-TR36], section 3.1. Guidance about this is given in Appendix A.8. _______________________________________________ IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
