[IPv6]Fw: RE: [External] Re: I-D Action: draft-ietf-6man-icmpv6-ioam-conf-state-03.txt

[[e-mail]]

Dear 6man chairs,

The authors believe draft-ietf-6man-icmpv6-ioam-conf-state is ready for WGLC.
Appreciate your consideration of our request.

Best Regards,
Xiao Min

Original


From: King,Daniel <[e-mail]>
To: 肖敏10093570;
Cc: [e-mail] <[e-mail]>;[e-mail] <[e-mail]>;
Date: 2024年06月11日 16:50
Subject: RE: [External] Re: [IPv6] I-D Action: draft-ietf-6man-icmpv6-ioam-conf-state-03.txt



The updates look good, and thanks for the Ack! 
 
BR, Dan. 
 

From: [e-mail] <[e-mail]> 
 Sent: Tuesday, June 11, 2024 9:42 AM
 To: King, Daniel <[e-mail]>
 Cc: [e-mail]; [e-mail]
 Subject: Re: [External] Re: [IPv6] I-D Action: draft-ietf-6man-icmpv6-ioam-conf-state-03.txt


 
Hi Dan,
 
I've posted a new -04 revision attempting to address your comments. Link as below.
https://datatracker.ietf.org/doc/html/draft-ietf-6man-icmpv6-ioam-conf-state-04 
In -05 revision I just added your name to the Acknowledgements. :-)
 
Cheers,
Xiao Min

Original

From: King,Daniel <[e-mail]>



To: 肖敏10093570;



Cc: [e-mail] <[e-mail]>;[e-mail] <[e-mail]>;



Date: 2024年06月10日 16:04



Subject: RE: [External] Re: [IPv6] I-D Action: draft-ietf-6man-icmpv6-ioam-conf-state-03.txt




Hi Xiao, 
 
Great, I'm glad the contributions are helping. 
 
>Examples of the Node IOAM Request
 
9. The sentence felt incomplete and could have been more concise.  
 
Original:
 
"Note that when a Node IOAM Request message is received, the message length is indicated by the Payload Length field of IPv6 Header [RFC8200]."
 
Maybe this would read better as:
 
"When a Node IOAM Request message is received, the length of the message is determined by the Payload Length field in the IPv6 Header, as specified in [RFC8200].
 
This was just a minor comment. 
 
BR, Dan. 
 


From: [e-mail] <[e-mail]> 
 Sent: Friday, June 7, 2024 11:05 AM
 To: King, Daniel <[e-mail]>
 Cc: [e-mail]; [e-mail]
 Subject: [External] Re: [IPv6] I-D Action: draft-ietf-6man-icmpv6-ioam-conf-state-03.txt



 
This email originated outside the University. Check before clicking links or attachments.
Dear Dan,

 Many thanks for your thorough review and comments, very helpful.
Please see inline for detailed responses.

Original

From: King,Daniel <[e-mail]>



To: [e-mail] <[e-mail]>;



Cc: [e-mail] <[e-mail]>;



Date: 2024年06月06日 06:01



Subject: RE: [IPv6] I-D Action: draft-ietf-6man-icmpv6-ioam-conf-state-03.txt




Hi Authors,
 
 I was reading RFC 9359  (Echo Request/Reply Enabled In Situ OAM). I’m interested in the applicability of IPv6 data plane monitoring, and I noticed your companion document - draft-ietf-6man-icmpv6-ioam-conf-state. Seeing as the document is still being discussed in the 6man WG, I thought I’d drop a review and give you some thoughts.  
 
 Firstly, I did not remember seeing the document being presented at IETF 119 and found no slides in the 6man materials – obviously, because it was not presented. 😊 Never mind, the document was straightforward to read without the slides. Great job!
[XM]>>> Yes, this document was presented at IETF 118 but not IETF 119, because the authors made few changes between the two IETF meetings. Fortunately you found it easy to read. :-)
 
A few thoughts:
 
 >Abstract  
 
 1. Being pedantic, the abstract mentions “described in RFC 9359 "Ping Enabled IOAM Capabilities"”, but actually, the specific name of the document (you also co-authored) is “Echo Request/Reply for Enabled In Situ OAM (IOAM) Capabilities”.
[XM]>>> Accepted. I thought the *title abbrev* populated in XML file can be displayed in the RFC text, obviously I was wrong.
 
>Introduction  
 
 2. Suggest reducing text.
 
 s/ Both [RFC4884] and [RFC8335] provide sound principles and examples on how to extend ICMPv6 messages / Both [RFC4884] and [RFC8335] provide sound principles and examples on extending ICMPv6 messages.
[XM]>>> Accepted.
 
3. I found the sentence a little wordy, it might be improved.  
 
 s/ The IOAM encapsulating node sends a NI Query to each IOAM transit and decapsulating node, then each receiving node executes access control procedures, and if access is granted, each receiving node returns a NI Reply which indicates the enabled IOAM capabilities of the receiving node. / The IOAM encapsulating node sends an NI Query to each IOAM transit and decapsulating node. Upon receiving the query, each node executes access control procedures. If access is granted, the node returns an NI Reply indicating its enabled IOAM capabilities.
[XM]>>> Accepted.
 
4. “exactly” seems redundant.
 
 s/ The NI Reply contains an ICMPv6 Extension Structure exactly customized to this message, and the ICMPv6 Extension Structure contains one or more IOAM Capabilities Objects / The NI Reply contains an ICMPv6 Extension Structure customized to this message, and the ICMPv6 Extension Structure contains one or more IOAM Capabilities Objects.
[XM]>>> Accepted. I can't recall why "exactly" is there, and I agree with you it seems redundant.
 
5. Again, some rewording and brevity might improve the text and reduce the number of words needed.    
 
 s/ Note that before the IOAM encapsulating node sends the NI Query, it needs to know the IPv6 address of each node along the transport path of a data packet to which IOAM data would be added. / Before the IOAM encapsulating node sends the NI Query, it must know the IPv6 address of each node along the transport path of the data packet to which IOAM data will be added.
[XM]>>> Accepted.
 
6. The follow-on sentence might be improved.  
 
 s/ That can be achieved by executing ICMPv6/UDP traceroute or provisioning explicit path at the IOAM encapsulating node. In an Equal-Cost Multipath (ECMP) scenario, the same value or values in any ECMP affecting fields (e.g., the 3-tuple of the Flow Label, Source Address, and Destination Address fields [RFC6437]) of IOAM data packets MUST be populated in the NI Query, ensuring the fate sharing between the NI Query and IOAM data packets. / This can be achieved by executing an ICMPv6/UDP traceroute or by provisioning an explicit path at the IOAM encapsulating node. In an Equal-Cost Multipath (ECMP) scenario, the same values in any ECMP-affecting fields (e.g., the 3-tuple of the Flow Label, Source Address, and Destination Address fields as per [RFC6437]) of the IOAM data packets MUST be populated in the NI Query, ensuring fate sharing between the NI Query and the IOAM data packets.
[XM]>>> Accepted.
 
>Node IOAM Request
 
 7. Punctuation would help.  
 
 s/ *Code: The value is (TBD1) the Data field contains a List of IOAM Namespace-IDs which is the Subject of this Query. / *Code: The value is (TBD1). The Data field contains a list of IOAM Namespace-IDs, which are the subject of this query.
[XM]>>> Accepted.
 
8. Punctuation and brackets for consistency with (TBD1).
 
 s/ *Qtype: The value is TBD2, which indicates the NI Query is a node IOAM capabilities query. / *Qtype: The value (TBD2). Which indicates the NI Query is a node IOAM capabilities query.
[XM]>>> Accepted. s/The value (TBD2)/The value is (TBD2).
 
>Examples of the Node IOAM Request
 
 9. The sentence felt incomplete and could have been more concise.  
 
 s/ Note that when a Node IOAM Request message is received, the message length is indicated by the Payload Length field of IPv6 Header [RFC8200]. / Note that when a Node IOAM Request message is received, the message length is indicated by the Payload Length field of the IPv6 Header [RFC8200].
[XM]>>> You said "the sentence felt incomplete", could you please elaborate it a little more?
 
>IOAM Capabilities Objects
 
 10. Suggest a modification for a smoother read and reduction in text.
 
 s/ *Object payload: Following the IOAM Capabilities Object Header, it's the IOAM Capabilities Object payload, which is defined respectively in Section 3.2.1, Section 3.2.3, Section 3.2.4, Section 3.2.5 and Section 3.2.6 of [RFC9359]. / *Object payload: Following the IOAM Capabilities Object Header is the IOAM Capabilities Object payload, which is defined in Sections 3.2.1, 3.2.3, 3.2.4, 3.2.5, and 3.2.6 of [RFC9359].
[XM]>>> Accepted.
 
>Examples of the Node IOAM Reply
 
 11. Grammar nit.
 
 s/ Note that when a Node IOAM Reply message is received, the message length is indicated by the Payload Length field of IPv6 Header [RFC8200]. / Note that when a Node IOAM Reply message is received, the message length is indicated by the Payload Length field of the IPv6 Header [RFC8200].
[XM]>>> Accepted.
 
>Code Field Processing
 
 12. Grammar nit.
 
 s/ The Code field in the Node IOAM Reply MUST be set to (TBD3) No Matched Namespace-ID if any of the following conditions applies: / The Code field in the Node IOAM Reply MUST be set to (TBD3) No Matched Namespace-ID if any of the following conditions apply:
[XM]>>> Accepted.
 
>Security Considerations
 
 13. Spelling nit.  
 
 s/ Securiy issues discussed in [RFC4620] and [RFC9359] apply to this document. / Security issues discussed in [RFC4620] and [RFC9359] apply to this document.
[XM]>>> Accepted.
 
I was impressed with the Security Considerations; the authors highlighted negation and mitigation strategies for OAM attack vectors, such as spoofed addresses and amplification. 
[XM]>>> Thank you.
 
Overall, I support the document. None of the issues highlighted above are particularly onerous, but at least some may improve the document's quality. I hope this review helps. 
[XM]>>> Thanks again! Your review helps much. :-)
 
Cheers,
Xiao Min
 
BR, Dan.
 
 -----Original Message-----
 From: [e-mail] <[e-mail]>  
 Sent: Monday, April 22, 2024 2:29 AM
 To: [e-mail]
 Cc: [e-mail]
 Subject: [IPv6] I-D Action: draft-ietf-6man-icmpv6-ioam-conf-state-03.txt
 
 Internet-Draft draft-ietf-6man-icmpv6-ioam-conf-state-03.txt is now available.
 It is a work item of the IPv6 Maintenance (6MAN) WG of the IETF.
 
    Title:   IPv6 Query for Enabled In-situ OAM Capabilities
    Authors: Xiao Min
             Greg Mirsky
    Name:    draft-ietf-6man-icmpv6-ioam-conf-state-03.txt
    Pages:   16
    Dates:   2024-04-21
 
 Abstract:
 
    This document describes the application of the mechanism of
    discovering In-situ OAM (IOAM) capabilities, described in RFC 9359
    "Ping Enabled IOAM Capabilities", in IPv6 networks.  IPv6 Node IOAM
    Request uses the IPv6 Node Information messages, allowing the IOAM
    encapsulating node to discover the enabled IOAM capabilities of each
    IOAM transit and IOAM decapsulating node.
 
    This document updates RFCs 4620 and 4884.
 
 The IETF datatracker status page for this Internet-Draft is:
 https://datatracker.ietf.org/doc/draft-ietf-6man-icmpv6-ioam-conf-state/
 
 There is also an HTMLized version available at:
 https://datatracker.ietf.org/doc/html/draft-ietf-6man-icmpv6-ioam-conf-state-03
 
 A diff from the previous version is available at:
 https://author-tools.ietf.org/iddiff?url2=draft-ietf-6man-icmpv6-ioam-conf-state-03
 
 Internet-Drafts are also available by rsync at:
 rsync.ietf.org::internet-drafts