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

Wed Nov 12 17:25:29 UTC 2014

Milton,

A periodic renewal (re-bidding) was the method followed by NTIA until now.
But I see it as more a consequence of the initial MoU, that was supposed to
be let go after a few years and was iteratively prolonged, than as a
structural mechanism that absolutely needs to be continued. It is indeed an
option but not an obligation. The pros and cons deserve to be weighed
carefully.

ICANN was fundamentally created to handle the IANA functions (cf the
Bylaws, where coordination of allocation and assignment of the three sets
of unique identifiers is mission n°1). It has performed this without major
problems so far and it should not be excluded a priori to confer this
mission permanently to the organization that was instituted for that
purpose. Permanently could also be understood, if need be, as tacit renewal
at regular intervals, with rights to cancel to be determined (see below).

I have often indicated that I see two different functions that NTIA
currently performs in the IANA context:
- the *workflow function* regarding the process of approval of individual
changes
- the *mandate function*: setting SLAs and attributing the responsibility
to an entity in particular, currently at various renewal intervals, and
potentially rescinding it for fault or lack of performance

The issue we are struggling with in designing the mandate function in a
post-NTIA environment is: if there is a periodic renewal, who conducts this
process? Hence various proposals to create a specific body, with all the
complex issues attached to composition, what it does on an ongoing basis
and the corresponding administrative and financial questions.

Were the overall community to agree - in the course of these stewardship
transition discussions - that this mission is conferred on a permanent
basis to ICANN, a large part of this problem goes away.

It would then transform into the following questions:
- who sets the SLAs for the three sets (in the case of this group, for the
two names communities)?
- who controls performance vis-à-vis these SLAs?
- what form do the corresponding arrangement(s) take?
- who has the power to denounce the arrangement(s) for lack of performance?
- who (or what) could trigger a re-bidding of the entire arrangement or
parts thereof?
- what would be the exceptional procedure adopted in that case?

I have some ideas on the answers to the questions above but wanted at that
stage to just insert the idea that regular renewal of a contract by a
single oversight entity (to be created) is only one option. Establishing
ICANN as the permanent manager of the IANA functions should not to be
dismissed from the onset without proper evaluation of the potential
benefits, particularly in terms of simplicity and potential distribution of
performance monitoring.

The situation is similar to the discussion on functional versus structural
separation. The last IANA contract has established a useful functional
separation and I sense that the community is keen on strengthening it,
which seems legitimate and strongly agree with. Some, including you in
particular, would prefer a completely separate entity. These two option are
on the table and discussed. I think it should be the same for the question
of permanent or temporary mandate. Your preference for a regular re-bidding
is well noted and legitimate. But it is not the only possible avenue and
other options - including a permanent mandate - should be listed and
discussed as well.

Hope this helps.

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 Wed, Nov 12, 2014 at 4:47 PM, Milton L Mueller <mueller at syr.edu> wrote:

>  Greg
>
> I see a fundamental problem with your options, hinging in the concept of
> separability. The point of separability is not to make IANA itself separate
> from ICANN per se, but to allow the new contracting authority to open
> bidding to other possible IANA functions operators. In other words, the
> IANA contract should be periodic, as it was under NTIA, and potentially
> competitive - the contracting authority should be able to receive multiple
> applications for the function and decide which one is best.
>
>
>
> In all of your models, I don’t see that happening – instead I see an
> emphasis on the separability of IANA from ICANN organizationally, but no
> concept of periodic renewal and open, competitive bidding.
>
>
>
> Am I missing something, or are you?
>
>
>
> *From:* cwg-rfp3-bounces at icann.org [mailto:cwg-rfp3-bounces at icann.org] *On
> Behalf Of *Greg Shatan
> *Sent:* Tuesday, November 11, 2014 10:28 PM
> *To:* Grace Abuhamad
> *Cc:* RFP3
> *Subject:* Re: [CWG-RFP3] Proposed Agenda for Wednesday 12 November
> Meeting
>
>
>
> All:
>
>
>
> In the course of preparing for tomorrow's call, including discussions with
> the Co-Chairs of the CWG and other subgroup leads, it was decided that a
> preferred course of action would be to prepare three "Strawman Proposals"
> rather than a single "Framework Document" with multiple variables.  These
> three Strawman Proposals are attached.  The proposals are organized on a
> consistent outline, largely taken from the "Variables" document.  This will
> allow us to consider the proposals both "vertically" and "horizontally"
> (i.e., across the documents), and to swap sections as we move toward the
> ultimate deliverable of a single proposal.  The proposals are intended to
> capture most of the major alternatives discussed on this list, the CWG
> list, and in our calls, as well as in other documents circulated in the
> community.  However, if a particular alternative has not been captured in
> any proposal, that does not mean that it is "dead" or even disfavored.
> Similarly, I expect there will be additional issues to be considered in any
> proposal, and these should be captured as well, either on the call or
> thereafter.
>
>
>
> I apologize for the lateness of the hour; I hope you will see that the
> alternatives are not unfamiliar, even if they are now repackaged in
> proposal form.  In our call tomorrow morning, I would like to review and
> work through these proposals in lieu of items 2 and 3 of the agenda.  In
> the course of that review, we should aim to consider pro's and con's, which
> will be added to a document during our call, and then posted or circulated
> for further editing.  I expect that the Strawman Proposals will be
> similarly posted or circulated.
>
>
>
> I look forward to our call.
>
>
>
> Best regards,
>
>
>
> Greg
>
>
>
>
>
>
>
> On Mon, Nov 10, 2014 at 12:31 PM, Grace Abuhamad <grace.abuhamad at icann.org>
> wrote:
>
>  Hi all,
>
>
>
> Here is the proposed agenda for the RFP3 subgroup meeting on Wednesday:
>
>    1. Welcome and Roll Call
>    2. Review of Variables Document (link here
>    <https://docs.google.com/document/d/10PIySH4OEdebff1lU7foynDe8S3PZEvjG2W_UCpJamM/edit?usp=sharing>
>    )
>    3. Review of Framework Document (to be circulated before call)
>    4. Live-Editing of Pros and Cons Document (to be circulated before
>    call)
>    5. Thoughts on this sub-group on how best to use time in Frankfurt
>    6. Assignments for fleshing out parts of Framework Document
>    7. AOB
>
>  Best,
>
> Grace
>
>
> _______________________________________________
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/cwg-rfp3/attachments/20141112/5c03debf/attachment.html>