Hi Francisco, Thank you for your reply!
Sincerely, Sarah Tarrant RFC Production Center > On Jul 29, 2026, at 4:18 AM, FRANCISCO LOPEZ GOMEZ <[email protected]> > wrote: > > Hi everyone, > > Please see inline our responses to the form. It is worth noting that we have > uploaded a new version of the draft with the small changes applied (updated > ACKs and removed <tt>). > > Best regards, > The EAP-EDHOC authors. > > Francisco López GómezPredoctoral Researcher > Dept. Ingeniería de la Información y las Comunicaciones [email protected] > > > > De: [email protected] <[email protected]> > Enviado: Miércoles, 29 de Julio de 2026 1:50 > Para: [email protected] <[email protected]>; RAFAEL MARIN LOPEZ > <[email protected]>; [email protected] <[email protected]>; > [email protected] <[email protected]>; FRANCISCO LOPEZ GOMEZ > <[email protected]>; > [email protected]<[email protected]> > CC: [email protected] <[email protected]>; > [email protected]<[email protected]>; [email protected] > <[email protected]>; [email protected] <[email protected]>; > [email protected]<[email protected]>; > [email protected] <[email protected]>; > [email protected] <[email protected]> > Asunto: Document intake questions about draft-ietf-emu-eap-edhoc > 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 receive > a > reply. We require a reply, even if you don’t have guidance or don’t feel > that you > need to make any updates to the document. After we hear from you, your > document > will start moving through the queue. You will be able to review and approve > our > updates during Final Review (formerly AUTH48). > > Please feel free to contact us with any questions you may have at > [email protected]. > > Thank you! > The RPC Team > > -- > > 1) Please consider whether any updates to the following are needed: > > - Authors' Addresses > - Contributors > - Acknowledgments > > [Authors] We have carefully reviewed authors' information and the ACKs > section, which has been updated with new funding information and ACKs to the > IESG Ads from the Ballot. > > 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, > WG style guide, etc.? If so, please provide a pointer to that information > (e.g., "This document's terminology should match DNS terminology in > RFC 9499." or "This document uses the style info at > <https://urldefense.com/v3/__https://httpwg.org/admin/editors/style-guide__;!!D9dNQwwGXtA!TCzX9fqT03ndkyE1fXKUKIdfldhwMiP9iQyJbKsBD9_xpy_UfDlk28giMY1TDWD1FvN3o3CZVaUsnQnGi7CcmnOflzWG$ > >."). > > * Is there a general pattern of capitalization or formatting of terms that > editors can follow (e.g., "Field names should have initial capitalization." > or "Parameter names should be in double quotes." or "<tt/> should be used > for token names." etc.)? > > [Authors] With respect to capitalization and terminology, all the relevant > aspects are already discussed in Section 2, e.g., > "Readers are expected to be familiar with the terms and concepts > defined in EAP [RFC3748] and EDHOC [RFC9528]." > > However, during the standardization process we have tried to align structure > and requirements with the rest of EAP methods, e.g., EAP-TLS 1.3 > (https://datatracker.ietf.org/doc/rfc9190/). > > > 3) Please carefully review the entries and their URLs in the > > References section 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://urldefense.com/v3/__https://author-tools.ietf.org/idnits__;!!D9dNQwwGXtA!TCzX9fqT03ndkyE1fXKUKIdfldhwMiP9iQyJbKsBD9_xpy_UfDlk28giMY1TDWD1FvN3o3CZVaUsnQnGi7Ccmm2ZR6K0$ > >. > > > [Authors] We have reviewed all references both manually and with id-nits and > seem to be valid and currently active. > > > 4) This document uses fixed width font (<tt>) in the following, but not > elsewhere in the document. Please review. Should these instances of <tt> be > removed? > > > > This document defines only the container for carrying EAP Channel Binding > information within EAP-EDHOC messages, using the <tt>EAD_3</tt> and > <tt>EAD_4</tt> fields. > > > [Authors] Yes, we have removed those <tt> instances. > > > 5) This document contains SVG. What tool did you use to make the 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. > > [Authors] We have used aasvg as SVG engine, generating those figures from > ASCII art. We have reviewed it again and seem to be correct. > > > > 6) 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://urldefense.com/v3/__https://www.rfc-editor.org/rpc/wiki/doku.php?id=pilot_test_kramdown_rfc__;!!D9dNQwwGXtA!TCzX9fqT03ndkyE1fXKUKIdfldhwMiP9iQyJbKsBD9_xpy_UfDlk28giMY1TDWD1FvN3o3CZVaUsnQnGi7Ccmopfbbuv$ > . > > > [Authors] We appreciate the opportunity to participate in this Pilot Tests > but prefer to continue with the classical path. > > > 7) Is there anything else that the RPC should be aware of while editing this > > document? > > [Authors] As far as author's knowledge, there is no extra considerations for > the RPC. > > > > > > Title : Using the Extensible Authentication Protocol (EAP) > with Ephemeral Diffie-Hellman over COSE (EDHOC) > > Author(s) : Dan Garcia-Carrillo, > > Rafael Marin-Lopez, > > Göran Selander, > > John Preuß Mattsson, > > Francisco Lopez-Gomez > > Working Group Chair(s) : Joseph Salowey, Peter Yee > > Area Director(s) : Deb Cooley, Christopher Inacio > > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
