At-Large Workspace: Initial Report on the New gTLD Subsequent Procedures Policy Development Process (Overarching Issues & Work Tracks 1-4)

“AGB”

means:

The New gTLD Program Applicant Guidebook

“ALAC”

means:

The ICANN At-Large Advisory Committee

“At-Large”

means:

The ICANN At-Large Community

“ICANN Org”

means:

The ICANN Organization

“Initial Report”

means:

The New gTLD Subsequent Procedures Initial Report dated 3 July 2018

“Program”

means:

The New gTLD Program

“RALO”

means:

ICANN Regional At-Large Organizations

“WG”

means:

The GNSO New gTLD Subsequent Procedures PDP Working Group

PDP Working Group Preliminary Recommendation (PR) / Question (Q) / Option

ALAC Response

2.2.1: Continuing Subsequent Procedures (full WG)

PR 2.2.1.c.1

The Working Group recommends no changes to the existing policy calling for subsequent application rounds introduced in an ongoing, orderly, timely and predictable manner.

(Justine)

A majority view in At-Large supports this recommendation. The rationale for this view, along with a minority view, is presented in Section 2.2.3 Applications Assessed in Rounds.

Q 2.2.1.e.1

The 2007 Final Report noted that success metrics would be developed around the New gTLD Program. What are some specific metrics that the program should be measured against?

(Holly, Evan)

PDP Working Group Preliminary Recommendation (PR) / Question (Q) / Option

ALAC Response

2.2.2: Predictability (full WG)

PR 2.2.2

Currently, as a result of consensus recommendations made by the GNSO, the ICANN Board endorsed the GNSO’s Policy and Implementation Recommendations, including those related to the Consensus Policy Implementation Framework (CPIF) for governing the implementation phase of GNSO policies. If issues arise during this phase, the GNSO could seek to utilize the GNSO Expedited Policy Development Process or the GNSO Guidance Process, as defined in the ICANN Bylaws. However, there is support in the Working Group for a recommendation that the New gTLD Program, once launched (i.e., after the Implementation Review Team), should be subject to a new Predictability Framework, to address issues that arise regarding the introduction of new gTLDs.

Among other recommendations, the Working Group believes that as part of the Predictability Framework, a Standing Implementation Review Team (IRT) should be constituted after the publication of the Applicant Guidebook to consider changes in the implementation, execution and/or operations of the new gTLD program after its launch, and the introduction of any further evaluation guidelines not available to applicants when applications were submitted. The Predictability Framework is intended to provide guidance to the Standing IRT in how issues should be resolved, which could include recommending that the GNSO Council initiate GNSO processes provided by the ICANN Bylaws. Please see sub-section d for full text of the Predictability Framework.

(Justine)

Substantive response is provided to the questions in this section 2.2.2, as set out below.

Q 2.2.2.e.1

Does the concept of a Predictability Framework make sense to address issues raised post-launch?

(Justine, Sebastien, Christopher)

Predictability is best served by ensuring that all applicable rules and procedures for the Program be settled prior to its launch. Further, we wish to highlight the need for the goal of predictability to be not only focused on the applicant but also consciously considered from the point of view of Internet end-users, by giving attention to their expectations as to the use of a gTLD from application through to post-delegation processes.

Notwithstanding, from experiences in the 2012 rounds, we acknowledge that it may be impossible for various reasons, for all rules and/or procedures to be identified or agreed upon beforehand. On this basis, the ALAC  is of the opinion that a Predictability Framework along the lines contemplated by the WG makes sense to provide guidance and predictability in the procedure for addressing issues raised post-launch. Further, the ALAC supports the concept a Standing Implementation Review Team (IRT) being constituted after the publication of the Applicant Guidebook to consider changes in the implementation, execution and/or operations of the new gTLD program after its launch, and the introduction of any further application and/or evaluation guidelines not available to applicants when applications were submitted whilst always considering the impact of the introduction of such guidelines equally on all applicants. In particular, the ALAC believes a Standing IRT is required to support and advise ICANN staff on the day-to-day tasks in implementing the new gTLD program.

Q 2.2.2.e.2

How should launch be defined? Ideas considered by the WG include Board adoption of the new Applicant Guidebook or the first day in which applications are accepted.

(Justine, Maureen)

The ALAC opines that “Launch” should be defined as the day on which the next round is actually opened for accepting applications.

This opinion is based on the following:

• If the WG’s Phase 3 – Operations / Administration (see the Initial Report pg 18) were to be established, then it is important to specify the actual date when the role or work of the Standing IRT commences;
• Such date referred to above should be slated for after all the other policy-specific processes have been completed, including Board approval of the AGB, in order to avoid overlap or confusion on allocation of responsibilities due to timing uncertainty; and
• To allow for some lead time between the constitution of the Standing IRT and launch of the next round unless the constitution is completed well before the date the Board approves the AGB for the next round.

The ALAC also notes that details of a Standing IRT remains to be agreed upon.

Q 2.2.2.e.3

A component of the Predictability Framework includes the identification or criteria to determine whether an issue can be handled through existing mechanisms or whether it can/should be handled by a Standing IRT. What are potential criteria that can be applied to help distinguish between types of issues and resolution mechanism?

(Justine)

The ALAC notes that the Standing IRT will only be charged to deal with post-launch operational / administration issues, so, supplementing the WG’s recorded deliberations in Section 2.2.2 Predictability, our list of potential criteria of post-launch issues for resolution by the Standing IRT would include:-

• Whether an issue is an one-off occurrence;
• How urgent is action/decision needed to resolve an issue or how badly does a lacuna need to be filled;
• Who (or the number of parties) would be affected by a recommendation or decision of the Standing IRT, including material levels;
• Whether the implementation of a recommendation or decision can be easily reversed (a remote consideration).

The WG is also urged to revisit the recommendations of the Policy and Implementation Working Group mentioned in the Initial Report on pg 25.

Q 2.2.2.e.4

Do you have thoughts on the open questions/details related to the Standing IRT panel discussed in section (f) below? Is there a different structure, process, or body (possibly already existing) that might help provide needed predictability in addressing issues raised post-launch?

(Justine)

Perhaps the only existing structure that could take on the duties of the Standing IRT is the IRT for Subsequent Procedures although the ALAC notes that the mandate and role of the IRT for Subsequent Procedures has been limited to reviewing the implementation aspects of the Program after a round is closed.

Q 2.2.2.e.5

How do you see the proposed Predictability Framework interacting with the existing GNSO procedures known as the GNSO Input Process, GNSO Guidance Process, and GNSO Expedited PDP?

(Justine)

The Phase 3 Predictability Framework mandate of a Standing IRT is limited in scope and time (as are the existing GNSO procedures) so if conducted well, should not lead to unintended overlaps. Therefore, we see the Standing IRT’s role raising any issues of policy-implementation conflict to the GNSO Council for further action as complementary, rather than disruptive, to existing GNSO procedures.

A Standing IRT, because of its mandated constitution with a Program launch (and ‘standing’ status) as well as scope, is likely to be able to react more promptly to consider, filter and address issues as appropriate based on its charter/role. As an example, we see that even with a GNSO Expedited PDP, time for getting up may result in impact due to process delay.

In any case, the ALAC, in general, welcomes a public comment process, although further consideration is warranted on whether all operational changes should be subject to public comment, in noting that all fundamental / possible policy impact changes to the Program must always go through a GNSO procedure.

2.2.2.2 Clarity of Application Process (WT1)

PR 2.2.2.2.c.1

When substantive/disruptive changes to the Applicant Guidebook or application processing are necessary and made through the Predictability Framework discussed above, there should be a mechanism that allows impacted applicants the opportunity to either (a) request an appropriate refund or (b) be tracked into a parallel process that deals with the discrete issues directly without impacting the rest of the program.

(From Google sheet)

Yes. ICANN Org must exercise greater transparency vis a vis impacted applicants by notifying them of material changes to the application process and to inform them clearly of the consequences and their options/rights resulting from those changes.

Q 2.2.2.2.e.1

Is ICANN organization capable of scaling to handle application volume and, if not, what would have to happen in order for ICANN organization to scale?

(From Google sheet)

The ALAC believes that ICANN Org needs to conduct a study regarding its scalability to handle the likely higher influx of applications for new gTLDs.

PDP Working Group Preliminary Recommendation (PR) / Question (Q) / Option

ALAC Response

2.2.3: Applications Assessed in Rounds (full WG)

PR 2.2.3

The Working Group recommends that the next introduction of new gTLDs shall be in the form of a “round.” With respect to subsequent introductions of the new gTLDs, although the Working Group does not have any consensus on a specific proposal, it does generally believe that it should be known prior to the launch of the next round either (a) the date in which the next introduction 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 subsequent process. For the purposes of providing an example, prior to the launch of the next round of new gTLDs, ICANN could state something like, “The subsequent introduction of new gTLDs after this round will occur on January 1, 2023 or nine months following the date in which 50% of the applications from the last round have completed Initial Evaluation.”

(Justine et al)

A majority view in At-Large supports this recommendation that the next introduction of new gTLDs be in the form a “round”, while a minority view within At-Large believes that “rounds” are unnecessary.

Within the majority view, opinions differ on the number of “rounds” that ought to be conducted in moving the Program forward. Some believe that the Program should proceed via 2 or 3 “rounds” then move to a first-come, first-served (FCFS) process for application whilst others believe “rounds” should be a perpetual feature underpinning the Program. 

Some views also qualified that applications could be conducted on a FCFS process but all applications must continue to be batched for assessment to allow for not only fair competition in string selection but also to facilitate manageable review procedures by various stakeholders (from Initial Evaluation to public comment, GAC Advice / GAC Early Warning, objections) and resolution procedures for contention sets and Community Priority Evaluation (CPE)).

However, there is full consensus in At-Large  around the need for the following regardless of whether re-introduction of the Program is done via a “round”, “rounds” or on a FCFS basis:

• That the AGB accurately and comprehensively reflects the policies, rules and procedures to be relied upon by all parties --- ICANN Org, applicants, evaluators, objectors, Dispute Resolution Service Providers (DRSPs) etc, and where separate rules and/or procedures are to apply, such rules and/or procedures must be made known in advance to all parties concerned, especially on applicable fees, and the applicability of criteria for evaluation;
• That there be a mechanism to allow for course corrections mandated by policy development processes to make substantial, policy-driven changes to the Program (a seamless mechanism in the case of the FCFS process but where changes made would only apply to applications submitted post changes);
• That community-based applications (or applications for community TLDs) be prioritized in the first instance (or the next one or more “rounds”);
• That the CPE procedure, in particular, be rigorously reviewed;
• That there be greater transparency in ICANN Org’s selection of DSRPs;
• That outreach efforts be undertaken to better create awareness of not only the Program but also parallel programs such as the Applicant Support Program (ASP).

Option 2.2.3.d.1

Conduct one additional “round” followed by an undefined review period to determine how future applications for new gTLDs should be accepted.

See our response to PR 2.2.3 above

Option 2.2.3.d.2

Conduct two or three additional application “rounds” separated by predictable periods for the purpose of major “course corrections,” to determine the permanent process for the acceptance of new gTLDs in the future. For illustration purposes only, this could include commencing an application window in Q1 of Year 1, a second application window in Q1 of Year 2, and a final application window in Q1 of Year 3 followed by a lengthy gap to determine the permanent process moving forward after Year 3.

See our response to PR 2.2.3 above

Option 2.2.3.d.3

Conduct all future new gTLD procedures in “rounds” separated by predictable periods for the purpose of course corrections indefinitely. Policy development processes would then be required to make substantial, policy-driven changes to the program and would then only apply to the opening of the application round following the date in which the PDP recommendations were adopted by the ICANN Board.

See our response to PR 2.2.3 above

Option 2.2.3.d.4

Conduct one additional “round” followed by the permanent opening up of a first-come, first-served process of new gTLD applications.

See our response to PR 2.2.3 above

Option 2.2.3.d.5

Commence two or three additional application “rounds” separated by predictable periods for the purpose of major course corrections, followed shortly thereafter by the permanent opening up of a first-come, first-served process of accepting new gTLD applications

See our response to PR 2.2.3 above

Option 2.2.3.d.6

Immediately commence a permanent first-come, first-served process of accepting new gTLD Applications.

See our response to PR 2.2.3 above

Q 2.2.3.e.1

Of the models described above, which model do you believe should be employed, if any? Please explain.

See our response to PR 2.2.3 above

Q 2.2.3.e.2

For the model you have selected, what are some mechanisms that can be employed to mitigate any of the listed (or unlisted) downsides.

No specific comments offered.

Q 2.2.3.e.3

Is there a way to assess the demand for new gTLDs to help us determine whether the subsequent new gTLD process should be a “round” or a “first-come first-served process? (e.g. Do we introduce an Expressions of Interest process?)

(Justine)

The ALAC opines that Expressions of Interest process normally only yields useful insight for mature, well-educated markets and hence, may be a good way to assess demand for new gTLDs in future. 

Further, the resources required for an Expressions of Interest process may, in the first instance, be better applied to rectify several identified deficiencies of the Program, namely, promoting greater awareness of the Program in regions where numbers of applications from the 2012 round were comparatively very low (eg Global South), using appropriate means and channels. Ideally, improving clarity in application process and access to as well as breadth of the Applicant Support Program (ASP) should precede any market outreach efforts in order to help establish a more genuine assessment of demand.

Perhaps a simpler form of Expressions of Interest such as simple market surveys which can be used at the ICANN roadshows and other outreach efforts could be the basis to gauge demand for new gTLDs in the next round. Such surveys ought to incorporate questions targeted at establishing on the one hand, awareness of key aspects of the Program, and on the other hand, basic expectations of potential applicants.

Q 2.2.3.e.4

If we were to have a process where a certain date was announced for the next subsequent procedure, what would be the threshold for the community to override that certain date (i.e., Is a different process needed if the number of applications exceeds a certain threshold in a given period of time?)

(Justine, Olivier)

The ALAC finds in principle the idea of overriding an announced date to be undesirable. However, in the event ICANN Org has not been able to account for the unexpected, then if at all,  and only on an as-needed basis, thresholds triggering an override would be limited to:

• Where the actual number of applications exceeded the expected number (for a round) which would then negatively impact on resources assigned based on the expected number (eg availability of ICANN staff resources, evaluation panels etc), or
• If the anticipated number of new gTLD delegations exceed the number which SSAC considers as the tipping point to maintaining the stability, security and resiliency of the DNS and root zone system.

PDP Working Group Preliminary Recommendation (PR) / Question (Q) / Option

ALAC Response

2.2.4: Different TLD Types (full WG)

PR 2.2.4.c.1

The Working Group recommends that each of the categories recognized by the 2012 Applicant Guidebook, both explicitly and implicitly, continue to be recognized on a going forward basis. These include standard TLDs, community-based TLDs, TLDs for which a governmental entity serves as the registry operator, and geographic TLDs. In addition, the Working Group also recognizes that Specification 13 .Brand TLDs should also be formally established as a category. The ramifications of being designated a specific category are addressed throughout this Initial Report as applicable.

(Olivier, Justine)

The ALAC has and continue to express their support for existing categories, which are standard TLDs, community-based TLDs, TLDs for which a governmental entity serves as the registry operator, and geographic TLD, and including .Brand TLDs as memorialized via Specification 13.

Q 2.2.4.e.1

The Working Group did not reach agreement on adding any additional categories of gTLDs. What would be the benefit of adding a further category/further categories? Should additional categories of TLDs be established and if so, what categories? Why or why not?

(Olivier, Justine)

The ALAC does not see a need for or benefits of adding a further category/further categories of TLDs.

Q 2.2.4.e.2

To the extent that you believe additional categories should be created, how would applications for those TLDs be treated differently from a standard TLD throughout the application process, evaluation process, string contention process, contracting, post-delegation, etc.

(Olivier, Justine)

The ALAC does not see a need for or benefits of adding a further category/further categories of TLDs.

Q 2.2.4.e.3 

If you have recommended additional categories of TLDs, what would be the eligibility requirements for those categories, how would those be enforced and what would be the ramifications of a TLD that qualified for a newly created category failing to continue to meet those qualifications?

(Olivier, Justine)

The ALAC does not see a need for or benefits of adding a further category/further categories of TLDs.

PDP Working Group Preliminary Recommendation (PR) / Question (Q) / Option

ALAC Response

2.2.5 Applications Submission Limits (full WG)

PR 2.2.5.c.1

Although some members of Working Group supported the notion of putting limits into place, ultimately the Working Group concluded that there were no effective, fair and/or feasible mechanisms to enforce such limits. It therefore concluded that no limits should be imposed on either the number of applications in total or the number of applications from any particular entity.

(Olivier, Justine)

The ALAC supports this preliminary recommendation for no limits to be imposed on either the number of applications in total or the number of applications from any particular entity.

PDP Working Group Preliminary Recommendation (PR) / Question (Q) / Option

ALAC Response

2.2.6: Accreditation Programs (WT1)

PR 2.2.6.c.1

Work Track 1 recommends using the term “pre-approval” as opposed to “accreditation.” To a number of Work Track members, the term “accreditation” implies having a contract in place with ICANN and other items for which there is no agreement within the Work Track. “Pre-approval” on the other hand does not have those same implications, but merely connotes applying the same standards, evaluation criteria and testing mechanisms (if any) at a point in time which is earlier than going through the standard process.

(Olivier, Justine)

The ALAC supports the concept of “pre-approval” process for registry service provider (RSP) per preliminary recommendations 2.2.6.c.1 to 2.2.6.c.5.

PR 2.2.6.c.2

The Work Track generally agrees that there should be a registry service provider (RSP) pre-approval process, which must be in place at least three (3) months prior to the opening of the application period.

See our response to preliminary recommendation 2.2.6.c.1.

PR 2.2.6.c.3

The RSP pre-approval process shall have technical requirements equal to the Technical and Operational Capabilities Evaluation (as established in section 2.7.7 on Applicant Reviews: Technical/Operational, Financial and Registry Services), but will also consider the RSP’s overall breadth of registry operator support.

See our response to preliminary recommendation 2.2.6.c.1.

PR 2.2.6.c.4

The RSP pre-approval process should be a voluntary program and the existence of the process will not preclude an applicant from providing its own registry services or providing registry services to other New gTLD Registry Operators.

See our response to preliminary recommendation 2.2.6.c.1.

PR 2.2.6.c.5

The RSP pre-approval process should be funded by those seeking pre-approval on a cost-recovery basis.

See our response to preliminary recommendation 2.2.6.c.1.

Q 2.2.6.e.1

Should the pre-approval process take into consideration the number and type of TLDs that an RSP intends to support? Why or why not?

Q 2.2.6.e.2

If so, how would the process take that into consideration? What if the number of applications submitted during the TLD application round exceed the number of TLDs for which the RSP indicated it could support?

Q 2.2.6.e.3

Should RSPs that are pre-approved be required to be periodically reassessed? If so, how would such a process work and how often should such a reassessment be conducted?

Q 2.2.6.e.4

If RSPs that go through the pre-approval process are required to go through a reassessment process, should RSPs/applicants that do not take part in the pre-approval program (e.g., providing registry services for its own registry or other registries) also be required to go through the reassessment process? Do you feel it will lead to inconsistent treatment of RSPs otherwise?

Q 2.2.6.e.5 Existing RSP.

Should existing RSPs be automatically deemed “pre-approved”? Why or why not? If not automatically pre-approved, should existing RSPs have a different process when seeking to become pre-approved? If so, what would the different process be? Are there any exceptions to the above? For example, should a history of failing to meet certain Service Levels be considered when seeking pre-approval? Please explain.

Q 2.2.6.e.6

What is the appropriate amount of time to allow for the submission of an application in order for the new RSP to be reviewed, so it can be added to the list of the approved registrars? What is an appropriate amount of time for that review to conclude?

PDP Working Group Preliminary Recommendation (PR) / Question (Q) / Option

ALAC Response

2.3.2: Global Public Interest (WT2)

PR 2.3.2.c.1 Mandatory PICs:

The Work Track is considering a recommendation to codify the current implementation of mandatory PICs as policy recommendations.256 In addition, such mandatory PICs should be revisited to reflect the ongoing discussions between the GAC Public Safety Working Group and Registries as appropriate.

(Holly, Bastiaan)

Voluntary PICs:

PR 2.3.2.c.2

The Work Track recommends continuing the concept of voluntary Public Interest Commitments and asking applicants to state any voluntary PICs in their application. In addition, the Work Track supports the ability of applicants to commit to additional voluntary PICs in response to public comments, GAC Early Warnings and/or GAC Advice. The Work Track acknowledges that changes to voluntary PICs may result in changing the nature of the application except where expressly otherwise prohibited in the Applicant Guidebook and that this needs further discussion.

PR 2.3.2.c.3

At the time a voluntary PIC is made, the applicant must set forth whether such PIC is limited in time, duration and/or scope such that the PIC can adequately be reviewed by ICANN, an existing objector (if applicable) and/or the GAC (if the voluntary PIC was in response to a GAC Early Warning or GAC Advice).

PR 2.3.2.c.4

To the extent that a Voluntary PIC is accepted, such PIC must be reflected in the applicant’s Registry Agreement. A process to change PICs should be established to allow for changes to that PIC to be made but only after being subject to public comment by the ICANN community. To the extent that the PIC was made in response to an objection, GAC Early Warning and/or GAC Advice, any proposed material changes to that PIC must take into account comments made by the applicable objector and/or the applicable GAC member(s) that issued the Early Warning, or in the case of GAC Advice, the GAC itself.

Q 2.3.2.e.1

Do you believe that there are additional Public Interest Commitments that should be mandatory for all registry operators to implement? If so, please specify these commitments in detail.

Q 2.3.2.e.2

Should there be any exemptions and/or waivers granted to registry operators of any of the mandatory Public Interest Commitments? Please explain.

Q 2.3.2.e.3

For any voluntary PICs submitted either in response to GAC Early Warnings, public comments, or any other concerns expressed by the community, is the inclusion of those PICs the appropriate way to address those issues? If not, what mechanism do you propose?

Q 2.3.2.e.4

To what extent should the inclusion of voluntary PICs after an application has been submitted be allowed, even if such inclusion results in a change to the nature of the original application?

Q 2.3.2.e.5

If a voluntary PIC does change the nature of an application, to what extent (if any) should there be a reopening of public comment periods, objection periods, etc. offered to the community to address those changes?

Q 2.3.2.e.6

The Work Track seeks to solicit input in regards to comments raised by the Verified TLD Consortium and National Association of Boards of Pharmacy that recommended a registry should be required to operate as a verified TLD if it 1) is linked to regulated or professional sectors; 2) is likely to invoke a level of implied trust from consumers; or 3) has implications for consumer safety and well-being. In order to fully consider the impact and nature of this recommendation, the WG is asking the following questions:

• 2.3.2.e.6.1: How would such a registry be recognized to be in line with these three criteria and who would make such a judgement?

• 2.3.2.e.6.2: What types of conditions should be placed upon a registry if it is required to operate as a verified TLD?

PDP Working Group Preliminary Recommendation (PR) / Question (Q) / Option

ALAC Response

2.3.3: Applicant Freedom of Expression (WT3)

PR 2.3.3.c.1

Work Track 3 discussed the protection of an applicant’s freedom of expression rights and how to ensure that evaluators and dispute resolution service providers (DSRPs) performed their roles in such a manner so as to protect these fundamental rights. The Work Track generally believes that the implementation guidelines should be clarified to ensure that dispute resolution service providers and evaluators are aware that freedom of expression rights are to be considered throughout the evaluation and any applicable objection processes as well as any Requests for Reconsideration and/or Independent Review Panel proceedings.  To do this, each policy principle should not be evaluated in isolation from the other policy principles, but rather should involve a balancing of legitimate interests where approved policy goals are not completely congruent or otherwise seem in conflict. Applicant freedom of expression is an important policy goal in the new gTLD process and should be fully implemented in accordance with the applicant’s freedom of expression rights that exist under law.

Q 2.3.3.e.1

What specific advice or other guidance should dispute resolution service providers that adjudicate objections proceedings and other evaluators be given to ensure that the policy principle of protecting applicant freedom of expression can be effectively implemented in the overall program?

Q 2.3.3.e.2

When considering Legal Rights Objections, what are some concrete guidelines that can be provided to dispute resolution service providers to consider “fair use,” “parody,” and other forms of freedom of expression rights in its evaluation as to whether an applied for string infringes on the legal rights of others?

Q 2.3.3.e.3

In the evaluation of a string, what criteria can ICANN and/or its evaluators apply to ensure that the refusal of the delegation of a particular string will not infringe an applicant’s freedom of expression rights?

PDP Working Group Preliminary Recommendation (PR) / Question (Q) / Option

ALAC Response

2.3.4: Universal Acceptance (WT4)

PR 2.3.4.c.1 Amended Principle B:

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 and 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.

(Eduardo)

Q 2.3.4.e.1

Work Track 4 is not proposing any additional work beyond that being done by the Universal Acceptance Initiative and the Universal Acceptance Steering Group. Do you believe any additional work needs to be undertaken by the community?

(Eduardo, updated)

Universal Acceptance (UA) is all about ensuring that: "Internet applications and systems must treat all TLDs (as well as identifiers derived from them such as URLs and email IDs) in a consistent manner, including new gTLDs and internationalized TLDs. Specifically, they must accept, validate, store, process and display all domain names".

The ALAC understands that the UA issue also involves informing, influencing and persuading all stakeholders of the Internet (including giants such as Microsoft and Google, all the way to end-users) about these changes and helping them achieve them.

As such, the ALAC is recommending the following:  Registries and Registrars, if they are own by the same entity, should be Universal Acceptance (UA) ready as part of their application. This mean that their systems should be ready for IDN registrations, ready handle IDN and non-IDN new gTLDs consistently on nameservers and other machines and able to manage any Email Address Internationalization (EAI), i.e.  <nativelanguage>@<idn>.<idn>, as part of the contact information and be able to send and receive emails from these type of addresses.

For example, if a government department wants to use an EAI address to communicate with a business, the Registries should be able to accept the email and respond to it. Registry systems that store any registrant data - including email addresses or name servers or anything else must be able to accept IDNs and EAI in their systems.

In addition, Registries and Registrars should take affirmative actions to ensure that their suppliers are also UA ready.

PDP Working Group Preliminary Recommendation (PR) / Question (Q) / Option

ALAC Response

2.4.1: Applicant Guidebook (WT1)

PR 2.4.1.c.1

Work Track 1 generally agreed that an Applicant Guidebook (AGB) of some form should continue to be utilized in future waves of applications. The Work Track generally agreed, however, that the Applicant Guidebook should be made more user friendly.

(Justine)

The ALAC supports this preliminary recommendation.

PR 2.4.1.c.2

In order to enhance accessibility for ease of understanding, especially for non-native English speakers and those that are less familiar with the ICANN environment, the Work Track believes that the AGB should:

PR 2.4.1.c.2.1

Be less focused on historical context and to the extent it is included, concentrate this content in appendices if possible.

(Justine)

In so far as the AGB’s primary target audience is applicants, the ALAC agrees with this preliminary recommendation. We also believe it is important to maintain a reference to historical context and that may well be included in appendices.

PR 2.4.1.c.2.2

Be less about policy, with a stronger focus on the application process.

(Justine)

In so far as the AGB’s primary target audience is applicants, the ALAC agrees with this preliminary recommendation. However, we believe it is important to maintain the link between application process and policy which underpin the same.

PR 2.4.1.c.2.3

Be focused on serving as a practical user guide that applicants can utilize in applying for a TLD. For instance, step-by-step instructions, possibly by type of application with a ‘choose your own adventure’ methodology.

(Justine)

In so far as the AGB’s primary target audience is applicants, the ALAC agrees with this preliminary recommendation.

PR 2.4.1.c.2.4

Have an improved Table of Contents, include an index and the online version should contain links to appropriate sections, definitions, etc.

(Justine)

In so far as the AGB’s primary target audience is applicants, the ALAC agrees with this preliminary recommendation.

PR 2.4.1.c.2.5

The online version could have sections that apply specifically to the type of application being applied for with the ability to only print those related sections.

(Justine)

In so far as the AGB’s primary target audience is applicants, the ALAC agrees with this preliminary recommendation.

PR 2.4.1.c.2.6

In conjunction with the above, the online version should allow for advanced indexing of an omnibus text. A core set of standard provisions may be applicable to everyone, but additional provisions may only be applicable to some. If the text is tagged and searchable, users could more easily locate the parts of the text that are relevant to them.

(Justine)

In so far as the AGB’s primary target audience is applicants, the ALAC agrees with this preliminary recommendation. However, tagging of text for greater search ability would also benefit the ICANN community’s use of the AGB.

PR 2.4.1.c.2.7

Any Agreements/Terms of Use for systems access (including those required to be “clicked-through” should be finalized in advance and included in the Applicant Guidebook with the goal of minimizing obstacles and/or legal burdens on applicants (see section 2.4.3 on Systems).   

(Justine)

The ALAC agrees with this preliminary recommendation.

PDP Working Group Preliminary Recommendation (PR) / Question (Q) / Option

ALAC Response

2.4.2: Communications (WT1)

Program Information, Education and Outreach:

PR 2.4.2.c.1

The Work Track believes that for the next round of new gTLDs there should continue to be a minimum of four (4) months from the time in which the final Applicant Guidebook is released and the time until which applications would be finally due.

(Justine, drawing from remarks to 2.5.4 AS)

The ALAC believes that the amount of time between which the final AGB is released and the time until which applications would be finally due is a function of (1) the clarity of policies, rules and procedures for the Program, and (2) how well they are set out in the AGB and accessible.

PR 2.4.2.c.2

There should be a sufficient period of time available prior to the opening of the application submission period to allow for outreach efforts related to Applicant Support and other program elements and execution of the Communication Plan (“Communications Period”).

• 2.4.2.c.2.1: The Communications Period for the next round of new gTLDs should be at least six (6) months.

• 2.4.2.c.2.2: In the event that following the next round of new gTLDs, application opportunities are organized as a series of application windows, the Communications Period may be shortened to three (3) months.

(Justine, drawing from remarks to 2.5.4 AS)

The ALAC welcomes this preliminary recommendation which recognizes the need to have a sufficiently effective Communications Period. Based on what occurred for the 2012 round, we believe the amount of lead time for effective devising and implementation of outreach efforts related to the ASP and other program elements could very well exceed six months.

PR 2.4.2.c.3

Publish all program information on the main icann.org website (as opposed to https://newgtlds.icann.org), along with other related ICANN information and links to improve usability and accessibility.

(Justine)

The ALAC does not believe it is necessary to publish all information on the Program on the main icann.org website. Use of a sub-website such as https://newgtlds.icann.org has merits. What is more important is there be a prominent entry on the main icann.org website directing attention to all related information about the Program, and yes, appropriate links should be included to improve usability and accessibility but not to the point of causing information overload to those who access the information.

PR 2.4.2.c.4

Leverage Global Stakeholder Engagement staff to facilitate interaction between regional ICANN organization teams and potential applicants from these regions.

(Adapted from ALAC CC2 comment)

ICANN’s Global Stakeholder Engagement (GSE) team is responsible for promotion global awareness of the Program. At-Large do not have much authority to undertake any real communication activity without funding and other support from GSE and At-Large Support staff. However, communication to the masses is an important feature of getting the right messages out about ICANN, the DNS, etc, RSP and Applicant Support Program (ASP), and the GSE team has not been successful in getting these out to underserved and “middle applicant” regions/countries targeted for the ASP. However RALOs are disadvantaged when outreach opportunities funded by ICANN are limited to few CROP slots. As an example, the APRALO deals with over 70 countries with the fastest growth of Internet end-users of all regions. Such is the extent of this problem, regional teams need to be organized within underserved / “middle applicant” regions to more effectively introduce, educate and inform people who may be qualified but without the right contacts to learn about the RSP program and ASP.

Communications with Applicants:

PR 2.4.2.c.5

Provide a robust online knowledge base of program information that is easy to search and navigate, updated in a timely manner, and focused on issues with wide-reaching impact. Offer an opt-in notification service that allows applicants to receive updates about the program and their application in real or near real time.

(Justine)

The ALAC does not object to this preliminary recommendation.

PR 2.4.2.c.6

Display and provide updates in a timely manner on expected response times on the website, so that applicants know when they can expect to receive a reply, as well as information about how applicants can escalate inquiries that remain unresolved.

(Justine)

The ALAC supports this preliminary recommendation.

PR 2.4.2.c.7

Facilitate communication between applicants and the ICANN organization by offering real-time customer support using a telephone “help line,” online chat functionality, and other online communication tools.

(Justine)

The ALAC does not object to this preliminary recommendation.

Q 2.4.2.e.1

Do you have any suggestions of criteria or metrics for determining success for any aspects of the new gTLD communications strategy?

(from ALAC CC2 comments)

Success could be measured in the number of people who apply for the training programs, and successfully achieve it outcomes, those who eventually get to set up their own RSP (or who gather together in a team to do so within a region). Success could also relate to the number of outreach opportunities within each of the region that results in getting people to apply, and talking to them about the Program.

Q 2.4.2.e.2

The communications period prior to the 2012 round of new gTLDs was approximately six months. Was this period optimal, too long or too short? Please explain.

(Justine)

Based on what occurred for the 2012 round, the ALAC believes the amount of lead time for effective devising and implementation of outreach efforts related to the ASP and other program elements could very well exceed six months.

Q 2.4.2.e.3

If ICANN were to launch new application windows in regular, predictable windows, would a communications period prior to the launch of each window be necessary? If so, would each communications period need to be the same length? Or if the application windows are truly predictable, could those communication periods be shorter for the subsequent windows?

(Justine)

The ALAC believes such a communications period will be necessary in so far as there is a need to communicate any changes to the Program as a result of changes in applicable policies, rules or procedures (if any). Further, we believe the communications period (and strategy) is meant to benefit newcomers to the DNS industry and not necessarily existing players. In this respect, the communication periods for if the application windows are truly predictable should not be shorter for subsequent windows. 

PDP Working Group Preliminary Recommendation (PR) / Question (Q) / Option

ALAC Response

2.4.3: Systems (WT1)

PR 2.4.3.c.1

The ICANN organization should ensure that enough time is provided for development and testing before any system is deployed.

PR 2.4.3.c.2

Systems should undergo extensive, robust Quality Assurance (QA), User Interface (UI), and Penetration testing to ensure that they are stable and secure, and that data is properly protected and kept confidential where appropriate. 

PR 2.4.3.c.3

Applicant-facing systems should be usable and integrated, ideally with a single login.

PR 2.4.3.c.4

Once a system is in use, the ICANN organization should be transparent about any system changes that impact applicants or the application process. In the event of any security breach, ICANN should immediately notify all impacted parties.

PR 2.4.3.c.5

The ICANN organization should offer prospective system end-users with the opportunity to beta-test systems while ensuring no unfair advantages are created for individuals who test the tools. It may accomplish this by setting up an Operational Test and Evaluation environment.

PR 2.4.3.c.6

As stated in section 2.4.1 above, “Any Agreements/Terms of Use for systems access (including those required to be “clicked-through”) should be finalized in advance and included in the Applicant Guidebook with the goal of minimizing obstacles and/or legal burdens on applicants.

Implementation Guidance regarding technical systems:

PR 2.4.3.c.7

Applicants should be able to enter non-ASCII characters in certain fields.

PR 2.4.3.c.8

Applicants should be able to access live (real time) support using tools such as a phone helpline or online chat to address technical system issues.

PR 2.4.3.c.9

A single applicant should be able to submit and access multiple applications without duplicative data entry and multiple logins.

PR 2.4.3.c.10

Applicants should be able to receive automated confirmation emails from the systems.

PR 2.4.3.c.11

Applicants should be able to receive automated application fee related invoices.

PR 2.4.3.c.12

Applicants should be able to view changes that have been made to an application in the application system.

PR 2.4.3.c.13

Applicants should be able to upload application documents in the application system.

PR 2.4.3.c.14

Applicants should be able to update information/documentation in multiple fields without having to copy and paste information into the relevant fields.

PR 2.4.3.c.15

Applicants should be able to specify additional contacts to receive communication about the application and/or access the application and be able to specify different levels of access for these additional points of contact. The systems should provide means for portfolio applicants to provide answers to questions and then have them disseminated across all applications being supported.

PR 2.4.3.c.16

The systems should provide clearly defined contacts within the ICANN organization for particular types of questions.

PDP Working Group Preliminary Recommendation (PR) / Question (Q) / Option

ALAC Response

2.5.1: Application Fees (WT1)

PR 2.5.1.c.1

Work Track 1 is considering proposing that the New gTLD Program continue to be self-funding where existing ICANN activities are not used to cross-subsidize the new gTLD application, evaluation, pre-delegation and delegation processes.

(Bastiaan)

PR 2.5.1.c.2

In addition, the Work Track generally believes that the application fee amount should continue to be based on the “revenue neutral” principal, though the accuracy should be improved to the greatest extent possible. Although the 2012 New gTLD Applicant Guidebook remained silent on what should happen with any excess fees obtained through the application process, the Work Track is leaning towards recommending that absent the use of an application fee floor (described in 3 below) excess fees should be refunded back to applicants.  If a deficit arises, the Work Track considered several options (see deliberations below), but there seemed to be support for ICANN recovering the majority of funds in future TLD application windows.

PR 2.5.1.c.3

The Work Track also is considering proposing that if in the event that the estimated application fee, based on the “revenue neutral” principal, falls below a predetermined threshold amount (i.e., the application fee floor), the actual application fee will be set at that higher application fee floor instead. The purpose of an application fee floor, as more fully discussed below, would be to deter speculation, warehousing of TLDs, and mitigating against the use of TLDs for abusive or malicious purposes, that could more easily proliferate with a low application fee amount.

PR 2.5.1.c.4

The application fee floor is a predetermined value that is the minimum application fee. By definition, an application fee floor will not meet the revenue neutral principle as the floor amount will be greater than the application fees creating an excess. In the event that an application fee floor is used to determine the application fee, excess fees received by ICANN if the application fee floor is invoked should be used to benefit the following categories:

• Support general outreach and awareness for the New gTLD Program (e.g., Universal Awareness and Universal Acceptance initiatives)

• Support the gTLD long-term program needs such as system upgrades, fixed assets, etc.

• Application Support Program

• Top-up any shortfall in the segregated fund as described below.

PR 2.5.1.c.5

To help alleviate the burden of an overall shortfall, a separate segregated fund should be set up that can be used to absorb any shortfalls and topped-up in a later round. The amount of the contingency should be a predetermined value that is reviewed periodically to ensure its adequacy.

Q 2.5.1.e.1

To the extent that warehousing/ squatting of TLDs has taken place and may occur in the future, what other restrictions/methodologies, beyond pricing, might prevent such behavior?

Q 2.5.1.e.2

What happens if the revenue-cost neutral amount results in a refund that is greater than the application fee floor value? Should it be only the difference between the cost floor and the amount refunded? Should there be any minimum dollar value for this to come into effect? i.e. the amount of the refund is a small amount, and if so, should this excess be distributed differently, i.e. Universal Awareness, Applicant Support, other?

Q 2.5.1.e.3

What are the considerations/implications if we move to continuous rounds, in this case limited to how it relates to ensuring the program is run in a revenue neutral manner?

Q 2.5.1.e.4

Are there policy, economic, or other principles or factors that might help guide the establishment of the floor amount?

Q 2.5.1.e.5

Under the circumstance where the application fee is set at the floor amount, do you have additional suggestions or strategy on the disbursement of excess funds?

Q 2.5.1.e.6

Are we acknowledging and accepting of ICANN being a so-called “registry of registries” (i.e., does the community envision ICANN approving a few thousand / hundreds of thousands / millions of gTLDs to be added to the root? Should there be a cap?)

Q 2.5.1.e.7

Is there a way in which the application fee can be structured such that it can encourage competition and innovation?

Q 2.5.1.e.8

How do we address the timely disbursement of excess funds? Can this happen prior to the “end” of the evaluation process for all applications? If yes, please explain. If not, what is the length of time applicants should expect a refund after the evaluation process is complete?

2.5.2: Variable Fees (WT1)

PR 2.5.2.c.1

Though Work Track 1 discussed a number of different possible alternative approaches, there was no agreement on any alternatives to the 2012 round; namely that all applications should incur the same base application fee amount regardless of the type of application or the number of applications that the same applicant submits.  This would not preclude the possibility of additional fees in certain circumstances, as was the case in the 2012 round of the program (e.g., objections, Registry Service Evaluation Process, etc.)

(Bastiaan)

Option 2.5.2.d.1

Different application fees for different types of applications is only warranted if the cost incurred for processing those different types is significant (for discussion purposes, 20% was used).

Option 2.5.2.d.2

Fees imposed for changing the type of application should be higher than applying for the desired TLD type originally (for discussion purposes, the applicant must pay 125% of the difference between the different application types in terms of fees plus any other related processing fees.)

Q 2.5.2.d.1

If the number of applications exceed capacity limits and projected processing costs (assuming these are limiting factors) should there be an option to increase capacity and costs to meet service expectations? If so, how should capacity vs. increased costs and/or limits be set? What is an acceptable increase and how would the actual percentage be determined?

Q 2.5.2.d.2

Should there be any exception to the rule that all applicants pay the same application fee regardless of the type of application? What exceptions might apply? Why or why not?

Q 2.5.2.d.3

If different types of applications result in different costs, what value (e.g., amount, percentage, other) would justify having different fees? How could we seek to prevent gaming of the different costs?

Q 2.5.2.d.4

If fees are imposed for changing the type of application, again what is an acceptable percentage and how should the percentage be determined?

PDP Working Group Preliminary Recommendation (PR) / Question (Q) / Option

ALAC Response

2.5.3: Application Submission Period (WT1)

Option 2.5.3.c.1

For the next round of new TLD applications, applicants should have a minimum of three (3) months from the time in which the application systems open until the time in which applications would become due (“application submission period”). This recommendation would apply if the next application opportunity is structured as a round.

Option 2.5.3.d.2

In the event that following the next round of new gTLDs, application opportunities are organized as a series of application windows, steps related to application processing and delegation should be able to occur in parallel with the opening of subsequent application windows.

Option 2.5.3.d.3

In the event that following the next round of new gTLDs, application opportunities are organized as a series of application windows, the Applications submission period may be shortened to two (2) months.

Q 2.5.3.e.1

For the next round, is having the applicant submission period set at three (3) months sufficient?

Q 2.5.3.e.2

Is the concept of a fixed period of time for accepting applications the right approach? Why or why not? Does this help facilitate a predictable schedule for submission and objections/comments?

PDP Working Group Preliminary Recommendation (PR) / Question (Q) / Option

ALAC Response

2.5.4: Applicant Support (WT1)

PR 2.5.4.c.1

In the 2012 round, although anyone could apply, applicants that operated in a developing economy were given priority in the Applicant Support Program (ASP). The Work Track generally agreed that Applicant Support should continue to be open to applicants regardless of their location so long as they meet the other criteria.

(Justine, Holly, Tijani, Marita, Maureen, Olivier, Alexander, Vanda, Jonathan, Andrew, Alan)

The ALAC agrees with this preliminary recommendation that Applicant Support should continue to be open to applicants regardless of their location so long as they meet the other criteria. In fact, discussions within At-Large pointed out that location of the applicant should not be a key determining factor. Also, in the context of location, it should be reinforced that it is the location of the communities proposed to be served by an application rather than the location of the applicant that matters.

PR 2.5.4.c.2

Geographic outreach areas should not only target the Global South, but also consider the “middle applicant” which are struggling regions that are further along in their development compared to underserved or underdeveloped regions.

The ALAC agrees with this preliminary recommendation. Geographic outreach areas were never meant to only target the Global South.

PR 2.5.4.c.3

Applicants who do not meet the requirements of the ASP should be provided with a limited period of time (that does not unreasonably delay the program) to pay the additional application fee amount and transfer to the relevant application process associated with their application.

The ALAC supports this preliminary recommendation. Further, the ALAC believes that all ASP applicants should be allowed to decide if they wish to pursue or withdraw their application in the event they are determined as not meeting the criteria for the ASP, knowing that they would be provided Sufficient time to pay the balance of the full application fee amount unless the Support Application Review Panel (SARP) determines that an application has been the subject of wilful gaming. Terminating all applications determined as not meeting the criteria as was the case in the 2012 round is a disproportionate means of preventing gaming of the ASP.

PR 2.5.4.c.4

ICANN should improve the awareness of the ASP by engaging with other ICANN communities and other suitable partners that include, but not limited to, focus on technology and communication industries, especially in underserved regions, while improving awareness through extensive promotional activities.

The ALAC agrees strongly with this preliminary recommendation. We believe it is imperative that ICANN improves the awareness of the ASP through effective means.

PR 2.5.4.c.5

ICANN should employ a multifaceted approach based on pre-application support, including longer lead times to create awareness, encouraging participation of insightful experts who understand relevant regional issues and potential ramifications on the related business plans, along with the tools and expertise on how to evaluate the business case, such as developing a market for a TLD.

The ALAC strongly supports this preliminary recommendation and suggests that resources be applied to systematically identify and address barriers to applications.

PR 2.5.4.c.6

Support should continue to extend beyond simply financial. ICANN’s approach should include mentorship on the management, operational and technical aspects of running a registry such as existing registries/registrars within the region to develop in-house expertise to help ensure a viable business for the long term.

The ALAC strongly supports this preliminary recommendation and suggests that resources be applied to systematically identify and address barriers to applications, and to facilitate assistance as described, where feasible.

PR 2.5.4.c.7

Additionally, financial support should go beyond the application fee, such as including application writing fees, related attorney fees, and ICANN registry-level fees.

The ALAC strongly supports this preliminary recommendation and suggests that resources be applied to systematically identify and address barriers to applications.

PR 2.5.4.c.8

ICANN should evaluate additional funding partners, including through multilateral and bilateral organizations, to help support the ASP.

The ALAC strongly supports this preliminary recommendation.

PR 2.5.4.c.9

ICANN should consider whether additional funding is required for the next round opening of the Applicant Support Program.

The ALAC supports this preliminary recommendation. We believe that in anticipation of effective awareness and education of the ASP, then a sum of USD2 mil (as was the sum set aside for ASP in the 2012 round) would arguably not adequately support an anticipated increase in number of successful applicants, based on an increase in ASP applicants.  

Q 2.5.4.e.1

Work Track 1 generally agreed that the Applicant Support Program (ASP) should be open to applicants regardless of their location (see recommendations 2.5.4.c.1 and 2.5.4.c.2 above). How will eligibility criteria need to be adjusted to accommodate that expansion of the program?

The ALAC is of the opinion that the perceived threat of gaming in the ASP in the 2012 round which culminated in ASP-disqualified applications being rejected altogether had contributed to the extremely low numbers of ASP applicants. The eligibility criteria for ASP in the 2012 round also somewhat mirrored that for Community Priority Evaluation (CPE) even though the SARP were said to have been given instructions to be more liberal in its interpretation of Community Based priority criteria, this proved problematic.

For greater success for the ASP, and consequently an expansion of the Program, the eligibility criteria should to be adjusted as follows:

Under Criteria #1 – Public Interest  

1. Community based project

• A more liberal approach in scoring the community establishment limb (tie to CPE Community definition criteria); and
• A more liberal approach in scoring the nexus between proposed string and community (in other words, a foreseeable nexus rather than an actual nexus would suffice); or
• Either dispense with the need to meet the criteria in all four tests in order to score 1 point or allow scoring of 0.25 points for each of the four tests, as opposed to nil; and
• Reduce the threshold score to 4.5 instead of 5 of 9.

4. Operation in a developing economy

• Applicants should be scored based on the location or identity of the proposed beneficiaries and less on the location of the applicant itself. However, applicants who are both from a developing economy and whose application proposes to benefit communities in a developing economy or indigenous communities would score the highest points.

Q 2.5.4.e.2

What does success look like? Is it the sheer number of applications and/or those approved? Or a comparison of the number that considered applying vs. the number that actually completed the application process (e.g., developed its business plan, established financial sustainability, secured its sources of funds, ensured accuracy of information?)

• 2.5.4.e.2.1: What are realistic expectations for the ASP, where there may be critical domain name industry infrastructure absent or where operating a registry may simply not be a priority for the potential applicants?

The ALAC opines that success should be based on the number of applications which qualified for ASP and which were ultimately approved, as we believe the number of applications for ASP is merely a contributing factor measuring the success of the Program communications strategy.

We would also suggest that the element of diversity be considered – in terms of application versus approval numbers from outside the US/Europe region, geographic spread and for IDNs.

As for Q 2.5.4.e.2.1, the realistic expectations under said circumstances would be at least some successful applicants (new operating registries) assisted by the ASP, but not many.   

Q 2.5.4.e.3

If there are more applicants than funds, what evaluation criteria should be used to determine how to disperse the funds: by region, number of points earned in the evaluation process, type of application, communities represented, other?

The ALAC believes that in such event, the evaluation criteria to be used for dispersion of funds should be based on the number of points earned in the evaluation process (assuming that all the other considerations are included in the eligibility criteria). 

Q 2.5.4.e.4

Did the ASP provide the right tools to potential program participants? If not, what was missing?

The ALAC believes that there was insufficient outreach to potential program participants and that more realistic eligibility criteria should be adopted for evaluating ASP applicants.

Q 2.5.4.e.5

How can we best ensure the availability of local consulting resources?

The ALAC suggests that ccTLD operators be tapped to ensure availability of local consulting resources. Further, a better designed ASP would also help.

Q 2.5.4.e.6

How can we improve the learning curve – what ideas are there beyond mentorship?

The ALAC suggests that resources be applied to systematically identify and address barriers to applications.

Q 2.5.4.e.7

How do we penalize applicants who may try to game the system?

By devising a component of the evaluation methodology for the SARP to determine if an application was the subject of wilful gaming and rejecting such application outright.

Q 2.5.4.e.8

Are there any considerations related to string contention resolution and auctions to take into account?

Applicants who are subject to string contention resolution procedures and auctions are expected to have the financial wherewithal to see through the resolution procedure or participate in an auction as a last resort.  Applicants who qualify for ASP are by default disadvantaged in this respect, given their need to obtain Applicant Support in the first place. Hence, perhaps in addition to fee reduction, Applicant Support could be extended to include either financial or non-financial resources to level the playing field to string contention resolution or auction.

Q 2.5.4.e.9

Should there be a dedicated round for applicants from developing countries?

There is some support within At-Large for a dedicated round for applicants from developing countries and which proposes to benefit communities in developing countries or indigenous communities.

Q 2.5.4.e.10

What should the source of funding be for the ASP? Should those funds be considered an extra component of the application fee? Should ICANN use a portion of any excess fees it generates through this next round of new gTLDs to fund subsequent Application Support periods?

Possible sources of funding for the ASP are (1) the excess application/evaluation fees generated from the 2012 round, and (2) proceeds from the auctions undertaken to resolve contention sets from the 2012 round.

There is some support within At-Large that for those funds be considered an extra component of the application fee for the upcoming round. There is also support within At-Large for ICANN to use a portion of any excess fees it generates through this next round of new gTLDs to fund subsequent Application Support periods.

Q 2.5.4.e.11

Are there any particular locales or groups that should be the focus of outreach for the ASP (e.g., indigenous tribes on various continents)?

There is some support within At-Large for ASP outreach to be targeted at communities based in developing countries/regions or “middle applicants”, with one particular group to be prioritized, that being the Native Peoples (indigenous tribes on various continents).

PDP Working Group Preliminary Recommendation (PR) / Question (Q) / Option

ALAC Response

2.5.5: Terms and Conditions (WT2)

PR 2.5.5.c.1

Work Track 2 believes that there should continue to be a Terms and Conditions document separate and apart from the Registry Agreement. Although the majority of the Terms and Conditions contained in the 2012 round were generally acceptable, the Work Track is considering proposing the following changes.

PR 2.5.5.c.2 & PR 2.5.5.c.3

Section 3 of the 2012 Terms and Conditions states that ICANN may deny any new TLD application for any reason at its sole discretion. It also allows ICANN to reject any application based on applicable law. The Work Track believes:

• 2.5.5.c.2: Unless required under specific law or the ICANN Bylaws, ICANN should only be permitted to reject an application if done so in accordance with the Terms and Conditions of the Applicant Guidebook. 

• 2.5.5.c.3: In the event an application is rejected, the ICANN organization should be required to cite the reason in accordance with the Applicant Guidebook, or if applicable, the specific law and/or ICANN Bylaw for not allowing an application to proceed.

PR 2.5.5.c.4

Section 6 currently gives ICANN a broad disclaimer of representations and warranties, but also contains a covenant by the applicant that it will not sue ICANN for any breach of the Terms and Conditions by ICANN. In general, the Work Track was not comfortable with the breadth of this covenant to not sue and Work Track members disagreed with the covenant not to sue as a concept. However, if the covenant not to sue ICANN is maintained, there must be a challenge/appeal mechanism established above and beyond the general accountability provisions in the ICANN Bylaws that allows for substantive review of the decision. This mechanism should look into whether ICANN (or its designees/contractors) acted inconsistently (or failed to act consistently) with the Applicant Guidebook (see section 2.8.2 on Accountability Mechanisms for further detail).

PR 2.5.5.c.5

Section 14 allows ICANN to make reasonable updates to the Applicant Guidebook at its discretion. The Work Track generally agrees that to the extent that substantive changes are made to the Applicant Guidebook or program processes, applicants should be allowed some type of recourse, including if applicable, the right to withdraw an application from ICANN’s consideration in exchange for a refund. A framework for ICANN to make transparent changes to the Applicant Guidebook as well as available recourse to change applications or withdraw for applicants should be laid out.

Q 2.5.5.e.1

Are there any other changes that should be made to the Applicant Terms and Conditions that balances ICANN’s need to minimize its liability as a non-profit organization with an applicant’s right to a fair, equitable and transparent application process?

Q 2.5.5.e.2

Under what circumstances (including those arising relative to the sections referenced above) should an applicant be entitled to a full refund?

Q 2.5.5.e.3

Some in the Work Track have noted that even if a limited challenge/appeals process is established (see preliminary recommendation 2 above), they believe the covenant to not sue the ICANN organization (i.e., Section 6 of the Terms and Conditions) should be removed. Others have noted the importance of the covenant not to sue, based on the ICANN organization’s non-profit status. Do you believe that the covenant not to sue should be removed whether or not an appeal process as proposed in section 2.8.2 on Accountability Mechanisms is instituted in the next round? Why or why not?

PDP Working Group Preliminary Recommendation (PR) / Question (Q) / Option

ALAC Response

2.6.1: Application Queuing (WT2)

PR 2.6.1.c.1

ICANN should not attempt to create a “skills-based” system like “digital archery” to determine the processing order of applications.

(Justine)

PR 2.6.1.c.2

ICANN should apply again for an appropriate license to conduct drawings to randomize the order of processing applications.

PR 2.6.1.c.3

If ICANN is able to secure such a license, applications should be prioritized for Initial Evaluation using a prioritization draw method similar to the method ultimately adopted in the 2012 round. Namely: Applicants who wish to have their application prioritized may choose to buy a ticket to participate in the “draw”; Applicants who choose not to buy a ticket will participate in a later draw to be held after the prioritized applicants; Assignment of a priority number is for the processing of the application and does not necessarily reflect when the TLD will be delegated.

PR 2.6.1.c.4

If an applicant has more than one application, they may choose which of their applications to assign to each priority number received within their portfolio of applications.

PR 2.6.1.c.5

To the extent that it is consistent with applicable law to do so, ICANN should include in the application amount the cost of participating in the drawing or otherwise assign a prioritization number during the application process without the need for a distinctly separate event.

PR 2.6.1.c.6

All applications submitted in the next round (regardless whether delegated or not) must have priority over applications submitted in any subsequent rounds/application windows even if the evaluation periods overlap.

Q 2.6.1.e.1

If there is a first-come, first-served process used after the next application window, how could ICANN implement such a process?

Q 2.6.1.e.2

In subsequent procedures, should IDNs and/or other types of strings receive priority in processing? Is there evidence that prioritization of IDN applications met stated goals in the 2012 round (served the public interest and increased DNS diversity, accessibility and participation)?

Q 2.6.1.e.3

If ICANN is unable to obtain a license to randomize the processing order of applications, what are some other mechanisms that ICANN could adopt to process applications (other than through a first-come, first-served process)?

Q 2.6.1.e.4

Some members have suggested that the processing of certain types of applications should be prioritized over others. Some have argued that .Brands should be given priority, while others have claimed that community-based applications or those from the Global South should be prioritized. Do you believe that certain types of applications should be prioritized for processing? Please explain.  

PDP Working Group Preliminary Recommendation (PR) / Question (Q) / Option

ALAC Response

2.7.1: Reserved Names (WT2)

PR 2.7.1.c.1: Reservation at the top level: Keep all existing reservations, but add:

• 2.7.1.c.1.1: The names for Public Technical Identifiers (i.e., PTI, PUBLICTECHNICALIDENTIFIERS, PUBLICTECHNICALIDENTIFIER).

• 2.7.1.c.1.2: Special-Use Domain Names through the procedure described in IETF RFC 6761.

PR 2.7.1.c.2

Reservations at the second level: Keep all existing reservations, but update Schedule 5 to include the measures for Letter/Letter Two-Character ASCII Labels to Avoid Confusion with Corresponding Country Codes adopted by the ICANN Board on 8 November 2016.

PR 2.7.1.c.3

The Work Track is also considering a proposal to remove the reservation of two-character strings at the top level that consist of one ASCII letter and one number (e.g., .O2 or .3M), but acknowledges that technical considerations may need to be taken into account on whether to lift the reservation requirements for those strings. In addition, some have expressed concern over two characters consisting of a number and an ASCII letter where the number closely resembles a letter (e.g., a “zero” looking like the letter “O” or the letter “L” in lowercase looking like the number “one”).

Q 2.7.1.e.1

The base Registry Agreement allows registry operators to voluntarily reserve (and activate) up to 100 strings at the second level which the registry deems necessary for the operation or the promotion of the TLD. Should this number of names be increased or decreased? Please explain. Are there any circumstances in which exceptions to limits should be approved? Please explain. 

Q 2.7.1.e.2

If there are no technical obstacles to the use of 2-character strings at the top level consisting of one letter and one digit (or digits more generally), should the reservation of those strings be removed? Why or why not? Do you believe that any additional analysis is needed to ensure that these types of strings will not pose harm or risk to security and stability? Please explain.

Q 2.7.1.e.3

In addition to the reservation of up to 100 domains at the second level, registry operators were allowed to reserve an unlimited amount of second level domain names and release those names at their discretion provided that they released those names through ICANN-accredited registrars. 

• 2.7.1.e.3.1 Should there be any limit to the number of names reserved by a registry operator? Why or why not?

• 2.7.1.e.3.2 Should the answer to the above question be dependent on the type of TLD for which the names are reserved (e.g., .Brand TLD, geographic TLD, community-based TLD and/or open)? Please explain.

• 2.7.1.e.3.3 During the 2012 round, there was no requirement to implement a Sunrise process for second-level domain names removed from a reserved names list and released by a registry operator if the release occurred after the general Sunrise period for the TLD. Should there be a requirement to implement a Sunrise for names released from the reserved names list regardless of when those names are released? Please explain. 

Q 2.7.1.e.4

Some in the community object to the Measures for Letter/Letter Two-Character ASCII Labels to Avoid Confusion with Corresponding Country Codes, adopted by the ICANN Board on 8 November 2016. Is additional work needed in this regard?

PDP Working Group Preliminary Recommendation (PR) / Question (Q) / Option

ALAC Response

2.7.2: Registrant Protections (WT2)

PR 2.7.2.c.1

Maintain the existing EBERO mechanism including triggers for an EBERO event and the critical registry functions that EBEROs provide as well as each of the other protections identified above.

PR 2.7.2.c.2

Single registrant TLDs (including those under Specification 13) should be exempt from EBERO requirements.

PR 2.7.2.c.3

Continue to allow publicly traded companies to be exempt from background screening requirements as they undergo extensive similar screenings, and extend the exemption to officers, directors, material shareholders, etc. of these companies.

PR 2.7.2.c.4

Improve the background screening process to be more accommodating, meaningful, and flexible for different regions of the world, for example entities in jurisdictions that do not provide readily available information.

Q 2.7.2.e.1

The deliberations section below discusses several alternate methods to fund the EBERO program. Please provide any feedback you have on the proposed methods and/or any other methods to fund EBERO in subsequent procedures.

Q 2.7.2.e.2

Should specific types of TLDs be exempt from certain registrant protections? If yes, which ones should be exempt? Should exemptions extend to TLDs under Specification 9, which have a single registrant? TLDs under Specification 13, for which registrants are limited to the registry operator, affiliates, and trademark licensees? If you believe exemptions should apply, under what conditions and why? If not, why not?

Q 2.7.2.e.3

ICANN’s Program Implementation Review Report stated that it may be helpful to consider adjusting background screening requirements to allow for meaningful review in different circumstances. Examples cited include newly formed entities and companies in jurisdictions that do not provide readily available information. Please provide feedback on ICANN’s suggestion along with any suggestions to make applicant background screenings more relevant and meaningful.

Q 2.7.2.e.4

Should publicly traded companies be exempt from background screening requirements? If so, should the officers, directors, and material shareholders of the companies also be exempt? Should affiliates of publicly traded companies be exempt?

Q 2.7.2.e.5

The Work Track is considering a proposal to include additional questions (see directly below) to support the background screening process. Should these questions be added? Why or why not?

• Have you had a contract with ICANN terminated or are being terminated for compliance issues?

• Have you or your company been part of an entity found in breach of contract with ICANN?"

PDP Working Group Preliminary Recommendation (PR) / Question (Q) / Option

ALAC Response

2.7.3: Closed Generics (WT2)

PR 2.7.3.c.1

The subject of Closed Generics has proved to be one of the most controversial issues tackled by Work Track 2 with strong arguments made by both those in favor of allowing Closed Generics in subsequent rounds and those opposing Closed Generics and in favor of keeping the current ban. Because this PDP was charged not only by the GNSO Council to analyze the impact of Closed Generics and consider future policy, a number of options emerged as potential paths forward with respect to Closed Generics, though the Work Track was not able to settle on any one of them. These options are presented in (d) below. The Work Track notes that there may be additional options that are not included in this list and welcomes suggested alternatives.

Option 2.7.3.d.1 No Closed Generics:

Formalize GNSO policy, making it consistent with the existing base Registry Agreement that Closed Generics should not be allowed.

Option 2.7.3.d.2 Closed Generics with Public Interest Application:

As stated above, GAC Advice to the ICANN Board was not that all Closed Generics should be banned, but rather that they should be allowed if they serve a public interest goal. Thus, this option would allow Closed Generics but require that applicants demonstrate that the Closed Generic serves a public interest goal in the application. This would require the applicant to reveal details about the goals of the registry. Under this option, Work Track 2 discussed the potential of an objections process similar to that of community-based objections challenging whether an application served a public interest goal. The Work Track recognized how difficult it would be to define the criteria against which such an application would be evaluated.

Option 2.7.3.d.3 Closed Generics with Code of Conduct:

This option would allow Closed Generics but require the applicant to commit to a code of conduct that addresses the concerns expressed by those not in favor of Closed Generics. This would not necessarily require the applicant to reveal details about the goals of the registry, but it would commit the applicant to comply with the Code of Conduct which could include annual self-audits. It also would establish an objections process for Closed Generics that is modelled on community objections.

Option 2.7.3.d.4 Allow Closed Generics:

This option would allow Closed Generics with no additional conditions but establish an objections process for Closed Generics that is modelled on community objections.

Q 2.7.3.e.1

What are the benefits and drawbacks of the above outlined options?

Q 2.7.3.e.2

Work Track 2 noted that it may be difficult to develop criteria to evaluate whether an application is in the public interest. For options 2 and 3 above, it may be more feasible to evaluate if an application does not serve the public interest. How could it be evaluated that a Closed Generic application does not serve the public interest? Please explain.

Q 2.7.3.e.3

For option 2.7.3.d.4 above, how should a Code of Conduct for Closed Generics serving the public interest be implemented? The Work Track sees that adding this to the existing Code of Conduct may not make the most sense since the current Code of Conduct deals only with issues surrounding affiliated registries and registrars as opposed to Public Interest Commitments. The Work Track also believes that this could be in a separate Specification if Closed Generics are seen as a separate TLD category. Would it be better to modify the current Code of Conduct or have a separate Code of Conduct for Closed Generics? Please explain. 

PDP Working Group Preliminary Recommendation (PR) / Question (Q) / Option

ALAC Response

2.7.4: String Similarity (WT3)

PR 2.7.4.c.1

Work Track 3 recommends adding detailed guidance on the standard of confusing similarity as it applies to 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 Work Track recommends:

● 2.7.4.c.1.1: 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 .CAR and .CARS could not both be delegated because they would be considered confusingly similar.

● 2.7.4.c.1.2: Expanding the scope of the String Similarity Review to encompass singulars/plurals of TLDs on a per-language basis. 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 during the same application window, these applications would be placed in a contention set, because they are confusingly similar. An application for a single/plural variation of an existing TLD would not be permitted.

○ Applications should not be automatically disqualified because of a single letter difference with an existing TLD. For example, .NEW and .NEWS should both be allowed, because they are not singular and plural versions of the same word.

● 2.7.4.c.1.3: Using a dictionary to determine the singular and plural version of the string for the specific language.

PR 2.7.4.c.2

In addition, the Work Track recommends eliminating use of the SWORD Tool in subsequent procedures.

PR 2.7.4.c.3

The Work Track also recommends that it should not be possible to apply for a string that is still being processed from a previous application opportunity.

Q 2.7.4.e.1

Are Community Priority Evaluation and auctions of last resort appropriate methods of resolving contention in subsequent procedures? Please explain.

Q 2.7.4.e.2

Do you think rules should be established to disincentivize “gaming” or abuse of private auctions? Why or why not? If you support such rules, do you have suggestions about how these rules should be structured or implemented?

Q 2.7.4.e.3

Should synonyms (for example .DOCTOR and .PHYSICIAN) be included in the String Similarity Review? Why or why not? Do you think the String Similarity Review standard should be different when a string or synonym is associated with a highly-regulated sector or is a verified TLD? Please explain.

PDP Working Group Preliminary Recommendation (PR) / Question (Q) / Option

ALAC Response

2.7.5: IDNs (WT4)

PR 2.7.5.c.1

General agreement in Work Track 4 that IDNs should continue to be an integral part of the program going forward (as indicated in Principle B of the original Final Report on New gTLDs).

(Satish?)

PR 2.7.5.c.2

General agreement that compliance with Root Zone Label Generation Rules (RZ-LGR, RZ-LGR-2, and any future RZ-LGR rules sets) should be required for the generation of IDN TLDs and valid variants labels.

PR 2.7.5.c.3

General agreement that 1-Unicode character gTLDs may be allowed for script/language combinations where a character is an ideograph (or ideogram) and do not introduce confusion risks that rise above commonplace similarities, consistent with SSAC and Joint ccNSO-GNSO IDN Workgroup (JIG) reports. Please see relevant question in section (f) below.

PR 2.7.5.c.4

Implementation Guidance: General agreement that to the extent possible, compliance with IDNA2008 (RFCs 5890-5895) or its successor(s) and applicable Root Zone Label Generation Rules (RZ-LGR, RZ-LGR-2, and any future RZ-LGR rules sets) be automated for future applicants.

PR 2.7.5.c.5

Implementation Guidance: General agreement that if an applicant is compliant with IDNA2008 (RFCs 5890-5895) or its successor(s) and applicable LGRs for the scripts it intends to support, Pre-Delegation Testing should be unnecessary for the relevant scripts.

PR 2.7.5.c.6

The Work Track discussed variants of IDN TLDs and is aware that the community will be tasked with establishing a harmonized framework (i.e., in gTLDs and ccTLDs) for the allocation of IDN variant TLDs of IDN TLDs. There is general agreement on the following:

2.7.5.c.6: IDN gTLDs deemed to be variants of already existing or applied for TLDs will be allowed provided: (1) they have the same registry operator implementing, by force of written agreement, a policy of cross-variant TLD bundling and (2) The applicable RZ-LGR is already available at the time of application submission.

Option 2.7.5.d.1:

Question 2.7.5.e.2 below regarding “bundling” asks whether the unification of implementation policies with respect to how variants are handled in gTLDs are matters for this PDP to consider or whether those matters should be handled through an Implementation Review Team or by each individual registry operator.

Q 2.7.5.e.1

For the recommendation regarding 1-Unicode character gTLDs above, can the more general “ideograph (or ideogram)” be made more precise and predictable by identifying the specific scripts where the recommendation would apply? Please see script names in ISO 15924.

Q 2.7.5.e.2

Should the policy of bundling second-level domains across variant TLDs be unified for all future new gTLDs or could it be TLD-specific? If unified, should it be prescribed in the Working Group final report or chosen at implementation? If TLD-specific, could it be any policy that adequately protects registrants, or would it need to be chosen from a menu of possible bundling implementations? Currently known bundling strategies include PIR’s .ong/.ngo, Chinese Domain Name Consortium guidance and Latin-script supporting ccTLDs such as .br and .ca.

Q 2.7.5.e.3

Are there any known specific scripts that would require manual validation or invalidation of a proposed IDN TLD?

Q 2.7.5.e.4

For IDN variant TLDs, how should the Work Track take into account the Board requested and yet to be developed IDN Variant Management Framework?

PDP Working Group Preliminary Recommendation (PR) / Question (Q) / Option

ALAC Response

2.7.6: Security and Stability (WT4)

PR 2.7.6.c.1

In the 2012-round, some applicants ended up applying for reserved or otherwise ineligible strings, causing them to later withdraw or be rejected. Towards preventing that and streamlining application processing, the Work Track suggests the following as Implementation Guidance: The application submission system should do all feasible algorithmic checking of TLDs, including against RZ-LGRs and ASCII string requirements, to better ensure that only valid ASCII and IDN TLDs can be submitted. A proposed TLD might be algorithmically found to be valid, algorithmically found to be invalid, or verifying its validity may not be possible using algorithmic checking. Only in the latter case, when a proposed TLD doesn’t fit all the conditions for automatic checking, a manual review should occur to validate or invalidate the TLD.

PR 2.7.6.c.2

For root zone scaling, the Work Track generally supports raising the delegation limit, but also agrees that ICANN should further develop root zone monitoring functionality and early warning systems as recommended by the SSAC, the RSSAC and the technical community.

Q 2.7.6.e.1

To what extent will discussions about the Continuous Data-Driven Analysis of Root Stability (CDAR) Report, and the analysis on delegation rates, impact Working Group discussions on this topic? How about the input sought and received from the SSAC, RSSAC, and the ICANN organization discussed below in section (f), under the heading Root Zone Scaling?

Q 2.7.6.e.2

The SSAC strongly discourages allowing emoji in domain names at any level and the Work Track is supportive of this position. Do you have any views on this issue?

PDP Working Group Preliminary Recommendation (PR) / Question (Q) / Option

ALAC Response

2.7.7: Applicant Reviews (WT4)

For all evaluations:

(Justine)

PR 2.7.7.c.1

In pursuit of transparency, publish (during the procedure) any Clarifying Questions (CQ) and CQ responses for public questions to the extent possible.

PR 2.7.7.c.2

Restrict scoring to a pass/fail scale (0-1 points only).

PR 2.7.7.c.3

An analysis of CQs, guidance to the Applicant Guidebook, Knowledge Articles, Supplemental Notes, etc. from the 2012 round need to be sufficiently analyzed with the goal of improving the clarity of all questions asked of applicants (and the answers expected of evaluators) such that the need for the issuance of Clarifying Questions is lessened. 

For Technical and Operational Evaluation:

PR 2.7.7.c.4

If an RSP pre-approval program is established (as described in section 2.2.6), a new technical evaluation will not be required for applicants that have either selected a “pre-approved” RSP in its application submission or if it commits to only using a pre-approved RSP during the transition to delegation phase.

PR 2.7.7.c.5

Consolidate the technical evaluation across applications as much as feasible, even when not using a pre-approved RSP. For example, if there are multiple applications using the same non-pre-approved RSP, that RSP would only have to be evaluated once as opposed to being evaluated for each individual application.

PR 2.7.7.c.6

For applicants that outsource technical or operational services to third parties, applicants should specify which services are being performed by them and which are being performed by the third parties when answering questions.

PR 2.7.7.c.7

Do not require a full IT/Operations security policy from applicants.

PR 2.7.7.c.8

Retain the same questions (except Q30b - Security Policy).

PR 2.7.7.c.9

“Applicants must be able to demonstrate their technical and operational capability to run a registry operation for the purpose that the applicant sets out, either by submitting it to evaluation at application time or agreeing to use a previously approved** technical infrastructure.” **(Could mean in the same procedure or previous procedures if an RSP program exists.)

PR 2.7.7.c.10

“The Technical and Operational Evaluation may be aggregated and/or consolidated to the maximum extent possible that generate process efficiencies, including instances both where multiple applications are submitted by the same applicant and multiple applications from different applicants share a common technical infrastructure.”

For Financial Evaluation:

PR 2.7.7.c.11

To the extent that it is determined that a Continued Operations Instrument will be required, it should not be part of the Financial Evaluation, but rather should only be required at the time of executing a Registry Agreement.

PR "2.7.7.c.12

Substitute the 2012 AGB evaluation of an applicant’s proposed business models and financial strength with the following:

● An applicant must identify whether the financials in its application apply to all of its applications, a subset of them or a single one (where that applicant (and/or its affiliates have multiple applications).

● ICANN won’t provide financial models or tools, but it will define goals and publish lists of RSPs, organizations (like RySG and BRG) and consultants.

● The goals of a financial evaluation are for the applicant to demonstrate financial wherewithal and assure long-term survivability of the registry. Therefore, the evaluation should look at whether an applicant could withstand not achieving revenue goals, exceeding expenses, funding shortfalls, or inability to manage multiple TLDs in the case of registries that are dependent upon the sale of registrations. However, there should also be a recognition that there will be proposed applications that will not be reliant on the sale of third party registrations and thus should not be subject to the same type of evaluation criteria. In other words, although the goals of the financial evaluation are to determine the financial wherewithal of an applicant to sustain the maintenance of a TLD, the criteria may be different for different types of registries. Criteria should not be established in a “one-size-fits-all” manner.

● If any of the following conditions are met, an applicant should be allowed to self-certify that it has the financial means to support its proposed business model associated with the TLD: If the applicant is a company traded on an applicable national public market; If the applicant and/or its Officers are bound by law in its jurisdiction to represent financials accurately; If the applicant is a current Registry Operator that is not in default on any of its financial obligations under its applicable Registry Agreements, and has not previously triggered the utilization of its Continued Operations Instrument.

● The applicant is required to provide credible 3rd-party certification of those goals if self-certification above is not used or achievable."

PR 2.7.7.c.13

To provide further clarity on the proposed financial evaluation model, the following are sample questions of how financials would be evaluated:

● Q45: “Identify whether this financial information is shared with another application(s)” (not scored).

● Q46: “Financial statements (audited, certified by officer with professional duty in applicant jurisdiction to represent financial information correctly or independently certified if not publicly-listed or current RO in good standing)” (0-1 scoring) (certification posted).

● Q47: “Declaration, certified by officer with professional duty in applicant jurisdiction to represent financial information correctly, independently certified if not publicly-listed or current RO in good standing, of financial planning meeting long-term survivability of registry considering stress conditions, such as not achieving revenue goals, exceeding expenses, funding shortfalls or spreading thin within current plus applied-for TLDs.” (0-1 scoring) (publicly posted).

● No other financial questions."

The Work Track proposes the following draft language for consideration, which would amend recommendation 8 from the 2007 Final Report:

For Financial Evaluation:

PR: 2.7.7.c.14

“Applicants must be able to demonstrate their financial and organizational operational capability in tandem for all currently-owned and applied-for TLDs that would become part of a single registry family.”

For Registry Services Evaluation:

PR 2.7.7.c.15

Allow for a set of pre-approved services that don’t require registry services evaluation as part of the new TLD application.; that set should include at least:

● Base contract required services (EPP, DNS publishing etc.)

● IDN services following IDN Guidelines

● BTAPPA (“Bulk Transfer After Partial Portfolio Acquisition”) "

PR 2.7.7.c.16

Since the content of Registry Agreement Amendment Templates for Commonly Requested Registry Services (https://www.icann.org/resources/pages/registry-agreement-amendment-templates-2018-01-29-en) satisfies the criteria above, referring to it instead of exhaustively enumerating the list is preferred. Applicants would inform which of the pre-approved services they want to be initially allowed in the registry agreement for that TLD.

● The Registry Services Evaluation Process should only be used to assess services that are not pre-approved. 

● Criteria used to evaluate those non-pre-approved registry services should be consistent with the criteria applied to existing registries that propose new registry services. To the extent possible, this may mean having the same personnel that currently reviews registry services for existing registries be the same personnel that reviews new registry services proposed by applicants. 

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

The Work Track proposes the following draft language for consideration for Registry Services Evaluation:

PR 2.7.7.c.17 “Applicants will be encouraged but not required to specify additional registry services that are critical to the operation and business plan of the registry. The list of previously approved registry services (IDN Languages, GPML, BTAPPA) will be included by reference in the Applicant Guidebook and Registry Agreement. If the applicant includes additional registry services, the applicant must specify whether it wants it evaluated through RSEP at evaluation time, contracting time, or after contract signing, acknowledging that exceptional processing could incur additional application fees. If the applicant has not included additional registry services, RSEP will only be available after contract signing.”

Q 2.7.7.e.1

While a financial evaluation model reached general agreement, Work Track 4 is seeking feedback on an option with more complex evaluations that was proposed that would be specific to a scenario where there are already many commercial TLDs operating and a number of delegated but yet unlaunched ones. Please see the reasoning for this proposal on the Work Track Wiki and of the model in the “Proposal - Straw Cookie-Monster” section of the document.

Q 2.7.7.e.2

If it is recommended that a registry only be evaluated once despite submitting multiple applications, what are some potential drawbacks of consolidating those evaluations? How can those issues be mitigated?

Q 2.7.7.e.3

Which financial model seems preferable and why?

Q 2.7.7.e.4

Some in the Work Track have suggested that ICANN provide a list of persons or entities that could assist applicants in establishing a proposed business model. Should ICANN be allowed or even required to maintain such a list? 

Q 2.7.7.e.5

The requirement to submit financial statements (especially with respect to non-public applicants that generally do not disclose financial information) was one of the main reasons applicants failed their initial evaluations in 2012. Although changes to financial evaluations are potentially being recommended, the Work Track is not suggesting changes to the requirement to submit financial statements. Are there any potential alternate ways in which an applicant’s financial stability can be measured without the submission of financial statements? If so, what are they?

Q 2.7.7.e.6

In Financial Evaluation, subsection 2.d, an exemption for public-traded companies is suggested. The Work Track hasn’t considered whether to include affiliates in that exemption; should it be changed to also allow exemption in such cases?

Q 2.7.7.e.7

An alternative to the Registry Services Evaluation was to not allow any services to be proposed at the time of application and instead to require all such services to be requested after contracting. What would be the pros and cons of that alternative?

Q 2.7.7.e.8

Not adding cost and time to applications that propose new services likely increases cost and processing time for those applications that do not propose any additional registry services. In other words, it has been argued that applications without additional services being proposed are “subsidizing” applications which do propose new services. Do you see this as an issue?

Q 2.7.7.e.9

Are there any other registry services that should be considered as “pre-approved”? This could include services such as protected marks lists, registry locks, and other services previously approved by ICANN for other registries that have already gone through the RSEP process (https://www.icann.org/resources/pages/rsep-2014-02-19-en).  Please explain.

Q 2.7.7.e.10

There are some who took the proposed registry services language as changing the 2012 implementation of asking for disclosure of services versus disclosure being required, while others argued it does not, keeping this aspect unchanged. Do you agree with one of those interpretations of the recommendation contained in (c) above? Please explain and, to the extent possible, please provide alternative wording.

PDP Working Group Preliminary Recommendation (PR) / Question (Q) / Option

ALAC Response

2.7.8: Name Collisions (WT4)

PR 2.7.8.c.1

Include a mechanism to evaluate the risk of name collisions in the TLD evaluation process as well during the transition to delegation phase.

PR 2.7.8.c.2

Use data-driven methodologies using trusted research-accessible data sources like Day in the Life of the Internet (DITL) and Operational Research Data from Internet Namespace Logs (ORDINAL).

PR 2.7.8.c.3

Efforts should be undertaken to create a “Do Not Apply” list of TLD strings that pose a substantial name collision risk whereby application for such strings would not be allowed to be submitted.

PR 2.7.8.c.4

In addition, a second list of TLDs should be created (if possible) of strings that may not pose as high of a name collision risk as the “Do Not Apply” list, but for which there would be a strong presumption that a specific mitigation framework would be required.

PR 2.7.8.c.5

Allow every application, other than those on the “do not apply” list, to file a name collision mitigation framework with their application.

PR 2.7.8.c.6

During the evaluation period, a test should be developed to evaluate the name collision risk for every applied-for string, putting them into 3 baskets: high risk, aggravated risk, and low risk. Provide clear guidance to applicants in advance for what constitutes high risk, aggravated risk, and low risk.

PR 2.7.8.c.8

Aggravated risk strings would require a non-standard mitigation framework to move forward in the process; the proposed framework would be evaluated by an RSTEP panel.

PR 2.7.8.c.9

Low risk strings would start controlled interruption as soon as such finding is reached, recommended to be done by ICANN org for a minimum period of 90 days (but likely more considering the typical timeline for evaluation, contracting and delegation).

PR 2.7.8.c.10

If controlled interruption (CI) for a specific label is found to cause disruption, ICANN org could decide to disable CI for that label while the disruption is fixed, provided that the minimum CI period still applied to that string.

Q 2.7.8.e.1

Is there a dependency between the findings from this Working Group and the Name Collisions Analysis Project (NCAP)? If there is, how should the PDP Working Group and NCAP Work Party collaborate in order to move forward? Or, should the PDP Working Group defer all name collision recommendations to NCAP?

Q 2.7.8.e.2

In the event that the NCAP work is not completed prior to the next application round, should the default be that the same name collision mitigation frameworks in place today be applied to those TLDs approved for the next round?

Q 2.7.8.e.3

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

Q 2.7.8.e.4

During the first 2 years following delegation of a new gTLD string, registry operators were required to implement a readiness program ensuring that certain actions be taken within a couple of hours in the event that a collision was found which presented a substantial risk to life. The 2-year readiness for possible collisions was kept as determined in the Name Collision Management Framework, but some in the Work Track felt that the service level for 2012 was too demanding. What would be a reasonable response time?

Q 2.7.8.e.5

If ICANN were initially required to initially delegate strings to its own controlled interruption platform and then later delegate the TLD to the registry, would that unreasonably increase the changes to the root zone?

Q 2.7.8.e.6

What threat vectors for name collisions in legacy gTLDs should the Working Group consider, and what mitigation controls (if any) can be used to address such threats?

Q 2.7.8.e.7

Regarding the “do not apply” and “exercise care” lists, how should technical standards for these categories be established? Should experts other than those involved in NCAP be consulted?

Q 2.7.8.e.8

As applicants are preliminarily recommended above to be allowed to propose name collision mitigation plans, who should be evaluating the mitigation frameworks put forth by applicants? Should RSTEP be utilized as preliminarily recommended above or some other mechanism/entity?

PDP Working Group Preliminary Recommendation (PR) / Question (Q) / Option

ALAC Response

2.8.1: Objections (WT3)

PR 2.8.1.c.1

A transparent process for ensuring that panelists, evaluators, and Independent Objectors are free from conflicts of interest must be developed as a supplement to the existing Code of Conduct Guidelines for Panelists and Conflict of Interest Guidelines for Panelists.

(Justine)

The ALAC supports this preliminary recommendation.

While it can be accepted that panelists, evaluators and Independent Objectors are expected to conduct themselves without bias in every objection/proceeding and to recuse themselves when conflicts of interest arise, there always remains a level of subjectivity in determining whether a conflict of interest arises as well as who should decide this question. Therefore in the interest of all concerned parties, a transparent process ought to be developed to supplement the existing Code of Conduct Guidelines for Panelists and Conflict of Interest Guidelines for Panelists, aimed at facilitating the opportunity to examine the positions of panelists, evaluators and Independent Objectors not only vis a vis applicants but also amongst themselves and other objectors to minimise the risk of objections being filed / proceedings being conducted under a potential shroud of conflicting interests as against panelists, evaluators and/or Independent Objectors.

PR 2.8.1.c.2

For all types of objections, the parties to a proceeding should be given the opportunity to agree upon a single panelist or a three-person panel - bearing the costs accordingly.

(Justine)

The ALAC holds a neutral stance on this preliminary recommendation on the proviso that parties are made aware of and are prepared to accept the impact on timeline and costs to them.

However, more importantly, the ALAC believes utmost attention must be given to (1) making overall cost of filing and seeing through objections much more affordable to communities and non-profit organisation objectors, and (2) disallow a wealthier party to a proceeding from dictating terms to insist on a 3-person panel and prejudice the challenge of its less wealthy opponent.

PR 2.8.1.c.3

ICANN must publish, for each type of objection, all supplemental rules as well as all criteria to be used by panelists for the filing of, response to, and evaluation of each objection. Such guidance for decision making by panelists must be more detailed than what was available prior to the 2012 round.

(Justine)

The ALAC supports this preliminary recommendation and goes further to state that guidance for panelists should be substantial insofar as decisions pertaining to definitions of “community” and “public interest”, allegations of conflict of interest on the part of objectors (especially the Independent Objector), and whether to apply an examination of the purpose and use of an applied-for string as opposed to just the term itself are concerned. This is needed to limit the risk of the divergent views, even values, of different panelists on different panels issuing diverging determinations (or even in conflict with the goals stated in ICANN’s Bylaws or GNSO consensus policy).

PR 2.8.1.c.4

Extension of the “quick look” mechanism, which currently applies to only the Limited Public Interest Objection, to all objection types. The “quick look” is designed to identify and eliminate frivolous and/or abusive objections.

(Justine)

The ALAC understands that the current discriminating use of “quick look” mechanism solely on Limited Public Interest objections presupposes that only Limited Public Interest objections would attract frivolous filings since only Limited Public Interest objection allows an inclusive standing base, (ie only Limited Public Interest objections are open to anyone to file). However, in principle, the ALAC opines it would be appropriate to apply consistency in the treatment of all types of objections. There is criterion in the “quick look” mechanism which could be useful to weed out abusive objections for eg. if an objection appears to attack an applicant without (seemingly) valid reason rather than the applied-for string.  On a practical level, can and should all the same criteria used in the “quick look” mechanism be applied to all types of objections?

PR 2.8.1.c.5

Provide applicants with the opportunity to amend an application or add Public Interest Commitments in response to concerns raised in an objection.

Please see our response to Q. 2.8.1.e.15

Option 2.8.1.d.1

GAC Advice must include clearly articulated rationale, including the national or international law upon which it is based.

(Justine)

The ALAC supports this option, and opines that such rationale articulated could include that of accepted national or international policy.

Option 2.8.1.d.2

Future GAC Advice, and Board action thereupon, for categories of gTLDs should be issued prior to the finalization of the next Applicant Guidebook. Any GAC Advice issued after the application period has begun must apply to individual strings only, based on the merits and details of the application, not on groups or classes of applications.

(Justine)

Yes, the ALAC believes this to be fair.

Option 2.8.1.d.3

Individual governments should not be allowed to use the GAC Advice mechanism absent full consensus support by the GAC. The objecting government should instead file a string objection utilizing the existing ICANN procedures (Community Objections/String Confusion Objections/Legal Rights Objections/Limited Public Interest Objections).

(Justine)

The ALAC opines that in principle, the GAC Advice mechanism should be left to GAC to manage. However, we also opine that where an individual government expresses its opposition to an applied-for string and that does not receive the consensus support of GAC (whether full or otherwise) then ideally no GAC Advice should be issued and that government should proceed to file an objection in its own name if it wish to pursue said opposition to the applied-for string.

Option 2.8.1.d.4

The application process should define a specific time period during which GAC Early Warnings can be issued and require that the government(s) issuing such warning(s) include both a written rationale/basis and specific action requested of the applicant. The applicant should have an opportunity to engage in direct dialogue in response to such warning and amend the application during a specified time period. Another option might be the inclusion of Public Interest Commitments (PICs) to address any outstanding concerns about the application.

(Justine)

Yes, the ALAC supports the call for specific time period for issuance of GAC Early Warnings and for the inclusion of both a written rationale/basis and specific action requested of the applicant.

Role of GAC Advice

Q 2.8.1.e.1

Some have stated that Section 3.1 of the Applicant Guidebook creates a “veto right” for the GAC to any new gTLD application or string. Is there any validity to this statement? Please explain.

(Alan, Justine)

At-Large believes there is no validity to the statement or notion that Section 3.1 of the AGB creates a “veto right” for the GAC to oppose any new gTLD application or string, on the following bases:

• While it may be misleading that the GAC Advice procedure is provided for under AGB Module 3 Objection Procedure, a GAC Advice in fact does not equate to an objection. It is, and as the name suggests, an “advice” which is structured to draw attention to an application which is seemingly problematic, eg one that potentially violates national law or raises sensitivities and which, if and when issued, is directed to the ICANN Board of Directors.
• Although a GAC Advice may take a number of forms (depending on whether there is consensus of the GAC or not) which ranges between at the one extreme, an advice that an application should not proceed at all because of certain concerns, to the other end, one which that an application should not proceed unless concerns are remediated, ultimately it is the Board that decides whether or not to take on board such advice with respect to any intervention the Board sees fit to make (if any).
• Any GAC Advice that is received by the Board on an application for a new gTLD string is published and the applicant concerned has the opportunity to submit a response to the Board. If it were a “veto right” there would not be such an opportunity.
• Similarly a GAC Early Warning to the applicant concerned merely alerts that applicant to the concerns which GAC holds, limited to potential violation of national laws or international agreements, or allegedly raises sensitivities, or touches on public policy issues.
• Neither a GAC Advice nor a GAC Early Warning suspends an application. An application is only suspended if an objection is filed.

It should be added that the GAC is the best placed stakeholder group to provide advice on application which bear potential conflicts with national law or international agreements or which touches on national sensitivities.

Q 2.8.1.e.2

Given the changes to the ICANN Bylaws with respect to the Board’s consideration of GAC Advice, is it still necessary to maintain the presumption that if the GAC provides Advice against a string (or an application) that such string or application should not proceed?

(Alan, Justine)

The ALAC’s position is that the Board should consider GAC Advice but is not obligated to accept it, as stipulated in sections 12.2(a)(x) and (xi) of the ICANN Bylaws (Feb 2016). The Board is expected to provide reasons why it declines to follow GAC Advice, therefore it must have considered the advice in order to do so. As such, while the presumption referred to Section 3.1 of the AGB is strictly unnecessary, it may remain to provide an ‘layman’ indication on the ‘severity’ of the GAC’s concern (by way consensus level) but should in no way prejudice the Board’s view and consideration of the advice. In this respect, the ALAC would welcome an attempt at softening of this “presumption”.

Q 2.8.1.e.3

Does the presumption that a “string will not proceed” limit ICANN’s ability to facilitate a solution that both accepts GAC Advice but also allows for the delegation of a string if the underlying concerns that gave rise to the objection were addressed? Does that presumption unfairly prejudice other legitimate interests?

(Justine, Alan)

The ALAC takes the view that this question is awkwardly phrased as there is, in fact, no presumption that a “string will not proceed”, since it is for the ICANN Board of Directors to decide whether it wishes to accept a GAC Advice on an application or not. The AGB in section 3.1 speaks of “a presumption that an application SHOULD not proceed” not that it will not proceed. In any case, At-Large would welcome an attempt at softening of any presumption that “a string should not proceed”.

Role of the Independent Objector:

Q 2.8.1.e.4

In the 2012 round, all funding for the Independent Objector came from ICANN. Should this continue to be the case? Should there be a limit to the number of objections filed by the Independent Objector?

(Justine)

Given that the Independent Objector is selected and appointed by ICANN with a clear mandate, the ALAC believes ICANN should continue to provide all funding for the IO in the next round. We also believe that in principle there should not be a limit to the number of objections filed by the IO. In respect of the 2012 round, the IO filed 24 objections and funding for the IO ((a) salaries and operating expenses) and for these objections ((b) DRP costs) did not appear to present an issue. However, budgetary constraints could arise in the next round if the number of new gTLD applications submitted were to exceed manifold the 1,930 completed applications received in 2012. Even so, given the IO’s specific role in safeguarding the interest of public who use the global Internet, it would be important to continue to provide all funding for this role in the next round.

Q 2.8.1.e.5

In the 2012 round, the IO was permitted to file an objection to an application where an objection had already been filed on the same ground only in extraordinary circumstances. Should this extraordinary circumstances exception remain? If so, why and what constitutes extraordinary circumstances?

(Justine)

Yes, the ALAC believes this extraordinary circumstances exception should remain because the IO has the obligation to act independently and only in the best interests of the public who use the global Internet. The fact that the IO is granted automatic standing to file objections on either Limited Public Interest or Community underlines the importance of this role. His/her ability to carry out his/her specific mandate should be constrained with as few obstacles as possible. The extraordinary circumstances exception provides an acceptable means of flexibility for the IO to file an objection to an application where another objection had already been filed on the same ground.

What constitutes extraordinary circumstances?

It is likely impossible to exhaustively list these, but a couple which could feasibly arise are:

• Where the reasons for which the IO files his/her objection differ substantially to those raised by the other objector. This would also mean the nature of bases raised by the IO and the other objector would likely not coincide.
• Where the IO’s bases for his/her objection are prima facie wider or more far-reaching in scope/impact than those raised by the other objector.
• See also our response to Q 2.8.1.e.6.

Not forgetting that because the IO is obliged to act independently, it would be difficult for him/her to ‘collaborate’ with any other party (non-agents) in bringing the objection.

Q 2.8.1.e.6

Should the Independent Objector be limited to only filing objections based on the two grounds enumerated in the Applicant Guidebook?

(Justine)

The ALAC notes that the IO may file objections only on Limited Public Interest or Community grounds per AGB section 3.2.5.

We  think it is worth considering lifting the 2-ground limit on the IO’s ability to file objections.

Consider the situation underpinning a String Confusion objection - an existing TLD operator or none of the other applicants mistakenly declining to assert a string confusion objection between an applied-for gTLD string and an existing delegated gTLD string or another applied-for gTLD string, as the case may be, preceded by a possible conflict that was not identified during the Initial Evaluation. All with the proviso that there is at least one comment in opposition to the relevant applied-for string made in the public sphere. What would have led to a contention set leading to proper procedures for resolution could pass evaluation and be delegated. The situation could well conclude differently if the IO were allowed to file a String Confusion objection citing reasons focusing on string confusion which may prejudice the interests of one or more communities or the global public who use the Internet, one that the IO deems to be ‘highly objectionable’, rather than be forced to rely purely on the basis for a Community objection.

We do not, however, see any like situation for a Legal Rights objection.

Q 2.8.1.e.7

In the 2012 round, there was only one Independent Objector appointed by ICANN. For future rounds, should there be additional Independent Objectors appointed? If so, how would such Independent Objectors divide up their work? Should it be by various subject matter experts?

(Justine)

At-Large feels there is no strong need for additional IOs to be appointed, taking into consideration five overarching factors:

• There is no clear evidence of an anticipated major increase in new gTLD applications in the next round;
• The possibility of a conflict of interest on the part of the appointed single IO which would either lead him/her to not file an objection which he/she would have otherwise had no qualms in filing, or one which would allow an applicant to easily challenge the validity of the IO’s objection, with such risk being remote and manageable through the selection of the best IO candidate available;
• Unless the constraint is removed, the IO is still not permitted to object to an application unless there is at least one (publicly available) comment opposing that application;
• The IO already has resources at his/her disposal to consult subject matter/legal expert; and
• Concerns over budgetary burden in funding the salaries and operating expenses of additional IOs.

General Questions

Q 2.8.1.e.8

Some members of the ICANN community believe that some objections were filed with the specific intent to delay the processing of applications for a particular string. Do you believe that this was the case? If so, please provide specific details and what you believe can be done to address this issue.

No comment offered.

Q 2.8.1.e.9

How can the “quick look” mechanism be improved to eliminate frivolous objections?

(Justine)

The ALAC suggests that analysis of the 2012 round objections which were found to be frivolous be undertaken to establish commonly identifiable traits and add those criteria to the “quick look” mechanism if not already present.

Q 2.8.1.e.10

ICANN agreed to fund any objections filed by the ALAC in the 2012 round. Should this continue to be the case moving forward? Please explain. If this does continue, should any limits be placed on such funding, and if so what limits? Should ICANN continue to fund the ALAC or any party to file objections on behalf of others?

(Justine)

Yes, At-Large believes strongly that ICANN should continue to fund all objections filed by ALAC in the future rounds. As ICANN’s primary organisational constituency for the voice and concerns of the individual Internet user, ALAC bears a responsibility as an established institution to pursue Community objections against applications for new gTLDs which it believes does not benefit individual Internet end users as a whole and meets the four tests prescribed for a Community objection per AGB section 3.5.4.

The existing limits or conditions placed on funding for ALAC objection filing and Dispute Resolution Procedure (DRP) costs already form an arduous “stress test” to not only establish the validity of a contemplated Community objection, but also support for it within At-Large.

Q 2.8.1.e.11

Should applicants have the opportunity to take remediation measures in response to objections about the application under certain circumstances? If so, under what circumstances? Should this apply to all types of objections or only certain types?

At-Large holds the view that if such opportunity were to be given at all, then it is preferable that crystal clear criteria be agreed on by the ICANN Community and in place before launch of the next round in respect of what circumstances would permit what remediation measures to be taken in response to which objections.

Assuming that this proposal were to be taken up and a constituted Standing IRT were to be given the task of deciding which applicant is awarded such an opportunity then the following (non-exhaustive) factors are important to influence a determination:

• Principle of fairness
• The extent to which an application is capable of being amended to address the concerns/opposition tabled in an objection
• The extent to which such an application is substantially amended to address the concerns/opposition tabled in an objection 
• How does an amendment, if allowed, impact other application(s)? This goes to the question of prejudice.
• How would consistency in considering and determining such opportunities be achieved?
• Would there be an appeals mechanism for either applicant or objector to challenge a determination?   

Q 2.8.1.e.12

Who should be responsible for administering a transparent process for ensuring that panelists, evaluators, and independent objectors are free from conflicts of interest?

Community Objections

Q 2.8.1.e.13

In 2012, some applicants for community TLDs were also objectors to other applications by other parties for the same strings. Should the same entity be allowed to apply for a TLD as community and also file a Community Objection for the same string? If so, why? If not, why not?

At-Large notes that the current AGB does not provide for restrictions or conditions in respect of designation of an application for gTLDs as a community gTLD. Designation of an application as community-based is entirely at the discretion of the applicant.

Further, while there are no restrictions as to who can file of a Community Objection, there are standing requirements for any person/entity to be met in order for a Community Objection to have a chance of succeeding. So even if there might be a self-serving reason for a community-based gTLD applicant to file a Community Objection against the applications by other parties for the same string, there is no justification for prohibiting the same. Such an objection would have to undergo consideration at two levels -- assuming an applicant for a community-based gTLD is able to demonstrate how it satisfies the standing requirements (1st level), then its objection will still need to be considered on its merits (2nd level). Hence, no bias (perceived or otherwise) which would justify the denial of an ability for a community-based gTLD applicant to file a Community Objection in respect of applications by others for the same applied-for string.

However, At-Large wishes to take this opportunity to clarify a possible bias in another scenario

A problem could arise from a non-consistent stance taken by different DRSPs in defining “community”. At-Large understands that a community-based gTLD applicant whose applied-for string is applied for by others may also have the option to file a String Contention Objection. So even if that applicant is able to “have two bites at the cherry” assuming they were able to pay for each objection they choose to file, but because different types of objections go to different DRSPs for resolution, we are concerned with the situation where a community-based gTLD applicant were to file two different types of objections resulting in diverging determinations based on different definitions of “community” adopted by each DRSP.

On this basis, and unless the evaluation of criteria for “community” can be harmonized across all DRSPs, At-Large suggests that it be stipulated that a community-based gTLD applicant may one file a Community Objection OR a String Contention Objection.

Q 2.8.1.e.14

Many Work Track members and commenters believe that the costs involved in filing Community Objections were unpredictable and too high. What can be done to lower the fees and make them more predictable while at the same time ensuring that the evaluations are both fair and comprehensive?

Yes, At-Large agrees with this statement.

At-Large understands the delicate balance between keeping objections processes affordable and the need for reliance on reputable DRSPs. Our suggestions to reconcile this balance include the following:

• ICANN could play greater role in facilitating a “meeting of minds” between applicants and objectors in a way that Community Objections go forward to the designated DRSP as the resolution mechanism of last resort. Reasonable time should be given for this facilitation and discussion between the parties for resolve concerns.
• Mandate clear advance notice to parties in objection resolution proceeding if cost varies. The appointed DRSP should be held to account by ICANN for why the cost for filing Community Objections varied upwards from originally quoted. Greater transparency on the part of the appointed DRSP needed.
• Allow for greater flexibility in consolidating Community Objections filed against the same string using pre-agreed criteria, including collaboration with the Independent Objector without compromising his/her independence.

Q 2.8.1.e.15

In the Work Track, there was a proposal to allow those filing a Community Objection to specify Public Interest Commitments (PICs) they want to apply to the string. If the objector prevails, these PICs become mandatory for any applicant that wins the contention set. What is your view of this proposal?

The ALAC welcomes this proposal but the AGB must reflect this possibility and the applicant be given the choice of withdrawing its application in the event the objector prevails.

What about appeals and refunds?

String Confusion Objections

Q 2.8.1.e.16

The RySG put forward a proposal to allow a single String Confusion Objection to be filed against all applicants for a particular string, rather than requiring a unique objection to be filed against each application. Under the proposal:
• An objector could file a single objection that would extend to all applications for an identical string.

• Given that an objection that encompassed several applications would still require greater work to process and review, the string confusion panel could introduce a tiered pricing structure for these sets. Each applicant for that identical string would still prepare a response to the objection.

• The same panel would review all documentation associated with the objection. Each response would be reviewed on its own merits to determine whether it was confusingly similar.

• The panel would issue a single determination that identified which applications would be in contention. Any outcome that resulted in an indirect contention would be explained as part of the response.

Do you support this proposal? Why or why not? Would this approach be an effective way to reduce the risk of inconsistent outcomes?

The ALAC supports this proposal for a number of reasons:

• It would automatically reinforce the notion that an objection is made against an applied-for string rather than against the applicants
• It would alleviate the need for an objector to file identical objections against each applications for the same applied-for string, thus saving costs also
• Affected applicants would not be prejudiced as they could still prepare a response to a single objection, and in fact would be relieved of a need to prepare multiple, if not identical, responses to multiple objections
• Only one DRSP panel would be required to evaluate and determine a single objection rather than multiple objections on the same applied-for string

Q 2.8.1.e.17

Some Work Track members have proposed that there should be grounds for a String Confusion Objection if an applied-for string is an exact translation of existing string that is in a highly regulated sector, and the applied-for string would not employ the same safeguards as the existing string. Do you support this proposal? Please explain.

Yes, the ALAC supports this proposal on two bases:

• That all applicants for the same string including an exact translation of an existing string should be subject to the same evaluation and/objection processes; and
• Public interest -- the fact that an applied-for string is an exact translation of an existing string that is in a highly regulated sector would necessarily require the same safeguards to be in place as were for the existing string. 

Legal Rights Objections

Q 2.8.1.e.18

Should the standard for the Legal Rights Objection remain the same as in the 2012 round?  Please explain.

No comment offered.

Other

Q 2.8.1.e.19

A Work Track member submitted a strawman redline edit of AGB section 3.2.2.2.

What is your view of these proposed edits and why?

No comment offered.

PDP Working Group Preliminary Recommendation (PR) / Question (Q) / Option

ALAC Response

2.8.2: Accountability Mechanisms (WT3)

PR 2.8.1.c.1

ICANN should create a new substantive appeal mechanism specific to the New gTLD Program. Such an appeals process will not only look into whether ICANN violated the Bylaws by making (or not making) a certain decision, but will also evaluate whether the original action or action was done in accordance with the Applicant Guidebook.

(Justine)

PR 2.8.2.c.2

The process must be transparent and ensure that panelists, evaluators, and independent objectors are free from conflicts of interest.

Post-delegation dispute resolution procedures:

PR 2.8.2.c.3

The parties to a proceeding should be given the opportunity to agree upon a single panelist or a three-person panel - bearing the costs accordingly.

PR 2.8.2.c.4

Clearer, more detailed, and better-defined guidance on scope and adjudication process of proceedings and the role of all parties must be available to participants and panelists prior to the initiation of any post-delegation dispute resolution procedures.

Limited Appeals Process:

Q 2.8.2.e.1

What are the types of actions or inactions that should be subject to this new limited appeals process? Should it include both substantive and procedural appeals? Should all decisions made by ICANN, evaluators, dispute panels, etc. be subject to such an Appeals process. Please explain.

Q 2.8.2.e.2

Who should have standing to file an appeal? Does this depend on the particular action or inaction?

Q 2.8.2.e.3

What measures can be employed to ensure that frivolous appeals are not filed? What would be considered a frivolous appeal?

Q 2.8.2.e.4

If there is an appeals process, how can we ensure that we do not have a system which allows multiple appeals?

Q 2.8.2.e.5

Who should bear the costs of an appeal? Should it be a “loser-pays” model?

Q 2.8.2.e.6

What are the possible remedies for a successful appellant?

Q 2.8.2.e.7

Who would be the arbiter of such an appeal?

Q 2.8.2.e.8

In utilizing a limited appeal process, what should be the impact, if any, on an applicant’s ability to pursue any accountability mechanisms made available in the ICANN Bylaws?

Q 2.8.2.e.9

Do you have any additional input regarding the details of such a mechanism?

PDP Working Group Preliminary Recommendation (PR) / Question (Q) / Option

ALAC Response

2.9.1: Community Applications (WT3)

CPE implementation guidance suggestions:

PR 2.9.1.c.1

The Community Priority Evaluation (CPE) process must be more transparent and predictable

Marita

Transparency and predictability was a major concern which was not addressed in the last round. Clearly community applications which end up in a community priority evaluation process should be able to trust that the process will be open and flexible enough to accommodate them. Many of the suggestions offered to further questions in this section are attempting to remedy this situation.

PR 2.9.1.c.2

CPE evaluations should be completed in a shorter period of time.

Nadira

The ALAC respects that the completion of the evaluation process not to deviate from the CPE evaluation announced schedule. However, if there is no schedule in place, the ALAC requests that there be a published schedule of the evaluation timeline.

PR 2.9.1.c.3

All evaluation procedures should be developed BEFORE the application process opens and made easily and readily available.

Nadira

The ALAC supports having transparent and published evaluation procedures before the call of the application process.  

PR 2.9.1.c.4

The CPE process should include a process for evaluators to ask clarifying questions and where appropriate engage in a dialogue with the applicant during the CPE process.

Nadira - Vanda

Since the CPE process is dealing with more supporting documentations, the ALAC encourages and supports having an enabling procedure to enable community-based applicant to fulfil the exact requirements or other inquiries by the evaluators.   

PR 2.9.1.c.5

Less restrictive word count for communities to engage in clarifying and providing information

Nadira

The more informative and clear the written requirements, the more crisp and precise the provided information will be. Hence, there is no need to have a less restrictive word count.

Q 2.9.1.e.1

During its deliberations, a number of Work Track 3 members expressed that they believed the “definition” of community, available in section 1.2.3.1 of the Applicant Guidebook, was deficient. A number of attempts were made by the Work Track to better define the term “community,” but no definition could be universally agreed upon. Do you believe the current definition of “community” in the AGB is sufficiently clear and flexible to represent the intentions of existing policy about community applications and the various types of communities that may seek priority in the new gTLD program? If not, how would you define “community” for the purposes of community-based applications in the New gTLD Program? What attributes are appropriate? Do you have specific examples where demonstrable community support should or should not award priority for a string? Do you believe examples are useful in developing an understanding of the purpose and goals of any community-based application treatment?

Marita Moll

The definition of community in section 1.2.3.1 of the AGB is actually a definition of a community application -- which can be submitted by any group calling itself a community which has support letters demonstrating community support.

There could be some benefit in further describing community in terms similar to the definition of association used by the European Court of Human Rights and the United Nations: "An association is any group of individuals or any legal entities brought together in order to collectively act, express, promote, pursue or defend a field of common interests."

Both of these definitions are sufficiently broad to enable applications from highly diverse communities. But rather than perfecting the definition, work needs to be done to ensure that members of the CPE have a full understanding of the types of communities bringing applications forward and are able to deal with them in a flexible way. Arbitrarily restricted interpretations and limited definitions applied on an ad hoc basis discriminate against valid community applications which do not fit into prevailing assumptions.

For example the word “community” is also described in the AGB section 4.2.3 which outlines community priority evaluation criteria: “Community” - Usage of the expression “community” has evolved considerably from its Latin origin – “communitas” meaning “fellowship” – while still implying more of cohesion than a mere commonality of interest. Notably, as “community” is used throughout the application, there should be:

(a) an awareness and recognition of a community among its members;

(b) some understanding of the community’s existence prior to September 2007 (when the new gTLD policy recommendations were completed); and

(c) extended tenure or longevity—non-transience—into the future

These attributes (a, b, and c) are subject to interpretations that can hinder or facilitate valid community applications. Does the awareness and recognition have to apply to all of the community or just most of it and where is that line drawn?  Is there a written policy that precisely explains how this works during evaluation? Is a 5 year history enough evidence of longevity or does it have to be 15? Living communities change over time. Who, outside of the community itself, is able to look into the future and attest to the longevity of that community? These are not questions that should be left in abeyance -- to be determined by a non-transparent process conducted by persons unknown. The community deserves to be consulted about the conditions that will be applied at the outset of the process and not be blindsided by evolving conditions in the midst of the process.

Q 2.9.1.e.2

Should community-based applications receive any differential treatment beyond the ability to participate in CPE, in the event of string contention?

Marita – Maureen - Nadira

The ALAC supports differential treatment in the form of access to experts to assist communities, particularly those  from underserved regions in preparing applications. This would help level the playing field between communities, often under resourced, and the  more experienced, well resourced players.

Q 2.9.1.e.3

Could/should alternative benefits be considered when scoring below the threshold to award the string (e.g., support in auction proceedings)?

Marita - Nadira

The ALAC does not see the need of any alteration of the scoring, but we believe there should be a mechanism within this process which is set up to help first time community applicants.

Q 2.9.1.e.4

What specific changes to the CPE criteria or the weight/scoring of those criteria should be considered, if the mechanism is maintained?

Marita

The term “membership” must be flexible enough to take into account the fact that modern communities, sometimes, but always, geographically distributed, often do not have traditional membership lists and should not be penalized for this.

Q 2.9.1.e.5

In the 2012 new gTLD round, it was determined that community-based applications should have preference over non-community-based applications for the same string. Some have argued that this preference should continue, others have claimed that this preference is no longer needed. Should the New gTLD Program continue to incorporate the general concept of preferential treatment for “community applications” going forward? Is the concept of awarding priority for community-based applications feasible, given that winners and losers are created?

Marita

Yes, communities should continue to be given special consideration. ICANN, as a not for profit corporation, needs to show that it is serving the public interest and one way it can do this is by creating an accessible enabling process for communities who wish to gain access to gTLDs.

The Work Track also considered a report on CPE prepared by the Council of Europe, which noted the need to refine the definition of community and re-assess the criteria and guidance for CPE in the AGB and CPE Guidelines. Although this paper has not been officially endorsed by the European Commission or the GAC, there are a number of recommendations in this report on community based applications. The Work Track is seeking feedback from the community on this report and more specifically which recommendations are supported, not supported or which require further exploration.

• Q 2.9.1.e.6: Do you agree with the Council of Europe Report, which in summary states, “Any failure to follow a decision-making process which is fair, reasonable, transparent and proportionate endangers freedom of expression and association, and risks being discriminatory.” Did the CPE process endanger freedom of expression and association? Why or why not?

(Alan, Justine)

While the ALAC agrees with the summary of the Council of Europe Report as stated here, we do not believe the CPE process endangered freedom of expression. We have reservations on impact to the aspect of freedom of association though, mainly in respect of various evaluators’ interpretation of the term “community” insofar as their determinations were focused on this element, and the divergence thereof. 

Q 2.9.1.e.7

In regards to recommendation 2.9.1.c.1 in section c above, what does, “more transparent and predictable,” mean to you? For what aspects of CPE would this apply in particular?

Marita

The CPE process in the last round, by all accounts, were severely lacking in transparency and predictability. In order to correct this in the next round, details about all the procedures used in decision making must be available to applicants well in advance of the deadline for submissions; background information about CPE participants, including support teams must be fully available to enable conflict of interest oversight; and data/documentation/research materials consulted in decision making must be referenced and released as part of the decision. Applicants should also be updated periodically about the status of their application.

It is important that the CPE evaluation team includes representatives from grassroots community organizations. A community application evaluation team whose main frame of reference is rooted in bottom-up community building would be more attuned to the particulars of this sector and more able to interpret the information available in the best light.

The ALAC Statement on Community Expertise in Community Priority Evaluation (Aug 9, 2013) already raised  these concerns and we wish to again highlight them here: "The ALAC has concerns about the sufficiency of community expertise in panels that evaluate new gTLD community applications." and "The ALAC stands ready to offer appropriate ICANN community volunteers to serve as panel members or advisors."

Q 2.9.1.e.8

Some in the Work Track have noted specific concerns about the way the CPE provider performed evaluations, particularly around the validation of letters of support/opposition. To what extent should the evaluators be able to deviate from pre-published guidance and guidelines? For instance, should the evaluators have the flexibility to perform elements of the evaluation in a procedurally different way?

Nadira

With CPE process, some applications and their letters of support might be unconventional, hence, the ALAC believes flexibility is needed to evaluate contextually even if there is a deviation from the given procedure.   

PDP Working Group Preliminary Recommendation (PR) / Question (Q) / Option

ALAC Response

2.10.1: Base Registry Agreement (WT2)

PR 2.10.1.c.1

Work Track 2 continues to support the original policy recommendations and implementation guidelines upon which the 2012 round was based. However, a clearer, structured, and efficient method for obtaining exemptions to certain requirements of the RA, which allows ICANN to consider unique aspects of registry operators, TLD strings, as well as the ability to accommodate a rapidly changing marketplace is needed.

Q 2.10.1.e.1

If ICANN were to have a “clearer, structured, and efficient methods for obtaining exemptions to certain requirements of the RA,” how can such a process be structured to consider unique aspects of registry operators and TLD strings, while at the same time balancing ICANN’s commitment to registry operators that it treat each registry operator equitably?  

Q 2.10.1.e.1.1

At a high level, there was a suggestion that for exemptions or exceptions, the proposer could provide the specific problematic provisions, the underlying policy justifications for those provisions, and the reasons why the relief is not contrary to those justifications. Does this seem like a reasonable approach? Why or why not? 

The Public Interest Commitment (PIC) Standing Panel Evaluation Report dated March 17, 2017 in the case of Adobe Systems Incorporated et al. v. Top Level Spectrum, Inc., d/b/a/ Fegistry, LLC et al., states the following: Second, the Panel notes that PIC (3)(a) of Specification 11 imposes no obligation on Respondent as the Registry Operator itself to avoid fraudulent and deceptive practices. Third, the Panel finds that Respondent’s Registry Operator Agreement contains no covenant by the Respondent to not engage in fraudulent and deceptive practices. 2.10.1.e.2: Should this Work Track recommend that ICANN include a covenant in the RA that the registry operator not engage in fraudulent and deceptive practices? Please explain. 

PDP Working Group Preliminary Recommendation (PR) / Question (Q) / Option

ALAC Response

2.10.2: Registrar Non-Discrimination / Registry/Registrar Standardization (WT2)

PR 2.10.2.c.1

Recommendation 19 should be revised to be made current with the current environment: Registries must use 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.

Q 2.10.2.e.1

In response to feedback from CC2, Work Track 2 members have suggested that .Brand registries as well as any registry operator granted an exemption from the Code of Conduct (as set forth in Specification 9 of the Registry Agreement), should not only be able to limit the number of registrars that they have to use, but should also have the ability to receive a complete exemption from using any ICANN-accredited registrars at all in the operation of their TLD by making them equally exempt from section 2.9 of the Registry Agreement. In connection with the above proposal, the Work Track is soliciting feedback on the following:

Q 2.10.2.e.1.1

Should a complete exemption be available to these registries? Please explain.

Q 2.10.2.e.1.2

If complete exemptions are granted, are there any obligations that should be imposed on .Brand registries to ensure that any obligations or registrant protections normally found in Registrar Accreditation Agreements that should be included in .Brand Registry Agreements if they elect to not use any ICANN-accredited registrars?

Q 2.10.2.e.1.3

Work Track members have suggested that input from the Registrars Stakeholder Group as well as the Brand Registry Group on this topic, would benefit further deliberations and any final recommendations. The Work Track makes note that feedback from all parties will be fully considered and contribute to further developments.

Q 2.10.2.e.2

Are there any other additional situations where exemptions to the Code of Conduct should be available?

Q 2.10.2.e.3

There are provisions in the Registrar Stakeholder Group Charter that some feel disfavor those who have been granted exemptions to the Code of Conduct. In the preliminary recommendation above, would it be better to phrase it as, “unless the Registry Code of Conduct does not apply” rather than, “unless an exemption to the Registry Code of Conduct is granted”?

PDP Working Group Preliminary Recommendation (PR) / Question (Q) / Option

ALAC Response

2.11.1: Registry System Testing (WT4)

PR 2.11.1.c.1

Registry System Testing (RST) should be split between overall registry service provider (RSP) matters and specific application/TLD testing.

PR 2.11.1.c.2

Remove a better part or all self-certification assessments.

PR 2.11.1.c.3

Rely on Service Level Agreement (SLA) monitoring for most if not all overall registry service provider testing.

PR 2.11.1.c.4

Limit Internationalized Domain Name (IDN) testing to specific TLD policies; do not perform an IDN table review in Registry System Testing.

PR 2.11.1.c.5

Include additional operational tests to assess readiness for Domain Name System Security Extensions (DNSSEC) contingencies (key roll-over, zone re-signing).

PR 2.11.1.c.6 Possible language:

“Applicants must be able demonstrate their technical capability to run a registry operation for the purpose that the applicant sets out, either by submitting it to evaluation at application time or agreeing to use a previously approved* technical infrastructure.” * Could mean in the same procedure or previous procedures if an RSP program exists.

Q 2.11.1.e.1

ICANN’s Technical Services group provided some recommendations to Work Track 4 on what it believed were improvements that could be made to improve its testing procedures to attempt to detect operational issues that its Service Level Monitoring system has uncovered with some registry service providers. Although the Work Track discussed this letter in some detail, the Work Track has not reached any consensus on whether those recommendations should be accepted. Therefore, we would like feedback from the community on whether any of the recommendations should be adopted by the Work Track in the final report. More specifically, we seek feedback on recommendation numbers 1 (PDT Operational Tests), 2 (Monitoring), 3 (Third-party certifications), 4 (Audits), 6 (Frequency of tests), 7 (Removal of testing IDN tables) and 8 (Consideration of number of TLDs). Some of the other recommendations, including number 4 (RSP pre-approval) are discussed in Section 2.2.6 on Accreditation Programs (e.g., RSP Pre-Approval).

PDP Working Group Preliminary Recommendation (PR) / Question (Q) / Option

ALAC Response

2.12.1: TLD Rollout (WT2)

PR 2.12.1.c.1

The ICANN organization should be responsible for meeting specific deadlines in the contracting and delegation processes.

PR 2.12.1.c.2

Work Track 2 supports the timeframes set forth in the Applicant Guidebook and the base Registry Agreement; namely (i) that successful applicants continue to have nine (9) months following the date of being notified that it successfully completed the evaluation process to enter into a Registry Agreement, and (ii) that Registry Operators must complete all testing procedures for delegation of the TLD into the root zone within twelve (12) months of the Effective Date of the Registry Agreement. In addition, extensions to those timeframes should continue to be available according to the same terms and conditions as they were allowed during the 2012 round.

Q 2.12.1.e.1

One of the reasons the delegation deadline was put into place was to prevent the incidence of squatting/warehousing.  Is this reason still applicable and/or relevant? Are other measures needed? If so, what measures and how will these measures address the issue?

Q 2.12.1.e.2

For the 2012 round, registry operators were required to complete the delegation process within twelve (12) months from the Effective Date of the Agreement.  This was the only requirement regarding use of the TLD. Other than delegation (which includes the maintenance of a required NIC.TLD page and a WHOIS.NIC.TLD page), no other use of a TLD is required. Is the definition of use of a TLD from the 2012 round still appropriate or are adjustments needed? If you believe that adjustments are needed, what adjustments are necessary and why?

PDP Working Group Preliminary Recommendation (PR) / Question (Q) / Option

ALAC Response

2.12.3: Contractual Compliance (WT2)

PR 2.12.3.c.1

WT2 believes that the foundational elements of the Contractual Compliance program put into place by ICANN as well as the relevant provisions in the base Registry Agreement have satisfied the requirements set forth in Recommendation 17. That said, members of the Work Track believe that ICANN’s Contractual Compliance department should publish more detailed data on the activities of the department and the nature of the complaints handled.

Q 2.12.3.e.1

The Work Track noted that with the exception of a generic representation and warranty in Section 1.3(a)(i) of the Registry Agreement, Specification 12 (for Communities) and voluntary Public Interest Commitments in Specification 11 of the Registry Agreement (if any), there were no mechanisms in place to specifically include other application statements made by Registry Operators in their applications for the TLDs. Should other statements, such as representations and/or commitments, made by applicants be included in the Registry Operator’s Agreements? If so, please explain why you think these statements should be included? Would adherence to such statements be enforced by ICANN Contractual Compliance?

Q 2.12.3.e.2

A concern was raised in the CC2 comment from INTA about operational practices, specifically, “arbitrary and abusive pricing for premium domains targeting trademarks; use of reserved names to circumvent Sunrise; and operating launch programs that differed materially from what was approved by ICANN.” What evidence is there to support this assertion? If this was happening, what are some proposed mechanisms for addressing these issues? How will the proposed mechanisms effectively address these issues?