Hi Chandra, The files have been updated per your request.
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) 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/rfc9705- >> diff.html__;!!NEt6yMaO-gk!Ffb5OXElFZyT8k54wSdXaSSIZVB4koLrq4- >> gSHhCAQNrB5_iTsKfND9wzggggVyJzUI4xyO6Km9sTg$ (comprehensive diff) >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9705- >> 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/msg/iet >>>> f- >>>> announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc__;!!NEt6yMaO- >> gk!FM2VL8WYKZ4l- >>>> zDnXFEMT1bMvVmTs- >>>> E1_Al7pzTrypczYwOa9zufdnM4Qo4xmCWUhUKQDOal5wQIaaUo4FQ8Jic$ >>>> >>>> * The archive itself: >>>> >>>> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/browse/ >>>> 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/rfc970 >>>> 5- >>>> diff.html__;!!NEt6yMaO-gk!FM2VL8WYKZ4l-zDnXFEMT1bMvVmTs- >>>> >> E1_Al7pzTrypczYwOa9zufdnM4Qo4xmCWUhUKQDOal5wQIaaUoJUHhmJY$ >>>> >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc970 >>>> 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/rfc970 >>>> 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
