[ippm] John Scudder's No Objection on draft-ietf-ippm-ioam-ipv6-options-11: (with COMMENT)

[John Scudder via Datatracker <[e-mail]>]

John Scudder has entered the following ballot position for
draft-ietf-ippm-ioam-ipv6-options-11: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-ipv6-options/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

# John Scudder, RTG AD, comments for draft-ietf-ippm-ioam-ipv6-options-11
CC @jgscudder

## COMMENT

Thanks for taking care of my previous DISCUSSes and many of my earlier
comments. There remain a few comments that weren't addressed in versions 10 or
11 nor responded to in email, please forgive me if I've missed a response. I
repeat the comments below, with section numbers updated to match the numbering
in versions 10 and 11.

### Section 3, reference for IOAM Type, nomenclature

```
IOAM Type: 8-bit field as defined in section 7.1 in [RFC9197].
```

Section 7.1 of RFC 9197 is the IOAM Option-Type Registry in the IANA
Considerations section. I wouldn't say an IANA registry "defines" anything, it
lists code points. I think a better reference would be Section 4 of 9197, which
does indeed define IOAM-Option-Types (in Section 4.1).

Also, it would be better to be consistent with your naming, in RFC 9197 you
don't call this the "IOAM Type" but rather the "IOAM-Option-Type" (34
occurrences in 9197) or "IOAM Option-Type" without the first hyphen (4
occurrences in 9197). I see why you don't want to use the full string from RFC
9197 in your packet diagram (too many characters) but "IOAM-Opt-Type" would fit
in the character budget.

### Section 4.2, encapsulation?

```
For deployments where the IOAM domain is bounded by hosts, hosts will perform
the operation of IOAM data field encapsulation and decapsulation. ```

Do you intend to imply that the hosts at the edge of the domain are sending
IP-in-IPv6 encapsulated data? It wouldn't seem to be required; since the hosts
are the source/sink of the packets, the problem described in C6 doesn't apply,
and the host can directly place the IOAM data in the header. (What would be the
"inner header" in an overlay solution.)

I suppose it's technically accurate to describe this as an "encapsulation and
decapsulation" operation, insofar as any data placed in any header might be
said to be encapsulated in that header -- but it's misleading. I think this
section needs to be rewritten to make the meaning plain. For example, something
like "... hosts will place the IOAM data field directly in the IPv6 header."
(You could say "outer IPv6 header" since there's nothing precluding a host from
sending tunneled packets for some purpose.)

(I notice Éric Vyncke raises a similar concern about the nontraditional use of
the term "encapsulation" in his comments.)

### Section 4.3, encapsulation again

This one is less misleading, but by analogy to 4.2 I suspect more clarity is
required here too.

```
For deployments where the IOAM domain is bounded by network devices, network
devices such as routers form the edge of an IOAM domain. Network devices will
perform the operation of IOAM data field encapsulation and decapsulation. ```

For example, a more straightforwardly understandable version of the last
sentence might be "Network devices will encapsulate in-flight packets in an
outer IPv6 header which carries the IOAM data field."

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