[CWG-RFP3] Contract re-bidding at regular intervals or permanent mandate?

Thu Nov 13 23:01:11 UTC 2014

Hi Seun and Guru,

I think you are talking about two different elements that overlap but are
distinct:

   - the notion that the contract(s) should be *breakable and transferable*
   to an other actor - for instance through an open bidding - in case of
   blatant non-performance, disfunction or fault. This is an
   extra-ordinary/emergency sanction and Seun indicates it should be possible
   at any point in time if the conditions are met.
   - the notion that the contract(s) could have a *set duration*, with Guru
   asking if a longer term (10 years) could alleviate the concern regarding
   institutional instability that doing a rebid at too short intervals could
   entail. This is discussed as a normal regime, even in the case that the
   operator performs OK.

I feel the first point would receive broad support. In any case, I am
personally comfortable with it. Some extra-ordinary procedure is probably
needed to anticipate real problematic situations. A key question is the
determination of the threshold(s)/acceptable triggers and how high they
are. But let's leave this aside for the moment.

*Two variables to define options for a "normal regime"*

The second point (the "normal regime" to be implemented even in the absence
of any problem a priori) makes me think that we can map options on the
basis of *two complementary variables*:

a) On one hand, the basic *duration of the contract*(s): there is a simple
range going from very short (eg: 2years) to fully permanent (including the
procedure above), with for the sake of simplicity, two intermediaries at 5
and 10 years for instance.

b) On the other hand, *what happens at the expiration of each period*. I
see here three basic options:

   1. systematic and compulsory full rebidding each time (as per Milton),
   2. explicit decision each time to either continue with the same operator
   for another period or do a rebidding
   3. presumption of renewal unless explicit decision is made to open
   rebidding under certain conditions (they can be more or less strict and
   even have no threshold at all)

*Combinations*

These two variables can be combined in many ways.

For instance, the current IANA contract has a first period of three years
plus two options for extension for two years each (ie: 7 years in total).
In the absence of the current effort towards transition, this would have
allowed NTIA to nor exercise the option after three years and open a rebid
if it wanted. This corresponds to option b)2 supra.

Likewise, the current regime for gTLDs is closer to b)3: presumption of
renewal unless very strict criteria justify otherwise.

In designing the post-transition regime, we need both to find a sustainable
solution that will not have to be re-discussed in a couple of years (the
natural tendency at ICANN, an organization in perpetual institutional flux)
and take into account that the new regime may need a period of
adaptation/transition itself.

Moving towards a longer contract period and presumption of renewal could be
envisaged with predetermined steps. For instance, five initial years with
an explicit extension option of five years and then a move to 10 years or
any other combination.

The option of opening rebidding would be available at each deadline but
could be (explicitly or implicitly) NOT exercised if performance is judged
sufficient and stability is deemed paramount. Or, on the contrary, be
available only IF performance is deemed insufficient. An alternative
similar to the opt-in and opt-out choice.

In other words, there are many ways to play with those components to tailor
something appropriate. In any case, I would argue that a very short
duration of the contract (2-3 years) with systematic rebidding would
probably harm stability and create administrative burdens more than it
would enhance accountability beyond other combinations.

*Open rebidding as principle or as signal?*

It is interesting to note that the last IANA contract process did not
produce competing candidates. It was mostly a negotiation of enhanced SLAs
and better structural organization (including functional separation). But
it created an important preliminary administrative burden.

Open rebidding is not needed to renegotiate SLAs or arrangements with the
same operator. Such a modification process could be triggered separately at
any appropriate moment, should the need arise, according to specific
separate rules.

In other terms, there is a difference between open rebidding as a matter of
principle, even when the operator is perceived as performing OK and open
rebidding as a signal that something is not functioning correctly. My sense
is that if it is optional, it strongly encourages the operator to avoid
deserving this message.

In that situation, any announcement on the occasion of a renewal that an
open rebid will be made would stigmatize strongly the operator. Remember
the image of ICANN when its first submission in the last IANA process was
refused. On the contrary, making rebid systematic penalizes the good
operator by not treating it differently from a non-performing one.

*The overall objective*

As a general rule, I favor regimes that make things easy for the good guy
and install strong ongoing monitoring and remediation measures to rapidly
address dysfunctions, rather than regimes tailored on the basis of defiance
and the a priori supposition of misconduct.

Changing the operator would not be a minor decision. It would entail
administrative and technical challenges, risks to the stability of the
system, and in any case unknowns regarding the potential replacement (the
devil you know...): making a submission is one thing, living up to the
promises might be another. It is therefore more a threat, a sanction, a
message, than an ongoing mundane mechanism.

So far, the contract has been renewed for the last 16 years. Hopefully
ICANN - once again created for that purpose - can be incentivized to
perform better and better and remain the operator far in the future. I
would favor designing the regime in the perspective of this objective.

Apologies for the long post. Certainly needs refinement. But I hope it
helps frame the discussion further. Just my own perspective.

Best

Bertrand

"*Le plus beau métier des hommes, c'est d'unir les hommes*", Antoine de
Saint Exupéry
("*There is no greater mission for humans than uniting humans*")BERTRAND DE
LA CHAPELLEInternet & Jurisdiction Project | Directoremail
bdelachapelle at internetjurisdiction.netemail bdelachapelle at gmail.comtwitter
@IJurisdiction <https://twitter.com/IJurisdiction> | @bdelachapelle
<https://twitter.com/bdelachapelle>mobile +33 (0)6 11 88 33 32
www.internetjurisdiction.net[image: A GLOBAL MULTI-STAKEHOLDER DIALOGUE
PROCESS]

On Thu, Nov 13, 2014 at 8:48 PM, Seun Ojedeji <seun.ojedeji at gmail.com>
wrote:

> On Thu, Nov 13, 2014 at 6:41 PM, Guru Acharya <gurcharya at gmail.com> wrote:
>
>> Would your concerns about stability arising from operator hopping be
>> addressed if the contract term is longer - say 7 or 10 years?
>>
>
> Not really, i am thinking more of a scenario where if ICANN goes against
> defined SLA/terms it be called to order to resolve and if that goes
> negative, a clearly defined process to transfer to another operator is
> initiated. Ability to do that should not be possible after a 2 years term
> neither should it be after a 10years. This should be possible at any point
> in time and if that understanding valid, i don't see why a termed contract
> will be necessary.
>
> However i am not a lawyer so perhaps what i have explained is not legally
> attainable, but from a logical point of view, i think it is feasible.
>
> Thanks
>
> Regards
>
>>
>> On Thu, Nov 13, 2014 at 10:58 PM, Seun Ojedeji <seun.ojedeji at gmail.com>
>> wrote:
>>
>>> While we consider all these options, I will ask that we also consider
>>> whether it's better to concentrate on an organisation with the aim of
>>> improving it's operation OR we keep on moving from one incomplete
>>> organisation to the other in the name of keeping the previous/current
>>> operator accountable.
>>>
>>> We should in this process determine whether there is significant
>>> improvement in the current operator of IANA and also whether there is room
>>> for further  improvement. Stability cannot be maintained if the operator
>>> itself is not stable.
>>>
>>> My 2 cents.
>>>
>>> Cheers!
>>>
>>> sent from Google nexus 4
>>> kindly excuse brevity and typos.
>>> On 13 Nov 2014 18:03, "Guru Acharya" <gurcharya at gmail.com> wrote:
>>>
>>>> I agree with Milton that the IANA contract should be for a limited time
>>>> period (say 3 or 5 years). The oversight body should be responsible for
>>>> deciding the new IANA operator at the end of the contract term. This is the
>>>> most effective way of ensuring accountability.
>>>>
>>>> However, I disagree with the mechanism of "Open Bidding" that Milton
>>>> seems to be suggesting for determining the new IANA operator. The term Open
>>>> Bidding seems to suggest financial reverse auctions. The mechanism should
>>>> instead be in the form of a transparent beauty contest wherein open
>>>> applications are invited from all interested parties. The judging
>>>> parameters for the beauty contest should be mostly technical. In this
>>>> beauty contest, the incumbent IANA operator should get extra marks in case
>>>> of a good record in the previous contract term, the measure of which should
>>>> be in the form of objective service level criteria.
>>>>
>>>> If the IANA contract is perpetual or with termination clauses based
>>>> solely on service levels then, in case of serious dissatisfaction with the
>>>> incumbent IANA operator, the process of changing the IANA operator may be
>>>> subjected to a lot of litigation and arm-twisting. The current transition
>>>> arrangements need to have the foresight to avoid such problems.
>>>>
>>>> On Thu, Nov 13, 2014 at 7:03 PM, Milton L Mueller <mueller at syr.edu>
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> *From:* Bertrand de La Chapelle [mailto:bdelachapelle at gmail.com]
>>>>>
>>>>>     view, accountability was also exercised on a regular basis,
>>>>> through the monitoring of performance, the possibility of audits and,
>>>>> actually, also the role of NTIA as RZM process administrator (on each
>>>>> modification). In this regard, moving the contract somewhere else, as
>>>>> "nuclear option", was the ultimate accountability stop but not the alpha
>>>>> and omega of the accountability system.
>>>>>
>>>>>
>>>>>
>>>>> MM: True. Those forms of accountability are complementary. But most of
>>>>> the proposals on the table for a new contracting authority also include
>>>>> these other forms of monitoring.
>>>>>
>>>>>
>>>>>
>>>>> Furthermore, ultimate accountability does not need to come from a
>>>>> single point of authority. It can be more distributed. For instance, if the
>>>>> different user communities of the IANA functions were to establish separate
>>>>> agreements with ICANN (or recognize that it plays this role for them) with
>>>>> the capacity to cancel this agreement on the basis of specific criteria
>>>>> (including performance), the capacity to "pull the trigger on a contract"
>>>>> would be fulfilled.
>>>>>
>>>>>
>>>>>
>>>>> MM: This is a very interesting idea and I hope you pursue it and make
>>>>> it more concrete. As a future scenario it is highly likely that IANA’s
>>>>> performance might satisfy one or two of the operational communities but not
>>>>> the other one. Furthermore, as you suggest, it is safer to distribute this
>>>>> contracting authority rather than having it concentrated.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> The question of accountability should not be limited to the single
>>>>> model of replacing the NTIA by another single structure (to be created),
>>>>> continuing without question the practice of re-bidding that was the result
>>>>> of circumstances as much as a voluntary choice, and focusing on the
>>>>> "nuclear option" as the most important aspect, neglecting on the way more
>>>>> continuous accountability dimensions.
>>>>>
>>>>>
>>>>>
>>>>> MM: Well, I do not want to neglect more continuous accountability
>>>>> dimensions, but after 16 years of experience with the ICANN environment I
>>>>> have a pretty strong conviction that nothing short of periodic renewal can
>>>>> provide the foundation for all the other forms of monitoring and
>>>>> accountability.
>>>>>
>>>>>
>>>>>
>>>>> All I argue for is that we should include in our thinking the
>>>>> following option: what would be the accountability mechanisms appropriate
>>>>> IANA were permanently managed by ICANN?
>>>>>
>>>>>
>>>>>
>>>>> MM: No, there is definitely a contradiction between “being
>>>>> accountable” and a grant of “permanent management” rights. While there can
>>>>> be some additional supervisory or oversight mechanisms, insofar as the
>>>>> grant is permanent it massively increases the slack that the operator has
>>>>> against its principals. If the assumption is, “I will always be the
>>>>> contractor” you can issue all the stern warnings and bad reports you like,
>>>>> the incentive to change is drastically weakened. This seems obvious to me.
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Cwg-rfp3 mailing list
>>>>> Cwg-rfp3 at icann.org
>>>>> https://mm.icann.org/mailman/listinfo/cwg-rfp3
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> Cwg-rfp3 mailing list
>>>> Cwg-rfp3 at icann.org
>>>> https://mm.icann.org/mailman/listinfo/cwg-rfp3
>>>>
>>>>
>>
>
>
> --
> ------------------------------------------------------------------------
>
>
>
>
>
> *Seun Ojedeji,Federal University Oye-Ekitiweb:
> http://www.fuoye.edu.ng <http://www.fuoye.edu.ng> Mobile: +2348035233535**alt
> email: <http://goog_1872880453>seun.ojedeji at fuoye.edu.ng
> <seun.ojedeji at fuoye.edu.ng>*
>
> The key to understanding is humility - my view !
>
>
>
> _______________________________________________
> Cwg-rfp3 mailing list
> 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/20141114/4daf27b0/attachment-0001.html>