Since I don't know much about EAP overall, I didn't necessarily follow all of the implications of this draft.  However, I think I have a grasp on the DNS implications.

This draft doesn't introduce any new use of the DNS.  Instead it simply asks for a new Special Use Domain name (RFC 6761) and uses domain names strictly as a naming convention for identifiers.  This seems like a perfectly good use for a Special Use Domain, and, in fact, it is just following the example set by 'eap-noob.arpa.'.

The draft suggests that the names need to conform to the domain name rules in RFC 1034.  Because of the way these old RFCs are written, it isn't clear that RFC 1034 puts many restrictions on domain names.  There appears to be an *assumption* that domain names are formed from the "letters-digits-hyphens" part of the ASCII character set, but the only actual requirements are:

1. The overall length of the domain name must be 255 characters or less, and
2. Domain names are case-insensitive in the ASCII range.
3. Domain names end in a period.

Some readers of the old RFCs might conclude that only standard, printable, non-punctuation characters are allowed.   Others may conclude that as long as labels and domain names adhere to the size limits, any character goes.  Thus we could have '\0007\0007\0007.eap.arpa' as an identifier (3 ASCII "bell" characters using the standard "decimal escape" syntax used on DNS zone file format.)  The infamous RFC 1123 is the one that (supposedly) states that "Internet Hosts" have domain names formed by "letters-digits-hyphens".  Of course, EAP "realm" names are not "Internet Hosts", so RFC 1123 likely doesn't apply.

RFC 1034 *is* clear that domain names end with a period, and the various examples in the draft do not.  I note that the IANA registry for Special Use Domain names does include the trailing dot.

Thus, I suggest:

* Consider making the various EPI strings end in a trailing period, OR
* Consider stating up front that they do not (MUST NOT?)
* Consider either using 1034 as a reference but further restricting the characters used in the EPIs, OR
* accept that only referencing RFC 1034 may allow for non-ASCII identifiers.

I'll note that I've spent this entire review essentially on one sentence in this draft.