Hello Alanna A bientôt;
Pascal > Le 12 déc. 2024 à 22:43, Alanna Paloma <apal...@amsl.com> a écrit : > > Hi Pascal, > > Thank you for your reply. The files have been updated accordingly. > Additionally, we have noted your approval on the AUTH48 status page for this > document. As there are questions that have not yet been addressed, we will > assume your approval stands even after your coauthors submit further changes > unless we hear otherwise at that time. Perfect! > >>> 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. >>> --> >>> >> >> I believe we mean shortcuts that span multiple levels. But the applicability >> draft that is following immediately this draft has more. Could we just >> reference it informationally? > > ) We note that draft-ietf-rift-applicability (which is currently in AUTH48 as > RFC-to-be 9696) is listed as an Informative Reference in this document. > Please let us know if/how you would like this sentence to be updated to > include a citation to that document. > Yes, exactly! Many thanks Pascal > ... > 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 12, 2024, at 7:35 AM, Pascal Thubert <pascal.thub...@gmail.com> wrote: >> >> Dear RFC editor >> >> Many thanks for your hard work. >> >> Speaking for myself only I approve your proposals below (but for beats see >> below) and I approve the draft for publication. >> >> Please see below some words on a small subset of the discussed items. >> In case of disagreement I’ll defer to the main editors, Tony and Jordan. >> >> >> Regards, >> >> Pascal >> >>>> Le 9 déc. 2024 à 23:57, rfc-edi...@rfc-editor.org a écrit : >>> >>> 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. --> >> >> Routing protocol. IGP. Anisotropic routing. Clos. Fat tree. Cloud. Distance >> vector. Link state. Optimized flooding. Zeroconf. >> >>> >>> 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. >>> --> >>> >> >> I believe we mean shortcuts that span multiple levels. But the applicability >> draft that is following immediately this draft has more. Could we just >> reference it informationally? >>> >>> 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. >>> --> >> >> >> >> Looks good! >> >>> 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. >>> --> >>> >> >> Or we just take our “in order.. leaves,” and start with “There are…” >>> >>> 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. >>> --> >>> >> >> Or >> >> 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 the >> failing ToP node is directly connected to its leaf nodes which can detect >> the link going down. Then again, the knowledge of the failure at the ToF >> level can only be useful if it is propagated transitively to all the leaves: >> it is useless above that level since the decision of placing a packet in a >> plane happens at the leaf that injects the packet in the fabric. >> >> >>> >>> 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]. >>> --> >> >> I find it readable; one could say >>> >>> >>> >>> IPv4 LIE exchange happens by default over a well-known IPv4 multicast >>> address [RFC2365] that may 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. >>> --> >>> >>> >> I think "local" and "remote" refer to the columns in the table >> >> >> >>> 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 >>> >>> --> >> >> >> Oups >> >>> >>> >>> 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). >>> --> >>> >> >> >> Yes >> >>> >>> 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 >>> >> >> Yes for me >> >>> >>> 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 >>> >> >> No, it is the name of a variable defined in the last bullet above >> >> >>> 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
