[CWG-RFP3] Separability was Re: [] Revised Survey

Wed Jan 7 18:00:49 UTC 2015

Hi,

I agree with Greg on this.  That, and perhaps coverage of any other
intractable IANA compliance issues.

Analogous to the situation that the IETF had a number of years ago,
before the advent of David Conrad,  where a great number of the IETF
partiicpants were upset with performance issues that got discussed at
every plenary. 

So for me this is about the IANA function and its proper governance
modalities.

The confusion we have with leverage on ICANN is different.

a. For many, this transition is an opportunity, perhaps a last
opportunity, to use the question of 'to transition or not to transition'
as leverage to try an obtain some further accountability and
accountability guarantees from the ICANN powers that be.

b. For some, the continued existence of a re-assignable contract remains
a Sword of Damocles type of incentive for accountability, but is not an
accountability mechanisms itself.

c. And perhaps for some, though I am not sure, it is a continuing
accountability measure that can be pulled out anytime it is wanted.

BTW, (c) is my reason for prefereing a reglar review and RFP over an
nuclear option RFP mechanism.  If the only way for consideration of the
contract is a nuclear option, someone is bound to precipitate a crisis
sooner of later for just that purpose - or at least take it to the brink
- as is the case with so many nuclear options.  A regular orderly
process-intense review and possible RFP* is not as prone to this form of
brinkmanship.

avri

* in some of the proposals not all reviews necessarily precipitate RFP -
much as is the case now with NTIA.

On 07-Jan-15 12:20, Greg Shatan wrote:
> Steve,
>
> Speaking for myself (but not thinking I'm alone), when I talk about
> "separability," I'm talking about the former (moving the IANA function
> operation to another operator if the IANA function is not being
> performed properly), not the latter (using the threat of moving the
> IANA function operation to another operator as a means of gaining
> leverage over the other parts of ICANN).
>
> Greg
>
> On Wed, Jan 7, 2015 at 11:15 AM, Steve Crocker
> <steve.crocker at icann.org <mailto:steve.crocker at icann.org>> wrote:
>
>     Avri,
>
>     I think the appropriate response to your seemingly plausible
>     statement is “governance of what?”
>
>     Are we talking about moving the IANA function operation to another
>     operator if the IANA function is not being performed properly, or
>     are we talking about using the threat of moving the IANA function
>     operation to another operator as a means of gaining leverage over
>     the other parts of ICANN?
>
>     If the latter is what’s really driving these discussions, I don’t
>     think this is good governance.  If there is a governance issue for
>     the rest of ICANN, the proper way to proceed is to improve ICANN’s
>     operation and governance mechanisms.
>
>     Moving the IANA function — or threatening to move the IANA
>     function — should be limited to making sure the IANA function is
>     performed properly.  And the IANA function consists solely and
>     exactly with publishing the information that’s been approved by
>     the processes that create that information.
>
>     Steve
>
>
>     On Jan 7, 2015, at 10:33 AM, Avri Doria <avri at acm.org
>     <mailto:avri at acm.org>> wrote:
>
>>     Hi,
>>
>>     While I agree with what Chuck says and feel much the same way, I
>>     think the reason for separability goes beyond this issue.
>>
>>     As we see with IETF and now with NRO/CRISP solution, they have an
>>     arms length relationship as separate entities with ICANN and can
>>     negotiate conditions because of the arms length and can make
>>     decision to sever the relationship.
>>
>>     The absence of actual separation, or even perceptible functional
>>     separation of ICANN-IANA, is more an issue of proper governance
>>     than of trust.  With NTIA holding the contract, there is a path
>>     for moving the function to another operator if necessary.  If the
>>     contract is eliminated, there is no possibility of change and no
>>     way to use the leverage of possible change in 'negotiations'. So
>>     the issue is about maintennace of a contractual relationship for
>>     governance's sake not just ICANN accountability.
>>
>>     I think it is problematic that we keep putting the discussion
>>     just in terms of trust and accountability - important as they
>>     are, the point is proper governance, where policy and operations
>>     are separate functions that need to be at the least functionally
>>     separated but which are often fully separated. And while the
>>     enables one kind of accountability, separation is not just about
>>     accountabilty.
>>
>>     So I think at least part of our conversation should center on the
>>     requirements of governance modalities, not just accountability
>>     and the amount of trust we may or may not have in the ability and
>>     willingness of this or any future Board to change the bylaws.
>>
>>     avri
>>
>>
>>     On 07-Jan-15 09:35, Gomes, Chuck wrote:
>>>
>>>     Olivier,
>>>
>>>      
>>>
>>>     As I know you understand, the convincing goes both ways.  I
>>>     agree that those who support the new approach have a
>>>     responsibility to firm up the details that any new entities will
>>>     remain accountable and I think that work is happening.  But I
>>>     also need to be convinced that the ICANN Board will agree to
>>>     accountability mechanisms that are binding.  They have never
>>>     been willing to do that since 1998, so I am curious why you
>>>     think they will do that this time around.  I am one who probably
>>>     will not be convinced until it happens and until there are
>>>     provisions put in place to make sure they cannot change that.
>>>
>>>      
>>>
>>>     Chuck
>>>
>>
>>     _______________________________________________
>>     Cwg-rfp3 mailing list
>>     Cwg-rfp3 at icann.org <mailto:Cwg-rfp3 at icann.org>
>>     https://mm.icann.org/mailman/listinfo/cwg-rfp3
>
>
>     _______________________________________________
>     Cwg-rfp3 mailing list
>     Cwg-rfp3 at icann.org <mailto:Cwg-rfp3 at icann.org>
>     https://mm.icann.org/mailman/listinfo/cwg-rfp3
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/cwg-rfp3/attachments/20150107/a9088f5e/attachment-0001.html>