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