Hi Stewart, Thank you for your review and valuable feedback. We have resubmitted the revised draft, and our responses are provided inline [Chongfeng].
On 25-Jun-26 03:34, Stewart Bryant via Datatracker wrote: Document: draft-ietf-v6ops-framework-md-ipv6only-underlay Title: Framework for Multi-domain IPv6-only Underlay Network and IPv4-as-a-Service Reviewer: Stewart Bryant Review result: Ready with Issues I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://wiki.ietf.org/en/group/gen/GenArtFAQ>. Document: draft-ietf-v6ops-framework-md-ipv6only-underlay-23 Reviewer: Stewart Bryant Review Date: 2026-06-24 IETF LC End Date: 2026-06-22 IESG Telechat date: Not scheduled for a telechat Summary: I am reviewing from a GENART perspective and with this perspective I think the text of the draft should reassure me that this unconditionally works for any legitimate IPv4 protocol stack and any legitimate operation of that protocol stack. The draft adequately describes how an IPv4 packet is sent and delivered over an IPv6 network at the network layer but IPv4/6 hosts have assumptions about the network they are using at other layers of the protocol stack and there is no in-depth exploration of the wider considerations. Hopefully these are addressed in other similar mechanisms that I did not have time to explore, but I think the general reader should be reassured in the body of the text. Major issues:The draft has covered ICMP by asserting the presence of a stateless translator, but I cannot but worry that the are a lot of other assumptions built into an IPv4 protocol stack that may surface during deployment. For example IPv6 has the assumption (for integrity reasons) that UDP will have a checksum. IPv4 is acrostic on that and frequently sets CS = 0 and yet the draft seems to be silent on the consequences. I wonder if the draft needs to be experimental until there is operational experience with the method. [Chongfeng]: This draft builds on prior works practice. As Brian noted, the translation mechanism in this draft adheres to RFC7915, which explicitly addresses the UDP zero-checksum issue. Moreover, the IPv4 data delivery cross IPv6-only network which is specified in RFC7915 has already been tested on large-scale production networks such as CERNET (see RFC6219) and ChinaNet, and there are no major issues observed in these operational environments, it is reasonable to conclude that the necessary experimental validation has been effectively done. The process of ICMP in the case of stateless translator is so mature that it can also be seen at, https://www.cisco.com/c/en/us/td/docs/routers/ios-xe/ip-addressing/ip-addressing/m_iadnat-stateless-nat64.html Following the comment of Brian about implementation status, the following sentence has been added in section 7, “It should be noted that the IPv4 data delivery cross IPv6-only network specified in RFC7915 has already been tested on some large-scale networks, such as CERNET, and there are no major issues observed.” Minor issues: None Nits/editorial comments:There seems to be a minor confusion between Network Operator and Network Provider in the text that needs examining. "service continuity after IPv4 address exhaustion, network operators (NPs). I assume this is just a typo [Chongfeng]: To reduce confusion, all occurrences of “network operator” in the text have been changed to “network provider”. If you have more comments, please feel free to let me know. Thanks. Chongfeng
_______________________________________________ Gen-art mailing list -- [email protected] To unsubscribe send an email to [email protected]
