Re: [Last-Call] [Gen-art] Genart last call review of draft-ietf-ippm-ioam-conf-state-06

[Lars Eggert <[e-mail]>]

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 <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/gen-art