<html><body><span style="font-family:Verdana; color:#000; font-size:10pt;"><div><div style="">Hello Everyone:</div><div style=""><br style=""></div><div style="">This comment is about separation and separability. </div><div style=""><br style=""></div><div style="">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 style=""><br style=""></div><div style="">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 style=""><br style=""></div><div style="">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 style=""><br style=""></div><div style=""><b>Scenario 1: Finding the best IANA operator</b></div><div style=""><b><br></b></div><div style="">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 style=""><br style=""></div><div style="">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 style=""><br style=""></div><div style="">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 style=""><br style=""></div><div style="">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 style=""><br style=""></div><div style=""><b>Scenario 2: Providing excellent IANA-function services</b></div><div style=""><b><br></b></div><div style="">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 style=""><br style=""></div><div style="">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 style=""><br style=""></div><div style="">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 style=""><br style=""></div><div style="">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 style=""><br style=""></div><div style="">The recommendations in Bertrand's email for identifying breaches, escalation and cure times are good and very typically employed.</div><div style=""><br style=""></div><div style="">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 style=""><br style=""></div><div style="">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 style=""><br style=""></div><div style=""><b>A word about separability</b></div><div style=""><br style=""></div><div style="">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 style=""><br style=""></div><div style="">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 style=""><br style=""></div><div style="">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 style=""><br style=""></div><div style="">Regards,</div><div style=""><br style=""></div><div style="">Kurt</div><div style=""><br></div><div style=""><br style=""></div></div><div><span mce_name="strong" mce_style="font-weight: bold;" style="font-weight: bold; " class="Apple-style-span" mce_fixed="1">Bertrand's note of 13 Nove ~23:00UTC</span></div><div><span mce_name="strong" mce_style="font-weight: bold;" style="font-weight: bold;" class="Apple-style-span" mce_fixed="1"><br></span></div><div><span style="">Hi Seun and Guru,</span></div><div style=""><br style=""></div><div style="">I think you are talking about two different elements that overlap but are distinct:</div><div style=""><ul style=""><li style="">the notion that the contract(s) should be <span mce_name="strong" mce_style="font-weight: bold;" style="font-weight: bold;" class="Apple-style-span" mce_fixed="1">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 style=""></li><li style="">the notion that the contract(s) could have a <span mce_name="strong" mce_style="font-weight: bold;" style="font-weight: bold;" class="Apple-style-span" mce_fixed="1">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 style=""></li></ul></div><div style="">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 style=""></div><div style=""><br style=""></div><div style=""><span mce_name="strong" mce_style="font-weight: bold;" style="font-weight: bold;" class="Apple-style-span" mce_fixed="1">Two variables to define options for a "normal regime"</span></div><div style=""><br style=""></div><div style="">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 mce_name="strong" mce_style="font-weight: bold;" style="font-weight: bold;" class="Apple-style-span" mce_fixed="1">two complementary variables</span>:</div><div style=""><br style=""></div><div style="">a) On one hand, the basic <span mce_name="strong" mce_style="font-weight: bold;" style="font-weight: bold;" class="Apple-style-span" mce_fixed="1">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 style=""><br style=""></div><div style="">b) On the other hand, <span mce_name="strong" mce_style="font-weight: bold;" style="font-weight: bold;" class="Apple-style-span" mce_fixed="1">what happens at the expiration of each period</span>. I see here three basic options: </div><div style=""><ol style=""><li style="">systematic and compulsory full rebidding each time (as per Milton),<br style=""></li><li style="">explicit decision each time to either continue with the same operator for another period or do a rebidding <br style=""></li><li style="">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 style=""></li></ol></div><div style=""><span mce_name="strong" mce_style="font-weight: bold;" style="font-weight: bold;" class="Apple-style-span" mce_fixed="1">Combinations</span></div><div style=""><span mce_name="strong" mce_style="font-weight: bold;" style="font-weight: bold;" class="Apple-style-span" mce_fixed="1"><br style=""></span></div><div style=""><div style="">These two variables can be combined in many ways.</div><div style=""><br style=""></div><div style="">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 style=""><br style=""></div><div style="">Likewise, the current regime for gTLDs is closer to b)3: presumption of renewal unless very strict criteria justify otherwise.</div></div><div style=""><br style=""></div><div style="">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 style=""><br style=""></div><div style="">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 style=""><br style=""></div><div style="">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 style=""><br style=""></div><div style="">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 style=""><span mce_name="strong" mce_style="font-weight: bold;" style="font-weight: bold;" class="Apple-style-span" mce_fixed="1"><br style=""></span></div><div style=""><span mce_name="strong" mce_style="font-weight: bold;" style="font-weight: bold;" class="Apple-style-span" mce_fixed="1">Open rebidding as principle or as signal?</span></div><div style=""><br style=""></div><div style="">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 style=""><br style=""></div><div style="">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 style=""><br style=""></div><div style="">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 style=""><br style=""></div><div style="">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 style=""><br style=""></div><div style=""><span mce_name="strong" mce_style="font-weight: bold;" style="font-weight: bold;" class="Apple-style-span" mce_fixed="1">The overall objective</span></div><div style=""><br style=""></div><div style="">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 style=""><br style=""></div><div style="">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 style=""><br style=""></div><div style="">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 style=""><br style=""></div><div style="">Apologies for the long post. Certainly needs refinement. But I hope it helps frame the discussion further. Just my own perspective. </div><div style=""><br style=""></div><div style="">Best</div><div style=""><br style=""></div><div style="">Bertrand</div><div></div><div><br></div><div><br></div><div><br></div>
<blockquote id="replyBlockquote" webmail="1" style="border-left: 2px solid blue; margin-left: 8px; padding-left: 8px; font-size:10pt; color:black; font-family:verdana;" mce_style="border-left: 2px solid blue; margin-left: 8px; padding-left: 8px; font-size:10pt; color:black; font-family:verdana;">
<div id="wmQuoteWrapper">
-------- Original Message --------<br>
Subject: Re: [CWG-RFP3] Proposed Redline to Strawman 1<br>
From: Avri Doria <<a href="mailto:avri@acm.org">avri@acm.org</a>><br>
Date: Sat, November 15, 2014 4:34 pm<br>
To: <a href="mailto:cwg-rfp3@icann.org">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">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">Stephanie.Duchesneau@neustar.us</a><br>
> <<a href="mailto:Stephanie.Duchesneau@neustar.us">mailto:Stephanie.Duchesneau@neustar.us</a>>><br>
> Date: Fri, November 14, 2014 1:50 pm<br>
> To: "'<a href="mailto:Cwg-rfp3@icann.org">Cwg-rfp3@icann.org</a> <<a href="mailto:Cwg-rfp3@icann.org">mailto:Cwg-rfp3@icann.org</a>>'" <<a href="mailto:Cwg-rfp3@icann.org">Cwg-rfp3@icann.org</a><br>
> <<a href="mailto:Cwg-rfp3@icann.org">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:***+1.202.533.2623 *Mobile: *+1.703.731.2040*Fax:<br>
> *+1.202.533.2623*/*<a href="http://www.neustar.biz" mce_href="http://www.neustar.biz">www.neustar.biz</a> <http://<a href="http://www.neustar.biz" mce_href="http://www.neustar.biz">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">Cwg-rfp3@icann.org</a> <<a href="mailto:Cwg-rfp3@icann.org">mailto:Cwg-rfp3@icann.org</a>><br>
> <a href="https://mm.icann.org/mailman/listinfo/cwg-rfp3" mce_href="https://mm.icann.org/mailman/listinfo/cwg-rfp3">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">Cwg-rfp3@icann.org</a><br>
> <a href="https://mm.icann.org/mailman/listinfo/cwg-rfp3" mce_href="https://mm.icann.org/mailman/listinfo/cwg-rfp3">https://mm.icann.org/mailman/listinfo/cwg-rfp3</a><br>
<br>
<hr>_______________________________________________<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">https://mm.icann.org/mailman/listinfo/cwg-rfp3</a><br>
</div>
</blockquote></span></body></html>