Hello, I approve this document for publication.
Cheers, Clarence > -----Original Message----- > From: Megan Ferguson <[email protected]> > Sent: Monday, August 25, 2025 17:53 > To: Ketan Talaulikar <[email protected]> > Cc: RFC Editor <[email protected]>; Clarence Filsfils (cfilsfil) > <[email protected]>; [email protected]; [email protected]; > [email protected]; [email protected]; [email protected]; > [email protected]; Roman Danyliw <[email protected]>; auth48archive@rfc- > editor.org > Subject: Re: AUTH48: RFC-to-be 9831 <draft-ietf-idr-bgp-sr-segtypes-ext-08> > for your review > > Hi Ketan, > > Thank you for spotting that! We have updated as requested (please refresh). > > We have also marked you as “approved” at the AUTH48 status page (see > below). Once we have approvals from your coauthors, we will forward the > necessary updates to IANA. > > The files have been posted here: > https://www.rfc-editor.org/authors/rfc9831.txt > https://www.rfc-editor.org/authors/rfc9831.pdf > https://www.rfc-editor.org/authors/rfc9831.html > https://www.rfc-editor.org/authors/rfc9831.xml > > The relevant diff files have been posted here: > https://www.rfc-editor.org/authors/rfc9831-diff.html (comprehensive) > https://www.rfc-editor.org/authors/rfc9831-rfcdiff.html (side by side) > > https://www.rfc-editor.org/authors/rfc9831-auth48diff.html (AUTH48 > changes only) > https://www.rfc-editor.org/authors/rfc9831-auth48rfcdiff.html (side by > side) > > The AUTH48 status page for this document can be found here: > https://www.rfc-editor.org/auth48/rfc9831 > > The relevant cluster information can be found here: > https://www.rfc-editor.org/cluster_info.php?cid=C534 > > Thank you. > > Megan Ferguson > RFC Production Center > > > On Aug 22, 2025, at 11:52 PM, Ketan Talaulikar <[email protected]> > wrote: > > > > Hi Megan, > > > > I had a look at the > > https://www.rfc-editor.org/authors/rfc9831-auth48diff.html and there > > is still this change that needs to be reverted in section 2.7 > > > > SRv6 SID: Optional. A 16-octet IPv6 address. The value 0 MAY be > > used when the controller wants to indicate the desired SRv6 > > Endpoint Behavior > > or and SID Structure without specifying the SID. > > Besides that, everything looks good and please take this email as my > approval for publication. > > > > Thanks, > > Ketan > > > > > > On Sat, Aug 23, 2025 at 1:35 AM Megan Ferguson <[email protected] > editor.org> wrote: > > Hi Ketan, > > > > Thank you for your prompt reply! > > > > We have updated as suggested and added these changes to the current > files/diffs (please refresh). > > > > The files have been posted here: > > https://www.rfc-editor.org/authors/rfc9831.txt > > https://www.rfc-editor.org/authors/rfc9831.pdf > > https://www.rfc-editor.org/authors/rfc9831.html > > https://www.rfc-editor.org/authors/rfc9831.xml > > > > The relevant diff files have been posted here: > > https://www.rfc-editor.org/authors/rfc9831-diff.html (comprehensive) > > https://www.rfc-editor.org/authors/rfc9831-rfcdiff.html (side by > > side) > > > > https://www.rfc-editor.org/authors/rfc9831-auth48diff.html (AUTH48 > changes only) > > https://www.rfc-editor.org/authors/rfc9831-auth48rfcdiff.html (side > > by side) > > > > The AUTH48 status page for this document can be found here: > > https://www.rfc-editor.org/auth48/rfc9831 > > > > The relevant cluster information can be found here: > > https://www.rfc-editor.org/cluster_info.php?cid=C534 > > > > Please let us know if any further updates are necessary. We will await > approvals from each party listed at the AUTH48 status page prior to moving > forward in the publication process. > > > > Thank you. > > > > RFC Editor/mf > > > > > On Aug 22, 2025, at 2:30 AM, Ketan Talaulikar <[email protected]> > wrote: > > > > > > Hi Megan, > > > > > > Please check inline below for responses with KT2. > > > > > > > > > On Fri, Aug 22, 2025 at 12:23 AM Megan Ferguson <[email protected] > editor.org> wrote: > > > Hi Ketan, > > > > > > Thank you for your response and guidance. > > > > > > Some further questions/comments below marked with [rfced]. > > > > > > > > > > > 4) <!-- [rfced] The following text from Section 2 may require > > > > clarification: > > > > > > > > "As specified in Sections 2.4.4 and 2.4.4.2 of [RFC9830], > > > > validation of an explicit path encoded by the Segment List sub-TLV > > > > is beyond the scope of BGP and performed by the Segment Routing > > > > Policy Module (SRPM) as described in Section 5 of [RFC9256]." > > > > > > > > The term "Segment Routing Policy Module (SRPM)" doesn't appear in > > > > [RFC9256]. > > > > > > > > --> > > > > > > > > KT> It should be RFC9830 > > > > > > [rfced] We believe the citation in the sentence following should be > updated as well (and have made the update). Please review and let us know > if this is in error. > > > > > > KT2> That 2nd sentence should refer to RFC9256 so please revert that > change to the original. > > > > > > What is being referenced is the following text > > > https://www.rfc-editor.org/rfc/rfc9256.html#section-5.1 > > > > > > Additionally, an explicit candidate path MAY be declared invalid when its > constituent segment lists (valid or invalid) are using segment types of > different > SR data planes. > > > > > > > > > > > > > > > > > > > > > > 5) <!--[rfced] The following text led us to believe that the subsection > > > > titles of Section 2 would match the Type names listed in Section > > > > 2 itself: but they do not. Please review and let us know if a > > > > closer 1:1 matchup is desired between these. > > > > > > > > Original: > > > > [I-D.ietf-idr-sr-policy-safi] specifies Segment Type Sub-TLVs for > > > > the segment types A and B. The following sub-sections specify the > > > > sub- TLVs used for encoding each of the other Segment Types above. > > > > > > > > > > > > KT> They look ok to me, but perhaps I don't follow your point. Could > you please illustrate with an example? > > > > > > > > > > > > --> > > > > > > [rfced] Sorry for any confusion. Just curious if the wording should be > made the same in the “names” of the Types. We see: > > > > > > Original ToC: > > > 2. Segment Type Sub-TLVs . . . . . . . . . . . . . . . . . . . . 3 > > > 2.1. Segment Type C - SR-MPLS Prefix SID for IPv4 . . . . . . 4 > > > 2.2. Segment Type D - SR-MPLS Prefix SID for IPv6 . . . . . . 5 > > > 2.3. Segment Type E - SR-MPLS Adjacency SID for IPv4 with an > > > Interface ID . . . . . . . . . . . . . . . . . . . . . . 5 > > > 2.4. Segment Type F - SR-MPLS Adjacency SID for IPv4 with an > > > Interface Address . . . . . . . . . . . . . . . . . . . 6 > > > 2.5. Segment Type G - SR-MPLS Adjacency SID for IPv6 with an > > > Interface ID . . . . . . . . . . . . . . . . . . . . . . 7 > > > 2.6. Segment Type H - SR-MPLS Adjacency SID for IPv6 with an > > > Interface Address . . . . . . . . . . . . . . . . . . . 9 > > > 2.7. Segment Type I - SRv6 END SID as IPv6 Node Address . . . 9 > > > 2.8. Segment Type J - SRv6 END.X SID as an Interface ID . . . 11 > > > 2.9. Segment Type K - SRv6 END.X SID as an Interface > > > Address . . . . . . . . . . . . . . . . . . . . . . . . > > > 12 > > > > > > Original list in Section 2: > > > Type A: SR-MPLS Label > > > Type B: SRv6 SID > > > Type C: IPv4 Prefix with optional SR Algorithm > > > Type D: IPv6 Global Prefix with optional SR Algorithm for SR-MPLS > > > Type E: IPv4 Prefix with Local Interface ID > > > Type F: IPv4 Addresses for link endpoints as Local, Remote pair > > > Type G: IPv6 Prefix and Interface ID for link endpoints as Local, > > > Remote pair for SR-MPLS > > > Type H: IPv6 Addresses for link endpoints as Local, Remote pair > > > for SR-MPLS > > > Type I: IPv6 Global Prefix with optional SR Algorithm for SRv6 > > > Type J: IPv6 Prefix and Interface ID for link endpoints as Local, > > > Remote pair for SRv6 > > > Type K: IPv6 Addresses for link endpoints as Local, Remote pair > > > for SRv6 > > > > > > > > > Perhaps the section titles of Section 2’s subsections should be updated as > follows to match their descriptions in the ToC above (or vice versa (with the > list in Section 2 being updated to match the styling in the original ToC))? > > > > > > For example, make the section titles be: > > > 2.1. Segment Type C: IPv4 Prefix with Optional SR Algorithm > > > 2.2. Segment Type D: IPv6 Global Prefix with Optional SR Algorithm > > > for > SR-MPLS > > > 2.3. Segment Type E: IPv4 Prefix with Local Interface ID > > > 2.4. Segment Type F: IPv4 Addresses for Link Endpoints as Local, > Remote Pair > > > 2.5. Segment Type G: IPv6 Prefix and Interface ID for Link > > > Endpoints as > Local, Remote Pair for SRMPLS > > > 2.6. Segment Type H: IPv6 Addresses for Link Endpoints as Local, > Remote Pair for SR-MPLS > > > 2.7. Segment Type I: IPv6 Global Prefix with Optional SR Algorithm > > > for > SRv6 > > > 2.8. Segment Type J: IPv6 Prefix and Interface ID for Link > > > Endpoints as > Local, Remote Pair for IPv6 > > > 2.9. Segment Type K: IPv6 for Link Endpoints as Local, Remote > > > Pair for SRv6 > > > > > > > > > If this close of a relationship is not necessary/desired, it is fine to > > > leave > them as they are. > > > > > > KT2> I see your point. However, now that you bring this up, the section > titles seem too long. How about we just have "Segment Type X" and then it > would be consistent with https://www.rfc- > editor.org/authors/rfc9830.html#section-2.4.4.2.1 as well and much shorter? > > > > > > > > > > > > > > > > > > > > > > > > > > > 7) <!-- [rfced] We note that Section 2.4.4.2.4 of [RFC9830] uses the > > > > term > > > > "SRv6 SID Endpoint Behavior and Structure" rather than "SRv6 > > > > Endpoint Behavior and SID Structure". Please let us know if/how > > > > these uses may be made consistent. > > > > --> > > > > > > > > KT> I would prefer the latter, but then we'll also need to make it > > > > KT> consistent in RFC9830 (e.g., > > > > KT> https://www.rfc-editor.org/authors/rfc9830.html#section-2.4.4. > > > > KT> 2.4 ) > > > > > > > [rfced] We have updated to use the latter throughout this document and > consistently throughout RFC-to-be 9830. Please review the use in both > documents (as an author of each) and reply to each specific email thread > with any further updates and/or approval of the changes. Note that we also > changed some instances in which “or” was used instead of “and” to be “and” > consistently. Please let us know if this was in error. > > > > > > KT2> The changes where the "or" was replaced by "and" are incorrect. In > those cases, we mean that when either the "SRv6 Endpoint Behavior" or "SID > Structure" then the SID can be set to 0. Please revert that change. The rest > looks good to me. > > > > > > > > > > > > > > > 8) <!--[rfced] Please review the entries in Table 1 in light of this > > > > response > regarding the names of sub-TLVs from Ketan when we discussed this topic for > RFC-to-be 9830: > > > > > > > > Ketan: > > > > "The names of the segments (titles) are to be "Segment Type X" while > the name of the sub-TLVs are to be "Type X Segment sub-TLV" (I've seen both > sub-TLV and Sub-TLV - either is OK but we should have been consistent). The > "Type-1" is actually "Type A Segment sub-TLV"." > > > > > > > > If updates are necessary to the corresponding IANA registry, we > > > > will communicate them on your behalf once AUTH48 concludes. > > > > > > > > KT> Yes, please apply the same to this document as well for > > > > KT> consistency. However, I notice that the IANA sections in both > > > > KT> 9830 and 9831 are not matching the sub-TLV names. Could you > > > > KT> please fix that? > > > > KT> https://www.rfc-editor.org/authors/rfc9830.html#section-6.5 > > > > > > > > > > > > > > > > —> > > > [rfced] We have made the necessary updates to Table 1 and will > communicate these changes to IANA once AUTH48 completes. > > > > > > With regard to RFC-to-be 9830: We believe you are referring to values 1 > and 13 in Table 5 (of Section 6.5) and have updated the document and will > communicate this change to IANA along with the changes to this document > (once AUTH48 for RFC-to-be 9831 concludes). > > > > > > KT2> Correct. > > > > > > > > > > > > We ask again that you review the changes to RFC 9830 and communicate > your approval or need for further updates in that email thread (for other > authors’ benefit as well as the AUTH48 archive). > > > > > > KT2> Done. > > > > > > Thanks, > > > Ketan > > > > > > > > > Any other changes have been incorporated as requested. Please review > carefully as we do not make changes once the document is published as an > RFC. > > > > > > The files have been posted here: > > > https://www.rfc-editor.org/authors/rfc9831.txt > > > https://www.rfc-editor.org/authors/rfc9831.pdf > > > https://www.rfc-editor.org/authors/rfc9831.html > > > https://www.rfc-editor.org/authors/rfc9831.xml > > > > > > The relevant diff files have been posted here: > > > https://www.rfc-editor.org/authors/rfc9831-diff.html (comprehensive) > > > https://www.rfc-editor.org/authors/rfc9831-rfcdiff.html (side by > > > side) > > > > > > https://www.rfc-editor.org/authors/rfc9831-auth48diff.html (AUTH48 > changes only) > > > https://www.rfc-editor.org/authors/rfc9831-auth48rfcdiff.html > > > (side by side) > > > > > > The AUTH48 status page for this document can be found here: > > > https://www.rfc-editor.org/auth48/rfc9831 > > > > > > The relevant cluster information can be found here: > > > https://www.rfc-editor.org/cluster_info.php?cid=C534 > > > > > > Thank you. > > > > > > RFC Editor/mf > > > > > > > > > > > > > > > > > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
