[CWG-RFP3] Proposed Redline to Strawman 1

[Greg Shatan]

All:

I have taken the liberty of adding this revised version of Strawman
Proposal 1 to the Strawman Matrix, where it is called Strawman Proposal
1A.  I also added the comments from Stephanie D. and Chuck that were in
that document.  I will leave it to staff [?] to transcribe Kurt and Avri's
comments in the document as posted above....

Greg

On Sun, Nov 16, 2014 at 1:48 PM, <kurt at kjpritz.com> wrote:

> Hello Everyone:
>
> This comment is about separation and separability.
>
> First, I refer to to Bertrand's excellent comment on this issue made on 13
> Nov (included below for reference). I have been thinking about how to
> compliment it, and hope you find the following perspective useful.
>
> Are we more concerned with: (a) providing excellent IANA services, or (b)
> finding the best IANA services operator. If one takes a long-term view, the
> two choices merge into one, but if one takes a short-term view, the two
> choices are different.
>
> Contractors perform best and make substantial investments when they have
> knowledge that the job is essentially theirs. Consider the short-term
> planning scenario where the IANA contract is regularly put out for bid.
>
> *Scenario 1: Finding the best IANA operator*
>
> Say the IANA contract was to be awarded to another entity (even though its
> customers state they are receiving excellent service): a transparent beauty
> contest was held and revealed a more capable player by some measure. The
> successor entity would have a relatively lower expectation that they would
> retain the contract over a long period. This is because the decision to
> move the contract had already been made once (despite excellent
> performance), setting a precedent that it would be moved again.
>
> While I am sure that the successor would strive to succeed, the
> successor’s strategic planners would always take the
> possibility/probability for removal into account. Effort that would go into
> planning for removal would take away from time available to plan for
> success. No successor could ever plan for operating the IANA function in
> the long term because, even if excellent service is provided, a better
> operator could be found.
>
> Also consider the effort that goes into the bidding process. It is
> exhausting and time consuming, taking away from the time devoted to
> improving service. Those that actually run the IANA service are those that
> will be involved with the bid process because they are the one with direct
> knowledge of the operation. The process takes months. During "down time"
> senior managers will not muse on ways to improve the operation, they will
> dwell on the bid, and that circumstances outside their control will have on
> their livelihoods.
>
> Do not think a rebid is a once-in-three-or-five-year occurrence that does
> not occupy the minds of everyone at other times. A continued cycle of
> uncertainty will impact a reliable and predictable IANA function. There
> would be substantial GNSO / ccNSO / community / IANA time devoted to
> designing and executing this process, taking substantially away from the
> other important work everyone has to do.
>
> *Scenario 2: Providing excellent IANA-function services*
>
> Say instead, there is a presumption of renewal predicated on providing
> excellent services. The oversight function would not spend a significant
> part of its time preparing for and executing the bidding process. Instead,
> they can invest their scarce time in more sophisticated monitoring and
> working with the customer base to continually upgrade SLAs in order to
> provide better and better performance.
>
> The IANA-services provider would concentrate strictly on performance
> knowing that its fate was in its own hands. So long as excellence was
> maintained (success as defined by the oversite function and IANA customers)
> the contract could be maintained. Capital investment could be made in the
> knowledge that the payback could be several years down the line. Staffing
> decisions would be made for the long term, bringing in young, talented
> staff with the time to train and provide continuity.
>
> At the end of the day, the efforts of the oversight function, IANA
> customers and the IANA-function services provider would all be focused on
> improving performance. The oversight function would set the SLAs. That is
> the real work of the oversight function - not conducting a transparent
> beauty contest, but in seeing to the collecting and analyzing of
> information so that the definition of success is continually evolved. The
> SLAs *define excellence*.
>
> If the current provider cannot meet the SLAs, then a new provider can be
> found. Tight process controls can be required of the operator to monitor
> performance. (The current operator already has these controls in place.) If
> performance goes outside the specifications then corrective action can be
> immediately taken.
>
> The recommendations in Bertrand's email for identifying breaches,
> escalation and cure times are good and very typically employed.
>
> With all respect (and I mean that) to all the comments and commenters made
> to date, competent operations managers seeking to set up and operate a
> center of excellence, would create an environment focused on continual
> improvement: meeting goals, measuring and then setting new ones. They would
> not find a valued partner, work with them for a pre-defined period and then
> start a new bidding process.
>
> I've pasted Bertrand's previous email below for ease of reference and to
> ensure it is part of the record for next week's meeting.
>
> *A word about separability*
>
> Some of the commentary has been about whether to impose a stricter degree
> of separation between ICANN and the IANA function. I believe the purpose of
> this is to make separation of the two entities easier if a decision were
> made to award the contract to another entity.
>
> I don't believe the discussion is necessary. Contracts come and go. Firms
> both large and small win contracts, organize in a way to perform, and then
> reorganize when the contract ends. ICANN is the same. If the IANA contract
> ends they would reorganize and transfer records as required to a successor.
>
> From the reference point of the CWG, I think it would be extremely
> difficult to ascertain real, net benefits from a specifically defined
> separation. Any benefit would have to be balanced against the greater costs
> and inefficiencies caused by new barriers in the organization. (The money
> comes from registrants.) We should ensure the current requirement for
> appropriate division of policy and operations continues to be met and then
> let the operator run the organization in the way that will best address the
> needs of its customers.
>
> Regards,
>
> Kurt
>
>
> Bertrand's note of 13 Nove ~23:00UTC
>
> 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
>
>
>
>  -------- Original Message --------
> Subject: Re: [CWG-RFP3] Proposed Redline to Strawman 1
> From: Avri Doria <avri at acm.org>
> Date: Sat, November 15, 2014 4:34 pm
> To: cwg-rfp3 at icann.org
>
> Hi,
>
> I added a few comment to Kurt's version.
>
> I basically had difficulty with several aspects of it.
> - the unistakeholder approach
> - the lack of a credible separability mechanism for removing the
> function to another contractor if needed
> - the reliance on changes to the bylaws that could be undone
>
> thanks
>
> avri
>
>
> On 15-Nov-14 14:01, kurt at kjpritz.com wrote:
> > Hi Stephanie:
> >
> > This is very good work and is organized in a way and is in enough detail
> to use
> > as a substantive discussion reference. I've made several comments that
> are
> > intended as constructive and also intended to flesh out the proposal.
> >
> > I made the comments to this proposal rather than the spreadsheet
> containing all
> > four proposals but they would apply to others as well. (I apologize to
> whomever
> > is responsible for taking all these comments starting on Monday to
> collate.)
> >
> > Regards,
> >
> > Kurt
> >
> >
> > -------- Original Message --------
> > Subject: [CWG-RFP3] Proposed Redline to Strawman 1
> > From: "Duchesneau, Stephanie" <Stephanie.Duchesneau at neustar.us
> > <mailto:Stephanie.Duchesneau at neustar.us
> <Stephanie.Duchesneau at neustar.us>>>
> > Date: Fri, November 14, 2014 1:50 pm
> > To: "'Cwg-rfp3 at icann.org <mailto:Cwg-rfp3 at icann.org <Cwg-rfp3 at icann.org>>'"
> <Cwg-rfp3 at icann.org
> > <mailto:Cwg-rfp3 at icann.org <Cwg-rfp3 at icann.org>>>
> >
> > Hi All,
> > Please find attached a redline, suggesting changes and additions to
> Greg’s
> > Strawman 1 model. The strawman reflects input from several gTLD registry
> > representatives to this group. As the redline is fairly heavy, I have
> > incorporated a clean version as well as a version that tracks all changes
> > made to the original version that Greg provided. The draft also includes
> > some comments on a few of the areas that will require further thought and
> > development.
> > I will also work to reflect these recommendations in the Google Docs that
> > compares the strawmen. We encourage members of this group to review this
> > document and provide any feedback on the updated strawman.
> > Best.
> > Stephanie
> > *Stephanie Duchesneau**
> > **Neustar, Inc. / *Public Policy Manager
> > 1775 Pennsylvania Avenue NW, 4^th Floor, Washington, DC 20006
> > *Office:***+1.202.533.2623 *Mobile: *+1.703.731.2040*Fax:
> > *+1.202.533.2623*/*www.neustar.biz <http://www.neustar.biz/>
> >
> --------------------------------------------------------------------------------
> > The information contained in this email message is intended only for the
> use
> > of the recipient(s) named above and may contain confidential and/or
> > privileged information. If you are not the intended recipient you have
> > received this email message in error and any review, dissemination,
> > distribution, or copying of this message is strictly prohibited. If you
> have
> > received this communication in error, please notify us immediately and
> > delete the original message.
> >
> --------------------------------------------------------------------------------
> > _______________________________________________
> > Cwg-rfp3 mailing list
> > Cwg-rfp3 at icann.org <mailto:Cwg-rfp3 at icann.org <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
>
> ------------------------------
> _______________________________________________
> 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/20141117/a59935e2/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 330.gif
Type: image/gif
Size: 96 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/cwg-rfp3/attachments/20141117/a59935e2/330-0001.gif>