Re: [Internetgovtech] Cross community

Avri Doria <> Wed, 23 July 2014 21:47 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C74471A030B for <>; Wed, 23 Jul 2014 14:47:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.165
X-Spam-Status: No, score=0.165 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kwQIjAOIKgsH for <>; Wed, 23 Jul 2014 14:47:02 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id C4FDA1A016F for <>; Wed, 23 Jul 2014 14:47:01 -0700 (PDT)
Received: from ([]) by (8.14.4/8.14.4) with ESMTP id s6NLl0KY016714 for <>; Wed, 23 Jul 2014 17:47:00 -0400
Received: (qmail 1469 invoked by uid 0); 23 Jul 2014 21:47:00 -0000
Received: from unknown (HELO ? ( by 0 with ESMTPA; 23 Jul 2014 21:47:00 -0000
Message-ID: <>
Date: Wed, 23 Jul 2014 17:46:59 -0400
From: Avri Doria <>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Antivirus: avast! (VPS 140722-1, 07/22/2014), Outbound message
X-Antivirus-Status: Not-Tested
Subject: Re: [Internetgovtech] Cross community
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Internet Governance and IETF technical work <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 23 Jul 2014 21:47:03 -0000


On 23-Jul-14 17:24, Brian E Carpenter wrote:
> On 24/07/2014 09:15, Avri Doria wrote:
>> Hi,
>> On 23-Jul-14 16:43, Brian E Carpenter wrote:
>>> It would be absurd to define new mechanisms if the existing ones are
>>> fully satisfactory.
>> ah the old 'if it ain't broke' conundrum.
>> Thing is, while it is not broken for some, it is broken for others.
>> For me, as an example at this point, I see breakage on things like the
>> self established ability of the IETF to unilaterally decide that a
>> protocol mandates removing labels from the list of available TLD labels.
> Can you be specific, since I really don't what you mean?

RFC 6761 Special Use Domain Names

Allows for protocol that meet certain conditions to reserve TLDs.

>> As a long time participant in the IETF, I see how natural this decision
>> is for the the IETF and a part of me cheers at the simplicity of this
>> solution for any number of issues.
>> As a member of the ICANN GNSO Council I am outraged at the idea because
>> it is a policy decision that the technical arm of the enterprise has no
>> business making.
>> To whom is the IETF accountable in making this decision?  Just itself?
> What does that have to do with ICANN or IANA accountability?

Well this and IETF act with regard to IANA entries in a area where ICANN
might think it get a say.

To whom is IANA accountable in making the reservation? the IETF.

But ICANN is responsible for policy regarding TLDs.  It gets to tell
IANA what to do with TLDs.

It seems to me that it is what could be called a cross-accountabilty

IETF 'quite rightly' says it controls protocol parameters and it can do
what it pleases with them despite any policy implications that may occur
that it may or may not have considered.  It tells IANA to make these
changes.  IANA arrangements with IETF says do what IETF says.  As long
as we stick to a single point of accountability for each function we
have no way out of this problem.  I therefore argue that there has to be
accountability mechanisms that cross the 'jurisdictions'.

And this is but one simple issue.