[discuss] [governance] U.S. to Give Up Oversight of Web Policymaking Body

[Jay Daley]

Hi Steve

>> - Strict functional separation of the policy making and administration
> 
> This is not as simple as it might seem.  It depends on exactly what you mean by “policy.”  I expect your focus, along with many others, is the decisions related to delegation and re-delegation, i.e. which names are added to the root zone who is allowed to operate them.  Perhaps “policy” also includes various issues related to public interest, compliance, etc.  For all of these, I would agree strongly that we do not want to burden the IANA group or the operation of the IANA function with those sorts of issues.
> 
> On the other hand, here are some other things that have been treated as policy issues in the past that are intimately related to the operation of the IANA function.
> 
> 	• DNSSEC.  Should the root be signed?  If so, how?  What should the rules be for assuring trust in the process?  How often should the root key be changed?  Etc.
> 
> Quite obviously we’ve gotten past the first few questions, but there was a lengthy period several years ago where the answers to these questions were stuck in limbo.  Even now, there are important questions about the frequency of key rollover, etc. that are not yet reduced to standard practice.
> 
> 	• IPv6 addresses for root servers.  Should IPv6 addresses be included as glue records for the root servers?
> 
> Again, we are now well past this question, but there was a surprisingly long period where several of the root servers were accessible via IPv6 addresses but those addresses were not in the root zone.   Worse yet, there was no process in place for figuring out whether it was ok to add them and what the issues might be.  (Eventually RSSAC and SSAC did an ad hoc study to provide advice to IANA to get it done.  (See SSAC reports SAC 018 and supporting reports SAC 016 and SAC 017.)
> 
> 	• IDN TLDs.  Are IDNs ok as top level domains?
> 
> It took a long time to work through these issues.  Along the way, eleven names in various scripts were added to the root zone for testing and evaluation.
> 
> Each of the items in the list above has a required policy development and policy decisions.  Equally, each is so intimately tied to the operation of the IANA function that it is impossible and ill-advised to insist there be a complete separate between “policy” and “administration.”  Going forward, I think we need to be careful to fit the solution to the problems.  The IANA function is critical to the operation of the Internet.  As technology changes, the details of its operation must change too.  From my perspective, there will be a mix of policy, technical, administrative and resource issues involved in these changes.  We need a system that is transparent and accountable.  We also need a system that is efficient and effective.

These are all policy issues so in a structurally separate arrangement ICANN would set the policy around these and IANA would implement them.  I think you have provided the template for how that works in your potted history above, in particular how the thorny questions around these policy issues are addressed - expert views are sought through the ICANN process and a sufficient degree of technical consensus is achieved.

We already have a good example of how this works in practice: the management of the minor registries under IANA.  In most cases the policy control rests with the IETF and IANA implements what it is asked to do in published RFCs.  Crucially, IANA can only make changes that appear in RFCs and only RFCs can ask IANA to make changes. 

> 
>> I think that many, myself included, do not see how being part of ICANN
>> and strict functionally separation are possible within ICANN's current
>> configuration.
> 
> Can you identify specific instances where the current configuration has failed to operate properly and where the failure is due to lack of strict functional separation?  (Also, I think there’s been pretty strong separation in place for a long time, so I’m not sure how much more separation you have in mind.

Asked that way the answer will always be that the IANA function in ICANN does a professional job and only implements what it is told to implement.  However the issue is not whether IANA does what it is told, it is whether the things it is told to do have always come from a documented process of community consensus.  

Structural separation to a large part guarantees that the changes that IANA is asked to implement can only come from a documented process of community consensus (as with the IETF to IANA interface) and cannot be arbitrary decisions of the ICANN board.  That's because with structural separation IANA can refuse to implement a decision that is not from such a process, whereas with IANA part of ICANN it cannot.

You've asked for examples, which means identifying examples of where the ICANN board has instructed IANA without community consensus being established first.  This is hard to do because in recent years decision about the redelegation of ccTLDs are discussed in secret by the ICANN board.  However the redelegation reports published show that community consensus is not measured and so we assume that decisions are made absent that.  With structural separation this would not be possible.

As a reminder, the Delegations/Redelegations Working Group (DRDWG) in the ccNSO in its final, well evidenced, report[1] noted:

	The DRDWG have conducted research on the ICANN decisions relating 
	to delegations and re-delegations of ccTLDs and believe the research 
	highlights decisions made that contain elements of inconsistent 
	application of policies, guidelines and procedures, and on occasions that 
	ICANN decisions have been based on criteria not included in the relevant 
	policies, guidelines and procedures. The decisions of the ICANN board 
	should be logical and predictable.

Please note, I am not suggesting no role for the ICANN board.  It is you who must determine when consensus has been reached, given that there will always be holdouts.

regards
Jay

[1] http://ccnso.icann.org/workinggroups/drd-wg-final-report-without-consent-07mar11-en.pdf    (see .iq and .cx for examples)

-- 
Jay Daley
Chief Executive
.nz Registry Services (New Zealand Domain Name Registry Limited)
desk: +64 4 931 6977
mobile: +64 21 678840
linkedin: www.linkedin.com/in/jaydaley