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://www.rfc-editor.org/auth48/rfc9692
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
