As a DNS reviewer, I don't feel competent to review the cryptographic and packet format content, which is 99.99% of this Internet-Draft. I did read through that content (skimmed? this draft is pretty long) and didn't notice anything amiss. The sole mention of DNS is in 5.2.3.24 "Notation Data", where it says: > Names in the user namespace consist of a UTF-8 string tag followed by "@" followed by a DNS domain name. Note that the tag MUST NOT contain an "@" character. For example, the "sample" tag used by Example Corporation could be "sample@example.com". > > Names in a user space are owned and controlled by the owners of that domain. Obviously, it's bad form to create a new name in a DNS space that you don't own. > > Since the user namespace is in the form of an email address, implementers MAY wish to arrange for that address to reach a person who can be consulted about the use of the named tag. Note that due to UTF-8 encoding, not all valid user space name tags are valid email addresses. This is clear on the surface -- if one is using a "user namespace" identifier, it should look like an email address. This is likely to be sufficient in practice. However, as a DNS person, one wonders what is meant by "DNS domain name" *precisely*. In particular, is it supposed to be an existing DNS domain name? Is it dangerous if not? Are there limits on the length of the domain name part (or the username part)? How does "UTF-8" encoding mesh with standard DNS domain name formats? Do we expect the domain name part to be "letters-digits-hyphens"? or can it be anything, differing from standard DNS presentation format by UTF-8 encoding of non-ascii characters instead of decimal encoding? My guess is that what is meant is that the DNS domain name part of the identifier is an existing (at the time) domain name that SHOULD be controlled by the user. Saying it is existing (or did exist) brings along many restrictions that then need not be stated. These are very minor questions about a very minor part of this draft, however.