Hi Ina and Dante, This is another friendly reminder that we await your reviews and approvals of the updated files.
The files have been posted here (please refresh): https://www.rfc-editor.org/authors/rfc9705.xml https://www.rfc-editor.org/authors/rfc9705.txt https://www.rfc-editor.org/authors/rfc9705.html https://www.rfc-editor.org/authors/rfc9705.pdf The relevant diff files have been posted here: https://www.rfc-editor.org/authors/rfc9705-diff.html (comprehensive diff) https://www.rfc-editor.org/authors/rfc9705-auth48diff.html (AUTH48 changes) https://www.rfc-editor.org/authors/rfc9705-lastdiff.html (htmlwdiff diff between last version and this) https://www.rfc-editor.org/authors/rfc9705-lastrfcdiff.html (rfcdiff between last version and this) For the AUTH48 status of this document, please see: https://www.rfc-editor.org/auth48/rfc9705 Best regards, RFC Editor/ap > On Feb 10, 2025, at 8:52 AM, Alanna Paloma <apal...@staff.rfc-editor.org> > wrote: > > Hi Ina and Dante, > > This is a friendly reminder that we await your reviews and approvals of the > updated files. > > The files have been posted here (please refresh): > https://www.rfc-editor.org/authors/rfc9705.xml > https://www.rfc-editor.org/authors/rfc9705.txt > https://www.rfc-editor.org/authors/rfc9705.html > https://www.rfc-editor.org/authors/rfc9705.pdf > > The relevant diff files have been posted here: > https://www.rfc-editor.org/authors/rfc9705-diff.html (comprehensive diff) > https://www.rfc-editor.org/authors/rfc9705-auth48diff.html (AUTH48 changes) > https://www.rfc-editor.org/authors/rfc9705-lastdiff.html (htmlwdiff diff > between last version and this) > https://www.rfc-editor.org/authors/rfc9705-lastrfcdiff.html (rfcdiff between > last version and this) > > For the AUTH48 status of this document, please see: > https://www.rfc-editor.org/auth48/rfc9705 > > Best regards, > RFC Editor/ap > >> On Feb 3, 2025, at 10:21 AM, Alanna Paloma <apal...@staff.rfc-editor.org> >> wrote: >> >> Hi Tarek, >> >> Thank you for your approval. It has been noted on the AUTH48 status page: >> https://www.rfc-editor.org/auth48/rfc9705 >> >> Best regards, >> RFC Editor/ap >> >>> On Feb 1, 2025, at 7:16 PM, Tarek Saad <tsaad....@gmail.com> wrote: >>> >>> Hi Alanna, >>> Thanks for the suggested edits to the document. I’ve gone through the diff >>> and I’m ok with the latest version of the document. >>> Regards, >>> Tarek >>> From: Alanna Paloma <apal...@staff.rfc-editor.org> >>> Date: Thursday, January 30, 2025 at 4:25 PM >>> To: Chandrasekar Ramachandran <cse...@juniper.net> >>> Cc: ts...@cisco.com <ts...@cisco.com>, inami...@google.com >>> <inami...@google.com>, dante.j.pace...@verizon.com >>> <dante.j.pace...@verizon.com>, rfc-edi...@rfc-editor.org >>> <rfc-edi...@rfc-editor.org>, mpls-...@ietf.org <mpls-...@ietf.org>, >>> mpls-cha...@ietf.org <mpls-cha...@ietf.org>, n.leym...@telekom.de >>> <n.leym...@telekom.de>, james.n.guich...@futurewei.com >>> <james.n.guich...@futurewei.com>, auth48archive@rfc-editor.org >>> <auth48archive@rfc-editor.org> >>> Subject: Re: AUTH48: RFC-to-be 9705 <draft-ietf-mpls-ri-rsvp-frr-22> for >>> your review >>> Hi Chandra, >>> >>> Thank you for your reply. We have updated the files accordingly and noted >>> your approval on the AUTH48 status page: >>> https://www.rfc-editor.org/auth48/rfc9705 >>> >>> Once we receive approvals from Tarek, Ina, and Dante, we will move this >>> document forward in the publication process. >>> >>> The files have been posted here (please refresh): >>> https://www.rfc-editor.org/authors/rfc9705.xml >>> https://www.rfc-editor.org/authors/rfc9705.txt >>> https://www.rfc-editor.org/authors/rfc9705.html >>> https://www.rfc-editor.org/authors/rfc9705.pdf >>> >>> The relevant diff files have been posted here: >>> https://www.rfc-editor.org/authors/rfc9705-diff.html (comprehensive diff) >>> https://www.rfc-editor.org/authors/rfc9705-auth48diff.html (AUTH48 changes) >>> https://www.rfc-editor.org/authors/rfc9705-lastdiff.html (htmlwdiff diff >>> between last version and this) >>> https://www.rfc-editor.org/authors/rfc9705-lastrfcdiff.html (rfcdiff >>> between last version and this) >>> >>> Best regards, >>> RFC Editor/ap >>> >>> >>>> On Jan 30, 2025, at 9:59 AM, Chandrasekar Ramachandran >>>> <cse...@juniper.net> wrote: >>>> >>>> Apologies for the delay. After going through the document, there is only >>>> one comment. Even though we initially agreed to replace "RSVP" with >>>> "RSVP-TE" when referring to "refresh interval independent RSVP", the >>>> replacement does not seem to be apt in the following text. RFC 8370 >>>> contains only "RSVP" in all references to "refresh interval independent >>>> RSVP". >>>> >>>> The suggestion is to revert to "RSVP" in all the below mentioned locations. >>>> >>>> (1) >>>> Section 4.6.1 Detecting Support for Refresh-Interval Independent RSVP-TE >>>> FRR >>>> >>>> (2) >>>> 4.6. Backward Compatibility Procedures >>>> >>>> "Refresh-Interval Independent RSVP-TE FRR" and "RI-RSVP-FRR" refer >>>> to... >>>> >>>> There is no further comment other than the above. Thanks a lot for patient >>>> editing of the document. >>>> >>>> Thanks, >>>> Chandra. >>>> >>>> >>>> Juniper Business Use Only >>>>> -----Original Message----- >>>>> From: Alanna Paloma <apal...@staff.rfc-editor.org> >>>>> Sent: Thursday, January 30, 2025 10:46 PM >>>>> To: Chandrasekar Ramachandran <cse...@juniper.net>; ts...@cisco.com; >>>>> inami...@google.com; dante.j.pace...@verizon.com >>>>> Cc: rfc-edi...@rfc-editor.org; mpls-...@ietf.org; mpls-cha...@ietf.org; >>>>> n.leym...@telekom.de; james.n.guich...@futurewei.com; >>>>> auth48archive@rfc-editor.org >>>>> Subject: Re: AUTH48: RFC-to-be 9705 <draft-ietf-mpls-ri-rsvp-frr-22> for >>>>> your >>>>> review >>>>> >>>>> [External Email. Be cautious of content] >>>>> >>>>> >>>>> Hi Authors, >>>>> >>>>> Just another friendly reminder that we await your reviews and approvals of >>>>> the updated files prior to moving this document forward in the publication >>>>> process. >>>>> >>>>> The files have been posted here (please refresh): >>>>> https://urldefense.com/v3/__https://www.rfc- >>>>> editor.org/authors/rfc9705.xml__;!!NEt6yMaO- >>>>> gk!BIe7YDkZ_z42F7AfPJDgue4F-NRoY5- >>>>> AOwQeNwLCrjerW2FvlEIu3MaKz2Wg4UL8zcslM3vJfM1DCq2LBSIvVo9q$ >>>>> https://urldefense.com/v3/__https://www.rfc- >>>>> editor.org/authors/rfc9705.txt__;!!NEt6yMaO-gk!BIe7YDkZ_z42F7AfPJDgue4F- >>>>> NRoY5- >>>>> AOwQeNwLCrjerW2FvlEIu3MaKz2Wg4UL8zcslM3vJfM1DCq2LBVlFVc53$ >>>>> https://urldefense.com/v3/__https://www.rfc- >>>>> editor.org/authors/rfc9705.html__;!!NEt6yMaO- >>>>> gk!BIe7YDkZ_z42F7AfPJDgue4F-NRoY5- >>>>> AOwQeNwLCrjerW2FvlEIu3MaKz2Wg4UL8zcslM3vJfM1DCq2LBZ8yfAXn$ >>>>> https://urldefense.com/v3/__https://www.rfc- >>>>> editor.org/authors/rfc9705.pdf__;!!NEt6yMaO- >>>>> gk!BIe7YDkZ_z42F7AfPJDgue4F-NRoY5- >>>>> AOwQeNwLCrjerW2FvlEIu3MaKz2Wg4UL8zcslM3vJfM1DCq2LBdbRCm5z$ >>>>> >>>>> The relevant diff files have been posted here: >>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9705- >>>>> diff.html__;!!NEt6yMaO-gk!BIe7YDkZ_z42F7AfPJDgue4F-NRoY5- >>>>> AOwQeNwLCrjerW2FvlEIu3MaKz2Wg4UL8zcslM3vJfM1DCq2LBUVcWY1X$ >>>>> (comprehensive diff) https://urldefense.com/v3/__https://www.rfc- >>>>> editor.org/authors/rfc9705-auth48diff.html__;!!NEt6yMaO- >>>>> gk!BIe7YDkZ_z42F7AfPJDgue4F-NRoY5- >>>>> AOwQeNwLCrjerW2FvlEIu3MaKz2Wg4UL8zcslM3vJfM1DCq2LBbH6ASEy$ >>>>> (AUTH48 changes) https://urldefense.com/v3/__https://www.rfc- >>>>> editor.org/authors/rfc9705-lastdiff.html__;!!NEt6yMaO- >>>>> gk!BIe7YDkZ_z42F7AfPJDgue4F-NRoY5- >>>>> AOwQeNwLCrjerW2FvlEIu3MaKz2Wg4UL8zcslM3vJfM1DCq2LBW0VqTA6$ >>>>> (htmlwdiff diff between last version and this) >>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9705- >>>>> lastrfcdiff.html__;!!NEt6yMaO-gk!BIe7YDkZ_z42F7AfPJDgue4F-NRoY5- >>>>> AOwQeNwLCrjerW2FvlEIu3MaKz2Wg4UL8zcslM3vJfM1DCq2LBZDQhJ5i$ >>>>> (rfcdiff between last version and this) >>>>> >>>>> For the AUTH48 status of this document, please see: >>>>> https://urldefense.com/v3/__https://www.rfc- >>>>> editor.org/auth48/rfc9705__;!!NEt6yMaO-gk!BIe7YDkZ_z42F7AfPJDgue4F- >>>>> NRoY5- >>>>> AOwQeNwLCrjerW2FvlEIu3MaKz2Wg4UL8zcslM3vJfM1DCq2LBfi5wYI2$ >>>>> >>>>> Thank you, >>>>> RFC Editor/ap >>>>> >>>>>> On Jan 23, 2025, at 8:30 AM, Alanna Paloma <apal...@staff.rfc-editor.org> >>>>> wrote: >>>>>> >>>>>> Hi Authors, >>>>>> >>>>>> This is another friendly reminder that we await your reviews and >>>>>> approvals >>>>> of the updated files. >>>>>> >>>>>> The files have been posted here (please refresh): >>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9705 >>>>>> .xml__;!!NEt6yMaO-gk!BIe7YDkZ_z42F7AfPJDgue4F-NRoY5- >>>>> AOwQeNwLCrjerW2Fvl >>>>>> EIu3MaKz2Wg4UL8zcslM3vJfM1DCq2LBSIvVo9q$ >>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9705 >>>>>> .txt__;!!NEt6yMaO-gk!BIe7YDkZ_z42F7AfPJDgue4F-NRoY5- >>>>> AOwQeNwLCrjerW2Fvl >>>>>> EIu3MaKz2Wg4UL8zcslM3vJfM1DCq2LBVlFVc53$ >>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9705 >>>>>> .html__;!!NEt6yMaO-gk!BIe7YDkZ_z42F7AfPJDgue4F-NRoY5- >>>>> AOwQeNwLCrjerW2Fv >>>>>> lEIu3MaKz2Wg4UL8zcslM3vJfM1DCq2LBZ8yfAXn$ >>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9705 >>>>>> .pdf__;!!NEt6yMaO-gk!BIe7YDkZ_z42F7AfPJDgue4F-NRoY5- >>>>> AOwQeNwLCrjerW2Fvl >>>>>> EIu3MaKz2Wg4UL8zcslM3vJfM1DCq2LBdbRCm5z$ >>>>>> >>>>>> The relevant diff files have been posted here: >>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9705 >>>>>> -diff.html__;!!NEt6yMaO-gk!BIe7YDkZ_z42F7AfPJDgue4F-NRoY5- >>>>> AOwQeNwLCrje >>>>>> rW2FvlEIu3MaKz2Wg4UL8zcslM3vJfM1DCq2LBUVcWY1X$ (comprehensive >>>>> diff) >>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9705 >>>>>> -auth48diff.html__;!!NEt6yMaO-gk!BIe7YDkZ_z42F7AfPJDgue4F-NRoY5- >>>>> AOwQeN >>>>>> wLCrjerW2FvlEIu3MaKz2Wg4UL8zcslM3vJfM1DCq2LBbH6ASEy$ (AUTH48 >>>>> changes) >>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9705 >>>>>> -lastdiff.html__;!!NEt6yMaO-gk!BIe7YDkZ_z42F7AfPJDgue4F-NRoY5- >>>>> AOwQeNwL >>>>>> CrjerW2FvlEIu3MaKz2Wg4UL8zcslM3vJfM1DCq2LBW0VqTA6$ (htmlwdiff >>>>> diff >>>>>> between last version and this) >>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9705 >>>>>> -lastrfcdiff.html__;!!NEt6yMaO-gk!BIe7YDkZ_z42F7AfPJDgue4F-NRoY5- >>>>> AOwQe >>>>>> NwLCrjerW2FvlEIu3MaKz2Wg4UL8zcslM3vJfM1DCq2LBZDQhJ5i$ (rfcdiff >>>>>> between last version and this) >>>>>> >>>>>> For the AUTH48 status of this document, please see: >>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9705_ >>>>>> _;!!NEt6yMaO-gk!BIe7YDkZ_z42F7AfPJDgue4F-NRoY5- >>>>> AOwQeNwLCrjerW2FvlEIu3M >>>>>> aKz2Wg4UL8zcslM3vJfM1DCq2LBfi5wYI2$ >>>>>> >>>>>> Thank you, >>>>>> RFC Editor/ap >>>>>> >>>>>>> On Jan 16, 2025, at 12:49 PM, Alanna Paloma <apal...@staff.rfc- >>>>> editor.org> wrote: >>>>>>> >>>>>>> Authors, >>>>>>> >>>>>>> This is a friendly reminder that we await your reviews and approvals of >>>>>>> the >>>>> updated files. >>>>>>> >>>>>>> The files have been posted here (please refresh): >>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc970 >>>>>>> 5.xml__;!!NEt6yMaO-gk!BIe7YDkZ_z42F7AfPJDgue4F-NRoY5- >>>>> AOwQeNwLCrjerW2F >>>>>>> vlEIu3MaKz2Wg4UL8zcslM3vJfM1DCq2LBSIvVo9q$ >>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc970 >>>>>>> 5.txt__;!!NEt6yMaO-gk!BIe7YDkZ_z42F7AfPJDgue4F-NRoY5- >>>>> AOwQeNwLCrjerW2F >>>>>>> vlEIu3MaKz2Wg4UL8zcslM3vJfM1DCq2LBVlFVc53$ >>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc970 >>>>>>> 5.html__;!!NEt6yMaO-gk!BIe7YDkZ_z42F7AfPJDgue4F-NRoY5- >>>>> AOwQeNwLCrjerW2 >>>>>>> FvlEIu3MaKz2Wg4UL8zcslM3vJfM1DCq2LBZ8yfAXn$ >>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc970 >>>>>>> 5.pdf__;!!NEt6yMaO-gk!BIe7YDkZ_z42F7AfPJDgue4F-NRoY5- >>>>> AOwQeNwLCrjerW2F >>>>>>> vlEIu3MaKz2Wg4UL8zcslM3vJfM1DCq2LBdbRCm5z$ >>>>>>> >>>>>>> The relevant diff files have been posted here: >>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc970 >>>>>>> 5-diff.html__;!!NEt6yMaO-gk!BIe7YDkZ_z42F7AfPJDgue4F-NRoY5- >>>>> AOwQeNwLCr >>>>>>> jerW2FvlEIu3MaKz2Wg4UL8zcslM3vJfM1DCq2LBUVcWY1X$ >>>>> (comprehensive >>>>>>> diff) >>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc970 >>>>>>> 5-auth48diff.html__;!!NEt6yMaO-gk!BIe7YDkZ_z42F7AfPJDgue4F-NRoY5- >>>>> AOwQ >>>>>>> eNwLCrjerW2FvlEIu3MaKz2Wg4UL8zcslM3vJfM1DCq2LBbH6ASEy$ >>>>> (AUTH48 >>>>>>> changes) >>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc970 >>>>>>> 5-lastdiff.html__;!!NEt6yMaO-gk!BIe7YDkZ_z42F7AfPJDgue4F-NRoY5- >>>>> AOwQeN >>>>>>> wLCrjerW2FvlEIu3MaKz2Wg4UL8zcslM3vJfM1DCq2LBW0VqTA6$ >>>>> (htmlwdiff diff >>>>>>> between last version and this) >>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc970 >>>>>>> 5-lastrfcdiff.html__;!!NEt6yMaO-gk!BIe7YDkZ_z42F7AfPJDgue4F-NRoY5- >>>>> AOw >>>>>>> QeNwLCrjerW2FvlEIu3MaKz2Wg4UL8zcslM3vJfM1DCq2LBZDQhJ5i$ >>>>> (rfcdiff >>>>>>> between last version and this) >>>>>>> >>>>>>> Once we’ve received all necessary approvals, we will move this document >>>>> forward in the publication process. >>>>>>> >>>>>>> For the AUTH48 status of this document, please see: >>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9705 >>>>>>> __;!!NEt6yMaO-gk!BIe7YDkZ_z42F7AfPJDgue4F-NRoY5- >>>>> AOwQeNwLCrjerW2FvlEIu >>>>>>> 3MaKz2Wg4UL8zcslM3vJfM1DCq2LBfi5wYI2$ >>>>>>> >>>>>>> Thank you, >>>>>>> RFC Editor/ap >>>>>>> >>>>>>>> On Jan 9, 2025, at 10:59 AM, Alanna Paloma <apal...@staff.rfc- >>>>> editor.org> wrote: >>>>>>>> >>>>>>>> Hi Chandra, >>>>>>>> >>>>>>>> The files have been updated per your request. >>>>>>>> >>>>>>>> The files have been posted here (please refresh): >>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc97 >>>>>>>> 05.xml__;!!NEt6yMaO-gk!BIe7YDkZ_z42F7AfPJDgue4F-NRoY5- >>>>> AOwQeNwLCrjerW >>>>>>>> 2FvlEIu3MaKz2Wg4UL8zcslM3vJfM1DCq2LBSIvVo9q$ >>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc97 >>>>>>>> 05.txt__;!!NEt6yMaO-gk!BIe7YDkZ_z42F7AfPJDgue4F-NRoY5- >>>>> AOwQeNwLCrjerW >>>>>>>> 2FvlEIu3MaKz2Wg4UL8zcslM3vJfM1DCq2LBVlFVc53$ >>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc97 >>>>>>>> 05.html__;!!NEt6yMaO-gk!BIe7YDkZ_z42F7AfPJDgue4F-NRoY5- >>>>> AOwQeNwLCrjer >>>>>>>> W2FvlEIu3MaKz2Wg4UL8zcslM3vJfM1DCq2LBZ8yfAXn$ >>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc97 >>>>>>>> 05.pdf__;!!NEt6yMaO-gk!BIe7YDkZ_z42F7AfPJDgue4F-NRoY5- >>>>> AOwQeNwLCrjerW >>>>>>>> 2FvlEIu3MaKz2Wg4UL8zcslM3vJfM1DCq2LBdbRCm5z$ >>>>>>>> >>>>>>>> The relevant diff files have been posted here: >>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc97 >>>>>>>> 05-diff.html__;!!NEt6yMaO-gk!BIe7YDkZ_z42F7AfPJDgue4F-NRoY5- >>>>> AOwQeNwL >>>>>>>> CrjerW2FvlEIu3MaKz2Wg4UL8zcslM3vJfM1DCq2LBUVcWY1X$ >>>>> (comprehensive >>>>>>>> diff) >>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc97 >>>>>>>> 05-auth48diff.html__;!!NEt6yMaO-gk!BIe7YDkZ_z42F7AfPJDgue4F-NRoY5- >>>>> AO >>>>>>>> wQeNwLCrjerW2FvlEIu3MaKz2Wg4UL8zcslM3vJfM1DCq2LBbH6ASEy$ >>>>> (AUTH48 >>>>>>>> changes) >>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc97 >>>>>>>> 05-lastdiff.html__;!!NEt6yMaO-gk!BIe7YDkZ_z42F7AfPJDgue4F-NRoY5- >>>>> AOwQ >>>>>>>> eNwLCrjerW2FvlEIu3MaKz2Wg4UL8zcslM3vJfM1DCq2LBW0VqTA6$ >>>>> (htmlwdiff >>>>>>>> diff between last version and this) >>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc97 >>>>>>>> 05-lastrfcdiff.html__;!!NEt6yMaO-gk!BIe7YDkZ_z42F7AfPJDgue4F-NRoY5- >>>>> A >>>>>>>> OwQeNwLCrjerW2FvlEIu3MaKz2Wg4UL8zcslM3vJfM1DCq2LBZDQhJ5i$ >>>>> (rfcdiff >>>>>>>> between last version and this) >>>>>>>> >>>>>>>> We will await any further changes you may have and approvals from each >>>>> author prior to moving forward in the publication process. >>>>>>>> >>>>>>>> [Note that my email address has changed from <apal...@amsl.com> to >>>>>>>> <apal...@staff.rfc-editor.org>.] >>>>>>>> >>>>>>>> Thank you, >>>>>>>> RFC Editor/ap >>>>>>>> >>>>>>>>> On Jan 9, 2025, at 8:11 AM, Chandrasekar Ramachandran >>>>> <csekar=40juniper....@dmarc.ietf.org> wrote: >>>>>>>>> >>>>>>>>> Please find a few more comments below. I am going through the >>>>> document fully once again and will provide a final list of comments (if >>>>> any) on >>>>> Monday. >>>>>>>>> >>>>>>>>> Abstract: >>>>>>>>> >>>>>>>>> Facility backup method allow one or more LSPs traversing... >>>>>>>>> should be >>>>>>>>> Facility backup method allows one or more LSPs traversing... >>>>>>>>> >>>>>>>>> Security Considerations: >>>>>>>>> >>>>>>>>> The security considerations pertaining to the original RSVP >>>>>>>>> protocols ([RFC2205], [RFC3209], and [RFC5920]) remain relevant. >>>>>>>>> should be >>>>>>>>> The security considerations pertaining to the original RSVP >>>>>>>>> protocol ([RFC2205], [RFC3209], and [RFC5920]) remain relevant. >>>>>>>>> >>>>>>>>>>> b) Should "RSVP" be added to the title for consistency with the >>>>>>>>>>> rest of the document and the abbreviated title? >>>>>>>>>>> >>>>>>>>>>> Original: >>>>>>>>>>> Refresh-interval Independent FRR Facility Protection >>>>>>>>>>> >>>>>>>>>>> Current: >>>>>>>>>>> Refresh-Interval Independent Fast Reroute (FRR) Facility >>>>>>>>>>> Protection >>>>>>>>>>> >>>>>>>>>>> Perhaps: >>>>>>>>>>> Refresh-Interval Independent RSVP Fast Reroute (RI-RSVP-FRR) >>>>>>>>>>> Facility Protection >>>>>>>>>>> >>>>>>>>>>> --> >>>>>>>>>> >>>>>>>>>> [CR] To keep the name consistent with RFC 4090 and RFC 8370, it >>>>>>>>>> can be RSVP- TE. >>>>>>>>>> >>>>>>>>>> NEW: >>>>>>>>>> Refresh-Interval Independent RSVP-TE Fast Reroute Facility >>>>>>>>>> Protection >>>>>>>>> >>>>>>>>> On the earlier discussion (shown above) on whether "RSVP" should be >>>>> added for which we provided a comment to make it "RSVP-TE", it will be >>>>> better to keep it as "RSVP" as you suggested because that is the >>>>> convention >>>>> used in RFC 8370. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Chandra. >>>>>>>>> >>>>>>>>> >>>>>>>>> Juniper Business Use Only >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Alanna Paloma <apal...@amsl.com> >>>>>>>>>> Sent: Tuesday, January 7, 2025 6:01 AM >>>>>>>>>> To: Chandrasekar Ramachandran <cse...@juniper.net> >>>>>>>>>> Cc: rfc-edi...@rfc-editor.org; ts...@cisco.com; >>>>>>>>>> inami...@google.com; dante.j.pace...@verizon.com; >>>>>>>>>> mpls-...@ietf.org; mpls-cha...@ietf.org; n.leym...@telekom.de; >>>>>>>>>> james.n.guich...@futurewei.com; auth48archive@rfc-editor.org >>>>>>>>>> Subject: Re: AUTH48: RFC-to-be 9705 >>>>>>>>>> <draft-ietf-mpls-ri-rsvp-frr-22> for your review >>>>>>>>>> >>>>>>>>>> [External Email. Be cautious of content] >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Hi Chandra, >>>>>>>>>> >>>>>>>>>> Thank you for your reply. We have updated as requested. >>>>>>>>>> >>>>>>>>>> The files have been posted here (please refresh): >>>>>>>>>> https://urldefense.com/v3/__https://www.rfc- >>>>>>>>>> editor.org/authors/rfc9705.xml__;!!NEt6yMaO- >>>>>>>>>> gk!Ffb5OXElFZyT8k54wSdXaSSIZVB4koLrq4- >>>>>>>>>> gSHhCAQNrB5_iTsKfND9wzggggVyJzUI4xyOO0kJHew$ >>>>>>>>>> https://urldefense.com/v3/__https://www.rfc- >>>>>>>>>> editor.org/authors/rfc9705.txt__;!!NEt6yMaO- >>>>>>>>>> gk!Ffb5OXElFZyT8k54wSdXaSSIZVB4koLrq4- >>>>>>>>>> gSHhCAQNrB5_iTsKfND9wzggggVyJzUI4xyNA9m3WMQ$ >>>>>>>>>> https://urldefense.com/v3/__https://www.rfc- >>>>>>>>>> editor.org/authors/rfc9705.html__;!!NEt6yMaO- >>>>>>>>>> gk!Ffb5OXElFZyT8k54wSdXaSSIZVB4koLrq4- >>>>>>>>>> gSHhCAQNrB5_iTsKfND9wzggggVyJzUI4xyN7PuCB9g$ >>>>>>>>>> https://urldefense.com/v3/__https://www.rfc- >>>>>>>>>> editor.org/authors/rfc9705.pdf__;!!NEt6yMaO- >>>>>>>>>> gk!Ffb5OXElFZyT8k54wSdXaSSIZVB4koLrq4- >>>>>>>>>> gSHhCAQNrB5_iTsKfND9wzggggVyJzUI4xyPfSJNPCA$ >>>>>>>>>> >>>>>>>>>> The relevant diff files have been posted here: >>>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc >>>>>>>>>> 9705- >>>>>>>>>> diff.html__;!!NEt6yMaO-gk!Ffb5OXElFZyT8k54wSdXaSSIZVB4koLrq4- >>>>>>>>>> gSHhCAQNrB5_iTsKfND9wzggggVyJzUI4xyO6Km9sTg$ (comprehensive >>>>> diff) >>>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc >>>>>>>>>> 9705- >>>>>>>>>> auth48diff.html__;!!NEt6yMaO- >>>>> gk!Ffb5OXElFZyT8k54wSdXaSSIZVB4koLrq4 >>>>>>>>>> - gSHhCAQNrB5_iTsKfND9wzggggVyJzUI4xyNiAMVGkA$ (AUTH48 >>>>> changes) >>>>>>>>>> >>>>>>>>>> Please review the document carefully and contact us with any >>>>>>>>>> further updates you may have. Note that we do not make changes >>>>>>>>>> once a document is published as an RFC. >>>>>>>>>> >>>>>>>>>> We will await approvals from each party listed on the AUTH48 >>>>>>>>>> status page below prior to moving this document forward in the >>>>> publication process. >>>>>>>>>> >>>>>>>>>> For the AUTH48 status of this document, please see: >>>>>>>>>> https://urldefense.com/v3/__https://www.rfc- >>>>>>>>>> editor.org/auth48/rfc9705__;!!NEt6yMaO- >>>>>>>>>> gk!Ffb5OXElFZyT8k54wSdXaSSIZVB4koLrq4- >>>>>>>>>> gSHhCAQNrB5_iTsKfND9wzggggVyJzUI4xyP_pDM6vQ$ >>>>>>>>>> >>>>>>>>>> Thank you, >>>>>>>>>> RFC Editor/ap >>>>>>>>>> >>>>>>>>>>> On Jan 6, 2025, at 8:51 AM, Chandrasekar Ramachandran >>>>>>>>>> <csekar=40juniper....@dmarc.ietf.org> wrote: >>>>>>>>>>> >>>>>>>>>>> Please find our responses inline. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Chandra. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Juniper Business Use Only >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org> >>>>>>>>>>>> Sent: Friday, December 20, 2024 6:19 AM >>>>>>>>>>>> To: Chandrasekar Ramachandran <cse...@juniper.net>; >>>>>>>>>> ts...@cisco.com; >>>>>>>>>>>> inami...@google.com; dante.j.pace...@verizon.com >>>>>>>>>>>> Cc: rfc-edi...@rfc-editor.org; mpls-...@ietf.org; >>>>>>>>>>>> mpls-cha...@ietf.org; n.leym...@telekom.de; >>>>>>>>>>>> james.n.guich...@futurewei.com; auth48archive@rfc-editor.org >>>>>>>>>>>> Subject: Re: AUTH48: RFC-to-be 9705 >>>>>>>>>>>> <draft-ietf-mpls-ri-rsvp-frr-22> for your review >>>>>>>>>>>> >>>>>>>>>>>> [External Email. Be cautious of content] >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Authors, >>>>>>>>>>>> >>>>>>>>>>>> While reviewing this document during AUTH48, please resolve (as >>>>>>>>>>>> necessary) the following questions, which are also in the XML file. >>>>>>>>>>>> >>>>>>>>>>>> 1) <!-- [rfced] Please review the following questions and >>>>>>>>>>>> changes regarding this document's title: >>>>>>>>>>>> >>>>>>>>>>>> a) FYI - Abbreviations have been expanded per Section 3.6 of RFC >>>>>>>>>>>> 7322 ("RFC Style Guide"). >>>>>>>>>>>> >>>>>>>>>>>> b) Should "RSVP" be added to the title for consistency with the >>>>>>>>>>>> rest of the document and the abbreviated title? >>>>>>>>>>>> >>>>>>>>>>>> Original: >>>>>>>>>>>> Refresh-interval Independent FRR Facility Protection >>>>>>>>>>>> >>>>>>>>>>>> Current: >>>>>>>>>>>> Refresh-Interval Independent Fast Reroute (FRR) Facility >>>>>>>>>>>> Protection >>>>>>>>>>>> >>>>>>>>>>>> Perhaps: >>>>>>>>>>>> Refresh-Interval Independent RSVP Fast Reroute (RI-RSVP-FRR) >>>>>>>>>>>> Facility Protection >>>>>>>>>>>> >>>>>>>>>>>> --> >>>>>>>>>>> >>>>>>>>>>> [CR] To keep the name consistent with RFC 4090 and RFC 8370, it >>>>>>>>>>> can be >>>>>>>>>> RSVP-TE. >>>>>>>>>>> >>>>>>>>>>> NEW: >>>>>>>>>>> Refresh-Interval Independent RSVP-TE Fast Reroute Facility >>>>>>>>>>> Protection >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 2) <!-- [rfced] Please insert any keywords (beyond those that >>>>>>>>>>>> appear in the >>>>>>>>>>>> title) for use on https://urldefense.com/v3/__https://www.rfc- >>>>>>>>>>>> editor.org/search__;!!NEt6yMaO-gk!FM2VL8WYKZ4l- >>>>>>>>>> zDnXFEMT1bMvVmTs- >>>>>>>>>>>> >>>>> E1_Al7pzTrypczYwOa9zufdnM4Qo4xmCWUhUKQDOal5wQIaaUoCPHz-SQ$ >>>>>>>>>> . - >>>>>>>>>>>> -> >>>>>>>>>>> >>>>>>>>>>> [CR] "ri-rsvp-frr" - both upper and lower cases >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 3) <!-- [rfced] Should the first bullet be separated into two >>>>>>>>>>>> separate bullets because it contains two separate problems? >>>>>>>>>>>> >>>>>>>>>>>> Original: >>>>>>>>>>>> The use of Refresh messages to >>>>>>>>>>>> cover many possible failures has resulted in a number of >>>>>>>>>>>> operational problems. >>>>>>>>>>>> >>>>>>>>>>>> - One problem relates to RSVP control plane scaling due to >>>>>>>>>>>> periodic refreshes of Path and Resv messages, another relates >>>>>>>>>>>> to the reliability and latency of RSVP signaling. >>>>>>>>>>>> >>>>>>>>>>>> - An additional problem is the time to clean up the stale state >>>>>>>>>>>> after a tear message is lost. For more on these problems see >>>>>>>>>>>> Section 1 of RSVP Refresh Overhead Reduction Extensions >>>>> [RFC2961]. >>>>>>>>>>>> >>>>>>>>>>>> Perhaps: >>>>>>>>>>>> The use of Refresh messages to >>>>>>>>>>>> cover many possible failures has resulted in a number of >>>>>>>>>>>> operational problems. >>>>>>>>>>>> >>>>>>>>>>>> * One problem relates to RSVP control plane scaling due to >>>>>>>>>>>> periodic refreshes of Path and Resv messages >>>>>>>>>>>> >>>>>>>>>>>> * Another problem relates to the relates to the reliability and >>>>>>>>>>>> latency of RSVP signaling. reliability and latency of RSVP >>>>>>>>>>>> signaling. >>>>>>>>>>>> >>>>>>>>>>>> * An additional problem is the time to clean up the stale state >>>>>>>>>>>> after a tear message is lost. For more on these problems see >>>>>>>>>>>> Section 1 of [RFC2961]. >>>>>>>>>>>> >>>>>>>>>>>> --> >>>>>>>>>>> >>>>>>>>>>> [CR] The authors are fine with the proposed text. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 4) <!--[rfced] To clarify this document's relation to [RFC2961], >>>>>>>>>>>> may we update this sentence as follows? >>>>>>>>>>>> >>>>>>>>>>>> Original: >>>>>>>>>>>> Therefore, this document makes support for [RFC2961] a pre- >>>>> requisite. >>>>>>>>>>>> >>>>>>>>>>>> Perhaps: >>>>>>>>>>>> Therefore, [RFC2961] is a prerequisite for this document. >>>>>>>>>>>> --> >>>>>>>>>>> >>>>>>>>>>> [CR] The authors are fine with the proposed text. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 5) <!-- [rfced] Please review the following questions and >>>>>>>>>>>> changes regarding Section 2 ("Terminology"). >>>>>>>>>>>> >>>>>>>>>>>> a) The terminology list contains a mixture of both abbreviations >>>>>>>>>>>> and definitions. For consistency and readability, may we >>>>>>>>>>>> separate definitions and abbreviations into two different lists? >>>>>>>>>>>> >>>>>>>>>>>> b) May we update some list items for a more accurate and 1:1 >>>>>>>>>>>> relationship between an abbreviation and its expansion? Please >>>>>>>>>>>> see examples in the "Perhaps" text below. >>>>>>>>>>>> >>>>>>>>>>>> c) In addition, the format of some definition items may suggest >>>>>>>>>>>> that >>>>>>>>>> "router" >>>>>>>>>>>> and "node" can be used interchangeably (see some examples >>>>> below). >>>>>>>>>>>> Please review and confirm if this is accurate. May we update the >>>>>>>>>>>> terms as suggested below? >>>>>>>>>>>> >>>>>>>>>>>> Originals: >>>>>>>>>>>> >>>>>>>>>>>> Phop node: Previous-hop router along the label switched path >>>>>>>>>>>> >>>>>>>>>>>> MP: Merge Point router as defined in [RFC4090] >>>>>>>>>>>> >>>>>>>>>>>> LP-MP node: Merge Point router at the tail of Link-Protecting >>>>>>>>>>>> bypass tunnel >>>>>>>>>>>> >>>>>>>>>>>> Perhaps (a few examples): >>>>>>>>>>>> >>>>>>>>>>>> PHOP: Previous-Hop (can refer to a router or node along the LSP) >>>>>>>>>>>> >>>>>>>>>>>> MP: Merge Point (can refer to a router as defined in [RFC4090]) >>>>>>>>>>>> >>>>>>>>>>>> LP-MP: Link-Protecting Merge Point (can refer to a router or >>>>>>>>>>>> node at the tail of a Link-Protecting bypass tunnel) >>>>>>>>>>>> >>>>>>>>>>>> d) FYI - We have added expansions for Path State Block (PSB) and >>>>>>>>>>>> Reservation State Block (RSB) to this terminology list to avoid >>>>>>>>>>>> expanding them inside of the definition of "LSP state". Please >>>>>>>>>>>> review and let us know if there are additional abbreviations or >>>>>>>>>>>> terminology used in this document (such as LSP, FRR, etc.) that >>>>>>>>>>>> you would like to add to >>>>>>>>>> this terminology list. >>>>>>>>>>>> >>>>>>>>>>>> --> >>>>>>>>>>> >>>>>>>>>>> [CR] All proposed changes to Terminology Section look good. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 6) <!-- [rfced] How may we update "has been configured to be >>>>>>>>>>>> long of the order of minutes" for clarity? >>>>>>>>>>>> >>>>>>>>>>>> Original: >>>>>>>>>>>> Assume that refresh interval has been configured to be long of >>>>>>>>>>>> the order >>>>>>>>>> of >>>>>>>>>>>> minutes and refresh reduction extensions are enabled on all >>>>>>>>>>>> routers. >>>>>>>>>>>> >>>>>>>>>>>> Perhaps: >>>>>>>>>>>> Assume that refresh interval has been configured to be as long >>>>>>>>>>>> as the >>>>>>>>>> order >>>>>>>>>>>> of minutes and that refresh reduction extensions are enabled on >>>>>>>>>>>> all >>>>>>>>>> routers. >>>>>>>>>>>> --> >>>>>>>>>>> >>>>>>>>>>> [CR] The authors are fine with the proposed text. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 7) <!-- [rfced] How may we update this section title to avoid >>>>>>>>>>>> using an RFC number as an adjective? >>>>>>>>>>>> >>>>>>>>>>>> Original: >>>>>>>>>>>> >>>>>>>>>>>> 4.1. Requirement on RFC 4090 Capable Node to advertise RI-RSVP >>>>>>>>>>>> Capability >>>>>>>>>>>> >>>>>>>>>>>> Perhaps (remove RFC number): >>>>>>>>>>>> >>>>>>>>>>>> 4.1. Requirement for Capable Nodes to Advertise the RI-RSVP >>>>>>>>>>>> Capability >>>>>>>>>>>> >>>>>>>>>>>> Perhaps (keep RFC number): >>>>>>>>>>>> >>>>>>>>>>>> 4.1. Requirement for Capable Nodes from RFC 4090 to Advertise >>>>>>>>>>>> the RI-RSVP Capability >>>>>>>>>>>> --> >>>>>>>>>>> >>>>>>>>>>> [CR] Both the changes proposed does not convey that the specific >>>>>>>>>> requirement in the section is for 4090 capable nodes. >>>>>>>>>>> Does the following look better? >>>>>>>>>>> >>>>>>>>>>> NEW: >>>>>>>>>>> >>>>>>>>>>> 4.1. Requirement for RFC 4090 Capable Nodes to Advertise the >>>>>>>>>>> RI-RSVP Capability >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 8) <!-- [rfced] Can the second sentence in the text below be >>>>>>>>>>>> made more concise, as it mostly contains repeated information >>>>>>>>>>>> from the previous sentence? >>>>>>>>>>>> >>>>>>>>>>>> Original: >>>>>>>>>>>> >>>>>>>>>>>> - The PLR MUST also include its router ID in a Node-ID >>>>>>>>>>>> sub-object in RRO object carried in any subsequent Path message >>>>>>>>>>>> corresponding to the LSP. While including its router ID in the >>>>>>>>>>>> Node-ID sub-object carried in the outgoing Path message, the >>>>>>>>>>>> PLR MUST include the Node-ID sub-object after including its >>>>>>>>>>>> IPv4/IPv6 address or unnumbered interface ID sub-object. >>>>>>>>>>>> >>>>>>>>>>>> Perhaps: >>>>>>>>>>>> >>>>>>>>>>>> * The PLR MUST also include its router ID in a Node-ID >>>>>>>>>>>> sub-object in the RRO object that is carried in any subsequent >>>>>>>>>>>> Path message corresponding to the LSP. While doing so, the PLR >>>>>>>>>>>> MUST include the Node-ID sub-object after including its >>>>>>>>>>>> IPv4/IPv6 address or unnumbered interface ID sub-object. >>>>>>>>>>>> --> >>>>>>>>>>> >>>>>>>>>>> [CR] The authors are fine with the proposed text. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 9) <!-- [rfced] May we update the text below to improve >>>>>>>>>>>> readability? >>>>>>>>>>>> In particular, how may we clarify what the MP "sets" the I-bit to? >>>>>>>>>>>> >>>>>>>>>>>> Original: >>>>>>>>>>>> >>>>>>>>>>>> If the MP has set the I-bit in the CAPABILITY object [RFC8370] >>>>>>>>>>>> carried in Hello message corresponding to the Node-ID based >>>>>>>>>>>> Hello session, >>>>>>>>>> then >>>>>>>>>>>> the PLR MUST conclude that the MP supports refresh- interval >>>>>>>>>>>> independent FRR procedures defined in this document. >>>>>>>>>>>> >>>>>>>>>>>> Perhaps: >>>>>>>>>>>> >>>>>>>>>>>> The PLR MUST conclude that the MP supports the >>>>>>>>>>>> refresh-interval independent FRR procedures defined in this >>>>>>>>>>>> document if the MP has set the I-bit in the CAPABILITY object >>>>>>>>>>>> [RFC8370] (carried in the Hello message) to correspond with the >>>>>>>>>>>> Node- ID-based Hello session. >>>>>>>>>>>> --> >>>>>>>>>>> >>>>>>>>>>> [CR] As the text above only applies to the I-bit in the >>>>>>>>>>> CAPABILITY object >>>>>>>>>> carried in the Hello message corresponding to the Node-ID based >>>>>>>>>> hello session, the following text will be the correct one. >>>>>>>>>>> >>>>>>>>>>> NEW: >>>>>>>>>>> >>>>>>>>>>> The PLR MUST conclude that the MP supports the refresh-interval >>>>>>>>>>> independent FRR procedures defined in this document if the MP >>>>>>>>>>> has set the I-bit in the CAPABILITY object [RFC8370] carried in >>>>>>>>>>> the Hello message corresponding to the Node- ID-based Hello >>>>>>>>>>> session. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 10) <!-- [rfced] FYI - There are a number of instances >>>>>>>>>>>> throughout the document where we have updated text to be >>>>>>>>>>>> formatted as a bulleted list to improve readability. >>>>>>>>>>>> Please review these instances and let us know of any objections. >>>>>>>>>>>> --> >>>>>>>>>>> >>>>>>>>>>> [CR] Most changes are good except for the ones listed below. >>>>>>>>>>> >>>>>>>>>>> (CR-i) Abstract >>>>>>>>>>> >>>>>>>>>>> OLD: Facility backup method allows one or more LSPs >>>>>>>>>>> PROPOSED: Facility backup methods allow one or more LSPs >>>>>>>>>>> >>>>>>>>>>> "Facility backup" is a mechanism defined by RFC 4090 and so >>>>>>>>>>> plural should >>>>>>>>>> not be used for that. >>>>>>>>>>> >>>>>>>>>>> OLD: The many-to-one nature of local repair technique >>>>>>>>>>> PROPOSED: The many-to-one nature of local repair techniques >>>>>>>>>>> >>>>>>>>>>> Same as the previous comment on "facility backup" method. >>>>>>>>>>> >>>>>>>>>>> OLD: timeout and hence make facility backup method >>>>>>>>>>> PROPOSED: timeout, hence, making facility backup methods >>>>>>>>>>> >>>>>>>>>>> It should be "facility backup method". >>>>>>>>>>> >>>>>>>>>>> (CR-ii) 4. Solution Aspects >>>>>>>>>>> >>>>>>>>>>> OLD: introduce PLR and MP procedures to establish Node-ID based >>>>>>>>>>> hello session between >>>>>>>>>>> PROPOSED: introduce PLR and MP procedures to establish >>>>>>>>>>> Node-ID-based Hello sessions between >>>>>>>>>>> >>>>>>>>>>> There will be only one node-id based Hello session between a PLR >>>>>>>>>>> and MP >>>>>>>>>> pair. >>>>>>>>>>> >>>>>>>>>>> (CR-iii) 4.4. Conditional PathTear >>>>>>>>>>> >>>>>>>>>>> OLD: >>>>>>>>>>> In the example provided in Section 4.3.3 of this document, B >>>>>>>>>>> deletes the PSB and RSB states corresponding to the LSP once B >>>>>>>>>>> detects its Phop link went down as B is not an MP. >>>>>>>>>>> >>>>>>>>>>> PROPOSED: >>>>>>>>>>> In the example provided in Section 4.3.3 of this document, B >>>>>>>>>>> deletes the PSB and RSB states corresponding to the LSP once B >>>>>>>>>>> detects its Phop link that went down as B is not an MP. >>>>>>>>>>> >>>>>>>>>>> Instead of adding "that", should the text be the following? >>>>>>>>>>> >>>>>>>>>>> CR-NEW: >>>>>>>>>>> In the example provided in Section 4.3.3 of this document, B >>>>>>>>>>> deletes the PSB and RSB states corresponding to the LSP once B >>>>>>>>>>> detects its Phop link has gone down as B is not an MP. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 11) <!-- [rfced] FYI - We have updated the text as follows to >>>>>>>>>>>> improve readability. >>>>>>>>>>>> Please let us know of any objections or if any further updates are >>>>> needed. >>>>>>>>>>>> >>>>>>>>>>>> Original: >>>>>>>>>>>> >>>>>>>>>>>> Now when A-B link fails, as B is not an MP and its Phop link has >>>>>>>>>>>> failed, B will delete the LSP state (this behavior is required >>>>>>>>>>>> for unprotected LSPs - refer to Section 4.3.1 of this document). >>>>>>>>>>>> >>>>>>>>>>>> Current: >>>>>>>>>>>> >>>>>>>>>>>> Now, when the A-B link fails, B will delete the LSP state, >>>>>>>>>>>> because B is not an MP and its Phop link has failed (this >>>>>>>>>>>> behavior is required for unprotected LSPs; refer to Section 4.3.1 >>>>>>>>>>>> of >>>>> this document). >>>>>>>>>>>> >>>>>>>>>>>> --> >>>>>>>>>>> >>>>>>>>>>> [CR] The authors are fine with the proposed text. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 12) <!-- [rfced] As all other fields are defined following >>>>>>>>>>>> Figure 2, should the Length field also have an entry? >>>>>>>>>>>> >>>>>>>>>>>> Current: >>>>>>>>>>>> 0 1 2 3 >>>>>>>>>>>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 >>>>>>>>>>>> 1 >>>>>>>>>>>> >>>>>>>>>>>> +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ >>>>>>>>>>>> --+--+--+--+-- >>>>>>>>>> +--+--+--+--+--+--+- >>>>>>>>>>>> | Length | Class | C-type | >>>>>>>>>>>> >>>>>>>>>>>> +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ >>>>>>>>>>>> --+--+--+--+-- >>>>>>>>>> +--+--+--+--+--+--+- >>>>>>>>>>>> | Flags (Reserved) |M| >>>>>>>>>>>> >>>>>>>>>>>> +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+-- >>>>>>>>>>>> +--+--+--+--+--+--+--+--+--+- >>>>>>>>>>>> >>>>>>>>>>>> Figure 2: CONDITIONS Object >>>>>>>>>>>> >>>>>>>>>>>> Class: 135 >>>>>>>>>>>> C-type: 1 >>>>>>>>>>>> Flags: 32 bit field >>>>>>>>>>>> M: Bit 31 is the Merge-point condition (M) bit. If the M bit >>>>>>>>>>>> is set to 1, then the PathTear message MUST be processed >>>>>>>>>>>> according to the receiver router role, i.e., if the receiving >>>>>>>>>>>> router is an MP or not for the LSP. If it is not set, then the >>>>>>>>>>>> PathTear message MUST be processed as a normal PathTear >>>>> message for the LSP. >>>>>>>>>>>> >>>>>>>>>>>> --> >>>>>>>>>>> >>>>>>>>>>> [CR] The authors are fine with the proposed text. Length need not >>>>>>>>>>> be >>>>>>>>>> explicitly defined because it is the same for all RSVP objects. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 13) <!-- [rfced] May we provide additional context or lead-in >>>>>>>>>>>> text for the list below? >>>>>>>>>>>> >>>>>>>>>>>> Original: >>>>>>>>>>>> >>>>>>>>>>>> Consider that B-C link goes down on the same example topology >>>>>>>>>>>> (Figure 1). As C is the NP-MP for the PLR A, C will retain LSP >>>>>>>>>>>> state. >>>>>>>>>>>> >>>>>>>>>>>> 1. The LSP is preempted on C. >>>>>>>>>>>> >>>>>>>>>>>> 2. C will delete the RSB state... >>>>>>>>>>>> >>>>>>>>>>>> Perhaps: >>>>>>>>>>>> >>>>>>>>>>>> Consider that the B-C link goes down on the same example >>>>>>>>>>>> topology (Figure 1). As C is the NP-MP for the PLR A, C will >>>>>>>>>>>> retain LSP state. This means: >>>>>>>>>>>> >>>>>>>>>>>> 1. The LSP is preempted on C. >>>>>>>>>>>> >>>>>>>>>>>> 2. C will delete the RSB state... >>>>>>>>>>>> >>>>>>>>>>>> --> >>>>>>>>>>> >>>>>>>>>>> [CR] The inclusion of "This means:" will not convey the intended >>>>>>>>>>> meaning >>>>>>>>>> here. The first paragraph starting with "If an LSP is preempted on >>>>>>>>>> an NP-MP after its Phop link..." specifies the behavior in general >>>>>>>>>> upon an event, and the rest of the Section 4.5.3.2 intends to >>>>>>>>>> convey what will happen in the event of preemption in a specific >>>>> condition. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 14) <!-- [rfced] To reflect usage in RFC 8370, may we update >>>>>>>>>>>> 'the flag "Refresh interval Independent RSVP" or RI-RSVP flag' >>>>>>>>>>>> below as >>>>>>>>>> follows? >>>>>>>>>>>> >>>>>>>>>>>> Original: >>>>>>>>>>>> >>>>>>>>>>>> An implementation supporting RI-RSVP-FRR extensions MUST set the >>>>>>>>>>>> flag "Refresh interval Independent RSVP" or RI-RSVP flag in the >>>>>>>>>>>> CAPABILITY object carried in Hello messages as specified in >>>>>>>>>>>> RSVP-TE Scaling Techniques [RFC8370]. >>>>>>>>>>>> >>>>>>>>>>>> Perhaps: >>>>>>>>>>>> >>>>>>>>>>>> An implementation supporting RI-RSVP-FRR extensions MUST set the >>>>>>>>>>>> RI- RSVP >>>>>>>>>>>> Capable flag in the CAPABILITY object carried in Hello messages >>>>>>>>>>>> as specified in RSVP-TE Scaling Techniques [RFC8370]. >>>>>>>>>>>> --> >>>>>>>>>>> >>>>>>>>>>> [CR] The authors are fine with the proposed text. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 15) <!-- [rfced] FYI - We have updated the following text to >>>>>>>>>>>> match similar introductory text from the previous section. >>>>>>>>>>>> >>>>>>>>>>>> Original: >>>>>>>>>>>> >>>>>>>>>>>> The procedures are as follows. >>>>>>>>>>>> >>>>>>>>>>>> Current: >>>>>>>>>>>> >>>>>>>>>>>> The procedures on the upstream direction are as follows: >>>>>>>>>>>> >>>>>>>>>>>> --> >>>>>>>>>>> >>>>>>>>>>> [CR] The authors are fine with the proposed text. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 16) <!-- [rfced] For clarity, may we update the text below as >>>>>>>>>>>> follows? >>>>>>>>>>>> >>>>>>>>>>>> Original: >>>>>>>>>>>> >>>>>>>>>>>> So, the implementations >>>>>>>>>>>> SHOULD provide the option to configure Node-ID neighbor specific >>>>>>>>>>>> or global authentication key to authentication messages received >>>>>>>>>>>> from Node-ID neighbors. >>>>>>>>>>>> >>>>>>>>>>>> Perhaps: >>>>>>>>>>>> >>>>>>>>>>>> Therefore, the implementations SHOULD provide the option to >>>>>>>>>>>> configure either a specific neighbor or global Node-ID >>>>>>>>>>>> authentication key to authentication messages received from >>>>>>>>>>>> Node-ID neighbors. >>>>>>>>>>>> >>>>>>>>>>>> --> >>>>>>>>>>> >>>>>>>>>>> [CR] The authors are fine with the proposed text. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 17) <!-- [rfced] Please review the following questions and >>>>>>>>>>>> changes regarding the terminology used in this document. >>>>>>>>>>>> >>>>>>>>>>>> a) We note some instances where "RSVP" is not included in >>>>>>>>>>>> "Refresh-Interval Independent FRR" (in the document title and >>>>>>>>>>>> elsewhere). For consistency, should "RSVP" be added to these >>>>> instances? >>>>>>>>>> Some examples are listed below. >>>>>>>>>>>> >>>>>>>>>>>> Original: >>>>>>>>>>>> 4.6.1. Detecting Support for Refresh interval Independent FRR >>>>>>>>>>>> ... >>>>>>>>>>>> "Refresh interval Independent FRR" or RI-RSVP-FRR refers to the >>>>>>>>>>>> set of procedures defined in this document to... >>>>>>>>>>>> >>>>>>>>>>>> Perhaps: >>>>>>>>>>>> 4.6.1. Detecting Support for Refresh-Interval Independent RSVP >>>>>>>>>>>> FRR ... >>>>>>>>>>>> "Refresh-Interval Independent RSVP FRR", or RI-RSVP-FRR, refers >>>>>>>>>>>> to the >>>>>>>>>> set >>>>>>>>>>>> of procedures defined in this document to... >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> [CR] The proposed changes look good with the proviso related to >>>>> "RSVP-TE" >>>>>>>>>> in place of RSVP (see the response to comment #1 earlier). >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> b) To parallel usage in RFC 4090, may we update the >>>>>>>>>>>> capitalization of the terms below throughout this document? >>>>>>>>>>>> >>>>>>>>>>>> Phop > PHOP >>>>>>>>>>>> PPhop > PPHOP >>>>>>>>>>>> Nhop > NHOP >>>>>>>>>>>> NNhop > NNHOP >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> [CR] The proposed changes above look good. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> c) To parallel usage in RFC 8796, may we update the >>>>>>>>>>>> capitalization of the terms below throughout this document? >>>>>>>>>>>> >>>>>>>>>>>> Association source > Association Source B-SFRR-Ready Extended >>>>>>>>>>>> Association object > B-SFRR-Ready Extended ASSOCIATION object >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> [CR] The proposed changes above look good. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> d) Should instances of "RRO object" and "LSP path" be updated to >>>>>>>>>>>> simply read "RRO" and "LSP" to avoid redundancy? If expanded, >>>>>>>>>>>> "RRO object" would read as "Record Route Object object" and "LSP >>>>> path" >>>>>>>>>>>> would read as "Label Switched Path path". Please review and let >>>>>>>>>>>> us know if any updates are needed. >>>>>>>>>>>> --> >>>>>>>>>>> >>>>>>>>>>> [CR] The proposed changes to "RRO object" and "LSP path" look >>>>>>>>>>> good >>>>>>>>>> except for the following text in Section 4.5.3.2. The word "path" >>>>>>>>>> in this text refers to the "path message" and not the "label switched >>>>> path". >>>>>>>>>>> >>>>>>>>>>> 4. B starts backup LSP signaling to D. But However, as D does not >>>>> have >>>>>>>>>>> the LSP state, it will reject the backup LSP Path and send a >>>>>>>>>>> PathErr to B. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 18) <!-- [rfced] Please review the "Inclusive Language" portion >>>>>>>>>>>> of the online Style Guide >>>>>>>>>>>> <https://urldefense.com/v3/__https://www.rfc- >>>>>>>>>>>> editor.org/styleguide/part2/*inclusive_language__;Iw!!NEt6yMaO- >>>>>>>>>>>> gk!FM2VL8WYKZ4l-zDnXFEMT1bMvVmTs- >>>>>>>>>>>> >>>>> E1_Al7pzTrypczYwOa9zufdnM4Qo4xmCWUhUKQDOal5wQIaaUoKz17HEE$ >>>>>>>>>>> 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. --> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> [CR] The authors have taken into consideration this aspect of the >>>>>>>>>>> language >>>>>>>>>> from the initial versions. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thank you. >>>>>>>>>>>> >>>>>>>>>>>> RFC Editor/kf/ap >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Dec 19, 2024, at 4:28 PM, rfc-edi...@rfc-editor.org wrote: >>>>>>>>>>>> >>>>>>>>>>>> *****IMPORTANT***** >>>>>>>>>>>> >>>>>>>>>>>> Updated 2024/12/19 >>>>>>>>>>>> >>>>>>>>>>>> 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://urldefense.com/v3/__https://www.rfc- >>>>>>>>>>>> editor.org/faq/__;!!NEt6yMaO-gk!FM2VL8WYKZ4l- >>>>> zDnXFEMT1bMvVmTs- >>>>>>>>>>>> E1_Al7pzTrypczYwOa9zufdnM4Qo4xmCWUhUKQDOal5wQIaaUo6- >>>>> bby7o$ >>>>>>>>>> ). >>>>>>>>>>>> >>>>>>>>>>>> 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 +IBM >>>>>>>>>>>> https://urldefense.com/v3/__https://trustee.ietf.org/license- >>>>>>>>>>>> info__;!!NEt6yMaO-gk!FM2VL8WYKZ4l-zDnXFEMT1bMvVmTs- >>>>>>>>>>>> >>>>> E1_Al7pzTrypczYwOa9zufdnM4Qo4xmCWUhUKQDOal5wQIaaUoFmg6l-Q$ >>>>>>>>>> ). >>>>>>>>>>>> >>>>>>>>>>>> * 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://urldefense.com/v3/__https://authors.ietf.org/rfcxml- >>>>>>>>>>>> vocabulary__;!!NEt6yMaO-gk!FM2VL8WYKZ4l- >>>>> zDnXFEMT1bMvVmTs- >>>>>>>>>>>> >>>>>>>>>> >>>>> E1_Al7pzTrypczYwOa9zufdnM4Qo4xmCWUhUKQDOal5wQIaaUoYWySWiY$ >>>>>>>>>>>>> . >>>>>>>>>>>> >>>>>>>>>>>> * 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 +IBg-REPLY >>>>>>>>>>>> ALL+IBk 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://urldefense.com/v3/__https://mailarchive.ietf.org/arch/ms >>>>>>>>>>>> g/iet >>>>>>>>>>>> f- >>>>>>>>>>>> announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc__;!!NEt6yMaO- >>>>>>>>>> gk!FM2VL8WYKZ4l- >>>>>>>>>>>> zDnXFEMT1bMvVmTs- >>>>>>>>>>>> >>>>> E1_Al7pzTrypczYwOa9zufdnM4Qo4xmCWUhUKQDOal5wQIaaUo4FQ8Jic$ >>>>>>>>>>>> >>>>>>>>>>>> * The archive itself: >>>>>>>>>>>> >>>>>>>>>>>> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/br >>>>>>>>>>>> owse/ >>>>>>>>>>>> auth48 >>>>>>>>>>>> archive/__;!!NEt6yMaO-gk!FM2VL8WYKZ4l-zDnXFEMT1bMvVmTs- >>>>>>>>>>>> >>>>> E1_Al7pzTrypczYwOa9zufdnM4Qo4xmCWUhUKQDOal5wQIaaUoRVSHF7c$ >>>>>>>>>>>> >>>>>>>>>>>> * 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 >>>>>>>>>>>> +IBQ OR +IBQ >>>>>>>>>>>> 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 >>>>>>>>>>>> +IBg-REPLY ALL+IBk, as all the parties CCed on this message need >>>>>>>>>>>> +to see >>>>>>>>>> your approval. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Files >>>>>>>>>>>> ----- >>>>>>>>>>>> >>>>>>>>>>>> The files are available here: >>>>>>>>>>>> https://urldefense.com/v3/__https://www.rfc- >>>>>>>>>>>> editor.org/authors/rfc9705.xml__;!!NEt6yMaO-gk!FM2VL8WYKZ4l- >>>>>>>>>>>> zDnXFEMT1bMvVmTs- >>>>>>>>>>>> >>>>>>>>>> >>>>> E1_Al7pzTrypczYwOa9zufdnM4Qo4xmCWUhUKQDOal5wQIaaUoSDoXJMg$ >>>>>>>>>>>> https://urldefense.com/v3/__https://www.rfc- >>>>>>>>>>>> editor.org/authors/rfc9705.html__;!!NEt6yMaO-gk!FM2VL8WYKZ4l- >>>>>>>>>>>> zDnXFEMT1bMvVmTs- >>>>>>>>>>>> >>>>>>>>>> >>>>> E1_Al7pzTrypczYwOa9zufdnM4Qo4xmCWUhUKQDOal5wQIaaUoWcC58ZM$ >>>>>>>>>>>> https://urldefense.com/v3/__https://www.rfc- >>>>>>>>>>>> editor.org/authors/rfc9705.pdf__;!!NEt6yMaO-gk!FM2VL8WYKZ4l- >>>>>>>>>>>> zDnXFEMT1bMvVmTs- >>>>>>>>>>>> >>>>>>>>>> >>>>> E1_Al7pzTrypczYwOa9zufdnM4Qo4xmCWUhUKQDOal5wQIaaUoVgwnY_M$ >>>>>>>>>>>> https://urldefense.com/v3/__https://www.rfc- >>>>>>>>>>>> editor.org/authors/rfc9705.txt__;!!NEt6yMaO-gk!FM2VL8WYKZ4l- >>>>>>>>>>>> zDnXFEMT1bMvVmTs- >>>>>>>>>>>> >>>>> E1_Al7pzTrypczYwOa9zufdnM4Qo4xmCWUhUKQDOal5wQIaaUocJFXiaA$ >>>>>>>>>>>> >>>>>>>>>>>> Diff file of the text: >>>>>>>>>>>> >>>>>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/r >>>>>>>>>>>> fc970 >>>>>>>>>>>> 5- >>>>>>>>>>>> diff.html__;!!NEt6yMaO-gk!FM2VL8WYKZ4l-zDnXFEMT1bMvVmTs- >>>>>>>>>>>> >>>>>>>>>> >>>>> E1_Al7pzTrypczYwOa9zufdnM4Qo4xmCWUhUKQDOal5wQIaaUoJUHhmJY$ >>>>>>>>>>>> >>>>>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/r >>>>>>>>>>>> fc970 >>>>>>>>>>>> 5- >>>>>>>>>>>> rfcdiff.html__;!!NEt6yMaO-gk!FM2VL8WYKZ4l-zDnXFEMT1bMvVmTs- >>>>>>>>>>>> >>>>> E1_Al7pzTrypczYwOa9zufdnM4Qo4xmCWUhUKQDOal5wQIaaUoLiVrrDQ$ >>>>>>>>>>>> (side by side) >>>>>>>>>>>> >>>>>>>>>>>> Diff of the XML: >>>>>>>>>>>> >>>>>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/r >>>>>>>>>>>> fc970 >>>>>>>>>>>> 5- >>>>>>>>>>>> xmldiff1.html__;!!NEt6yMaO-gk!FM2VL8WYKZ4l- >>>>> zDnXFEMT1bMvVmTs- >>>>>>>>>>>> >>>>> E1_Al7pzTrypczYwOa9zufdnM4Qo4xmCWUhUKQDOal5wQIaaUoHvtwQhI$ >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Tracking progress >>>>>>>>>>>> ----------------- >>>>>>>>>>>> >>>>>>>>>>>> The details of the AUTH48 status of your document are here: >>>>>>>>>>>> https://urldefense.com/v3/__https://www.rfc- >>>>>>>>>>>> editor.org/auth48/rfc9705__;!!NEt6yMaO-gk!FM2VL8WYKZ4l- >>>>>>>>>>>> zDnXFEMT1bMvVmTs- >>>>>>>>>>>> >>>>> E1_Al7pzTrypczYwOa9zufdnM4Qo4xmCWUhUKQDOal5wQIaaUoJm6CZos$ >>>>>>>>>>>> >>>>>>>>>>>> Please let us know if you have any questions. >>>>>>>>>>>> >>>>>>>>>>>> Thank you for your cooperation, >>>>>>>>>>>> >>>>>>>>>>>> RFC Editor >>>>>>>>>>>> >>>>>>>>>>>> -------------------------------------- >>>>>>>>>>>> RFC9705 (draft-ietf-mpls-ri-rsvp-frr-22) >>>>>>>>>>>> >>>>>>>>>>>> Title : Refresh-interval Independent FRR Facility >>>>>>>>>>>> Protection >>>>>>>>>>>> Author(s) : C. Ramachandran, T. Saad, I. Minei, D. Pacella >>>>>>>>>>>> WG Chair(s) : Nicolai Leymann, Tarek Saad, Tony Li >>>>>>>>>>>> >>>>>>>>>>>> Area Director(s) : Jim Guichard, John Scudder, Gunter Van de >>>>>>>>>>>> Velde >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >> > -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
