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

[Seun Ojedeji]

Hi Andrew,

Thanks for providing convincing explanation to confirm there is indeed a
way to approach this (based on ICANN policy authority on the root). That
said, I like to quote a specific part of your message below which I think
may be quite important.

"...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...."

Considering that staff has implementation experience on this, it may be
good hear their thought on the first part of your comment above. Hopefully
we will not be taking the question to legal (well maybe we could ask ICANN
staff legal since they are expected to have some implementation experience
as well).

Regards

Sent from my LG G4
Kindly excuse brevity and typos
On 11 Apr 2016 03:28, "Andrew Sullivan" <ajs at anvilwalrusden.com> wrote:

> 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
> _______________________________________________
> Accountability-Cross-Community mailing list
> Accountability-Cross-Community at icann.org
> https://mm.icann.org/mailman/listinfo/accountability-cross-community
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/accountability-cross-community/attachments/20160411/d5bcd36c/attachment.html>