[Gen-art] Genart last call review of draft-ietf-ippm-ioam-ipv6-options-08

[Joel Halpern via Datatracker <[e-mail]>]

Reviewer: Joel Halpern
Review result: Ready with Issues

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.