Re: [Internetgovtech] Cross community

John Curran <jcurran@istaff.org> Wed, 23 July 2014 22:23 UTC

Return-Path: <jcurran@istaff.org>
X-Original-To: internetgovtech@ietfa.amsl.com
Delivered-To: internetgovtech@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C0101ABD19 for <internetgovtech@ietfa.amsl.com>; Wed, 23 Jul 2014 15:23:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id chEUZZoSx-hY for <internetgovtech@ietfa.amsl.com>; Wed, 23 Jul 2014 15:23:57 -0700 (PDT)
Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E4141A040B for <internetgovtech@iab.org>; Wed, 23 Jul 2014 15:23:57 -0700 (PDT)
Received: from pool-108-56-179-253.washdc.fios.verizon.net ([108.56.179.253] helo=[192.168.1.10]) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from <jcurran@istaff.org>) id 1XA4x2-000G2K-KU; Wed, 23 Jul 2014 22:23:56 +0000
X-Mail-Handler: Dyn Standard SMTP by Dyn
X-Originating-IP: 108.56.179.253
X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information)
X-MHO-User: U2FsdGVkX1/E1GAPzBNuyU6rUsuK4+1o
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: John Curran <jcurran@istaff.org>
In-Reply-To: <53D02D53.6070501@acm.org>
Date: Wed, 23 Jul 2014 18:23:54 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <B3719ABF-B9A7-4496-921C-9DEFB3B2EB76@istaff.org>
References: <A193D048-2B67-469A-93BA-C61BB362DA75@vigilsec.com> <53CD1E8A.1060804@acm.org> <FA4238C4-ADDC-435F-9591-E3B074C2F6F6@vigilsec.com> <53CD2300.5050307@acm.org> <20140721143105.GH16966@mx1.yitter.info> <53CD291E.1020801@acm.org> <9045EC0A-E123-4CDC-B87F-5BC32C644C85@istaff.org> <53CD57E8.4000909@acm.org> <B7163126-31B6-4CC6-A711-F225051C294A@istaff.org> <53CD8F41.9060909@gih.com> <53CD939D.5020001@cisco.com> <9DE8F705-9748-407D-8E77-7B787ACD9873@gmail.com> <53CE4B39.1090202@acm.org> <53D016B6.2020000@gih.com> <53D01E6B.8020606@gmail.com> <53D025F3.5050708@acm.org> <53D02828.1030805@gmail.com> <53D02D53.6070501@acm.org>
To: Avri Doria <avri@acm.org>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/JB6Qx2y-TzU0g6AqEoUrtC5n-F8
Cc: internetgovtech@iab.org
Subject: Re: [Internetgovtech] Cross community
X-BeenThere: internetgovtech@iab.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Internet Governance and IETF technical work <internetgovtech.iab.org>
List-Unsubscribe: <https://www.iab.org/mailman/options/internetgovtech>, <mailto:internetgovtech-request@iab.org?subject=unsubscribe>
List-Archive: <http://www.iab.org/mail-archive/web/internetgovtech/>
List-Post: <mailto:internetgovtech@iab.org>
List-Help: <mailto:internetgovtech-request@iab.org?subject=help>
List-Subscribe: <https://www.iab.org/mailman/listinfo/internetgovtech>, <mailto:internetgovtech-request@iab.org?subject=subscribe>
X-List-Received-Date: Wed, 23 Jul 2014 22:23:59 -0000

On Jul 23, 2014, at 5:46 PM, Avri Doria <avri@acm.org> wrote:

> On 23-Jul-14 17:24, Brian E Carpenter wrote:
>> 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.

IANA accountability is about whether the IANA operator performs 
in accordance with the supplied policies...  that is it, i.e.
does IANA perform registry updates as specified by the policy
documents.  It's a fairly straightforward question of contractual
performance (or at least in the case of the RIRs and IAB which
perform their policy development separate from ICANN/IANA)

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

IANA is accountable to the IAB/IETF for technical reservations in
both the IP and DNS spaces (as per the ICANN/IAB/IETF MOU.)  It is 
accountable to the RIRs for adherence to global policy for general 
purpose IP space (per ICANN/NRO MOU) and one presumes that it is 
accountable to ICANN's guidance for following policy for the general 
purpose DNS space (although it is unclear if that's to the ICANN 
DNS policy body or to ICANN's Board)

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

ICANN has the ability to make policy with respect to DNS names, but 
that is still subject to its existing agreements, including the MOU 
between ICANN and the IAB/IETF (RFC 2860)... That MOU is quite clear 
about deference to IETF specifications for technical reservations 
if ICANN wishes to continue serving as the IANA.

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

Not at all - IANA accountability is about operating the registry accordingly 
to the policy authority, whereas you are raising issues about the proper 
policy authority.  The IANA must know the proper policy authority for each
registry it administers, but that is set external to the IANA via agreements
between the parties.

You _never_ want the IANA deciding to insert its own independent judgement
regarding dispute situations; the IANA is a set of interrelated technical 
recording functions, not an oversight or judicial role.

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

Again, IANA accountability is about the IANA adherence to the supplied 
policy; is it doing it promptly and accurately.  You are asking a more 
general issue about IETF and ICANN accountability for policy development 
to their respective communities, and does not appear to be in scope for 
the transition proposal.  Specifically -

"In discussions to date, a number of topics have arisen that are outside the scope of this transition. To avoid any misunderstanding, there are a range issues that, while important, are not appropriately part of a transition proposal requested by NTIA, including:

	• Policy development related to the IANA functions. As NTIA currently plays no unique role in the development of policies for the coordination of the Internet’s domain name system, the proposal is not about how relevant policies are created, nor the relevant structures in which they are created. The roles of all Internet registry policy bodies (such as the RIRs, IAB, IETF, ASO, NRO, ccNSO, ccTLD Registry Operators, and the GNSO) will stay unchanged. These bodies continue to represent their respective communities and hold policy authority for the protocol parameter, number, and name spaces, including responsibility to ensure the faithful registry implementation by ICANN according to those policies."

<https://www.icann.org/en/system/files/files/iana-transition-scoping-08apr14-en.pdf>

i.e. it is perfectly reasonable to specify how "RIRs, IAB, IETF, ASO, NRO, 
ccNSO, ccTLD Registry Operators, and the GNSO" will know that the IANA is 
performing faithful registry administration of the supplied policies, but
asking how those individual bodies are accountable to their communities in
policy development is out of scope.

Thanks!
/John

Disclaimer: My views alone.