Authors and AD*, Authors, while reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in GitHub issues (see https://github.com/rfc-editor/AUTH48-rfc9971/issues).
*AD, please see question #1 below (also listed at https://github.com/rfc-editor/AUTH48-rfc9971/issues/2). If needed, you may comment in the issue to discuss, but we require approval via email. 1) <!-- [rfced] AD, the following update was made to the Acknowledgements section per the author response to the document intake form. Please review and approve this change. You may also view this change at https://www.rfc-editor.org/authors/rfc9971-diff.html or in the GitHub repo. OLD: Many thanks to Alec Hothan of the OPNFV NFVbench project for a thorough review and numerous useful comments and suggestions in the earlier versions of this document. NEW: Many thanks to the Linux Foundation FastData I/O (FD.io) project, specifically committers and contributors to the two core projects of FD.io: VPP and CSIT. It was there where MLRsearch need originally came up, and it was in FD.io CSIT labs where the first MLRsearch open-source code got prototyped and then over the years productized. Thanks also goes to Alec Hothan of the OPNFV NFVbench project for a thorough review and numerous useful comments and suggestions in the earlier draft versions of this document. --> 2) <!-- [rfced] FYI - We made some editorial updates to the references in the References section to match RFC Style Guidance. Please review and let us know if you have any objections. --> 3) <!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on https://www.rfc-editor.org/search. --> 4) <!--[rfced] May we update "possible discovered throughput values" to "throughput values that could be discovered" at the end of this sentence? Original: * Software DUTs show noisy trial results, leading to a big spread of possible discovered throughput values. Perhaps: * Software DUTs show noisy trial results, leading to a big spread of throughput values that could be discovered. --> 5) <!--[rfced] How may we clarify the citation and text within the parentheses? Original: * Throughput requires a loss of exactly zero frames, but the industry best practices frequently allow for low but non-zero losses tolerance ([Y.1564], test-equipment manuals). Perhaps: * Throughput requires a loss of exactly zero frames, but the industry best practices frequently allow for tolerance of low but non-zero losses (see [Y.1564] and test-equipment manuals for more information). --> 6) <!-- [rfced] Would combining these sentences/paragraphs be helpful? Note that "implementation details" is mentioned in both. Original: Enhancements 1, 2 and partly 4 are formalized as MLRsearch Specification within this document, other implementation details are out the scope. The remaining enhancements are treated as implementation details, thus achieving high comparability without limiting future improvements. Perhaps: Enhancements 1, 2 and partly 4 are formalized as the MLRsearch Specification within this document. The remaining enhancements are treated as implementation details and out of scope for this document. This achieves high comparability without limiting future improvements. --> 7) <!--[rfced] To clarify "per term subsection", may we rephrase the text as follows? Original: Each per term subsection contains a short _Definition_ paragraph containing a minimal definition and all strict requirements, followed by _Discussion_ paragraphs focusing on important consequences and recommendations. Perhaps: Each subsection defining a term contains a short "Definition" paragraph containing a minimal definition and all strict requirements, followed by "Discussion" paragraphs focusing on important consequences and recommendations. --> 8) <!-- [rfced] Regarding "In some discussion paragraphs" in the sentence, is the intent to refer to the discussion parapraphs in Section 4.5 ("Trial Terms")? Or is the current correct? Original: In some discussion paragraphs, it is useful to consider the traffic as sent and received by a tester, as implicitly defined in Section 6 of [RFC2544]. Perhaps: In some "Discussion" paragraphs in Section 4.5, it is useful to consider the traffic as sent and received by a tester, as implicitly defined in Section 6 of [RFC2544]. --> 9) <!-- [rfced] Would updating "capitalized verbs" as follows be helpful/correct? Original: The definition describes some traits, not using capitalized verbs to signify strength of the requirements. Perhaps: The definition above describes some traits but does not use key words as defined in BCP 14 [RFC2119] [RFC8174] to signify the strength of the requirements. --> 10) <!--[rfced] As these two paragraphs are related, we have combined them into one paragraph. Please let us know of any objections. Original: The last paragraph also applies to other terms related to Load. For example, tests with symmetric bidirectional traffic can report load-related values as "bidirectional load" (double of "unidirectional load"). Current: The previous paragraph also applies to other terms related to Load. For example, tests with symmetric bidirectional traffic can report load-related values as "bidirectional load" (double of "unidirectional load"). --> 11) <!-- [rfced] Section 4.5.2 is titled "Trial Load", but we see a few instances of "Traffic Load" in the sentences below. Please review and let us know if any updates are needed. Original: Informally, Traffic Load is a single number that can "scale" any traffic pattern as long as the intuition of load intended against a single interface can be applied. ... In the case of a non-constant load, the Test Report MUST explicitly mention how exactly non-constant the traffic is and how it reacts to Traffic Load value. ... but again the Test Report MUST explicitly describe how the traffic pattern reacts to Traffic Load value, and this specification does not discuss all the implications of that approach. --> 12) <!--[rfced] May we update "in a detail sufficient to" to "in sufficient enough detail to" to improve readability of the text? Original: Only if this is not the case, the test report MUST describe the Traffic Profile in a detail sufficient to imply how Trial Forwarding Ratio should be calculated. Perhaps: However, if this is not the case, the test report MUST describe the Traffic Profile in sufficient enough detail to imply how the Trial Forwarding Ratio should be calculated. --> 13) <!--[rfced] Again, as these two paragraphs are connected, we have combined these into one paragraph. Please let us know of any objections. Original: Note that, contrary to Load terms, frame counts used to compute Trial Forwarding Ratio are generally aggregates over all SUT output interfaces, as most test procedures verify all outgoing frames. The procedure for {{RFC2544}} Throughput counts received frames, so implicitly it implies bidirectional counts for bidirectional traffic, even though the final value is "rate" that is still per-interface. For example, in a test with symmetric bidirectional traffic, if one direction is forwarded without losses but the opposite direction does not forward at all, the Trial Forwarding Ratio would be 0.5 (50%). Current: Note that, contrary to Load terms, frame counts used to compute Trial Forwarding Ratio are generally aggregates over all SUT output interfaces, as most test procedures verify all outgoing frames. The procedure for {{RFC2544}} Throughput counts received frames, so implicitly it implies bidirectional counts for bidirectional traffic, even though the final value is "rate" that is still per-interface. For example, in a test with symmetric bidirectional traffic, if one direction is forwarded without losses, but the opposite direction does not forward at all, the Trial Forwarding Ratio would be 0.5 (50%). --> 14) <!--[rfced] The following text in Section 4.5.6 is a sentence fragment; please review and let us know how it may be updated to be a complete sentence. Original: 100% minus the Trial Forwarding Ratio, when expressed as a percentage. --> 15) <!-- [rfced] We do not see the phrase "Controller calls Measurer" elsewhere in the document. Are any updates needed? Original: For example, when MLRsearch Specification mentions "Controller calls Measurer", it is possible that the Controller notifies the Manager to call the Measurer indirectly instead. --> 16) <!--[rfced] Please review "big freedom" here. Would "considerable freedom", "broad discretion", or something similar be a better word choice? Original: Informally, the Controller has big freedom in selection of Trial Inputs, and the implementations want to achieve all the Search Goals in the shortest average time. --> 17) <!--[rfced] To clarify the text, may we update "SUT, the Measurer" to "SUT and the Measurer"? Does this retain the intended meaning? Original: The Manager initializes the SUT, the Measurer (and the tester if independent from Measurer) with their intended configurations before calling the Controller. Perhaps: The Manager initializes the SUT and the Measurer (and the tester if independent from Measurer) with their intended configurations before calling the Controller. --> 18) <!-- [rfced] We note that Section 7 of [RFC2544] is titled "DUT set up" and "SUT" is not mentioned in that document. Please review the citation in this sentence and let us know if any updates are needed. Original: Note that Section 7 of [RFC2544] already puts requirements on SUT setups: --> 19) <!--[rfced] Should a citation be included for the pointer to the "802.3 IEEE standard"? If yes, please provide us with the reference information. Original: For example, Section 5.1.1 of [RFC5180] recommends testing jumbo frames if SUT can forward them, even though they are outside the scope of the 802.3 IEEE standard. --> 20) <!-- [rfced] May we put this note into 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). Original: Note: For clarity of explanation, variables are tagged as (I)nput, (T)emporary, (O)utput. --> 21) <!--[rfced] It is unclear how "is called" fits into this sentence. Should "is called" be removed here? Note that similar text elsewhere in the document does not include "is called". Original: - Subceed ratio (T) is one minus the Goal Exceed Ratio (I) is called. Perhaps: - Subceed ratio (T) is one minus the Goal Exceed Ratio (I). --> 22) <!-- [rfced] Should "Effective Trial Duration" here be updated to "Trial Effective Duration" (as defined in Section 4.5.8)? Original: In all Trials, the Effective Trial Duration is equal to Trial Duration. Perhaps: In all Trials, the Trial Effective Duration is equal to Trial Duration. --> 23) <!-- [rfced] Formatting a) The goals in Appendix C.1 and the points in Appendix C.1 currently convert to <artwork> in the XML. We believe that these should be <dl> (see https://authors.ietf.org/rfcxml-vocabulary#dl). Please confirm. If you agree, we will make this change when we convert the document to XML. b) The following was noted in response to the document intake form: We also use backticks in appendices A and B (for full and partial variable names). But we are not sure what effect it has, as all text in HTMLized draft is already fixed-width. FYI that the backticks in the markdown file produce <tt> in the XML file. In the HTML and PDF outputs, <tt> produces fixed-width font with a slight background shading; in the TXT output, there is no text styling. We reviewed the backticks, and the usage appears to be consistent in the document. However, note that we did update to use quotation marks for parts of variable names, e.g., "_s" and "_sum". c) In Section 4.7 ("Auxiliary Terms"), if no objections, we will update the "**" formatting to quotation marks. The "**" in the markdown file produces the <strong> element when converted to XML. The <strong> element is used for "text that is semantically strong"; see https://authors.ietf.org/rfcxml-vocabulary#strong. Note that <strong> produces bold in the HTML and PDF outputs and produces an asterisk before and after the text in the TXT output. In addition, for the following sentences in Section 4.7, we will also use quotation marks for the terms "lossy trial" and "zero-loss trial": Current: A trial with Trial Loss Ratio larger than a Goal Loss Ratio value is called a *high-loss trial*, with respect to given Search Goal (or lossy trial, if Goal Loss Ratio is zero). ... If a trial is not high-loss, it is called a *low-loss trial* (or zero-loss trial, if Goal Loss Ratio is zero). Perhaps: A trial with a Trial Loss Ratio larger than a Goal Loss Ratio value is called a "high-loss trial", with respect to the given Search Goal (or "lossy trial", if Goal Loss Ratio is zero). ... If a trial is not high-loss, it is called a "low-loss trial" (or "zero-loss trial", if the Goal Loss Ratio is zero). --> 24) <!--[rfced] Abbreviations 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. Application-Specific Integrated Circuit (ASIC) Field-Programmable Gate Array (FPGA) Internet Mix (IMIX) Network Processing Unit (NPU) b) Both the expansion and the acronym for the following terms are used throughout the document. Would you like to update to using the expansion upon first usage and the acronym for the rest of the document for consistency? frames per second (fps) million frames per second (Mfps) Multiple Loss Ratio search (MLRsearch) c) How should "MAC" be expanded in the sentence below? As "Media Access Control", "Medium Access Control", "Message Authentication Code", "Mandatory Access Control", or something else? Original: It is RECOMMENDED to interpret the "learning frames" to be any such time-sensitive per-trial configuration method, with bridge MAC learning being only one possible examples. d) How should "NIC" be expanded in the sentence below? As "Network Interface Card", "Network Information Center", "Network Interface Controller", or something else? Original: Even if bandwidth of a medium allows higher traffic forwarding performance, the SUT interfaces may have their additional own limitations, e.g., a specific frames-per-second limit on the NIC (a common occurrence). --> 25) <!-- [rfced] Terminology: a) The following text about capitalization of terms defined in this document appears in Sections 1 and 4: Original: If a phrase appears with the first letters capitalized, it likely refers to a specific term defined in an eponymous subsection of "MLRsearch Specification" (Section 4). ... Some terms used in the specification are capitalized. It is just a stylistic choice for this document, reminding the reader this term is introduced, defined or explained elsewhere in the document. Lower case variants are equally valid. The following terms are defined in Section 4 of this document and appear in the document with inconsistent capitalization. We did not make any changes per the text above, but please review and let us know if you would like to make any updates for consistency. Binary Search vs. binary search Exceed Probability vs. exceed probability Full-Length Trial vs. full-length trial High-Loss Trial vs. high-loss trial Inconsistent Trial Result vs. inconsistent trial result Load Classification Logic vs. Load Classification logic Low-Loss Trial vs. Low-Loss trial vs. low-loss trial Lower Bound vs. lower bound vs. lower-bound Search Duration vs. search duration Search Goal vs. Search goal vs. search goal Search Result vs. search result Short Trial vs. short trial Test Report vs. test report Traffic Profile vs. traffic profile Trial Forwarding Rate vs. trial forward rate Trial Result vs. trial result Upper Bound vs. upper bound vs. upper-bound Trial vs. trail Trial Duration vs. trial duration b) We note inconsistencies in the terms below. Please review these occurrences and let us know if/how they may be made consistent. [RFC2544] Throughput vs. [RFC2544] throughput Full-Length Low-Loss Trial vs. full-length low-loss trial Load vs. load Offered Load vs. offered load Search vs. search multiple-goal vs. multi-goal vs. many-goal --> 26) <!-- [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. Note that our script did not flag any words in particular, but this should still be reviewed as a best practice. --> Thank you. Alanna Paloma and Rebecca VanRheenen RFC Production Center On May 13, 2026, at 10:04 PM, [email protected] wrote: *****IMPORTANT***** Updated 2026/05/13 RFC Author(s): -------------- Your document has now entered AUTH48. The document was edited in kramdown-rfc as part of the RPC pilot test (see https://www.rfc-editor.org/rpc/wiki/doku.php?id=pilot_test_kramdown_rfc). AUTH48 is being handled in GitHub as part of the GitHub pilot test (see https://www.rfc-editor.org/rpc/wiki/doku.php?id=rpc-github-phase-0-pilot-test). Your document is available for review at: https://github.com/rfc-editor/AUTH48-rfc9971 Please do the following: a) provide your GitHub usernames so that we can add you as collaborators to the GitHub repo and accept the invitations once they are sent. b) see the README for details on the AUTH48 process: https://github.com/rfc-editor/AUTH48-rfc9971/blob/Approved/README.md c) review and resolve the issues: https://github.com/rfc-editor/AUTH48-rfc9971/issues Once the content of the .md file is stable, we will convert it to .xml and provide the .html, .pdf, .txt, and .xml files for review. You and your coauthor are responsible for engaging other parties (e.g., Contributors or Working Group) as necessary before providing your approval. Once the document has been reviewed and approved by all of the authors, 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/). Please let us know if you have any questions. Thank you for your cooperation, RFC Editor -------------------------------------- RFC9971 (draft-ietf-bmwg-mlrsearch-15) Title : Multiple Loss Ratio Search Author(s) : M. Konstantynowicz, V. Polák WG Chair(s) : Sarah Banks, Giuseppe Fioccola Area Director(s) : Mohamed Boucadair, Mahesh Jethanandani -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
