I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-ippm-ioam-ipv6-options-08
Reviewer: Joel Halpern
Review Date: 2022-06-28
IETF LC End Date: 2022-07-01
IESG Telechat date: Not scheduled for a telechat

Summary: If the issues identified below are addressed, this document will be ready for publication as a Proposed Standard RFC.

Major issues:
    Why is the domain boundary expectation in section 4 only a SHOULD?  Either there is no need to restrict it, or it is important and it is a MUST?  This comes up again in section 5.1 item C4.

Minor issues:
    The document uses the term IOAM extensively.  It expands the term as "In-situ Operations, Administration, and Maintenance".  While a good start, it would be very helpful if the document either defined IOAM or cited a definition.  The expansion does not explain what the difference is between IOAM and other forms of OAM, nor indicate what sorts of packets IOAM applies to.

    Section 5.1 (Considerations for IOAM deployment in IPv6 networks) requirement C1 seems to be an implementation requirement not a deployment requirement.  The text even ends with "Implementations of IOAM SHOULD..."  Why is this in a deployment considerations section?

    Requirement C3 in section 5.1 is very oddly worded.  It seems to say "X should not happen" but does not tell the implementor or deployer how to avoid having X occur.  I would recommend rewording.  (At a guess, something about how entities sending errors outside of an IOAM domain should remove any IOAM data??)

    Requirement C5 in 5.1 says that leaks need to be easily identified and attributed.  That's nice.  It doesn't seem to say HOW that is to be done.  So how does an implementor or deployer comply with the requirement?

     Could the description clause of the two IANA entries please use "IOAM destination option" and "IOAM hop-by-hop option" rather than describing them both just as "IOAM".

Nits/editorial comments:
    Given the problems of acronym overload and the sparse need for it, I would recommend not using the acronym ION (IOAM Overlay Network), and simply spelling that out in the few places it is needed.

    It would be helpful if section 5.3 (IOAM domains bounded by network devices) restated that such ingress edge devices will encapsulate the user packet, and put the IOAM option in the resulting encapsulating header.  And decapsulate at the egress.