Hi Dante, Thank you for your reply. Your approval has been noted: https://www.rfc-editor.org/auth48/rfc9705
Once we receive Ina’s approval, we will move this document forward in the publication process. Best regards, RFC Editor/ap > On Feb 24, 2025, at 9:59 AM, Pacella, Dante J <dante.j.pace...@verizon.com> > wrote: > > Alanna & RFC Editors, > > Apologies for the delayed response. Yes, these changes make sense. > > Thanks, > Dante > > On Mon, Feb 24, 2025 at 12:17 PM Alanna Paloma <apal...@staff.rfc-editor.org> > wrote: > Hi Ina and Dante, > > We do not believe we have heard from you regarding this document's readiness > for publication. Please review the updated files and let us know if you have > any further changes. We will move this document forward in the publication > process once we’ve received your approvals. > > The files have been posted here (please refresh): > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_authors_rfc9705.xml&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=3v2kN75t0hArjqO2VR1eCG4np4n5qSg9k9G4alU6q8Q&m=a8lF4_RohpCnE70OPcI0rhdvGCDT-cM_sJTQ6XNRo8XKOE7idjsaV9ohS6kz4ZNh&s=Jymrj3LJ-qDZ3ssK01cS6_ibGzZKqhe8YzCsQDT0Yts&e= > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_authors_rfc9705.txt&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=3v2kN75t0hArjqO2VR1eCG4np4n5qSg9k9G4alU6q8Q&m=a8lF4_RohpCnE70OPcI0rhdvGCDT-cM_sJTQ6XNRo8XKOE7idjsaV9ohS6kz4ZNh&s=zHC1fAS-rxAFbr3xRNWcFuKaBLAyIO-kbS8YV7WM83Y&e= > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_authors_rfc9705.html&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=3v2kN75t0hArjqO2VR1eCG4np4n5qSg9k9G4alU6q8Q&m=a8lF4_RohpCnE70OPcI0rhdvGCDT-cM_sJTQ6XNRo8XKOE7idjsaV9ohS6kz4ZNh&s=qthP23aytGYwk931_WH3IvTUAIlYXsBGXpHlIBgMgT8&e= > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_authors_rfc9705.pdf&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=3v2kN75t0hArjqO2VR1eCG4np4n5qSg9k9G4alU6q8Q&m=a8lF4_RohpCnE70OPcI0rhdvGCDT-cM_sJTQ6XNRo8XKOE7idjsaV9ohS6kz4ZNh&s=tMt0celMrF7zwR07VtGkt8ZBFUz7F4MGii9tCkbwaU8&e= > > The relevant diff files have been posted here: > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_authors_rfc9705-2Ddiff.html&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=3v2kN75t0hArjqO2VR1eCG4np4n5qSg9k9G4alU6q8Q&m=a8lF4_RohpCnE70OPcI0rhdvGCDT-cM_sJTQ6XNRo8XKOE7idjsaV9ohS6kz4ZNh&s=s2Gi-1EUn3NXHQUrOt2FSkq6Pepog0Hww4WHuZZn1aQ&e= > (comprehensive diff) > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_authors_rfc9705-2Dauth48diff.html&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=3v2kN75t0hArjqO2VR1eCG4np4n5qSg9k9G4alU6q8Q&m=a8lF4_RohpCnE70OPcI0rhdvGCDT-cM_sJTQ6XNRo8XKOE7idjsaV9ohS6kz4ZNh&s=UrbuTzsrVfwz4tKCU982dqNC0pp0owYw8uTjmYThsGg&e= > (AUTH48 changes) > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_authors_rfc9705-2Dlastdiff.html&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=3v2kN75t0hArjqO2VR1eCG4np4n5qSg9k9G4alU6q8Q&m=a8lF4_RohpCnE70OPcI0rhdvGCDT-cM_sJTQ6XNRo8XKOE7idjsaV9ohS6kz4ZNh&s=rWufTc_dsj3oXMHvuZhLqYgxLhxfGeoWWJJgZMWCrVo&e= > (htmlwdiff diff between last version and this) > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_authors_rfc9705-2Dlastrfcdiff.html&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=3v2kN75t0hArjqO2VR1eCG4np4n5qSg9k9G4alU6q8Q&m=a8lF4_RohpCnE70OPcI0rhdvGCDT-cM_sJTQ6XNRo8XKOE7idjsaV9ohS6kz4ZNh&s=jKVvt__4GnyHVlGXeTf6TQRcfw5PTGBYyP9AtFhWXlI&e= > (rfcdiff between last version and this) > > For the AUTH48 status of this document, please see: > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_auth48_rfc9705&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=3v2kN75t0hArjqO2VR1eCG4np4n5qSg9k9G4alU6q8Q&m=a8lF4_RohpCnE70OPcI0rhdvGCDT-cM_sJTQ6XNRo8XKOE7idjsaV9ohS6kz4ZNh&s=L8soeMa11uoChko091Pt15hsRfCbwDyzsSucND97P3I&e= > > Best regards, > RFC Editor/ap > > > On Feb 18, 2025, at 8:36 AM, Alanna Paloma <apal...@staff.rfc-editor.org> > > wrote: > > > > Hi Ina and Dante, > > > > This is another friendly reminder that we await your reviews and approvals > > of the updated files. > > > > The files have been posted here (please refresh): > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_authors_rfc9705.xml&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=3v2kN75t0hArjqO2VR1eCG4np4n5qSg9k9G4alU6q8Q&m=a8lF4_RohpCnE70OPcI0rhdvGCDT-cM_sJTQ6XNRo8XKOE7idjsaV9ohS6kz4ZNh&s=Jymrj3LJ-qDZ3ssK01cS6_ibGzZKqhe8YzCsQDT0Yts&e= > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_authors_rfc9705.txt&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=3v2kN75t0hArjqO2VR1eCG4np4n5qSg9k9G4alU6q8Q&m=a8lF4_RohpCnE70OPcI0rhdvGCDT-cM_sJTQ6XNRo8XKOE7idjsaV9ohS6kz4ZNh&s=zHC1fAS-rxAFbr3xRNWcFuKaBLAyIO-kbS8YV7WM83Y&e= > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_authors_rfc9705.html&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=3v2kN75t0hArjqO2VR1eCG4np4n5qSg9k9G4alU6q8Q&m=a8lF4_RohpCnE70OPcI0rhdvGCDT-cM_sJTQ6XNRo8XKOE7idjsaV9ohS6kz4ZNh&s=qthP23aytGYwk931_WH3IvTUAIlYXsBGXpHlIBgMgT8&e= > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_authors_rfc9705.pdf&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=3v2kN75t0hArjqO2VR1eCG4np4n5qSg9k9G4alU6q8Q&m=a8lF4_RohpCnE70OPcI0rhdvGCDT-cM_sJTQ6XNRo8XKOE7idjsaV9ohS6kz4ZNh&s=tMt0celMrF7zwR07VtGkt8ZBFUz7F4MGii9tCkbwaU8&e= > > > > The relevant diff files have been posted here: > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_authors_rfc9705-2Ddiff.html&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=3v2kN75t0hArjqO2VR1eCG4np4n5qSg9k9G4alU6q8Q&m=a8lF4_RohpCnE70OPcI0rhdvGCDT-cM_sJTQ6XNRo8XKOE7idjsaV9ohS6kz4ZNh&s=s2Gi-1EUn3NXHQUrOt2FSkq6Pepog0Hww4WHuZZn1aQ&e= > > (comprehensive diff) > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_authors_rfc9705-2Dauth48diff.html&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=3v2kN75t0hArjqO2VR1eCG4np4n5qSg9k9G4alU6q8Q&m=a8lF4_RohpCnE70OPcI0rhdvGCDT-cM_sJTQ6XNRo8XKOE7idjsaV9ohS6kz4ZNh&s=UrbuTzsrVfwz4tKCU982dqNC0pp0owYw8uTjmYThsGg&e= > > (AUTH48 changes) > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_authors_rfc9705-2Dlastdiff.html&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=3v2kN75t0hArjqO2VR1eCG4np4n5qSg9k9G4alU6q8Q&m=a8lF4_RohpCnE70OPcI0rhdvGCDT-cM_sJTQ6XNRo8XKOE7idjsaV9ohS6kz4ZNh&s=rWufTc_dsj3oXMHvuZhLqYgxLhxfGeoWWJJgZMWCrVo&e= > > (htmlwdiff diff between last version and this) > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_authors_rfc9705-2Dlastrfcdiff.html&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=3v2kN75t0hArjqO2VR1eCG4np4n5qSg9k9G4alU6q8Q&m=a8lF4_RohpCnE70OPcI0rhdvGCDT-cM_sJTQ6XNRo8XKOE7idjsaV9ohS6kz4ZNh&s=jKVvt__4GnyHVlGXeTf6TQRcfw5PTGBYyP9AtFhWXlI&e= > > (rfcdiff between last version and this) > > > > For the AUTH48 status of this document, please see: > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_auth48_rfc9705&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=3v2kN75t0hArjqO2VR1eCG4np4n5qSg9k9G4alU6q8Q&m=a8lF4_RohpCnE70OPcI0rhdvGCDT-cM_sJTQ6XNRo8XKOE7idjsaV9ohS6kz4ZNh&s=L8soeMa11uoChko091Pt15hsRfCbwDyzsSucND97P3I&e= > > > > Best regards, > > RFC Editor/ap > > > >> On Feb 10, 2025, at 8:52 AM, Alanna Paloma <apal...@staff.rfc-editor.org> > >> wrote: > >> > >> Hi Ina and Dante, > >> > >> This is a friendly reminder that we await your reviews and approvals of > >> the updated files. > >> > >> The files have been posted here (please refresh): > >> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_authors_rfc9705.xml&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=3v2kN75t0hArjqO2VR1eCG4np4n5qSg9k9G4alU6q8Q&m=a8lF4_RohpCnE70OPcI0rhdvGCDT-cM_sJTQ6XNRo8XKOE7idjsaV9ohS6kz4ZNh&s=Jymrj3LJ-qDZ3ssK01cS6_ibGzZKqhe8YzCsQDT0Yts&e= > >> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_authors_rfc9705.txt&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=3v2kN75t0hArjqO2VR1eCG4np4n5qSg9k9G4alU6q8Q&m=a8lF4_RohpCnE70OPcI0rhdvGCDT-cM_sJTQ6XNRo8XKOE7idjsaV9ohS6kz4ZNh&s=zHC1fAS-rxAFbr3xRNWcFuKaBLAyIO-kbS8YV7WM83Y&e= > >> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_authors_rfc9705.html&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=3v2kN75t0hArjqO2VR1eCG4np4n5qSg9k9G4alU6q8Q&m=a8lF4_RohpCnE70OPcI0rhdvGCDT-cM_sJTQ6XNRo8XKOE7idjsaV9ohS6kz4ZNh&s=qthP23aytGYwk931_WH3IvTUAIlYXsBGXpHlIBgMgT8&e= > >> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_authors_rfc9705.pdf&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=3v2kN75t0hArjqO2VR1eCG4np4n5qSg9k9G4alU6q8Q&m=a8lF4_RohpCnE70OPcI0rhdvGCDT-cM_sJTQ6XNRo8XKOE7idjsaV9ohS6kz4ZNh&s=tMt0celMrF7zwR07VtGkt8ZBFUz7F4MGii9tCkbwaU8&e= > >> > >> The relevant diff files have been posted here: > >> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_authors_rfc9705-2Ddiff.html&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=3v2kN75t0hArjqO2VR1eCG4np4n5qSg9k9G4alU6q8Q&m=a8lF4_RohpCnE70OPcI0rhdvGCDT-cM_sJTQ6XNRo8XKOE7idjsaV9ohS6kz4ZNh&s=s2Gi-1EUn3NXHQUrOt2FSkq6Pepog0Hww4WHuZZn1aQ&e= > >> (comprehensive diff) > >> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_authors_rfc9705-2Dauth48diff.html&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=3v2kN75t0hArjqO2VR1eCG4np4n5qSg9k9G4alU6q8Q&m=a8lF4_RohpCnE70OPcI0rhdvGCDT-cM_sJTQ6XNRo8XKOE7idjsaV9ohS6kz4ZNh&s=UrbuTzsrVfwz4tKCU982dqNC0pp0owYw8uTjmYThsGg&e= > >> (AUTH48 changes) > >> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_authors_rfc9705-2Dlastdiff.html&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=3v2kN75t0hArjqO2VR1eCG4np4n5qSg9k9G4alU6q8Q&m=a8lF4_RohpCnE70OPcI0rhdvGCDT-cM_sJTQ6XNRo8XKOE7idjsaV9ohS6kz4ZNh&s=rWufTc_dsj3oXMHvuZhLqYgxLhxfGeoWWJJgZMWCrVo&e= > >> (htmlwdiff diff between last version and this) > >> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_authors_rfc9705-2Dlastrfcdiff.html&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=3v2kN75t0hArjqO2VR1eCG4np4n5qSg9k9G4alU6q8Q&m=a8lF4_RohpCnE70OPcI0rhdvGCDT-cM_sJTQ6XNRo8XKOE7idjsaV9ohS6kz4ZNh&s=jKVvt__4GnyHVlGXeTf6TQRcfw5PTGBYyP9AtFhWXlI&e= > >> (rfcdiff between last version and this) > >> > >> For the AUTH48 status of this document, please see: > >> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_auth48_rfc9705&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=3v2kN75t0hArjqO2VR1eCG4np4n5qSg9k9G4alU6q8Q&m=a8lF4_RohpCnE70OPcI0rhdvGCDT-cM_sJTQ6XNRo8XKOE7idjsaV9ohS6kz4ZNh&s=L8soeMa11uoChko091Pt15hsRfCbwDyzsSucND97P3I&e= > >> > >> Best regards, > >> RFC Editor/ap > >> > >>> On Feb 3, 2025, at 10:21 AM, Alanna Paloma <apal...@staff.rfc-editor.org> > >>> wrote: > >>> > >>> Hi Tarek, > >>> > >>> Thank you for your approval. It has been noted on the AUTH48 status page: > >>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_auth48_rfc9705&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=3v2kN75t0hArjqO2VR1eCG4np4n5qSg9k9G4alU6q8Q&m=a8lF4_RohpCnE70OPcI0rhdvGCDT-cM_sJTQ6XNRo8XKOE7idjsaV9ohS6kz4ZNh&s=L8soeMa11uoChko091Pt15hsRfCbwDyzsSucND97P3I&e= > >>> > >>> Best regards, > >>> RFC Editor/ap > >>> > >>>> On Feb 1, 2025, at 7:16 PM, Tarek Saad <tsaad....@gmail.com> wrote: > >>>> > >>>> Hi Alanna, > >>>> Thanks for the suggested edits to the document. I’ve gone through the > >>>> diff and I’m ok with the latest version of the document. > >>>> Regards, > >>>> Tarek > >>>> From: Alanna Paloma <apal...@staff.rfc-editor.org> > >>>> Date: Thursday, January 30, 2025 at 4:25 PM > >>>> To: Chandrasekar Ramachandran <cse...@juniper.net> > >>>> Cc: ts...@cisco.com <ts...@cisco.com>, inami...@google.com > >>>> <inami...@google.com>, > >>>> dante.j.pace...@verizon.com<dante.j.pace...@verizon.com>, > >>>> rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org>, mpls-...@ietf.org > >>>> <mpls-...@ietf.org>, mpls-cha...@ietf.org <mpls-cha...@ietf.org>, > >>>> n.leym...@telekom.de <n.leym...@telekom.de>, > >>>> james.n.guich...@futurewei.com<james.n.guich...@futurewei.com>, > >>>> auth48archive@rfc-editor.org <auth48archive@rfc-editor.org> > >>>> Subject: Re: AUTH48: RFC-to-be 9705 <draft-ietf-mpls-ri-rsvp-frr-22> for > >>>> your review > >>>> Hi Chandra, > >>>> > >>>> Thank you for your reply. We have updated the files accordingly and > >>>> noted your approval on the AUTH48 status page: > >>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_auth48_rfc9705&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=3v2kN75t0hArjqO2VR1eCG4np4n5qSg9k9G4alU6q8Q&m=a8lF4_RohpCnE70OPcI0rhdvGCDT-cM_sJTQ6XNRo8XKOE7idjsaV9ohS6kz4ZNh&s=L8soeMa11uoChko091Pt15hsRfCbwDyzsSucND97P3I&e= > >>>> > >>>> 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://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_authors_rfc9705.xml&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=3v2kN75t0hArjqO2VR1eCG4np4n5qSg9k9G4alU6q8Q&m=a8lF4_RohpCnE70OPcI0rhdvGCDT-cM_sJTQ6XNRo8XKOE7idjsaV9ohS6kz4ZNh&s=Jymrj3LJ-qDZ3ssK01cS6_ibGzZKqhe8YzCsQDT0Yts&e= > >>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_authors_rfc9705.txt&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=3v2kN75t0hArjqO2VR1eCG4np4n5qSg9k9G4alU6q8Q&m=a8lF4_RohpCnE70OPcI0rhdvGCDT-cM_sJTQ6XNRo8XKOE7idjsaV9ohS6kz4ZNh&s=zHC1fAS-rxAFbr3xRNWcFuKaBLAyIO-kbS8YV7WM83Y&e= > >>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_authors_rfc9705.html&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=3v2kN75t0hArjqO2VR1eCG4np4n5qSg9k9G4alU6q8Q&m=a8lF4_RohpCnE70OPcI0rhdvGCDT-cM_sJTQ6XNRo8XKOE7idjsaV9ohS6kz4ZNh&s=qthP23aytGYwk931_WH3IvTUAIlYXsBGXpHlIBgMgT8&e= > >>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_authors_rfc9705.pdf&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=3v2kN75t0hArjqO2VR1eCG4np4n5qSg9k9G4alU6q8Q&m=a8lF4_RohpCnE70OPcI0rhdvGCDT-cM_sJTQ6XNRo8XKOE7idjsaV9ohS6kz4ZNh&s=tMt0celMrF7zwR07VtGkt8ZBFUz7F4MGii9tCkbwaU8&e= > >>>> > >>>> The relevant diff files have been posted here: > >>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_authors_rfc9705-2Ddiff.html&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=3v2kN75t0hArjqO2VR1eCG4np4n5qSg9k9G4alU6q8Q&m=a8lF4_RohpCnE70OPcI0rhdvGCDT-cM_sJTQ6XNRo8XKOE7idjsaV9ohS6kz4ZNh&s=s2Gi-1EUn3NXHQUrOt2FSkq6Pepog0Hww4WHuZZn1aQ&e= > >>>> (comprehensive diff) > >>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_authors_rfc9705-2Dauth48diff.html&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=3v2kN75t0hArjqO2VR1eCG4np4n5qSg9k9G4alU6q8Q&m=a8lF4_RohpCnE70OPcI0rhdvGCDT-cM_sJTQ6XNRo8XKOE7idjsaV9ohS6kz4ZNh&s=UrbuTzsrVfwz4tKCU982dqNC0pp0owYw8uTjmYThsGg&e= > >>>> (AUTH48 changes) > >>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_authors_rfc9705-2Dlastdiff.html&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=3v2kN75t0hArjqO2VR1eCG4np4n5qSg9k9G4alU6q8Q&m=a8lF4_RohpCnE70OPcI0rhdvGCDT-cM_sJTQ6XNRo8XKOE7idjsaV9ohS6kz4ZNh&s=rWufTc_dsj3oXMHvuZhLqYgxLhxfGeoWWJJgZMWCrVo&e= > >>>> (htmlwdiff diff between last version and this) > >>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_authors_rfc9705-2Dlastrfcdiff.html&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=3v2kN75t0hArjqO2VR1eCG4np4n5qSg9k9G4alU6q8Q&m=a8lF4_RohpCnE70OPcI0rhdvGCDT-cM_sJTQ6XNRo8XKOE7idjsaV9ohS6kz4ZNh&s=jKVvt__4GnyHVlGXeTf6TQRcfw5PTGBYyP9AtFhWXlI&e= > >>>> (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
