I have reviewed the latest version 16 of the draft with Operational Considerations section 9.3 added to address L4 checksum discussion on ML. The draft is well written and is ready for publication.

I have been following the ML thread since it began related to L4 checksum.  The key here for operators deploying c-SID SRv6 Compression Next SID is that endpoints performing L4 checksum would not exist on the SRv6 network closed domain and would exist within the customer payload which remains unaltered and will always pass the L4 checksum.  Section 9.3 addresses the operational consideration where the DA is not the same as the final destination and may require enhancements to convey the final destination address.

Section 9.3
Upper layer checksums are computed by the originator of an IPv6 packet and verified by the ultimate destination(s) as it processes the upper layer protocol.

As specified in Section 6.5, SR source nodes originating TCP/UDP packets ensure that the upper layer checksum is correctly calculated based on the ultimate destination of the session, which may be different from the address placed in the IPv6 destination address. Such SR source nodes leveraging TCP/UDP offload engines may require enhancements to convey the ultimate destination address. These implementation enhancements are outside the scope of this document.

Middleboxes such as packet sniffers, if deployed inside the SR domain, may fail to verify the upper layer checksum of transit SRv6 traffic. Making these middleboxes SRv6 aware in general or C-SID aware in particular is out of the scope of this document.

Major issues:
None 

Minor issues:
None 

Nits:
None