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" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: "Adrian Farrel" <[EMAIL PROTECTED]>; <[email protected]>; "Lou Berger"
<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
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: <[EMAIL PROTECTED]>
To: <[email protected]>; <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
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
[EMAIL PROTECTED] Mobile: +1 (978) 394-7754
----------------------------------------------------
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
