Re: [Internetgovtech] Transition to the web

Eric Burger <eburger@standardstrack.com> Sun, 13 July 2014 12:04 UTC

Return-Path: <eburger@standardstrack.com>
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 05A111B2B5F for <internetgovtech@ietfa.amsl.com>; Sun, 13 Jul 2014 05:04:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.122
X-Spam-Level:
X-Spam-Status: No, score=-1.122 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779] 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 B_j7DieGooWR for <internetgovtech@ietfa.amsl.com>; Sun, 13 Jul 2014 05:04:48 -0700 (PDT)
Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 092661B2B55 for <internetgovtech@iab.org>; Sun, 13 Jul 2014 05:04:48 -0700 (PDT)
Received: from ip68-100-74-115.dc.dc.cox.net ([68.100.74.115]:59905 helo=[192.168.15.115]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from <eburger@standardstrack.com>) id 1X6IVt-0008CS-Bg for internetgovtech@iab.org; Sun, 13 Jul 2014 05:04:46 -0700
From: Eric Burger <eburger@standardstrack.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_B2FFA107-A862-4A12-8C24-5E2E1D107AAF"; protocol="application/pgp-signature"; micalg="pgp-sha1"
Message-Id: <CC30D388-07FF-40F8-81FB-ED8020DDDCD1@standardstrack.com>
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Date: Sun, 13 Jul 2014 08:04:17 -0400
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> <6F94B6B7-1C04-47BF-B04A-DF8C69E5D5C5@cs.georgetown.edu>
To: internetgovtech@iab.org
In-Reply-To: <6F94B6B7-1C04-47BF-B04A-DF8C69E5D5C5@cs.georgetown.edu>
X-Mailer: Apple Mail (2.1878.6)
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com
X-AntiAbuse: Original Domain - iab.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - standardstrack.com
X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed
X-Source:
X-Source-Args:
X-Source-Dir:
Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/47eLvKEpqN4LCZKG7Wi3Z6hFZrk
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 12:04:49 -0000

This is not just David's perception - these are the facts on the ground.

The IANA works because everyone ‘happens’ to use it. There are no contracts mandating it, no treaties mandating it, no laws mandating it. Tomorrow, someone could say, “I’m the new IANA function, use me!” In fact, that has happened: c.f. Name.Space, OpenNIC, New.net, etc. And… no one cared and for the most part, everyone uses the ICANN IANA directories.

If anything, those facts on the ground means we need to be MORE careful about how we proceed than sanguine. One can envision an organization imposing a treaty regime requiring the use of a particular IANA protocol parameters function, IP address function, and domain name function. That would most likely not be in the IETF’s interest.

On Jul 12, 2014, at 7:05 PM, David Conrad <drc@virtualized.org> wrote:

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