| A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z | AA | AB | |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
1 | Item # | Package | Name | Report Section | Additional Details | Applicable Text | Rationale for Change | Proposed Change | Date discussed by WG | Outcome | ||||||||||||||||||
2 | AAS1.1 | 1 | Anne Aikman-Scalese | 2.4.3 Systems | p. 7 – 5th bullet point | Allow autofill in applications for all questions but Questions 16, 18(a), 18(b), 19, 20, 21, 22, and 23 (but only if additional services are specified) | Agree with Questions designated as not eligible for “autofill” but not the limiting text re Question 23 “(but only if additional services are specified)” Applicants should not automatically autofill all pre-approved services at the time of application and wait until after application to specify additional services. This circumvents initial public comment periods and relies on later procedures available at ICANN for approving additional new services that do not receive as much public scrutiny. | Delete “(but only if additional services are specified)”. As stated in Footnote 14 on page 7, Question 23 “asks the applicant to provide the name and full description of all the Registry Services to be provided.” Thus, registry services have to be disclosed at the time of application and this section should not be subject in any way to autofill. Deliberations under c. state that WG determined that auto-fill could be allowed in a “limited number of fields”. The current approach is the opposite – autofill permitted everywhere except for a limited number of questions. | 28 May 2020 | Edited with compromise language. | ||||||||||||||||||
3 | AAS1.2 | 1 | Anne Aikman-Scalese | 2.5.1 Application Fees & 2.5.2 Variable Fees | p 10 | The Working Group believes that for subsequent procedures the only historical costs that should be part of the cost structure in determining application fees are those actual costs directly related to the implementation of the New gTLD Program | The 2012 round demonstrates that significant costs can arise subsequent to applications being delegated. For the 2012 round, this included funding procedures for further policy development, interacting with regulatory authorities, launching an EPDP, and running the Sub Pro PDP. It’s not realistic to believe that ICANN can adequately determine and budget application fees without considering the ongoing indirect costs of the nature described above. | Delete “those actual costs directly related to the implementation of the New gTLD Program” and replace with “those actual and anticipated costs of implementation and subsequent administration of the New gTLD Program, including but not limited to costs arising from new legal compliance and/or policy development processes that may be required”. | 28 May 2020 | Original text retained. | ||||||||||||||||||
4 | AAS1.3 | 1 | Anne Aikman-Scalese | 2.5.5 Terms & Conditions | p 14 first paragraph | Unless required under specific laws or the ICANN Bylaws, ICANN must only reject an application if done so in accordance with the provisions of the Applicant Guidebook. | The language does not account for the fact that the Board is required to act in a fiduciary capacity. For example, you cannot say that the Board has to approve an application made in accordance with the AGB if the Board determines it has a fiduciary duty to reject the application or if it would be permitted by the ByLaws, in the exercise of its fiduciary duty, to reject it. (This is different from saying that the ByLaws require them to reject it.) | Revise as shown in ALL CAPS below “Unless required under specific laws, OR AS THE BOARD DETERMINES IN THE EXERCISE OF ITS FIDUCIARY DUTIES AS CONTEMPLATED BY THE ICANN BYLAWS” , ICANN must only reject an application if such rejection is done in accordance with the provisions of the Applicant guidebook.” | 2 June 2020 | Edited with compromise language. | ||||||||||||||||||
5 | AAS1.4 | 1 | Anne Aikman-Scalese | 2.5.5 Terms & Conditions | P. 15 – Recommendation xx (rationale 3) | …some type of recourse if substantive changes are made to the Applicant Guidebook or progam processes if such changes have or are reasonably likely to have a material impact on Applicants | The recommendation does not specify: (1) What “some type of recourse” means. (2) The timing at which changes are made that result in the “material impact”. (3) The standard of proof for determining “material impact” This language is very confusing and indefinite in many respects. Did we establish a separate appeals mechanism for decisions by ICANN that fit under this recommendation? And how do the Applicant’s rights in this regard fit into the application of the Predictability Framework? | Revise the Recommendation as follows: “Applicants must be allowed to challenge substantive changes made to the Applicant Guidebook after applications are submitted through an appeals mechanism or Request for Reconsideration or both, at Applicant’s discretion. In such cases, the Applicant will have the burden of proof to demonstrate that the change has, or is likely to have, a material impact on the Applicant.” | 2 June 2020 | Edited to clarify the original intent of the recomendation. | ||||||||||||||||||
6 | JC1.1 | 1 | Justine Chew | 2.4.2 Communications | a. Recommendations and/or implementation guidelines Afirmation xx: …. • Implementation Guideline C: “ICANN will provide frequent communications with applicants and the public including comment forums which will be used to inform evaluation panels.” | Proposed change does not impact rationale but instead adds necessary clarity by addressing omission of a dependency to the Role of Application Comment section. | To add footnote: Usage to inform evaluation panels is addressed more specifically in section xx Role of Application Comment. | 26 May 2020 | Proposed text incorporated. | |||||||||||||||||||
7 | JC1.2 | 1 | Justine Chew | 2.4.2 Communications | d. Dependencies/ relationships with other areas of this report or external efforts | Proposed change does not impact rationale but instead adds necessary clarity by addressing omission of a dependency to the Role of Application Comment section. | To add a 3rd bullet: • The impact of comments collected through the comment forums referred to in Implementation Guideline C is addressed separately (see xx Role of Application Comment). | 28 May 2020 | Proposed text incorporated with minor edit to clarify text. | |||||||||||||||||||
8 | JC1.3 | 1 | Justine Chew | 2.4.2 Communications | a. Recommendations and/or implementation guidelines Implementation Guidance xx: For timeliness, the Working Group believes that for the next subsequent round, the Communications Period should begin at least six (6) months prior to the beginning of the application submission period. ….. | 1. Since insufficient awareness of the Program prior to the last round is well acknowledged, this Implementation Guidance ought to prescribe – not merely suggest – a minimum time period for the next round’s Communications Period. 2. Prior WG discussion on the distinction between the terms “must” and“should” and when either ought to be used, applies. | To replace “should” with “must”. | 28 May 2020 | Original text retained. | |||||||||||||||||||
9 | JC1.4 | 1 | Justine Chew | 2.5.1 Application Fees & 2.5.2 Variable Fees | a. Recommendations and/or implementation guidelines Implementation Guidance xx (rationale 4): In the event that an application fee floor is used to determine the application fee, excess fees received by ICANN should be used to benefit one or more of the following elements of the New gTLD Program: (a) a global communication and awareness campaign about the introduction and availability of new gTLDs ….. | 1. The word “should” used here suggests that there is an option to use excess fees to benefit one or more of the 4 stated elements (a) to (d). There should be no such option in event there is excess fees 2. Unlike the Implementation Guidance xx (rationale 4) relating to application fee floor not being implemented where returning of any excess fee to applicants may not be possible, no such limitation is envisaged in respect of excess fees – collected in the event of application fee floor being used – being applied towards the 4 stated elements of the Program. | To replace “should” with “must”. | 2 June | Edited to make this a recommendation. | |||||||||||||||||||
10 | KK1.1 | 1 | Kathy Kleiman | 2.5.3 Application Submission Period | Page 14, b, first paragraph | Namely, if communications and outreach efforts are effective prior to the point at which the window opens, prospective applicants will be prepared to apply and will therefore need less time to actually submit the application. | It’s unclear in current text who should be reponsivle for the communications and outreach efforts. Since it’s ICANN, we should make that quite clear. It’s ICANN’s outreach into communities around the world, including the Global South, that will help to generate the diversity of applications we are seeking. | Namely, if ICANN’s communications and outreach efforts are effective prior to the point at which the window opens, prospective applicants will be prepared to apply and will therefore need less time to actually submit the [application. | 2 June 2020 | Proposed text incorporated. | ||||||||||||||||||
11 | KK1.2 | 1 | Kathy Kleiman | 2.5.1 Application Fees & 2.5.2 Variable Fees | Implementation Guidance xx (rationale 1): Fees for the technical and operational evaluation for the core registry services should be charged to an applicant if they are using a registry service provider that is not pre-evaluated (“Technical Evaluation Fee”). The Technical Evaluation Fee should be the same regardless of whether the evaluation occurs as part of the Pre-Evaluation Process or as part of the application process. For example, if the Technical Evaluation Fee portion of the overall Application Fee is $US25,000, that portion of the Application Fee should only be charged to those applicants that do not select a pre-evaluated registry service provider. | For example, if the Technical Evaluation Fee portion of the overall Application Fee is $US25,000, that portion of the Application Fee should only be charged to those applicants that do not select a pre-evaluated registry service provider (which has not been removed from the pre-evaluated registry acceptance list and does not have major incident reports pending against it). | 28 May 2020 | Original text retained. | ||||||||||||||||||||
12 | KK1.3 | 1 | Kathy Kleiman | 2.4.3 Systems | p. 7 – 5th bullet point | Allow autofill in applications for all questions but Questions 16, 18(a), 18(b), 19, 20, 21, 22, and 23 (but only if additional services are specified) | Applicants should not automatically autofill all pre-approved services at the time of application and wait until after application to specify additional services. These fields, and their differentiation, is critical for public review. Plus this was the agreement after extensive discussion. Also the “but” is slightly ambiguous in this context. | Allow autofill in applications for all questions except Questions 16, 18(a), 18(b), 19, 20, 21, 22, and 23 which must each be individually filled out. Delete: “(but only if additional services are specified)” | 28 May 2020 | Edited with compromise language. | ||||||||||||||||||
13 | Neustar1.1 | 1 | Neustar, submitted by Donna Austin | 2.5.1 Application Fees & 2.5.2 Variable Fees | Implementation Guidance xx (rationale 4): In the event that an application fee floor is used to determine the application fee, excess fees received by ICANN should be used to benefit one or more of the following elements of the New gTLD Program | The work ‘should’ allows for ICANN discretion in the use of excess funds, I would prefer that this is not discretionary and as such prefer the use of the word ‘must’. ICANN should not have any discretion regarding excess fees. | In the event that an application fee floor is used to determine the application fee, excess fees received by ICANN must be used to benefit one or more of the following elements of the New gTLD Program | 2 June | Edited to make this a recommendation. | |||||||||||||||||||
14 | Neustar1.2 | 1 | Neustar, submitted by Donna Austin | 2.5.1 Application Fees & 2.5.2 Variable Fees | Clarification on when the ‘application fee floor’ can be used. | It’s not a cannot live with issue, but rather one of clarity: In reading the whole section it is unclear to me whether the ‘application fee floor’ can be used in the next Subsequent Procedure or only in rounds that follow. I don’t recall the intent so have not suggested any language, but I do believe this is something that should be an explicit recommendation particularly if the intent is that an application fee floor not be used in the intial Subsequent Procedure. | 28 May 2020 | Implementation Guidance xx (rationale 3) edited to clarify that that fee floor concept applies to the next round and all subsequent rounds. | ||||||||||||||||||||
15 | Neustar1.3 | 1 | Neustar, submitted by Donna Austin | 2.5.1 Application Fees & 2.5.2 Variable Fees | Implementation Guidance xx (rationale 3): A reassessment should take place prior to each application round to estimate the application fee that would be necessary to achieve cost recovery. In the event that the estimated application fee, based on the revenue neutral principle, falls below a predetermined threshold amount (i.e., the application fee floor), the actual application fee should be set at that higher application fee floor instead. | This section would benefit from Implementation Guidance that requires ICANN to be transparent in how they arrived at the Application Fee amount for the Subsequent Procedure and all rounds that follow. Particularly when a value has been determined for an application fee floor. One of the challenges we experienced in discussion the application fee for 2012 was the lack of information available on how the fee was determined. | Implementation Guidance: The development of the Application Fee should be fully transparent with all cost assumptions explained and documented. | 28 May 2020 | Proposed text incorporated. | |||||||||||||||||||
16 | AAS2.1 | 2 | Anne Aikman-Scalese | 2.10.2 Registrar Non-Discrimination / Registry/Registrar Standardization | “Registries must ue only ICANN accredited registrars in registering domain names and may not discriminate among such accredited registrars, unless an exemption to the Registry Code of Conduct is granted.” | The language appears to permit registries to obtain exemptions from the Code of Conduct to allow them to use unaccredited registrars. I don’t recall this being the thrust of exemptions that were granted in the 2012 round. I believe the exemptions granted in the 2012 round related to issues other than accreditation. Are there currently unaccredited registrars issuing domain name registrations? | Add the following; , provided, however, that no such exemptions shall be granted without public comment and further provided that exemption requests seeking approval of the use of unaccredited registrars will not be granted. | 4 June 2020 | Edited to clarify the original intent of the recomendation. | |||||||||||||||||||
17 | AAS3.1 | 3 | Anne Aikman-Scalese | 2.2.1 Continuing Subsequent Procedures | Sub-section d. | No text exists re external efforts | In light of all the text in Rationale 1 and references to the March 1, 2019 Board Resolution, Section 2.2.1.d. should refer to Jeff Neuman’s letter to the GNSO Council re DNS Abuse | The Working Group Chair has directed a letter to GNSO Council relative to addressing CCT-RT recommendations re DNS Abuse holistically. The letter is dated __________ and is attached to this report as ______________. | 2 June 2020 | Reference to the letter added to Global Public Interest. | ||||||||||||||||||
18 | AAS3.2 | 3 | Anne Aikman-Scalese | 2.2.3 Applications Assessed in Rounds | Implementation Guidance xx (Rationale 2) | “It should not be possible to apply for a string that is still being processed from a previous application round…” | Dissenting Views should be noted in the draft final report with more prominence and particularity as to the rationale for the Dissenting View. | Dissenting View: In recognition Principle G, Applicant Freedom of Expression, timely applications for any string previously applied for but not yet delegated should be permitted, but such applications should not be processed further unless and until the matching string from the previous round has been classified as “Will Not Proceed:”. ADD the following to text on page 28: The stated rationale for the Dissenting View was that applicants from prior rounds would retain too much power to (a) insist on non-compliance with new policy requirements applicable to subsequent procedures and (b) be able to effectively block later applicants for the same string who are willing to comply with new subsequent procedures policy requirements. Examples provided related to evolving name collisions policy and closed generics policy. | 2 June 2020 | Proposed text incorporated with modifications. | ||||||||||||||||||
19 | AAS3.3 | 3 | Anne Aikman-Scalese | 2.2.3 Applications Assessed in Rounds | Recommendation xx (Rationale 2) | “More specifically, prior to the commencement of the next Application Submission Period, ICANN shall publish either (a) the date in which the next subsequent round of new gTLDs will take place or (b) the specific set of criteria and/or events that must occur prior to the opening up of the next subsequent round” | What do we mean by the use of the word, “shall”? Do we mean ICANN “must”? Or ICANN “should”? This is a Recommendation so we need to be very specific. What are the conventions in relation to the use of the terms, “shall”, “must”, and “should” in the draft Final Report? | Suggest we replace “shall” with “must” if that is what we mean. | 2 June 2020 | Proposed text incorporated. | ||||||||||||||||||
20 | JC3.1 | 3 | Justine Chew | 2.2.1 Continuing Subsequent Procedures | b. Rationale for Affirmation xx (rationale 2), pg 25 | A major theme that was repeatedly raised throughout the life cycle of this PDP was the need for predictability for all parties involved. The desire for an “orderly, timely and predictable” New gTLD Program is universally supported. | It is important to recognize that the need for predictability be balanced for all parties involved and should not necessarily default in favour of or against applicants. The universal support for the affirmation is, arguably, predicated on this understanding. For eg, in Section 2.2.3 Applications Assessed in Round, we expressedly mentioned, “Rounds enhance the predictability for applicants (e.g., preparation), the ICANN community and other third-party observers to the program (e.g., public comments, objections)” | A major theme that was repeatedly raised throughout the life cycle of this PDP was the need for balanced predictability for all parties involved. It is on this basis that the desire for an “orderly, timely and predictable” New gTLD Program is universally supported. | 28 May 2020 | Proposed text incorporated. | ||||||||||||||||||
21 | JC3.2 | 3 | Justine Chew | 2.2.1 Continuing Subsequent Procedures | b. Rationale for Affirmation xx (rationale 3), p 25 | The Working Group agreed that fostering consumer choice, consumer trust, and market differentiation should continue to primary focal points for the New gTLD Program. | The word “be” is omitted in the sentence. | The Working Group agreed that fostering consumer choice, consumer trust, and market differentiation should continue to be primary focal points for the New gTLD Program. | 28 May 2020 | Proposed text incorporated. | ||||||||||||||||||
22 | JC3.3 | 3 | Justine Chew | 2.2.3 Applications Assessed in Rounds | a. Implementation Guidance xx (rationale 2), p 26-27 | It should not be possible to apply for a string that is still being processed from a previous application round, specifically: • If a TLD has already been delegated, no application for that string will be allowed for a string in a subsequent round. …. • …. • If all applications for a particular string have been Withdrawn, meaning the string has not been delegated, new applications for the string will be allowed in a subsequent round. • If a Registry Operator has terminated its Registry Agreement and (i) the TLD has not been reassigned to a different Registry Operator, and (ii) in the case of a Specification 13 Brand TLD, it is more than 2 years following the Expiration Date (See RA Section 4.5(a)), then applications will be allowed to be submitted during a subsequent round. • …. • If a TLD has a status of “Not Approved”, an application for the TLD will only be allowed if ….. (see far right column for remaining text) | The phrasing and/or formatting of ths Implementation Guidance is confusing and problematic insofar as the affirmative is mixed with the negative. It starts off with, “It should not be possible to apply for a string that is still being processed from a previous application round, specifically:…” and, • the 1st bullet deals with delegated strings - doesn’t delegation constitute the end of processing? Are delegated strings still be considered as being processed? • by the 3rd bullet, it provides for circumstances where a new application will be allowed. • the 4th bullet deals with a delegated TLD for which an RA has been terminated but no reassigned to a different RO – again would this still be considered as being processed? • the 6th and last bullet refers to a TLD that is “Not Approved” - at what point does a string be referred to as a TLD? Are we using “string” and “TLD” interchangeably here? | “Where a TLD has already been delegated, no application for that string will be allowed for a string in a subsequent round. It should in general not be possible to apply for a string that is still being processed from a previous application round, i.e. • If there is an application that has a status of “Active”, “Applicant Support”, “In Contracting”, “On-hold” or “In PDT”, a new application for that string will not be allowed in a subsequent round. However, • If all applications for a particular string have been Withdrawn, meaning the string has not been delegated, new applications for the string will be allowed in a subsequent round. • If a Registry Operator has terminated its Registry Agreement and (i) the TLD has not been reassigned to a different Registry Operator, and (ii) in the case of a Specification 13 Brand TLD, it is more than 2 years following the Expiration Date (See RA Section 4.5(a)), then applications will be allowed to be submitted during a subsequent round. [Not sure where to place this para] • If all applications for a given string have a status of “Will Not Proceed”, an application for the TLD will only be allowed if: o All appeals and/or accountability mechanisms have proceeded through final disposition and no applications for the string have succeeded in such appeals and/or accountability mechanisms; or o All applicable time limitations (statute of limitations) have expired such that all applicants for a particular string would not be in a position to file an appeal or accountability mechanism with respect to the string. • If a TLD has all applications for a given string have a status of “Not Approved”, an application for the TLDstring will only be allowed if: o All appeals and/or accountability mechanisms have proceeded through final disposition and no applications for the string have succeeded in such appeals and/or accountability mechanisms; or o All applicable time limitations (statute of limitations) have expired such that all applicants for a particular string would not be in a position to file an appeal or accountability mechanism with respect to the string; and o The ICANN Board has not approved new policies or procedures that would allow one or more of the applicants from the prior round to cure the reasons for which it was placed in the “Not Approved” category, but has approved new policies or procedures that would allow an applicant to apply for the string in any subsequent round. In the event that there are new policies or procedures put into place which would allow the application of strings which were “Not Approved” in a prior round, the ICANN Board must make a determination as to whether the applicants in the prior round have any preferential rights for those strings at the time such policies or procedures are put into place.” | 2 June 2020 | Proposed text incorporated. | ||||||||||||||||||
23 | JC3.4 | 3 | Justine Chew | 2.2.3 Applications Assessed in Rounds | a. (The 1st) Recommendation xx (see rationale 3), p 27 | Application procedures must take place at predictable, regularly occurring intervals without indeterminable periods of review unless the GNSO Council recommends pausing the program and such recommendation is approved by the Board. Unless and until other procedures are recommended by the GNSO Council and approved by the ICANN Board, ICANN must only use “rounds” as part of the New gTLD Program. | Re: “…. ICANN must only use “rounds” as part of the New gTLD Program.” What does “as part of the New gTLD Program” mean? | Replace “as part of” with “to administer”? | 2 June 2020 | Proposed text incorporated. | ||||||||||||||||||
24 | JC3.5 | 3 | Justine Chew | 2.2.3 Applications Assessed in Rounds | a. (The 2nd) Recommendation xx (see rationale 3) | Absent extraordinary circumstances, future reviews and/or policy development processes, including the next CCT Review, should take place concurrently with subsequent application rounds. In other words, future reviews and/or policy development processes must not stop or delay subsequent new gTLD rounds. | No harm spelling out CCT even though earlier reference made to “Competition, Consumer Choice & Consumer Trust Review Team (CCT-RT) Final Report”. | Absent extraordinary circumstances, future reviews and/or policy development processes, including the next Competition, Consumer Choice & Consumer Trust (CCT) Review, should take place concurrently with subsequent application rounds. In other words, future reviews and/or policy development processes must not stop or delay subsequent new gTLD rounds. | 2 June 2020 | Proposed text incorporated. | ||||||||||||||||||
25 | JC3.6 | 3 | Justine Chew | 2.2.6 RSP Evaluation | Last paragraph of section c. New issue | This last paragraph seems to lack a conclusion. | Perhaps add, “Ultimately, the Working Group did not think a recommendation was necessary.” | 2 June 2020 | Proposed text incorporated. | |||||||||||||||||||
26 | JC3.7 | 3 | Justine Chew | 2.3.4 Universal Acceptance | a. Recommendation xx: | Principle B from the 2007 policy states: “Some new generic top-level domains should be internationalised domain names (IDNs) subject to the approval of IDNs being available in the root.” The Working Group recommends revising Principle B to read: “Some new generic top-level domains should be internationalised domain names (IDNs), although applicants should be made aware of Universal Acceptance challenges in ASCII and IDN TLDs. Applicants must given access to all applicable information about Universal Acceptance currently maintained on ICANN’s Universal Acceptance Initiative page, through the Universal Acceptance Steering Group, as well as future efforts.” | The word “be” is omitted in the last sentence. | Applicants must be given access to all applicable information about Universal Acceptance currently maintained on ICANN’s Universal Acceptance Initiative page, through the Universal Acceptance Steering Group, as well as future efforts. | 2 June 2020 | Proposed text incorporated. | ||||||||||||||||||
27 | JC3.8 | 3 | Justine Chew | 2.3.4 Universal Acceptance | c. New issues, pg 37-38 | There were comments by the ALAC and the BC to the Initial Report that, while have not materialized into standalone recommendations, remain important to include in the Final Report. The basis for these can be derived from an earlier version of deliberations on the topic | “While some commenters thought that no additional work should be proposed beyond that being done through the Universal Acceptance Initiative and by the Universal Acceptance Steering Group, others believe that more can and should be done to further the adoption of Universal Acceptance (UA) Since the primary obstacle to the successful expansion of the domain namespace remains the rejection of these new gTLDs by legacy code, the community and ICANN Org need to involve themselves in more active outreach efforts to explain to third parties the benefits of increasing Internet inclusitivity and diversity in UA to reach Internet end-users. At the same time, ICANN should, at a minimum, require registries and registrars that are owned by the same entity, to be UA ready as part of their application for a new gTLD. This means that their systems should be ready for IDN registrations, ready to handle IDNs and non-IDN new gTLD consistently on nameserves and other machines, be able to manage any Email Address Internationalization (EAI), and to send and receive emails from these types of addresses. ICANN should also require registries and registrars to take affirmative action to ensure UA-readiness in their downstream supply-chains.” | 4 June 2020 | Proposed text incorporated. | |||||||||||||||||||
28 | KK3.1 | 3 | Kathy Kleiman | 2.2.5 Application Submission Limits | c. New issues, pg 37-38 | While a number of responses to public comment supported preliminary recommendations that no application submission limits should be put in place, the Working Group also reviewed and discussed comments that favored placing limits on the number of applications. In particular, the Working Group considered a suggestion that ICANN should allow no more than 24 applications for each company, including its parent company, subsidiaries, and affiliates. The stated goals of this proposal were to increase fairness and allow for adequate oversight and public review. The Working Group did not find a clear rationale for the specific number proposed and did not come to any agreement to move forward with the proposal. | The issue in our discussions wasn’t fairness (I think there was a strong view that allowing a few large players to dominate isn’t fair), but feasibility. How would we enforce limits? How could they be detected if subsidiaries were created? Certainly this issue of ownership has been reviewed and incorporated by other groups – foreign ownership restrictions, for example, on US broadcast stations by the FCC. But it was not something this group found feasible at this time. | While a number of responses to public comment supported preliminary recommendations that no application submission limits should be put in place, the Working Group also reviewed and discussed strong comments that favored placing limits on the number of applications. In particular, the Working Group considered a suggestion that ICANN should allow no more than 24 applications for each company, including its parent company, subsidiaries, and affiliates. The rationale provided for this dissenting view was that potentially unlimited application numbers favored large, existing entities, at odds with the overall goals of encouraging applications for gTLDs from companies and communities around the world. If hundreds, or thousands, of applications are allowed from large companies in developed countries, there will few gTLDs left for the Global South. The stated goals of this proposal were to increase fairness and allow for adequate oversight and public review. The Working Group did not find a clear rationale feasible way to enforce a or the specific number proposed and did not come to any agreement to move forward with the proposal. | 2 June 2020 | Proposed text incorporated with modifications. | ||||||||||||||||||
29 | Valideus3.1 | 3 | Susan Payne/Valideus | 2.2.1 Continuing Subsequent Procedures | b | Rationale for Affirmation xx (rationale 1): The existing policy for New gTLDs states that there will be a “systemized manner of applying for gTLDs to be developed in the long term.” Consistent with its overall approach, the Working Group approached this topic from the standpoint that there must be a compelling reason to recommend altering or superseding the existing policy (e.g., no longer allowing new gTLDs). | The Final Report will contain a number of Affirmations of the existing policy. It makes more sense, and presumably was the intention, to have an overarching/introductory section which explains the Working Group’s overall approach, since this applies not just to this particular affirmation but to all of them. If that is not the case, then the overall approach applied ought to be specified against every other Affirmation the WG makes and not just in this case. | Rationale for Affirmation xx (rationale 1): The existing policy for New gTLDs states that there will be a “systemized manner of applying for gTLDs to be developed in the long term.” In affirming the continuation of this policy the Working Group applied the consistent approach outlined in [Introduction].Consistent with its overall approach, the Working Group approached this topic from the standpoint that there must be a compelling reason to recommend altering or superseding the existing policy (e.g., no longer allowing new gTLDs). | 2 June 2020 | Proposed text incorporated. | ||||||||||||||||||
30 | Valideus3.2 | 3 | Susan Payne/Valideus | 2.2.1 Continuing Subsequent Procedures | b | The Working Group took note of the Competition, Consumer Choice & Consumer Trust Review Team (CCT-RT) Final Report, which states that “on balance the expansion of the DNS marketplace has demonstrated increased competition and consumer choice.” While the Working Group recognizes that some parties believe the New gTLD market to already be saturated, the Working Group did not agree that a compelling reason was identified to override existing policy. | Rationale focuses only on the negative opinion of some that the TLD market is “saturated” and does not also acknowledge that there are also areas of demand, including from among Dot Brands who do not rely on sale of second level names and thus are not impacted by any perceived market saturation at the second level (if this even exists), and would challenge the notion of market saturation at the top level. | The Working Group took note of the Competition, Consumer Choice & Consumer Trust Review Team (CCT-RT) Final Report, which states that “on balance the expansion of the DNS marketplace has demonstrated increased competition and consumer choice.” While the Working Group recognizes that some parties believe the New gTLD market to already be saturated, others have indicated that they are aware of interested potential applicants, including dot Brands. Overall, the Working Group did not agree that a compelling reason was identified to override existing policy. | 2 June 2020 | Proposed text incorporated. | ||||||||||||||||||
31 | JC4.1 | 4 | Justine Chew | 2.7.5 Internationalized Domain Names | Recommendation xx (Rationale 4): IDN gTLDs identified as variants of already existing or applied for TLDs will be allowed provided they have the same registry operator and back-end registry service provider. This policy of cross-variant TLD bundling must be captured in relevant Registry Agreements | The explanation provided by the At-Large IDN WG is as follows, The wording of this recommendation seems to expect that an IDN Variant TLD go through the same "application process“ when in fact any IDN Variant TLD should only be "activated" not "applied for" by the same Registry Operator. This is consistent with how the 2012 round was envisioned and handled. Allowing IDN Variant TLDs to be "applied for" is problematic for the concept of IDN Variants. | Amend to, IDN gTLDs deemed to be variants of already existing or applied for TLDs will not be allowed for separate application and allowed for activation by provided they have the same registry operator and back-end registry service provider. This policy of cross-variant TLD bundling must be captured in relevant Registry Agreements. | 16 June 2020 | Edited with compromise language. | |||||||||||||||||||
32 | JC4.2 | 4 | Justine Chew | 2.7.5 Internationalized Domain Names | Rationale for Recommendation xx (rationale 4): In support of security and stability, and in light of the fact that IDN variants are considered to essentially be identical, the Working Group believes that IDN variant TLDs must be owned and operated by the same Registry Operator and must have the same back-end registry service provider. ….. | A little concern looms over the usage of the word “owned” in the phrase “IDN variant TLDs must be owned and operated by the same Registry Operator …” Does ICANN have a practice of saying that a TLD or IDN variant TLD is owned by a RO? | Is it feasible to say “delegated” instead of “owned”? | 16 June 2020 | Proposed text incorporated with modifications. | |||||||||||||||||||
33 | JP4.1 | 4 | Jim Prendergast | 2.7.8 Name Collisions | Implementation Guidance xx (Rationale 4): ICANN should develop a mechanism or test to determine the name collision risk for any given string. The Working Group suggests putting them into three categories: high risk, aggravated risk, and low risk. High-risk strings should not be allowed to be applied for (if possible) or delegated, and aggravated risk strings should require the inclusion of a specific name collision mitigation framework. | Based on the April 30, 2020 plenary meeting which included SSAC/NCAP Co-chair Jim Galvin, when discussing this particular Implementation Guidance Jim G noted that instead of creating a list of high-risk TLDs, it was more likely that a set of criteria would be established where data could be collected and examined by the Board who would then decide whether or not to delegate a TLD. Galvin reinforced that the SSAC would not decide what can and cannot be delegated. While Jim G admitted that criteria could be manipulated by anyone trying to take advantage of the knowledge of the criteria and influence the data, he also warned against the development of a specific list of TLDs to be prohibited. Ideally that criteria would be available to applicants to use in determining if they can/ should move forward. However, creating a mechanism to determine risk of name collision for new TLDs prior to the application window opening is too easily gamed. As such, I am recommending that this criteria be considered “after the application window closes”. The ICANN Board can examine name collision data for a specific applied for string during the evaluation period and decide whether or not to delegate the string. | The SSAC or NCAP should develop name collision risk criteria and a test to provide information to an applicant for any given string after the application window closes so that the applicant can determine if they should move forward with evaluation. | 16 June 2020 | Edited with compromise language. | |||||||||||||||||||
34 | JP4.2 | 4 | Jim Prendergast | 2.7.8 Name Collisions | Implementation Guidance (Rationale 5): To the extent possible, ICANN should seek to identify high-risk strings in advance of opening the Application Submission Period, which should constitute a “Do Not Apply” list. ICANN should also seek to identify aggravated risk strings in advance, which would be expected to require a specific name collision mitigation framework. However, all applied-for strings should be subject to a DNS Stability evaluation to determine whether they represent a high, aggravated, or low risk of name collision. | Same rationale as above. | To the extent possible, all applied-for strings should be subject to a DNS Stability evaluation to determine whether they represent a high, aggravated, or low risk of name collision. | 16 June 2020 | Edited with compromise language. | |||||||||||||||||||
35 | JP4.3 | 4 | Jim Prendergast | 2.7.8 Name Collisions | Rationale for Affirmation xx (Rationale 3): The Working Group notes that ICANN org, in cooperation with the NCAP Discussion Group, has since completed its Study 1, leveraging an outside consultant. The consultant who produced the Study 1 report made the following draft conclusions relating to Studies 2 and 3: “Regarding Study 2 analyzing datasets is unlikely to identify significant root causes for name collisions that have not already been identified. New causes for name collisions are far more likely to be found by investigating TLD candidates for potential delegation on a case by case basis. Regarding Study 3, the review of prior work has not identified any new mitigation strategies for name collisions to be tested. Also, controlled interruption has already proven an effective mitigation strategy. Without a compelling new mitigation strategy to consider, Study 3 does not seem to be needed at this time.” | The text as currently written does not indicate that the NCAP work is still in progress, and the name collision framework and mitigation may change after the subpro work is complete. | Add this additional quote from the NCAP Study 1 Final Report to the original text in this section: “All of that being said, this does not mean further study should not be conducted into name collision risks and the feasibility of potentially delegating additional domains that are likely to cause name collisions. Most notably, the Study 3 question of how to mitigate name collisions for potential delegation of the corp, home, and mail TLDs is still unresolved. However, the proposals for Studies 2 and 3, which were developed years ago, do not seem to be effective ways of achieving the intended goals.” | 16 June 2020 | Proposed text incorporated. | |||||||||||||||||||
36 | RK4.1 | 4 | Rubens Kuhl | 2.7.7 Applicant Reviews: Technical/Operational, Financial and Registry Services | “That list will include those that are included in the Registry Agreement” | Mismatch between recommendation text and rationale text | “That list will include those that are included in the base Registry Agreement” | 16 June 2020 | Proposed text incorporated. | |||||||||||||||||||
37 | KK4.1 | 4 | Kathy Kleiman | 2.3 Role of Application Comment | Rationale for Recommendation xx and Implementation Guidance xx (rationale 5): | The Working Group notes that if an applicant proposes changes to the application in response to public comments, additional processes apply, including an additional public comment period, where applicable. Please see section xx Application Change Requests for discussion of processes related to changes in the application. | We have asked for ICANN to collect information about the commenters, including email, so it should be relatively easy to notify commenters that, in response to public comment, a proposed change has been made (and fair too). Letting those providing the original comments know that a directly-related change has been proposed to the application and a public comment period has opened seems an easy follow-on to continue the discussion and foster review the proposed change. | The Working Group notes that if an applicant proposes changes to the application in response to public comments, additional processes apply, including an additional public comment period, where applicable. Please see section xx Application Change Requests for discussion of processes related to changes in the application, with notification to the extent possible of those who made the requests for proposed changes. | 11 June 2020 | Original text retained. | ||||||||||||||||||
38 | KK4.2 | 4 | Kathy Kleiman | 2.7.2 Registrant Protections | Recommendation xx (rationale 4): TLDs that have exemptions from the Code of Conduct (Specification 9), including .Brand TLDs qualified for Specification 13, must also receive an exemption from COI requirements or requirements for the successor to the COI. | Recommend few abbreviations – life is hard enough for our readers . | COI –> Conflict of Interest? Continuing Operations Instrument? | 11 June 2020 | Proposed text incorporated. | |||||||||||||||||||
39 | KK4.3 | 4 | Kathy Kleiman | 2.7.2 Registrant Protections | Rationale for Affirmation xx and Implementation Guidance xx (rationale 2): The Working Group notes that PIRR recommendation 2.2.a states: “Consider whether background screening should be performed during IE or at the time of contract execution.” The Working Group reviewed that in the 2012 round, background screening took place during Initial Evaluation. Per the PIRR, | Recommend few abbreviations – life is hard enough for our readers . | PIRR -> I don’t even remember what this means. | 11 June 2020 | Proposed text incorporated. | |||||||||||||||||||
40 | KK4.4 | 4 | Kathy Kleiman | 2.7.4 String Similarity | Applications will not automatically be placed in the same contention set because they appear visually to be a single and plural of one another but have different intended uses. For example, .SPRING and .SPRINGS could both be allowed if one refers to the season and the other refers to elastic objects, because they are not singular and plural versions of the same word. However, if both are intended to be used in connection with the elastic object, then they will be placed into the same contention set. Similarly, if an existing TLD .SPRING is used in connection with the season and a new application for .SPRINGS is intended to be used in connection with elastic objects, the new application will not be automatically disqualified. | Question/clarification: What if they are both open gTLDs without specific use specified; or one is specific use, e.g., elastics, and one is open? | 11 June 2020 | New Implementation Guidance added to address this concern. | ||||||||||||||||||||
41 | AAS3.4 | 3 | Anne Aikman-Scalese | 2.3.3 Applicant Freedom of Expression | Implementation Guidance xx: As the ICANN organization and community incorporate human rights into ICANN’s processes in line with the recommendations of CCWG-Accountability Work Stream 2, they may want to consider the application of this work to elements of the New gTLD Program. | “may want to consider” does not reflect the fact that Accountabily Workstream 2 work is binding on the community and Sub Pro implementation will have to be consistent with that work. | Proposed changes (taking into account whether others would be able to live with them) Change “may want to consider” to “should consider”. | |||||||||||||||||||||
42 | AAS4.1 | 4 | Anne Aikman-Scalese | 2.7.8 Name Collisions | Implementation Guidance xx (Rationale 4): ICANN should develop a mechanism or test to determine the name collision risk for any given string. The Working Group suggests putting them into three categories: high risk, aggravated risk, and low risk. High-risk strings should not be allowed to be applied for (if possible) or delegated, and aggravated risk strings should require the inclusion of a specific name collision mitigation framework. | This language omits the fact that the work of the Name Collision Analysis Project (NCAP) is active and ongoing with weekly conference calls designed to develop further methods of responding to questions posed by the ICANN Board when it passed a Resolution asking the SSAC to address name collision risk. It also fails to acknowledge the fact that during public comment on the Initial Report, the ICANN Board noted the opportunity for the Working Group to work together with the NCAP to resolve issues relative to name collision risk. | “The Working Group acknowledges that the Name Collision Analysis Project work in relation to Board Resolutions _____________ is ongoing and that the Board advised the Working Group in public comment on the Sub Pro Initial Report to work together with the NCAP on the topic of name collisions. Accordingly, Sub Pro Co-Chair Jeff Neuman and some Sub Pro Working Group members are actively participating in the weekly conference calls of the NCAP.” | 16 June 2020 | Proposed text incorporated with modifications. | |||||||||||||||||||
43 | AAS4.2 | 4 | Anne Aikman-Scalese | 2.7.8 Name Collisions | Implementation Guidance (Rationale 5): To the extent possible, ICANN should seek to identify high-risk strings in advance of opening the Application Submission Period, which should constitute a “Do Not Apply” list. ICANN should also seek to identify aggravated risk strings in advance, which would be expected to require a specific name collision mitigation framework. However, all applied-for strings should be subject to a DNS Stability evaluation to determine whether they represent a high, aggravated, or low risk of name collision. | The meaning of “in advance” is unclear. Does this mean develop a standard for measuring collision risk (e.g. a numeric standard based on DITL stats) in advance of the application process or does it mean test each individual string prior to delegation? Name collision risk may not boil down to sheer numbers since the risk assessment includes factors related to whether collisions are more likely to occur at the institutional level or the consumer level, etc. Aggravated risk strings ultimately may or may not be eligible to submit a name collision risk mitigation strategy depending on the upcoming recommendations from the SSAC and the NCAP. All proposed mitigation frameworks should be subject to public comment. | In the interest of predictability, ICANN should also seek to develop criteria for identifying aggravated risk strings in advance of the next application window opening and to publish such criteria in the Applicant Guidebook. ICANN should also develop criteria for determining when an applicant for a collision string may be offered the opportunity to propose a specific name collision mitigation framework. Any such proposed name collision mitigation framework must be subject to public comment. Each applied-for string should be screened for name collision risk in advance of proceeding to further evaluation to determine whether the registration of names in the proposed TLD would pose a high, aggravated, or low risk of name collisions. | 16 June 2020 | Edited with compromise language. | |||||||||||||||||||
44 | AAS4.3 | 4 | Anne Aikman-Scalese | 2.7.8 Name Collisions | Rationale for Affirmation xx (Rationale 3): The Working Group notes that ICANN org, in cooperation with the NCAP Discussion Group, has since completed its Study 1, leveraging an outside consultant. The consultant who produced the Study 1 report made the following draft conclusions relating to Studies 2 and 3: “Regarding Study 2 analyzing datasets is unlikely to identify significant root causes for name collisions that have not already been identified. New causes for name collisions are far more likely to be found by investigating TLD candidates for potential delegation on a case by case basis. Regarding Study 3, the review of prior work has not identified any new mitigation strategies for name collisions to be tested. Also, controlled interruption has already proven an effective mitigation strategy. Without a compelling new mitigation strategy to consider, Study 3 does not seem to be needed at this time.” | The text is incomplete in quoting Study 1 in that it excludes language stating that the author has NOT concluded that there should be no further study into name collision risk. It is also misleading in that it does not reflect the fact that the NCAP is moving forward with work designed to answer the Board’s specific questions re .HOME, .CORP, and .MAIL as well as the Board’s specific questions regarding possible mitigation strategies. | Add this additional quote from the NCAP Study 1 Final Report to the original text in this section: “All of that being said, this does not mean further study should not be conducted into name collision risks and the feasibility of potentially delegating additional domains that are likely to cause name collisions. “ The Working Group has been advised by the Co-Chairs of the NCAP that some (presumably redesigned) versions of Studies 2 and 3 are necessary in order to properly address questions posed by the Board to the SSAC. | 16 June 2020 | Proposed text incorporated. | |||||||||||||||||||
45 | AAS4.4 | 4 | Anne Aikman-Scalese | 2.7.5 IDNs | Recommendation xx (Rationale 4): IDN gTLDs identified as variants of already existing or applied for TLDs will be allowed provided they have the same registry operator and back-end registry service provider. This policy of cross-variant TLD bundling must be captured in relevant Registry Agreements. | Clarifying Question: Do we mean here that in the next round, no one can apply for “.casino” in Cyrillic script or .bible” in Hebrew script and that any TLD that exists now in the root bars all applications by a third parties for the spelling/translation of that string in a different script? In other words, that only the original applicant may activate the equivalent idn? | 16 June 2020 | Footnote added pointing to the definition of variant. See Recommendation xx (rationale 2), which is the first place that variants are mentioned in the section. | ||||||||||||||||||||
46 | RK5.1 | 5 | Rubens Kuhl | 2.7.1 Reserved Names | The Working Group supports continuing to reserve as unavailable for registration those strings that are currently considered Reserved Names at the second level as of the publication date of this report and as required by future Consensus Policy. | Text would freeze 2nd level reserved names as they are today, not accounting for possible changes, as described in one rationale for this section that correctly foresees the list to be updated. | The Working Group supports subsequent procedures gTLDs continuing to follow the same schedule of reserved names at registration level(s) that 2012 gTLDs have to follow, which might change from time to time. | 18 June 2020 | Edited with compromise language. | |||||||||||||||||||
47 | RK5.2 | 5 | Rubens Kuhl | 2.7.1 Reserved Names | The Working Group further affirms that strings that were unavailable at the top level in the 2012 round should remain unavailable and that strings at the second level that are currently unavailable should remain unavailable. | Text would freeze 2nd level reserved names as they are today, not accounting for possible changes, as described in one rationale for this section that correctly foresees the list to be updated. | The Working Group further affirms that strings that were unavailable at the top level in the 2012 round should remain unavailable and that strings at the second level that are unavailable in 2012 gTLDs at a given time should also be unavailable in subsequent procedures gTLDs at that moment. | 18 June 2020 | Edited with compromise language. | |||||||||||||||||||
48 | RK5.3 | 5 | Rubens Kuhl | 2.8.2 Limited Challenge/Appeal Mechanism | https://docs.google.com/spreadsheets/d/1R4eU7C-HI5ikF5RtVhp5JRXKVVRn6R8WX8fIU0IOwu8/edit#gid=0 Tab 1, cell E14, For challenge of Registry Services Evaluation decision, the arbiter of the challenge is currently listed as: "Existing evaluator entity - different ultimate decision maker(s) within the entity." | RSTEP is not done by entities, so the arbiter of challenge needs to be changed | New panel with different RSTEP panelists selected from the standing roster | 29 June 2020 | ||||||||||||||||||||
49 | KK5.1 | 5 | Kathy Kleiman | 2.8.2 Limited Challenge/Appeal Mechanism | Recommendation xx (rationale 2): The Working Group recommends that ICANN establish a mechanism that allows specific parties to challenge or appeal certain types of actions or inactions that are inconsistent with the Applicant Guidebook. | It’s not inconsistent with the Applicant Guidebook until there is a finding as such. Until then, the applicant is making an allegation! | Recommendation xx (rationale 2): The Working Group recommends that ICANN establish a mechanism that allows specific parties to challenge or appeal certain types of actions or inactions that are appear to be inconsistent with the Applicant Guidebook. | 25 June 2020 | Proposed text incorporated. | |||||||||||||||||||
50 | KK5.2 | 5 | Kathy Kleiman | 2.8.2 Limited Challenge/Appeal Mechanism | The Working Group recommends that the limited challenge/appeal mechanism applies to the following types of evaluations and objections decisions: | The term “formal objection” comes from the current AGB (see current Module 3) and it may help to flag readers to understand the important distinction of evaluation changes and objection appeals – a clarity issue. | The Working Group recommends that the limited challenge/appeal mechanism applies to the following types of evaluations and formal objections decisions: | 25 June 2020 | Proposed text incorporated. | |||||||||||||||||||
51 | KK5.3 | 5 | Kathy Kleiman | 2.8.2 Limited Challenge/Appeal Mechanism | Appeals of Objections Decisions | The term “formal objection” comes from the current AGB (see current Module 3) and it may help to flag readers to understand the important distinction of evaluation changes and objection appeals – a clarity issue. | Appeals of Formal Objections Decisions | 25 June 2020 | Proposed text incorporated. | |||||||||||||||||||
52 | KK5.4 | 5 | Kathy Kleiman | 2.8.2 Limited Challenge/Appeal Mechanism | Footnote 96 | In section xx Objections, the Working Group recommends that parties to an objections proceeding have the opportunity to mutually agree on whether to use a single panelist or a three-person panel, bearing the costs accordingly. This recommendation extends the same opportunity for appeals of objections decisions. | Question | What if the parties don’t agree, e.g., one wants a single panelist (or that is all they can afford) and the other party(ies) want three panelists? Default perhaps one panelist? | 25 June 2020 | Clarification text added to IG. | ||||||||||||||||||
53 | KK5.5 | 5 | Kathy Kleiman | 2.8.2 Limited Challenge/Appeal Mechanism | subsection b | In general, the Working Group believes that parties affected by an evaluation or objections decision should have the opportunity to file a challenge/appeal. | Should not be controversial; we opened only a limited right of appeal. Best to flag it as such. | In general, the Working Group believes that parties affected by an evaluation or objections decision should have the opportunity to file a challenge/appeal under limited circumstances. | 25 June 2020 | Proposed text incorporated. | ||||||||||||||||||
54 | KK5.6 | 5 | Kathy Kleiman | 2.8.1 GAC Consensus Advice and GAC Early Warning | Application changes would be subject to evaluation by ICANN as discussed in section xx Application Change Requests. | Should not be controversial; many application changes reviewed by ICANN are also reviewed by the Community. Just clarifying here. | Application changes would be subject to evaluation by ICANN and the Community as discussed in section xx Application Change Requests. | 29 June 2020 | Proposed text incorporated with modifications. | |||||||||||||||||||
55 | JC5.1 | 5 | Justine Chew | 2.7.1 Reserved Names | approx page 76 | Recommendation xx (rationale 3): The Working Group recommends reserving as unavailable for delegation at the top level the acronym associated with Public Technical Identifiers, “PTI”. | It is noted that discussion in the WG led to a recommendation for just the acronym “PTI” be reserved as unavailable for delegation at the top level. However, given that the PTI is a core service that the Internet relies on, the At-Large thinks that “PUBLICTECHNIDENTIFIER” and “PUBLICTECHNICALIDENTIFIERS” should also be recommended to be reserved and unavailable for delegation at the top level, which is consistent with preliminary recommendation 2.7.1.c.1 of the SubPro Initial Report. Recommending that they be reserved would disallow them from being applied which is more optimal than subjecting the ICANN community to a need to file objections against any applications for PUBLICTECHNCALIDENTIFIER” and/or “PUBLICTECHNICALIDENTIFIERS”, and to altogether avoid any risk of misuse of these strings. | The Working Group recommends reserving as unavailable for delegation at the top level the strings “PUBLICTECHNICALIDENTIFIER”, “PUBLICTECHNICALIDENTIFIERS” and “PTI”, all of which are associated with Public Technical Identifiers. | 18 June 2020 | Original text retained. | ||||||||||||||||||
56 | JC5.2 | 5 | Justine Chew | 2.7.1 Reserved Names | approx page 77 | Rationale for Recommendation xx (rationale 3): The Working Group considered that Public Technical Identifiers (PTI) was incorporated in August 2016 as an affiliate of ICANN with the primary responsibility of operating the IANA functions. The acronym “PTI” is not included in the list of unavailable/reserved names from the 2012 round because PTI had not yet been established at the time the list was developed. The Working Group recommends that for subsequent procedures, the string “PTI” should be reserved and unavailable for delegation at the top level. | The proposed change (on the right) corresponds to the change to the above Recommendation xx (rationale 3). | The Working Group considered that Public Technical Identifiers (PTI) was incorporated in August 2016 as an affiliate of ICANN with the primary responsibility of operating the IANA functions. The strings associated with PTI, namely “PUBLICTECHNICALIDENTIFIER” and “PUBLICTECHNICALIDENTIFIERS”, as well as its acronym “PTI”, are not included in the list of unavailable/reserved names from the 2012 round because PTI had not yet been established at the time the list was developed. The Working Group recommends that for subsequent procedures, the strings PUBLICTECHNICALIDENTIFIER”, “PUBLICTECHNICALIDENTIFIERS” and “PTI” should be reserved and unavailable for delegation at the top level. | 18 June 2020 | Original text retained. | ||||||||||||||||||
57 | JC5.3 | 5 | Justine Chew | 2.8.2 Limited Challenge/Appeal Mechanism | approx page 78 | Affirmation xx (rationale 1): The Working Group affirms Recommendation 12 from 2007, which states: “Dispute resolution and challenge processes must be established prior to the start of the process.” | Insofar as the topic of Objections serves as an antecedent to this topic of Limited Challenge/Appeal Mechanism, is there an inconsistency with the approach the WG is taking in (possibly) affirming Recommendation 12 with modification under the topic of Objections? | Perhaps, adopt the (final) text for the affirmation of Recommendation 12 under “Objections”? | 25 June 2020 | Proposed text incorporated. | ||||||||||||||||||
58 | JC5.4 | 5 | Justine Chew | 2.8.2 Limited Challenge/Appeal Mechanism | approx page 81 | Rationale for Affirmation xx (rationale 1): The Working Group believes that it is important for New gTLD Program elements to be predictable for applicants and other interested parties. By establishing dispute resolution and challenge processes in advance, ICANN provides a greater degree of predictability. Therefore, the Working Group affirms Recommendation 12 from the 2007 policy. | As above | Pending clarification. | 25 June 2020 | Rationale updated to be consistent with updated Affirmation with modification. | ||||||||||||||||||
59 | JC5.5 | 5 | Justine Chew | 2.8.2 Limited Challenge/Appeal Mechanism | approx page 80 | Implementation Guidance xx (rationale 5): The type of decision that may be challenged/appealed should vary depending on the process being challenged/appealed. The Working Group’s guidance on this issue is summarized in Annex xx. | The nature of this intervention is more inquisitorial at this point and as pointed out earlier, the topic of Limited Challenge/Appeal Mechanism with Annex xx is very much connected to the topic of Objections. I am happy to take this up again when we consider the topic of Objections provided that Annex xx is still open for further edits. The key question here is whether the draft recommendation and/or Implementation Guidance under Objections which confirms the ALAC as an established institution for the purposes of a Community Objection, altogether removes any requirement on the part of the DRSP to find on the issue of standing to object vis a vis the ALAC. If the answer is yes, then Annex xx is necessarily complete. If the answer is no, then Annex xx may need to be clarified to include “standing” as a ground of appeal. | Pending clarification. | 25 June 2020 | Text added to summary table that will be included as an Annex to this section, currently available here: https://docs.google.com/spreadsheets/d/1R4eU7C-HI5ikF5RtVhp5JRXKVVRn6R8WX8fIU0IOwu8/edit#gid=0 | ||||||||||||||||||
60 | JC5.6 | 5 | Justine Chew | 2.4 Application Change Request | approx page 90 | N/A | In the interest of transparency and predictability, it should be clarified if application change requests are allowed immediately after close of the application period and when all applied-for strings and corresponding applicants are revealed. Where permissible, we should consider allowing applicants which have applied for exactly matching strings or strings which in their belief run the risk of being confusingly similar an opportunity to delay their evaluation/reviews pending submission of an applicant change request on the basis of business combination or other forms of joint ventures. Having to evaluate just the new combined venture or entity will help avoid need for re-evaluation, also save time and costs. Withdrawals of application and corresponding refunds should be allowed. | Implementation Guidance xx (rationale 3): Insofar as it is feasible, ICANN org should explore the possibility of allowing applicants to delay evaluation pending early submission of an applicant change request on the basis of business combination or other forms of joint ventures, so as to facilitate evaluation (instead of re-evaluation) of the new combined venture or entity, in an effort to save time and cost. | 29 June 2020 | Proposed text incorporated with modifications. | ||||||||||||||||||
61 | JC5.7 | 5 | Justine Chew | 2.4 Application Change Request | approx page 92 | Rationale for Recommendation xx (rationale 3): The Working Group sees merit in allowing applicants in a contention set to form a joint venture and make corresponding changes to the application. ….. the need for auctions of last resort. ^^ The Working Group notes that Module 6 of the Applicant Guidebook, …. | The proposed change (to the right) is to account for the above new Implementation Guidance xx (rationale 3). | Rationale for Recommendation xx and Implementation Guidance xx-xx (rationale 3): The Working Group sees merit in allowing applicants in a contention set to form a joint venture and make corresponding changes to the application. …... the need for auctions of last resort. The Working Group further suggests that ICANN org explore the possibility of allowing applicants to delay evaluation pending early submission of an applicant change request on the basis of business combination or other forms of joint ventures, so as to facilitate evaluation (instead of re-evaluation) of the new combined venture or entity, in an effort to save time and cost. The Working Group notes that Module 6 of the Applicant Guidebook, ….. | 29 June 2020 | Proposed text incorporated with modifications. | ||||||||||||||||||
62 | JC5.8 | 5 | Justine Chew | 2.4 Application Change Request | approx page 92 | Recommendation xx (rationale 4): The Working Group see merit in allowing .Brands in contention to change their applied-for string, noting the importance of having appropriate guardrails in place to avoid gaming. Applicants will be given the opportunity to continue with the application process for a string linked to their brand without the need for an auction of last resort to resolve contention. Process guardrails ensure that changes in the applied-for string occur only under narrow circumstances, limit impact on the New gTLD Program more broadly, and are subject to public comment and objections processes. …… | For greater comfort, the sentence “Applicants will be given the opportunity to continue with the application process for a string linked to their brand without the need for an auction of last resort to resolve contention.” must be expressly tied to a .Brand context and contingent on the process guardrails described. As it stands, that sentence is too open-ended. | Recommendation xx (rationale 4): The Working Group see merit in allowing .Brands in contention to change their applied-for string, noting the importance of having appropriate guardrails in place to avoid gaming. Applicants of .Brand strings will be given the opportunity to continue with the application process for a change in string that is linked to their brand without the need for an auction of last resort to resolve contention, contingent on process guardrails which ensure that changes in the applied-for string occur only under narrow circumstances, limit impact on the New gTLD Program more broadly, and are subject to public comment and objections processes….. | 29 June 2020 | Proposed text incorporated. | ||||||||||||||||||
63 | JC5.9 | 5 | Justine Chew | 2.5.4 Applicant Support | approx page 100 | Recommendation xx (rationale 2): ….. In addition, the Working Group recommends that ICANN continue to facilitate non-financial assistance including the provision of pro-bono assistance to applicants in need…… | The At-Large considers the use of the expression “continue to facilitate” to be insufficient because CCT-RT Recommendation 31 suggests that ICANN org not merely facilitate, but to coordinate the pro-bono assistance program. We believe this means that ICANN org must actively encourage the participation of parties wishing to offer pro-bono assistance as well as coordinate communication between those parties and applicants in need to ensure that those applicants have effective access to pro-bono assistance and not be left with just a list of offerors, which was what happened with the 2012 round. | Recommendation xx (rationale 2): ….. In addition, the Working Group recommends that ICANN proactively manage the pro bono assistance program by not only encouraging the provision of non-financial pro-bono assistance but also by coordinating communication in respect of the provision of pro-bono assistance to and uptake by applicants in need. | 29 June 2020 | Edited with compromise language. | ||||||||||||||||||
64 | JC5.10 | 5 | Justine Chew | 2.5.4 Applicant Support | approx page 104 | Rationale for Affirmation xx with modification (rationale 2): … as was the case in the 2012 round. The Working Group further supports ICANN’s continued facilitation of non-financial pro-bono assistance to applicants in need. The Working Group believes …. | The proposed change (to the right) corresponds to the change to the above Recommendation xx (rationale 2). | Rationale for Affirmation xx with modification (rationale 2): … as was the case in the 2012 round. The Working Group believes that ICANN has to proactively manage the pro bono assistance program to increase the program’s utility and accessibility to applicants in need. Specifically, ICANN must actively encourage the participation of parties wishing to offer pro-bono assistance as well as coordinate communication between those parties and applicants in need to maximize uptake by applicants in need. | 29 June 2020 | Edited with compromise language. | ||||||||||||||||||
65 | JC5.11 | 5 | Justine Chew | 2.5.4 Applicant Support | approx page 100 | Recommendation xx (rationale 4): The Working Group recommends that ICANN improve outreach, awareness-raising, application evaluation, and program evaluation elements of the Applicant Support Program, as proposed in the Implementation Guidance below. | At-Large considers the element of education around viable business models for applicants as identified by the AMGlobal Study is also important to increase the utility of the ASP for potential ASP applicants. | Recommendation xx (rationale 4): The Working Group recommends that ICANN improve utility, outreach, awareness-raising, application evaluation, and program evaluation elements of the Applicant Support Program, as proposed in the Implementation Guidance below. | 29 June 2020 | Edited with compromise language. | ||||||||||||||||||
66 | JC5.12 | 5 | Justine Chew | 2.5.4 Applicant Support | 101 | Implementation Guidance xx (rationale 4): In implementing the Applicant Support Program for subsequent rounds, the dedicated Implementation Review Team should draw on experts with relevant knowledge, including from the targeted regions, to develop appropriate program elements related to outreach, education, and application evaluation. Regional experts may be particularly helpful in providing insight on the evaluation of business plans from different parts of the world. | The proposed change (to the right) corresponds to the change to the above the above Recommendation xx (rationale 4). | Implementation Guidance xx (rationale 4): In implementing the Applicant Support Program for subsequent rounds, the dedicated Implementation Review Team should draw on experts with relevant knowledge, including from the targeted regions, to develop appropriate program elements related to outreach, education (including education on business models, for e.g. through different business case studies), and application evaluation. Regional experts may be particularly helpful in providing insight on the evaluation of business plans from different parts of the world. | 29 June 2020 | Edited with compromise language. | ||||||||||||||||||
67 | JC5.13 | 5 | Justine Chew | 2.5.4 Applicant Support | 104 | Rationale for Recommendation xx and Implementation Guidance xx-xx (rationale 4): ….. The Working Group reviewed and discussed recommendations contained in the report “New gTLDs and the Global South: Understanding Limited Global South Demand in the Most Recent new gTLD Round and Options Going Forward” by AMGlobal, …. The AMGlobal Report emphasizes the importance of timely and effective outreach and communications regarding the New gTLD Program to better reach potential applicants in the Global South and emerging markets. The Working Group believes that similar conclusions can be made about the Applicant Support Program. | The proposed change (to the right) corresponds to the change to the above the above Recommendation xx (rationale 4) and Implementation Guidance xx (rationale 4). | Rationale for Recommendation xx and Implementation Guidance xx-xx (rationale 4): ….. The Working Group reviewed and discussed recommendations contained in the report “New gTLDs and the Global South: Understanding Limited Global South Demand in the Most Recent new gTLD Round and Options Going Forward” by AMGlobal, …. The AMGlobal Report emphasizes the importance of timely and effective outreach and communications, and business model education regarding the New gTLD Program to better reach potential applicants in the Global South and emerging markets. | 29 June 2020 | Edited with compromise language. | ||||||||||||||||||
68 | JC5.14 | 5 | Justine Chew | 2.5.4 Applicant Support | 104 | Rationale for Recommendation xx and Implementation Guidance xx-xx (rationale 6): There will need to be a clear plan in place for funding the Applicant Support Program. ICANN will need to evaluate the extent to which funds will be provided from the ICANN org budget and if additional funding is needed, should consider additional funding sources. | Securing funding for the ASP is critical to its chance for success. In anticipation of more applicants for ASP in the next round, there should be concerted effort to raise more than the USD2mil allocated in the last round. In this respect, stronger language with more concrete exploratory steps is needed to compel securing of such funding. | Rationale for Recommendation xx and Implementation Guidance xx-xx (rationale 6): There will need to be a clear plan in place for funding the Applicant Support Program. ICANN will need to evaluate the extent to which funds will be provided from the ICANN org budget and if additional funding is needed, should consider additional funding sources. In this respect, ICANN org should actively inform, encourage and liaise with National banks and aid agencies worldwide to participate in sponsoring applicants or funding for the Applicant Support Program, as well as to take steps to structure a mechanism to implement joint financing. | 29 June 2020 | Original text retained. | ||||||||||||||||||
69 | JC5.15 | 5 | Justine Chew | 2.5.4 Applicant Support | 107 | c. New issues raised in deliberations since publication of the Initial Report, if applicable. | Reference to the ALAC/At-Large proposal that an applicant that qualifies for ASP be given priority in any string contention set, and not be subjected to any further string contention resolution process is omitted. Unsure if this omission was intended because of the latest deliberation on a multiplier/bid credit for applicants which qualify for ASP. | The Working Group considered a comment submitted by the ALAC during the call for public comments to the Initial Report which proposed for an applicant that qualifies for ASP to be given priority in any string contention set, and not be subjected to any further string contention resolution process. While the Working Group noted that applicants which apply for applicant support would be consider themselves as applicants in need of financial support and therefore less likely to possess the financial wherewithal to succeed in an auction of last resort, the Working Group did not come to an agreement on the ALAC’s proposal. Instead, the Working Group preferred to consider the ALAC’s secondary proposal for the provision of a multiplier (or equivalent) to help applicants which qualified for applicant support to effectively compete in auctions of last resort against other applicants in their string contention sets that are better resourced and not in need of financial support. | 29 June 2020 | Concept to be incorporated into additional text that will be added to this section and released with package 7. Additional text will also reflect recent discussions regarding the bid multiplier concept. | ||||||||||||||||||
70 | JC5.16 | 5 | Justine Chew | 2.7.1.2 Geographic Names | Submission of a dissenting view, while reserving the right to edit the same depending on how and where this view is to be inserted. | As members of Work Track 5, we would like to take this opportunity to offer the following dissenting view to this WT5 report. We note that much effort was expended during WT5 deliberations to resolve the issue of whether an application for a string falling within categories with geographic meaning which are not included in the 2012 AGB should be accompanied by a letter of non-opposition or support from the appropriate administration of the place that the name refers to, in addition to cases where this requirement already applies according to the 2012 AGB. In the final days of the process, a modified proposal was submitted that, instead of asking for a letter of non-opposition, sought that a notification of the intention to use the string with geographic meaning be sent to the appropriate administration. There was a straw poll that indicated that this proposal had wide support in the group. Even that was not accepted by WT5. A mention of this proposal made its way to the Montreal communiqué of the GAC, but not as a consensus advice: In order to facilitate the processing of future applications for gTLDs, many GAC members expressed interest in the development of a tool that would provide timely notifications to GAC Members of strings that consist in geographic names, drawing inspiration as appropriate from the existing tool for the 2-character codes. Even at this late stage, it is worth pointing out that many At-Large members who participated in WT5 were - and are - also interested in a “tool” that would fulfill the need of what could be described an elementary courtesy from the part of the applicant - not only towards the appropriate administration of the place concerned, but also the internet end users and the entire local multistakeholder community for whom local and regional names have a special significance. If the intended use of the string/name is associated with the place and its inhabitants, such an approach would seem a natural part of good business practices. We feel that this has been a major lost opportunity for ICANN and internet users in general and wish to register our extreme disappointment. Signed: Justine Chew Yrjö Länsipuro Marita Moll | 2 July 2020 | Original text retained. | ||||||||||||||||||||
71 | CW5.1 | 5 | Christopher Wilkinson | 2.7.1.2 Geographic Names | Introduction | The final product of work completed | WT5 did not achieve anything like what iot was set up to do. WT5 itself refers to “any future discussions” | Import paragraph on p12 into the Introduction | 2 July 2020 | Original text retained. | ||||||||||||||||||
72 | CW5.2 | 5 | Christopher Wilkinson | 2.7.1.2 Geographic Names | Introduction | …unless there was agreement recommende4d maintaining the rules included in the 2012 AGB | This premise was repeatedly used tp block necessary changes.- There are about eight specific instances in the WT5 Report where 'no agreement' blocks well argued amnd necessaroy changes. | Please cite explicit authority for this premise which severely devalues the merits of the report as a whole. Matters of disagreement should initially be referred to the PDP as a whole. | 2 July 2020 | Original text retained. | ||||||||||||||||||
73 | CW5.3 | 5 | Christopher Wilkinson | 2.7.1.2 Geographic Names | Sec. 2.2.1.4.2 (p.6) | Thus City names are not univers-ally protected. | On the contrary, some city names ARE legally. For those that are not, the public have a moral right to their use, whereas the typical applicant has no rights to them, whatsoever. | State explicitly that a major objective of WT5 was to develop rules applicable to all geo-names, and that until that can be done, application windows for geo names should be deferred. | 2 July 2020 | Original text retained. | ||||||||||||||||||
74 | CW5.4 | 5 | Christopher Wilkinson | 2.7.1.2 Geographic Names | 2(c) Vacant (p.7) | 2012 implementation | The fact that the 2012 AGB failed to address all the OTHER geo-names was the source of significant problems, and for some participants was the primary reason for participating in WT5. | Reconvene WT5 with a new Terms of Reference: in the absence of agreement, future application windows for geo-names will be deferred. | 2 July 2020 | Original text retained. | ||||||||||||||||||
75 | CW5.5 | 5 | Christopher Wilkinson | 2.7.1.2 Geographic Names | D. Rationale | August 2007 (p. 11) | The reference to the 2007 GNSO text is a distraction. That policy was wrong in several respects and unfortunately had to be corrected 'on the hoof' Furthermore, the intervening Transition has transformed the nature and scope of the ICANN community concerned. | The whole WT5 report shouild have taken as base-line the 2012 Implementation, only. | 2 July 2020 | Original text retained. | ||||||||||||||||||
76 | CW5.6 | 5 | Christopher Wilkinson | 2.7.1.2 Geographic Names | E. New Issues (p. 14) | …their understanding of international law… | The ICANN Articles of Incorporation refer to applicable Local Law. | Refer to the obligation on the ICANN community and ICANN.org to look beyond international law to applicable local law. | 2 July 2020 | Original text retained. | ||||||||||||||||||
77 | CW5.7 | 5 | Christopher Wilkinson | 2.7.1.2 Geographic Names | Addn'l deliber-ations (p. 20) | Early Renewal Process | We know from several sources that GAC will require early warning of applications for geographical names. WT5 is misguided to reject this proposal. | Implement early warning in support of prior authorization or non-objection to applications for geographical names | 2 July 2020 | Original text retained. | ||||||||||||||||||
78 | CW5.8 | 5 | Christopher Wilkinson | 2.7.1.2 Geographic Names | 3. Non Capital City Names (p. 24) | The work track did not reach any agreement… | Authorisation or non-objection should be obtained for ALL applications for geographical names, whatever the purpose, including .brands The political consequences of the present situation will prove to be unacceptable. | The WT proposes rules for authorisation or non-objection | 2 July 2020 | Original text retained. | ||||||||||||||||||
79 | CW5.9 | 5 | Christopher Wilkinson | 2.7.1.2 Geographic Names | 4.Conten-tion sets (p. 25) | …no agreement within the WT | The applicant for geo-purposes should benefit from Preference. | Propose preference for use for geographic purposes. | 2 July 2020 | Original text retained. | ||||||||||||||||||
80 | JC6.1 | 6 | Justine Chew | 2.8.1 Objections | Recommendation xx (rationale 3): For all types of objections, the parties to a proceeding must be given the opportunity to mutually agree upon a single panelist or a three-person panel, bearing the costs accordingly. | Just flagging: What is the conclusion to the question raised of what happens if parties do not agree on a single panelist or 3-person panel? | Awaiting proposed changes to the same question from a topic under Package 5. | 6 July 2020 | Clarification text added. | |||||||||||||||||||
81 | JC6.2 | 6 | Justine Chew | 2.8.1 Objections | Implementation Guidance xx (rationale 4): All criteria to be used by panelists for the filing of, response to, and evaluation of each objection, should be included in the Applicant Guidebook. | Question on language: Why would there be criteria used by panelists to file objections? | Subject to clarification. | 6 July 2020 | Clarification text added. | |||||||||||||||||||
82 | JC6.3 | 6 | Justine Chew | 2.8.1 Objections | Rationale for Affirmations xx-xx and Implementation Guidance xx (rationale 1): 2nd para ….The Working Group expressed concerns about the effectiveness and execution of the Independent Objector (IO), but believes that the role should be maintained, with similar rules and procedures in place, though it notes that stricter adherence to constraints may improve effectiveness | Question on language: What does “and execution of the Independent Objector” mean? | Subject to clarification. | 6 July 2020 | Clarification text added. | |||||||||||||||||||
83 | JC6.4 | 6 | Justine Chew | 2.9.1 Community Applications | • Implementation Guideline xx (rationale 2): To support predictability, the CPE guidelines, or as amended, should be considered a part of the policy adopted by the Working Group. • Implementation Guideline xx (rationale 3): ICANN org should examine ways to make the CPE process more efficient in terms of costs and timing. • c. New issues raised | Not disagreeing with the text but taking the opportunity to table a document, “Revised Community Priority Evaluation Guidelines – A Proposal by At-Large” which is At-Large’s amendment of the CPE guidelines of 27 Sep 2013, and which could be useful as Implementation Guidance. | Please refer to the “Revised Community Priority Evaluation Guidelines – A Proposal by At-Large”. This version of 11 June may be subject to amendment by At-Large but if that happens, then the updated version would likely be shared vide ALAC’s response to the upcoming public comment process for the Final Report. NB. There is a second document “At-Large Interventions on Community-based Applications and Community Priority Evaluation” which includes, inter alia: - some high level explanation on key amendments to the CPE guidelines of 27 Sep 2013) - desired criteria for a CPE provide/panelists A solution to JC6.3 could be to insert a paragraph under c. New Issues, along the lines of: On 30 June 2020, a Working Group member provided input from the At-Large comprising a series of proposed improvements to Community Priority Evaluation in subsequent procedures. The input [footnote1], calls for, among other things, greater community participation in ICANN’s engagement of a CPE service provider / panelists, changes to the CPE process including the provision of an interlocutory mechanism for addressing claims of conflicts of interest of panelists, the elimination of a supplementary call for documented support or opposition, as well as the introduction of a limited challenge/appeal mechanism against evaluations of panelists. The input also includes proposed changes to the CPE criteria and guidelines, specifically a full revision of the CPE Guidelines from 2012 [footnote2], which provides for a broader, more flexible interpretation of "community", inclusion of community expertise input in evaluation panels, adjustments to CPE criteria, sub-criteria and scoring guidelines to eliminate undue bias against unconventional communities (eg. Human Rights-based groups; minority, linguistic, cultural, ethnic groups), guarding against imbalance by panelists in considering opposition and support for applications, and lowering of the threshold to prevail in CPE. [footnote1: “At-Large Interventions on Community-based Applications and Community Priority Evaluation” (https://community.icann.org/download/attachments/111390697/01C.%20At-Large%20Interventions%20on%20CBA%20%26%20CPE%20as%20at%2011.06.2020.pdf?version=1&modificationDate=1592012475000&api=v2) ] [footnote2: “Revised Community Priority Evaluation Guidelines – A Proposal by At-Large” (https://community.icann.org/download/attachments/111390697/01B.%20CPE%20Guidelines%20-%20At-Large%20Proposal%2011.06.2020.pdf?version=1&modificationDate=1592012489000&api=v2) ] | 6 July 2020 | Original text retained. Public comment will be submitted. | |||||||||||||||||||
84 | JN6.1 | 6 | Jeff Neuman | 2.7.3 Closed Generics | 2.7.3 (a) | Response to Group Concerns on “Ban” Language. | 1. No Agreement: The Working Group notes that in the 2012 round of the New gTLD Program, a decision was made by the ICANN Board to require applicants for exclusive generic strings to either (a) “submit a change request to no longer be an exclusive generic TLD”, (b) “withdraw their application” or (c) “maintain their plan to operate an exclusive generic TLD,” which would operate to defer their application to the next round of the New gTLD Program, subject to rules developed for the next round, to allow time for the GNSO to develop policy advice concerning exclusive generic TLD.” All applicants in 2012 chose either options (a) or (b). It is the understanding of the Working Group that the ICANN Board intended that its decision to not allow Closed Generics to proceed in the 2012 round applied only to the 2012 round and that it wanted the GNSO to engage in policy discussions regarding the treatment of such strings in subsequent rounds. Although the Working Group has had numerous discussions about this topic, and received extensive comments from the community, including members of the Governmental Advisory Committee, the Working Group was not able to agree as to how to treat these applications in subsequent rounds. | 6 July 2020 | Edited with compromise language. | |||||||||||||||||||
85 | JN6.2 | 6 | Jeff Neuman | 2.7.3 Closed Generics | 2.7.3 (b): On 21 June 2015, the ICANN Board passed a resolution that effectively banned Exclusive Generic / Closed Generic TLDs in the 2012 round. In addition, the Board requested that the GNSO consider this topic in future policy development work for subsequent procedures. The GNSO Council has in turn charged the Working Group with analyzing the impact of Closed Generics and considering future policy | Response to Group Concerns on “Ban” Language. | 2. On 21 June 2015, the ICANN Board passed a resolution that required applicants for exclusive generic strings to either (a) “submit a change request to no longer be an exclusive generic TLD”, (b) “withdraw their application” or (c) “maintain their plan to operate an exclusive generic TLD,” which would operate to defer their application to the next round of the New gTLD Program, subject to rules developed for the next round, to allow time for the GNSO to develop policy advice concerning exclusive generic TLD.” In addition, the Board requested that the GNSO consider this topic in future policy development work for subsequent procedures. The GNSO Council has in turn charged the Working Group with analyzing the impact of Closed Generics and considering future policy | 6 July 2020 | Proposed text incorporated. | |||||||||||||||||||
86 | JN6.3 | 6 | Jeff Neuman | 2.7.3 Closed Generics | Four options were discussed and were put out for public comment in the Initial Report. As the Working Group developed and deliberated on these options, it took into consideration GAC Advice included in the Beijing Communique on Category 2.2 Safeguards, and specifically the Advice that “For strings representing generic terms, exclusive registry access should serve a public interest goal.” The Working Group was careful to note that the implementation in 2012, of effectively banning closed generics, was not necessarily representative of the GAC Advice, which appeared to envision a scenario where an exclusive registry (i.e., closed generic) could be acceptable. Therefore, four options were considered by the Working Group: | Response to Group Concerns on “Ban” Language. | 3. Four options were discussed and were put out for public comment in the Initial Report. As the Working Group developed and deliberated on these options, it took into consideration GAC Advice included in the Beijing Communique on Category 2.2 Safeguards, and specifically the Advice that “For strings representing generic terms, exclusive registry access should serve a public interest goal.” The Working Group was careful to note that the implementation in 2012 was not necessarily representative of the GAC Advice, which appeared to envision a scenario where an exclusive registry (i.e., closed generic) could be acceptable. Therefore, four options were considered by the Working Group: | 6 July 2020 | Proposed text incorporated. | |||||||||||||||||||
87 | PM6.1 | 6 | Paul McGrady | 2.7.3 Closed Generics | Section 2.7.3 in its entirety (Package 6) | 1. Cannot live with references to a “ban.” The Board did not ban close generics. The Board deferred them to the next round. 2. We should continue our discussion on whether or not there needs to be a “public interest” for so-called closed generics. 3. The Supreme Court of the United States rejected per se bans on generic terms + domain name elements by the USPTO and shredded arguments that having such trademarks would have any appreciable impact on others wanting to use the generic term for its generic meaning. See https://www.law360.com/dockets/download/5efb47347da17405e86713cb?doc_url=https%3A%2F%2Fwww.supremecourt.gov%2Fopinions%2F19pdf%2F19-46_8n59.pdf&label=Opinion. This has direct impact on our discussion and we should discuss the affects of this case on the push by some to insist ICANN have a per se ban as well. | 1. Eliminate references to a “ban” and put in what really happened which was a deferral. 2. Have another call. 3. Have another call. | 6 July 2020 | Edited with compromise language. | |||||||||||||||||||
88 | SP6.1 | 6 | Susan Payne | 2.6.1 Application Queuing | sub-section c. | The Working Group considered that if numbers were only transferable between applications with the same owner, there may not be a risk of a secondary market forming. The Working Group did not come to a conclusion about whether to move forward with this potential recommendation. | Whilst it is understood that creating an aftermarket for prioritization numbers is undesirable, this concern does not apply to the applications of a single applicant. There seems to be no demonstrable reason to prevent an applicant from making their own choice as to how to prioritise as between their own applications. Since we have not made a recommendation that a single applicant may not apply for more than one TLDs then, to the extent that opposition to transfer of priority between applications of the same owner are based on a fundamental objection to multiple applications, this would seem to be irrelevant. | Recommend that priority numbers be transferable between the applications of the same owner. | 6 July 2020 | Original text retained. | ||||||||||||||||||
89 | SP6.2 | 6 | Susan Payne | 2.7.3 Closed Generics | sub-section a. | The Working Group notes that in the 2012 round of the New gTLD Program, a decision was made by the ICANN Board to effectively ban exclusive use / generic applications. It is the understanding of the Working Group that the ICANN Board intended that its decision to effectively ban Closed Generics applied only to the 2012 round and that it wanted the GNSO to engage in policy discussions regarding the treatment of such strings in subsequent rounds. Although the Working Group has had numerous discussions about this topic, and received extensive comments from the community, including members of the Governmental Advisory Committee, the Working Group was not able to agree as to how to treat these applications in subsequent rounds. | There was no “ban” by the Board. Jeff’s suggested alternative wording is a more appropriate reflection of the facts. | 1. No Agreement: The Working Group notes that in the 2012 round of the New gTLD Program, a decision was made by the ICANN Board to require applicants for exclusive generic strings to either (a) “submit a change request to no longer be an exclusive generic TLD”, (b) “withdraw their application” or (c) “maintain their plan to operate an exclusive generic TLD,” which would operate to defer their application to the next round of the New gTLD Program, subject to rules developed for the next round, to allow time for the GNSO to develop policy advice concerning exclusive generic TLD.” All applicants in 2012 chose either options (a) or (b). It is the understanding of the Working Group that the ICANN Board intended that its decision to not allow Closed Generics to proceed in the 2012 round applied only to the 2012 round and that it wanted the GNSO to engage in policy discussions regarding the treatment of such strings in subsequent rounds. Although the Working Group has had numerous discussions about this topic, and received extensive comments from the community, including members of the Governmental Advisory Committee, the Working Group was not able to agree as to how to treat these applications in subsequent rounds. | 6 July 2020 | Edited with compromise language. | ||||||||||||||||||
90 | SP6.3 | 6 | Susan Payne | 2.7.3 Closed Generics | sub-section b. | On 21 June 2015, the ICANN Board passed a resolution that effectively banned Exclusive Generic / Closed Generic TLDs in the 2012 round. | There was no “ban” by the Board. Jeff’s suggested alternative wording is a more appropriate reflection of the facts. | On 21 June 2015, the ICANN Board passed a resolution that prevented Exclusive Generic / Closed Generic TLDs proceeding in the 2012 round. | 6 July 2020 | Text proposed by Jeff Neuman incorporated, same concept as proposed by Susan. | ||||||||||||||||||
91 | AAS6.1 | 6 | Anne Aikman-Scalese | 2.2.4 Different TLD Types | Recommendation xx: Other than the types listed in Recommendation xx, creating additional application types must only be done under exceptional circumstances. Creating additional application types, string types, or applicant types must be done solely when differential treatment is warranted and is NOT intended to validate or invalidate any other differences in applications. Implementation Guidance xx: To the extent that in the future, the then-current application process and/or base agreement unduly impedes an otherwise allowable TLD application by application type, string type, or applicant type, there should be a predictable community process by which potential changes can be considered. This process should follow the Predictability Framework discussed in Section xx. See also recommendation xx in Section xx Base Registry Agreement regarding processes for obtaining exemptions to certain provisions of the base Registry Agreement. | This text does not identify “Closed Generics” as a type of application. It has been treated by the Working Group as a type of application and has a separate section. To avoid confusion, this application “type” should be distinguished and set apart from this general WG recommendation. | Add a footnote: “The Working Group notes that the so-called ‘Closed Generic’ application is a separate type of application treated in Section 2.7.3 of this draft Final Report. The Recommendation and Implementation Guidance provided in this Section 2.2.4 is not intended to apply to Closed Generics as they are subject to a need for further policy efforts in the community. | 6 July 2020 | Proposed text incoporated with minor edits for clarity. | |||||||||||||||||||
92 | AAS6.2 | 6 | Anne Aikman-Scalese | 2.9.1 | sub-section c. | The Working Group considered proposals for specific changes to the CPE Guidelines from 2012, but did not ultimately recommend any specific changes to the text of the Guidelines. Rather, this should be done by the Implementation Review Team taking into account all of the recommendations and implementation guidance described herein. | Although the Working Group made some references to the CPE Guidelines with a view toward affirming the scoring mechanism for the next round, the full Working Group never actually discussed all the changes that would be needed to bring this document current for the next round. I don’t recall the Working Group making the decision that the appropriate revisions to the CPE Guidelines and scoring system should be left to the IRT. | The Working Group considered proposals for specific changes to the CPE Guidelines from 2012 but did not fully review and discuss the changes proposed by Working Group members to the CPE Guidelines. Accordingly, the Working Group is seeking public comment on the 2012 CPE Guidelines linked at Footnote 197 prior to the finalization of its recommendations for changes to those Guidelines and will incorporate the public comment into its consideration of the changes needed for the implementation of CPE Guidelines and scoring system to be appied in the next round. | 6 July 2020 | Original text retained. Question will be included for public comment. | ||||||||||||||||||
93 | RK6.1 | 6 | Rubens Kuhl | 2.6.1 Application Queuing | sub-section a. | Affirmation with modification xx: If the volume of applications received exceeds 500, applications will be processed in batches of 500. In the 2012 round, the Section 1.1.2.5 of the Applicant Guidebook provided that the first batch would consist of 500 applications, but each subsequent batch was to be only 400 applications. For ease, the Working Group has modified this to an even 500 applications per batch. | The actual 2012 implementation used no batching whatsoever, and I don’t saw a consensus to change that to implement batching. It also contradicts evaluation efficiencies. | In the 2012 round, the Section 1.1.2.5 of the Applicant Guidebook provided that the first batch would consist of 500 applications, but each subsequent batch was to be only 400 applications. Nevertheless, the actual 2012 implementation had no batching at all. The workgrup affirms the 2012 implementation, so it also prescribes changing the Applicant Guidebook to reflect it. | 6 July 2020 | Clarification added with additional language regarding the definition and use of batches in Affirmation with modification xx. | ||||||||||||||||||
94 | RK6.2 | 6 | Rubens Kuhl | 2.6.1 Application Queuing | sub-section a. | Recommendation xx: For subsequent rounds, the Working Group recommends that the following formula must be used with respect to giving priority to Internationalized Domain Name applications: • First batch of 500 | If batches are removed, the language needs to be adopted. The listed method can be kept so the IDN priorities can be fitted in the overall randomization. Removing batches requires no change to this except language. | Change all instances of the word “batch” with the word “group”, ending up with the same effect in providing IDN applications some priority. | 6 July 2020 | Concept adopted with additional language in Affirmation with modification xx. | ||||||||||||||||||
95 | RK6.3 | 6 | Rubens Kuhl | 2.6.1 Application Queuing | sub-section a. | Implementation Guidance xx: Procedures related to application queuing should be simplified and streamlined to the extent possible. For example, applicants could be provided the opportunity to pay the optional fee for participating in the drawing along with payment for the application. Another suggestion is to explore ways to assign a prioritization number during the application process without the need for a distinctly separate drawing event. | It’s unclear whether this is optional to applicants or to ICANN. If ICANN can establish a draw without a separate fee, then this option must be exercised. | Implementation Guidance xx: Procedures related to application queuing should be simplified and streamlined to the extent possible. For example, applicants could be provided the opportunity to pay the optional fee for participating in the drawing along with payment for the application. If the fee is not required to establish a legal basis for the randomization, then a fee must not be required, only an indication of wanting prioritization or not. Another suggestion is to explore ways to assign a prioritization number during the application process without the need for a distinctly separate drawing event. | 6 July 2020 | Clarification added with additional language regarding the definition and use of batches in Affirmation with modification xx. | ||||||||||||||||||
96 | RK6.4 | 6 | Rubens Kuhl | 2.6.1 Application Queuing | sub-section b. | If batches are removed, the language needs to be adopted. The listed method can be kept so the IDN priorities can be fitted in the overall randomization. Removing batches requires no change to this except language. | Change all instances of the word “batch” with the word “group”, ending up with the same effect in providing IDN applications some priority. | 6 July 2020 | Clarification added with additional language regarding the definition and use of batches in Affirmation with modification xx. | |||||||||||||||||||
97 | AAS7.1 | 7 | Anne Aikman-Scalese | 2.3.2 Registry Voluntary Commitments | Recommendation xx (Rationale 9): ICANN must allow applicants to submit Registry Voluntary Commitments (RVCs) (previously called voluntary PICs) in subsequent rounds in their applications and/or to respond to public comments, objections, GAC Early Warnings, and/or GAC Consensus Advice. | At some point in amendments made to Package 6, the word “formal” was inserted in numerous places in the Objection section. This included a statement that RVCs adopted in response to FORMAL Objections are considered Application Change Requests requiring public comment. Two changes are required to clarify that all RVCs adopted via both formal and informal objection resolution require public comment in an Application Change Request procedure. | ICANN must allow applicants to submit Registry Voluntary Commitments (RVCs) (previously called voluntary PICs) in subsequent rounds in their applications and/or to respond to public comments, objections, whether formal or informal, GAC Early Warnings, and/or GAC Consensus Advice. | Proposed text incorporated | ||||||||||||||||||||
98 | MC8.1 | 8 | Marc Tractenberg | 2.7.3 Closed Generics | sub-section c. | For the purposes of the draft Final Report, the Working Group designated the status as No Agreement and has made no recommendations with respect to either allowing or disallowing Closed Generics. However, with widely diverging viewpoints, the Working Group asked Working Group members to contribute additional proposals for consideration, to help identify circumstances when a Closed Generic may be permitted. These proposals were not thoroughly vetted by the Working Group and therefore none of the proposals at this point in time have any agreement within the Working Group to pursue. However, the Working Group is very interested in community feedback regarding the three proposals received, in regards to both the high level principles and the details (where provided). Thus, any feedback is appreciated. The Working Group is particularly interested to hear from the community about which proposals, if any, they believe warrant further consideration by the Working Group, and why. The Working Group would also like input on whether there are elements or high-level principles in any of the proposals that are critical to permitting Closed Generics, even if commenters may disagree with some of the details. | The proposed wordking limits comments to the three proposals. It should also solicit other proposals from the community, if any | For the purposes of the draft Final Report, the Working Group designated the status as No Agreement and has made no recommendations with respect to either allowing or disallowing Closed Generics. However, with widely diverging viewpoints, the Working Group asked Working Group members to contribute additional proposals for consideration, to help identify circumstances when a Closed Generic may be permitted. These proposals were not thoroughly vetted by the Working Group and therefore none of the proposals at this point in time have any agreement within the Working Group to pursue. However, the Working Group is very interested in community feedback regarding the three proposals received, in regards to both the high level principles and the details (where provided), as well as any other proposals members of the community may with repsect to the availability of closed generic strings.Any feedback is appreciated. The Working Group is particularly interested to hear from the community about which proposals, if any, they believe warrant further consideration by the Working Group, and why or if there are any other proposals that members of the community may have with repect to the availability of closed generic strings. The Working Group would also like input on whether there are elements or high-level principles in any of the existing proposals put forth by the working Group members that are critical to permitting Closed Generics, even if commenters may disagree with some of the details. | 13 August 2020 | Compromise text incorporated. | ||||||||||||||||||
99 | MC8.2 | 8 | Marc Tractenberg | 2.7.3 Closed Generics | sub-section b. | Option 4: Allow Closed Generics with no additional conditions. Establish an objections process modelled on community objections. | This language does not accurately capture our proposal/option. We proposed an option with no additional conditions for closed generics but did not propose that there should be any objections process based on community application objections | Option 4: Allow Closed Generics with no additional conditions. | 13 August 2020 | Text adjusted to clarify that the text in this section refers to options discussed prior to the introduction of the new proposals. | ||||||||||||||||||
100 | MC8.3 | 8 | Marc Tractenberg | 2.7.3 Closed Generics | sub-section b. | Some Working Group members felt that it may not be possible to define the public interest, but it may be possible to entrust an entity to judge whether a proposed Closed Generic is or is not in the public interest. | You have not captured the view of some working group members including myself, Kurt, Mike, and Paul (and even Alex to some extent) that it simply is not possible to define the public interest. We did not say and do not agree that it would be possible to entrust an entity to judge whether a proposed Closed Generic is or is not in the public interest and we do not agree this is possible | Some Working Group members felt that it is not possible to define the public interest in any way that can be meangfully applied to new gTLDs. Some other Working Group members believed that it may be possible to entrust an entity to judge whether a proposed Closed Generic is or is not in the public interest. For example, one Working Group member suggested allowing Closed Generic applications in line with GAC Advice only where the ICANN Board determined that the TLD would serve a public interest goal. Some proposed that the Board could only do this if the Board approved the application by a supermajority for example at least 90% of sitting, non-conflicted, Board members) that the TLD would serve a public interest goal. | 13 August 2020 | Text adjusted to clarify that the text in this section refers to early deliberations prior to the introduction of the new proposals. |