I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-core-dns-over-coap-?? Reviewer: Elwyn Davies Review Date: 2025-06-26 IETF LC End Date: 2025-07-04 IESG Telechat date: Not scheduled for a telechat Summary:Ready with Nits. All seems to be in good shape. The nits are mostly simple typographcal issues plus a number of unexpanded abbreviations. Major issues: None Minor issues: None Nits/editorial comments: s1, para 1 and s8: Since RFC 9147 obsoletes RFC6347, is the reference to RFC 6347 needed? 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 CRI Constrained Resource Identifier CoRE Constrained RESTful Environments 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 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