[Gnso-newgtld-wg] Notes on Registry Services

Fri Sep 6 11:55:13 UTC 2019

Hello Anne, 

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.

To say more, we might refer as to 'former applicant', but AGB has no power over Registries. 

⁣Maxim Alzoba

On 6 Sep 2019, 01:24, at 01:24, "Aikman-Scalese, Anne" <aaikman at lrrc.com> wrote:
>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.)
>
>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.)
>
>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.
>
>Thank you,
>Anne
>
>-----Original Message-----
>From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces at icann.org> On Behalf Of
>Rubens Kuhl
>Sent: Wednesday, September 4, 2019 12:57 PM
>To: gnso-newgtld-wg at icann.org
>Subject: [Gnso-newgtld-wg] Notes on Registry Services
>
>[EXTERNAL]
>
>
>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:
>
>- GPML
>When this topic was being discussed in WT4, the then-current draft of
>what currently is the Fast-Track RSEP process
>(https://www.icann.org/resources/pages/fast-track-rsep-process-authorization-language-2019-06-14-en)
>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.
>(This also covers a couple suggestions to add Registration Validation
>to that list)
>
>- Pre-approved services
>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.
>
>- Disclosure of new services
>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.
>
>- ICANN Org interpretation
>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.
>
>- Overload of RSEP acronyms
>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.
>
>- Moment of registry service evaluation
>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.
>
>
>
>
>Rubens
>
>
>
>
>
>
>
>_______________________________________________
>Gnso-newgtld-wg mailing list
>Gnso-newgtld-wg at icann.org
>https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg
>_______________________________________________
>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
>(https://www.icann.org/privacy/policy) and the website Terms of Service
>(https://www.icann.org/privacy/tos). 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.
>
>
>________________________________
>
>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.
>_______________________________________________
>Gnso-newgtld-wg mailing list
>Gnso-newgtld-wg at icann.org
>https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg
>_______________________________________________
>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
>(https://www.icann.org/privacy/policy) and the website Terms of Service
>(https://www.icann.org/privacy/tos). 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg/attachments/20190906/99dc2f5f/attachment.html>