Document: draft-ietf-core-groupcomm-bis Title: Group Communication for the Constrained Application Protocol (CoAP) Reviewer: Petr Špaček Review result: Ready with Nits 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. -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
