Hi Karen, We've made these updates:
BGP Tunnel Encapsulation Attribute Sub-TLVs: 129 SR Policy Candidate Path Name sub-TLV [RFC-ietf-idr-sr-policy-safi-13] IETF 130 SR Policy Name sub-TLV [RFC-ietf-idr-sr-policy-safi-13] IETF SR Policy Binding SID Flags: 1 Drop-Upon-Invalid Flag (I-Flag) [RFC-ietf-idr-sr-policy-safi-13] SR Policy SRv6 Binding SID Flags: 1 Drop-Upon-Invalid Flag (I-Flag) [RFC-ietf-idr-sr-policy-safi-13] Registry: https://www.iana.org/assignments/bgp-tunnel-encapsulation/ SR Policy ENLP Values: 1 Push an IPv4 Explicit NULL label on an unlabeled IPv4 packet but do not push an IPv6 Explicit NULL label on an unlabeled IPv6 packet [RFC-ietf-idr-sr-policy-safi-13] 2 Push an IPv6 Explicit NULL label on an unlabeled IPv6 packet but do not push an IPv4 Explicit NULL label on an unlabeled IPv4 packet [RFC-ietf-idr-sr-policy-safi-13] 3 Push an IPv6 Explicit NULL label on an unlabeled IPv6 packet and push an IPv4 Explicit NULL label on an unlabeled IPv4 packet [RFC-ietf-idr-sr-policy-safi-13] Registry: https://www.iana.org/assignments/segment-routing/ Best regards, David Dong IANA Services Sr. Specialist On Mon Aug 04 21:06:02 2025, kmo...@staff.rfc-editor.org wrote: > Dear IANA, > > Please make the following updates to match the edited document at > <https://www.rfc-editor.org/authors/rfc9830-diff.html>. > > 1) Under the "BGP Tunnel 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: > 129 SR Policy Candidate Path Name sub-TLV > 130 SR Policy Name sub-TLV > > ... > 2) Under the "SR Policy Binding SID Flags” and "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: > 1 Drop-Upon-Invalid Flag (I-Flag) > > ... > 3) Under the "SR Policy ENLP Values” registry at > <https://www.iana.org/assignments/segment-routing/>: > > OLD: > 1 Push an IPv4 Explicit NULL label on an unlabeled IPv4 packet, > but do not push an IPv6 Explicit NULL label on an unlabeled > IPv6 packet > > 2 Push an IPv6 Explicit NULL label on an unlabeled IPv6 packet, > but do not push an IPv4 Explicit NULL label on an unlabeled IPv4 > packet > > 3 Push an IPv6 Explicit NULL label on an unlabeled IPv6 packet, > and push an IPv4 Explicit NULL label on an unlabeled IPv4 packet > > NEW (remove the commas): > 1 Push an IPv4 Explicit NULL label on an unlabeled IPv4 packet > but do not push an IPv6 Explicit NULL label on an unlabeled > IPv6 packet > > 2 Push an IPv6 Explicit NULL label on an unlabeled IPv6 packet > but do not push an IPv4 Explicit NULL label on an unlabeled IPv4 > packet > > 3 Push an IPv6 Explicit NULL label on an unlabeled IPv6 packet > and push an IPv4 Explicit NULL label on an unlabeled IPv4 packet > > Thank you in advance! > RFC Editor/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- > >>>> a...@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 > >>>>> KT> following instances, all other uses of "policy" should be > >>>>> KT> replaced by "SR Policy" for clarity and consistency. There > >>>>> KT> 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 > >>>>> KT> used together (or SRv6 Endpoint Behavior) - that is a > >>>>> KT> technical term. However, there are only a few other places > >>>>> KT> where the word is used as an English word and should not be > >>>>> KT> capitalized (e.g. "link endpoints", "endpoint/node > >>>>> KT> 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 > >>>>> KT> that context that should be changed to "behavior" for > >>>>> KT> 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 the > >>>>> KT> 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 > >>>>>> KT> just by looking at the index. However, there is no concern > >>>>>> KT> if they were included as well. I would go with your > >>>>>> KT> 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 > >>>>>> KT> something new gets added to the IANA SAFI registry group. > >>>>>> KT> 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 in > >>>>>> KT> 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 > >>>>>> KT> 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 > >>>>>> KT> 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 > >>>>>> KT> X" while the name of the sub-TLVs are to be "Type X Segment > >>>>>> KT> sub-TLV" (I've seen both sub-TLV and Sub-TLV - either is OK > >>>>>> KT> but we should have been consistent). The "Type-1" is > >>>>>> KT> 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-bgp- > >>>>>> KT> sr-segtypes-ext which is also in the RFC Editor Q. Please do > >>>>>> KT> 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 > >>>>>> KT> 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. > >>>>>> KT> They were a single document and the authors were made to > >>>>>> KT> 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 > >>>>>> KT> 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 > >>>>>> KT> 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 > >>>>>> KT> 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
