Ballot for draft-ietf-spring-srv6-srh-compression
Yes
No Objection
Recuse
Note: This ballot was opened for revision 19 and is now closed.
LGTM; thanks for addressing my comments!
Thanks for your quick work.
Thank you to Stewart Bryant for the GENART review. I support Erik Kline's DISCUSS position.
# Éric Vyncke, INT AD, comments for draft-ietf-spring-srv6-srh-compression-19 CC @evyncke Thank you for the work put into this document. While the content is rather complex, it is also easy to read. Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education). Special thanks to Pablo Camarillo for the shepherd's *very detailed* write-up including the WG consensus *and* the justification of the intended status. Please note that Benson Muite is the Internet directorate reviewer (at my request) and you may want to consider this int-dir review as well when it will be available (no need to wait for it though): https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-srh-compression/reviewrequest/21238/ I hope that this review helps to improve the document, Regards, -éric ## COMMENTS (non-blocking) ### Erik Kline's comment about section 4.2 I support Erik Kline's DISCUSS about some CSID containers not being valid IPv6 addresses, i.e., not compliant to RFC 8754 (requiring that this document updates RFC 8754). ### Title Suggest adding the acronym CSID in the title (e.g., like in RFC 7599, 9631, and others) this will help search engines. ### Section 1 Please expand CSID on first use. ### Section 2 Suggest adding the extension of SID at first use. I wonder whether `If the Locator-Node length ... its CSID encoding is zero.` belongs to terminology or should rather be in the specification part of this document to ease the implementer task. Unsure how to do it, but should LNFL be expanded ? ### Section 4.1 Should this be an uppercase MAY in `An implementation MUST support a 32-bit Locator-Block length (LBL) and a 16-bit CSID length (LNFL) for NEXT-CSID flavor SIDs, and may support any other Locator-Block and CSID length.` ? (to be consistent with the uppercase MUST) ### Section 4.1.6 (and possibly other places) s/Destination Option header/Destination Option*s* header/ ### Section 5.3 Like Erik Kline, please use the RFC 9602 SRv6 block for the examples rather than 2001:db8::/32 ### Section 7.1 I was about to DISCUSS this point but, as I may have misread this section, I am just commenting. Should there be clearly specified that the prefixes being swapped are of the same length ? It is also a little weird that the title and the PS acronym use "prefix" while it is all about locator block... ### Section 9.5 Below comments are to be consistent with my DISCUSS point about section 7 of RFC 9631 "The IPv6 Compact Routing Header (CRH)" that was easily resolved in the 6MAN WG IETF draft. See https://mailarchive.ietf.org/arch/msg/ipv6/a_RdmiI3iYk6Sk6mamrppoLTvnc/ The last two paragraphs are useless as they state the obvious and, therefore, could be confusing to the reader. I strongly suggest removing them (I was even about to DISCUSS these points). `Such SR source nodes leveraging TCP/UDP offload engines may require enhancements to convey the ultimate destination address.` it is obvious to me that current HW / SW do not always support the latest RFC, e.g., when RFC 2460 (IPv6) was published not all routers supported IPv6, this issue did not prevent publication of RFC 2460 nor the deployment of IPv6 (even if I would prefer to have a broader deployment than now ;-) ). `It was reported that some network node implementations ... may attempt to verify the upper layer checksum of transit IPv6 packets.` These implementations clearly violates the end to end architecture of the Internet, so, why would a standard track document would care about them? And if these box are used for RFC 7258 pervasive monitoring then it is even a benefit of this specification ;-) ### SVG Thanks for using the nice SVG graphics ;-)
As a contributor to this document I am recusing myself from the ballot.