Shepherd write-up for draft-ietf-mpls-lsp-ping-registries-update-06
> (1) What type of RFC is being requested
The MPLS working group requests that this document is published as an
RFC on the Standards Track. This is appropriate as it updates RFCs
8029 and 8611 both of which are Standards Track RFCs. Furthermore, the
document requests IANA action applied to registries that need Standards
Action.
The document clearly indicates "Standards Action."
> (2) Please provide a Document Announcement Write-Up.
>
> Technical Summary:
This document updates RFC 8029 and RFC 8611 that both define IANA
registries for MPLS LSP Ping. It also updates the description of the
procedures for the responses sent when an unknown or erroneous code
point is found. The updates are to clarify and align this name space
with recent developments.
> Working Group Summary:
It has been somewhat hard to get WG review for what is a dry procedural
document. However, after poking the group several times we got enough
review to know that the document is sound, and there were no negative
comments.
> Document Quality:
There's nothing here to implement. The judge of the document is whether
IANA can understand it well enough to implement it, and whether the WG
agrees with the intention. That seems to be achieved.
> Personnel:
Adrian Farrel (adrian@olddog.co.uk) is the Document Shepherd
Deborah Brungard (dbrungard@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.
I have reviewed this document several times and the authors made changes
to address my comments. This version is ready for publication.
> (4) Does the document Shepherd have any concerns about the depth or
> breadth of the reviews that have been performed?
As noted in the WG Summary, more reviews would have been reassuring, but
there was enough review for this type of document.
> (5) Do portions of the document need review from a particular or from
> broader perspective. If so, describe the review that took place.
We sent the -04 revision to IANA for review. They sent minor comments
and stated that the document was clear.
> (6) Describe any specific concerns or issues that the Document
> Shepherd has with this document that the Responsible Area Director
> and/or the IESG should be aware of?
No 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. If not, explain why?
All authors confirmed. See https://mailarchive.ietf.org/arch/msg/mpls/jGlcQAYdKaiW7xbmrN36bcqeqm0/
> (8) Has an IPR disclosure been filed that references this document?
No IPR disclosed.
> (9) How solid is the WG consensus behind this document?
No dissenting voices. A few voices of solid support, and a few voices
of minor support.
> (10) Has anyone threatened an appeal or otherwise indicated extreme
> discontent?
No discontent.
> (11) Identify any ID nits the Document Shepherd has found in this
> document.
idnits warns about normative references to IANA registries. Otherwise
no issues.
> (12) Describe how the document meets any required formal review
> criteria.
None needed.
> (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?
None such.
> (15) Are there downward normative references references (see RFC
> 3967)?
None such (but see the answer to 11).
> (16) Will publication of this document change the status of any
> existing RFCs? Are those RFCs listed on the title page header, listed
> in the abstract, and discussed in the introduction?
This document Updates RFC 8029 and RFC 8611.
This is noted in the header.
The Abstract observes that this document updates those RFCs and
describes the nature of the update.
The Introduction expands on the details of the update.
> (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 8126).
This document is all about IANA actions, and is clear. The IANA
Considerations section explicitly directs IANA and is consistent with
the explanations in the rest of the document.
There are no new registries, but there are changes to allocation
procedures for several registries. These are clearly described and all
registries are clearly indicated.
> (18) List any new IANA registries that require Expert Review for
> future allocations.
No Expert Review is needed for any parts of any of the registries.
> (19) Describe reviews and automated checks performed by the Document
> Shepherd to validate sections of the document written in a formal
> language.
No formal language used, no checks performed.
> (20) If the document contains a YANG module, has the module been
> checked with any of the recommended validation tools?
No YANG.