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
