[CCWG-ACCT] ICANN doesn't "allocate" or "assign" beyond the root (was Re: CCWG - Proposed Responses to questions on Draft Bylaws)

[Andrew Sullivan]

On Sun, Apr 10, 2016 at 06:40:46PM +0100, Seun Ojedeji wrote:
> above.  A layman thought is a scenario where there is a rule by ICANN that
> requires gTLDs to consider icann.tld to be forbidden, so if removing the
> "in the root" can permit that legitimately then I would be fine.
 
> SO: I agree and this bothers me as well. If there is other way to do this
> without going out of the scope then it will be good otherwise, I think this
> change should be clearly marked during the PC with our rationale indicated.

Apparently I have still failed to communicate this clearly enough:
there is a way to do that.  It stems from ICANN's control of
delegations from the root zone.

Every delegation in the root involves delegation to another party.
Those parties are TLD registries.

When ICANN delegates to a registry, it can attach conditions to that
delegation.  And in fact, that's what it does today: when an entity
(organization, corporation, individual, whatever) gets a delegation
from the root, it agrees to all sorts of consensus policies.  The key
thing here is that it is the _entity_ that makes the agreement.  That
agreement often imposes terms on the operation of the delegated name
space. 

These are terms that control the actions of the entity -- it's not
about "levels" in the DNS.  So, ICANN can also control the actions of
the entity lower in the tree, or even elsewhere in the tree (this sort
of term, for instance, is what made it possible for ICANN to require
registries not to be registrars -- it's not regulation, but commercial
agreement.  I won't agree to X unless you agree to Y).  It all stems
from ICANN's policy control over the root zone.  If there is language
needed to make it clear that such contractual terms required for
deletation are ok (and I do not believe there is such a need, but
let's suppose it), then the language must be about that.  It must not
weaken the claim that ICANN's proper DNS mission is with respect to
the root zone and not others.

This sort of term allows for ICANN's ability to impose conditions on
contracted parties anywhere in the DNS name space at all, without
specifying what ICANN can do at this or that "level" of the DNS.  In
DNS terms, the "levels" of the DNS are a figment of the imagination.
There's no technical difference between name deletation from
really.dumb.long.name.anvilwalrusden.com and com itself.  There's a
_legal_ difference, though, and that's the parties to the agreement.
I registered anvilwalrusden.com with Verisign through a reseller that
resells Tucows services.  I have an agreement with the reseller.  The
reseller has an agreement with Tucows.  Tucows has an agreement with
ICANN and also with Verisign, and Verisign has an agreement with ICANN
too.  I don't have an agreement with ICANN, so ICANN can't impose
contractual terms on me except indirectly (via a long chain).

I hope this makes clear why ICANN doesn't need to have control over
assignment or allocation of names in the DNS generally in order to
impose limits on the freedom of TLD registries even outside the name
directly deleted.  It only needs to work on the root.[1]

A

[1] Again, int is a special case, and I hope we can treat it as the
exception it is.  I can provide a more complicated account if need be.

-- 
Andrew Sullivan
ajs at anvilwalrusden.com