Re: [Internetgovtech] Transition to the web

Brian E Carpenter <brian.e.carpenter@gmail.com> Sun, 13 July 2014 01:14 UTC

Return-Path: <brian.e.carpenter@gmail.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 2173F1B291A for <internetgovtech@ietfa.amsl.com>; Sat, 12 Jul 2014 18:14:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q5T1M9uBWsEA for <internetgovtech@ietfa.amsl.com>; Sat, 12 Jul 2014 18:14:26 -0700 (PDT)
Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4212E1B2916 for <internetgovtech@iab.org>; Sat, 12 Jul 2014 18:14:26 -0700 (PDT)
Received: by mail-pa0-f41.google.com with SMTP id fb1so3395798pad.14 for <internetgovtech@iab.org>; Sat, 12 Jul 2014 18:14:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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=Z1vPPiOlQM2UvZM+WgBFW7aAUE9zDeuzIa6pI2hLe9g=; b=fzD/VfKeHajqyTKCpN6SjWDrlq8ZU2nkiXKoQWjzuuzuPTRvwRhqSNKm8rUQpTJ8RL 1Nm59q7t/WcTYVazFPSLJvpXbfCI42BYgW68h3/yJJH6JEAoNQRpLrS9w6ANZ+TSiBG1 Xc71gjpRm1q1gbiBjzcb+5tGcmJi3URjglFY8sDicFFTEoTY+aw2ACbiZJGJ3H86rOkX imG21kNY/EjEir8WsqSKwXuA+OvmYYM3c65aYRNfwLoFrVFpi65kSqlOTAO/3bJc6Hov 4w5NgBbfZUT3lAidRFTiCgsXzAiRsPx5B4wZAIzRur4RCb9gMLtQsyhe2aGVHbQM1r/n ytyQ==
X-Received: by 10.67.23.227 with SMTP id id3mr7814156pad.45.1405214064584; Sat, 12 Jul 2014 18:14:24 -0700 (PDT)
Received: from [192.168.178.23] (139.198.69.111.dynamic.snap.net.nz. [111.69.198.139]) by mx.google.com with ESMTPSA id xx6sm26949402pab.34.2014.07.12.18.14.22 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 12 Jul 2014 18:14:23 -0700 (PDT)
Message-ID: <53C1DD6C.8030501@gmail.com>
Date: Sun, 13 Jul 2014 13:14:20 +1200
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: David Conrad <drc@virtualized.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"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/ksCoyHYZRGYeypvtWUSShe2A6yE
Cc: internetgovtech@iab.org, Miles Fidelman <mfidelman@meetinghouse.net>
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 01:14:30 -0000

On 13/07/2014 11:05, 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, it's a very legalistic view in an area where there is actually
no law (I mean international law) and no need for law, since things
work perfectly well without it.

<ianal>In fact, the IETF/ICANN MoU is a signed and ratified document,
and I have been told in other contexts that such a document is exactly the
same thing as a contract if it ends up in court. Certainly the attention
paid to its wording by lawyers on both sides in 1999/2000 was exactly
what I have experienced in contract negotiations. Of course, if a court
had to decide between conflicting provisions of an NTIA/ICANN contract
and the IETF/ICANN MoU, one might trump the other. However, I think that
a lot of the ICANN lawyer's amendments to the MoU draft were intended
to avoid conflicting provisions. </ianal>

As far as I can see, the only problem that actually needs a solution
right now is: who is the watchdog with adequate teeth to ensure that if
ICANN takes bad decisions about TLD policy, they can be set back on
the right track?

Everything else is in the "not broken, don't fix" category as far
as I am concerned. The RIRs and the IETF have ways to deal with
bad decisions by ICANN in their own areas of concern.

Apart from that, +1 to David's comments.

  Brian

>> 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?
> 
>> 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?
> 
> 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?
> 
> Regards,
> -drc
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Internetgovtech mailing list
> Internetgovtech@iab.org
> https://www.iab.org/mailman/listinfo/internetgovtech