On Mon, 2009-06-01 at 13:02 -0700, Chris Lonvick wrote: > Hi Folks, > > David and I are going to open the discussion about rechartering. Below > are some ideas that we've seen on the list that may fit into a charter for > a new syslog Working Group. These seem to fit better in the Operations > and Management Area than in the Security Area so we are asking the ADs to > move the WG to there when we do recharter. > > We'd like to get the discussion started now on this mailing list and have > a WG meeting in Stockholm to discuss rechartering issues. We hope that by > having a real meeting, we can draw in more OPS people who are willing to > work on these items, and/or to craft additional goals for syslog. > > Please send your comments in about this and help move syslog forward. > > > > Fundamentals > - Documenting how a syslog relay is supposed to work. RFC3164 says that a > relay MAY change the header information in a syslog message. This needs > to be reexamined since syslog-sign mandates that no changes are allowed > in the whole syslog message between the sender and the device that > validates the detached signatures.
there are other relay specific discrepancies, like how Structured Data is supposed to work in relaying scenarios. For example sequenceId is hop-by-hop or end-to-end. And what if the relay drops some messages because of filtering? > - A DHC option for a syslog receiver. Write an ID that standardizes how > DHCP should specify a syslog server and associated transport (udp, tls, > beep) in a URI format. > - The OpSec WG was planning to develop a draft about log event taxonomy > (what to log). This work should be compared to the syslog-alarm draft > from Sharon and Rainer, which defines categories for the alarm that are > fairly consistent with the ALARM-MIB and ITU alarm categories. There is > also CEE work that is also trying to define catagories of what to log. > > > Architecture > - An informational document that describes how each of the header fields > should be used. The technical information is in RFC 5424 but could use > some further explanation. > - Possibly combined with the previous topic, a "practical usage guide" > would be a good document for implementors and coders. > - A relook at the PRI values. There are currently 7 Severity levels and > 21 Facilities. The Facilities are ill-defined and out of date. The > information there could be better described in SDEs. We kept the > historical PRI values so that we would have a smooth(er) transition from > historical syslog to the IETF standard syslog. That has worked as > current syslog receivers do receive syslog messages in the new format. The key here is probably a process to define new facility codes by IANA If there's a process, it does not really matter if it uses numeric codes (e.g. the current PRI field), or textual (perhaps in an SDE). > > > Transport > - Documenting a TCP transport for syslog. There are many implementations > in the wild right now with two major variants. The problem between them > is the delimiter; prevalently a CR (I believe) is used to separate > multiple messages within a single TCP packet. The minor-use > implementation does not have a delimiter and just assumes one message > per packet. This will be relatively easy to straighten out. > - Finish syslog-transport-dtls. There are two individual submissions > which may be combined and moved into the WG. > - We should do something with syslog/BEEP. Should we declare the current > syslog/BEEP historic? and/or should we start an effort to publish an > update? Application layer acks is present in the BEEP transport, but the message formatting is ancient (basically the same as RFC3164, e.g. without year, timezone, etc). I guess a BEEP transport with an updated message format would be interesting. Also, on-the-line compression support is requested by a lot of people. > > > Ancillary > - There are other documents in the OPSAWG which might be better reviewed > in the new syslog WG, if they have not already completed reviews > elsewhere: > - Alarms in SYSLOG > - Mapping Simple Network Management Protocol (SNMP) Notifications to > SYSLOG Messages > - Definitions of Managed Objects for Mapping SYSLOG Messages to Simple > Network Management Protocol (SNMP) Notifications > - It would be good to encourage other groups to bring drafts of Structured > Data implementations to Syslog WG for review. These would likely not be > Syslog WG documents but the documents would benefit from being reviewed > by the Syslog WG. > - draft-fan-syslog-sending-policy-01 (Syslog Discard Messages) create > SDEs to report that a series of messages have been dropped by a > sender. This document defines special syslog messages called > Discard messages for carrying logs loss statistics which indicate > how many logs (in terms of facility level or/and severity level) > were discarded by the syslog sender before they had a chance to hit > the wire connected to the syslog receiver during a particular period > in an extreme case. The statistics information Disard messages > convey is of interest to syslog receivers and helpful for later on > audit. > - draft-dulaunoy-syslog-geolocation-00 proposes adding geographic meta > information to syslog messages. This might be done using SDEs > - In an earlier version of netconf, there was work to correlate between > the information models of alarms from different NM interfaces. Part of > the purpose was to ease correlation of event reports for the same event > via different NM interfaces. > - Benoit Claise proposed making ipfix a general purpose reporting > protocol. Such a protocol might replace or supplement syslog. There > may be benefit to utilizing ipfix for carrying syslog information, so > there might be benefit to defining a way to convert syslog content into > ipfix formats, or to modify ipfix PDUs to carry syslog formats (both the > human-readable message part and the SDEs). This was a brand new > proposal at IETF 74, so has not had much discussion yet. We can discuss > this to see if there would be interest in such a direction. -- Bazsi _______________________________________________ Syslog mailing list [email protected] https://www.ietf.org/mailman/listinfo/syslog
