Gyan, thank you for your review. I have entered a No Objection ballot for this document. Lars > On Oct 10, 2022, at 18:30, Gyan Mishra via Datatracker <noreply@xxxxxxxx> wrote: > > Reviewer: Gyan Mishra > 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-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. > > > _______________________________________________ > Gen-art mailing list > Gen-art@xxxxxxxx > https://www.ietf.org/mailman/listinfo/gen-art
Attachment:
signature.asc
Description: Message signed with OpenPGP
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
