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]
