<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta name=Title content=""><meta name=Keywords content=""><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@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:"Apple Color Emoji";
panose-1:0 0 0 0 0 0 0 0 0 0;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
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;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:Calibri;}
span.EmailStyle18
{mso-style-type:personal;
font-family:Calibri;
color:windowtext;}
span.EmailStyle19
{mso-style-type:personal;
font-family:Calibri;
color:windowtext;}
span.EmailStyle20
{mso-style-type:personal;
font-family:Calibri;
color:windowtext;}
span.EmailStyle21
{mso-style-type:personal;
font-family:Calibri;
color:windowtext;}
span.EmailStyle22
{mso-style-type:personal;
font-family:Calibri;
color:windowtext;}
span.EmailStyle23
{mso-style-type:personal;
font-family:Calibri;
color:windowtext;}
span.EmailStyle24
{mso-style-type:personal-reply;
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-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style></head><body bgcolor=white lang=EN-US link="#0563C1" vlink="#954F72"><div class=WordSection1><p class=MsoNormal><span style='font-size:10.5pt'>Dear Sub Team Members,<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.5pt'> <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.5pt'>Please see below the action items and discussion notes captured by staff from the meeting on 16 May. <i>These high-level notes are designed to help Work Track Sub Team members navigate through the content of the call and are not a substitute for the recording</i>. Please also see the recording on the meetings page at: <a href="https://community.icann.org/display/NGSPP/Work+Track+1+Meetings">https://community.icann.org/display/NGSPP/Work+Track+1+Meetings</a>.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.5pt'> <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.5pt'>Please note also that the slides referenced below are attached and for ease of reference chat excerpts are included below. Please also see the link to the reference Google doc at: <a href="https://docs.google.com/document/d/1nWljRzRgDQgmSlSxyf7G6f2Dv7XDoD01D30KfWhoHNw/edit">https://docs.google.com/document/d/1nWljRzRgDQgmSlSxyf7G6f2Dv7XDoD01D30KfWhoHNw/edit</a>. <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.5pt'> <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.5pt'>Best,<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.5pt'>Julie<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.5pt'> <o:p></o:p></span></p><div style='border:none;border-bottom:solid windowtext 1.0pt;padding:0in 0in 1.0pt 0in'><p class=MsoNormal><span style='font-size:10.5pt'>Julie Hedlund, Policy Director<o:p></o:p></span></p></div><p class=MsoNormal><span style='font-size:10.5pt'> <o:p></o:p></span></p><p class=MsoNormal><b><span style='font-size:10.5pt'>Actions/Discussion Notes:</span></b><span style='font-size:10.5pt'><o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.5pt'><o:p> </o:p></span></p><p class=MsoNormal><i><span style='font-size:10.5pt'>RSP Program<o:p></o:p></span></i></p><p class=MsoNormal><span style='font-size:10.5pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:10.5pt'>See: https://docs.google.com/document/d/1nWljRzRgDQgmSlSxyf7G6f2Dv7XDoD01D30KfWhoHNw/edit and the attached slides.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.5pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:10.5pt'>-- General Comment: RSP work is going on in several places, such as Registry Stakeholder Group preparing a letter. The PDP WG should take into consideration other work. RySG is scheduled to meet on 17 May.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.5pt'><o:p> </o:p></span></p><p class=MsoNormal><u><span style='font-size:10.5pt'>Document Purpose:<o:p></o:p></span></u></p><p class=MsoNormal><span style='font-size:10.5pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:10.5pt'>-- Include the question, "If not an RSP program are there other remedies that could address the problem?"<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.5pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:10.5pt'>-- Question: Was the repetitive resource intensive technical evaluation and pre-delegation testing an interpretation of the rules -- a form of application rather than the fault with the rules themselves?<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.5pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:10.5pt'>-- Perspective of a swap-out of an RSP discussion in RySG: Process developed by ICANN -- started a discussion on what could be done to improve the process. Realized early on that the process was repetitive, but wasn't anticipated.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.5pt'><o:p> </o:p></span></p><p class=MsoNormal><u><span style='font-size:10.5pt'>1. Security and stability of gTLDs must not be negatively impacted and preferable, improved.<o:p></o:p></span></u></p><p class=MsoNormal><span style='font-size:10.5pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:10.5pt'>-- There has been information released by ICANN that even existing registry providers are struggling. Shouldn't assume that anyone who met the 2012 threshold should be grandfathered or pre-approved.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.5pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:10.5pt'>-- Helpful to understand why ICANN has not pulled the EBERO on those registries that haven't met SLAs. Need to understand the level of the problem that has been identifed.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.5pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:10.5pt'>-- ICANN made a decision on its own that evoking EBERO may make more issues rather than less. The presentation this past weekend was from the OCTO in Madrid -- slides on how many incidents there have been -- 32 of 37 registry operators have had an SLA breach. See the slides at: https://www.icann.org/en/system/files/files/presentation-slam-13may17-en.pdf<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.5pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:10.5pt'>-- This does raise the prospect of setting a minimum threshold as part of a form of accreditation. Recommendations should seek to address the problems. What are the current problems and what is being solved? Is it performance issues? Also linked to item number 5.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.5pt'><o:p> </o:p></span></p><p class=MsoNormal><u><span style='font-size:10.5pt'>5. RSPs must be able to innovate and differentiate themselves<o:p></o:p></span></u></p><p class=MsoNormal><span style='font-size:10.5pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:10.5pt'>-- Speaks to the issue of a race to the bottom.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.5pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:10.5pt'>-- Comment that the base agreement that applies sets the core standard.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.5pt'><o:p> </o:p></span></p><p class=MsoNormal><u><span style='font-size:10.5pt'>2. Efficiency in evaluation and pre-delegation for ICANN, applicants, and RSPs must be improved.<o:p></o:p></span></u></p><p class=MsoNormal><span style='font-size:10.5pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:10.5pt'>-- Re: "Coordination between ICANN and RSPs should be improved" assume this refers to communications? Would ICANN only communicate with RSPs? If RSP is not responding that would have an overall impact on the application and the applicant would be responsible.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.5pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:10.5pt'>-- We are looking at this based on what happened in the past and how can we improve it in the future. RSPs would have an opportunity to become pre-approved prior to the opening of an application window -- something akin to addressing technical questions and pre-delegation testing.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.5pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:10.5pt'>-- In terms of coordination between ICANN and RSPs being improved -- that is happening in the context of the current situation. ICANN had the relationship with the contracted party and the contracted had the relationship with the RSP. No formal mechanism for ICANN to reach out directly to an RSP.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.5pt'><o:p> </o:p></span></p><p class=MsoNormal><u><span style='font-size:10.5pt'>3. Evaluation and pre-delegation testing must be consistent, predictable, and to the extent possible, objective.<o:p></o:p></span></u></p><p class=MsoNormal><span style='font-size:10.5pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:10.5pt'>-- Understanding that there were three different technical advisers with JAS coordination with an attempt to ensure results were consistent.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.5pt'><o:p> </o:p></span></p><p class=MsoNormal><u><span style='font-size:10.5pt'>4. 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 the RSP are not the same entity.<o:p></o:p></span></u></p><p class=MsoNormal><span style='font-size:10.5pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:10.5pt'>-- Add comments about grandfathering registries from 2012.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.5pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:10.5pt'>-- Standards are being discussed in Work Track 4. We don't want to create barriers to entry. Could have existing and new operators be held to a higher standard, but to not create additional barriers to entry that don't exist today. These are two different discussions -- how the process is conducted versus what are the standards (discussed in Work Track 4).<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.5pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:10.5pt'>-- Expressed in the original purpose. Mitigate the duplicative work at the outset. Important that we don't drift into a discussion of standards as these are being discussed in Work Track 4.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.5pt'><o:p> </o:p></span></p><p class=MsoNormal><u><span style='font-size:10.5pt'>8. 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></u></p><p class=MsoNormal><span style='font-size:10.5pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:10.5pt'>-- Conversations about whether it's possible to do this -- the ability of a registry to scale without actually doing it. Whether it's possible to assess whether a registry could manage X number of names, or if there is a distinction between types of TLDs. Premise is that this may not be easy to do in a preparatory stage. There are various elements that could result in an answer to this question.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.5pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:10.5pt'>-- Create some sort of formula or predicted number of names in the future, or methodology to consider that. Expand that idea.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.5pt'><o:p> </o:p></span></p><p class=MsoNormal><u><span style='font-size:10.5pt'>6. An RSP Program should be designed in such a manner so it does not increase ICANN's liability.<o:p></o:p></span></u></p><p class=MsoNormal><span style='font-size:10.5pt'><o:p> </o:p></span></p><p class=MsoNormal><u><span style='font-size:10.5pt'>7. Applicants must have access to a list of Registry Service Providers and a list of the functional areas they have been pre-approved for through the RSP Program.<o:p></o:p></span></u></p><p class=MsoNormal><span style='font-size:10.5pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:10.5pt'>-- What do we mean by "functional areas" is that the different services registries provide? Yes.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.5pt'><o:p> </o:p></span></p><p class=MsoNormal><u><span style='font-size:10.5pt'>9. Applicants must not be required to select a "pre-approved" RSP, but shall be able to either propose providing its own registry services or selection 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></u></p><p class=MsoNormal><span style='font-size:10.5pt'><o:p> </o:p></span></p><p class=MsoNormal><u><span style='font-size:10.5pt'>10. How do we solve the issues of changing from one service provider to another service provider?<o:p></o:p></span></u></p><p class=MsoNormal><span style='font-size:10.5pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:10.5pt'>-- Need to add more to deal with this issue.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.5pt'>-- That is something that the RySG is looking at now and will hopefully be able to provide some guidance. We are working with ICANN to understand how the process can be improved.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.5pt'><o:p> </o:p></span></p><p class=MsoNormal><u><span style='font-size:10.5pt'>11. If an RSP Program is the agreed upon solution, do we have different categories of providers?<o:p></o:p></span></u></p><p class=MsoNormal><span style='font-size:10.5pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:10.5pt'>From the chat:<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.5pt'>Steve Chan: WT2 had asked questions about the EBERO in relation to registrant protections. Here is the response from GDD.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.5pt'>Steve Chan: Section 6 of Specification 10 of the Registry Agreement for new gTLDs provides emergency thresholds for the 5 critical registry functions. Per the Registry Agreement, reaching any one of these thresholds could trigger an EBERO event.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.5pt'>Steve Chan: ICANN monitors registries’ performance of these critical registry functions, and regularly engages with Registry Operators and Registry Service Providers when service outages occur. Not all services outages reach emergency thresholds. If emergency thresholds are reached, ICANN evaluates each individual case and make decisions regarding whether to trigger an EBERO event based on the unique circumstances.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.5pt'>Ashley Roberts: slides are here: https://www.icann.org/en/system/files/files/presentation-slam-13may17-en.pdf<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.5pt'>Jessica Hooper (Verisign): Agree. This could lead to a race to the bottom by setting minimum standards rather than having providers strive for excellence in service. (third bullet point)<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.5pt'>Jeff Neuman: @Jessica - How is setting SLAs in the agreements now any different than setting them in a pre-approval process? I am not sure why this would become a race to the bottom. Can someone clarify that?<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.5pt'>Kurt Pritz: @ Jeff. SLAs are sort of backward looking. Some registries will cut costs until there is a failure. Then it is too late. A pre-approved RSP might have forward-looking criteria that are intended to avoid failures such as statistical process controls and new threat identification and remediation.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.5pt'>Jeff Neuman: @kurt - then this is a problem with existing registries and RSPs already. Its not something that is new. Nor is it something that would be worse with a Pre-approval process.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.5pt'>VANDA SCARTEZINI: @kurt, looks you have a point - agree with you comment<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.5pt'>Jonathan Robinson (Afilias): Pre-approval to meet a minimum standard which seems to be demonstrably inadequate doesn't sound like it's moving in the direction of future security and stability.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.5pt'>VANDA SCARTEZINI: + 1 Jonathan<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.5pt'>Trang Nguyen: @Jeff, there were 3 firms providing technical evaluation.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.5pt'>Donna Austin, Neustar: @Trang, but PDT is done by the same provider?<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.5pt'>Sarah L Verisign: @Jeff I thought the RSP accreditation process was intended to make improvements to what we have today rather haan not make something that already exists without it "worse" - I dont see how that plays into security and stablity. Sorry for beeing late to the meeting I only just joinned.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.5pt'>Trang Nguyen: @Donna, correct, PDT is performed by 1 vendor.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.5pt'>Jeff Neuman: @sarah = Sure, standards can be approved for future as well and apply retroactively to all providers. If we think the standards are too low now (which I am not saying), then we can always through a policy that starts today amend the existing agreements to increase the SLAs for all.....and then apply that to the future applications<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.5pt'>Jeff Neuman: I guess what I am saying is that there should not be additional barriers to entry in the future that do not exist today.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.5pt'>Ashley Roberts: Jonathan, if we think the standards in the current RA are insufficient then that is a different conversation. I believe that topic comes under the remit of WT4 (please correcct me if I'm wrong).. All we are talking about is at what stage and how many times we evaluate whether the RSP meets the required standards (whether they be the current standards or some otherwise agreed standards).<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.5pt'>Cheryl Langdon-Orr (CLO): indeed it does not Jonathan, and an issue to be delt with, no doubt... but it's an issue not a new issue with any proposed pre approval, what is to me an opportunity is to possibly explore and enact mitigation or risk management of heading to a failure point, to be tethered to any such recommendations, and that also could help avoid the same risk in existing standards...<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.5pt'>Cheryl Langdon-Orr (CLO): yes Ashley far more clearly said... sorry </span><span style='font-size:10.5pt;font-family:"Apple Color Emoji"'>🙏</span><span style='font-size:10.5pt'> not fully operational atm<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.5pt'>VANDA SCARTEZINI: Ok got it Ashley. tks<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.5pt'>Kurt Pritz: I think #4 is kind of irrelevant. If an RSP bears costs associated with its certification, those costs have to be passed on to registry operators somehow, either through a one-time charge or some rate. I think it is up to the RSP what they want to charge and then up to their customers if they want to pay that charge<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.5pt'>Jeff Neuman: Kurt - I disagree. This is costs to pay ICANN. Not costs paid by Registry to RSP<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.5pt'>Cheryl Langdon-Orr (CLO): Staff can we make sure we capture this standards issue, chat extracts etc., and send it to our WT4 <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.5pt'>Kurt Pritz: @ Jeff - lemme think about that. Maybe the Proposal should be edited a little.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.5pt'>Alan Greenberg: @Kurt, if testing is done ahead of time, there are no applicants at that point, only RSPs. If an RSP does not end up being used by any applicants, RSP is only entitty to bear costs.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.5pt'> Jeff Neuman:ICANN collected approx $61,667 from each application (paid for by Registry Operators) to pay for evaluations. A substantial portion of that was paid for technical evaluation. That can be eliminated from the Registry Operator's application for the TLD with a pre-approval program<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.5pt'> Kurt Pritz:@Alan - but it passes those costs along at some point. If an RSP makes an initial investment, it has to recoup that investment<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.5pt'> Jeff Neuman:It can then charge RSPs to get "pre-approved" one time.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.5pt'> Jeff Neuman:@Kurt - There is a big difference to pass through an evaluation cost incurred once divided by all its customers, then to be charged that evaluation costs 300 times (in the case of some RSPs) and pass those on to the ROs<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.5pt'> Emily Barabas:@Cheryl, notes, chat transcripts, and recordings for this call will be available here: <a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_display_NGSPP_2017-2D05-2D16-2BNew-2BgTLD-2BSubsequent-2BProcedures-2BPDP-2BWork-2BTrack-2B1&d=DwIFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=QiF-05YzARosRvTYd84AB_UYInlydmFcjNmBM5XgySw&m=KT9yZegfV_4Os1sfXC6WRsBgN6zfUqk7Ifi2Lu7kbhU&s=suOciiSRhnh0225UI1AYC7e8QsdXu402U5rh5CQTXHU&e">https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_display_NGSPP_2017-2D05-2D16-2BNew-2BgTLD-2BSubsequent-2BProcedures-2BPDP-2BWork-2BTrack-2B1&d=DwIFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=QiF-05YzARosRvTYd84AB_UYInlydmFcjNmBM5XgySw&m=KT9yZegfV_4Os1sfXC6WRsBgN6zfUqk7Ifi2Lu7kbhU&s=suOciiSRhnh0225UI1AYC7e8QsdXu402U5rh5CQTXHU&e</a>= . Once all documents are posted, we can share this link with WT4.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.5pt'> Jeff Neuman:For example, if RSP Approval costs $50,000 (hypothetically), then dividing that one time charge amongst 300 registry operators is much different than passing through $50,000 to each of its ROs to be evaluated 300 times.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.5pt'> Cheryl Langdon-Orr (CLO):thanks Emily, I don't want any nexus points overlooked... <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.5pt'> VANDA SCARTEZINI:donna's points in the doc cover up the point<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.5pt'>Kurt Pritz:@Jeff : Won't the market deal with that? <o:p></o:p></span></p></div></body></html>