How about adding it to 2606 ? 2606bis could add a note that
".local" might be used for local purposes specified elsewhere
There is now a 2606bis draft, but it doesn't mention .local :
This memo quotes an agreement between ICANN and VeriSign about
gTLD .net published in
While that's all fine for gTLD .net and all TLDs with similar
agreements it's somewhat strange for other TLDs:
What's wrong with any "labels at all levels" matching one of
aso, gnso, icann, internic, ccsno, afrinic, apnic, arin,
example, gtld-servers, iab, iana, iana-servers, iesg, ietf,
irtf, istf, lacnic, latnic, rfc-editor, ripe, root-servers ?
Where's the technical problem with one of these strings in an
SLD or elsewhere ? What's the technical purpose of reserving
these strings everywhere ? When did all ccTLDs agree to this
This draft references the informational RfC 1591 as normative.
So far I thought that 1591 in essence says that the internal
business of a TLD is, well, its internal business.
E.g. it's not obliged to offer a whois server no matter what
ICANN's agreements with other TLDs like .net might say.
For chapter 3.3 the purpose is clear, but xn-- is not more
reserved, it's already used as specified elsewhere.
3.4 is also clear: FQDN whois.sc is a Bad Thing, because it's
unrelated to a whois server of ccTLD .sc OTOH one reserved SLD
nic could be good enough for all TLDs, an inflation of reserved
SLD labels doesn't help (?)
3.2 prohibits single characters as SLD. What's the technical
purpose of this prohibition ? It also prohibits two characters
as SLD unless the government of the corresponding ccTLD, or if
that doesn't exist the ISO 3166 MA allow it.
What on earth has ISO 3166 to do with SLDs ? They are ignorant
about ccTLDs as demonstrated by CS. Numerous SLDs using two
characters, country codes, letters, or else, exist. If ICANN
doesn't allow this in its agreements it's fine, but where is
the technical reason to prohibit something like http://a9.com
or http://ix.de ? (Yes, the latter is a legacy case under
DENIC rules, but so far this is no BCP affecting all TLDs.)
Ietf mailing list