Re: [Ianaplan] Question from the ICG

Eliot Lear <lear@cisco.com> Fri, 25 September 2015 13:03 UTC

Return-Path: <lear@cisco.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 D7A1E1A0196 for <ianaplan@ietfa.amsl.com>; Fri, 25 Sep 2015 06:03:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level:
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 MKgAgEdHMafo for <ianaplan@ietfa.amsl.com>; Fri, 25 Sep 2015 06:03:03 -0700 (PDT)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4B3E1A0195 for <ianaplan@ietf.org>; Fri, 25 Sep 2015 06:03:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=30807; q=dns/txt; s=iport; t=1443186182; x=1444395782; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=2VQoqKouqvANOtKHHVRu4paKMJw9vmT0m/+fAbQjtpI=; b=LcRpyIb3PRlthPz1yhoZXm8Ks+7WptRqBQ6SuZslFC3fRt07oL5kiMTZ HPSdVIldRlYqMDsiWRXY9Hue50KIbtnVyvs7Vpa9bsQCsJW86G6FpTGgp h3XgXCH2RSUM2sd+k6sesGssNG9EF2H4fqMsmkEhn0jT1V+eqK7paShA9 A=;
X-Files: signature.asc : 481
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DlBAAXRQVW/xbLJq1dgleBIWmDKrtkGgELhS1KAoICAQEBAQEBgQuEJQEBBAEBASAKOgcKEQsYCRYBAQkCAgkDAgECARUwBgEMBgIBARCIGg23T5QkAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSLcIUUgmmBQwEElWeCS4FdiGOBT4Q2gn6SJ2OEAzwziWwBAQE
X-IronPort-AV: E=Sophos;i="5.17,587,1437436800"; d="asc'?scan'208,217";a="605358789"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Sep 2015 13:03:00 +0000
Received: from [10.61.216.221] ([10.61.216.221]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t8PD30uP015004; Fri, 25 Sep 2015 13:03:00 GMT
To: Russ Housley <housley@vigilsec.com>, ianaplan@ietf.org
References: <56A1B728-98DF-409A-B2B6-2624F53FE175@cooperw.in> <3A58359B-420B-4FEC-B812-4659D980C5D3@vigilsec.com>
From: Eliot Lear <lear@cisco.com>
Message-ID: <56054602.3000003@cisco.com>
Date: Fri, 25 Sep 2015 15:02:58 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <3A58359B-420B-4FEC-B812-4659D980C5D3@vigilsec.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="659rMeQ2I3mn1wgr3XFDPA6r0MjNCHR02"
Archived-At: <http://mailarchive.ietf.org/arch/msg/ianaplan/yZDP50SaHsKqUg8v2WGYwYbexBU>
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: Fri, 25 Sep 2015 13:03:06 -0000

Hi Russ,

I agree, but I also see a bit of confusion in the question that is being
asked with regard to "operator" and "operational communities".  While
different functions operators may be required in the future, the
policies governing a given IANA function do not change simply because
the operator changes.  Wisdom and operational experience have guided us
toward collaboration across the various communities with regard to these
policies thus far, and will continue to do so in the future.

Eliot


On 9/25/15 12:26 AM, Russ Housley wrote:
> 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
>>
>
>
>
> _______________________________________________
> Ianaplan mailing list
> Ianaplan@ietf.org
> https://www.ietf.org/mailman/listinfo/ianaplan