[CCWG-ACCT] Some remarks on open questions on mission (was Re: Deck for Meeting #75 Mission Statement discussion)

Andrew Sullivan ajs at anvilwalrusden.com
Thu Jan 7 18:58:14 UTC 2016


On Wed, Jan 06, 2016 at 07:03:10PM +0000, Burr, Becky wrote:
> Is attached in DRAFT FORM.

There are some questions in the draft, and in the interests of cutting
down mic time in the meeting I have some observations.  Sorry these
are so close to the conference call, but I couldn't send sooner.

    Does ICANN’s fundamental Mission to ensure “stable and secure
    operation” of the DNS, and its various Commitments (i.e., to use
    processes that enable compe;;on, and to preserve stability,
    reliability, security, global interoperability, resilience, and
    openness) adequately address [consumer protection] concern?

I say it does.  If users are abused by the operation of the DNS, they
won't trust it, and that will undermine the stable and secure

On "including the allocation and assignment of names in the root zone
as a result of those policies," I don't object to the inclusion.  But
the board's overall proposed language is troubling:

    In this role, ICANN’s scope includes the coordination of the
    development and implementation of domain name policies (including
    the allocation and assignment of names in the root zone as a result
    of those policies.)

First, the move to "includes" is in effect an unbounded scope, because
it does not state where the end of the inclusion lies.  But more
troubling, this says, "development and implementation of domain name
policies," as though ICANN has responsibility for domain names other
than the root zone.  It never has, it does not today, it should not,
and it must not.

The DNS is a system of distributed authority: the SOA record, which
marks a zone cut, is so named because it stands for "Start of
Authority".  ICANN has no more business telling me what to do in
anvilwalrusden.com or crankycanuck.ca than I have business in telling
them how to run icann.org.  ICANN can make policies about under what
conditions it will delegate from the root zone, and for those policies
to have teeth it can of course say that if the delegated zone does not
conform with a policy the delegation will be removed (although that
has interesting stability implications).  It can also make policies
about any other zone for which it is the authority (such as
icann.org).  But it cannot make policies for domain names in general.
This is a consequence of the DNS architecture.

Best regards,


Andrew Sullivan
ajs at anvilwalrusden.com

More information about the Accountability-Cross-Community mailing list