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

[[e-mail]]

Lou,

This is close - there's still a problem with "severity":

> >>- 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.

I looked at RFC 3877 and couldn't find anything I would characterize
as explanations and examples of when to use which severity value.
While GMPLS-specific examples would provide the most insight, RFC 3877
points at M.3100 as the source of these severity concepts, so changing
the RFC 3877 citation in the above text to M.3100 will suffice.

Additional comments interspersed below - everything else is basically
ok.

Thanks,
--David

> 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.

Are you sure about the removal?  The 3.1.4 explanation of why this
form was used will be useful to others working on RSVP after this
RFC is published.
 
> >>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.

See above.  Fastest fix is probably to cite M.3100.

> >>- 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.

That'll take care of explaining why the strong recommendations
are being made.

> >>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.

Something operational - the value of consolidating alarm instances
to a harried operator trying to sort out a network crisis, perhaps.
 
> >>- 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