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

[Mueller, Milton L]

> -----Original Message-----
> 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.

This is correct. So I agree with Andrew, Avri and others that we need to keep the "in the root zone" in there.

I would have to add, however, that even the contractual requirements it imposes on registries are limited by its mission, which is to coordinate the global DNS name space. ICANN could not, I hope you agree, put into a registry contract that the registry operator must steal Andrew Sullivan's fedora whenever he is seen wearing it. Just to use a random example.

Insofar as ICANN can touch domain names beyond the TLD it does so contractually via its delegation of the top level domains in the root zone. It does NOT have any free-floating authority to issue commands about what happens elsewhere in the DNS. 








> 
> 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
> _______________________________________________
> Accountability-Cross-Community mailing list Accountability-Cross-
> Community at icann.org
> https://mm.icann.org/mailman/listinfo/accountability-cross-community