Mapping Simple Network Management Protocol (SNMP) Notifications to SYSLOG Messages
draft-ietf-opsawg-syslog-snmp-05

[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.

[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.)

[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]/

[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.

[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).

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.

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.