Re: the names that aren't DNS names problem, was Last Call: <draft-ietf-dnsop-onion-tld-00.txt>

[John C Klensin <[e-mail]>]

--On Saturday, July 25, 2015 4:58 PM +0000 John Levine
<[e-mail]> wrote:

>> [1] That "due diligence by applicants" argument suggests that
>> this is a huge fuss about nothing.
> 
> The problem, as noted with .CS, is that it screwed up people
> who have no connection to the applicant and no interest in
> buying a domain name from them.  Viz. the current concerns
> about .corp, .home. and .mail.

Exactly.  A "due diligence by applicant" requirement might still
require those applicants to search for unrelated parties who
might be negatively affected, but one could reasonably expect
them to not be highly motivated in such a search and for the
affected parties to be hard to find.    The place where the CS.
analogy breaks down is that we certainly knew enough about
"relative name" practices to anticipate trouble but, given other
arrangements at the time, we had little or no standing to object
and neither the relevant government nor 3166/MA considered
"don't cause an Internet DNS mess" to be among their criteria,
much less their priorities.

> I suppose you could say that about .onion, but you could also
> say that their current request to be added to the 6761 list is
> the due diligence.

I may not have said this explicitly before, but I don't have a
problem adding onion to the list given the model that now
exists.  My problem is that I don't see a stopping rule and the
idea of the IETF reserving names using our own collective but
very subjective judgment strikes me as risky, both wrt the
quality and completeness of the list and because I think ICANN
and IETF both benefit from clear delineation about boundaries
and responsibilities.  At least unless we can make the stopping
rules much more clear or the evaluation rules much less
subjective, we are, IMO, at high risk getting risk of getting
ourselves into a situation in which we build lists that ICANN
then becomes responsible for using --and likely evaluating-- in
what has historically been the most political and
special-influence-prone part of their processes.  

I continue to believe that the most straightforward solution is
to turn the list-keeping over to them, with the IETF free to
make recommendations that ICANN could decline only with reasons
and willingness to participate in discussion, but with ICANN
able to accept recommendations from others (including its ACs)
as well.  I can imagine other solutions, but most of them
require significant internal organizational changes within ICANN
(e.g., allowing a technically-oriented AC to say "no" not merely
(even if implicitly) "we suggest 'no' but you can always
override our decision or appoint more committees".

If nothing else, if it is their list, the broader Internet
community knows who to hold accountable.  If it is our list and
they, either as a decision or a matter of sequencing with other
decisions, don't use its provisions, the opportunities for
finger-pointing or worse are, well, considerable.

    john