Paul, thanks for your review. Dhruv, thanks for the updates. I entered a No Objection ballot.
Alissa > On Aug 21, 2019, at 1:12 PM, Paul Kyzivat <[email protected]> wrote: > > Dhruv, > > Thanks for addressing my concerns. > > Regarding (C-E / E-C) and (EC-EP / EP-EC): I recognized that there was more > to it, and that using "E" for P-PCE in this document would be problematic. I > guess this is just a conflict between documents that has to be tolerated. > > And it hadn't dawned on me that the linking issues were artifacts of the > automatic generation mechanism. > > Thanks, > Paul > > On 8/21/19 7:26 AM, Dhruv Dhody wrote: >> Hi Paul, >> Thanks for your review, please see inline... >> On Tue, Aug 20, 2019 at 9:58 PM Paul Kyzivat <[email protected]> wrote: >>> >>> I am the assigned Gen-ART reviewer for this draft. The General Area >>> Review Team (Gen-ART) reviews all IETF documents being processed >>> by the IESG for the IETF Chair. Please treat these comments just >>> like any other last call comments. >>> >>> For more information, please see the FAQ at >>> >>> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. >>> >>> Document: draft-ietf-pce-stateful-hpce-11 >>> Reviewer: Paul Kyzivat >>> Review Date: 2019-08-20 >>> IETF LC End Date: 2019-08-28 >>> IESG Telechat date: ? >>> >>> Summary: >>> >>> This draft is basically ready for publication, but has nits that should >>> be fixed before publication. >>> >>> Issues: >>> >>> Major: 0 >>> Minor: 0 >>> Nits: 7 >>> >>> 1) NIT: No glossary >>> >>> Since I am not familiar with the subject domain, when I started reading >>> this document I felt I was lost among the acronyms. While you are good >>> at defining these at first use, I couldn't keep them all in mind as I >>> read. I had to create my own glossary to support me while reading. I >>> would really appreciate having a glossary in the document. >>> >> Added. >>> 2) NIT: Inconsistent terminology >>> >>> In section 3 two pairs of terms are introduced: (C-E / E-C) and (EC-EP / >>> EP-EC). IIUC in the first pair "E" stands for "PCE" while in the second >>> pair "E" seems to stand for "Extended", while "P" stands for PCE. I >>> found this very confusing. I think it would be better to allow "E" to >>> mean the same thing in both pairs. Perhaps you could use "X" to stand >>> for "eXtended". Then there would be clear parallels: >>> >>> C -> XC >>> E -> XE >>> >>> Please consider doing something relieve the confusion. >>> >> The use of notation C-E and E-C is as per RFC 8231 >> https://tools.ietf.org/html/rfc8231#section-4 where PCC to PCE is >> (C-E) and PCE to PCC is (E-C). In this document we wanted to represent >> messages between C-PCE (child PCE) to P-PCE (parent PCE) and we used >> EC-EP for it and the reverse EP-EC for P-PCE to C-PCE communication. >> This was discussed during shepherd review as well (as we were using CE >> and PE before but that was causing confusion because of the well known >> meaning of those terms in routing). >> I would like to keep the existing notations that has WG support. >>> 3) NIT: Badly formed sentence >>> >>> I can't parse this sentence in section 3.1: >>> >>> Procedures as described in [RFC6805] are applied and where the >>> ingress C-PCE (Child PCE), triggers a path computation request for >>> the LER in the domain where the LSP originates, sends a request to >>> the P-PCE. >>> >>> Can you rephrase it? >>> >> Updated. >>> 4) NIT: Unclear text >>> >>> In section 3.1 are steps A/B/C/D to be added at the *end*, after step >>> 11? It would help to be explicit. >>> >>> In step (C) of section 3.2, can you please be explicit about which node >>> is to execute these elements? I think it is PCE5, but I'm not certain. >>> >> Updated. >>> 5) NIT: Unlinked references >>> >>> Some RFC references (e.g. [RFC8051] and [RFC8231] in section 1.1, and >>> [RFC8232] in section 3.1) are not linked in the HTML version. I suggest >>> a global search for all such unlinked references in the source. >>> >> The HTML version of the draft is automatically generated from the text >> version. The `rfcmarkup` is used to render the HTML of the I-D/sRFCs. >> Specifically, rfcmarkup produces the final HTML using heuristics from >> the source TXT and this is beyond the control of the authors. >>> 6) NIT: Bad reference link >>> >>> In the following from section 3.1: >>> >>> Steps 1 to 11 are exactly as described in section 4.6.2 (Hierarchical >>> PCE End-to-End Path Computation Procedure) of [RFC6805], the >>> >>> the "section 4.6.2" is linked to the non-existent section 4.6.2 of >>> *this* document rather than RFC6805. >>> >>> A similar link to the same spot in section 3.2 is ok. >>> >> I arranged the words so that rfcmarkup works. >>> 7) NIT: Outdated references: >>> >>> IdNits reports outdated references. I trust these will be updated in due >>> course. >>> >> Updated. >> Working Copy: >> https://github.com/dhruvdhody/ietf/blob/master/draft-ietf-pce-stateful-hpce-12.txt >> Diff: >> https://tools.ietf.org/rfcdiff?url1=draft-ietf-pce-stateful-hpce-11&url2=https://raw.githubusercontent.com/dhruvdhody/ietf/master/draft-ietf-pce-stateful-hpce-12.txt >> Thanks! >> Dhruv > > _______________________________________________ > Gen-art mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/gen-art _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
