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

Brian E Carpenter <brian.e.carpenter@gmail.com> Fri, 15 May 2015 01:05 UTC

Return-Path: <brian.e.carpenter@gmail.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 837CA1B2E8A for <ianaplan@ietfa.amsl.com>; Thu, 14 May 2015 18:05:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, LOTS_OF_MONEY=0.001, SPF_PASS=-0.001] 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 1KMq5-CSqgsG for <ianaplan@ietfa.amsl.com>; Thu, 14 May 2015 18:05:07 -0700 (PDT)
Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28DB71B2E80 for <ianaplan@ietf.org>; Thu, 14 May 2015 18:05:07 -0700 (PDT)
Received: by pabtu10 with SMTP id tu10so2958890pab.0 for <ianaplan@ietf.org>; Thu, 14 May 2015 18:05:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=8/OoLwf8sK31l1iXCUq9+PJy60oqJOchAIbuQ2FOBmQ=; b=mpufz8jnrWOPKhzxv48p95AS6ZILlJt9LZ8CrPEyhHB6EkOxvzYOZ1eUbxPEx/y8zK Vl/8dSMvw9BeaQ8B+23pJfkfcW+c4J35CyY6hKcp+RwxLAaiv3wBnDrSsjFisAd7sFHZ YzqkTfP44FmnOs3pEaDwLNbGovklhwkb1wITcWEQKeJhfR7uHwK1ISolK2YiTBH77QkG E8N2uXnKNo/XjM+RCbnGKQ9F6DXdIZ1e6VMnYniepGNUOrVXW0/TEVfS7OZFznowCQUm 9bTANWUFH/hTLqXw6SUTQqoejIrbyElqyOogzTCcNJMb0nU+rP8B6zr2xUH+GecHlLd2 Y62A==
X-Received: by 10.67.6.231 with SMTP id cx7mr13112026pad.79.1431651906689; Thu, 14 May 2015 18:05:06 -0700 (PDT)
Received: from ?IPv6:2001:df0:0:2006:c0da:ac17:5f6d:8e76? ([2001:df0:0:2006:c0da:ac17:5f6d:8e76]) by mx.google.com with ESMTPSA id ux6sm11982pab.24.2015.05.14.18.05.02 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 May 2015 18:05:05 -0700 (PDT)
Message-ID: <55554648.4080009@gmail.com>
Date: Fri, 15 May 2015 13:05:12 +1200
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Russ Housley <housley@vigilsec.com>, Eliot Lear <lear@cisco.com>
References: <5550F809.80200@cisco.com> <0CA1D546-198C-4BC2-8B71-DF85D4FEB1F7@vigilsec.com>
In-Reply-To: <0CA1D546-198C-4BC2-8B71-DF85D4FEB1F7@vigilsec.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/ianaplan/_WFU2wNkB1yIPjccJf8ihn4x67M>
Cc: "ianaplan@ietf.org" <ianaplan@ietf.org>
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: Fri, 15 May 2015 01:05:09 -0000

On 15/05/2015 03:40, Russ Housley wrote:
> I'm not convinced there is a problem for IANAPLAN.  In the current situation, we have an MOU with ICANN, and the IANA Department does the work.  Under the proposal, we still have an MOU with ICANN, and an affiliate (the PTI) does the work.  I think of it as a reorganization.  ICANN has the same responsibilities and commitments to the IETF community.

Exactly. We measure IANA's performance today and negotiate any issues
with the people doing the work and their immediate management. In the
worst case, the IETF can give notice and find an alternative provider.
Whether ICANN performs the work in-house or through a subsidiary really
doesn't matter, formally.

What does matter is the direct contact with the people.

(For people less familiar with the history, the IETF has managed
changes of service provider for both the Secretariat and the
RFC Editor in the past. Doing the same for protocol parameter
registration would not be so different. I hope it doesn't become
necessary, of course.)

    Brian

> 
> I thik they can be glued together in a straightforward manner if the CWG and CCWG works is scoped exclusively to the names registry.
> 
> Russ
> 
> On May 11, 2015, at 11:42 AM, Eliot Lear <lear@cisco.com> wrote:
> 
>> Hi everyone,
>>
>> I'm writing this with an eye toward a conversation that perhaps the IAB and IAOC might find useful, as they consider various activities relating to the IANA transition.
>>
>> Over the last week or so, I read through the CWG proposal for the naming component of the IANA functions transition proposal.  That proposal can be found at [1].  I'm posting some comments here strictly as relates to the IETF relationship with ICANN, and not the rest of it, since that discussion should occur elsewhere.
>>
>> The basis of the naming community's proposal is to create a new entity to take on the IANA functions, known as Post-Transition IANA (PTI)[2].  That entity would be a wholly owned subsidiary of ICANN, but have its own management structure, including a customer service component, known as the Customer Standing Committee.  All current IANA functions would be transferred to the PTI under this proposal.  A multistakeholder IANA Function Review  (IFR) process is created as well.  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.  There's a bunch of mechanism proposed to reduce the likelihood of a change, including escalation, a separation review, etc., but at the end of the day the choice would be the naming community's, just as the IAB has had the choice to con
tinue the protocol parameters arrangement.
>>
>> How does this affect the IETF?  
>>
>> 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.  
>>
>> 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 brings us back to the cardinal question: what's right for the Internet?  Here I understand that different people will have varying views.
>>
>> Having the burden of funding shift to another source can itself be a source of instability.  The CWG proposal contains the FY15 budget costs for the IANA function.  That total is $6.3 million[6], but includes indirect and shared costs as well.  What isn't in those costs is an allocation across functions.  At the very least we should have that information.  Preferably we should have those costs separately funded, to the extent possible.  This would provide the naming community all the freedom they want, and us all the freedom we want, without budgetary risk.
>>
>> Having written that last line, I feel the need to once again point out what we said in our response, that we are satisfied with the performance of ICANN as IFO, and have been for quite some time, and that all of this is still contingency planning.[5]
>>
>> And so questions:
>> 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?
>> If the arrangement is with PTI, should we seek a budgetary separation, and what would be the complexities of that?
>> I think there may be other questions for the CWG proposal, but to me these are the big questions.
>>
>> Eliot
>> [1] https://www.icann.org/en/system/files/files/cwg-stewardship-draft-proposal-with-annexes-22apr15-en.pdf
>> [2] See III.A bullet 1.
>> [3] RFC 2860
>> [4] Message from Axel Pawlik to icg-forum@icanncg.org on 10 May 2015,
>> "Numbers community proposal contact points with CWG’s Draft IANA".
>> [5] draft-ietf-ianaplan-icg-response.
>> [6] See Annex P of the CWG draft.
>>
>>
>> _______________________________________________
>> Ianaplan mailing list
>> Ianaplan@ietf.org
>> https://www.ietf.org/mailman/listinfo/ianaplan
> 
> _______________________________________________
> Ianaplan mailing list
> Ianaplan@ietf.org
> https://www.ietf.org/mailman/listinfo/ianaplan
> 
> 
> 
> _______________________________________________
> Ianaplan mailing list
> Ianaplan@ietf.org
> https://www.ietf.org/mailman/listinfo/ianaplan
>