- Gnso-newgtld-wg - lists.icann.org

Use Requirement for 2nd round new gTLDs
by Alexander Schubert Nov. 22, 2019

Nov. 22, 2019

Dear Jeff, As discussed on the call yesterday here a brief suggestion regarding a “use requirement”. First a summary of my suggestion: The new RA (Registry Agreement) should contain a clause that denies contract renewal if registries have not had a Sunrise registration phase (Spec-13 Brand Registries would be exempted from this clause). Here my rationale for this: Obviously the 2007 PDP demanded a use requirement. Hence currently registries face steep penalties for not contracting (application will be withdrawn) and not testing/entering the root (cancelation of the contract). Let’s be cognizant of the 3 gTLD categories that emerged in 2012: 1. Spec 13 gTLDs (Brands) 2. Geo gTLDs (mainly cities) 3. All others We can’t always find “one size fits all” solutions – and claim that in absence of a global solution we will not create ANY solution at all. That said: I can’t speak for the category 1. And as Martin Sutton said on the Monday GNSO call: if “use” was defined by “number of domains”: nothing more easy than registering a number of domains. So yes: for brand gTLDs it’s nifty to “define” a “use requirement” – maybe someone else can come up with a solution for Spec-13 registries. BUT: For categories 2 and 3 I think the solution is simple! We already steeply penalize if the prospective registry doesn’t contract or engage in testing. There are grace periods to do so (I think 9 month). We could use the same grace period for “startup” – which is opening the string up for registrations in Sunrise! At BARE minimum we should put into the new RA (Registry Agreement) that failure for categories 2 and 3 (non-Spec-13 registries) to startup (start sunrise) WILL be a reason to deny contract renewal! A DECADE of not starting up should be a clear sign of failure. This solution is NOT impacting Spec 13 applicants. We can discuss separately whether or not we wish to add a “use requirement” for them as well. This solution would also NOT impact 2012 round new gTLDs. Thanks, Alexander.berlin

10 21

Proposed agenda - New gTLD Subsequent Procedures PDP WG - Tuesday, 26 November 2019 at 03:00 UTC
by Julie Hedlund Nov. 22, 2019

Nov. 22, 2019

Dear all, Please find below the proposed agenda for the call on Tuesday, 26 November 2019 at 03:00 UTC for 90 minutes: 1. Review Agenda/Statements of Interest 2. CCT-RT Recommendations -- see: https://docs.google.com/spreadsheets/d/1PGV5_nMafLWtSHyCGdr-b8eqoJj9B8YKBSh… [docs.google.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_spread…> (continue discussion on Recommendation 12) 3. String Contention Mechanisms of Last Resort: https://docs.google.com/document/d/16qDoiK6vydQp6a0v9tMvU2l5fcypJY24hCzTIVT… [docs.google.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_docume…> 4. AOB If you need a dial out or would like to submit an apology, please email gnso-secs(a)icann.org<mailto:gnso-secs@icann.org>. Kind regards, Julie Julie Hedlund, Policy Director

1 0

Post call / New gTLD Subsequent Procedures Working Group call / Thursday, 21 November 2019 at 20:00 UTC
by Julie Bisland Nov. 22, 2019

Nov. 22, 2019

Dear all, All recordings for the New gTLD Subsequent Procedures Working Group call held on Thursday, 21 November 2019 at 20:00 UTC can be found on the agenda wiki page <https://community.icann.org/x/Z4QzBw> (attendance included) and the GNSO Master calendar <https://urldefense.proofpoint.com/v2/url?u=http-3A__gnso.icann.org_en_group…> . These include: * Attendance (please let me know if your name has been left off the attendance list) * Audio recording * Zoom chat archive * Zoom recording (including audio, visual, rough transcript) * Transcript As a reminder only members can join the call, observers can listen to the recordings and read the transcript afterwards. Please email gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> if you would like to change your status from observer to member. For additional information, you may consult the mailing list archives <http://mm.icann.org/pipermail/gnso-newgtld-wg/> and the main wiki page<https://community.icann.org/x/RgV1Aw>. Thank you. Kind regards, Julie

1 0

Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 21 November 2019
by Julie Hedlund Nov. 21, 2019

Nov. 21, 2019

Dear Working Group members, Please see below the notes from the meeting on 21 November 2019. These high-level notes are designed to help WG members navigate through the content of the call and are not a substitute for the recording, transcript, or the chat, which will be posted at: https://community.icann.org/display/NGSPP/2019-11-21+New+gTLD+Subsequent+Pr…. Kind regards, Julie Julie Hedlund, Policy Director Notes and Action Items: Actions: Contractual Compliance: ACTION ITEM: Ask a couple of people to work on these suggestions: -- We could make a recommendation that a registry or registrar that has access to the TMCH should not download a copy of all the strings in the TMCH to set up reserved names. -- We could modify the dispute mechanism to include this type of case. See what if anything could be changed in a Sunrise dispute mechanism policy. CCT-RT Recommendations: Recommendation #9: ACTION ITEM: Proposal to consider -- The WG would say that a global discount program is not something that is feasible at this point. There are new services that came on the market since the CCT-RT work was done and we could see if any of these address the recommendations. Also, what have trademark owners learned from the last round. Then we could say that certain types of data should be collected by ICANN to see if this really is an issue for subsequent TLDs. Notes: 1. Welcome and Updates to Statements of Interest: -- Paul McGrady is no longer on the GNSO Council. He will update his SOI. 2. Contractual Compliance -- Data Metrics: https://docs.google.com/document/d/1eYhtbK_sEKWzdUjwg7zURL2HnKYTYCJeItX-h66… [docs.google.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_docume…> Is there evidence of “arbitrary and abusive pricing for premium domains targeting trademarks; use of reserved names to circumvent Sunrise; and operating launch programs that differed materially from what was approved by ICANN.” If yes, how should these issues be addressed? -- Corresponded with the RPM PDP WG that this issue was more properly in scope for the SubPro PDP WG. -- INTA comments: Agreement/New Idea/Concerns - Points to 2017 INTA study for examples of issues experienced (see full comment for list of examples). Reports that INTA has been raising concerns about pricing and other practices which appear calculated to circumvent the RPMs, and for which little or no action appears to be taken by ICANN Compliance, since 2015. -- IPC: Agreement -- LeMarit: Agreement/New Idea -- Neustar: Is not aware of any evidence that would support the assertion that these operational practices are being implemented. -- RySG: Has no empirical evidence of these types of activities and generally believe these allegations are unsupported. If these activities are occurring, existing mechanisms are sufficient to address them. Discussion: -- Should the WG make recommendations relating to this issue? Some comments say there is evidence others say there isn’t a problem. -- Opposed to premium pricing per se. The starting point is a ban on premium pricing. -- What's the harm in doing something about it? If the new gTLD registries are sure that nothing untoward is going on, then they won't mind making it clear that premium domain names can only be listed after Sunrise is done. -- Can see that for some TLDs the concept of premium pricing may well have merit. Earlier comments say there is specific evidence; we should go back and get those specific cases. We need to understand if there is an issue that needs to be addressed. The comments are disagreeing with each other. -- The TMCH has every single ascii letter and number. TM holders gamed the TMCH. And the argument over what’s a brand and what’s generic isn’t for registries to decide. -- Where a registrant has created the value in the string it’s particularly irksome to be charged a premium price. Example of Facebook creating the value and then being charged a premium price. -- Much more legitimacy for ICANN's new gTLD program. It suffers from the perception that it was based primarily on the hope that brand owners would show up and financially support it. The premium domain names that corresponded to brands and were not available in Sunrise just appeared predatory and the ICANN's Board's unwillingness to do anything about it just made them look complicit. ICANN needs all the legitimacy it can borrow right now. -- One of the arguments from the trademark owners that we’ve heard and in the INTA study it is true that for a number of registries the domains were often considered premium once they came out of Sunrise. -- Once of the CCT-RT recommendations has to do with pricing and brand owners and using RPMs. -- Is there something we could say that might satisfy both the trademark owners and the registry concerns? -- Creating a generic brand type test is difficult. -- Or you could automatically do a Sunrise, or a Sunrise before you can release them to another owner. -- It is a business decision by the brands to register their name in a TLD, and weren't there other mechanisms put in place such as the URS to allow TM owners a quick way to address illegitimate registration? -- There were no mechanisms to challenge premium pricing of the registry. -- Legitimate TM holders did not game the TMCH. Domain speculators gamed trademark offices and the TMCH. If registries aren’t supposed to be determining what a trademark is, then registries should stop premium pricing for trademarks. In some cases, it’s been quite obvious where registries are targeting trademarks and trademark owners. -- We can’t outlaw reserved names. Not sure that we can regulate pricing, but sounds like there are issues. -- PDDRP might work here but only if there was an avalanche of activity by a single registry. -- Many trademark owners felt that the pricing that was assigned to names was designed to circumvent the RPMs. Perhaps that could be a factor in a PDDRP against a registry. -- Legitimate registries didn’t extort legitimate trademark holders. -- But isn’t relegating pricing on sunrise names exactly what they are asking for? Forbid the pricing to prevent circumvention is a form of regulation. -- If a registry is putting special prices on these that are in the TMCH, the problem of course is that someone can register a trademark, but it in the TMCH, quite easily and then make sure the pricing can’t be increased on it. People will be gaming this on both sides. You shouldn’t be using the TMCH to see who you can charge more for a name. -- Parse it down a little further. We see to be talking about two different things in chat: 1) premium pricing in a Sunrise and 2) in conjunction with reserved names that are only available after Sunrise is closed. I thought we were talking about the latter, which isn’t a pricing issue, but whether the Sunrise is being honored. What is it that we are talking about? -- The RPMs PDP WG is well aware of this issue. -- We are not to talk about what is in the TMCH, etc., but whether we believe that there are things registries are doing that have the effect of circumventing the RPMs. -- The terms of the registry agreement have a prohibition on ICANN regulating pricing. It’s not practical to approach this from the standpoint of regulating pricing. Sounds like we would need to approach this the standpoint of dealing with reserved names. -- This is not a pricing issue and I agree ICANN needs to stay out of that. I think the real concern here is that the entire RPM process is observed.  -- Focus on those actions that have the effect of circumventing the RPMs. -- The fact that registries can play this game and try to charge premium pricing for certain strings suggests registries have monopoly over certain strings. -- We should have a policy of preventing abuses in the pricing system. -- Remember, our group is not dealing with what is in the TMCH or what is required to show to get your mark in there We are only dealing with the limited issue of circumvention of the RPMs. -- For use in Sunrise, use must be proven to the TMCH. The great majority of trademarks in TMCH have submitted proof of use in order to participate in Sunrise. Only a few chose not to, and they only participate in Claims, which doesn’t block. -- That is the mechanism to challenge any gaming in the TMCH. -- Sunrise DRP only has limited causes of action. TMCH issues will be challenged through the TMCH DRP not the Sunrise DRP. -- Jeff I think the terms of use of the TMCH limit access to the list solely for claims notification and verification of the name in the TMCH. Check that first . -- Is the Sunrise dispute resolution mechanism something the RPMs group is looking at? Answer: The RPMs PDP WG did look at the Sunrise DRP and will have recommendations for improving it. A wrongly granted Sunrise registration that did not result from a bad TMCH entry is something that could be dealt with under the Sunrise DRP. The Sunrise DRP was created before the TMCH was created so it ended up being redundant to TMCH challenges. See: https://www.icann.org/sites/default/files/tlds/xn--ngbc5azd/xn--ngbc5azd-sd… . -- Re: Trademarks have to be used to be protected -- that is not true in all jurisdictions. -- RPMs PDP WG did address several times of actions that would result in reserving names. -- For Sunrise you do have to put proof of use in the TMCH even if you didn’t need to do it to get your name registered. -- The notion of whether reserving names prior to Sunrise for the purpose of either circumventing the RPMs is something we agree is not a good thing. We just need to think of where a challenge could be made for that type of action. -- Not trying to prevent legitimate uses of the TMCH. ACTION ITEM: Ask a couple of people to work on these suggestions: -- We could make a recommendation that a registry or registrar that has access to the TMCH should not download a copy of all the strings in the TMCH to set up reserved names. -- We could modify the dispute mechanism to include this type of case. See what if anything could be changed in a Sunrise dispute mechanism policy. 3. CCT-RT Recommendations -- see: https://docs.google.com/spreadsheets/d/1PGV5_nMafLWtSHyCGdr-b8eqoJj9B8YKBSh<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_spread…> eVJQcvHg/edit#gid=0 [docs.google.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_spread…> -- Talking about the recommendations specifically targeted at this PDP WG. -- We need to decide if it is proper for this WG to address the recommendations. -- If so, what should we be doing to address it. -- Comment period on implementation plan for accepted CCT recs is complete - these comments now being analyzed. Recommendation #9: WG Co-Leaders: The recommendation appears to be directed more at the RPMs WG, with the text stating that, "uneven distribution of costs of defensive registrations to a small number of trademark holders may be an unanticipated effect of the current RPM regime..." It is likely beyond the remit of the SubPro PDP to affect that RPM regime, so it is unclear what actions may be needed from the SubPro PDP. The SubPro PDP may want to coordinate with the RPMs PDP to determine if one or both the PDPs should be responsible for considering this recommendation. Comments: Jim Prendergast: But don't pricing policies come under our remit? Agree there may be some RPM play here but I don't think we are completely absolved of responsibility either. Jeff Neuman: Having read this section, which I attach below, it was clear that the CCT RT did not fully understand who this should go to, but at the end of the day, it relates to reducing the amount of defensive registrations (See pg 72 of report - "Success measures."). There is no way to address this recommendation other than through an exhaustive look at the RPMs. (see full comment) Discussion: -- Very hard to address this recommendation. There is very little data and not all registries are connected to this centralized registry. Doesn’t seem like a feasible recommendation for this WG. There is no way to do a global discount program. -- If there a small number of trademark owners that register most of the names -- not many Sunrise registrations but a large portion of these registrations are from very few trademark owners. So, what is causing these few companies to register in every Sunrise while some are not. They are paying the lion’s share so is there a way to lower the cost. -- This is unsolvable. There are many different reasons to register defensively. -- Have we considered asking members of the CCT-RT how they think this could be accomplished? Answer: On this recommendation we did talk to them and asked them this question. The response was that the CCT-RT doesn’t have an answer to this. We just noted this data correlation, but thought it was something for this WG to consider. -- Not all brands are uniformly dependent on Internet traffic and not all TLDs are as inherently "scary" as the next. .Sneakers would be much "scarier" to NIKE than .birthdaycake. -- Forcing discounts is also a form of price control and ICANN should steer clear. If registries want to offer blocking services in order to keep down the need for defensive registrations, great, but that should be the product of the free market. -- Registries are not connected to each other, but the common nexus is ICANN so maybe they could serve as a conduit. -- Several registries offer a domain mark protection list so that a mark holder can pay a small amount for blocking registration of their brand across many TLDs. -- Perhaps we can recommend a "best efforts 'by ICANN.org to establish this data set might help. ACTION ITEM: Proposal to consider -- The WG would say that a global discount program is not something that is feasible at this point. There are new services that came on the market since the CCT-RT work was done and we could see if any of these address the recommendations. Also, what have trademark owners learned from the last round. Then we could say that certain types of data should be collected by ICANN to see if this really is an issue for subsequent TLDs. Recommendation #12: WG Co-Leaders: The SubPro PDP has not thoroughly considered the findings from the Nielsen surveys, which at a high level indicated that, "the public believes that websites have different extensions to “properly identify the purpose or owner or to give an indication of content or function.” As such, the PDP WG has also not considered whether it believes that creating incentives or removing potential barriers (e.g., application fee, annual fees, possible need for RSEP) to operating restricted TLDs is in the best interest of the program. Discussion: -- We have talked about this and we put some of this out for public comment. -- Would be nice to know what the incentives and disincentives are… -- The WG does not need to recommend specific incentives or disincentives, but if they don’t this will have to be addressed in implementation. -- It’s a policy decision whether to provide these incentives. We could agree or disagree with the CCT-RT. We could adopt it, not adopt it, or adopt it with modifications. -- It is not clear if you can identify verified TLDs in the public interest. We should make a recommendation in this regard. If we can make a recommendation about how to do it, that would be better. But we can’t ignore it. This issue is directly linked to consumer trust and the public interest. -- This is a nice idea, but the RA is already convoluted and confusing enough. The incentives should exist outside of the RA mechanism. There might be incentives that only last for a limited period of time. In terms of developing mechanisms, simpler is better. -- One simple solution is lower fees. Other solutions might be more difficult. -- What if verified TLDs got priority in the way that communities got priority in contention sets in the 2012 round? -- Running a verified TLD costs more and tends to have fewer registrations. Verified TLDs may be able to pay less at auction and may be less able to pay fees. -- You could also provide support registrars. This could make it more valuable to the registry. -- This topic will be discussed further on the next call on Tuesday, 26 November 2019 at 03:00 UTC for 90 minutes 

1 0

Proposed agenda - New gTLD Subsequent Procedures PDP WG - Thursday, 21 November 2019 at 20:00 UTC
by Julie Hedlund Nov. 20, 2019

Nov. 20, 2019

Dear all, Please find below the proposed agenda for the call on Thursday, 21 November 2019 at 20:00 UTC for 90 minutes: 1. Review Agenda/Statements of Interest 2. Contractual Compliance -- Data Metrics: https://docs.google.com/document/d/1eYhtbK_sEKWzdUjwg7zURL2HnKYTYCJeItX-h66… [docs.google.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_docume…> 3. CCT-RT Recommendations -- see: https://docs.google.com/spreadsheets/d/1PGV5_nMafLWtSHyCGdr-b8eqoJj9B8YKBSh… [docs.google.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_spread…> 4. String Contention Mechanisms of Last Resort: https://docs.google.com/document/d/16qDoiK6vydQp6a0v9tMvU2l5fcypJY24hCzTIVT… [docs.google.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_docume…> (time permitting) 5. AOB If you need a dial out or would like to submit an apology, please email gnso-secs(a)icann.org<mailto:gnso-secs@icann.org>. Kind regards, Julie Julie Hedlund, Policy Director

1 0

Post-ICANN66 Policy Report Now Available
by Nathalie Peregrine Nov. 20, 2019

Nov. 20, 2019

Dear all, The Post-ICANN66 Policy Report is now available. Please click here to access it: https://go.icann.org/post66 [go.icann.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__go.icann.org_post66&d=…>. Kind regards, Nathalie Nathalie Peregrine Manager, Operations Support (GNSO) Internet Corporation for Assigned Names and Numbers (ICANN) Email: nathalie.peregrine(a)icann.org <nathalie.peregrine(a)icann.org%20> Skype: nathalie.peregrine.icann Find out more about the GNSO by visiting: https://learn.icann.org/ <https://urldefense.proofpoint.com/v2/url?u=https-3A__learn.icann.org_&d=DwM…> Follow @GNSO on Twitter: https://twitter.com/ICANN_GNSO <https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_ICANN-5FGN…> Transcripts and recordings of GNSO Working Group and Council events are located on the GNSO Master Calendar <https://urldefense.proofpoint.com/v2/url?u=https-3A__gnso.icann.org_en_grou…> See All SO and AC events on the ICANN Global calendar [features.icann.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__features.icann.org_cal…>

1 0

Re: [Gnso-newgtld-wg] Use Requirement for 2nd round new gTLDs
by Alexander Schubert Nov. 20, 2019

Nov. 20, 2019

I also have a new idea how to prevent gTLD-warehousing and attempts by big corporations to shut down entire verticals: E.g. a (imaginary) big Chinese Online Bookstore “BabiAla” applying for “.book” in Chinse script – only to never start a Sunrise phase; effectively “shutting down” the vertical. Proposed solution: * Have a “Early Startup” Commitment checkbox in the application form. * If an applicant checks the box (which he isn’t required to do) they would be prioritized over those who haven’t (similar to the Community Priority). * Real world example: o BabiAla wants to shut down the vertical “.book” (in Chinese) – has no plans to start up quickly (enter into sunrise within 9 month after testing) – doesn’t tick the “Early Startup” check box o The “Chinese Writers Association” would also apply for .book in Chinse script; plans to startup right away and DOES commit to Early Startup (checks the Early Startup Check Box) o In that case priority would be provided to Chinese Writers Association’s application, and BabiAla’s application would be withdrawn by ICANN. The Chinese Writers Association would prevail the contention based on their Early Startup Commitment. This would allow those who do NOT have any startup plans to still be able to apply – but prioritize those who can commit to startup ASAP. It would put a pressure on big corporations who want to “shut down” verticals – as they have to fear that potential contention would be get prioritized. It would also slow down warehousing for exactly the same reason. This was an issue in 2012 already – but now we face a situation where the application fees might go as low as US $50 (hopefully not) AND “One Stop Solution Providers” are already offering to execute application processing (incl. contracting and testing) for US $50k for the 2nd round (a friend of mine is offering that). At US $100k plus 25k per year big corporations will JUMP on “shutting down” their killer industry keyword. Even if you look at a 10 year period: it’s MUCH cheaper than the identical .com domain! So if I can shut down a gTLD for a decade at a price lower than the .com domain: it’s a NO-BRAINER! An Early Startup Priority would create an obstacle – and should prevent a number of “actors” from engaging in questionable actions. Thanks, Alexander From: Alexander Schubert [mailto:alexander@schubert.berlin] Sent: Mittwoch, 20. November 2019 11:49 To: 'gnso-newgtld-wg(a)icann.org' <gnso-newgtld-wg(a)icann.org> Subject: Use Requirement for 2nd round new gTLDs Dear Jeff, As discussed on the call yesterday here a brief suggestion regarding a “use requirement”. First a summary of my suggestion: The new RA (Registry Agreement) should contain a clause that denies contract renewal if registries have not had a Sunrise registration phase (Spec-13 Brand Registries would be exempted from this clause). Here my rationale for this: Obviously the 2007 PDP demanded a use requirement. Hence currently registries face steep penalties for not contracting (application will be withdrawn) and not testing/entering the root (cancelation of the contract). Let’s be cognizant of the 3 gTLD categories that emerged in 2012: 1. Spec 13 gTLDs (Brands) 2. Geo gTLDs (mainly cities) 3. All others We can’t always find “one size fits all” solutions – and claim that in absence of a global solution we will not create ANY solution at all. That said: I can’t speak for the category 1. And as Martin Sutton said on the Monday GNSO call: if “use” was defined by “number of domains”: nothing more easy than registering a number of domains. So yes: for brand gTLDs it’s nifty to “define” a “use requirement” – maybe someone else can come up with a solution for Spec-13 registries. BUT: For categories 2 and 3 I think the solution is simple! We already steeply penalize if the prospective registry doesn’t contract or engage in testing. There are grace periods to do so (I think 9 month). We could use the same grace period for “startup” – which is opening the string up for registrations in Sunrise! At BARE minimum we should put into the new RA (Registry Agreement) that failure for categories 2 and 3 (non-Spec-13 registries) to startup (start sunrise) WILL be a reason to deny contract renewal! A DECADE of not starting up should be a clear sign of failure. This solution is NOT impacting Spec 13 applicants. We can discuss separately whether or not we wish to add a “use requirement” for them as well. This solution would also NOT impact 2012 round new gTLDs. Thanks, Alexander.berlin

2 1

FW: Letter to SubPro PDP WG Co-Chairs: GAC Input on Scope of Upcoming New gTLDs Subsequent Procedures PDP WG Public Comment
by Jeff Neuman Nov. 20, 2019

Nov. 20, 2019

FYI. Again, this is not on the agenda to discuss today, but I wanted to get this around to the group as it just came in. Jeff Neuman Senior Vice President Com Laude | Valideus D: +1.703.635.7514 E: jeff.neuman(a)comlaude.com<mailto:jeff.neuman@comlaude.com> From: Julia Charvolen <julia.charvolen(a)icann.org> Sent: Monday, November 18, 2019 9:24 AM To: Jeff Neuman <jeff.neuman(a)comlaude.com>; Cheryl Langdon-Orr <langdonorr(a)gmail.com> Cc: council(a)gnso.icann.org; Johan Helsingius <julf(a)julf.com>; GACLEADERSHIP <gac-leadership(a)icann.org> Subject: Letter to SubPro PDP WG Co-Chairs: GAC Input on Scope of Upcoming New gTLDs Subsequent Procedures PDP WG Public Comment Dear Jeff and Cheryl, Please find attached a letter from the GAC Chair, Manal Ismail, on behalf of GAC Membership relative to the scope of the upcoming new gTLDs Subsequent Procedures PDP WG Public Comment proceeding, with a cc to the GNSO Council and GNSO Liaison to the GAC for their information. The letter can be found on the GAC website correspondence page<https://gac.icann.org/contentMigrated/gac-input-on-scope-of-upcoming-new-gt…>. Thank you. Best regards, GAC Support Team -- Julia Charvolen GAC Advice and Policy Support Manager ICANN ________________________________ 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>

2 2

Post Call / New gTLD Subsequent Procedures Working Group call on Monday, 18 November 2019 at 15:00 UTC
by Michelle DeSmyter Nov. 18, 2019

Nov. 18, 2019

Dear all, All recordings for the New gTLD Subsequent Procedures Working Group call held on Monday, 18 November 2019 at 15:00 UTC can be found on the agenda wiki page (<https://community.icann.org/x/ZIQzBw>attendance included) and the GNSO Master calendar <https://urldefense.proofpoint.com/v2/url?u=http-3A__gnso.icann.org_en_group…> . These include: * Attendance (please let me know if your name has been left off the attendance list) * Audio recording * Zoom chat archive * Zoom recording (including audio, visual, rough transcript) * Transcript As a reminder only members can join the call, observers can listen to the recordings and read the transcript afterwards. Please email gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> if you would like to change your status from observer to member. For additional information, you may consult the mailing list archives <http://mm.icann.org/pipermail/gnso-newgtld-wg/> and the main wiki page<https://community.icann.org/x/RgV1Aw>. Thank you. Kind regards, Michelle

1 0

Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 18 November 2019
by Julie Hedlund Nov. 18, 2019

Nov. 18, 2019

Dear Working Group members, Please see below the notes from the meeting on 18 November 2019. These high-level notes are designed to help WG members navigate through the content of the call and are not a substitute for the recording, transcript, or the chat, which will be posted at: https://community.icann.org/display/NGSPP/2019-11-18+New+gTLD+Subsequent+Pr…. Kind regards, Julie Julie Hedlund, Policy Director Notes and Action Items: Actions: Contractual Compliance: https://docs.google.com/document/d/1eYhtbK_sEKWzdUjwg7zURL2HnKYTYCJeItX-h66… ACTION ITEM 1: Continue discussion on the list of the following question: Is there evidence of “arbitrary and abusive pricing for premium domains targeting trademarks; use of reserved names to circumvent Sunrise; and operating launch programs that differed materially from what was approved by ICANN.” If yes, how should these issues be addressed? Notes: 1. Welcome and Updates to Statements of Interest: -- Re SOI, Anne Aikman-Scalese has been appointed as CSG voting rep to the Auction Proceeds CCWG. 2. Review of summary documents: a. Registry System Testing: https://docs.google.com/document/d/1RGB1DYMZAb62izAV0Uxo9pmEskYzZ4SGSa4JqWQ… (page 2) Policy Goals: * The following recommendations from 2007 remain applicable: * Recommendation 7: “Applicants must be able to demonstrate their technical capability to run a registry operation for the purpose that the applicant sets out.” * Recommendation 8: “Applicants must be able to demonstrate their financial and organisational operational capability.” High-level Agreements: -- Remove a better part or all self-certification assessments. Outstanding Items: Remove a better part or all self-certification assessments. -- ICANN Org: New Idea - It should be noted that some self-certifications, such as those related to load testing, should be retained as operational testing of load would be disruptive and not favorable, and it is important to do load testing to ensure that the infrastructure can handle expected traffic. -- At least one RySG member: New Idea - Recommendation should stipulate that removal of the self-certification assessment applies to established RO's who exhibit the exact same business rules across TLDs. There is opposition within RySG for that viewpoint, believing it to be anti-competitive. Registry System Testing (RST) should be split between overall registry service provider (RSP) matters and specific application/TLD testing. -- BRG: Agreement. -- Consider whether this rises to the level of a preliminary recommendation. Rely on Service Level Agreement (SLA) monitoring for most if not all overall registry service provider testing. -- BRG/At least one RySG member: Agreement. -- Some RySG: Concerns/New Idea. -- ICANN Org: Concern - The Initial Report indicates that this preliminary recommendation was based on ICANN Org’s response to a PDP Working Group request. ICANN org would like to clarify that our recommendation was that some tests could be removed from Registry System Testing in favor of ongoing monitoring of TLD operations against a broader set of existing contractual technical requirements. -- SSAC: Divergence - In general, it is preferable to discover major failures before delegation instead of after the TLD is in operation. Past performance is not a guarantee of future performance. Discussion: -- How can we merge/reconcile this views? We need to drill down on the ones ICANN Org said could be eliminated. There isn’t a consensus to remove those other aspects, but we should talk about whether pre-delegation testing needs to be done on every top-level domain. -- What would be the utility of testing pre-approved RSPs? Do different TLDs react in different ways to the sane system?  Same system (although hoping the system is sane). -- If the only difference between pre-approval and regular approval is the timing, then it shouldn’t be an issue. -- I don’t think we want to eliminate any parts of PDT that discovered these issues prior to delegation -- But as to the point of timing, earlier testing can then be a boon. -- Wouldn't the pre-approval process essentially involve the pre-delegation testing? So it wouldn't need to be done time after time . -- There would still be a need for pre-delegation testing lite—to make sure the name servers are correctly configured. But it would be so much less burdensome than the complete PDT from last time. -- Drill down into the elements that ICANN Org thought could be removed and get agreement on those. -- If we are moving toward removing pieces from the previous round make sure we aren’t removing anything that may have caught deficiencies. Limit Internationalized Domain Name (IDN) testing to specific TLD policies; do not perform an IDN table review in Registry System Testing. -- BRG/Neustar: Agreement -- RySG: Agreement/Concerns. -- ICANN Org: Concern - The Initial Report indicates that this preliminary recommendation was based on ICANN Org’s response to the PDP Working Group request. The ICANN Org recommendation suggests removing IDN table review from PDT if using tables pre-vetted by the community, or if using tables not pre-vetted that they be reviewed prior to Registry System Testing. Discussion: -- One of the main challenges with the IDN tables is that the testing provider changes the requirements often without notification. Include additional operational tests to assess readiness for Domain Name System Security Extensions (DNSSEC) contingencies (key roll-over, zone re-signing). -- RySG: Concerns from some members & New Idea from some members. Possible language: “Applicants must be able to demonstrate their technical capability to run a registry operation for the purpose that the applicant sets out, either by submitting it to evaluation at application time or agreeing to use a previously approved* technical infrastructure.” * Could mean in the same procedure or previous procedures if an RSP program exists. -- BRG/Neustar: Agreement. -- RySG: At least one RySG member suggests that if an applicant is choosing to use a previously approved technical infrastructure, then the applicant should be required to identify that service provider at application. This is opposed by at least one RySG member, stating that this would only serve the interest of registry service providers, while leaving approved registry operators to later choose a registry service provider increase competitiveness in that field. -- Consider whether this rises to the level of a preliminary recommendation. Feedback on recommendations ICANN’s Technical Services group provided to WT4 -- RySG: Agreement/Concerns/New Idea/Divergence. b. TLD Rollout: https://docs.google.com/document/d/1eYhtbK_sEKWzdUjwg7zURL2HnKYTYCJeItX-h66… (page 2) Policy Goals: The following Implementation Guideline from the 2007 recommendations remains appropriate: * Implementation Guideline I: “An applicant granted a TLD string must use it within a fixed timeframe which will be specified in the application process.” High-level Agreements: * The ICANN organization should be responsible for meeting specific deadlines in the contracting and delegation processes. * Maintain the timeframes set forth in the Applicant Guidebook and the base Registry Agreement; namely (i) that successful applicants continue to have nine (9) months following the date of being notified that it successfully completed the evaluation process to enter into a Registry Agreement, and (ii) that Registry Operators must complete all testing procedures for delegation of the TLD into the root zone within twelve (12) months of the Effective Date of the Registry Agreement. In addition, extensions to those timeframes should continue to be available according to the same terms and conditions as they were allowed during the 2012 round. -- RySG states in its support for this recommendation that any specific proposal should be flexible enough to permit ICANN to extend the contracting and delegation process for security and stability and public interest reasons subject to SSAC advice and / or GAC consensus with board approval. Outstanding Items: Maintain the timeframes set forth in the Applicant Guidebook and the base Registry Agreement * ICANN Org: Concerns - Extensions in the 2012 round caused extensive delays and consumed significant program resources (see the ICANN Program Review Report for discussion on extensions for contracting and Registry System Testing). Additionally, the lack of a time limit for launch of a gTLD created significant burden and costs on ICANN operations to support a number of activities that take place between delegation launch (i.e., processing sub-contractor changes and RSEP requests). This impacts program financials, and has a potential impact on the timing of closure of a round depending on the criteria used to close a round. Discussion: -- How can this WG help to address ICANN Org’s concerns? Hard to see what we could do without affecting different TLD models. Is prevention of squatting/warehousing still a relevant reason to have a delegation deadline? Are other measures needed? -- BRG: Agreement. -- RySG: Agreement/Divergence. -- MarkMonitor: Agreement. Is the definition of use of a TLD from the 2012 round still appropriate or are adjustments needed? -- BRG/RySG: Support use requirement in the 2012 AGB. No adjustments are necessary. -- RrSG: Does not support requiring a TLD to have registrations within 12 months for the Registry Operator to retain the license to the TLD. Suggests increasing the time-to-first-registration (other than NIC.TLD and WHOIS.NIC.TLD) to 5 years for non-exempt TLDs. Additional comments: -- Christopher Wilkinson: 1. Rollout: It would be helpful to have information about how many new TLDs have still not been implemented and why. The Initial Report appears to indicate that the WG would in practice accept squatting and warehousing of new TLDs. The WG should pursue a more proactive approach to discouraging such behavior in the future. Discussion: -- There is a huge problem with warehousing. -- Particularly concerned about the political repercussions of warehousing of geo-names outside the corresponding jurisdiction. -- There was never anything in the AGB that had a requirement of use and doesn’t seem to be much support for adding a use requirement. -- To be clear, I think prevention of squatting/warehousing is still relevant reason to have a delegation deadline. I just think .brand TLDs not launching is a lesser concern than others TLDs. -- Pushing all TLDs to start selling names within a certain period encourages multiple launches all at the same time - surely a RO ought to be able to roll out at the time they believe they will lead to the best business outcome. -- There are many factors that impact launch and use of TLDs, especially those that are not purely for commercial purposes. The last round was also hindered by many delays, which had a detrimental impact for many. -- Didn’t all applications have to state their intended use? If that was to change, or not occur because roll out does not happen, is there not a procedure or penalty to address this? -- If you don't make available domains to the community - then others should be granted the opportunity to steward that string. At the very latest once the first 10 years went by without measurable use (a few registered domains aren't sufficient). So no use = contract cancelation. -- What contractual obligations do the registry operators have in this regard? -- Public comment did not sway this towards any changes being required. -- To address ICANN's concerns, minimum payments could be required for TLDs not yet launched within years after delegation and signed contract. This would have to be based on average costs. -- To answer the question of whether TLDs are not in use we need to define what we mean by “use”. -- What is the problem we are trying to resolve here? We’ve already collected public comments on this question. -- Prevention of squatting/warehousing is still relevant reason to have a delegation deadline. -- Is it worth pointing to the previous calls on the public comments on this topic. -- It seems the record should reflect that there is deep concern from many in Non-Registry Community on this call. -- Struggling with what the problem is and possible ramifications on defining/requiring use. Lacking the evidence and issue base to come up with a way forward on this. -- Without clear definition of "squatting" or "use", I would suggest looking at reasonable timeline to launch for registration. Especially if the RO had prevailed in a contention set or objection. Timeline to be proposed by RO themselves. This is my personal opinion. c. Contractual Compliance: https://docs.google.com/document/d/1eYhtbK_sEKWzdUjwg7zURL2HnKYTYCJeItX-h66… (page 6) Policy Goals: The following existing recommendation from the 2007 policy remains appropriate: * Recommendation 17: “A clear compliance and sanctions process must be set out in the base contract which could lead to contract termination.” High-level Agreements: * ICANN’s Contractual Compliance Department should publish more detailed data on the activities of the department and the nature of the complaints handled. -- While generally supporting this recommendation, the following additional points were raised -- RySG and Neustar indicated that ICANN should not publish or reporting that identifies any specific party(ies) subject to compliance action. IPC asked that the WG's recommendation include additional detail so that it can be more fully considered. Should applicant statements, such as representations and/or commitments, be included in the Registry Operator’s Agreements? Why or why not? -- INTA, IPC, ALAC: Agreement. -- IPC: Agree especially in relation to rights protection mechanisms. -- BRG, RySG: Agree if inclusion is optional. -- INTA: New Idea. -- Neustar: Divergence. -- Christopher Wilkinson: The statement in the Initial Report that 'There was no agreement … in support of this proposal' is a rather weak conclusion which might be queried at a later stage. Is there evidence of “arbitrary and abusive pricing for premium domains targeting trademarks; use of reserved names to circumvent Sunrise; and operating launch programs that differed materially from what was approved by ICANN.” If yes, how should these issues be addressed? -- INTA: Agreement/New Idea/Concerns. -- IPC: Agreement. -- LeMarit: Agreement/New Idea. -- Neustar: Is not aware of any evidence that would support the assertion that these operational practices are being implemented. -- RySG: Has no empirical evidence of these types of activities and generally believe these allegations are unsupported. If these activities are occurring, existing mechanisms are sufficient to address them. Discussion: -- Is it within this group's scope to consider or review the thresholds used for meeting compliance and triggering sanctions? If not, then whose job would that be? -- Continue discussion on the list. -- What can be done about it would not be a question of regulating pricing - need a different remedy because the RA prohibits ICANN from regulating pricing - as far as I know.

1 0