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://www.rfc-editor.org/search. --> 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. --> 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. --> 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. --> 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. --> 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://authors.ietf.org/en/rfcxml-vocabulary#aside). 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. 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. 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. Section 10.3.17 Note: This node's level is already included on the packet header. --> 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. --> 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. --> 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. --> 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. --> 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]. --> 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. --> 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. --> 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; --> 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 --> 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. --> 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. --> 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. --> 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 --> 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. --> 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. --> 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). --> 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. --> 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. --> 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. --> 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: --> 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. --> 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). Perhaps: This schema references [RFC5837], [RFC5880], and [RFC6550]. --> 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. --> 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. --> 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. --> 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. --> 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://www.iana.org/assignments/rift. (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. --> 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. --> 35) <!--[rfced] References a) The original URL for [thrift] goes to a GitHub repository. The web portion of the style guide (https://www.rfc-editor.org/styleguide/part2/#ref_repo) recommends using GitHub repositories for informative references only. We found the site for the Apache Thrift documentation at the following URL: https://thrift.apache.org/docs/. 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://github.com/apache/thrift/tree/0.15.0/doc>. Current: [thrift] Apache Software Foundation, "Apache Thrift Documentation", <https://thrift.apache.org/docs/>. 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 <http://standards.ieee.org/develop/regauth/tut/eui.pdf> to <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>. 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, <http://standards.ieee.org/develop/regauth/tut/eui.pdf>. Current: [EUI64] IEEE, "Guidelines for Use of Extended Unique Identifier (EUI), Organizationally Unique Identifier (OUI), and Company ID (CID)", <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>. d) FYI, RFC 5226 has been obsoleted by RFC 8126. We have replaced usage in this document accordingly. --> 36) <!--[rfced] Should Alankar Sharma's name also be listed in the Contributors section, since the other authors are also listed there? --> 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. 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. 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? Here is an example of SVG where the strings within the SVG are selectable and searchable: https://www.rfc-editor.org/rfc/rfc9576.html#figure-1 --> 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://www.rfc-editor.org/rfc/rfc9692.html) --> 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) --> 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://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types) does not contain an applicable type, then feel free to let us know. Also, it is acceptable to leave the "type" attribute not set. --> 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. --> 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. --> 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 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 c) May we update "non-significant bits" to "insignificant bits"? Original (2 instances): The non-significant bits can be used for operational purposes. 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 ... --> 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 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 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) --> 45) <!-- [rfced] Please review the "Inclusive Language" portion of the online Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> 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 In addition, please consider whether "traditional" should be updated for clarity. While the NIST website <https://www.nist.gov/nist-research-library/nist-technical-series-publications-author-instructions#table1> 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://www.rfc-editor.org/faq/). 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://trustee.ietf.org/license-info). * 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://authors.ietf.org/rfcxml-vocabulary>. * 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://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc * The archive itself: https://mailarchive.ietf.org/arch/browse/auth48archive/ * 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://www.rfc-editor.org/authors/rfc9692.xml https://www.rfc-editor.org/authors/rfc9692.html https://www.rfc-editor.org/authors/rfc9692.pdf https://www.rfc-editor.org/authors/rfc9692.txt Diff file of the text: https://www.rfc-editor.org/authors/rfc9692-diff.html https://www.rfc-editor.org/authors/rfc9692-rfcdiff.html (side by side) Diff of the XML: https://www.rfc-editor.org/authors/rfc9692-xmldiff1.html Tracking progress ----------------- The details of the AUTH48 status of your document are here: https://www.rfc-editor.org/auth48/rfc9692 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 -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
