[Gen-art] Re: Gen ART review of draft-ietf-ccamp-gmpls-alarm-spec-03.txt

[Lou Berger <[e-mail]>]

David,
         Much thanks for the comments.  Please see below for in-line responses.
Note, the other co-authors on this draft have been included in this response.

Lou

>----- Original Message ----- From: <[e-mail]>
>To: <[e-mail]>; <[e-mail]>
>Cc: <[e-mail]>; <[e-mail]>; 
><[e-mail]>; <[e-mail]>
>Sent: Wednesday, August 09, 2006 4:59 PM
>Subject: Gen ART review of draft-ietf-ccamp-gmpls-alarm-spec-03.txt
>
>
>>Lou,
>>
>>I am the assigned Gen-ART reviewer for
>>draft-ietf-ccamp-gmpls-alarm-spec-03.txt .
>>
>>For background on Gen-ART, please see the FAQ at
>><http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html>.
>>
>>Please resolve these comments along with any other
>>Last Call comments you may receive.
>>
>>This draft is basically ready for publication, but has nits
>>that should be fixed before publication.
>>
>>The draft is generally well-written and to the point.  All
>>of these comments are minor.
>>- Section 3.1.  Say why the two-leading-one-bits form is used
>>for ALARM_SPEC objects in this section in addition to
>>Section 3.1.4.  It would be ok to move the text from Section
>>3.1.4 up into Section 3.1.

I've added a forward reference to 3.1.  Note that this comment will 
be removed once IANA assigns the class number.

>>Also, if there's a good explanation
>>for why C-Type 1 and 2 are Reserved, that explanation should
>>be added.

sure.

>>- Section 3.1.1 should give guidance for and examples of appropriate
>>use of Severity values.

There's a whole body of work on this, and for this reason the 
document provides a reference to an RFC that already discusses this 
topic.  I think the current text ("See [RFC3877] for more information 
on severity.") is the best and right about of guidance in this 
document.  If you have specific alternative text, we'd be happy to 
consider its inclusion.

>>- Section 3.1.2 has a number of SHOULDs and SHOULD NOTs.  There needs
>>to be an explanation of why these strong recommendations are
>>being made (which would imply consequences of not following
>>the recommendations) and/or a description of what goes wrong
>>when they're not followed.

I'm not sure I agree with this point, but will add some text nevertheless.

>>The overall explanation appears
>>to be a desire to supply enough basic information to allow
>>the recipient to understand the alarm (this info can be quite
>>important as the recipient may be dealing with a crisis of
>>which the alarm is a part).

will cover this in the updated text.

>>The "MAY" for the ref
>>count TLV needs to be explained  (why would it be used?).

This is explained earlier in the document, but sure will add something.

>>- Section 3.1.2 on p10 discusses adding alarm objects to the
>>"state of LSPs".  The quoted phrase needs to be defined -
>>I think the addition is to the LSP state communicated by
>>RSVP Path and Resv messages.

so there seems to be a few points here:

point 1:  clarify which stats are referred to by "state of LSPs".

Per your comment, I've changed this to read "Path and Resv states of LSPs".


point 2 and 3: define the quoted phrases: "alarm communication 
inhibited state." and "administratively down" .

These phrase are defined in the last sentence of the paragraph:
     These states are indicated by the I and A bits of the
     Admin_Status object, see Section 3.2.

Thanks again for the feedback!

Lou

PS in case you're interested there's a "preview" copy of the updated 
text attached.

>>Thanks,
>>--David
>>----------------------------------------------------
>>David L. Black, Senior Technologist
>>EMC Corporation, 176 South St., Hopkinton, MA  01748
>>[phone]             FAX: [phone]
>>[e-mail]        Mobile: [phone]
>>----------------------------------------------------
>>
>
>
>
>
>

_______________________________________________
Gen-art mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/gen-art