GNSO SubPro Supplemental Recommendations Community Consultation

6 March 2024

| 2

Background

| 3

| 3

SubPro Pending Recs Background

• Feb 2021 - Council unanimously adopted Final Report
• Jan 2022 - Operational Design Phase initiated, concluded with delivery of Operational Design Assessment in Dec 2022.
• Mar 2023 - Board adopts majority of recommendations, but places 38 in a pending status
• GNSO Council establishes small team and collaborates with ICANN Board to resolve as many pending recommendations as possible. The manner in which they’ve been resolved include:
• Mutual understanding that an issue can be resolved in implementation.
• Adoption of a clarifying statement at the Council level, which will be taken into account during implementation.

| 4

SubPro Pending Recs Background, cont.

• In September and October, the ICANN Board did not adopt seven (7) and three (3) recommendations respectively covering 6 different topics. These non-adopted recommendations constitute the scope of work for this Small Team Plus.
• Per Annex A of the ICANN Bylaws, “...the Council shall meet to affirm or modify its recommendation, and communicate that conclusion (the "Supplemental Recommendation") to the Board, including an explanation for the then-current recommendation.”
• The Council has charged the Small Team Plus with potentially developing and proposing Supplemental Recommendations to address the Board’s concerns that will subsequently be considered at the Council level for approval.

| 5

SubPro Pending Recs Background, cont.

• The non-adopted recommendations are generally a subset from the following six topics:
• Topic 9: Registry Voluntary Commitments / Public Interest Commitments
• Topic 17: Applicant Support
• Topic 18: Terms & Conditions
• Topic 22: Registrant Protections
• Topic 24: String Similarity Evaluations
• Topic 32: Limited Challenge/Appeal Mechanism

| 6

Small Team Plus Membership

* See “Topics” tab on wiki page to identity topic specific SMEs and alternates

| 7

Upcoming Milestones/Meetings and Dates

| 8

Supplemental Recommendations

| 9

| 9

Topic 9 - RVCs/PICs

Board Concern:

• Waiver to Specification 11, sections 3(a) and 3(b) could lead to DNS abuse for second-level registrations in a single-registrant TLD going undeterred, unobserved and therefore unmitigated.

​

Supplemental Recommendation Highlights:

• Waiver is not automatic - applicants must apply for a waiver.
• Waiver can be for either or both of 3(a) or 3(b).
• All domains in TLD are registered to and controlled by the RO or its affiliates.
• RO will take effective steps to identify and mitigate domains that are perpetrating DNS abuse, which may not constitute periodical technical analysis (as envisaged in the RA).

​

| 10

| 10

Topic 9 - RVCs/PICs - Supplemental Rec

Recommendation 9.2: TLDs that have exemptions from the Code of Conduct (Specification 9), including .Brand TLDs qualified for specification 13, may be granted, upon a successful application for a waiver, an Provide single-registrant TLDs with exemptions from either or both the and/or waivers to mandatory PICs included in Specification 11 3(a) and Specification 11 3(b)., provided that (i) all domain name registrations in the TLD are registered to, and maintained by, Registry Operator, or its Affiliates, for the exclusive use of Registry Operator or its Affiliates, (ii) Registry Operator does not sell, distribute or transfer control or use of any registrations in the TLD to any third party that is not an Affiliate or Registry Operator, and (iii) in the case of Spec 11 (3)(b), Registry Operator demonstrates that it takes or will take other effective steps to identify and mitigate domains in the TLD perpetrating DNS Abuse, but which may not constitute periodical technical analysis as envisaged under the Registry Agreement.

​

Implementation Guidance:

​

• All TLDs will continue to be subject to the Spec 11 (3)(a) and (b) obligations unless they apply for, and meet the requirements to be granted, a waiver.
• The application for a waiver may be made as part of the application process, with the applicant making a contractual commitment to operate the TLD only in the required manner, once delegated.
• The registration policies for the TLD must reflect the limitations on registration and use necessary to qualify for the waiver.
• The Registry Operator must promptly notify ICANN in writing of any change to the TLD that could cause the TLD to fail to meet the requirements for the waiver. Registry Operator must also provide ICANN with any amendment or modification to the registration policies for the TLD that could potentially disqualify the TLD for the waiver.
• Registry Operator must conduct internal reviews at least once per calendar year to ensure that the TLD meets the requirements for the waiver. Within 20 calendar days following the end of each calendar year, Registry Operator will provide ICANN with the results of its internal review(s), along with a certification executed by one of its executive officers certifying that the TLD meets the requirements for the waiver.
• If, at any time, the TLD ceases to meet the requirements for a waiver, the Registry Operator will become subject to the Spec 11(3)(a) and (b) obligations.
• Denial of a waiver will not trigger any appeals process internal to the new gTLD program

| 11

| 11

Topic 17 - Applicant Support

Board Concern:

• The open-ended nature of fees which may be affirmative payments of costs beyond application fees, which could raise fiduciary concerns for the Board.

​

Supplemental Recommendation Highlights:

• Substituted specific reference to “application writing fees and attorney fees” for a much broader reference to an “array of resources useful for the capacity building, planning, application, evaluation, pre-delegation and post-delegation phases of the lifecycle of the application.”
• Included a reference to community suggestions for the implementation of the recommendation.

| 12

| 12

Topic 17 - Applicant Support - Supplemental Rec

Supplemental Recommendation 17.2: The Working Group The GNSO Council recommends expanding the scope of Applicant Support financial support provided to Applicant Support Program beneficiaries beyond the application fee to provide access to an array of resources useful for the capacity building, planning, application, evaluation, pre-delegation and post-delegation phases of the lifecycle of the application. For the avoidance of doubt, this recommendation does not obligate ICANN to provide support for all phases of the lifecycle of the application process as well as the registry. also cover costs such as application writing fees and attorney fees related to the application process.

​

Community suggestions for implementation of supplemental recommendation 17.2: Below are some suggestions from the community which Council believes should be considered for possible implementation:

https://docs.google.com/document/d/1O9Kn0sTNB83wuYZC-xaD2WMW52x5fUYOWH_EmF6KWjA/edit

​

| 13

| 13

Topic 24 - String Similarity

Board Concern:

• Wording in sections (a) and (c) of this Recommendation stipulate “intended use” of a gTLD, which implies that ICANN will have to enforce the “intended use” post-delegation, which could be challenged as acting outside its mission.
• Number of concerns around extending string similarity beyond just a visual similarity check to include a singular/plural check.

​

Supplemental Recommendation Highlights:

• Substantively, removed intended use elements. Also removed extraneous explanatory text and rationale that is unnecessary for the recommendation.
• Added a provision that allows both the singular and plural to proceed when at least one application is a dotBrand.
• Substituted the reliance on a dictionary to recognised linguistic resources.

| 14

| 14

Topic 24 - String Similarity - Supplemental Rec

Recommendation 24.3A: The GNSO Council Working Group recommends updating the POLICY standards of both (a) confusing similarity to an existing top-level domain or a Reserved Name, and (b) similarity for purposes of determining string contention, to address singular and plural versions of the same word, noting that this was an area where there was insufficient clarity in the 2012 round. Specifically, the GNSO Council Working Group recommends prohibiting plurals and singulars of the same word within the same language/script in order to reduce the risk of consumer confusion. For example, the TLDs .EXAMPLE and .EXAMPLES may not both be delegated because they are considered confusingly similar. This expands the scope of the String Similarity Review to encompass singulars/plurals of TLDs on a per-language/script basis.

​

1. An application for a single/plural variation of a word in the same language/script of an existing TLD or Reserved Name will not be permitted if the intended use of the applied-for string is the single/plural version of the existing TLD or Reserved Name. For example, if there is an existing TLD .SPRINGS that is used in connection with elastic objects and a new application for .SPRING that is also intended to be used in connection with elastic objects, .SPRING will not be permitted.
2. If there is an application for the singular version of a word and an application for a plural version of the same word in the same language/script during the same application window, these applications will be placed in a contention set, because they are confusingly similar.

​

| 15

| 15

Topic 24 - String Similarity - Supplemental Rec, cont.

Recommendation 24.3B: An applications for a registered trademark term being applied for as a dotBrand TLD will not automatically be placed in the same contention set with a non dotBrand application pursuant to 24.3A , if the application is one for which, pursuant and subject to Specification 13, domains are allocated and used only by the registry operator, its Affiliates and Trademark Licensees. For this 24.3B exception to apply, the applicant for the dotBrand would need to commit to maintaining Specification 13 in its contract. In the event that it ceased to be eligible for Specification 13, the TLD would need to be terminated. Nothing in this Supplemental Recommendation affects the right of any party to file a timely Objection pursuant to the Applicant Guidebook. 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.

​

Recommendation 24.3C: The GNSO Council Working Group recommends identifying and using a dictionary recognised linguistic resources to determine the singular and plural version of the string for the specific language. The Working Group recognizes that singulars and plurals may not visually resemble each other in multiple languages and scripts globally. Nonetheless, If by using a recognised linguistic resource dictionary, two strings are determined to be the singular or plural of each other, and their intended use is substantially similar, then both should not be eligible for delegation these will be placed in a contention set..

​

Recommendation 24.5: If two applications are submitted during the same application window for strings that create the probability of a user assuming that they are single and plural versions of the same word, but the applicants intend to use the strings in connection with two different meanings, the applications will only be able to proceed if each of the applicants agrees to the inclusion of a mandatory Public Interest Commitment (PIC) in its Registry Agreement. The mandatory PIC must include a commitment by the registry to use the TLD in line with the intended use presented in the application, and must also include a commitment by the registry that it will require registrants to use domains under the TLD in line with the intended use stated in the application.

​

| 16

| 16

Topic 18 - T&Cs Rec 18.1

Board Concern:

• The recommendation unduly restricting ICANN’s discretion to reject an application in circumstances that fall outside the specific grounds set out in the recommendation.

​

Supplemental Recommendation Highlights:

• Shifted the emphasis away from certain grounds that require ICANN org to reject an application to providing the allowable grounds under which ICANN org may reject an application.

| 17

| 17

Topic 18 - T&Cs Rec 18.1 - Supplemental Rec

Recommendation 18.1: ICANN may only reject an application in accordance with the Applicant Guidebook, Unless required by specific laws, ICANN Board members’ fiduciary duties, or the ICANN Bylaws, or applicable laws, ICANN must only reject an application if done so in accordance with the provisions of the Applicant Guidebook. In the event an application is rejected, ICANN org must cite with specificity the reason(s) in accordance with the above Applicant Guidebook, or if applicable, the specific law and/or ICANN Bylaws for not allowing an application to proceed. This recommendation constitutes a revision to Section 3 of the Terms and Conditions from the 2012 round.

​

| 18

| 18

Topic 18 - T&Cs Rec 18.3

Board Concern:

• Dissatisfied applicants or objectors might argue based on this policy recommendation that the covenant not to sue is not valid because they did not like the way the appeals/challenge was built or operated. Anything that could weaken the covenant not to sue might preclude the ability to offer the program due to an unreasonable risk of lawsuits.

​

Supplemental Recommendation Highlights:

• Removed the dependent language between the covenant not to sue and specific reference to the challenge and appeals mechanism as described under Topic 32.
• Made clear that there simply must be a challenge and appeals mechanism.

| 19

| 19

Topic 18 - T&Cs Rec 18.3 - Supplemental Rec

Supplemental Recommendation 18.3 In subsequent rounds, there must be mechanisms in place whereby Applicants have the ability to have evaluation decisions and objection decisions substantively reviewed. This may be satisfied by implementing an appeals/ challenge and appeal mechanisms described generally under Topic 32. If there are is an appeals / challenge and appeal mechanisms or other processes whereby those decisions can be substantively reviewed, ICANN may continue to have Terms and Conditions that contain a covenant not to sue. if, and only if, the appeals/challenge mechanisms set forth under Topic 32 of this report are introduced into the program (in addition to the accountability mechanisms set forth in the current ICANN Bylaws). This recommendation is in reference to Section 6 of the Terms and Conditions from the 2012 round.

​

| 20

| 20

Topic 32 - Limited Challenge/Appeal Mechanism

Board Concern:

• It is not clear that a challenge/appeal mechanism applicable to Initial/Extended Evaluation decisions made by ICANN or third-party providers or challenges concerning conflict of interest of panelists could be designed in a way that does not cause excessive, unnecessary costs or delays in the application process.

​

Supplemental Recommendation Highlights:

• Removed references to specific evaluation and objection elements and instead, made the specific areas dependent on being feasible and implementable.
• Emphasized that the challenge or appeal is limited and on a one-time basis.
• Specifically removed evaluation elements from being challengeable where Extended Evaluation is available
• Softened the linkage between the recommendation and the underlying implementation guidance (i.e., generally aligned with the principles…).

| 21

| 21

Topic 32 - Supplemental Recc

​

Recommendation 32.1: The GNSO Council Working Group recommends that as set forth in Annex F, where feasible and implementable, ICANN establish a mechanism that allows specific parties to, on a limited and one-time basis: (i) challenge evaluation results for which Extended Evaluation is unavailable, or (ii) appeal formal objection results, where such evaluation results or dispute resolution results certain types of actions or inactions that appear to be inconsistent with the Applicant Guidebook.

​

The new substantive challenge/appeal mechanism is not a substitute or replacement for the accountability mechanisms in the ICANN Bylaws that may be invoked to determine whether ICANN staff or Board violated the Bylaws by making or not making a certain decision. Implementation of this mechanism must not conflict with, be inconsistent with, or impinge access to accountability mechanisms under the ICANN Bylaws.

​

The Working Group recommends that the limited challenge/appeal mechanism applies to the following types of evaluations and formal objections decisions:

​

Evaluation Challenges

1. Background Screening
2. String Similarity
3. DNS Stability
4. Geographic Names
5. Technical / Operational Evaluation
6. Financial Evaluation
7. Registry Services Evaluation
8. Community Priority Evaluation
9. Applicant Support
10. RSP Pre-Evaluation

​

Appeals of Formal Objections Decisions

1. String Confusion Objection
2. Legal Rights Objection
3. Limited Public Interest Objection
4. Community Objection
5. Conflict of Interest of Panelists

​

| 22

| 22

Topic 32 - Topic 32 - Supplemental Recc, cont.

​

Recommendation 32.2: In support of transparency, clear procedures and rules must be established for challenge/appeal processes generally aligned with the principles as described in the implementation guidance below.

​

Recommendation 32.10: The limited challenge/appeal process must be designed in a manner that does not cause excessive, unnecessary costs or delays in the application process, generally aligned with the principles as described in the implementation guidance below.

​

Note, Annex F is also amended to remove all evaluation elements that allow for Extended Evaluation.

| 23

| 23

Next Steps

| 24

| 24

Reminder: Upcoming Milestones/Meetings and Dates

| 25

Q&A

| 26

| 26

AOB

| 27

| 27

Engage with ICANN

Visit us at icann.org

Thank You and Questions

Email: email

| 28