Re: [Ianaplan] what *is* a succession plan?

"Richard Hill" <rhill@hill-a.ch> Sun, 14 September 2014 14:44 UTC

Return-Path: <rhill@hill-a.ch>
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 C22931A03D9 for <ianaplan@ietfa.amsl.com>; Sun, 14 Sep 2014 07:44:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] 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 4RuvXwgbiuko for <ianaplan@ietfa.amsl.com>; Sun, 14 Sep 2014 07:44:11 -0700 (PDT)
Received: from smtp3.infomaniak.ch (smtp3.infomaniak.ch [IPv6:2001:1600:2:5:92b1:1cff:fe01:147]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A23B1A03D8 for <ianaplan@ietf.org>; Sun, 14 Sep 2014 07:44:11 -0700 (PDT)
Received: from Laurie (adsl-178-38-125-152.adslplus.ch [178.38.125.152]) (authenticated bits=0) by smtp3.infomaniak.ch (8.14.5/8.14.5) with ESMTP id s8EEi65X007347; Sun, 14 Sep 2014 16:44:06 +0200
From: Richard Hill <rhill@hill-a.ch>
To: John Curran <jcurran@istaff.org>, Eliot Lear <lear@cisco.com>
Date: Sun, 14 Sep 2014 16:43:55 +0200
Message-ID: <GLEAIDJPBJDOLEICCGMNOEODCKAA.rhill@hill-a.ch>
MIME-Version: 1.0
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <6FACFE24-BE91-411F-AB89-B800626BF6D9@istaff.org>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157
Archived-At: http://mailarchive.ietf.org/arch/msg/ianaplan/Pets3o0s9mAv-VNPIApgA-eJ39s
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
Reply-To: rhill@hill-a.ch
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:44:12 -0000

Dear John,

Thank you for pointing us to the draft IAB document "A Framework for
Describing the Internet Assigned Numbers Authority(IANA)".  I found this
paper to be very clear and very helpful.

But, in section 5.4 "Oversight Examples", I think that it should mention the
NTIA IANA functions contract which, at present is, in my view, very
signficant.

Indeed, as stated before, it seems to me (and others) that the present
discussion is about what, if anything, has to be done to replace the IANA
functions contract.

Best,
Richard

> -----Original Message-----
> From: Ianaplan [mailto:ianaplan-bounces@ietf.org]On Behalf Of John
> Curran
> Sent: dimanche, 14. septembre 2014 16:34
> To: Eliot Lear
> Cc: ianaplan@ietf.org
> Subject: Re: [Ianaplan] what *is* a succession plan?
>
>
> 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.
>
>
>
>
> _______________________________________________
> Ianaplan mailing list
> Ianaplan@ietf.org
> https://www.ietf.org/mailman/listinfo/ianaplan
>
>