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
