Public Comment CloseStatement
Name 

Status

Assignee(s)

Call for
Comments Open
Call for
Comments
Close 
Vote OpenVote CloseDate of SubmissionStaff Contact and EmailStatement Number

26 September 2018

ADOPTED

14Y, 0N, 1A

1A: Seun Ojedeji:  "My personal and professional workload unexpectedly increased, which limited my participation in a number of ICANN processes."

21 September 2018

25 September 2018

28 September 2018

02 October 2018

26 September 2018

AL-ALAC-ST-0918-03-01-EN

Hide the information below, please click here 


FINAL VERSION SUBMITTED (IF RATIFIED)

The final version to be submitted, if the draft is ratified, will be placed here by upon completion of the vote. 



FINAL DRAFT VERSION TO BE VOTED UPON BY THE ALAC

The final draft version to be voted upon by the ALAC will be placed here before the vote is to begin.


AT-LARGE ADVISORY COMMITTEE

ALAC Statement on the Initial Report on the New gTLD Subsequent Procedures Policy Development Process (Overarching Issues & Work Tracks 1-4)

 

Introduction

Alan Greenberg, At-Large Advisory Committee (ALAC) Chair, Jonathan Zuck, member of the North American Regional At-Large Organization (NARALO), and Justine Chew, member of the Asian, Australasian and Pacific Islands Regional At-Large Organization (APRALO), developed an initial draft of the statement on behalf of the ALAC, in consultation with drafters from the At-Large Consolidated Policy Working Group (CPWG).

The At-Large CPWG held weekly calls in consultation with the community from 18 July 2018 - 26 September 2018, working from three Google Documents created by Jonathan Zuck, Justine Chew and staff, as well as the At-Large workspace to consolidate comments. Drafters of topics were assigned, including: Metrics for Consumer Trust/Choice - Holly Raiche, Evan Leibovitch; Community Prioritization/Applications - Justine Chew, Marita Moll, Abdulkarim Ayopo Oloyede, Yrjö Lansipuro, Nadira Alaraj; Fees - Bastiaan Goslings; Pics - Bastiaan Goslings, Holly Raiche; Applicant Support - Justine Chew, Alberto Soto, Marita Moll, Tijani Ben Jemaa; Objections - Justine Chew; Predictability & Clarity of Application Process - Justine Chew; Universal Acceptance - Eduardo Diaz, Satish Babu; Applications Assessed in Rounds/Batching Applicant Assessment (incl. Continuing Subsequent Procedures (2.2.1.c.1)) - Justine Chew.

On 21 September 2018, the first draft of the statement was posted on its At-Large workspace. On the same day, ICANN policy staff in support of the At-Large community sent a call for comments on the statement to the At-Large community via the ALAC work mailing list. Assigned drafters and At-Large community members added comments to the wiki workspace and consolidated final draft Google Doc.

On 26 September 2018, the CPWG met to finalize the ALAC statement draft. On the same day, the ALAC Chair submitted comment, and requested that Staff open an ALAC ratification vote.

In the interest of time, the ALAC Chair requested that the statement be transmitted to the ICANN public comment process, copying the ICANN staff member responsible for this topic, with a note that the statement is pending ALAC ratification.

 

 

 

 

ALAC Statement on the Initial Report on the New gTLD Subsequent Procedures Policy Development Process (Overarching Issues & Work Tracks 1-4)

Summary of the ALAC Responses

While the ALAC and wider At-Large community continue to debate the actual benefits to communities in expanding the New gTLD Program (“Program”), we acknowledge that the Program will likely continue to be expanded in one form or another.  In this respect, the ALAC considers this opportunity to comment on the Initial Report on the New gTLD Subsequent Procedures Policy Development Process (Overarching Issues & Work Tracks 1-4) dated 03 July 2018 (“Initial Report”) a valuable one, and wishes to put on record our responses, suggestions and in some cases, advocacy, to the preliminary recommendations and questions as posed by the GNSO New gTLD Subsequent Procedures PDP Working Group (“WG”) in its Initial Report, from the perspective of and benefit to Internet end users At-Large. On the same note, we have also chosen not to offer comments to selected sections of the Initial Report, namely sections which the ALAC believes has little or no impact on Internet end users, as indicated herein. On the same note, we have chosen to offer comments only to parts of the Initial Report which we believe carry an impact on Internet end users.

In particular, the ALAC wishes to highlight to following key consensus positions:

Concept of “Rounds”

The ALAC believes that regardless of whether future applications are called for by way of a “round” or “rounds” or on a first come, first served (FCFS) basis, 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).

In any case, the ALAC strongly advocates against the immediate commencement of a permanent FCFS process of accepting New applications for the Program.

Community Applications and Community Priority Evaluation

Community applications which end up in the CPE process should be able to trust that the process will be open and flexible enough to accommodate them. The ALAC offers a series of suggestions for improvement:

With respect to the definition of communities, we think 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" could be useful. But we feel the real issue is in ensuring 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.

The ALAC believes that communities should continue to be given special consideration. We support differential treatment for community applications in the form of access to experts to assist communities, particularly those from and/or which are conceived to serve underserved regions, in preparing applications; we believe there should be a mechanism within this process which is set up to help first time community applicants; we believe that the concept of membership must be flexible enough to take into account the fact that geographically dispersed communities often do not have traditional membership lists and should not be penalized for this.

The CPE process needs to be more transparent and predictable. 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 the CPE team include representatives from grassroots community organizations and the ALAC has offered to assist in this task.

Metrics

The ALAC believes that metrics should be developed and used both to gauge the extent to which Internet end users have benefitted from the introduction and use of New gTLDs and to highlight areas in which improvements to the introduction can be improved for the benefit of end users.

Public Interest Commitments

Public Interest Commitments (PICs) are a core part of the ALAC's campaign for TLDs that have a high public interest worth. Therefore, the ALAC supports the prospects of ICANN codifying Mandatory PICs. The ALAC also notes the usefulness of Voluntary PICs from the 2012 rounds in respect of applications for strings representing highly regulated sectors and on this basis supports the continued use of Voluntary PICs in the effort to protect the interest of Internet end users.

Applicant Support Program

The ALAC strongly advocates for Applicant Support to continue to be open to applicants whose applications are conceived to serve underserved regions and/or underserved communities regardless of their location, so long as they meet the other Applicant Support Program (ASP) criteria. Further, we believe that it is imperative that ICANN improves the global awareness of the ASP through effective means. The ALAC also advocates for all Applicant Support applicants who are found to have failed the criteria for the ASP to be allowed to decide if they wish to pursue or withdraw their application, with the grant of 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.

IDNs

The ALAC is strongly in favour of IDNs being continued as an integral part of the Program since – putting aside telecommunications infrastructure availability (which is beyond the remit of ICANN) –  IDNs have the potential to benefit countless communities whose languages are not Roman-script based. While the ALAC agrees with many of the preliminary recommendations set out in the Initial Report, it also advocates for Pre-Delegation Testing to continue to be conducted for TLD applications as a prudent safeguard measure, regardless of the presence of a general agreement on compliance with IDNA2008 (or its successor(s)) and applicable LGRs. The ALAC also believes that IDN variant-related policies such as “bundling” are best handled at the TLD level, provided that if both variants are registered, they need to be under the control of the same registrant.

Universal Acceptance

The ALAC believes that the primary obstacle to the successful expansion of the domain namespace is the rejection of these New strings by legacy code. It behoves the ICANN community to engage in substantial outreach to the Internet community on this issue. The ALAC acknowledges the challenges associated with such outreach but the fact that some of the largest websites on the Internet, including major banking and airline sites continue to reject the New strings suggests that more can – and must – be done to advocate code revision on the Internet.

SSAC Research and Recommendations

In several places in our response, the ALAC defer to the SSAC for further recommendations. This includes areas such as dotless domains and name collisions. Again, we reiterate, there is no cause for urgency surrounding the further introduction of gTLDs and due time should be given to the SSAC to explore the security and stability implications of various proposals before any New round should begin.

Objections

The ALAC advocates for the ALAC and the Independent Objector (IO) to have continued active roles in filing objections to applications for strings and that they be funded by ICANN. In the case of the ALAC, we do not believe there should be any additional limits or conditions placed on the funding for ALAC objection filing and Dispute Resolution Procedure (DRP) costs. In the case of the IO, the ALAC supports the retention of the “extraordinary circumstances” exception as described in the Initial Report and we opine that the IO may, under certain circumstances, even have a role to play in String Confusion Objections. With respect to the DRP process, we strongly advocate for the process to be kept affordable, especially to communities and non-profit organization objectors, and that any applicable rules or procedures, as well as costs for DRPs, must be required to be published well in advance of any procedure being commenced. We also strongly advocate that guidance for DRP panellists be substantial in respect of adopting definitions of terms – such as “community” and “public interest” – as well as questions on objector standing, in an effort to limit the “damage” resulting from panellists’ unfamiliarity with the ICANN community structure, divergent panellists’ views – even values – on the same, and which conflict with the goals stated in ICANN’s Bylaws or GNSO consensus policy.

High Standards for Applicants

Finally, a number of questions address the question of “registrant protections” or more broadly, the standards that should be applied to applicants for New gTLDs. While the ALAC concedes there might be special circumstances that require adjusting the evaluation process to accommodate applicants for underserved regions and perhaps brand TLDs, we maintain that standards for applicants should remain high. Furthermore, whatever the standards that are ultimately set, ICANN should do a better job of applying those standards during the application process than was done during the 2012 round. There are certainly instances when applicants that failed to meet the registrant protection standards were nonetheless allowed to proceed, casting the shadow of impropriety on the entire process.

 

 

 

Glossary

“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 03 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.

 

The ALAC supports this preliminary recommendation in principle. However, please also refer to our responses to 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?

 

The ALAC supports the use of the following metrics to better understand whether/how New gTLDs have benefitted end users:

For end user confusion – customer surveys:

  • Frequency of success in reaching intended supplier through entry of domain name, and
  • Frequency of landing at unintended destinations

Is the name legally secure, alive and active:

  • How many domain names are just parked and/or acquired for resale,
  • How many domain names are live in a server, but not actually used (no WWW nor MX records),
  • How many domain names have an active web page, what level of traffic do they generate, and
  • How many domain names just redirect to a domain name in a legacy TLD

Diversity:

To have an index related to population, for instance "number of registrars per 100,000 inhabitants”, or similar. This index could reflect the levels of DNS market penetration, consumer choice, and consumer support in a country/location.

Consumer complaints:

  • How many complaints received related to  New gTLDs
  • How many complaints are resolved in set timeframes and how many complaints relating to New gTLDs have resulted in ICANN compliance action.

Industry statistics:

  • The ALAC has also supported acquisition of additional information including information on:
    • The relationship between specific registry operators, registrars and DNS abuse, and
    • Collection of data about and publicize the chain of parties responsible for gTLD domain registration.

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.

 

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?

 

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.

The ALAC believes that the Standing IRT must include one or more people considering the Program from an end user perspective, and that it 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.

 

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 p. 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?

 

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 gap in the law need to be addressed; and
  • Who (or the number of parties) would be affected by a recommendation or decision of the Standing IRT, including material levels.

The WG is also urged to revisit the recommendations of the Policy and Implementation Working Group mentioned in the Initial Report on p. 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?

 

The ALAC believes more extensive deliberation is required on the open questions/details regarding the Standing IRT panel and a separate process outside of this WG’s present public comment process is warranted to address the same.

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?

 

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.

 

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?

 

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

 

The ALAC believes that 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).

Regardless of whether re-introduction of the Program applications is done via a “round”, “rounds” or on a FCFS basis, the ALAC advocates:

  • 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;
  • That the Community Priority Evaluation (CPE) procedure, in particular, be rigorously reviewed;
  • That there be greater transparency in ICANN Org’s selection of evaluators and DRSPs; and
  • 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 Preliminary Recommendation 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 Preliminary Recommendation 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 Preliminary Recommendation 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 Preliminary Recommendation 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 Preliminary Recommendation 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 Preliminary Recommendation 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 Preliminary Recommendation 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?)

 

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 (e.g. “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 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?)

 

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 (e.g. 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.

 

The ALAC has and continues 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?

 

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.

 

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?

 

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.

 

The ALAC does not object to 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.

 

No comment offered.

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.

 

No comment offered.

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.

 

No comment offered.

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.

 

No comment offered.

PR 2.2.6.c.5

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

 

No comment offered

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?

 

No comment offered.

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?

 

No comment offered.

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?

 

No comment offered.

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?

 

No comment offered.

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.

 

No comment offered.

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?

 

No comment offered.


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. In addition, such mandatory PICs should be revisited to reflect the ongoing discussions between the GAC Public Safety Working Group and Registries as appropriate.

 

The ALAC supports this preliminary recommendation.

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.

 

The ALAC strongly agrees. Voluntary PICs have proved instrumental in ensuring that some TLDs are operated responsibly.

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

 

The ALAC supports this preliminary recommendation.

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.

 

The ALAC agrees with this preliminary recommendation.

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.

 

At this juncture, no, but the ALAC opines that if issues were to arise during implementation, it might be necessary to reconsider this question.

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.

 

Yes, the ALAC opines that this can be considered where the applicant is able to propose alternative, equally rigorous ways of achieving the commitments.

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?

 

Yes, the ALAC opines that this is appropriate since their inclusion into the applicant’s Registry Agreement leads to their enforceability.

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?

 

Only to the extent that the voluntary PICs are introduced to address a GAC Early Warning or GAC Advice or an objection.

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?

 

In such circumstances, the ALAC advocates for a short objection period to be called, where the same period could also be used for parties to confirm whether an objection or issue has been resolved.

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?

 

The ALAC supports this recommendation by the Verified TLD Consortium and National Association of Boards of Pharmacy and suggests:

  • The use of a panel with panellists skilled in the field of consumer trust; and
  • That the WG should identify and study several options in depth to establish some recommendations.

 


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.

 

No comment offered.

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?

 

No comment offered.

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?

 

 

No comment offered.

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?

 

No comment offered.


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.

 

Yes, the ALAC believes that the UASG should include and consult our constituency in developing initiatives that better advances the principles of universal acceptance.

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?

 

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

 

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:

 

No specific comments offered.

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.

 

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 ought to be made easily available.

PR 2.4.1.c.2.2

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

 

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.

 

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.

 

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.

 

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.

 

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

 

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.

 

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

 

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.

 

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.

 

ICANN’s Global Stakeholder Engagement (GSE) team is responsible for promoting global awareness of the Program. 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. RALOs are well-placed to assist but 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.

 

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.

 

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.

 

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?

 

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.

 

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?

 

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.

 

No comment offered.

 

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. 

 

No comment offered.

PR 2.4.3.c.3

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

 

No comment offered.

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.

 

No comment offered.

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.

 

No comment offered.

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.

 

 

 

 

No comment offered.

Implementation Guidance regarding technical systems:

PR 2.4.3.c.7

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

 

No comment offered.

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.

 

No comment offered.

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.

 

No comment offered.

PR 2.4.3.c.10

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

 

No comment offered.

PR 2.4.3.c.11

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

 

No comment offered.

PR 2.4.3.c.12

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

 

No comment offered.

PR 2.4.3.c.13

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

 

No comment offered.

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.

 

No comment offered.

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.

 

No comment offered.

PR 2.4.3.c.16

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

 

No comment offered.


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.

 

The original program presumed that the number of new registrations would ensure that all operational costs associated with the program would be well covered by the operational fees.

The number of new registrations is FAR below expectations and it is not clear that this has happened.

So yes, the ALAC agree that the program should be self-funding which should include contingent programs such as the expansion of contract compliance capability.

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.

 

.While the ALAC did not reach consensus on whether an application fee floor should be used, Tthe ALAC does recommends that excess funds after cost recovery should be spent on endeavors that promote the public interest and should not be used to refund applicants.

These excess fees received by ICANN could 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

When it comes to the 'revenue neutral' principle, the ALAC would like to see clear estimates of costs that need to be covered by application fees, as specific as possible and with numbers provided. The ALAC finds it quite surprising to see the report refer to the fact that ‘documentation related to the process used in setting the 2012 application fee were unavailable’ (page 80) and ‘while the Work Track was unable to attain the document that reflected these steps and any related insight, it still asked itself if there is better method to increase precision of (cost) estimates’ (page 82).

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.

 

A TLD is a valuable piece of unique Internet real-estate. The floor price should not be below that used in the first round. Based on experience from the first round, it is clear that the price used then was not a deterrent to a large number of often speculative applications.

 

If an application fee floor is used for a.o. this reason, it would need to be determined at what level the floor sufficiently mitigates the risk of speculation, warehousing, abuse etc., while still making it attractive to invest in the introduction of New gTLDs.

 

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.

 

The ALAC agrees with this preliminary recommendation.

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.

The ALAC agrees with this preliminary recommendation. If an application fee floor is simultaneously introduced the levels of both would need to be considered in combination with each other, the amount set aside for contingency could be funded from the excess fees received because of the application fee floor.

 

 

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?

No specific comments offered.

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?

In general the ALAC believes that excess funds should be spent on the categories mentioned in 2.5.1.c.4. From question 2.5.1.e.2  it is not clear to the ALAC whether this is about what is left after spending the excess fees received to ‘benefit the categories’ as described in 2.5.1.c.4 when using an ‘application fee floor’.  Applicant support is already mentioned as a category in 2.5.1.c.4

 

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?

No specific comments offered.

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?

No specific comments offered.

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?

The ALAC believes excess funds should be spent on the categories mentioned in 2.5.1.c.4. Also the separate fund in 2.5.1.c.5 could be funded by -planned for- 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?)

Any cap set on the number of (new) gTLDs in the root should initially be determined by what the root-zone system can handle technically.

 

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?

In theory, if only looking at lower barriers for competition and to stimulate innovation, application fees should be set at an as low as possible level, i.e. purely based on a cost recovery basis. However as argued before, there are good reasons to set the application fees at a higher level than purely on a cost recovery basis. In order to determine a balance between on the hand preserving the value of domain names and mitigating the negative side effects of a too low a price, while on the other hand stimulating competition and innovation, numbers and statistics are necessary, clear estimates and contingency planning, in order to determine a level of application fees to be set.

Therefore the ALAC agrees with the statement on page 79 of the Initial Report that ‘the Work Track recognizes that additional analysis would be needed to establish a new estimated cost’.

 

 

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?

No specific comments offered.

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

 

The ALAC suggests the WG consider discounted application fees for community applications with non-profit intentions.

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

The ALAC thinks it makes sense to make clear what the cost differences are for the variety of applications. However that should not be the leading argument to use different application fees. See our earlier suggestion to offer discounts to e.g. community applications.

The ALAC notes though that on page 84 of the Initial Report it says: ‘While the Work Track sought actual costs from the ICANN organization, the Work Track understands that costs were not tracked at an application by application level, making it difficult to determine if there is substantial variance in costs incurred for different application types and/or evaluation paths.'

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

No specific comments offered.

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?

No specific comments offered.

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?

 

The ALAC supports the fee reduction model currently applied in the Applicant Support Program (ASP) and believes that this should be the only exception to the fixed application fees regime, since one of the ASP criteria is that of “Financial Need”.

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?

No specific comments offered.

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?

No specific comments offered.


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.

 

Please refer to our responses to Q 2.5.3.e.1 and Q 2.5.3.e.2 below. 

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.

 

Yes, the ALAC supports in this Option, in principle.

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.

 

Please refer to our responses to Q 2.5.3.e.1 and Q 2.5.3.e.2 below. Further, the ALAC suggests that consideration should always be given to not discourage or disadvantage first-time applicants.

Q 2.5.3.e.1

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

 

The ALAC favours conditions that will improve the number of community-based applications, in particular, ones made by community-supported applicants or ones which are conceived to benefit underserved regions and/or underserved communities, hence we see an appropriate application submission period as a function of how well such applicants can be expected to comprehend the requirements needed to prepare their applications and time needed to actually prepare the same.

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?

 

While the ALAC supports an approach which facilitates predictability for all parties concerned, we believe that batching applications for assessment holds greater importance than a fixed period for accepting applications. Please also refer to our responses to Section 2.2.3 Applications Assessed in Rounds, in particular for Preliminary Recommendation 2.2.3.


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.

 

The ALAC believes that Applicant Support should continue to be open to applicants whose applications are conceived to serve underserved regions and/or underserved communities regardless of their location so long as they meet the other criteria. 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 reiterates its belief that Applicant Support should continue to be open to applicants whose applications are conceived to serve underserved regions and/or underserved communities regardless of their location so long as they meet the other criteria. To effect this, the eligibility criteria will need to be adjusted to require applications to demonstrate how they will serve an underserved region and/or underserved community, and not merely service in the public interest.

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 from the current round and that applicant (including its representatives) should be disallowed from participating in any application for Applicant Support for a specified period.

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. On this basis, we propose that an applicant who qualifies for ASP should be given priority in any string contention set, and not be subjected to any further string contention resolution process.  

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.

No specific comments offered.

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.

 

The ALAC agrees in principle with the statements laid out in preliminary recommendations 2.5.5.c.2 and 2.5.5.c.3.

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

 

The ALAC believes that if the covenant not to sue were contemplated to be removed, then a reasonable limitation of liability clause must be simultaneously put in place. The financial stability of ICANN is a core, joint responsibility of the ICANN Community which cannot be put at risk through an unmitigated removal of the covenant not to sue as a term in the Program. However, we do not disagree with the need for a challenge/appeal mechanism for which we have provided input in section 2.8.2 Accountability Mechanisms.

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.

 

The ALAC agrees with this preliminary recommendation.

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?

 

All applicable routes, procedures, costs and timelines for any challenge/appeal mechanism and for each stage up to delegation ought to be made clear in the Applicant Terms and Conditions.

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?

 

No comment offered.

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?

 

The ALAC believes that if the covenant not to sue were contemplated to be removed, then a reasonable limitation of liability clause must be simultaneously put in place. The financial stability of ICANN is a core, joint responsibility of the ICANN Community which cannot be put at risk through an unmitigated removal of the covenant not to sue as a term in the Program.


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.

 

The ALAC supports this preliminary recommendation.

PR 2.6.1.c.2

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

 

The ALAC supports this preliminary recommendation.

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.

 

The ALAC does not object to the continued use of a system of buying a ticket to participate in a prioritization draw method provided always that the cost of ticket is not prohibitive to some applicants, for example those which apply for Applicant Support.

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.

 

No comment offered.

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.

 

The ALAC supports this preliminary recommendation. Please also see our response to Preliminary Recommendation 2.6.1.c.3.

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.

 

The ALAC supports this preliminary recommendation.

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?

 

No specific comment offered. Please refer to our response to Preliminary Recommendation 2.2.3.

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)?

Yes, the ALAC believes that IDNs and community-based string applications should receive priority in processing.

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)?

 

No comment offered.

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.  

 

Yes, the ALAC believes that community-based applications, including IDN applications, which are conceived to serve underserved regions and/or underserved communities regardless of their location.


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.

No specific comments offered.

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.

 

The ALAC notes that policy recommendations on geographic names at the top level are tasked to WT5.

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”).

 

Avoidance of end user confusion is a paramount consideration to the ALAC.  All practicable, reasonable measures must be considered and implemented to safeguard this end user protection principle.

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. 

 

No specific comments offered.

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.

No specific comments offered.

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. 

No specific comments offered.

• 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?

 

Avoidance of end user confusion is a paramount consideration to the ALAC. All practicable, reasonable measures must be considered and implemented to safeguard this end user protection principle.


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.

 

The goal of EBERO and/or COI is to protect consumers and not prop up failing registry operators. Therefore, it is imperative for ICANN to observe the original intent of the EBERO and allow it to function under that scope.

PR 2.7.2.c.2

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

No specific comments offered.

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.

No specific comments offered.

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.

No specific comments offered.

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.

No specific comments offered.

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?

No specific comments offered.

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.

No specific comments offered.

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?

 

No. The ALAC maintains that ICANN should subject all registrants, including publicly traded companies and their affiliates, to a background check. The At-Large believes that adhering to the background checks it already has in place will increase transparency in the application process. Additionally, background checks will ensure that ICANN is properly vetting registrants so that no person or entity “games” the registration process.

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?"

 

The ALAC supports such additional checks. Ensuring that applicants are reputable is a large part of ensuring that New TLDs will be operated for the safety of Internet end users.


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.

 

The ALAC believes that ICANN should prohibit the use of closed generics if it is not coupled with a Public Interest Application, because closed-generic TLDs allow an applicant to have a potentially unfair influence over registration priority in a generic term, such as “app.” Additionally, closed generics lead to a slippery slope that could enable significant security risks for those particular strings, particularly for dotless domains as the SSAC found. As SSAC concluded in its report, “the way in which domain names are interpreted in different contexts would lead to unpredictable and unexpected dotless domain behaviour.” Closed generics can exist – but they may introduce unintended security and stability issues which the SSAC should weigh in on. Thus, to completely eliminate this competitive and security threat, ICANN must prohibit their use.

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.

No specific comments offered.

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.


The ALAC provisionally supports closed generics with associated public interest specifications.

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.


The ALAC is supportive of this idea.

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.

 

The ALAC would certainly not be in favour of an open season on closed generics for the reasons outlined above.

Q 2.7.3.e.1

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

No specific comments offered.

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.

No specific comments offered.

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. 

No specific comments offered.


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.

 

The ALAC strongly supports this preliminary recommendation.

PR 2.7.4.c.2

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

 

The ALAC believes that a replacement solution is required if the SWORD Tool is eliminated from use.

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.

 

The ALAC supports this preliminary recommendation.

 

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.

 

If properly administered, CPE is an appropriate method of resolving contentions because pre-set criteria is used in assessing applications. Auction of last resort, on the other hand, is not appropriate because it will always favour applicants with deeper pockets, not to mention being open to abuse if not conducted openly.

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?

 

At this point, the community does not know enough about abuse that may have occurred in the 2012 round of auctions, both ICANN and private ones. Even the legality of private auctions is in question. A study should be completed to resolve these issues. Alternatively, ICANN should explore other contention resolution mechanisms outside of auctions that may serve as more equitable (e.g., like a draw).

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.

 

The ALAC believes that the standards should certainly be different in the context of a highly regulated sector as a matter of consumer protection. While string confusion is a concern everywhere, areas of potential consumer harm need to be addressed first.


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

 

The ALAC strongly supports this preliminary recommendation.

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.

 

The ALAC agrees with this preliminary recommendation as LGRs are the recommended manner in which IDN TLDs and variants are to be identified.

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.

 

The ALAC agrees with this preliminary recommendation in principle. Additional inputs from the CJK communities would be useful to confirm if they see any language-related risks in 1-letter IDN labels (beyond the technical risks identified by SSAC/JIG).

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.

 

The ALAC agrees with this preliminary recommendation. Such automation would be useful if technically feasible.

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.

 

Pre-Delegation Testing (PDT) covers the testing of different aspects that could potentially impact the stability and manageability of registry operations, such as DNS, WHOIS, EPP, IDN, Data Escrow and Documentation. IDN variants introduce added complexity to registry operations, even where compliant with IDNA2008 or LGRs. Consequently the ALAC believes it may be prudent to continue with PDT practices.

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.

 

The ALAC agrees with this preliminary recommendation in principle. The manageability – and consequently the associated risks – will depend on the nature and number of variants, and therefore a conservative approach may be appropriate, especially while deciding on the numbers of variants.

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.

 

The ALAC believes that IDN variant-related policies such as “bundling” are best handled at the TLD-level provided that if both variants are registered, they need to be under the control of the same registrant.

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.

 

Among extant scripts, it is largely the Chinese family of scripts (Chinese-Japanese-Korean) that are considered as ideograms. Further work on this aspect may only be needed if the respective language communities raise it explicitly.

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.

 

 

The ALAC opines that given the fact that there is a manageability constraint when dealing with IDN labels at the top and second levels, it may be prudent to entrust related policies (including bundling) to the respective registry operators. The current policy process under way for IDN Variant TLD Implementation will also be guiding this policy.

Q 2.7.5.e.3

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

 

The ALAC opines that under the current IDN regime, this manual validation/invalidation is unlikely to occur.

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?

 

As the finalization of the IDN Variant TLD Implementation Framework is under way, it is recommended that the Work Track should consider its recommendations as inputs.


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.

No specific comments offered.

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.

No specific comments offered.

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?

No specific comments offered.

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?

No specific comments offered.


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

ALAC Response

2.7.7: Applicant Reviews (WT4)

For all evaluations:

 

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.

No specific comments offered.

PR 2.7.7.c.2

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

No specific comments offered.

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. 

No specific comments offered.

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.

No specific comments offered.

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.

No specific comments offered.

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.

No specific comments offered.

PR 2.7.7.c.7

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

 

No specific comments offered.

PR 2.7.7.c.8

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

No specific comments offered.

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

No specific comments offered.

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

No specific comments offered.

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.

No specific comments offered.

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

 

 

No specific comments offered.

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

No specific comments offered.

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

No specific comments offered.

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”) "

No specific comments offered.

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

No specific comments offered.

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

No specific comments offered.

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.

No specific comments offered.

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?

No specific comments offered.

Q 2.7.7.e.3

Which financial model seems preferable and why?

No specific comments offered.

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? 

 

No specific comments offered.

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?

No specific comments offered.

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?

No specific comments offered.

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?

No specific comments offered.

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?

No specific comments offered.

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.

No specific comments offered.

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.

No specific comments offered.


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.

 

Collisions have the potential for great user harm. The process needs to wait for the SSAC to complete its work and to be subject to their recommendations.

The next round should not proceed before that is in.

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

 

Wait on SSAC recommendations.

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.

 

Wait on SSAC recommendations.

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.

 

Wait on SSAC recommendations.

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.

 

Wait on SSAC recommendations.

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.

 

Wait on SSAC recommendations.

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.

 

Wait on SSAC recommendations.

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

 

Wait on SSAC recommendations.

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.

 

Wait on SSAC recommendations.

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?

 

Wait on SSAC recommendations.

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?

 

Wait on SSAC recommendations.

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?

 

Wait on SSAC recommendations.

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?

 

Wait on SSAC recommendations.

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?

 

Wait on SSAC recommendations.

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?

 

Wait on SSAC recommendations.

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?

 

Wait on SSAC recommendations.

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?

 

Wait on SSAC recommendations.


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 panellists, evaluators, and Independent Objectors are free from conflicts of interest must be developed as a supplement to the existing Code of Conduct Guidelines for Panellists and Conflict of Interest Guidelines for Panellists.

 

The ALAC supports this preliminary recommendation.

While it can be accepted that panellists, 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 Panellists and Conflict of Interest Guidelines for Panellists, aimed at facilitating the opportunity to examine the positions of panellists, 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 panellists, 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.

 

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 panellists for the filing of, response to, and evaluation of each objection. Such guidance for decision making by panellists must be more detailed than what was available prior to the 2012 round.

 

The ALAC supports this preliminary recommendation and goes further to state that guidance for panellists 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 panellists 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.

 

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, (i.e. 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 e.g., 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.

 

 

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.

 

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

 

The ALAC supports the intent of this option that where an individual government expresses its opposition to an applied-for string and that does not receive the full consensus support of GAC 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.

 

Yes, the ALAC supports this option calling 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.

 

The ALAC believes that any notion that Section 3.1 of the AGB creates a “veto right” for the GAC to oppose any New gTLD application or string is one that is incorrectly held for the reasons stated below. On this basis, we suggest the removal of all references to a strong presumption to be taken by the ICANN Board.

  • 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, e.g., 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.

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?

 

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. As such, we suggest the removal of any such reference to a “presumption” altogether.

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?

 

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. This is an example of an incorrectly formed notion and therefore the ALAC suggests the removal of any such reference to a “presumption” altogether.

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?

 

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?

 

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?

 

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?

 

The ALAC 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?

 

We suggest 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?

 

Yes, the ALAC believes strongly that ICANN should continue to fund all objections filed by us in the future rounds. As ICANN’s primary organisational constituency for the voice and concerns of the individual Internet user, the ALAC bears a responsibility as an established institution to pursue Limited Public Interest and/or Community objections against applications for New gTLDs which it believes does not benefit individual Internet end users as a whole.

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.

However, for ALAC objections to have proper effect as intended in the AGB, the ALAC proposes that guidance for DRSP panellists be substantial in respect of adopting definitions of terms – such as “community” and “public interest” – as well as questions on objector standing, in an effort to limit the ‘damage’ resulting from panellists’ unfamiliarity with the ICANN Community structure, divergent panellists’ views, even values, on the same, and which conflict with the goals stated in ICANN’s Bylaws or GNSO consensus policy.

 

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?

 

The ALAC 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 panellists, evaluators, and independent objectors are free from conflicts of interest?

 

No comment offered.

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?

 

The ALAC 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, we wish to take this opportunity to clarify a possible bias or conflict in another scenario

A problem could arise from a non-consistent stance taken by different DRSPs in defining “community”. We 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, we suggest 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, the ALAC agrees with this statement.

We understand 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. The WG is urged to also give consideration to the matter of refunds for withdrawals as well as an appeals mechanism for the Community Objection dispute resolution process.

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.

 

The ALAC supports this preliminary recommendation which we believe will provide not only a welcomed platform to facilitate the administration of justice within ICANN, but also a more accessible one for parties concerned.

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.

 

The ALAC strongly supports this preliminary recommendation.

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.

 

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.

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.

 

The ALAC strongly supports this preliminary recommendation.

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.

 

Yes, the ALAC believes this new limited appeals process should include both substantive and procedural appeals as this would be consistent with the outcomes of the Cross Community Working Group on Enhancing ICANN Accountability which led to similar changes to the ICANN Bylaws.

Yes all decisions made by ICANN, evaluators, dispute panels, etc., should be subject to such an appeals process as anecdotal evidence from the 2012 round pointing to existing accountability mechanisms being insufficient to properly facilitate challenges to evaluations (including for ASP), objections and CPE.

  • Relevant actions which should be appealable include while decisions undertaken by any purported decision-maker who did not have standing to do so, or by any properly authorised decision-maker which was supported or accompanied by either weak or no justification or reason whatsoever.
  • Relevant inactions could include no formal response given to or decision being made on a question or issue put forth by a party with standing; and a delay in action which prejudiced a party (which in effect amounts to an inaction).

Q 2.8.2.e.2

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

 

Any party which is directly aggrieved by an event of action or inaction. Yes, it is likely to 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?

 

The ALAC suggests that an administrative check be undertaken to establish that appeal filed must be accompanied by a filing fee and the filed appeal must contain at least one ground of 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?

 

The ALAC suggests that the contemplated appeals process paths be clearly laid out and incorporate a stipulation that disallows multiple appeals.

Q 2.8.2.e.5

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

 

A “loser-pays” model could be considered, provided the costs of an appeal be fixed in advance and all parties involved are given prior notice of the same.

Q 2.8.2.e.6

What are the possible remedies for a successful appellant?

 

This would depend on the nature and substance of the appeal.

Q 2.8.2.e.7

Who would be the arbiter of such an appeal?

 

The ALAC suggests that the Board Accountability Mechanisms Committee be the arbiter of such an appeal, supported by a subject matter expert if need be.

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?

 

If the Board Accountability Mechanisms Committee is made the arbiter of a limited appeals process, then accountability mechanisms made available in the ICANN Bylaws would automatically be incorporated.

Q 2.8.2.e.9

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

 

No comment offered.


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

 

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.

 

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.

 

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.

 

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

 

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?

 

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?

 

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)?

 

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?

 

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?

 

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?

 

The ALAC does not believe that the CPE process endangered freedom of expression or association as such. But due to the narrow definition of membership and how "association" is measured, the evaluators and the process they followed did discredit many forms of association that had great merit, but did not satisfy the narrow model being used.

Most of the community TLDs that did not undergo CPE would have similarly failed. But many of them do embody the intent of the concept of a "community" and thus a "community TLD".

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?

 

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 wishes to 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?

 

With the 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.

No specific comments offered.

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?  

No specific comments offered.

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? 

No specific comments offered.

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. 

No specific comments offered.



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.

No specific comments offered.

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:

No specific comments offered.

Q 2.10.2.e.1.1

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

No specific comments offered.

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?

No specific comments offered.

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.

No specific comments offered.

Q 2.10.2.e.2

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

No specific comments offered.

Q 2.10.2.e.3

There are provisions in the Registrar Stakeholder Group Charter that some feel disfavour 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”?

No specific comments offered.



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.

No specific comments offered.

PR 2.11.1.c.2

Remove a better part or all self-certification assessments.

No specific comments offered.

PR 2.11.1.c.3

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

No specific comments offered.

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.

No specific comments offered.

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

No specific comments offered.

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.

No specific comments offered.

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

No specific comments offered.



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.

No specific comments offered.

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.

No specific comments offered.

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?

No specific comments offered.

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?

No specific comments offered.


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.

 

The ALAC strongly supports this preliminary recommendation.

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?

 

The ALAC believes that other statements, such as representations and/or commitments, made by applicants ought to be included in the Registry Operator’s Agreement as the means to codify those statements for the purpose of enforceability. This is especially important if the effect of those statements is to proffer benefits to Internet end users.

Adherence to such statements would be monitored and 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?

 

No comment offered.



DRAFT SUBMITTED FOR DISCUSSION

The first draft submitted will be placed here before the call for comments begins. The Draft should be preceded by the name of the person submitting the draft and the date/time. If, during the discussion, the draft is revised, the older version(S) should be left in place and the new version along with a header line identifying the drafter and date/time should be placed above the older version(s), separated by a Horizontal Rule (available + Insert More Content control).

PLEASE NOTE THIS DRAFT HAS BEEN COPIED FROM A LIVE GOOGLE DOCUMENT FOR COMMUNITY INPUT. COMMENTS ON THIS DRAFT WILL BE OPEN 21 - 25 SEPTEMBER 2018.

See: First Draft Google Doc (view-only link)

ALAC Statement on the Initial Report on the new gTLD Subsequent Procedures Policy Development Process (Overarching Issues & Work Tracks 1-4)

Glossary

“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?


41 Comments

  1. Response on Public Interest Commitments (PICs).

    Background:

    ALAC has made a number of submissions on this issue.  See <https://atlarge.icann.org/topics/public-interest/background>.

    PICs were not included in the original Applicant Guidebook, but added after representations, including from ALAC, that new registry operators should commit to the names that would be allowed by that registry. Provision for both mandatory and voluntary PICS are contained in Specification 11 of the 2013 RAA. Both Mandatory and Voluntary PICs, while forming part of the ICANN-Registry contract, are enforceable through a separate process - the PICDRP (PIC Dispute Resolution Process) Mandatory PICS have been strengthened (see below) since the original Specification 11.  ALAC was hopeful, at that time, that applicant registry operators would also, under the Specification, make additional voluntary commitments, on how names under that registry would be used.  Indeed, as ALAC commented (18 May 2017) in reviewing the Interim Review on Competition, Consumer Trust and Consumer Choice:

    However, the Report does suggest that end users have some expectation that there will be a connection between the specific gTLD and the website. (p. 64) Indeed, their expectations are that there will be restrictions on registrations to reflect that connection. (p. 67) This strengthens the ALAC view that all applications for new gTLDs should contain a commitment that details how the name will relate to the registrars and their registrant’s use of the new gTLD.

    Voluntary PICS

    As set out in the background, ALAC had conerns about voluntary PICS including their enforceability, and the fact that the PICS statement could include provisions that would allow change of or termination of use at any time.  Indeed, voluntary PICS have, in ALAC's view, been a disappointment. Of the original 1930 successful applications (1232 of which are now delegated), only 499 included PICS, and few of those included commitments on how the names would be used by reggistries and registrants. 

    Closed Generics: As part of the PICs issue, GAC (supported by ALAC) raised concerns about the use of genenric terms (such as doctor, lawyer etc) by registries in allowing registrars/registrants to use the TLD with no necessary connection to the TLD name.

    Mandatory PICS, however, do add consumer protections through requirements on the reegistry operator, as set out in the Sepcification:

    • Clause 1 requires Registry Operators to only accredit registrars that are party to the 2013 RAA.
    • Clause 2 says that the Registry operator will operate the registry in compliance with commitments they made in the application, business plans, etc for the new gTLD.   Enforcement will be through the special PIC Dispute Resolution Process. 
    • Clause 3 (subsequent amendment) imposes specific PICS, enforceable through the PICDRP as follows:
      • Include in their registration agreements a prohibition prohibiting Registered Name Holders from distributing malware, abusively operating botnets, phishing, piracy. etc.  and providing ‘consequences’ for such activities
      • Periodically conduct technical analysis to assess whether domains in the TLD are being used to perpetrate malware, botnets, phishing, etc
      • Establishing, publishing and adhering to clear registration policies
      • Registry operator of a ‘generic string’ TLD may not impose eligibility criteria for registering names in that TLD that limit registrations to a single person/entity…

    Suggested  Questions/Recommndations on PICS - all part of Clause 2.3.2

    • codify mandatory PICS as a policy recommendation?  Suggest ALAC support. (rationale - the revised mandatory PICS provide additional protection for end users.  As mandatory PICS, the enforcement is through the PICDRP. Those requirements should be enforceable as a contract term in an ICAN-Registry agreement - which can only be done through a policy process.
    • Agree that the concept of voluntary PICS continue - allowing applicants to make additional commitments?
    • Question the recommendation that the applicant must state whether the PIC is limited in time, and/or scope. such that it can be reviewed. While recognising that a registry may change its nature/focus, should there be a required public process before such changes are made?
    • On whether voluntary PICS should be mandatory for registry operators  to implement ?
    •  If a volunary PIC is made in response to he GAC, public comments or other concerns, is the inclusion of a PIC in the contract the     proper mechanism - or something else?
    • Is there concern that a voluntary PIC could change the nature of the application?
    • There is a specific question about concerns from the pharmaceuticals on PICS



    1. Wow Holly – I could have not put it better than this. Well done!

      IMHO - both mandatory PICs and voluntary PICs should be enforced in the same way.

      More PICs should be mandatory and should include consumer protection issues.

      All PICs should be explicitly included in the contracts so they can be enforced and a breach of contract if ignored.

      I also think, like others, that a "voluntary PIC" is not worth a warm bucket of spit, especially if a clause also says that a voluntary PIC can be dropped by the Registry at their own leisure. That, to me, is just cheap marketing.

      1. Thanks Olivier.

        And to clarify, since this issue was raised in the CPWG about enforceability of PICS.  Yes, PICS are incorporated into the agreement, under Specification 11 (setting out the Mandatory PICs) says the following:

          Registry Operator’s obligations pursuant to this paragraph shall be enforceable by ICANN and through the Public Interest Commitment Dispute Resolution Process established by ICANN

        So yes - the PICs now are enforceable through that process - and my recommendation which Olivier agrees with is that they should be enforceable as a contract term

        1. Thank you Holly, for putting the  PICs issues simply and clearly.  Although ALAC position to provide what would be the best for consumers or registrants but it is important to keep in mind that the New gTLD Registries are there to have a surviving competitive business.   The more mandatory PICs are enforced the more limited in their marketing strategies, even if it is "cheap" marketing as Oliver has put it.

          Once, I had a talk with someone from the New gTLD Registries, they told me about the difficulties that they are facing to attract demands. 

          The more relaxed the PICs the more entrances of new registries could be. 

          1. Is it an end user concern that registries should have as many open business models?

            In my opinion if a Registry has a difficult attracting a market then they should be looking at diversification into other markets. I do not subscribe to making a market the Wild West in order to keep opportunities open for any wild idea.

      2. +1

        Appears we're in the same section of the choir!


        -Carlton

    2. Have we covered / reinforced all the points ALAC made on PICs in CC2?

    3. Thank you Holly for this masterful recap and analysis.  As you know, I'm in the choir with you on almost all of these points, save and except the matter of PICS.  

      I strongly recommend the At-Large abjure the concept of voluntary PICS, reject this as purely 'feelgoodism' inimical to the interest of end users.  If there will be PICS they must be committed, sustained and enforceable under contract. 

      In regard DNS expansion, I tend to see this corner of the world between two pillars, one which says a fool and his money are soon parted and the other that says when dogs have money they buy cheese.

      I cannot see a market demand for more gTLDS in the foreseeable future but come to this with an unabashed Robin Hood mindset. If some fo..er, investor wants to drop big bucks to get in, why, we should assist the taking. So long as we have settled ways to use the taking for community strengthening and expansion plus a sharing of the fruits of the DNS to the world.  My disposition thus drives my mind to favour a continuous open season instead of rounds as the methodology for expansion.

      In regard to the matter of beneficiaries, I am open to a category of community applications that are treated affirmatively. However, that cockeyed approach last time to determining who or what is a community need a stake thru its heart. Why? It is neither serviceable nor commonsensical. OCL will recall he, on behalf of the ALAC, went to the EIU - the fellas hired to assess community application in the 2012 expansion -  seeking an understanding of their methodology and was politely told to bugger off. I'm still gobsmacked that some ICANN genius thought this outfit would have been the perfect exemplars for such a task. 

      -Carlton

       

  2. 2.5.4 Applicant Support

    The SubPro WG made a number of preliminary recommendations:

    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.

    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.

    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

    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.

    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.

    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.

    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.

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

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


    The SubPro WG then asks a series of questions (ie Q 2.5.4.e.1 to Q 2.5.4.e.11 reproduced below):


    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?


    Q 2.5.4.e.2 Metrics
    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?


    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?


    Q 2.5.4.e.4
    Did the ASP provide the right tools to potential program participants? If not, what was missing?


    Q 2.5.4.e.5
    How can we best ensure the availability of local consulting resources?


    Q 2.5.4.e.6
    How can we improve the learning curve – what ideas are there beyond mentorship?


    Q 2.5.4.e.7
    How do we penalize applicants who may try to game the system?


    Q 2.5.4.e.8
    Are there any considerations related to string contention resolution and auctions to take into account?


    Q 2.5.4.e.9
    Should there be a dedicated round for applicants from developing countries?


    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?


    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)?


    What input do you have to these preliminary recommendations and/or questions?


    1. I personally agree with the Preliminary  Recommendations.  Suggested response to the questions:

      Yes, continue with the ASP

      Metrics - should look at actually approved applications, but I'd add a diversity test - outside of the US/Europe, geographic spread, IDNs. And agree that in many areas, the infrastructure simply isn't there.  So is that an ASP issue?

      On metrics - I'd add diversity.  And note OCL's commnts - we tried for clarification of what constituted community - we need to try again

      I"m not sure about a specific round for developing countries.  I'd rather have that discussion as part of a Middle East or Asia Pacific area discussion - looking at news, as well as existing infrstructure

      And why not use the funds to address (in part at least) some of the barriers to applications

      One group for outreach - amongst others - the Native Peoples

  3. 2.9.1 Community Applications (String Contention Resolution)

    The SubPro WT3 made a number of preliminary recommendations:

    WT3 had a number of extensive discussions on the topics of string contention and “communities”. In addition, it received a number of comments related to the treatment of communities during the 2012 New gTLD round in CC2.

    Although the WT has yet to come to an agreement on any preliminary policy recommendations, based on many of the implementation related issues identified by the WT and the wider community, it has come to some level of general agreement on the following CPE implementation guidance related suggestions:

    • 2.9.1.c.1: The Community Priority Evaluation (CPE) process must be more transparent and predictable

    • 2.9.1.c.2: CPE evaluations should be completed in a shorter period of time.

    • 2.9.1.c.3: All evaluation procedures should be developed BEFORE the application process opens and made easily and readily available.

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

    • 2.9.1.c.5: Less restrictive word count for communities to engage in clarifying and providing information.

    They then asked a series of questions (i.e. Q 2.9.1.e.1 to Q 2.9.1.e.8 reproduced below):

    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.288 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?


    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?

    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)?

    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?

    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?


    The Work Track also considered a report on CPE prepared by the Council of Europe,289 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?


    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?

    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?


    What input do you have to these preliminary recommendations and/or questions?

    1. Yes, this was a vexed issue.  Before any start to a 'next round' if there is one, we need clarity on what ICANN means by community.

      I'm not adamant about how community applications should be given particular treatment, but at the least, clearer definitions, and special consideration.  In definitions- if there isn't one agreed definition, maybe a set of guiding principles, with examples, to accommodate the various types of communities

  4. 2.2.3 Applications Assessed in Rounds (Application Submission Periods)

    Preliminary Recommendation
    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.”

    The Options under Consideration

    Option No.

    Option description

    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.

    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.

    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.

    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.

    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.

    Option 2.2.3.d.6

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


    They then asked a series of questions (i.e. Q 2.2.3.e.1 to Q 2.2.3.e.4 reproduced below):

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


    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.


    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?)


    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?)


    What input do you have to these preliminary recommendation and/or questions?

    1. Input to Q 2.2.3.e.1
      Note, with approval, the WG’s current thinking (per points listed on page 37 of the Initial Report) and concur with the WG’s recommendation that the next introduction of new gTLDs shall be in the form of a “round”, as it remains consistent with Recommendation 13 of the 2007 GNSO FInal Report Introduction of New gTLDs, that “Applications must be initially assessed in rounds until the scale of demand is clear”.  Also note, with approval, the WG’s general non-support for Option 2.2.3.d.6 (Model 6) in the first instance for reasons highlighted the the WG’s Initial Report (on page 31).

      In looking forward, a hybrid approach drawing on aspects of Option 2.2.3.d.2 (Model 2), Option 2.2.3.d.3 (Model 3) and Option 2.2.3.d.5 (Model 5) would be ideal IMO. In other words,

      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. Remaining deficiencies to be identified and where major “course corrections” are needed, they should be addressed via existing policy development processes required to make substantial, policy-driven changes to the program and which 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. All with the goal of a permanent opening up of a first-come, first-served process of accepting new gTLD applications.

      Reasons:

      • The 2012 round did not enjoy as much predictability as it could have, due to parts of the AGB being amended (whether out of necessity or not, including changes to the same resulting from GAC Advice, Board decisions, etc). Also, where lacunae exists in both the AGB and GNSO 2007 policy, implementation of the round was subject ICANN staff interpretations. With these hindsight, identified deficiencies can and ought to be resolved via new policy affirmation (or amendment, as the case may be) to be reflected in the AGB for the next round. Hence, there is value in repeating this cycle for another two or three rounds to enable the ICANN Community to reach, by consensus, the comfort level to support a call to permanently open up the process of accepting new gTLD applications on a first-come, first-served basis.

      • The ICANN Community continues to debate the merits of expanding the new gTLD program. The availability of strings considered (or not) to be geographic names is a case in point. New categories of gTLD are still being mooted. SSAC’s continued assessment on the impact of adding more gTLDs to the root-zone is critical to stability, security and resiliency of the Internet. Against the backdrop of these significant considerations and not really knowing the actual demand for still available strings and/or possibly release of previously reserved strings at the top level, it would be prudent to maintain the practice of rounds to collect/analyse data over time to reasonably predict that the Internet “won’t break down” if the ICANN Community chooses in future to support a call to permanently open up the process of accepting new gTLD applications on a first-come, first-served basis.

      • In any case, while the goal of a permanent opening up of a first-come, first-served process of accepting new gTLD applications is easy enough to achieve, we need to clearly differentiate the actions of “accepting” versus “assessing” applications. Even if applications were to be “accepted” on an ongoing basis, the practice of “assessing” applications in batches will need to be retained (with batches pre-defined in terms of a time period, eg all applications received in Q1 will be assessed in Q2). This is because the assessment processes in place require not only temporal boundaries (for string-contention evaluation, priority evaluation, objections etc), but also reasonable time-limes and/or limits for technical evaluations and other relevant measures leading to delegation.



      Input to Q 2.2.3.e.2
      Many of the cons identified by the WG for Models 2, 3, and 5 are acceptable downsides and/or are outweighed by the pros similarly identified by the WG for the same models.

      However, attention should be paid to defer to ICANN-facilitated auctions effectively as the mechanism of last resort for resolving string contentions in view of concerns with auction procedure being an inappropriate method to serve the public interest since it clearly has the potential to disproportionately award gTLDs to financially richer entities, a view also reflected in the Council of Europe report presented at ICANN50. One unintended consequence of restricting applications (and assessment) by rounds is the emergence of private auctions as a resolution mechanism for string contentions, leading to instances of gaming associated with some private auctions. While conducting auctions may be regarded as a legitimate resolution mechanism -- indeed ICANN has stipulated this as a mechanism of last resort for resolving string contentions -- incidences of gaming through private auctions should be prohibited.


      Input to Q 2.2.3.e.3
      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 New gTLD 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 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 simply 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 new gTLD program, and on the other hand, basic expectations of potential applicants.


      Input to Q 2.2.3.e.4
      If at all, and only on an as-needed basis, 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.


      1. There are lots of input/comments posed via the mail list. I'm trying my best in picking up and reposting them at Justine Chew's Google Doc.

    2. From the last discussion in the CPWG, I'm not sure we all agree that applications should be in a round/rounds, and not just a continuous process. 

      1. Noted, though the answers are my perspective for input, and not necessarily the draft statements to be adopted.

        Will have a look at the spreadsheet for inputs before actual drafting.

        Cheers.

  5. 2.8.1 Objections

    WT3 seeks input on the following preliminary recommendations:

    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.

    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.

    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.

    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.

    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.

    WT3 seeks community input on the following possible recommendations regarding GAC Advice and GAC Early Warnings:

    Option No.

    Option description

    Option 2.8.1.d.1

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

    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.

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

    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.

    Then we are asked a series of questions (Q 2.8.1.e.1 to Q 2.8.1.e.19 reproduced below):

    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.

    Q 2.8.1.e.2
    Given the changes to the ICANN Bylaws with respect to the Board’s consideration of GAC Advice,285 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?

    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?


    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?

    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?

    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?

    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?


    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

    Q 2.8.1.e.9
    How can the “quick look” mechanism be improved to eliminate frivolous objections?

    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?

    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?

    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?

    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?

    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?


    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?


    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.


    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.


    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?


    What input do you have to the preliminary recommendation and/or questions highlighted in blue?

    1. Inputs to section 2.8.1 Objections (26-29 Aug) see also Justine Chew's Google Doc )

      On Preliminary Recommendations 2.8.1.c.1 to 2.8.1.c.5

      I support unequivocally the following preliminary recommendations:

      • 2.8.1.c.1: While I can accept 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.
      • 2.8.c.1.2: No harm with taking up this recommendation so long as parties are aware of and are prepared to accept impact on timeline and costs to them. However, more importantly, utmost attention must be given to (1) make 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.
      • 2.8.c.1.3: Absolutely. Should not even need to be said but apparently it does! In fact, 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).
      • 2.8.c.1.4: 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). This is understandable. However, in principle, 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 uncategorically appears to attack an applicant without (seemingly) valid reason rather than the applied-for string. Question is can and should all the same criteria used in thebe applied for “quick look” mechanism be applied to all types of objections? Do they need to be?

      As for preliminary recommendation 2.8.c.1.5 - ability to amend application or add a PIC in light of an objection - is difficult to assess without specific reference to use cases or problems arising from the 2012 round. Also (non-exhaustive) factors such as the following could also have an impact on its desirability:

      • How well have applicants been educated on the how best to position their application?
      • Is their selected string likely to attract objections such that they should have submitted a PIC with their application to begin with?
      • What is the nature of the amendment contemplated? Will it significantly change the strength of the application or is it to clarify an already included statement?
      • What impact will an amendment have on other applications, in the context of contention sets? Will an amendment, if allowed, then prejudice the competing application(s) in contention sets?
      1. Inputs to section 2.8.1 Objections (28-29 Aug) see also Justine Chew's Google Doc )

        On Role of Independent Objector


        Input to Q 2.8.1.e.4

        Backgrounder: https://www.independent-objector-newgtlds.org/home/the-independent-objector-s-objections/

        Given that the Independent Objector is selected and appointed by ICANN with a clear mandate, yes, ICANN should continue to provide all funding for the IO in the next round. 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 present an issue. However, budgetary constraints could arise in the next round if the number of New gTLD string 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.


        Input to Q 2.8.1.e.5

        Yes, this extraordinary circumstances exception should remain. Reason:

        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 the 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.
        • (I can think of another extraordinary circumstance but it doesn’t fall under a situation where another objection - either Limited Public Interest objection or Community objection - had already been filed. See my input 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.


        Input to Q 2.8.1.e.6

        Note: The IO may file objections only on Limited Public Interest or Community grounds per AGB section 3.2.5

        I 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, rather than be forced to rely purely on the basis for a Community objection.

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


        Input to Q 2.8.1.e.7

        Probably not, taking into consideration 4 overarching factors:

        1. Unless there is clear evidence of an anticipated major increase in New gTLD string applications in the next round (there are differing views on this in the community, so we need to examine evidence of potential demand, assuming there is some)
        2. The possibility of a conflict of interest of 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. Such risk is remote and manageable through the selection of the best IO candidate available.
        3. 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.
        4. Concerns over budgetary burden in funding the salaries and operating expenses of additional IOs.


      2. Inputs to section 2.8.1 Objections (28-29 Aug, 3 Sep) see also Justine Chew's Google Doc )

        On General Questions (also where ALAC is mentioned)


        Input to 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.

        I personally don't have any input to this question at this point.


        Input to Q 2.8.1.e.9 How can the “quick look” mechanism be improved to eliminate frivolous objections?

        Analyse the 2012 round objections which were found to be frivolous to establish commonly identifiable traits and add those criteria to the “quick look” mechanism if not already present.


        Input to 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?

        YES! (emphasis entirely mine)


        Yes, 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 gTLD strings which it believes does not benefit individual Internet 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 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 the At-Large community.

        **Note: Funding for ALAC objection filing and DRP costs is contingent on publication by ALAC of its approved process for considering and making objections. At a min, the process for objecting to a gTLD application will require: bottom-up development of potential objections, discussion and approval of objections at the RALO level, and a process for consideration and approval of the objection by the ALAC. Legal fees are not included in this funding for ALAC.  

        Should the existing highlighted conditions be relaxed? Which ones? How?

        Olivier Crepin-Leblond Since you were involved in the ALAC objection filing procedure for 2012 round, would appreciate your input here.

        Dev Anand Teelucksingh Any thoughts on difficulties or disconnect between the At-Large New gTLD Review Team's work and ALAC's objection filing? 


        My Backgrounder

        Questions were hinted at as to whether reconsideration was needed on the ALAC and GAC’s ability to file Limited Public Interest and Community objections. In the 2012 round, ALAC was determined as not having standing in 2 Community Objections it filed in respect of the <dot>health applied-for string and it was suggested that GAC would also have been expected to be ruled to not have standing to file Community Objections. This was the result of failure (according to the ICC) to satisfy the required element of “ongoing relationship with a clearly delineated community” - it is said that this failure would apply to GAC as well. However, it was pointed out that GAC had access to the (built-in) GAC Advice mechanism for voicing concerns to an applied-for string to the ICANN Board (even if this mechanism isn’t an objection mechanism per se) while ALAC had no such mechanism at its disposal.

        So, if ALAC was highly unlikely (or even never) going to be able to satisfy the said required element, why then allow ALAC funding to file objections in the next round(s)? Shouldn’t we see the crux of the problem as ALAC, while as ICANN’s primary organisational constituency for the voice and concerns of the individual Internet user, being denied a rightful standing to file Community objections because the appointed DRSP does not recognise or even understand the role of ALAC within the ICANN Community with respect to defending the interests of the individual Internet users? Is ALAC expected to merely publish a public comment opposing or voicing concerns to an applied-for string which it deems is against the interests of the individual Internet users and hope that the Independent Objector would then take up the ‘cause’ of filing an objection? Recall that given the mandated independence of the Independent Objector, it would be highly difficult (or even impossible) for ALAC to ‘collaborate’ with the IO in positioning his/her objection to highlight ALAC’s concerns.


        Input to 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?

        Tough question to answer. 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. Application of a principle of fairness would be a paramount consideration.  

        Assuming that this proposal were to be taken up and a constituted SIRT 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)? Question of prejudice.

        • How would consistency in considering and determining such opportunities be achieved? Task undertaken by same, full SIRT?

        • Would there be an appeals mechanism for either applicant or objector to challenge a determination?    


        Input to 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?

        (not input per se) I have to confess that I was the person who asked for this question to be included in the WG’s Initial Report, but have no answer in mind. 

    2. Inputs to section 2.8.1 Objections (26-29 Aug) see also Justine Chew's Google Doc )

      On Role of GAC

      (I am re-posting Alan Greenberg's input to me, with his permission, together with mine)


      Input to Q 2.8.1.e.1

      Alan: 

      There is no validity. 3.1 Allows the GAC to provide advice to the Board in a number of different forms. The Board is required to consider such advice but in no case does 3.1 require that this advice be taken.

      Justine:

      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. The reasons being:

      • 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 of a New gTLD 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.


      Input to Q 2.8.1.e.2

      Alan:

      That will be a Board decision and one that it is required to provide a rationale for. In one of the three forms of GAC objection, the Guidebook says there is a presumption but not an absolute requirement that the advice be taken. The ALAC would readily accept this "presumption" to be softened to make it clear that this is a conscious Board decision and will include consideration of any rationale provided by the GAC.

      Justine:

      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. Softening of this “presumption”, as Alan suggests, would be welcomed. 


      Input to Q 2.8.1.e.3

      Alan:

      As noted in 2.8.1.e.2, the ALAC can accept the "presumption" presuming it is qualified by the need for the Board to fully consider the issue, but would be happy to see it softened as described above.

      Justine:

      The WG’s question is awkwardly phrased -- there is no presumption that a “string will not proceed”, 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 I agree with Alan’s suggestion to soften the notion of any “presumption” with respect to a GAC Advice.

    3. Inputs to section 2.8.1 Objections (3 Sep) see also Justine Chew's Google Doc )

      On Community Objections


      Input to 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?

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

      The case for Yes: Similarly, there are no restrictions as to who can file of a Community objection but 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, I don’t see any 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.

      The case for No: However, a problem arises stemming from a non-consistent stance taken by different DRSPs in defining “community”. It should be noted that a community-based gTLD applicant whose applied-for string is applied for by others also has the option to file a String Contention Objection. So while that might present a situation of a community-based gTLD applicant “having two bites at the cherry” being fine if they were able to pay for each objection they choose to file, but because different types of objections go to different DRSPs for resolution, what happens if a community-based gTLD applicant were to file 2 different objections which resulted in diverging determinations based on different definitions of “community” adopted by each DRSP?

      Conclusion: Should we then stipulate that a community-based gTLD applicant may one file a Community Objection OR a String Contention Objection and let them decide of which objection would be easier for them to mount?


      Input to 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, no doubt to the statement in the first sentence.

      What can be done? Delicate balance between keeping objections process affordable and reliance on reputable DRSP.

      • 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 costs 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.


      Input to 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?

      Holly Raiche FYI. I'd like your input please to ensure we develop an answer that is consistent with the response to the PICs section. Thanks!

      1. There is an overlap in this debate.  The original idea of the PICS - originally voluntary - was that the applicant might want to specify a bit more about the sort of names supported by the applicant registry. One example that was accepted was GOP - the applicant being the US Republican Party - often called the 'Grand Old Party'. Thus a registry for GOP would be for local, state and national republic party entities.  However, by in large, PICS were not that specific. (and in the interim report of the Consumer TComptition, Choice and Trust report, it said end users rather expected that the domain name would have some connection with the site's content - which most often isn't the case.)  However, the GAC did specify that for some names (such as doctor, lawyer) there should be a restriction on how the name is used so that people aren't misled (that's another whole discussion). In the end, most voluntary PICS aren't that helpful.  (As I said in the entry on PICS, the mandatory ones are impotant in the protections they provide). The implication of the statement above was that, if people filing an objection to protect their 'community' - however defined - won, then they should be required to - in their PIC - to specify how they will ensure that names in their 'community' registry must only be used for their 'community' as they have defined it. (Sorry to be long winded - I hope this helps)

        1. Thanks!

          Yes, there is overlap in this debate, that's why I hope we can develop an answer that is consistent with the response to the PICs section. In fact, there is overlap in other areas too – notably with Community Applications, Community Objections and CPE but that's another story.

          Appreciate the reinforcement of PICs concept but isn't Q 2.8.1.e.15 more of a 'twist' to your 3rd last bullet/question in the PICs section? (ie. 

          •  If a volunary PIC is made in response to he GAC, public comments or other concerns, is the inclusion of a PIC in the contract the     proper mechanism - or something else?)


          I read Q 2.8.1.e.15 as asking if we thought it was a good idea for a PIC specified by a Community Objector to apply to an applied-for string becoming mandatory for a successful applicant in a contention set in event the Community Objector prevails.

          I'd even take it further to ask if the same approach could be taken with all Community Objections with an applied-for string whether it's subject to a contention sets or not so long as a Community Objection is filed and it prevails.  

          1. And that is the question I was also asking - looking for input.

            There is logic in saying that, if a community objector successfully objects and gains that community name - then if they plan to be the registrar for that community, surely there should be some way of ensuring that the registry does, in fact, ensure that the name is used for those community purposes. 

            Again, though, remember that PICs are enforceable through the PIC Dispute Resolution Scheme.  That was another point in my text. 

            1. Yep, we're in the same boat. 

              I'd say both your question and this Q 2.8.1.e.15 should be answered in the affirmative. I think it's best to get a PIC in as the primary objective since ALAC appears to favour use of PICs (especially mandatory PICs), and leave the enforcement mechanism as secondary problem. We just have to be careful to frame each PIC in a way that it is not too outrageous or too vague a contractual obligation to be enforceable if it goes to a PICDRP.

              1. Great - I think we're on the same page with this one. 

                Next task - what is meant by community such that, to use your words, it's not too outrageous or too vague

    4. Inputs to section 2.8.1 Objections (2 Sep) see also Justine Chew's Google Doc )


      Input to Option 2.8.1.d.1 -- Yes, and I would include accepted national or international public policy.

      Input to Option 2.8.1.d.2 --  Yes, this is fair.

      Input to Option 2.8.1.d.3 -- In principle, I think use of the GAC Advice mechanism should be left to GAC to manage. However, 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. Noting that in any case that GAC Advice is not an objection.

      Input to Option 2.8.1.d.4 -- Yes, to specific time period for GAC Early Warning and for the inclusion of both a written rationale/basis and specific action requested of the applicant.

  6. 2.2.4 Different TLD Types (~ Community Applications, etc)

    Preliminary Recommendation
    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.

    The WG seeks input on:

    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?

    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.

    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?

    What input do you have to the questions highlighted in blue?

  7. I wondering if anyone might have an example of possible (even fictional) communities which in which the CPE process would endanger freedom of expression and association – as per question below


    The Work Track also considered a report on CPE prepared by the Council of Europe,289 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?
    1. I don't think it has endangered freedom of speech or association, but what it did is discredit such speech and association.

      .bank is a community TLD. It certainly does not represent all banks world-wide, or even a small fraction of them, but it does have the imprimatur of being a "community TLD". A community applicant that did face another applicant for the same string had to undergo the CPE and generally failed. So even though that group may have had a much wider representation of the "community" than .bank (and I am only picking that one because it is very visible), it was denied the right to be known as an Internet community (in the TLD sense). That does put it in a more questionable position and this does have impact.

  8. The CPE process had a real struggle in defining what was a community and what was not a community.


    As a result, applications from communities were turned down as not being from a community. A real example off the top of my head is .GAY

    That's of course because ICANN chose an external organisation for the job of determining what was a community, that was completely ill-suited for the job: the Economist Intelligence Unit (EIU). Back then I contacted the EIU on behalf of the ALAC and we event sent them a Statement to ask about their method for determining communities, as well as ask for transparency. We were blatantly ignored.

  9. That is interesting Olivier. Thank you. I added a few qualifiers to Justine's google doc. around the definition of community such as – deleting anything requiring the payment of fees and also not requiring any kind of certification. But if, as you say, the evaluation committee has no clue what community could or should be, pretty hard to beat that back. So maybe the issue is really how is that committee chosen. 

    1. For references you might wish to read:

      https://atlarge.icann.org/advice_statements/7041  <--- strong correspondence from the ALT to the Board

      https://atlarge.icann.org/advice_statements/7171

      https://atlarge.icann.org/advice_statements/7201


      Unfortunately, at the end, we were blatantly ignored. You can therefore understand my cynicism now. But we need to make these points again now.

  10. Community Applications

    Note 1) This note is to bring your attention that the following draft about Community Applications is added to Justine Google Doc to follow-up with the discussions that started there.  

    Note 2)  Since I was not part of any working tracks on the New gTLD Subsequent Procedures Policy Development Process, the draft I put together is based on my own reading and the different comments that were added. Hence do feel free to remove/change any of the drafted text.

     

    Definition of the “Community”

    The community definition found in the “Council of Europe Report” and “GAG communiqué”, still not adopted or endorsed.  A possible problem for there is no agreement on one definition because the term “community” could be used to describe an officially registered community with clear mission and vision vs. the community of a group of dispersed people that have a common interest. 

    Providing a discrete “community” definition that satisfies all kind of communities would not be easy. While providing a detailed acceptable description in the Application Guidebook (AGB) of all kinds of communities that could be referred to by the  Community Priority Evaluation (CPE).  That would be also helpful for an applicant to community-based string to find easy supporting documentation based on the Community description in the AGB.

     

    Categorizing Community-Based applicants

    Applicants could be categorized as an 1) existing registry operator,  2) A new registry operator that applies on behalf of the community and might be specialized into community-based strings, and 3) new registry start up.

     

    Application Guidebook on CPE Guidelines

    With the above categorization in mind, it would be good to write a clear and detailed AGB that provides starters with step by step procedures and samples of the required documentations.   

    Furthermore, the more details included in the AGB the more transparent and predictable the outcomes of the application reviews would be. It was noticed the concerns on the lengthy CPE review time, revising the CPE review timeframe to have new estimate of the expected review time for the CPE would reduce the applicant comments.

    Having an anticipated CPE Q&A section in the AGB will be also very helpful.

     

    Issues of community-based string

    Providing an elaborate description of “Community” might contribute to the reduce the proposed community-based string contention.

    It is expected that the community based string application to comes with certain package/model to serve the community registrants. This package is expected to be reflected in the applications as contractual requirements in Specification 12 of the Registry Agreement.

    Issues of Freedom of expression and association will always be a discussion point whenever there is a community based string.

     

    Community-based Application process

    First time community-based registry applicants need to have a good understanding of process difference between community related strings and non-community strings applications.  AGB would be one reference for this information but providing outreach prior to the opening of string applications would be helpful.

    To avoid the excessive time in CPE review applications, it would be good to have an ICANN staff checking the applications and make applicants in compliance with the all the requirements.  

    Provide a clarifying text and/or examples on each requirement in the application form, does help applicants to provide a crisp and precise replies within the restrictive word count.

     

    Application reviewers/panelists and the CPE review process

    There is a need for a clear selection criteria to be in place for the appointment of the CPE reviewers, to make sure that they are well informed and there is no potential conflict of interest.

    Since CPE has extra examinations steps, there is a need to put a detailed list of tasks required throughout the review process, this provide a better estimation of the review cost.

    CPE scoring still raises many concerns.  There is a need to study the listed CPE criteria in the AGB and propose change if needed. Then testing this modified scoring criteria to be able to generate consistency among the evaluators scoring.  Which might lead to lower the threshold score for success. 

  11. The drafting team on section 9.1 has been discussing the definition of community and 3 out of 4 in our group is leaning towards  a definition from a Council of Europe report which offers the following definition, based on the concept of association used by the European Court of Human Rights and the United Nations: "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".  One of our group feels it is too broad and would lead to abuse. 

    We are looking for more input. Does the Council of Europe definition satisfy the following conditions set out in the AGB?

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


  12. The drafting team on 9.1 is also considering the following amendment to the more detailed definition of community:

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

     not be tied to 2007. 

    Especially if gTLDs move to a continuous schedule rather than through rounds, a firm number should be used instead, eg. that the community must be able to show it has been in existence for (x) years -- it could be 5,7, or 10.


  13. Topic 2.2.1: Continuing Subsequent Procedures (full WG) Question:   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?    

    Background:

    The 2009 Affirmation of Agreements called for a regular review of the degree to which the Net Generic Top-Level Domain (gTLD) program promoted consumer trust and choice and increased competition in the DNS market.

    In 2013, the GNSO established a draft report on possible metrics that could be used to measure achievement against the three headings of consumer trust, consumer choice and competition. The ALAC believed the metrics were too focused on registries and registrars and did not measure end user benefits and trust.   In response, the ALAC developed additional metrics for end-user confusion, growth in both domain name and non domain name use to access Internet resources, complaints data, and transparency of consumer information. While those metrics were forwarded to the GNSO, many of them were not adopted. (see ALAC Statement on the At-Large new gTLD Metrics Task Force Report 1 April 2013)

    In the end, 60 metrics were developed and used in the Draft Report on Competition, Consumer Trust and Consumer Choice, released for comment in March 2017 and in new sections to that report, released for comment in November 2017.  ALAC provided comments on both (see the ALAC Statements of 18 May 2017 and 15 January 2018).

    The other set of metrics come from the Market Place Health Index to analyse the overall health and diversity of the global gTLD marketplace.  ALAC provided input into the metrics in its statement of 21 December 2015. A Beta version of the Index was published in June 2018, with metrics on Robust Competition: Geographic Diversity, Robust Competition- Competition, Robust Competition –Total  gTLDS, Robust Competition – Additions and Deletions, Market place stability, and Trust. All but one of those headings has metrics.  Metrics have not been developed for ‘Trust’ in this index.

    In all of ALAC’s submissions, comments have focussed on the outcomes for end users.

     

    Suggested Metrics – focussing on the impact on End Users (headings taken from our various Statements)

    For End user Confusion – customer surveys

    • Frequency of success in reaching intended supplier through entry of domain name
    • Frequency of landing at unintended destinations

    Is the name legally secure, alive and active:

    • how many domain names are just parked and/or for resale,
    • how many domain names are live in a server, but not actually used (no WWW nor MX records),
    • how many domain names have an active webpage and what level of traffic do they generate, and,
    • how many domain names just redirect to a domain name in a legacy TLD

    diversity

    have an index related to population, for instance "number of registrars per 100,000 inhabitants, or similar. This index could reflect the levels of DNS market penetration, consumer choice, and consumer support in a country/location.

    Consumer Complaints

    • How many complaints received related to  new gTLDs
    • How many complaints are resolved in set timeframes and how many complaints relating to new gTLDs have resulted in ICANN compliance action

    industry statistics:

    Resellers  should included in statistics and tracked in the same way as Registrars (since most customers will not appreciate the difference between a registrar  and a reseller)


    ALAC has also supported acquisition of additional information including information on 

    • the relationship between specific registry operators, registrars and DNS abuse
    • collection of data about and publicize the chain of parties responsible for gTLD domain registration.

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

  14. I have been working as part of the New Subsequent Procedures since the beginning and have followed all comments stated here. in general, I have stated my comments before the group, being the only concern still existing, the issue related the problem of market access for smaller/community dedicated  registries , specially in developing regions, where there is few or none registrars and large ones, from other regions, do not want to work with those strings leaving those new gTLDs registries without option. This is being debated and I believe a reasonable alternative will result and incorporate. The ALAC Statement represents, in my view, the best analysis we could offer about the report.  

  15. First I like to thank all those that contributed to this statement. Secondly i like to note my unavailability to contribute to this and my apologies for same. I have just gone through the summary alone and I just want to make 2 comments on that:

    1.  I am not sure why we needed to acknowledge that the newgtld program would continue, I feel that the best we should do is to be silent on it especially as the preceding text to that clearly indicates that it's still a point of debate within At-Large. To me our acknowledgement is somewhat an endorsement

    2. The purpose of ALAC is clearly stated in the bylaws, I don't think we need to state why we are commenting on one part and not on the other. We can't entirely affirm that other sections are not important to end users and that is why we didn't comment about them. I feel that may do some de-service hence I suggest we just make the comment and leave it at that; We were silent on the other parts by not making a comment on them hence we should not indirectly endorse them by saying they do not concern end user. I therefore suggest the following sections be removed "On the same note, we have also chosen not to offer comments to selected sections of the Initial Report, namely sections which the ALAC believes has little or no impact on Internet end users, as indicated herein. On the same note, we have chosen to offer comments only to parts of the Initial Report which we believe carry an impact on Internet end users."

    Once again I apologize for making comments now but it's okay if this is too late and can't be accommodated,  may just have to abstain from voting (hopefully it won't be counted)

    Regards