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