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

Hi,

<hat = (chair and co-author)>
Thanks for the changes
</hat>

<hat = co-author>
Can we take this opportunity to update the references?

OLD
[GMPLS-UNI] Swallow, G., Drake, J., Ishimatsu, H., and Rekhter, Y.
            "GMPLS UNI: RSVP Support for the Overlay Model",
            draft-ietf-ccamp-gmpls-overlay-05.txt, October 2004,
            work in progress.

[GMPLS-ENNI] Papadimitriou, D., Editor,  "Generalized MPLS (GMPLS)
             RSVP-TE Signaling in support of Automatically Switched
             Optical Network (ASON)",
             draft-ietf-ccamp-gmpls-rsvp-te-ason-04.txt, July 2005,
             work in progress.

NEW
[GMPLS-OVERLAY] Swallow, G., Drake, J., Ishimatsu, H., and Rekhter, Y.
            "Generalized Multiprotocol Label Switching (GMPLS)
             User-Network Interface (UNI): Resource ReserVation
             Protocol-Traffic Engineering (RSVP-TE) Support for the
             Overlay Model", RFC 4208, October 2005.

</hat>

Thanks,
Adrian

----- Original Message ----- 
From: "Lou Berger" <lberger@labn.net>
To: <Black_David@emc.com>
Cc: "Adrian Farrel" <adrian@olddog.co.uk>; <gen-art@ietf.org>; "Lou Berger" 
<lberger@labn.net>; <rcallon@juniper.net>; <dbrungard@att.com>; 
<Black_David@emc.com>; <ibryskin@movaz.com>; 
<dimitri.papadimitriou@alcatel.be>; <asatyana@cisco.com>
Sent: Friday, August 11, 2006 11:01 PM
Subject: Re: Gen ART review of draft-ietf-ccamp-gmpls-alarm-spec-03.txt

> 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: <Black_David@emc.com>
>>To: <gen-art@ietf.org>; <lberger@movaz.com>
>>Cc: <rcallon@juniper.net>; <adrian@olddog.co.uk>;
>><dbrungard@att.com>; <Black_David@emc.com>
>>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
>>>+1 (508) 293-7953             FAX: +1 (508) 293-7786
>>>black_david@emc.com        Mobile: +1 (978) 394-7754
>>>----------------------------------------------------
>>>
>>
>>
>>
>>
>>
> 

_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www1.ietf.org/mailman/listinfo/gen-art