Hi Rebecca, all, Works for me for #1. Thanks.
Cheers, Med > -----Message d'origine----- > De : [email protected] <[email protected]> > Envoyé : jeudi 14 mai 2026 07:12 > À : [email protected]; [email protected] > Cc : [email protected]; [email protected]; bmwg- > [email protected]; [email protected]; BOUCADAIR Mohamed > INNOV/NET <[email protected]>; auth48archive@rfc- > editor.org > Objet : [AD] Re: AUTH48: RFC-to-be 9971 <draft-ietf-bmwg- > mlrsearch-15> for your review > > > 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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > github.com%2Frfc-editor%2FAUTH48- > rfc9971%2Fissues&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cf > 3ed7c4e35d04e329b3108deb17758a4%7C90c7a20af34b40bfbc48b9253b6f5d20 > %7C0%7C0%7C639143323315192751%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1h > cGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIl > dUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=1HtCbj4cIH7pol1uuwUT8axUutJyJqEG > 8AD4dlJtAhA%3D&reserved=0). > > *AD, please see question #1 below (also listed at > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > github.com%2Frfc-editor%2FAUTH48- > rfc9971%2Fissues%2F2&data=05%7C02%7Cmohamed.boucadair%40orange.com > %7Cf3ed7c4e35d04e329b3108deb17758a4%7C90c7a20af34b40bfbc48b9253b6f > 5d20%7C0%7C0%7C639143323315209562%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0 > eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbC > IsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=1lFFrhkz7iaUgMqDUV0BM2yQC5Xk > wc67WwI4KFTHxC8%3D&reserved=0). 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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > www.rfc-editor.org%2Fauthors%2Frfc9971- > diff.html&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cf3ed7c4e > 35d04e329b3108deb17758a4%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C > 0%7C639143323315219856%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnR > ydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyf > Q%3D%3D%7C0%7C%7C%7C&sdata=vAKIYrQh4zEnxVjJRCzr6aj0XSq280zEJ3tmaCS > V%2BP8%3D&reserved=0 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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > www.rfc- > editor.org%2Fsearch&data=05%7C02%7Cmohamed.boucadair%40orange.com% > 7Cf3ed7c4e35d04e329b3108deb17758a4%7C90c7a20af34b40bfbc48b9253b6f5 > d20%7C0%7C0%7C639143323315229888%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0e > U1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCI > sIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=9h9yG1FHgo2ZERlfcdJplsNWpdxAb > OUw0Wd%2FdK6gazw%3D&reserved=0. --> > > > 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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2 > Fauthors.ietf.org%2Fen%2Frfcxml- > vocabulary%23aside&data=05%7C02%7Cmohamed.boucadair%40orange.com%7 > Cf3ed7c4e35d04e329b3108deb17758a4%7C90c7a20af34b40bfbc48b9253b6f5d > 20%7C0%7C0%7C639143323315239576%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU > 1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIs > IldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=iqPia63CNQKXcsobdiKFtacJa00INM > 7W%2BjCjzM0wHdE%3D&reserved=0). > > 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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > authors.ietf.org%2Frfcxml- > vocabulary%23dl&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cf3 > ed7c4e35d04e329b3108deb17758a4%7C90c7a20af34b40bfbc48b9253b6f5d20% > 7C0%7C0%7C639143323315249098%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hc > GkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIld > UIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=JX%2BsO3Rl6VO%2BO8WWAE7S0mLauv%2B > qiOu5ytAT%2F6Qh23s%3D&reserved=0). 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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > authors.ietf.org%2Frfcxml- > vocabulary%23strong&data=05%7C02%7Cmohamed.boucadair%40orange.com% > 7Cf3ed7c4e35d04e329b3108deb17758a4%7C90c7a20af34b40bfbc48b9253b6f5 > d20%7C0%7C0%7C639143323315261349%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0e > U1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCI > sIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=4A1teN0G8Vlrlul3BfPthRBvd7gYR > XDwkmP1MJXZONM%3D&reserved=0. > > 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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2 > Fwww.rfc- > editor.org%2Fstyleguide%2Fpart2%2F%23inclusive_language&data=05%7C > 02%7Cmohamed.boucadair%40orange.com%7Cf3ed7c4e35d04e329b3108deb177 > 58a4%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6391433233152714 > 38%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDA > wMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C > &sdata=tnkU7BghCSHYp7nVvUBk71FOpguQgFAgYWTPrnRpbdA%3D&reserved=0> > 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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > www.rfc- > editor.org%2Frpc%2Fwiki%2Fdoku.php%3Fid%3Dpilot_test_kramdown_rfc& > data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cf3ed7c4e35d04e329b > 3108deb17758a4%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C639143 > 323315284076%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiO > iIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C > 0%7C%7C%7C&sdata=xxp6MV4UvYJ9ozPxinzc0T%2FhbAErhJCc%2FaW%2FAsGTfTo > %3D&reserved=0). > > AUTH48 is being handled in GitHub as part of the GitHub pilot test > (see > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > www.rfc-editor.org%2Frpc%2Fwiki%2Fdoku.php%3Fid%3Drpc-github- > phase-0-pilot- > test&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cf3ed7c4e35d04 > e329b3108deb17758a4%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6 > 39143323315294576%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUs > IlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D% > 3D%7C0%7C%7C%7C&sdata=nZ9U%2BtE%2FWZGXd7JEz8K0%2FgGyQhypUT3ECwYV5B > PAiGI%3D&reserved=0). > > Your document is available for review at: > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > github.com%2Frfc-editor%2FAUTH48- > rfc9971&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cf3ed7c4e35 > d04e329b3108deb17758a4%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0% > 7C639143323315304249%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRyd > WUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ% > 3D%3D%7C0%7C%7C%7C&sdata=Fe7da3VruCEm%2FKR0Ja%2B2h%2Bi4MfW482zb5i7 > 0ciN7QRI%3D&reserved=0 > > 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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > github.com%2Frfc-editor%2FAUTH48- > rfc9971%2Fblob%2FApproved%2FREADME.md&data=05%7C02%7Cmohamed.bouca > dair%40orange.com%7Cf3ed7c4e35d04e329b3108deb17758a4%7C90c7a20af34 > b40bfbc48b9253b6f5d20%7C0%7C0%7C639143323315313873%7CUnknown%7CTWF > pbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zM > iIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Sax6GTLJUFf > 5noDp0%2FlQ0hUxqgw0yBBErdyzb9uuC70%3D&reserved=0 > > c) review and resolve the issues: > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > github.com%2Frfc-editor%2FAUTH48- > rfc9971%2Fissues&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cf > 3ed7c4e35d04e329b3108deb17758a4%7C90c7a20af34b40bfbc48b9253b6f5d20 > %7C0%7C0%7C639143323315323947%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1h > cGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIl > dUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=zt2c5AdCTy33rHQDmBzzT91PAhAIcBpz > bYmlF6CM8hQ%3D&reserved=0 > > 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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2 > Fwww.rfc- > editor.org%2Ffaq%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com% > 7Cf3ed7c4e35d04e329b3108deb17758a4%7C90c7a20af34b40bfbc48b9253b6f5 > d20%7C0%7C0%7C639143323315333628%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0e > U1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCI > sIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=jT5GPjF59bazSmjb2u5Ips5UBwJam > Dz8r9YTn2NguD8%3D&reserved=0). > > 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 ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
