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

Mon Mar 9 12:54:59 UTC 2015

 "Gomes, Chuck" writes:

 > 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.

As far as I understand "PDP = policy development process" is what is
meant.

Berry requested in a private mail whether it could be let known whom
is the author of this note. It turns out it is actually a collective
reaction from a couple of SSAC people and should be earmarked as
"informal reaction" from SSAC. Since I wasn't part in creating the
mails (I only forwarded it), I suggest that if you want more details,
you contact the chair of the SSAC, Patrik Fältström
<patrik at frobbit.se>.

Regards,

	jaap

 > 
 > 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