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

[Jaap Akkerhuis]

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.