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
