syslog WG Rechartering Discussion

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.
- 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