Network Service Header (NSH) Encapsulation for In Situ OAM (IOAM) Data
draft-ietf-sfc-ioam-nsh-13

[Ballot comment]
I believe that the Security Considerations section is very underspecified - simply saying that "operators need to properly secure the IOAM domain to avoid malicious configuration" feels like it is sidestepping the issues / absolving itself of responsibility.

[Ballot comment]
I support Jim's and Roman's DISCUSS positions.

Thanks for a well done shepherd writeup.  I note that the writeup advises notifying IPPM of this work.  Was that done?

Section 2 defines "SFC", but the document doesn't actually use that term anywhere.

[Ballot discuss]
Hi,

Thanks for this document.

A couple of discuss points that I raised only because I find the spec to be unclear which should be be easy to clarify:

(1) p 2, sec 3.  IOAM encapsulation with NSH

                                                      The operator MUST
  ensure that all nodes along the service path support IOAM.

Is it actually 'all nodes along the service path' or "SFC aware nodes along the service path" that MUST support IOAM?


(2) p 3, sec 3.  IOAM encapsulation with NSH

      IOAM HDR Len:  8 bit Length field contains the length of the IOAM
        header in 4-octet units.

Does this mean quantized to 4 byte units, or that the actual length in bytes is 4 * "Hdr Len" field?

[Ballot comment]
(3) p 2, sec 3.  IOAM encapsulation with NSH

    Otherwise
  packets with IOAM are likely to be dropped per [RFC8300].  There can
  be multiple IOAM headers added by encapsulating nodes as configured.

Possibly "MAY" may be better than "can", since RFC 2119 language is being used elsewhere in this paragraph.

Also thanks to Susan Hares for the OPSDIR review.

Regards,
Rob

[Ballot discuss]
Thank you for the work put into this document.

Please find below one blocking DISCUSS points (easy to address), some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits.

Special thanks to Greg Mirsky for the shepherd's detailed write-up including the WG consensus ***and*** the justification of the intended status.

I hope that this review helps to improve the document,

Regards,

-éric


# DISCUSS (blocking)

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is just a request to have a discussion on the following topics:

## Section 3

This is probably due to my lack of knowledge about NSH... So, a simple discussion over email will probably be enough to clear my DISCUSS points.

RFC 9197 has an incremental tracing (section 4.4.1), how does it impact the length of the IOAM header in this case? Assuming that this header size is increased, I suggest to add some text about increasing the length field of IOAM header.

`When a packet with IOAM is received at an NSH based forwarding node such as an Service Function Forwarder (SFF) that does not understand IOAM header, it SHOULD drop the packet.` is actually a copy of RFC 8300 ```  Packets with Next Protocol values not supported SHOULD be silently dropped
      by default, although an implementation MAY provide a configuration
      parameter to forward them. ```
and not a new behaviour. So, let's rather be clear and use a structure like "Per section 2.2 of RFC 8300, ..." followed by the RFC 8300 text. While very similar to Jim Guichard's DISCUSS point, it is related to another part of the document.

[Ballot comment]

# COMMENTS (non-blocking)

## Section 1

Please expand SFF at first use.

## Section 3

Please expand ESP (is it IPsec ESP ?) in the packet format.

Should there be text about the absence of padding in the "IOAM Option and Optional Data Space" field (assuming that all IOAM options are always in 32-bit units)?

## Section 4

`IANA is requested to allocate protocol numbers for the following "NSH Next Protocol" related to IOAM` is underspecified. If it is about https://www.iana.org/assignments/nsh/nsh.xhtml#next-protocol, then let's be clear.

Note: I intended to DISCUSS this point, but as Jim is already holding a DISCUSS on the same point, I will let him to be the owner.

# NITS (non-blocking / cosmetic)

A couple of missing hypens in "open source" or "8 bit field".

[Ballot comment]
# John Scudder, RTG AD, comments for draft-ietf-sfc-ioam-nsh-11
CC @jgscudder

Thanks for this document. I have a few brief comments.

## COMMENTS

### Section 1, implementation

"An implementation of IOAM which leverages NSH to carry the IOAM data is available from the FD.io open source software project [FD.io]."

- Is it appropriate to include this here? If you wanted to flag this for reviewers' and WG's information, maybe following the practice recommended in RFC 7942 would be better? That document makes the case (Section 2) for not leaving it in the RFC:

  Since this information is necessarily time dependent, it is
  inappropriate for inclusion in a published RFC.

- The contradiction with the shepherd writeup is a little concerning: "Although no implementations have been reported..." The shepherd writeup was last updated in July of 2022 but the draft text appears to have been present since the 01 version published March 11, 2019.

### Section 3, header length

Perhaps in "IOAM HDR Len: 8 bit Length field contains the length of the IOAM header in 4-octet units", mention that the length covers the type and length fields? I think this is already implicit in what you've written, but better explicit than implicit.

### Section 5, "several operators"

I support Roman Danyliw's DISCUSS.

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues.

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments

[Ballot discuss]
(revised ballot)

** Section 5.
  IOAM is considered a "per domain" feature, where one or several
  operators decide on leveraging and configuring IOAM according to
  their needs.

This seems like an an expansion of the applicability statement of IOAM.  I don’t see reference to multiple operators in Section 3 of RFC9197.  Please explicitly cite the RFC9197 applicability statement to be clear that scope is not being expanded and and consider if discussion of multiple operators is needed.

[Ballot comment]
I support Jim Guichard's DISCUSS position on clarifying Section 3's text: "[t]he operator MUST ensure that all nodes along the service path support IOAM.  Otherwise  packets with IOAM are likely to be dropped per [RFC8300]."

** Section 5. Wrong reference. (Same observation as Jim)

  For additional IOAM
  related security considerations, see Section 10 in [RFC9197].

s/see Section 10/see Section 9/.

[Ballot comment]
I support Jim Guichard's DISCUSS position on clarifying Section 3's text: "[t]he operator MUST ensure that all nodes along the service path support IOAM.  Otherwise  packets with IOAM are likely to be dropped per [RFC8300]."

** Section 5.
  IOAM is considered a "per domain" feature, where one or several
  operators decide on leveraging and configuring IOAM according to
  their needs.

Is this an expansion of the applicability statement of IOAM?  I don’t see reference to multiple operators in Section 3 of RFC9197.  Consider explicitly citing this section.

** Section 5. Wrong reference. (Same observation as Jim)

  For additional IOAM
  related security considerations, see Section 10 in [RFC9197].

s/see Section 10/see Section 9/.

[Ballot comment]

General comment. There are several typos or grammatical errors in the document. Suggest running an error checker against the document.

Section 1: "In-situ OAM (IOAM)" in the first sentence does not need to be expanded as the authors already did so in the abstract.

Section 1: "Service Function Chaining (SFC) [RFC7665]" should read "Service Function Chaining (SFC) Architecture [RFC7665]".

Section 3: 6th sentence use of "service path" should probably be changed to the correct terminology used by the SFC architecture which is Service Function Path (SFP). Further, the next sentence should be folded into the 6th sentence as a single sentence to make it more readable.

Section 3: "See [I-D.ietf-ippm-ioam-deployment] for a discussion of deployment related aspects of IOAM-Data-fields.". This reference should be changed to [RFC9378].

Section 3: "[I-D.ietf-ippm-ioam-flags]". This reference should be changed to [RFC9322].

Several outdated references need to be updated:

  == Outdated reference: A later version (-03) exists of
    draft-ietf-sfc-oam-packet-01

  == Outdated reference: draft-ietf-ippm-ioam-deployment has been published
    as RFC 9378

  == Outdated reference: draft-ietf-ippm-ioam-direct-export has been
    published as RFC 9326

  == Outdated reference: draft-ietf-ippm-ioam-flags has been published as RFC
    9322

[Ballot comment]

General comment. There are several typos or grammatical errors in the document. Suggest running an error checker against the document.
Section 1: "In-situ OAM (IOAM)" in the first sentence does not need to be expanded as the authors already did so in the abstract.
Section 1: "Service Function Chaining (SFC) [RFC7665]" should read "Service Function Chaining (SFC) Architecture [RFC7665]".
Section 3: 6th sentence use of "service path" should probably be changed to the correct terminology used by the SFC architecture which is Service Function Path (SFP). Further, the next sentence should be folded into the 6th sentence as a single sentence to make it more readable.
Section 3: "See [I-D.ietf-ippm-ioam-deployment] for a discussion of deployment related aspects of IOAM-Data-fields.". This reference should be changed to [RFC9378].
Section 3: "[I-D.ietf-ippm-ioam-flags]". This reference should be changed to [RFC9322].

Several outdated references need to be updated:

  == Outdated reference: A later version (-03) exists of
    draft-ietf-sfc-oam-packet-01

  == Outdated reference: draft-ietf-ippm-ioam-deployment has been published
    as RFC 9378

  == Outdated reference: draft-ietf-ippm-ioam-direct-export has been
    published as RFC 9326

  == Outdated reference: draft-ietf-ippm-ioam-flags has been published as RFC
    9322

[Ballot discuss]
- Section 3:
  The IOAM-Data-Fields MUST follow the definitions corresponding to
  IOAM-Option-Types (e.g., see Section 5 of [RFC9197] and Section 3.2
  of [I-D.ietf-ippm-ioam-direct-export])

The above reference to RFC9197 is incorrect although a simple fix. The IOAM-Option-Types are defined in Section 4 of that document not Section 5. Adding a DISCUSS as this reference is important enough to not just be a comment. Note that the same incorrect reference is used later on in Section 3 and must be corrected also.

- Section 3:
  The operator MUST ensure that all nodes along the service path support IOAM.  Otherwise
  packets with IOAM are likely to be dropped per [RFC8300].

This text needs clarification as RFC8300 says nothing about IOAM specifically and dropping of OAM packets is discussed in that RFC here -> https://www.rfc-editor.org/rfc/rfc8300#:~:text=O%20bit%3A%20%20Setting,disabled%20by%20default. The authors should clarify exactly what they mean by the above text and clarify what specifically in RFC8300 would cause packets to be dropped if a node does not support IOAM.

- IANA Considerations:
The text says "IANA is requested to allocate protocol numbers for the following "NSH Next Protocol" related to IOAM" but there is no reference to the correct registry. NSH Next Protocol allocations can be found here:
https://www.iana.org/assignments/nsh/nsh.xhtml#next-protocol and they are part of the Network Service Header (NSH) Parameters registry. Please provide an accurate reference to the Network Service Header (NSH) Parameters registry for IANA.

- Section 5: Another incorrect reference needs to be corrected. "For additional IOAM related security considerations, see Section 10 in [RFC9197].". It is actually section 9 of that RFC so please correct the reference.

[Ballot comment]

General comment. There are several typos or grammatical errors in the document. Suggest running an error checker against the document.

- Section 1: "In-situ OAM (IOAM)" in the first sentence does not need to be expanded as the authors already did so in the abstract.
- Section 1: "Service Function Chaining (SFC) [RFC7665]" should read "Service Function Chaining (SFC) Architecture [RFC7665]".
- Section 3: 6th sentence use of "service path" should probably be changed to the correct terminology used by the SFC architecture which is Service Function Path (SFP). Further, the next sentence should be folded into the 6th sentence as a single sentence to make it more readable.
- Section 3: "See [I-D.ietf-ippm-ioam-deployment] for a discussion of deployment related aspects of IOAM-Data-fields.". This reference should be changed to [RFC9378].
- Section 3: "[I-D.ietf-ippm-ioam-flags]". This reference should be changed to [RFC9322].

Several outdated references need to be updated:

  == Outdated reference: A later version (-03) exists of
    draft-ietf-sfc-oam-packet-01

  == Outdated reference: draft-ietf-ippm-ioam-deployment has been published
    as RFC 9378

  == Outdated reference: draft-ietf-ippm-ioam-direct-export has been
    published as RFC 9326

  == Outdated reference: draft-ietf-ippm-ioam-flags has been published as RFC
    9322

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

The IANA Functions Operator has completed its review of draft-ietf-sfc-ioam-nsh-11. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document.

The IANA Functions Operator understands that, upon approval of this document, there is a single action which we must complete.

In the NSH Next Protocol registry on the Network Service Header (NSH) Parameters registry page located at:

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

a single new registration is to be made as follows:

Next Protocol: [ TBD-at-Registration ]
Description:
Reference: [ RFC-to-be ]

IANA Question --> What is the description to be used with this registration? TBD_IOAM appears to be a placeholder for a future, edited version of the draft.

As this document requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

The IANA Functions Operator understands that this is the only action 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.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Specialist

The following Last Call announcement was sent out (ends 2023-04-18):

From: The IESG
To: IETF-Announce
CC: andrew-ietf@liquid.tech, draft-ietf-sfc-ioam-nsh@ietf.org, gregory.mirsky@ericsson.com, sfc-chairs@ietf.org, sfc@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Network Service Header (NSH) Encapsulation for In-situ OAM (IOAM) Data) to Proposed Standard


The IESG has received a request from the Service Function Chaining WG (sfc)
to consider the following document: - 'Network Service Header (NSH)
Encapsulation for In-situ OAM (IOAM) Data'
  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
last-call@ietf.org mailing lists by 2023-04-18. 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


  In-situ Operations, Administration, and Maintenance (IOAM) is used
  for recording and collecting operational and telemetry information
  while the packet traverses a path between two points in the network.
  This document outlines how IOAM data fields are encapsulated with the
  Network Service Header (NSH).




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/


The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/3527/

# Document Shepherd Writeup

*This version is dated 8 July 2022.*

## 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?
The WG consensus represents the strong concurrence among all active participants of the SFC WG.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?
There were no controversial points brought up in the course of discussing this document by the SFC WG.

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, no one objected to adopting the draft by the WG (WG AP), nor to the decision to publish it (WG LC).

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][3] recommends) or elsewhere
  (where)?
Although no implementations have been reported, several proponents indicated considerations to support IOAM in NSH.

### Additional Reviews

5. Does this document need review from other IETF working groups or external
  organizations? Have those reviews occurred?
Notifying the IPPM WG seems like a reasonable step.

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.
None of the abovementioned formal reviews is required to progress this document.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] 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][5]?
The document doesn't include the YANG module.

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.
None required.

### 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 document is clearly written, easy to read, and based on pragmatic engineering practices.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. Do any such issues remain that would merit specific
    attention from subsequent reviews?
I believe that all the listed common issues are reasonably addressed in the latest version of the document.

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 intended publication is as Proposed Standard. That is the proper type of RFC as the document defines encapsulation that affects the NSH data plane.

12. Has the interested community confirmed that any and all appropriate IPR
    disclosures required by [BCP 78][7] and [BCP 79][8] have been filed? If not,
    explain why. If yes, summarize any discussion and conclusion regarding the
    intellectual property rights (IPR) disclosures, including links to relevant
    emails.
The IPR disclosure was properly filed https://datatracker.ietf.org/ipr/3527/.
All authors responded to the IPR inquiry stating that they are not aware of any IPR other than already disclosed. https://mailarchive.ietf.org/arch/browse/sfc/?gbt=1&index=dPQBjkIrquNrUiBTN9lnmUTrXew. The same statement was made by the following contributors: Vengada Prasad Govindan, Hannes Gredler, John Leddy, Stephen Youell, Tal Mizrahi, Carlos Pignataro, and David Mozes. Two contributors have not responded: Petr Lapukhov and Remy Chang. Note that the email for Remy Chang is missing.

13. Has each Author or Contributor confirmed their willingness to be listed as
    such? If the number of Authors/Editors on the front page is greater than 5,
    please provide a justification.
All Authors and Contributors agreed to be listed accordingly.

14. Identify any remaining I-D nits in this document. (See [the idnits tool][9]
    and the checkbox items found in Guidelines to Authors of Internet-Drafts).
    Simply running the idnits tool is not enough; please review the entire
    guidelines document.
Reference to draft-ietf-ippm-ioam-data must be updated to RFC 9197.

15. Should any informative references be normative or vice-versa?
All references are used appropriately.

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 in the open access.

17. Are there any normative downward references (see [RFC 3967][10],
    [BCP 97][11])? If so, list them.
No downrefs in the document.

18. Are there normative references to documents that are not ready for
    advancement or are otherwise in an unclear state? If they exist, what is the
    plan for their completion?
draft-ietf-sfc-oam-packet in the "Submitted to IESG for Publication" state.

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.
The publication of this document would not change the status of any existing RFC.

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][12]).
All actions requested in the IAN Considerations section of this document are clearly explained and properly attributed to existing IANA registries.

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 IANA registries are requested.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp78
[8]: https://www.rfc-editor.org/info/bcp79
[9]: https://www.ietf.org/tools/idnits/
[10]: https://www.rfc-editor.org/rfc/rfc3967.html
[11]: https://www.rfc-editor.org/info/bcp97
[12]: https://www.rfc-editor.org/rfc/rfc8126.html

# Document Shepherd Writeup

*This version is dated 8 July 2022.*

## 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?
The WG consensus represents the strong concurrence among all active participants of the SFC WG.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?
There were no controversial points brought up in the course of discussing this document by the SFC WG.

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, no one objected to adopting the draft by the WG (WG AP), nor to the decision to publish it (WG LC).

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][3] recommends) or elsewhere
  (where)?
Although no implementations have been reported, several proponents indicated considerations to support IOAM in NSH.

### Additional Reviews

5. Does this document need review from other IETF working groups or external
  organizations? Have those reviews occurred?
Notifying the IPPM WG seems like a reasonable step.

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.
None of the abovementioned formal reviews is required to progress this document.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] 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][5]?
The document doesn't include the YANG module.

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.
None required.

### 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 document is clearly written, easy to read, and based on pragmatic engineering practices.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. Do any such issues remain that would merit specific
    attention from subsequent reviews?
I believe that all the listed common issues are reasonably addressed in the latest version of the document.

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 intended publication is as Proposed Standard. That is the proper type of RFC as the document defines encapsulation that affects the NSH data plane.

12. Has the interested community confirmed that any and all appropriate IPR
    disclosures required by [BCP 78][7] and [BCP 79][8] have been filed? If not,
    explain why. If yes, summarize any discussion and conclusion regarding the
    intellectual property rights (IPR) disclosures, including links to relevant
    emails.
The IPR disclosure was properly filed https://datatracker.ietf.org/ipr/3527/.
All authors responded to the IPR inquiry stating that they are not aware of any IPR other than already disclosed. https://mailarchive.ietf.org/arch/browse/sfc/?gbt=1&index=dPQBjkIrquNrUiBTN9lnmUTrXew. The same statement was made by the following contributors: Vengada Prasad Govindan, Hannes Gredler, John Leddy, Stephen Youell, Tal Mizrahi, and Carlos Pignataro. Several contributors have not responded: David Mozes, Petr Lapukhov, and Remy Chang. Note that the email for Remy Chang is missing.

13. Has each Author or Contributor confirmed their willingness to be listed as
    such? If the number of Authors/Editors on the front page is greater than 5,
    please provide a justification.
All Authors and Contributors agreed to be listed accordingly.

14. Identify any remaining I-D nits in this document. (See [the idnits tool][9]
    and the checkbox items found in Guidelines to Authors of Internet-Drafts).
    Simply running the idnits tool is not enough; please review the entire
    guidelines document.
Reference to draft-ietf-ippm-ioam-data must be updated to RFC 9197.

15. Should any informative references be normative or vice-versa?
All references are used appropriately.

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 in the open access.

17. Are there any normative downward references (see [RFC 3967][10],
    [BCP 97][11])? If so, list them.
No downrefs in the document.

18. Are there normative references to documents that are not ready for
    advancement or are otherwise in an unclear state? If they exist, what is the
    plan for their completion?
draft-ietf-sfc-oam-packet in the "Submitted to IESG for Publication" state.

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.
The publication of this document would not change the status of any existing RFC.

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][12]).
All actions requested in the IAN Considerations section of this document are clearly explained and properly attributed to existing IANA registries.

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 IANA registries are requested.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp78
[8]: https://www.rfc-editor.org/info/bcp79
[9]: https://www.ietf.org/tools/idnits/
[10]: https://www.rfc-editor.org/rfc/rfc3967.html
[11]: https://www.rfc-editor.org/info/bcp97
[12]: https://www.rfc-editor.org/rfc/rfc8126.html

# Document Shepherd Writeup

*This version is dated 8 July 2022.*

## 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?
The WG consensus represents the strong concurrence among all active participants of the SFC WG.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?
There were no controversial points brought up in the course of discussing this document by the SFC WG.

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, no one objected to adopting the draft by the WG (WG AP), nor to the decision to publish it (WG LC).

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][3] recommends) or elsewhere
  (where)?
Although no implementations have been reported, several proponents indicated considerations to support IOAM in NSH.

### Additional Reviews

5. Does this document need review from other IETF working groups or external
  organizations? Have those reviews occurred?
Notifying the IPPM WG seems like a reasonable step.

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.
None of the abovementioned formal reviews is required to progress this document.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] 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][5]?
The document doesn't include the YANG module.

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.
None required.

### 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 document is clearly written, easy to read, and based on pragmatic engineering practices.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. Do any such issues remain that would merit specific
    attention from subsequent reviews?
I believe that all the listed common issues are reasonably addressed in the latest version of the document.

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 intended publication is as Proposed Standard. That is the proper type of RFC as the document defines encapsulation that affects the NSH data plane.

12. Has the interested community confirmed that any and all appropriate IPR
    disclosures required by [BCP 78][7] and [BCP 79][8] have been filed? If not,
    explain why. If yes, summarize any discussion and conclusion regarding the
    intellectual property rights (IPR) disclosures, including links to relevant
    emails.
The IPR disclosure was properly filed https://datatracker.ietf.org/ipr/3527/.
All authors responded to the IPR inquiry stating that they are not aware of any IPR other than already disclosed. https://mailarchive.ietf.org/arch/browse/sfc/?gbt=1&index=dPQBjkIrquNrUiBTN9lnmUTrXew. The same statement was made by the following contributors: Vengada Prasad Govindan, Hannes Gredler, John Leddy, Stephen Youell, Tal Mizrahi. Several contributors have not responded: Carlos Pignataro, David Mozes, Petr Lapukhov, and Remy Chang. Note that the email for Remy Chang is missing.

13. Has each Author or Contributor confirmed their willingness to be listed as
    such? If the number of Authors/Editors on the front page is greater than 5,
    please provide a justification.
All Authors and Contributors agreed to be listed accordingly.

14. Identify any remaining I-D nits in this document. (See [the idnits tool][9]
    and the checkbox items found in Guidelines to Authors of Internet-Drafts).
    Simply running the idnits tool is not enough; please review the entire
    guidelines document.
Reference to draft-ietf-ippm-ioam-data must be updated to RFC 9197.

15. Should any informative references be normative or vice-versa?
All references are used appropriately.

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 in the open access.

17. Are there any normative downward references (see [RFC 3967][10],
    [BCP 97][11])? If so, list them.
No downrefs in the document.

18. Are there normative references to documents that are not ready for
    advancement or are otherwise in an unclear state? If they exist, what is the
    plan for their completion?
draft-ietf-sfc-oam-packet in the "Submitted to IESG for Publication" state.

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.
The publication of this document would not change the status of any existing RFC.

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][12]).
All actions requested in the IAN Considerations section of this document are clearly explained and properly attributed to existing IANA registries.

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 IANA registries are requested.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp78
[8]: https://www.rfc-editor.org/info/bcp79
[9]: https://www.ietf.org/tools/idnits/
[10]: https://www.rfc-editor.org/rfc/rfc3967.html
[11]: https://www.rfc-editor.org/info/bcp97
[12]: https://www.rfc-editor.org/rfc/rfc8126.html

# Document Shepherd Writeup

*This version is dated 8 July 2022.*

## 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?
The WG consensus represents the strong concurrence among all active participants of the SFC WG.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?
There were no controversial points brought up in the course of discussing this document by the SFC WG.

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, no one objected to adopting the draft by the WG (WG AP), nor to the decision to publish it (WG LC).

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][3] recommends) or elsewhere
  (where)?
Although no implementations have been reported, several proponents indicated considerations to support IOAM in NSH.

### Additional Reviews

5. Does this document need review from other IETF working groups or external
  organizations? Have those reviews occurred?
Notifying the IPPM WG seems like a reasonable step.

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.
None of the abovementioned formal reviews is required to progress this document.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] 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][5]?
The document doesn't include the YANG module.

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.
None required.

### 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 document is clearly written, easy to read, and based on pragmatic engineering practices.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. Do any such issues remain that would merit specific
    attention from subsequent reviews?
I believe that all the listed common issues are reasonably addressed in the latest version of the document.

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 intended publication is as Proposed Standard. That is the proper type of RFC as the document defines encapsulation that affects the NSH data plane.

12. Has the interested community confirmed that any and all appropriate IPR
    disclosures required by [BCP 78][7] and [BCP 79][8] have been filed? If not,
    explain why. If yes, summarize any discussion and conclusion regarding the
    intellectual property rights (IPR) disclosures, including links to relevant
    emails.
The IPR disclosure was properly filed https://datatracker.ietf.org/ipr/3527/.
All authors responded to the IPR inquiry stating that they are not aware of any IPR other than already disclosed. https://mailarchive.ietf.org/arch/browse/sfc/?gbt=1&index=dPQBjkIrquNrUiBTN9lnmUTrXew. The same statement was made by the following contributors: Vengada Prasad Govindan, Hannes Gredler, John Leddy, Stephen Youell, Tal Mizrahi. Several contributors have not responded: Carlos Pignataro, David Mozes, Petr Lapukhov, and Remy Chang. Note that the email for Remy Chang is missing.

13. Has each Author or Contributor confirmed their willingness to be listed as
    such? If the number of Authors/Editors on the front page is greater than 5,
    please provide a justification.
All Authors and Contributors agreed to be listed accordingly.

14. Identify any remaining I-D nits in this document. (See [the idnits tool][9]
    and the checkbox items found in Guidelines to Authors of Internet-Drafts).
    Simply running the idnits tool is not enough; please review the entire
    guidelines document.
Reference to draft-ietf-ippm-ioam-data must be updated to RFC 9197.

15. Should any informative references be normative or vice-versa?
All references are used appropriately.

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 in the open access.

17. Are there any normative downward references (see [RFC 3967][10],
    [BCP 97][11])? If so, list them.
No downrefs in the document.

18. Are there normative references to documents that are not ready for
    advancement or are otherwise in an unclear state? If they exist, what is the
    plan for their completion?
draft-ietf-sfc-oam-packet in the "Submitted to IESG for Publication" state.

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.
The publication of this document would not change the status of any existing RFC.

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][12]).
All actions requested in the IAN Considerations section of this document are clearly explained and properly attributed to existing IANA registries.

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 IANA registries are requested.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp78
[8]: https://www.rfc-editor.org/info/bcp79
[9]: https://www.ietf.org/tools/idnits/
[10]: https://www.rfc-editor.org/rfc/rfc3967.html
[11]: https://www.rfc-editor.org/info/bcp97
[12]: https://www.rfc-editor.org/rfc/rfc8126.html

# Document Shepherd Writeup

*This version is dated 5 July 2022.*

## 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?
The WG consensus represents the strong concurrence among all active participants of the SFC WG.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?
There were no controversial points brought up in the course of discussing this document by the SFC WG.

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, no one objected to adopting the draft by the WG (WG AP), nor to the decision to publish it (WG LC).

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][3] recommends) or elsewhere
  (where)?
Although no implementations have been reported, several proponents indicated considerations to support IOAM in NSH.

### Additional Reviews

5. Does this document need review from other IETF working groups or external
  organizations? Have those reviews occurred?
Notifying the IPPM WG seems like a reasonable step.

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.
None of the abovementioned formal reviews is required to progress this document.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] 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][5]?
The document doesn't include the YANG module.

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.
None required.

### 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 document is clearly written, easy to read, and based on pragmatic engineering practices.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. Do any such issues remain that would merit specific
    attention from subsequent reviews?
I believe that all the listed common issues are reasonably addressed in the latest version of the document.

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 intended publication is as Proposed Standard. That is the proper type of RFC as the document defines encapsulation that affects the NSH data plane.

12. Has the interested community confirmed that any and all appropriate IPR
    disclosures required by [BCP 78][7] and [BCP 79][8] have been filed? If not,
    explain why. If yes, summarize any discussion and conclusion regarding the
    intellectual property rights (IPR) disclosures, including links to relevant
    emails.
The IPR disclosure was properly filed https://datatracker.ietf.org/ipr/3527/.
Most authors and contributors responded to the IPR inquiry https://mailarchive.ietf.org/arch/browse/sfc/?gbt=1&index=dPQBjkIrquNrUiBTN9lnmUTrXew. Waiting for replies from Carlos Pignataro, David Mozes, Petr Lapukhov, and Remy Chang. Note that the email for Remy Chang is missing.

13. Has each Author or Contributor confirmed their willingness to be listed as
    such? If the number of Authors/Editors on the front page is greater than 5,
    please provide a justification.
All Authors and Contributors agreed to be listed accordingly.

14. Identify any remaining I-D nits in this document. (See [the idnits tool][9]
    and the checkbox items found in Guidelines to Authors of Internet-Drafts).
    Simply running the idnits tool is not enough; please review the entire
    guidelines document.
Reference to draft-ietf-ippm-ioam-data must be updated to RFC 9197.

15. Should any informative references be normative or vice-versa?
All references are used appropriately.

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 in the open access.

17. Are there any normative downward references (see [RFC 3967][10],
    [BCP 97][11])? If so, list them.
No downrefs in the document.

18. Are there normative references to documents that are not ready for
    advancement or are otherwise in an unclear state? If they exist, what is the
    plan for their completion?
draft-ietf-sfc-oam-packet in the "Submitted to IESG for Publication" state.

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.
The publication of this document would not change the status of any existing RFC.

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][12]).
All actions requested in the IAN Considerations section of this document are clearly explained and properly attributed to existing IANA registries.

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 IANA registries are requested.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp78
[8]: https://www.rfc-editor.org/info/bcp79
[9]: https://www.ietf.org/tools/idnits/
[10]: https://www.rfc-editor.org/rfc/rfc3967.html
[11]: https://www.rfc-editor.org/info/bcp97
[12]: https://www.rfc-editor.org/rfc/rfc8126.html

Request for posting confirmation emailed to previous authors: Frank Brockners , sfc-chairs@ietf.org, Vengada Govindan , Tal Mizrahi , John Leddy , Petr Lapukhov , Carlos Pignataro , Shwetha Bhandari , Hannes Gredler , Stephen Youell , David Mozes , Remy Chang

Request for posting confirmation emailed to previous authors: Frank Brockners , sfc-chairs@ietf.org, Tal Mizrahi , Vengada Govindan , John Leddy , Petr Lapukhov , Carlos Pignataro , Shwetha Bhandari , Hannes Gredler , Stephen Youell , David Mozes , Remy Chang

Request for posting confirmation emailed  to submitter and authors: Frank Brockners , Tal Mizrahi , Vengada Govindan , John Leddy , Petr Lapukhov , Carlos Pignataro , Shwetha Bhandari , Hannes Gredler , Stephen Youell , David Mozes