Dear Sarah, Find our reply to your questions inline.
On 9/11/25 23:33, Sarah Tarrant wrote:
[...] 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?
Yes.
* Are the References, Authors' Addresses, Contributors, and Acknowledgments sections current?
For the most part, yes. However, there was a last minute typo found by Jan Romann, so we’d like to add him to the list of thanks in our acknowledgements. We have a change prepared for that in the working group repo [1], however, not as a draft version. Should we just submit that as a version now, or wait until AUTH48 for minor changes like that?
[1] https://github.com/core-wg/draft-dns-over-coap/commit/bf41ba46e2f211956cc11347ef3ce247db480216
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).
All documents we derive terminology from are referenced in Section 2, “Terminology and Conventions”.
* 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.)
Please refer to the respective CoAP and DNS specification for most of that. In general, we
- Put hex dumps and examples in <tt/> (e.g., <tt>ff 0a 00 04 03 64 6e 73</tt>), - Put text strings occuring, e.g., in the format or IANA tables, as well as the name of SvcParamKeys in quotation marks (e.g., "application/dns-message", "coaps://[2001:db8::1]/", "alpn", …), - Wrote DNS header fields, record type, and classes in ALLCAPS, - Capitalized CoAP options (e.g., Uri-Path, Content-Format, …), and - Protocol names and other proper names are capitalized.Examples are represented as code blocks, the human-readable parts are loosely based on the output of the dig tool.
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?
There were no particularly contentious sections. However, Section 5.1 "DNS Push Notifications and CoAP Observe" and Section 10 "Operational Considerations" were quite heavily reworked (or in case of Section 10, specifically created) during the IESG review stage. As they did not receive as many eyeballs yet, they should receive extra attention.
4) Is there anything else that the RPC should be aware of while editing this document?
No.
5) 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 **)
Yes.
6) This document is part of Cluster 554. * 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.
draft-ietf-core-coap-dtls-alpn is a normative reference for draft-ietf-core-dns-over-coap: The ALPN ID defined in draft-ietf-core-coap-dtls-alpn is used for the discovery of DNS over CoAP servers in draft-ietf-core-dns-over-coap. This is the main reason why these documents are clustered. As such, draft-ietf-core-coap-dtls-alpn should be read first. We do not have any preferred order, in our eyes they do not even need to sit right next to each other.
Regarding specific RFC numbers, our co-author Christian Amsüss already contacted rfc-edi...@rfc-editor.org on Sep 11th: If that is something that can be requested at all, we would love to have a number that ends in -53 (referencing the DNS port number) or -84 (referencing the RFC8484/DoH legacy) as a little easter egg for draft-ietf-core-dns-over-coap. However, we do see this as nothing more than an easter egg, so if that is not possible or would delay publication too much, we are fine with any number.
* 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.
No.
7) 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.
Since we edited the draft originally in kramdown-rfc, yes. Kind regards, Martine Lenders on behalf of all co-authors
On Sep 11, 2025, at 4:29 PM, rfc-edi...@rfc-editor.org wrote: Author(s), Your document draft-ietf-core-dns-over-coap-19, 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
smime.p7s
Description: S/MIME Cryptographic Signature
-- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
