Re: [Ianaplan] A draft for your review

John Curran <jcurran@istaff.org> Sat, 01 November 2014 03:53 UTC

Return-Path: <jcurran@istaff.org>
X-Original-To: ianaplan@ietfa.amsl.com
Delivered-To: ianaplan@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD6E61A87CB for <ianaplan@ietfa.amsl.com>; Fri, 31 Oct 2014 20:53:00 -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 G0f_oGTndNDx for <ianaplan@ietfa.amsl.com>; Fri, 31 Oct 2014 20:52:58 -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 B26081A87CA for <ianaplan@ietf.org>; Fri, 31 Oct 2014 20:52:58 -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:AES256-SHA:256) (Exim 4.72) (envelope-from <jcurran@istaff.org>) id 1XkPkH-000BQ9-G1; Sat, 01 Nov 2014 03:52:57 +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+Mal/buV52NnmLK3WzubNF
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\))
From: John Curran <jcurran@istaff.org>
In-Reply-To: <7471A339-3938-4D65-81ED-9E27A80EC32B@virtualized.org>
Date: Fri, 31 Oct 2014 23:52:56 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <7AA47255-2AA0-4EA4-9080-421CC8449D3B@istaff.org>
References: <54017E09.8060504@cisco.com> <6.2.5.6.2.20140830052032.0c96c880@resistor.net> <54047E4A.30503@cisco.com> <6.2.5.6.2.20140901094544.0b305698@resistor.net> <54059587.8070608@cisco.com> <6.2.5.6.2.20141024004255.0b5ef5d8@resistor.net> <4C1255B9-68C3-45D5-A618-2C7553386DF4@gmail.com> <54522E43.5020709@acm.org> <545428AC.3090802@gmail.com> <7471A339-3938-4D65-81ED-9E27A80EC32B@virtualized.org>
To: David Conrad <drc@virtualized.org>, Brian E Carpenter <brian.e.carpenter@gmail.com>
X-Mailer: Apple Mail (2.1990.1)
Archived-At: http://mailarchive.ietf.org/arch/msg/ianaplan/454f-lS-qUqpMorJM_p9qSeBgh0
Cc: ianaplan@ietf.org
Subject: Re: [Ianaplan] A draft for your review
X-BeenThere: ianaplan@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IANA Plan <ianaplan.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ianaplan>, <mailto:ianaplan-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ianaplan/>
List-Post: <mailto:ianaplan@ietf.org>
List-Help: <mailto:ianaplan-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ianaplan>, <mailto:ianaplan-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 01 Nov 2014 03:53:01 -0000

On Oct 31, 2014, at 10:15 PM, David Conrad <drc@virtualized.org> wrote:
> 
> My reading of RFC 2860 section 4.3 suggests that the responsibility for the administration of the domain names is explicitly "outside of the scope of this MOU" unless the assignments are for "technical uses" ...

That matches my reading of the MOU as well - ICANN is to provide IANA services 
for all IETF registries per supplied policy, but the assignment of domain names 
and the assignment of IP address pose policy issues which are outside the scope 
of the MOU, unless made for technical/specialized/experimental uses. 

In borderline cases, constructive engagement between the IETF and the particular
delegated policy body (ICANN, RIRs) would be most productive.  I do believe that 
IETF has sufficient flexibility (via experimental/technical uses) to effectively
preempt the delegation and put in entries into these spaces without coordination.  
That's not something likely to be done lightly... i.e. in the end, that which the 
Internet service providers around the globe configure is actually what gets used, 
and our failure to provide effective coordination is a good way to encourage 
exploration of alternative mechanisms.

/John

Disclaimer: my views alone.