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

Sat Nov 15 14:24:23 UTC 2014

I noticed I missed 2 critical words in my last mail which may have
misrepresented what I intend to say. Kindly find below:

Hi Chuck,

Thanks for your response, however i will like to mention that "cancellation
for cause" in itself is an incentive for the operator to be innovative.
Having to renew a contract within this context may *NOT* then be a very
important part because the operator already knows the clear indication that
could cause termination..... I also think the issue of competition as an
incentive may be quite in-significant in this context because the IANA
functions are very clear and i don't see what other innovation that would
be required unless those introduced by the relevant communities either by
policy OR by RFCs. What is usually the bone of contention is the operator's
organisation and i think there is improvement in building an inclusive
environment within the current operator...which i don't think we will
easily achieve if another operator is assigned the role.

The other side is that a renewal in itself opens another level of politics,
lobbying etc especially now that the role of renewing is leaving the hands
of a "legitimate entity". So i think *IT* could do us all well to avoid
such situation by considering the non-termed route.

Nevertheless, i must also note that there are merits in going the termed
route especially if we don't sense that the current operator is growing and
improving significantly in its processes

Cheers!

sent from Google nexus 4
kindly excuse brevity and typos.
On 14 Nov 2014 16:30, "Seun Ojedeji" <seun.ojedeji at gmail.com> wrote:

> Hi Chuck,
>
> Thanks for your response, however i will like to mention that
> "cancellation for cause" in itself is an incentive for the operator to be
> innovative. Having to renew a contract within this context may then be a
> very important part because the operator already knows the clear indication
> that could cause termination..... I also think the issue of competition as
> an incentive may be quite in-significant in this context because the IANA
> functions are very clear and i don't see what other innovation that would
> be required unless those introduced by the relevant communities either by
> policy OR by RFCs. What is usually the bone of contention is the operator's
> organisation and i think there is improvement in building an inclusive
> environment within the current operator...which i don't think we will
> easily achieve if another operator is assigned the role.
>
> The other side is that a renewal in itself opens another level of
> politics, lobbying etc especially now that the role of renewing is leaving
> the hands of a "legitimate entity". So i think could do us all well to
> avoid such situation by considering the non-termed route.
>
> Nevertheless, i must also note that there are merits in going the termed
> route especially if we don't sense that the current operator is growing and
> improving significantly in its processes
>
> Cheers!
>
>
>
> On Fri, Nov 14, 2014 at 3:36 PM, Gomes, Chuck <cgomes at verisign.com> wrote:
>
>>  Seun,
>>
>>
>>
>> I get your point but I personally think that there are important
>> differences between cancelling a contract for cause and renewing a contract
>> at the end of a term.  Here are some examples:
>>
>> 1.       Cancelling a contract for cause would be an unplanned event and
>> would presumably need to happen in a shorter time period than a planned
>> renewal.
>>
>> 2.       If the threat of cancelling for cause was too easy to do, that
>> could create an unpredictable situation for the contracted party; I don’t
>> think that motivates investment in improvements and a stable environment.
>>
>> 3.       A contract renewal can be planned well in advance whereas a
>> cancellation for cause would have to be done in a shorter time frame.
>>
>> 4.       A cancellation for cause could result in a temporary situation
>> where the contracted party is not very motivated to perform well.
>>
>> 5.       A renewal introduces the element of competition that can
>> generate innovative ideas and allow us to compare current services with
>> those new ideas.
>>
>>
>>
>> Chuck
>>
>>
>>
>> *From:* cwg-rfp3-bounces at icann.org [mailto:cwg-rfp3-bounces at icann.org] *On
>> Behalf Of *Seun Ojedeji
>> *Sent:* Friday, November 14, 2014 12:41 AM
>> *To:* Milton L Mueller
>> *Cc:* RFP3
>> *Subject:* Re: [CWG-RFP3] Contract re-bidding at regular intervals or
>> permanent mandate?
>>
>>
>>
>> Hello Bertrand and Milton,
>>
>> @Milton it seem you are implying that a non-termed contract/agreement
>> will not be possible because that was my point?
>>
>> @Bertrand moving in 7 to 10 years may make a relatively stable operator.
>> However my point is, why make it termed if it's possible to withdraw at any
>> point in time. Maybe the review of contract/agreement terms can be termed
>> as we see the organization improve but I necessarily don't see why a
>> contract renewal process need to exist. Especially as this oversight
>> transition to multistakeholder which is a very big word if you ask me.
>>
>> In this process, we should also be determined to continue building the
>> organisation operating IANA. Moving across operator should only be an
>> option and remain as such.
>>
>> Thanks
>>
>> Cheers!
>>
>> sent from Google nexus 4
>> kindly excuse brevity and typos.
>>
>> On 14 Nov 2014 03:14, "Milton L Mueller" <mueller at syr.edu> wrote:
>>
>> Seun
>>
>> There is a simple answer to your question. If the service provided by the
>> incumbent is satisfactory then they are likely to retain the contract.
>> Other applicants might look very good in the ‘beauty contest,’ but unless
>> there is some kind of profound dissatisfaction with the incumbent there is
>> a lot of pressure not to change. So one could re-bid the contract every
>> three years but still end up with the same organization doing it for 12
>> years or 30 years.
>>
>>
>>
>> *From:* Seun Ojedeji [mailto:seun.ojedeji at gmail.com]
>> *Sent:* Thursday, November 13, 2014 12:29 PM
>> *To:* Guru Acharya
>> *Cc:* RFP3; Milton L Mueller
>> *Subject:* Re: [CWG-RFP3] Contract re-bidding at regular intervals or
>> permanent mandate?
>>
>>
>>
>> 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 !
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/cwg-rfp3/attachments/20141115/a4142c00/attachment-0001.html>