I think it would be helpful if this document were more explicit about its motivation. In my view, the underlying motivation for this draft is to enable seamless management of DNS service within a CoAP-centered deployment, by sharing key distribution, access controls, monitoring, etc. The draft claims various performance benefits from DoC, but these are unproven and seem unlikely to be significant. ... For our document, I think we need at least confirmation or decline that the "coap" ALPN could be used for DTLS, SVCB for OSCORE/EDHOC, I think is out of scope at the moment anyways. I'm not sure I follow, but using the same ALPN for multiple transports renders that ALPN permanently incompatible with SVCB. I recommend keeping "coap" for TLS/TCP only, and defining a new ALPN ID for CoAP/DTLS. Furthermore, there is still an open question, if DoC can or should be translated at a CoAP-HTTP proxy to DoH. Namely, how the FETCH that DoC uses should be translated into the POST/GET of DoH [3]. I don't think there is any need to specify this. A DoC server could act as a forwarder to an upstream using DoH, DoQ, etc. in accordance with the relevant standards, without impacting its compliance as a DoC server.
However, this does resemble a concern I've previously raised: the draft does not explain why it is necessary to define a new DoC mechanism, rather than simply forwarding RFC 8484 DoH through a CoAP-HTTP proxy.
_______________________________________________ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
