Re: [Syslog] syslog WG Rechartering Discussion

[Balazs Scheidler <[e-mail]>]

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