[discuss] [IANAxfer] [ccnso-igrg] Two accountability questions - help pls- Workshop 23 - ICANN accountability

[John Curran]

On Sep 10, 2014, at 3:53 PM, Milton L Mueller <mueller at syr.edu> wrote:

>> Trying to make IANA
>> accountability structures that address the IANA operator's failure to perform
>> is quite straightforward; it is when we also try to address the possible
>> situation of the IANA operator performing exactly as directed (but somehow
>> out of alignment with served community) that designing mechanisms for
>> accountability becomes rather challenging...
> 
> Yes, that's why some of us favor structural separation and why IANA transition and ICANN accountability are on separate tracks.

Indeed.

> We should not mix up the two requirements. 

Agreed.

> A bad way of mixing them up is allowing the IANA operator to veto or alter approved policies. 

Correct.  This is definitely not expected behavior by the IANA operator, and it 
is specifically ruled out in the both current IETF/ICANN IANA MOU (RFC 2860) and 
in the current NTIA statement of work in section C.8.2 ("This contract does not 
authorize the Contractor to make material changes in the policies and procedures 
developed by the relevant entities associated with the performance of the IANA 
functions.")

> A good way to reconcile those two requirements is to have an "independent judiciary" with the authority to enforce binding, constitutional limitations on what the policy process can do. This appeals process could be used to challenge ultra vires policies, to challenge major process failures, or to challenge implementations that do not reflect agreed policies. All of these challenges should take place BEFORE anything hits the IANA, of course.  

While it's somewhat understandable that this would be considered desirable by some 
in the DNS community, it's probably worth considering how this looks to the other 
organizations which rely on the IANA operator (i.e. the IETF and RIR communities.)

For the IETF community, your "independent judiciary" introduces "noise" into their 
already existing and well-working system.  It effectively creates an "attack vector" 
by which parties that object to the outcome from the IETF's extensive standard 
development and appeal processes could attempt to overturn them.  Frankly, I have 
far more faith in the IETF's processes for handling protocol registry policy 
development disputes than some completely untested tribunal that is still to-be-
defined.

One could make the same arguments for the RIR community, but there's even more 
irony in this particular case, in that the "independent review" body for new global 
address policies is already in place and operational, and it is... the ICANN Board.   
(Per the Global Policy Development Process contained in the ASO MOU agreement between 
the RIRs and ICANN, ICANN reviews the resulting policy and basically either accepts
such or rejects it with "an explanation of the significant viewpoints that were not 
adequately considered during the regular RIR process")  Obviously, this process
seem quite reasonable in the case where the policy development process runs entirely 
external to ICANN _and_ the policy implementation is quite straightforward without
the introduction of additional judgement, but neither of those conditions seems to 
be true in the DNS case.  However, if you proceed with your "independent judiciary" 
approach for the IETF and RIR circumstances, it's likely to be viewed as unneeded, 
undesirable and/or duplicative by those communities (for some very good reasons...)

FYI,
/John

Disclaimer: my views alone.