Subject: Re: [Pce] AD review: draft-ietf-pce-wson-rwa-ext

From: Leeyoung <[email-masked]>
Date: Mon, 3 Dec 2018 20:02:48 +0000

Hi Deborah,

Thanks for your good comments and suggestion. We agreed with and accepted all your comments. Please see inline to see our specific response to your comments. Please see also the suggested update in the attached diff file that compares v9 and v10.

Best regards,
Young

From: BRUNGARD, DEBORAH A [mailto:[email-masked]]
Sent: Friday, November 30, 2018 4:16 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: AD review: draft-ietf-pce-wson-rwa-ext

Dear Authors,

I've done my AD review of your document, I've noted a couple of items which need to be clarified before starting IETF Last Call. As draft-ietf-pce-gmpls-pcep-extensions just finished Last Call and is being revised for comments, please follow closely its progress so as to stay aligned.

Thanks!
Deborah

--comments-

1.       Abstract and other sections of document: term: Lightpath
I didn't see lightpath <provisioning> defined? I did a quick check of other WSON documents, don't see it. Should use term previously used to be consistent as confusing to the reader. If no previous term identified, suggest: lightpath/s/path, as discussing optical path provisioning where optical=wavelength, so not actually provisioning a "wdm" path. Also last sentence: optical light path computation/s/optical path computation. So check your overuse of "light".

YL>> Agree. Deleted all "light" from all usage of lightpath.

2.       I don't see reference to RFC5440 in the Abstract or Introduction. Need to add it when mentioning PCEP. Shouldn't RFC5440 be normative (listed as informative)?

YL>> Agree. I added RFC5440 in the introduction and put this as a normative reference.

3.       Section 2 - need to reference also RFC8174.
YL>> Agree. I added this.

4.       4.1(a) suggest:
in the sense that the allocated labels MAY appear after an interface route subobject./s/ The allocated labels MAY appear after an interface route subobject.

YL>> Corrected.

5.       Section 4.1: As the RTG Dir reviewer commented, ELC needs to be referenced. Noted it was added to 4.1 (b), but not on first mention in (a). I checked RFC3471, ELC is not used as a term. I don't recall it being used elsewhere? It's best not to introduce new terms. Just say "Explicit Label Control [RFC3471]".

YL>> OK. Per your suggestion, in 4.1 (a), just said "Explicit Label Control [RFC3471]". Removed this reference from 4.1(b).

6.       Section 4.1: Need references to pcep-gmpls (e.g. end-points) for consistency (for the reader). Also other sections, e.g. 4.3.1 Link identifier needs reference (not new to this draft, we know where it is defined, but need reference for the reader that doesn't know). Need to be consistent on naming - have IPv4 is an "Entry", IPv6 is a "Sub-TLV".

YL>> Added [PCEP-GMPLS] as reference to "ENDPOINT".  Added references RFC3630, RFC5329 and RFC 4203 respectively for IPv4, IPv6 and unnumbered link;
s/Entry/Sub-TLV

7.       Section 6.2 on Information and Data Models - need to add YANG. Suggest to delete "A future revision of this document..." as this has not been added (or add it).

YL>> Agree.

OLD:
6.2. Information and Data Models, e.g., MIB module, YANG
Extensions to the PCEP MIB module defined in [RFC7420] should be defined, so as to
cover the WSON RWA information introduced in this document. A future revision of this document will list the information that should be added to the MIB module.

NEW:
6.2. Information and Data Models
Extensions to a MIB or a YANG model should be defined, so as to
cover the WSON RWA information introduced in this document.

8.       Section 7 Security Considerations:
Suggest:
This document has no requirement for a change to the security models
   within PCEP . However the additional information distributed in
   order to address the RWA problem represents a disclosure of network
   capabilities that an operator may wish to keep private.
   Consideration should be given to securing this information.
/s/
The security considerations discussed in [RFC5440] are relevant for this document, this document does not introduce any new security issues. If an operator wishes to keep private the information distributed by WSON, PCEPS [RFC8253] SHOULD be used.

(Add RFC8253 as normative reference)

YL>> Agree and edited per your suggestion.

9.       Normative references should be listed before informative. I'm not sure if you switched the titles and meant the reverse as some of these documents could be listed in the other list. Need to check carefully, also there are no rewards for having long lists of references, I think some of these are not necessary. They will only worry the other ADs/reviewers as they will think they need to review all these documents when reviewing this document. Remember "normative references are essential to implementing or understanding the content of the RFC and informative references provide additional information". But that doesn't mean every RFC/draft that mentions PCE/GMPLS/WSON needs to be included.

YL>> Agree. I switched the order, normative first followed by informative. I also reduced the number of references and in some cases deleted some text. In addition, moved a number of normative references to the informative reference section. Please see the reference sections.