Re: [Internetgovtech] Transition to the web

Miles Fidelman <mfidelman@meetinghouse.net> Sun, 13 July 2014 02:06 UTC

Return-Path: <mfidelman@meetinghouse.net>
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 E17521B292D for <internetgovtech@ietfa.amsl.com>; Sat, 12 Jul 2014 19:06:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.88
X-Spam-Level:
X-Spam-Status: No, score=-0.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, LOTS_OF_MONEY=0.001, MISSING_HEADERS=1.021, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no
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 aigaYJQC8oWz for <internetgovtech@ietfa.amsl.com>; Sat, 12 Jul 2014 19:06:14 -0700 (PDT)
Received: from server1.neighborhoods.net (server1.neighborhoods.net [207.154.13.48]) by ietfa.amsl.com (Postfix) with ESMTP id E1ABE1B292C for <internetgovtech@iab.org>; Sat, 12 Jul 2014 19:06:13 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by server1.neighborhoods.net (Postfix) with ESMTP id BD611118438 for <internetgovtech@iab.org>; Sat, 12 Jul 2014 22:06:11 -0400 (EDT)
X-Virus-Scanned: by amavisd-new-2.6.2 (20081215) (Debian) at neighborhoods.net
Received: from server1.neighborhoods.net ([127.0.0.1]) by localhost (server1.neighborhoods.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id mBHd-7FwGTxJ for <internetgovtech@iab.org>; Sat, 12 Jul 2014 22:05:50 -0400 (EDT)
Received: from new-host-3.home (pool-173-76-155-14.bstnma.fios.verizon.net [173.76.155.14]) by server1.neighborhoods.net (Postfix) with ESMTPSA id 6B2C911842F for <internetgovtech@iab.org>; Sat, 12 Jul 2014 22:05:47 -0400 (EDT)
Message-ID: <53C1E977.4050306@meetinghouse.net>
Date: Sat, 12 Jul 2014 22:05:43 -0400
From: Miles Fidelman <mfidelman@meetinghouse.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26.1
MIME-Version: 1.0
CC: internetgovtech@iab.org
References: <6.2.5.6.2.20140708142055.0d5fbb78@elandnews.com> <D1AC4482BED7C04DAC43491E9A9DBEC3998608C6@BK-EXCHMBX01.blacknight.local> <20140709161653.GM59034@mx1.yitter.info> <9B506E73B33873103AE5EC52@JcK-HP8200.jck.com> <20140709171401.GB2935@mx1.yitter.info> <53BD843F.1070304@cs.tcd.ie> <53BD84BB.7000002@meetinghouse.net> <53BDA867.7090701@gmail.com> <53BE602F.7020108@firsthand.net> <53BE6384.5030504@cs.tcd.ie> <53BE69D2.9070509@firsthand.net> <6.2.5.6.2.20140711000259.0cc016e8@resistor.net> <53BFD828.3070007@firsthand.net> <53C06E7C.4010903@gmail.com> <CAD_dc6ihUvV8SDkmoc3fGHWoOoR6nFhRz-=tgCjKnuNvRO2JXw@mail.gmail.com> <53C0F1D9.3090400@cisco.com> <53C17B5C.4090600@abenaki.wabanaki.net> <C5750A628D4D973F3C44F6DC@JcK-HP8200.jck.com> <53C1B2C6.40501@meetinghouse.net> <72F8472D-2913-4BEC-9260-6DAC7791BBF8@virtualized.org>
In-Reply-To: <72F8472D-2913-4BEC-9260-6DAC7791BBF8@virtualized.org>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/f4mOUNS-fggS49zG-m5QoKyRur0
Subject: Re: [Internetgovtech] Transition to the web
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: Sun, 13 Jul 2014 02:06:16 -0000

David Conrad wrote:
> Miles,
>
> On Jul 12, 2014, at 3:12 PM, Miles Fidelman <mfidelman@meetinghouse.net> wrote:
>> 1. ALL of ICANN's responsibilities and authority to perform the IANA function currently flow from the DOC-ICANN contract.
>> 2. That includes the responsibilities for protocol numbers and such.
> I think this will be quite surprising (if not amusing) to (e.g.) folks at RIPE-NCC, AfriNIC, LACNIC, and APNIC. I know individuals at ARIN have argued that there is a top-down chain of authority through various US government agreements, but that always struck me more as transparent and silly CYA driven by a lawyer than anything anyone actually believed in.
>
> It may also come as a surprise to many folks within the IETF (paging Brian Carpenter :)), particularly those who wrote RFCs 2860 and 6220.

Well, the RFC's specfically exclude domain and address functions, and 
preclude charging for anything - so that all comes from the DOC contract.

The DOC contract - 
https://www.icann.org/en/system/files/files/contract-01oct12-en.pdf - 
includes things like this under contractor responsibilities:

C.2.4 The Contractor is required to perform the IANA functions, which 
are critical for the
operation of the Internet’s core infrastructure, in a stable and secure 
manner. The IANA functions are administrative and technical in nature 
based on
established policies developed by interested and affected parties, as 
enumerated in Section C.1.3. The Contractor shall treat each of the IANA 
functions with equal priority
and process all request spromptly and efficiently.


C.2.9 Internet Assigned Numbers Authority (IANA) Functions include (1) 
the coordination
of the assignment of technical Internet protocol parameters; (2) the 
administration of certain
responsibilities associated with the Internet DNS root zone management; 
(3) the allocation of
Internet numbering resources; and (4) other services related to the 
management of the ARPA
and INT top level domains (TLDs).

Which I read as saying:
1. We're paying you to perform all the IANA functions.
2. You've got to coordinate with all the other stakeholders.

There's also a clause about:
- you can't charge the USG
- you CAN charge other people - but it has to be approved by the 
contract officer

To the extent that anybody has "chartered" ICANN to play IANA - that 
seems to be where it comes from, as a follow-on to the old SRI-NIC contract.
>
>> 3. IETF's role is defined in the MOU, but seems to be in addition to, and/or enabled by the DOC-ICANN contract.
> I'm unclear why you think there is any relationship between the MoU and the IANA Functions contract.  How exactly does the IANA Functions contract enable the IETF/IAB/ICANN MoU?

See above.
>
>> 4. If/when the contract lapses, any "official" responsibilities and authority end - except for what comes out of the transition process.
> My impression has always been that the authority for the IANA Function operator (and, in fact, pretty much all other parts of Internet's system of unique identifiers) derives from the acceptance of the recipients of those resources to accept the coordination performed by the operator.  For example, in the case of the IP addresses, an RIR serves as a voluntary coordination point that facilitates a multilateral arrangement for the association of IP address blocks with ISPs and others. Without this coordination service, there is no way the system would scale since it would require myriad bilateral agreements along the lines of "We agree that I have 1.0.0.0/8 and you have 2.0.0.0/8". There is no law that ensures this association -- it is purely the voluntary agreement of the parties involved to accept the association that allows it to work.
>
> A more thorough albeit dated (1996!) description of this view can be found in http://ccs.mit.edu/papers/CCSWP197/CCSWP197.html.
>
>> 1. The authority to charge for registry related activities, and use of those funds to pay for some of the other IANA functions, is all dictated by the DOC contract -- and it strike me as perfectly legitimate for DOC to require that the income stream support all of the IANA activities.  In essence the contract is what grants ICANN it's franchise, and DOC can dictate the terms of that franchise.
> Out of curiosity, why do you believe DoC has authority to grant the franchise on management of the Internet's system of unique identifiers?

The contract, and a related document I came across where the DOC 
authorizes ICANN to charge registry fees.
>
> As a reductio ad absurdum thought experiment, assume DoC decided that this whole multistakeholder thing was a mistake and they decided to grant "the franchise" of the IANA Functions to Evil Defense Contractor, Inc., completely ignoring any input from the IETF, IAB, or anyone else. EDC then decides to charge (say) $1000 for every protocol parameter allocation, modification, or deletion. What would stop the IETF/IESG/IAB from deciding to pick their own "IANA" and having that IANA provide protocol parameter allocation, modifications, and deletion services under the terms the IETF/IESG/IAB permits?

Well, that is the $64,000 dollar question underlying all this transition 
stuff, isn't it.
>
> Similarly, as another absurd thought experiment, there are some who argue that the U. S. Government owns all the address space. Suppose the USG decided to take back "their" address space, perhaps to sell it off to pay off the national debt.  Why do you think ISPs of the world would accept this assertion?
>
>
Chaos would ensue.

This collaborative, multi-stakeholder stuff has been an experiment from 
day one - so far a successful one, but there have been blips - some of 
the games the backbone providers tried to pull around the NSFnet 
backbone, Michigan Bell trying to pull their dark fiber tariff - and so 
far, community reaction has righted the ship. Still, we're heading into 
another set of uncharted waters, where one organization is positioned to 
wreak havoc (either directly, or by community reaction to poor 
decisions).  It seems only prudent to pay attention to some of these 
details.

Right now, the DOC contract is a very loose framework that seems to be 
working.  The transition group is charged with figuring out what comes 
next.  Let's try to work out some of the details.  The question of who 
pays for the IETF-related IANA functions seems to be one of those details.

Cheers,

Miles

-- 
In theory, there is no difference between theory and practice.
In practice, there is.   .... Yogi Berra