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

Eliot Lear <lear@cisco.com> Mon, 03 November 2014 22: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 6AB121A1A60 for <ianaplan@ietfa.amsl.com>; Mon, 3 Nov 2014 14:03:27 -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 Hz5uNjf5VlzO for <ianaplan@ietfa.amsl.com>; Mon, 3 Nov 2014 14:03:25 -0800 (PST)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A15B31A1A15 for <ianaplan@ietf.org>; Mon, 3 Nov 2014 14:03:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5829; q=dns/txt; s=iport; t=1415052205; x=1416261805; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=XicfBAeQIuMGZN3yguHxsW2QsHH8qhtD+X2chgtSOkc=; b=JF3wWn3XL5N6qLr2SGR7Hod3LbY20G0e0KGhWgoOOr1ZwdgSFHPW5aX4 nquryzMdluKnhwsQsAHsPyKlIIdTJIvkdL7Gn1ZGVsxDif1sUUucqKWZQ vLLt4O+XroKilStRwtW7TUZ6KEbd9kecwYgRnAc9ap3qTRmGN6WUovhao I=;
X-Files: signature.asc : 486
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ArcEACz7V1StJssW/2dsb2JhbABcg2JYgwbLE4dVAoE8AQEBAQF9hAMBAQQjVRELDgoJFgQHAgIJAwIBAgFFBgEJAwgBARCILbV3lDgBAQEBAQEEAQEBAQEBARuKdIYjgneBVAEEi3aIOYFSaIcYgTE9hgc7jiCCNIFlHC+CSwEBAQ
X-IronPort-AV: E=Sophos;i="5.07,309,1413244800"; d="asc'?scan'208";a="230272453"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 03 Nov 2014 22:03:21 +0000
Received: from [10.154.176.54] ([10.154.176.54]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id sA3M3KsN023486; Mon, 3 Nov 2014 22:03:21 GMT
Message-ID: <5457FBA7.6050908@cisco.com>
Date: Mon, 03 Nov 2014 14:03:19 -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: Andrew Sullivan <ajs@anvilwalrusden.com>, ianaplan@ietf.org
References: <20141103183007.GP27751@mx1.yitter.info> <GLEAIDJPBJDOLEICCGMNEENBCNAA.rhill@hill-a.ch> <20141103212831.GF28565@mx1.yitter.info>
In-Reply-To: <20141103212831.GF28565@mx1.yitter.info>
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="Elk3tOQXn5s9fgDwWDaNJgRlEBkVbxu6L"
Archived-At: http://mailarchive.ietf.org/arch/msg/ianaplan/TFBVgvbatP-b7XlUC4F8z2KxFXM
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: Mon, 03 Nov 2014 22:03:27 -0000

Hi Andrew,

It seems a good time to review why we are at this point, and what can be
done.

We are seeking what amounts to backward compatibility - that is, things
keep going the way they were, even in the face of an IANA operator
change.  That means, at least to me, that the links that are spread
hither and yon continue to work.

You have stated that you deem it unreasonable to impose post-contract
responsibilities on the current contract holder.  Fair enough.
You and Milton came to what seemed like a reasonable compromise which
was that the next IANA functions operator be transferred the material.
Then Alissa suggested there might need to be more than one, and
therefore, that a mark could not be split three ways.

The fundamental goal is that links continue to work.  I suggest that if
the IETF/IAB or IETF trust takes control of the name, it do so with the
understanding that it take responsibility for seeing that backward
compatibility continue for each customer (names, numbers, protocol
parameters, in particular) for so long as it is safe to do so.  If
someone else wants to take control of the name, they should make that
same promise.

How does that sound to you in principle?

Eliot

On 11/3/14, 1:28 PM, Andrew Sullivan wrote:
> On Mon, Nov 03, 2014 at 09:30:28PM +0100, Richard Hill wrote:
>> Yes.  But we differ on what "staying the same" means.
>>
>> To me, it means that ICANN should not have unfettered control of the mark
>> IANA and the domain name IANA.ORG.
> So, that's the "different" meaning of "same"?  They have control of
> those items now, and they got it as part of the arrangement that
> created the NTIA agreement in the first place.  Stamping our foot
> about moral authority (particularly when it's as dubious as this)
> isn't a strong bargaining position.
>  
>> Exactly.  Trying to negotiate with ICANN if things do fall apart is going to
>> be messy.  Anybody who has gone through a divorce, or has friends who have
>> gone through divorces, should understand what I'm referring to.
> As I've argued repeatedly, in case of separation of the various IANA
> portions from one another, the cases boil down to two: either we have
> a co-operative separation (in which case, there'll be a pointer
> installed immediately to wherever the new registry is), or we have a
> hostile situation (in which case, no amount of agreement in advance
> will help, because everything will be contested and we'll have to act
> much faster than any legal process will permit).  
>
> If people are genuinely worried about this problem, then the right
> thing to do is not to try to get control of "IANA".  As Alissa keeps
> saying, we still can't split a mark three ways.  Therefore, if we are
> really concerned about arranging for that, we should create a separate
> mark and domain name now.  We should start using the new name instead
> of "IANA" in the newly-minted "Protocol Parameter Registry
> Considerations" section.  We should publish another document that
> says, "IANA now renamed NEWREG for protocol parameters", thereby
> telling everyone that they can read "NEWREG" for "IANA" in all old
> documents wherever a parameter is called out.  And we can point the
> "NEWREG" site to the IANA site (probably by judicious use of a DNAME),
> thereby preserving operation exactly as it currently functions. 
>
> Again, I think it is entirely premature and foolish to do that now.
> It would send exactly the wrong message when it is obviously better
> that the various functions stay together and in the incumbent
> operator.  There is effectively zero risk right now that we're going
> to exercise this sort of thing in the short term, so we have lots of
> time to undertake such a strategy in the future should there appear to
> be any chance at all that we might need it.
>
>> Why do you assume that?  As Milton has pointed out, ICANN is bound to
>> implement whatever the consenus is of the global multi-stakeholder
>> community.  
> I think Milton is wrong about that.  What incentive does ICANN have to
> accept a term that it doesn't like if the NTIA says it should do it?
> NTIA has already announced its intention to change things.  If the
> terms of that change are not to ICANN's liking, then ICANN can do one
> of three things: 1. roll over anyway, 2. hold out and see if NTIA
> blinks, 3. open negotiations with NTIA on extension of the existing
> agreement.  It seems to me that (1) is unlikely and (3) is not what we
> want.  (2) is unappealing, so we should avoid creating situations that
> could cause that when there's not a significant upside for us.  
>  
>> Why not keep it simple, and transfer the mark and the domain name IANA.ORG
>> to the IETF Trust?
> I don't believe that's simple at all.
>
> Best regards,
>
> A
>