Hi Stavros,

Thank you for your reply! 

As for the question about idnits flags about the references, we'll take a 
closer look as we process them. I doubt that those suggestions are necessary.

Once I get AD approval for the email address updates, it should be all set.

Sincerely,
Sarah Tarrant
RFC Production Center

> On Jan 13, 2026, at 4:25 AM, Kousidis <[email protected]> wrote:
> 
> Dear RFC Editor Team,
> thank you for adding our document to the queue.
> We fixed some nits and published version -17.
> Please see our replies inline below.
> Best
> Stavros
> On 1/6/26 23:22, Sarah Tarrant 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?
> Yes
>> 
>> 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).
> Our documents terminology should match post-quantum hybrid schemes 
> terminology in RFC9794 (as it is stated in Section 1.1.1 of our document).
>> 
>> * 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.)
> We wrapped functions, parameters, variables, equations, and assignments in 
> single backticks to format them as code.
>> 
>> 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).
>> 
>> * References to I-Ds that have been replaced by another I-D will be 
>> updated to point to the replacement I-D.
>> 
>> * References to documents from other organizations that have been 
>> superseded will be updated to their superseding version.
>> 
>> 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.
>> 
> After fixing some minor nits idnits gives us:
> =============================================================
> idnits 2.17.1 
> 
> draft-ietf-openpgp-pqc-17.txt:
> 
> Checking boilerplate required by RFC 5378 and the IETF Trust (see
> https://trustee.ietf.org/license-info):
> ----------------------------------------------------------------------------
> 
> No issues found here.
> 
> Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
> ----------------------------------------------------------------------------
> 
> No issues found here.
> 
> Checking nits according to https://www.ietf.org/id-info/checklist :
> ----------------------------------------------------------------------------
> 
> No issues found here.
> 
> Miscellaneous warnings:
> ----------------------------------------------------------------------------
> 
> No issues found here.
> 
> Checking references for intended status: Proposed Standard
> ----------------------------------------------------------------------------
> 
> (See RFCs 3967 and 4897 for information about using normative references
> to lower-maturity documents in RFCs)
> 
> -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-203'
> 
> -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-204'
> 
> -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-205'
> 
> -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-OPENPGP'
> 
> ** Downref: Normative reference to an Informational RFC: RFC 3394
> 
> ** Downref: Normative reference to an Informational RFC: RFC 7748
> 
> ** Downref: Normative reference to an Informational RFC: RFC 8032
> 
> 
> Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--).
> 
> Run idnits with the --verbose option for more detailed information about
> the items above.
> 
> ===========================================================================================
> We listed those references as normative as they contain the algorithmic 
> specifications needed.
> We would appreciate guidance from the RFC Editor Team if this should be 
> handled differently.
>> 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?
> No
>> 
>> 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 `)
>> * italics (<em/> or *)
>> * bold (<strong/> or **)
>> 
>> 
> As far as we know, yes.
>> 
>> 7) This document contains sourcecode: 
>> 
>> * Does the sourcecode validate?
> Yes
>> 
>> * 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 
>> types: https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types.)
> Yes
>> 
>> 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.
> No
>> 
>> 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.
> No
>> 
>>> On Jan 6, 2026, at 4:17 PM, [email protected] wrote:
>>> 
>>> Author(s),
>>> 
>>> Your document draft-ietf-openpgp-pqc-16, 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]

Reply via email to