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]> 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]> 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 -- [email protected]
To unsubscribe send an email to [email protected]
