Hi Martine, Thank you for the update on your review process for this cluster. We look forward to hearing from you soon.
Best regards, Karen Moore RFC Production Center > On Mar 6, 2026, at 1:28 AM, Martine Sophie Lenders > <[email protected]> wrote: > > Dear Karen, dear Rebecca, > > thank you and the RFC Editor team as a whole for your editorial on our drafts > (both this one and RFC-to-be 9952)! We want to discuss your questions and > review your editorial carefully among us co-authors. However, due to > preparations for IETF 125 and time-critical matters in our research work, we > are unable to do this immediately. Please expect first answers to your > questions next Wednesday at the earliest, hopefully before IETF week starts. > > Thank you for your patience > Martine > > On 3/6/26 04:15, [email protected] wrote: >> Authors, >> While reviewing this document during AUTH48, please resolve (as necessary) >> the following questions, which are also in the source file. >> 1) <!--[rfced] FYI: We updated [I-D.ietf-core-coap-dtls-alpn] to >> [PRE-RFC9952] >> for now. We will make the final updates in RFCXML (i.e., remove "PRE-"). >> --> >> 2) <!--[rfced] Please note that the title of the document has been >> updated as follows. The abbreviation has been expanded per Section 3.6 >> of RFC 7322 ("RFC Style Guide"). We also added "the". Please review. >> Original: >> DNS over CoAP (DoC) >> Current: >> DNS over the Constrained Application Protocol (DoC) >> --> >> 3) <!--[rfced] May we remove "(CoAPS)" in the Abstract as this >> term/abbreviation is not used elsewhere in the document? Please >> review. >> Original: >> These CoAP messages can be protected by (D)TLS-Secured CoAP (CoAPS) >> or Object Security for Constrained RESTful Environments (OSCORE) to >> provide encrypted DNS message exchange for constrained devices in >> the Internet of Things (IoT). >> Perhaps: >> These CoAP messages can be protected by (D)TLS-Secured CoAP or >> Object Security for Constrained RESTful Environments (OSCORE) to >> provide encrypted DNS message exchange for constrained devices in >> the Internet of Things (IoT). >> --> >> 4) <!--[rfced] FYI: draft-ietf-iotops-7228bis has not been published yet >> (currently, its IESG state is "I-D Exists"). Thus, we have left >> references to RFC 7228 and draft-ietf-iotops-7228bis as is. >> Author note: >> Please remove the {{-constr-nodes}} reference and replace >> it with {{I-D.ietf-iotops-7228bis}} throughout the document in case >> {{I-D.ietf-iotops-7228bis}} becomes an RFC before publication. >> --> >> 5) <!--[rfced] FYI - We updated "authoritive name server" to "authoritative >> name >> server" to match other usage in this document and in other RFCs. >> Original: >> That DoC server can be the authoritive name server for the queried >> record or a DNS client (i.e., a stub or recursive resolver) that >> resolves DNS information by using other DNS transports such as DNS >> over UDP [STD13], DNS over HTTPS [RFC8484], or DNS over QUIC >> [RFC9250] when communicating with the upstream DNS infrastructure. >> Updated: >> That DoC server can be the authoritative name server for the queried >> record or a DNS client (i.e., a stub or recursive resolver) that >> resolves DNS information by using other DNS transports such as DNS >> over UDP [STD13], DNS over HTTPS [RFC8484], or DNS over QUIC >> [RFC9250] when communicating with the upstream DNS infrastructure. >> --> >> 6) <!-- [rfced] Please clarify "is of length 0 and 24 octets" in this >> sentence. >> Original: >> As long as each docpath- >> segment is of length 0 and 24 octets, it is easily transferred into >> the path representation in CRIs [I-D.ietf-core-href] by masking each >> length octet with the CBOR text string major type 3 (0x60 as an >> octet, see [RFC8949]). >> Perhaps: >> As long as each docpath- >> segment has a length between 0 and 24 octets, it is easily transferred >> into >> the path representation in CRIs [CRI] by masking each length octet >> with the CBOR text string major type 3 (0x60 as an octet; see >> [RFC8949]). >> --> >> 7) <!--[rfced] We are having trouble parsing this sentence. Please let us >> know if it can be revised as shown below for clarity. >> Original: >> Likewise, it can be transferred into a URI path-abempty form by >> replacing each length octet with the "/" character None of the >> abovementioned prevent longer docpath-segments than the considered, >> they just make the translation harder, as they require to make space >> for the longer delimiters, in turn requiring to move octets. >> Perhaps: >> Likewise, it can be transferred into a URI path-abempty form by >> replacing each length octet with the "/" character. None of the >> abovementioned prevent longer docpath-segments than the considered >> ones; they just make the translation harder as space is required >> for the longer delimiters, which in turn require octets to be >> moved. >> --> >> 8) <!-- [rfced] May we update "going through" to "with" here to improve >> clarity? >> Original: >> The construction algorithm for DoC >> requests is as follows, going through the provided records in order >> of their priority. >> Perhaps: >> The construction algorithm for DoC >> requests is as follows, with the provided records in order >> of their priority. >> --> >> 9) <!-- [rfced] How may we update the third item in the series for parallel >> structure? Would either removing "from" or adding "information" be correct? >> Original: >> This may include (1) A >> or AAAA RRs associated with the target name and delivered with the >> SVCB RR (see [RFC9462]), (2) "ipv4hint" or "ipv6hint" SvcParams >> from the SVCB RR (see [RFC9461]), or (3) from IPv4 or IPv6 >> addresses provided if DNR [RFC9463] is used. >> Perhaps A (cut "from"): >> This may include (1) A >> or AAAA RRs associated with the target name and delivered with the >> SVCB RR (see [RFC9462]), (2) "ipv4hint" or "ipv6hint" SvcParams >> from the SVCB RR (see [RFC9461]), or (3) IPv4 or IPv6 >> addresses provided if DNR [RFC9463] is used. >> or >> Perhaps B (add "information"): >> This may include (1) A >> or AAAA RRs associated with the target name and delivered with the >> SVCB RR (see [RFC9462]), (2) "ipv4hint" or "ipv6hint" SvcParams >> from the SVCB RR (see [RFC9461]), or (3) information from IPv4 or IPv6 >> addresses provided if DNR [RFC9463] is used. >> --> >> 10) <!--[rfced] Per the following note, we have replaced "ff 0a" with "00 >> 0a" in >> the examples in Section 3.2.1 (per IANA's assignment of "10" for >> "docpath"). Please confirm that this is correct and let us know if any >> further >> updates are needed. >> Author note: >> Since the number for "docpath" was not assigned at the time of >> writing, we used the hex `ff 0a` (in decimal 65290; from the >> private use range of SvcParamKeys) throughout this section. Before >> publication, please replace `ff 0a` with the hexadecimal >> representation of the final value assigned by IANA in this >> section. Please remove this paragraph after that. >> --> >> 11) <!--[rfced] We note that "Cache-Key" appears as "cache key" in RFC >> 8132. Would you like to match use in RFC 8132? >> Original: >> This ensures that the CoAP Cache-Key (see [RFC8132], Section 2) >> does not change when multiple DNS queries for the same DNS data, >> carried in CoAP requests, are issued. >> Perhaps: >> This ensures that the CoAP cache key (see [RFC8132], Section 2) >> does not change when multiple DNS queries for the same DNS data, >> carried in CoAP requests, are issued. >> --> >> 12) <!-- [rfced] Please review the text starting with "OPCODE—a DNS >> Update ...". Should this be updated as follows or in some other way? >> Original: >> As described in Section 4.1, a DoC server uses NotImp (RCODE = 4) if >> it does not support an OPCODE—a DNS Update (OPCODE = 5) for >> "example.org" in this case. >> Perhaps: >> As described in Section 4.1, a DoC server uses NotImp (RCODE = 4) if >> it does not support an OPCODE - in this case, a DNS Update (OPCODE = 5) >> for >> "example.org" is used. >> --> >> 13) <!--[rfced] Please clarify what "a failure to do so" refers to in the >> following sentence. >> Original: >> As there is no CoAP observer anymore from the perspective of the >> DoC server, a failure to do so cannot be communicated back to any >> DoC observer. >> --> >> 14) <!--[rfced] FYI: We added "to protect" to this sentence for >> clarity. Please let us know if it changes the intended meaning. >> Original: >> For secure communication via (D)TLS or OSCORE, an unpredictable ID >> against spoofing is not necessary. >> Updated: >> For secure communication via (D)TLS or OSCORE, an unpredictable ID >> to protect against spoofing is not necessary. >> --> >> 15) <!-- [rfced] FYI: We removed the change log, which included a >> reference to RFC 2136. If RFC 2136 should be mentioned elsewhere in >> the running text, please let us know. >> --> >> 16) <!--[rfced] We note that "draft-amsuess-core-cachable-oscore" is >> expired and has been replaced by "draft-ietf-core-cacheable-oscore". >> May we replace the current entry below with the entry for >> "draft-ietf-core-cacheable-oscore"? >> Current: >> [I-D.amsuess-core-cachable-oscore] >> Amsüss, C. and M. Tiloca, "Cacheable OSCORE", Work in Progress, >> Internet-Draft, draft-amsuess-core-cachable-oscore-11, 6 July 2025, >> <https://datatracker.ietf.org/doc/html/draft-amsuess-core-cachable- >> oscore-11>. >> Perhaps: >> [CACHABLE-OSCORE] >> Amsüss, C. and M. Tiloca, "Cacheable OSCORE", Work in >> Progress, Internet-Draft, draft-ietf-core-cacheable- >> oscore-00, 22 September 2025, >> <https://datatracker.ietf.org/doc/html/draft-ietf-core- >> cacheable-oscore-00>. >> --> >> 17) <!--[rfced] Sourcecode and artwork >> a) Some lines in Figure 1 are too long for the TXT output. This figure is >> marked as artwork, so it needs to have a width of 72 characters or less. How >> may we revise this figure to fit these parameters? We tested removing some >> space in the figure; please check out the following test files and let us >> know >> if this would work (see TXT file for ascii art and HTML for SVG). If not, >> please >> provide an updated figure. >> Test files: >> https://www.rfc-editor.org/authors/rfc9953test.md >> https://www.rfc-editor.org/authors/rfc9953test.txt >> https://www.rfc-editor.org/authors/rfc9953test.html >> b) We have updated the blocks in Sections 3.2, 3.2.1, 4.2.3, and 4.3.3 to be >> marked as sourcecode. We set the type for the block in Section 3.2 as "abnf" >> (i.e., "~~~ abnf"). Please let us know if the type should be set for the >> other >> sourcecode blocks. For example, should the ones in Section 3.2.1 be marked as >> type "dns-rr"? If the current list of preferred values (see link below) does >> not contain an applicable type, feel free to let us know. Also, it is >> acceptable to leave the type not set. >> List of sourcecode types: >> https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types >> c) The blocks in Section 4.3.3 are too long for the TXT output. We marked >> these as sourcecode, so they should have a width of 69 characters or less. >> The >> long lines are currently 70 characters. Would moving all the lines with >> semicolons over to the left one space (in just this section or in all the >> sourcecode in the document) be a good solution? We tried this in the test >> files listed above so you can see what the output will look like. Feel free >> to >> offer other suggestions as well. >> --> >> 18) <!--[rfced] Please review the "Inclusive Language" portion of the online >> Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> >> and let us know if any changes are needed. Updates of this nature typically >> result in more precise language, which is helpful for readers. >> Note that our script did not flag any words in particular, but this should >> still be reviewed as a best practice. >> --> >> Thank you. >> Karen Moore and Rebecca VanRheenen >> RFC Production Center >> On Mar 5, 2026, at 7:10 PM, [email protected] wrote: >> *****IMPORTANT***** >> Updated 2026/03/05 >> RFC Author(s): >> -------------- >> Your document has now entered AUTH48. >> The document was edited in kramdown-rfc as part of the RPC pilot test (see >> https://www.rfc-editor.org/rpc/wiki/doku.php?id=pilot_test_kramdown_rfc). >> Please review the procedures for AUTH48 using kramdown-rfc: >> https://www.rfc-editor.org/rpc/wiki/doku.php?id=pilot_test_instructions_completing_auth48_using_kramdown >> Once your document has completed AUTH48, it will be published as >> an RFC. >> Files >> ----- >> The files are available here: >> https://www.rfc-editor.org/authors/rfc9953.md >> https://www.rfc-editor.org/authors/rfc9953.html >> https://www.rfc-editor.org/authors/rfc9953.pdf >> https://www.rfc-editor.org/authors/rfc9953.txt >> Diff file of the text: >> https://www.rfc-editor.org/authors/rfc9953-diff.html >> https://www.rfc-editor.org/authors/rfc9953-rfcdiff.html (side by side) >> Diff of the kramdown: >> https://www.rfc-editor.org/authors/rfc9953-md-diff.html >> https://www.rfc-editor.org/authors/rfc9953-md-rfcdiff.html (side by side) >> Tracking progress >> ----------------- >> The details of the AUTH48 status of your document are here: >> https://www.rfc-editor.org/auth48/rfc9953 >> Please let us know if you have any questions. >> Thank you for your cooperation, >> RFC Editor >> -------------------------------------- >> RFC9953 (draft-ietf-core-dns-over-coap-20) >> Title : DNS over CoAP (DoC) >> Author(s) : M. S. Lenders, C. Amsüss, C. Gündoğan, T. C. Schmidt, M. >> Wählisch >> WG Chair(s) : Jaime Jimenez, Marco Tiloca >> Area Director(s) : Gorry Fairhurst, Mike Bishop -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
