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, mfergu...@staff.rfc-editor.org 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 > > <ketant.i...@gmail.com> wrote: > > > > Thank you Megan. It looks good now. > > > > Thanks, > > Ketan > > > > > > On Sat, Aug 23, 2025 at 1:35 AM Megan Ferguson <mfergu...@staff.rfc- > > 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 > > > <ketant.i...@gmail.com> 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 > > > <ketant.i...@gmail.com> 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 > > > <mfergu...@staff.rfc-editor.org> 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 <kmo...@staff.rfc- > > > > editor.org> wrote: > > > > > > > > Authors, > > > > > > > > IANA has completed the updates to their registries. > > > > > > > > This now completes the AUTH48 process for this document. We will > > > > move this document forward in the publication process along with > > > > the companion documents when they have completed AUTH48 (see the > > > > status at <https://www.rfc-editor.org/cluster_info.php?cid=C534>) > > > > . > > > > > > > > Thank you for your time! > > > > > > > > RFC Editor/mf/kc > > > > > > > >> On Aug 4, 2025, at 2:04 PM, Karen Moore <kmo...@staff.rfc- > > > >> editor.org> wrote: > > > >> > > > >> Hi Paul, > > > >> > > > >> Thank you for your response; we have noted your approval on the > > > >> AUTH48 status page (https://www.rfc-editor.org/auth48/rfc9830). > > > >> > > > >> We will now ask IANA to update their registries to match the > > > >> edited document. We will inform you when the updates are > > > >> complete. > > > >> > > > >> Best regards, > > > >> RFC Editor/kc > > > >> > > > >>> On Aug 4, 2025, at 11:32 AM, Paul Mattes > > > >>> <pamat...@microsoft.com> wrote: > > > >>> > > > >>> > > > >>> > > > >>> The document looks good to me. > > > >>> > > > >>> pdm > > > >>> > > > >>> > > > >>> > > > >>> From: Karen Moore <kmo...@staff.rfc-editor.org> > > > >>> Sent: Monday, August 4, 2025 12:40 PM > > > >>> To: D Jain <dhanendra.i...@gmail.com>; Ketan Talaulikar > > > >>> <ketant.i...@gmail.com>; Paul Mattes <pamat...@microsoft.com>; > > > >>> Clarence Filsfils (cfilsfil) <cfils...@cisco.com>; > > > >>> stef...@previdi.net<stef...@previdi.net> > > > >>> Cc: Megan Ferguson <mfergu...@staff.rfc-editor.org>; RFC Editor > > > >>> <rfc-edi...@rfc-editor.org>; idr-...@ietf.org<idr- > > > >>> 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: [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 > > > >>>>>> 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 > > > >>>>>>> <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 > > > >>>>>>> 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 > > > >>>>>>> > > > >>>>>>> * 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
