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

[[e-mail]]

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 <[e-mail]>
To: The IESG <[e-mail]>;
Cc: [e-mail] <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;
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