Re: [Syslog] syslog WG Rechartering Discussion

["Glenn M. Keeni" <glenn at cysols.com>]

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
> Syslog at ietf.org
> https://www.ietf.org/mailman/listinfo/syslog