Re: [ippm] Alvaro Retana's No Objection on draft-ietf-ippm-ioam-conf-state-07: (with COMMENT)

[[e-mail]]

Hi Alvaro,







Thank you for the review and thoughtful comments.


Please check inline the proposed changes that will be incorporated into the next revision.






Best Regards,


Xiao Min







Original



From: AlvaroRetanaviaDatatracker <[e-mail]>
To: The IESG <[e-mail]>;
Cc: [e-mail] <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;
Date: 2022年10月26日 05:04
Subject: Alvaro Retana's No Objection on draft-ietf-ippm-ioam-conf-state-07: (with COMMENT)


Alvaro Retana has entered the following ballot position for
draft-ietf-ippm-ioam-conf-state-07: No Objection
 
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
 
 
Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/  
for more information about how to handle DISCUSS and COMMENT positions.
 
 
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-conf-state/
 
 
 
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------
 
 
The Abstract (and the corresponding text in the Introduction) is misleading:
 
   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.
 
This document describes an extension that *could be used* as mentioned above,
but it doesn't specify "an extension to the echo request/reply mechanisms used
in..."  Please clarify that the document describes a generic format.

[XM]>>> OK. Combining your comment and that one from Eric Vyncke on the abstract, I propose to change the abstract (and the corresponding text in the introduction) as below.

NEW

   This document describes a generic format for the echo request/reply   mechanisms used in IPv6, 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 Introduction later clarifies that "specification details for these
different echo request/reply protocols are outside the scope of this document".
 However, if the mentioned applications are expected to be the users of this
specification, the corresponding WGs (6man, spring, mpls, sfc, and bier) should
have been consulted.  I couldn't find anything in the archives to show
interaction.

[XM]>>> As far as I can tell, the cross-wg review and communication can always be improved. As to this case, the idea is that (like RFC9197) the main document defines a generic format that can be reused by some follow-on documents, avoiding repetitive definition of the same format in multiple documents. For IPv6 (including SRv6), draft-xiao-6man-icmpv6-ioam-conf-state has been submitted as the follow-on document, which was presented twice (at IETF 112 and 114) in 6man and some good discussions happened at the meeting and on the mailing list. For MPLS (including SR-MPLS), draft-xiao-mpls-lsp-ping-ioam-conf-state has been submitted as the follow-on document, which is on the agenda for mpls@IETF-115. For SFC and BIER, the follow-on documents are in the plan (note that one co-author of the main document is also the primary author of SFC echo request/reply and a co-author of BIER echo request/reply). You're right we authors could have done more consultations with the corresponding WGs, and I promise to make the improvement in the future.