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: - 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-...) 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
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! Jeff Neuman Senior Vice President Com Laude | Valideus D: +1.703.635.7514 E: jeff.neuman@comlaude.com -----Original Message----- From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces@icann.org> On Behalf Of Rubens Kuhl Sent: Wednesday, September 4, 2019 3:57 PM To: gnso-newgtld-wg@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: - 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-...) 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@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. ________________________________ 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>
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@icann.org> On Behalf Of Rubens Kuhl Sent: Wednesday, September 4, 2019 12:57 PM To: gnso-newgtld-wg@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-...) 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@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.
Em 5 de set de 2019, à(s) 15:23:000, Aikman-Scalese, Anne <AAikman@lrrc.com> escreveu:
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.)
Anne, For that to be true, 2012 applications would have to be blocked from using RSEP after being delegated. As you know, those registries have used RSEP many many times since their delegation.
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.
That's one of the reasons for allowing applicants to do both: disclose the intended service at application time, but have it evaluated after contracting. This gets both transparency and expediency without making that choice.
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.)
RSEP is subject in all cases to public scrutiny, as described in the RSEP page. A capital P, capital C public comment is required only when the service is referred to an RSTEP panel, but all proposed services can receive comments.
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.
That opinion doesn't hold to reality... so unless ICANN disavows all RSEPs approved for 2012-round TLDs, the overall set of AGB, RA incorporated in AGB, Consensus Policies included by reference in RA and the RSEP policy itself tell a different story. Rubens
Thank you, Anne
-----Original Message----- From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces@icann.org> On Behalf Of Rubens Kuhl Sent: Wednesday, September 4, 2019 12:57 PM To: gnso-newgtld-wg@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-...) 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@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.
Anne, Please listen to the call last night. I spent a lot of time on the basics of what are Registry Services, what is the Application RSTEP, vs. what is an RSEP for an existing registry/already delegated registry. As we discussed last night, if we state that all new applications that propose Registry Services (other than the Pre-Approved Services) go through the same process that existing registries go through to introduce new Registry Services, then all Registry Services that should go out for Public Comment will go out for Public Comment prior to being approved. If a new applicant does not want to get those services approved prior to its signing an agreement with ICANN, that is fine. But if it applies for the new service after their contract is signed, they will have to go through the then-current RSEP process (like all existing registries). Those services that would be put out for public comment under that RSEP process, would also be put out for public comment. In other words, we are treating the new entrants the same as the existing registries. This is critical as we do not want to stiffly innovation or make it harder for the new players than for the 1200+ incumbent TLDs. Jeff Neuman Senior Vice President Com Laude | Valideus D: +1.703.635.7514 E: jeff.neuman@comlaude.com -----Original Message----- From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces@icann.org> On Behalf Of Aikman-Scalese, Anne Sent: Thursday, September 5, 2019 2:24 PM To: Rubens Kuhl <rubensk@nic.br>; gnso-newgtld-wg@icann.org Subject: Re: [Gnso-newgtld-wg] Notes on Registry Services 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@icann.org> On Behalf Of Rubens Kuhl Sent: Wednesday, September 4, 2019 12:57 PM To: gnso-newgtld-wg@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-...) 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@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@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. ________________________________ 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>
Thanks Jeff. I have followed up with the IPC pursuant to the "Action Item" from the call. My understanding is that RSEP jurisdiction includes proposing new services and involves a 15 day "preliminary determination" period. If ICANN org determines that the registry service does not involve significant Security and Stability implications or raise "significant competition issues" , the proposed new service can remain "confidential" and the Registry Operator is free to deploy the new service after the 15 day period when ICANN determines no such issues are involved. Hence, if I were a registry, I would rather have that discussion and determination made with ICANN Org than via public comment. A description of the RSEP “preliminary determination” process is pasted below along with a link to the RSEP “workflow”. Please let me know if the text on the ICANN website is somehow incorrect. https://www.icann.org/en/system/files/files/rsep-process-workflow-14jun19-en... Preliminary Determination by ICANN Org described in RSEP Procedures here: 2.4 Preliminary Determination Period Following written notification by Registry Operator to ICANN that Registry Operator may make a change in a Registry Service within the scope of the preceding paragraph: ICANN shall have 15 calendar days to make a "preliminary determination" whether a Registry Service requires further consideration by ICANN because it reasonably determines such Registry Service: (i) could raise significant Security or Stability issues or (ii) could raise significant competition issues. Registry Operator must provide sufficient information at the time of notification to ICANN that it may implement such a proposed Registry Service to enable ICANN to make an informed "preliminary determination." Information provided by Registry Operator and marked "CONFIDENTIAL" shall be treated as confidential by ICANN. Registry Operator will not designate "CONFIDENTIAL" information necessary to describe the purpose of the proposed Registry Service and the effect on users of the DNS. ICANN may seek expert advice during the preliminary determination period (from entities or persons subject to confidentiality agreements) on the competition, Security or Stability implications of the Registry Service in order to make its "preliminary determination." To the extent ICANN determines to disclose confidential information to any such experts, it will provide notice to Registry Operator of the identity of the expert(s) and the information it intends to convey. For Security or Stability implications, ICANN may draw an expert from the Registry Services Technical Evaluation Panel described in 2.4(F) below. If ICANN determines during the 15 calendar day "preliminary determination" period that the proposed Registry Service, does not raise significant Security or Stability (as defined in Sections 1.3 and 1.4), or competition issues, Registry Operator shall be free to deploy it upon such a determination. If the implementation of a proposed service requires a material change to a Registry Agreement, the preliminary determination will be referred to the ICANN Board (See RSEP Implementation Notes Step 5). Anne -----Original Message----- From: Jeff Neuman <jeff.neuman@comlaude.com> Sent: Thursday, September 5, 2019 1:28 PM To: Aikman-Scalese, Anne <AAikman@lrrc.com>; Rubens Kuhl <rubensk@nic.br>; gnso-newgtld-wg@icann.org Subject: RE: [Gnso-newgtld-wg] Notes on Registry Services [EXTERNAL] Anne, Please listen to the call last night. I spent a lot of time on the basics of what are Registry Services, what is the Application RSTEP, vs. what is an RSEP for an existing registry/already delegated registry. As we discussed last night, if we state that all new applications that propose Registry Services (other than the Pre-Approved Services) go through the same process that existing registries go through to introduce new Registry Services, then all Registry Services that should go out for Public Comment will go out for Public Comment prior to being approved. If a new applicant does not want to get those services approved prior to its signing an agreement with ICANN, that is fine. But if it applies for the new service after their contract is signed, they will have to go through the then-current RSEP process (like all existing registries). Those services that would be put out for public comment under that RSEP process, would also be put out for public comment. In other words, we are treating the new entrants the same as the existing registries. This is critical as we do not want to stiffly innovation or make it harder for the new players than for the 1200+ incumbent TLDs. Jeff Neuman Senior Vice President Com Laude | Valideus D: +1.703.635.7514 E: jeff.neuman@comlaude.com<mailto:jeff.neuman@comlaude.com> -----Original Message----- From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces@icann.org<mailto:gnso-newgtld-wg-bounces@icann.org>> On Behalf Of Aikman-Scalese, Anne Sent: Thursday, September 5, 2019 2:24 PM To: Rubens Kuhl <rubensk@nic.br<mailto:rubensk@nic.br>>; gnso-newgtld-wg@icann.org<mailto:gnso-newgtld-wg@icann.org> Subject: Re: [Gnso-newgtld-wg] Notes on Registry Services 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@icann.org<mailto:gnso-newgtld-wg-bounces@icann.org>> On Behalf Of Rubens Kuhl Sent: Wednesday, September 4, 2019 12:57 PM To: gnso-newgtld-wg@icann.org<mailto:gnso-newgtld-wg@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-...) 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@icann.org<mailto:Gnso-newgtld-wg@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@icann.org<mailto:Gnso-newgtld-wg@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. ________________________________ 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<http://www.comlaude.com%3chttps:/comlaude.com>> ________________________________ 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.
Em 5 de set de 2019, à(s) 18:37:000, Aikman-Scalese, Anne <AAikman@lrrc.com> escreveu:
Thanks Jeff. I have followed up with the IPC pursuant to the "Action Item" from the call.
My understanding is that RSEP jurisdiction includes proposing new services and involves a 15 day "preliminary determination" period. If ICANN org determines that the registry service does not involve significant Security and Stability implications or raise "significant competition issues" , the proposed new service can remain "confidential" and the Registry Operator is free to deploy the new service after the 15 day period when ICANN determines no such issues are involved. Hence, if I were a registry, I would rather have that discussion and determination made with ICANN Org than via public comment. A description of the RSEP “preliminary determination” process is pasted below along with a link to the RSEP “workflow”. Please let me know if the text on the ICANN website is somehow incorrect.
https://www.icann.org/en/system/files/files/rsep-process-workflow-14jun19-en... <https://www.icann.org/en/system/files/files/rsep-process-workflow-14jun19-en...>
The text on the workflow states what is seen by registries that an RSEP is published while ICANN does security, stability and competition review. It's only unpublished during completeness check, but as soon as it deemed to have all elements for a decision to make, it's published while ICANN makes such determination. This can be seen in https://www.icann.org/resources/pages/rsep-2014-02-19-en <https://www.icann.org/resources/pages/rsep-2014-02-19-en> : there are two requests by ZACR for Registry Lock in African TLDs there are listed as "ICANN Review". Everyone can see what those requests are and help ICANN make a determination. Rubens
I have the following from IPC President Brian Winterfeldt: Dear Anne, Thank you for reaching out for clarification on the IPC position, as stated in its prior public comments, regarding disclosure of registry services. As far as I am aware, the IPC position on this matter has not changed since those comments were filed. Essentially, the IPC feels it is important for all prospective and reasonably foreseeable registry services associated with a particular TLD to be disclosed at the time of application, and included in the application evaluation process. This will ensure TLD applications are as complete as possible, improves transparency, and should make the evaluation process more efficient in comparison to relying on piecemeal post-application RSEPs to evaluate additional registry services. I hope this is helpful, and I certainly welcome additional input from other IPC members on this subject. Best regards, Brian IPC President ________________________________ [https://daks2k3a4ib2z.cloudfront.net/59358b8cf7332631232417e8/595fb59d73c5b113a1d2a61b_WIPG_LogoMark.png]<https://www.winterfeldt.law/> Brian J. Winterfeldt Principal Winterfeldt IP Group 1200 17<x-apple-data-detectors://12/1>th<x-apple-data-detectors://12/1> St NW<x-apple-data-detectors://12/1>, Ste 501<x-apple-data-detectors://12/1> Washington, DC 20036<x-apple-data-detectors://12/1> brian@winterfeldt.law<mailto:brian@winterfeldt.law> +1 202 903 4422 From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces@icann.org> On Behalf Of Rubens Kuhl Sent: Thursday, September 5, 2019 3:44 PM To: gnso-newgtld-wg@icann.org Subject: Re: [Gnso-newgtld-wg] Notes on Registry Services [EXTERNAL] ________________________________ Em 5 de set de 2019, à(s) 18:37:000, Aikman-Scalese, Anne <AAikman@lrrc.com<mailto:AAikman@lrrc.com>> escreveu: Thanks Jeff. I have followed up with the IPC pursuant to the "Action Item" from the call. My understanding is that RSEP jurisdiction includes proposing new services and involves a 15 day "preliminary determination" period. If ICANN org determines that the registry service does not involve significant Security and Stability implications or raise "significant competition issues" , the proposed new service can remain "confidential" and the Registry Operator is free to deploy the new service after the 15 day period when ICANN determines no such issues are involved. Hence, if I were a registry, I would rather have that discussion and determination made with ICANN Org than via public comment. A description of the RSEP “preliminary determination” process is pasted below along with a link to the RSEP “workflow”. Please let me know if the text on the ICANN website is somehow incorrect. https://www.icann.org/en/system/files/files/rsep-process-workflow-14jun19-en... The text on the workflow states what is seen by registries that an RSEP is published while ICANN does security, stability and competition review. It's only unpublished during completeness check, but as soon as it deemed to have all elements for a decision to make, it's published while ICANN makes such determination. This can be seen in https://www.icann.org/resources/pages/rsep-2014-02-19-en : there are two requests by ZACR for Registry Lock in African TLDs there are listed as "ICANN Review". Everyone can see what those requests are and help ICANN make a determination. Rubens ________________________________ 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.
Rubens is correct. And although the language states that the registries are free to deploy, it does not mean that they are free to deploy and nothing is disclosed. Furthermore the 15 day period is not a back and forth negotiation with ICANN. It is solely for ICANN to make sure the request is complete and for them to quickly analyze whether there are an security, stability, etc. concerns. Jeff Neuman Senior Vice President Com Laude | Valideus D: +1.703.635.7514 E: jeff.neuman@comlaude.com<mailto:jeff.neuman@comlaude.com> From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces@icann.org> On Behalf Of Rubens Kuhl Sent: Thursday, September 5, 2019 6:44 PM To: gnso-newgtld-wg@icann.org Subject: Re: [Gnso-newgtld-wg] Notes on Registry Services Em 5 de set de 2019, à(s) 18:37:000, Aikman-Scalese, Anne <AAikman@lrrc.com<mailto:AAikman@lrrc.com>> escreveu: Thanks Jeff. I have followed up with the IPC pursuant to the "Action Item" from the call. My understanding is that RSEP jurisdiction includes proposing new services and involves a 15 day "preliminary determination" period. If ICANN org determines that the registry service does not involve significant Security and Stability implications or raise "significant competition issues" , the proposed new service can remain "confidential" and the Registry Operator is free to deploy the new service after the 15 day period when ICANN determines no such issues are involved. Hence, if I were a registry, I would rather have that discussion and determination made with ICANN Org than via public comment. A description of the RSEP “preliminary determination” process is pasted below along with a link to the RSEP “workflow”. Please let me know if the text on the ICANN website is somehow incorrect. https://www.icann.org/en/system/files/files/rsep-process-workflow-14jun19-en... The text on the workflow states what is seen by registries that an RSEP is published while ICANN does security, stability and competition review. It's only unpublished during completeness check, but as soon as it deemed to have all elements for a decision to make, it's published while ICANN makes such determination. This can be seen in https://www.icann.org/resources/pages/rsep-2014-02-19-en : there are two requests by ZACR for Registry Lock in African TLDs there are listed as "ICANN Review". Everyone can see what those requests are and help ICANN make a determination. Rubens ________________________________ 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>
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@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@icann.org> On Behalf Of Rubens Kuhl Sent: Wednesday, September 4, 2019 12:57 PM To: gnso-newgtld-wg@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-...) 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@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@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.
participants (4)
-
Aikman-Scalese, Anne -
Jeff Neuman -
Maxim Alzoba -
Rubens Kuhl