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

[Alissa Cooper <[e-mail]>]

Eliot, thanks for kicking off this discussion.

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.

Alissa

On May 11, 2015, at 11:42 AM, Eliot Lear <[e-mail]> 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 continue 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 [e-mail] 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ianaplan