IETF Last Call Review of draft-ietf-core-groupcomm-bis-14
review-ietf-core-groupcomm-bis-14-dnsdir-lc-spacek-2025-07-11-00

Document: Group Communication for the Constrained Application Protocol (CoAP)

I was assigned as the dnsdir reviewer for draft-ietf-core-groupcomm-bis-14.
For more information about the DNS Directorate, please see
https://wiki.ietf.org/en/group/dnsdir

I did not review CoAP bits in depth but from a quick glance it makes sense on
the high level. The text is legible to a non-CoAP person, which is something I
did not expect. Great work!

The document mentions very little of DNS, but funnily enough even that little
might be too much :-) See below.

### High level nit/Terminological issue
IIUC the only interaction with DNS is via coap:// URIs, but coap:// URI is not
defined to use 'DNS'. RFC 7252 section 6.1 clearly says DNS is not the only
option.

This draft goes to great lengths to allow multiple transport protocols and it
seems to support distributed operation, so I would think the same should be
done with naming system, in the spirit of RFC 7252 section 6.1. (Multicast DNS
comes to mind for distributed operation, as an example.)

### Section 2.2.1.1. CoAP Groups
I recommend removing references to DNS and specifically to RFC1035. Perhaps
replace them with RFC 7252 style: 'a name resolution service, such as DNS,' or
something like that.

(If you insist on calling out DNS for reverse mapping at the end of the
section, RFC 1035 might not be the best reference: It is a very old document
and it defines 'inverse queries' in section 6.4 which are not a thing anymore,
and does not mention IPv6 at all. Given that all examples in this draft use
IPv6 perhaps RFC 3596 section 2.5 might be a better reference.)

### B.3. Group Naming using the URI Authority Component
> Specifically, the first label of the DNS name is used.

Nit #1: The host component is not a 'DNS name' but a 'host name'. Again, some
other naming system might be used to resolve 'host name' into an address.

Nit #2: I think it would be better to say either 'leftmost' or 'least
significant' because what label is 'first' is kind of uncertain, at least in
DNS. 'Most significant' is written on the right end, but DNS tree starts on top
with 'first' label being root ("")... A rabbit hole to avoid.