Re: [Internetgovtech] Transition to the web

John Curran <jcurran@istaff.org> Tue, 15 July 2014 14:24 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 DFA571A04E7 for <internetgovtech@ietfa.amsl.com>; Tue, 15 Jul 2014 07:24:38 -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 4m-s9RKLesOI for <internetgovtech@ietfa.amsl.com>; Tue, 15 Jul 2014 07:24:37 -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 860C31A03FC for <internetgovtech@iab.org>; Tue, 15 Jul 2014 07:24:37 -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 1X73em-0005sQ-Qc; Tue, 15 Jul 2014 14:24:36 +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: U2FsdGVkX18TK2a1BKinxY382u37T7TE
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: <53C1E977.4050306@meetinghouse.net>
Date: Tue, 15 Jul 2014 10:24:34 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <C2727BEC-6E3A-45E7-A3C2-DD4A6F118ED9@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> <53C1E977.4050306@meetinghouse.net>
To: Miles Fidelman <mfidelman@meetinghouse.net>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/Axts5FoJL16CTbsJhwlvuwo74ZE
Cc: internetgovtech@iab.org
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:24:39 -0000

On Jul 12, 2014, at 10:05 PM, Miles Fidelman <mfidelman@meetinghouse.net> wrote:
> 
> Well, the RFC's specfically exclude domain and address functions, ...

RFC 2860 does not exclude domain and address functions - please read it again 
carefully. 

Section 4.1 says that the IANA will assign and register Internet protocol 
parameters per technical considerations specified by the IETF; section 4.3 
notes that two particular assigned spaces present "policy issues" in addition 
to the technical considerations, and places those "policy issues" outside the 
scope of the MOU.  It goes on further to note that ICANN needs to take care 
not to make conflicts with technical reservations within those same assigned 
spaces. 

Placing "policy issues" outside of the MOU space does not exclude the duty
of the IANA to maintain these registries; it is simply a recognition that 
there are delegations of policy authority for the general purpose portions
of these spaces to other parties (e.g. for IP spaces, it's in RFC 7020 and 
RFC 7249)

Remember, there is only one DNS root zone (registry) and one IPv4 space and 
one IPv6 space... each of these registry spaces consist of both technical/
specialized entries and "general purpose" entries, but in the end each space 
must have single consistent registry published containing all entries.  This
is particularly important when dealing with non-trivial publications protocols
such as DNSSEC.

Thanks,
/John

Disclaimer: My views alone.