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

[Leeyoung <[e-mail]>]

Hi Deborah,

Thanks a lot for your good comments. We will address your comments as soon as we can and get back to you in a timely manner to keep pace with the progress of draft-ietf-pce-gmpls-pcep-extensions.

Best regards,
Young

From: BRUNGARD, DEBORAH A [mailto:[e-mail]]
Sent: Friday, November 30, 2018 4:16 PM
To: [e-mail]
Cc: [e-mail]; [e-mail]
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".

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)?

3.       Section 2 - need to reference also RFC8174.

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.

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


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

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

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)

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.