Yes, slowly coming up to the top of my list after a large project here is being handed off after couple months of hard work.
First week Mar’, maybe before > On 10 Feb 2025, at 17:40, Alanna Paloma <[email protected]> wrote: > > [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!GjV1czP391CNVd_pv1aWBk49yKZtUGw1J7ngPSaA0QaGHiYAaG8zixrnfmN_K0NPhXkwHQuahAEpbbEKE0CEVbU$ > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9692.txt__;!!NEt6yMaO-gk!GjV1czP391CNVd_pv1aWBk49yKZtUGw1J7ngPSaA0QaGHiYAaG8zixrnfmN_K0NPhXkwHQuahAEpbbEKPOU9Khw$ > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9692.html__;!!NEt6yMaO-gk!GjV1czP391CNVd_pv1aWBk49yKZtUGw1J7ngPSaA0QaGHiYAaG8zixrnfmN_K0NPhXkwHQuahAEpbbEKoPY2Vt4$ > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9692.pdf__;!!NEt6yMaO-gk!GjV1czP391CNVd_pv1aWBk49yKZtUGw1J7ngPSaA0QaGHiYAaG8zixrnfmN_K0NPhXkwHQuahAEpbbEKNE-ERUc$ > > The relevant diff files have been posted here: > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9692-diff.html__;!!NEt6yMaO-gk!GjV1czP391CNVd_pv1aWBk49yKZtUGw1J7ngPSaA0QaGHiYAaG8zixrnfmN_K0NPhXkwHQuahAEpbbEKTR9TRpU$ > (comprehensive diff) > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9692-auth48diff.html__;!!NEt6yMaO-gk!GjV1czP391CNVd_pv1aWBk49yKZtUGw1J7ngPSaA0QaGHiYAaG8zixrnfmN_K0NPhXkwHQuahAEpbbEKZilcDDI$ > (AUTH48 changes) > > For the AUTH48 status of this document, please see: > https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9692__;!!NEt6yMaO-gk!GjV1czP391CNVd_pv1aWBk49yKZtUGw1J7ngPSaA0QaGHiYAaG8zixrnfmN_K0NPhXkwHQuahAEpbbEK_qPTKLA$ > > Best regards, > RFC Editor/ap > >> On Jan 29, 2025, at 10:12 AM, Antoni Przygienda <[email protected]> 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 <[email protected]> >>> 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 <[email protected]> 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 <[email protected]> >>>> Date: Wednesday, January 22, 2025 at 11:26 AM >>>> To: Antoni Przygienda <[email protected]>, Jordan Head <[email protected]>, >>>> [email protected] <[email protected]> >>>> Cc: Alankar Sharma <[email protected]>, >>>> [email protected]<[email protected]>, >>>> [email protected]<[email protected]>, [email protected] >>>> <[email protected]>, [email protected] <[email protected]>, >>>> [email protected] <[email protected]>, [email protected] >>>> <[email protected]>, [email protected] >>>> <[email protected]>, [email protected] >>>> <[email protected]> >>>> 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 <[email protected]> >>>>> 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 <[email protected]> wrote: >>>>>> >>>>>> Please record my approval. Thanks for all the hard work. >>>>>> >>>>>> Regards, >>>>>> Alankar >>>>>> >>>>>> On Wed, Jan 8, 2025 at 7:32 PM Alanna Paloma >>>>>> <[email protected]> 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 <[email protected]> wrote: >>>>>>> >>>>>>> I’ve attached the new XML document that addresses the issues you >>>>>>> mentioned. >>>>>>> Thank you >>>>>>> Jordan >>>>>>> >>>>>>> Juniper Business Use Only >>>>>>> From: Jordan Head <[email protected]> >>>>>>> Date: Wednesday, January 8, 2025 at 3:28 PM >>>>>>> To: Alanna Paloma <[email protected]> >>>>>>> Cc: [email protected] <[email protected]>, Antoni >>>>>>> Przygienda <[email protected]>, [email protected] <[email protected]>, >>>>>>> [email protected] <[email protected]>, >>>>>>> [email protected] <[email protected]>, >>>>>>> [email protected]<[email protected]>, [email protected] >>>>>>> <[email protected]>, [email protected] <[email protected]>, >>>>>>> [email protected]<[email protected]>, >>>>>>> [email protected]<[email protected]>, >>>>>>> [email protected]<[email protected]> >>>>>>> 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 <[email protected]> >>>>>>> Date: Wednesday, January 8, 2025 at 2:45 PM >>>>>>> To: Jordan Head <[email protected]> >>>>>>> Cc: [email protected] <[email protected]>, Antoni >>>>>>> Przygienda <[email protected]>, [email protected] <[email protected]>, >>>>>>> [email protected] <[email protected]>, >>>>>>> [email protected] <[email protected]>, >>>>>>> [email protected]<[email protected]>, [email protected] >>>>>>> <[email protected]>, [email protected] <[email protected]>, >>>>>>> [email protected]<[email protected]>, >>>>>>> [email protected]<[email protected]>, >>>>>>> [email protected]<[email protected]> >>>>>>> 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 <[email protected]> to >>>>>>> <[email protected]>.] >>>>>>> >>>>>>> Thank you, >>>>>>> RFC Editor/ap >>>>>>> >>>>>>>> On Jan 8, 2025, at 5:29 AM, Jordan Head >>>>>>>> <[email protected]> wrote: >>>>>>>> >>>>>>>> Thank you for the update, replies/comments inline as jhead>> >>>>>>>> >>>>>>>> Juniper Business Use Only >>>>>>>> From: Alanna Paloma <[email protected]> >>>>>>>> Date: Tuesday, January 7, 2025 at 5:01 PM >>>>>>>> To: Jordan Head <[email protected]> >>>>>>>> Cc: [email protected] <[email protected]>, Antoni >>>>>>>> Przygienda <[email protected]>, [email protected] <[email protected]>, >>>>>>>> [email protected] <[email protected]>, >>>>>>>> [email protected]<[email protected]>, >>>>>>>> [email protected]<[email protected]>, [email protected] >>>>>>>> <[email protected]>, [email protected] <[email protected]>, >>>>>>>> [email protected]<[email protected]>, >>>>>>>> [email protected]<[email protected]>, >>>>>>>> [email protected]<[email protected]> >>>>>>>> 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 >>>>>>>>> <[email protected]> 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: [email protected] <[email protected]> >>>>>>>>> Date: Monday, December 9, 2024 at 5:57 PM >>>>>>>>> To: Antoni Przygienda <[email protected]>, Jordan Head >>>>>>>>> <[email protected]>, [email protected] <[email protected]>, >>>>>>>>> [email protected]<[email protected]>, >>>>>>>>> [email protected]<[email protected]>, >>>>>>>>> [email protected]<[email protected]> >>>>>>>>> Cc: [email protected] <[email protected]>, >>>>>>>>> [email protected] <[email protected]>, [email protected] >>>>>>>>> <[email protected]>, [email protected] >>>>>>>>> <[email protected]>, >>>>>>>>> [email protected]<[email protected]>,[email protected]<[email protected]> >>>>>>>>> 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, [email protected] 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 >>>>>>>>> >>>>>>>>> * [email protected] (the RPC team) >>>>>>>>> >>>>>>>>> * other document participants, depending on the stream (e.g., >>>>>>>>> IETF Stream participants are your working group chairs, the >>>>>>>>> responsible ADs, and the document shepherd). >>>>>>>>> >>>>>>>>> * [email protected], which is a new archival mailing list >>>>>>>>> to preserve AUTH48 conversations; it is not an active discussion >>>>>>>>> list: >>>>>>>>> >>>>>>>>> * More info: >>>>>>>>> >>>>>>>>> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/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, >>>>>>>>> [email protected] will be re-added to the CC list and >>>>>>>>> its addition will be noted at the top of the message. >>>>>>>>> >>>>>>>>> You may submit your changes in one of two ways: >>>>>>>>> >>>>>>>>> An update to the provided XML file >>>>>>>>> — 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 -- [email protected] To unsubscribe send an email to [email protected]
