Skip to main content

Mapping Simple Network Management Protocol (SNMP) Notifications to SYSLOG Messages
RFC 5675

Revision differences

Document history

Date Rev. By Action
2015-10-14
05 (System) Notify list changed from opsawg-chairs@ietf.org, draft-ietf-opsawg-syslog-snmp@ietf.org, vl.marinov@googlemail.com, j.schoenwaelder@jacobs-university.de to vl.marinov@googlemail.com
2012-08-22
05 (System) post-migration administrative database adjustment to the No Objection position for Lars Eggert
2009-10-20
05 Amy Vezza State Changes to RFC Published from RFC Ed Queue by Amy Vezza
2009-10-20
05 Amy Vezza [Note]: 'RFC 5675' added by Amy Vezza
2009-10-19
05 (System) RFC published
2009-09-02
05 Amy Vezza State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2009-09-01
05 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2009-09-01
05 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2009-09-01
05 (System) IANA Action state changed to In Progress from Waiting on Authors
2009-08-31
05 (System) IANA Action state changed to Waiting on Authors from In Progress
2009-08-31
05 (System) IANA Action state changed to In Progress
2009-08-31
05 Amy Vezza IESG state changed to Approved-announcement sent
2009-08-31
05 Amy Vezza IESG has approved the document
2009-08-31
05 Amy Vezza Closed "Approve" ballot
2009-08-31
05 Dan Romascanu State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Dan Romascanu
2009-08-31
05 Dan Romascanu State Changes to IESG Evaluation::AD Followup from IESG Evaluation::Revised ID Needed by Dan Romascanu
2009-08-14
05 Alexey Melnikov [Ballot Position Update] Position for Alexey Melnikov has been changed to No Objection from Discuss by Alexey Melnikov
2009-08-14
05 Alexey Melnikov
[Ballot comment]
In Section 7:

  The SNMP architecture supports an access control mechanism ensuring
  that SNMP notifications are only sent to receivers who …
[Ballot comment]
In Section 7:

  The SNMP architecture supports an access control mechanism ensuring
  that SNMP notifications are only sent to receivers who are authorized
  to receive the notification.  Network operators using this mapping of
  SNMP notifications to SYSLOG messages should enforce a consistent

s/should/SHOULD ?

  policy preventing people from accessing SNMP notifications via the
  SYSLOG mapping that would otherwise not be accessible.
2009-08-14
05 Alexey Melnikov [Ballot discuss]
2009-08-14
05 (System) Removed from agenda for telechat - 2009-08-13
2009-08-13
05 Cindy Morgan State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Cindy Morgan
2009-08-13
05 (System) New version available: draft-ietf-opsawg-syslog-snmp-05.txt
2009-08-13
05 Ross Callon [Ballot Position Update] New position, No Objection, has been recorded by Ross Callon
2009-08-13
05 Lisa Dusseault [Ballot Position Update] New position, No Objection, has been recorded by Lisa Dusseault
2009-08-12
05 Robert Sparks [Ballot Position Update] New position, No Objection, has been recorded by Robert Sparks
2009-08-12
05 Tim Polk [Ballot Position Update] New position, No Objection, has been recorded by Tim Polk
2009-08-12
05 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded by Jari Arkko
2009-08-11
05 Ron Bonica [Ballot Position Update] New position, No Objection, has been recorded by Ron Bonica
2009-08-11
05 Adrian Farrel [Ballot Position Update] New position, No Objection, has been recorded by Adrian Farrel
2009-08-11
05 Lars Eggert [Ballot Position Update] Position for Lars Eggert has been changed to No Objection from Discuss by Lars Eggert
2009-08-11
05 Lars Eggert
[Ballot comment]
Section 3.1., paragraph 1:
>    which correponds to "Notice: normal but significant condition".  If

  Nit: s/correponds/corresponds/


Section 3.2., paragraph 7:
>  …
[Ballot comment]
Section 3.1., paragraph 1:
>    which correponds to "Notice: normal but significant condition".  If

  Nit: s/correponds/corresponds/


Section 3.2., paragraph 7:
>    NULL            = ""

  zero-length char-val (You can just remove NULL everywhere, I think.)
2009-08-11
05 Lars Eggert
[Ballot discuss]
DISCUSS: This mapping appears to be IPv4-specific, which is in conflict
  with the IETF's goal of having all new work apply to …
[Ballot discuss]
DISCUSS: This mapping appears to be IPv4-specific, which is in conflict
  with the IETF's goal of having all new work apply to IPv4 and IPv6.

Section 3.2., paragraph 5:
>    OIDSTART        = (("0." / "1.")[%d49-51] DIGIT) / ("2." OIDSUBID)

  DISCUSS: ABNF error: Concatenation of adjacent elements is not allowed
  (missing whitespace?) Maybe: s/(("0." / "1.")[%d49-51]/(("0." / "1.")
  [%d49-51]/
2009-08-11
05 Lars Eggert [Ballot Position Update] New position, Discuss, has been recorded by Lars Eggert
2009-08-11
05 Pasi Eronen [Ballot Position Update] New position, No Objection, has been recorded by Pasi Eronen
2009-08-10
05 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded by Russ Housley
2009-08-09
05 Dan Romascanu State Change Notice email list have been change to opsawg-chairs@tools.ietf.org, draft-ietf-opsawg-syslog-snmp@tools.ietf.org, vl.marinov@googlemail.com, j.schoenwaelder@jacobs-university.de from opsawg-chairs@tools.ietf.org, draft-ietf-opsawg-syslog-snmp@tools.ietf.org
2009-08-09
05 Alexey Melnikov
[Ballot comment]
In Section 3.2:

Bill Fenner's ABNF validator complains about the following ABNF production:

  OIDSTART        = (("0." / "1.")[%d49-51] DIGIT) …
[Ballot comment]
In Section 3.2:

Bill Fenner's ABNF validator complains about the following ABNF production:

  OIDSTART        = (("0." / "1.")[%d49-51] DIGIT) / ("2." OIDSUBID)

It should be:
  OIDSTART        = (("0." / "1.") [%d49-51] DIGIT) / ("2." OIDSUBID)

[i.e. an extra space after '1.")']


In Section 3.3:

  The MSG part of the SYSLOG message is optional and may contain a
  free-form message that provides a textual description of the SNMP
  event notification.  The character set used in MSG SHOULD be UNICODE,
  encoded using UTF-8 as specified in [RFC3629].  If the originator can
  not encode the MSG in Unicode, it MAY use any other encoding.

At first I thought it was strange to make UTF-8 only a SHOULD, but this is cut & paste from the SYSLOG spec itself. It might be better clarifying that, e.g. "According to [SYSLOG] the character set ..."

I also think this would benefit from an informative reference to section
7.3.3 in SYSLOG, in case the generator wants to convey the language used in MSG.

In Section 7:

  The SNMP architecture supports an access control mechanism ensuring
  that SNMP notifications are only sent to receivers who are authorized
  to receive the notification.  Network operators using this mapping of
  SNMP notifications to SYSLOG messages should enforce a consistent

s/should/SHOULD ?

  policy preventing people from accessing SNMP notifications via the
  SYSLOG mapping that would otherwise not be accessible.
2009-08-09
05 Alexey Melnikov
[Ballot discuss]
I have 2 minor points and would be happy if they are addressed as RFC Editor notes:

1). VALUTF8STRING ABNF production in Section …
[Ballot discuss]
I have 2 minor points and would be happy if they are addressed as RFC Editor notes:

1). VALUTF8STRING ABNF production in Section 3.2

2). I think the reference to [RFC3629] must be normative, but this might change depending on how you resolve 1).
2009-08-09
05 Alexey Melnikov [Ballot Position Update] New position, Discuss, has been recorded by Alexey Melnikov
2009-08-06
05 Dan Romascanu [Ballot Position Update] New position, Yes, has been recorded for Dan Romascanu
2009-08-06
05 Dan Romascanu Ballot has been issued by Dan Romascanu
2009-08-06
05 Dan Romascanu Created "Approve" ballot
2009-08-06
05 Dan Romascanu State Changes to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup by Dan Romascanu
2009-08-06
05 Dan Romascanu Placed on agenda for telechat - 2009-08-13 by Dan Romascanu
2009-08-06
05 (System) Sub state has been changed to AD Follow up from New Id Needed
2009-08-06
04 (System) New version available: draft-ietf-opsawg-syslog-snmp-04.txt
2009-08-03
05 Dan Romascanu State Changes to Waiting for AD Go-Ahead::Revised ID Needed from Waiting for AD Go-Ahead by Dan Romascanu
2009-07-13
05 (System) State has been changed to Waiting for AD Go-Ahead from In Last Call by system
2009-07-08
05 Amanda Baber
IANA comments:

Upon approval of this document, IANA will make the following
assignments at
http://www.iana.org/assignments/syslog-parameters
Registry: syslog Structured Data ID Values

Structured Data ID Structured …
IANA comments:

Upon approval of this document, IANA will make the following
assignments at
http://www.iana.org/assignments/syslog-parameters
Registry: syslog Structured Data ID Values

Structured Data ID Structured Data Parameter Required or Optional Note
------------------ ------------------------- -------------------- ----
snmp OPTIONAL
ctxEngine OPTIONAL
ctxName OPTIONAL
v OPTIONAL [1]
l OPTIONAL [1]
o OPTIONAL [1]
x OPTIONAL [1]
c OPTIONAL [1]
C OPTIONAL [1]
u OPTIONAL [1]
d OPTIONAL [1]
i OPTIONAL [1]
n OPTIONAL [1]
p OPTIONAL [1]
t OPTIONAL [1]
a OPTIONAL [1]

The "Note" column will be added to the registry.
2009-07-03
05 Samuel Weiler Request for Last Call review by SECDIR is assigned to Vidya Narayanan
2009-07-03
05 Samuel Weiler Request for Last Call review by SECDIR is assigned to Vidya Narayanan
2009-06-29
05 Amy Vezza Last call sent
2009-06-29
05 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2009-06-29
05 Dan Romascanu State Changes to Last Call Requested from Publication Requested by Dan Romascanu
2009-06-29
05 Dan Romascanu Last Call was requested by Dan Romascanu
2009-06-29
05 (System) Ballot writeup text was added
2009-06-29
05 (System) Last call text was added
2009-06-29
05 (System) Ballot approval text was added
2009-06-15
05 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
05 Cindy Morgan Draft Added by Cindy Morgan in state Publication Requested
2009-06-15
05 Cindy Morgan [Note]: 'Scott Bradner (sob@harvard.edu) is the document shepherd.' added by Cindy Morgan
2009-05-15
03 (System) New version available: draft-ietf-opsawg-syslog-snmp-03.txt
2009-03-26
02 (System) New version available: draft-ietf-opsawg-syslog-snmp-02.txt
2009-03-09
01 (System) New version available: draft-ietf-opsawg-syslog-snmp-01.txt
2009-02-10
00 (System) New version available: draft-ietf-opsawg-syslog-snmp-00.txt