DNS over CoAP (DoC)
draft-ietf-core-dns-over-coap-20

[Ballot comment]
Thanks for this short and useful specification and thanks for responding to the TSV-ART review by T Pauley.
====
Editorial:
Please more clearly label the following, so it is seen as an RFC-Ed comment:
"Before publication, please replace ff 0a with the hexadecimal...."
===
Editorial:
      If it is "co", a
      CoAP request for CoAP over DTLS MUST be constructed.  Any other
      SvcParamKeys specifying a transport are out of the scope of this
      document.
- This seems to be missing a normative reference to: I-D.ietf-core-coap-dtls-alpn.

NiTs:
/This document provides no specification on how to map between DoC and
  DoH, e.g., at a CoAP-to-HTTP-proxy.  In fact, such...
/This document provides no specification on how to map between DoC and
  DoH, e.g., at a CoAP-to-HTTP-proxy, such.../
(To connect the RFC2119 requirement to the clause to which it refers.)

/...this kind of poisoning attacks./...this kind of poisoning attack./
(remove 's').

and thanks also for addressing my DISCUSS issues.

[Ballot comment]
Thanks for this short and useful specification and thanks for responding to the TSV-ART review by T Pauley.
====
Editorial:
Please more clearly label the following, so it is seen as an RFC-Ed comment:
"Before publication, please replace ff 0a with the hexadecimal...."
===
Editorial:
      If it is "co", a
      CoAP request for CoAP over DTLS MUST be constructed.  Any other
      SvcParamKeys specifying a transport are out of the scope of this
      document.
- This seems to be missing a normative reference to: I-D.ietf-core-coap-dtls-alpn.

NiTs:
/This document provides no specification on how to map between DoC and
  DoH, e.g., at a CoAP-to-HTTP-proxy.  In fact, such...
/This document provides no specification on how to map between DoC and
  DoH, e.g., at a CoAP-to-HTTP-proxy, such.../
(To connect the RFC2119 requirement to the clause to which it refers.)

/...this kind of poisoning attacks./...this kind of poisoning attack./
(remove 's').

[Ballot comment]
# Orie Steele, ART AD, comments for draft-ietf-core-dns-over-coap-17
CC @OR13

* line numbers:
  - https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-core-dns-over-coap-17.txt&submitcheck=True

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

Thanks to Todd Herr for the ARTART review.

## Comments

### Why not MUST?

```
252   discovery of designated resolvers [RFC9462].  Automatic configuration
253   SHOULD only be done from a trusted source.
```

Suggest to strengthen the language to "MUST" or provide a rationale for why it is "SHOULD".


### confusing MAY

```
302   list.  The same considerations for the "," and "" characters in
303   docpath-segments for zone-file implementations as for the alpn-ids in
304   an "alpn" SvcParam MAY apply (Section 7.1.1 of [RFC9460]).
```

Do you need the "MAY" here, is it not enough to say the same considerations apply?
I only skimmed 7.1.1 but it also contains a MAY, which I read as being sufficiently clear.

### Why not MUST?

```
375       If not, or if the endpoint becomes unreachable, the algorithm
376       SHOULD be repeated with the SVCB record with the next highest
377       priority.
```

Are there other strategies implied by this should, or is this a should only because retry is not required?

### MUST be able to understand when not accepted

```
525   Section 4.1) when requested.  A DoC client MUST be able to understand
526   responses in the "application/dns-message" Content-Format when it
527   does not send an Accept option.  Any response Content-Format other
```

I think this is better phrased as "use of the accept header is optional, however, all DoC clients MUST understand the "application/dns-message" Content-Format".
Possibly an alternative wording would be clearer.

[Ballot discuss]
I have a DISCUSS that should be easy to fix, and a few comments.

Section 4.2.3.

I don't see RFC3655 or RFC2535 allowing setting the AD bit in a query,
only in the answer. But here it shows the example query with an AD bit
set. Shouldn't this be the DO bit?

[Ballot comment]

        A full SVCB mapping is being prepared in
        [I-D.ietf-core-transport-indication],

Phrase this more neutrally, as if the document is also already published.

        Paths with longer segments cannot be advertised with the "docpath"
        SvcParam and are thus NOT RECOMMENDED for the path to the DoC
        resource.

Should this not be a MUST NOT?

Section 8

        A DoC client may not be able to perform DNSSEC validation,
        e.g., due to code size constraints, or due to the size of
        the responses. It may trust its DoC server to perform DNSSEC
        validation;

I can't see an IoT device doing DNSSEC validation. It would have to
validate a large number of queries in a row to get the validation from
the DNS root down to the domain. Validation of a single query would
not contain all the information required, so you either need to implement
a fully recursive validating DNS server, or support RFC 7901 CHAIN Query
Requests in both the DoC Server and DoC client. While I think RFC7901 support
is doable, implementing a fully recursive validating DNS server is not.
I would rewrite the Section based on these assumptions (eg it has to trust
the AD bit)

[Ballot comment]
# Andy Newton, ART AD, comments for draft-ietf-core-dns-over-coap-17
CC @anewton1998

* line numbers:
  - https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-core-dns-over-coap-17.txt&submitcheck=True

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## No Objection

I have no objection to the publication of this document as an RFC.

Many thanks to Todd Herr for the ARTART review.

[Ballot comment]

# Éric Vyncke, INT AD, comments for draft-ietf-avtcore-rtp-scip-05
CC @evyncke

Thank you for the work put into this document. Like others, I was puzzled at first sight about a n+1 mechanism to transport DNS traffic, but after reading the motivation in section 1, it does make sense even if actual data (packet size, transaction, ...) would be helpful as DNS payload is already compressed.

Please find below some non-blocking COMMENT points/nits (replies would be appreciated even if only for my own education).

Special thanks to Marco Tiloca for the shepherd's write-up including the WG consensus and the justification of the intended status.

Other thanks to Vladimír Čunát , the DNS directorate reviewer (at my request), please consider this dns-dir review:
https://datatracker.ietf.org/doc/review-ietf-core-dns-over-coap-17-dnsdir-telechat-cunat-2025-07-31/

I hope that this review helps to improve the document,

Regards,

-éric

## COMMENTS (non-blocking)

### Abstract

Please mention that only OPCODE=0 is supported, i.e., not 'generic DNS messages' but only "DNS queries".

### Section 1

Rather than using RFC 1035, you may want to use STD 13.

Please mention that only OPCODE=0 is supported, i.e., not 'generic DNS messages' but only "DNS queries".

s/link layer frame sizes/link-layer frame sizes/ ?

Thanks for providing SVG graphics, the HTML rendering is so much nicer :)

### Section 3.2

Should there be a space in `255OCTET`?

### Section 4.1

Is there any way for provide an extension to other RR codes ? `For the purposes of this document, only OPCODE 0 (Query) is supported for DNS messages. Future work might provide specifications and considerations for other values of OPCODE.` seems rather vague about extension points. The UPDATE op-code could be very interesting.

### Section 4.2.3

As there is only one example, please use singular in the section title.

### Section 8

s/That information can also imply trust in the DNSSEC validation by that server./That information can also imply trust in the DNSSEC validation by that *DoC* server./

More generally, I was expecting more text about DNSSEC earlier in the text, e.g, by stating that a DoC server MAY (or SHOULD or MUST) be the DNSSEC validator.

Rather then referring to RFC 9364, you may want to refer to BCP 237.

[Ballot discuss]
Thanks for this short and useful specification, I have two areas I would like to discuss to understand how this is expected to operate.

As noted in https://datatracker.ietf.org/doc/statement-iesg-handling-ballot-positions-20220121/, a DISCUSS ballot is a request to have a discussion on the points below; I think that the document would be improved with a small addition here, but can be convinced otherwise.

===
1. Are there actions the server needs to complete when a client has requested
to observe the record, such as to retain a count/list of observing
clients? ... I think I couuld be missing a part of the logic here:

  If the CoAP request indicates that the DoC client wants to observe a
  resource record, a DoC server MAY use a DNS Subscribe message instead
  of a classic DNS query to fetch the information on behalf of a DoC
  client.
===
2. This statement confused me:

  If no more DoC clients observe a resource record for which the DoC
  server has an open subscription, the DoC server MUST use a DNS
  Unsubscribe message to close its subscription to the resource record
  as well.

- 2.1. What does 'no more' mean?
- Is this perhaps when there are no remaining clients, if so how is this
known? See above query about how should (or could) this be detected?
- 2.2. What happens if the DNS Unsubscribe message fails to close its subscription?
... please explain a little the implication and what needs to be done in this case.
====

[Ballot comment]
Thanks to Ben Schwartz for his earlier review (if not his secdir review) of this draft.

Section 1, para 1:  Instead of just referencing DTLS with two RFCs, perhaps say that 'be secured by DTLS 1.2 or 1.3' and then add the RFC references (and you do need RFC 6347 even though 9147 obsoletes it).  If you can do the same for TLS, then do it (obviously RFC8446 is TLS 1.3).  [this construct appears throughout the draft, not just in Section 1]

Section 3, last sentence:  What are the consequences of not complying with the SHOULD?

Section 8, para 4:  I don't understand the first sentence:  'impact....limited,..both harden against injecting...' seem to be opposite?  If the impact is limited, how does it harden against injecting? 

Section 8, para 5, last sentence:  The 'e.g.' makes this confusing.  Are there other options besides DNSSEC?

[Ballot discuss]
Thanks for this short and useful specification, I have two areas I would like to discuss to understand how this is expected to operate.

===
1. Are there actions the server needs to complete when a client has requested
to observe the record, such as to retain a count/list of observing
clients? ... I think I couuld be missing a part of the logic here:

  If the CoAP request indicates that the DoC client wants to observe a
  resource record, a DoC server MAY use a DNS Subscribe message instead
  of a classic DNS query to fetch the information on behalf of a DoC
  client.
===
2. This statement confused me:

  If no more DoC clients observe a resource record for which the DoC
  server has an open subscription, the DoC server MUST use a DNS
  Unsubscribe message to close its subscription to the resource record
  as well.

- 2.1. What does 'no more' mean?
- Is this perhaps when there are no remaining clients, if so how is this
known? See above query about how should (or could) this be detected?
- 2.2. What happens if the DNS Unsubscribe message fails to close its subscription?
... please explain a little the implication and what needs to be done in this case.
====

[Ballot comment]
Thanks for responding to the TSV-ART review by T Pauley.
====
Editorial:
Please more clearly label the following, so it is seen as an RFC-Ed comment:
"Before publication, please replace ff 0a with the hexadecimal...."
===
Editorial:
      If it is "co", a
      CoAP request for CoAP over DTLS MUST be constructed.  Any other
      SvcParamKeys specifying a transport are out of the scope of this
      document.
- This seems to be missing a normative reference to: I-D.ietf-core-coap-dtls-alpn.

NiTs:
/This document provides no specification on how to map between DoC and
  DoH, e.g., at a CoAP-to-HTTP-proxy.  In fact, such...
/This document provides no specification on how to map between DoC and
  DoH, e.g., at a CoAP-to-HTTP-proxy, such.../
(To connect the RFC2119 requirement to the clause to which it refers.)

/...this kind of poisoning attacks./...this kind of poisoning attack./
(remove 's').

[Ballot comment]
Thank you to Elwyn Davies for the GENART review.

From idnits:

  == Unused Reference: 'RFC8742' is defined on line 951, but no explicit
    reference was found in the text

[Ballot comment]
Hi Martine, Christian, Cenk, Thomas, and Matthias,

Thank you for the effort put into this specification.

Also, thanks to Tim Wicinski for the DNSDIR reviews and for the authors for taking care of his comments.

Although there are a bunch of DNS transport out there (Do53, DoT, DoQ, DoH, etc.), the motivations for DoC are solid. Better, the proposed design is well-thought. I support this effort, hence my "Yes" ballot.

Please find below some comments; major comments are tagged with (*):

# Lack of operation considerations (*)

Other than discovery, the document does not discuss operational considerations that are worth to take into account to ease the deployability of DoC. At least, co-existence considerations (when several transport flavors are supported) should be covered (e.g., preference order). The following additional points may be considered:

## Redirection (*)

Likewise, do we allow (and thus need to support) server redirection in case of 5.03? We should be explicit about the expected behavior. An example of deployment case where redirection support may be useful is: bootstrapping with a centralized DoC server and then redirect the DoC client to a local DoC server. I’m not pushing for any direction here, but simply providing an example of aspects to cover.

## Confirmable and Non-Confirmable (*)

Should the spec provide more guidance about which mode should be used by default? I guess, the default mode is Confirmable. Right?

## Control of CoAP Proxy Hops (*)

The spec mentions CoAP proxies, but I wonder whether it needs to mention the use of Hop-Limit Option to control how queries are propagated or help detect infinite loops due to incorrect proxy configuration.

## Troubleshooting (*)

Do we need extra codes to demux DNS-related errors vs. conventional CoAP? For example, CoAP leg may be OK but the upstream DNS query may not be sent out because of a DNS failure. How to report that back to the DoC client?

# SVCB is normative  (*)

Text such as (and similar)

  This document specifies "docpath" as a single-valued SvcParamKey that
  is mandatory for DoC SVCB records. 

or

  Paths with longer segments cannot be advertised
  with the "docpath" SvcParam and are thus NOT RECOMMENDED for the path
  to the DoC resource.

Suggests that understanding the concept of SvcParam is required. I suggest to cite SVCB as normative.

# Recursion termination in the CoAP realm

Figure 1 may be interpreted as if “conventional” DNS message will always be triggered by a query from a DoC client. Should we mention that DoC server can terminate the query if it is authoritative for the queried resource?

# Back-to-Back DoC Server and Do53/DoT/DoH

There is no mapping frozen in the spec between various DNS transport. It would be cleaner from an architectural standpoint to indicate the B2B entity in Figure 1.

# Trusted source

CURRENT:
  Automatic configuration
  SHOULD only be done from a trusted source.

Why isn’t this a MUST?

# On OSCORE

CURRENT:
  Because the ALPN extension is only
  defined for (D)TLS, these mechanisms cannot be used for DoC servers
  which use only OSCORE [RFC8613] and Ephemeral Diffie-Hellman Over
  COSE (EDHOC) [RFC9528] (with COSE abbreviating "Concise Binary Object
  Notation (CBOR) Object Signing and Encryption" [RFC9052]) for
  security. 

Please note that DNR says the following:

      The "alpn" SvcParam may not be required in contexts such as a
      variant of DNS over the Constrained Application Protocol (CoAP)
      where messages are encrypted using Object Security for Constrained
      RESTful Environments (OSCORE) [RFC8613].

# Mysterious destination IP address (*)

CURRENT:
  *  The destination address for the request SHOULD be taken from
      additional information about the target, e.g., from an AAAA resource record
      associated with the target name or from an "ipv6hint" SvcParam

How we got that resolution as at this stage we don’t have a DNS server to communicate with? Maybe I’m missing something.

# Redundant requirement?

CURRENT:
  A DoC server MUST be able to parse requests of
  Content-Format "application/dns-message".

How is this different from:

  “Both DoC client and DoC server MUST be able to parse contents in the "application/dns-message"
  Content-Format"?

# I-D.ietf-iotops-7228bis note

It is unlikely that I-D.ietf-iotops-7228bis will make it before DoC. I suggest you simply delete that RFC Editor note.

Cheers,
Med

[Ballot comment]
One more item I noticed while preparing the ballot: the abstract and introduction state the use of DTLS and OSCORE for message protection, but TLS is also supported according to the remaining sections. Please either explicitly mention TLS or adjust to "(D)TLS" where appropriate.

IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-core-dns-over-coap-15. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there are three actions which we must complete.

First, in the CoAP Content-Formats registry in the Constrained RESTful Environments (CoRE) Parameters registry group located at:

https://www.iana.org/assignments/core-parameters/

a single new registration will be made as follows:

Content Type: application/dns-message
Content Coding:
Media Type: [application/dns-message]
ID: [ TBD-at-Registration ]
Reference: [RFC8484][ RFC-to-be; Section 4.1 ]

IANA notes that the authors have suggested an ID of 553 for this registration.

As this document requests a registration in an Expert Review or Specification Required (see RFC 8126) registry, we have completed the required Expert Review via a separate request.

Second, in the DNS SVCB Service Parameter Keys (SvcParamKeys) registry in the DNS Service Bindings (SVCB) registry group located at:

https://www.iana.org/assignments/dns-svcb/

a single new registration will be made as follows:

Number: [ TBD-at-Registration ]
Name: docpath
Meaning: DNS over CoAP resource path
Change Controller: IETF
Reference: [ RFC-to-be; Section 3 ]

IANA notes that the authors have suggested the number 10 for this new registration.

As this also requests a registration in an Expert Review or Specification Required (see RFC 8126) registry, we have initiated the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

Third, in the Resource Type (rt=) Link Target Attribute Values registry in the Constrained RESTful Environments (CoRE) Parameter registry group located at:

https://www.iana.org/assignments/core-parameters/

a single new registration will be made as follows:

Value: core.dns
Description: DNS over CoAP resource.
Reference: [ RFC-to-be; Section 3 ]

We understand that these are the only actions required to be completed upon approval of this document.

NOTE: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Please note that specific values cannot be reserved. However, early allocation is available for some types of registrations. For more information, please see RFC 7120.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2025-07-04):

From: The IESG
To: IETF-Announce
CC: core-chairs@ietf.org, core@ietf.org, draft-ietf-core-dns-over-coap@ietf.org, marco.tiloca@ri.se, mbishop@evequefou.be
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (DNS over CoAP (DoC)) to Proposed Standard


The IESG has received a request from the Constrained RESTful Environments WG
(core) to consider the following document: - 'DNS over CoAP (DoC)'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2025-07-04. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document defines a protocol for exchanging DNS messages over the
  Constrained Application Protocol (CoAP).  These CoAP messages can be
  protected by DTLS-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).




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-core-dns-over-coap/


The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/5233/



The document contains these normative downward references.
See RFC 3967 for additional information:
    draft-ietf-core-coap-dtls-alpn: ALPN ID Specification for CoAP over DTLS (None - Internet Engineering Task Force (IETF) stream)
    draft-ietf-cbor-edn-literals: CBOR Extended Diagnostic Notation (EDN) (None - Internet Engineering Task Force (IETF) stream)

# Document Shepherd Writeup for draft-ietf-core-dns-over-coap

Document status: https://datatracker.ietf.org/doc/draft-ietf-core-dns-over-coap/

Document Shepherd: Marco Tiloca

Area Director: Mike Bishop


## Document Summary

This document defines DNS over CoAP (DoC), a protocol for exchanging DNS messages using the Constrained Application Protocol (CoAP) (RFC 7252).


## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a few individuals, with others being silent, or did it reach broad agreement?

  The WG has reached broad agreement and strong consensus on this document.

2. Was there controversy about particular points, or were there decisions where the consensus was particularly rough?

  There has been no controversy during the development of this document.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

    No.

4. For protocol documents, are there existing implementations of the contents of the document? Have a significant number of potential implementers indicated plans to implement? Are any existing implementations reported somewhere, either in the document itself (as RFC 7942 recommends) or elsewhere (where)?

  Yes, there are at least two known implementations. Within the document, those are surveyed in the Section "Implementation Status", per the recommendations from RFC 7942.


### Additional Reviews

5. Do the contents of this document closely interact with technologies in other IETF working groups or external organizations, and would it therefore benefit from their review? Have those reviews occurred? If yes, describe which reviews took place.

  There is a close interaction between the protocol specified in this document and the DNS ecosystem.

  The document has notably received reviews from DNS experts, including Ben Schwartz as well as Tim Wicinski who provided two DNSDIR Early reviews (of versions -01 and -09).

  During both the WG Adoption Call and the WG Last Call for this document, the Working Groups DNSOP and DPRIVE have been CCed on the CoRE WG mailing list.

6. Describe how the document meets any required formal expert review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

  Not applicable.

7. If the document contains a YANG module, has the final version of the module been checked with any of the recommended validation tools for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC 8342?

  Not applicable.

8. Describe reviews and automated checks performed to validate sections of the final version of the document written in a formal language, such as XML code, BNF rules, MIB definitions, CBOR's CDDL, etc.

  Not applicable.


### Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this document is needed, clearly written, complete, correctly designed, and ready to be handed off to the responsible Area Director?

  The Shepherd fully supports the document and believes it to be ready.

10. Several IETF Areas have assembled lists of common issues that their reviewers encounter. For which areas have such issues been identified and addressed? For which does this still need to happen in subsequent reviews?

    None of the common issues from the IETF areas has been identified as applicable to this document.

11. What type of RFC publication is being requested on the IETF stream (Best Current Practice, Proposed Standard, Internet Standard, Informational, Experimental or Historic)? Why is this the proper type of RFC? Do all Datatracker state attributes correctly reflect this intent?

    The intended RFC status is Proposed Standard, as fitting for the protocol specification provided by this document.

    All Datatracker state attributes correctly reflect this intent.

12. Have reasonable efforts been made to remind all authors of the intellectual property rights (IPR) disclosure obligations described in BCP 79? To the best of your knowledge, have all required disclosures been filed? If not, explain why. If yes, summarize any relevant discussion, including links to publicly-available messages when applicable.

    The IETF has received one "IPR disclosure" related to this document, see https://datatracker.ietf.org/ipr/5233/

    The existence of such IPR has been explicitly reminded to the CoRE WG before the WG Last Call on this document occurred, and again during a final "IPR Poll" run by the Shepherd while preparing the present Write-Up.

    Each author has stated that, besides the already filed IPR declaration mentioned above, they do not have direct, personal knowledge of any further IPR related to this document. The Shepherd is not aware of any further IPR either.

    In the CoRE WG, there have been no concerns raised about the known IPR declaration mentioned above and no further IPR discussion about this document has occurred.

13. Has each author, editor, and contributor shown their willingness to be listed as such? If the total number of authors and editors on the front page is greater than five, please provide a justification.

    Yes.

14. Document any remaining I-D nits in this document. Simply running the idnits tool is not enough; please review the "Content Guidelines" on authors.ietf.org.

    No I-D nits are left; the few warnings and comments raised by the idnits tool are actually fine.

    In particular, the reference to RFC 6347 (obsoleted by RFC 9147) is intentional. This is in order to explicitly consider also DTLS 1.2, as the secure communication protocol originally selected for CoAP in RFC 7252.

    Furthermore, the two reported DOWNREF items are deemed appropriate and acceptable at this point (see points 17 and 18 below for more details).

    The document complies with the "Content Guidelines" on authors.ietf.org.

15. Should any informative references be normative or vice-versa? See the IESG Statement on Normative and Informative References.

    References are listed in the appropriate category.

16. List any normative references that are not freely available to anyone. Did the community have sufficient access to review any such normative references?

    All the normative references are freely available.

17. Are there any normative downward references (see RFC 3967 and BCP 97) that are not already listed in the DOWNREF registry? If so, list them.

    Yes, they are the two Internet Drafts draft-ietf-cbor-edn-literals and draft-ietf-core-coap-dtls-alpn.

    As to draft-ietf-cbor-edn-literals, it has already been submitted to the IESG.

    As to draft-ietf-core-coap-dtls-alpn, it has been submitted to the IESG closely before the submission of the present document.

18. Are there normative references to documents that are not ready to be submitted to the IESG for publication or are otherwise in an unclear state? If so, what is the plan for their completion?

    No. The two normatively referred Internet Drafts will both have been submitted to the IESG by the time that publication has been requested for the present document.

19. Will publication of this document change the status of any existing RFCs? If so, does the Datatracker metadata correctly reflect this and are those RFCs listed on the title page, in the abstract, and discussed in the introduction? If not, explain why and point to the part of the document where the relationship of this document to these other RFCs is discussed.

    No.

20. Describe the document shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all aspects of the document requiring IANA assignments are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that each newly created IANA registry specifies its initial contents, allocations procedures, and a reasonable name (see RFC 8126).

    For the three IANA registries for which registrations are requested, the provided IANA considerations are correct, complete, and appropriate.

    This document does not define new IANA registries.

21. List any new IANA registries that require Designated Expert Review for future allocations. Are the instructions to the Designated Expert clear? Please include suggestions of designated experts, if appropriate.

    Not applicable.

# Document Shepherd Writeup for draft-ietf-core-dns-over-coap

Document status: https://datatracker.ietf.org/doc/draft-ietf-core-dns-over-coap/

Document Shepherd: Marco Tiloca

Area Director: Mike Bishop


## Document Summary

This document defines DNS over CoAP (DoC), a protocol for exchanging DNS messages using the Constrained Application Protocol (CoAP) (RFC 7252).


## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a few individuals, with others being silent, or did it reach broad agreement?

  The WG has reached broad agreement and strong consensus on this document.

2. Was there controversy about particular points, or were there decisions where the consensus was particularly rough?

  There has been no controversy during the development of this document.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

    No.

4. For protocol documents, are there existing implementations of the contents of the document? Have a significant number of potential implementers indicated plans to implement? Are any existing implementations reported somewhere, either in the document itself (as RFC 7942 recommends) or elsewhere (where)?

  Yes, there are at least two known implementations. Within the document, those are surveyed in the Section "Implementation Status", per the recommendations from RFC 7942.


### Additional Reviews

5. Do the contents of this document closely interact with technologies in other IETF working groups or external organizations, and would it therefore benefit from their review? Have those reviews occurred? If yes, describe which reviews took place.

  There is a close interaction between the protocol specified in this document and the DNS ecosystem.

  The document has notably received reviews from DNS experts, including Ben Schwartz as well as Tim Wicinski who provided two DNSDIR Early reviews (of versions -01 and -09).

  During both the WG Adoption Call and the WG Last Call for this document, the Working Groups DNSOP and DPRIVE have been CCed on the CoRE WG mailing list.

6. Describe how the document meets any required formal expert review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

  Not applicable.

7. If the document contains a YANG module, has the final version of the module been checked with any of the recommended validation tools for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC 8342?

  Not applicable.

8. Describe reviews and automated checks performed to validate sections of the final version of the document written in a formal language, such as XML code, BNF rules, MIB definitions, CBOR's CDDL, etc.

  Not applicable.


### Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this document is needed, clearly written, complete, correctly designed, and ready to be handed off to the responsible Area Director?

  The Shepherd fully supports the document and believes it to be ready.

10. Several IETF Areas have assembled lists of common issues that their reviewers encounter. For which areas have such issues been identified and addressed? For which does this still need to happen in subsequent reviews?

    None of the common issues from the IETF areas has been identified as applicable to this document.

11. What type of RFC publication is being requested on the IETF stream (Best Current Practice, Proposed Standard, Internet Standard, Informational, Experimental or Historic)? Why is this the proper type of RFC? Do all Datatracker state attributes correctly reflect this intent?

    The intended RFC status is Proposed Standard, as fitting for the protocol specification provided by this document.

    All Datatracker state attributes correctly reflect this intent.

12. Have reasonable efforts been made to remind all authors of the intellectual property rights (IPR) disclosure obligations described in BCP 79? To the best of your knowledge, have all required disclosures been filed? If not, explain why. If yes, summarize any relevant discussion, including links to publicly-available messages when applicable.

    The IETF has received one "IPR disclosure" related to this document, see https://datatracker.ietf.org/ipr/5233/

    The existence of such IPR has been explicitly reminded to the CoRE WG before the WG Last Call on this document occurred, and again during a final "IPR Poll" run by the Shepherd while preparing the present Write-Up.

    Each author has stated that, besides the already filed IPR declaration mentioned above, they do not have direct, personal knowledge of any further IPR related to this document. The Shepherd is not aware of any further IPR either.

    In the CoRE WG, there have been no concerns raised about the known IPR declaration mentioned above and no further IPR discussion about this document has occurred.

13. Has each author, editor, and contributor shown their willingness to be listed as such? If the total number of authors and editors on the front page is greater than five, please provide a justification.

    Yes.

14. Document any remaining I-D nits in this document. Simply running the idnits tool is not enough; please review the "Content Guidelines" on authors.ietf.org.

    No I-D nits are left; the few warnings and comments raised by the idnits tool are actually fine.

    In particular, the reference to RFC 6347 (obsoleted by RFC 9147) is intentional. This is in order to explicitly consider also DTLS 1.2, as the secure communication protocol originally selected for CoAP in RFC 7252.

    Furthermore, the two reported DOWNREF items are deemed appropriate and acceptable at this point (see points 17 and 18 below for more details).

    The document complies with the "Content Guidelines" on authors.ietf.org.

15. Should any informative references be normative or vice-versa? See the IESG Statement on Normative and Informative References.

    References are listed in the appropriate category.

16. List any normative references that are not freely available to anyone. Did the community have sufficient access to review any such normative references?

    All the normative references are freely available.

17. Are there any normative downward references (see RFC 3967 and BCP 97) that are not already listed in the DOWNREF registry? If so, list them.

    Yes, they are the two Internet Drafts draft-ietf-cbor-edn-literals and draft-ietf-core-coap-dtls-alpn.

    As to draft-ietf-cbor-edn-literals, it has already been submitted to the IESG.

    As to draft-ietf-core-coap-dtls-alpn, it has been submitted to the IESG closely before the submission of the present document.

18. Are there normative references to documents that are not ready to be submitted to the IESG for publication or are otherwise in an unclear state? If so, what is the plan for their completion?

    No. The two normatively referred Internet Drafts will both have been submitted to the IESG by the time that publication has been requested for the present document.

19. Will publication of this document change the status of any existing RFCs? If so, does the Datatracker metadata correctly reflect this and are those RFCs listed on the title page, in the abstract, and discussed in the introduction? If not, explain why and point to the part of the document where the relationship of this document to these other RFCs is discussed.

    No.

20. Describe the document shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all aspects of the document requiring IANA assignments are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that each newly created IANA registry specifies its initial contents, allocations procedures, and a reasonable name (see RFC 8126).

    For the three IANA registries for which registrations are requested, the provided IANA considerations are correct, complete, and appropriate.

    This document does not define new IANA registries.

21. List any new IANA registries that require Designated Expert Review for future allocations. Are the instructions to the Designated Expert clear? Please include suggestions of designated experts, if appropriate.

    Not applicable.

Changed document external resources from:

github_repo https://github.com/core-wg/draft-dns-over-coap (Working Group Repo)

to:

github_repo https://github.com/core-wg/draft-dns-over-coap (Working Group Repo)
related_implementations https://github.com/RIOT-OS/RIOT/tree/master/sys/net/application_layer/gcoap (DoC client implementation in RIOT)
related_implementations https://github.com/anr-bmbf-pivot/aiodnsprox (DoC server implementation in Python)