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]
