MPLS Network Actions for In Situ Operations, Administration, and Maintenance
draft-ietf-mpls-mna-ioam-14

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.

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.