Hi Eric The AUTH state is not a new state but an existing one - see https://authors.ietf.org/en/rfc-publication-process for the full state diagram.
Jay -- Jay Daley IETF Executive Director > On 8 Jul 2025, at 18:33, Eric Vyncke (evyncke) > <[email protected]> wrote: > > > Hi Jean, > > While I like the idea, I have concerns about the name near-collision of AUTH > and AUTH48 as the state names are really similar. Could another name be > chosen for the new “AUTH” state ? Could simply be “INTAKE” 😉 > > Regards, > > -éric > > From: A. Jean Mahoney <[email protected]> > Date: Monday, 7 July 2025 at 21:59 > To: RFC Interest <[email protected]>, [email protected] > <[email protected]> > Subject: Intake form: an experimental RPC process for docs entering the RFC > Editor Queue > > Hi all, > > As mentioned in a recent blog post [1] and during the RPC community > calls [2] [3], the RFC Production Center has been looking at ways to > streamline our processes and improve queue times. We have drafted an > intake form that asks authors a few questions about their documents. The > answers to these questions will help us as we copy edit the documents. > Please see below for the initial intake form. > > The RPC will send these questions in an email message to the authors > when their document enters the RFC Editor Queue. The message's CC list > will basically be the same as the initial AUTH48 message (but without > auth48archive) and will include the ADs, chairs, doc shepherd, and the > RFC Editor mailing list. > > The RPC will wait for a response from the authors before we start > editing the document. That is, the document will remain in AUTH state > until we hear back. When we receive an answer, we will move the document > into EDIT state. The authors will be able to review our updates during > AUTH48. > > We expect that the authors will answer the intake form quickly as the > document is still fresh in their minds. If we don't receive an answer > within a week, though, we will send a reminder, and we will escalate to > a stream approver after two weeks by adding a flag in the subject line > (e.g., [AD]), similar to the AUTH48 process. However, if we have not > heard from the authors after a month, we will move the document into > EDIT state, and the document will move through the queue as usual. > > As this is an experiment, we will be assessing impact by measuring the > time in AUTH state, whether we needed to escalate to a stream approver, > the percent of facilitative answers, whether we received a revised I-D, > and whether that revised I-D needed approval. > > Please let us know if you have any questions or concerns. We plan to > send an intake form for every document that enters the queue starting > July 14. > > Best regards, > > Jean Mahoney > RFC Production Center > > [1] https://www.ietf.org/blog/rpc-retreat-2025/ > [2] > https://notes.ietf.org/notes-ietf-interim-2025-rpc-01-rpc?view#Process-efficiency > [3] > https://notes.ietf.org/notes-ietf-interim-2025-rpc-04-rpc?view#Project-Updates > > ------------------------------------------------------ > Subject: Author action required for draft-foo-00 > > 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 is still accurate? > * Are the References, Authors' Addresses, Contributors, and > Acknowledgments sections current? > > > 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). > * 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.) > > > 3) Is there any text that should be handled extra cautiously? For > example, are there any sections that were contentious when the document > was drafted? > > 4) Is there anything else that the RPC should be aware of while editing > this document? > > Questions to be sent as needed: > > X) This document uses the following text style: <tt/>, <em/>, and/or > <strong/> > Are these elements used consistently? See the full list of use > available at https://www.rfc-editor.org/authors/draft...-textstyle.txt > > > X) This document contains sourcecode: > > * Does the sourcecode validate? > * Some sourcecode types (e.g., YANG) require certain references and/or > text in the Security Considerations section. Is this information correct? > * Is the sourcecode type indicated in the XML? (see information about > sourcecode types). > > > X) This document contains SVG. The RPC cannot update SVG diagrams, so > please ensure that: > > * the SVG figures match the ASCII art used in the text output as closely > as possible, and > * the figures fit on the pages of the PDF output. > > > X) This document is part of Cluster XXX. > > * To help the reader understand the content of the cluster, is there a > document in the cluster that should be read first? Next? If so, please > provide the order and we will provide RFC numbers for the documents > accordingly. If order is not important, please let us know. > * Is there any text that has been repeated within the cluster document > that should be edited in the same way? For instance, parallel > introductory text or Security Considerations.
_______________________________________________ rfc-interest mailing list -- [email protected] To unsubscribe send an email to [email protected]
