Last Call Review of draft-ietf-ippm-ioam-conf-state-06
review-ietf-ippm-ioam-conf-state-06-genart-lc-mishra-2022-10-10-00

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-conf-state-??
Reviewer: Gyan Mishra
Review Date: 2022-10-10
IETF LC End Date: 2022-10-06
IESG Telechat date: Not scheduled for a telechat

Summary:
   This document describes an extension to the echo request/reply
   mechanisms used in IPv6 (including Segment Routing with IPv6 data
   plane (SRv6)), MPLS (including Segment Routing with MPLS data plane
   (SR-MPLS)), Service Function Chain (SFC) and Bit Index Explicit
   Replication (BIER) environments, which can be used within the In situ
   Operations, Administration, and Maintenance (IOAM) domain, allowing
   the IOAM encapsulating node to discover the enabled IOAM capabilities
   of each IOAM transit and IOAM decapsulating node.

The draft is well written and is almost ready for publication.

Major issues:
None

Minor issues:
I believe the draft should make more clear  the use of the capabilities
discovery extension throughout the draft that it applies to both IOAM data and
use of IOAM DEX “draft-ietf-ippm-ioam-direct-export-11” and if it applies to
one or the other to make that clear.  I can understand how it can easily apply
to IOAM Data but for IOAM DEX is based on an export off line postcard based
telemetry I am not sure how this extension could be applicable.  Also the
applicability to both use cases above should be explained in section 4
operational guide.

Nits/editorial comments:
Please review the SHOULD normative language where I think maybe MUST might be
appropriate

middle of page 6

   If there is no IOAM capability to be reported by the receiving node,
   then this container SHOULD be ignored by the receiving node, which
   means the receiving node SHOULD send an echo reply without IOAM
   capabilities or no echo reply, in the light of whether the echo
   request includes other containers than the IOAM Capabilities Query
   Container.

middle of page 7

   A list of IOAM capabilities objects (one
   or more objects) which contains the enabled IOAM capabilities SHOULD
   be included in this container of echo reply.

middle of page 8

   Namespace-ID field has the same definition as what's specified in
   Section 4.3 of [RFC9197], it should be one of the Namespace-IDs
   listed in the IOAM Capabilities Query Object of the echo request.

top of page 13

   For the echo reply, there
   should be an IOAM Capabilities Response Container containing one or
   more Objects.