Subject: [Pce] Alvaro Retana's No Objection on draft-ietf-pce-hierarchy-extensions-10: (with COMMENT)

From: Alvaro Retana via Datatracker <[email-masked]>
Date: Wed, 15 May 2019 05:49:07 -0700

Alvaro Retana has entered the following ballot position for
draft-ietf-pce-hierarchy-extensions-10: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-pce-hierarchy-extensions/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

(1) rfc6805 should be a Normative reference; the contents reflect its
importance in the definition of the extensions, and this text in the
Introduction confirms it:

   This document defines the PCEP extensions for the purpose of
   implementing Hierarchical PCE procedures, which are described in
   [RFC6805].

[I am not balloting this point as a DISCUSS because I believe it is easy to
resolve and trust the Responsible AD.]

(2) The Shepherd's writeup mentions the existence of "commercial as well as
open source implementations" -- these are documented in Appendix A.  What code
points are used in those implementation?  Is the code deployed (in production)?
 I'm asking because all the code points (except the ones defined in this
document, of course) have not been assigned by IANA...and have to wonder about
potential collision (or even squatting).

[I realize the Authors may not have an answer available...it would be very nice
if someone (Authors/Shepherd/Chair/AD/anyone) would check.  There might be
nothing to worry about; better safe than sorry.]

(3) §3.2.2: It is not clear to me whether the Domain Type is a bit field (one
per type), or if there are 256 possible types.  Please clarify.

(4) Related to the last point...  §7.3 doesn't list which range is
unassigned...nor whether the value 0 (assuming it is not a bit field) is
available to assignment or not.

(5) Please add a reference for PCEP-LS?

(6) [nit] s/achild/a child

(7) [nit] §3.2.1.1: The first paragraph is missing the closing ".

---

From: Dhruv Dhody <[email-masked]>
Date: Wed, 15 May 2019 18:56:33 +0530

Hi Alvaro,

Responding to this comment -

> nothing to worry about; better safe than sorry.]

For the implementations I am aware of and remember, the code is not
deployed in production yet and the experimental code points was used
(as per RFC8356 where possible), with the plan to update the code once
IANA allocation is done. I will re-check.

Thanks!
Dhruv (Shepherd)