[ippm] John Scudder's Discuss on draft-ietf-ippm-ioam-ipv6-options-10: (with DISCUSS and COMMENT)

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

John Scudder has entered the following ballot position for
draft-ietf-ippm-ioam-ipv6-options-10: Discuss

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/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

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

## DISCUSS

Thanks for taking care of my previous DISCUSS! I'm so sorry to have to raise
another one, related to the new text.

   C1  IOAM MUST be deployed as a limited domain feature as defined in
      [RFC8799].

I applaud your desire to be prescriptive and concise. Unfortunately, I think
there are a few problems here. First the small ones: you have RFC 8799 as an
Informative reference, which is problematic since you want to make adherence to
it mandatory. But, if you move it to be a Normative reference (as seems
indicated), then we encounter two further issues: first and less importantly,
it’s not an IETF document, so possibly needs to be treated as a downref?

But most importantly, as far as I can tell RFC 8799 does not define “a limited
domain feature”. It provides a taxonomy for talking about limited domains and
various considerations, but nothing I would call a “definition”. I confess I’ve
only briefly reviewed 8799 just now, not fully re-read it, so maybe you will be
able to point me to a clear and actionable definition, that an implementor of
your spec could apply in order to comply with C1. If so, please do let me know
what that definition is, and also update your reference to cite it
specifically, rather than just the RFC number. In my own review of 8799, the
closest I see is Section 6, "Functional Requirements of Limited Domains”. I
will be a little surprised if you really want to require adherence requirements
1-11 in that section, though.

Sadly, I suspect that you’ll end up concluding that RFC 8799 isn’t fit for the
purpose you’re trying to use it for and that you’ll need to write out in your
own words what the specific requirements are for your case. It looks to me as
though the taxonomy section of RFC 8799 might be quite useful to you in that
respect, indeed that seems to be partly what it’s for:

```
A.9. Making Use of This Taxonomy

This taxonomy could be used to design or analyze a specific type of limited
domain. ```

It’s unfortunate that we don’t have a good, citable definition of “limited
domain” in our document set... but we don’t. This might be merely because
nobody has bothered to write it yet, although I think the real reason is more
likely that it turns out to be a sticky problem to nail it down to a definition
that is both general enough to be broadly applicable and specific enough to be
actionable.


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

## COMMENT

Thanks for taking care of many of my previous comments. A few appear not to
have been addressed in version 10 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 version 10.

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