Re: [Ianaplan] control and negotiation (was Re: draft-ietf-ianaplan-icg-response-02 working group last call)

Eliot Lear <lear@cisco.com> Thu, 06 November 2014 17:15 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 3EC9D1A8895 for <ianaplan@ietfa.amsl.com>; Thu, 6 Nov 2014 09:15:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.095
X-Spam-Level:
X-Spam-Status: No, score=-15.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001, 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 008oA80d6Is0 for <ianaplan@ietfa.amsl.com>; Thu, 6 Nov 2014 09:15:39 -0800 (PST)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBDF41A888A for <ianaplan@ietf.org>; Thu, 6 Nov 2014 09:15:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3365; q=dns/txt; s=iport; t=1415294138; x=1416503738; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=apDY2qyle4Hll5q2n0mweDvTMwDCpYe36dx6zBObpDE=; b=hc4vCmIgXPBPSSNNMUPO8xvVPNbV+23rr9ippQHgURo5+bgd+ChnlBoX crC+EC+70ljkrzt/qs7MbvqbZfb23/DmrkqtHqJIz3WeHFfBXoLWH2FEw Zv6JqbmFQGiChZbaBGjRcYW5Ok+XvzRPWDPxFMeTi1vKFy2dOHi5ComjJ 0=;
X-Files: signature.asc : 486
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ag4FAHCsW1StJV2U/2dsb2JhbABbgw6EM89tAoEgFgEBAQEBfYQDAQEEI1UBEAsOCgkWBAcCAgkDAgECAUUGDQEHAQGIPblZlUcBAQEBAQEBAQEBAQEBAQEBAQEBARiKdYYcB4J3gVQBBIt9iD2BUogIh3aOY4I0gWUcgnoBAQE
X-IronPort-AV: E=Sophos;i="5.07,327,1413244800"; d="asc'?scan'208";a="369995134"
Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-6.cisco.com with ESMTP; 06 Nov 2014 17:15:36 +0000
Received: from [10.154.176.81] ([10.154.176.81]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id sA6HFaKc018898; Thu, 6 Nov 2014 17:15:36 GMT
Message-ID: <545BACB7.8020701@cisco.com>
Date: Thu, 06 Nov 2014 09:15:35 -0800
From: Eliot Lear <lear@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Miles Fidelman <mfidelman@meetinghouse.net>
References: <GLEAIDJPBJDOLEICCGMNIEOJCNAA.rhill@hill-a.ch> <54594A50.4090305@meetinghouse.net> <20141105001731.GA30186@mx1.yitter.info> <54597BDB.7040305@meetinghouse.net> <5459BA98.1070006@gmail.com> <545A208A.7040304@meetinghouse.net> <631e3e3d29c843bd9c23151c63612989@EX13-MBX-13.ad.syr.edu> <20141105154903.GI30379@mx1.yitter.info> <498a39b81b774192bd2d609b3feab35f@EX13-MBX-13.ad.syr.edu> <20141105234444.GM31320@crankycanuck.ca> <545ABCB0.5080206@meetinghouse.net> <8f3dcda6c3db4cd8be1b77444f987d59@EX13-MBX-13.ad.syr.edu> <D0805C27.136BE7%jon.peterson@neustar.biz> <7F52A930-DD6F-4D0D-8278-A021CF8A466C@istaff.org> <D080D78C.136C6E%jon.peterson@neustar.biz> <D8680FE5-1088-4842-ADB8-EB8E6F6CF681@istaff.org> <545BA463.3090106@cisco.com> <545BAB1A.1020001@meetinghouse.net>
In-Reply-To: <545BAB1A.1020001@meetinghouse.net>
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="Tf1sqtfQECUXRXV1N1apIthvBHKwu2nqR"
Archived-At: http://mailarchive.ietf.org/arch/msg/ianaplan/Nr5FBV2qIj9kOzsItrmXajEOEHc
Cc: "ianaplan@ietf.org" <ianaplan@ietf.org>
Subject: Re: [Ianaplan] control and negotiation (was Re: draft-ietf-ianaplan-icg-response-02 working group last call)
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: Thu, 06 Nov 2014 17:15:40 -0000

Hi Miles,

On 11/6/14, 9:08 AM, Miles Fidelman wrote:
> Eliot Lear wrote:
>> Hi John,
>>
>> On 11/6/14, 8:10 AM, John Curran wrote:
>>> I think it would be great if cooperation in the use of the domain name
>>> and marks (to serve multiple communities) was achieved even absent
>>> NTIA's present IANA stewardship; how do you proposed this should be
>>> achieved?
>> On the whole through shared goals and values which have served us so
>> well in the past.  However, we need to leave open the possibility that
>> something will go wrong for reasons that today we cannot fathom.  One
>> form of sharing is what we have today.  Are there other forms of
>> sharing?  Here I largely agree with Alissa: that is more a matter for
>> the IAOC to explore.  Our requirement is seeing that people get properly
>> directed to the registries that the IETF has told them to go to through
>> our documentation.  Off the top of my head I can think of several
>> structural arrangements to satisfy that requirement.  But I am quite
>> happy IAOC to "take it from here".
>
> And that brings us back to the procedural question that remains
> unanswered:
>
> - Is the final IETF proposal, to the ICG, going to be the document
> generated by this WG, or,
> - Is the WG draft going to be massaged by others (including the IAOC)
> before delivery to the ICG?

Our charter does not require us to conclude explicit agreements.  It
requires us to state our requirements, and then let the IAOC do its job
to meet those requirements.  I think the ICG response needs to indicate
what requirements need to be met, and perhaps even how they have been
met, if that happens in time.

In fact you laid out a perfect path that I had borrowed from in one of
the revisions:

1.  State what is required
2.  Express as a transition need that the requirement be satisfied.

How detailed we get in requirements is always a good question, but as
far as the NTIA is concerned, so long as they can see that the
requirement has indeed been addressed, and they can come back to us to
ask, then that should suffice.  As Jon Peterson and Cullen Jennings have
pointed out, some wiggle room is helpful, and dare I say productive. 
But what we must do here is state what we need, and there needs to be
sufficient clarity so that the IAOC can do its job.  I think that's
where Alissa's text comes in...

Eliot