Re: [Internetgovtech] Cross community

Brian E Carpenter <> Wed, 23 July 2014 22:36 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 726CE1B27A8 for <>; Wed, 23 Jul 2014 15:36:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9fKBXsxOu00E for <>; Wed, 23 Jul 2014 15:36:28 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E60511A004D for <>; Wed, 23 Jul 2014 15:36:27 -0700 (PDT)
Received: by with SMTP id w62so1919340wes.1 for <>; Wed, 23 Jul 2014 15:36:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=EU8tyCWdlePDPpTO6KX28Jwn9fCaDVPB5jwcHX+5F0Q=; b=UUKL/JLLRlSsYpVEHfuulCP1ZBJeDI8bF2SGuDrdHsHV0pDRShAmuRG1Jij2hF0nL0 bP+S8EpcAxLtKxgDQhxEs4uzpmSTGwhx8YwjUHuJRCcepBiye8aGHw56bK39cW0TAYwD d394dUUV/ptJMAIfzOEUgWNqk7zoEA8765Xl5gezamJcrKbYgixFK0fb5X9M6h+h11Bv 1wh+FAeMdlUOSaJVotA/6P+R7N8vKYS49r6uCxOkGavk3s3kT4TPKWDlju/YlADN86rM bdHZy3HD3LZfia5/mUKFhT0a5UjfFhRjfExYO+BEIEsvXyhJSVF9+t+PrNPcUfN3Reiv 0Vgw==
X-Received: by with SMTP id ev6mr3580026wjc.61.1406154985448; Wed, 23 Jul 2014 15:36:25 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id fu7sm14477168wib.2.2014. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 23 Jul 2014 15:36:24 -0700 (PDT)
Message-ID: <>
Date: Thu, 24 Jul 2014 10:36:31 +1200
From: Brian E Carpenter <>
Organization: University of Auckland
User-Agent: Thunderbird (Windows/20070728)
MIME-Version: 1.0
To: Avri Doria <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
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 22:36:30 -0000

Hi Avri,

On 24/07/2014 09:46, Avri Doria wrote:
> Hi,
> 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.

Indeed, but this is a more precise instantiation of the
exception to the policy exception in the IETF/ICANN MoU
from 2000 - nothing new here in principle or in practice.
It's been exercised a number of times since then, but
quite rarely:

  "Note that (a) assignments of domain names for technical uses (such as
   domain names for inverse DNS lookup), (b) assignments of specialised
   address blocks (such as multicast or anycast blocks), and (c)
   experimental assignments are not considered to be policy issues, and
   shall remain subject to the provisions of this Section 4."

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

Yes it does, because it was explicitly excepted from the agreement. It's
unfortunate if that wasn't well understood when the GNSO Council was created.

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

Except for the exception signed off 14 years ago.

> It seems to me that it is what could be called a cross-accountabilty
> example.
> 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'.

Oh, in the general case I certainly agree that the 3 major
areas should consult with each other when there's an overlap
issue. But I don't quite see how this impacts accountability
as such.

In the instance you mention, was the existence of the draft
and the IETF last call etc. notified in any way to the ICANN TLG
or (maybe indirectly) to the GNSO? If not, that was probably
an omission IMHO, but I still don't see where accountability
comes in.


> And this is but one simple issue.
> avri
> _______________________________________________
> Internetgovtech mailing list