Alarms in Syslog
draft-ietf-opsawg-syslog-alarm-02

[Ballot comment]
The document says:

  Support of the "alarm" SD-ID is optional, but once supported some of
  the SD-PARARMS are mandatory.

but at this point in the document the terms SD-ID and SD-PARARMS have not
been introduced yet. And there isn't even a forward reference. Is it
SD-PARARMS, really, or SD-PARAMS?

[Ballot comment]
Very minor readsbility nits:
Reorder sections 3.1-3.6 to match the order of the list in section 3.
Reorder the bullet list in section 3.3 to match the order of the list in section 2.

"trendIndication" in section 3.5 could use a clearer definition.  How is trendIndication "[s]imilar to the definition of perceived severity"?  Perhaps trendIndication is "related to perceived severity, indicating the trend of the perceived severity relative to previously reported values of perceived severity for the same alarm source"?

[Ballot discuss]
Syslog messages can be transmitted over unreliable protocols (UDP). This means that raising alarms via syslog is inherently different from raising alarms via the Alarm MIB, because SNMP is reliable. I'm not clear how the Alarm MIB is used in the ITU-T and how this syslog method will be used, so I'd like to confirm that unreliable transmission is not an issue.

(Should this be called out in the document somewhere?)

[Ballot discuss]
From Rob Austein's SecDir review: it's not clear what e.g. 'If the
"alarm" SD-ID is supported, the "resource" SD-PARAM MUST be supported'
(and other similar sentences) mean. Does it mean that if the "alarm"
SD-ID is included in a syslog message, the "resource" SD-PARAM MUST be
included? (Or if not, what is meant by "supported" here?)

[Ballot comment]
Please review the comments provided in the Gen-ART Review by
  Suresh Krishnan:

  * Please replace reference to obsolete RFC1738 with a reference to
    RFC4248 or RFC4266 or both depending on what is required.

  * Section 4: Replace the nonexistent reference [Syslog] with
    [RFC5424] if that is what you intended to use.

[Ballot comment]
Nits you should fix to reduce the load on the RFC Editor if you are
editing the document.

Have a look to see whether you are consistent in your use of "syslog,"
"Syslog," and "SYSLOG."

----

idnits says...

== The page length should not exceed 58 lines per page, but there
  was 1 longer page, the longest (page 1) being 63 lines

== Missing Reference: 'Syslog' is mentioned on line 225, but not
  defined

** Obsolete normative reference: RFC 1738 (Obsoleted by RFC 4248,
  RFC 4266)
-----
Abstract is a little hard to parse

  It
  includes the mapping of ITU perceived severities onto syslog message
  fields and a number of alarm-specific SD-PARAM definitions from X.733
  and the IETF Alarm MIB.

What maps onto what?
-----
Section 1

  defines a mapping of syslog severity to the severity of
  the alarm.

Which way is the mapping defined in this document? I think the mapping
is from alarm severity to syslog severity.

Should include references to RFC3877, X.733 and X.736 where they are
mentioned.
-----
Section 2

s/severities which are useful/severities which it is useful/

s/A STRUCTURED-DATA element is defined/A STRUCTURED-DATA element is defined in this document/
-----
Section 3
s/The following are defined/The following are defined in this document/
-----
Section 6
It would be really helpful to IANA and would make certain that you get the results you want if you name the registry from which you wish IANA to make these allocations.
-----
Section 8.2 appears to have some double-double quotes

[Ballot comment]
3.  Alarm STRUCTURED-DATA Elements

  Support of the "alarm" SD-ID is optional,

s/optional/OPTIONAL ?

  but once supported some of
  the SD-PARARMS are mandatory.


3.6.  resourceURI

  If the "alarm" SD-ID is supported, the "resourceURI" SD-PARAM SHOULD
  be supported.  This item uniquely identifies the resource under
  alarm.

  The value of this field MUST conform to the URI definition in
  [RFC1738] and its updates.  In the case of an SNMP resource, the

This RFC was obsoleted 3 times. This should be pointing to RFC 3986 instead.

  syntax in [RFC4088] MUST be used and "resourceURI" must point to the
  same resource as alarmActiveResourceId [RFC3877] for this alarm.

IANA comments:


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

Registry Name: syslog Structured Data ID Values

OLD:

Structured Data ID Structured Data Parameter Required or Optional
------------------ ------------------------- --------------------
...

meta OPTIONAL
sequenceId OPTIONAL
sysUpTime OPTIONAL
language OPTIONAL



NEW:

Structured Data ID Structured Data Parameter Required or Optional
------------------ ------------------------- --------------------
...

meta OPTIONAL
sequenceId OPTIONAL
sysUpTime OPTIONAL
language OPTIONAL

alarm OPTIONAL
resource MANDATORY
probableCause MANDATORY
perceivedSeverity MANDATORY
eventType OPTIONAL
trendIndication OPTIONAL
resourceURI OPTIONAL

IANA comments:


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

Registry Name: syslog Structured Data ID Values

OLD:

Structured Data ID Structured Data Parameter Required or Optional
------------------ ------------------------- --------------------
...

meta OPTIONAL
sequenceId OPTIONAL
sysUpTime OPTIONAL
language OPTIONAL



NEW:

Structured Data ID Structured Data Parameter Required or Optional
------------------ ------------------------- --------------------
...

meta OPTIONAL
sequenceId OPTIONAL
sysUpTime OPTIONAL
language OPTIONAL

alarm OPTIONAL
resource MANDATORY
probableCause MANDATORY
perceivedSeverity MANDATORY
eventType OPTIONAL
trendIndication OPTIONAL
resourceURI OPTIONAL

(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?

the WG discussed this document over quite a period of time and there was
good consensus for it to be published

(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/). Boilerplate checks are
not enough; this check needs to be thorough.

I have not but IDs can not be published w/o passing the ID nits

Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type and URI type reviews?

n/a

(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?

yes

Are the IANA registries clearly identified?

yes

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?

n/a

(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
This document describes how to send alarm information in
syslog. It includes the mapping of ITU perceived severities onto syslog
message fields and a number of alarm-specific SD-PARAM definitions from
X.733 and the IETF Alarm MIB.

Working Group Summary
The document was revised based on WG feedback & the result meets
the issues that were raised.

Document Quality
The document was reviewed by the opsawg and Scott Bradner.