Hi Megan, The document looks good to me, I approve the publication.
Thanks, Dhanendra. On Mon, Aug 25, 2025 at 8:53 AM Megan Ferguson < mfergu...@staff.rfc-editor.org> wrote: > 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 > consistent in RFC9830 (e.g., > https://www.rfc-editor.org/authors/rfc9830.html#section-2.4.4.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 > consistency. However, I notice that the IANA sections in both 9830 and 9831 > are not matching the sub-TLV names. Could you please fix that? > 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
