Éric Vyncke has entered the following ballot position for draft-ietf-spring-srv6-security-17: Discuss
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/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- # Éric Vyncke INT AD comments for draft-ietf-spring-srv6-security-17 CC @evyncke Thank you for the work put into this document. It is well structured, easy to read, and quite useful. Thanks to the authors for navigating in muddy waters ;-) Please find below one blocking DISCUSS points (easy to address), some non-blocking COMMENT points/nits (replies would be appreciated even if only for my own education). Special thanks to Zafar Ali for the shepherd's detailed write-up including the WG consensus *and* the justification of the intended status. I hope that this review helps to improve the document, Regards, -éric Note: this ballot comments follow the Markdown syntax of https://github.com/mnot/ietf-comments/tree/main, i.e., they can be processed by a tool to create github issues. ## DISCUSS (blocking) As noted in https://datatracker.ietf.org/doc/statement-iesg-handling-ballot-positions-20220121/, a DISCUSS ballot is a request to have a discussion on the points below; I really think that the document would be improved with a change here, but can be convinced otherwise. ### Section 6.3.2.1 RFC 8476 is only relevent to communicate the MSD in the SR-MPLS context and not in SRv6 ;-) So `Another example in the context of SRv6 is the advertisement of an incorrect Maximum SID Depth (MSD) value [RFC8476].` should be removed or RFC 9513 be used. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- ## COMMENTS (non-blocking) ### Section 1 s/deprecated routing header 0/deprecated routing header *type* 0/ ? s/the bridging of islands of SRv6 devices with standard IPv6 unicast *routing*/the bridging of islands of SRv6 devices with standard IPv6 unicast *forwarding*/ ? ### Section 2 Why not adding RFC 9602 to the list of important RFC as it reserves 5f00::/16 for SRv6, which could simplify some security policies ? It is cited in 7.1.3 though. Who is the "we" in `we note that SRv6 is under active development` ? The authors ? The SPRING WG ? the IETF community ? Please be clear or rephrase with the passive voice. Also in section 5 and possibly others. ### Section 4 The title somehow disagree with `This section introduces the threat *taxonomy*/, i.e., suggest to change the section title to use "taxonomy" rather than "terminology". s/The following figure/Figure 1/ ### Section 5 Some people may prefer "on-path attacks" rather than `man-in-the-middle attacks` ### Section 6.2.1.1 Adding SRH or SRH TLV is not so easy as it could exceed the MTU, so, the attacked is not so easy to mount. Should this be mentioned ? ### Section 6.3.3.1 Add a normative reference to RFC 9259 about the O-flag in `Segment Routing Header Flags` even if this RFC is cited in the previous paragraph, the link with the O-flag must be clear. ### Section 6.3.4 Rename the section title to "Centralized Control Plane Attacks" to be consistent with the text of 6.3.4.1 ? ### Use of SVG graphics To make a much nicer HTML rendering, suggest using the aasvg tool to generate SVG graphics. It is worth a try especially if the I-D uses the Kramdown file format ;-) _______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
