Echo Request/Reply for Enabled In Situ OAM (IOAM) Capabilities
draft-ietf-ippm-ioam-conf-state-10

[Ballot comment]
Thanks for the revisions. I have one further comment that occurred to me
in looking at the revised text:

                                                Note that since the
  Default-Namespace-ID of 0x0000 is mandated to appear first in the
  list, if it appears any trailing 0x0000 octets must therefore be
  padding and MUST be disregarded.
 
it seems to me it can be tightened up a little more, as in

  Since the Default-Namespace-ID of 0x0000 is mandated to appear first in
  the list, any other occurrences of 0x0000 MUST be disregarded.
 
That is, unless you want to mandate some kind of error response to
0x0000 appearing in a non-first, non-trailing position.

[Ballot comment]
I think the two IANA registries being created in this document are under-specified.  I suggest enumerating the fields in each entry, describing what they're for, and what their valid values are, before providing the initial values.  As it stands, IANA has to read other parts of the document to infer valid values for the first column in both cases.

I also concur with Lars' point about the limited set of available values in each registry, but I see the latest version dealt with that.

[Ballot comment]
Thank you for your reply, addressing my DISCUSS (https://mailarchive.ietf.org/arch/msg/ippm/93f6B7Xb3zwj-WVqhe_ygbhAjKk/)

I am still concerned about what feels like an increase in things like filtering requirements in documents, and what is actually implementable on network devices - see https://mailarchive.ietf.org/arch/msg/ippm/1qNDrh-AiYY4a17KEqn2bEWNfLI/ for more background. I understand that it is not feasible to stop developing new protocols until all routers support $whatever, but it is still a topic which causes my discomfort.

However, this is a larger issue than just this document, and so I've cleared my DISCUSS and changed to NoObjection...

Thank you again for addressing my ballot, and doing it so quickly.

[Ballot comment]
# Internet AD comments for draft-ietf-ippm-ioam-conf-state-07
CC @ekline

I support John's request for clarification.

## Comments

### S3.1

* "MUST send an echo reply without IOAM capabilities or no echo reply"

  I think I understand the intent, and overall I think this text is likely
  to not be an issue in practice.  But I'll note that anything "MUST" where
  ICMP is concerned may not exactly be enforceable.

## Nits

### S2.2

* Maybe consider adding DEX to this list (it's also fully expanded on first
  use in S1, but it might be nice for ease of reference).

### S3.1, S3.2

* /depends on the specific environment it is applied at/ ->
  /depends on the specific deployment environment/ maybe?

[Ballot discuss]
Hi,

I support Roman and Warren's discuss, and again, I have a similar, but slightly separate concern:

(1) p 14, sec 6.  Security Considerations

  To protect against unauthorized sources using echo request messages
  to obtain IOAM Capabilities information, it is RECOMMENDED that
  implementations provide a means of checking the source addresses of
  echo request messages against an access list before accepting the
  message.

I'm concerned that performing a source address filtering isn't necessarily that secure, compared with use NETCONF or RESTCONF that can provide AAA access controls.  Hence, I think that the security considerations should REQUIRE that IOAM daemons do not respond to these capability requests unless explicitly configured to do so, specifically to avoid implementations potentially leaking information if they are not aware of this functionality (e.g., if it was enabled by default).

[Ballot comment]
(2) p 2, sec 1.  Introduction

  *  When NETCONF/YANG is used in this scenario, each IOAM
      encapsulating node (including the host when it takes the role of
      an IOAM encapsulating node) needs to implement a NETCONF Client,
      each IOAM transit and IOAM decapsulating node (including the host
      when it takes the role of an IOAM decapsulating node) needs to
      implement a NETCONF Server, the complexity can be an issue.
      Furthermore, each IOAM encapsulating node needs to establish
      NETCONF Connection with each IOAM transit and IOAM decapsulating
      node, the scalability can be an issue.

Isn't it quite likely that the network devices in question has already implement NETCONF servers, and hence really the additional code would only be NETCONF client code.  There is also a separate option that RESTCONF could be used instead of NETCONF, which is a somewhat lighter protocol.  I believe that one big advantage to using NETCONF over these loopback mechanisms is that they are properly secure, and NACM can be used to limit access to the IOAM capabilities to only those devices/individuals which should be allowed to access the data.

Regards,
Rob

[Ballot comment]
# John Scudder, RTG AD, comments for draft-ietf-ippm-ioam-conf-state-07
CC @jgscudder

## COMMENTS

### Section 1

```
  Fate sharing is a common requirement for all kinds of active OAM
  packets, echo request is among them, in this document that means echo
  request is required to traverse a path of IOAM data packet.  This
  requirement can be achieved by, e.g., applying same explicit path or
  ECMP processing to both echo request and IOAM data packet.
```

Explicit path, yes, but it's known that you can't simply expect to "apply same ECMP processing" to two quite distinct packets, without carefully arranging for that to happen. If this is a requirement (and the paragraph says it is) then I think it's necessary to be clearer about how it's to be achieved.

### Section 3.1, Default-Namespace-ID

```
              A list of IOAM Namespace-IDs (one or more Namespace-IDs)
  MUST be included in this container in the echo request, and if
  present, the Default-Namespace-ID 0x0000 MUST be placed at the
  begining of the list of IOAM Namespace-IDs.  The IOAM encapsulating
  node requests only the enabled IOAM capabilities that match one of
  the Namespace-IDs.  The Namespace-ID has the same definition as
  what's specified in Section 4.3 of [RFC9197].
```

- You specify that if present 0x0000 must be placed at the beginning of the list. Is there any other sorting requirement on the list, or is that the only mandated ordering?

- It wasn't clear to me from a quick perusal of RFC 9197 §4.3 whether a request carrying 0x0000 would elicit replies for all Namespace-IDs (since 0x0000 matches everything) or if it would elicit replies only for capabilities that have no configured non-default namespace, or are explicitly configured with namespace 0x0000. Can you either clarify this in the text, or if you think it's clear from the reference, help me understand what makes it clear?

- If the first guess above is correct (0x0000 elicits replies for all Namespace-IDs) then it would seem that if the list contains 0x0000, it's pointless to include anything else in the list, and that might be worth pointing out in the text.

- If the first guess above is correct, that would also prompt comments on the use of Namespace-ID field in Sections 3.2.x, but we can address that if needed.

### Section 3.1, container format, padding

```
  The IOAM Capabilities Query Container has a container header that is
  used to identify the type and optionally length of the container
  payload, and the container payload (List of IOAM Namespace-IDs) is
  zero-padded to align to a 4-octet boundary.

  The length, structure, and definition of the IOAM Capabilities Query
  Container Header depends on the specific environment it is applied
  at.
```

I regret I'm not sufficiently familiar with all the different bearer protocols you're envisioning embedding this container in. So I'll just ask,

- Why is the length of the payload said to be optional, when it's a (presumably variable-length) list? Does this relate to a bearer protocol where the length of the list is inferred some other way, or what?

- The specification that the payload is zero-padded to 4-octet alignment carries some implications. Let's explore these with an example. Suppose we want to signal a single Namespace-ID, 0x0001. Then presumably the payload has to be 0x0001 0x0000, once the mandated pad bytes are added. Is the receiver supposed to know that it ignores the 0x0000 value (which is otherwise the Default-Namespace-ID) because it comes at the end of the list, not the beginning as the previous paragraph required? If so, this seems worth calling out. If not, how is the receiver supposed to know where payload ends and padding begins?

### Section 3.2, container format, padding

Similar questions to those above apply to:

```
  The IOAM Capabilities Response Container has a container header that
  is used to identify the type and optionally length of the container
  payload, and the container payload (List of IOAM Capabilities
  Objects) is zero-padded to align to a 4-octet boundary.
```

That is, considering you've disclaimed defining specifics about the semantics of the header, how is the recipient of one of these things supposed to know how to ignore the zero-padding?

I do see that all the objects you've defined in this document are a multiple of four bytes long (if we assume their unspecified headers are a multiple of four byte long, that is!) so no padding would ever be required for a payload consisting only of these objects, and thus my question wouldn't apply. But if that's the answer to my question, then the final clause I quote above (about zero-padding) should just be removed.

### Section 3.2, object format, padding

```
  Similar to the container, each object has an object header that is
  used to identify the type and length of the object payload, and the
  object payload is zero-padded to align to a 4-octet boundary.
```

Similar to the above, in some cases there will be a need to know how to separate payload from padding. In all the objects you defined in Sections 3.2.x this is unnecessary (*if* you assume the unspecified header is 4-octet aligned itself) since you've carefully specified them so that they don't require padding.

It might be more straightforward to just mandate that future object specifications have a length that is a multiple of four octets, as all of your current ones do. That defers the question of what to do about variable payloads to the specification of the -- notional? -- object that has such a payload.

### Section 4

You talk about TTL in the first paragraph. Do you mean "TTL or Hop Limit"?

### Section 6, integrity protection

You talk about integrity protection in passing. Let's assume a deployment hasn't enabled any kind of integrity protection. Have you done any analysis of what kind of mischief an attacker could cause by inserting incorrect capabilities in a forged response?

### Section 6, MBZ fields

You suggest checking the must-be-zero reserved fields and reporting an exception if they aren't zero. Often, such reserved fields are expected to be extended in future, and indeed this is what you indicate in this spec too. I guess since the packets terminate at the recipient of the reply, it's not terribly harmful to police that these be zero, but it would likely create an awfully noisy set of exceptions in the case of a partially rolled-out extension. Is this really a good recommendation? The more usual practice is of the form "must be zero on Tx, must be ignored on Rx".

## 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 comment]
# John Scudder, RTG AD, comments for draft-ietf-ippm-ioam-conf-state-07
CC @jgscudder

## COMMENTS

### Section 1

```
  Fate sharing is a common requirement for all kinds of active OAM
  packets, echo request is among them, in this document that means echo
  request is required to traverse a path of IOAM data packet.  This
  requirement can be achieved by, e.g., applying same explicit path or
  ECMP processing to both echo request and IOAM data packet.
```

Explicit path, yes, but it's known that you can't simply expect to "apply same ECMP processing" to two quite distinct packets, without carefully arranging for that to happen. If this is a requirement (and the paragraph says it is) then I think it's necessary to be clearer about how it's to be achieved.

### Section 3.1, Default-Namespace-ID

```
              A list of IOAM Namespace-IDs (one or more Namespace-IDs)
  MUST be included in this container in the echo request, and if
  present, the Default-Namespace-ID 0x0000 MUST be placed at the
  begining of the list of IOAM Namespace-IDs.  The IOAM encapsulating
  node requests only the enabled IOAM capabilities that match one of
  the Namespace-IDs.  The Namespace-ID has the same definition as
  what's specified in Section 4.3 of [RFC9197].
```

- You specify that if present 0x0000 must be placed at the beginning of the list. Is there any other sorting requirement on the list, or is that the only mandated ordering?

- It wasn't clear to me from a quick perusal of RFC 9197 §4.3 whether a request carrying 0x0000 would elicit replies for all Namespace-IDs (since 0x0000 matches everything) or if it would elicit replies only for capabilities that have no configured non-default namespace, or are explicitly configured with namespace 0x0000. Can you either clarify this in the text, or if you think it's clear from the reference, help me understand what makes it clear?

- If the first guess above is correct (0x0000 elicits replies for all Namespace-IDs) then it would seem that if the list contains 0x0000, it's pointless to include anything else in the list, and that might be worth pointing out in the text.

- If the first guess above is correct, that would also prompt comments on the use of Namespace-ID field in Sections 3.2.x, but we can address that if needed.

### Section 3.1, container format, padding

```
  The IOAM Capabilities Query Container has a container header that is
  used to identify the type and optionally length of the container
  payload, and the container payload (List of IOAM Namespace-IDs) is
  zero-padded to align to a 4-octet boundary.

  The length, structure, and definition of the IOAM Capabilities Query
  Container Header depends on the specific environment it is applied
  at.
```

I regret I'm not sufficiently familiar with all the different bearer protocols you're envisioning embedding this container in. So I'll just ask,

- Why is the length of the payload said to be optional, when it's a (presumably variable-length) list? Does this relate to a bearer protocol where the length of the list is inferred some other way, or what?

- The specification that the payload is zero-padded to 4-octet alignment carries some implications. Let's explore these with an example. Suppose we want to signal a single Namespace-ID, 0x0001. Then presumably the payload has to be 0x0001 0x0000, once the mandated pad bytes are added. Is the receiver supposed to know that it ignores the 0x0000 value (which is otherwise the Default-Namespace-ID) because it comes at the end of the list, not the beginning as the previous paragraph required? If so, this seems worth calling out. If not, how is the receiver supposed to know where payload ends and padding begins?

### Section 3.2, container format, padding

Similar questions to those above apply to:

```
  The IOAM Capabilities Response Container has a container header that
  is used to identify the type and optionally length of the container
  payload, and the container payload (List of IOAM Capabilities
  Objects) is zero-padded to align to a 4-octet boundary.
```

That is, considering you've disclaimed defining specifics about the semantics of the header, how is the recipient of one of these things supposed to know how to ignore the zero-padding?

I do see that all the objects you've defined in this document are a multiple of four bytes long (if we assume their unspecified headers are a multiple of four byte long, that is!) so no padding would ever be required for a payload consisting only of these objects, and thus my question wouldn't apply. But if that's the answer to my question, then the final clause I quote above (about zero-padding) should just be removed.

### Section 3.2, object format, padding

```
  Similar to the container, each object has an object header that is
  used to identify the type and length of the object payload, and the
  object payload is zero-padded to align to a 4-octet boundary.
```

Similar to the above, in some cases there will be a need to know how to separate payload from padding. In all the objects you defined in Sections 3.2.x this is unnecessary (*if* you assume the unspecified header is 4-octet aligned itself) since you've carefully specified them so that they don't require padding.

It might be more straightforward to just mandate that future object specifications have a length that is a multiple of four octets, as all of your current ones do. That defers the question of what to do about variable payloads to the specification of the -- notional? -- object that has such a payload.

### Section 4

You talk about TTL in the first paragraph. Do you mean "TTL or Hop Limit"?

### Section 6

- You talk about integrity protection in passing. Let's assume a deployment hasn't enabled any kind of integrity protection. Have you done any analysis of what kind of mischief an attacker could cause by inserting incorrect capabilities in a forged response?

- You suggest checking the must-be-zero reserved fields and reporting an exception if they aren't zero. Often, such reserved fields are expected to be extended in future, and indeed this is what you indicate in this spec too. I guess since the packets terminate at the recipient of the reply, it's not terribly harmful to police that these be zero, but it would likely create an awfully noisy set of exceptions in the case of a partially rolled-out extension. Is this really a good recommendation? The more usual practice is of the form "must be zero on Tx, must be ignored on Rx".

## 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 comment]
# John Scudder, RTG AD, comments for draft-ietf-ippm-ioam-conf-state-07
CC @jgscudder

## COMMENTS

### Section 1

```
  Fate sharing is a common requirement for all kinds of active OAM
  packets, echo request is among them, in this document that means echo
  request is required to traverse a path of IOAM data packet.  This
  requirement can be achieved by, e.g., applying same explicit path or
  ECMP processing to both echo request and IOAM data packet.
```

Explicit path, yes, but it's known that you can't simply expect to "apply same ECMP processing" to two quite distinct packets, without carefully arranging for that to happen. If this is a requirement (and the paragraph says it is) then I think it's necessary to be clearer about how it's to be achieved.

### Section 3.1, Default-Namespace-ID

```
              A list of IOAM Namespace-IDs (one or more Namespace-IDs)
  MUST be included in this container in the echo request, and if
  present, the Default-Namespace-ID 0x0000 MUST be placed at the
  begining of the list of IOAM Namespace-IDs.  The IOAM encapsulating
  node requests only the enabled IOAM capabilities that match one of
  the Namespace-IDs.  The Namespace-ID has the same definition as
  what's specified in Section 4.3 of [RFC9197].
```

- You specify that if present 0x0000 must be placed at the beginning of the list. Is there any other sorting requirement on the list, or is that the only mandated ordering?

- It wasn't clear to me from a quick perusal of RFC 9197 §4.3 whether a request carrying 0x0000 would elicit replies for all Namespace-IDs (since 0x0000 matches everything) or if it would elicit replies only for capabilities that have no configured non-default namespace, or are explicitly configured with namespace 0x0000. Can you either clarify this in the text, or if you think it's clear from the reference, help me understand what makes it clear?

- If the first guess above is correct (0x0000 elicits replies for all Namespace-IDs) then it would seem that if the list contains 0x0000, it's pointless to include anything else in the list, and that might be worth pointing out in the text.

- If the first guess above is correct, that would also prompt comments on the use of Namespace-ID field in Sections 3.2.x, but we can address that if needed.

### Section 3.1, container format, padding

```
  The IOAM Capabilities Query Container has a container header that is
  used to identify the type and optionally length of the container
  payload, and the container payload (List of IOAM Namespace-IDs) is
  zero-padded to align to a 4-octet boundary.

  The length, structure, and definition of the IOAM Capabilities Query
  Container Header depends on the specific environment it is applied
  at.
```

I regret I'm not sufficiently familiar with all the different bearer protocols you're envisioning embedding this container in. So I'll just ask,

- Why is the length of the payload said to be optional, when it's a (presumably variable-length) list? Does this relate to a bearer protocol where the length of the list is inferred some other way, or what?

- The specification that the payload is zero-padded to 4-octet alignment carries some implications. Let's explore these with an example. Suppose the payload is a single Namespace-ID, 0x0001. Then presumably the payload has to be 0x0001 0x0000, once the mandated pad bytes are added. Is the receiver supposed to know that it ignores the 0x0000 value (which is otherwise the Default-Namespace-ID) because it comes at the end of the list, not the beginning as the previous paragraph required? If so, this seems worth calling out. If not, how is the receiver supposed to know where payload ends and padding begins?

### Section 3.2, container format, padding

Similar questions to those above apply to:

```
  The IOAM Capabilities Response Container has a container header that
  is used to identify the type and optionally length of the container
  payload, and the container payload (List of IOAM Capabilities
  Objects) is zero-padded to align to a 4-octet boundary.
```

That is, considering you've disclaimed defining specifics about the semantics of the header, how is the recipient of one of these things supposed to know how to ignore the zero-padding?

I do see that all the objects you've defined in this document are a multiple of four bytes long (if we assume their unspecified headers are a multiple of four byte long, that is!) so no padding would ever be required for a payload consisting only of these objects, and thus my question wouldn't apply. But if that's the answer to my question, then the final clause I quote above (about zero-padding) should just be removed.

### Section 3.2, object format, padding

```
  Similar to the container, each object has an object header that is
  used to identify the type and length of the object payload, and the
  object payload is zero-padded to align to a 4-octet boundary.
```

Similar to the above, in some cases there will be a need to know how to separate payload from padding. In all the objects you defined in Sections 3.2.x this is unnecessary (*if* you assume the unspecified header is 4-octet aligned itself) since you've carefully specified them so that they don't require padding.

It might be more straightforward to just mandate that future object specifications have a length that is a multiple of four octets, as all of your current ones do. That defers the question of what to do about variable payloads to the specification of the -- notional? -- object that has such a payload.

### Section 4

You talk about TTL in the first paragraph. Do you mean "TTL or Hop Limit"?

### Section 6

- You talk about integrity protection in passing. Let's assume a deployment hasn't enabled any kind of integrity protection. Have you done any analysis of what kind of mischief an attacker could cause by inserting incorrect capabilities in a forged response?

- You suggest checking the must-be-zero reserved fields and reporting an exception if they aren't zero. Often, such reserved fields are expected to be extended in future, and indeed this is what you indicate in this spec too. I guess since the packets terminate at the recipient of the reply, it's not terribly harmful to police that these be zero, but it would likely create an awfully noisy set of exceptions in the case of a partially rolled-out extension. Is this really a good recommendation? The more usual practice is of the form "must be zero on Tx, must be ignored on Rx".

## 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]
### Clarity about scope of the document

As I understand it, this document isn't intended to be an implementable protocol specification on its own; rather, "specification details for these different echo request/reply protocols are outside the scope of this document".

If this approach is to be followed there are some changes needed. Below I provide some suggested text -- please know that I'm just supplying this as a straw man to illustrate my thinking; while you're welcome to use the text I've provided, I don't necessarily expect that.

The Abstract says that "This document describes an extension to the echo request/reply mechanisms". It does not. Here's an example of how it might be changed to be clearer.

OLD:
  This document describes an extension to the echo request/reply
  mechanisms used in IPv6 (including Segment Routing with IPv6 data
  plane (SRv6)), MPLS (including Segment Routing with MPLS data plane
  (SR-MPLS)), Service Function Chain (SFC) and Bit Index Explicit
  Replication (BIER) environments, which can be used within the In situ
  Operations, Administration, and Maintenance (IOAM) domain, allowing
  the IOAM encapsulating node to discover the enabled IOAM capabilities
  of each IOAM transit and IOAM decapsulating node.

NEW:
  There is a need to extend echo request/reply mechanisms used in IPv6
  (including Segment Routing with IPv6 data plane (SRv6)), MPLS
  (including Segment Routing with MPLS data plane (SR-MPLS)), Service
  Function Chain (SFC) and Bit Index Explicit Replication (BIER)
  environments, for use within the In situ Operations, Administration,
  and Maintenance (IOAM) domain, allowing the IOAM encapsulating node
  to discover the enabled IOAM capabilities of each IOAM transit and
  IOAM decapsulating node.

  Although this document does not itself specify the necessary
  extensions, it specifies formats and objects that can be used in such
  specifications, and provides guidelines and requirements for their
  development.

I think the Introduction also needs to be cleaned up. Saying that "specification details... are outside the scope" undersells the scope of what's needed. For example, maybe these changes would work in the Introduction:

OLD:
  This document describes an extension to the echo request/reply
  mechanisms used in IPv6 (including SRv6), MPLS (including SR-MPLS),
  SFC and BIER environments, which can be used within the IOAM domain,
  allowing the IOAM encapsulating node to discover the enabled IOAM
  capabilities of each IOAM transit and IOAM decapsulating node.

NEW:
  This document specifies formats and objects that can be used in the
  extension of echo request/reply mechanisms used in IPv6 (including
  SRv6), MPLS (including SR-MPLS), SFC and BIER environments, which can
  be used within the IOAM domain, allowing the IOAM encapsulating node
  to discover the enabled IOAM capabilities of each IOAM transit and
  IOAM decapsulating node.

OLD:
  Note that specification details for these different echo request/
  reply protocols are outside the scope of this document.  It is
  expected that each such protocol extension would be specified by an
  RFC and jointly designed by the working group that develops or
  maintains the echo request/reply protocol and the IETF IP Performance
  Measurement (IPPM) Working Group.

NEW:
  It is expected that the specification of the instantiation of each of
  these extensions will be done in the form of an RFC jointly designed
  by the working group that develops or maintains the echo
  request/reply protocol and the IETF IP Performance Measurement (IPPM)
  Working Group.
 
### Clarity of formats

Because this document is specifying things (or trying to) in absence of any concrete instantiation, it's difficult for me to evaluate if the formats as specified are complete and unambiguous. For now I've left my detailed discussion of this in my COMMENT section, and am optimistic that we can sort it out. However, I'm putting a placeholder here in case that problem turns out to be thornier than hoped.

[Ballot discuss]
### Clarity about scope of the document

As I understand it, this document isn't intended to be an implementable protocol specification on its own; rather, "specification details for these different echo request/reply protocols are outside the scope of this document".

If this approach is to be followed there are some changes needed. Below I provide some suggested text -- please know that I'm just supplying this as a straw man to illustrate my thinking; while you're welcome to use the text I've provided, I don't necessarily expect that.

The Abstract says that "This document describes an extension to the echo request/reply mechanisms". It does not. Here's an example of how it might be changed to be clearer.

OLD:
  This document describes an extension to the echo request/reply
  mechanisms used in IPv6 (including Segment Routing with IPv6 data
  plane (SRv6)), MPLS (including Segment Routing with MPLS data plane
  (SR-MPLS)), Service Function Chain (SFC) and Bit Index Explicit
  Replication (BIER) environments, which can be used within the In situ
  Operations, Administration, and Maintenance (IOAM) domain, allowing
  the IOAM encapsulating node to discover the enabled IOAM capabilities
  of each IOAM transit and IOAM decapsulating node.

NEW:
  There is a need to extend echo request/reply mechanisms used in IPv6
  (including Segment Routing with IPv6 data plane (SRv6)), MPLS
  (including Segment Routing with MPLS data plane (SR-MPLS)), Service
  Function Chain (SFC) and Bit Index Explicit Replication (BIER)
  environments, for use within the In situ Operations, Administration,
  and Maintenance (IOAM) domain, allowing the IOAM encapsulating node
  to discover the enabled IOAM capabilities of each IOAM transit and
  IOAM decapsulating node.

  Although this document does not itself specify the necessary
  extensions, it specifies formats and objects that can be used in such
  specifications, and provides guidelines and requirements for their
  development.

I think the Introduction also needs to be cleaned up. Saying that "specification details... are outside the scope" undersells the scope of what's needed. For example, maybe these changes would work in the Introduction:

OLD:
  This document describes an extension to the echo request/reply
  mechanisms used in IPv6 (including SRv6), MPLS (including SR-MPLS),
  SFC and BIER environments, which can be used within the IOAM domain,
  allowing the IOAM encapsulating node to discover the enabled IOAM
  capabilities of each IOAM transit and IOAM decapsulating node.

NEW:
  This document specifies formats and objects that can be used in the
  extension of echo request/reply mechanisms used in IPv6 (including
  SRv6), MPLS (including SR-MPLS), SFC and BIER environments, which can
  be used within the IOAM domain, allowing the IOAM encapsulating node
  to discover the enabled IOAM capabilities of each IOAM transit and
  IOAM decapsulating node.

OLD:
  Note that specification details for these different echo request/
  reply protocols are outside the scope of this document.  It is
  expected that each such protocol extension would be specified by an
  RFC and jointly designed by the working group that develops or
  maintains the echo request/reply protocol and the IETF IP Performance
  Measurement (IPPM) Working Group.

NEW:
  It is expected that the specification of the instantiation of each of
  these extensions will be done in the form of an RFC jointly designed
  by the working group that develops or maintains the echo
  request/reply protocol and the IETF IP Performance Measurement (IPPM)
  Working Group.
 
### Clarity of formats

Because this document is specifying things (or trying to) in absence of any concrete instantiation, it's very difficult for me to evaluate if the formats as specified are complete and unambiguous. For now I've left my detailed discussion of this in my COMMENT section, and am optimistic that we can sort it out. However, I'm putting a placeholder here in case that problem turns out to be thornier than hoped.

[Ballot discuss]
### Clarity about scope of the document

As I understand it, this document isn't intended to be an implementable protocol specification on its own; rather, "specification details for these different echo request/reply protocols are outside the scope of this document".

I'm not crazy about this approach, but if it's to be followed there are some changes needed. Below I provide some suggested text -- please know that I'm just supplying this as a straw man to illustrate my thinking; while you're welcome to use the text I've provided, I don't necessarily expect that.

The Abstract says that "This document describes an extension to the echo request/reply mechanisms". It does not. Here's an example of how it might be changed to be clearer.

OLD:
  This document describes an extension to the echo request/reply
  mechanisms used in IPv6 (including Segment Routing with IPv6 data
  plane (SRv6)), MPLS (including Segment Routing with MPLS data plane
  (SR-MPLS)), Service Function Chain (SFC) and Bit Index Explicit
  Replication (BIER) environments, which can be used within the In situ
  Operations, Administration, and Maintenance (IOAM) domain, allowing
  the IOAM encapsulating node to discover the enabled IOAM capabilities
  of each IOAM transit and IOAM decapsulating node.

NEW:
  There is a need to extend echo request/reply mechanisms used in IPv6
  (including Segment Routing with IPv6 data plane (SRv6)), MPLS
  (including Segment Routing with MPLS data plane (SR-MPLS)), Service
  Function Chain (SFC) and Bit Index Explicit Replication (BIER)
  environments, for use within the In situ Operations, Administration,
  and Maintenance (IOAM) domain, allowing the IOAM encapsulating node
  to discover the enabled IOAM capabilities of each IOAM transit and
  IOAM decapsulating node.

  Although this document does not itself specify the necessary
  extensions, it specifies formats and objects that can be used in such
  specifications, and provides guidelines and requirements for their
  development.

I think the Introduction also needs to be cleaned up. Saying that "specification details... are outside the scope" undersells the scope of what's needed. For example, maybe these changes would work in the Introduction:

OLD:
  This document describes an extension to the echo request/reply
  mechanisms used in IPv6 (including SRv6), MPLS (including SR-MPLS),
  SFC and BIER environments, which can be used within the IOAM domain,
  allowing the IOAM encapsulating node to discover the enabled IOAM
  capabilities of each IOAM transit and IOAM decapsulating node.

NEW:
  This document specifies formats and objects that can be used in the
  extension of echo request/reply mechanisms used in IPv6 (including
  SRv6), MPLS (including SR-MPLS), SFC and BIER environments, which can
  be used within the IOAM domain, allowing the IOAM encapsulating node
  to discover the enabled IOAM capabilities of each IOAM transit and
  IOAM decapsulating node.

OLD:
  Note that specification details for these different echo request/
  reply protocols are outside the scope of this document.  It is
  expected that each such protocol extension would be specified by an
  RFC and jointly designed by the working group that develops or
  maintains the echo request/reply protocol and the IETF IP Performance
  Measurement (IPPM) Working Group.

NEW:
  It is expected that the specification of the instantiation of each of
  these extensions will be done in the form of an RFC jointly designed
  by the working group that develops or maintains the echo
  request/reply protocol and the IETF IP Performance Measurement (IPPM)
  Working Group.
 
### Clarity of formats

Because this document is specifying things (or trying to) in absence of any concrete instantiation, it's very difficult for me to evaluate if the formats as specified are complete and unambiguous. For now I've left my detailed discussion of this in my COMMENT section, and am optimistic that we can sort it out. However, I'm putting a placeholder here in case that problem turns out to be thornier than hoped.

[Ballot comment]
# John Scudder, RTG AD, comments for draft-ietf-ippm-ioam-conf-state-07
CC @jgscudder

## COMMENTS

### Section 1

```
  Fate sharing is a common requirement for all kinds of active OAM
  packets, echo request is among them, in this document that means echo
  request is required to traverse a path of IOAM data packet.  This
  requirement can be achieved by, e.g., applying same explicit path or
  ECMP processing to both echo request and IOAM data packet.
```

Explicit path, yes, but it's known that you can't simply expect to "apply same ECMP processing" to two quite distinct packets, absent very carefully arranging for that to happen. If this is a requirement (and the paragraph says it is) then I think it's necessary to be clearer about how it's to be achieved.

### Section 3.1, Default-Namespace-ID

```
              A list of IOAM Namespace-IDs (one or more Namespace-IDs)
  MUST be included in this container in the echo request, and if
  present, the Default-Namespace-ID 0x0000 MUST be placed at the
  begining of the list of IOAM Namespace-IDs.  The IOAM encapsulating
  node requests only the enabled IOAM capabilities that match one of
  the Namespace-IDs.  The Namespace-ID has the same definition as
  what's specified in Section 4.3 of [RFC9197].
```

- You specify that if present 0x0000 must be placed at the beginning of the list. Is there any other sorting requirement on the list, or is that the only mandated ordering?

- It wasn't clear to me from a quick perusal of RFC 9197 §4.3 whether a request carrying 0x0000 would elicit replies for all Namespace-IDs (since 0x0000 matches everything) or if it would elicit replies only for capabilities that have no configured non-default namespace, or are explicitly configured with namespace 0x0000. Can you either clarify this in the text, or if you think it's clear from the reference, help me understand what makes it clear?

- If the first guess above is correct (0x0000 elicits replies for all Namespace-IDs) then it would seem that if the list contains 0x0000, it's pointless to include anything else in the list, and that might be worth pointing out in the text.

- If the first guess above is correct, that would also prompt comments on the use of Namespace-ID field in Sections 3.2.x, but we can address that if needed.

### Section 3.1, container format, padding

```
  The IOAM Capabilities Query Container has a container header that is
  used to identify the type and optionally length of the container
  payload, and the container payload (List of IOAM Namespace-IDs) is
  zero-padded to align to a 4-octet boundary.

  The length, structure, and definition of the IOAM Capabilities Query
  Container Header depends on the specific environment it is applied
  at.
```

I regret I'm not sufficiently familiar with all the different bearer protocols you're envisioning embedding this container in. So I'll just ask,

- Why is the length of the payload said to be optional, when it's a (presumably variable-length) list? Does this relate to a bearer protocol where the length of the list is inferred some other way, or what?

- The specification that the payload is zero-padded to 4-octet alignment carries some implications. Let's explore these with an example. Suppose the payload is a single Namespace-ID, 0x0001. Then presumably the payload has to be 0x0001 0x0000, once the mandated pad bytes are added. Is the receiver supposed to know that it ignores the 0x0000 value (which is otherwise the Default-Namespace-ID) because it comes at the end of the list, not the beginning as the previous paragraph required? If so, this seems worth calling out. If not, how is the receiver supposed to know where payload ends and padding begins?

### Section 3.2, container format, padding

Similar questions to those above apply to:

```
  The IOAM Capabilities Response Container has a container header that
  is used to identify the type and optionally length of the container
  payload, and the container payload (List of IOAM Capabilities
  Objects) is zero-padded to align to a 4-octet boundary.
```

That is, considering you've disclaimed defining specifics about the semantics of the header, how is the recipient of one of these things supposed to know how to ignore the zero-padding?

I do see that all the objects you've defined in this document are a multiple of four bytes long (if we assume their unspecified headers are a multiple of four byte long, that is!) so no padding would ever be required for a payload consisting only of these objects, and thus my question wouldn't apply. But if that's the answer to my question, then the final clause I quote above (about zero-padding) should just be removed.

### Section 3.2, object format, padding

```
  Similar to the container, each object has an object header that is
  used to identify the type and length of the object payload, and the
  object payload is zero-padded to align to a 4-octet boundary.
```

Similar to the above, in some cases there will be a need to know how to separate payload from padding. In all the objects you defined in Sections 3.2.x this is unnecessary (*if* you assume the unspecified header is 4-octet aligned itself) since you've carefully specified them so that they don't require padding.

It might be more straightforward to just mandate that future object specifications have a length that is a multiple of four octets, as all of your current ones do. That defers the question of what to do about variable payloads to the specification of the -- notional? -- object that has such a payload.

### Section 4

You talk about TTL in the first paragraph. Do you mean "TTL or Hop Limit"?

### Section 6

- You talk about integrity protection in passing. Let's assume a deployment hasn't enabled any kind of integrity protection. Have you done any analysis of what kind of mischief an attacker could cause by inserting incorrect capabilities in a forged response?

- You suggest checking the must-be-zero reserved fields and reporting an exception if they aren't zero. Often, such reserved fields are expected to be extended in future, and indeed this is what you indicate in this spec too. I guess since the packets terminate at the recipient of the reply, it's not terribly harmful to police that these be zero, but it would likely create an awfully noisy set of exceptions in the case of a partially rolled-out extension. Is this really a good recommendation? The more usual practice is of the form "must be zero on Tx, must be ignored on Rx".

## 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]
Thank you very much for writing this document.
Please see: https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/


My concerns are closely related to Roman's DISCUSS point:

The document says: "A deployment can increase security by using border filtering of incoming and outgoing echo requests/replies."

I'm unclear why this is just a "can increase security", and not something much much stronger -- but, also, I'm unclear how exactly an operator would be expected to filter these. The Abstract says: "This document describes an extension to the echo request/reply mechanisms used in [...]", but from what I can tell, it is more "here are some containers that you could use in some other protocols".

It seems like, instead of only relying on the network for filtering (which doesn't yet seem to be implemented), the:
"To protect against unauthorized sources using echo request messages to obtain IOAM Capabilities information, it is RECOMMENDED that implementations provide a means of checking the source addresses of echo request messages against an access list before accepting the message."
should be made stronger. Implementations need to be created to understand IOAM, and so requiring that they have the capability to only accept configured source addresses seems simple.

[Ballot comment]
# GEN AD review of draft-ietf-ippm-ioam-conf-state-07

CC @larseggert

Thanks to Gyan S. Mishra for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/wA_8u8-xjQ7sl29P3Qul3W_U_aw).

## Comments

### Section 5.1, paragraph 3
```
    0b01 - 0b11 are available for assignment via RFC Required process as
    per [RFC8126].
```
Since there are only three codepoints remaining, would a stricter assignment
policy not make sense?

### Section 5.2, paragraph 3
```
    0b11 is available for assignment via RFC Required process as per
    [RFC8126].
```
Since there is only a single codepoint remaining, would a stricter assignment
policy not make sense?

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Typos

#### Section 3.1, paragraph 4
```
-    begining of the list of IOAM Namespace-IDs.  The IOAM encapsulating
+    beginning of the list of IOAM Namespace-IDs.  The IOAM encapsulating
+        +
```

#### Section 6, paragraph 9
```
-    Except for what's described above, the securiy issues discussed in
+    Except for what's described above, the security issues discussed in
+                                                +
```

### Grammar/style

#### Section 3.2.2, paragraph 9
```
C9197]. This document defines SoP as follow: 0b00 means 64-bit "PktID" and 6
                                  ^^^^^^^^^
```
Did you mean "as follows"?

#### Section 3.2.6, paragraph 1
```
th TTL equal to 2 to reach the second nearest node, which also may be an IOAM
                              ^^^^^^^^^^^^^^
```
It appears that a hyphen is missing.

#### Section 4, paragraph 1
```
s per [RFC8126]. The subsequent sub-sections detail the registries herein co
                                ^^^^^^^^^^^^
```
This word is normally spelled as one.

## 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. Review generated by the [`ietf-reviewtool`][IRT].

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

[Ballot discuss]
Section 6.

  A deployment can increase security by using border filtering of
  incoming and outgoing echo requests/replies.

Thanks for calling out the security impact of echo request/replies.  Since the cited RFC9197 reminds the reader that a “network operator is expected to enforce policies that prevent IOAM traffic from leaking outside of the IOAM-Domain”, why is this guidance not mandatory?

Would the following text be more appropriate?

NEW
A deployment MUST ensure that border filtering drops inbound echo requests with a IOAM Capabilities Container Header from outside of the domain, and drops outbound echo request/replies with IOAM Capabilities Headers leaving the domain.

[Ballot comment]
Thanks to Chris Lonvick for the SecDir review. He raised a few points that are worth addressing: https://datatracker.ietf.org/doc/review-ietf-ippm-ioam-conf-state-05-secdir-lc-lonvick-2022-09-30/


  Reserved field is reserved for future use and MUST be set to zero.

Can this be extended to say "and MUST be ignored when non-zero" ? There is more than one of these.


Why is the SoP field specified as two bits from a reserved field, when it only uses one bit? Why not just take one bit from the reserved field?

[Ballot comment]

The Abstract (and the corresponding text in the Introduction) is misleading:

  This document describes an extension to the echo request/reply
  mechanisms used in IPv6 (including Segment Routing with IPv6 data
  plane (SRv6)), MPLS (including Segment Routing with MPLS data plane
  (SR-MPLS)), Service Function Chain (SFC) and Bit Index Explicit
  Replication (BIER) environments, which can be used within the In situ
  Operations, Administration, and Maintenance (IOAM) domain, allowing
  the IOAM encapsulating node to discover the enabled IOAM capabilities
  of each IOAM transit and IOAM decapsulating node.

This document describes an extension that *could be used* as mentioned above, but it doesn't specify "an extension to the echo request/reply mechanisms used in..."  Please clarify that the document describes a generic format.

The Introduction later clarifies that "specification details for these different echo request/reply protocols are outside the scope of this document".  However, if the mentioned applications are expected to be the users of this specification, the corresponding WGs (6man, spring, mpls, sfc, and bier) should have been consulted.  I couldn't find anything in the archives to show interaction.

[Ballot comment]

# Éric Vyncke, INT AD, comments for draft-ietf-ippm-ioam-conf-state-07
CC @evyncke

Thank you for the work put into this document.

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education).

Special thanks to Marcus Ihlar 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

## COMMENTS

### Abstract

This is a very long sentence... Consider shortening it.

The `echo request/reply mechanisms used in IPv6 ...` would benefit of being qualified (perhaps with 'generic' or 'specified' ?).

### Section 1

The IPv6 node information query, while sent over ICMPv6, is not really an 'echo/request' exchange, hence the title of this RFC is not really adequate. I have no suggestion though.

### Section 2.2

When defining "TTL" please also add that this is the hop-limit field in the IPv6 header (which has no TTL field).

### Section 3.2.1 and other sections including 3.2.6 "Must be zero"

Please do not forget to specify the receiver's behavior when receiving reserved bits that are no all 0.

### Section 3.2.3

Explaining what "SoP" is would ease the reading.


## 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

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

The IANA Functions Operator has completed its review of draft-ietf-ippm-ioam-conf-state-05. If any part of this review is inaccurate, please let us know.

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

First a new registry page is to be created called the In-Situ OAM (IOAM) Capabilities Parameters registry page. The page will be created on the IANA Protocol Registries page at:

https://www.iana.org/protocols

NOTE: In accordance with current practice, IANA prefers to leave the
string \u201cParameters\u201d out of the name of a new registry grouping, unless
doing so will cause confusion. Please let us know if there will be any
issues with using the term \u201cIn-Situ OAM (IOAM) Capabilities\u201d instead of \u201cIn-Situ OAM (IOAM) Capabilities Parameters.\u201d

Second, a new registry is to be created called the IOAM SoP Capability registry. The new registry will be located on the newly created In-Situ OAM (IOAM) Capabilities Parameters registry page. Values in the registry range from 0b00 to 0b11. The registration rule for the new registry is RFC Required as defined in RFC 8126. There is a single initial registration in the new registry as follows:

SoP Description Reference
---- ------------------------------------------- -------------
0b00 64-bit "PktID" and 64-bit "Cumulative" data [ RFC-to-be ]

Third, a new registry is to be created called the IOAM TSF Capability registry. The new registry will be located on the newly created In-Situ OAM (IOAM) Capabilities Parameters registry page. Values in the registry range from 0b00 to 0b11. The registration rule for the new registry is RFC Required as defined in RFC 8126. There are three initial registrations in the new registry as follows:

TSF Description Reference
---- ------------------------------ -------------
0b00 PTP Truncated Timestamp Format [ RFC-to-be ]
0b01 NTP 64-bit Timestamp Format [ RFC-to-be ]
0b10 POSIX-based Timestamp Format [ RFC-to-be ]
0b11 Unassigned

The IANA Services Operator understands that these three actions are the only ones 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 2022-10-06):

From: The IESG
To: IETF-Announce
CC: draft-ietf-ippm-ioam-conf-state@ietf.org, ippm-chairs@ietf.org, ippm@ietf.org, marcus.ihlar@ericsson.com, martin.h.duke@gmail.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Echo Request/Reply for Enabled In-situ OAM Capabilities) to Proposed Standard


The IESG has received a request from the IP Performance Measurement WG (ippm)
to consider the following document: - 'Echo Request/Reply for Enabled In-situ
OAM Capabilities'
  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 2022-10-06. 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


  This document describes an extension to the echo request/reply
  mechanisms used in IPv6 (including Segment Routing with IPv6 data
  plane (SRv6)), MPLS (including Segment Routing with MPLS data plane
  (SR-MPLS)), Service Function Chain (SFC) and Bit Index Explicit
  Replication (BIER) environments, which can be used within the In situ
  Operations, Administration, and Maintenance (IOAM) domain, allowing
  the IOAM encapsulating node to discover the enabled IOAM capabilities
  of each IOAM transit and IOAM decapsulating node.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-conf-state/


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

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

# Document Shepherd Writeup

*This version is dated 8 April 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this writeup to give helpful context to Last Call and
Internet Engineering Steering Group ([IESG][1]) reviewers, and your diligence in
completing it, is appreciated. The full role of the shepherd is further
described in [RFC 4858][2], and informally. You will need the cooperation of
authors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## 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 of a few individuals, with
  others being silent. 

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

  The strongest criticism has been related to not being fully aligned with
  the data model described in: draft-ietf-ippm-ioam-yang. There have been
  disagreements on the usefulness of this feature (why is there a need for
  IOAM capability discovery within a limited domain?).

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.

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)?

  There are no current implementations known to the shepherd or the authors.
  ZTE and China Telecom have expressed that they intend to implement the
  solution described in the document. 

### Additional Reviews

5. Does this document need review from other IETF working groups or external
  organizations? Have those reviews occurred?
 
  No

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.
 
  n/a

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]?
 
  n/a

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.

  n/a

### 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 needed (as expressed by some WG members) and technically
  sound. There is room for improvement of the language in the document, but
  overall it's ready to progress.

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?

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?

    Proposed standard as it builds upon other IOAM standards such as RFC 9197.
    The datatracker state attributes reflect this intent.

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.

    There is a single IPR [13] relating to IOAM in general. The authors have
    confirmed that they are not aware of any additional IPRs.

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.

    Yes.

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.

    The abstract consists of several abbreviations, none of them expanded.

    Section 3:
    References to ioam-data (RFC 9197) point to the wrong section numbers:
    IOAM-Trace-Type field is defined in section 4.4 of RFC 9197.
    Namespace-ID field is defined in section 4.3 of RFC 9197.
    IOAM-POT-Type field is defined in section 4.5 of RFC 9197.
    IOAM-E2E-Type field is defined in section 4.6 of RFC 9197.

    ID nits output:

    Outdated reference: draft-ietf-ippm-ioam-data has been published as RFC
    9197

    Outdated reference: A later version (-09) exists of
    draft-ietf-ippm-ioam-direct-export-07

    Outdated reference: A later version (-19) exists of draft-ietf-sfc-multi-layer-oam-18

    Outdated reference: A later version (-01) exists of draft-xiao-6man-icmpv6-ioam-conf-state-00

15. Should any informative references be normative or vice-versa?

    No.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?
   
    n/a

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

    No.

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?

    There is a normative reference to I-D.ietf-ippm-ioam-direct-export which is
    currently under IESG evaluation.

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.

    n/a

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]).

    Contains a request for a new registry group with an appropriate name: 
    "In-Situ OAM (IOAM) Capabilities Parameters".

    Two registries are proposed for the group:

    IOAM SoP Capability Registry
    IOAM TSF Capability Registry

    Both registries have descriptive names and short descriptions with
    references to relevant technical content.

    There's a small nit in section 5.2 which states that the registry
    defines three code points. It actually defines four, and assigns
    three.

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.

    n/a

[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

[13]: https://datatracker.ietf.org/ipr/3531/

# Document Shepherd Writeup

*This version is dated 8 April 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this writeup to give helpful context to Last Call and
Internet Engineering Steering Group ([IESG][1]) reviewers, and your diligence in
completing it, is appreciated. The full role of the shepherd is further
described in [RFC 4858][2], and informally. You will need the cooperation of
authors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## 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 of a few individuals, with
  others being silent. 

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

  The strongest criticism has been related to not being fully aligned with
  the data model described in: draft-ietf-ippm-ioam-yang. There have been
  disagreements on the usefulness of this feature (why is there a need for
  IOAM capability discovery within a limited domain?).

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.

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)?

  There are no current implementations known to the shepherd or the authors.
  ZTE and China Telecom have expressed that they intend to implement the
  solution described in the document. 

### Additional Reviews

5. Does this document need review from other IETF working groups or external
  organizations? Have those reviews occurred?
 
  No

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.
 
  n/a

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]?
 
  n/a

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.

  n/a

### 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 needed (as expressed by some WG members) and technically
  sound. There is room for improvement of the language in the document, but
  overall it's ready to progress.

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?

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?

    Proposed standard as it builds upon other IOAM standards such as RFC 9197.
    The datatracker state attributes reflect this intent.

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.

    There is a single IPR [13] relating to IOAM in general. The authors have
    confirmed that they are not aware of any additional IPRs.

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.

    Yes.

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.

    The abstract consists of several abbreviations, none of them expanded.

    Section 3:
    References to ioam-data (RFC 9197) point to the wrong section numbers:
    IOAM-Trace-Type field is defined in section 4.4 of RFC 9197.
    Namespace-ID field is defined in section 4.3 of RFC 9197.
    IOAM-POT-Type field is defined in section 4.5 of RFC 9197.
    IOAM-E2E-Type field is defined in section 4.6 of RFC 9197.

    ID nits output:

    Outdated reference: draft-ietf-ippm-ioam-data has been published as RFC
    9197

    Outdated reference: A later version (-09) exists of
    draft-ietf-ippm-ioam-direct-export-07

    Outdated reference: A later version (-19) exists of draft-ietf-sfc-multi-layer-oam-18

    Outdated reference: A later version (-01) exists of draft-xiao-6man-icmpv6-ioam-conf-state-00

15. Should any informative references be normative or vice-versa?

    No.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?
   
    n/a

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

    No.

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?

    There is a normative reference to I-D.ietf-ippm-ioam-direct-export which is
    currently under IESG evaluation.

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.

    n/a

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]).

    Contains a request for a new registry group with an appropriate name: 
    "In-Situ OAM (IOAM) Capabilities Parameters".

    Two registries are proposed for the group:

    IOAM SoP Capability Registry
    IOAM TSF Capability Registry

    Both registries have descriptive names and short descriptions with
    references to relevant technical content.

    There's a small nit in section 5.2 which states that the registry
    defines three code points. It actually defines four, and assigns
    three.

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.

    n/a

[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

[13]: https://datatracker.ietf.org/ipr/3531/