GMPLS - Communication of Alarm Information
draft-ietf-ccamp-gmpls-alarm-spec-06

The following text in Section 5 is confusing, or at least confused me:

OLD:
   Additionally, Section 3.1.3 defines a new RSVP Error Code.  The Error
   Code is "Alarms" and uses Error Values defined in the Alarm MIB
   [RFC3877].  The suggested Error Code value is 28.

I suggest to clarify it by replacing it with:

NEW:
   Additionally, Section 3.1.3 defines a new RSVP Error Code.  The Error
   Code is "Alarms" and the suggested Error Code value is 28. The 
   interpretation of the Error Value field is context-specific. The 
   context is derived from the value of the Error Code field. When 
   the Error Code field indicates "Alarms", the value of the Error Value 
   field is taken from the IANA ITU Alarm TC MIB defined in the Alarm MIB 
   [RFC3877]

Section 3., paragraph 1:
>    The communication of alarm information is optional.

  Nit: s/optional/OPTIONAL/


Section 3.1.1., paragraph 1:
>    All TLVs defined in this section are optional.

  Nit: s/optional/OPTIONAL/


Section 3.1.1., paragraph 8:
>          The number of times this alarm has been repeated as determined
>          by the reporting node.  This field MUST NOT be set to zero.

  "...when sent, and a received TLV with a reference count of zero MUST
  be ignored." (I assume?) Also, is there a need to describe what
  happens at rollover?


Section 3.1.1., paragraph 22:
>          The number of seconds since 0000 UT on 1 January 1970,
>          according to the clock on the node that originates this TLV.

  Rolls over in 2038 - do we need to care?


Section 3.1.2., paragraph 2:
>    Nodes that support the communication of alarm information, SHOULD
>    record the information contained in a received ALARM_SPEC for later
>    use.

  Can't parse the sentence.


Section 3.1.4., paragraph 1:
>    The support of ALARM_SPEC objects is optional.  Non-supporting nodes
>    will pass the objects through the node unmodified, because the
>    ALARM_SPEC object has a C-Num of the form 11bbbbbb.

  Nit: s/optional/OPTIONAL/ and s/will/MUST/ (or SHOULD?)


Section 5., paragraph 1:
>    This section uses the terminology of BCP 26 "Guidelines for Writing
>    an IANA Considerations Section in RFCs" [BCP26].

  Nit: Missing Reference: 'BCP26' is mentioned on line 635, but not defined


Section 6.2., paragraph 4:

>     [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
>             Requirement Levels," RFC 2119.

  Nit: Should probably be normative.