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

[[e-mail]]

Hi Gyan,





Thank you for the review and thoughtful comments.


I'v posted a new -07 revision, attempting to address your comments.


https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-conf-state-07


Please see inline my responses...





Best Regards,


Xiao Min



Original



From: GyanMishraviaDatatracker <[e-mail]>
To: [e-mail] <[e-mail]>;
Cc: [e-mail] <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;
Date: 2022年10月10日 23:30
Subject: Genart last call review of draft-ietf-ippm-ioam-conf-state-06


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.

[XM]>>> Thank you.


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.

[XM]>>> This draft applies to both IOAM Data and IOAM DEX. The updated draft has made it more clear as you suggested, specifically, both the introduction section and the operational guide section are updated.


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.

[XM]>>> OK.


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.

[XM]>>> OK.


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.

[XM]>>> OK. Several other places are also changed in the same way.


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

[XM]>>> Considering the quoted text is within the operational guide section, I prefer to remove the normative language.