Stateful Path Computation Element (PCE) Protocol Extensions for Usage with Point-to-Multipoint TE Label Switched Paths (LSPs)
draft-ietf-pce-stateful-pce-p2mp-13

[Ballot discuss]
The Security Considerations section has numerous helpful and appropriate references.  Thanks for tracking them down.  However, explicit, additional text is required to help identify, de-duplicate and deconflict the “relevant guidance” provided by them. 

(1) Per “it is important that implementations conform to the relevant security requirements of [RFC5440], [RFC8306] and [RFC8231], and [RFC8281]”:

** [RFC8231] says “RECOMMENDED that these PCEP extensions only be activated on authenticated and encrypted sessions across PCEs and PCCs belonging to the same administrative authority, using Transport Layer Security (TLS) [PCEPS], as per the recommendations and best current practices in [RFC7525]”.  Good language.  This draft again re-states “Securing the PCEP session using Transport Layer Security (TLS) [RFC8253], as per the recommendations and best current practices in [RFC7525], is RECOMMENDED.”  Why say that twice?  Is there something new there?

** Per Section 10.4 of RFC5440 from 2009, IPSec is a MAY and Section 10.2 makes TCP-MD5 a MUST.  The more recent (2017) RFC8306 and RFC8253 reference TLS and TCP-AO, no IPSec.  RFC8306 explicitly says don’t use TCP-MD5.  What is the RECOMMENDED approach today?

(2) Per “[s]ecuring the PCEP session using Transport Layer Security (TLS) [RFC8253], as per the recommendations and best current practices in [RFC7525], is RECOMMENDED”, how should the guidance on both of these drafts be synthesized?  Specifically, this sentence is unclear on whether the the robust TLS 1.2 requirements in Section 3.4 of RFC8253 are RECOMMENDED, and/or whether the Security Considerations/Section 7 of RFC8253, which undermine these robust requirements by saying administrators MAY allow the usage weak ciphersuites, apply.  This sentence also cites RFC7525 which makes statements that weak (NULL) cipher suites MUST NOT be negotiated in contradiction to the RFC8253 Section 7 guidance.

Given the discussion of TLs, some additional treatment of TLS v1.3 is needed, recognizing that RFC7525 does recommend “v1.2+”

Again, there is helpful guidance across all of the references.  Please provide more textually narrative about which specific sections apply on the references.

[Ballot discuss]
This is a comparatively minor point, but I don't think some of the
message layout is quite fully specified.  In particular, Section 7.2
discusses some new TLVs (in a confusing way, referring to the class of
two TLVs as a single nonexistent TLV) but does not always say which
object the TLVs are allowed to appear within.  (The first paragraph
seems to talk of the TLV appearing in a PCRpt, which is a message and as
such would contain only objects and not TLVs directly.)  The second
paragraph does mention the LSP object, which leads the reader to infer
that this TLV is only intended to appear in the LSP object, and only in
the PCRpt and PCUpd messages explicitly mentioned, but we probably
shouldn't force readers to make that leap.

[Ballot comment]
I've made a lot of comments about grammar nits (tagged as such), but
there are also some more substantial comments to look for.

Section 1

  [RFC4875] describes how to set up point-to-multipoint (P2MP) Traffic
  Engineering Label Switched Paths (TE LSPs) for use in Multiprotocol
  Label Switching (MPLS) and Generalized MPLS (GMPLS) networks.  The
  PCE has been identified as a suitable application for the computation
  of paths for P2MP TE LSPs ([RFC5671]).

nit: some readers might wonder who has done this identification.

Section 3.1

  [RFC8051] presents several use cases, demonstrating scenarios that
  benefit from the deployment of a stateful PCE including optimization,
  recovery, etc., which are equally applicable to P2MP TE LSPs.
  [RFC8231] defines the extensions to PCEP for P2P TE LSPs.  [...]

nit: maybe "the extensions to PCEP needed for stateful operation of P2P
TE LSPs"?  Just "the extensions" is pretty generic.

Section 5.1

  Path Computation State Report (PCRpt):  Each P2MP TE LSP State Report
      in a PCRpt message can contain actual P2MP TE LSP path attributes,

Is this "can contain" or just "contains"?

Section 5.6.3.1

  The Instantiation operation of P2MP TE LSPs is same as defined in

nit: "the same as"

  section 5.3 of [RFC8281] including handling of PLSP-ID, SYMBOLIC-

nit: comma after "[RFC8281]"

  PATH-NAME TLV etc.  Rules of processing and error codes remains

nit: comma after TLV

  unchanged.  The N (P2MP) flag (Section 7.1) MUST be set in LSP object

nit: "The rules for processing and use of error codes remain unchanged."
nit: "in the LSP object"

  in PCInitiate message by PCE to specify the instantiation is for P2MP

nit: "PCInitiate messages by the PCE to specify that the instantiation"

  TE LSPs.  Like the PLSP-ID as per [RFC8281], the P2MP-LSP-IDENTIFIERS

nit: parentheses around "as per [RFC8281]"

  TLV SHOULD NOT be included in the LSP object in PCIntiitate message

nit: "PCInitiate messages"

  (as it is generated by PCC and carried in PCRpt message instead) and
  MUST be ignored on receipt.

Section 6.1

Was it a conscious decision to depart from RFC 8231 and inline objects
in the definition of  (as opposed to keeping the
intermediate construction)?

  The P2MP END-POINTS object defined in [RFC8306] is mandatory for
  specifying address of P2MP leaves grouped based on leaf types.

nit: "addresses of P2MP leaves, grouped by leaf type"

  When reporting the status of a P2MP TE LSP, the destinations MUST be
  grouped in END-POINTS object based on the operational status (O field
  in S2LS object) and leaf type (in END-POINTS).  This way, leaves of
  the same type that share the same operational status are grouped
  together.  [...]

Does this mean that it's an error for a PCRpt message to include more
than one END-POINTS object with a given value of leaf-type?  If so, it
may be worth stating that explicitly.

  For a delegated P2MP TE LSP configuration changes are reported via
  PCRpt message.  For example, adding of new leaves END-POINTS (leaf-
  type = 1) is used where as removing of old leaves (leaf-type = 2) is
  used.

nit: "is used, and removing of old leaves (leaf-type = 2) is used".

  Note that the compatibility with the [RFC8231] definition of  is preserved.  At least one instance of  MUST be
  present in this message for P2MP LSP.

Interestingly, RFC 8231 does not spell the structure of the PCRpt
message using an  object.

Section 6.2

  Note that the compatibility with the [RFC8231] definition of  is preserved.

If I'm reading this right, compatibility is only preserved when
is omitted (and the list only has a single endpoint/path
pair).  Perhaps some more text could be added about the nature of the
provided (and needed) compatibility?

Section 6.6.2

  The LSP State Report message is sent by a PCC to report or delegate
  the P2MP TE LSPs.  An example of a PCRpt message for a delegated P2MP
  TE LSPs is described below to add new leaves to an existing P2MP TE

nit: "TE LSP"

It might be handy to mention inline "for leaf type 1 (add)" and "leaf
type 2 (remove)" just to refresh the reader's memory.

Section 7.1

  The flags defined in this section (N, F, E flags) are used in PCRpt,
  PCUpd, or PCInitiate message.  In case of PCReq and PCRep message,
  these flags have no meaning and thus MUST be ignored.  The
  corresponding flags in the RP (Request Parameters) object are used as
  described in [RFC8231].

I'm not really finding much discussion of RP flags in RFC 8231 (as
opposed to SRP, in Section 7.2 thereof).  RFC 5440 does define a few
flags for the RP object, though.

Section 7.2

I strongly suggest changing the initial language to make it clear that
there is not a single P2MP-LSP-IDENTIFIER TLV, but rather a class of two
related TLVs that serve to identify P2MP LSPs, e.g., by referring to
"P2MP LSP Identification TLVs" (without hyphenation or all-caps).

  If the N bit is set on a PCRpt but the P2MP-LSP-IDENTIFIER TLV is

nit: the bit is set in the LSP object within the PCRpt, right?

  The P2MP-LSP-IDENTIFIERS TLV MAY be included in the LSP object in the
  PCUpd message for P2MP TE LSPs.  The special value of all zeros for
  this TLV is used to refer to all paths pertaining to a particular
  PLSP-ID.

Given that we haven't specialized into the IP version-specific TLVs yet,
I agree with the previous comments that we need greater clarity on what
the "value of all zeros" means, here.  Additionally, is that special
value supposed to be restricted to the given IP version or literally all
paths, so that there are two functionally equivalent encodings for these
semantics?

Section 9

  The PCEP extensions described in this document for stateful PCEs with
  P2MP capability MUST NOT be used if PCE has not advertised its
  stateful capability with P2MP as per Section 5.2.  If the PCEP
  Speaker on the PCC supports the extensions of this draft (understands
  the P2MP flag in the LSP object) but did not advertise this
  capability, then upon receipt of PCUpd message from the PCE, it
  SHOULD generate a PCErr with error-type 19 ("Invalid Operation"),
  error-value 12 (early allocated by IANA) ("Attempted LSP Update
  Request for P2MP if active stateful PCE capability for P2MP was not
  advertised") and terminate the PCEP session.  If the PCEP Speaker on
  the PCE supports the extensions of this draft (understands the P2MP
  flag in the LSP object) but did not advertise this capability, then

We should probably disambiguate these two "P2MP flag"s to "M flag" and
"N flag", respectively.  ("P flags" is used below.)

  If a Stateful PCE receives a P2MP TE LSP report message and the PCE
  does not understand the P2MP flag in the LSP object, and therefore
  the PCEP extensions described in this document, then the Stateful PCE
  would act as per [RFC8231].

Without a section reference, it's a little annoying to figure out
exactly what that behavior would be.

Section 14.2

One could perhaps argue that RFCs 4875, 7525, and 8253 should be
normative references.

[Ballot comment]
* Section 7.2.

"The special value of all zeros for this TLV is used to refer to all paths pertaining to a particular PLSP-ID."

Can you clarify what fields are all zero? What would the length be?

[Ballot comment]
Just a quick clarification question on fragmentation: I'm wondering if it is really necessary to define a fragmentation mechanism/bit for each object separately (e.g also RFC8306) or if it would be more appropriate to allocate one bit in the common header? Just asking as I'm really not an expert here...

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-pce-stateful-pce-p2mp-12. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there are seven actions which we must complete.

First, in the Path Computation Element (PCE) Capability Flags registry on the Open Shortest Path First v2 (OSPFv2) Parameters registry page located at:

https://www.iana.org/assignments/ospfv2-parameters/

the following temporary registrations will be made permanent and have their references changed to [ RFC-to-be ]:

Bit Meaning
13 Active Stateful PCE with P2MP
14 Passive Stateful PCE with P2MP
15 Stateful PCE Initiation with P2MP

Second, in the STATEFUL-PCE-CAPABILITY TLV Flag Field registry on the Path Computation Element Protocol (PCEP) Numbers registry page located at:

https://www.iana.org/assignments/pcep/

the following temporary registrations will be made permanent and have their references changed to [ RFC-to-be ].

Value Meaning
23 P2MP-LSP-INSTANTIATION-CAPABILITY
24 P2MP-LSP-UPDATE-CAPABILITY
25 P2MP-CAPABILITY

Third, in the LSP Object Flag Field registry also on the Path Computation Element Protocol (PCEP) Numbers registry page located at:

https://www.iana.org/assignments/pcep/

the following temporary registrations will be made permanent and have their references changed to [ RFC-to-be ]:

Bit Description
2 Fragmentation
3 P2MP

In addition, a single, new registration will be made in the same registry as follows:

Bit: [ TBD-at-Registration ]
Description: ERO-compression
Reference: [ RFC-to-be ]

Fourth, in the PCEP-ERROR Object Error Types and Values registry also on the Path Computation Element Protocol (PCEP) Numbers registry page located at:

https://www.iana.org/assignments/pcep/

the following temporary registrations will be made permanent and have their references changed to [ RFC-to-be ]:

Error-Type Meaning
6 Mandatory Object missing [RFC5440]
Error-value?: S2LS object missing
Error-value?: P2MP-LSP-IDENTIFIERS TLV missing
18 P2MP Fragmentation Error [RFC8306]
Error-value= 2. Fragmented Report
failure
Error-value= 3. Fragmented Update
failure
Error-value= 4. Fragmented Instantiation
failure
19 Invalid Operation [RFC8231]
Error-value= 11. Attempted LSP State Report
for P2MP if stateful PCE capability
for P2MP was not advertised
Error-value= 12. Attempted LSP Update Request
for P2MP if active stateful PCE capability
for P2MP was not advertised
Error-value= 13. Attempted LSP Instantiation
Request for P2MP if stateful PCE
instantiation capability for P2MP was not
advertised

In addition, a single, new registration will be made in the same registry as follows:

Error-Type Meaning
10 Reception of an invalid object [RFC5440]
Error-value=TBD1: Mis-match of O field in S2LS and LSP object

Fifth, in the PCEP TLV Type Indicators registry also on the Path Computation Element Protocol (PCEP) Numbers registry page located at:

https://www.iana.org/assignments/pcep/

the following temporary registrations will be made permanent and have their references changed to [ RFC-to-be ]:

Value Meaning
32 P2MP-IPV4-LSP-IDENTIFIERS
33 P2MP-IPV6-LSP-IDENTIFIERS

Sixth, in the PCEP Objects registry also on the Path Computation Element Protocol (PCEP) Numbers registry page located at:

https://www.iana.org/assignments/pcep/

the following temporary registration will be made permanent and have its reference changed to [ RFC-to-be ]:

Object-Class Value Name Object-Type
41 S2LS
0: Reserved
1: S2LS

Seventh, a new registry is to be created called the S2LS Object Flag Field registry. The new registry will be located on the Path Computation Element Protocol (PCEP) Numbers registry page located at:

https://www.iana.org/assignments/pcep/

The registry will be managed via Standards Action as defined in RFC 8126. The S2LS Object Flag Field is a 32-bit field. There are initial registrations in the new registry as follows:

Bit Description Reference
-------+---------------------+----------------
29-31 Operational (3-bits) [ RFC-to-be ]
0-28 Unassigned

The IANA Functions Operator understands that these are the only actions required to
be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2019-03-20):

From: The IESG
To: IETF-Announce
CC: db3546@att.com, draft-ietf-pce-stateful-pce-p2mp@ietf.org, Adrian Farrel , pce@ietf.org, pce-chairs@ietf.org, adrian@olddog.co.uk
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Path Computation Element (PCE) Protocol Extensions for Stateful PCE usage for Point-to-Multipoint Traffic Engineering Label Switched Paths) to Proposed Standard


The IESG has received a request from the Path Computation Element WG (pce) to
consider the following document: - 'Path Computation Element (PCE) Protocol
Extensions for Stateful PCE
  usage for Point-to-Multipoint Traffic Engineering Label Switched
  Paths'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2019-03-20. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  The Path Computation Element (PCE) has been identified as an
  appropriate technology for the determination of the paths of point-
  to-multipoint (P2MP) TE Label Switched Paths (LSPs).  This document
  provides extensions required for Path Computation Element
  Communication Protocol (PCEP) so as to enable the usage of a stateful
  PCE capability in supporting P2MP TE LSPs.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-pce-p2mp/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-pce-p2mp/ballot/


No IPR declarations have been submitted directly on this I-D.

Shepherd Write-up for draft-ietf-pce-stateful-pce-p2mp-09

> (1) What type of RFC is being requested (BCP, Proposed Standard,
>    Internet Standard, Informational, Experimental, or Historic)?
>    Why is this the proper type of RFC?  Is this type of RFC
>    indicated in the title page header?

Publication is requested as a Standards Track RFC. 
This is appropriate because the document defines extensions to a
protocol that is already published on the Standards Track. These
extensions are intended for implementation and deployment.
This is indicated in the header of the document.

> (2) The IESG approval announcement includes a Document
>    Announcement
>
> Technical Summary

The Path Computation Element (PCE) has been identified as an
appropriate technology for the determination of the paths of
point-to-multipoint (P2MP) TE Label Switched Paths (LSPs).

This document provides extensions required for Path Computation
Element Communication Protocol (PCEP) so as to enable the usage
of a statefulPCE capability in supporting P2MP TE LSPs.

> Working Group Summary

The working group process has been uneventful. The author team
comes from vendors and operators who ship and deploy P2MP
RSVP-TE and so have a very strong interest in these PCE
extensions.

IANA Early code point allocation was made for the code points
needed by this work.

> Document Quality

This document received only moderate review during its time in
the working group. P2MP function is somewhat fringe, and so
only a small group of people worked on it. As a result, WG last
call was quiet.

The document shepherd (Adrian Farrel) and the out-going chair
(Jon Hardwick) made a detailed reviews that led to a number of
minor changes.

Implementation status is not known, but it is believed that
two vendors have roadmap plans.

> Personnel

Adrian Farrel (adrian@olddog.co.uk) is the Document Shepherd

Deborah Brungard (db3546@att.com) is the Responsible
Area Director

> (3) Briefly describe the review of this document that was
>    performed by the Document Shepherd.  If this version of
>    the document is not ready for publication, please explain
>    why the document is being forwarded to the IESG.

The Shepherd did a detailed line-by-line review and the authors
made appropriate updates. This revision is ready for publication.

> (4) Does the document Shepherd have any concerns about the
>    depth or breadth of the reviews that have been performed?

Good enough. Could have used more, but it will do.

> (5) Do portions of the document need review from a particular
>    or from broader perspective, e.g., security, operational
>    complexity, AAA, DNS, DHCP, XML, or internationalization?
>    If so, describe the review that took place.

No. There are some parts that use RBNF. They are not normative,
but have had careful scrutiny from PCEP experts.

> (6) Describe any specific concerns or issues that the Document
>    Shepherd has with this document.

No such concerns.

> (7) Has each author confirmed that any and all appropriate IPR
>    disclosures required for full conformance with the
>    provisions of BCP 78 and BCP 79 have already been filed.

A poll was carried out on the mailing list and all authors
explicitly confirmed their compliance.

> (8) Has an IPR disclosure been filed that references this
>    document? If so, summarize any WG discussion and conclusion
>    regarding the IPR disclosures.

No IPR has been disclosed.

> (9) How solid is the WG consensus behind this document? Does
>    it represent the strong concurrence of a few individuals,
>    with others being silent, or does the WG as a whole
>    understand and agree with it? 

General agreement that the work should be done, but light interest
in the details beyond the author team and reviewers. No dissent.

> (10) Has anyone threatened an appeal or otherwise indicated
> extreme discontent?

No.

> (11) Identify any ID nits the Document Shepherd has found in
>      this document.

Only problem is s/[This I-D]/[This.I-D]/

> (12) Describe how the document meets any required formal
>      review criteria, such as the MIB Doctor, media type,
>      and URI type reviews.

No such requirements.

> (13) Have all references within this document been identified
>      as either normative or informative?

Yes

> (14) Are there normative references to documents that are not
>      ready for advancement or are otherwise in an unclear state?
>      If such normative references exist, what is the plan for
>      their completion?

No issues.

> (15) Are there downward normative references references (see
>      RFC 3967)?

No Downrefs

> (16) Will publication of this document change the status of
>      any existing RFCs?

No.

> (17) Describe the Document Shepherd's review of the IANA
>      considerations section, especially with regard to its
>      consistency with the body of the document. Confirm that
>      all protocol extensions that the document makes are
>      associated with the appropriate reservations in IANA
>      registries.
>      Confirm that any referenced IANA registries have been
>      clearly identified. Confirm that newly created IANA
>      registries include a detailed specification of the
>      initial contents for the registry, that allocations
>      procedures for future registrations are defined, and a
>      reasonable name for the new registry has been suggested
>      (see RFC 5226).

Everything looks good.
A substantial set of early allocations were made in April 2018
and this publication request (with the IANA section) requests
IANA to confirm those assignments.

This document makes no requests to modify or remove any of the
early allocations, however, section 10.7 does request the
creation of a further registry. This is well defined.

> (18) List any new IANA registries that require Expert Review
>      for future allocations.

None

> (19) Describe reviews and automated checks performed by the
>      Document Shepherd to validate sections of the document
>      written in a formal language, such as XML code, BNF rules,
>      MIB definitions, etc.

RBNF reviewed manually.

Shepherd Write-up for draft-ietf-pce-stateful-pce-p2mp-09

> (1) What type of RFC is being requested (BCP, Proposed Standard,
>    Internet Standard, Informational, Experimental, or Historic)?
>    Why is this the proper type of RFC?  Is this type of RFC
>    indicated in the title page header?

Publication is requested as a Standards Track RFC. 
This is appropriate because the document defines extensions to a
protocol that is already published on the Standards Track. These
extensions are intended for implementation and deployment.
This is indicated in the header of the document.

> (2) The IESG approval announcement includes a Document
>    Announcement
>
> Technical Summary

The Path Computation Element (PCE) has been identified as an
appropriate technology for the determination of the paths of
point-to-multipoint (P2MP) TE Label Switched Paths (LSPs).

This document provides extensions required for Path Computation
Element Communication Protocol (PCEP) so as to enable the usage
of a statefulPCE capability in supporting P2MP TE LSPs.

> Working Group Summary

The working group process has been uneventful. The author team
comes from vendors and operators who ship and deploy P2MP
RSVP-TE and so have a very strong interest in these PCE
extensions.

IANA Early code point allocation was made for the code points
needed by this work.

> Document Quality

This document received only moderate review during its time in
the working group. P2MP function is somewhat fringe, and so
only a small group of people worked on it. As a result, WG last
call was quiet.

The document shepherd (Adrian Farrel) and the out-going chair
(Jon Hardwick) made a detailed reviews that led to a number of
minor changes.

Implementation status is not known, but it is believed that
two vendors have roadmap plans.

> Personnel

Adrian Farrel (adrian@olddog.co.uk) is the Document Shepherd

Deborah Brungard (db3546@att.com) is the Responsible
Area Director

> (3) Briefly describe the review of this document that was
>    performed by the Document Shepherd.  If this version of
>    the document is not ready for publication, please explain
>    why the document is being forwarded to the IESG.

The Shepherd did a detailed line-by-line review and the authors
made appropriate updates. This revision is ready for publication.

> (4) Does the document Shepherd have any concerns about the
>    depth or breadth of the reviews that have been performed?

Good enough. Could have used more, but it will do.

> (5) Do portions of the document need review from a particular
>    or from broader perspective, e.g., security, operational
>    complexity, AAA, DNS, DHCP, XML, or internationalization?
>    If so, describe the review that took place.

No. There are some parts that use RBNF. They are not normative,
but have had careful scrutiny from PCEP experts.

> (6) Describe any specific concerns or issues that the Document
>    Shepherd has with this document.

No such concerns.

> (7) Has each author confirmed that any and all appropriate IPR
>    disclosures required for full conformance with the
>    provisions of BCP 78 and BCP 79 have already been filed.

A poll was carried out on the mailing list and all authors
explicitly confirmed their compliance.

> (8) Has an IPR disclosure been filed that references this
>    document? If so, summarize any WG discussion and conclusion
>    regarding the IPR disclosures.

No IPR has been disclosed.

> (9) How solid is the WG consensus behind this document? Does
>    it represent the strong concurrence of a few individuals,
>    with others being silent, or does the WG as a whole
>    understand and agree with it? 

General agreement that the work should be done, but light interest
in the details beyond the author team and reviewers. No dissent.

> (10) Has anyone threatened an appeal or otherwise indicated
> extreme discontent?

No.

> (11) Identify any ID nits the Document Shepherd has found in
>      this document.

Only problem is s/[This I-D]/[This.I-D]/

> (12) Describe how the document meets any required formal
>      review criteria, such as the MIB Doctor, media type,
>      and URI type reviews.

No such requirements.

> (13) Have all references within this document been identified
>      as either normative or informative?

Yes

> (14) Are there normative references to documents that are not
>      ready for advancement or are otherwise in an unclear state?
>      If such normative references exist, what is the plan for
>      their completion?

No issues.

> (15) Are there downward normative references references (see
>      RFC 3967)?

No Downrefs

> (16) Will publication of this document change the status of
>      any existing RFCs?

No.

> (17) Describe the Document Shepherd's review of the IANA
>      considerations section, especially with regard to its
>      consistency with the body of the document. Confirm that
>      all protocol extensions that the document makes are
>      associated with the appropriate reservations in IANA
>      registries.
>      Confirm that any referenced IANA registries have been
>      clearly identified. Confirm that newly created IANA
>      registries include a detailed specification of the
>      initial contents for the registry, that allocations
>      procedures for future registrations are defined, and a
>      reasonable name for the new registry has been suggested
>      (see RFC 5226).

Everything looks good.
A substantial set of early allocations were made in April 2018
and this publication request (with the IANA section) requests
IANA to confirm those assignments.

This document makes no requests to modify or remove any of the
early allocations, however, section 10.7 does request the
creation of a further registry. This is well defined.

> (18) List any new IANA registries that require Expert Review
>      for future allocations.

None

> (19) Describe reviews and automated checks performed by the
>      Document Shepherd to validate sections of the document
>      written in a formal language, such as XML code, BNF rules,
>      MIB definitions, etc.

RBNF reviewed manually.