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

[Alissa Cooper <[e-mail]>]

Hi Milton,

Thanks. I guess we are really talking about two aspects of the IANA functions and whether those aspects should change. (1) Currently all the functions are provided by the same entity (the IANA Department) and (2) that department is currently part of ICANN. If either of these must change, you have a preference for changing 2 and not 1; I have a preference for changing 1 and not 2. 

On May 14, 2015, at 8:38 AM, Milton L Mueller <[e-mail]> wrote:

>  
> MM: Thanks for a very interesting and thoughtful intervention, Alissa. My responses in line, and I want especially to take up the issue of whether there are “compelling arguments” for transferring protocols stuff into PTI:
>  
> 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.
>  
> MM: I there are 2 compelling arguments and 2 others which may not be quite as compelling. I will quickly set them out below, but keep in mind that most of them hinge on general benefits for Internet governance and not necessarily on specific benefits to IETF. I hope IETF can take the larger view. They are:
> 1.      Economies in organizational overhead
> 2.      Complementarity and coordination of functions
> 3.      More rational financial/resource accounting
> 4.      More focused negotiation
> 1) Any PTI will have some fixed organizational costs and the entity will be more efficient if they are spread over more functions and activities. Just to illustrate this point, it would make little sense to create a separate organization for, say, the numbers function alone as that would be maybe two people.

That may be true, but if the names functions on their own can’t justify the overhead they require, I would question why they’re being split out in the first place. I tend to think they do actually justify their own overhead, and the overhead for protocol parameters and numbers can continue to be subsumed in the larger ICANN cost structure. Furthermore, we’re talking about a pretty small PTI no matter whether it encompasses all three functions or just one — it’s not like the IANA functions are a huge operation. We’re talking about three people who provide the protocol parameters function.

>  
> 2) If the IANA functions and their management involve any interrelated activities, require coordination, or have some complementarity on the supply side, it would be better to keep them in the same entity rather than forcing the entity to reach across organizational boundaries every time they need to coordinate, etc. I frankly don’t know how many interactions there are between protocol registry management and names/numbers management but I suspect there are some, and there are also some for names and numbers. This leads to what I think is a pretty strong response to your “if it’s not broken don’t fix it” argument, which is that if part of the current IANA dept moves to PTI then keeping the protocol functions inside ICANN is _not_ the status quo but a new and untested organizational arrangement.

I’m not aware of much coordination at the operational level. The important coordination happens at the policy level and should continue to be the responsibility of the policy bodies. It’s true that the policy bodies might need to know to inform a different operator if one or more of the functions moves outside the IANA Department, but that seems like the appropriate path to me, rather than asking the operators to coordinate, which seems like it would be outside their mandates anyway.

If the operators all continue to share the same web site then they will need some administrative coordination, but that seems trivial enough and again not sufficient reason to keep the personnel and resources together.

> Further, if all the functions are provided by the same provider the less risk there is discrimination in the execution of the IANA functions. IANA should be by design a stable institution that can avoid conflicts between registries.

I’m not sure what you mean by discrimination and conflicts between registries.

>  
> 3) Structural separation makes things more visible in terms of their costs, which in turn enables greater financial accountability and efficiency.
>  
> 4) In the future, do you want to negotiate with the legal staff and CEO of ICANN, which has a much broader agenda that is affected by a lot of ancillary things, or with a smaller, more focused entity?

The above two arguments strike me as additional benefits that you think the CWG proposal provides to the IETF, but the IETF has already submitted its proposal and is on the record as being satisfied with the current arrangements. If we think the above two points are valid, we could pursue them in the future or we could have included them in our own proposal, but we didn’t.

>  
> 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.
>  
> MM: What you seem to be saying here is that there is really no strong reason _not_ to move them along with the other functions.

See my point above about preferring to split operations rather than move to PTI.

>  
> 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.
>  
> MM: That depends on whether you think current relations with ICANN are “working.” See point 4 above, and perhaps take another guilty look at Andrew Sullivan’s accidental message. ;-) The broader point is: I don’t see any disadvantages to moving it, either.

Again, the IETF consensus is that we are satisfied with current arrangements.

>  
> 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.
>  
> MM: I mostly agree with the logic here. But, you may be unaware of the larger issues associated with the PTI board. The main debate in the CWG plan is whether the PTI board is controlled by ICANN or not (could have ICANN on it but not a majority). It’s called “insider” vs “outsider” board. CWG is currently trending toward insider board but should it move toward an outsider board and wants non-ICANN people on it, why not an IETF appointee? Not necessarily in their capacity as “IETF,” but just someone from the protocols community. If PTI performs all 3 IANA functions, does it not make sense to have someone from protocols on its board?That’s more what this issue is about, not about supervision of the IETF MoU and SLA. Just as a hypothetical, suppose ICANN decided to (or its bylaws required it to) appoint its board liaison to the PTI. Doesn’t sounds like you would support this, but would you oppose it? Sounds more like you are indifferent.

Reading this, it seems like there are too many missing details about the board at this point to really be able to provide an opinion. 

Alissa