I have been selected as the DNS Directorate reviewer for this draft. The
DNS Directorate seeks to review all DNS or DNS-related drafts as
they pass through IETF last call and IESG review, and sometimes on special
request. The purpose of the review is to provide assistance to the ADs.
For more information about the DNS Directorate, please see
https://wiki.ietf.org/en/group/dnsdir

This document reference the DNS as one of multiple possible name
spaces for Name-Based UUID Generation. It has no considerations that
reflect on the DNS.

Issue:

The document does not reference any DNS RFCs.

Section 5.3, 5.5 and 6.5 refer to "a canonical sequence of octets in
network byte order". It is not specified what that canonical sequence
is nor is there a reference to a document that specifies the canonical
sequence for any of the name spaces.

Section 6.5 also has this:
   *  UUIDs generated at different times from the same name in the same
      namespace MUST be equal.

It is unclear to me how to implement that MUST if there is not a
single canonical sequence specified for a given name space, as is the
case for DNS.

For DNS RFC 8499 has this:
      Format of names: Names in the global DNS are domain names.  There
      are three formats: wire format, presentation format, and common
      display.

The test vectors in Appendix C use the common display format, i.e. they
leave off the root label and the "." before it.

I'm not sure how best to address this issue, options include:
- refer to specifications for all the name spaces and point at the
  canonical sequence (in case of DNS this means RFC 8499 and choosing
  common display)
- mark it out of scope, like is done for "uniqueness within their name
  spaces".
- mark it out of scope, but point out that applications must (MUST?)
  agree on what the canonical sequence is.

Nits:

4.  UUID Format
old: the version bits described in the next sections in determine
new: the version bits described in the next sections determine

6.5.  Name-Based UUID Generation
old: but the hashspace should be used to as the starting point
new: but the hashspace should be used as the starting point