Hello Elwyn, Thanks for your review!Most of your comments are addressed in https://github.com/core-wg/draft-dns-over-coap/pull/47. Let me know if these changes are ok for you.
Inline below, you find some replies to your questions and clarifying questions on my part on points that were not addressed by that PR.
Best Martine On 6/26/25 17:57, Elwyn Davies via Datatracker wrote:
[...] s1, para 1 and s8: Since RFC 9147 obsoletes RFC6347, is the reference to RFC 6347 needed?
Since many CoAP implementations still use DTLS 1.2, we decided to include that reference.
s1. end of para 2: [Note: Presumably RFC7228 can be removed once 7228bis is approved. An RFC editor note would be appropriate.] s1, para 4: s/To avoid resource requirements/To avoid the resource requirements/ s1, last para: s/like when/as when/ s2, last para: OLD: For better readability, examples in this document the binary payload is provided in hexadecimal NEW: For better readability, in the examples in this document the binary payload is shown in a hexadecimal ENDS s2: The following terms/abbreviations are used but not defined/expanded elsewhere in the document and could be usefully included here as they are not well-known abbreviations according to the RFC Editor: SVCB Service Binding DNR Discovery of Network-designated Resolvers (I assume) ALPN Application-Layer Protocol Negotiation COSE CBOR Object Signing and Encryption CBOR Concise Binary Object Representation
Recursive abbreviations are no fun to resolve :)
Because it is resolved just besides "URI", I resolved that one, too, even though it should be a well-known abbreviation. Otherwise, it looked weird.CRI Constrained Resource Identifier
CoRE Constrained RESTful Environments
This one is resolved in the Terminology section already.
s3.2, 1st bullet point after para 4: s/CoAP over TLS MUST be construct./CoAP over TLS MUST be constructed./ s3.2, 1st bullet point after para 4: The default port of the CoAP transport - is this referring to port 5683 as allocated by Section 12.6 of RFC 7252? If so this might be usefully referred to here. s4.3.2: The discussion of ETag generation might need an illustrative reference e.g., RFC 2616 Section 14.19
As far as I can see, that section does not mention hashing of the content at all, which is the typical way to generate generic ETags in many CoAP implementations. So I am not sure what the reference should illustrate. Would RFC 7252, Section 5.10.6 be suitable?
s4.3.3 Header explanation for does.not.exist case would look better with spaces
around the hyphens: OLD:
When a DNS error—NxDomain (RCODE = 3) for "does.not.exist" in this
case—is noted in the DNS response, the CoAP response still indicates
success.
NEW:
When a DNS error — NxDomain (RCODE = 3) for "does.not.exist" in this
case — is noted in the DNS response, the CoAP response still indicates
success.
ENDS
s6: s/Section Section/Section/ [Remove 'Section' from before expanded XML cross
reference.]
s6: s/unprotected CoAP request./unprotected CoAP requests./
s9.2, table: The text in the Reference column upsets idnits. Probably
[RFC-XXXX], Section 3 would be more acceptable
<<attachment: smime.p7s>>
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
