Gunter Van de Velde has entered the following ballot position for draft-ietf-spring-srv6-security-17: 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-spring-srv6-security/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- # Gunter Van de Velde, RTG AD, comments for review of draft-ietf-spring-srv6-security-17 # Many thanks to Henning Rogge and Andrew Alston for the RTGDIR review. # Thanks for the nice useful writeup. While reviewing i found two easy to resolve items to discuss and few observations you may want to comment upon. # Through the document please replace the reference to the "last SRH entry" with an explicit field expression. For an ordinary uncompressed SRH, the final policy segment is Segment List[0], not the entry indexed by Last Entry. Please also look into guidance for packets without an SRH and for compressed segment lists. A general instruction to read one SRH entry does not cover those cases, and that should be made explicit within the text. # Within Sections 1 and 3: Make SRH optionality clear from the introduction. Please describe SRv6 as "potentially" using an SRH. This will align the opening explanation with the later filtering discussion and avoid suggesting that SRH detection identifies all SRv6 traffic. # Section 2: Explain how the listed specifications were assessed. RFC 9491 and RFC 9524 are identified as part of the assessment, but their specific behaviors deserve a short explicit explanation of how the general analysis covers them. # Section 6.3.2: Cite the SRv6-specific MSD definitions. It is correct that RFC 8476 supplies the OSPF MSD advertisement framework, but it is insufficient as the sole reference for the SRv6 example. For completeness you could consider to add RFC 9352, Section 4, and RFC 9513, Section 4. They distinguish Maximum Segments Left, Maximum End Pop, Maximum H.Encaps, and Maximum End D MSD types. Brgds, Gunter Van de Velde Routing Area Director _______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
