<div dir="ltr">All:<div><br></div><div>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 <img src="cid:330@goomoji.gmail" goomoji="330" style="margin: 0px 0.2ex; vertical-align: middle;"> to transcribe Kurt and Avri's comments in the document as posted above....</div><div><br></div><div>Greg</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Nov 16, 2014 at 1:48 PM, <span dir="ltr"><<a href="mailto:kurt@kjpritz.com" target="_blank">kurt@kjpritz.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><span style="font-family:Verdana;color:#000;font-size:10pt"><div><div>Hello Everyone:</div><div><br></div><div>This comment is about separation and separability. </div><div><br></div><div>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. </div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div><b>Scenario 1: Finding the best IANA operator</b></div><div><b><br></b></div><div>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.</div><div><br></div><div>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. </div><div><br></div><div>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. </div><div><br></div><div>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.</div><div><br></div><div><b>Scenario 2: Providing excellent IANA-function services</b></div><div><b><br></b></div><div>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. </div><div><br></div><div>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.</div><div><br></div><div>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 <b>define excellence</b>. </div><div><br></div><div>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. </div><div><br></div><div>The recommendations in Bertrand's email for identifying breaches, escalation and cure times are good and very typically employed.</div><div><br></div><div>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. </div><div><br></div><div>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.</div><div><br></div><div><b>A word about separability</b></div><div><br></div><div>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. </div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Regards,</div><div><br></div><div>Kurt</div><div><br></div><div><br></div></div><div><span style="font-weight:bold">Bertrand's note of 13 Nove ~23:00UTC</span></div><div><span style="font-weight:bold"><br></span></div><div><span>Hi Seun and Guru,</span></div><div><br></div><div>I think you are talking about two different elements that overlap but are distinct:</div><div><ul><li>the notion that the contract(s) should be <span style="font-weight:bold">breakable and transferable</span> 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. <br></li><li>the notion that the contract(s) could have a <span style="font-weight:bold">set duration</span>, 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. <br></li></ul></div><div>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. <br></div><div><br></div><div><span style="font-weight:bold">Two variables to define options for a "normal regime"</span></div><div><br></div><div>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 <span style="font-weight:bold">two complementary variables</span>:</div><div><br></div><div>a) On one hand, the basic <span style="font-weight:bold">duration of the contract</span>(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. </div><div><br></div><div>b) On the other hand, <span style="font-weight:bold">what happens at the expiration of each period</span>. I see here three basic options: </div><div><ol><li>systematic and compulsory full rebidding each time (as per Milton),<br></li><li>explicit decision each time to either continue with the same operator for another period or do a rebidding <br></li><li>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) <br></li></ol></div><div><span style="font-weight:bold">Combinations</span></div><div><span style="font-weight:bold"><br></span></div><div><div>These two variables can be combined in many ways.</div><div><br></div><div>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. </div><div><br></div><div>Likewise, the current regime for gTLDs is closer to b)3: presumption of renewal unless very strict criteria justify otherwise.</div></div><div><br></div><div>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. </div><div><br></div><div>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. </div><div><br></div><div>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. </div><div><br></div><div>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. </div><div><span style="font-weight:bold"><br></span></div><div><span style="font-weight:bold">Open rebidding as principle or as signal?</span></div><div><br></div><div>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. </div><div><br></div><div>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. </div><div><br></div><div>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. </div><div><br></div><div>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.</div><div><br></div><div><span style="font-weight:bold">The overall objective</span></div><div><br></div><div>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. </div><div><br></div><div>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. </div><div><br></div><div>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. </div><div><br></div><div>Apologies for the long post. Certainly needs refinement. But I hope it helps frame the discussion further. Just my own perspective. </div><div><br></div><div>Best</div><div><br></div><div>Bertrand</div><div></div><div><br></div><div><br></div><div><br></div>
<blockquote style="border-left:2px solid blue;margin-left:8px;padding-left:8px;font-size:10pt;color:black;font-family:verdana">
<div><div><div class="h5">
-------- Original Message --------<br>
Subject: Re: [CWG-RFP3] Proposed Redline to Strawman 1<br>
From: Avri Doria <<a href="mailto:avri@acm.org" target="_blank">avri@acm.org</a>><br>
Date: Sat, November 15, 2014 4:34 pm<br>
To: <a href="mailto:cwg-rfp3@icann.org" target="_blank">cwg-rfp3@icann.org</a><br>
<br>
Hi,<br>
<br>
I added a few comment to Kurt's version.<br>
<br>
I basically had difficulty with several aspects of it.<br>
- the unistakeholder approach<br>
- the lack of a credible separability mechanism for removing the<br>
function to another contractor if needed<br>
- the reliance on changes to the bylaws that could be undone<br>
<br>
thanks<br>
<br>
avri<br>
<br>
<br>
On 15-Nov-14 14:01, <a href="mailto:kurt@kjpritz.com" target="_blank">kurt@kjpritz.com</a> wrote:<br>
> Hi Stephanie:<br>
><br>
> This is very good work and is organized in a way and is in enough detail to use <br>
> as a substantive discussion reference. I've made several comments that are <br>
> intended as constructive and also intended to flesh out the proposal.<br>
><br>
> I made the comments to this proposal rather than the spreadsheet containing all <br>
> four proposals but they would apply to others as well. (I apologize to whomever <br>
> is responsible for taking all these comments starting on Monday to collate.)<br>
><br>
> Regards,<br>
><br>
> Kurt<br>
><br>
><br>
> -------- Original Message --------<br>
> Subject: [CWG-RFP3] Proposed Redline to Strawman 1<br>
> From: "Duchesneau, Stephanie" <<a href="mailto:Stephanie.Duchesneau@neustar.us" target="_blank">Stephanie.Duchesneau@neustar.us</a><br>
> <<a href="mailto:Stephanie.Duchesneau@neustar.us" target="_blank">mailto:Stephanie.Duchesneau@neustar.us</a>>><br>
> Date: Fri, November 14, 2014 1:50 pm<br>
> To: "'<a href="mailto:Cwg-rfp3@icann.org" target="_blank">Cwg-rfp3@icann.org</a> <<a href="mailto:Cwg-rfp3@icann.org" target="_blank">mailto:Cwg-rfp3@icann.org</a>>'" <<a href="mailto:Cwg-rfp3@icann.org" target="_blank">Cwg-rfp3@icann.org</a><br>
> <<a href="mailto:Cwg-rfp3@icann.org" target="_blank">mailto:Cwg-rfp3@icann.org</a>>><br>
><br>
> Hi All,<br>
> Please find attached a redline, suggesting changes and additions to Greg’s<br>
> Strawman 1 model. The strawman reflects input from several gTLD registry<br>
> representatives to this group. As the redline is fairly heavy, I have<br>
> incorporated a clean version as well as a version that tracks all changes<br>
> made to the original version that Greg provided. The draft also includes<br>
> some comments on a few of the areas that will require further thought and<br>
> development.<br>
> I will also work to reflect these recommendations in the Google Docs that<br>
> compares the strawmen. We encourage members of this group to review this<br>
> document and provide any feedback on the updated strawman.<br>
> Best.<br>
> Stephanie<br>
> *Stephanie Duchesneau**<br>
> **Neustar, Inc. / *Public Policy Manager<br>
> 1775 Pennsylvania Avenue NW, 4^th Floor, Washington, DC 20006<br>
> *Office:***<a href="tel:%2B1.202.533.2623" value="+12025332623" target="_blank">+1.202.533.2623</a> *Mobile: *<a href="tel:%2B1.703.731.2040" value="+17037312040" target="_blank">+1.703.731.2040</a>*Fax:<br>
> *<a href="tel:%2B1.202.533.2623" value="+12025332623" target="_blank">+1.202.533.2623</a>*/*<a href="http://www.neustar.biz" target="_blank">www.neustar.biz</a> <http://<a href="http://www.neustar.biz" target="_blank">www.neustar.biz</a>/><br>
> --------------------------------------------------------------------------------<br>
> The information contained in this email message is intended only for the use<br>
> of the recipient(s) named above and may contain confidential and/or<br>
> privileged information. If you are not the intended recipient you have<br>
> received this email message in error and any review, dissemination,<br>
> distribution, or copying of this message is strictly prohibited. If you have<br>
> received this communication in error, please notify us immediately and<br>
> delete the original message.<br>
> --------------------------------------------------------------------------------<br>
> _______________________________________________<br>
> Cwg-rfp3 mailing list<br>
> <a href="mailto:Cwg-rfp3@icann.org" target="_blank">Cwg-rfp3@icann.org</a> <<a href="mailto:Cwg-rfp3@icann.org" target="_blank">mailto:Cwg-rfp3@icann.org</a>><br>
> <a href="https://mm.icann.org/mailman/listinfo/cwg-rfp3" target="_blank">https://mm.icann.org/mailman/listinfo/cwg-rfp3</a><br>
><br>
><br>
> _______________________________________________<br>
> Cwg-rfp3 mailing list<br>
> <a href="mailto:Cwg-rfp3@icann.org" target="_blank">Cwg-rfp3@icann.org</a><br>
> <a href="https://mm.icann.org/mailman/listinfo/cwg-rfp3" target="_blank">https://mm.icann.org/mailman/listinfo/cwg-rfp3</a><br>
<br>
</div></div><hr><span class="">_______________________________________________<br>
Cwg-rfp3 mailing list<br>
<a href="mailto:Cwg-rfp3@icann.org" target="_blank">Cwg-rfp3@icann.org</a><br>
<a href="https://mm.icann.org/mailman/listinfo/cwg-rfp3" target="_blank">https://mm.icann.org/mailman/listinfo/cwg-rfp3</a><br>
</span></div>
</blockquote></span></div>
<br>_______________________________________________<br>
Cwg-rfp3 mailing list<br>
<a href="mailto:Cwg-rfp3@icann.org">Cwg-rfp3@icann.org</a><br>
<a href="https://mm.icann.org/mailman/listinfo/cwg-rfp3" target="_blank">https://mm.icann.org/mailman/listinfo/cwg-rfp3</a><br>
<br></blockquote></div><br></div>