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

[Lou Berger <[e-mail]>]

I'll add the reverence to M.3100.

Lou


At 06:42 PM 8/12/2006, [e-mail] wrote:

>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