Hi Martine, Thank you for your reply!
A) Regarding: >> * 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? Please submit a new version to datatracker so that it's clear where that change originated. B) Also, regarding "Regarding specific RFC numbers," - we have made a note of your request and will see if we can make it happen! After submitting the new draft to datatracker, please send along the self-contained markdown file to us so we can get started. Sincerely, Sarah Tarrant RFC PRoduction Center > On Sep 16, 2025, at 5:49 AM, Martine Sophie Lenders > <[email protected]> wrote: > > 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 [email protected] 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, [email protected] 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 >>> -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
