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