Path Computation Element Communication Protocol (PCEP) Extensions for the Hierarchical Path Computation Element (H-PCE) Architecture
RFC 8685

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

A few simple items in the Security Considerations (Section 8):
(1) s/security requirements defined in [RFC5440]/security considerations defined in [RFC5440]/.  The motivation for this change is that the discussion of vulnerabilities and mitigations in [RFC5440] also applies.

(2) Please include a reference to RFC7525 when recommending TLS/RFC8253

Thanks for responding to the Gen-ART comments and my DISCUSS ballot.

Upon re-reading 4.1 with my new understanding of the OPEN semantics, it's not totally clear why the "shoulds" in this section (dealing with the error conditions) are non-normative.

Thanks for a well-written document.  A procedural point: as Dhruv is listed as a contributing author, it would have been better had someone else been assigned as the document shepherd.  Not a big thing, but something to remember for next time.

A couple of minor editorial comments:

— Section 3.2.2 —

   The value part comprises of -

We don’t say “comprises of”, and the dash isn’t right. Make it:

   The value part comprises:

— Section 3.3.2 —

   The usage of Domain-ID TLV, carried in an OPEN object, is used to

Remove “usage of”, as it’s redundant.

Hi,

thanks for this Document. I have a couple of comments/suggestions:

3.2.1
   If the PCE understands the H-PCE path computation request but did not
   advertise its H-PCE capability, it MUST send a PCErr message with
   Error-Type=TBD8 ("H-PCE error") and Error-Value=1 ("Parent PCE
   Capability not advertised").
I believe the description of the error is incorrect and should be: "H-PCE Capability not advertised"


3.6.  SVEC Object
   o  O (Domain diverse) bit - TBD14
You call it the O bit here but not in the IANA registry. I guess the two should be consistent.


In IANA section:
s/H-PCE-FLAGS/H-PCE-FLAG/ (twice)
s/assign three new/assign four new/

typos
s/suitible /suitable/ 
s/Aditionally/Additionally/

I recommend to also use normative language in section 6, especially 6.1.2.:
 "The parent PCE must only accept path computation requests from
   authorized child PCEs.  If a parent PCE receives requests from an
   unauthorized child PCE, the request should be dropped."