Authors, Just a note to state that some changes to the document have been added per discussion of RFC-to-be 9831.
These updates include the following: - The reference entry pointing to RFC-to-be 9831 (title, date) - Table 5 in Section 6.5 (to reword the names to appear as Type A Segment sub-TLV and Type B Segment sub-TLV) - Updates to consistently use the phrasing "SRv6 Endpoint Behavior and SID Structure” throughout. If we can get one author to review and approve these changes, we would appreciate it. NOTE: We will communicate the changes to Table 5 to IANA along with the similar changes requested for RFC-to-be 9831 once that document completes AUTH48. Note that this document has moved from AUTH48-DONE back to AUTH48 until we hear confirmation from authors and IANA completes their corresponding actions. The changes have been folded into the existing files/diffs (please refresh!): The files have been posted here: https://www.rfc-editor.org/authors/rfc9830.txt https://www.rfc-editor.org/authors/rfc9830.pdf https://www.rfc-editor.org/authors/rfc9830.html https://www.rfc-editor.org/authors/rfc9830.xml The relevant diff files have been posted here: https://www.rfc-editor.org/authors/rfc9830-diff.html https://www.rfc-editor.org/authors/rfc9830-rfcdiff.html (side by side) https://www.rfc-editor.org/authors/rfc9830-auth48diff.html https://www.rfc-editor.org/authors/rfc9830-auth48rfcdiff.html (side by side) These diff files show only the changes made during the last edit round: https://www.rfc-editor.org/authors/rfc9830-lastdiff.html https://www.rfc-editor.org/authors/rfc9830-lastrfcdiff.html (side by side) The AUTH48 status page for this document can be found here: https://www.rfc-editor.org/auth48/rfc9830 The relevant cluster information can be found here: https://www.rfc-editor.org/cluster_info.php?cid=C534 Thank you. RFC Editor/mf > On Aug 4, 2025, at 6:02 PM, Karen Moore <kmo...@staff.rfc-editor.org> wrote: > > Authors, > > IANA has completed the updates to their registries. > > This now completes the AUTH48 process for this document. We will move this > document forward in the publication process along with the companion > documents when they have completed AUTH48 (see the status at > <https://www.rfc-editor.org/cluster_info.php?cid=C534>) . > > Thank you for your time! > > RFC Editor/mf/kc > >> On Aug 4, 2025, at 2:04 PM, Karen Moore <kmo...@staff.rfc-editor.org> wrote: >> >> Hi Paul, >> >> Thank you for your response; we have noted your approval on the AUTH48 >> status page (https://www.rfc-editor.org/auth48/rfc9830). >> >> We will now ask IANA to update their registries to match the edited >> document. We will inform you when the updates are complete. >> >> Best regards, >> RFC Editor/kc >> >>> On Aug 4, 2025, at 11:32 AM, Paul Mattes <pamat...@microsoft.com> wrote: >>> >>> >>> >>> The document looks good to me. >>> >>> pdm >>> >>> >>> >>> From: Karen Moore <kmo...@staff.rfc-editor.org> >>> Sent: Monday, August 4, 2025 12:40 PM >>> To: D Jain <dhanendra.i...@gmail.com>; Ketan Talaulikar >>> <ketant.i...@gmail.com>; Paul Mattes <pamat...@microsoft.com>; Clarence >>> Filsfils (cfilsfil) <cfils...@cisco.com>; >>> stef...@previdi.net<stef...@previdi.net> >>> Cc: Megan Ferguson <mfergu...@staff.rfc-editor.org>; RFC Editor >>> <rfc-edi...@rfc-editor.org>; idr-...@ietf.org<idr-...@ietf.org>; idr-chairs >>> <idr-cha...@ietf.org>; Sue Hares <sha...@ndzh.com>; Roman Danyliw >>> <r...@cert.org>; Shawn Zandi via auth48archive >>> <auth48archive@rfc-editor.org> >>> Subject: [EXTERNAL] Re: AUTH48: RFC-to-be 9830 >>> <draft-ietf-idr-sr-policy-safi-13> for your review >>> >>> [You don't often get email from kmo...@staff.rfc-editor.org. Learn why this >>> is important athttps://aka.ms/LearnAboutSenderIdentification ] >>> >>> Dhanendra and Stefano, >>> >>> Thank you for your replies. We have noted your approvals on the AUTH48 >>> status page >>> (https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauth48%2Frfc9830&data=05%7C02%7Cpamattes%40microsoft.com%7C74d814640ab44129b00508ddd37e0233%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638899260662146350%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=Qrur9iWIKrFQN5LA1ltExrc73RfvUql2m2rcH5gUpPI%3D&reserved=0). >>> >>> We now await approval from Paul. Once approval is received, we will ask >>> IANA to update their registries to match the edited document. >>> >>> Best regards, >>> RFC Editor/kc >>> >>> >>>> On Aug 4, 2025, at 1:48 AM, Stefano Previdi <stef...@previdi.net> wrote: >>>> >>>> Hi, >>>> >>>> the document looks good to me. >>>> >>>> thanks. >>>> s. >>> >>> >>>> On Aug 2, 2025, at 5:51 PM, D Jain <dhanendra.i...@gmail.com> wrote: >>>> >>>> Hi Karen, >>>> >>>> >>>> >>>> The document looks good to me. I approve the publication. >>>> >>>> >>>> >>>> Thanks, >>>> >>>> Dhanendra. >>>> >>> >>>> >>>> On Fri, Aug 1, 2025 at 12:42 PM Karen Moore <kmo...@staff.rfc-editor.org> >>>> wrote: >>>> Hello Clarence and Ketan, >>>> >>>> Thanks for your replies. We have noted Clarence’s approval on the AUTH48 >>>> status page >>>> (https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauth48%2Frfc9830&data=05%7C02%7Cpamattes%40microsoft.com%7C74d814640ab44129b00508ddd37e0233%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638899260662174104%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=XP4Bg6pt0aF7MR5NtWK%2FmOvJLwOSVbdd%2BPvmY0uu99Q%3D&reserved=0). >>>> >>>> We now await approvals from Dhanendra, Paul, and Stefano. Once approvals >>>> are received, we will ask IANA to update their registries to match the >>>> edited document. >>>> >>>> Best regards, >>>> RFC Editor/kc >>>> >>>>> On Aug 1, 2025, at 1:28 AM, Clarence Filsfils (cfilsfil) >>>>> <cfils...@cisco.com> wrote: >>>>> >>>>> Hello, >>>>> >>>>> The document looks good to me and I approve its publication. >>>>> >>>>> Cheers, >>>>> Clarence >>>>> >>>>> From: Ketan Talaulikar <ketant.i...@gmail.com> >>>>> Sent: Friday, August 1, 2025 7:40 AM >>>>> To: Karen Moore <kmo...@staff.rfc-editor.org> >>>>> Cc: Clarence Filsfils (cfilsfil) <cfils...@cisco.com>; >>>>> dhanendra.i...@gmail.com; stef...@previdi.net; pamat...@microsoft.com; >>>>> Megan Ferguson <mfergu...@staff.rfc-editor.org>; RFC Editor >>>>> <rfc-edi...@rfc-editor.org>; idr-...@ietf.org; idr-chairs >>>>> <idr-cha...@ietf.org>; Sue Hares <sha...@ndzh.com>; Roman Danyliw >>>>> <r...@cert.org>; Shawn Zandi via auth48archive >>>>> <auth48archive@rfc-editor.org> >>>>> Subject: Re: AUTH48: RFC-to-be 9830 <draft-ietf-idr-sr-policy-safi-13> >>>>> for your review >>>>> >>>>> Thanks Karen everything looks good to me. >>>>> >>>>> Thanks, >>>>> Ketan >>>>> >>>>> >>>>> On Fri, Aug 1, 2025 at 2:31 AM Karen Moore <kmo...@staff.rfc-editor.org> >>>>> wrote: >>>>> Hi Ketan, >>>>> >>>>> Thank you for the clarifications and for working closely with us on the >>>>> terminology; we have noted your approval of the document on the AUTH48 >>>>> status page. Note that we updated our files to reflect “long SR Policy >>>>> name” and have included “SR” for “Policy Name”, “Policy Candidate Path”, >>>>> and the TLV names with policy in them (excluding "Explicit NULL Label >>>>> Policy” as previously mentioned). >>>>> >>>>> We also changed “Policy Color” to “Color”, and we updated the SR Policy >>>>> SAFI NLRI as follows; if that is not correct, please let us know. >>>>> >>>>> Original: >>>>> SR Policy SAFI NLRI: <Distinguisher, Policy-Color, Endpoint> >>>>> >>>>> Current: >>>>> SR Policy SAFI NLRI: <Distinguisher, Color, Endpoint> >>>>> >>>>> Please review the updated files and let us know if any other updates are >>>>> needed. >>>>> >>>>> --FILES (please refresh)-- >>>>> >>>>> The files have been posted here: >>>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9830.txt&data=05%7C02%7Cpamattes%40microsoft.com%7C74d814640ab44129b00508ddd37e0233%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638899260662188115%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=vC0iW8s0TadcaaKGuTNXsIJZcVbdDwMqzCOGCKcHvRU%3D&reserved=0 >>>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9830.pdf&data=05%7C02%7Cpamattes%40microsoft.com%7C74d814640ab44129b00508ddd37e0233%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638899260662199742%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=X2gd9sVoCh4wcxJHPX6UCrD87Bl1P0Uy8GLAHaWaSGY%3D&reserved=0 >>>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9830.html&data=05%7C02%7Cpamattes%40microsoft.com%7C74d814640ab44129b00508ddd37e0233%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638899260662211038%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=AR0Tms%2Bs0BYPhrK%2FqxVake4f3RVthgsHyTK6vh9ghlg%3D&reserved=0 >>>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9830.xml&data=05%7C02%7Cpamattes%40microsoft.com%7C74d814640ab44129b00508ddd37e0233%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638899260662222042%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=t1zsDJCL3JonCLnznCd%2B34SxH%2BGUiahkNMNlaKKulH8%3D&reserved=0 >>>>> >>>>> The relevant diff files have been posted here: >>>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9830-diff.html&data=05%7C02%7Cpamattes%40microsoft.com%7C74d814640ab44129b00508ddd37e0233%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638899260662231233%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=x3REJ7pLrF3uA0tJnSqG5NPhWMkMEXF4a4mMz6TgGkU%3D&reserved=0 >>>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9830-rfcdiff.html&data=05%7C02%7Cpamattes%40microsoft.com%7C74d814640ab44129b00508ddd37e0233%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638899260662241608%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=GIZZnYA9DY2uLNTRljVZKuYBiUaiQSMRVqaWXmWSGgs%3D&reserved=0 >>>>> (side by side) >>>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9830-auth48diff.html&data=05%7C02%7Cpamattes%40microsoft.com%7C74d814640ab44129b00508ddd37e0233%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638899260662254077%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=OVu990XgDw9xVLPZ9lK0Caz%2FcHTsQK7L4odpZLpvb8k%3D&reserved=0 >>>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9830-auth48rfcdiff.html&data=05%7C02%7Cpamattes%40microsoft.com%7C74d814640ab44129b00508ddd37e0233%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638899260662262700%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=kx3AMJhoqq17NynXdM2pPF5WzfnSQmn4%2F1HmN6Ypjp0%3D&reserved=0 >>>>> (side by side) >>>>> >>>>> These diff files show only the changes made during the last edit round: >>>>> >>>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9830-lastdiff.html&data=05%7C02%7Cpamattes%40microsoft.com%7C74d814640ab44129b00508ddd37e0233%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638899260662270602%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=nbpEqt7fkdEK5PgxDOExl2lHtyreg5V0UmXXGAmUTZI%3D&reserved=0 >>>>> >>>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9830-lastrfcdiff.html&data=05%7C02%7Cpamattes%40microsoft.com%7C74d814640ab44129b00508ddd37e0233%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638899260662278846%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=%2BRrFznB74Errfc1SxbzqPis%2BSyBL3pU2hSqCQPdUZZY%3D&reserved=0 >>>>> (side by side) >>>>> >>>>> We will await approvals from each party listed at this document’s AUTH48 >>>>> status page >>>>> (seehttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauth48%2Frfc9830&data=05%7C02%7Cpamattes%40microsoft.com%7C74d814640ab44129b00508ddd37e0233%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638899260662286712%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=LEbzWF0rdNbmQBAfGYmpy%2FPA%2B8AsBic%2FjygeVVYSQ74%3D&reserved=0) >>>>> and the completion of AUTH48 of this document’s companion documents (see >>>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fcluster_info.php%3Fcid%3DC534&data=05%7C02%7Cpamattes%40microsoft.com%7C74d814640ab44129b00508ddd37e0233%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638899260662294919%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=NxzS%2FrWPuPoFutIbPXVpt3pPFeI1wazXtVOkl2j4y4Q%3D&reserved=0) >>>>> prior to moving forward in the publication process. >>>>> >>>>> Best regards, >>>>> RFC Editor/kc >>>>> >>>>> >>>>>> On Jul 31, 2025, at 5:36 AM, Ketan Talaulikar <ketant.i...@gmail.com> >>>>>> wrote: >>>>>> >>>>>> Hi Karen, >>>>>> >>>>>> That one instance left about "long policy name" is also about the "SR >>>>>> Policy". >>>>>> >>>>>> Moreover, the names like Policy Name and Policy Candidate Path name >>>>>> should be changed to "SR Policy ..." for consistency. This also applies >>>>>> to the TLV/sub-TLV names that have "Policy" in it. The only exception is >>>>>> perhaps Figure 1 and its field explanations where we can change "Policy >>>>>> Color" to "Color" so it aligns with the "Endpoint" that is used without >>>>>> that prefix. >>>>>> >>>>>> I have reviewed all other changes in the diff and please consider this >>>>>> email as my approval for publication. >>>>>> >>>>>> Thanks, >>>>>> Ketan >>>>>> >>>>>> >>>>>> On Thu, Jul 31, 2025 at 12:22 AM Karen Moore >>>>>> <kmo...@staff.rfc-editor.org> wrote: >>>>>> Hi Ketan, >>>>>> >>>>>> We have made the changes discussed below. Please review the updated >>>>>> files and let us know if any further updates are needed or if the >>>>>> current text is agreeable. >>>>>> >>>>>> Note that we left one instance of "policy" here: "The Policy Name >>>>>> sub-TLV may exceed 255 bytes in length due to a long policy name". If >>>>>> that is not correct and it should be "SR Policy", please let us know. >>>>>> >>>>>> --FILES (please refresh)-- >>>>>> >>>>>> The files have been posted here: >>>>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9830.txt&data=05%7C02%7Cpamattes%40microsoft.com%7C74d814640ab44129b00508ddd37e0233%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638899260662305578%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=YeoYKzs%2B08o%2Barz7KMMvWqdX5yBKVaUhInRkXZibClc%3D&reserved=0 >>>>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9830.pdf&data=05%7C02%7Cpamattes%40microsoft.com%7C74d814640ab44129b00508ddd37e0233%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638899260662314466%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=v0tuEpS6dl6TTMZjkT8ENlDDMz1F0lpei2UYxeBq7qM%3D&reserved=0 >>>>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9830.html&data=05%7C02%7Cpamattes%40microsoft.com%7C74d814640ab44129b00508ddd37e0233%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638899260662325093%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=gPFqquHaH9az3qRIUFV0aqsZgIqBMsA91GlvwEMTO6M%3D&reserved=0 >>>>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9830.xml&data=05%7C02%7Cpamattes%40microsoft.com%7C74d814640ab44129b00508ddd37e0233%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638899260662334073%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=XP0%2FhFUTOfeL3XpDLgSXHdHjXryD4KnaBjUVcCud9sA%3D&reserved=0 >>>>>> >>>>>> The relevant diff files have been posted here: >>>>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9830-diff.html&data=05%7C02%7Cpamattes%40microsoft.com%7C74d814640ab44129b00508ddd37e0233%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638899260662342489%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=arOvSFuAKjSEWDirZzr08eH5pKg10ghGSCuNNl%2FT9mI%3D&reserved=0 >>>>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9830-rfcdiff.html&data=05%7C02%7Cpamattes%40microsoft.com%7C74d814640ab44129b00508ddd37e0233%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638899260662351753%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=KfstHSUaiO5sC0WfG1TW0MjwjrQsQYNz%2Bli8AOqCHrs%3D&reserved=0 >>>>>> (side by side) >>>>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9830-auth48diff.html&data=05%7C02%7Cpamattes%40microsoft.com%7C74d814640ab44129b00508ddd37e0233%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638899260662363581%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=QTg7dEY92VITqmjrqEMiiq227APoBUU8RlGno6%2Fvnzg%3D&reserved=0 >>>>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9830-auth48rfcdiff.html&data=05%7C02%7Cpamattes%40microsoft.com%7C74d814640ab44129b00508ddd37e0233%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638899260662374090%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=zgsaQdRjjvVvZoIVH7lm%2BZERCirse08brTWeURVUFw0%3D&reserved=0 >>>>>> (side by side) >>>>>> >>>>>> These diff files show only the changes made during the last edit round: >>>>>> >>>>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9830-lastdiff.html&data=05%7C02%7Cpamattes%40microsoft.com%7C74d814640ab44129b00508ddd37e0233%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638899260662384228%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=bmU4ICXXe%2Biso2c%2BGdVGQtcnuFh%2FtGWAYIlCH0XJvuo%3D&reserved=0 >>>>>> >>>>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9830-lastrfcdiff.html&data=05%7C02%7Cpamattes%40microsoft.com%7C74d814640ab44129b00508ddd37e0233%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638899260662393573%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=OBH87PB9Al72fsFW0N7eJHObzxHV%2BlDyqpij8WnzLt0%3D&reserved=0 >>>>>> (side by side) >>>>>> >>>>>> We will await approvals from each party listed at this document’s AUTH48 >>>>>> status page >>>>>> (seehttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauth48%2Frfc9830&data=05%7C02%7Cpamattes%40microsoft.com%7C74d814640ab44129b00508ddd37e0233%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638899260662404848%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=xMRCwvhwzEyvO1vrM%2FItEpA5xGuebP3vF%2B9p5AjOKhI%3D&reserved=0) >>>>>> and the completion of AUTH48 of this document’s companion documents >>>>>> (see >>>>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fcluster_info.php%3Fcid%3DC534&data=05%7C02%7Cpamattes%40microsoft.com%7C74d814640ab44129b00508ddd37e0233%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638899260662414916%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=iWDamdBhjiA5BZdzmrkEZsPQsP%2BeUFjxyGkNqsPcqsM%3D&reserved=0) >>>>>> prior to moving forward in the publication process. >>>>>> >>>>>> Best regards, >>>>>> RFC Editor/kc >>>>>> >>>>>> On Jul 27, 2025, at 6:59 AM, Ketan Talaulikar <ketant.i...@gmail.com> >>>>>> wrote: >>>>>> >>>>>> Hi Megan, >>>>>> >>>>>> Thanks for your response. Please check inline below. >>>>>> >>>>>> >>>>>> On Tue, Jul 22, 2025 at 7:32 PM Megan Ferguson >>>>>> <mfergu...@staff.rfc-editor.org> wrote: >>>>>> Hi Ketan, >>>>>> >>>>>> Thank you for your reply and guidance! >>>>>> >>>>>> A few followups below with comments in [rfced]: >>>>>> >>>>>> >>>>>>>> 5) <!--[rfced] Please review the following for how "4 octets" connects >>>>>>>> to >>>>>>>> the rest of the sentence (perhaps text is missing as we generally >>>>>>>> see "octets of foo" in previous descriptions)? >>>>>>>> >>>>>>>> Original: >>>>>>>> >>>>>>>> Weight: 4 octets an unsigned integer value indicating the weight >>>>>>>> associated with a segment list... >>>>>>>> >>>>>>>> >>>>>>>> --> >>>>>>>> >>>>>>>> KT> It should be "4 octets carrying and unsigned ..." >>>>>> >>>>>> [rfced] We made this “4 octets carrying an unsigned…” (“an" instead of >>>>>> “and"). If this is in error, please let us know. >>>>>> >>>>>> KT> Agree >>>>>> >>>>>> >>>>>> >>>>>>> 16) <!--[rfced] We had the following questions related to terminology >>>>>>> use throughout the document. >>>>>>> >>>>>>> a) Should the following terms be made consistent with regard to >>>>>>> capitalization, hyphenation, etc.? If so, please let us know how to >>>>>>> update. >>>>>>> >>>>>>> SR Policy vs. SR policy vs. policy >>>>>> [rfced] We have not made any updates to uses of simply “policy”. If >>>>>> there are places where it should be changed to “SR Policy”, please let >>>>>> us know. >>>>>> >>>>>> KT> Thanks for bringing this to my attention. Except for the following >>>>>> instances, all other uses of "policy" should be replaced by "SR Policy" >>>>>> for clarity and consistency. There are quite a lot of places where we >>>>>> have missed this. >>>>>> >>>>>> "local policy" or "one possible policy" or "registration policy" ... >>>>>> where the use is as in the English word policy and not the technical >>>>>> term SR Policy >>>>>> "explicit null label policy" >>>>>> >>>>>> >>>>>>> >>>>>>> KT> SR Policy per RFC9256 >>>>>>> >>>>>>> BGP UPDATE message vs. BGP update message vs. BGP Update >>>>>>> >>>>>>> KT> BGP UPDATE message per RFC4271 when referring to the message >>>>>> >>>>>> [rfced] Please carefully review our updates to these and let us know if >>>>>> further changes are necessary (as we tried to take clues from the >>>>>> context in some places). >>>>>> >>>>>> KT> Looks good to me >>>>>> >>>>>>> >>>>>>> [snip] >>>>>>> >>>>>>> Color vs. color >>>>>>> >>>>>>> KT> Color >>>>>>> >>>>>>> Endpoint vs. endpoint >>>>>>> >>>>>>> KT> endpoint >>>>>> >>>>>> [rfced] As color and endpoint are often in a tuple and used similarly, >>>>>> we wondered if they should be treated the same for capitalization — so >>>>>> we ended up capping Endpoint as this also seemed to match the use in RFC >>>>>> 9256. Please review the text as it stands and let us know if you would >>>>>> like further updates. >>>>>> >>>>>> KT> The capitalization is correct where Color and Endpoint are used >>>>>> together (or SRv6 Endpoint Behavior) - that is a technical term. >>>>>> However, there are only a few other places where the word is used as an >>>>>> English word and should not be capitalized (e.g. "link endpoints", >>>>>> "endpoint/node addresses"). >>>>>> >>>>>>> >>>>>>> [snip] >>>>>>> >>>>>>> "Drop Upon Invalid" behavior vs. "drop upon invalid" config >>>>>>> >>>>>>> KT> Drop-Upon-Invalid per RFC9256 >>>>>> >>>>>> [rfced] We assume no change from “config” to “behavior” is desired. >>>>>> Please correct us if that is in error. Also, please see the related >>>>>> updates to the IANA Considerations sections and let us know any >>>>>> objections to the changes there (as the name of the I-Flag). >>>>>> >>>>>> KT> Looks good except that there is still one use of "config" in that >>>>>> context that should be changed to "behavior" for consistency. >>>>>> >>>>>> >>>>>> >>>>>> [rfced] With regard to ENLP (mentioned in both questions 15 and 16 in >>>>>> our previous mail), we see variance between the following when we look >>>>>> for the sub-TLV name: >>>>>> >>>>>> ENLP sub-TLV >>>>>> Explicit NULL Label Policy (ENLP) sub-TLV >>>>>> >>>>>> Please let us know if/how these may be made consistent. >>>>>> >>>>>> KT> The expanded form should be there on first use (also on section >>>>>> title and IANA) and rest of the text we can use the acronym as per usual >>>>>> practice. >>>>>> >>>>>> Thanks again, >>>>>> Ketan >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> All other requested changes have been incorporated and the files have >>>>>> been reposted (please be sure to refresh). >>>>>> >>>>>> The files have been posted here: >>>>>> >>>>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9830.txt&data=05%7C02%7Cpamattes%40microsoft.com%7C74d814640ab44129b00508ddd37e0233%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638899260662423491%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=X62D9Rwu5vgUiGmdga%2F7MfmLr9V%2Fhd%2BB03MxIOtRT7Y%3D&reserved=0 >>>>>> >>>>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9830.pdf&data=05%7C02%7Cpamattes%40microsoft.com%7C74d814640ab44129b00508ddd37e0233%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638899260662431277%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=cx%2Flww7OkK344s8eLSnWUuQvf3qYBKO6CWs62THmulA%3D&reserved=0 >>>>>> >>>>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9830.html&data=05%7C02%7Cpamattes%40microsoft.com%7C74d814640ab44129b00508ddd37e0233%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638899260662439166%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=e0FiyC0gv3oiJO%2B5no5ulQiwWoobeIOBPlJPZ4oMHXM%3D&reserved=0 >>>>>> >>>>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9830.xml&data=05%7C02%7Cpamattes%40microsoft.com%7C74d814640ab44129b00508ddd37e0233%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638899260662447612%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=jovCX79D4FoVUITgluGkJpNHlOXIizTxFpDgztWgKjg%3D&reserved=0 >>>>>> >>>>>> The relevant diff files have been posted here: >>>>>> >>>>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9830-diff.html&data=05%7C02%7Cpamattes%40microsoft.com%7C74d814640ab44129b00508ddd37e0233%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638899260662455860%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=zPr5a6lDfWGn6gYLIf1Xqag0RHCATgfEKVQoMgbB%2F4k%3D&reserved=0 >>>>>> >>>>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9830-rfcdiff.html&data=05%7C02%7Cpamattes%40microsoft.com%7C74d814640ab44129b00508ddd37e0233%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638899260662464946%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=6gQU%2FTRCOvgFUYL7dwI2y9mCBCUjpqT7Gjfma0Fxh%2BA%3D&reserved=0 >>>>>> (side by side) >>>>>> >>>>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9830-auth48diff.html&data=05%7C02%7Cpamattes%40microsoft.com%7C74d814640ab44129b00508ddd37e0233%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638899260662472728%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=5B7KwyDHhrSdTriEhgbZt%2Fj91ZIrQODz9vnf3MHqC4M%3D&reserved=0 >>>>>> >>>>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9830-auth48rfcdiff.html&data=05%7C02%7Cpamattes%40microsoft.com%7C74d814640ab44129b00508ddd37e0233%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638899260662483339%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=t4TcG13pU3dWJQpYzPie8bR9mCxXxdfqDiuMxJCV6X8%3D&reserved=0 >>>>>> (side by side) >>>>>> >>>>>> Please review carefully as we do not make changes once the document is >>>>>> published as an RFC. >>>>>> >>>>>> We will await the resolution of the issues above, approvals from each >>>>>> party listed at this document’s AUTH48 status page (see >>>>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauth48%2Frfc9830&data=05%7C02%7Cpamattes%40microsoft.com%7C74d814640ab44129b00508ddd37e0233%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638899260662494018%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=KbtDpg6fBesyK8qF2ceOlmcVquPoT6Jj48zSxWXsxX8%3D&reserved=0), >>>>>> and the completion of AUTH48 of this document’s companion documents >>>>>> (seehttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fcluster_info.php%3Fcid%3DC534&data=05%7C02%7Cpamattes%40microsoft.com%7C74d814640ab44129b00508ddd37e0233%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638899260662504043%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=cqnM5MrhapjSPbLfPy%2FhACqZKOwLtUxUNFCkbtGyPX4%3D&reserved=0) >>>>>> prior to moving forward in the publication process. >>>>>> >>>>>> Thank you. >>>>>> >>>>>> RFC Editor/mf >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> On Jul 18, 2025, at 11:10 AM, Ketan Talaulikar <ketant.i...@gmail.com> >>>>>>> wrote: >>>>>>> >>>>>>> Hi Megan, >>>>>>> >>>>>>> Thanks for your help on this document. Please check inline below for >>>>>>> responses. >>>>>>> >>>>>>> >>>>>>> On Thu, Jul 17, 2025 at 4:33 AM <rfc-edi...@rfc-editor.org> wrote: >>>>>>> Authors, >>>>>>> >>>>>>> While reviewing this document during AUTH48, please resolve (as >>>>>>> necessary) the following questions, which are also in the XML file. >>>>>>> >>>>>>> 1) <!-- [rfced] Please insert any keywords (beyond those that appear in >>>>>>> the title) for use on >>>>>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fsearch&data=05%7C02%7Cpamattes%40microsoft.com%7C74d814640ab44129b00508ddd37e0233%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638899260662512225%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=kWSjUF%2BLSixNEKZrHecYO44iKshHy2oELN3ShhAuL%2B0%3D&reserved=0. >>>>>>> --> >>>>>>> >>>>>>> >>>>>>> 2) <!--[rfced] Should "itself" be "themselves"? If neither of the >>>>>>> following capture your intended meaning, please rephrase. >>>>>>> >>>>>>> Original: >>>>>>> Alternatively, a BGP egress router may advertise SR Policies that >>>>>>> represent paths terminating on itself. >>>>>>> >>>>>>> Perhaps A: >>>>>>> Alternatively, a BGP egress router may advertise SR Policies that >>>>>>> represent paths terminating on themselves. >>>>>>> >>>>>>> Perhaps B: >>>>>>> Alternatively, a BGP egress router may advertise SR Policies that >>>>>>> represent paths that terminate on it. >>>>>>> >>>>>>> --> >>>>>>> >>>>>>> KT> Option B is better. >>>>>>> >>>>>>> >>>>>>> >>>>>>> 3) <!--[rfced] The following sentence is long and difficult to parse. >>>>>>> In >>>>>>> particular, what is being made unique? How may we rephrase? >>>>>>> >>>>>>> Original: >>>>>>> The distinguisher has no semantic value and is solely used by the SR >>>>>>> Policy originator to make unique (from an NLRI perspective) both for >>>>>>> multiple candidate paths of the same SR Policy as well as candidate >>>>>>> paths of different SR Policies (i.e. with different segment lists) >>>>>>> with the same Color and Endpoint but meant for different headends. >>>>>>> >>>>>>> >>>>>>> KT> How about the following? >>>>>>> >>>>>>> The distinguisher has no semantic value. It is used by the SR Policy >>>>>>> originator to form unique NLRIs in the following situations: >>>>>>> - to differentiate multiple candidate paths of the same SR Policy >>>>>>> - to differentiate candidate paths meant for different headends but >>>>>>> having the same Color and Endpoint >>>>>>> >>>>>>> >>>>>>> >>>>>>> --> >>>>>>> >>>>>>> >>>>>>> 4) <!-- [rfced] We note that [RFC4456] uses the term "ORIGINATOR_ID" >>>>>>> rather than "Originator ID". Please review and let us know if any >>>>>>> updates are necessary. --> >>>>>>> >>>>>>> KT> Yes, please update to match RFC4456 >>>>>>> >>>>>>> >>>>>>> >>>>>>> 5) <!--[rfced] Please review the following for how "4 octets" connects >>>>>>> to >>>>>>> the rest of the sentence (perhaps text is missing as we generally >>>>>>> see "octets of foo" in previous descriptions)? >>>>>>> >>>>>>> Original: >>>>>>> >>>>>>> Weight: 4 octets an unsigned integer value indicating the weight >>>>>>> associated with a segment list... >>>>>>> >>>>>>> >>>>>>> --> >>>>>>> >>>>>>> KT> It should be "4 octets carrying and unsigned ..." >>>>>>> >>>>>>> >>>>>>> >>>>>>> 6) <!--[rfced] Please clarify "it" in the following text: >>>>>>> >>>>>>> Original: >>>>>>> >>>>>>> If one or more route targets are present and none matches the local >>>>>>> BGP Identifier, then, while the SR Policy NLRI is valid, it is not >>>>>>> usable on the receiver node. >>>>>>> >>>>>>> Perhaps: >>>>>>> >>>>>>> If one or more route targets are present, and none matches the >>>>>>> local BGP Identifier, then, while the SR Policy NLRI is valid, the >>>>>>> route targets are not usable on the receiver node. >>>>>>> --> >>>>>>> >>>>>>> KT> It should be (but please feel free to improve): >>>>>>> >>>>>>> If one or more route targets are present, and none matches the >>>>>>> local BGP Identifier, then, while the SR Policy NLRI is valid, the SR >>>>>>> Policy NLRI is not usable on the receiver node. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> 7) <!--[rfced] We note that the IANA Considerations section (Section 6) >>>>>>> starts with a summary of all of the actions that follow in the >>>>>>> subsections. We had a few questions/comments related to this >>>>>>> section: >>>>>>> >>>>>>> a) Note that we have consolidated mentions of the registry group names >>>>>>> in the introductory text for each type of action in order to reduce >>>>>>> redundancy. Please review these changes and let us know any >>>>>>> objections. >>>>>>> >>>>>>> KT> Looks good to me >>>>>>> >>>>>>> >>>>>>> b) To further reduce redundancy, might it be agreeable to delete the >>>>>>> registry group names from the subsections that follow? They were used >>>>>>> inconsistently in the original, and the reader would be able to find >>>>>>> that information in Section 6 itself if desired. >>>>>>> >>>>>>> KT> I would check on this with the IANA team on their preference >>>>>>> >>>>>>> >>>>>>> c) Would you like to add section pointers to the corresponding >>>>>>> subsections where the actions are further described? >>>>>>> >>>>>>> KT> I don't think this is necessary as they are easy to locate just by >>>>>>> looking at the index. However, there is no concern if they were >>>>>>> included as well. I would go with your recommendation. >>>>>>> >>>>>>> >>>>>>> d) Please note that any changes to text that appears in any IANA >>>>>>> registries mentioned in this document will be communicated to IANA by >>>>>>> the RPC prior to publication but after the completion of AUTH48. >>>>>>> --> >>>>>>> >>>>>>> >>>>>>> 8) <!--[rfced] We had a few questions regarding Section 6.1 and the BGP >>>>>>> SAFI Code Point: >>>>>>> >>>>>>> >>>>>>> a) We received the following note from IANA. We do not see mention of >>>>>>> this update in the IANA Considerations section of this document. >>>>>>> Should anything be added? >>>>>>> >>>>>>> IANA's Note: >>>>>>> NOTE: We've also updated the associated iana-routing-types YANG module >>>>>>> to reflect the new description and enum variable. >>>>>>> >>>>>>> Please see >>>>>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iana.org%2Fassignments%2Fiana-routing-types&data=05%7C02%7Cpamattes%40microsoft.com%7C74d814640ab44129b00508ddd37e0233%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638899260662520858%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=QSRrp8LSVXZQRT4QEFkTPFpNYSh5VqJiVng63xXowEA%3D&reserved=0 >>>>>>> >>>>>>> KT> This looks like an action that IANA does on its own when something >>>>>>> new gets added to the IANA SAFI registry group. Please check the note >>>>>>> inhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iana.org%2Fassignments%2Fsafi-namespace%2Fsafi-namespace.xhtml&data=05%7C02%7Cpamattes%40microsoft.com%7C74d814640ab44129b00508ddd37e0233%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638899260662529453%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=Gd1%2B%2FMFmU7o%2FJyrPFWv1t0ym6ugx%2B7nngjqDDqxDt1A%3D&reserved=0 >>>>>>> and as such this document does not need to say anything in this >>>>>>> regard. I am happy to be corrected by the IANA team. >>>>>>> >>>>>>> >>>>>>> >>>>>>> b) We don't see any mention of "BGP" in the corresponding IANA >>>>>>> registry. Should the title of Table 1 be updated? >>>>>>> >>>>>>> Currently in the document: >>>>>>> Table 1: BGP SAFI Code Point >>>>>>> >>>>>>> At >>>>>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iana.org%2Fassignments%2Fsafi-namespace%2Fsafi-namespace.xhtml&data=05%7C02%7Cpamattes%40microsoft.com%7C74d814640ab44129b00508ddd37e0233%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638899260662538149%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=q01ecHD3MY2aE%2FHhIVILypxdwGE2B%2BVSsYdTmRPAFrA%3D&reserved=0: >>>>>>> SR Policy SAFI >>>>>>> >>>>>>> KT> I think what we have currently looks good to me. Please let me know >>>>>>> if the IANA team feels otherwise. >>>>>>> >>>>>>> >>>>>>> c) The title of this section is "Subsequent Address Family Identifiers >>>>>>> (SAFI) Parameters". This is the title of registry group. Subsequent >>>>>>> subsections in the document are titled using the subregistry. Should >>>>>>> the title of Section 6.1 be updated to "SAFI Values"? >>>>>>> >>>>>>> KT> This is related to (7)(b) and I would let the IANA team take the >>>>>>> call if a change is needed. >>>>>>> >>>>>>> >>>>>>> >>>>>>> --> >>>>>>> >>>>>>> >>>>>>> 9) <!--[rfced] We had the following questions/comments regarding Section >>>>>>> 6.3: >>>>>>> >>>>>>> a) We note that the corresponding IANA registry >>>>>>> (https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iana.org%2Fassignments%2Fbgp-tunnel-encapsulation%2Fbgp-tunnel-encapsulation.xhtml%23tunnel-sub-tlvs&data=05%7C02%7Cpamattes%40microsoft.com%7C74d814640ab44129b00508ddd37e0233%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638899260662546269%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=S%2F9TM7rJ39PsYjd2KRBX%2Bt0g1OxrlV5gsuHUuG2cnJs%3D&reserved=0) >>>>>>> also has a "Change Controller" column in which some of the code points >>>>>>> listed by this document contain information (i.e., IETF). Should any >>>>>>> mention of this be made in Table 3? >>>>>>> >>>>>>> KT> Yes please - IETF is the change controller for all of them. >>>>>>> >>>>>>> >>>>>>> b) Please review our update to the title of Table 3 and let us know >>>>>>> any objections. >>>>>>> >>>>>>> Original: >>>>>>> >>>>>>> Table 3: BGP Tunnel Encapsulation Attribute Code Points >>>>>>> >>>>>>> Current: >>>>>>> >>>>>>> Table 3: BGP Tunnel Encapsulation Attribute Sub-TLV Code Points >>>>>>> >>>>>>> KT> Ack >>>>>>> >>>>>>> --> >>>>>>> >>>>>>> >>>>>>> 10) <!--[rfced] We had the following questions/comments related to Table >>>>>>> 5: >>>>>>> >>>>>>> a) Please review our update to the title to include "Sub-TLV". >>>>>>> >>>>>>> Original: >>>>>>> Table 5: SR Policy Segment List Code Points >>>>>>> >>>>>>> Current: >>>>>>> Table 5: SR Policy Segment List Sub-TLV Code Points >>>>>>> >>>>>>> KT> Ack >>>>>>> >>>>>>> >>>>>>> b) We note that Table 5 includes "Segment Type A sub-TLV". Elsewhere >>>>>>> in the document, we see "Type A Segment Sub-TLV" (note the word order >>>>>>> change). Further, we see >>>>>>> Type-1 (using a hyphen while lettered types do not). Please review >>>>>>> all of these differences and let us know if/how these should be made >>>>>>> consistent. >>>>>>> >>>>>>> KT> 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". >>>>>>> >>>>>>> >>>>>>> c) In the document, we see points 3-8 as "Unassigned". At >>>>>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iana.org%2Fassignments%2Fbgp-tunnel-encapsulation%2Fbgp-tunnel-encapsulation.xhtml%23color-extended-community-flags&data=05%7C02%7Cpamattes%40microsoft.com%7C74d814640ab44129b00508ddd37e0233%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638899260662556805%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=R7U8h3LFcxXCG3Uh2XCxzJaFRf6fhJevG%2B3XYGATy0Q%3D&reserved=0, >>>>>>> we see Segment Type C - Type H sub-TLVs. The same is true for points >>>>>>> 14-16 (this document includes them in the 14-255 "Unassigned"). >>>>>>> Please review and let us know what, if any, updates are necessary. >>>>>>> >>>>>>> KT> I don't think any update is necessary as they were not assigned by >>>>>>> this document but the other draft-ietf-idr-bgp-sr-segtypes-ext which is >>>>>>> also in the RFC Editor Q. Please do cross-check with IANA as well >>>>>>> though. >>>>>>> >>>>>>> >>>>>>> --> >>>>>>> >>>>>>> >>>>>>> 11) <!--[rfced] We had the following questions/comments regarding >>>>>>> Section >>>>>>> 6.8 and the corresponding IANA registry at >>>>>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iana.org%2Fassignments%2Fbgp-tunnel-encapsulation%2Fbgp-tunnel-encapsul&data=05%7C02%7Cpamattes%40microsoft.com%7C74d814640ab44129b00508ddd37e0233%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638899260662566581%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=WNg%2FEqHiasF%2FWLch5VoZoliHaoYnV3%2B7pNDpeRCYfyo%3D&reserved=0 >>>>>>> ation.xhtml#sr-policy-segment-flags: >>>>>>> >>>>>>> a) This document lists Bits 1-2 as "Unassigned" while the IANA >>>>>>> registry lists entries for these values (the A-Flag and S-Flag). >>>>>>> Please review and let us know what, if any, updates need to be made >>>>>>> for consistency. >>>>>>> >>>>>>> --> >>>>>>> >>>>>>> KT> This too is related to draft-ietf-idr-bgp-sr-segtypes-ext and so it >>>>>>> is the same as the previous comment. >>>>>>> >>>>>>> >>>>>>> >>>>>>> 12) <!--[rfced] We had the following questions/comments related to >>>>>>> Section >>>>>>> 6.10 and its corresponding registry at: >>>>>>> >>>>>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iana.org%2Fassignments%2Fsegment-routing%2Fsegment-routing.xhtml%23sr-policy-enlp-values&data=05%7C02%7Cpamattes%40microsoft.com%7C74d814640ab44129b00508ddd37e0233%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638899260662574702%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=MxmHLLG%2FOrOjp9am5zT0AziwzWGqWivcr3BhUmGIKNE%3D&reserved=0: >>>>>>> >>>>>>> a) There is a slight difference in the Description of Code Point 0. >>>>>>> Please let us know if/how these may be made consistent. >>>>>>> >>>>>>> This document: >>>>>>> Reserved (not to be used) >>>>>>> >>>>>>> IANA registry: >>>>>>> Reserved >>>>>>> >>>>>>> KT> We can make it "Reserved" >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> --> >>>>>>> >>>>>>> >>>>>>> 13) <!--[rfced] In the following, how may we update to correct the >>>>>>> connection between "address families" and "SAFI"? If our >>>>>>> suggested text does not correctly capture your intent, please let >>>>>>> us know how to rephrase. >>>>>>> >>>>>>> Original: >>>>>>> BGP peering sessions for address-families other than SR Policy SAFI >>>>>>> may be set up to routers outside the SR domain. >>>>>>> >>>>>>> >>>>>>> Perhaps: >>>>>>> BGP peering sessions for address families other than those that use >>>>>>> the SR Policy SAFI may be set up to routers outside the SR domain. >>>>>>> >>>>>>> --> >>>>>>> >>>>>>> KT> Ack >>>>>>> >>>>>>> >>>>>>> >>>>>>> 14) <!--[rfced] We note that this document has an Informative Reference >>>>>>> entry to draft-ietf-idr-bgp-sr-segtypes-ext-07, which is moving >>>>>>> through the RFC Editor queue simultaneously. >>>>>>> >>>>>>> We have updated this reference entry to use its RFC-to-be form as we >>>>>>> assume the intent is to publish them together. >>>>>>> >>>>>>> However, since this dependency is not normative, please indicate if >>>>>>> your preference is not to wait (if >>>>>>> draft-ietf-idr-bgp-sr-segtypes-ext-07 has not completed AUTH48 prior >>>>>>> to this document; in which case, we would revert to the I-D version of >>>>>>> the reference entry). --> >>>>>>> >>>>>>> KT> I would prefer to process them together for publication. They were >>>>>>> a single document and the authors were made to split them. >>>>>>> >>>>>>> >>>>>>> >>>>>>> 15) <!-- [rfced] We had the following questions/comments related to >>>>>>> abbreviation use throughout the document: >>>>>>> >>>>>>> a) FYI - We have added expansions for abbreviations upon first use per >>>>>>> Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each >>>>>>> expansion in the document carefully to ensure correctness. >>>>>>> >>>>>>> KT> Please change [SR-BGP-LS] to [BGP-LS-SR-POLICY]. Everything else >>>>>>> looks good to me. >>>>>>> >>>>>>> >>>>>>> b) We will update to have the abbreviation expanded upon first use and >>>>>>> then use the abbreviation thereafter (per the guidance at >>>>>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fstyleguide%2Fpart2%2F%23exp_abbrev&data=05%7C02%7Cpamattes%40microsoft.com%7C74d814640ab44129b00508ddd37e0233%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638899260662583032%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=NfQZ8hEE1xzzNRs%2FY9k9Zz40eNjLjl6Rt6GZXy2cOok%3D&reserved=0) >>>>>>> *except when >>>>>>> in a sub-TLV name* for the following abbreviations unless we hear >>>>>>> objection. >>>>>>> >>>>>>> KT> Ack >>>>>>> >>>>>>> >>>>>>> Segment Routing (SR) >>>>>>> candidate path (CP) >>>>>>> subsequent address family (SAFI) >>>>>>> Route Reflectors (RR) >>>>>>> Binding SID (BSID) >>>>>>> Explicit NULL Label Policy (ENLP) >>>>>>> >>>>>>> c) May we expand NH as Next Hop? >>>>>>> >>>>>>> KT> Yes >>>>>>> >>>>>>> >>>>>>> --> >>>>>>> >>>>>>> >>>>>>> 16) <!--[rfced] We had the following questions related to terminology >>>>>>> use throughout the document. >>>>>>> >>>>>>> a) Should the following terms be made consistent with regard to >>>>>>> capitalization, hyphenation, etc.? If so, please let us know how to >>>>>>> update. >>>>>>> >>>>>>> SR Policy vs. SR policy vs. policy >>>>>>> >>>>>>> KT> SR Policy per RFC9256 >>>>>>> >>>>>>> BGP UPDATE message vs. BGP update message vs. BGP Update >>>>>>> >>>>>>> KT> BGP UPDATE message per RFC4271 when referring to the message >>>>>>> >>>>>>> Route Target Extended Community vs. route target extended community >>>>>>> >>>>>>> KT> Route Target extended community >>>>>>> >>>>>>> Tunnel Type vs. Tunnel-Type vs. Tunnel-type >>>>>>> >>>>>>> KT> Tunnel Type >>>>>>> >>>>>>> Flags field vs. Flag octect (singular and field vs. octet) >>>>>>> >>>>>>> KT> Flags field >>>>>>> >>>>>>> Color vs. color >>>>>>> >>>>>>> KT> Color >>>>>>> >>>>>>> Endpoint vs. endpoint >>>>>>> >>>>>>> KT> endpoint >>>>>>> >>>>>>> Length field vs. length field (and simply length) >>>>>>> >>>>>>> KT> Length field >>>>>>> >>>>>>> "Drop Upon Invalid" behavior vs. "drop upon invalid" config >>>>>>> >>>>>>> KT> Drop-Upon-Invalid per RFC9256 >>>>>>> >>>>>>> Segment Type vs. segment type vs. Segment Types sub-TLV (plural) >>>>>>> >>>>>>> KT> That would vary by context - capitalized when referring to the name >>>>>>> and lowercase otherwise >>>>>>> >>>>>>> Explicit NULL Label vs. Explicit NULL label >>>>>>> >>>>>>> KT> That would vary by context - same as the previous one >>>>>>> >>>>>>> >>>>>>> b) We see that some field names are in double quotes. Should this be >>>>>>> made uniform throughout? If so, are quotation marks or no quotation >>>>>>> marks preferred? >>>>>>> >>>>>>> For example: >>>>>>> "Flags" field vs. Flags field >>>>>>> >>>>>>> KT> I think we can skip the quotes. >>>>>>> >>>>>>> >>>>>>> >>>>>>> --> >>>>>>> >>>>>>> >>>>>>> 17) <!--[rfced] Please review uses of the slash character "/" in the >>>>>>> body >>>>>>> of the document and consider whether "and", "or", or "and/or" >>>>>>> might be clearer for the reader. --> >>>>>>> >>>>>>> KT> No change is needed - they are clear to the reader in the >>>>>>> respective context >>>>>>> >>>>>>> >>>>>>> >>>>>>> 18) <!-- [rfced] Please review the "Inclusive Language" portion of the >>>>>>> online Style Guide >>>>>>> >>>>>>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fstyleguide%2Fpart2%2F%23inclusive_language&data=05%7C02%7Cpamattes%40microsoft.com%7C74d814640ab44129b00508ddd37e0233%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638899260662591281%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=A9uSst0WF26gb7vCAbFJcej58eZuHEmfBjRfvaPTNxk%3D&reserved=0> >>>>>>> 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> Thanks for the check. >>>>>>> >>>>>>> Thanks, >>>>>>> Ketan >>>>>>> >>>>>>> >>>>>>> >>>>>>> Thank you. >>>>>>> >>>>>>> RFC Editor/mf >>>>>>> >>>>>>> *****IMPORTANT***** >>>>>>> >>>>>>> Updated 2025/07/16 >>>>>>> >>>>>>> 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Ffaq%2F&data=05%7C02%7Cpamattes%40microsoft.com%7C74d814640ab44129b00508ddd37e0233%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638899260662599597%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=X7tpRLys6U4JaNpbpDTt0H7GhjRTS96GU0wmKGI4Zp0%3D&reserved=0). >>>>>>> >>>>>>> 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrustee.ietf.org%2Flicense-info&data=05%7C02%7Cpamattes%40microsoft.com%7C74d814640ab44129b00508ddd37e0233%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638899260662607914%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=8d0nHgD5YfGLZ6mpqPc%2F8ocatmxCIaTH6Cbhe7jAu7Q%3D&reserved=0). >>>>>>> >>>>>>> * 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthors.ietf.org%2Frfcxml-vocabulary&data=05%7C02%7Cpamattes%40microsoft.com%7C74d814640ab44129b00508ddd37e0233%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638899260662617425%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=fSqsImBu1ZQOm0v7T1L90xKKIXL%2Bfe5uM%2FG3Zxixm%2BI%3D&reserved=0>. >>>>>>> >>>>>>> * 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 >>>>>>> >>>>>>> * rfc-edi...@rfc-editor.org (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). >>>>>>> >>>>>>> * auth48archive@rfc-editor.org, which is a new archival mailing list >>>>>>> to preserve AUTH48 conversations; it is not an active discussion >>>>>>> list: >>>>>>> >>>>>>> * More info: >>>>>>> >>>>>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fietf-announce%2Fyb6lpIGh-4Q9l2USxIAe6P8O4Zc&data=05%7C02%7Cpamattes%40microsoft.com%7C74d814640ab44129b00508ddd37e0233%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638899260662630199%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=VyrJOTd4PA2m%2BRJrg4cNLnTCULDgUelXC7Um1T4DNUI%3D&reserved=0 >>>>>>> >>>>>>> * The archive itself: >>>>>>> >>>>>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fbrowse%2Fauth48archive%2F&data=05%7C02%7Cpamattes%40microsoft.com%7C74d814640ab44129b00508ddd37e0233%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638899260662642869%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=1mUUCrr7VDtbv0bRCnH%2B2qDIzyPuONPoJ8rswJ%2Bg4lk%3D&reserved=0 >>>>>>> >>>>>>> * 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, >>>>>>> auth48archive@rfc-editor.org 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9830.xml&data=05%7C02%7Cpamattes%40microsoft.com%7C74d814640ab44129b00508ddd37e0233%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638899260662651883%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=Wd7HIOOH37LyqvjUDDB4M4j5I9fdyDMMaF3CdfUISTc%3D&reserved=0 >>>>>>> >>>>>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9830.html&data=05%7C02%7Cpamattes%40microsoft.com%7C74d814640ab44129b00508ddd37e0233%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638899260662661193%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=3Apw8Q795EmP8q7BEE9oOWA%2BakzFYt4sne9sBu9QZJA%3D&reserved=0 >>>>>>> >>>>>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9830.pdf&data=05%7C02%7Cpamattes%40microsoft.com%7C74d814640ab44129b00508ddd37e0233%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638899260662669754%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=hWUYrauVXlnR93AVGrPWH9qfLDtOZNXd1e5mw2q5Io4%3D&reserved=0 >>>>>>> >>>>>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9830.txt&data=05%7C02%7Cpamattes%40microsoft.com%7C74d814640ab44129b00508ddd37e0233%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638899260662678790%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=fMe91N3sPIcXC8OqRwGFILVFV%2Fg3Ez3Lb3o8SZIxYqI%3D&reserved=0 >>>>>>> >>>>>>> Diff file of the text: >>>>>>> >>>>>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9830-diff.html&data=05%7C02%7Cpamattes%40microsoft.com%7C74d814640ab44129b00508ddd37e0233%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638899260662689139%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=eKXBk0qBot8H5DoGY1pbzHwMrDfnP0cAGbPAyUNjaRE%3D&reserved=0 >>>>>>> >>>>>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9830-rfcdiff.html&data=05%7C02%7Cpamattes%40microsoft.com%7C74d814640ab44129b00508ddd37e0233%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638899260663042002%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=HrKkIayh4Spb8CpJZZ6UT%2FeBzj0YO4aOlzo3sELkcWk%3D&reserved=0 >>>>>>> (side by side) >>>>>>> >>>>>>> Diff of the XML: >>>>>>> >>>>>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9830-xmldiff1.html&data=05%7C02%7Cpamattes%40microsoft.com%7C74d814640ab44129b00508ddd37e0233%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638899260663059900%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=sPPgpl2nnyYSNqESF%2Br2xqEqFCBjCMYTlC3OWbiSOWA%3D&reserved=0 >>>>>>> >>>>>>> >>>>>>> Tracking progress >>>>>>> ----------------- >>>>>>> >>>>>>> The details of the AUTH48 status of your document are here: >>>>>>> >>>>>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauth48%2Frfc9830&data=05%7C02%7Cpamattes%40microsoft.com%7C74d814640ab44129b00508ddd37e0233%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638899260663071839%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=6Bbxz8xORIQsFqNsViTOKLa7cpuyeZcw8hAis8idSik%3D&reserved=0 >>>>>>> >>>>>>> Please let us know if you have any questions. >>>>>>> >>>>>>> Thank you for your cooperation, >>>>>>> >>>>>>> RFC Editor >>>>>>> >>>>>>> -------------------------------------- >>>>>>> RFC9830 (draft-ietf-idr-sr-policy-safi-13) >>>>>>> >>>>>>> Title : Advertising Segment Routing Policies in BGP >>>>>>> Author(s) : S. Previdi, C. Filsfils, K. Talaulikar, P. Mattes, >>>>>>> D. Jain >>>>>>> WG Chair(s) : Susan Hares, Keyur Patel, Jeffrey Haas >>>>>>> >>>>>>> Area Director(s) : Jim Guichard, Ketan Talaulikar, Gunter Van de Velde >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >> > -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
