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

xiao.min2@zte.com.cn Wed, 26 October 2022 07:40 UTC

Return-Path: <xiao.min2@zte.com.cn>
X-Original-To: ippm@ietfa.amsl.com
Delivered-To: ippm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDB98C14F735; Wed, 26 Oct 2022 00:40:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.905
X-Spam-Level:
X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, UNPARSEABLE_RELAY=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1g1aRjPZRG1Y; Wed, 26 Oct 2022 00:40:34 -0700 (PDT)
Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.216.63.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07B10C14F72C; Wed, 26 Oct 2022 00:40:32 -0700 (PDT)
Received: from mse-fl2.zte.com.cn (unknown [10.5.228.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mxhk.zte.com.cn (FangMail) with ESMTPS id 4My11q0GG7z4xVnp; Wed, 26 Oct 2022 15:40:31 +0800 (CST)
Received: from njxh01app02.zte.com.cn ([10.41.132.206]) by mse-fl2.zte.com.cn with SMTP id 29Q7eOcV010250; Wed, 26 Oct 2022 15:40:24 +0800 (+08) (envelope-from xiao.min2@zte.com.cn)
Received: from mapi (njxh01app01[null]) by mapi (Zmail) with MAPI id mid201; Wed, 26 Oct 2022 15:40:26 +0800 (CST)
Date: Wed, 26 Oct 2022 15:40:26 +0800
X-Zmail-TransId: 2af96358e46affffffff8591d83c
X-Mailer: Zmail v1.0
Message-ID: <202210261540261120274@zte.com.cn>
In-Reply-To: <93596B5C-6089-49CF-8608-9F0BBF308291@cisco.com>
References: 166661639377.4029.4774710549016071859@ietfa.amsl.com, 202210251459229500154@zte.com.cn, 93596B5C-6089-49CF-8608-9F0BBF308291@cisco.com
Mime-Version: 1.0
From: xiao.min2@zte.com.cn
To: evyncke@cisco.com
Cc: iesg@ietf.org, draft-ietf-ippm-ioam-conf-state@ietf.org, ippm-chairs@ietf.org, ippm@ietf.org, marcus.ihlar@ericsson.com
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: mse-fl2.zte.com.cn 29Q7eOcV010250
X-Fangmail-Gw-Spam-Type: 0
X-FangMail-Miltered: at cgslv5.04-192.168.250.138.novalocal with ID 6358E46F.000 by FangMail milter!
X-FangMail-Envelope: 1666770031/4My11q0GG7z4xVnp/6358E46F.000/10.5.228.133/[10.5.228.133]/mse-fl2.zte.com.cn/<xiao.min2@zte.com.cn>
X-Fangmail-Anti-Spam-Filtered: true
X-Fangmail-MID-QID: 6358E46F.000/4My11q0GG7z4xVnp
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/-VSUx2F5L7idpvBgdZPG9SegMsM>
Subject: Re: [ippm] Éric Vyncke's No Objection on draft-ietf-ippm-ioam-conf-state-07: (with COMMENT)
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ippm>, <mailto:ippm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ippm/>
List-Post: <mailto:ippm@ietf.org>
List-Help: <mailto:ippm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Oct 2022 07:40:39 -0000

It's my pleasure, Eric.






Best Regards,


Xiao Min









Original



From: EricVyncke(evyncke) <evyncke@cisco.com>
To: 肖敏10093570;
Cc: iesg@ietf.org <iesg@ietf.org>;draft-ietf-ippm-ioam-conf-state@ietf.org <draft-ietf-ippm-ioam-conf-state@ietf.org>;ippm-chairs@ietf.org <ippm-chairs@ietf.org>;ippm@ietf.org <ippm@ietf.org>;marcus.ihlar@ericsson.com <marcus.ihlar@ericsson.com>;
Date: 2022年10月26日 13:47
Subject: Re: Éric Vyncke's No Objection on draft-ietf-ippm-ioam-conf-state-07: (with COMMENT)






Hello Xiao Min,


 


Thanks for your reply and your kind words. All the changes seem good to me (and now, I know what SoP means ;-) )


 


Regards


 


-éric


 


 



From: "xiao.min2@zte.com.cn" <xiao.min2@zte.com.cn>
 Date: Tuesday, 25 October 2022 at 08:59
 To: Eric Vyncke <evyncke@cisco.com>
 Cc: "iesg@ietf.org" <iesg@ietf.org>, "draft-ietf-ippm-ioam-conf-state@ietf.org" <draft-ietf-ippm-ioam-conf-state@ietf.org>, "ippm-chairs@ietf.org" <ippm-chairs@ietf.org>, "ippm@ietf.org" <ippm@ietf.org>, "marcus.ihlar@ericsson.com" <marcus.ihlar@ericsson.com>
 Subject: Re: Éric Vyncke's No Objection on draft-ietf-ippm-ioam-conf-state-07: (with COMMENT)



 


Hi Eric,

 

Thank you for the review and thoughtful comments.

All your comments are accepted and the proposed changes will be incorporated into the next revision.

Please check inline the proposed changes.

 

Best Regards,

Xiao Min


Original



From: ÉricVynckeviaDatatracker <noreply@ietf.org>



To: The IESG <iesg@ietf.org>;



Cc: draft-ietf-ippm-ioam-conf-state@ietf.org <draft-ietf-ippm-ioam-conf-state@ietf.org>;ippm-chairs@ietf.org <ippm-chairs@ietf.org>;ippm@ietf.org <ippm@ietf.org>;marcus.ihlar@ericsson.com <marcus.ihlar@ericsson.com>;marcus.ihlar@ericsson.com <marcus.ihlar@ericsson.com>;



Date: 2022年10月24日 20:59



Subject: Éric Vyncke's No Objection on draft-ietf-ippm-ioam-conf-state-07: (with COMMENT)




Éric Vyncke 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:
 ----------------------------------------------------------------------
 
 
 # Éric Vyncke, INT AD, comments for draft-ietf-ippm-ioam-conf-state-07
 CC @evyncke
 
 Thank you for the work put into this document.
 
 Please find below some non-blocking COMMENT points (but replies would be
 appreciated even if only for my own education).
 
 Special thanks to Marcus Ihlar for the shepherd's detailed write-up including
 the WG consensus and the justification of the intended status.

I hope that this review helps to improve the document,

[XM]>>> It does help to improve the document.



 Regards,
 
 -éric
 
 ## COMMENTS
 
 ### Abstract
 
 This is a very long sentence... Consider shortening it.
 
 The `echo request/reply mechanisms used in IPv6 ...` would benefit of being

qualified (perhaps with 'generic' or 'specified' ?).

[XM]>>> OK. Propose to shorten the abstract as below.

OLD

   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. NEW

   This document describes an extension to 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.  

### Section 1



 The IPv6 node information query, while sent over ICMPv6, is not really an
 'echo/request' exchange, hence the title of this RFC is not really adequate. I

have no suggestion though.

[XM]>>> Yes, you're absolutely right. A bit of tricky thing here is that ICMPv6 echo request/reply has a different meaning with MPLS/SFC/BIER echo request/reply. I propose to add a sentence as the new penultimate paragraph of the introduction section.

NEW

Also note that in this document the echo request/reply mechanism used in IPv6 does not mean ICMPv6 Echo Request/Reply [RFC4443], but means IPv6 Node Information Query/Reply [RFC4620].



 ### Section 2.2
 
 When defining "TTL" please also add that this is the hop-limit field in the

IPv6 header (which has no TTL field).

[XM]>>> OK. Propose to change the TTL definition in the abbreviations section as below.

OLD

TTL: Time to Live NEW

TTL: Time to Live, this is also the Hop Limit field in the IPv6 header.  


### Section 3.2.1 and other sections including 3.2.6 "Must be zero" 
 
 Please do not forget to specify the receiver's behavior when receiving reserved

bits that are no all 0.

[XM]>>> OK. This comment is similar to that one Chris Lonvick has made in the Secdir review. I've added the penultimate paragraph of the security section to address that comment.

 


### Section 3.2.3

Explaining what "SoP" is would ease the reading.

[XM]>>> OK. Will do s/SoP/SoP (Size of POT).



 ## Notes
 
 This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
 [`ietf-comments` tool][ICT] to automatically convert this review into
 individual GitHub issues.
 
 [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
 [ICT]: https://github.com/mnot/ietf-comments