Re: [Pce] Gen-ART Last Call review of draft-ietf-pce-stateful-hpce-11

[Paul Kyzivat <[e-mail]>]

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 <[e-mail]> 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
>