Re: [Ianaplan] Question from the ICG

Russ Housley <housley@vigilsec.com> Thu, 24 September 2015 22:26 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 D1ECB1B3D57 for <ianaplan@ietfa.amsl.com>; Thu, 24 Sep 2015 15:26:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.899
X-Spam-Level:
X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 ktLhsYReI5pt for <ianaplan@ietfa.amsl.com>; Thu, 24 Sep 2015 15:26:45 -0700 (PDT)
Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id E319C1B2CFA for <ianaplan@ietf.org>; Thu, 24 Sep 2015 15:26:44 -0700 (PDT)
Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 393BEF24171 for <ianaplan@ietf.org>; Thu, 24 Sep 2015 18:26:34 -0400 (EDT)
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 R-Z+9adbR5yg for <ianaplan@ietf.org>; Thu, 24 Sep 2015 18:25:17 -0400 (EDT)
Received: from [172.16.1.99] (173-14-214-10-Atlanta.hfc.comcastbusiness.net [173.14.214.10]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id F1210F2416B for <ianaplan@ietf.org>; Thu, 24 Sep 2015 18:26:12 -0400 (EDT)
From: Russ Housley <housley@vigilsec.com>
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: multipart/alternative; boundary=Apple-Mail-146-969893772
Date: Thu, 24 Sep 2015 18:26:01 -0400
In-Reply-To: <56A1B728-98DF-409A-B2B6-2624F53FE175@cooperw.in>
To: ianaplan@ietf.org
References: <56A1B728-98DF-409A-B2B6-2624F53FE175@cooperw.in>
Message-Id: <3A58359B-420B-4FEC-B812-4659D980C5D3@vigilsec.com>
X-Mailer: Apple Mail (2.1085)
Archived-At: <http://mailarchive.ietf.org/arch/msg/ianaplan/L9NHLJKvztRhrlDHybd8dxhihkM>
Subject: Re: [Ianaplan] Question from the ICG
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: <https://mailarchive.ietf.org/arch/browse/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: Thu, 24 Sep 2015 22:26:48 -0000

I think that we should respond with a very simple confirmation that we plan to continue to coordinate with the other operational communities, but that we do not think that formal processes are necessary to do so.  This is consistent with the comments that were sent by the IAB to the ICG.  See https://www.iab.org/documents/correspondence-reports-documents/2015-2/iab-comments-on-icg-proposal/.

Russ


On Sep 24, 2015, at 6:02 PM, Alissa Cooper wrote:

> Dear IANAPLAN WG,
> 
> Based on comments received during the ICG’s public comment period, the ICG has a question for the protocol parameters community. We are requesting a response to this question ideally by 7 October at 23:59 UTC (prior to the ICG’s final call before ICANN 54 on October 8), or by 14 October at 23:59 UTC if the protocol parameters community requires more time. We realize this is an aggressive timetable, so please keep us informed if you feel you need further time.
> 
> The ICG would like to state explicitly that we do not expect a further ICG public comment period to be necessary on the combined proposal in response to the answers that the protocol parameters community may provide. While the ICG reserves the right to seek further public comment if we receive extensive amendments from any of the operational communities, we do not expect to do so at this time.
> 
> The three operational communities have a long history of cooperation as needed to help ensure the smooth functioning of the DNS and the Internet. A number of comments were concerned that the three IANA functions could end up being carried out by different operators and suggested that there was a need for some information exchange and coordination between the operational communities to ensure a proper understanding of the impact a change might have on the operation of the other functions (perhaps because of interdependencies between the functions or because of shared resources or key staff). This information exchange might also help in coordinating action in the case of remedying operational difficulties. For this to work, the three operational communities need to commit to coordinating and cooperating as necessary when changing operator, whether by leveraging existing coordination mechanisms or new ones. Can the protocol parameters operational community provide such a commitment? If so, the ICG intends to reflect that and the commitments of the other communities in Part 0 of the transition proposal.
> 
> Please let us know if the question requires clarification.
> 
> Thanks,
> 
> Alissa Cooper on behalf of the ICG
>