Thanks a lot for the review, please see responses inline, an updated revision will be posted shortly.
________________________________ From: David Sinicrope <[email protected]> Sent: Sunday, November 18, 2018 05:48 To: [email protected]; [email protected] Cc: BRUNGARD, DEBORAH A; Yemin (Amy); Jonathan Hardwick; [email protected] Subject: RtgDir Early Review: draft-ietf-pce-gmpls-pcep-extensions Hello I have been selected to do a routing directorate “early” review of this draft. https://datatracker.ietf.org/doc/draft-ietf-pce-gmpls-pcep-extensions<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dpce-2Dgmpls-2Dpcep-2Dextensions&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=v8kOGBIadQ654pIrYCNQnqFCp1HfR6KLM8nYfCB2wLo&m=wHPiFqxmYJrVYmHWGBU5LyXxKf1Slo900lGIZikn4lE&s=crBdZrzY6aSHQSUdIbjackqcWU4CrESiV30pG0nbkSc&e=> The routing directorate will, on request from the working group chair, perform an “early” review of a draft before it is submitted for publication to the IESG. The early review can be performed at any time during the draft’s lifetime as a working group document. The purpose of the early review depends on the stage that the document has reached. As this document is in working group last call, my focus for the review was to determine whether the document is ready to be published. Please consider my comments along with the other working group last call comments. For more information about the Routing Directorate, please see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir<https://urldefense.proofpoint.com/v2/url?u=http-3A__trac.tools.ietf.org_area_rtg_trac_wiki_RtgDir&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=v8kOGBIadQ654pIrYCNQnqFCp1HfR6KLM8nYfCB2wLo&m=wHPiFqxmYJrVYmHWGBU5LyXxKf1Slo900lGIZikn4lE&s=AobxwZ5By6omomwW7i8zc8xl7gwYY3Yd7z-Cx6KW9E0&e=> Document: draft-ietf-pce-gmpls-pcep-extensions-12.txt Reviewer: David Sinicrope Review Date: November 17, 2018 Intended Status: Standards Track Summary: * This document is basically ready for publication, but has nits and clarifications that should be considered prior to being submitted to the IESG. Comments: Although a bit terse on motivation the document is of good quality and detail providing the level of information needed for protocol specification and implementation. The comments provided below are aimed at improving readability, comprehension and consumption of the document by those that would use it for architecture, solution design and implementation. Abstract. Please provide some detail scope and purpose beyond one line. This is supposed to answer why / whether I should delve into the document. [MC] OLD: This memo provides extensions to the Path Computation Element communication Protocol (PCEP) for the support of GMPLS control plane. NEW: The Path Computation Element (PCE) provides path computation functions for Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. Additional requirements for GMPLS are identified in [RFC7025] . This memo provides extensions to the Path Computation Element communication Protocol (PCEP) for the support of the GMPLS control plane to address those requirements. END General Comments (no particular section) 1. Given that this document is providing the detail for the requirements in 7025, it might be advantageous to the reader to structure the document according to the requirements listed in 7025. [MC] Sections following RFC7025 structure is added to the introduction. 2. The document gives a sparse highlight of what extensions are needed and why Section 1 and then launches into the details in section2 and on. More elaboration on motivation and gaps and requirements would be helpful to better understand why the extensions are needed. [MC] New section describing the requirements and where extensions are needed is added 3. This should be liaised to ITUT SG15 Q12 and Q14 for review. Maybe Q11/15 too. [MC] No additions to what Deborah indicated. Sec 1.2 - RFC 7025 has 13 different requirements listed. 1. Why are they repeated here and not simply referenced? One must have both documents to fully understand the requirements this document is addressing, so there is no need to restate (and possibly misstate) the agreed requirements here for readability [MC] The intent is to summarize the requirements (which are referenced in Section 2), this has been changed on -13 2. Why is this only a subset of the requirements in RFC 7025? Is there less covered here than in RFC7025? If so this must be spelled out in terms of coverage. Perhaps a table to explain the functions noted in 7025 vs what this document covers. [MC] There is less covered than RFC7025 because some of those requirements are addressed by RFC8282, Tables for RFC7025 section 3.1 and section 3.2 will be added to better indicate: - Which requirement is already covered in existing document - Which requirement need new extension. Introduction - this document assumes a significant familiarity with rfc7025 and the other documents listed. It should state this outright. [MC] Added Sec 1.3 - please correlate these to the requirements they are addressing. Also please provide more explanation. Some of these are seemingly contradictory the way they are listed currently. E.g. END-POINTS and ERO make it sound confused as to whether the 7025 requirement on unnumbered interfaces is addressed or not. Some examples would go a long way to providing clarity Note: I noted this is done later in the specific extensions, but could also be done here. [MC] Added in new sections Sec 1.3 - PCEP objects, needs plural [MC] OK Sec 1.3 - they can’t be shortcomings if they were not designed for the use noted. Perhaps “gaps in functional coverage” or “areas for enhancement” is a better description. [MC] OK Sec 1.3 - why is the infusion/exclusion of labels a shortcoming? Please elaborate. [MC] This is a functional gap, text updated Sec 1.3 – Protection should be listed with the others “shortcomings” right now looks like a summary which it isn’t. Indent this text. [MC] OK Sec 1.3 covered pcep extensions - covered by what? This document? If so, please say so. Also say/elaborate on why they are needed. Note: I can see this is done much more in the individual sections describing the extension. It would suffice then to add a note here that more detail on motivation is provided with each individual extension. [MC] The description of which extensions are needed has been reworded to be more clear. Sec 2.2 - excellent cross reference to RFC 7025. I see this is done elsewhere. This makes addressing solution architecture most helpful. Nits: Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 1206 has weird spacing: '...ted bit routi...' -- The document date (September 27, 2018) is 52 days in the past. Is this intentional? [MC] This has been updated From: DEBORAH BRUNGARD <[email protected]> Date: Monday, October 15, 2018 at 12:07 PM To: "[email protected]" <[email protected]> Cc: "[email protected]" <[email protected]>, David Sinicrope <[email protected]> Subject: IETF Last Call started-draft-ietf-pce-gmpls-pcep-extensions Hi Authors (and Shepherd), I thought your document was well written and considering how long we have been waiting for this document😊, I have started IETF Last Call. I’ve started the IETF Last Call due to the window closing in on the next IETF meeting when the other Areas prefer not to have Last Calls overlapping. Dave Sinicrope will be the rtg-dir reviewer and will do his review in parallel with Last Call. Please be sure to have one of you available as the main pen holder to be responsive to Dave, other Area Directorate reviewers comments, and IESG comments. Thanks! Deborah
_______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
