> On 17 Jul 2015, at 10:52 pm, hellekin <helle...@gnu.org> wrote: > > On 07/17/2015 11:32 AM, David Conrad wrote: >> >> No. .LOCAL was not already in the root zone. .FOO is. >> > *** Therefore the .FOO label is not available for Special-Use anymore, > end of story. A Special-Use name cannot be an already registered name in > the root zone. > > If you referring to e.g., .corp that has proposals both for Special-Use > and normal ICANN assignation, this is a distinct issue, as the label is > not yet in the root zone, and there are good reasons why it would be a > bad idea to put it there (already existing name conflicts) but not > compelling (if the .corp registrar is ready to deal with the extra load, > or if capturing all the "leaked" requests from random devices around the > world is not deemed to pose a security issue...). This is an entirely > different matter.
Of course, ICANN has already determined that .corp does pose a security
issue of sufficient significance that .corp will not be delegated.
> Now if there's a prior request for Special-Use and an ICANN registration
> appears after the fact, that would be a problem: if someone would ask to
> register .onion or .gnu today, we'd run into the problem you're suggesti
> ng.
And objections to delegation would almost certainly be raised inside
ICANN processes and dealt with there if that happened.
While it is worth considering whether ICANN gTLD delegation and IETF
Special-Use consideration processes could end up on a collision course in
theory, in practice, it is fairly unlikely. There is significant overlap
between the two organisations from board level on down such that the two are
unlikely to be considered in isolation. The ICANN board obviously considered
the issue (as it was mentioned in correspondence from the board to the
community, which I am unable to locate currently due to ICANNs execrable web
site search/document management), and chose for the moment to, rather than
adding formal mechanisms, to encourage members of the ICANN community to
monitor discussions in DNSOP (which was the catalyst for my joining DNSOP). I
personally think that informal mechanisms will be enough for the moment, and
I’m sure if it proves to be inadequate that other more formal coordination
mechanisms can be considered.
David
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
