Note: This meeting was rescheduled from Monday, 17 February.
The call for the New gTLD Subsequent Procedures Working Group will take place on Tuesday, 18 February 2020 at 15:00 UTC for 90 minutes.
For other places see: https://tinyurl.com/vfesdub
PROPOSED AGENDA
- Review Agenda/Statements of Interest
- Review draft final recommendations – see attached Working Document and here:https://docs.google.com/document/d/1kUlmZH8nxWTgfcRluA5FxLheMm4XhhOwkRt7om52aQU/edit?usp=sharing [docs.google.com]
- 2.6.1 Application Queuing (page 30)
- 2.7.3 Closed Generics (page 33)
- AOB
Please prepare for the following topics for future meetings:
Thursday, 20 February at 15:00 UTC: 2.7.3 Closed Generics
Other upcoming topics:
2.2.5 Applications Submission Limits
2.3 Role of Application Comment
BACKGROUND DOCUMENTS
RECORDINGS
PARTICIPATION
Notes/ Action Items
Actions:
2.6.1 Application Queuing
Affirmation xx:
ACTION ITEM: Capture in a comment the request to add the words “non-IDN” in the first paragraph in brackets: “The Working Group affirms the approach ultimately taken for [non-IDNs] to application queuing during the 2012 round, in which ICANN conducted drawings to randomize the order of processing applications within an application window.
Recommendation xx:
ACTION ITEM: Any processes put into place for application queuing should be clear, predictable, and finalized and published [at the same time as] in the Applicant Guidebook.
Implementation Guidance xx:
ACTION ITEM: Add in the accompanying rationale that this is Implementation Guidance because it is subject to a legal review.
No Agreement:
ACTION ITEM: Add text to clarify that in the absence of agreement the policy will revert to the 2012 round implementation.
c. New issues raised in deliberations since publication of the Initial Report, if applicable.
-- Re: The second paragraph.
ACTION ITEM: Request alternative text from Christopher Wilkinson.
2.7.3 Closed Generics (page 33)
ACTION ITEM: Request that Alan Greenberg submit his proposal in writing to the list.
ACTION ITEM: Insert some suggested language to clarify the following sentence: “The ICANN Board made it clear, however, that the decision it made applied only to the 2012 round and that it wanted the GNSO to engage in policy discussion regarding the treatment of such strings in subsequent rounds.” Reference the Board resolution.
Notes:
- Review Agenda/Statements of Interest: No updates provided.
2. Review draft final recommendations – see attached Working Document and here:https://docs.google.com/document/d/1kUlmZH8nxWTgfcRluA5FxLheMm4XhhOwkRt7om52aQU/edit?usp=sharing
a. 2.6.1 Application Queuing (page 30)
Affirmation xx: The Working Group affirms the approach ultimately taken to application queuing during the 2012 round, in which ICANN conducted drawings to randomize the order of processing applications within an application window. The Working Group acknowledges that continuing to use the randomized drawing approach is contingent upon local law and the ability of ICANN to obtain the necessary license to conduct such drawings, but advises that under no circumstances should ICANN attempt to create a “skills-based” system like “digital archery” to determine the processing order of applications in subsequent procedures. This affirmation updates and replaces Implementation Guideline D from 2007 which recommended a first-come first served method of processing applications.
Discussion:
-- Make sure that we cover the prioritization of IDNs -- note that this is covered but not in the first affirmation.
-- Group applications according to characteristics, not only the IDNs.
-- But note that IDNs were randomized in their group.
-- Suggest you look at making the insertion after the word "randomize", e.g. "with idns taking priority at a group and randomized separately"
-- Suggest "which were treated separately but for which queueing was also randomized"
ACTION ITEM: Capture in a comment the request to add the words “non-IDN” in the first paragraph in brackets: “The Working Group affirms the approach ultimately taken for [non-IDNs] to application queuing during the 2012 round, in which ICANN conducted drawings to randomize the order of processing applications within an application window.
Recommendation xx: Any processes put into place for application queuing should be clear, predictable, and established in advance. The recommendation to establish procedures in advance is in line with recommendation 1.2.a in the Program Implementation Review Report which states: “Assign priority numbers to applications prior to commencement of application processing.”
Discussion:
-- Need to clarify what is meant by “in advance”. “In advance” should mean with the publication of the AGB.
-- Say that the AGB is “finalized and published”.
-- Publish as an addendum to the AGB.
-- What's the purpose of the Applicant Guidebook? Is it to document all elements of the application, evaluation and other related information?
-- At the same time as the AGB.
-- +1 for having it in the AGB. If not in the AGB, it seems appropriate to have it published prior to the application window opening.
-- Agree with the support for having it in AGB. Newcomers will have enough of a time trying to find info on this.
ACTION ITEM: Any processes put into place for application queuing should be clear, predictable, and finalized and published [at the same time as] in the Applicant Guidebook.
Implementation Guidance xx: Procedures related to application queuing should be simplified and streamlined to the extent possible. For example, applicants could be provided the opportunity to pay the optional fee for participating in the drawing along with payment for the application. Another suggestion is to explore ways to assign a prioritization number during the application process without the need for a distinctly separate drawing event.
ACTION ITEM: Add in the accompanying rationale that this is Implementation Guidance because it is subject to a legal review.
No Agreement: The Working Group notes that in the 2012 round a decision was made by ICANN Org to prioritize applications for IDN strings. Although there was a 30-day public comment period, the decision to prioritize IDN strings was never subject to policy review. Although the Working Group received a number of comments on this issue (both in support and against), the Working Group was not able to come to agreement as to whether those IDN applications should receive any priority in subsequent rounds.
Discussion:
-- This was not approved policy and the WG can’t agree to it as approved policy, therefore it shouldn’t be part of the next round.
-- Question: What does the WG do when it doesn’t have agreement? Answer: We said at the beginning of this PDP that we wouldn’t make changes to the existing policy if we couldn’t reach consensus to do so.
-- This is a rare situation because this wasn’t in the AGB and wasn’t consensus policy.
-- One WG member disagrees that we should treat the status quo as policy and that there should be a separate PDP on just IDNs that would take priority over this PDP.
-- If we can’t agree on a change then the policy was as the 2012 round was implemented.
-- The lack of agreement to change the practice implemented in the 2012 round leads to the retention of what was practiced.
-- We are talking about giving IDNs a slight head start over non-IDNs that aren’t in a contention set. Did this 2012 round implementation violate policy?
-- The policy was first-come, first-served, but the community said that wasn’t the best way to do it so at some point during the writing of the AGB the notion of the secondary time stamp came to be accepted by the community.
-- Looking at the comments there is agreement that first-come, first-served is not the way to do it and support for a random draw.
-- Only thing the WG can say is that we don’t agree. We don’t agree to recommend the status quo as policy.
-- Need to sort out this issue now.
-- Change the framework for how the WG operates in cases where the implementation violates policy?
-- As long as we cannot agree on a change, my view is that we must be consistent and leave it as AGB as implemented, that os 2012 practice.
-- In order to continue as policy it needs to be approved as policy.
-- Need to be consistent.
-- IDN Prioritization didn't seem to violate a policy. Conflating it with Closed Generics stacks the deck against the pro-closed generics folks in the next topic. Unfortunate.
ACTION ITEM: Add text to clarify that in the absence of agreement the policy will revert to the 2012 round implementation to prioritize IDNs.
Re: “Specifically on the topic of prioritizing entire contention sets including community-based applications, the Working Group considered a proposed recommendation put forward by one member: “All community applications in contention sets should be prioritized for Initial Evaluation if they provide advance commitment to enter the Community Priority Evaluation immediately up completing initial evaluation.” The Working Group member noted that the processing time for these applications is longer than standard applications, and therefore it would make sense to begin processing them earlier. Further, in the 2012 round, Community Priority Evaluations (CPE) were held until the entire contention set was through Initial Evaluation. The member noted that CPE is the quickest way to resolve a contention set, and a positive CPE result could spare standard applicants in the contention set any expense for Initial Evaluation, therefore creating greater efficiency in the process and savings for members of the contention set.”
Discussion:
-- Disagree with the above paragraph.
-- Need to have a restrictive concept of portfolio applications.
ACTION ITEM: Request alternative text from Christopher Wilkinson.
b. 2.7.3 Closed Generics (page 33)
No Agreement: The Working Group notes that in the 2012 round of the New gTLD Program, a decision was made by the ICANN Board to effectively ban exclusive use generic applications. The ICANN Board made it clear, however, that the decision it made applied only to the 2012 round and that it wanted the GNSO to engage in policy discussion regarding the treatment of such strings in subsequent rounds. Although the Working Group has had numerous discussions about this topic, and received extensive comments from the community, received a number of comments on this, the Working Group was not able to agree as to how to treat these applications in subsequent rounds.
See the Board resolution at: https://www.icann.org/resources/board-material/resolutions-new-gtld-2015-06-21-en#2.a
Discussion:
-- Not sure this is accurate: “The ICANN Board made it clear, however, that the decision it made applied only to the 2012 round and that it wanted the GNSO to engage in policy discussion regarding the treatment of such strings in subsequent rounds.”
-- Board resolution is interpreted to mean that you should be able to move your application to the next round subject to the rules of the next round -- so not a ban depending on the rules of the subsequent round.
-- This sentence and the Board resolution isn’t clear.
-- How do we allow closed generics without allowing in those that we find problematic.
-- Proposal: Allow a closed generic subject to approval of ICANN Board with near unanimity. If not approved it is not appealable.
-- There would have to be a criteria applied to any decision of this kind by the board, otherwise it becomes too subjective.
-- Question: What is the fallback position if we end up with no agreement?
-- We need to get to absolute clarity on what happens if we don't adopt an affirmative Policy ban on closed generics (which has never been adopted, by the way).
-- We need to develop a solution. If we want applicants to innovate in the next round, we need to make sure their hands aren't tied.
-- It's possible an outcome is "it seems applicants CAN mostly do what they want within the existing rules...let's codify some form of a ban" (Not saying that's likely, but possible.) But we should explore it to make sure we aren't unduly prejudicing new applicants.
-- Default was that the Board banned closed generics -- reference the Board motion.
-- WG will not make a recommendation that is only supported by one Constituency or Stakeholder Group.
ACTION ITEM: Request that Alan Greenberg submit his proposal in writing to the list.
ACTION ITEM: Insert some suggested language to clarify the following sentence: “The ICANN Board made it clear, however, that the decision it made applied only to the 2012 round and that it wanted the GNSO to engage in policy discussion regarding the treatment of such strings in subsequent rounds.” Reference the Board resolution.