Hi Chris. We also have the Syslog-MIB work (draft-ietf-syslog-device-mib-17.txt) that is currently on hold. A lot of work and discussion has gone into the document. Do we want to move this onto the next charter or, do it in the current WG ? I think that with another push we can take this through, now that we understand Syslog better.
Glenn > Hi Folks,Chris Lonvick wrote: > > 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. > - 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. > > > 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? > > > 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. > > > Thanks, > Chris & David > _______________________________________________ > Syslog mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list [email protected] https://www.ietf.org/mailman/listinfo/syslog
