<html><head></head><body><div dir="auto">Hello Anne, <br><br></div>
<div dir="auto">After execution or RA there is no applicant, only a Registry. So whatever applicant does in the application phase stays in 'childhood', and a new Registry is a subject to all GNSO policies, including RSEP.<br><br></div>
<div dir="auto">To say more, we might refer as to 'former applicant', but AGB has no power over Registries. <br><br></div>
<div dir="auto"><!-- tmjah_g_1299s -->Maxim Alzoba<!-- tmjah_g_1299e --></div>
<div class="gmail_quote" >On 6 Sep 2019, at 01:24, "Aikman-Scalese, Anne" <<a href="mailto:aaikman@lrrc.com" target="_blank">aaikman@lrrc.com</a>> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre class="blue">Thanks Rubens. I was also unable to attend last night's call but will listen later on.. Regarding the moment of disclosing registry services, the disagreement in Work Track 4 was over whether the 2012 AGB application form (Questions 18 Purposes and 23 Services taken together) required disclosure of all services the applicant intended to render. I believe a clear reading of the application says that ALL services intended to be rendered would need to be disclosed for public comment and evaluation. (Disclosing all services ultimately helps evaluate the purpose of the TLD.)<br><br>I believe that the notion that an applicant can "skate through" by mentioning only the pre-approved services (and getting a faster approval for delegation by doing so) and then waiting to apply for the RSEP process later actually DECREASES transparency in the evaluation process and lessens the opportunity for public comment. In the trade-off between (1) transparency for public comment purposes and (2) keeping business plans confidential at the time of application, I would favor transparency. (I know RSEP may, in some cases, be subject to public comment but I don't think the public is really watching at that time.)<br><br>Others may have different opinions, but to my mind, it's clear that Question 23 of the 2012 Application calls for the applicant to list all proposed registry services and that is the fallback.<br><br>Thank you,<br>Anne<br><br>-----Original Message-----<br>From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces@icann.org> On Behalf Of Rubens Kuhl<br>Sent: Wednesday, September 4, 2019 12:57 PM<br>To: gnso-newgtld-wg@icann.org<br>Subject: [Gnso-newgtld-wg] Notes on Registry Services<br><br>[EXTERNAL]<br><br><br>Since I'm not sure I'll be able to join the call in a few hours that will discuss registry services, I will post here some WT4 and RA context regarding some of the comments:<br><br>- GPML<br>When this topic was being discussed in WT4, the then-current draft of what currently is the Fast-Track RSEP process (<a href="https://www.icann.org/resources/pages/fast-track-rsep-process-authorization-language-2019-06-14-en">https://www.icann.org/resources/pages/fast-track-rsep-process-authorization-language-2019-06-14-en</a>) included protected marks list services, but not mentioned as GPML. I used GPML as a token to represent that in order to avoid personalising to one specific registry that is known for providing such PML services... if that list was to be updated, it would read (BTAPPA, Registration Validation per Applicable Law, Registry Lock, IDN Languages) instead of (IDN Languages, GPML, BTAPPA), so one decision for the WG is whether to update the list or to remove the list altogether, since the idea is to reference the Fast-Track process anyways.<br>(This also covers a couple suggestions to add Registration Validation to that list)<br><br>- Pre-approved services<br>All 2012 registry agreements include a set of pre-approved services that are basic to registry operation, like DNS publication, accepting registrations etc.; so, the discussion is whether this list can be increased, not if such a list could exist. It already exists.<br><br>- Disclosure of new services<br>In 2012, there was no blocking in the registry agreement to use RSEPs later during the life of the TLD, and the RSEP site contains a number of RSEPs that were approved and incorporated new services into the registry agreements. Since revising the RSEP policy is outside of the WG purview, no SubPro policy can have any effect on that freedom of innovation. We can write anything someone wants in the SubPro policy and that won't change.<br><br>- ICANN Org interpretation<br>It seems ICANN Org misinterpreted the idea of pre-approved services; pre-approved services means that no registry service evaluation will be made for them, and any evaluation of those services could only happen in other contexts like Technical/Operational evaluation. It's not just a change of label for the process, it's not evaluating those services at all from a registry services perspective, but indeed possibly considering them in other angles of the evaluation.<br><br>- Overload of RSEP acronyms<br>Because RSEP is used to imply Registry Services Evaluation Procedure, Evaluation Process or Evaluation Policy depending on reference, the term is very loaded to the point that some comments said RSEP Policy shouldn't be changed. The use of RSEP in the WT4 output refers to the process, not to the policy that is used to evaluate new registry services after a TLD is contracted with ICANN.<br><br>- Moment of registry service evaluation<br>What's currently in the draft was an attempt to have the more transparency and freedom of innovation as possible in the application, by allowing services that would only be applied after contract signing to be described by the applicant. Taking that out only causes less transparency; the more information is published, the more something can trigger application comments or objections.<br><br><br><br><br>Rubens<br><br><br><br><br><br><br><br><hr><br>Gnso-newgtld-wg mailing list<br>Gnso-newgtld-wg@icann.org<br><a href="https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg">https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg</a><br><hr><br>By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (<a href="https://www.icann.org/privacy/policy">https://www.icann.org/privacy/policy</a>) and the website Terms of Service (<a href="https://www.icann.org/privacy/tos">https://www.icann.org/privacy/tos</a>). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.<br><br><br><hr><br><br>This message and any attachments are intended only for the use of the individual or entity to which they are addressed. If the reader of this message or an attachment is not the intended recipient or the employee or agent responsible for delivering the message or attachment to the intended recipient you are hereby notified that any dissemination, distribution or copying of this message or any attachment is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the sender. The information transmitted in this message and any attachments may be privileged, is intended only for the personal and confidential use of the intended recipients, and is covered by the Electronic Communications Privacy Act, 18 U.S.C. ยง2510-2521.<br><hr><br>Gnso-newgtld-wg mailing list<br>Gnso-newgtld-wg@icann.org<br><a href="https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg">https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg</a><br><hr><br>By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (<a href="https://www.icann.org/privacy/policy">https://www.icann.org/privacy/policy</a>) and the website Terms of Service (<a href="https://www.icann.org/privacy/tos">https://www.icann.org/privacy/tos</a>). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.</pre></blockquote></div></body></html>