Comments inline. Unless noted, I have implemented these in -18, if they meet your approval I can incorporate them with the next submission. There is another email coming that addresses a lot of the non-discussion comments all in one email since there was a bit of overlap there.
On Thu, Oct 8, 2026 at 6:10 AM Éric Vyncke via Datatracker <[email protected]> wrote: > > É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. OLD: Another example in the context of SRv6 is the advertisement of an incorrect Maximum SID Depth (MSD) value [RFC8476]. NEW: Another example in the context of SRv6 is the advertisement of an incorrect Maximum SID Depth (MSD) value, such as the SRv6 MSD types defined in Section 4 of [RFC9352] and Section 4 of [RFC9513] (with the general MSD framework described in [RFC8476]). > > > ---------------------------------------------------------------------- > 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]
