Hi Tony, Thank you for your quick reply! We will continue with the process at this time.
Thank you, RFC Editor/sg > On Mar 25, 2025, at 2:12 PM, Antoni Przygienda <p...@juniper.net> wrote: > > Sandy, yes,, no problem. We can go ahead like this > > > > • Tony > > > > Juniper Business Use Only > > From: Sandy Ginoza <sgin...@staff.rfc-editor.org> > Date: Tuesday, 25 March 2025 at 21:02 > To: Antoni Przygienda <p...@juniper.net> > Cc: Pascal Thubert <pascal.thub...@gmail.com>, Jordan Head > <jh...@juniper.net>, Alanna Paloma <apal...@staff.rfc-editor.org>, Dmitry > Afanasiev <dmitry.afanas...@gmail.com>, Alankar Sharma <as3...@gmail.com>, > brunorijs...@gmail.com <brunorijs...@gmail.com>, > james.n.guich...@futurewei.com <james.n.guich...@futurewei.com>, Dmitry > Afanasiev <f...@yandex-team.ru>, RFC Editor <rfc-edi...@rfc-editor.org>, > rift-...@ietf.org <rift-...@ietf.org>, rift-cha...@ietf.org > <rift-cha...@ietf.org>, ext-zhang.zh...@zte.com.cn <zhang.zh...@zte.com.cn>, > auth48archive@rfc-editor.org <auth48archive@rfc-editor.org> > Subject: Question about table 19 - Re: AUTH48: RFC-to-be 9692 > <draft-ietf-rift-rift-24> for your review > > [External Email. Be cautious of content] > > > Authors, > > As we prepare this RFC for publication, we note that table 19 extends 6 > characters beyond the 69 character limit for tables. We have removed the > Comments column and added explanatory text, as was done in other sections. > Please review. > > The updated files: > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9692.xml__;!!NEt6yMaO-gk!Er7eACFRULaakmqG5anPImfY8vlCnHCMXjkgB5NpShgz8yFYJdI6xHDrQmFu352NLJlQBIKqH_7Cg96U8SKJd4U$ > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9692.txt__;!!NEt6yMaO-gk!Er7eACFRULaakmqG5anPImfY8vlCnHCMXjkgB5NpShgz8yFYJdI6xHDrQmFu352NLJlQBIKqH_7Cg96U3PrSQ3o$ > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9692.pdf__;!!NEt6yMaO-gk!Er7eACFRULaakmqG5anPImfY8vlCnHCMXjkgB5NpShgz8yFYJdI6xHDrQmFu352NLJlQBIKqH_7Cg96U-eC8oCE$ > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9692.html__;!!NEt6yMaO-gk!Er7eACFRULaakmqG5anPImfY8vlCnHCMXjkgB5NpShgz8yFYJdI6xHDrQmFu352NLJlQBIKqH_7Cg96UPW3psYw$ > > Please note that we will wait for at least one author acknowledgement that > the update was reviewed and there are no objections before we continue with > publication. > > Thank you, > RFC Editor/sg > > > > > On Mar 18, 2025, at 7:42 AM, Antoni Przygienda > > <prz=40juniper....@dmarc.ietf.org> wrote: > > > > No objection > > > > > > Juniper Business Use Only > > > > From: Pascal Thubert <pascal.thub...@gmail.com> > > Date: Tuesday, 18 March 2025 at 14:02 > > To: Jordan Head <jh...@juniper.net> > > Cc: Alanna Paloma <apal...@staff.rfc-editor.org>, Dmitry Afanasiev > > <dmitry.afanas...@gmail.com>, Antoni Przygienda <p...@juniper.net>, Alankar > > Sharma <as3...@gmail.com>, brunorijs...@gmail.com <brunorijs...@gmail.com>, > > james.n.guich...@futurewei.com<james.n.guich...@futurewei.com>, Dmitry > > Afanasiev <f...@yandex-team.ru>, rfc-edi...@rfc-editor.org > > <rfc-edi...@rfc-editor.org>, rift-...@ietf.org <rift-...@ietf.org>, > > rift-cha...@ietf.org <rift-cha...@ietf.org>, ext-zhang.zh...@zte.com.cn > > <zhang.zh...@zte.com.cn>, auth48archive@rfc-editor.org > > <auth48archive@rfc-editor.org> > > Subject: Re: AUTH48: RFC-to-be 9692 <draft-ietf-rift-rift-24> for your > > review > > > > [External Email. Be cautious of content] > > > > > > No objection! > > > > A bientôt; > > > > Pascal > > > > > Le 18 mars 2025 à 13:19, Jordan Head <jh...@juniper.net> a écrit : > > > > > > No objections. > > > > > > Sent from my iPhone > > > > > >> On Mar 18, 2025, at 6:58 AM, Alanna Paloma > > >> <apal...@staff.rfc-editor.org> wrote: > > >> > > >> [External Email. Be cautious of content] > > >> > > >> > > >> All, > > >> > > >> As Dmitry indicated he reviewed the document and sent his approval, we > > >> have added him back as an author. At this time, we would appreciate a > > >> positive confirmation from at least one other author indicating that > > >> there are no objections. We will then continue with publication of this > > >> document. > > >> > > >> The files have been posted here (please refresh): > > >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9692.xml__;!!NEt6yMaO-gk!FNfyV_0hpRiMiCkexflzoGZ7vJTncV6M3s19YXPDA5Y81zFwfy6-0jdfFtayzB2NNVJgS6UJEAPI5zbSHREJpCYe$ > > >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9692.txt__;!!NEt6yMaO-gk!FNfyV_0hpRiMiCkexflzoGZ7vJTncV6M3s19YXPDA5Y81zFwfy6-0jdfFtayzB2NNVJgS6UJEAPI5zbSHY1TWMEh$ > > >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9692.html__;!!NEt6yMaO-gk!FNfyV_0hpRiMiCkexflzoGZ7vJTncV6M3s19YXPDA5Y81zFwfy6-0jdfFtayzB2NNVJgS6UJEAPI5zbSHS_qwy0M$ > > >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9692.pdf__;!!NEt6yMaO-gk!FNfyV_0hpRiMiCkexflzoGZ7vJTncV6M3s19YXPDA5Y81zFwfy6-0jdfFtayzB2NNVJgS6UJEAPI5zbSHTscTKzo$ > > >> > > >> The relevant diff files have been posted here: > > >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9692-diff.html__;!!NEt6yMaO-gk!FNfyV_0hpRiMiCkexflzoGZ7vJTncV6M3s19YXPDA5Y81zFwfy6-0jdfFtayzB2NNVJgS6UJEAPI5zbSHWyoNpK4$ > > >> (comprehensive diff) > > >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9692-auth48diff.html__;!!NEt6yMaO-gk!FNfyV_0hpRiMiCkexflzoGZ7vJTncV6M3s19YXPDA5Y81zFwfy6-0jdfFtayzB2NNVJgS6UJEAPI5zbSHSTST5on$ > > >> (AUTH48 changes) > > >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9692-lastdiff.html__;!!NEt6yMaO-gk!FNfyV_0hpRiMiCkexflzoGZ7vJTncV6M3s19YXPDA5Y81zFwfy6-0jdfFtayzB2NNVJgS6UJEAPI5zbSHZB8TqJ-$ > > >> (htmlwdiff diff between last version and this) > > >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9692-lastrfcdiff.html__;!!NEt6yMaO-gk!FNfyV_0hpRiMiCkexflzoGZ7vJTncV6M3s19YXPDA5Y81zFwfy6-0jdfFtayzB2NNVJgS6UJEAPI5zbSHYNL0Ijy$ > > >> (rfcdiff between last version and this) > > >> > > >> Best regards, > > >> RFC Editor/ap > > >> > > >>>> On Mar 18, 2025, at 11:20 AM, Dmitry Afanasiev > > >>>> <dmitry.afanas...@gmail.com> wrote: > > >>> > > >>> Hi All, > > >>> went through the document once again, I think it's good to go. > > >>> > > >>> Best regards, > > >>> Dmitry > > >>> > > >>>> On Tue, Mar 11, 2025 at 9:51 AM Alanna Paloma > > >>>> <apal...@staff.rfc-editor.org> wrote: > > >>> Hi Authors and Jim (AD), > > >>> > > >>> Authors - We have not yet heard from Dmitry Afanasiev. Do you have > > >>> updated contact information you can share? > > >>> > > >>> Jim - As this document has been in AUTH48 since December 2024 and the > > >>> remaining coauthors have already approved the RFC for publication, > > >>> please consider whether you would like to approve in place of Dmitry . > > >>> See the RFC Editor FAQ for more information regarding missing authors > > >>> <https://urldefense.com/v3/__https://www.rfc-editor.org/faq/*missingauthor__;Iw!!NEt6yMaO-gk!FNfyV_0hpRiMiCkexflzoGZ7vJTncV6M3s19YXPDA5Y81zFwfy6-0jdfFtayzB2NNVJgS6UJEAPI5zbSHYIMQg2_$ > > >>> >. > > >>> > > >>> Best regards, > > >>> RFC Editor/ap > > >>> > > >>>>> On Mar 5, 2025, at 12:53 PM, Alanna Paloma > > >>>>> <apal...@staff.rfc-editor.org> wrote: > > >>>> > > >>>> Hi Tony, > > >>>> > > >>>> Thank you for your review and reply. The files have been updated > > >>>> accordingly, and we have noted your approval. > > >>>> > > >>>> FYI - To reflect your suggested update to similar text, we have also > > >>>> updated the text below. Please let us know of any objections. > > >>>> > > >>>> Previous: > > >>>> then CLEANUP, PUSH UpdateZTPOffer, and PUSH UnacceptableHeader, > > >>>> > > >>>> Current: > > >>>> then CLEANUP, then PUSH UpdateZTPOffer, then PUSH UnacceptableHeader, > > >>>> > > >>>> > > >>>> Once we receive Dmitry’s approval, we will ask IANA to update their > > >>>> registry accordingly. After the IANA updates are complete, we will > > >>>> move forward with the publication process. > > >>>> ... > > >>>> The files have been posted here (please refresh): > > >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9692.xml__;!!NEt6yMaO-gk!FNfyV_0hpRiMiCkexflzoGZ7vJTncV6M3s19YXPDA5Y81zFwfy6-0jdfFtayzB2NNVJgS6UJEAPI5zbSHREJpCYe$ > > >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9692.txt__;!!NEt6yMaO-gk!FNfyV_0hpRiMiCkexflzoGZ7vJTncV6M3s19YXPDA5Y81zFwfy6-0jdfFtayzB2NNVJgS6UJEAPI5zbSHY1TWMEh$ > > >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9692.html__;!!NEt6yMaO-gk!FNfyV_0hpRiMiCkexflzoGZ7vJTncV6M3s19YXPDA5Y81zFwfy6-0jdfFtayzB2NNVJgS6UJEAPI5zbSHS_qwy0M$ > > >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9692.pdf__;!!NEt6yMaO-gk!FNfyV_0hpRiMiCkexflzoGZ7vJTncV6M3s19YXPDA5Y81zFwfy6-0jdfFtayzB2NNVJgS6UJEAPI5zbSHTscTKzo$ > > >>>> > > >>>> The relevant diff files have been posted here: > > >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9692-diff.html__;!!NEt6yMaO-gk!FNfyV_0hpRiMiCkexflzoGZ7vJTncV6M3s19YXPDA5Y81zFwfy6-0jdfFtayzB2NNVJgS6UJEAPI5zbSHWyoNpK4$ > > >>>> (comprehensive diff) > > >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9692-auth48diff.html__;!!NEt6yMaO-gk!FNfyV_0hpRiMiCkexflzoGZ7vJTncV6M3s19YXPDA5Y81zFwfy6-0jdfFtayzB2NNVJgS6UJEAPI5zbSHSTST5on$ > > >>>> (AUTH48 changes) > > >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9692-lastdiff.html__;!!NEt6yMaO-gk!FNfyV_0hpRiMiCkexflzoGZ7vJTncV6M3s19YXPDA5Y81zFwfy6-0jdfFtayzB2NNVJgS6UJEAPI5zbSHZB8TqJ-$ > > >>>> (htmlwdiff diff between last version and this) > > >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9692-lastrfcdiff.html__;!!NEt6yMaO-gk!FNfyV_0hpRiMiCkexflzoGZ7vJTncV6M3s19YXPDA5Y81zFwfy6-0jdfFtayzB2NNVJgS6UJEAPI5zbSHYNL0Ijy$ > > >>>> (rfcdiff between last version and this) > > >>>> > > >>>> Best regards, > > >>>> RFC Editor/ap > > >>>> > > >>>>> On Mar 5, 2025, at 10:19 AM, Antoni Przygienda <p...@juniper.net> > > >>>>> wrote: > > >>>>> > > >>>>> Review from my side done (sorry for the time it took). > > >>>>> Observations from my side > > >>>>> > > >>>>> 1. IMPORTANT > > >>>>> A natural number without the unit associated with two entities. > > >>>>> Does not sound right. Unit is NOT defined, so AFAIS it’s an “a” as in > > >>>>> indefinite article Also, it’s “associated with a single entity” and > > >>>>> not two. > > >>>>> • This changes the sense of the sentence, please revert > > >>>>> and its state further, conditions may be checked > > >>>>> It is not the (further state), those are (further conditions) and > > >>>>> hence the comma changes the meaning > > >>>>> • We need to update > > >>>>> CLEANUP, PUSH UpdateZTPOffer, and PUSH MTUMismatch, > > >>>>> To CLEANUP, then PUSH UpdateZTPOffer, then PUSH MTUMismatch It’s a > > >>>>> sequence, the “ands” imply possibly arbitrary/paralllel execution of > > >>>>> the three which is incorrect > > >>>>> 5. > > >>>>> fully, automatically > > >>>>> Comma changes meaning, it is really “in a fully automatic fashion” so > > >>>>> I think “fully automatically” or equivalent thereof > > >>>>> With those changes resolved, OK from my side > > >>>>> • -tony > > >>>>> > > >>>>> Juniper Business Use Only > > >>>>> From: Antoni Przygienda <p...@juniper.net> > > >>>>> Date: Tuesday, 25 February 2025 at 15:45 > > >>>>> To: Alanna Paloma <apal...@staff.rfc-editor.org> > > >>>>> Cc: Jordan Head <jh...@juniper.net>, Dmitry Afanasiev > > >>>>> <f...@yandex-team.ru>, Alankar Sharma <as3...@gmail.com>, > > >>>>> pascal.thub...@gmail.com <pascal.thub...@gmail.com>, > > >>>>> brunorijs...@gmail.com <brunorijs...@gmail.com>, > > >>>>> rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org>, > > >>>>> rift-...@ietf.org <rift-...@ietf.org>, rift-cha...@ietf.org > > >>>>> <rift-cha...@ietf.org>, ext-zhang.zh...@zte.com.cn > > >>>>> <zhang.zh...@zte.com.cn>, james.n.guich...@futurewei.com > > >>>>> <james.n.guich...@futurewei.com>, auth48archive@rfc-editor.org > > >>>>> <auth48archive@rfc-editor.org> > > >>>>> Subject: Re: AUTH48: RFC-to-be 9692 <draft-ietf-rift-rift-24> for > > >>>>> your review > > >>>>> Finally found time to start on it > > >>>>> Reading > > >>>>> Diff: rfc9692.original - rfc9692.txt > > >>>>> rfc-editor.org > > >>>> <favicon.ico> > > >>>>> > > >>>>> > > >>>>> Which I assume is the last diff’ed stuff > > >>>>> Will chip at it next days > > >>>>> Thanks > > >>>>> — Tony > > >>>>> > > >>>>> > > >>>>> On 10 Feb 2025, at 22:43, Alanna Paloma > > >>>>> <apal...@staff.rfc-editor.org> wrote: > > >>>>> [External Email. Be cautious of content] > > >>>>> > > >>>>> > > >>>>> Hi Jordan and Tony, > > >>>>> > > >>>>> Thank you for your replies. Jordan’s approval and Tony’s delay have > > >>>>> been noted on the AUTH48 status page: > > >>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9692__;!!NEt6yMaO-gk!DT_f-QA0UD90PBgaDF680YQpT5u_Y_Uvr1X8KOs56Tw_z4bWQj1-jQvxSqb2SFopnFj3W0Hi90VyXsWJAwJEN_4$ > > >>>>> > > >>>>> Best regards, > > >>>>> RFC Editor/ap > > >>>>> > > >>>>> > > >>>>> > > >>>>> On Feb 10, 2025, at 10:19 AM, Jordan Head <jh...@juniper.net> wrote: > > >>>>> > > >>>>> Hi Alanna, > > >>>>> I approve. > > >>>>> Thanks > > >>>>> > > >>>>> Juniper Business Use Only > > >>>>> From: Alanna Paloma <apal...@staff.rfc-editor.org> > > >>>>> Date: Monday, February 10, 2025 at 11:41 AM > > >>>>> To: Antoni Przygienda <p...@juniper.net>, Jordan Head > > >>>>> <jh...@juniper.net>, Dmitry Afanasiev <f...@yandex-team.ru> > > >>>>> Cc: Alankar Sharma <as3...@gmail.com>, > > >>>>> pascal.thub...@gmail.com<pascal.thub...@gmail.com>, > > >>>>> brunorijs...@gmail.com<brunorijs...@gmail.com>, > > >>>>> rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org>, > > >>>>> rift-...@ietf.org <rift-...@ietf.org>, rift-cha...@ietf.org > > >>>>> <rift-cha...@ietf.org>, ext-zhang.zh...@zte.com.cn > > >>>>> <zhang.zh...@zte.com.cn>, > > >>>>> james.n.guich...@futurewei.com<james.n.guich...@futurewei.com>, > > >>>>> auth48archive@rfc-editor.org <auth48archive@rfc-editor.org> > > >>>>> Subject: Re: AUTH48: RFC-to-be 9692 <draft-ietf-rift-rift-24> for > > >>>>> your review > > >>>>> [External Email. Be cautious of content] > > >>>>> > > >>>>> > > >>>>> Hi Tony, Jordan, and Dmitry, > > >>>>> > > >>>>> Just another friendly reminder that the document awaits your > > >>>>> approvals. Once we have received your approvals, we will move 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/rfc9692.xml__;!!NEt6yMaO-gk!H6fC4ayhwGLMCbrPEkkd3e7HGe6Dx5_Y32BMYcA7qew4kmRbr2PTcrdRpfoC816FI11M2iVkIj1_ZMKwhKtrFNFf$ > > >>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9692.txt__;!!NEt6yMaO-gk!H6fC4ayhwGLMCbrPEkkd3e7HGe6Dx5_Y32BMYcA7qew4kmRbr2PTcrdRpfoC816FI11M2iVkIj1_ZMKwhOnm7HYI$ > > >>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9692.html__;!!NEt6yMaO-gk!H6fC4ayhwGLMCbrPEkkd3e7HGe6Dx5_Y32BMYcA7qew4kmRbr2PTcrdRpfoC816FI11M2iVkIj1_ZMKwhB9tw4u_$ > > >>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9692.pdf__;!!NEt6yMaO-gk!H6fC4ayhwGLMCbrPEkkd3e7HGe6Dx5_Y32BMYcA7qew4kmRbr2PTcrdRpfoC816FI11M2iVkIj1_ZMKwhNEKCWko$ > > >>>>> > > >>>>> The relevant diff files have been posted here: > > >>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9692-diff.html__;!!NEt6yMaO-gk!H6fC4ayhwGLMCbrPEkkd3e7HGe6Dx5_Y32BMYcA7qew4kmRbr2PTcrdRpfoC816FI11M2iVkIj1_ZMKwhNGmi0gk$ > > >>>>> (comprehensive diff) > > >>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9692-auth48diff.html__;!!NEt6yMaO-gk!H6fC4ayhwGLMCbrPEkkd3e7HGe6Dx5_Y32BMYcA7qew4kmRbr2PTcrdRpfoC816FI11M2iVkIj1_ZMKwhOILetWQ$ > > >>>>> (AUTH48 changes) > > >>>>> > > >>>>> For the AUTH48 status of this document, please see: > > >>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9692__;!!NEt6yMaO-gk!H6fC4ayhwGLMCbrPEkkd3e7HGe6Dx5_Y32BMYcA7qew4kmRbr2PTcrdRpfoC816FI11M2iVkIj1_ZMKwhJ7xl4Ht$ > > >>>>> > > >>>>> Best regards, > > >>>>> RFC Editor/ap > > >>>>> > > >>>>> > > >>>>> On Jan 29, 2025, at 10:12 AM, Antoni Przygienda <p...@juniper.net> > > >>>>> wrote: > > >>>>> > > >>>>> I chewed through all the hanging things with Jordan a while ago and > > >>>>> we’re in sync so he’ll polish things up > > >>>>> > > >>>>> I’m underwater with projects here so it’s on my todo list to review > > >>>>> the spec carefully. I’ll get to it as soon as I can > > >>>>> > > >>>>> — Tony > > >>>>> > > >>>>> > > >>>>> On 29 Jan 2025, at 18:21, Alanna Paloma > > >>>>> <apal...@staff.rfc-editor.org> wrote: > > >>>>> > > >>>>> [External Email. Be cautious of content] > > >>>>> > > >>>>> > > >>>>> Hi Tony, Jordan, and Dmitry, > > >>>>> > > >>>>> 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/rfc9692.xml__;!!NEt6yMaO-gk!EzOvGycuo2LCEiZ90XcihKTM_GOqmVv7HNqptGyOv45zcndh9WB9r6P3Evtu1txCnw_vL99oYZ4pYGu_IJYnmKc$ > > >>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9692.txt__;!!NEt6yMaO-gk!EzOvGycuo2LCEiZ90XcihKTM_GOqmVv7HNqptGyOv45zcndh9WB9r6P3Evtu1txCnw_vL99oYZ4pYGu_u0jDnTk$ > > >>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9692.html__;!!NEt6yMaO-gk!EzOvGycuo2LCEiZ90XcihKTM_GOqmVv7HNqptGyOv45zcndh9WB9r6P3Evtu1txCnw_vL99oYZ4pYGu_rlh0pOQ$ > > >>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9692.pdf__;!!NEt6yMaO-gk!EzOvGycuo2LCEiZ90XcihKTM_GOqmVv7HNqptGyOv45zcndh9WB9r6P3Evtu1txCnw_vL99oYZ4pYGu_X5Q-mbI$ > > >>>>> > > >>>>> The relevant diff files have been posted here: > > >>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9692-diff.html__;!!NEt6yMaO-gk!EzOvGycuo2LCEiZ90XcihKTM_GOqmVv7HNqptGyOv45zcndh9WB9r6P3Evtu1txCnw_vL99oYZ4pYGu_rpMIM5c$ > > >>>>> (comprehensive diff) > > >>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9692-auth48diff.html__;!!NEt6yMaO-gk!EzOvGycuo2LCEiZ90XcihKTM_GOqmVv7HNqptGyOv45zcndh9WB9r6P3Evtu1txCnw_vL99oYZ4pYGu_IyfW7-w$ > > >>>>> (AUTH48 changes) > > >>>>> > > >>>>> For the AUTH48 status of this document, please see: > > >>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9692__;!!NEt6yMaO-gk!EzOvGycuo2LCEiZ90XcihKTM_GOqmVv7HNqptGyOv45zcndh9WB9r6P3Evtu1txCnw_vL99oYZ4pYGu_sDtB7Ds$ > > >>>>> > > >>>>> Best regards, > > >>>>> RFC Editor/ap > > >>>>> > > >>>>> > > >>>>> On Jan 22, 2025, at 9:00 AM, Jordan Head <jh...@juniper.net> wrote: > > >>>>> > > >>>>> Thanks for your patience on this. Tony and I are still doing a > > >>>>> thorough review of what we have. > > >>>>> > > >>>>> Juniper Business Use Only > > >>>>> From: Alanna Paloma <apal...@staff.rfc-editor.org> > > >>>>> Date: Wednesday, January 22, 2025 at 11:26 AM > > >>>>> To: Antoni Przygienda <p...@juniper.net>, Jordan Head > > >>>>> <jh...@juniper.net>, f...@yandex-team.ru <f...@yandex-team.ru> > > >>>>> Cc: Alankar Sharma <as3...@gmail.com>, > > >>>>> pascal.thub...@gmail.com<pascal.thub...@gmail.com>, > > >>>>> brunorijs...@gmail.com<brunorijs...@gmail.com>, > > >>>>> rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org>, > > >>>>> rift-...@ietf.org <rift-...@ietf.org>, rift-cha...@ietf.org > > >>>>> <rift-cha...@ietf.org>, ext-zhang.zh...@zte.com.cn > > >>>>> <zhang.zh...@zte.com.cn>, > > >>>>> james.n.guich...@futurewei.com<james.n.guich...@futurewei.com>, > > >>>>> auth48archive@rfc-editor.org <auth48archive@rfc-editor.org> > > >>>>> Subject: Re: AUTH48: RFC-to-be 9692 <draft-ietf-rift-rift-24> for > > >>>>> your review > > >>>>> [External Email. Be cautious of content] > > >>>>> > > >>>>> > > >>>>> Hi Tony, Jordan, and Dmitry, > > >>>>> > > >>>>> This is a friendly reminder that we await your reviews and approvals > > >>>>> of the updated files. Once we have received your approvals, we will > > >>>>> move 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/rfc9692.xml__;!!NEt6yMaO-gk!GeQ4qHD4Elr83mURhv2OFHuuUKEfpPUnmzj93FexuOwq2uSWvclaILY3zE_hiLAGsYIuLxX7g7LOZFYXsBnHYN7M$ > > >>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9692.txt__;!!NEt6yMaO-gk!GeQ4qHD4Elr83mURhv2OFHuuUKEfpPUnmzj93FexuOwq2uSWvclaILY3zE_hiLAGsYIuLxX7g7LOZFYXsGNB9PP9$ > > >>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9692.html__;!!NEt6yMaO-gk!GeQ4qHD4Elr83mURhv2OFHuuUKEfpPUnmzj93FexuOwq2uSWvclaILY3zE_hiLAGsYIuLxX7g7LOZFYXsDeh7F1c$ > > >>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9692.pdf__;!!NEt6yMaO-gk!GeQ4qHD4Elr83mURhv2OFHuuUKEfpPUnmzj93FexuOwq2uSWvclaILY3zE_hiLAGsYIuLxX7g7LOZFYXsCm2KNTk$ > > >>>>> > > >>>>> The relevant diff files have been posted here: > > >>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9692-diff.html__;!!NEt6yMaO-gk!GeQ4qHD4Elr83mURhv2OFHuuUKEfpPUnmzj93FexuOwq2uSWvclaILY3zE_hiLAGsYIuLxX7g7LOZFYXsNrwmalq$ > > >>>>> (comprehensive diff) > > >>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9692-auth48diff.html__;!!NEt6yMaO-gk!GeQ4qHD4Elr83mURhv2OFHuuUKEfpPUnmzj93FexuOwq2uSWvclaILY3zE_hiLAGsYIuLxX7g7LOZFYXsA-fqbod$ > > >>>>> (AUTH48 changes) > > >>>>> > > >>>>> For the AUTH48 status of this document, please see: > > >>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9692__;!!NEt6yMaO-gk!GeQ4qHD4Elr83mURhv2OFHuuUKEfpPUnmzj93FexuOwq2uSWvclaILY3zE_hiLAGsYIuLxX7g7LOZFYXsPZEQZbx$ > > >>>>> > > >>>>> Best regards, > > >>>>> RFC Editor/ap > > >>>>> > > >>>>> > > >>>>> On Jan 15, 2025, at 8:16 AM, Alanna Paloma > > >>>>> <apal...@staff.rfc-editor.org> wrote: > > >>>>> > > >>>>> Hi Alankar, > > >>>>> > > >>>>> Thank you for your approval. It has been noted: > > >>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9692__;!!NEt6yMaO-gk!GeQ4qHD4Elr83mURhv2OFHuuUKEfpPUnmzj93FexuOwq2uSWvclaILY3zE_hiLAGsYIuLxX7g7LOZFYXsPZEQZbx$ > > >>>>> > > >>>>> Best regards, > > >>>>> RFC Editor/ap > > >>>>> > > >>>>> > > >>>>> On Jan 14, 2025, at 8:53 AM, Alankar Sharma <as3...@gmail.com> wrote: > > >>>>> > > >>>>> Please record my approval. Thanks for all the hard work. > > >>>>> > > >>>>> Regards, > > >>>>> Alankar > > >>>>> > > >>>>> On Wed, Jan 8, 2025 at 7:32 PM Alanna Paloma > > >>>>> <apal...@staff.rfc-editor.org> wrote: > > >>>>> Authors, > > >>>>> > > >>>>> Thank you for the updated XML file and for resolving the spacing issue > > >>>>> > > >>>>> As all of our questions have been addressed, we will await any > > >>>>> further changes you may have and approvals from Tony, Jordan, > > >>>>> Alankar, Bruno, and Dmitry 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/rfc9692.xml__;!!NEt6yMaO-gk!GeQ4qHD4Elr83mURhv2OFHuuUKEfpPUnmzj93FexuOwq2uSWvclaILY3zE_hiLAGsYIuLxX7g7LOZFYXsBnHYN7M$ > > >>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9692.txt__;!!NEt6yMaO-gk!GeQ4qHD4Elr83mURhv2OFHuuUKEfpPUnmzj93FexuOwq2uSWvclaILY3zE_hiLAGsYIuLxX7g7LOZFYXsGNB9PP9$ > > >>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9692.html__;!!NEt6yMaO-gk!GeQ4qHD4Elr83mURhv2OFHuuUKEfpPUnmzj93FexuOwq2uSWvclaILY3zE_hiLAGsYIuLxX7g7LOZFYXsDeh7F1c$ > > >>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9692.pdf__;!!NEt6yMaO-gk!GeQ4qHD4Elr83mURhv2OFHuuUKEfpPUnmzj93FexuOwq2uSWvclaILY3zE_hiLAGsYIuLxX7g7LOZFYXsCm2KNTk$ > > >>>>> > > >>>>> The relevant diff files have been posted here: > > >>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9692-diff.html__;!!NEt6yMaO-gk!GeQ4qHD4Elr83mURhv2OFHuuUKEfpPUnmzj93FexuOwq2uSWvclaILY3zE_hiLAGsYIuLxX7g7LOZFYXsNrwmalq$ > > >>>>> (comprehensive diff) > > >>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9692-auth48diff.html__;!!NEt6yMaO-gk!GeQ4qHD4Elr83mURhv2OFHuuUKEfpPUnmzj93FexuOwq2uSWvclaILY3zE_hiLAGsYIuLxX7g7LOZFYXsA-fqbod$ > > >>>>> (AUTH48 changes) > > >>>>> > > >>>>> For the AUTH48 status of this document, please see: > > >>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9692__;!!NEt6yMaO-gk!GeQ4qHD4Elr83mURhv2OFHuuUKEfpPUnmzj93FexuOwq2uSWvclaILY3zE_hiLAGsYIuLxX7g7LOZFYXsPZEQZbx$ > > >>>>> > > >>>>> Best regards, > > >>>>> RFC Editor/ap > > >>>>> > > >>>>> > > >>>>> On Jan 8, 2025, at 1:30 PM, Jordan Head <jh...@juniper.net> wrote: > > >>>>> > > >>>>> I’ve attached the new XML document that addresses the issues you > > >>>>> mentioned. > > >>>>> Thank you > > >>>>> Jordan > > >>>>> > > >>>>> Juniper Business Use Only > > >>>>> From: Jordan Head <jh...@juniper.net> > > >>>>> Date: Wednesday, January 8, 2025 at 3:28 PM > > >>>>> To: Alanna Paloma <apal...@staff.rfc-editor.org> > > >>>>> Cc: rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org>, Antoni > > >>>>> Przygienda <p...@juniper.net>, as3...@gmail.com <as3...@gmail.com>, > > >>>>> pascal.thub...@gmail.com <pascal.thub...@gmail.com>, > > >>>>> brunorijs...@gmail.com <brunorijs...@gmail.com>, > > >>>>> f...@yandex-team.ru<f...@yandex-team.ru>, rift-...@ietf.org > > >>>>> <rift-...@ietf.org>, rift-cha...@ietf.org <rift-cha...@ietf.org>, > > >>>>> ext-zhang.zh...@zte.com.cn<zhang.zh...@zte.com.cn>, > > >>>>> james.n.guich...@futurewei.com<james.n.guich...@futurewei.com>, > > >>>>> auth48archive@rfc-editor.org<auth48archive@rfc-editor.org> > > >>>>> Subject: Re: AUTH48: RFC-to-be 9692 <draft-ietf-rift-rift-24> for > > >>>>> your review > > >>>>> Thanks for the quick reply. > > >>>>> I can address the spacing issues, I’ll send a new XML file when it’s > > >>>>> ready. > > >>>>> Thanks > > >>>>> Jordan > > >>>>> From: Alanna Paloma <apal...@staff.rfc-editor.org> > > >>>>> Date: Wednesday, January 8, 2025 at 2:45 PM > > >>>>> To: Jordan Head <jh...@juniper.net> > > >>>>> Cc: rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org>, Antoni > > >>>>> Przygienda <p...@juniper.net>, as3...@gmail.com <as3...@gmail.com>, > > >>>>> pascal.thub...@gmail.com <pascal.thub...@gmail.com>, > > >>>>> brunorijs...@gmail.com <brunorijs...@gmail.com>, > > >>>>> f...@yandex-team.ru<f...@yandex-team.ru>, rift-...@ietf.org > > >>>>> <rift-...@ietf.org>, rift-cha...@ietf.org <rift-cha...@ietf.org>, > > >>>>> ext-zhang.zh...@zte.com.cn<zhang.zh...@zte.com.cn>, > > >>>>> james.n.guich...@futurewei.com<james.n.guich...@futurewei.com>, > > >>>>> auth48archive@rfc-editor.org<auth48archive@rfc-editor.org> > > >>>>> Subject: Re: AUTH48: RFC-to-be 9692 <draft-ietf-rift-rift-24> for > > >>>>> your review > > >>>>> [External Email. Be cautious of content] > > >>>>> > > >>>>> > > >>>>> Hi Jordan, > > >>>>> > > >>>>> > > >>>>> ) To improve the SVG output in the HTML and PDF files, we suggest the > > >>>>> following. Please let us know which you would prefer: > > >>>>> (a) put the ASCII art into the HTML and PDF files, i.e., match Fig 14 > > >>>>> and 29 from rfc9692.txt or > > >>>>> (b) redraw the figures with another app to make new SVG (e.g., > > >>>>> Inkscape). > > >>>>> > > >>>>> jhead>> We received positive feedback for both images during the > > >>>>> review process. Can you please provide some context as to what you > > >>>>> mean by “jumbled”? > > >>>>> > > >>>>> ) Both figures appear to have spacing issues between the vertical > > >>>>> pipes and letters, making the labels difficult to read. > > >>>>> > > >>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9692.html*lie-fsm-figure__;Iw!!NEt6yMaO-gk!EKiq0cAeW1D2n8maKa_Lo0BoJmC0hf-G7hZr-cq3WvZH1zRByPBHoGVmZ2AN8THBU5U1k4D603GBr3gxL_G0dZiD$ > > >>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9692.html*normative-ztp-fsm__;Iw!!NEt6yMaO-gk!EKiq0cAeW1D2n8maKa_Lo0BoJmC0hf-G7hZr-cq3WvZH1zRByPBHoGVmZ2AN8THBU5U1k4D603GBr3gxL7xiMMaN$ > > >>>>> > > >>>>> To fix the spacing, please let us know which of the aforementioned > > >>>>> options you would prefer. > > >>>>> > > >>>>> [Note that my email address has changed from <apal...@amsl.com> to > > >>>>> <apal...@staff.rfc-editor.org>.] > > >>>>> > > >>>>> Thank you, > > >>>>> RFC Editor/ap > > >>>>> > > >>>>> > > >>>>> On Jan 8, 2025, at 5:29 AM, Jordan Head > > >>>>> <jhead=40juniper....@dmarc.ietf.org> wrote: > > >>>>> > > >>>>> Thank you for the update, replies/comments inline as jhead>> > > >>>>> > > >>>>> Juniper Business Use Only > > >>>>> From: Alanna Paloma <apal...@amsl.com> > > >>>>> Date: Tuesday, January 7, 2025 at 5:01 PM > > >>>>> To: Jordan Head <jh...@juniper.net> > > >>>>> Cc: rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org>, Antoni > > >>>>> Przygienda <p...@juniper.net>, as3...@gmail.com <as3...@gmail.com>, > > >>>>> pascal.thub...@gmail.com <pascal.thub...@gmail.com>, > > >>>>> brunorijs...@gmail.com<brunorijs...@gmail.com>, > > >>>>> f...@yandex-team.ru<f...@yandex-team.ru>, rift-...@ietf.org > > >>>>> <rift-...@ietf.org>, rift-cha...@ietf.org <rift-cha...@ietf.org>, > > >>>>> ext-zhang.zh...@zte.com.cn<zhang.zh...@zte.com.cn>, > > >>>>> james.n.guich...@futurewei.com<james.n.guich...@futurewei.com>, > > >>>>> auth48archive@rfc-editor.org<auth48archive@rfc-editor.org> > > >>>>> Subject: Re: AUTH48: RFC-to-be 9692 <draft-ietf-rift-rift-24> for > > >>>>> your review > > >>>>> [External Email. Be cautious of content] > > >>>>> > > >>>>> > > >>>>> Hi Jordan, > > >>>>> > > >>>>> Thank you for your reply. We have updated the files accordingly. > > >>>>> Please note that we have some follow ups regarding the document’s SVG > > >>>>> and artwork. > > >>>>> > > >>>>> > > >>>>> 37) <!-- [rfced] Regarding the SVG questions below, please review the > > >>>>> TXT, HTML, > > >>>>> and PDF outputs, as we will need you to update the edited copy > > >>>>> of the XML. > > >>>>> > > >>>>> a) The SVG figures contain duplicate ids, which generates invalid > > >>>>> HTML. Please > > >>>>> let us know if you want to correct the SVG or if you want us to run a > > >>>>> utility > > >>>>> that creates unique ids within the SVG. > > >>>>> jhead>> Yes, please run the utility for us. > > >>>>> jhead>> As an aside, can you point me to the utility for future use? > > >>>>> > > >>>>> ) The utility is ran through kramdown-rfc. See > > >>>>> https://urldefense.com/v3/__https://github.com/cabo/kramdown-rfc/wiki/SVG*svg-id-collisions__;Iw!!NEt6yMaO-gk!DDAbBV9p0keMQbEGGvPYIbOvPzHtP4FpurOG5qPLd3TyLzWH2xW22JbXNvhXx37P2xou6x3HUUeIIg$ > > >>>>> . > > >>>>> > > >>>>> jhead>> Images still look good, thanks for addressing this for us! > > >>>>> > > >>>>> > > >>>>> b) Please see Figures 14 and 29 in the HTML and PDF outputs. The > > >>>>> output for the > > >>>>> SVG appear to be jumbled. To fix the SVG, please provide us with the > > >>>>> files of > > >>>>> the updated SVG. > > >>>>> jhead>> Both of these are generated directly from code and cannot > > >>>>> really be changed. > > >>>>> > > >>>>> ) To improve the SVG output in the HTML and PDF files, we suggest the > > >>>>> following. Please let us know which you would prefer: > > >>>>> (a) put the ASCII art into the HTML and PDF files, i.e., match Fig 14 > > >>>>> and 29 from rfc9692.txt or > > >>>>> (b) redraw the figures with another app to make new SVG (e.g., > > >>>>> Inkscape). > > >>>>> > > >>>>> jhead>> We received positive feedback for both images during the > > >>>>> review process. Can you please provide some context as to what you > > >>>>> mean by “jumbled”? > > >>>>> > > >>>>> > > >>>>> 38) <!--[rfced] The artwork ("ascii-art") for Figures 3, 13, and 18 is > > >>>>> too wide for the text output. Is it possible to wrap it within > > >>>>> the 72-character line limit? > > >>>>> > > >>>>> If not: Because SVG diagrams exist for those 3 figures, you have the > > >>>>> option > > >>>>> to remove the ascii-art completely; in that case, the text file would > > >>>>> contain > > >>>>> a pointer to the HTML file. For example: > > >>>>> > > >>>>> (Artwork only available as SVG: see > > >>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/rfc/rfc9692.html__;!!NEt6yMaO-gk!DvhlYJjwDvmKheQ1Utsr8x7uFX3j5uE9GyxeAWQq1UDV5AT4xhBdBQMpyXP9EgfU9iLJmIaEg5POujbjFiAPo5s$ > > >>>>> ) > > >>>>> --> > > >>>>> > > >>>>> jhead>> I was able to do this for Figures 13 and 18. However, it is > > >>>>> not possible to address Figure 3. Let’s just add the pointer to the > > >>>>> HTML version of the document where Figure 3 is. > > >>>>> jhead>> I cannot do this as the link you sent me is broken. If you > > >>>>> send me a fixed link / syntactical example of how to add the pointer, > > >>>>> I will add it or you can add it if that’s easier. > > >>>>> > > >>>>> ) The link pointing the HTML file will not work until after this > > >>>>> document is published. We have added the text; see Figure 3 in > > >>>>> <https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9692.txt__;!!NEt6yMaO-gk!DDAbBV9p0keMQbEGGvPYIbOvPzHtP4FpurOG5qPLd3TyLzWH2xW22JbXNvhXx37P2xou6x0O8GJtmQ$ > > >>>>> >. > > >>>>> > > >>>>> As Figure 3 directly follows Figure 2, we have moved text from the > > >>>>> preceding paragraph between the two figures to improve readability. > > >>>>> Please let us know if you have any objections. > > >>>>> > > >>>>> Curent: > > >>>>> > > >>>>> Figure 2: A Three-Level Spine-and-Leaf Topology > > >>>>> > > >>>>> The topology in Figure 2 is referred to in all further > > >>>>> considerations. This figure depicts a generic "single-plane fat > > >>>>> tree" and the concepts explained using three levels apply by > > >>>>> induction to further levels and higher degrees of connectivity. > > >>>>> > > >>>>> (Artwork only available as SVG: see > > >>>>> > > >>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/rfc/rfc9692.html__;!!NEt6yMaO-gk!DDAbBV9p0keMQbEGGvPYIbOvPzHtP4FpurOG5qPLd3TyLzWH2xW22JbXNvhXx37P2xou6x25B0RmZQ$ > > >>>>> ) > > >>>>> > > >>>>> Figure 3: Topology with Multiple Planes > > >>>>> > > >>>>> Further, this document will also deal with designs that provide only > > >>>>> sparser connectivity and "partitioned spines", as shown in Figure 3 > > >>>>> and explained further in Section 5.2. > > >>>>> > > >>>>> jhead>> This change looks good, thank you. > > >>>>> > > >>>>> ... > > >>>>> The files have been posted here (please refresh): > > >>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9692.xml__;!!NEt6yMaO-gk!DDAbBV9p0keMQbEGGvPYIbOvPzHtP4FpurOG5qPLd3TyLzWH2xW22JbXNvhXx37P2xou6x3SP1qaag$ > > >>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9692.txt__;!!NEt6yMaO-gk!DDAbBV9p0keMQbEGGvPYIbOvPzHtP4FpurOG5qPLd3TyLzWH2xW22JbXNvhXx37P2xou6x0O8GJtmQ$ > > >>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9692.html__;!!NEt6yMaO-gk!DDAbBV9p0keMQbEGGvPYIbOvPzHtP4FpurOG5qPLd3TyLzWH2xW22JbXNvhXx37P2xou6x23lr81ZQ$ > > >>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9692.pdf__;!!NEt6yMaO-gk!DDAbBV9p0keMQbEGGvPYIbOvPzHtP4FpurOG5qPLd3TyLzWH2xW22JbXNvhXx37P2xou6x2kEXQdVg$ > > >>>>> > > >>>>> The relevant diff files have been posted here: > > >>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9692-diff.html__;!!NEt6yMaO-gk!DDAbBV9p0keMQbEGGvPYIbOvPzHtP4FpurOG5qPLd3TyLzWH2xW22JbXNvhXx37P2xou6x10IDngzg$ > > >>>>> (comprehensive diff) > > >>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9692-auth48diff.html__;!!NEt6yMaO-gk!DDAbBV9p0keMQbEGGvPYIbOvPzHtP4FpurOG5qPLd3TyLzWH2xW22JbXNvhXx37P2xou6x2HMdaFHg$ > > >>>>> (AUTH48 changes) > > >>>>> > > >>>>> For the AUTH48 status of this document, please see: > > >>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9692__;!!NEt6yMaO-gk!DDAbBV9p0keMQbEGGvPYIbOvPzHtP4FpurOG5qPLd3TyLzWH2xW22JbXNvhXx37P2xou6x2aInCVcg$ > > >>>>> > > >>>>> Thank you, > > >>>>> RFC Editor/ap > > >>>>> > > >>>>> > > >>>>> > > >>>>> On Dec 26, 2024, at 1:18 PM, Jordan Head > > >>>>> <jhead=40juniper....@dmarc.ietf.org> wrote: > > >>>>> > > >>>>> Dear Editors, > > >>>>> Thank you so much for the time and effort you’ve put into this, it’s > > >>>>> certainly been a journey. > > >>>>> • I have read your comments and replied inline as jhead>> > > >>>>> • I have also re-read the entire spec’s diff. There were critical > > >>>>> areas in the new version that need to be reverted back to the > > >>>>> original text as they would have normative implications if left as > > >>>>> is. Beyond that, just a handful of minor editorial things. I will > > >>>>> call out the important items below. > > >>>>> • I have also added a handful of non-normative edits. I will call out > > >>>>> the major items below #2 > > >>>>> I have attached the updated (expanded) XML file (rfc9692.jhead.xml) > > >>>>> to this e-mail, please let me know if you do not receive it. > > >>>>> Adjustments to RFC Editor Proposed Changes > > >>>>> • Some of the proposed changes in sections 6.2, 6.2.1, 6.3.2, > > >>>>> 6.3.3.1.2.2, 6.3.3.1.3.2, 6.3.3.1.4, 6.3.8, 6.3.9, 6.8.4.1, and 7 > > >>>>> alter critical semantics that are required to interpret the > > >>>>> specification correctly. Specifically, items like and/or emphasis, > > >>>>> if/else logic, and other similar items. Multiple implementations have > > >>>>> been built upon the existing text, so I have reverted the necessary > > >>>>> areas while leaving the editorial components that were changed. > > >>>>> • Section 6.2.1 > > >>>>> • In the proposed text there were several instances of changes to > > >>>>> “multiple neighbors' timers”, “multiple neighbors timer” is neither > > >>>>> possessive nor plural. Reverted them back to “multiple neighbors > > >>>>> timer” > > >>>>> • Section 6.3.7 > > >>>>> • New text says “When a node exits in the network”, original text of > > >>>>> “When a node exits the network” is correct. > > >>>>> • Section 6.3.9 > > >>>>> • New text changed similarity to similarly, similarity is correct in > > >>>>> the mathematical context. > > >>>>> • Section 6.4.3 > > >>>>> • New text states “changes in the forwarding direction”, “changes in > > >>>>> forwarding direction” is correct here. > > >>>>> • Section 6.5.1 > > >>>>> • New text states “all the lower-level nodes are flooded to the same > > >>>>> disaggregated prefixes” the addition of “to the same” makes this > > >>>>> incorrect. What this sentence is saying is “all the lower-level nodes > > >>>>> are flooded (receive) the same disaggregated prefixes (from the > > >>>>> higher-level nodes)…” I’d like to revert to the original text if that > > >>>>> works. > > >>>>> • Section 6.8.6 > > >>>>> • New text changed “Up” to “up” and “Down” to “down”, both of those > > >>>>> are normative states in the BFD FSM. I left the changes you > > >>>>> incorporated except for the initial capitalization of those two items. > > >>>>> • Appendix B.3 > > >>>>> • Proposed changes to the unordered list following the text “To > > >>>>> finish this example, the following list shows sets computed by ToF 22 > > >>>>> using notation introduced in Section 6.5” are semantically incorrect. > > >>>>> I have reverted them to the original to ensure alignment with the > > >>>>> referenced section. > > >>>>> Other Edits > > >>>>> • Section 5.2.2 > > >>>>> • Figure 6 and Figure 10 did not match between the ASCII and SVG > > >>>>> variants, I have corrected this. > > >>>>> • Previous text stated: “a PoD node has K number of ports” when in > > >>>>> fact it should be “a PoD node has 2K number of ports”. > > >>>>> • Section 5 (and some of its sub-sections) > > >>>>> • While still correct, there were some instances of the word “spine” > > >>>>> could be more specific (e.g., use ToF or ToP). Those instances have > > >>>>> been adjusted. > > >>>>> Again, thank you so much for the hard work! > > >>>>> Jordan Head > > >>>>> > > >>>>> Juniper Business Use Only > > >>>>> From: rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org> > > >>>>> Date: Monday, December 9, 2024 at 5:57 PM > > >>>>> To: Antoni Przygienda <p...@juniper.net>, Jordan Head > > >>>>> <jh...@juniper.net>, as3...@gmail.com <as3...@gmail.com>, > > >>>>> pascal.thub...@gmail.com<pascal.thub...@gmail.com>, > > >>>>> brunorijs...@gmail.com<brunorijs...@gmail.com>, > > >>>>> f...@yandex-team.ru<f...@yandex-team.ru> > > >>>>> Cc: rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org>, > > >>>>> rift-...@ietf.org <rift-...@ietf.org>, rift-cha...@ietf.org > > >>>>> <rift-cha...@ietf.org>, ext-zhang.zh...@zte.com.cn > > >>>>> <zhang.zh...@zte.com.cn>, > > >>>>> james.n.guich...@futurewei.com<james.n.guich...@futurewei.com>,auth48archive@rfc-editor.org<auth48archive@rfc-editor.org> > > >>>>> Subject: Re: AUTH48: RFC-to-be 9692 <draft-ietf-rift-rift-24> 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 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!DvhlYJjwDvmKheQ1Utsr8x7uFX3j5uE9GyxeAWQq1UDV5AT4xhBdBQMpyXP9EgfU9iLJmIaEg5POujbjgea3dNM$ > > >>>>> . --> > > >>>>> > > >>>>> jhead>> I have added several key words in the body of the document. > > >>>>> > > >>>>> 2) <!--[rfced] We are having difficulty parsing the final part of > > >>>>> this sentence. > > >>>>> Should "compute" be "computational resources" or otherwise? > > >>>>> > > >>>>> Original: > > >>>>> Such a solution would allow local > > >>>>> IP fabric bandwidth to be consumed in a 'standard component' fashion, > > >>>>> i.e. provision it much faster and operate it at much lower costs than > > >>>>> today, much like compute or storage is consumed already. > > >>>>> > > >>>>> Perhaps: > > >>>>> Such a solution would allow local > > >>>>> IP fabric bandwidth to be consumed in a "standard component" fashion, > > >>>>> i.e., provision it much faster and operate it at much lower costs than > > >>>>> today, similar to how computational resources (e.g., CPU, storage) are > > >>>>> consumed already. > > >>>>> --> > > >>>>> > > >>>>> jhead>> I’d prefer we leave this one as is as “compute” is a noun in > > >>>>> the standard technical vernacular. > > >>>>> > > >>>>> > > >>>>> 3) <!--[rfced] To improve readability, may we make this sentence into > > >>>>> two? > > >>>>> > > >>>>> Original: > > >>>>> Alas, such aggregation could > > >>>>> drop traffic in cases of misconfiguration or while failures are being > > >>>>> resolved or even cause persistent network partitioning and this has > > >>>>> to be addressed by some adequate mechanism. > > >>>>> > > >>>>> Perhaps: > > >>>>> Alas, such aggregation could > > >>>>> drop traffic in cases of misconfiguration or while failures are being > > >>>>> resolved. It could also cause persistent network partitioning, which > > >>>>> has > > >>>>> to be addressed by some adequate mechanism. > > >>>>> --> > > >>>>> jhead>> Yes, this works. I have adjusted this. > > >>>>> > > >>>>> > > >>>>> 4) <!--[rfced] May we update "multiple level" to "multi-level"? > > >>>>> > > >>>>> Original: > > >>>>> Several modifications such as leaf- > > >>>>> 2-leaf shortcuts and multiple level shortcuts are possible and > > >>>>> described further in the document. > > >>>>> > > >>>>> Perhaps: > > >>>>> Several modifications such as leaf- > > >>>>> 2-leaf shortcuts and multi-level shortcuts are possible and > > >>>>> described further in the document. > > >>>>> --> > > >>>>> jhead>> Yes, this works. I have adjusted this. > > >>>>> > > >>>>> > > >>>>> 5) <!--[rfced] Does "The usual natural numbers algebra" refer to > > >>>>> a typical formula for cost? If so, should it be included, as > > >>>>> "usual" seems vague. Is there a word that would be more > > >>>>> clear than "algebra" here? > > >>>>> > > >>>>> Original: > > >>>>> Cost: > > >>>>> A natural number without a unit associated with two entities. The > > >>>>> usual natural numbers algebra can be applied to costs. > > >>>>> --> > > >>>>> jhead>> Per Tony, I have changed that part of the definition to say: > > >>>>> Cost: “A natural number without the unit associated with two > > >>>>> entities. The cost is a monoid under addition.” … > > >>>>> > > >>>>> > > >>>>> 6) <!--[rfced] Should any of the following text be in the <aside> > > >>>>> element? It is > > >>>>> defined as "a container for content that is semantically less > > >>>>> important > > >>>>> or tangential to the content that surrounds it" > > >>>>> (https://urldefense.com/v3/__https://authors.ietf.org/en/rfcxml-vocabulary*aside__;Iw!!NEt6yMaO-gk!DvhlYJjwDvmKheQ1Utsr8x7uFX3j5uE9GyxeAWQq1UDV5AT4xhBdBQMpyXP9EgfU9iLJmIaEg5POujbjDxy_rO4$ > > >>>>> ). > > >>>>> > > >>>>> Section 3.1 > > >>>>> As a final > > >>>>> footnote: Clos terminology often uses the concept of "stage", but > > >>>>> due to the folded nature of the Fat Tree, it is not used from this > > >>>>> point on to prevent misunderstandings. > > >>>>> jhead>> Fixed. > > >>>>> > > >>>>> Section 10.3.6 > > >>>>> Note: For interface addresses, the protocol can propagate the address > > >>>>> part beyond the subnet mask and on reachability computation that has > > >>>>> to be normalized. The non-significant bits can be used for > > >>>>> operational purposes. > > >>>>> jhead>> Fixed. > > >>>>> > > >>>>> > > >>>>> Section 10.3.11 > > >>>>> Note: The only purpose of those values is to introduce an ordering, > > >>>>> whereas an implementation can internally choose any other values as > > >>>>> long the ordering is preserved. > > >>>>> jhead>> Fixed. > > >>>>> > > >>>>> > > >>>>> Section 10.3.17 > > >>>>> Note: This node's level is already included on the packet header. > > >>>>> jhead>> Fixed. > > >>>>> > > >>>>> --> > > >>>>> > > >>>>> > > >>>>> 7) <!--[rfced] We are having some difficulty parsing "that allows to > > >>>>> protect" > > >>>>> in the sentence below. May we update it as follows? > > >>>>> > > >>>>> Original: > > >>>>> RIFT packets are flooded within an authenticated security envelope > > >>>>> that allows to protect the integrity of information a node accepts > > >>>>> if any of the mechanisms in Section 10.2 is used. > > >>>>> > > >>>>> Perhaps: > > >>>>> RIFT packets are flooded within an authenticated security envelope > > >>>>> that protects the integrity of information a node accepts > > >>>>> if any of the mechanisms in Section 10.2 are used. > > >>>>> --> > > >>>>> jhead>> “allows to” is more akin to “optionally enables”. Text now > > >>>>> reads: “RIFT packets are flooded within an authenticated security > > >>>>> envelope that optionally enable protection of the integrity of > > >>>>> information…” > > >>>>> > > >>>>> > > >>>>> 8) <!--[rfced] May we make this sentence more concise? > > >>>>> > > >>>>> Original: > > >>>>> For the moment > > >>>>> describing the East-West direction is left out until later in the > > >>>>> document. > > >>>>> > > >>>>> Perhaps: > > >>>>> The East-West direction is described later in the document. > > >>>>> --> > > >>>>> jhead>> Yes, adjusted. > > >>>>> > > >>>>> > > >>>>> 9) <!--[rfced] To improve readability, may we reorder this sentence as > > >>>>> follows? > > >>>>> > > >>>>> Original: > > >>>>> In order to reach a 1:1 connectivity > > >>>>> ratio between the ToF and the leaves, it results that there are K_TOP > > >>>>> ToF nodes, because each port of a ToP node connects to a different > > >>>>> ToF node, and K_LEAF ToP nodes for the same reason. > > >>>>> > > >>>>> Perhaps: > > >>>>> In order to reach a 1:1 connectivity > > >>>>> ratio between the ToF and the leaves, there are K_TOP > > >>>>> ToF nodes and K_LEAF ToP nodes because each port of a ToP node > > >>>>> connects > > >>>>> to a different ToF node. > > >>>>> --> > > >>>>> jhead>> Previous edit suggested by Pascal stands. > > >>>>> > > >>>>> > > >>>>> 10) <!--[rfced] To improve the readability, may we update this > > >>>>> sentence to > > >>>>> reduce the number of commas? > > >>>>> > > >>>>> Original: > > >>>>> The problem can also be > > >>>>> observed by the ToF nodes in the other planes through the flooding > > >>>>> of North TIEs from the affected leaf nodes, if there are only 3 > > >>>>> levels and the ToP nodes are directly connected to the leaf nodes, > > >>>>> and then again it can only be effective if it is propagated > > >>>>> transitively to the leaf, and useless above that level. > > >>>>> > > >>>>> Perhaps: > > >>>>> The problem can also be > > >>>>> observed by the ToF nodes in the other planes through the flooding > > >>>>> of North TIEs from the affected leaf nodes if there are only 3 > > >>>>> levels and the ToP nodes are directly connected to the leaf nodes, > > >>>>> and then again, it can only be effective if it is propagated > > >>>>> transitively to the leaf and is useless above that level. > > >>>>> --> > > >>>>> > > >>>>> jhead>> Previous edit suggested by Pascal stands. > > >>>>> > > >>>>> 11) <!--[rfced] We are having trouble parsing this sentence. Please > > >>>>> review > > >>>>> and let us know how it should be updated for clarity. > > >>>>> > > >>>>> Original: > > >>>>> IPv4 LIE exchange happens by default over well-known administratively > > >>>>> locally scoped and configured or otherwise well-known IPv4 multicast > > >>>>> address [RFC2365]. > > >>>>> --> > > >>>>> jhead>> Subtle change to Pascal’s suggested edit, text now reads: > > >>>>> “IPv4 LIE exchange happens by default over a well-known IPv4 > > >>>>> multicast address [RFC2365] that may also be administratively > > >>>>> configured (e.g., with a local scope).” > > >>>>> > > >>>>> > > >>>>> 12) <!--[rfced] May we clarify "local" and "remote" to refer to > > >>>>> address > > >>>>> families? > > >>>>> > > >>>>> Original: > > >>>>> The table is symmetric, i.e. local and remote can be > > >>>>> exchanged to construct the remaining combinations. > > >>>>> > > >>>>> Perhaps: > > >>>>> The table is symmetric, i.e. local and remote address families (AFs) > > >>>>> can be exchanged to construct the remaining combinations. > > >>>>> --> > > >>>>> jhead>> Newly proposed text reads as: “The table is symmetric, i.e., > > >>>>> the local and remote columns can be exchanged to construct the > > >>>>> remaining combinations.” However, your original proposal is better, I > > >>>>> think. > > >>>>> > > >>>>> > > >>>>> 13) <!--[rfced] We are having difficulty understanding how "given > > >>>>> they have > > >>>>> implications in terms of level and adjacency forming here" fits into > > >>>>> this > > >>>>> sentence. Please review and let us know how we may update this > > >>>>> sentence > > >>>>> for clarity. Also, does "they" refer to "definitions" or "leaf flags"? > > >>>>> > > >>>>> Original: > > >>>>> Further definitions of leaf flags are found in Section 6.7 given they > > >>>>> have implications in terms of level and adjacency forming here. > > >>>>> --> > > >>>>> jhead>> I have changed the text to: “Further leaf flag definitions > > >>>>> are found in Section 6.7 as they have implications in terms of level > > >>>>> and adjacency formation”. > > >>>>> jhead>> “they” refers to the “leaf flags definitions”, it’s really a > > >>>>> single term that specifies how the leaf flags function. > > >>>>> > > >>>>> > > >>>>> 14) <!--[rfced] We are having difficulty parsing "already to nodes > > >>>>> at". > > >>>>> Please review and let us know how we may clarify this sentence. > > >>>>> Also, does "with level different" refer to the nodes? > > >>>>> > > >>>>> Original: > > >>>>> i) the node is at _leaf_level_ value and has no _ThreeWay_ > > >>>>> adjacencies already to nodes at Highest Adjacency _ThreeWay_ > > >>>>> (HAT as defined later in Section 6.7.1) with level different > > >>>>> than the adjacent node *or* > > >>>>> > > >>>>> Perhaps: > > >>>>> a. the node is at the _leaf_level_ value and does not already > > >>>>> have any _ThreeWay_ adjacencies to nodes that are at Highest > > >>>>> Adjacency _ThreeWay_ (HAT), as defined in Section 6.7.1, > > >>>>> and that have a level different than the adjacent node; > > >>>>> --> > > >>>>> jhead>> A couple readability aspects of the proposed text are fine, > > >>>>> but the sentence phrasing and structure carries a degree of semantic > > >>>>> importance (this is one of the examples I mentioned earlier in the > > >>>>> e-mail). I have changed the text to: “the node is at the _leaf_level_ > > >>>>> value and does not already have any _ThreeWay_ adjacencies to nodes > > >>>>> that are at the Highest Adjacency _ThreeWay_ (HAT), as defined in > > >>>>> Section 6.7.1, with a level that is different than the adjacent node > > >>>>> *or*” > > >>>>> > > >>>>> > > >>>>> 15) <!--[rfced] Is the repetition of "return" intentional here? > > >>>>> > > >>>>> Original: > > >>>>> return return TIEHeader with larger seq_nr is larger > > >>>>> > > >>>>> Perhaps: > > >>>>> return TIEHeader with larger seq_nr is larger > > >>>>> > > >>>>> --> > > >>>>> > > >>>>> jhead>> As Pascal said, single return is correct. > > >>>>> > > >>>>> 16) <!--[rfced] To improve the readability of this sentence, may we > > >>>>> clarify it > > >>>>> as follows? > > >>>>> > > >>>>> Original: > > >>>>> This allows for future > > >>>>> extensions of the protocol within the same major schema with types > > >>>>> opaque to some nodes with some restrictions defined in Section 7. > > >>>>> > > >>>>> Perhaps: > > >>>>> This allows for future > > >>>>> extensions of the protocol that are within the same major schema > > >>>>> and that have types that are opaque to some nodes; some restrictions > > >>>>> are defined in Section 7. > > >>>>> --> > > >>>>> > > >>>>> jhead>> Yes, I’ve added your change. > > >>>>> > > >>>>> 17) <!--[rfced] What does "TIRDE" refer to in "TIRDEs_PER_PKT"? > > >>>>> Is this sufficiently clear to the reader from the text? We note > > >>>>> "TIDE" and "TIRE" are defined in Section 3.1. > > >>>>> > > >>>>> Current: > > >>>>> The constant _TIRDEs_PER_PKT_ SHOULD be computed per interface and > > >>>>> used by the implementation to limit the amount of TIE headers per > > >>>>> TIDE so the sent TIDE PDU does not exceed the interface of MTU. > > >>>>> --> > > >>>>> jhead>> This should be TIRES_PER_TIDE_PKT instead, I have updated all > > >>>>> instances. > > >>>>> > > >>>>> > > >>>>> 18) <!--[rfced] Is "spaced" the correct term to use here? If so, it > > >>>>> is unclear how > > >>>>> TIDE PDUs should be spaced. Please review and let us know if/how this > > >>>>> sentence > > >>>>> may be updated for clarity. > > >>>>> > > >>>>> Original: > > >>>>> TIDE PDUs SHOULD be spaced on sending to prevent packet drops. > > >>>>> --> > > >>>>> jhead>> Text now reads: TIDE PDUs SHOULD be transmitted at a rate > > >>>>> that does not lead to packet drops. > > >>>>> > > >>>>> 19) <!--[rfced] Should the terms defined in Sections 6.3.3.1.2.1, > > >>>>> 6.3.3.1.2.2, > > >>>>> and 6.3.3.1.3.2 be prefaced with introductory text? The current text > > >>>>> introduces the steps of a process, but then is followed directly by > > >>>>> definitions. May we rearrange the order of the text so that the > > >>>>> definitions > > >>>>> come before the current lead-in text? > > >>>>> > > >>>>> For example: > > >>>>> Original: > > >>>>> On reception of TIDEs the following processing is performed: > > >>>>> > > >>>>> TXKEYS: Collection of TIE Headers to be sent after processing of > > >>>>> the packet > > >>>>> > > >>>>> REQKEYS: Collection of TIEIDs to be requested after processing of > > >>>>> the packet > > >>>>> > > >>>>> CLEARKEYS: Collection of TIEIDs to be removed from flood state > > >>>>> queues > > >>>>> > > >>>>> LASTPROCESSED: Last processed TIEID in TIDE > > >>>>> > > >>>>> DBTIE: TIE in the Link State Database (LSDB) if found > > >>>>> > > >>>>> a. LASTPROCESSED = TIDE.start_range > > >>>>> > > >>>>> b. for every HEADER in TIDE do > > >>>>> > > >>>>> Perhaps: > > >>>>> TXKEYS: Collection of TIE Headers to be sent after processing of > > >>>>> the packet > > >>>>> > > >>>>> REQKEYS: Collection of TIEIDs to be requested after processing of > > >>>>> the packet > > >>>>> > > >>>>> CLEARKEYS: Collection of TIEIDs to be removed from flood state > > >>>>> queues > > >>>>> > > >>>>> LASTPROCESSED: Last processed TIEID in TIDE > > >>>>> > > >>>>> DBTIE: TIE in the Link State Database (LSDB) if found > > >>>>> > > >>>>> > > >>>>> On reception of TIDEs, the following processing is performed: > > >>>>> > > >>>>> a. LASTPROCESSED = TIDE.start_range > > >>>>> > > >>>>> b. for every HEADER in TIDE do > > >>>>> --> > > >>>>> jhead>> Yes, I’ve adjusted this. > > >>>>> > > >>>>> > > >>>>> 20) <!--[rfced] May "on first and only first request" be updated to > > >>>>> "on only the first request" for clarity? > > >>>>> > > >>>>> Original: > > >>>>> ...when receiving TIREs or TIDEs > > >>>>> resulting in requests for a TIE of which the newest received copy > > >>>>> came on an adjacency where the node was not flood repeater it > > >>>>> SHOULD ignore such requests on first and only first request. > > >>>>> > > >>>>> Perhaps: > > >>>>> ...when receiving TIREs or TIDEs > > >>>>> resulting in requests for a TIE of which the newest received copy > > >>>>> came on an adjacency where the node was not a flood repeater, it > > >>>>> SHOULD ignore such requests on only the first request. > > >>>>> --> > > >>>>> > > >>>>> jhead>> Yes. > > >>>>> > > >>>>> 21) <!--[rfced] Should "TIE north" be "North TIE" to match other > > >>>>> instances > > >>>>> throughout the document? > > >>>>> > > >>>>> Original: > > >>>>> More difficult is a condition where a node (e.g. a leaf) floods a TIE > > >>>>> north towards its grandparent, then its parent reboots, partitioning > > >>>>> the grandparent from leaf directly and then the leaf itself reboots. > > >>>>> --> > > >>>>> > > >>>>> jhead>> In this case, no, let’s leave it as is. > > >>>>> > > >>>>> 22) <!--[rfced] We are having some trouble parsing "term set". May we > > >>>>> rephrase this sentence as follows for clarity? > > >>>>> > > >>>>> Original: > > >>>>> We term set of those > > >>>>> prefixes |R, and for each prefix, r, in |R, its set of next-hops > > >>>>> is defined to be |H(r). > > >>>>> > > >>>>> Perhaps: > > >>>>> The set of those prefixes is referred to as |R; for each prefix > > >>>>> r in |R, its set of next hops is |H(r). > > >>>>> --> > > >>>>> > > >>>>> jhead>> We adjusted the text to now say “The set of those prefixes is > > >>>>> referred to as |R; for each prefix r in |R, its set of next hops is > > >>>>> referred to as |H(r).” > > >>>>> > > >>>>> 23) <!--[rfced] We are having difficulty understanding "subsequently > > >>>>> adjacencies > > >>>>> to nodes that advertised..." How may we update for clarity? > > >>>>> > > >>>>> Original: > > >>>>> The nexthop > > >>>>> adjacencies for a negative prefix are inherited from the longest > > >>>>> positive prefix that aggregates it, and subsequently adjacencies to > > >>>>> nodes that advertised negative for this prefix are removed. > > >>>>> > > >>>>> Option A: > > >>>>> The next-hop > > >>>>> adjacencies for a negative prefix are inherited from the longest > > >>>>> positive prefix that aggregates it; subsequently, adjacencies to > > >>>>> nodes that negatively advertised for this prefix are removed. > > >>>>> > > >>>>> Option B: [if the intended meaning is 'as a result' rather than > > >>>>> 'afterward'] > > >>>>> The next-hop > > >>>>> adjacencies for a negative prefix are inherited from the longest > > >>>>> positive prefix that aggregates it; as a result, adjacencies to > > >>>>> nodes that negatively advertised for this prefix are removed. > > >>>>> --> > > >>>>> > > >>>>> jhead>> We have changed the text to say “The next-hop adjacencies for > > >>>>> a negative prefix are inherited from the longest positive prefix that > > >>>>> aggregates it; subsequently, adjacencies to nodes that advertised > > >>>>> negative disaggregation for this prefix are removed.” > > >>>>> > > >>>>> 24) <!--[rfced] To clarify the content of Appendix A, may we update > > >>>>> this > > >>>>> sentence as follows? > > >>>>> > > >>>>> Original: > > >>>>> The sequence counter in [RFC8505] is encoded as one octet and wraps > > >>>>> around using Appendix A. > > >>>>> > > >>>>> Perhaps: > > >>>>> The sequence counter in [RFC8505] is encoded as one octet and wraps > > >>>>> around using the arithmetic defined in Appendix A. > > >>>>> --> > > >>>>> > > >>>>> jhead>> Yes, this is good. I’ve adjusted the text. > > >>>>> > > >>>>> > > >>>>> 25) <!--[rfced] May we update "Init" to "Initial state"? > > >>>>> > > >>>>> Original: > > >>>>> In case an established BFD session goes Down after it was Up, RIFT > > >>>>> adjacency SHOULD be re-initialized and subsequently started from > > >>>>> Init after it receives a consecutive BFD Up. > > >>>>> > > >>>>> Perhaps: > > >>>>> In case an established BFD session goes Down after it was Up, RIFT > > >>>>> adjacency SHOULD be re-initialized and subsequently started from > > >>>>> the Initial state after it receives a consecutive BFD Up. > > >>>>> --> > > >>>>> > > >>>>> jhead>> No, Init is a normative state in BFD. > > >>>>> > > >>>>> 26) <!--[rfced] To avoid the repetition of "to compute", should this > > >>>>> sentence > > >>>>> be updated as follows? > > >>>>> > > >>>>> Original: > > >>>>> On a node, L, use Node TIEs to compute from each non-overloaded > > >>>>> northbound neighbor N to compute 3 values: > > >>>>> > > >>>>> Perhaps: > > >>>>> On a node, L, use Node TIEs to compute 3 values from each > > >>>>> non-overloaded > > >>>>> northbound neighbor, N: > > >>>>> --> > > >>>>> > > >>>>> jhead>> Yes, this is good, I’ve adjusted the text. > > >>>>> > > >>>>> > > >>>>> 27) <!--[rfced] As this is a long sentence, may we break it up to > > >>>>> improve > > >>>>> its readability? > > >>>>> > > >>>>> Original: > > >>>>> Any value in > > >>>>> the packet following a security fingerprint MUST be used by a > > >>>>> receiver only after the fingerprint generated based on acceptable, > > >>>>> advertised key ID has been validated against the data covered by it > > >>>>> bare exceptions arising from operational exigencies where, based on > > >>>>> local configuration, a node MAY allow for the envelope's integrity > > >>>>> checks to be skipped and for behavior specified in Section 6.9.6. > > >>>>> > > >>>>> Perhaps: > > >>>>> Any value in > > >>>>> the packet following a security fingerprint MUST be used by a > > >>>>> receiver only after the fingerprint generated based on an acceptable, > > >>>>> advertised key ID has been validated against the data covered by the > > >>>>> bare exceptions arising from operational exigencies. Based on > > >>>>> local configuration, a node MAY allow for the envelope's integrity > > >>>>> checks to be skipped and for the procedure specified in Section 6.9.6 > > >>>>> to be implemented. > > >>>>> --> > > >>>>> > > >>>>> jhead>> Your proposed changes are better, I’ve updated the document. > > >>>>> > > >>>>> 28) <!--[rfced] We note that the following references are only cited > > >>>>> in the > > >>>>> sourcecode in Section 7.2. In order to have a 1:1 match-up between the > > >>>>> references section and the text, please review the text and let us > > >>>>> know > > >>>>> where a citation for each of the following may be included. > > >>>>> > > >>>>> [RFC5837] > > >>>>> [RFC5880] > > >>>>> [RFC6550] > > >>>>> > > >>>>> Alternatively, a sentence can be included before the sourcecode > > >>>>> stating > > >>>>> that it refers to the following (and then list the citations). > > >>>>> jhead>> > > >>>>> > > >>>>> Perhaps: > > >>>>> This schema references [RFC5837], [RFC5880], and [RFC6550]. > > >>>>> --> > > >>>>> > > >>>>> jhead>> I’ve added your suggestion to the top of the common.thrift > > >>>>> section. > > >>>>> > > >>>>> 29) <!--[rfced] May we make this sentence more concise? > > >>>>> > > >>>>> Original: > > >>>>> In a scenario > > >>>>> where such attacks are likely _maximum_valid_nonce_delta_ can be > > >>>>> implemented as configurable, small value and > > >>>>> _nonce_regeneration_interval_ configured to very small value as well. > > >>>>> > > >>>>> Perhaps: > > >>>>> In a scenario > > >>>>> where such attacks are likely, _maximum_valid_nonce_delta_ and > > >>>>> _nonce_regeneration_interval_ can be implemented as configurable, > > >>>>> small values. > > >>>>> --> > > >>>>> > > >>>>> jhead>> Text now reads: “In a scenario where such attacks are likely, > > >>>>> _maximum_valid_nonce_delta_ and _nonce_regeneration_interval_ can be > > >>>>> implemented as configurable; and set to small values.” > > >>>>> > > >>>>> 30) <!--[rfced] We are having some difficulty understanding how "leaf > > >>>>> level > > >>>>> value and always setting overload flag" fits into the rest of the > > >>>>> sentence. > > >>>>> Please let us know how this sentence may be clarified. > > >>>>> > > >>>>> Original: > > >>>>> To isolate possible attack vectors on the leaf to the largest > > >>>>> possible extent a dedicated leaf-only implementation could run > > >>>>> without any configuration by hard-coding a well-known adjacency key > > >>>>> (which can be always rolled-over by the means of, e.g., well-known > > >>>>> key-value distributed from top of the fabric), leaf level value and > > >>>>> always setting overload flag. > > >>>>> > > >>>>> Perhaps: > > >>>>> To isolate possible attack vectors on the leaf to the largest > > >>>>> possible extent, a dedicated leaf-only implementation could run > > >>>>> without any configuration by > > >>>>> * hard-coding a well-known adjacency key (which can be always > > >>>>> rolled over by means of, e.g., a well-known key-value distributed > > >>>>> from top of the fabric), > > >>>>> * hard-coding a _leaf_level_ value, and > > >>>>> * always setting the overload flag. > > >>>>> --> > > >>>>> > > >>>>> jhead>> Yes, this is great. I’ve added an unordered list per your > > >>>>> suggestion. We don’t need to say “leaf_level” here, we can refer to > > >>>>> it generically as it was previously. > > >>>>> > > >>>>> 31) <!--[rfced] Should 'outer key' be plural 'outer keys' in this > > >>>>> sentence? > > >>>>> (If so, we will ask IANA to update the registry accordingly.) > > >>>>> > > >>>>> Original (for HMAC-SHA256): > > >>>>> Simplest way to ensure integrity of transmissions across adjacencies > > >>>>> when used as outer key and integrity of TIEs when used as inner keys. > > >>>>> --> > > >>>>> > > >>>>> jhead>> Yes. > > >>>>> > > >>>>> 32) <!--[rfced] FYI, we have moved the text preceding Tables 9, 10, > > >>>>> 12, 13, > > >>>>> 14, 15, 17, 18, 19, 20, 21, 22, 24, 25, 27, 28, 29, 30, 31, 32, 33, > > >>>>> 34, > > >>>>> 35, 36, 37, 38, 39, 40, 41, 42, and 43 to be the table titles. Please > > >>>>> let > > >>>>> us know if you prefer otherwise. (In some cases, perhaps removing the > > >>>>> table title is best because the section title already provides the > > >>>>> corresponding registry name.) > > >>>>> > > >>>>> Additionally, please let us know if Tables 7, 8, 11, 16, 23, and 26 > > >>>>> should > > >>>>> have titles. > > >>>>> --> > > >>>>> > > >>>>> jhead>> I’m good with existing changes. > > >>>>> jhead>> For table 7, I’ve titled it “RIFT Security Algorithms” > > >>>>> jhead>> For the remaining items the only thought was to use the > > >>>>> section title, but as you said it’s probably best to leave it off. > > >>>>> > > >>>>> 33) <!--[rfced] Regarding Sections 10.3.1 - 10.3.36: > > >>>>> > > >>>>> a) Would you like the order of the columns in the tables in the IANA > > >>>>> Considerations to be updated to match the IANA registry? In other > > >>>>> words, > > >>>>> would you like to switch the Name and Value columns so that Value is > > >>>>> the first > > >>>>> column on the left? See Section 10.3.2 for an example of the update > > >>>>> to match > > >>>>> https://urldefense.com/v3/__https://www.iana.org/assignments/rift__;!!NEt6yMaO-gk!DvhlYJjwDvmKheQ1Utsr8x7uFX3j5uE9GyxeAWQq1UDV5AT4xhBdBQMpyXP9EgfU9iLJmIaEg5POujbjcxct13s$ > > >>>>> . (If the answer is no, then we will > > >>>>> revert Section 10.3.2.) > > >>>>> > > >>>>> b) FYI, the section titles have been updated to match the names > > >>>>> of the IANA registries. > > >>>>> --> > > >>>>> jhead>> Your proposed changes are fine with me. > > >>>>> > > >>>>> 34) <!--[rfced] Please clarify; how does and "on reachability > > >>>>> computation > > >>>>> that has to be normalized" connect with the rest of the sentence? > > >>>>> > > >>>>> Original: > > >>>>> @note: for interface addresses the protocol can propagate the address > > >>>>> part beyond the subnet mask and on reachability computation that has > > >>>>> to be normalized. The non-significant bits can be used for > > >>>>> operational purposes. > > >>>>> --> > > >>>>> > > >>>>> jhead>> Text now reads: “Note: For interface addresses the protocol > > >>>>> can propagate the address part beyond the subnet mask and on > > >>>>> reachability computation the non-significant bits have to be > > >>>>> normalized. Those bits can be used for operational purposes.” > > >>>>> > > >>>>> > > >>>>> 35) <!--[rfced] References > > >>>>> > > >>>>> a) The original URL for [thrift] goes to a GitHub repository. The web > > >>>>> portion > > >>>>> of the style guide > > >>>>> (https://urldefense.com/v3/__https://www.rfc-editor.org/styleguide/part2/*ref_repo__;Iw!!NEt6yMaO-gk!DvhlYJjwDvmKheQ1Utsr8x7uFX3j5uE9GyxeAWQq1UDV5AT4xhBdBQMpyXP9EgfU9iLJmIaEg5POujbj_AUx2nQ$ > > >>>>> ) > > >>>>> recommends using GitHub repositories for informative references only. > > >>>>> We found > > >>>>> the site for the Apache Thrift documentation at the following URL: > > >>>>> https://urldefense.com/v3/__https://thrift.apache.org/docs/__;!!NEt6yMaO-gk!DvhlYJjwDvmKheQ1Utsr8x7uFX3j5uE9GyxeAWQq1UDV5AT4xhBdBQMpyXP9EgfU9iLJmIaEg5POujbj71IyMCc$ > > >>>>> . > > >>>>> We have updated the reference as follows. Please let us know if you > > >>>>> prefer otherwise. > > >>>>> > > >>>>> Original: > > >>>>> [thrift] Apache Software Foundation, "Thrift Language > > >>>>> Implementation and Documentation", > > >>>>> > > >>>>> <https://urldefense.com/v3/__https://github.com/apache/thrift/tree/0.15.0/doc__;!!NEt6yMaO-gk!DvhlYJjwDvmKheQ1Utsr8x7uFX3j5uE9GyxeAWQq1UDV5AT4xhBdBQMpyXP9EgfU9iLJmIaEg5POujbjEY-My8U$ > > >>>>> >. > > >>>>> > > >>>>> Current: > > >>>>> [thrift] Apache Software Foundation, "Apache Thrift Documentation", > > >>>>> > > >>>>> <https://urldefense.com/v3/__https://thrift.apache.org/docs/__;!!NEt6yMaO-gk!DvhlYJjwDvmKheQ1Utsr8x7uFX3j5uE9GyxeAWQq1UDV5AT4xhBdBQMpyXP9EgfU9iLJmIaEg5POujbj71IyMCc$ > > >>>>> >. > > >>>>> > > >>>>> > > >>>>> b) FYI, the [SHA-2] reference has been updated from NIST FIPS PUB > > >>>>> 180-3 > > >>>>> to NIST FIPS 180-4, as per the note from IANA and because it was > > >>>>> superseded. > > >>>>> > > >>>>> > > >>>>> c) We have updated the URL for [EUI64] from > > >>>>> <https://urldefense.com/v3/__http://standards.ieee.org/develop/regauth/tut/eui.pdf__;!!NEt6yMaO-gk!DvhlYJjwDvmKheQ1Utsr8x7uFX3j5uE9GyxeAWQq1UDV5AT4xhBdBQMpyXP9EgfU9iLJmIaEg5POujbjRbbOcqo$ > > >>>>> > to > > >>>>> <https://urldefense.com/v3/__https://standards-support.ieee.org/hc/en-us/articles/4888705676564-Guidelines-for-Use-of-Extended-Unique-Identifier-EUI-Organizationally-Unique-Identifier-OUI-and-Company-ID-CID__;!!NEt6yMaO-gk!DvhlYJjwDvmKheQ1Utsr8x7uFX3j5uE9GyxeAWQq1UDV5AT4xhBdBQMpyXP9EgfU9iLJmIaEg5POujbj8xwO_Xs$ > > >>>>> >. The original URL led to a page about IEEE Registration > > >>>>> Authority programs. Please review and let us know if you have any > > >>>>> objections. > > >>>>> > > >>>>> Original: > > >>>>> [EUI64] IEEE, "Guidelines for Use of Extended Unique Identifier > > >>>>> (EUI), Organizationally Unique Identifier (OUI), and > > >>>>> Company ID (CID)", IEEE EUI, > > >>>>> > > >>>>> <https://urldefense.com/v3/__http://standards.ieee.org/develop/regauth/tut/eui.pdf__;!!NEt6yMaO-gk!DvhlYJjwDvmKheQ1Utsr8x7uFX3j5uE9GyxeAWQq1UDV5AT4xhBdBQMpyXP9EgfU9iLJmIaEg5POujbjRbbOcqo$ > > >>>>> >. > > >>>>> > > >>>>> Current: > > >>>>> [EUI64] IEEE, "Guidelines for Use of Extended Unique Identifier > > >>>>> (EUI), Organizationally Unique Identifier (OUI), and > > >>>>> Company ID (CID)", > > >>>>> <https://urldefense.com/v3/__https://standards-support.ieee.org/hc/__;!!NEt6yMaO-gk!DvhlYJjwDvmKheQ1Utsr8x7uFX3j5uE9GyxeAWQq1UDV5AT4xhBdBQMpyXP9EgfU9iLJmIaEg5POujbjxasZpz0$ > > >>>>> en-us/articles/4888705676564-Guidelines-for-Use-of- > > >>>>> Extended-Unique-Identifier-EUI-Organizationally-Unique- > > >>>>> Identifier-OUI-and-Company-ID-CID>. > > >>>>> > > >>>>> > > >>>>> d) FYI, RFC 5226 has been obsoleted by RFC 8126. We have replaced > > >>>>> usage in this document accordingly. > > >>>>> --> > > >>>>> > > >>>>> jhead>> All reference changes look good. > > >>>>> > > >>>>> 36) <!--[rfced] Should Alankar Sharma's name also be listed in the > > >>>>> Contributors > > >>>>> section, since the other authors are also listed there? > > >>>>> --> > > >>>>> > > >>>>> jhead>> Yes, done. > > >>>>> 37) <!-- [rfced] Regarding the SVG questions below, please review the > > >>>>> TXT, HTML, > > >>>>> and PDF outputs, as we will need you to update the edited copy > > >>>>> of the XML. > > >>>>> > > >>>>> a) The SVG figures contain duplicate ids, which generates invalid > > >>>>> HTML. Please > > >>>>> let us know if you want to correct the SVG or if you want us to run a > > >>>>> utility > > >>>>> that creates unique ids within the SVG. > > >>>>> jhead>> Yes, please run the utility for us. > > >>>>> jhead>> As an aside, can you point me to the utility for future use? > > >>>>> > > >>>>> b) Please see Figures 14 and 29 in the HTML and PDF outputs. The > > >>>>> output for the > > >>>>> SVG appear to be jumbled. To fix the SVG, please provide us with the > > >>>>> files of > > >>>>> the updated SVG. > > >>>>> jhead>> Both of these are generated directly from code and cannot > > >>>>> really be changed. > > >>>>> > > >>>>> c) We note that the text within many of the SVG figures is not able > > >>>>> to be > > >>>>> selected. (For example: text in Figures 1, 2, 32.) Is it possible to > > >>>>> modify > > >>>>> the SVG using your preferred SVG editing software to improve the > > >>>>> rendering > > >>>>> of the string in the SVG? > > >>>>> jhead>> Not possible at this point. > > >>>>> > > >>>>> Here is an example of SVG where the strings within the SVG are > > >>>>> selectable and searchable: > > >>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/rfc/rfc9576.html*figure-1__;Iw!!NEt6yMaO-gk!DvhlYJjwDvmKheQ1Utsr8x7uFX3j5uE9GyxeAWQq1UDV5AT4xhBdBQMpyXP9EgfU9iLJmIaEg5POujbjtopemTQ$ > > >>>>> --> > > >>>>> > > >>>>> > > >>>>> 38) <!--[rfced] The artwork ("ascii-art") for Figures 3, 13, and 18 is > > >>>>> too wide for the text output. Is it possible to wrap it within > > >>>>> the 72-character line limit? > > >>>>> > > >>>>> If not: Because SVG diagrams exist for those 3 figures, you have the > > >>>>> option > > >>>>> to remove the ascii-art completely; in that case, the text file would > > >>>>> contain > > >>>>> a pointer to the HTML file. For example: > > >>>>> > > >>>>> (Artwork only available as SVG: see > > >>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/rfc/rfc9692.html__;!!NEt6yMaO-gk!DvhlYJjwDvmKheQ1Utsr8x7uFX3j5uE9GyxeAWQq1UDV5AT4xhBdBQMpyXP9EgfU9iLJmIaEg5POujbjFiAPo5s$ > > >>>>> ) > > >>>>> --> > > >>>>> > > >>>>> jhead>> I was able to do this for Figures 13 and 18. However, it is > > >>>>> not possible to address Figure 3. Let’s just add the pointer to the > > >>>>> HTML version of the document where Figure 3 is. > > >>>>> jhead>> I cannot do this as the link you sent me is broken. If you > > >>>>> send me a fixed link / syntactical example of how to add the pointer, > > >>>>> I will add it or you can add it if that’s easier. > > >>>>> > > >>>>> 39) <!-- [rfced] The sourcecode element in Sections 7.2 > > >>>>> (common.thrift) > > >>>>> contains lines that are too long for the line-length limitation of > > >>>>> the text output. Please let us know how we may wrap the text to fit > > >>>>> within 69 characters per line (or please update the XML source > > >>>>> file). > > >>>>> > > >>>>> FYI, we added line breaks and adjusted whitespace in sourcecode > > >>>>> elements > > >>>>> in the following sections to fit the limit. Please review. > > >>>>> Section 6.3.3 (TIEHeader Comparison Function) > > >>>>> Section 7.3 (encoding.thrift) > > >>>>> --> > > >>>>> > > >>>>> jhead>> I’ve fixed all instances in 7.2 > > >>>>> > > >>>>> 40) <!--[rfced] Please review the "type" attribute of each sourcecode > > >>>>> element > > >>>>> in the XML file to ensure correctness. If the current list of > > >>>>> preferred > > >>>>> values for "type" > > >>>>> (https://urldefense.com/v3/__https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types__;!!NEt6yMaO-gk!DvhlYJjwDvmKheQ1Utsr8x7uFX3j5uE9GyxeAWQq1UDV5AT4xhBdBQMpyXP9EgfU9iLJmIaEg5POujbjXQmev9E$ > > >>>>> ) > > >>>>> does not contain an applicable type, then feel free to let us know. > > >>>>> Also, it is acceptable to leave the "type" attribute not set. > > >>>>> --> > > >>>>> > > >>>>> jhead>> I’ve unset the type attribute for all instances in the > > >>>>> document. > > >>>>> > > >>>>> 41) <!-- [rfced] Regarding <em> and <strong> elements: > > >>>>> > > >>>>> In the HTML and PDF outputs, <em> yields italics. > > >>>>> In the text output, <em> yields an underscore before and after. > > >>>>> > > >>>>> In the HTML and PDF outputs, <strong> yields bold. > > >>>>> In the text output, <strong> yields an asterisk before and after. > > >>>>> > > >>>>> Please review the occurrences and let us know if any updates are > > >>>>> needed for > > >>>>> consistency. > > >>>>> jhead>> I’ve already made updates here where necessary. > > >>>>> > > >>>>> --> > > >>>>> > > >>>>> > > >>>>> 42) <!-- [rfced] Some author comments are present in the XML. Please > > >>>>> confirm > > >>>>> that no updates related to these comments are outstanding. Note that > > >>>>> the > > >>>>> comments will be deleted prior to publication. > > >>>>> --> > > >>>>> jhead>> Nothing outstanding from our end. > > >>>>> > > >>>>> > > >>>>> 43) <!-- [rfced] Terminology > > >>>>> > > >>>>> a) Throughout the text, the following terminology appears to be used > > >>>>> inconsistently. Please review these occurrences and let us know > > >>>>> if/how they > > >>>>> may be made consistent. > > >>>>> > > >>>>> Fallen Leaf vs. fallen leaf > > >>>>> holddown vs. hold down > > >>>>> Radix vs. radix > > >>>>> single-plane vs. single plane > > >>>>> North Node TIE vs. node North TIE > > >>>>> South Node TIE vs. Node South TIE > > >>>>> north prefix TIE vs. Prefix North TIE > > >>>>> South Prefix TIE vs. south prefix TIE vs. Prefix South TIE vs. > > >>>>> prefix South TIE > > >>>>> superspine vs. super-spine > > >>>>> jhead>> Used “fallen leaf” except in instances where the words are > > >>>>> part of a title or term. > > >>>>> jhead>> All instances of “hold down” were changed to “holddown” > > >>>>> jhead>> All instances of “single plane” are now “single-plane” > > >>>>> jhead>> All instances of specific TIE types (e.g., node North TIE, > > >>>>> etc.) are now converged on Direction + Type (e.g., North Node TIE, > > >>>>> South Prefix TIE, etc.) > > >>>>> jhead>> All instances of “super-spine” are now “superspine”. > > >>>>> > > >>>>> b) We note that there is mixed usage of the terms listed below > > >>>>> throughout > > >>>>> the document. May we update to the form on the right? > > >>>>> > > >>>>> fat tree vs. Fat Tree > > >>>>> Key ID vs. key ID > > >>>>> leaf-2-leaf vs. leaf-to-leaf > > >>>>> > > >>>>> jhead>> “Fat Tree” is now “fat tree” except in instances of titles, > > >>>>> registries, etc. > > >>>>> jhead>> “key ID” is fine, no changes are required. > > >>>>> jhead>> “leaf-to-leaf” is the correct long form of the term. > > >>>>> > > >>>>> c) May we update "non-significant bits" to "insignificant bits"? > > >>>>> > > >>>>> Original (2 instances): > > >>>>> The non-significant bits can be used for operational purposes. > > >>>>> > > >>>>> jhead>> No, non-significant is correct. > > >>>>> > > >>>>> d) May this misspelling be corrected? Apparently "multiplier" was > > >>>>> intended. > > >>>>> > > >>>>> multiple_neighbors_lie_holdtime_multipler (5 instances) > > >>>>> -> multiple_neighbors_lie_holdtime_multiplier > > >>>>> > > >>>>> multipler for default ... -> multiplier for default ... > > >>>>> --> > > >>>>> > > >>>>> jhead>> Yes, I’ve fixed all instances to now say “multiplier”. > > >>>>> > > >>>>> 44) <!-- [rfced] Acronyms > > >>>>> > > >>>>> a) FYI - We have added expansions for the following abbreviations > > >>>>> per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each > > >>>>> expansion in the document carefully to ensure correctness. > > >>>>> > > >>>>> Bidirectional Forwarding Detection (BFD) > > >>>>> Internet of Things (IoT) > > >>>>> Layer 3 (L3) > > >>>>> Locator/ID Separation Protocol (LISP) > > >>>>> MAC Address Block Large (MA-L) > > >>>>> Virtual eXtensible Local Area Network (VXLAN) > > >>>>> > > >>>>> b) Should the following acronym be expanded? > > >>>>> > > >>>>> RND > > >>>>> jhead>> No. > > >>>>> > > >>>>> c) Which form should the following acronyms be expanded as? > > >>>>> > > >>>>> AF = Assured Forwarding vs. Address Family vs. Appointed Forwarder > > >>>>> IDL = interface definition language vs. Interface Description > > >>>>> Language > > >>>>> L2L = Leaf-to-Leaf vs. leaf-2-leaf > > >>>>> > > >>>>> jhead>> Address Family for AF is correct. I changed the instances to > > >>>>> their expanded form. > > >>>>> jhead>> Interface Description Language for IDL is correct, I expanded > > >>>>> the first instance of it. Do we need to expand for the rest as well? > > >>>>> jhead>> Leaf-to-Leaf for L2L, I didn’t change anything because it’s > > >>>>> one of the defined terms in the glossary. > > >>>>> > > >>>>> d) After their first expansion, may we update all instances of the > > >>>>> following > > >>>>> expanded forms to be their corresponding acronyms? > > >>>>> > > >>>>> East-West (E-W) > > >>>>> flood repeater (FR) > > >>>>> key identifiers (key ID) > > >>>>> leaf-2-leaf (L2L) > > >>>>> link state database (LSDB) > > >>>>> --> > > >>>>> > > >>>>> jhead>> Let’s leave “East-West” and “Flood Repeater” as is, changing > > >>>>> those might be confusing. The remaining terms can be flipped to their > > >>>>> acronyms. > > >>>>> jhead>> I have compressed all instances of every other term to their > > >>>>> acronyms (unless it is the first instance, which is expanded) > > >>>>> > > >>>>> 45) <!-- [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!DvhlYJjwDvmKheQ1Utsr8x7uFX3j5uE9GyxeAWQq1UDV5AT4xhBdBQMpyXP9EgfU9iLJmIaEg5POujbjQHMFZIQ$ > > >>>>> > > > >>>>> and let us know if any changes are needed. Updates of this nature > > >>>>> typically > > >>>>> result in more precise language, which is helpful for readers. > > >>>>> > > >>>>> For example, please consider whether the following should be updated: > > >>>>> man in the middle > > >>>>> > > >>>>> jhead>> The inclusivity aspect was reviewed during the IESG phase > > >>>>> (thanks, Alvaro!). This is one of the exceptions where it refers to a > > >>>>> specific type of security attack. There is no alternative. > > >>>>> > > >>>>> In addition, please consider whether "traditional" should be updated > > >>>>> for clarity. > > >>>>> jhead>> Changed two instances of “traditional” to “typical”. > > >>>>> > > >>>>> While the NIST website > > >>>>> <https://urldefense.com/v3/__https://www.nist.gov/nist-research-library/nist-technical-series-publications-author-instructions*table1__;Iw!!NEt6yMaO-gk!DvhlYJjwDvmKheQ1Utsr8x7uFX3j5uE9GyxeAWQq1UDV5AT4xhBdBQMpyXP9EgfU9iLJmIaEg5POujbjbB8xY_w$ > > >>>>> > > > >>>>> indicates that this term is potentially biased, it is also ambiguous. > > >>>>> --> > > >>>>> > > >>>>> > > >>>>> Thank you. > > >>>>> > > >>>>> RFC Editor/ap/ar > > >>>>> > > >>>>> > > >>>>> > > >>>>> On Dec 9, 2024, rfc-edi...@rfc-editor.org wrote: > > >>>>> > > >>>>> *****IMPORTANT***** > > >>>>> > > >>>>> Updated 2024/12/09 > > >>>>> > > >>>>> 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!DvhlYJjwDvmKheQ1Utsr8x7uFX3j5uE9GyxeAWQq1UDV5AT4xhBdBQMpyXP9EgfU9iLJmIaEg5POujbjdSv7gVQ$ > > >>>>> ). > > >>>>> > > >>>>> 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 – > > >>>>> https://urldefense.com/v3/__https://trustee.ietf.org/license-info__;!!NEt6yMaO-gk!DvhlYJjwDvmKheQ1Utsr8x7uFX3j5uE9GyxeAWQq1UDV5AT4xhBdBQMpyXP9EgfU9iLJmIaEg5POujbjovk2NmU$ > > >>>>> ). > > >>>>> > > >>>>> * 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!DvhlYJjwDvmKheQ1Utsr8x7uFX3j5uE9GyxeAWQq1UDV5AT4xhBdBQMpyXP9EgfU9iLJmIaEg5POujbjSADZWe8$ > > >>>>> >. > > >>>>> > > >>>>> * 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 ‘REPLY ALL’ as all > > >>>>> the parties CCed on this message need to see your changes. The parties > > >>>>> include: > > >>>>> > > >>>>> * your coauthors > > >>>>> > > >>>>> * rfc-edi...@rfc-editor.org (the RPC team) > > >>>>> > > >>>>> * other document participants, depending on the stream (e.g., > > >>>>> IETF Stream participants are your working group chairs, the > > >>>>> responsible ADs, and the document shepherd). > > >>>>> > > >>>>> * auth48archive@rfc-editor.org, which is a new archival mailing list > > >>>>> to preserve AUTH48 conversations; it is not an active discussion > > >>>>> list: > > >>>>> > > >>>>> * More info: > > >>>>> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc__;!!NEt6yMaO-gk!DvhlYJjwDvmKheQ1Utsr8x7uFX3j5uE9GyxeAWQq1UDV5AT4xhBdBQMpyXP9EgfU9iLJmIaEg5POujbjkiCF7Wo$ > > >>>>> > > >>>>> * The archive itself: > > >>>>> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/browse/auth48archive/__;!!NEt6yMaO-gk!DvhlYJjwDvmKheQ1Utsr8x7uFX3j5uE9GyxeAWQq1UDV5AT4xhBdBQMpyXP9EgfU9iLJmIaEg5POujbjY2FgrPw$ > > >>>>> > > >>>>> * 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 > > >>>>> — OR — > > >>>>> 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 ‘REPLY ALL’, > > >>>>> 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/rfc9692.xml__;!!NEt6yMaO-gk!DvhlYJjwDvmKheQ1Utsr8x7uFX3j5uE9GyxeAWQq1UDV5AT4xhBdBQMpyXP9EgfU9iLJmIaEg5POujbj2oNpkI8$ > > >>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9692.html__;!!NEt6yMaO-gk!DvhlYJjwDvmKheQ1Utsr8x7uFX3j5uE9GyxeAWQq1UDV5AT4xhBdBQMpyXP9EgfU9iLJmIaEg5POujbj5LFHVHY$ > > >>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9692.pdf__;!!NEt6yMaO-gk!DvhlYJjwDvmKheQ1Utsr8x7uFX3j5uE9GyxeAWQq1UDV5AT4xhBdBQMpyXP9EgfU9iLJmIaEg5POujbjCUyDetU$ > > >>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9692.txt__;!!NEt6yMaO-gk!DvhlYJjwDvmKheQ1Utsr8x7uFX3j5uE9GyxeAWQq1UDV5AT4xhBdBQMpyXP9EgfU9iLJmIaEg5POujbj-zrHYQk$ > > >>>>> > > >>>>> Diff file of the text: > > >>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9692-diff.html__;!!NEt6yMaO-gk!DvhlYJjwDvmKheQ1Utsr8x7uFX3j5uE9GyxeAWQq1UDV5AT4xhBdBQMpyXP9EgfU9iLJmIaEg5POujbjYjQxU8o$ > > >>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9692-rfcdiff.html__;!!NEt6yMaO-gk!DvhlYJjwDvmKheQ1Utsr8x7uFX3j5uE9GyxeAWQq1UDV5AT4xhBdBQMpyXP9EgfU9iLJmIaEg5POujbjc0_npQI$ > > >>>>> (side by side) > > >>>>> > > >>>>> Diff of the XML: > > >>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9692-xmldiff1.html__;!!NEt6yMaO-gk!DvhlYJjwDvmKheQ1Utsr8x7uFX3j5uE9GyxeAWQq1UDV5AT4xhBdBQMpyXP9EgfU9iLJmIaEg5POujbjVcGPHL0$ > > >>>>> > > >>>>> > > >>>>> Tracking progress > > >>>>> ----------------- > > >>>>> > > >>>>> The details of the AUTH48 status of your document are here: > > >>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9692__;!!NEt6yMaO-gk!DvhlYJjwDvmKheQ1Utsr8x7uFX3j5uE9GyxeAWQq1UDV5AT4xhBdBQMpyXP9EgfU9iLJmIaEg5POujbjbhotpcE$ > > >>>>> > > >>>>> Please let us know if you have any questions. > > >>>>> > > >>>>> Thank you for your cooperation, > > >>>>> > > >>>>> RFC Editor > > >>>>> > > >>>>> -------------------------------------- > > >>>>> RFC9692 (draft-ietf-rift-rift-24) > > >>>>> > > >>>>> Title : RIFT: Routing in Fat Trees > > >>>>> Author(s) : T. Przygienda, J. Head, A. Sharma, P. Thubert, B. > > >>>>> Rijsman, D. Afanasiev > > >>>>> WG Chair(s) : Zhaohui (Jeffrey) Zhang, Jeff Tantsura > > >>>>> Area Director(s) : Jim Guichard, John Scudder, Gunter Van de > > >>>>> Velde<rfc9692.jhead.xml><rfc9692.jhead.1.xml> > > >>>> > > >>>> > > >>> > > >> > > -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
