[Ianaplan] Comment on draft-ietf-ianaplan-icg-response-02

Russ Housley <housley@vigilsec.com> Mon, 03 November 2014 21:48 UTC

Return-Path: <housley@vigilsec.com>
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 4C0A01A875C for <ianaplan@ietfa.amsl.com>; Mon, 3 Nov 2014 13:48:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.5
X-Spam-Level:
X-Spam-Status: No, score=-100.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, USER_IN_WHITELIST=-100] 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 f4GM-nmw_fGw for <ianaplan@ietfa.amsl.com>; Mon, 3 Nov 2014 13:48:11 -0800 (PST)
Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id CB8A91A1A10 for <ianaplan@ietf.org>; Mon, 3 Nov 2014 13:48:10 -0800 (PST)
Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 4FF6A9A4485 for <ianaplan@ietf.org>; Mon, 3 Nov 2014 16:48:00 -0500 (EST)
X-Virus-Scanned: amavisd-new at smetech.net
Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id TqKFT+ZFSM24 for <ianaplan@ietf.org>; Mon, 3 Nov 2014 16:47:59 -0500 (EST)
Received: from [192.168.10.50] (unknown [64.129.13.2]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 425BB9A447F for <ianaplan@ietf.org>; Mon, 3 Nov 2014 16:47:59 -0500 (EST)
From: Russ Housley <housley@vigilsec.com>
Content-Type: multipart/signed; boundary="Apple-Mail-94-804876553"; protocol="application/pkcs7-signature"; micalg="sha1"
Date: Mon, 03 Nov 2014 16:47:36 -0500
Message-Id: <18A7D037-9E3C-499B-B97A-475B61B70151@vigilsec.com>
To: ianaplan@ietf.org
Mime-Version: 1.0 (Apple Message framework v1085)
X-Mailer: Apple Mail (2.1085)
Archived-At: http://mailarchive.ietf.org/arch/msg/ianaplan/aSO9O2wp86GAqdiBB0H-TofZ4L4
Subject: [Ianaplan] Comment on draft-ietf-ianaplan-icg-response-02
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: Mon, 03 Nov 2014 21:48:15 -0000

The document says:

> In this context, the IETF considers "overlap" to be where there is in some way shared responsibility for a single registry across multiple organizations. In this sense, there is no overlap between organizations because responsibility for each registry is carefully delineated. There are, however, points of interaction between other organizations, and a few cases where we may further define the scope of a registry for technical purposes. This is the case with both names and numbers, as described in the paragraphs below. In all cases, the IETF engages directly with the appropriate organizations to ensure that each organization’s policies are followed.

We should add a paragraph after that one that considers a future where names, numbers, and protocol parameters do not use the sam operator.  I suggest:

"At present, there is a single IANA functions operator maintaining the IANA registries for the names, numbers, and protocol parameters.  Having a single IANA functions operator aids coordination.  However, in the future, delegated registries may be maintained by the responsible organization directly or by a contracted registry maintenance vendor so long as any necessary coordination is maintained."

Russ