Hi Sarah, Apologies for the delay in getting back to you, but we needed a bit of time to properly address your questions and minimize excessive email correspondence.
Please see inline for our answers, and let us know if you have any further questions. Looking forward to hearing from you/team regarding the next steps. Cheers, -Maciek and Vratko (authors) From: Sarah Tarrant <[email protected]> Date: Thursday, 13 November 2025 at 22:53 To: Maciek Konstantynowicz (mkonstan) <[email protected]>, Vratko Polák -X (vrpolak - PANTHEON TECH SRO at Cisco) <[email protected]> Cc: [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]> Subject: Re: Document intake questions about <draft-ietf-bmwg-mlrsearch-15> Hi Author(s), This is a friendly reminder that we await answers to the questions below before continuing with the editing process for this document. Thank you, Sarah Tarrant RFC Production Center > On Nov 5, 2025, at 10:22 AM, Sarah Tarrant <[email protected]> > wrote: > > Author(s), > > Congratulations, your document has been successfully added to the RFC Editor > queue! > The team at the RFC Production Center (RPC) is looking forward to working > with you > as your document moves forward toward publication. To help reduce processing > time > and improve editing accuracy, please respond to the questions below. Please > confer > with your coauthors (or authors of other documents if your document is in a > cluster) as necessary prior to taking action in order to streamline > communication. > If your document has multiple authors, only one author needs to reply to this > message. > > As you read through the rest of this email: > > * If you need/want to make updates to your document, we encourage you to make > those > changes and resubmit to the Datatracker. This allows for the easy creation of > diffs, > which facilitates review by interested parties (e.g., authors, ADs, doc > shepherds). > * If you feel no updates to the document are necessary, please reply with any > applicable rationale/comments. > > > Please note that the RPC team will not work on your document until we hear > from you > (that is, your document will remain in AUTH state until we receive a reply). > Even > if you don't have guidance or don't feel that you need to make any updates to > the > document, you need to let us know. After we hear from you, your document will > start > moving through the queue. You will be able to review and approve our updates > during AUTH48. > > Please feel free to contact us with any questions you may have at > [email protected]. > > Thank you! > The RPC Team > > -- > > 1) As there may have been multiple updates made to the document during Last > Call, > please review the current version of the document: > > * Is the text in the Abstract still accurate? Yes. > * Are the Authors' Addresses, Contributors, and Acknowledgments > sections current? Acknowledgements section should be updated to the following: Insert a new paragraph, replacing current 3rd paragraph in section 9. Acknowledgments: "Many thanks to 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 were MLRsearch need originally came up, and it was in FD.io CSIT labs were first MLRsearch opensource code got prototyped and then over the years productized. Thanks go also 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.” The rest is fine. > > > 2) Please share any style information that could help us with editing your > document. For example: > > * Is your document's format or its terminology based on another document? > If so, please provide a pointer to that document (e.g., this document's > terminology should match DNS terminology in RFC 9499). See section "4.4. Existing Terms", references to RFC1242, RFC2285 and RFC2544. > * Is there a pattern of capitalization or formatting of terms? (e.g., field > names > should have initial capitalization; parameter names should be in double > quotes; > <tt/> should be used for token names; etc.) Yes, currently we use capitalization and also double quotes, and we try to be consistent, but mistakes are probably present. For capitalization, the text in the following section should clarify our intent: 1. Introduction (second and third paragraph) 4. MLRsearch Specification (second paragraph) For double quotes, we ran out of time trying to verbalize the rules we intuitively follow. Further e-mail discussion might be needed to achieve consistency. > > > 3) Please review the entries in the References section carefully with > the following in mind. Note that we will update as follows unless we > hear otherwise at this time: > > * References to obsoleted RFCs will be updated to point to the current > RFC on the topic in accordance with Section 4.8.6 of RFC 7322 > (RFC Style Guide). All references are up-to-date. Feel free to propose updates, but authors need to approve. > > * References to I-Ds that have been replaced by another I-D will be > updated to point to the replacement I-D. All references are up-to-date. Feel free to propose updates, but authors need to approve. > > * References to documents from other organizations that have been > superseded will be updated to their superseding version. All references are up-to-date. Feel free to propose updates, but authors need to approve. > > Note: To check for outdated RFC and I-D references, you can use > idnits <https://author-tools.ietf.org/idnits>. You can also help the > IETF Tools Team by testing idnits3 <https://author-tools.ietf.org/idnits3/> > with your document and reporting any issues to them. > > > 4) Is there any text that should be handled extra cautiously? For example, are > there any sections that were contentious when the document was drafted? Yes, the following sections went through broader working group discussions: 1.2. Positioning within BMWG Methodologies 4.1. Scope (and its three subsections) Most of definitions in Specification are also sensitive to minor edits, but they are not contentious (we do not need larger consensus to approve edits there). > > > 5) Is there anything else that the RPC should be aware of while editing this > document? No. > > > 6) This document uses one or more of the following text styles. > Are these elements used consistently? > > * fixed width font (<tt/> or `) There are instances of "<CODE BEGINS> … <CODE ENDS>” - but they don’t seem to affect HTML rendering. 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. > * italics (<em/> or *) Currently yes, but we prefer converting them to bold instead. > * bold (<strong/> or **) Yes, we use bold for emphasis, and we try to be consistent, but mistakes are probably present. We ran out of time trying to verbalize the rules we intuitively follow. Further e-mail discussion might be needed to achieve consistency. > > > 7) This document contains sourcecode: > > * Does the sourcecode validate? Yes, the Python sourcecode in appendices (between <CODE BEGINS> and <CODE ENDS>) does validate. > * Some sourcecode types (e.g., YANG) require certain references and/or text > in the Security Considerations section. Is this information correct? No security implications for our code, our formulas do not have any side effects. > * Is the sourcecode type indicated in the XML? (See information about > sourcecode types.) In kramdown source we use `~~~ python`, even though it includes the CODE tags that are not valid Python. > > > 8) Would you like to participate in the RPC Pilot Test for editing in > kramdown-rfc? > If so, please let us know and provide a self-contained kramdown-rfc file. For > more > information about this experiment, see: > https://www.rfc-editor.org/rpc/wiki/doku.php?id=pilot_test_kramdown_rfc. Yes. > > > 9) Would you like to participate in the RPC Pilot Test for completing AUTH48 > in > GitHub? If so, please let us know. For more information about this experiment, > see: > https://www.rfc-editor.org/rpc/wiki/doku.php?id=rpc-github-phase-0-pilot-test. Yes. > > >> On Nov 5, 2025, at 11:19 AM, [email protected] wrote: >> >> Author(s), >> >> Your document draft-ietf-bmwg-mlrsearch-15, which has been approved for >> publication as >> an RFC, has been added to the RFC Editor queue >> <https://www.rfc-editor.org/current_queue.php>. >> >> If your XML file was submitted using the I-D submission tool >> <https://datatracker.ietf.org/submit/>, we have already retrieved it >> and have started working on it. >> >> If you did not submit the file via the I-D submission tool, or >> if you have an updated version (e.g., updated contact information), >> please send us the file at this time by attaching it >> in your reply to this message and specifying any differences >> between the approved I-D and the file that you are providing. >> >> You will receive a separate message from us asking for style input. >> Please respond to that message. When we have received your response, >> your document will then move through the queue. The first step that >> we take as your document moves through the queue is converting it to >> RFCXML (if it is not already in RFCXML) and applying the formatting >> steps listed at <https://www.rfc-editor.org/pubprocess/how-we-update/>. >> Next, we will edit for clarity and apply the style guide >> (<https://www.rfc-editor.org/styleguide/>). >> >> You can check the status of your document at >> <https://www.rfc-editor.org/current_queue.php>. >> >> You will receive automatic notifications as your document changes >> queue state (for more information about these states, please see >> <https://www.rfc-editor.org/about/queue/>). When we have completed >> our edits, we will move your document to AUTH48 state and ask you >> to perform a final review of the document. >> >> Please let us know if you have any questions. >> >> Thank you. >> >> The RFC Editor Team >> >
-- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
