[Gnso-newgtld-wg] Notes on Registry Services
jeff.neuman at comlaude.com
Thu Sep 5 02:49:11 UTC 2019
Thanks Rubens. We will be sure to cover all of this during the call in a few minutes.
For those that cannot follow the detail in Rubens note, part of the call tonight will be to educate everyone on what all of this means so we can look at this area from the same vantage point. Thanks!
Senior Vice President
Com Laude | Valideus
E: jeff.neuman at comlaude.com
From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces at icann.org> On Behalf Of Rubens Kuhl
Sent: Wednesday, September 4, 2019 3:57 PM
To: gnso-newgtld-wg at icann.org
Subject: [Gnso-newgtld-wg] Notes on Registry Services
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:
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.
Gnso-newgtld-wg mailing list
Gnso-newgtld-wg at icann.org
The contents of this email and any attachments are confidential to the intended recipient. They may not be disclosed, used by or copied in any way by anyone other than the intended recipient. If you have received this message in error, please return it to the sender (deleting the body of the email and attachments in your reply) and immediately and permanently delete it. Please note that the Com Laude Group does not accept any responsibility for viruses and it is your responsibility to scan or otherwise check this email and any attachments. The Com Laude Group does not accept liability for statements which are clearly the sender's own and not made on behalf of the group or one of its member entities. The Com Laude Group includes Nom-IQ Limited t/a Com Laude, a company registered in England and Wales with company number 5047655 and registered office at 28-30 Little Russell Street, London, WC1A 2HN England; Valideus Limited, a company registered in England and Wales with company number 06181291 and registered office at 28-30 Little Russell Street, London, WC1A 2HN England; Demys Limited, a company registered in Scotland with company number SC197176, having its registered office at 33 Melville Street, Edinburgh, Lothian, EH3 7JF Scotland; Consonum, Inc. dba Com Laude USA and Valideus USA, headquartered at 1751 Pinnacle Drive, Suite 600, McLean, VA 22102, USA; Com Laude (Japan) Corporation, a company registered in Japan having its registered office at Suite 319,1-3-21 Shinkawa, Chuo-ku, Tokyo, 104-0033, Japan. For further information see www.comlaude.com<https://comlaude.com>
More information about the Gnso-newgtld-wg