syslog-protocol

[back] [Raw Mail Archive]

Abstract

Syslog-protocol describes the syslog protocol. The syslog protocol has been used throughout the years to convey event notifications. The document describes a layered architecture for an easily extensible syslog protocol. It also describes the basic message format and structured elements used to provide meta-information about the message.

This page tracks discussion topics/issues during the creation of syslog-protocol. Syslog-protocol shall become a standards-track RFC.

IDs/RFCS (includes all drafts, most current first):

Issues after Vancouver Meeting (2005)

Below, there are some references to specific mailing list threads. While the author honestly thinks these are the relevant posts, the selection is obviously subjective. It is suggested that one scans the complete mailing list archive to find posts not specifically mentioned.

The WG charter shall be modified to keep the WG focused and also limit the expectations of what syslog-protocol should do. The latest proposal is:

==== MODIFIED Version of Chris's 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. =====   ======

For charter discussion, see http://www.mail-archive.com/syslog%40lists.ietf.org/msg00242.html.

There are also discussions on the syslog-protocol I-D. This is a rather quick tracker of current discussions. For a glimpse at how this list was constructed, see http://www.mail-archive.com/syslog%40lists.ietf.org/msg00226.html. This status given below has been compiled on 2005-11-30, around 11a UTC. It might have changed after that. Many decisions and suggestions are backed by lab testing, code review of existing open source syslogd  implementation and a proof-of-concept implementation of syslog-protocol in rsyslog. Rsyslog is an open source project, so interested parties can pull the source and check it out. Please be warned that at the time of this writing the syslog-protocol proof must be obtained from CVS (see web site) because it has not yet been officially released as a source tarball.

  1. testing and code review has shown that there is no point in trying to preserve more than <PRI>; RFC 3164 provides a false impression of common behaviour.
  2. The max message length issue resurfaces. There seems to be a fragile consensus that we can life with the compromise in  syslog-protocol and eventualy open a debate if we (ever) go to a TCP transport.
  3. There is a question if NUL octets are to be supported in the MSG content.
  4. There seems to be a fragile consensus that MSG should primarily contain textual data, including XMLified content. On the contrary, pure binary data should not be used.
  5. Character encoding in MSG: due to my proof-of-concept implementation, I have raised the (ugly) question if we need to allow encodings other than UTF-8. Please note that this question arises from needs introduced by e.g. POSIX. So we can't easily argue them away by whishful thinking ;)
  6. field order
    • issues has been merged with 7
  7. Header fields: there seems to be a fragile consensus that MSGID, PROCID, APP-NAME, and VERSION should be in the header and TRUNCATE should not be in it.
  8. MSG-octet counting and/or trailer is resurfacing. I think this item is not well understood and well discussed.
  9. I have found some minor items not already discussed during my proof-of-concept implementation (like "drop requirements" and such). These are not absolutely vital, but should be considered before a final text is issued (or even the next revision).
  10. STRUCTURED-DATA: there has been surprisingly few discussion about STRUCTURED-DATA. I conclude that this is non-controversal.

     

    11.

Previous Issues (2004 discussion)

Presentations

Other Material

Other things to do

This is a reminder section for Rainer ;)

 

This page last updated: Sat Nov 17 17:54:07 2007.
For content issues, contact rgerhards-at-adiscon.com - for legal issues, please contact Adiscon who is the legal owner and publisher of this web site.
Visit our topic pages for practical information on syslog.
Raw Mail Archive: [threaded] [by date] [search]