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

Jari Arkko <jari.arkko@piuha.net> Thu, 21 May 2015 14:00 UTC

Return-Path: <jari.arkko@piuha.net>
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 3EDBC1A0163 for <ianaplan@ietfa.amsl.com>; Thu, 21 May 2015 07:00:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.79
X-Spam-Level:
X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[BAYES_50=0.8, T_RP_MATCHES_RCVD=-0.01] 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 kMWtONiy4sdN for <ianaplan@ietfa.amsl.com>; Thu, 21 May 2015 07:00:08 -0700 (PDT)
Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id B55BB1A026E for <ianaplan@ietf.org>; Thu, 21 May 2015 07:00:07 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 0F6E92CC6F; Thu, 21 May 2015 17:00:07 +0300 (EEST) (envelope-from jari.arkko@piuha.net)
X-Virus-Scanned: amavisd-new at piuha.net
Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SUJGYkiqvxUP; Thu, 21 May 2015 17:00:06 +0300 (EEST)
Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 664AC2CC5A; Thu, 21 May 2015 17:00:06 +0300 (EEST) (envelope-from jari.arkko@piuha.net)
Content-Type: multipart/signed; boundary="Apple-Mail=_135FC640-748C-4D9E-AB14-F108FFCC24C6"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Jari Arkko <jari.arkko@piuha.net>
In-Reply-To: <A78B554A-48C1-44FC-96B8-792EAB5C5DEB@cooperw.in>
Date: Thu, 21 May 2015 17:00:04 +0300
Message-Id: <09266390-5379-45BC-AEA3-DF3CE7F47649@piuha.net>
References: <5550F809.80200@cisco.com> <A78B554A-48C1-44FC-96B8-792EAB5C5DEB@cooperw.in>
To: Alissa Cooper <alissa@cooperw.in>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/ianaplan/hgULEb4HAHb-NNN3r-7yvh-2Xf8>
Cc: "ianaplan@ietf.org" <ianaplan@ietf.org>, Eliot Lear <lear@cisco.com>
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: Thu, 21 May 2015 14:00:13 -0000

> Having followed the CWG process to some extent, I appreciate that the PTI proposal is the same sort of compromise that we arrive at now and again in the IETF -- one that leaves the interested parties all mildly dissatisfied. If the names community did not represent such a diversity of interests, I’m sure a cleaner proposal that more readily achieves various goals that people have for the naming functions and their accountability could have obtained consensus. But the reality is that the names community is diverse and that compromises are messy by their nature. I think it would be a more productive use of this list’s time to focus on the question of the implications of the CWG proposal for the IETF rather than re-litigate the debates that have already occurred within the CWG about all the aspects of the current proposal that may seem less than ideal depending on where one sits. This is particularly true for the “why not take names policy out of ICANN instead of taking IANA out” line of argument. The last 7 months of CWG discussions have me quite convinced that the current CWG proposal has a much better shot at obtaining broad consensus than either taking names policy out of ICANN or leaving both names policy and IANA as-is inside of ICANN. 
> 
> My personal view is that if the PTI is established, it would be preferable to keep the protocol parameters personnel, resources, and MOU at ICANN. Simply put, the current protocol parameters system works well. If it ain’t broke, don’t fix it.
> 
> I haven’t seen particularly strong arguments for why the protocol parameters personnel, resources, or MOU would need to move to the PTI if the PTI gets established for names. However, if a compelling argument were to be made, I don’t see major hurdles in moving the personnel or resources to the PTI. In other words, I don’t understand why it is proposed to move those things to the PTI, and I think moving them makes less sense than leaving them at ICANN proper, but I think the protocol parameters registries could probably continue to work just fine if the resources and personnel were moved based on some good argument for doing so.
> 
> I don’t see any advantages in moving the MOU even if the personnel and resources move. Since the PTI is proposed as a wholly owned subsidiary of ICANN, we can maintain our agreement with ICANN and they can subcontract the work out to their subsidiary if necessary. Again, no need to make extra changes to things that are working.
> 
> I think it’s valid to want to understand the budget for providing the protocol parameters registry services, but that is the case regardless of whether the PTI gets established or not. If the point is for the IETF to understand how much ICANN spends providing the services, that inquiry was as valid 15 years ago when the MOU was signed as it is now or after the transition. I’m not sure it tells us very much about how much we should be willing to pay a different operator in the future, but in any event I don’t think it helps to mix that inquiry with responses to the CWG proposal.
> 
> I don’t think it makes sense for the IETF to have a seat on the PTI board. The IAB can continue to exercise its oversight over the registry operator’s performance of the protocol parameters function, so the addition of the board seat is not necessary. The CWG also proposes that the performance of IANA be periodically reviewed post-transition and that the protocol parameter community be offered the opportunity to appoint liaisons to the team performing reviews. Considering that we already have our own performance review process, I don’t think this liaison is necessary either. In short, even if the protocol parameters resources and personnel were to move to the PTI, I think we should stick with our existing oversight and performance review processes, which work well.

I just wanted to say that I agree with Alissa on all of the above. Thanks.

Jari