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