August 2019 - Gnso-newgtld-wg

Re: [Gnso-newgtld-wg] - Specification 13
by Alexander Schubert Aug. 14, 2019

Aug. 14, 2019

Marc,If I understand correctly then ONLY trademark based applications can have a Spec 13; right?You claimed in your initial posting that TM applications based on "generic terms" can't get a Spec 13!Are you standing by this claim - or not? Also "protectable under applicable law" - does that mean "national law" - as in law in the jurisdiction of the country the string is trademarked in?Alexander -------- Original message -------- From: trachtenbergm(a)gtlaw.com Date: 8/14/19 21:16 (GMT+02:00) To: alexander(a)schubert.berlin, gnso-newgtld-wg(a)icann.org Subject: RE: [Gnso-newgtld-wg] - Specification 13  Alex, These applications are for trademarks, not generic terms, and at least VISA and DISCOVER are famous and well-known brand across the globe. You might even have one in your wallet. Best regards, Marc H. Trachtenberg Shareholder Greenberg Traurig, LLP | 77 West Wacker Drive | Suite 3100 | Chicago, IL 60601 Tel 312.456.1020 Mobile 773.677.3305 trachtenbergm(a)gtlaw.com | www.gtlaw.com From: Gnso-newgtld-wg [mailto:gnso-newgtld-wg-bounces@icann.org] On Behalf Of Alexander Schubert Sent: Wednesday, August 14, 2019 10:47 AM To: gnso-newgtld-wg(a)icann.org Subject: Re: [Gnso-newgtld-wg] - Specification 13 Dear Marc, I might misinterpret your suggestion – but you are saying there are no generic term based applications such as “smart”, “visa” or “discovery” have a Spec 13 in their contract? (I checked these three – and they seem to have a Spec 13 in their contracts – I assume when checking all the other generic keyword based applications the same will occur). And well: You need to register with the TM Clearinghouse: easy thing to do; the hurdles for that are very low (I have done TMCH applications for trademarks). Plus I am taking about a “real brand” – albeit a small one. So a small shoe brand “SHANGHAI” will easily meet all requirements for a spec 13. In my mind – please correct me if I am wrong. Thanks, Alexander From: trachtenbergm(a)gtlaw.com [mailto:trachtenbergm@gtlaw.com] Sent: Mittwoch, 14. August 2019 17:51 To: alexander(a)schubert.berlin; gnso-newgtld-wg(a)icann.org Subject: RE: [Gnso-newgtld-wg] - Specification 13 Alexander, Please also note that Spec 13 does not require just “some trademark registration” and specifically excludes generic string TLDs. Christopher conveniently “forgot” to point out that Section 9.3 of Spec 13 requires: (i) the TLD string is identical to the textual elements protectable under applicable law, of a registered trademark valid under applicable law, which registered trademark: a. is recorded with, and issued a signed data mark file by, the Trademark Clearinghouse or any successor or alternative trademark validation authority appointed by ICANN, if such trademark meets the eligibility requirements of such validation authority (provided that Registry Operator is not required to maintain such recordation for more than one year); b. is owned and used by the Registry Operator or its Affiliate in the ordinary course of Registry Operator’s or its Affiliates’ business in connection with the offering of any of the goods and/or services claimed in the trademark registration; c. was issued to Registry Operator or its Affiliate prior to the filing of its TLD registry application with ICANN; d. is used throughout the Term continuously in the ordinary course of business of Registry Operator or its Affiliate in connection with the offering of any of the goods and/or services identified in the trademark registration; e. does not begin with a period or a dot; and f. is used by Registry Operator or its Affiliate in the conduct of one or more of its businesses that are unrelated to the provision of TLD Registry Services; and (ii) only Registry Operator, its Affiliates or Trademark Licensees are registrants of domain names in the TLD and control the DNS records associated with domain names at any level in the TLD; (iii) the TLD is not a Generic String TLD (as defined in Specification 11); and (iv) Registry Operator has provided ICANN with an accurate and complete copy of such trademark registration. Best regards, Marc H. Trachtenberg Shareholder Greenberg Traurig, LLP | 77 West Wacker Drive | Suite 3100 | Chicago, IL 60601 Tel 312.456.1020 Mobile 773.677.3305 trachtenbergm(a)gtlaw.com | www.gtlaw.com From: Gnso-newgtld-wg [mailto:gnso-newgtld-wg-bounces@icann.org] On Behalf Of Alexander Schubert Sent: Wednesday, August 14, 2019 9:42 AM To: gnso-newgtld-wg(a)icann.org Subject: Re: [Gnso-newgtld-wg] - Specification 13 *EXTERNAL OF GT* Dear Paul, Don’t forget: I am ALL FOR famous (well known) TMs to be able to secure their brand as gTLD! I just think for generic term-based and geo name--based strings a spec 13 application (which locks out the general public) should meet WAY higher hurdles than just “some trademark registration”. Otherwise: Yes, I have grossly simplified the rather complex intellectual property rights cloud. There are of course IR TMs and (e.g. in Germany) enhanced protections for famous TMs that extend well beyond the goods and services originally protected. Thanks for clarifying, Alexander From: McGrady, Paul D. [mailto:PMcGrady@taftlaw.com] Sent: Mittwoch, 14. August 2019 17:15 To: alexander(a)schubert.berlin; gnso-newgtld-wg(a)icann.org Subject: RE: [Gnso-newgtld-wg] - Specification 13 Thanks Alexander. Respectfully, your analysis is incorrect. While trademarks are local (state), national, or international (EU marks, Benelux marks) in nature there are protections for trademarks found in International law, e.g. the Paris Convention. I wouldn’t expect anyone in this WG to know that other than the trademark attorneys who participate, so good you brought it up so that I could set the record straight. Your second notion, that trademarks are limited to corresponding goods/services is mostly true (except in jurisdictions that recognize the doctrine of dilution for the protection of famous marks. This would be a more interesting point if gTLD registry applications came with restrictions, i.e. that an applicant made it clear that they have applied for .apple to run an apple farm and that they pledge in advance that there will be no second level registrations that would contain terms or could be used to infringe the APPLE mark (for example, no ability to register computer.apple or use store.apple to sell electronics). Those restrictions would then be incorporated in PICS and brand owners could enforce against registries accordingly. However, ICANN has put no use requirements in place for applicants to agree to, so until they do, we have to take a broad view of trademark rights in order to protect consumers from confusion and malicious activities. Best, Paul Taft / Paul D. McGrady /

4 3

Proposed agenda - New gTLD Subsequent Procedures PDP WG - 12 August 2019 at 15:00 UTC
by Julie Hedlund Aug. 14, 2019

Aug. 14, 2019

Dear all, Please find below the proposed agenda for the call on Monday, 12 August 2019 at 15:00 UTC for 90 minutes: 1. Welcome and Updates to Statements of Interest 2. Review of summary document: a. Application Change Requests (continuing discussion - start on page 7) -- See: https://docs.google.com/document/d/1nf8qGP9Y7OYuT0ZvxIgM1fZtNa4Kj8DyhzpmPhE…<https://docs.google.com/document/d/1nf8qGP9Y7OYuT0ZvxIgM1fZtNa4Kj8DyhzpmPhE…> b. Reserved Names (page 4) -- https://docs.google.com/document/d/1Q6_DxsCvSA_3B7ArncO2U4tWNY3vH7Wi4nINrou… c. Registrant Protections (page 5) -- https://docs.google.com/document/d/1Q6_DxsCvSA_3B7ArncO2U4tWNY3vH7Wi4nINrou… 3. 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

8 12

Proposed agenda - New gTLD Subsequent Procedures PDP WG - 15 August 2019 at 20:00 UTC
by Julie Hedlund Aug. 13, 2019

Aug. 13, 2019

Dear all, Please find below the proposed agenda for the call on Thursday, 15 August 2019 at 20:00 UTC for 90 minutes: 1. Welcome and Updates to Statements of Interest 2. Review of summary document: b. Reserved Names (page 4) -- https://docs.google.com/document/d/1Q6_DxsCvSA_3B7ArncO2U4tWNY3vH7Wi4nINrou… c. Registrant Protections (page 5) -- https://docs.google.com/document/d/1Q6_DxsCvSA_3B7ArncO2U4tWNY3vH7Wi4nINrou… 3. 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 on Monday, 12 August 2019 at 15:00 UTC
by Michelle DeSmyter Aug. 12, 2019

Aug. 12, 2019

Dear all, All recordings for the New gTLD Subsequent Procedures Working Group call held on Monday, 12 August 2019 at 15:00 UTC can be found on the agenda wiki page <https://community.icann.org/x/TaujBg> (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 - 12 August 2019
by Julie Hedlund Aug. 12, 2019

Aug. 12, 2019

Dear Working Group members, Please see below the notes from the meeting today, 12 August 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-08-12+New+gTLD+Subsequent+Pr…. Kind regards, Julie Julie Hedlund, Policy Director Notes and Action Items: Notes: 1. Welcome and Updates to Statements of Interest: No updates provided. 2. Review of summary document: a. Application Change Requests (continuing discussion - start on page 7) -- See: https://docs.google.com/document/d/1nf8qGP9Y7OYuT0ZvxIgM1fZtNa4Kj8DyhzpmPhE… [docs.google.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_docume…> -- Page 5 – High-Level Agreement – when an applicant may change the applied for string. Jeff Neuman’s comment. Example on Delta. Very narrow circumstance that came up a couple of times in the 2012 round. -- Should be very specific list of changes that do not require evaluation or cost. A lot of that is already subject to high-level agreement. -- Concerns from ICANN Org about the need to put all applied-for strings through contention again. Would require constant re-evaluations concerning string similarity. -- Could have a required time frame. Adding a descriptive word to an applied-for brand is unlikely to create confusion. Need to consider the benefits – such as reducing the contention sets or avoiding an auction process. -- Need to think about how this would impact Specification 13. -- On timing, if the change is before the string-similarity evaluation occurs that would not result in any disruptions to the process per ICANN Org. But if the intent is for this to happen after the string similarity evaluation is completed, the there are concerns about result in additional string evaluation. Note this concern in the document. -- We need a fixed period or before evaluations start or terminated changes are allowed. Should be a period of time that any changes should be allowed to be made. But these are changes to the natural cycle. -- Note in high-level agreements that this is a very narrow proposal. It currently is in a comment. To the extent that there is agreement we’ll be more specific. -- Perhaps we need to loop back to this again as a “general matter of changes to strings proposed” after Auctions matter is settled? General Comments about Change Requests RrSG comment: Allow a change for typos: -- These were allowed in the 2012 round in a limited way. Need to verify that it is an error. Also, consider whether there should be a fee. Don’t want to encourage applicants to be less scrupulous. -- Depends on if it is subject to cost or public comment. -- Should be a period of time to make these or any changes. -- Question on the timing: when should it be allowed? After submission and revealed, or after the world knows what is submitted? Answer: There is an administrative check, perhaps it could happen then? This was just to make sure all of the questions were filled out. This type of typo/error check was not part of the admin check. -- Why not allow an obvious error correction any time during the application or after the reveal? Could be gamed after the reveal and contentions are shown. If we allow it before the reveal less likely to be gamed. -- The type of error correction we are talking about is of the string itself. NCSG comments – changes related to public comments, early warnings, could be very material. Allowing changes to respond to comments. Had specific rules for changes relating to community applications, but not for GAC early warning. -- In the 2012 round the applicants were not required to explain why they requested the change. -- Should collect the reason for the change (was not collected in 2012). -- In 2012 change requests for posted for a 30-day comment period. -- Early warning is not objection and does not require a change, but an applicant may decide to make changes. Note the distinction between required or optional changes. -- Applicants have to provide the necessary rationale for the change request so that ICANN can evaluate it. But ICANN doesn’t track or report on the reasons/rationales provided by applicants. -- Don’t think we should put ICANN Org in the position of making a judgement call. -- Proposal that there shouldn’t any substantive changes absent a public reason. But is that realistic if the time for evaluation takes longer than a year. -- How to prevent gaming? Think about what constitutes gaming. What are the concerns with the 7 criteria – these were spelled out in the supplemental report and most of the commenters agreed with the criteria. -- Needs to be carefully written to avoid any type of gaming. -- Perhaps a practical recommendation: Allow a subscription to keep track on any proposed changes and be notified of a comment period, etc. Comments on criteria used to evaluate change requests in the 2012 round: -- Not sure what IPC means by “contention” but could be dealt with as part of Criteria 1. They meant “contention set” Suggest change to allow – joint venture created to resolve string contention: -- Seems to be agreement. Other types of change: Looks like a typo – check the comments. No entity noted following GAC comment. Upon reviewing the comments noted that these are from the NCSG. How does the discussion change the High-Level Agreements? -- No changes but some details concerning implementation. -- Modify the third bullet, the specific narrow situations where the string change should be allowed. -- How to encapsulate the 7 criteria? They were called out in the Supplemental Initial Report and will be called out in the Final Report.

1 0

Re: [Gnso-newgtld-wg] Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 08 August 2019
by Jamie Baxter Aug. 9, 2019

Aug. 9, 2019

1 0

Re: [Gnso-newgtld-wg] Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 08 August 2019
by Jamie Baxter Aug. 9, 2019

Aug. 9, 2019

3 3

Post Call | New gTLD Subsequent Procedures Working Group | Thursday, 08 August 2019 at 20:00 UTC
by Julie Bisland Aug. 8, 2019

Aug. 8, 2019

Dear all, All recordings for the New gTLD Subsequent Procedures Working Group call held on Thursday, 08 August 2019 at 20:00 UTC can be found on the agenda wiki page <https://community.icann.org/x/S6ujBg> (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 - 08 August 2019
by Julie Hedlund Aug. 8, 2019

Aug. 8, 2019

Dear Working Group members, Please see below the notes from the meeting today, 08 August 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-08-08+New+gTLD+Subsequent+Pr…. Kind regards, Julie Julie Hedlund, Policy Director Notes and Action Items: Actions: Proposal: Make priority numbers transferable between applications in an applicant portfolio: ACTION ITEM: See whether there is enough support to keep this as a recommendation. Christa Taylor and Paul McGrady will work on language. Proposal: Priority processing for certain strings: ACTION ITEM: Explore further the proposal to have community applications be prioritized. Jamie Baxter to propose language in a separate thread. Proposal: Prioritization of applications in the next round over those in subsequent rounds/windows: ACTION ITEM: Susan Payne to send the proposal to the list to see if there is support. Proposal: Change to the applied-for string to a closely related string to avoid contention. Re-evaluation would be required. There would be possible additional costs to applicant: ACTION ITEM: Jeff to write up a proposal. Notes: 1. Welcome and Updates to Statements of Interest: No updates provided. 2. Review of summary document: a. Application Queuing (continued), beginning on page 2 – See: https://docs.google.com/document/d/1nf8qGP9Y7OYuT0ZvxIgM1fZtNa4Kj8DyhzpmPhE…<https://docs.google.com/document/d/1nf8qGP9Y7OYuT0ZvxIgM1fZtNa4Kj8DyhzpmPhE…> Make priority numbers transferable between applications in an applicant portfolio: -- ICANN Org concern about secondary market for priority numbers -- So you can't do this if your string is in contention. -- That sounds sensible and there is broad support for this (only Registrars and 1 individual stated they were against it).  -- See if we can find that there is enough support for this proposal. Not enough support in the comments to support or not support. -- Priority numbers transferred with same owner should be fine. Should not be creating a secondary market in priority numbers. ACTION ITEM: See whether there is enough support to keep this as a recommendation. Christa Taylor and Paul McGrady will work on language. Application Queuing if there is a first-come first-serve process: -- No consensus on having a first-come, first-served, process. Priority processing for certain strings: -- Default would be to keep the default as in 2012. -- Add a priority to application support applications. -- Order from the 2012 round: Drawing 1: IDN applications for which a ticket had been purchased ● Drawing 2: Non-IDN applications for which a ticket had been purchased ● Drawing 3: IDN applications for which a ticket had NOT been purchased ● Drawing 4: Non-IDN applications for which a ticket had NOT been purchased  -- Concern that portfolio applications undermine the basic commitment to enhancing competition and choice. -- Evaluate community applications first since it is generally a longer cycle because of CPE. There is a larger issue about the expectation that a community application has to endure a longer application evaluation period. -- Support that IDNs go first. -- Do not support - As we saw from the last round, so-called community applications are quite controversial. I think AGB 2012 already gave them enough special rights. -- There was also discussion on having Applicant Support Applicants going first. -- IDNs could be treated as communities (people speaking the same language). -- It seems to me that if CPE occurs early and that application fails CPE, it may clear the way for other applicants for that string and they will get to market sooner. It makes sense for everyone and the marketplace in general to get to CPE as early as possible. -- What about an Applicant Support applicant who needs time to raise funds if they are not eligible for AS funds?  -- Only heard 2 individuals supporting the new special treatment for community applications. Is that enough to keep itu alive? Seems like we could put that one to rest. -- ALAC also expressed a preference for giving community applications priority. ACTION ITEM: Explore further the proposal to have community applications be prioritized. Jamie Baxter to propose language in a separate thread. Prioritization of applications in the next round over those in subsequent rounds/windows: -- COMMENT: 2012 applications are out of scope for this policy process - not in the PDP Charter. The other issue is that applications made in 2012 may or may not meet the policies adopted for the next round. In addition, a determination as to what is "confusingly similar' is a matter for the String Confusion Objection, not a matter for preventing an application from being made. We can't put a "chilling effect" on new applicants. COMMENT -- This isn’t a suggestion to change the past round. -- We still have applications from 2012 pending out there and we need to know how they will be dealt with . -- From the Valideus comment: “Although it does not expressly say so, this recomemndation should also apply to any applications from the 2012 round which remain pending - it should not be possible in a later application phase to submit an identical or confusingly similar application which takes precedence over one submitted in an earlier application phase.“ -- COMMENT @ Paul et al - Knowing how to deal with those 2012 applications does not mean there should be a ban on new applications for that same string. You could say there would be no contention set but you can't say no one can apply for that string. It violates the Principle of Applicant Freedom of Expression. That's a long term policy issue for all Subsequent Rounds. COMMENT -- Valideus: If there still something from round one unresolved, aren’t we doing a disservice to new applicants who might apply for something that might never be available. -- COMMENT: Round 2 applicants can decide whether or not they want to take the risk of applying for the same string or not. COMMENT COMMENT: If policies change, the first application could fail. COMMENT -- It should be at their own (hopefully informed) risk; you pay yer money and you take your chances.  -- It is possible to have a list (or a place to go to) to check if an application is still pending (at least we can recommend that) -- Application status is available here from the 2012 round applications: https://gtldresult.icann.org/applicationstatus/viewstatus -- At the time the application window is opened, there should be a list readily available that identifies strings that are in some kind of 'pending' status. -- ACTION ITEM: Susan Payne to send the proposal to the list to see if there is support. ICANN Org: WG should clarify what is meant by “must have priority over applications submitted in any subsequent rounds/application windows.” For example must all applications in a current round complete contracting prior to any application in a subsequent round being able to sign a Registry Agreement? Note that priority number is also used in other program phases to prioritize applications (i.e., contracting and RST). -- Didn’t get support for this concern. b. Application Change Requests (page 5) -- See: https://docs.google.com/document/d/1nf8qGP9Y7OYuT0ZvxIgM1fZtNa4Kj8DyhzpmPhE…<https://docs.google.com/document/d/1nf8qGP9Y7OYuT0ZvxIgM1fZtNa4Kj8DyhzpmPhE…> Policy Goals: The framework for considering and responding to change requests should be clear, consistent, fair and predictable. High-Level Agreement: -- Part of this is referring to the criteria that ICANN used into 2012 (in the Initial Report). -- The change request process and criteria are here: https://newgtlds.icann.org/en/applicants/global-support/change-requests -- Explanation: Is a reasonable explanation provided? 2. Evidence that original submission was in error: Are there indicia to support an assertion that the change merely corrects an error? 3. Other third parties affected: Does the change affect other third parties materially? 4. Precedents: Is the change similar to others that have already been approved? Could the change lead others to request similar changes that could affect third parties or result in undesirable effects on the program? 5. Fairness to applicants: Would allowing the change be construed as fair to the general community? Would disallowing the change be construed as unfair? 6. Materiality: Would the change affect the evaluation score or require reevaluation of some or all of the application? Would the change affect string contention or community priority? 7. Timing: Does the timing interfere with the evaluation process in some way? -- When drafting in relation to pending applications still outstanding from 2012, could you be sure to cover the issue of possible non-compliance of those applications with new policy adopted subsequent to 2012? (I previously suggested, as Christopher Wilkinson pointed out on On this point: If it is allowed that an applicant may change the applied-for string because the original string is in a contention set, the new string should not create a new contention set or enter into another existing contention set. -- Not sure why this should be in the high-level agreement. -- It is here because it is conditional. Outstanding Items - New Ideas/Concerns/Divergence Suggested change to allow: Change to the applied-for string to a closely related string to avoid contention. Re-evaluation would be required. There would be possible additional costs to applicant: -- Opposed: Risk of gaming, difficult situation for public and applicant. Discussion: -- How would this not be fair? The issue if it is generic/dictionary terms. -- Modify the proposal that if you are a brand owner and had a trademark and wanted to change your string with a descriptor. -- Raises a lot of questions about processes. There are much more complex examples. -- ICANN Org concerns: Very careful about change requests to the applied for string in the 2012 round. If an application is allowed to change the applied for string then all the applications would need to be re-evaluated. Could create additional contention sets. Very subjective to decide what “closely related” means. -- changing to something similar will open door to the applications made with intentions of future changes … it is bad from the public being confused during the comments phase -- COMMENT: The issue re modification in the .brand realm is that the .brand applicant may not have trademark rights in the modified string. This would have to be put out for public comment. There could be other trademark holders who might object to the modified string as confusingly similar. COMMENT -- I agree with the general idea that Kathy has put forward. I disagree with the idea that it should be limited to brands that are “non-generic terms.” -- Trademarks are inherently non-generic in their context, so the requirement is a non-sequitor  -- These revised string should still be subject to all the usual objection processes (not sure anyone said otherwise...). -- If we narrow down the proposal the complications go away. -- Don't support the proposal and share the concerns raised by Jamie and Trang. I don't believe this is as simple as you make it out to be. -- There may be some relevant comments to this discussion that were submitted under the topic of auctions of last resort -- there's some overlap in the two subjects and comments on them. Change to the applied-for string to a closely related string to avoid contention. Re-evaluation would be required. There would be possible additional costs to applicant: ACTION ITEM: Jeff to write up a proposal.

1 0

Proposed agenda - New gTLD Subsequent Procedures PDP WG - 8 August 2019 at 20:00 UTC
by Emily Barabas Aug. 7, 2019

Aug. 7, 2019

Dear all, Please find below the proposed agenda for the call tomorrow, 8 August 2019 at 20:00 UTC for 90 minutes: 1. Welcome and Updates to Statements of Interest 2. Review of summary document: a. Application Queuing (continued), beginning on page 2 – See: https://docs.google.com/document/d/1nf8qGP9Y7OYuT0ZvxIgM1fZtNa4Kj8DyhzpmPhE… b. Application Change Requests (page 5) -- See: https://docs.google.com/document/d/1nf8qGP9Y7OYuT0ZvxIgM1fZtNa4Kj8DyhzpmPhE… 3. AOB For item 2a we will also reference this document, which provides the timing of delegation of IDNs from the 2012 round: https://docs.google.com/spreadsheets/d/1nQw13qN4qdr27ZaNbD47Vp70OzM6ESFDVEa… 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, Emily Emily Barabas | Policy Manager ICANN | Internet Corporation for Assigned Names and Numbers Email: emily.barabas(a)icann.org | Phone: +31 (0)6 84507976

2 1