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 <[email protected]> > Sent: Tuesday, January 7, 2025 6:01 AM > To: Chandrasekar Ramachandran <[email protected]> > Cc: [email protected]; [email protected]; [email protected]; > [email protected]; [email protected]; [email protected]; > [email protected]; [email protected]; > [email protected] > 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 > <[email protected]> wrote: > > > > Please find our responses inline. > > > > Thanks, > > Chandra. > > > > > > Juniper Business Use Only > >> -----Original Message----- > >> From: [email protected] <[email protected]> > >> Sent: Friday, December 20, 2024 6:19 AM > >> To: Chandrasekar Ramachandran <[email protected]>; > [email protected]; > >> [email protected]; [email protected] > >> Cc: [email protected]; [email protected]; > >> [email protected]; [email protected]; > >> [email protected]; [email protected] > >> 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, [email protected] 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 > >> > >> * [email protected] (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). > >> > >> * [email protected], 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, > >> [email protected] 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 -- [email protected] To unsubscribe send an email to [email protected]
