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://www.rfc-editor.org/authors/rfc9692.html#lie-fsm-figure https://www.rfc-editor.org/authors/rfc9692.html#normative-ztp-fsm 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> -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
