[CCWG-ACCT] CCWG - Proposed Responses to questions on Draft Bylaws

[Andrew Sullivan]

Hi,

On Fri, Apr 08, 2016 at 04:54:44PM -0300, Rubens Kuhl wrote:
> 
> ICANN might have authority over third-level in very specific circumstances. The one I know is a gTLD registry offering registrations on the 3rd level; even though most gTLDs offer registrations at 2nd level, if registry operator wishes to sell domains at 3rd level, ICANN has contractual authority to establish conditions (like which 2nd levels) and requirements (like proper escrow of registration data). This RSEP public comment is one of such cases:
> https://www.icann.org/public-comments/wed-amendment-2014-06-04-en
> 
> And that probably won't be even limited to 3rd level per se... the DNS maximum label size is the limit. 
> 

I think the above demands very careful attention to the reasoning.  I
believe that, if we consider the above argument, there are two
possibilities:

    1.  ICANN can do this due to its commercial relationships flowing
    from its control of the root zone.

    2.  ICANN can do this because it really is in charge overall of
    names in the DNS.

Let me start with the latter.  I believe that, if that is true, then
ICANN and anyone who uses the present IANA root servers are complicit
in undermining the architecture of the DNS.  The design of the DNS is
decentralized authority.  Indeed, the "SOA" record, which marks the
apex of every zone in the DNS, stands for "start of authority".  The
point of this arrangement is to permit distributed management of the
names in the DNS in accordance with the operational distribution of
most of the Internet: your network, your rules.  I do not believe for
a moment that we are all -- or even that ICANN is -- involved in some
conspiracy to undermine the Internet.  So this explanation makes no
sense, and therefore the reason for ICANN's ability to set rules about
registration at parts of the domain name tree must come from something
else.

That something else is the first option.  ICANN has the policy
authority over what labels go into the root zone.  ICANN does this by
coming to some agreement with those who are allocated these labels.
Those who are allocated such labels may choose to have them activated
by having them appear in the root zone, in which case the label
becomes a "top-level domain name", by getting a delegation (some NS
records in the root zone) to another name server.  At that name
server, there is an SOA record that marks the start of authority.  So,
TLD operators after such a delegation are authoritative over the name
space so delegated.  So, then, how does ICANN get policy authority?
Simple: commercial agreement.

Since ICANN holds the policy over the root zone, it can in theory
remove the delegation of the name in question at any time.  So, it can
set as conditions of its delegation of a name any policies it wants on
the entity that gets that delegation.  What ICANN does in fact is use
ICANN-community-developed consensus policies and imposes them on these
operators.  The condition, then, is on the _operator_, and not on the
top-level domain as such.  If the operator wants to operate some lower
domain as a delegation-centric domain [*], then it's not too
surprising that ICANN believes its agreements cover that too.  And
hence ICANN's ability to impose terms on registrars: it can require
TLD registries to permit retail operation only through accredited
registrars, and then it can set conditions on how that accreditation
is maintained.  This is ICANN's market-making activity, but it is able
to do it only through its control of the root zone.

[* Aside: that's what we DNS geeks call TLDs and similar kinds of
domains: delegation-centric, because they mostly contain delegations.
Other zones have mostly resource records that point to service
offerings and so on, like AAAA and A and MX records.  Com is
delegation-centric because it mostly exists to delegate out to others;
Verisign doesn't run anvilwalrusden.com any more than ICANN runs com.]

I claim that the above is the reason ICANN's Mission involving
allocation and assignment of domain names is only in the root. [+] It
doesn't assign things generally in the DNS.  I am not a direct
customer of ICANN and I do not have a direct commercial relationship
with them.  If they told me to register icann.anvilwalrusden.com in my
zone, I would quite correctly tell them about a short pier awaiting
their long walk.  Indeed, avoiding such a power (which nobody,
including I think ICANN, really wants ICANN to have) is precisely what
the clarifications to ICANN's limited mission is all about.  It
would be bad for ICANN to have a Mission that gave it overall
authority over names in the DNS, because that would allow it to be
used as a regulator.  And indeed, with the new community powers, it
would be possible for the Empowered Community to force ICANN to act
that way unless the explicit restriction (to the root zone) is
restored to the bylaws.

[+ Aside: "only in the root" is a slight exaggeration, because of int.
But as we all know, int is a bit of a wart on the arrangements and it
would probably be better if ICANN were out of that.  The only reason
it hangs around is because of the misfortune that it's already there;
it isn't clear how to fix it, and we have a different political hot
potato to cool just now so it'll have to wait.  It's permissable
anyway under the new bylaws, AFAICT, because the bylaws encourage such
temporary arrangements in order to support security and stability of
the DNS.]

Best regards,

A

-- 
Andrew Sullivan
ajs at anvilwalrusden.com