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://github.com/cabo/kramdown-rfc/wiki/SVG#svg-id-collisions. > 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). > 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://www.rfc-editor.org/authors/rfc9692.txt>. 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://www.rfc-editor.org/rfc/rfc9692.html) 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. ... 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 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
