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
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.
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
