Re: [Ianaplan] CWG draft and its impact on the IETF

Eliot Lear <lear@cisco.com> Wed, 13 May 2015 05:58 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 C21BF1AC3EA for <ianaplan@ietfa.amsl.com>; Tue, 12 May 2015 22:58:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -13.11
X-Spam-Level:
X-Spam-Status: No, score=-13.11 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 u9noIbdO8yqx for <ianaplan@ietfa.amsl.com>; Tue, 12 May 2015 22:58:04 -0700 (PDT)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A32061AC3F1 for <ianaplan@ietf.org>; Tue, 12 May 2015 22:58:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22020; q=dns/txt; s=iport; t=1431496683; x=1432706283; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=KUqw8mBwflbHNlzH7JUT4eI3kAbpkR0+QUpj558eDMo=; b=XXM83Va5AIdb3yRBDXa9E1v8Wh3inQE4Rzl0H4wfuBzdNigUpRUIFE1R YCQLDlit+6y+AyVvuvt2GPQIYi+2WY4YjBbRTC5RKdPE04pVan3sqVTKg /K1yy4VgIMMUBO+gEOPfa8HaP5BgTEFlT5WqnSmRrM0HuYAND5HfQbLUo A=;
X-Files: signature.asc : 481
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0D9AwCR51JV/xbLJq1cDoI3gR5egx7CCQmHXQKBbRQBAQEBAQEBgQqEIAEBAQMBIwpFBgYLCQIVAwkWCAMCAgkDAgECATQRBgEJAwYCAQEQiBAImGCdB5I3AQEBAQEBAQECAQEBAQEBAQEBAQEXizmENlUBgmiBRQEEhxqNRIE/hySBJYY+izyDVyNhgQUjHIEUQDwxgkYBAQE
X-IronPort-AV: E=Sophos;i="5.13,419,1427760000"; d="asc'?scan'208,217";a="494003490"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 13 May 2015 05:58:00 +0000
Received: from [10.61.211.148] ([10.61.211.148]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t4D5vx1U009724; Wed, 13 May 2015 05:57:59 GMT
Message-ID: <5552E7E6.4020903@cisco.com>
Date: Wed, 13 May 2015 07:57:58 +0200
From: Eliot Lear <lear@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Milton L Mueller <mueller@syr.edu>, "ianaplan@ietf.org" <ianaplan@ietf.org>
References: <5550F809.80200@cisco.com> <a7cee9a6045a4f65966aa33ba02a854d@EX13-MBX-13.ad.syr.edu>
In-Reply-To: <a7cee9a6045a4f65966aa33ba02a854d@EX13-MBX-13.ad.syr.edu>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="SjqRRuVXTMIcF5Kn83Su5EKEMGMhgxcd6"
Archived-At: <http://mailarchive.ietf.org/arch/msg/ianaplan/LTmLl0I7ADzRU1I7gjtIRPjB_Ag>
Subject: Re: [Ianaplan] CWG draft and its impact on the IETF
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: Wed, 13 May 2015 05:58:08 -0000

Hi Milton (and everyone),

I apologize for the delay in responding.

On 5/12/15 8:32 AM, Milton L Mueller wrote:
>
>  
>
>  
>
> *From:*Ianaplan [mailto:ianaplan-bounces@ietf.org] *On Behalf Of
> *Eliot Lear
>
> In a sense, the proposal is vaguely reminiscent of our own
> arrangements.  In particular it seems that the names community also
> wants to a customer relationship with the IANA Functions Operator
> (IFO) and to have the choice to change providers, should that ever
> become necessary. 
>
>  
>
> MM: That is correct. I hope this community understands the importance
> of doing that.
>
>  
>
> First, if all functions are meant to be transferred to the PTI, it
> seems that the IAB would have to agree to an assignment, per the terms
> of RFC-2860.[2]  Second, since for the first time the naming community
> would have a choice in whether they wish to change IFO, we have to ask
> the question, “What if they did?”  What would happen to the PTI? 
> What, in particular, are the funding implications?  It has always been
> possible for ICANN or the IAB to terminate the arrangement.  If that
> happened, however, the IAB and IAOC would have to work with ISOC to
> determine a funding source for a new IFO for protocol parameters. 
>
>  
>
> MM: If I understand your comment, you are assuming that if the naming
> community abandons PTI for another IFO, then the IETF would too.
>

Quite the opposite.  What would happen if the naming community chose to
separate from the PTI, but the IETF *didn't* want to?  What is the
incentive for the parent organization to continue to fund the PTI?  That
is a new risk for this community.

> This is not necessarily true. IETF could continue to rely on PTI for
> its own IANA functions even if it did not provide the naming functions
> if it wanted to. If that were the case, the total budget for PTI would
> probably to change, but it is not necessarily true that the ICANN
> affiliate would crease to want to perform the protocol functions as
> before. However, if PTI were performing badly enough that the names
> community wanted to leave it, then presumably the protocols people
> might have concerns, too. But if they did, they would still have to
> face the funding issues.
>
>
> It's worth noting that NRO Executive Council has stated that they wish
> to retain a direct relationship with ICANN, and NOT the PTI[4].  The
> IAB could do the same, but then it seems to me that the value of the
> PTI itself is diminished.  And so that
>
>  
>
> MM: This was a mistake, in my opinion, but it was motivated by
> uncertainty as to the status of PTI. I would view it as a short-term
> arrangement that, as PTI matured, would change to a direct relationship.
>

I think that's possible here as well, but it will depend on this
community's belief that the *long term *stability of the function can be
maintained, particularly in the case where one of the other functions
(like names) wants to go their own way.

> But even if it did not, it does not alter the great value of finally
> creating a clear separation between the names policy arrangements and
> the IANA functions. If NRO is short-sighted enough to want to remain
> in a direct relationship with ICANN, even after its recent treatment
> by ICANN legal, I suppose that is it’s right, but we shouldn’t allow
> it to undermine reform in the naming area.
>
>  
>

Sure, so long as it doesn't destabilize long term stability of the other
functions.

> Having the burden of funding shift to another source can itself be a
> source of instability.
>
>  
>
> MM: If you don’t choose to move IANA away from ICANN there is no need
> for a “funding shift.”
>
> If you did choose to do so under RFC 2860 then there would be, and
> this would be true REGARDLESS of whether there was a PTI or not. So
> the logic of this comment escapes me.
>

It's all about choice.  The naming community will have new choices. 
That's good for them.  But it requires this community to ask the
question, “what happens to us if they avail themselves of that choice?” 
That was my comment.

>   * Under this new arrangement, does it make sense to continue the
>     relationship with ICANN as it stood before or does it make sense
>     to go directly to PTI?
>
> MM: You should embrace the new arrangement and go directly to PTI. But
> I am sure ICANN will love it if you do not, as you will reinforce
> their sense that the IANA functions are something they own and should
> be considered a presumptive monopoly of theirs. And long term, that
> will not be a positive thing for any of the operational communities,
> if you consider the bargaining power
>

You wrote elsewhere that the PTI was a compromise.  I see that John has
responded.  I would simply add that not all of this needs to happen at
once, but that for it to happen in the future, the structure should be
such that there is an incentive for this community to make the change. 
The only incentive to me that matters is the long term stability of the
function.

Eliot