[CWG-Stewardship] Singapore Thursday Q&A Session Input

[Gomes, Chuck]

Jaap,

It is not clear to me that what is meant by PDPs in the following.  In my mind PDP = policy development process but the way it is used below sometimes doesn't make sense if I use that definition.

Chuck

-----Original Message-----
From: cwg-stewardship-bounces at icann.org [mailto:cwg-stewardship-bounces at icann.org] On Behalf Of Jaap Akkerhuis
Sent: Monday, February 23, 2015 9:01 AM
To: Berry Cobb; cwg-stewardship at icann.org
Subject: Re: [CWG-Stewardship] Singapore Thursday Q&A Session Input

On the SSAC mail list I pointed out this request for input and got a personal reaction. So do note, this is not a a reaction from SSAC as group, just from an individual member of SSAC.

Nevertheless, I found int intersting enough to forward.

	jaap


----
> * Do you believe that the transition from the NTIA should happen
    (Please provide the reasons for your answer)?

Yes, because it is important IANA function oversight is moved from US Government to the communities that do set the policies by which IANA operates.

> * Are you comfortable with ICANN as policy-maker also being the IANA
    operator without the benefit of external oversight?

Impossible to answer as "ICANN" is not specified well enough.

I am comfortable with ICANN ccNSO and gNSO being policy makers while the IANA Function at ICANN Corporation is implementing the policy developed by the PDPs.

> * Should registries, as the primary customers of the IANA functions,
    have more of a say as to which transition proposal is acceptable?

The registries are not the primary customers of the IANA functions.
The IANA functions include many other things like IP Addresses, Protocol Parameters etc.

The balance in who has what say regarding instructions to IANA should be set by the design of the PDPs that control the IANA functions which include ccNSO and gNSO.

> * What does functional separation of IANA from ICANN mean to you?
    (this is not referring to having another operator than ICANN
    performing the IANA functions but rather the internal separation
    between ICANN and IANA in the context where ICANN is the IANA
    operator)

First of all, there are already other organizations providing functions that IANA Function at ICANN could do (RIPE NCC for E.164 numbers for example).

Internal separation is only needed in the cases the PDPs do not create clear enough instructions to what IANA is to make. People participating do mix up ICANN decisions (on who can be registry for a specific TLD for example) with IANA actions (to take instructions and otherwise communicate with the registries).

So, I view the need for separation collapse into need for the PDPs to:

1. specifically produce instructions for IANA 2. explicitly validate that IANA is following the instructions

> * In considering the key factors (such as security and stability,
    ease of separating the IANA function from ICANN, quality of services,
    accountability mechanisms etc.) for evaluating the various transition
    proposals what importance would you give to the ability to separate
    IANA from ICANN (separability) vs. the other factors?

If the IANA Function of ICANN is not following the instructions then an RFP must be filed for a separate group following those instructions. ICANN have already demonstrated such RFP can be hosted, run and affected for the ICG Secretariat that is now independent and separated from ICANN.

Don't forget the financing of IANA and other bodies people ask for.

> * Given the IANA functions could be separated from ICANN do you
    believe it would be important for the community to obtain from ICANN
    on an annual basis the costs for operating IANA including overhead
    costs?

The PDP should decide what the rules for IANA should be, and if needed also who should take care of it. As part of that is also of course financing issues.

Regarding separation, as long as ICANN is financing, there is no real separation.

So, if the PDP want someone else than ICANN to run IANA, then the PDP must also be able to find money for the operation.

> * Would it be important to separate out the costs associated with
address and protocol functions?

If RIRs or IETF want to move the functions, then of course IETF and RIR have to find financing of the (new) operator for that coordination. ICANN have nothing to do with it.

Today ICANN have agreed to finance the IANA Function as long as it is hosted at ICANN. That in turn might be a reason for (for example) RIRs to donate money to ICANN, and for Registry operators of TLDs to do the same.

> * Could there be unforeseen impacts relative to selecting a new
    operator for the IANA functions vs the ICANN policy role (should ICANN
    determine that there will be another round of new gTLDs, how could it
    ensure that the new operator would accept this)?

Once again, it is only possible to talk about this if one talk about the role of the PDPs. Not just say "ICANN".

> * Are there other transition models which the CWG should be
    exploring?

It must be much more clear what the role of the PDPs ccNSO and gNSO have to be able to do further evaluation, but in short I think better steps forward include:

A. Have the PDPs explicitly be the creators of instructions to IANA, and create interaction between the PDPs and IANA similar to the interaction IETF have. Specifically separate the IANA instructions from the rules for (for example) new TLDs.

B. Have GAC be responsible for finding a permanent solution for the .INT TLD based on the existing rules (RFC 1591 minus the international database).

C. Have ccNSO resolve the issues with ccTLD delegation/redelegation.

D. Have ICANN bylaws or otherwise be changed to ensure the power stays with the PDPs.

_______________________________________________
CWG-Stewardship mailing list
CWG-Stewardship at icann.org
https://mm.icann.org/mailman/listinfo/cwg-stewardship