[core] Re: Review of draft-ietf-core-dns-over-coap-11

[Martine Sophie Lenders <[e-mail]>]

Hello Carsten,

again, thanks for the review!

Since I sometimes used different wordings than we discussed in 
yesterday's interim to fix the issues you pointed out, I opened 
https://github.com/core-wg/draft-dns-over-coap/pull/39.

Best
Martine

On 12.02.25 15:18, Carsten Bormann wrote:
> Below is a quick review of draft-ietf-core-dns-over-coap-11 ahead of the meeting in 40 minutes.
> A number of nits that probably don’t need more attention beyond merging them are in PR #[38], the rest is quickly summarized below.
> 
> Grüße, Carsten
> 
> ## Minor
> 
> The DNS update discussion uncovered that we are not really addressing
> anything but DNS queries (OPCODE = 0).  This could be made clear in a
> general scope statement about opcodes: this doc is only about opcode 0.
> Section 4.3.3 would then not be necessary.
> 
> We probably need an example for a "Not Implemented" response triggered
> by an unsupported opcode.
> 
> 4.3.1: what is a "valid DNS response" (not defined by RFC 1035)?
> 
> 4.3.1 "Communication errors with a DNS server (e.g., timeouts) SHOULD be indicated
> by including a SERVFAIL DNS response in a successful CoAP response."
> -- what is an exception to this?  Should this not be a MUST?
> 
> 5.3 "it is NOT RECOMMENDED".  Not sure what "it" is.  Directly mapping
> CoAP to HTTP without the use of a DNS server?
> 
> s/Unencrypted/Unprotected/ (it seems the text using "unencrypted" is
> mostly about not having integrity protection)
> (and s/unencrypted/unprotected/ as well)
> 
> ## Nits
> 
> Nit fixes have been collected in PR #[38]
> 
> [38]: https://github.com/core-wg/draft-dns-over-coap/pull/38
> 
> Some I did not want to just fill in:
> 
> ### Typos
> 
> (Nits listed:)
> 
> ... Clarify that DoC and DoC are...
> 
> ### Editorial
> 
> (Nits listed:)
> 
> * prevent TCP and HTTPS resource requirements
> * prevent resource requirements of DTLS or TLS
> 
> (We don't prevent these requirements, we cause them not to apply)
> 
> CoAP resource identifier
> 
> (Not a defined term)
> 
> For reliability and energy saving measures content decoupling and thus
> en-route caching on proxies takes[...]
> 
> (can't really parse)
> 
> refresh stale cache entries without large messages
> 
> (neither -- when do stale cache entries have large messages?)
> 
> algorithm to assure the requirement for the DoC
> 
> (one more)
> 
>