Re: [IPv6] WG Adoption call for draft-xiao-6man-icmpv6-ioam-conf-state

Hi Chongfeng,

Thanks for your support and thoughtful review.

I believe all your comments can be addressed after wg adoption.

Please see inline...

Best Regards,

Xiao Min

Original

From: ChongfengXie <xiechf@chinatelecom.cn>
To: 肖敏10093570;Jen Linkova <furry13@gmail.com>;
Cc: IPv6 List <ipv6@ietf.org>;6man Chairs <6man-chairs@ietf.org>;
Date: 2022年12月06日 19:23
Subject: Re: Re: [IPv6]WG Adoption call for draft-xiao-6man-icmpv6-ioam-conf-state

Hi 6man chairs and all,

I support the adoption of this draft.

This document illustrates the IPv6 Node IOAM Information Query functionality, which enables the IOAM encapsulating node discover the enabled IOAM capabilities of each IOAM transit and decapsulating node. I think this is useful. 

[XM]>>> Thank you.

I also have two questions and one suggestion as below,

Q 1. From the perspective of time dimension, is the process described in this document before the process described in the document draft-ietf-ippm-ioam-ipv6-options?The latter describes how packets use the IOAM when they traverses a path between two points in the network。

[XM]>>> Yes, your're absolutely right.

Q 2.The type of this document is stand track, in which the approach described is based on IPv6 Node Information messages, but RFC4620 mentions that ‘it defines an Experimental Protocol for the Internet community.  It does not specify an Internet standard of any kind’. I don't know whether it is appropriate to define standard track type document based-on the experimental protocol?

[XM]>>> Good catch. I've mentioned the similar question in page 8 of my slides for IETF 115 presentation, and it's preferred to answer this question after wg adoption.

One suggestion：
The current document mainly introduces the message format. I suggest adding a figure to describe the the location of the different roles, e.g., IOAM encoding node, IOAM transit and decapitating node in the network. If necessary, the workflow can also be introduced based on this figure.

[XM]>>> I believe a reference to RFC 9197 would address your comment. RFC 9197 is the core spec for IOAM and it specifies what you want clearly. This draft doesn't change that in any way.

Best regards

Chongfeng

From: xiao.min2@zte.com.cn
Date: 2022-12-05 09:34
To: furry13@gmail.com
CC: ipv6@ietf.org; 6man-chairs@ietf.org
Subject: Re: [IPv6]WG Adoption call for draft-xiao-6man-icmpv6-ioam-conf-state

Hi Jen,

As a co-author, I support wg adoption of this draft.

Thanks!

Xiao Min

From: JenLinkova <furry13@gmail.com>
To: 6man <ipv6@ietf.org>;
Cc: 6man Chairs <6man-chairs@ietf.org>;
Date: 2022年12月03日 00:01
Subject: [IPv6] WG Adoption call for draft-xiao-6man-icmpv6-ioam-conf-state

This message starts a call on adopting the following draft as a 6MAN
working group document :

Title:   IPv6 Query for Enabled In-situ OAM Capabilities
Authors:        Xiao Min , Greg Mirsky
File Name:   draft-xiao-6man-icmpv6-ioam-conf-state-02
Datatracker: https://datatracker.ietf.org/doc/draft-xiao-6man-icmpv6-ioam-conf-state/

Substantive comments and statements of support for adopting this
document should be sent to the mailing list. Editorial suggestions can
be sent to the authors.

This adoption call will end on Dec 18th 2022, 23:59:59 UTC

--  
SY, Jen Linkova on behalf of 6MAN chairs.

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------