Authors (*Stafano), Thank you for the approvals we have received thus far: we have marked them on the AUTH48 status page (see below). We believe the only author approval outstanding is *Stefano’s.
Once we receive all author approvals, we will request that IANA update to match any relevant changes made during AUTH48 (same for RFC-to-be 9830; the update has already been requested for RFC-to-be 9832). Once we receive confirmation of the registry/document matching for all documents in the cluster, we will move forward in the publication process. 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 26, 2025, at 1:46 AM, Clarence Filsfils (cfilsfil) > <[email protected]> wrote: > > 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]
