Hi, Sorry for being late, I approve the publication.
Thanks. s. On Fri, Aug 29, 2025, 18:41 Megan Ferguson <mfergu...@staff.rfc-editor.org> wrote: > 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) < > cfils...@cisco.com> wrote: > > > > Hello, > > > > I approve this document for publication. > > > > Cheers, > > Clarence > > > >> -----Original Message----- > >> From: Megan Ferguson <mfergu...@staff.rfc-editor.org> > >> Sent: Monday, August 25, 2025 17:53 > >> To: Ketan Talaulikar <ketant.i...@gmail.com> > >> Cc: RFC Editor <rfc-edi...@rfc-editor.org>; Clarence Filsfils > (cfilsfil) > >> <cfils...@cisco.com>; stef...@previdi.net; pamat...@microsoft.com; > >> dhanendra.i...@gmail.com; idr-...@ietf.org; idr-cha...@ietf.org; > >> sha...@ndzh.com; Roman Danyliw <r...@cert.org>; 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 <ketant.i...@gmail.com> > >> 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 <mfergu...@staff.rfc- > >> 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 <ketant.i...@gmail.com> > >> wrote: > >>>> > >>>> Hi Megan, > >>>> > >>>> Please check inline below for responses with KT2. > >>>> > >>>> > >>>> On Fri, Aug 22, 2025 at 12:23 AM Megan Ferguson <mfergu...@staff.rfc- > >> 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 -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
