IPv6 Options for In Situ Operations, Administration, and Maintenance (IOAM)
draft-ietf-ippm-ioam-ipv6-options-12

[Ballot 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

[Ballot comment]
Hi,

Firstly thanks for the modifications to the text.  While I still support the discuss points raised by John, I'm going to clear my discuss based on the fact that I think that the new next in C2 seems to address my destination option query, since I'm going to presume that if the destination address is a SID - it stands to reason that where a SID is not bound to a specific interface, it cannot be IOAM enabled and therefore the packets should be ignored.

[Ballot 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.

[Ballot 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

[Ballot comment]
# GEN AD review of draft-ietf-ippm-ioam-ipv6-options-09

CC @larseggert

Thanks to Joel Halpern for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/N0aMpTOtDieVf0vT6Tu2reLFewI).

## Comments

I find myself agreeing with the numerous DISCUSS positions, but
I trust the ADs that raised them to resolve them with the authors.

### Section 4, paragraph 28
```
    All the in-situ OAM IPv6 options defined here have alignment
    requirements.  Specifically, they all require 4n alignment.  This
```
I haven't come across the term "4n alignment" before. Suggest to
rephrase (by using the text in the following sentence.)

## 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 5.1, paragraph 4
```
-    C3  Packets with IOAM data or associated ICMP errors, should not
-                                                        -
```

### Outdated references

Document references `draft-ietf-ippm-ioam-direct-export`, but that has been
published as `RFC9326`.

### URLs

These URLs point to tools.ietf.org, which has been taken out of service:

* https://tools.ietf.org/id/draft-kitamura-ipv6-record-route-00.txt

These URLs in the document can probably be converted to HTTPS:

* http://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml#ipv6-parameters-2

### Grammar/style

#### Section 5.1, paragraph 3
```
IOAM. For example, if IOAM is used in in transit devices, misleading ICMP er
                                  ^^^^^
```
Possible typo: you repeated a word.

#### Section 5.1, paragraph 3
```
ommunicate the errors to devices outside of the IOAM domain MUST remove any
                                ^^^^^^^^^^
```
This phrase is redundant. Consider using "outside".

#### Section 5.1, paragraph 5
```
options that follow IOAM options. Hence when the IOAM Incremental Trace Opt
                                  ^^^^^
```
A comma may be missing after the conjunctive/linking adverb "Hence".

#### Section 5.4.1, paragraph 1
```
LA destination address is invalid outside of the IOAM domain. There is no ext
                                  ^^^^^^^^^^
```
This phrase is redundant. Consider using "outside".

## 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 comment]
# GEN AD review of draft-ietf-lamps-rfc3709bis-08

CC @larseggert

Thanks to Paul Kyzivat for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/IiFgJfnLGPzwxj92raQWE4oI108).

## Comments

### Section 4.1, paragraph 8
```
    Note that the HTTPS scheme (https://...) requires the validation of
    other certificates to establish a secure connection.  For this
    reason, the HTTP scheme (http://...) may be easier for a client to
    handle.  Also, the hash of the logotype data provides data integrity.
```
It may be easier, but it's also insecure. I find it odd that we don't
recommend HTTPS over HTTP here?

### Inclusive language

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

* Term `his`; alternatives might be `they`, `them`, `their`
* Term `traditional`; alternatives might be `classic`, `classical`, `common`,
  `conventional`, `customary`, `fixed`, `habitual`, `historic`,
  `long-established`, `popular`, `prescribed`, `regular`, `rooted`,
  `time-honored`, `universal`, `widely used`, `widespread`

## 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, paragraph 6
```
-    applications where the audio text is placed as the "alt" atttribute
-                                                                -
```

#### Section 3, paragraph 6
```
-    value of an html image (img) element and the language value obtained
-                ^^^^
+    value of an HTML image (img) element and the language value obtained
+                ^^^^
```

#### Section 7, paragraph 16
```
-    When a bitmapped image is used, the PNG [ISO15948] format SHOULD be
-                ---
```

### URLs

These URLs in the document can probably be converted to HTTPS:

* http://www.w3.org/TR/2008/PR-SVGTiny12-20081117

### Grammar/style

#### Section 1, paragraph 3
```
tificate may be examined from several different perspectives. Systematic pro
                            ^^^^^^^^^^^^^^^^^
```
Consider using "several".

#### Section 1, paragraph 9
```
a user identifies the owner of the web site. * Peer e-mail exchange in busin
                                  ^^^^^^^^
```
Nowadays, it's more common to write this as one word.

#### Section 1.1, paragraph 4
```
ate is too technical and is not user friendly. It contains no graphic symbol
                              ^^^^^^^^^^^^^
```
This word is normally spelled with a hyphen.

#### Section 1.3, paragraph 3
```
the end, the human will decide whether or not to accept an executable email a
                              ^^^^^^^^^^^^^^
```
Consider shortening this phrase to just "whether". It is correct though if you
mean "regardless of whether".

#### Section 6, paragraph 7
```
references to information stored outside of the SVG image of type B, C, or D
                                ^^^^^^^^^^
```
This phrase is redundant. Consider using "outside".

#### Section 7, paragraph 2
```
FC1952] as specified in [SVGR]. When a uncompressed SVG image is fetched wit
                                    ^
```
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

#### Section 7, paragraph 3
```
characters as specified above. When a SVG image is embedded in the certific
                                    ^
```
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

## 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 comment]
Hi,

Thanks for this doc.

Minor level comments:                                                                                                                                                                                                                                                                                                                                                                       
                                                                                                                                                                                                                                                                                                                                                                                           
(1) p 5, sec 4.  In-situ OAM Metadata Transport in IPv6                                                                                                                                                                                                                                                                                                                                     
                                                                                                                                                                                                                                                                                                                                                                                           
  IPv6 options can have a maximum length of 255 octets.  Consequently,                                                                                                                                                                                                                                                                                                                     
  the total length of IOAM Option-Types including all data fields is                                                                                                                                                                                                                                                                                                                       
  also limited to 255 octets when encapsulated into IPv6.                                                                                                                                                                                                                                                                                                                                 
                                                                                                                                                                                                                                                                                                                                                                                           
Given the alignment requirements, wouldn't the max length be slightly smaller, e.g. 252 bytes?                                                                                                                                                                                                                                                                                             
                                                                                                                                                                                                                                                                                                                                                                                           
                                                                                                                                                                                                                                                                                                                                                                                           
(2) p 6, sec 5.2.  IOAM domains bounded by hosts                                                                                                                                                                                                                                                                                                                                           
                                                                                                                                                                                                                                                                                                                                                                                           
  For deployments where the IOAM domain is bounded by hosts, hosts will                                                                                                                                                                                                                                                                                                                   
  perform the operation of IOAM data field encapsulation and                                                                                                                                                                                                                                                                                                                               
  decapsulation.  IOAM data is carried in IPv6 packets as Hop-by-Hop or                                                                                                                                                                                                                                                                                                                   
  Destination options as specified in this document.                                                                                                                                                                                                                                                                                                                                       
                                                                                                                                                                                                                                                                                                                                                                                           
For clarity, does this mean that in this case that there is presumably no need to encapsulate the host packet within a separate IPv6 packet, and the OAM extension header could be embedded directly when the v6 header of the host packet is being constructed?                                                                                                                           
                                                                                                                                                                                                                                                                                                                                                                                           
                                                                                                                                                                                                                                                                                                                                                                                           
(3) p 7, sec 5.4.1.  IP-in-IPv6 encapsulation with ULA                                                                                                                                                                                                                                                                                                                                     
                                                                                                                                                                                                                                                                                                                                                                                           
    An                                                                                                                                                                                                                                                                                                                                                                                     
  IPv6 header including IOAM data fields in an extension header is                                                                                                                                                                                                                                                                                                                         
  added in front of it, to forward traffic within and across the IOAM                                                                                                                                                                                                                                                                                                                     
  domain.                                                                                                                                                                                                                                                                                                                                                                                 
                                                                                                                                                                                                                                                                                                                                                                                           
Rather than saying add an IPv6 in front of it, wouldn't be more accurate to say that it is being encapsulated with an IPv6 header including the IOAM data fields?                                                                                                                                                                                                                           
                                                                                                                                                                                                                                                                                                                                                                                           
                                                                                                                                                                                                                                                                                                                                                                                           
(4) p 7, sec 5.4.1.  IP-in-IPv6 encapsulation with ULA                                                                                                                                                                                                                                                                                                                                     
                                                                                                                                                                                                                                                                                                                                                                                           
    IPv6 addresses for the IOAM Overlay Network, i.e. the outer                                                                                                                                                                                                                                                                                                                           
  IPv6 addresses are assigned from the ULA space.  Addressing and                                                                                                                                                                                                                                                                                                                         
  routing in the IOAM Overlay Network are to be configured so that the                                                                                                                                                                                                                                                                                                                     
  IP-in-IPv6 encapsulated packets follow the same path as the original,                                                                                                                                                                                                                                                                                                                   
  non-encapsulated packet would have taken.  This would create an                                                                                                                                                                                                                                                                                                                         
  internal IPv6 forwarding topology using the IOAM domain's interior                                                                                                                                                                                                                                                                                                                       
  ULA address space which is parallel with the forwarding topology that                                                                                                                                                                                                                                                                                                                   
  exists with the non-IOAM address space (the topology and address                                                                                                                                                                                                                                                                                                                         
  space that would be followed by packets that do not have supplemental                                                                                                                                                                                                                                                                                                                   
  IOAM information).  Establishment and maintenance of the parallel                                                                                                                                                                                                                                                                                                                       
  IOAM ULA forwarding topology could be automated, e.g., similar to how
  LDP [RFC5036] is used in MPLS to establish and maintain an LSP
  forwarding topology that is parallel to the network's IGP forwarding
  topology.

Maintaining a separate ULA forwarding topology seems to introduce a certain level of additional complexity.  Is there any risk of the parallel forwarding plane programming lagging behind the non-IOAM topology such that different paths through the network would be taken?


(5) p 8, sec 6.  Security Considerations

  As this document describes new options for IPv6, these are similar to
  the security considerations of [RFC8200] and the weakness documented
  in [RFC8250].

Are there any security considerations relative to using ULA addressing for encapsulating the traffic that should be documented here?

Regards,
Rob

[Ballot discuss]
# Internet AD comments for draft-ietf-ippm-ioam-ipv6-options-09
CC @ekline

* Thanks to 6MAN chairs Bob, Ole, and Jen for their last-minute
  "IPv6 Directorate" reviews.  Some of their comments are reflected below.

* There was kind of leaning toward concluding that the rewriting of a
  Hop-by-Hop option's size was both against the spirit of RFC 8200 and
  not actually against the letter.  I'm not sure that's actually the case
  and so my biggest DISCUSS is this point (more below).

## Discuss

### S4

* I don't think the Incremental Trace Option is something that can be
  supported by current text in RFC 8200.  While is makes sense to have this
  behavior described in RFC 9197, I don't think IPv6 HbH can support it.

  My rationale for seeing this as a protocol violation is as follows.

    - RFC 8200 S4.2 says this about the on-path mutability bit and the
      expectations that result:

      """
      The third-highest-order bit of the Option Type specifies whether or
      not the Option Data of that option can change en route to the
      packet's final destination.  When an Authentication header is present
      in the packet, for any option whose data may change en route, its
      entire Option Data field must be treated as zero-valued octets when
      computing or verifying the packet's authenticating value.
      """

    - Specifically, only the Option Data (not Option Length) is allowed to
      change.  Any AH header, for example, would still have processed the
      entire option with only the Data being zeroed -- the existence of the
      option and the length of it would still have been part of the AH
      computation.

  Unless there's some misunderstanding here I think this option would need
  removing from the document.

* I think text needs to be added to make it clear that whatever options are
  used they MUST be added, though not necessarily "filled in", by the
  originator of the packet (the node bearing the interface assigned the
  outermost Source Address).

  The reasoning here again is the defined behavior of AH processing.  Any
  options, even on-path mutable ones, MUST be present in the Hop-by-Hop
  option when an AH is computed.

[Ballot comment]

## Comments

### S5.1

* In C2: "domain SHOULD ensure that the addition of OAM information does not
  lead to fragmentation of the packet"

  This should probably be rephrased to be more IPv6-compatible (as there is
  no on-path fragmentation).  Perhaps:

  "does not lead to an ICMP Packet To Big error message being sent to the
  originator and the packet being dropped"

  or something to that effect.

* Also in C2: "exceeds the packet size beyond PTMU" in the domain, etc.

  It may be worth noting that any single node can only know the configured
  MTU of its outgoing links, and that this is why it MUST be a domain-managed
  parameter.

* C3 appears to create a requirement for some very deep packet inspection on
  IOAM domain egress.

  Also, if there's going to be talk of ICMPv6 you probably need to add a
  reference to RFC 4443.

* With respect to C4, I'd defer to the other IESG comments.

* C5: this seems like it might be important for a Standards Track feature?

  If it were Experimental, perhaps, then there could be text saying that
  learning how this might best be done was an expected outcome of the
  experiment?

[Ballot discuss]
Hi There,

Firstly thanks for the document.  I have two issues I'd like to discuss and see if we can find some clarity on.

The first stems from RFC8200 Section 4.8 Third Paragraph, which reads:

New hop-by-hop options are not recommended because nodes may be
  configured to ignore the Hop-by-Hop Options header, drop packets
  containing a Hop-by-Hop Options header, or assign packets containing
  a Hop-by-Hop Options header to a slow processing path.  Designers
  considering defining new hop-by-hop options need to be aware of this
  likely behavior.  There has to be a very clear justification why any
  new hop-by-hop option is needed before it is standardized.

I believe that the document potentially needs to spell out a clearer justification to meet the requirements laid out in the above text.

The second question relates to dealing with IOAM in the context of SRv6.  With the HbH option - this is processed on a hop-by-hop basis and, as per RFC8200, is placed directly after the IPv6 header.  This I don't see as a problem.  My question comes in the case of the destination option.  In SRv6, where a SID is, for all intents and purposes, acting like an address - I'd like to see some text dealing with what happens when the DO is applied in the context of the SRv6 where the destination address is not a normal address - but rather an IPv6 SID.  Does the router drop the entire packet?  Does the router "de-encap" as if it were a tunneled packet? Basically - I see a situation where that could lead to undefined behavior that always makes me nervous.

Could the authors, therefore, expand slightly on how the destination option is handled in the context of SRv6 and its various flavors?

[Ballot comment]
I spent a while oscillating between DISCUSS and NoObjection when balloting on this document, before finally settling on Abstain (a non-blocking position).

Like others, I have concerns about what happens when IOAM EH packets invariably leak outside the IOAM domain. My views align very strongly with John Scudder's, but seeing as he is already carrying the DISCUSS, I'm going to cowardly abstain and hide behind him.

The document feels like it is creating something very similar to a "limited domain"; the reason that I'm not balloting DISCUSS is that the document "feels" like it is trying to minimize the damage when IOAM packets do leak. This includes "failing closed" ('IOAM MUST be explicitly enabled per interface on every node within the IOAM domain'). I am, however, quite troubled by the "As additional security, IOAM domains MUST provide a mechanism to prevent unauthorized injections at ingress or leaks at egress." without actually stating how this would be performed.

The fact that the IOAM data is information (it doesn't obfuscate the source of the traffic, nor (hopefully!) change routing / forwarding) also helps push this from DISCUSS to Abstain for me - when a domain *does* leak packets with IOAM info, they will either exceed the MTU and so be dropped, or will "just" be leaking traffic stats from that domain, and should otherwise be forwarded OK.

There are some Considerations in Sec 5 which I think are unrealistic, but not harmful - for example:
* I suspect that in some cases adding IOAM will change ECMP hashing (C1);
* they *will* leak (C3), but this shouldn't break things;
* they *will* leak (C4), but I suspect that external devices will simply ignore the EH header;


I have a horrible feeling that I'm being inconsistent with my balloting: normally I would ballot DISCUSS on documents which either add information to an in-flight packet, or which create any sort of closed domain, but in this case I feel that the document has sufficiently attempted to mitigate the (external) consequences of leaks that I'm choosing Abstain instead.

[Ballot discuss]
# John Scudder, RTG AD, comments for draft-ietf-ippm-ioam-ipv6-options-09
CC @jgscudder

## DISCUSS

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

### Structure of the document; Section 5 is vague

The first part of the document, through Section 4, is unproblematic for me -- you're simply allocating some IPv6 extension header option types and defining how to use them to transport fields you defined in RFC 9197. Fine.

But Section 5 is giving me a headache. For some reason, even though this is a Standards Track document, you've structured it as some rather high-level "considerations" (or are they "requirements"? It's unclear) and then some generally-worded polite suggestions about how you could deploy it this way or that way.

Is there some reason you've shied away from being prescriptive in Section 5? As the document stands, I felt a bit like I'd been presented with a puzzle. "The solution of this problem is left as an exercise for the student" is great in textbooks, but not so wonderful in Standards Track documents.

### Section 5.1, C5 is problematic

```
An Autonomous System (AS) that inserts and leaks the IOAM data needs to be easy to identify for the purpose of troubleshooting, due to the high complexity in identifying the source of the leak. Such a troubleshooting process might require coordination between multiple operators, complex configuration verification, packet capture analysis, etc. This requirement may require additional option or fields to be defined to identify the domain that inserted the IOAM data, this is out of the scope of this document.
```

First, just as in C4, the underlying assumption that it's OK if an AS "leaks the IOAM data" appears problematic.

Second, how can you both say "this is a requirement" and in the same paragraph "it's out of scope"? Surely, if this functionality is required, a finished spec is required to support it. And if the spec isn't finished, we shouldn't be advancing it, the WG should take it up and finish it, then send it back when done.

Is it that this isn't truly a requirement? Or is the spec incomplete? If neither, please help me understand.

[Ballot discuss]
# John Scudder, RTG AD, comments for draft-ietf-ippm-ioam-ipv6-options-09
CC @jgscudder

## DISCUSS

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

### Structure of the document; Section 5 is vague

The first part of the document, through Section 4, is unproblematic for me -- you're simply allocating some IPv6 extension header option types and defining how to use them to transport fields you defined in RFC 9197. Fine.

But Section 5 is giving me a headache. For some reason, even though this is a Standards Track document, you've structured it as some rather high-level "considerations" (or are they "requirements"? It's unclear) and then some generally-worded polite suggestions about how you could deploy it this way or that way.

Is there some reason you've shied away from being prescriptive in Section 5? As the document stands, I felt a bit like I'd been presented with a puzzle. "The solution of this problem is left as an exercise for the student" is great in textbooks, but not so wonderful in Standards Track documents.

### Section 5.1, C5 is problematic

```
An Autonomous System (AS) that inserts and leaks the IOAM data needs to be easy to identify for the purpose of troubleshooting, due to the high complexity in identifying the source of the leak. Such a troubleshooting process might require coordination between multiple operators, complex configuration verification, packet capture analysis, etc. This requirement may require additional option or fields to be defined to identify the domain that inserted the IOAM data, this is out of the scope of this document.
```

First, just as in C4, the underlying assumption that it's OK if an AS "leaks the IOAM data" appears problematic.

Second, how can you both say "this is a requirement" and in the same paragraph "it's out of scope"? Surely, if this functionality is required, a finished spec is required to support it. And if the spec isn't finished, we shouldn't be advancing it, the WG should take it up and finish it, then send it back when done.

Is it that this isn't truly a requirement? Or is the spec incomplete? If neither, please help me understand.

[Ballot discuss]
# John Scudder, RTG AD, comments for draft-ietf-ippm-ioam-ipv6-options-09
CC @jgscudder

## DISCUSS

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

### Structure of the document; Section 5 is vague

The first part of the document, through Section 4, is unproblematic for me -- you're simply allocating some IPv6 extension header option types and defining how to use them to transport fields you defined in RFC 9197. Fine.

But Section 5 is giving me a headache. For some reason, even though this is a Standards Track document, you've structured it as some rather high-level "considerations" (or are they "requirements"? It's unclear) and then some generally-worded polite suggestions about how you could deploy it this way or that way.

Is there some reason you've shied away from being prescriptive in Section 5? As the document stands, I felt a bit like I'd been presented with a puzzle. "The solution of this problem is left as an exercise for the student" is great in textbooks, but not so wonderful in Standards Track documents.

### Section 5.1, C5 is problematic

```
An Autonomous System (AS) that inserts and leaks the IOAM data needs to be easy to identify for the purpose of troubleshooting, due to the high complexity in identifying the source of the leak. Such a troubleshooting process might require coordination between multiple operators, complex configuration verification, packet capture analysis, etc. This requirement may require additional option or fields to be defined to identify the domain that inserted the IOAM data, this is out of the scope of this document.
```

First, just as in C4, the underlying assumption that it's OK if an AS "leaks the IOAM data" appears problematic.

Second, how can you both say "this is a requirement" and in the same paragraph "it's out of scope"? Surely, if this functionality is required, a finished spec is required to support it. And if the spec isn't finished, we shouldn't be advancing it, the WG should take it up and finish it, then send it back when done.

Is it that this isn't truly a requirement? Or is the spec incomplete? If neither, please help me understand.

[Ballot discuss]
# John Scudder, RTG AD, comments for draft-ietf-ippm-ioam-ipv6-options-09
CC @jgscudder

## DISCUSS

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

### Structure of the document; Section 5 is vague

The first part of the document, through Section 4, is unproblematic for me -- you're simply allocating some IPv6 extension header option types and defining how to use them to transport fields you defined in RFC 9197. Fine.

But Section 5 is giving me a headache. For some reason, even though this is a Standards Track document, you've structured it as some rather high-level "considerations" (or are they "requirements"? It's unclear) and then some generally-worded polite suggestions about how you could deploy it this way or that way.

Is there some reason you've shied away from being prescriptive in Section 5? As the document stands, I felt a bit like I'd been presented with a puzzle. "The solution of this problem is left as an exercise for the student" is great in textbooks, but not so wonderful in Standards Track documents.

### Section 5.1, C5 is problematic

```
An Autonomous System (AS) that inserts and leaks the IOAM data needs to be easy to identify for the purpose of troubleshooting, due to the high complexity in identifying the source of the leak. Such a troubleshooting process might require coordination between multiple operators, complex configuration verification, packet capture analysis, etc. This requirement may require additional option or fields to be defined to identify the domain that inserted the IOAM data, this is out of the scope of this document.
```

First, just as in C4, the underlying assumption that it's OK if an AS "leaks the IOAM data" appears problematic.

Second, how can you both say "this is a requirement" and in the same paragraph "it's out of scope"? Surely, if this functionality is required, a finished spec is required to support it. And if the spec isn't finished, we shouldn't be advancing it, the WG should take it up and finish it, then send it back when done.

Is it that this isn't truly a requirement? Or is the spec incomplete? If neither, please help me understand.

[Ballot discuss]
# John Scudder, RTG AD, comments for draft-ietf-ippm-ioam-ipv6-options-09
CC @jgscudder

## DISCUSS

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

### Structure of the document; Section 5 is vague

The first part of the document, through Section 4, is unproblematic for me -- you're simply allocating some IPv6 extension header option types and defining how to use them to transport fields you defined in RFC 9197. Fine.

But Section 5 is giving me a headache. For some reason, even though this is a Standards Track document, you've structured it as some rather high-level "considerations" (or are they "requirements"? It's unclear) and then some generally-worded polite suggestions about how you could deploy it this way or that way.

Is there some reason you've shied away from being prescriptive in Section 5? As the document stands, I felt a bit like I'd been presented with a puzzle. "The solution of this problem is left as an exercise for the student" is great in textbooks, but not so wonderful in Standards Track documents.

### Section 5.1, C5 is problematic

```
An Autonomous System (AS) that inserts and leaks the IOAM data needs to be easy to identify for the purpose of troubleshooting, due to the high complexity in identifying the source of the leak. Such a troubleshooting process might require coordination between multiple operators, complex configuration verification, packet capture analysis, etc. This requirement may require additional option or fields to be defined to identify the domain that inserted the IOAM data, this is out of the scope of this document.

```

First, just as in C4, the underlying assumption that it's OK if an AS "leaks the IOAM data" appears problematic.

Second, how can you both say "this is a requirement" and in the same paragraph "it's out of scope"? Surely, if this functionality is required, a finished spec is required to support it. And if the spec isn't finished, we shouldn't be advancing it, the WG should take it up and finish it, then send it back when done.

Is it that this isn't truly a requirement? Or is the spec incomplete? If neither, please help me understand.

[Ballot discuss]
# John Scudder, RTG AD, comments for draft-ietf-ippm-ioam-ipv6-options-09
CC @jgscudder

## DISCUSS

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

### Structure of the document; Section 5 is vague

The first part of the document, through Section 4, is unproblematic for me -- you're simply allocating some IPv6 extension header option types and defining how to use them to transport fields you defined in RFC 9197. Fine.

But Section 5 is giving me a headache. For some reason, even though this is a Standards Track document, you've structured it as some rather high-level "considerations" (or are they "requirements"? It's unclear) and then some generally-worded polite suggestions about how you could deploy it this way or that way.

Is there some reason you've shied away from being prescriptive in Section 5? As the document stands, I felt a bit like I'd been presented with a puzzle. "The solution of this problem is left as an exercise for the student" is great in textbooks, but not so wonderful in Standards Track documents.

### Section 5.1, C5 is problematic

```
An Autonomous System (AS) that inserts and leaks the IOAM data needs to be easy to identify for the purpose of troubleshooting, due to the high complexity in identifying the source of the leak. Such a troubleshooting process might require coordination between multiple operators, complex configuration verification, packet capture analysis, etc. This requirement may require additional option or fields to be defined to identify the domain that inserted the IOAM data, this is out of the scope of this document.
```

First, just as in C4, the underlying assumption that it's OK if an AS "leaks the IOAM data" appears problematic.

Second, how can you both say "this is a requirement" and in the same paragraph "it's out of scope"? Surely, if this functionality is required, a finished spec is required to support it. And if the spec isn't finished, we shouldn't be advancing it, the WG should take it up and finish it, then send it back when done.

Is it that this isn't truly a requirement? Or is the spec incomplete? If neither, please help me understand.

[Ballot comment]
## COMMENTS

These comments are non-blocking, but I'd still appreciate responses.

### Section 4, a particular interface

```
Unless a particular interface is explicitly enabled (i.e., explicitly configured) for IOAM, a router MUST ignore IOAM Options.
```

I suppose what you mean is, the router MUST ignore IOAM Options on packets received on that interface? If so, please say so. (If not, let's discuss.)

### Section 4, 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, Trace-Type constraints

```
In addition, to maintain IPv6 extension header 8-octet alignment and avoid the need to add or remove padding at every hop, the Trace-Type for Incremental Trace Option in IPv6 MUST be selected such that the IOAM node data length is a multiple of 8-octets.
```

I spent some time trying to understand exactly what it means for the Trace-Type to be selected such that, etc. I suppose this isn't too complicated in the end, since all the types defined in RFC 9197 are either four- or eight-byte fields. I don't see an explicit pad field being defined, though, so I wonder if it would be a helpful hint to note that the Opaque State Snapshot with Length 0 and Schema ID 0xFFFFFF can be used as a four-octet pad if needed. I see you use 0xFFFFFFFF as a pad in some places in RFC 9197, but there's no corresponding Trace-Type and it doesn't seem prudent to just poach a currently undefined bit to indicate the pad. I guess the other alternative would be to allocate a new Trace-Type bit to explicitly indicate a four-byte pad field, but given you can use Opaque State for this purpose, I don't see why you'd burn the bit.

Anyway, if I've missed some explicit way eight-byte alignment is supported in RFC 9197, please point it out to me? Otherwise, I think you need to be clearer about this, to discourage implementors from exercising "creativity".

### Section 5.1, C3, entities that communicate the errors

```
The entities that communicate the errors to devices outside of the IOAM domain MUST remove any IOAM data from the packet included in the error message
```

This is quite non-specific. Who are “the entities“ in this context? The host or router that originates the ICMP report? The router that forwards it outside the domain? If the former, I guess that means every entity within the domain that might originate an ICMP message has to know a priori if it's sending its message to an internal or external recipient. If the latter, that's a notable new requirement on border routers.

### Section 5.1, C4 violates closed domain

```
OAM data leaks can affect the forwarding behavior and state of network elements outside an IOAM domain. IOAM domains MUST provide a mechanism to prevent data leaks or be able to ensure that if a leak occurs, network elements outside the domain are not affected (i.e., they continue to process other valid packets).
```

I have a few difficulties with C4. Among them --

- The first sentence is quite nonspecific, I don't know if you have some actual failure modes in mind but I suppose you must. Can you elucidate?
- The second sentence, starting with "or", appears to violate the limited domain assumption, or at the least, it introduces a creative understanding of it ("go ahead and leak as long as you're sure the leaks are fine").
- I don't understand how an operator could possibly fulfill the "or" clause with confidence since by definition whatever is happening outside the border of the limited domain is not under the control of, or even necessarily known to, the operator.

My guess is that you're trying to motivate the ULA deployment option here, without talking about it specifically. Is that right?

### Section 5.1, C6 is inaccurate

```
Compliance with [RFC8200] requires OAM data to be encapsulated instead of header/option insertion directly into in-flight packets using the original IPv6 header.
```

I don't think you mean the OAM data (by which I think you mean IOAM data) needs to be encapsulated, but rather that it needs to be within an encapsulation header? That's what's implied by your Deployment Options section, anyway. If so, please say so, if not, let's discuss.

Assuming I've guessed correctly, a possible rewrite could look something like

```
[RFC8200] precludes insertion of IOAM data directly into the original IPv6 header of in-flight packets. Therefore, in order to add IOAM data, in-flight packets must be encapsulated in an outer header, and the IOAM data added to that header.
```

### Section 5.1, C7, wording

```
Hence when the IOAM Incremental Trace Option-Type is used in the deployment the RemainingLen field of the option MUST follow the guidance in [RFC9197] and must be computed and set appropriately.
```

I assume you mean "used in deployment" and didn't intend the definite article (which would imply you're talking about a specific deployment). But I think instead of just dropping "the", you might as well go ahead and drop "in the deployment" (where else is it going to be used after all, where this guidance wouldn't apply?).

### Section 5.1, C7, lack of specificity

```
The IOAM Incremental Trace Option-Type expands the option length that may affect the processing of extension headers and options that follow IOAM options. Hence when the IOAM Incremental Trace Option-Type is used in the deployment the RemainingLen field of the option MUST follow the guidance in [RFC9197] and must be computed and set appropriately.
```

What guidance, exactly, is supposed to be followed? I dug around in RFC 9197 and the best guess I could come up with is

```
The sender MAY calculate the value of the RemainingLen field by computing the number of node data bytes allowed before exceeding the PMTU, given that the PMTU is known to the sender.
```

I'm not very happy with that guess, because it doesn't seem to be responsive to the problem you've posed. What I've quoted from RFC 9197 is a way to avoid exceeding the PMTU, but in the present document you've posed the concern that if you shove too much data into the IOAM header, other extension headers may be ignored. That's not the same as PMTU, which relates to total packet size, not header options size.

Whatever it is you're trying to do here, I think you need to be more specific about it.

### Section 5.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 5.3, encapsulation again

This one is less misleading, but by analogy to 5.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."

### Section 5.4.1 infeasible requirement

```
Addressing and routing in the IOAM Overlay Network are to be configured so that the IP-in-IPv6 encapsulated packets follow the same path as the original, non-encapsulated packet would have taken.
```

This doesn't seem to be feasible in the face of ECMP.

### Section 5.4.2, wording

```
In this case IOAM can be encapsulated in as an extension header in the tunnel (outer) IPv6 header.
```

Is the "as" unintended in the quoted text? If so, please remove it, if not, I don't understand the meaning.

## NITS

### Section 5.1

"if IOAM is used in in transit devices"

s/in in/in/

### Section 5.4

"This section lists out"

Just "lists", no "out".

### 5.4.1

"almost close to zero"

I assume you mean either "almost zero" or "close to zero". Because as written, I would parse "almost close to zero" as "not close to zero" which is probably not what you're going for.

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

# Éric Vyncke, INT AD, comments for draft-ietf-ippm-ioam-ipv6-options-09
CC @evyncke

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 Marcus Ihlar for the shepherd's detailed write-up including the WG consensus *and* the justification of the intended status.

Please note that Dave Thaler is the Internet directorate reviewer (at my request) and you may want to consider this int-dir reviews as well when Tim will complete the review (no need to wait for it though):
https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-ipv6-options/reviewrequest/16642/

I hope that this review helps to improve the document,

Regards,

-éric


## DISCUSS

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

### Section 5.1

```
      Operators of an IOAM
      domain SHOULD ensure that the addition of OAM information does not
      lead to fragmentation of the packet, e.g., by configuring the MTU
      of transit routers and switches to a sufficiently high value.
```
Should it be a MUST as IPv6 routers are unable to fragment an IPv6 packet ? Should "e.g." be replaced by "i.e." ?

Roman's DISCUSS points are also sensible.

[Ballot comment]

## COMMENTS

### Encapsulation

In the abstract and introduction, it is written that "IOAM options are encapsulated in IPv6". I am unsure whether this is the right wording as it is the original packet that is encapsulated and then IOAM options added. Suggest to simply use "IOAM option are transported in IPv6 packets".

It also seems to prevent the use of IOAM by the source node, which appears to me as an important use case (e.g., video conferencing).

### Section 2

As written by others, the location of the contributors is at a weird location.

### Section 4

`IOAM data fields can be encapsulated in "option data" fields` is hard to parse even for an IPv6-aware person. Is it "option data" as in the diagram below ? Or is it the option fields of HbH & DO as defined in RFC 8200.

Does every interface really need to be IOAM enabled ? It seems that not enabling on interface will only degrade the collected information but would still be useful.

`a router MUST ignore IOAM Options` what about a host (i.e., not a router) receiving a packet with a destination option containing an IOAM option ?

The Reserved field must be set to 0 on transmission, does it include also when it is received in HbH ? I.e., then re-transmitted to the next node ? Suggest to use "set to 0 by the source".

### Section 5.1

To be honest, I was about to mark those comments as blocking discuss points.

In C1:
```
    Implementations of IOAM SHOULD ensure that ECMP
      behavior for packets with and without IOAM data fields is the
      same.
```
What about non-IOAM-aware routers (or even not routers like LACP bundles)? Is it the reason why all routers need to support IOAM as specified in section 4 ?

In C2: `which is intended to support hardware implementations of IOAM, ` seems weird. Is it about "which is intended to be used only by hardware-supported implementation" ?

In C3, I am afraid that I cannot really parse this consideration. E.g., what is meant by "associated ICMP errors" ? Is it ICMP packet generated by an IOAM-domain router containing IOAM options (my guess) ? If the original packet is encapsulated (per the rest of this I-D), how could an ICMP sent back to the encapsulating node be sent further once decapsulated ?

C4, does "data leak" means a "packet with IOAM data leaking outside of the IOAM domain" ?

Unsure about the usefulness of C5.

### Section 5.2

The use of "encapsulation" and "decapsulation" appears weird in a host processing.

### Section 5.4

Should it be a sub-section of 5.3 ? (IOAM bounded by network devices)

### Section 5.4.1

Unsure whether there could be a real use case of using ULA just for IOAM... Suggest to remove this section.

### Section 5.4.2

Please add reference to VXLAN and Geneve.

## NITS

### Capitalized Extension header

Some occurrence of `Extension header`, unsure whether "extension" should be capitalized though.

### IOAM or in-situ OAM

Suggest to always use either "IOAM" or "in-situ OAM" and not the current mix.

### Section 5.1

s/that/than/ in `should follow the same path within the domain that an identical` ?

## 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]
I support Roman's DISCUSS points.


NITS: It is non-standard to list contributors at the start of the document. Usually this is done in an acknowledgement section at the end of the document. Any reason why not to move the Contributors section just before or within the Acknowledgement section ?

are encapsulated in the IPv6  -> are encapsulated in IPv6

[Ballot discuss]
Section 4 and RFC9197 seem clear that IOAM traffic cannot leave the IOAM domain.  However, this document seems to be suggesting behavior that violates this guidance.  Specifically, in Section 5.1, it allows for the possibility of leaks per (a) and explicitly describe a use case where leaks are intentional (b).

(a) Section 5.1.  C3.
      IOAM domains MUST
      provide a mechanism to prevent data leaks or be able to ensure
      that if a leak occurs, network elements outside the domain are not
      affected (i.e., they continue to process other valid packets).

(b) Section 5.1. C5.
      An Autonomous System (AS) that inserts and leaks the IOAM data
      needs to be easy to identify for the purpose of troubleshooting,...

Furthermore, per (a), why are “IOAM domains … provid[ing] a mechanism” which suggests a feature rather than a required to explicitly prevent this behavior.

[Ballot comment]
** Section 4.
  As
  additional security, IOAM domains MUST provide a mechanism to prevent
  unauthorized injections at ingress or leaks at egress.

No disagreement.  To clarify, is this a new requirement? I thought this configuration was the mandatory architecture of IOAM.  Per RFC9197:

  Notably, IOAM is expected to be deployed in limited domains, thus
  confining the potential attack vectors to within the limited domain.
  A limited administrative domain provides the operator with the means
  to select, monitor, and control the access of all the network
  devices, making these devices trusted by the operator.  Indeed, in
  order to limit the scope of threats mentioned above to within the
  current limited domain, the network operator is expected to enforce
  policies that prevent IOAM traffic from leaking outside of the IOAM-
  Domain and prevent IOAM data from outside the domain to be processed
  and used within the domain.

** Section 4.  Please be explicit on where the Option Data is specified.  I believe it is:

-- For the “Pre-allocated Traction Option” and “Incremental Trace Option”, Section 4.4 of RFC9197

-- For the “Proof of Transition Option”, Section 4.5 of RFC9197

-- For the “Edge to Edge Option”, Section 4.6 of RFC9197

-- For the “Direct Export Option” Section 3.2 of RFC9326

** Section 5.1.  C3.
      Packets with IOAM data or associated ICMP errors, should not
      arrive at destinations that have no knowledge of IOAM.  For
      example, if IOAM is used in in transit devices, misleading ICMP
      errors due to addition and/or presence of OAM data in a packet
      could confuse the host that sent the packet if it did not insert
      the OAM information. 

Is the expectation that any entity which adds IOAM headers (either at the source or in transit) will know if a destination in the IOAM domain supports these headers?  If so, is that realistic (not knowing where this is currently, or anticipated to be, fielded)?.

** Section 5.1.  C3.

      The entities that communicate the errors to
      devices outside of the IOAM domain MUST remove any IOAM data from
      the packet included in the error message.

The completeness of this guidance seems to depend on how one reads “the entities that communicate the error” – is it the IOAM hosts or also the network devices at the edge of the IOAM domain.  I took it to mean hosts per the deployment model defined in Section 5.2. (IOAM domains bounded by hosts) which would be insufficient.  Could this text please be made clearer to cover the deployment models described in 5.2 and 5.3.

Editorial

** Section 4.  Typo. s/inSection 7/in Section 7/

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

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

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

In the Destination Options and Hop-by-Hop Options registry on the Internet Protocol Version 6 (IPv6) Parameters registry page located at:

https://www.iana.org/assignments/ipv6-parameters/

two existing, temporary registrations will be made permanent and their references changed to [ RFC-to-be ] as follows:

Hex Value: 0x11
Binary Value (act): 00
Binary Value (chg): 0
Binary Value (rest): 10001
Description: IOAM
Reference: [ RFC-to-be ]

Hex Value: 0x31
Binary Value (act): 00
Binary Value (chg): 1
Binary Value (rest): 10001
Description: IOAM
Reference: [ RFC-to-be ]

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,

Michelle Thangtamsatid
IANA Services Specialist

The following Last Call announcement was sent out (ends 2022-07-01):

From: The IESG
To: IETF-Announce
CC: draft-ietf-ippm-ioam-ipv6-options@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:  (In-situ OAM IPv6 Options) to Proposed Standard


The IESG has received a request from the IP Performance Measurement WG (ippm)
to consider the following document: - 'In-situ OAM IPv6 Options'
  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-07-01. 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) records
  operational and telemetry information in the packet while the packet
  traverses a path between two points in the network.  This document
  outlines how IOAM data fields are encapsulated in IPv6.




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


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

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

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Proposed Standard, this is appropriate since this describes a common deployment option of the IOAM proposed standard.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

In-situ Operations, Administration, and Maintenance (IOAM) records operational and telemetry information in the packet while the packet traverses a path between two points in the network. This document outlines how IOAM data fields are encapsulated in IPv6

Working Group Summary:

To my knowledge the working group process has been fairly smooth and uncontroversial. The document was at first proposed to the 6man wokring group, but there it was decided that it would be more appropriate for ippm to take responsibility for it.

Document Quality:

The specification has good implementation support, in particular it has been implemented in the Linux kernel. Asside from a few small nits the shepherd has no concerns with the document quality.

Personnel:

Shepherd: Marcus ihlar
Responsible AD: Martin Duke

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

I have reviewed this document as part of the shepherding process. Furthermore, this document has received substantial review as part of the working group process.
With the exception from a few small nits this document shoudld be ready for publication.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No, reviews have been recived by ippm participants and 6man participants.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

No particular concerns.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

The authors have confirmed that, to their knowledge, there are no more IPR declarations other than https://datatracker.ietf.org/ipr/3529/.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

There is one IPR disclosure (https://datatracker.ietf.org/ipr/3529/) that references this document, it was done prior to WG adoption and I could not see much discussion about it.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

There seems to be pretty solid consensus, there's quite a large set of contributors and some good feedback from the 6man wg has been considered.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise 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.)

Not to my knowledge.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

The ID nits tool produced a single comment about the publication date of the document.
Nits found by me:
Section 4, paragraph 2 has a reference to section 4 of draft-ietf-ippm-ioam-data-17, this one should probably be to section 5 of that document.
Last paragraph of section 4 has a spelling mistake: lenght -> length. 

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

Not applicable.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

The two normative references that are not yet published RFCs are draft-ietf-ippm-ioam-data-17 which is in AUTH48 and draft-ietf-ippm-ioam-direct-export-07 which is under AD evaluation.

(15) Are there downward normative references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No

(17) 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 protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

This document adds two values to the the Destination Options and Hop-by-Hop Options sub-registry of IPv6 Parameters.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

Not applicable.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

Not applicable.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

Not applicable.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Proposed Standard, this is appropriate since this describes a common deployment option of the IOAM proposed standard.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

In-situ Operations, Administration, and Maintenance (IOAM) records operational and telemetry information in the packet while the packet traverses a path between two points in the network. This document outlines how IOAM data fields are encapsulated in IPv6

Working Group Summary:

To my knowledge the working group process has been fairly smooth and uncontroversial. The document was at first proposed to the 6man wokring group, but there it was decided that it would be more appropriate for ippm to take responsibility for it.

Document Quality:

The specification has good implementation support, in particular it has been implemented in the Linux kernel. Asside from a few small nits the shepherd has no concerns with the document quality.

Personnel:

Shepherd: Marcus ihlar
Responsible AD: Martin Duke

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

I have reviewed this document as part of the shepherding process. Furthermore, this document has received substantial review as part of the working group process.
With the exception from a few small nits this document shoudld be ready for publication.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No, reviews have been recived by ippm participants and 6man participants.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

No particular concerns.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

The authors have confirmed that, to their knowledge, there are no more IPR declarations other than https://datatracker.ietf.org/ipr/3529/.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

There is one IPR disclosure (https://datatracker.ietf.org/ipr/3529/) that references this document, it was done prior to WG adoption and I could not see much discussion about it.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

There seems to be pretty solid consensus, there's quite a large set of contributors and some good feedback from the 6man wg has been considered.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise 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.)

Not to my knowledge.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

The ID nits tool produced a single comment about the publication date of the document.
Nits found by me:
Section 4, paragraph 2 has a reference to section 4 of draft-ietf-ippm-ioam-data-17, this one should probably be to section 5 of that document.
Last paragraph of section 4 has a spelling mistake: lenght -> length. 

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

Not applicable.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

The two normative references that are not yet published RFCs are draft-ietf-ippm-ioam-data-17 which is in AUTH48 and draft-ietf-ippm-ioam-direct-export-07 which is under AD evaluation.

(15) Are there downward normative references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No

(17) 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 protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

This document adds two values to the the Destination Options and Hop-by-Hop Options sub-registry of IPv6 Parameters.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

Not applicable.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

Not applicable.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

Not applicable.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Proposed Standard, this is appropriate since this describes a common deployment option of the IOAM proposed standard.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

In-situ Operations, Administration, and Maintenance (IOAM) records operational and telemetry information in the packet while the packet traverses a path between two points in the network. This document outlines how IOAM data fields are encapsulated in IPv6

Working Group Summary:

To my knowledge the working group process has been fairly smooth and uncontroversial. The document was at first proposed to the 6man wokring group, but there it was decided that it would be more appropriate for ippm to take responsibility for it.

Document Quality:

The specification has good implementation support, in particular it has been implemented in the Linux kernel. Asside from a few small nits the shepherd has no concerns with the document quality.

Personnel:

Shepherd: Marcus ihlar
Responsible AD: Martin Duke

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

I have reviewed this document as part of the shepherding process. Furthermore, this document has received substantial review as part of the working group process.
With the exception from a few small nits this document shoudld be ready for publication.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No, reviews have been recived by ippm participants and 6man participants.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

No particular concerns.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Waiting for one of the two authors to respond to this, but the current indication is that there are no more IPR declarations other than https://datatracker.ietf.org/ipr/3529/.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

There is one IPR disclosure (https://datatracker.ietf.org/ipr/3529/) that references this document, it was done prior to WG adoption and I could not see much discussion about it.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

There seems to be pretty solid consensus, there's quite a large set of contributors and some good feedback from the 6man wg has been considered.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise 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.)

Not to my knowledge.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

The ID nits tool produced a single comment about the publication date of the document.
Nits found by me:
Section 4, paragraph 2 has a reference to section 4 of draft-ietf-ippm-ioam-data-17, this one should probably be to section 5 of that document.
Last paragraph of section 4 has a spelling mistake: lenght -> length. 

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

Not applicable.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

The two normative references that are not yet published RFCs are draft-ietf-ippm-ioam-data-17 which is in AUTH48 and draft-ietf-ippm-ioam-direct-export-07 which is under AD evaluation.

(15) Are there downward normative references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No

(17) 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 protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

This document adds two values to the the Destination Options and Hop-by-Hop Options sub-registry of IPv6 Parameters.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

Not applicable.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

Not applicable.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

Not applicable.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Proposed Standard, this is appropriate since this describes a common deployment option of the IOAM proposed standard.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

In-situ Operations, Administration, and Maintenance (IOAM) records operational and telemetry information in the packet while the packet traverses a path between two points in the network. This document outlines how IOAM data fields are encapsulated in IPv6

Working Group Summary:

To my knowledge the working group process has been fairly smooth and uncontroversial. The document was at first proposed to the 6man wokring group, but there it was decided that it would be more appropriate for ippm to take responsibility for it.

Document Quality:

The specification has good implementation support, in particular it has been implemented in the Linux kernel. Asside from a few small nits the shepherd has no concerns with the document quality.

Personnel:

Shepherd: Marcus ihlar
Responsible AD: Martin Duke

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

I have reviewed this document as part of the shepherding process. Furthermore, this document has received substantial review as part of the working group process.
With the exception from a few small nits this document shoudld be ready for publication.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No, reviews have been recived by ippm participants and 6man participants.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

No particular concerns.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Waiting for one of the two authors to respond to this, but the current indication is that there are no more IPR declarations other than https://datatracker.ietf.org/ipr/3529/.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

There is one IPR disclosure (https://datatracker.ietf.org/ipr/3529/) that references this document, it was done prior to WG adoption and I could not see much discussion about it.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

There seems to be pretty solid consensus, there's quite a large set of contributors and some good feedback from the 6man wg has been considered.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise 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.)

Not to my knowledge.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

The ID nits tool produced a single comment about the publication date of the document.
Nits found by me:
Section 4 has a reference to section 4 of draft-ietf-ippm-ioam-data-17, this one should probably be to section 5 of that document.
Last paragraph of section 4 has a spelling mistake: lenght -> length. 

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

Not applicable.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

The two normative references that are not yet published RFCs are draft-ietf-ippm-ioam-data-17 which is in AUTH48 and draft-ietf-ippm-ioam-direct-export-07 which is under AD evaluation.

(15) Are there downward normative references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No

(17) 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 protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

This document adds two values to the the Destination Options and Hop-by-Hop Options sub-registry of IPv6 Parameters.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

Not applicable.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

Not applicable.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

Not applicable.

Request for posting confirmation emailed to previous authors: Aviv Kfir , Barak Gafni , Carlos Pignataro , Frank Brockners , Hannes Gredler , John Leddy , Mark Smith , Mickey Spiegel , Petr Lapukhov , Rajiv Asati , Shwetha Bhandari , Stephen Youell , Suresh Krishnan , Tal Mizrahi , ippm-chairs@ietf.org

Request for posting confirmation emailed to previous authors: Aviv Kfir , Barak Gafni , Carlos Pignataro , Frank Brockners , Hannes Gredler , John Leddy , Mark Smith , Mickey Spiegel , Petr Lapukhov , Rajiv Asati , Shwetha Bhandari , Stephen Youell , Suresh Krishnan , Tal Mizrahi , ippm-chairs@ietf.org

Request for posting confirmation emailed to previous authors: Mickey Spiegel , Carlos Pignataro , Barak Gafni , Suresh Krishnan , Hannes Gredler , Aviv Kfir , Petr Lapukhov , Shwetha Bhandari , John Leddy , Rajiv Asati , ippm-chairs@ietf.org, Stephen Youell , Frank Brockners , Tal Mizrahi , Mark Smith

Request for posting confirmation emailed to previous authors: Frank Brockners , Stephen Youell , Tal Mizrahi , Barak Gafni , Rajiv Asati , ippm-chairs@ietf.org, Hannes Gredler , John Leddy , Suresh Krishnan , Aviv Kfir , Petr Lapukhov , Mickey Spiegel , Carlos Pignataro , Shwetha Bhandari

Request for posting confirmation emailed to previous authors: Barak Gafni , Carlos Pignataro , Stephen Youell , ippm-chairs@ietf.org, Mickey Spiegel , Hannes Gredler , Suresh Krishnan , Frank Brockners , Rajiv Asati , Tal Mizrahi , Petr Lapukhov , John Leddy , Aviv Kfir , Shwetha Bhandari

Request for posting confirmation emailed to previous authors: John Leddy , Stephen Youell , Carlos Pignataro , Tal Mizrahi , Hannes Gredler , Rajiv Asati , Mickey Spiegel , ippm-chairs@ietf.org, Frank Brockners , Barak Gafni , Suresh Krishnan , Shwetha Bhandari , Aviv Kfir , Petr Lapukhov