Re: [Internetgovtech] Transition to the web

John Curran <jcurran@istaff.org> Tue, 15 July 2014 14:02 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 0171C1B28B5 for <internetgovtech@ietfa.amsl.com>; Tue, 15 Jul 2014 07:02:50 -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 EvMl_iQXH4ZR for <internetgovtech@ietfa.amsl.com>; Tue, 15 Jul 2014 07:02:41 -0700 (PDT)
Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 728571B2883 for <internetgovtech@iab.org>; Tue, 15 Jul 2014 07:02:41 -0700 (PDT)
Received: from pool-108-56-179-253.washdc.fios.verizon.net ([108.56.179.253] helo=[192.168.1.7]) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from <jcurran@istaff.org>) id 1X73JY-000FnE-8C; Tue, 15 Jul 2014 14:02:40 +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+2QJqaSgBNAvoHwdJqoalQ
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: John Curran <jcurran@istaff.org>
In-Reply-To: <53C1DD6C.8030501@gmail.com>
Date: Tue, 15 Jul 2014 10:02:36 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <EC465F37-403A-4188-A9E9-705E0D6E62B3@istaff.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>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/pXdfEOKghMp-k_dGoYMDuFMYZgI
Cc: internetgovtech@iab.org, David Conrad <drc@virtualized.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: Tue, 15 Jul 2014 14:02:50 -0000

On Jul 12, 2014, at 9:14 PM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
> ...
> <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>

Also, in a model absent NTIA contract, there would be nothing to conflict...

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

Hmm... "bad decisions about TLD policy" can be a very subjective topic.

It might be worth thinking about two distinct situations:

 - Situations where the contracted IANA party fails to follow the published
   guidance provided by the IETF (or a delegated authority) in administration
   of a given registry.  Some of this appears to be already well-addressed   
   in section 4.1/4.2 of RFC 2860 (and why public registry visibility, 
   reporting and SLA's are all quite useful...)

 - Situations where a delegated policy authority for a registry (e.g. one 
   of the general purpose subsets of the DNS root or IP spaces) should 
   chronically fail to represent the affected registry user community via 
   policy development done in an open, inclusive and transparent manner... 
   (i.e. in accordance with sections 3 & 4 of the IANA framework doc 
   <http://tools.ietf.org/html/draft-iab-iana-framework-02>)  Ideally,
   one would make the accountability to be very clearly stated to be
   performance against specific principles, and periodic assessment of 
   same, since anything else risks creating a mechanism which could be 
   inundated with individual appeals of policy development decisions, 
   rather than the actual question of whether the delegated policy 
   development body is following the IETF's expected IANA principles.

/John

Disclaimer: My views alone. This email message is provided "as-is", with no 
warranty expressed or implied.  Please use your own judgement when building 
global Internet coordination systems.