Last Call Review of draft-ietf-pce-wson-rwa-ext-08

Request Review of draft-ietf-pce-wson-rwa-ext
Requested rev. no specific revision (document currently at 17)
Type Last Call Review
Team Routing Area Directorate (rtgdir)
Deadline 2018-10-22
Requested 2018-10-05
Requested by Deborah Brungard
Draft last updated 2018-10-22
Completed reviews Rtgdir Last Call review of -08 by Ravi Singh (diff)
Genart Last Call review of -10 by Elwyn Davies (diff)
Secdir Last Call review of -10 by Watson Ladd (diff)
Genart Telechat review of -11 by Elwyn Davies (diff)
Prep for IETF Last Call
Assignment Reviewer Ravi Singh
State Completed
Review review-ietf-pce-wson-rwa-ext-08-rtgdir-lc-singh-2018-10-22
Reviewed rev. 08 (document currently at 17)
Review result Has Nits
Review completed: 2018-10-22


Meant to copy rtg-dir as well.

From: Ravi Singh
Sent: Monday, October 22, 2018 4:45 PM
Subject: Rtgdir review: draft-ietf-pce-wson-rwa-ext-08


I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see ‚Äč

Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft.

Document: draft-ietf-pce-wson-rwa-ext-08
Reviewer: Ravi Singh
Review Date: 10/22/2018
Intended Status: Standard Track

This document is basically ready for publication, but has nits that should be considered prior to publication.

The draft is overall easy to understand.
However, there is a need to address some nits and make minor changes for better readability.

Specific details below:
1.       Section 3: The following text could elaborate the function/properties of a 3R regenerator in a little bit more detail.
"On the other hand, translucent networks include 3R regenerators that are sparsely placed." :
2.       Figure 1:  "SwCap": this could use some more info in the text somewhere.
3.       Section 4:
a.       " the PCEP extensions that are going to be specified in this document based on
   this architecture." ->
" the PCEP extensions that are going to be specified in this document are based on
   this architecture."
4.       Section 4.1:
a.        text says that the WA object must be after the Endpoints object and does not say anything about ordering w.r.t. any following objects. It would be desirable to make an explicit statement either saying that ordering w.r.t. the other following objects is irrelevant, since the text is implying that that is the case.
b.      The term "explicit label control (ELC)" seems to have been coined in this draft and does not exist in RFC4003: while it logically follows from RFC4003, defining a new term in this doc should refer to lingo used in RFC4003 to enable better readability.
5.       Section 4.3:
a.       "Note that the Action field can be set to 0 when unnumbered link identifier is used." : not clear. Please clarify and this sentences belongs in a paragraph of its own to avoid entanglement with "action bits" description.
b.      "See Section 4.2.1. for the encoding of the Link Identifiers Field." : 4.2.1 -> 4.3.1
c.       "See Section 4.2.1. for Link Identifier encoding and Section 4.2.2. for the Wavelength Restriction Field encoding, respectively." -> 4.3.1 and 4.3.2
6.       Section 4.3.1:
a.       IPv4 address and IPv6 address as show in the figure do not align correctly as per the lengths: kindly fix.
b.      4.3.2: "section 2.6," hyperlink links to this draft rather than to RFC7579 as intended. Same for other sections referred in this section.
7.       Section 5:
a.       "Reply for wavelength allocation as discussed" -> "Reply for wavelength allocation request as discussed'
b.      4.2.1/4.2.2 -> 4.3.1/4.3.2
8.       Section 8.2/8.5/8.6: is this IANA request really necessary since an existing subTLV format is being re-used?