Eric, Responses inline @ [RP] Thanks, Rishabh.
On Wed, Oct 22, 2025 at 7:29 AM Éric Vyncke via Datatracker < [email protected]> wrote: > Éric Vyncke has entered the following ballot position for > draft-ietf-bess-mvpn-evpn-sr-p2mp-15: 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-bess-mvpn-evpn-sr-p2mp/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > > # Éric Vyncke, INT AD, comments for draft-ietf-bess-mvpn-evpn-sr-p2mp-15 > CC @evyncke > > Thank you for the work put into this document. > > 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 Stéphane Litkowski for the shepherd's write-up including > the > WG consensus *and* the justification of the intended status. > > Please note that Tim Winters 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-bess-mvpn-evpn-sr-p2mp/reviewrequest/22937/ > > I hope that this review helps to improve the document, > > Regards, > > -éric > > ## 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. > > ### Sections 3 & 5.2 > > Keeping the field name of "MPLS Label" (singular) is really misleading as > it > can contains SRV6 SID. Did the WG/authors consider updating RFC 6514 to > change > the field name ? > [RP] No, we did not because RFC 9252 Section 6.3 already set a precedent of using the "MPLS Label" field to transpose some part of the End.DT2M SID. I can change the title of the Section to "MPLS Label field" and add clarifying text to the SRv6 sub-section. > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > ## COMMENTS (non-blocking) > > ### Abstract > > s/This document describes/This document specifies/ > > ### Section 1 > > s/allow a Service Provider/allow a network operator/ > > s/This document describes/This document specifies/ > [RP] Done. > > While the statements `The reader is expected...` are valid in a RFC, they > do > not help the IESG review by a non expert. > [RP] Maybe, but much of this document is based on work done in other RFCs which are a prerequisite for understanding this document. Based on another comment, I have converted some of this text to a Terminology section, but the prerequisite understanding is still required. > > ### Section 3.1.2 > > To be honest, I failed to follow the procedure... A decriptive figure would > help a lot. The same comment for the whole section 4. > [RP] The next revision is going to reorganize and restructure this document based on Ketan's comments; I hope it will improve readability and clarity. Section 3.1.2 is based on Section 4 and 6.1.3 of RFC 9252. We have added a diagram and high level explanation of the solution in Section 2 and Section 4 (or at least the detailed Auto-Discovery procedures) have been simplified. > > ### Section 7 > > Please properly define `IMET`. > > No need to define twice the "BUM". > [RP] These are now defined in the Terminology section. > > What is a `NVE`? > [RP] Text related to NVE has been removed in next revision. > > ### Section 8 > > Having a list of implementations is nice, but if the document refers to RFC > 7942, then it should follow section 2 of this RFC rather than having a very > succint description. > > [RP] May I ask what is lacking in this section? > ### Section 9 > > Please add also a URI for "SRv6 Endpoint Behaviors" registry. > [RP] Done. > > > > _______________________________________________ > BESS mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ BESS mailing list -- [email protected] To unsubscribe send an email to [email protected]
