Re: [Ianaplan] what *is* a succession plan?
John Curran <jcurran@istaff.org> Sun, 14 September 2014 14:33 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 E14D01A03B5 for <ianaplan@ietfa.amsl.com>; Sun, 14 Sep 2014 07:33:59 -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 aY0pyt612Orj for <ianaplan@ietfa.amsl.com>; Sun, 14 Sep 2014 07:33:57 -0700 (PDT)
Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A62A01A03D4 for <ianaplan@ietf.org>; Sun, 14 Sep 2014 07:33:57 -0700 (PDT)
Received: from pool-108-56-179-253.washdc.fios.verizon.net ([108.56.179.253] helo=[192.168.1.6]) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from <jcurran@istaff.org>) id 1XTAsG-000AvD-NX; Sun, 14 Sep 2014 14:33:56 +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: U2FsdGVkX18jzMI2SjoG7QzfpN8+FTL+
From: John Curran <jcurran@istaff.org>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
Date: Sun, 14 Sep 2014 10:33:55 -0400
Message-Id: <6FACFE24-BE91-411F-AB89-B800626BF6D9@istaff.org>
To: Eliot Lear <lear@cisco.com>
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/ianaplan/_ITkbWf1AzoN6GuvaUd6ZlFK3M4
Cc: ianaplan@ietf.org
Subject: Re: [Ianaplan] what *is* a succession plan?
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: Sun, 14 Sep 2014 14:34:01 -0000
From Eliot at Sun, 14 Sep 2014 14:39:41 +0200 > All of this having been written, on this one point: > No single entity, not ICANN, not NTIA, not the IAB, _NO_ one, has the ability to define the “authority to continue performing that function”. > ... Eliot - For protocol parameters which are not assigned to "real world" entities (i.e. the vast majority of the thousand or so IANA registries) it is fairly clear that the IETF/IAB does indeed have the sole authority to define these registries, establish the technical registry policy for their administration, and ability to arrange/contract for an IANA operator for their administration... (if this is not the case, the RFCs 5226 and 6220 should be updated asap to reflect what other entities are claimed to be involved.) There are a few registries which are instead "general-purpose" in nature (in which the identifiers are assigned to real-world entities for purposes of unique labeling, rather than representing technical features/codepoints), and these general-purpose registries pose what has been called "policy issues" in past documents. I would assert that the IETF/IAB, as the entity that defines these registries via the protocol specification, does indeed have the authority to set the registry policy and the registry administrator, but instead has shown great wisdom in recognizing that the establishment any registry is meaningless unless the affected user community supports its use. To this end, the IETF has not directly administered these general-purpose registries (DNS root zone, IP address spaces), but has instead opted to work with organizations that are recognized as representing the affected communities. It is the combination of the IETF (which brings the registry definition and technical IANA considerations) and the affected user community's support of general-purpose registry policy (developed via an open, transparent, and inclusive organization) that results a useful and "authoritative" registry; i.e. this is effectively a restatement of the "No single entity" point above, but _only_ with respect to these general-purpose registries... On a related point, it would probably be a good idea if the IETF had clear criteria for the recognition of delegated registries (general purpose or otherwise); I do think that <https://tools.ietf.org/html/draft-iab-iana-framework-02> is a good start to this end. FYI, /John Disclaimer: my views alone.
- Re: [Ianaplan] what *is* a succession plan? John Curran
- Re: [Ianaplan] what *is* a succession plan? Richard Hill
- Re: [Ianaplan] what *is* a succession plan? Eliot Lear
- Re: [Ianaplan] what *is* a succession plan? David Conrad
- Re: [Ianaplan] what *is* a succession plan? S Moonesamy
- Re: [Ianaplan] what *is* a succession plan? Miles Fidelman
- Re: [Ianaplan] what *is* a succession plan? John Curran