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.