Subsequent Procedures Response

	A	B	C	D	E	F	G
1	Section	Subject	Outstanding Questions/Preliminary Recommendations for Comment	Should ALAC Respond? (Y/N)	ALAC Positions for Comment	Feedback	Pen Holder
2	2.2.1	Continuing Subsequent Procedures	The Working Group recommends no changes to the existing policy calling for subsequent application rounds introduced in an ongoing, orderly, timely and predictable manner.
3	2.2.1	Continuing Subsequent Procedures	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? ALAN has added this text which has no meaning. And AGAIN		Yes. ICANN needs to better define its metrics that it will use to determine whether a particular program is a “success.” Moreover, the ICANN community should leverage existing metrics it has already developed and collected (e.g., the market place health index and market indicators) to make such determinations.	Justine Chew: Where have the IAG-CCT’s identified 66 metrics fed into for collection, monitoring and reporting since their recommendation in Sep 2014? CCT-RT? Marketplace health index monitoring? DAAR? What has ICANN done specifically to define, capture data and analyse metrics to understand “scale of demand”?
4	2.2.2	Predictability	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)255 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.		ICANN should strive and seek for more inclusivity from all aspects of the ICANN community; this way a term like “predictability” for the applicant does not translate into isolation favoring certain applicants over others.	Justine Chew: Yes, the Predictability Framework as contemplated (even if it requires more in depth consideration -- see page 24 of Initial Report) makes sense to provide guidance and predictability in addressing issues raised post-launch. Further, I find the concept of a Standing IRT to be appealing, pursuant to the ideas raised in the Initial Report pages 16-22.
5	2.2.2	Predictability	Does the concept of a Predictability Framework make sense to address issues raised postlaunch?; How should launch be defined?
6	2.2.2	Predictability	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.		ICANN should define the term “launch” as the first day which applications are accepted.	Justine Chew: Yes, the Predictability Framework as contemplated (even if it requires more in depth consideration -- see page 24 of Initial Report) makes sense to provide guidance and predictability in addressing issues raised post-launch. Further, I find the concept of a Standing IRT to be appealing, pursuant to the ideas raised in the Initial Report pages 16-22
7	2.2.2	Predictability	What are potential criteria that can be applied to help distinguish between types of issues and resolution mechanism?
8	2.2.2	Predictability	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.			Justine Chew: As the Standing IRT would only deal with post-launch operational / administration issues:- Who (or how many parties) would be affected by a recommendation or decision of the SIRT? And severity levels. Is an issue a one-off occurrence? How urgent is action needed to resolve issue? How badly does a lacuna need to be filled? Can implementation of an SIRT recommendation or decision reversible? Need to look at the recommendations of the Policy and Implementation WG.
9	2.2.2	Predictability	Do you have thoughts on the open questions/details related to the Standing IRT panel discussed in section (f) below?			Justine Chew: Don’t know if there is an existing structure that can take on the “duties” of the SIRT. Is there? Does the IRT for Subsequent Procedures care to take this on?
10	2.2.2	Predictability	Is there a different structure, process, or body (possibly already existing) that might help provide needed predictability in addressing issues raised post-launch?
11	2.2.2	Predictability	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 Chew: I think several key points are evident: The Phase 3 Predictability Framework mandate of an SIRT is limited in scope and time (as are the existing GNSO procedures) so if conducted well, shouldn’t cause unintended overlaps. It is also supposed to raise any issues of policy-implementation conflict to the GNSO Council for further action. An SIRT, 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. We can see that even with a GNSO Expedited PDP, time for getting up may result in impact due to delay. In any case, a public comment process is (generally?) welcomed by At-Large, although the pertinent question is “Should operational changes be subject to public comment?” -- noting that all fundamental / possible policy impact changes must always go through a GNSO procedure.
12	2.2.2.2	Clarity of Application Process	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 should exercise more transparency in the process to impacted applicants by notifying them of material changes to the application process.
13	2.2.2.2	Clarity of Application Process	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 community believes that ICANN needs to conduct a study regarding its scalability to handle the likely higher influx of applications for new gTLDs.
14	2.2.3	Applications Assessed in Rounds	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.”
15	2.2.3	Applications Assessed in Rounds	Option: Conduct one additional “round” followed by an undefined review period to determine how future applications for new gTLDs should be accepted.
16	2.2.3	Applications Assessed in Rounds	Option: 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.
17	2.2.3	Applications Assessed in Rounds	Option: 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.
18	2.2.3	Applications Assessed in Rounds	Option: Conduct one additional “round” followed by the permanent opening up of a first-come, first-served process of new gTLD applications.
19	2.2.3	Applications Assessed in Rounds	Option: 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.
20	2.2.3	Applications Assessed in Rounds	Option: Immediately commence a permanent first-come, first-served process of accepting new gTLD Applications.
21	2.2.3	Applications Assessed in Rounds	Of the models described above, which model do you believe should be employed, if any? Please explain.			Justine Chew: 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 would then be 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 anongoing 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. Holly Raiche: 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.
22	2.2.3	Applications Assessed in Rounds	For the model you have selected, what are some mechanisms that can be employed to mitigate any of the listed (or unlisted) downsides.			Justine Chew: 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 should 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.
23	2.2.3	Applications Assessed in Rounds	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 Chew: 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 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 new gTLD program, and on the other hand, basic expectations of potential applicants. 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.
24	2.2.3	Applications Assessed in Rounds	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 Chew: 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 systemInternet.
25	2.2.3	Applications Assessed in Rounds	Has the scale of demand been made clear? Does the concept of rounds affect market behavior and should factors beyond demand affect the type of application acceptance mechanism?
26	2.2.4	Different TLD Types	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.		ICANN should continue to recognize the community priority category. However, it should not impose narrowly defined restrictions so as to limit applicants who would otherwise fall into the “community” category.		· Mariat Moll; Abdulkarim Oloyede; · Nadira AL-Araj; Yrjö Länsipuro
27	2.2.4	Different TLD Types	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?
28	2.2.4	Different TLD Types	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.
29	2.2.4	Different TLD Types	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?
30	2.2.5	Applications Submission Limits	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.
31	2.2.5	Applications Submission Limits	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.
32	2.2.6	Accreditation Programs	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.
33	2.2.6	Accreditation Programs	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.
34	2.2.6	Accreditation Programs	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.
35	2.2.6	Accreditation Programs	The RSP pre-approval process should be funded by those seeking pre-approval on a costrecovery basis.
36	2.2.6	Accreditation Programs	Should the pre-approval process take into consideration the number and type of TLDs that an RSP intends to support? Why or why not?
37	2.2.6	Accreditation Programs	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?
38	2.2.6	Accreditation Programs	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?
39	2.2.6	Accreditation Programs	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?
40	2.2.6	Accreditation Programs	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.
41	2.2.6	Accreditation Programs	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?
42	2.3.2	Global Public Interest	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.		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.		Holly Raiche; Bastian Goslings
43	2.3.2	Global Public Interest	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 supports the report’s recommendation to continue voluntary PICs given their value to end-users and ensure equity in the gTLD process.		Holly Raiche; Bastian Goslings
44	2.3.2	Global Public Interest	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).
45	2.3.2	Global Public Interest	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.
46	2.3.2	Global Public Interest	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.
47	2.3.2	Global Public Interest	Should there be any exemptions and/or waivers granted to registry operators of any of the mandatory Public Interest Commitments? Please explain.
48	2.3.2	Global Public Interest	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?
49	2.3.2	Global Public Interest	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?
50	2.3.2	Global Public Interest	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?
51	2.3.2	Global Public Interest	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.257 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?;			Holly Raiche: I’m not sure where or how to do this, but I am putting my hand up for the PICS issue. I”ll try to have something on the policy page workspace in the next couple of days. Looking at the recommendations, generally, our issues: Mandatory Should there still be mandatory PICS (and in response to the earlier section, all provisions on PICS should be in place BEFORE more applications (in rounds or otherwise) start. One of the issues was that PICS weren’t in the original Applilcant Guidebook so there was justifiable criticism of inserting them afterwards What should they be/do we want to add to what is already there - and one of the questions - should the requirements be codified through a PDP to be mandatory We raised the issue of enforceability - under Specification 11, they do form part of the agreement. But we raised the issue of who enforces - clearly ICANN compliance Voluntary The Guidebook was also amended to allow for additional commitments to be made. Some of the questions being asked are whether they can be limited in scope or duration, whether it would be reflected in the Registry Agreement, ec The GAC also said that some PICS raise the issue of ‘early warning’ - and to what extend should they be treated differently - or indeed, what should we say (again) Evan Leibovitch: Unlike the first time we went over this issue at length, we now have some hindsight to guide us. A few points to consider before we commit substantial volunteer time to a repeat of what we did for the last round. Consider what might be some lessons learned, IMO: The "PI" intended to connote a "public interest" component of "PIC" turned out to be misleading. The PICs that were mandatory were those designed to appease trademark and copyright interests, measures against so-called piracy and similar obsessions of the intellectual property constituency. PICs primarily intended to serve the global public interest (such as keeping category-name TLDs true to their category) were weakly designed, optional, and effectively unenforceable. It can be objectively measured: exactly how many registries were cited for violating PICs, especially the "optional" ones? What action was taken as a result? What process existed for the public to be aware of PICs and then be able to report violations? To my recollection the effectiveness of PICs from the last round was somewhere between negligible and nonexistent. Based on the miserable history of actual "public interest" PICs -- their creation, maintenance and enforcement -- I personally would challenge the need to spend effort designing new-round PICs that will also be weak, optional and unenforced. So either we need to demand that the PIC concept itself be made useful, or we ought not waste our time validating what is effectively a charade. Olivier Crepin-Leblon: Based on the miserable history of actual "public interest" PICs -- their creation, maintenance and enforcement -- I personally would challenge the need to spend effort designing new-round PICs that will also be weak, optional and unenforced. So either we need to demand that the PIC concept itself be made useful, or we ought not waste our time validating what is effectively a charade. Whilst I agree with you that PICs should be meaningful & enforceable, I do not know what hard data you are basing your comments on their lack of usefulness. If they are currently not useful then let's get them improved! But throwing the towel in when we're actually in a position to make a difference is not constructive in my opinion. If we already go to battle saying we're wasting our time, then we've already lost the battle. Carlton Samuels: Since I'm one who spent a lot of hours on this topic in the last round, I feel compelled to say my 2 cents. First, there is no successful contradiction to the fact that PICs came about as a tactical response, a tack on. Second, there is no successful contradiction to the fact that notwithstanding the ICANN org noise that all PICS were contracted and thusly enforceable, showed no enthusiasm for enforcement. Three, the PICs themselves have a fundamental weakness as they tend to envelop business plans removed from the actual DNS. Speaking as a corporate strategist, it is a fickle thing to enforce and one I personally think ICANN would be challenged to enforce. Four, the anecdotal evidence is that a couple of outfits have implemented PICs that smoothly integrate into their business plans; think a few of the gTLDs that attracted GAC early warnings. I looked and could not find any contemporary information either from the Compliance side or from the outfits themselves that tell how things are working years on. On the balance of facts and the weight of evidence, most who filed PICS know its a 'feel-good-add-a-compliant-tick mark-get-out-of-jail-card' thing and that alone. In fact I believed my first use of the label 'not worth a bucket of warm spit' was to record my estimate of their value to the global public interest. Maybe we need to encourage PICs. And maybe the gTLD operators will, like those outfits cognizant of GAC early warnings, come up with some that converge seamlessly into their business plans. If there is a better mousetrap to sell then I'm in. However, given the facts and history, I would need to be persuaded this is worthy of another investment of volunteer time. Nadira Al-Araj: 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.
52	2.5.3	Application Submission Period	Is three months the proper amount of time? Is the concept of a fixed period of time for accepting applications the right approach?
53	2.2.5	Application Submission Limits	Should there be limits to the number of applications from a single applicant/group? Consider if the round could be restricted to a certain applicant type(s) (e.g., from least developed countries) or other limiting factor.
54	2.5.2	Variable Fees	Should the New gTLD application fee be variable based on such factors as application type (e.g., open or closed registries), multiple identical applications, or other factors?
55	2.3.3	Applicant Freedom of Expression	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)258 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.259 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.
56	2.3.3	Applicant Freedom of Expression	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?
57	2.3.3	Applicant Freedom of Expression	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?
58	2.3.3	Applicant Freedom of Expression	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?
59	2.3.4	Universal Acceptance	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,260 through the Universal Acceptance Steering Group,261 as well as future efforts.
60	2.3.4	Universal Acceptance	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?		Yes, the At-Large Committee believes that the UASG should include and consult our constituency in developing initiatives that better advances the principles of universal acceptance.
61	2.4.1	Applicant Guidebook	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.
62	2.4.1	Applicant Guidebook	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: • 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. • 2.4.1.c.2.2: Be less about policy, with a stronger focus on the application process.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. • 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. • 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. • 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. • 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).
63	2.4.2	Communications	Program Information, Education and Outreach: 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
64	2.4.2	Communications	Program Information, Education and Outreach: 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.
65	2.4.2	Communications	Program Information, Education and Outreach: 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
66	2.4.2	Communications	Program Information, Education and Outreach: Leverage Global Stakeholder Engagement staff to facilitate interaction between regional ICANN organization teams and potential applicants from these regions.
67	2.4.2	Communications	Communications with Applicants: 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.
68	2.4.2	Communications	Communications with Applicants: 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.
69	2.4.2	Communications	Communications with Applicants: 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.
70	2.4.2	Communications	Do you have any suggestions of criteria or metrics for determining success for any aspects of the new gTLD communications strategy?			Vanda Scartezin: Metrics for end users are security, respect to privacy and " continuity". If organization has no capacity to support initial investment so it will fail in a couple years and all registrant had done to promote the new domain will be waste of money. I have been promoting here 2012 round. But it was this, myself talking with several organizations to enter. We had a reasonable success but the reality was there was NO PROMOTION of 2012 round in the South Hemisphere. Nothing in digital news in local languages. ICANN came one day to Sao Paulo Brazil and I asked people to join - we got 50 attendees . We had 8 ( from 11 applied in Brazil) that attended this meeting . Nothing else was done in South America. When I have done a survey in 2015 talking with big companies around South America I found just 1 that said they have no intention to apply if there was another round, all others responded YES, they had interest, please alert us, if there will be another round. So - the point here is just one: MAKE HUGE PROMOTION IN SOUTH HEMISPHERE Maureen Hilyard: “So - the point here is just one: MAKE HUGE PROMOTION IN SOUTH HEMISPHERE” And focus on making a splash in the Pacific region as well.. Michele Neylon: It's not just the Southern hemisphere We were approached by companies and government agencies after the application window was closed. Marita Moll: I agree with Holly's points, and the further clarifications. Promotion, including adequate advance notice, were clearly missing last time around. It has also been suggested in other threads that, once ICANN moves beyond rounds to continuous availability, this problem could become even more acute. So it should be given lots of consideration during this series of discussions. The general awareness of new TLDs outside the "bubble" is a problem. It's not just language, though I agree that it is an important factor.
71	2.4.2	Communications	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
72	2.4.2	Communications	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?			Vanda Scartezini: a) Community Priority Evaluations what was relevant during 2012 was the fact that all the effort asked for community to prove support ( ltos of money to do this around the world ) was ignored during the analysis period and several community ( I have promoted few) faced auction though their competitors had no prove of community interest. Then, if we will impose some demands to community we need to make sure those items will be considered and none without similar qualifications will be compete with them.
73	2.4.3	Systems	The ICANN organization should ensure that enough time is provided for development and testing before any system is deployed.
74	2.4.3	Systems	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.
75	2.4.3	Systems	Applicant-facing systems should be usable and integrated, ideally with a single login.
76	2.4.3	Systems	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.
77	2.4.3	Systems	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.
78	2.4.3	Systems	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.
79	2.4.3	Systems	Implementation Guidance regarding technical systems: Applicants should be able to enter non-ASCII characters in certain fields.
80	2.4.3	Systems	Implementation Guidance regarding technical systems: 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.
81	2.4.3	Systems	Implementation Guidance regarding technical systems: A single applicant should be able to submit and access multiple applications without duplicative data entry and multiple logins.
82	2.4.3	Systems	Implementation Guidance regarding technical systems: Applicants should be able to receive automated confirmation emails from the systems.
83	2.4.3	Systems	Implementation Guidance regarding technical systems: Applicants should be able to receive automated application fee related invoices.
84	2.4.3	Systems	Implementation Guidance regarding technical systems: Applicants should be able to view changes that have been made to an application in the application system.
85	2.4.3	Systems	Implementation Guidance regarding technical systems: Applicants should be able to upload application documents in the application system.
86	2.4.3	Systems	Implementation Guidance regarding technical systems: Applicants should be able to update information/documentation in multiple fields without having to copy and paste information into the relevant fields.
87	2.4.3	Systems	Implementation Guidance regarding technical systems: 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.
88	2.4.3	Systems	Implementation Guidance regarding technical systems: The systems should provide clearly defined contacts within the ICANN organization for particular types of questions.
89	2.5.1	Application Fees	Work Track 1 is considering proposing that the New gTLD Program continue to be selffunding where existing ICANN activities are not used to cross-subsidize the new gTLD application, evaluation, pre-delegation and delegation processes.
90	2.5.1	Application Fees	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.263 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.
91	2.5.1	Application Fees	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,264 that could more easily proliferate with a low application fee amount.
92	2.5.1	Application Fees	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.		ICANN should base its application fees on its needs so that it can cover basic expenses, and can continue to function and promote public-interest endeavors.
93	2.5.1	Application Fees	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.
94	2.5.1	Application Fees	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?
95	2.5.1	Application Fees	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?
96	2.5.1	Application Fees	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?
97	2.5.1	Application Fees	Are there policy, economic, or other principles or factors that might help guide the establishment of the floor amount?
98	2.5.1	Application Fees	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?; 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?)
99	2.5.1	Application Fees	Is there a way in which the application fee can be structured such that it can encourage competition and innovation?; 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?
100	2.5.1	Variable Fees	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.265 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.).