<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:x="urn:schemas-microsoft-com:office:excel" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Title" content="">
<meta name="Keywords" content="">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Courier New";
panose-1:2 7 3 9 2 2 5 2 4 4;}
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:PMingLiU;
panose-1:2 2 5 0 0 0 0 0 0 0;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:Calibri;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:Calibri;
color:windowtext;}
span.msoIns
{mso-style-type:export-only;
mso-style-name:"";
text-decoration:underline;
color:teal;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:Calibri;}
@page WordSection1
{size:595.0pt 842.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:486678024;
mso-list-template-ids:-1938811616;}
@list l0:level1
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:36.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:72.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:"Courier New";
mso-bidi-font-family:"Times New Roman";}
@list l0:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:108.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:144.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level5
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:180.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:216.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:252.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level8
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:288.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:324.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l1
{mso-list-id:669915733;
mso-list-type:hybrid;
mso-list-template-ids:1073007850 67698703 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l1:level1
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Times New Roman";}
@list l1:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l1:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l1:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l2
{mso-list-id:1828202578;
mso-list-type:hybrid;
mso-list-template-ids:-327894168 881467058 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l2:level1
{mso-level-start-at:4;
mso-level-number-format:bullet;
mso-level-text:-;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Times New Roman";
mso-fareast-font-family:"Times New Roman";}
@list l2:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Courier New";}
@list l2:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Wingdings;}
@list l2:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Symbol;}
@list l2:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Courier New";}
@list l2:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Wingdings;}
@list l2:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Symbol;}
@list l2:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Courier New";}
@list l2:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Wingdings;}
ol
{margin-bottom:0cm;}
ul
{margin-bottom:0cm;}
--></style>
</head>
<body bgcolor="white" lang="EN-US" link="#0563C1" vlink="#954F72">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt">Dear all,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Please see below the action items and discussion notes captured by staff from the meeting on 25 April. <i>These high-level notes are designed to help PDP WG members navigate through the content of the call
and are not meant as a substitute for the recording</i>. Call recording and chat transcript are available on the wiki: https://community.icann.org/display/NGSPP/2017-04-25+New+gTLD+Subsequent+Procedures+PDP+Work+Track+1<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Kind regards,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Emily<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Agenda <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<ol style="margin-top:0cm" start="1" type="1">
<li class="MsoNormal" style="mso-list:l1 level1 lfo1"><span style="font-size:11.0pt">Welcome & Agenda Overview<o:p></o:p></span></li><li class="MsoNormal" style="mso-list:l1 level1 lfo1"><span style="font-size:11.0pt">SOIs<o:p></o:p></span></li><li class="MsoNormal" style="mso-list:l1 level1 lfo1"><span style="font-size:11.0pt">RSP Program<o:p></o:p></span></li><li class="MsoNormal" style="mso-list:l1 level1 lfo1"><span style="font-size:11.0pt">Costing<o:p></o:p></span></li><li class="MsoNormal" style="mso-list:l1 level1 lfo1"><span style="font-size:11.0pt">AOB<o:p></o:p></span></li></ol>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">2. SOIs <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">- No update<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">3. RSP Program<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">- To discuss today: draft requirements or principles that might apply to an RSP program if one was created<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">- Problem statements (From the Google Doc)<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">1. The New gTLD technical evaluation and pre-delegation testing processes were repetitive, resource intensive, unnecessarily expensive and inefficient.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">2. The costs of the technical evaluations were borne by new gTLD applicants (front-end registry operators) as opposed to the actual technical registry service providers.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">3. Applicants were required to select (and in some cases pay for) back-end registry service providers prior to knowing whether those providers would pass the ICANN technical evaluation.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">4. Multiple evaluations of the same registry service provider by different evaluators led to inconsistent evaluation results despite presenting the exact same technical registry solution
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">- Draft Requirements/Principles:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">From the Google Doc: Security and stability of gTLDs must not be negatively impacted, and preferably, improved<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:72.0pt;text-indent:-18.0pt;mso-list:l2 level2 lfo2">
<![if !supportLists]><span style="font-size:11.0pt;font-family:"Courier New""><span style="mso-list:Ignore">o<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span style="font-size:11.0pt">Applicants’ (or applicant’s provider) must be able to demonstrate technical capability equal to or greater than the 2012 round of the New gTLD Program<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:72.0pt;text-indent:-18.0pt;mso-list:l2 level2 lfo2">
<![if !supportLists]><span style="font-size:11.0pt;font-family:"Courier New""><span style="mso-list:Ignore">o<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span style="font-size:11.0pt">The evaluation of a Registry Services Provider should account for the number of TLDs it supports with respect to the five critical services it provides (DNS, SRS, Whois, DNSSEC and Data Escrow)<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:72.0pt;text-indent:-18.0pt;mso-list:l2 level2 lfo2">
<![if !supportLists]><span style="font-size:11.0pt;font-family:"Courier New""><span style="mso-list:Ignore">o<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span style="font-size:11.0pt">Service Levels for Registry Service Providers must be equal to or greater than the 2012 round of the New gTLD Program<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">- In relation to Security and Stability, what is the different to the two bullets above?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">- Some of the technical requirements may not translate into specific service levels. One of the requirements in the technical questions was backup plan or registry failure capabilities that are not necessarily
measured by service levels. There are differences between making sure someone meets service levels and actual technical capabilities.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">- Context for the document: last week we were looking at proposals. It might be helpful to agree on some principles for a program, which might help to evaluate potential solutions.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">From the Google Doc: Efficiency in evaluation and pre-delegation for ICANN, applicants, and RSPs must be improved<o:p></o:p></span></p>
<ul style="margin-top:0cm" type="disc">
<ul style="margin-top:0cm" type="circle">
<li class="MsoNormal" style="mso-list:l0 level2 lfo3"><span style="font-size:11.0pt">Coordination between ICANN and RSPs should be improved<o:p></o:p></span></li><li class="MsoNormal" style="mso-list:l0 level2 lfo3"><span style="font-size:11.0pt">Burden on RSPs and applicants must be reduced<o:p></o:p></span></li><li class="MsoNormal" style="mso-list:l0 level2 lfo3"><span style="font-size:11.0pt">Overall costs for ICANN evaluations and pre-delegation testing should be reduced<o:p></o:p></span></li></ul>
</ul>
<p class="MsoNormal"><span style="font-size:11.0pt">- We need to be specific in these problem statements and principles. Some of these requirements listed in the Google Doc may actually be problem statements. It will take some time to digest this document and
provide feedback.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">- This is an early to draft to be used as a springboard for conversation. There will time to provide feedback and revise.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">From the Google Doc:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">- Evaluation and pre-delegation testing must be consistent, predictable, and to the extent possible, objective<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">- The costs associated with the evaluation and testing of an RSP should be borne by the RSP as opposed to the Applicant where the Applicant and RSP are not the same entity.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">- RSPs must be able to innovate and differentiate themselves<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">- Applicants must not be prohibited from serving as its own Registry Services Provider. <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">- An RSP Program should be designed in such a manner as to not adversely impact ICANN’s liability
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">- Applicants must have access to a list of Registry Service Providers that have been pre-approved through the RSP Program. <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">- Pre-approval of RSPs could be done in such a way as to take into account the capacity of such RSPs, the type of TLDs they support and the services they provide.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">- Applicants must not be required to select a “pre-approved” RSP, but shall be able to either propose providing its own registry services or selecting a new RSP. if that occurs, such new RSP must be evaluated
prior to the ultimate selection of the Applicant to manage one or more specific TLDs.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">From the chat: <o:p></o:p></span></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt">Jeff Neuman</span></b><span style="font-size:11.0pt">: That last bullet is a long way of saying it is a voluntary program :)<o:p></o:p></span></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt">Jim Prendergast</span></b><span style="font-size:11.0pt">: the costs point is something that going to need more discussion. I don't think this group should dictate that. if two parties want to negotiate
it or an RSP wants to offer that, that's a differentiator in the marketplace. buts it's not the role of this group to dictate that.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">- We heard that applicants were not in a position to negotiate with RSPs due to a lack of knowledge. Applicants were not certain that the RSPs they selected would pass the initial evaluation or would have
to go into extended evaluation. The Brand Registry Group said that they would prefer if providers were pre-approved so they would not have to bear the cost of another evaluation. Maybe we should label this item “for discussion.”<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">- On the cost issue, we may be talking about two separate issues. If we assume pre-approval, costs associated with testing should probably be taken on by the RSP. But any relationship that the RSP enters into
with an applicant and a registry operator is separate issue that ICANN does not enter into. There may conflation between the costs associated with these two sets of costs.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">From the chat:<o:p></o:p></span></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt">Jim Prendergast</span></b><span style="font-size:11.0pt">: that probably warrants to clarification to it<o:p></o:p></span></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt">Jeff Neuman</span></b><span style="font-size:11.0pt">: I think that is right Donna. It's not to govern the relationship between the RSP and RO, but rather who pays for the cost of technical evaluation
if there is a preapproval process <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">- We need to be specific in these potential requirements which parties we’re talking about in each bullet.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">From the chat:<o:p></o:p></span></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt">Jeff Neuman</span></b><span style="font-size:11.0pt">: Agree- All, please make suggestions in the google Doc. Let's get the wording to a point where it is clear and we can all agree<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">- There were some additional points in for discussion (from the Google Doc):<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">- FOR DISCUSSION: RSPs [should or should not] be subject to additional contractual terms and conditions with ICANN.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">- FOR DISCUSSION: RSPs that provide back-end registry services for then-currently delegated TLDs should be deemed to be pre-approved for subsequent procedures for similarly situated new TLDs.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">- For the second item above – it is a difficult sentence to understand. Donna’s proposal broke this down into categories. If the last bullet is about grandfathering, can we state that? If so, let’s put that
in the document. <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">From the chat:<br>
<b>Jim Prendergast</b>: I'll elaborate more in google docs on the last point but the fact that icann has had instances of a few operators failing SLAs and having to coach them into compliance makes it difficult to automatically grandfather them. In<br>
<b>Justine Chew</b>: Agree with Donna. Also subject to any changes in technical requirements for operating as RSP.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">- The reason the phrasing may seem a little odd is that we were trying to get at the requirement and not speak to a specific solution.<br>
- It wasn’t just an issue of grandfathering. You may have some existing RSPs that have the capacity to handle what they currently have, but may not be able to handle additional TLDs or additional types of TLDs. If there is a better way to phrase, please suggest
wording. <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">From the chat: <br>
<b>Justine Chew</b>: So we need to address scalability, Jeff?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">- If one of the principles is that evaluation and PDT must be consistent, predicable, and objective you are going to run into this problem for those who go through any future testing. It’s very difficult to
assess the ability of the RSP to scale based on assessment of technical capabilities. The scalability question has to be answered after the fact. Perhaps another test needs to be done to address this point. To the extent we can identify what processes are
required to approve and RSP vs. the scalability question, that would be helpful.<br>
- As we’re evolving, we are starting to get different types of TLDs. While conceiving of a process that an RSP goes through, that can actually be done with scalability in mind. We haven’t thought through the process that needs to happen. The problem with grandfathering
is that those providers would not be subject the same processes as other providers in the new round/procedures. For gTLD applicants, they don’t have an equal view of all RSPs they are considering in terms of predictability. Perhaps the issue of grandfathering
should be considered on its own. <o:p></o:p></span></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt">Donna Austin, Neustar</span></b><span style="font-size:11.0pt">: @ Avri, as I see it and how i read this document, we are really only discussing a pre-approval process and if that doesn't change substantively
from what was undertaken in 2012 i don't see why 2012 RSPs could not be grandfathered in.<br>
<b>Jeff Neuman:</b> Perhaps the grandfathering applies to what is the same with perhaps some lesser amount of evaluation on only those new requirements (if any)<br>
<b>avri doria</b>: wee are trng to eliminate multipel testings, i do not see the requiremnt to eliminate all testing for some.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">4. Costing<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">- (Reading from the slide) – review of previous discussion on costing<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">- holistic costing models: basis for determining model – rounds, applications, others
</span><span style="font-size:11.0pt;font-family:PMingLiU"><br>
</span><span style="font-size:11.0pt">- possible cost floor: floor is a minimum price, but if’s below a threshold change the costing model
</span><span style="font-size:11.0pt;font-family:PMingLiU"><br>
</span><span style="font-size:11.0pt">- what should be done with excess costs</span><span style="font-size:11.0pt;font-family:PMingLiU"><br>
</span><span style="font-size:11.0pt">- still to flesh out – fees by application type</span><span style="font-size:11.0pt;font-family:PMingLiU"><br>
</span><span style="font-size:11.0pt">- If we have something that looks like a rolling process and a policy that the system is self-funding, and a principle that costing be revisited periodically, any excess funds would feed back into the system, the problem
could take care of itself.<br>
- Question – how would we work out the allocation to different systems. <br>
- Jim Prendergast: did the community determine the pricing in the previous rounds or was that dictated by ICANN?<br>
Jeff Neuman: @Jim - Dictated by ICANN<br>
Jeff Neuman: Based on some vague formulas and SWAGs on expected volumes<br>
Jim Prendergast: that's what I thought.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">- There are a number of dependencies on the costing issue. One thing we haven’t discussed is the CDAR report. One of the recommendations is that you maintain the controlled rate of delegation, similar to the
2012 round. The 2012 round is based on an arbitrary number. If that rate of delegation stays in place for no more than a 12 month period, how does that impact costing? That puts pressure on who gets delegation first and may also drive the costs up. This is
difficult because it’s based on so many other conversations we haven’t had yet. <o:p>
</o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">From the chat:<br>
<b>Jeff Neuman</b>: Applicant support programs need to get funding from somewhere<br>
<b>Jeff Neuman</b>: (if we have them)<br>
<b>Cheryl Langdon-Orr (CLO)</b>: indeed they do!!!<br>
<b>Cheryl Langdon-Orr (CLO)</b>: and we should IMO<br>
<b>avri doria</b>: Jeff the cost of those should be calcualted into the total cost.<br>
<b>Jeff Neuman</b>: WE do need to revisit that report. If as people believe there will be 25000 applications, then under the current rates, it would take 25 years to complete delegating those TLDs<br>
<b>Jeff Neuman</b>: So we need to push those boudaries of that recommendation<br>
<b>Jim Prendergast</b>: 25 years....wow<br>
<b>Jeff Neuman</b>: That report found no issues with the current rate of delegations and said it could handle much more<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal" style="text-autospace:none"><b><span style="font-size:11.0pt">Emily Barabas
</span></b><span style="font-size:11.0pt">| Policy Specialist<o:p></o:p></span></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt">ICANN</span></b><span style="font-size:11.0pt"> | Internet Corporation for Assigned Names and Numbers<o:p></o:p></span></p>
<p class="MsoNormal" style="text-autospace:none"><span style="font-size:11.0pt">Email: emily.barabas@icann.org | Phone: +31 (0)6 84507976<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</body>
</html>