Content Comparison

Audio Recordingonly

Zoom Recordingrecording

Chat TranscriptZoom chat

GNSO transcripts are located on the GNSO Calendar

Attendance  Attendance

Apologies: Martin Sutton, Kristine Dorrain, Flip Petillion,  Kristina Rosette

Notes/ Action Items

Action Items:

ACTION ITEM 1: Staff to provide an update on EBERO-triggering events.

ACTION ITEM 2: Develop a definition of an RSP especially in terms of RST.

ACTION ITEM 3: Staff to circulate the meeting schedule for SubPro at ICANN65 once the schedule is published.

Notes:

1. Updates to Statements of Interest (SOIs): No updates provided.

2. Review of Summary Documents (see: https://docs.google.com/document/d/1R4zXTH3hIgfbqoxyqsSp19Bl6J96NNeV7oCgxsXKD-w/edit?usp=sharing)

a. 2.2.5 Application Submission Limits

Policy Goals / What the WG is Seeking to Accomplish

• If limits are set, there must be a clear rationale for establishing these limits.
• It must be operationally feasible to implement any policy that is developed. In this case, it must be feasible to enforce any limits that are set.
• If any limits are imposed on the overall number of applications or the number of applications a particular entity may submit, the policy must be fair to all applicants.
• Policy should support competition and consumer choice.

Public comment summary

High-level Agreements

• Support from most commenters that no limits should be placed in the overall number of applications or the number of applications particular entity may submit.

Outstanding Items - New Ideas/Concerns/Divergence

• Public Interest Community/Christopher Wilkinson: Divergence - Place limits on the number of applications per company and in cooperation with other companies
• Public Interest Community: New Idea - ICANN should allow no more than 2 dozen applications for each company, including its parent company, subsidiaries, and affiliates to increase fairness and allow for adequate oversight and public review.

Discussion:

-- Shouldn’t there be an additional policy goal of fairness?

-- Question to OCTO/RSSAC/SSAC: Answer was that there was no upper limit on the number of TLDs that could be in the root.  There is a scale for TLDs to be added to the root.  Very high scale.  The primary concern raised by the SSAC and RSSAC is more about rate of change rather than an upper limit.
Rate of change to the root zone, to be more specific.

-- Concerns about fairness to the Global South -- one of the policy goals should be application limits early on to enable applicants from the Global South to apply.

-- Processing time and large numbers of applicants could prevent others from applying.

-- Not allowing large applicants to dominate, what the community can process, protecting the Global South.

-- Concerns about free speech rights if there are limits.

-- Not all interests should be assumed to be conflicts of interest.

-- How do we objectively get to a number?

-- A limit of 24 multiplied by large applicants would give a large number.

-- A limit should be based on facts.

-- Difficult to have this conversation in isolation.  If we have one more round then it is difficult to have a limit.  If we have 5 or more rounds then it might make sense if they open on a schedule (say after 6 or so months).

-- Go on the assumption that there will be multiple rounds and some type of formula for determining when to open the next round.

-- Global South applications and/or Middle applicants and/or applications which intend to benefit under-served communities are better supported through prioritization, Applicant Support, partnerships, rather than limiting application numbers.

-- Applicant freedom of expression is a guiding principle for the program.  There is an overarching concern about the public interest.  Could there be a dedicated unit in ICANN for a different type of application so that these types of applications get processed more quickly?  This would fall into the topic of prioritization.

-- There is a policy recommendation from this WG that applications would be prioritized.

-- ICANN Org: there is a rate of delegation limit of 1000 a year.  So that also limits processing.  But the SSAC now says this is a sliding scale.

b. 2.2.6 Accreditation Programs (e.g., RSP Pre-Approval)

Policy Goals / What the WG is Seeking to Accomplish

• Where operationally feasible and appropriate, efficiencies should be realized in the technical evaluation of registry services without compromising the goals of the program, such as diversity, competition, and security of the DNS.
• Where a single RSP provides registry services for multiple TLD applications, duplicative evaluation and testing should be reduced.
• To the extent that there is testing as part of the Pre-Approval Program, Testing must be consistent, objective and to the extent possible, predictable.
• Program should avoid processes and structures that show undue preference to incumbent RSPs versus prospective RSPs and should be equally available to both.  Note from Jeff:  This was a comment from Google, and supported in comments by Mark Monitor and Lemarit, but seems like one that had support when discussed previously.  Should this be here?

Discussion:

-- Comments from Valideus would support the 4th bullet -- equal treatment of all.

-- If this is a pre-approval program, then both incumbents and new entrants would have to go through the program and treated equally.

-- Seemed to be general support that this would be a voluntary program.

-- Don’t want an RSP that is not currently an incumbent to complain that they are disadvantaged because incumbent RSPs are already following ICANN’s procedures.  We don’t want to cater to the lowest common denominator.  There needs to be a strong basis in security and stability.

-- Seems to be agreement that our structures and processes should treat all RSPs equitably (4th bullet in Policy Goals).

-- Note on referrals to other sections: “To the extent that the Working Group adopts the notion that all RSPs are evaluated in the same manner using the same processes (except the Pre-approval process happens earlier in time, then all evaluation requirements should be referred to applicable sections (eg., 2.7.6 Security & Stability and 2.7.7 Applicant Reviews)”

High-Level Agreements:

-- Support for use of the term “Pre-Approval Program”.

-- Support for process having technical requirements.

-- Some commenters also supported the consideration of anbut will also consider the RSP’s overall breadth of registry operator support, while others believed that the measurement of overall breadth of registry operator support would be difficult to assess.

-- Support expressed for the idea that 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. The Business Constituency was the only one to recommend that the program be mandatory.

-- Support for self-funding on a cost-recovery basis.

-- Some support for the idea that if required, the requirement should be extended to RSPs that are not Pre-Approved as well.

-- ICANN Org Seeks confirmation that only difference between a pre-approved RSP and one that is approved during application evaluation is the timing of when the approval takes place;  All criteria for evaluation and Registry Services Testing (RST) are the same.  Comment from Jeff:  Does this have high level agreement?  If so, keep here.

3. ICANN65:

-- Sessions scheduled on Day 1 (Monday) -- 2 sessions scheduled for WT5 in the morning.  Then for the WG there are sessions split between Day 1 and Day 2.

-- Staff will circulate the schedule of SubPro meetings at ICANN65 once the schedule is published