Skip to main content

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

Yes

(Dan Romascanu)

No Objection

(Cullen Jennings)
(Lars Eggert)
(Lisa Dusseault)
(Robert Sparks)
(Ron Bonica)
(Ross Callon)
(Tim Polk)

Note: This ballot was opened for revision 02 and is now closed.

Dan Romascanu Former IESG member
Yes
Yes () Unknown

                            
Adrian Farrel Former IESG member
No Objection
No Objection (2009-08-25) Unknown
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
Alexey Melnikov Former IESG member
No Objection
No Objection (2009-08-21) Unknown
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.
Cullen Jennings Former IESG member
No Objection
No Objection () Unknown

                            
Jari Arkko Former IESG member
No Objection
No Objection (2009-08-26) Unknown
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?
Lars Eggert Former IESG member
(was Discuss) No Objection
No Objection () Unknown

                            
Lisa Dusseault Former IESG member
No Objection
No Objection () Unknown

                            
Pasi Eronen Former IESG member
(was Discuss) No Objection
No Objection (2009-08-26) Unknown
Couple of typos in Section 4:

'APP-NAME is "su"' -> 'APP-NAME is "evntslog"'
'exampleSDID@0' -> 'exampleSDID@32473'
'resourceURI =' -> 'resourceURI='
Ralph Droms Former IESG member
No Objection
No Objection (2009-08-26) Unknown
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"?
Robert Sparks Former IESG member
No Objection
No Objection () Unknown

                            
Ron Bonica Former IESG member
No Objection
No Objection () Unknown

                            
Ross Callon Former IESG member
No Objection
No Objection () Unknown

                            
Russ Housley Former IESG member
No Objection
No Objection (2009-08-25) Unknown
  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.
Tim Polk Former IESG member
No Objection
No Objection () Unknown