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

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

Hi Mike,

thanks for your review. Most changes I address as is (see 
https://github.com/core-wg/draft-dns-over-coap/pull/45) but here are 
some comments still up for discussion.

On 6/12/25 17:40, Mike Bishop wrote:
> Thanks for this work — it looks like a useful addition to the suite of 
> DoFoo protocols. (Though the identical pronunciation between DoC and DoQ 
> may lead to some accidental confusion down the road.)
> 
> I have a few high-level notes as well as smaller comments and nits.
> 
> First, I note the normative dependency on draft-ietf-cbor-edn-literals 
> which was returned to the cbor WG after IETF Last Call. Have the authors 
> and chairs coordinated on the timeline of that document and whether it 
> will delay publication of this one? Are the updates in that draft needed 
> for this work or would a reference to RFC 8949/8610 suffice to unblock this?

Since we only reference draft-ietf-cbor-edn-literals to use CBOR string 
sequences, it should be fine to reference RFC 8949.

> Second, this document seems to sidestep discussion of a gap around 
> discovery: a DoC server which uses OSCORE without transport security. 
> It's fine to specify the DoC protocol without specifying discovery 
> mechanisms for every possible mode, particularly when pre-configuration 
> is a realistic possibility. If there is no current discovery mechanism 
> for this mode, we should just say that directly.

We discuss the discovery of DoC servers using OSCORE in 
draft-lenders-core-dnr, but I agree it is worth noting that OSCORE 
discovery is out of scope of this document.
> Lastly, a note that may simply be my lack of history with this domain. 
> Is "CoRE" a term we use in RFCs or simply the name of the WG? If the 
> latter, it's probably incorrect to refer to FETCH as CoRE-specific in 
> Section 1. Should this be "CoAP-specific"? Similarly, the title of 
> Section 5 can simply discuss CoAP.

Regarding referring to FETCH as CoRE-specific, I think you are right. 
Regarding the general usage of CoRE as an umbrella term as we do in the 
title of section 5, I have to pass the ball to the core WG itself. We 
wrote CoRE here since, e.g. OSCORE is not necessarily only used over 
CoAP, right? Is there precedence for this?

> ===Other Comments===
> [...]
> In Section 3.2:
> 
>   *
>     Consider whether the normative downrefs to [I-D.ietf-core-coap-dtls-
>     alpn] and [I-D.ietf-cbor-edn-literals] are needed. At first glance,
>     neither appears to be specifying requirements, but are examples or
>     implementation possibilities. Could these be informative?

Regarding the -edn-literals downref, see above. Since we are using the 
ALPN defined in -coap-dtls-alpn, we came to the conclusion that the 
reference should be normative that is also why -coap-dtls-alpn and this 
draft were given to IESG together. However, if we now decide that the 
-coap-dlts-alpn reference can be informative, I happily downgrade it.

>   * [...]
>   *
>     Saying that the algorithm "could be as follows" suggests this is
>     merely illustrative. Are there any normative guidelines on how "MUST
>     [be] constructed from the SvcParams" gets executed? Note the
>     informative reference to transport-indication is probably not the
>     answer.

Is it enough that we write something like "A construction algorithm for 
DoC requests MUST be as follows, [...]" and then specify below "A more 
generalized construction algorithm for any CoAP request can be found in 
[transport-indication].". I.e., specifying that this algorithm only 
considers requests for DoC.
> In Section 4.2.2, explain when the SHOULD doesn't apply. Does a forward 
> reference to Sections 6 and 8 help with that?

Apart from losing the benefits of CoAP caching, there is no real harm in 
keeping an ID, e.g., when the query came from somewhere else. As such 
maybe adding some sentences such as "Apart from losing these benefits, 
there is no harm it not setting it to 0, e.g., when the query was 
received from somewhere else. A DoC server MUST copy the ID from the 
query in its response." Section 6 and 8 do not provide any guidance on 
when SHOULD does not apply, as they state that the CoAP token can take 
the same function when it comes to cache poisoning attacks.

> [...]
>   *
>     Equating the integrity of the connection (DoQ) and the integrity of
>     the records (DNSSEC) seems likely to draw fire during IESG Review.
>     Consider rewording this section to talk about the upstream
>     connection and the records separately.

See 
https://github.com/core-wg/draft-dns-over-coap/pull/45/commits/2b0f35978ed88e74a08d23cc04a18b9c19a1d0da

Best
Martine