Thanks, Eric. I do have another set of fixes that I missed coming soon and will follow up separately with that.
On Fri, Oct 16, 2026 at 8:38 AM Eric Vyncke (evyncke) <[email protected]> wrote: > Hello Nick, and other authors, > > Thank you for your prompt answer. The -18 indeed addresses my blocking > DISCUSS concern; even if it left many of my COMMENT-level issues > unaddressed, I will shortly clear my ballot position in YES. > > Note that when addressing a comment about "routing header *type* 0", you > added a sentence in section without the "type" in `Unlike routing header 0,`😊 > it would be nice to also fix it. > > Regards > > -éric > > > *From: *Nick Buraglio <[email protected]> > *Date: *Tuesday, 13 October 2026 at 03:32 > *To: *Eric Vyncke (evyncke) <[email protected]> > *Cc: *The IESG <[email protected]>; [email protected] < > [email protected]>; [email protected] < > [email protected]>; [email protected] < > [email protected]>; [email protected] <[email protected]>; Zafar Ali > (zali) <[email protected]> > *Subject: *Re: Éric Vyncke's Discuss on > draft-ietf-spring-srv6-security-17: (with DISCUSS and COMMENT) > > 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]
