[Gnso-newgtld-wg] Written Comments - Draft Initial Report Section 1.7

Sat May 26 08:36:12 UTC 2018

> On 25 May 2018, at 21:57, Aikman-Scalese, Anne <AAikman at lrrc.com> wrote:
> 
> Dear all:
> Regarding accurate reflection of the discussions which occurred in Work Track 4  - see Section 1.7 of the draft Initial Report - items raised several times are summarized in my e-mail of February 28, 2018 below.   These items were raised in the Work Track 4 call on November 30, 2017  as documented in the attached email of January 17, 2018.   (The attached email notes the points in the mp3 recording from November 30 at which these items were discussed.)   Thus, the points were raised, at a minimum, on November 30, 2017, January 17, 2018, and February 28, 2018.
> 
> Please note that the items set out below are specifically identified as issues/questions that should be put out for public comment and that should be highlighted in the Initial Report.   Accordingly, could staff please make certain that Section 1.7 of the draft accurately reflects the items below? That should save a lot of time on the May 29 call.
> 

Anne,

All the items you raised were already factored into the draft report.

> 
> 
> 1.       Aggregated technical evaluation should not affect the order of processing applications.  Kurt Pritz objected to the “as much as feasible” language in the slides and stated “Additional technical evaluation should not retard or slow down applications….they should retain their place in queue and should not be penalized in any way from a timing standpoint.”  This issue should be raised for public comment.

This is already listed here at preliminary recommendation here:

"In order to not hinder innovation, applications proposing non-pre-approved services should not be required to pay a higher application fee, unless it is deemed as possibly creating a security or stability risk requiring an RSTEP (Registry Services Technical Evaluation Panel).  In addition, in order to encourage the proposal of innovative uses of TLDs, those proposing new non-approved registry services should not to the extent possible be unreasonably delayed in being evaluated.  "

And a question on that is already included:
"Not adding cost and time to applications that propose new services likely increases cost and processing time for those applications that do not propose any additional Registry Services. In other words, it has been argued that applications without additional services being proposed are “subsidizing” applications which do propose new services.  Do you see this as an issue?"

> 
> 2.       Issue Still to be Defined – whether a new gTLD applicant should or should not be required to disclose planned new services at the time of application.  This is an important question for public comment in that the current policy requires such disclosure where as several in the group commented that they disfavor public disclosure of new services and favor the RSEP process.   This also relates to Question 18 of the application.  Three straw models were proposed and discussed.  Friendly amendments were offered, but no final recommended model was adopted by the group.  Will all three models go out for public comment?

As happened with the financial model discussion, all straw models were replaced by a common framework that was discussed in the San Juan meeting, which is reflected in the final document. The decision was (1) to not automatically add the pre-approved services to the registry agreement, requiring applicants to say they will provided a service (even a pre-approved one), even if it's pre-approved. That allows applicants to better state what their intended registry will or won't be; (2) to allow applicannts to disclose they will be later pursuing an RSEP process for a non pre-approved service.

Note that whatever we decide in SubPro can't override the Registry Services Evaluation Policy, since it's out of scope of the PDP, and applicant (later registry) freedom of enterprise still applies, meaning even if it was not disclosed at application time, a registry may file an RSEP the second it gets a contract.We went to great lengths to allow willing applicants to disclose anything they want disclose, to not have services listed in their agreement unless they want to provide those services, but no option that violates the PDP mandate - like prohibiting RSEP for registries that haven't disclosed that intention in their application - are in scope for SubPro.

> 
> 3.       Name Collisions – Items which should be put out for public comment are:
> 
> (a) Should ICANN be directly responsible for controlled interruption rather than the registries?

There is a question discussing the impact of that decision:
"If ICANN were initially required  to initially delegate strings to its own controlled interruption platform and then later delegate the TLD to the registry, would that unreasonably increase the changes to the root zone?"

Perhaps tuning that question to also ask this question ? Could you propose language changes in that specific question ?

> (b) What should be the period of controlled interruption?

Already in:
"
The Work Track generally agreed to keep the Controlled Interruption period at  90 days due to lack of consensus in changing it. Some evidence indicated a 60-day period would be enough. Though no evidence was provided to require a longer period, other work track members argued for a longer 120 days. What length do you suggest and
 why? Note that the preliminary recommendation to have ICANN Org conduct CI as early as possible would likely mitigate potential delays to applicants in launching their TLD.
"

> (c) Re the proposal for “do not apply” and “exercise care” lists, as well as low and medium risk categories, we need public comment on how to establish standards for these lists so that our input can be provided to the SSAC, and

"The Work Track notes that the following issues are still pending further deliberations and input:
(...)
Guidelines, or guidance to make guidelines, for categorization and list-creation, including possible applicant opinion and collision framework;"

> (d) we need public comment on whether or not applicants should be able to propose name collision mitigation plans on an individual string-by-string basis and what mechanism, if any, could be put in place to approve such an individualized  mitigation plan.  (Again, this will be important for providing input to the SSAC.)

This sounds somewhat redundant with the content already in the report, but would you suggest text for such two questions ?

Rubens

> 
> The above issues should be highlighted in the Initial Report.
> 
> Thank you,
> Anne
> 
> Anne E. Aikman-Scalese
> Of Counsel
> 520.629.4428 office
> 520.879.4725 fax
> AAikman at lrrc.com <mailto:AAikman at lrrc.com>
> _____________________________
> <image002.png>
> Lewis Roca Rothgerber Christie LLP
> One South Church Avenue, Suite 2000
> Tucson, Arizona 85701-1611
> lrrc.com <http://lrrc.com/>
> 
> 
> From: Gnso-newgtld-wg-wt4 [mailto:gnso-newgtld-wg-wt4-bounces at icann.org <mailto:gnso-newgtld-wg-wt4-bounces at icann.org>] On Behalf Of Rubens Kuhl
> Sent: Tuesday, February 27, 2018 7:29 PM
> To: gnso-newgtld-wg-wt4 at icann.org <mailto:gnso-newgtld-wg-wt4 at icann.org>
> Subject: [Gnso-newgtld-wg-wt4] WT4 Call #25
> 
> 
> Dear WT4 members,
> 
> The next call for the New gTLD Subsequent Procedures Sub Team – Track 4 - IDNs/Technical & Operations will take place for 60 minutes on Thursday, 01 March 2018 at 20:00 UTC, 21:00 Brussels, 20:00 London, 12:00 Los Angeles, 15:00 Washington DC; Friday 02 March, 04:00 Singapore, 05:00 Tokyo, 07:00 Sydney.
> 
> 
> The proposed agenda, as previously mentioned during the last WT4 call, is as follows:
> 
> 1.         Welcome, SOI updates
> 2.         WG Co-chairs guidance on Initial Report
> 3.         Registry System Testing
> 4.    AOB
> 
> Since RST (Registry System Testing) was described in AGB as PDT (Pre-Delegation Testing), reading section 5.2 is recommended:
> https://newgtlds.icann.org/en/applicants/agb/transition-delegation-04jun12-en.pdf <https://newgtlds.icann.org/en/applicants/agb/transition-delegation-04jun12-en.pdf>
> 
> More documents are available at ICANN's RST website, https://www.icann.org/resources/registry-system-testing <https://www.icann.org/resources/registry-system-testing> , of which this chart - https://www.icann.org/sites/default/files/assets/rst-1280x720-31jul17-en.jpg <https://www.icann.org/sites/default/files/assets/rst-1280x720-31jul17-en.jpg> - is an useful high-level summary.
> 
> For WG members, please use the instructions in the calendar invite for connecting to AC and phone bridge, with phone bridge recommended for those willing to speak.
> 
> Best,
> CLO & 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.
> <RE [Gnso-newgtld-wg-wt4] Registry Services straw-person.eml>_______________________________________________
> Gnso-newgtld-wg mailing list
> Gnso-newgtld-wg at icann.org <mailto:Gnso-newgtld-wg at icann.org>
> https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg <https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg/attachments/20180526/08c4de05/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 529 bytes
Desc: Message signed with OpenPGP
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg/attachments/20180526/08c4de05/signature-0001.asc>