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

From: Paul Kyzivat <[email-masked]>
Date: Tue, 20 Aug 2019 12:28:44 -0400

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.

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.

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?

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.

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.

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.

7) NIT: Outdated references:

IdNits reports outdated references. I trust these will be updated in due 
course.

---

From: "King, Daniel" <[email-masked]>
Date: Wed, 21 Aug 2019 09:24:36 +0000

Thanks for the detailed review. We can address these NITS in a new version. 

BR, Dan. 

-----Original Message-----
From: Paul Kyzivat <[email-masked]> 
Sent: 20 August 2019 17:29
To: [email-masked]
Cc: General Area Review Team <[email-masked]>
Subject: Gen-ART Last Call review of draft-ietf-pce-stateful-hpce-11

<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrac.ietf.org%2Ftrac%2Fgen%2Fwiki%2FGenArtfaq&amp;data=02%7C01%7Cd.king%40lancaster.ac.uk%7C0d24550b9fbc4e5be20c08d7258b7fa2%7C9c9bcd11977a4e9ca9a0bc734090164a%7C1%7C1%7C637019153385705933&amp;sdata=68DF9KuLuw6s4TOiccSfdVFPTknX6B%2BNzoIxxU3amsU%3D&amp;reserved=0>.

Summary:

Issues:

Major: 0
Minor: 0
Nits:  7

1) NIT: No glossary

C -> XC
E -> XE

Can you rephrase it?

4) NIT: Unclear text

---

From: Dhruv Dhody <[email-masked]>
Date: Wed, 21 Aug 2019 16:56:31 +0530

Hi Paul,

Thanks for your review, please see inline...

> would really appreciate having a glossary in the document.

Added.

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

>     the LER in the domain where the LSP originates, sends a request to

Updated.

> is to execute these elements? I think it is PCE5, but I'm not certain.

Updated.

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

> A similar link to the same spot in section 3.2 is ok.

I arranged the words so that rfcmarkup works.

> IdNits reports outdated references. I trust these will be updated in due

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

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 21 Aug 2019 13:12:20 -0400

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