Hi Karen, all,
I have one concern to discuss. I’ve tried to suss out the answer by looking
through the email thread quickly, but am still puzzled; perhaps one of you has
the answer at their fingertips.
Table 6 in the approved document included both a short name (“Type K”, for
example) and a prose description (“IPv6 Addresses for link endpoints as Local,
Remote pair for SRv6” would be the current version, per the Table 1 update).
The new version of Table 6 gives only the short name ("Type K Segment”).
It seems to me that the table is a more useful reference for human beings if it
includes a prose description for each item. I acknowledge that this introduces
some redundancy with Table 1, and I see that the RFC Editor raised this as a
concern — but Table 6 is part of the IANA registry and Table 1 is not, and the
work to align the descriptions in the two tables is a one-time effort and
doesn’t seem onerous.
Can someone explain to me what the rationale was for making this change? If
there is not a strong preference for the current format, I would favor
restoring the long descriptions to Table 6.
A similar point applies to the changes to the titles of Sections 5.7.1.1.1 -
5.7.1.1.11. In my experience, while some (many?) implementors end up memorizing
“Type K means mumble foo”, more casual users of the spec are often
unnecessarily hampered by excessive brevity of this kind. (Honest, it’s not
just me; other people have complained to me about this.)
The other changes look fine to me.
$0.02,
—John
> On Sep 16, 2025, at 2:21 PM, Karen Moore <[email protected]> wrote:
>
> [External Email. Be cautious of content]
>
>
> Hi Jeff and *John (AD),
>
> Thank you for providing your approval of the document; we have noted it here
> <https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9857__;!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyW-h2yu9g$
> >. We now await approvals from Hannes, Jie, and Stefano.
>
> *John, please review the following updates and let us know if you approve.
> The changes can be reviewed here:
> <https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9857-auth48diff.html__;!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyXMg0_xow$
> >.
>
> 1) Update to the description of “V-Flag” in Section 5.3 (added “MUST”)
> 2) Updates to Table 1 in Section 5.7.1.1 to match the descriptions in RFCs
> 9256, 9830, and 9831
> 3) Updates to Table 6 in Section 8.5 (FYI: updates will be needed to the
> "BGP-LS SR
> Segment Descriptor Types” IANA registry at
> <https://urldefense.com/v3/__https://www.iana.org/assignments/bgp-ls-parameters/__;!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyVcl5es5Q$
> >)
> 4) Updates to the titles of Sections 5.7.1.1.1 - 5.7.1.1.11 to more closely
> match Table 6
>
>
> —Files (please refresh)—
>
> Updated XML file:
> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9857.xml__;!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyWxLv61Wg$
>
> Updated output files:
> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9857.txt__;!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyXZl_3-qQ$
> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9857.pdf__;!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyWpcW64rA$
> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9857.html__;!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyX4SSyzCQ$
>
> Diff files showing all changes made during AUTH48:
> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9857-auth48diff.html__;!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyXMg0_xow$
> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9857-auth48rfcdiff.html__;!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyW_WrJjiA$
> (side by side)
>
> Diff files showing only changes made during the last editing round:
> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9857-lastdiff.html__;!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyX_hYqEJQ$
> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9857-lastrfcdiff.html__;!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyV2Omod4w$
>
> Diff files showing all changes:
> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9857-diff.html__;!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyU2Qc-XpQ$
> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9857-rfcdiff.html__;!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyVbYay7_g$
> (side by side)
>
> For the AUTH48 status of this document, please see:
> https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9857__;!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyW-h2yu9g$
>
> Best regards,
>
> Karen Moore
> RFC Production Center
>
>
>> On Sep 16, 2025, at 7:56 AM, Jeff Tantsura <[email protected]> wrote:
>>
>> Hi Karen,
>>
>> Approved.
>> Thanks!
>>
>> Cheers,
>> Jeff
>>
>>> On Sep 15, 2025, at 13:00, Karen Moore <[email protected]> wrote:
>>>
>>> Hi Ketan,
>>>
>>> Thank you for the clarifications. We have updated 2 instances of “RESERVED”
>>> as advised in Section 5.7 and have updated Table 1 to match the
>>> descriptions in RFCs 9256, 9830, and 9831. Please review. We have also
>>> noted your approval of the document.
>>>
>>> If any further updates are needed in Sections 5.7.1.1.1 - 5.7.1.1.11 to
>>> more closely match the wording/changes in Table 1, please let us know.
>>>
>>> Note that we await approvals of the document from all coauthors listed at
>>> https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9857__;!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyW-h2yu9g$
>>> prior to moving forward with publicaiton.
>>>
>>> —Files (please refresh)—
>>>
>>> Updated XML file:
>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9857.xml__;!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyWxLv61Wg$
>>>
>>> Updated output files:
>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9857.txt__;!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyXZl_3-qQ$
>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9857.pdf__;!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyWpcW64rA$
>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9857.html__;!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyX4SSyzCQ$
>>>
>>> Diff files showing all changes made during AUTH48:
>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9857-auth48diff.html__;!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyXMg0_xow$
>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9857-auth48rfcdiff.html__;!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyW_WrJjiA$
>>> (side by side)
>>>
>>> Diff files showing only changes made during the last editing round:
>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9857-lastdiff.html__;!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyX_hYqEJQ$
>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9857-lastrfcdiff.html__;!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyV2Omod4w$
>>>
>>> Diff files showing all changes:
>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9857-diff.html__;!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyU2Qc-XpQ$
>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9857-rfcdiff.html__;!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyVbYay7_g$
>>> (side by side)
>>>
>>> For the AUTH48 status of this document, please see:
>>> https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9857__;!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyW-h2yu9g$
>>>
>>> Best regards,
>>>
>>> Karen Moore
>>> RFC Production Center
>>>
>>>
>>>
>>> On Sep 14, 2025, at 8:18 PM, Ketan Talaulikar <[email protected]> wrote:
>>>
>>> Hi Karen,
>>>
>>> Please check inline below for responses.
>>>
>>> Besides the comment below about Table 1, there is only one minor update
>>> needed: For the fields that were marked as RESERVED1 and 2 in the figures,
>>> please make the same change in the individual field descriptions below
>>> those figures as well.
>>>
>>> Once these are taken care of, please consider this email as my approval for
>>> publication.
>>>
>>>
>>> On Sat, Sep 13, 2025 at 5:35 AM Karen Moore <[email protected]>
>>> wrote:
>>> Hi Ketan,
>>>
>>> Thank you for your comment and close review of the questions/document. We
>>> have updated our files per your suggestions. Please note that we have a few
>>> additional questions.
>>>
>>> 1) Regarding the comments below, we updated the titles of Sections
>>> 5.7.1.1.1 - 5.7.1.1.11 accordingly. We also updated the descriptions in
>>> Table 6, which we agree will align better with RFCs-to-be 9830 and 9831.
>>> Please review to ensure the changes are correct.
>>>
>>> KT> Ack
>>>
>>>> Comparing this to RFC9830/1, the Table 1 is what is listed
>>>> in
>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9830.html*section-2.4.4.2__;Iw!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyUhEMEjGg$
>>>> and Table 6 is what is listed in
>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9831.html*section-3.1__;Iw!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyXrJw9_5w$
>>>> - more specifically, I would prefer
>>>> that we have alignment for the Table 1 column Segment Description with the
>>>> other two RFCs
>>>> with one change that we want to keep the (Type X) as a prefix in this
>>>> document.
>>>>
>>>> KT> There is no change required for Table 1, however, we can and perhaps
>>>> should
>>>
>>>> change the section titles 5.7.1.1.1 through 5.7.1.1.11 to reflect RFC9830
>>>> sections
>>>> 2.4.4.2.1 - 2.4.4.22 and RFC9831 sections 2.1 through 2.10.
>>>>
>>>> As an example: Type 1: SR-MPLS Label (Type A) -> Type 1: Segment Type A
>>>>
>>>> This will make the section headings short and align with the other two
>>>> RFCs that specify
>>>> the southbound BGP signaling while this document specifies its northbound
>>>> reporting.
>>>>
>>>> The titles for figures are ok.
>>>>
>>>> The descriptions can then be changed along the lines of
>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9831.html*section-3.1__;Iw!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyXrJw9_5w$
>>>>
>>>> As an example: (Type A) SR-MPLS Label -> Type A Segment
>>>>
>>>> Please let me know your views from the perspective of readability and
>>>> alignment across RFC9256 and
>>>> the 3 BGP RFCs under RFC Editor currently including this document.
>>>
>>> 2) It was mentioned that no changes were required for Table 1 - want to
>>> clarify if that is still the case or if any further updates are needed for
>>> consistency with the wording/style in Table 2 of RFC 9256.
>>>
>>> KT> The descriptions originate from
>>> https://urldefense.com/v3/__https://www.rfc-editor.org/rfc/rfc9256.html*table-2__;Iw!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyVy0twDtg$
>>> and so, we should try to make things consistent with that. The same is
>>> there in
>>> https://urldefense.com/v3/__https://www.rfc-editor.org/rfc/rfc9830*section-2.4.4.2__;Iw!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyVCaIBrBg$
>>> and
>>> https://urldefense.com/v3/__https://www.rfc-editor.org/rfc/rfc9831*section-2__;Iw!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyVZzeoH8g$
>>> - therefore, the Table 1 descriptions should be the same. The only
>>> exception is that the alphabetical Type is indicated in brackets to provide
>>> the necessary correlation between the two separate code point spaces. I
>>> hope this also covers the queries below.
>>>
>>> Thanks,
>>> Ketan
>>>
>>>
>>>
>>> Please also consider the following.
>>>
>>> a) Section 5.7.1.1.6 describes the IPv4 Local & Remote Interface Addresses
>>> as a “pair”; is “pair" correct to add to the description of Type F in Table
>>> 1?
>>>
>>> Current:
>>> (Type F) SR-MPLS Adjacency SID as IPv4 Local & Remote Interface Addresses
>>>
>>> Perhaps A:
>>> (Type F) SR-MPLS Adjacency SID as pair of IPv4 Local & Remote Interface
>>> Addresses
>>>
>>> Perhaps B (in attempt to follow the style of RFC 9256):
>>> (Type F) IPv4 Interface Addresses for SR-MPLS Adjacency SID as Local,
>>> Remote pair
>>>
>>> b) Does the pair consist of one IPv6 global address and one interface ID?
>>> Please let us know if any clarifcation is needed. This applies to Types G
>>> (Section 5.7.1.1.7) and J (Section 5.7.1.1.10).
>>>
>>> Table 1:
>>> Current:
>>> (Type G) SR-MPLS Adjacency SID as pair of IPv6 Global Address & Interface
>>> ID for
>>> Local & Remote nodes
>>>
>>> Perhaps A:
>>> (Type G) SR-MPLS Adjacency SID as pair of an IPv6 Global Address &
>>> Interface ID for Local & Remote Nodes
>>>
>>> Perhaps B (in attempt to follow the style of RFC 9256):
>>> (Type G) IPv6 Global Address & Interface ID for SR-MPLS Adjacency SID as
>>> Local, Remote Node pair
>>>
>>> Section 5.7.1.1.7
>>> Current:
>>> The Segment is an SR-MPLS Adjacency SID type and is specified as a
>>> pair of IPv6 global address and interface ID for local and remote
>>> nodes.
>>>
>>> Perhaps:
>>> The Segment is an SR-MPLS Adjacency SID type and is specified as a
>>> pair of one IPv6 global address and one interface ID for local and remote
>>> nodes.
>>>
>>> --Files--
>>> Note that it may be necessary for you to refresh your browser to view the
>>> most recent version. Please review the document carefully to ensure
>>> satisfaction as we do not make changes once it has been published as an RFC.
>>>
>>> We will await approvals from each author prior to moving forward in the
>>> publication process.
>>>
>>> Updated XML file:
>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9857.xml__;!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyWxLv61Wg$
>>>
>>> Updated output files:
>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9857.txt__;!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyXZl_3-qQ$
>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9857.pdf__;!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyWpcW64rA$
>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9857.html__;!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyX4SSyzCQ$
>>>
>>> Diff files showing all changes made during AUTH48:
>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9857-auth48diff.html__;!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyXMg0_xow$
>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9857-auth48rfcdiff.html__;!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyW_WrJjiA$
>>> (side by side)
>>>
>>> Diff files showing all changes:
>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9857-diff.html__;!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyU2Qc-XpQ$
>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9857-rfcdiff.html__;!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyVbYay7_g$
>>> (side by side)
>>>
>>> For the AUTH48 status of this document, please see:
>>> https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9857__;!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyW-h2yu9g$
>>>
>>> Best regards,
>>>
>>> Karen Moore
>>> RFC Production Center
>>>
>>>
>>>> On Sep 11, 2025, at 5:14 AM, Ketan Talaulikar <[email protected]>
>>>> wrote:
>>>>
>>>> Hi Karen & Allana,
>>>>
>>>> Thanks for your help with this document. I realize it was challenging
>>>> given the inconsistent use of terms within the document and across its
>>>> related documents. Appreciate your tidying it up for publication.
>>>>
>>>> Please check inline below for responses.
>>>>
>>>>
>>>> On Thu, Sep 11, 2025 at 3:39 AM <[email protected]> wrote:
>>>> Authors,
>>>>
>>>> While reviewing this document during AUTH48, please resolve (as necessary)
>>>> the following questions, which are also in the source file.
>>>>
>>>> 1) <!--[rfced] May we update "PCEP protocol" to simply read "PCEP" to
>>>> avoid redundancy? If expanded, "PCEP protocol" would read as "Path
>>>> Computation Element Communication Protocol protocol".
>>>>
>>>> Original:
>>>> As illustrated in the figure below, the
>>>> PCC is not an LSR in the routing domain, thus the head-end nodes of
>>>> the SR Policies may not implement the PCEP protocol.
>>>>
>>>> Perhaps:
>>>> As illustrated in the figure below, the
>>>> PCC is not an LSR in the routing domain, thus the head-end nodes of
>>>> the SR Policies may not implement the PCEP.
>>>> -->
>>>>
>>>> KT> Ack
>>>>
>>>>
>>>>
>>>> 2) <!--[rfced] In Section 3, should the list be formatted as a definition
>>>> list for ease of reading and consistency with other sections?
>>>>
>>>> Original:
>>>> Where:
>>>>
>>>> * Protocol-ID field specifies the component that owns the SR Policy
>>>> state in the advertising node. An additional Protocol-ID "Segment
>>>> Routing" (value 9) is introduced by this document that MUST be
>>>> used for advertisement of SR Policies.
>>>>
>>>> * "Identifier" is an 8 octet value as defined in section 5.2 of
>>>> [RFC9552].
>>>>
>>>> * "Local Node Descriptor" (TLV 256) [RFC9552] is used as specified
>>>> further in this section.
>>>>
>>>> * The SR Policy Candidate Path Descriptor TLV is specified in
>>>> Section 4.
>>>>
>>>> Perhaps:
>>>> Where:
>>>>
>>>> * Protocol-ID field: Specifies the component that owns the SR Policy
>>>> state in the advertising node. An additional Protocol-ID "Segment
>>>> Routing" (value 9) is introduced by this document that MUST be
>>>> used for the advertisement of SR Policies.
>>>>
>>>> * Identifier: 8-octet value as defined in Section 5.2 of [RFC9552].
>>>>
>>>> * Local Node Descriptors (TLV 256): Defined in [RFC9552] and used as
>>>> specified further in this section.
>>>>
>>>> * SR Policy Candidate Path Descriptor TLV: Specified in Section 4.
>>>> -->
>>>>
>>>> KT> Ack
>>>>
>>>>
>>>>
>>>> 3) <!--[rfced] As shown below, we removed "Number" from "Autonomous
>>>> System Number (TLV 512)" per RFC 9552, and we removed "ASN"
>>>> following "AS Confederation Identifier" as it is not present in
>>>> RFC 5065. Note that this change was also applied to similar text
>>>> in Section 3.2. Please let us know of any objections.
>>>>
>>>> Note that "ASN" was expanded only on the first mention.
>>>>
>>>> Original:
>>>> * Autonomous System Number (TLV 512) [RFC9552], which contains the
>>>> ASN (or AS Confederation Identifier (ASN) [RFC5065], if
>>>> confederations are used) of the headend node of the SR Policy.
>>>>
>>>> Current:
>>>> * Autonomous System (TLV 512) [RFC9552], which contains the
>>>> Autonomous System Number (ASN) (or AS Confederation Identifier
>>>> [RFC5065], if confederations are used) of the headend node of
>>>> the SR Policy.
>>>> -->
>>>>
>>>> KT> Ack
>>>>
>>>>
>>>>
>>>> 4) <!--[rfced] In RFC 9552, we note that "IGP Router-ID" is listed as
>>>> both a sub-TLV and a TLV code point. As "sub-TLV" and "TLV" are
>>>> not included in the description, how may we update "IGP Router-ID
>>>> sub-TLV (TLV 515)" for conciseness? Would "IGP Router-ID
>>>> (sub-TLV/TLV 515)" be correct? Note that there are two instances
>>>> in the document.
>>>>
>>>> Original:
>>>> The determination of whether the
>>>> IGP Router-ID sub-TLV (TLV 515) contains a 4-octet OSPF Router-ID
>>>> or a 6-octet ISO System-ID is to be done based on the length of
>>>> that sub-TLV since the Protocol-ID in the NLRI is always going to
>>>> be "Segment Routing".
>>>>
>>>> Perhaps:
>>>> The determination of whether the
>>>> IGP Router-ID (sub-TLV/TLV 515) contains a 4-octet OSPF Router-ID
>>>> or a 6-octet ISO System-ID is to be done based on the length of
>>>> that sub-TLV because the Protocol-ID in the NLRI is always going
>>>> to be "Segment Routing".
>>>> -->
>>>>
>>>> KT> The reference here is to the TLV and the IANA registry is for TLV
>>>> codepoints but they can also be used as sub-TLVs. So, I agree that your
>>>> suggestion is better, but how about "IGP Router-ID (TLV 515)" ?
>>>>
>>>>
>>>>
>>>> 5) <!-- [rfced] We note that Section 6.2.3 of RFC 9256 uses
>>>> "Specified-BSID-only". Given this, should "Specified BSID" be
>>>> updated for consistency?
>>>>
>>>> Original:
>>>> The TLV MAY also optionally contain the Specified BSID value for
>>>> reporting as described in section 6.2.3 of [RFC9256].
>>>>
>>>> Perhaps:
>>>> The TLV MAY also optionally contain the Specified-BSID-only value
>>>> for reporting as described in Section 6.2.3 of [RFC9256].
>>>> -->
>>>>
>>>> KT> This change is not appropriate. Here, the idea is to signal the
>>>> Specified-BSID value. Whether or not the Specified-BSID-only is to be used
>>>> is indicated by a different flag.
>>>>
>>>>
>>>>
>>>> 6) <!--[rfced] Please clarify if "BSID" should be singular (option A) or
>>>> plural (option B) in the following:
>>>>
>>>> Original:
>>>> D-Flag: Indicates the dataplane for the BSIDs and if they are
>>>> 16 octet SRv6 SID (when set) or are 4 octet SR/MPLS
>>>> label value (when clear).
>>>>
>>>> Perhaps A:
>>>> D-Flag: Indicates the data plane for the BSIDs and if a BSID is
>>>> a 16-octet SRv6 SID (when set) or a 4-octet SR/MPLS
>>>> label value (when clear).
>>>>
>>>> Perhaps B:
>>>> D-Flag: Indicates the data plane for the BSIDs and if the BSIDs
>>>> are 16-octet SRv6 SIDs (when set) or 4-octet SR/MPLS
>>>> label values (when clear).
>>>> -->
>>>>
>>>> KT> A is better.
>>>>
>>>>
>>>>
>>>> 7) <!--[rfced] We note that Figures 7 and 19 use "Sub-TLVs" (capitalized),
>>>> while Figures 11 and 18 use "sub-TLVs" (lowercased). Should these be
>>>> consistent? If yes, which form is preferred?
>>>> -->
>>>>
>>>> KT> Here "sub-TLVs" is appropriate as it is not referring to a specific
>>>> sub-TLV name.
>>>>
>>>>
>>>>
>>>>
>>>> 8) <!--[rfced] We note multiple instances of "MUST be set to 0 by the
>>>> originator and MUST be ignored by a receiver". Should the one
>>>> instance below that contains only one "MUST" be updated
>>>> accordingly (see Section 5.3)?
>>>>
>>>> Original:
>>>> V-Flag: Indicates the candidate path has at least one valid SID-List
>>>> when set and indicates no valid SID-List is available or evaluated
>>>> when clear. When the E-Flag is clear (i.e. the candidate path has not
>>>> been evaluated), then this flag MUST be set to 0 by the originator and
>>>> ignored by the receiver.
>>>>
>>>> Perhaps:
>>>> V-Flag: Indicates that the candidate path has at least one valid SID-List
>>>> when set and that no valid SID-List is available or evaluated when clear.
>>>> When the E-Flag is clear (i.e., the candidate path has not been evaluated),
>>>> then this flag MUST be set to 0 by the originator and MUST be ignored by a
>>>> receiver.
>>>> -->
>>>>
>>>> KT> Ack
>>>>
>>>>
>>>>
>>>> 9) <!--[rfced] Please review 2 instances of the term "NULL" in this
>>>> document. Should "NULL terminator" be "NUL terminator" or "null
>>>> terminator" for correctness? We ask per guidance received from a
>>>> Gen Art reviewer. Note that RFC 9256 uses "null endpoint",
>>>> "Explicit Null Label Policy", and "IPv6 Explicit NULL Label".
>>>>
>>>> Current:
>>>> SR Policy Name: Symbolic name for the SR Policy without a NULL
>>>> terminator as specified in Section 2.1 of [RFC9256].
>>>>
>>>> Candidate Path Name: Symbolic name for the SR Policy candidate path
>>>> without a NULL terminator as specified in Section 2.6 of
>>>> [RFC9256].
>>>> -->
>>>>
>>>> KT> It should be the NUL - which is what I believe it is called in ASCII.
>>>>
>>>>
>>>>
>>>> 10) <!--[rfced] How may we clarify this "either" sentence. Is the intended
>>>> meaning that the dynamic path is computed by the headend or
>>>> delegated to a controller (option A)? Or that the dynamic path is
>>>> computed by the headend or by delegation to a controller (option B)?
>>>>
>>>> Original:
>>>> The constraints are generally applied to a dynamic candidate path which is
>>>> computed either by the headend or may be delegated to a controller.
>>>>
>>>> Perhaps A:
>>>> The constraints are generally applied to a dynamic candidate path that is
>>>> either computed by the headend or delegated to a controller.
>>>>
>>>> Perhaps B:
>>>> The constraints are generally applied to a dynamic candidate path that is
>>>> computed by either the headend or delegation to a controller.
>>>> -->
>>>>
>>>> KT> A is correct.
>>>>
>>>>
>>>>
>>>> 11) <!--[rfced] We note that Figure 15 uses "Request-Flags" and
>>>> "Status-Flags"
>>>> (hyphenated), while the definitions of these fields use "Request Flags"
>>>> and "Status Flags" (unhyphenated). To make these consistent, which form is
>>>> preferred?
>>>> -->
>>>>
>>>> KT> the unhyphenated please
>>>>
>>>>
>>>>
>>>> 12) <!-- [rfced] For consistency, should "Association Object" be updated
>>>> to "ASSOCIATION object" per use in Section 6.1 of [RFC8697]? Note
>>>> that there are four instances.
>>>> -->
>>>>
>>>> KT> Ack
>>>>
>>>>
>>>>
>>>> 13) <!--[rfced] How may we rephrase the text in Section 5.6.6 for clarity?
>>>>
>>>> KT> I think a copy/paste error from my side in section 5.6.6 with
>>>> referencine Table 1 has caused a confusion between metric types and
>>>> segment types.
>>>>
>>>> In the first sentence, we note that Table 1 (Section 5.7.1.1)
>>>> does not list references for the types. Should the term
>>>> "reference" be replaced with "Segment Descriptor" or other for
>>>> conciseness? And may we rephrase the second sentence as shown
>>>> below for clarity and to make it parallel?
>>>>
>>>> We also note that Tables 1 and 6 contain the same information. Should
>>>> Table 1 be removed and references to Table 1 (in Sections 5.6.6 and
>>>> 5.7.1.1) be updated to point to Table 6?
>>>>
>>>> KT> The two tables have different purposes. The Table 1 provides the
>>>> mapping between the
>>>> segment types (A to K) defined in RFC 9256 with the code points of the
>>>> types defined in
>>>> this document. While table 6 represents the initial allocations for the
>>>> codepoints
>>>> for the segment types for IANA. Comparing this to RFC9830/1, the Table 1
>>>> is what is listed
>>>> in
>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9830.html*section-2.4.4.2__;Iw!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyUhEMEjGg$
>>>> and Table 6 is what is listed in
>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9831.html*section-3.1__;Iw!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyXrJw9_5w$
>>>> - more specifically, I would prefer
>>>> that we have alignment for the Table 1 column Segment Description with the
>>>> other two RFCs
>>>> with one change that we want to keep the (Type X) as a prefix in this
>>>> document.
>>>>
>>>> KT> There is no change required for Table 1, however, we can and perhaps
>>>> should
>>>> change the section titles 5.7.1.1.1 through 5.7.1.1.11 to reflect RFC9830
>>>> sections
>>>> 2.4.4.2.1 - 2.4.4.22 and RFC9831 sections 2.1 through 2.10.
>>>>
>>>> As an example: Type 1: SR-MPLS Label (Type A) -> Type 1: Segment Type A
>>>>
>>>> This will make the section headings short and align with the other two
>>>> RFCs that specify
>>>> the southbound BGP signaling while this document specifies its northbound
>>>> reporting.
>>>>
>>>> The titles for figures are ok.
>>>>
>>>> The descriptions can then be changed along the lines of
>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9831.html*section-3.1__;Iw!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyXrJw9_5w$
>>>>
>>>> As an example: (Type A) SR-MPLS Label -> Type A Segment
>>>>
>>>> Please let me know your views from the perspective of readability and
>>>> alignment across RFC9256 and
>>>> the 3 BGP RFCs under RFC Editor currently including this document.
>>>>
>>>>
>>>> Original (Section 5.6.6):
>>>> The Table 1 below lists the metric types introduced by this document
>>>> along with reference for each. Where the references are for IS-IS
>>>> and OSPF specifications, those metric types are defined for a link
>>>> while in the SR Policy context those relate to the candidate path
>>>> or the segment list.
>>>>
>>>> Perhaps:
>>>> Table 6 lists the metric types introduced by this document along
>>>> with a Segment Descriptor for each. Where the Segment Descriptors
>>>> relate to IS-IS and OSPF specifications, the metric types are defined
>>>> for a link. Where the Segment Descriptors relate to the SR Policy,
>>>> the metric types are defined for a candidate path or a segment list.
>>>>
>>>>
>>>> KT> Can you please fix/update this blob as below?
>>>>
>>>> Below is a list of metric types introduced by this document
>>>> along with references for each. Where the references are for IS-IS
>>>> and OSPF specifications, those metric types are defined for a link
>>>> while in the SR Policy context those relate to the candidate path
>>>> or the segment list.
>>>>
>>>> The "list" is actually right after the paragraph with this text and the
>>>> reference to Table 1
>>>> was an error. I hope this clarifies.
>>>>
>>>> ...
>>>> Original (Section 5.7.1.1)
>>>> The following types are currently defined and their mapping to the
>>>> respective segment types defined in [RFC9256]:
>>>>
>>>> Perhaps:
>>>> See Table 6 for the type definitions and their mappings to the
>>>> respective segment types defined in [RFC9256].
>>>> -->
>>>>
>>>> KT> The above change is now not necessary.
>>>>
>>>>
>>>>
>>>> 14) <!--[rfced] For clarity, should the registry that the metric types are
>>>> taken from be listed here instead of only the registry that they are
>>>> not listed in?
>>>>
>>>> Original:
>>>> Note that the metric type in this field is not taken from the "IGP
>>>> Metric Type" registry from IANA "IGP Parameters" and is a separate
>>>> registry that includes IGP Metric Types as well as metric types
>>>> specific to SR Policy path computation.
>>>>
>>>> Perhaps:
>>>> Note that the metric types in this field are taken from the
>>>> "BGP-LS SR Policy Metric Types" IANA registry, which includes
>>>> IGP Metric Types as well as metric types specific to SR Policy
>>>> path computation (i.e., the metric types are not from the
>>>> "IGP Metric-Type" registry).
>>>> -->
>>>>
>>>> KT> Ack
>>>>
>>>>
>>>>
>>>> 15) <!--[rfced] In Section 5.6.6, we updated "Average" to "Avg" to
>>>> match use in Table 7 and the "BGP-LS SR Policy Metric Types"
>>>> registry. If you prefer to update the registry to reflect
>>>> "Average" instead of "Avg", please let us know.
>>>>
>>>> Link to registry:
>>>> https://urldefense.com/v3/__https://www.iana.org/assignments/bgp-ls-parameters/__;!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyVcl5es5Q$
>>>> bgp-ls-parameters.xhtml#bgp-ls-sr-segment-descriptor-types>.
>>>>
>>>> Original:
>>>> Type 6: Average Unidirectional Delay:
>>>>
>>>> Current:
>>>> Type 6: Avg Unidirectional Delay:
>>>> -->
>>>>
>>>> KT> Ack
>>>>
>>>>
>>>>
>>>> 16) <!--[rfced] We note that Figure 18 contains two "RESERVED" fields.
>>>> As these are two distinctly different fields, should they be updated
>>>> as "RESERVED1" and "RESERVED2", which would reflect Figure 11?
>>>> -->
>>>>
>>>> KT> Yes, please do the same for Figure 11
>>>>
>>>>
>>>>
>>>>
>>>> 17) <!--[rfced] Table 6 (Section 8.5) specifies the SRv6 SID as an "IPv6
>>>> address", but Section 5.7.1.1.2 specifies it as an "SRv6 SID address".
>>>> Is an update needed in Section 5.7.1.1.2 for consistency with Table 6?
>>>>
>>>> Original:
>>>> The Segment is SRv6 type and is specified simply as the SRv6 SID address.
>>>>
>>>> Perhaps:
>>>> The Segment is an SRv6 type and is specified simply as the IPv6 address.
>>>> -->
>>>>
>>>> KT> It should just say "SRv6 SID" in 7.7.1.1.2 and in Table 6. But please
>>>> refer to the previous suggestion on Table 6.
>>>>
>>>>
>>>>
>>>> 18) <!--[rfced] In Section 5.7.1.1.6, should "interface" be added to more
>>>> closely match Table 6 (the "BGP-LS SR Segment Descriptor Types"
>>>> registry)?
>>>>
>>>> Link to registry:
>>>> https://urldefense.com/v3/__https://www.iana.org/assignments/bgp-ls-parameters/__;!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyVcl5es5Q$
>>>> bgp-ls-parameters.xhtml#bgp-ls-sr-segment-descriptor-types
>>>>
>>>> Original:
>>>> IPv4 Local Address:
>>>> IPv4 Remote Address:
>>>>
>>>> Perhaps:
>>>> IPv4 Local Interface Address:
>>>> IPv4 Remote Interface Address:
>>>>
>>>> ...
>>>> Original (Figure 25):
>>>> IPv4 Local Address (4 octets)
>>>> IPv4 Remote Address (4 octets)
>>>>
>>>> Perhaps:
>>>> IPv4 Local Interface Address (4 octets)
>>>> IPv4 Remote Interface Address (4 octets)
>>>> -->
>>>>
>>>> KT> Ack for both
>>>>
>>>>
>>>>
>>>> 19) <!--[rfced] In Sections 5.7.1.1.8 and 5.7.1.1.11, should the following
>>>> be updated for consistency with the descriptions in Table 6 (the
>>>> "BGP-LS SR Segment Descriptor Types" registry)?
>>>>
>>>> Link to registry:
>>>> https://urldefense.com/v3/__https://www.iana.org/assignments/bgp-ls-parameters/__;!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyVcl5es5Q$
>>>> bgp-ls-parameters.xhtml#bgp-ls-sr-segment-descriptor-types?
>>>>
>>>> Original:
>>>> IPv6 Local Address:
>>>> IPv6 Remote Address:
>>>>
>>>> Perhaps:
>>>> IPv6 Local Global Address:
>>>> IPv6 Remote Global Address:
>>>>
>>>> ...
>>>> Original (Figures 27 and 30):
>>>> Global IPv6 Local Interface Address (16 octets)
>>>> Global IPv6 Remote Interface Address (16 octets)
>>>>
>>>> Perhaps:
>>>> IPv6 Local Interface Global Address (16 octets)
>>>> IPv6 Remote Interface Global Address (16 octets)
>>>> -->
>>>>
>>>> KT> Ack for both.
>>>>
>>>>
>>>>
>>>> 20) <!-- [rfced] Section 4 of this document as well as RFC 9256 uses
>>>> "Protocol-Origin" rather than "Protocol Origin". Are any updates
>>>> needed to the "SR Policy Protocol Origin" registry name, two
>>>> instances of "SR Protocol Origin", or "Protocol Origin field"?
>>>>
>>>> Original:
>>>> Per this document, IANA has created and maintains a new registry
>>>> called "SR Policy Protocol Origin" under the "Segment Routing"
>>>> registry group with the allocation policy of Expert Review [RFC8126]
>>>> using the guidelines for designated experts as specified in
>>>> [RFC9256]. This registry contains the code points allocated to the
>>>> "Protocol Origin" field defined in Section 4.
>>>> -->
>>>>
>>>> KT> Lets use "Protocol-Origin" to be consistent with RFC9256
>>>>
>>>>
>>>>
>>>> 21) <!--[rfced] Under the "Segment Descriptor" column in the "BGP-LS SR
>>>> Segment Descriptor Types" registry, should the following changes
>>>> be made to the code point descriptions? That is, add articles,
>>>> make names following "pair" plural, and capitalize instances of
>>>> "address" and "node", accordingly.
>>>>
>>>> The form to the right of the arrow is suggested. If changes are made,
>>>> we will update the running text accordingly (namely the subsections
>>>> under Section 5.7.1.1) as well as the IANA registry.
>>>>
>>>> Link to registry:
>>>> <https://urldefense.com/v3/__https://www.iana.org/assignments/bgp-ls-parameters/__;!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyVcl5es5Q$
>>>> bgp-ls-parameters.xhtml#bgp-ls-sr-segment-descriptor-types>
>>>>
>>>> (Type B) SRv6 SID as IPv6 address -> (Type B) SRv6 SID as an IPv6 Address
>>>>
>>>>
>>>> (Type C) SR-MPLS Prefix SID as IPv4 Node Address ->
>>>> (Type C) SR-MPLS Prefix SID as an IPv4 Node Address
>>>>
>>>> (Type D) SR-MPLS Prefix SID as IPv6 Node Global Address ->
>>>> (Type D) SR-MPLS Prefix SID as an IPv6 Node Global Address
>>>>
>>>> (Type E) SR-MPLS Adjacency SID as IPv4 Node Address & Local Interface ID ->
>>>> (Type E) SR-MPLS Adjacency SID as an IPv4 Node Address & a Local
>>>> Interface ID
>>>>
>>>> (Note: Section 5.7.1.1.6 describes Type F as a "pair"; is that correct to
>>>> add?)
>>>> (Type F) SR-MPLS Adjacency SID as IPv4 Local & Remote Interface Addresses
>>>> ->
>>>> (Type F) SR-MPLS Adjacency SID as a pair of IPv4 Local & Remote
>>>> Interface Addresses
>>>>
>>>> (Type G) SR-MPLS Adjacency SID as pair of IPv6 Global Address & Interface
>>>> ID for
>>>> Local & Remote nodes ->
>>>> (Type G) SR-MPLS Adjacency SID as a pair of IPv6 Global Addresses &
>>>> Interface IDs for Local & Remote Nodes
>>>>
>>>> (Type H) SR-MPLS Adjacency SID as pair of IPv6 Global Addresses for the
>>>> Local & Remote Interface ->
>>>> (Type H) SR-MPLS Adjacency SID as a pair of IPv6 Global Addresses for
>>>> Local & Remote Interface Addresses
>>>>
>>>> (Type I) SRv6 END SID as IPv6 Node Global Address ->
>>>> (Type I) SRv6 END SID as an IPv6 Node Global Address
>>>>
>>>> (Type J) SRv6 END.X SID as pair of IPv6 Global Address & Interface ID
>>>> for Local & Remote nodes ->
>>>> (Type J) SRv6 END.X SID as a pair of IPv6 Global Addresses & Interface
>>>> IDs
>>>> for Local & Remote Nodes
>>>>
>>>> (Type K) SRv6 END.X SID as pair of IPv6 Global Addresses for the Local &
>>>> Remote Interface ->
>>>> (Type K) SRv6 END.X SID as a pair of IPv6 Global Addresses for Local &
>>>> Remote Interface Addresses
>>>> -->
>>>>
>>>> KT> Please refer to my response to your point 13 that impacts this. With
>>>> that in mind, I would think
>>>> that these queries are no longer relevant?
>>>>
>>>>
>>>>
>>>> 22) <!--[rfced] FYI: In the Contributors section, we updated the lead-in
>>>> text as follows to indicate that the individuals listed are
>>>> coauthors.
>>>>
>>>> Original:
>>>> The following people have substantially contributed to the editing of
>>>> this document:
>>>>
>>>> Current:
>>>> The following people have contributed substantially to the
>>>> content of this document and should be considered coauthors:
>>>> -->
>>>>
>>>> KT> Ack
>>>>
>>>>
>>>>
>>>> 23) <!-- [rfced] Terminology
>>>>
>>>> a) Throughout the text, the following terminology appears to be used
>>>> inconsistently. Please review these occurrences and let us know if/how they
>>>> may be made consistent.
>>>>
>>>> -Flag vs. -flag
>>>> (e.g., "D-Flag" vs. "A-flag" in the running text)
>>>>
>>>> KT> -flag
>>>>
>>>> Metric Type field vs. "metric type" field
>>>> (Note: the companion document uses "metric type field" with no quote marks)
>>>>
>>>> KT> metric type field - without the quotes
>>>>
>>>> Segment Descriptor vs. Segment descriptor
>>>>
>>>> KT> segment descriptor (except when used in titles where capitalization is
>>>> used)
>>>>
>>>> Segment List vs. segment list
>>>>
>>>> KT> 2nd
>>>>
>>>> SID-List vs. SID-list vs. SID-LIST vs. SID List
>>>>
>>>> KT> SID list to be consistent with a single usage in RFC9256
>>>>
>>>> SR Policy Candidate Path NLRI Type vs. SR Policy Candidate Path NLRI type
>>>>
>>>> KT> 2nd
>>>>
>>>>
>>>> SR Policy Candidate Path vs. SR Policy Candidate path vs. SR Policy
>>>> candidate path
>>>>
>>>> KT> Capitalization when used in name (1st) and otherwise (3rd)
>>>>
>>>>
>>>>
>>>> b) We updated the following terms for consistency. Please let us know of
>>>> any objections.
>>>>
>>>> codepoint -> code point (per IANA registries)
>>>> dataplane -> data plane
>>>> drop upon invalid -> Drop-Upon-Invalid (per RFC 9256)
>>>> Global address -> global address (2 instances in the running text)
>>>> head-end -> headend
>>>> nexthop -> next hop
>>>> traffic engineering -> Traffic Engineering (per RFC 9552 and the companion
>>>> document)
>>>>
>>>> KT> Ack
>>>>
>>>>
>>>> c) FYI: We made "Constraints" in the following sub-TLV names singular for
>>>> consistency
>>>> with Table 4.
>>>>
>>>> SR Affinity Constraints Sub-TLV -> SR Affinity Constraint Sub-TLV (Figure
>>>> 12)
>>>> SR Bandwidth Constraints Sub-TLV -> SR Bandwidth Constraint Sub-TLV
>>>> (Figure 14)
>>>>
>>>> SR Bidirectional Group Constraints Sub-TLV ->
>>>> SR Bidirectional Group Constraint Sub-TLV (Figure 16)
>>>>
>>>> SR Disjoint Group Constraints Sub-TLV -> SR Disjoint Group Constraint
>>>> Sub-TLV (Figure 15)
>>>> SR Metric Constraints Sub-TLV -> SR Metric Constraint Sub-TLV (Figure 17
>>>> and Section 5.7.2)
>>>> SR SRLG Constraints Sub-TLV -> SR SRLG Constraint Sub-TLV (Figure 13)
>>>>
>>>> KT> Ack
>>>>
>>>>
>>>> d) FYI: We updated 7 instances of "Descriptor" to "Descriptors"
>>>> for TLV 256 per RFC 9552.
>>>>
>>>> Local Node Descriptor (TLV 256) -> Local Node Descriptors (TLV 256)
>>>> -->
>>>>
>>>> KT> Ack
>>>>
>>>>
>>>>
>>>> 24) <!-- [rfced] Abbreviations
>>>>
>>>> a) FYI - We have added expansions for the following abbreviations
>>>> per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
>>>> expansion in the document carefully to ensure correctness.
>>>>
>>>> Autonomous System Number (ASN)
>>>> Bidirectional Forwarding Detection (BFD)
>>>> External BGP (EBGP)
>>>> Label Edge Routers (LERs)
>>>> Label Switched Path (LSP)
>>>> Label Switching Router (LSR)
>>>> Network Layer Reachability Information (NLRI)
>>>> Path Computation Element Communication Protocol (PCEP)
>>>>
>>>> KT> Ack
>>>>
>>>>
>>>>
>>>> b) To reflect more common usage in previously published RFCs, may we update
>>>> the expansion of "BGP-LS" from "BGP Link-State" to "BGP - Link State"? If
>>>> yes,
>>>> note that the title of this document would also be updated accordingly.
>>>>
>>>> Original:
>>>> Advertisement of Segment Routing Policies using BGP Link-State
>>>> ...
>>>> This document describes a mechanism to collect the Segment Routing
>>>> Policy information that is locally available in a node and advertise
>>>> it into BGP Link-State (BGP-LS) updates.
>>>>
>>>> Perhaps:
>>>> Advertisement of Segment Routing Policies using BGP - Link State
>>>> ...
>>>> This document describes a mechanism to collect the Segment Routing
>>>> Policy information that is locally available in a node and advertise
>>>> it into BGP - Link State (BGP-LS) updates.
>>>> -->
>>>>
>>>> KT> ack
>>>>
>>>>
>>>>
>>>> 25) <!-- [rfced] Please review the "Inclusive Language" portion of the
>>>> online
>>>> Style Guide
>>>> <https://urldefense.com/v3/__https://www.rfc-editor.org/styleguide/part2/*inclusive_language__;Iw!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyV_9i0NgA$
>>>> >
>>>> and let us know if any changes are needed. Updates of this nature
>>>> typically
>>>> result in more precise language, which is helpful for readers.
>>>>
>>>> Note that our script did not flag any words in particular, but this should
>>>> still be reviewed as a best practice.
>>>> -->
>>>>
>>>> KT> Looks good to me.
>>>>
>>>> Thanks,
>>>> Ketan
>>>>
>>>>
>>>>
>>>> Thank you.
>>>>
>>>> Karen Moore and Alanna Paloma
>>>> RFC Production Center
>>>>
>>>>
>>>> On Sep 10, 2025, at 3:08 PM, [email protected] wrote:
>>>>
>>>> *****IMPORTANT*****
>>>>
>>>> Updated 2025/09/10
>>>>
>>>> RFC Author(s):
>>>> --------------
>>>>
>>>> Instructions for Completing AUTH48
>>>>
>>>> Your document has now entered AUTH48. Once it has been reviewed and
>>>> approved by you and all coauthors, it will be published as an RFC.
>>>> If an author is no longer available, there are several remedies
>>>> available as listed in the FAQ
>>>> (https://urldefense.com/v3/__https://www.rfc-editor.org/faq/__;!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyXvctUK_g$
>>>> ).
>>>>
>>>> You and you coauthors are responsible for engaging other parties
>>>> (e.g., Contributors or Working Group) as necessary before providing
>>>> your approval.
>>>>
>>>> Planning your review
>>>> ---------------------
>>>>
>>>> Please review the following aspects of your document:
>>>>
>>>> * RFC Editor questions
>>>>
>>>> Please review and resolve any questions raised by the RFC Editor
>>>> that have been included in the XML file as comments marked as
>>>> follows:
>>>>
>>>> <!-- [rfced] ... -->
>>>>
>>>> These questions will also be sent in a subsequent email.
>>>>
>>>> * Changes submitted by coauthors
>>>>
>>>> Please ensure that you review any changes submitted by your
>>>> coauthors. We assume that if you do not speak up that you
>>>> agree to changes submitted by your coauthors.
>>>>
>>>> * Content
>>>>
>>>> Please review the full content of the document, as this cannot
>>>> change once the RFC is published. Please pay particular attention to:
>>>> - IANA considerations updates (if applicable)
>>>> - contact information
>>>> - references
>>>>
>>>> * Copyright notices and legends
>>>>
>>>> Please review the copyright notice and legends as defined in
>>>> RFC 5378 and the Trust Legal Provisions
>>>> (TLP –
>>>> https://urldefense.com/v3/__https://trustee.ietf.org/license-info__;!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyWFTQ7lZA$
>>>> ).
>>>>
>>>> * Semantic markup
>>>>
>>>> Please review the markup in the XML file to ensure that elements of
>>>> content are correctly tagged. For example, ensure that <sourcecode>
>>>> and <artwork> are set correctly. See details at
>>>> <https://urldefense.com/v3/__https://authors.ietf.org/rfcxml-vocabulary__;!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyVFxynzPA$
>>>> >.
>>>>
>>>> * Formatted output
>>>>
>>>> Please review the PDF, HTML, and TXT files to ensure that the
>>>> formatted output, as generated from the markup in the XML file, is
>>>> reasonable. Please note that the TXT will have formatting
>>>> limitations compared to the PDF and HTML.
>>>>
>>>>
>>>> Submitting changes
>>>> ------------------
>>>>
>>>> To submit changes, please reply to this email using ‘REPLY ALL’ as all
>>>> the parties CCed on this message need to see your changes. The parties
>>>> include:
>>>>
>>>> * your coauthors
>>>>
>>>> * [email protected] (the RPC team)
>>>>
>>>> * other document participants, depending on the stream (e.g.,
>>>> IETF Stream participants are your working group chairs, the
>>>> responsible ADs, and the document shepherd).
>>>>
>>>> * [email protected], which is a new archival mailing list
>>>> to preserve AUTH48 conversations; it is not an active discussion
>>>> list:
>>>>
>>>> * More info:
>>>>
>>>> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc__;!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyWTvQQngw$
>>>>
>>>> * The archive itself:
>>>>
>>>> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/browse/auth48archive/__;!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyXGlj5uPw$
>>>>
>>>> * Note: If only absolutely necessary, you may temporarily opt out
>>>> of the archiving of messages (e.g., to discuss a sensitive matter).
>>>> If needed, please add a note at the top of the message that you
>>>> have dropped the address. When the discussion is concluded,
>>>> [email protected] will be re-added to the CC list and
>>>> its addition will be noted at the top of the message.
>>>>
>>>> You may submit your changes in one of two ways:
>>>>
>>>> An update to the provided XML file
>>>> — OR —
>>>> An explicit list of changes in this format
>>>>
>>>> Section # (or indicate Global)
>>>>
>>>> OLD:
>>>> old text
>>>>
>>>> NEW:
>>>> new text
>>>>
>>>> You do not need to reply with both an updated XML file and an explicit
>>>> list of changes, as either form is sufficient.
>>>>
>>>> We will ask a stream manager to review and approve any changes that seem
>>>> beyond editorial in nature, e.g., addition of new text, deletion of text,
>>>> and technical changes. Information about stream managers can be found in
>>>> the FAQ. Editorial changes do not require approval from a stream manager.
>>>>
>>>>
>>>> Approving for publication
>>>> --------------------------
>>>>
>>>> To approve your RFC for publication, please reply to this email stating
>>>> that you approve this RFC for publication. Please use ‘REPLY ALL’,
>>>> as all the parties CCed on this message need to see your approval.
>>>>
>>>>
>>>> Files
>>>> -----
>>>>
>>>> The files are available here:
>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9857.xml__;!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyWxLv61Wg$
>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9857.html__;!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyX4SSyzCQ$
>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9857.pdf__;!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyWpcW64rA$
>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9857.txt__;!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyXZl_3-qQ$
>>>>
>>>> Diff file of the text:
>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9857-diff.html__;!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyU2Qc-XpQ$
>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9857-rfcdiff.html__;!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyVbYay7_g$
>>>> (side by side)
>>>>
>>>> Diff of the XML:
>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9857-xmldiff1.html__;!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyUsHTfAmg$
>>>>
>>>>
>>>> Tracking progress
>>>> -----------------
>>>>
>>>> The details of the AUTH48 status of your document are here:
>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9857__;!!NEt6yMaO-gk!D4F1Vd1X-_yDK9ojj8Y7U7lduUFStPzG0ytqztur5C10VxgnxYQg5Vs_Kcp2XcH0j4hSxa7lkWxAWyW-h2yu9g$
>>>>
>>>> Please let us know if you have any questions.
>>>>
>>>> Thank you for your cooperation,
>>>>
>>>> RFC Editor
>>>>
>>>> --------------------------------------
>>>> RFC9857 (draft-ietf-idr-bgp-ls-sr-policy-17)
>>>>
>>>> Title : Advertisement of Segment Routing Policies using BGP
>>>> Link-State
>>>> Author(s) : S. Previdi, K. Talaulikar, Ed., J. Dong, H. Gredler, J.
>>>> Tantsura
>>>> WG Chair(s) : Susan Hares, Keyur Patel, Jeffrey Haas
>>>>
>>>> Area Director(s) : Jim Guichard, Ketan Talaulikar, Gunter Van de Velde
>>>>
>>>>
>>>
>>>
>
--
auth48archive mailing list -- [email protected]
To unsubscribe send an email to [email protected]
