Hi Jordan, Authors, We have updated the document as described below. Please review and let us know the current files are acceptable. In particular, please review the ordering in Figure 28 of the text file.
The files are available here: https://www.rfc-editor.org/authors/rfc9692.xml https://www.rfc-editor.org/authors/rfc9692.txt https://www.rfc-editor.org/authors/rfc9692.pdf https://www.rfc-editor.org/authors/rfc9692.html Diffs of the most recent updates only: https://www.rfc-editor.org/authors/rfc9692-lastdiff.html https://www.rfc-editor.org/authors/rfc9692-lastrfcdiff.html (side by side) AUTH48 diffs: https://www.rfc-editor.org/authors/rfc9692-auth48diff.html https://www.rfc-editor.org/authors/rfc9692-auth48rfcdiff.html (side by side) Comprehensive diffs: https://www.rfc-editor.org/authors/rfc9692-diff.html https://www.rfc-editor.org/authors/rfc9692-rfcdiff.html (side by side) Thank you, RFC Editor/sg > On Mar 27, 2025, at 4:45 PM, Jordan Head <jh...@juniper.net> wrote: > > Thank you! > > Replies inline > > Sent from my iPhone > >> On Mar 27, 2025, at 6:21 PM, Sandy Ginoza <sgin...@staff.rfc-editor.org> >> wrote: >> >> [External Email. Be cautious of content] >> >> >> Hi Jordan, >> >> Thank you for the quick updates! We’re almost there! >> >> For figures 13 and 18, we recommend treating these in a similar manner to >> figure 3, whereby the text points to the SVG in the html file: >> >> (Artwork only available as SVG: see >> >> https://urldefense.com/v3/__https://www.rfc-editor.org/rfc/rfc9692.html__;!!NEt6yMaO-gk!EqNuRG7PDG5ENMUzMarOMuU2huU3QK1gDX8UvPCwecqm5jy19IYaGpv2JpJtFaUAKYkodtK1v5TSkIWxxG4jGtjF$ >> ) >> > jhead>> Sure, feel free to make that change. >> >> For figure 29 - we understand there is no significance in the order to the >> reader. However, the figures should match as much as possible. To avoid >> updating the SVG, may we update the order in the text to align with the >> order in the SVG? >> > > jhead>> Sure, that’s fine with me. > >> The current files are available here: >> >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9692.xml__;!!NEt6yMaO-gk!EqNuRG7PDG5ENMUzMarOMuU2huU3QK1gDX8UvPCwecqm5jy19IYaGpv2JpJtFaUAKYkodtK1v5TSkIWxxNhafBH8$ >> >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9692.txt__;!!NEt6yMaO-gk!EqNuRG7PDG5ENMUzMarOMuU2huU3QK1gDX8UvPCwecqm5jy19IYaGpv2JpJtFaUAKYkodtK1v5TSkIWxxIfCZ3PT$ >> >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9692.pdf__;!!NEt6yMaO-gk!EqNuRG7PDG5ENMUzMarOMuU2huU3QK1gDX8UvPCwecqm5jy19IYaGpv2JpJtFaUAKYkodtK1v5TSkIWxxMRCN-rd$ >> >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9692.html__;!!NEt6yMaO-gk!EqNuRG7PDG5ENMUzMarOMuU2huU3QK1gDX8UvPCwecqm5jy19IYaGpv2JpJtFaUAKYkodtK1v5TSkIWxxAYLlx-0$ >> >> Diffs highlighting the recent updates: >> >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9692-lastdiff.html__;!!NEt6yMaO-gk!EqNuRG7PDG5ENMUzMarOMuU2huU3QK1gDX8UvPCwecqm5jy19IYaGpv2JpJtFaUAKYkodtK1v5TSkIWxxPRPh0jl$ >> >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9692-lastrfcdiff.html__;!!NEt6yMaO-gk!EqNuRG7PDG5ENMUzMarOMuU2huU3QK1gDX8UvPCwecqm5jy19IYaGpv2JpJtFaUAKYkodtK1v5TSkIWxxM9KjANb$ >> (side by side) >> >> AUTH48 diff: >> >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9692-auth48diff.html__;!!NEt6yMaO-gk!EqNuRG7PDG5ENMUzMarOMuU2huU3QK1gDX8UvPCwecqm5jy19IYaGpv2JpJtFaUAKYkodtK1v5TSkIWxxH-5zVvo$ >> >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9692-auth48rfcdiff.html__;!!NEt6yMaO-gk!EqNuRG7PDG5ENMUzMarOMuU2huU3QK1gDX8UvPCwecqm5jy19IYaGpv2JpJtFaUAKYkodtK1v5TSkIWxxCYUmJVZ$ >> (side by side) >> >> Comprehensive diffs: >> >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9692-diff.html__;!!NEt6yMaO-gk!EqNuRG7PDG5ENMUzMarOMuU2huU3QK1gDX8UvPCwecqm5jy19IYaGpv2JpJtFaUAKYkodtK1v5TSkIWxxE0x4swS$ >> >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9692-rfcdiff.html__;!!NEt6yMaO-gk!EqNuRG7PDG5ENMUzMarOMuU2huU3QK1gDX8UvPCwecqm5jy19IYaGpv2JpJtFaUAKYkodtK1v5TSkIWxxJQB1a6v$ >> (side by side) >> >> >> Thank you, >> RFC Editor/sg >> >> >> >> >>> On Mar 27, 2025, at 10:10 AM, Jordan Head <jh...@juniper.net> wrote: >>> >>> Final version attached. >>> >>> Replies inline as jhead>> >>> >>> >>> Juniper Business Use Only >>> >>> From: Sandy Ginoza <sgin...@staff.rfc-editor.org> >>> Date: Wednesday, March 26, 2025 at 5:56 PM >>> To: Antoni Przygienda <p...@juniper.net> >>> Cc: Pascal Thubert <pascal.thub...@gmail.com>, Jordan Head >>> <jh...@juniper.net>, 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: Discrepancies in the figures - Re: AUTH48: RFC-to-be 9692 >>> <draft-ietf-rift-rift-24> for your review >>> >>> [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) >>> >>> jhead>> Fixed. >>> >>> (none) —> South (2x) >>> >>> jhead>> Fixed. >>> >>> L2L —> (L2L) (includes parentheses) >>> >>> jhead>> Fixed. >>> >>> Multi-homed —> multihomed (we recommend single word and lowercase) >>> >>> jhead>> I updated the ASCII version to match the SVG. The SVGs are a bit >>> fragile and would like to leave them alone at this point unless it’s >>> absolutely necessary. >>> >>> Perhaps shift compass rose so they appear on the same side of the figure? >>> >>> jhead>> Leaving this as is, it has no functional impact to the reader. >>> >>> 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) >>> >>> jhead>> No concerns. >>> >>> B) Figure 6 >>> >>> Top of PoD Node (Spine) —> Top-of-PoD Node (Spine) (Hyphens) >>> >>> jhead>> Fixed. >>> >>> 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 >>> >>> jhead>> Adjusted SVGs to match. >>> >>> 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 >>> >>> jhead>> These are fine as is, we are simply limited by ASCII when showing >>> complex 3D images. >>> >>> 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 >>> >>> jhead>> No concerns. >>> >>> F) Figure 28 >>> >>> A (s) —> (no parentheses) >>> X (L2L) —> (no parentheses) >>> Y (L) —> (no parentheses) >>> >>> jhead>> Leaving this as is, it has no functional impact to the reader. >>> >>> G) Figure 29 - some of the lists appear out of order - please consider >>> updating the lists to they match. >>> >>> jhead>> These these are not lists, but actions/events in the FSM, I’m going >>> to leave this as is considering that the order carries no significance to >>> the reader. >>> >>> >>> 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 >>> >>> jhead>> Adjusted SVG to use 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? >>> >>> >>> jhead>> This will inherit all changes made to Figure 2 as described above. >>> >>> J) Figure 36 >>> (none) —> Failure >>> >>> >>> jhead>> Fixed. >>> >>> >>> >>> 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> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>> >>>> >>> >>> <rfc9692-final.xml> >> -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
