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