Document Shepherd Write-Up for draft-ietf-mpls-mna-ioam
Document shepherd: Adrian Farrel (adrian@olddog.co.uk)
Current revision: 13
## Document History
> 1. Does the working group (WG) consensus represent the strong
> concurrence of a few individuals, with others being silent, or did
> it reach broad agreement?
There was clear supportive consensus from the working group.
A number of small issues were raised, but these were resolved in new
revisions of the document.
> 2. Was there controversy about particular points, or were there
> decisions where the consensus was particularly rough?
No controversy or roughness.
> 3. Has anyone threatened an appeal or otherwise indicated extreme
> discontent? If so, please summarize the areas of conflict in
> separate email messages to the responsible Area Director. (It
> should be in a separate email because this questionnaire is
> publicly available.)
No threats or visible discontent.
> 4. For protocol documents, are there existing implementations of the
> contents of the document? Have a significant number of potential
> implementers indicated plans to implement? Are any existing
> implementations reported somewhere, either in the document itself
> (as RFC 7942 recommends) or elsewhere (where)?
No implementations have been reported.
## Additional Reviews
> 5. Do the contents of this document closely interact with technologies
> in other IETF working groups or external organizations, and would
> it therefore benefit from their review? Have those reviews
> occurred? If yes, describe which reviews took place.
There is a strong dependency on the iOAM work done in the IPPM working
group. The authors specifically introduced the draft to IPPM, a review
from the Perfmetrics Directorate and another from the Operations
Directorate were commissioned and addressed.
> 6. Describe how the document meets any required formal expert review
> criteria, such as the MIB Doctor, YANG Doctor, media type, and URI
> type reviews.
No formal reviews required.
> 7. If the document contains a YANG module, has the final version of
> the module been checked with any of the recommended validation
> tools for syntax and formatting validation? If there are any
> resulting errors or warnings, what is the justification for not
> fixing them at this time? Does the YANG module comply with the
> Network Management Datastore Architecture (NMDA) as specified in
> RFC 8342?
No YANG.
> 8. Describe reviews and automated checks performed to validate
> sections of the final version of the document written in a formal
> language, such as XML code, BNF rules, MIB definitions, CBOR's
> CDDL, etc.
No formal language.
## Document Shepherd Checks
> 9. Based on the shepherd's review of the document, is it their opinion
> that this document is needed, clearly written, complete, correctly>
> designed, and ready to be handed off to the responsible Area
> Director?
The shepherd review took place after WGLC has completed and the document
had been updated. The review threw up a few nits that the authors will
either address in a new revision, or will hold to fold in with any
changes resulting from the AD review.
> 10. Several IETF Areas have assembled lists of common issues that
> their reviewers encounter. For which areas have such issues been
> identified and addressed? For which does this still need to happen
> in subsequent reviews?
The document has been compared against the RTG Area issues list. No
further resolutions are needed.
> 11. What type of RFC publication is being requested on the IETF stream
> (Best Current Practice, Proposed Standard, Internet Standard,
> Informational, Experimental or Historic)? Why is this the proper
> type of RFC? Do all Datatracker state attributes correctly reflect
> this intent?
The document targets publication on the Standards Track. This is
appropriate for a protocol specification with IANA code point
assignments.
All fields are correctly set.
> 12. Have reasonable efforts been made to remind all authors of the
> intellectual property rights (IPR) disclosure obligations
> described in BCP 79? To the best of your knowledge, have all
> required disclosures been filed? If not, explain why. If yes,
> summarize any relevant discussion, including links to publicly-
> available messages when applicable.
There was an IPR poll on the MPLS list rooted at
https://mailarchive.ietf.org/arch/msg/mpls/XFonf-xqBuF_lh0xU88eZvYNGAc/
All authors and contributors responded (although several were in a
separate thread).
There are 5 IPR disclosures against individual I-Ds that were replaced
by the working group draft. All were notified to the list and none
caused any debate.
> 13. Has each author, editor, and contributor shown their willingness
> to be listed as such? If the total number of authors and editors
> on the front page is greater than five, please provide a
> justification.
By their responses to the IPR poll, we can assume that all authors and
contributors acknowledge their roles.
> 14. Document any remaining I-D nits in this document. Simply running
> the idnits tool is not enough; please review the "Content
> Guidelines" on authors.ietf.org. (Also note that the current
> idnits tool generates some incorrect warnings; a rewrite is
> underway.)
No nits other than those flagged in the shepherd review.
> 15. Should any informative references be normative or vice-versa? See
> the IESG Statement on Normative and Informative References.
The balance of references seems good.
> 16. List any normative references that are not freely available to
> anyone. Did the community have sufficient access to review any
> such normative references?
All normative references are from the IETF.
> 17. Are there any normative downward references (see RFC 3967 and BCP
> 97) that are not already listed in the DOWNREF registry? If so,
> list them.
None such.
There is a downref to 9789 which is already in the registry.
> 18. Are there normative references to documents that are not ready to
> be submitted to the IESG for publication or are otherwise in an
> unclear state? If so, what is the plan for their completion?
There is a normative reference to [I-D.ietf-mpls-mna-ps-hdr]. That
document is already on the RFC Editor Queue.
> 19. Will publication of this document change the status of any
> existing RFCs? If so, does the Datatracker metadata correctly
> reflect this and are those RFCs listed on the title page, in the
> abstract, and discussed in the introduction? If not, explain why
> and point to the part of the document where the relationship of
> this document to these other RFCs is discussed.
No status changes.
> 20. 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 aspects of the document
> requiring IANA assignments are associated with the appropriate
> reservations in IANA registries. Confirm that any referenced IANA
> registries have been clearly identified. Confirm that each newly
> created IANA registry specifies its initial contents, allocations
> procedures, and a reasonable name (see RFC 8126).
The IANA section is simple and clear. New assignments are requested from
a registry that is being created by [I-D.ietf-mpls-mna-ps-hdr] and so
there is no baseline registry to check against (yet), but the requests
are consistent with that I-D.
> 21. List any new IANA registries that require Designated Expert Review
> for future allocations. Are the instructions to the Designated
> Expert clear? Please include suggestions of designated experts, if
> appropriate.
No new registries.