Re: [Internetgovtech] Transition to the web

Miles Fidelman <mfidelman@meetinghouse.net> Sun, 13 July 2014 02:13 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 875E21B2937 for <internetgovtech@ietfa.amsl.com>; Sat, 12 Jul 2014 19:13:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.881
X-Spam-Level:
X-Spam-Status: No, score=-0.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 FQVNCg2JzRfZ for <internetgovtech@ietfa.amsl.com>; Sat, 12 Jul 2014 19:13:26 -0700 (PDT)
Received: from server1.neighborhoods.net (server1.neighborhoods.net [207.154.13.48]) by ietfa.amsl.com (Postfix) with ESMTP id 42ACA1B2934 for <internetgovtech@iab.org>; Sat, 12 Jul 2014 19:13:26 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by server1.neighborhoods.net (Postfix) with ESMTP id 26D1D138001 for <internetgovtech@iab.org>; Sat, 12 Jul 2014 22:13:24 -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 Hl99yJMmyxQV for <internetgovtech@iab.org>; Sat, 12 Jul 2014 22:12:56 -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 2A39611842F for <internetgovtech@iab.org>; Sat, 12 Jul 2014 22:12:53 -0400 (EDT)
Message-ID: <53C1EB22.9070907@meetinghouse.net>
Date: Sat, 12 Jul 2014 22:12:50 -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> <53C1DD6C.8030501@gmail.com>
In-Reply-To: <53C1DD6C.8030501@gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/7fh10LZ6VotHwqM5fUGE6fT2LZs
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:13:27 -0000

Brian E Carpenter wrote:
> 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.

Arguably, things work because there's just enough law and contracts.  
Isn't the big concern all around "what happens when the very loose leash 
of the DOC contract expires?"  It could be everything just continues to 
work, or chaos could ensue.  The whole point of this multistakeholder 
discussion and transition process is to avoid chaos.
>
> <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>

Yes, it's a contract - but it exists in the context of the DOC contract 
that says:

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, among other things is the framework under which ICANN charges for 
some IANA functions, and uses those funds to support the rest of the 
functions.

Which funding is the issue that started this particular branch of 
discussion - who pays after the contract expires.

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

That, and funding for the non-domain related functions!
>
> 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.

As much as I'm in agreement with "if it ain't broke, don't fix it" - 
there is this looming change and a transition process underway. Seems 
only prudent to take steps to avoid breakage resulting from too little, 
or too much change and transition.

Cheers,

Miles

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