Authors, Now that we have all necessary approvals, the IANA updates have been confirmed, and the other documents in the cluster have completed AUTH48, we will move the three documents from Cluster C534 forward in the publication process at this time.
The relevant cluster information can be found here: https://www.rfc-editor.org/cluster_info.php?cid=C534 Thank you all for your time and attention during AUTH48. Megan Ferguson RPC Production Center > On Sep 4, 2025, at 7:32 AM, Megan Ferguson <[email protected]> > wrote: > > Sabrina, > > Looks great - thanks! > > Megan Ferguson > RPC Production Center > >> On Sep 3, 2025, at 2:38 PM, Sabrina Tanamal via RT <[email protected]> >> wrote: >> >> Hi Megan, >> >> It looks like the changes for items #1, #3, and #4 were completed back in >> August [IANA #1426690]. I’ve now updated the registry to reflect the changes >> for item #2. Please let me know if I missed anything. >> >> https://www.iana.org/assignments/bgp-tunnel-encapsulation >> >> Thanks, >> Sabrina >> >> On Fri Aug 29 17:50:54 2025, [email protected] wrote: >>> IANA, >>> >>> Please review the following updates to make the registries consistent >>> with this document. Please let us know when the updates are complete >>> or if you have any questions/comments/concerns. >>> >>> 1) Please make the following updates to the BGP Encapsulation >>> Attribute Sub-TLVs registry at https://www.iana.org/assignments/bgp- >>> tunnel-encapsulation: >>> >>> Old: >>> 129 Policy Candidate Path Name sub-TLV >>> 130 Policy Name sub-TLV >>> >>> New (add SR): >>> 129 SR Policy Candidate Path Name sub-TLV >>> 130 SR Policy Name sub-TLV >>> >>> >>> 2) Please make the following updates to the SR Policy Segment List >>> Sub-TLVs registry at https://www.iana.org/assignments/bgp-tunnel- >>> encapsulation: >>> >>> Old: >>> 1 Segment Type A sub-TLV >>> 13 Segment Type B sub-TLV >>> >>> New (flip the placement of Segment): >>> 1 Type A Segment sub-TLV >>> 13 Type B Segment sub-TLV >>> >>> >>> 3) Please make the following updates to *both* the SR Policy Binding >>> SID Flags registry and the “SR Policy SRv6 Binding SID Flags” >>> registries at https://www.iana.org/assignments/bgp-tunnel- >>> encapsulation: >>> >>> Old: >>> 1 Drop Upon Invalid Flag (I-Flag) >>> >>> New (add hyphens): >>> 1 Drop-Upon-Invalid Flag (I-Flag) >>> >>> 4) Please make the following updates to the “SR Policy ENLP Values >>> registry at https://www.iana.org/assignments/segment-routing: >>> >>> Old: >>> >>> 1 …on an unlabeled IPv4 packet,… >>> 2 …on an unlabeled IPv6 packet,… >>> 3 …on an unlabeled IPv6 packet,… >>> >>> >>> New (remove comma): >>> 1 …on an unlabeled IPv4 packet… >>> 2 …on an unlabeled IPv6 packet… >>> 3 …on an unlabeled IPv6 packet… >>> >>> Thank you. >>> >>> Megan Ferguson >>> RFC Production Center >>> >>> >>>> On Aug 22, 2025, at 11:47 PM, Ketan Talaulikar >>>> <[email protected]> wrote: >>>> >>>> Thank you Megan. It looks good now. >>>> >>>> Thanks, >>>> Ketan >>>> >>>> >>>> On Sat, Aug 23, 2025 at 1:35 AM Megan Ferguson <[email protected] >>>> editor.org> wrote: >>>> Hi Ketan, >>>> >>>> Thanks for your review and guidance on this point. We have reverted >>>> this change in the files below (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 >>>> >>>> Once RFC-to-be 9831 completes AUTH48, we will send the necessary >>>> updates to IANA for both documents and continue along with the >>>> publication process. >>>> >>>> Thank you. >>>> >>>> RFC Editor/mf >>>> >>>>> On Aug 22, 2025, at 2:31 AM, Ketan Talaulikar >>>>> <[email protected]> wrote: >>>>> >>>>> Hi Megan, >>>>> >>>>> I missed this one change that was made incorrectly and needs to be >>>>> reverted. I've explained the reasons on the other thread on >>>>> RFC9831. >>>>> >>>>> The value 0 MAY be >>>>> used when the controller wants to indicate the desired SRv6 >>>>> Endpoint >>>>> Behavior, Behavior and >>>>> SID Structure, or flags without specifying >>>>> the BSID. >>>>> >>>>> >>>>> Thanks, >>>>> Ketan >>>>> >>>>> >>>>> On Fri, Aug 22, 2025 at 1:47 PM Ketan Talaulikar >>>>> <[email protected]> wrote: >>>>> Hi Megan, >>>>> >>>>> Thanks for making these changes for consistency between the two >>>>> documents. They look good to me. >>>>> >>>>> Thanks, >>>>> Ketan >>>>> >>>>> >>>>> On Fri, Aug 22, 2025 at 12:23 AM Megan Ferguson >>>>> <[email protected]> wrote: >>>>> 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 <[email protected] >>>>>> 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 <[email protected] >>>>>>> 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 >>>>>>>> <[email protected]> wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> The document looks good to me. >>>>>>>> >>>>>>>> pdm >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> From: Karen Moore <[email protected]> >>>>>>>> Sent: Monday, August 4, 2025 12:40 PM >>>>>>>> To: D Jain <[email protected]>; Ketan Talaulikar >>>>>>>> <[email protected]>; Paul Mattes <[email protected]>; >>>>>>>> Clarence Filsfils (cfilsfil) <[email protected]>; >>>>>>>> [email protected]<[email protected]> >>>>>>>> Cc: Megan Ferguson <[email protected]>; RFC Editor >>>>>>>> <[email protected]>; [email protected]<idr- >>>>>>>> [email protected]>; idr-chairs <[email protected]>; Sue Hares >>>>>>>> <[email protected]>; Roman Danyliw <[email protected]>; Shawn Zandi >>>>>>>> via auth48archive <[email protected]> >>>>>>>> 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 [email protected]. >>>>>>>> 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 >>>>>>>>> <[email protected]> wrote: >>>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> the document looks good to me. >>>>>>>>> >>>>>>>>> thanks. >>>>>>>>> s. >>>>>>>> >>>>>>>> >>>>>>>>> On Aug 2, 2025, at 5:51 PM, D Jain <[email protected]> >>>>>>>>> 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 <[email protected] >>>>>>>>> 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) >>>>>>>>>> <[email protected]> wrote: >>>>>>>>>> >>>>>>>>>> Hello, >>>>>>>>>> >>>>>>>>>> The document looks good to me and I approve its publication. >>>>>>>>>> >>>>>>>>>> Cheers, >>>>>>>>>> Clarence >>>>>>>>>> >>>>>>>>>> From: Ketan Talaulikar <[email protected]> >>>>>>>>>> Sent: Friday, August 1, 2025 7:40 AM >>>>>>>>>> To: Karen Moore <[email protected]> >>>>>>>>>> Cc: Clarence Filsfils (cfilsfil) <[email protected]>; >>>>>>>>>> [email protected]; [email protected]; >>>>>>>>>> [email protected]; Megan Ferguson <[email protected] >>>>>>>>>> editor.org>; RFC Editor <[email protected]>; idr- >>>>>>>>>> [email protected]; idr-chairs <[email protected]>; Sue Hares >>>>>>>>>> <[email protected]>; Roman Danyliw <[email protected]>; Shawn Zandi >>>>>>>>>> via auth48archive <[email protected]> >>>>>>>>>> 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 <[email protected] >>>>>>>>>> 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 >>>>>>>>>>> <[email protected]> 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 >>>>>>>>>>> <[email protected]> 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 >>>>>>>>>>> <[email protected]> wrote: >>>>>>>>>>> >>>>>>>>>>> Hi Megan, >>>>>>>>>>> >>>>>>>>>>> Thanks for your response. Please check inline below. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Tue, Jul 22, 2025 at 7:32 PM Megan Ferguson >>>>>>>>>>> <[email protected]> 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 >>>>>>>>>>> KT> following instances, all other uses of "policy" should >>>>>>>>>>> KT> be replaced by "SR Policy" for clarity and consistency. >>>>>>>>>>> KT> There are quite a lot of places where we have missed >>>>>>>>>>> KT> 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 >>>>>>>>>>>> KT> 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 >>>>>>>>>>> KT> are used together (or SRv6 Endpoint Behavior) - that is >>>>>>>>>>> KT> a technical term. However, there are only a few other >>>>>>>>>>> KT> places where the word is used as an English word and >>>>>>>>>>> KT> should not be capitalized (e.g. "link endpoints", >>>>>>>>>>> KT> "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 >>>>>>>>>>> KT> "config" in that context that should be changed to >>>>>>>>>>> KT> "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 >>>>>>>>>>> KT> section title and IANA) and rest of the text we can use >>>>>>>>>>> KT> 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 >>>>>>>>>>>> <[email protected]> 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 <[email protected]> >>>>>>>>>>>> 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 >>>>>>>>>>>> KT> 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 >>>>>>>>>>>> KT> locate just by looking at the index. However, there is >>>>>>>>>>>> KT> no concern if they were included as well. I would go >>>>>>>>>>>> KT> 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 >>>>>>>>>>>> KT> when something new gets added to the IANA SAFI registry >>>>>>>>>>>> KT> group. Please check the note >>>>>>>>>>>> KT> >>>>>>>>>>>> inhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iana.org%2Fassignments%2Fsafi- >>>>>>>>>>>> KT> namespace%2Fsafi- >>>>>>>>>>>> KT> >>>>>>>>>>>> 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 >>>>>>>>>>>> KT> and as such this document does not need to say anything >>>>>>>>>>>> KT> in this regard. I am happy to be corrected by the IANA >>>>>>>>>>>> KT> 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 >>>>>>>>>>>> KT> 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 >>>>>>>>>>>> KT> 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 >>>>>>>>>>>> KT> 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 >>>>>>>>>>>> KT> Type X" while the name of the sub-TLVs are to be "Type >>>>>>>>>>>> KT> X Segment sub-TLV" (I've seen both sub-TLV and Sub-TLV >>>>>>>>>>>> KT> - either is OK but we should have been consistent). The >>>>>>>>>>>> KT> "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 >>>>>>>>>>>> KT> assigned by this document but the other draft-ietf-idr- >>>>>>>>>>>> KT> bgp-sr-segtypes-ext which is also in the RFC Editor Q. >>>>>>>>>>>> KT> 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- >>>>>>>>>>>> KT> 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 >>>>>>>>>>>> KT> publication. They were a single document and the >>>>>>>>>>>> KT> 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]. >>>>>>>>>>>> KT> 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 >>>>>>>>>>>> KT> 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 >>>>>>>>>>>> KT> 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 >>>>>>>>>>>> KT> 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 >>>>>>>>>>>> >>>>>>>>>>>> * [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://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, >>>>>>>>>>>> [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://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 -- [email protected] To unsubscribe send an email to [email protected]
