Skip to main content

Definitions of Managed Objects for Mapping SYSLOG Messages to Simple Network Management Protocol (SNMP) Notifications
RFC 5676

Revision differences

Document history

Date Rev. By Action
2020-01-21
06 (System) Received changes through RFC Editor sync (added Verified Errata tag)
2017-05-16
06 (System) Changed document authors from "Jürgen Schönwälder, Anirban Karmakar" to "Jürgen Schönwälder, Anirban Karmakar, Alex Clemm"
2015-10-14
06 (System) Notify list changed from opsawg-chairs@ietf.org, draft-ietf-opsawg-syslog-msg-mib@ietf.org to (None)
2012-08-22
06 (System) post-migration administrative database adjustment to the No Objection position for Pasi Eronen
2012-08-22
06 (System) post-migration administrative database adjustment to the No Objection position for Jari Arkko
2012-08-22
06 (System) post-migration administrative database adjustment to the No Objection position for Tim Polk
2009-10-20
06 Amy Vezza State Changes to RFC Published from RFC Ed Queue by Amy Vezza
2009-10-20
06 Amy Vezza [Note]: 'RFC 5676' added by Amy Vezza
2009-10-19
06 (System) RFC published
2009-09-02
06 Amy Vezza State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2009-09-01
06 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2009-09-01
06 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2009-09-01
06 (System) IANA Action state changed to In Progress from Waiting on Authors
2009-08-31
06 (System) IANA Action state changed to Waiting on Authors from In Progress
2009-08-31
06 (System) IANA Action state changed to In Progress
2009-08-31
06 Amy Vezza IESG state changed to Approved-announcement sent
2009-08-31
06 Amy Vezza IESG has approved the document
2009-08-31
06 Amy Vezza Closed "Approve" ballot
2009-08-31
06 Dan Romascanu State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Dan Romascanu
2009-08-31
06 Dan Romascanu State Changes to IESG Evaluation::AD Followup from IESG Evaluation::Revised ID Needed by Dan Romascanu
2009-08-29
06 Adrian Farrel
[Ballot comment]
I've cleared my Discuss that used to read:

> Nice work. Just a quick issue to discuss.
>
> When syslogMsgIndex wraps, the …
[Ballot comment]
I've cleared my Discuss that used to read:

> Nice work. Just a quick issue to discuss.
>
> When syslogMsgIndex wraps, the implementation knows where
> to write the next entry. But how does the reader know where
> to start in order to read the messages in the order they
> arrived since the lowest value of syslogMsgIndex does not
> give this information.

The authors and WG have made a strong argument that complexity should be pushed to the management station and away from the agent. That means that it is not considered a burden for the management station to have to read and store the entire table in order to work out how to process the table. I would still prefer the table to include pointers to the oldest and newest entries to speed up accessing specific records, but the WG feel that this is not necessary for their implementations.

=== Original comments below ===

syslogMsgTableMaxSize

Usefully says...

        If an application reduces the limit while there are syslog
        messages in the syslogMsgTable, the syslog messages that are
        in the syslogMsgTable for the longest time MUST be discarded
        to bring the table down to the new limit.

However, it is not clear how we know which entries have been in the
table for the longest time. I presume that the implementation is
either required to maintain this information, or deduce it from the
index wrapping.

---

syslogMsgIndex

It may be helpful to clarify whether...

  "A monotonically increasing number used to identify entries in
  the syslogMsgTable. When syslogMsgIndex reaches the maximum
  value the value wraps back to 1."

...means 4294967295 or the value of syslogMsgTableMaxSize.

---

Do you want to suggest that when objects in a table entry are read one
at a time, syslogMsgMsgID should be read first and last to check that
no change has been made to the row while the read was in progress?
2009-08-29
06 Adrian Farrel [Ballot discuss]
2009-08-29
06 Adrian Farrel [Ballot Position Update] Position for Adrian Farrel has been changed to No Objection from Discuss by Adrian Farrel
2009-08-18
06 Tim Polk [Ballot Position Update] Position for Tim Polk has been changed to No Objection from Undefined by Tim Polk
2009-08-18
06 Tim Polk [Ballot Position Update] Position for Tim Polk has been changed to Undefined from Discuss by Tim Polk
2009-08-18
06 Jari Arkko [Ballot Position Update] Position for Jari Arkko has been changed to No Objection from Discuss by Jari Arkko
2009-08-14
06 Pasi Eronen [Ballot Position Update] Position for Pasi Eronen has been changed to No Objection from Undefined by Pasi Eronen
2009-08-14
06 Pasi Eronen [Ballot Position Update] Position for Pasi Eronen has been changed to Undefined from Discuss by Pasi Eronen
2009-08-14
06 (System) Removed from agenda for telechat - 2009-08-13
2009-08-13
06 Cindy Morgan State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Cindy Morgan
2009-08-13
06 (System) New version available: draft-ietf-opsawg-syslog-msg-mib-06.txt
2009-08-13
06 Ross Callon [Ballot Position Update] New position, No Objection, has been recorded by Ross Callon
2009-08-13
06 Lisa Dusseault [Ballot Position Update] New position, No Objection, has been recorded by Lisa Dusseault
2009-08-13
06 Jari Arkko
[Ballot discuss]
This document is in good shape and I was prepared to ballot Yes.
However, there was one small unclear thing, which I think …
[Ballot discuss]
This document is in good shape and I was prepared to ballot Yes.
However, there was one small unclear thing, which I think should
be changed to benefit readers:

syslogMsgHostName OBJECT-TYPE
    SYNTAX      DisplayString (SIZE (0..255))
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
        "The host name of the syslog message. A zero-length string
        indicates an unknown host name. The SYSLOG protocol
        specification constrains this string to printable US-ASCII
        code points."
    REFERENCE
        "RFC5424: The Syslog Protocol (section 6.2.4)"
    ::= { syslogMsgEntry 6 }

When I read RFC 5424, it says that the HOSTNAME field is actually
a host name *and a domain name*, i.e., a FQDN. Given historical
reasons, the domain name part cannot be guaranteed to be there always.
However, I think it is incorrect to say just "the host name". It would
be more correct to say:

1) The hostname and the (optional) domain name of the originator as
specified in Section 6.2.4 of RFC 5424.

2) the HOSTNAME field of the Syslog message, i.e., the the hostname and
the domain name of the originator as specified in Section 6.2.4 of
RFC 5424.
2009-08-13
06 Jari Arkko [Ballot Position Update] New position, Discuss, has been recorded by Jari Arkko
2009-08-12
06 Robert Sparks [Ballot Position Update] New position, No Objection, has been recorded by Robert Sparks
2009-08-12
06 Tim Polk
[Ballot discuss]
[Authors: this is a fairly small discuss, and should be addressed in just a few sentences. 
Anything elaborate means you are working too …
[Ballot discuss]
[Authors: this is a fairly small discuss, and should be addressed in just a few sentences. 
Anything elaborate means you are working too hard!] 

I am concerned about maintaining a consistent level of security between the syslog and snmp
deployments.  Since the contents of this MIB were transmitted using syslog, and some syslog transport mappings do not provide security, I think some cautionary words should be appended
to the security considerations section.  The point of the new text is that securing the MIB is
necessary but not sufficient.    Implementers should also ensure that the syslog transport
mappings in use are appropriate for the environment.
2009-08-12
06 Tim Polk [Ballot Position Update] New position, Discuss, has been recorded by Tim Polk
2009-08-12
06 Alexey Melnikov [Ballot comment]
I am agreeing with Adrian's DISCUSS.
2009-08-11
06 Adrian Farrel
[Ballot comment]
syslogMsgTableMaxSize

Usefully says...

        If an application reduces the limit while there are syslog
        messages in …
[Ballot comment]
syslogMsgTableMaxSize

Usefully says...

        If an application reduces the limit while there are syslog
        messages in the syslogMsgTable, the syslog messages that are
        in the syslogMsgTable for the longest time MUST be discarded
        to bring the table down to the new limit.

However, it is not clear how we know which entries have been in the
table for the longest time. I presume that the implementation is
either required to maintain this information, or deduce it from the
index wrapping.

---

syslogMsgIndex

It may be helpful to clarify whether...

  "A monotonically increasing number used to identify entries in
  the syslogMsgTable. When syslogMsgIndex reaches the maximum
  value the value wraps back to 1."

...means 4294967295 or the value of syslogMsgTableMaxSize.

---

Do you want to suggest that when objects in a table entry are read one
at a time, syslogMsgMsgID should be read first and last to check that
no change has been made to the row while the read was in progress?
2009-08-11
06 Adrian Farrel
[Ballot discuss]
Nice work. Just a quick issue to discuss.

When syslogMsgIndex wraps, the implementation knows where to write the next entry. But how does …
[Ballot discuss]
Nice work. Just a quick issue to discuss.

When syslogMsgIndex wraps, the implementation knows where to write the next entry. But how does the reader know where to start in order to read the messages in the order they arrived since the lowest value of syslogMsgIndex does not give this information.
2009-08-11
06 Adrian Farrel [Ballot Position Update] New position, Discuss, has been recorded by Adrian Farrel
2009-08-11
06 Ron Bonica [Ballot Position Update] New position, No Objection, has been recorded by Ron Bonica
2009-08-11
06 Lars Eggert [Ballot Position Update] New position, No Objection, has been recorded by Lars Eggert
2009-08-11
06 Pasi Eronen
[Ballot discuss]
I have reviewed draft-ietf-opsawg-syslog-msg-mib-05, and have
couple of small questions that I'd like to discuss before
recommending approval of the document:

It …
[Ballot discuss]
I have reviewed draft-ietf-opsawg-syslog-msg-mib-05, and have
couple of small questions that I'd like to discuss before
recommending approval of the document:

It looks like syslogMsgSDParamValue is limited to 255 octets -- isn't
this way too small?

Should the examples in Section 8 use the enterprise code reserved for
documentation use (32473) instead of zero?
2009-08-11
06 Pasi Eronen [Ballot Position Update] New position, Discuss, has been recorded by Pasi Eronen
2009-08-10
06 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded by Russ Housley
2009-08-09
06 Alexey Melnikov
[Ballot comment]
syslogMsgMsg OBJECT-TYPE
    SYNTAX      OCTET STRING
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
  …
[Ballot comment]
syslogMsgMsg OBJECT-TYPE
    SYNTAX      OCTET STRING
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
        "The message part of the syslog message. The syntax does not
        impose a size restriction. Implementations of this MIB module
        may truncate the message part of the syslog message such that
        it fits into the size constraints imposed by the implementation
        environment. Such truncations can also happen elsewhere in the
        syslog forwarding chain.

        If the first octets contain the value 'EFBBBF'h, then the rest
        of the message is a UTF-8 string. Since syslog messages may be
        truncated at arbitrary octet boundaries during forwarding, the
        message may contain invalid UTF-8 encodings at the end."

I suspect that existing SNMP implementations can't do that, so this is only a comment: is there a way of requiring (via SHOULD?) implementations to truncate on Unicode character boundary?
2009-08-09
06 Alexey Melnikov [Ballot Position Update] New position, No Objection, has been recorded by Alexey Melnikov
2009-08-06
06 Dan Romascanu State Changes to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup by Dan Romascanu
2009-08-06
06 Dan Romascanu Placed on agenda for telechat - 2009-08-13 by Dan Romascanu
2009-08-06
06 Dan Romascanu [Ballot Position Update] New position, Yes, has been recorded for Dan Romascanu
2009-08-06
06 Dan Romascanu Ballot has been issued by Dan Romascanu
2009-08-06
06 Dan Romascanu Created "Approve" ballot
2009-08-06
06 (System) Sub state has been changed to AD Follow up from New Id Needed
2009-08-06
05 (System) New version available: draft-ietf-opsawg-syslog-msg-mib-05.txt
2009-08-03
06 Dan Romascanu State Changes to Waiting for AD Go-Ahead::Revised ID Needed from Waiting for AD Go-Ahead by Dan Romascanu
2009-07-22
06 Samuel Weiler Request for Last Call review by SECDIR Completed. Reviewer: Magnus Nystrom.
2009-07-13
06 (System) State has been changed to Waiting for AD Go-Ahead from In Last Call by system
2009-07-08
06 Amanda Baber
IANA comments:

Upon approval of this document, IANA will make the following
assignments at
http://www.iana.org/assignments/smi-numbers
sub-registry: Prefix: iso.org.dod.internet.mgmt.mib-2 (1.3.6.1.2.1)

Decimal Name Description References
------- ---- …
IANA comments:

Upon approval of this document, IANA will make the following
assignments at
http://www.iana.org/assignments/smi-numbers
sub-registry: Prefix: iso.org.dod.internet.mgmt.mib-2 (1.3.6.1.2.1)

Decimal Name Description References
------- ---- ----------- ----------
TBD syslogMsgMib SYSLOG-MSG-MIB [RFC-opsawg-syslog-msg-mib-04]
2009-07-03
06 Samuel Weiler Request for Last Call review by SECDIR is assigned to Magnus Nystrom
2009-07-03
06 Samuel Weiler Request for Last Call review by SECDIR is assigned to Magnus Nystrom
2009-06-29
06 Amy Vezza Last call sent
2009-06-29
06 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2009-06-29
06 Dan Romascanu State Changes to Last Call Requested from AD Evaluation by Dan Romascanu
2009-06-29
06 Dan Romascanu Last Call was requested by Dan Romascanu
2009-06-29
06 (System) Ballot writeup text was added
2009-06-29
06 (System) Last call text was added
2009-06-29
06 (System) Ballot approval text was added
2009-06-16
06 Dan Romascanu State Changes to AD Evaluation from Publication Requested by Dan Romascanu
2009-06-15
06 Cindy Morgan
This is a request to publish Mapping Simple Network Management Protocol (SNMP)
Notifications to SYSLOG Messages (draft-ietf-opsawg-syslog-snmp-03.txt) and
Definitions of Managed Objects for …
This is a request to publish Mapping Simple Network Management Protocol (SNMP)
Notifications to SYSLOG Messages (draft-ietf-opsawg-syslog-snmp-03.txt) and
Definitions of Managed Objects for Mapping SYSLOG Messages to Simple Network
Management Protocol (SNMP) Notifications (draft-ietf-opsawg-syslog-msg-mib-04.txt)
as Proposed Standards.

These documents are products of the opsawg.


(1.a) Who is the Document Shepherd for this document?

Scott Bradner

Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?
yes

(1.b) Has the document had adequate review both from key WG members
and from key non-WG members?

yes

Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

no

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization or XML?

no

(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of?

no

For example, perhaps he
or she is uncomfortable with certain parts of the document, or
has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated
that it still wishes to advance the document, detail those
concerns here.

n/a

Has an IPR disclosure related to this document
been filed?

no

If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.

n/a

(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

There is wg consensus to publish these documents

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent?

no

If so, please summarise the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)

n/a

(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See
http://www.ietf.org/ID-Checklist.html and
http://tools.ietf.org/tools/idnits/).

yes

Boilerplate checks are
not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type and URI type reviews?

At least some MIB experts have reviewed the mib.

(1.h) Has the document split its references into normative and
informative?

yes

Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear
state?

no
If such normative references exist, what is the
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

n/a


(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body
of the document?

yes

If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggest a
reasonable name for the new registry? See [RFC5226]. If the
document describes an Expert Review process has Shepherd
conferred with the Responsible Area Director so that the IESG
can appoint the needed Expert during the IESG Evaluation?

n/a

(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

I verified that the author has run the MIB checker.

(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Write-Up? Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary
These documents describe mapping SNMP event notifications into syslog messages and
defines a portion of the Management Information Base (MIB) for these mappings.

Working Group Summary
There was consensus in the working group to publish these documents.

Document Quality
The documents were reviewed by the opsawg and by Scott Bradner.
2009-06-15
06 Cindy Morgan Draft Added by Cindy Morgan in state Publication Requested
2009-06-15
06 Cindy Morgan [Note]: 'Scott Bradner (sob@harvard.edu) is the document shepherd.' added by Cindy Morgan
2009-05-29
04 (System) New version available: draft-ietf-opsawg-syslog-msg-mib-04.txt
2009-05-15
03 (System) New version available: draft-ietf-opsawg-syslog-msg-mib-03.txt
2009-03-09
02 (System) New version available: draft-ietf-opsawg-syslog-msg-mib-02.txt
2009-02-16
01 (System) New version available: draft-ietf-opsawg-syslog-msg-mib-01.txt
2009-02-10
00 (System) New version available: draft-ietf-opsawg-syslog-msg-mib-00.txt