Dear Working Group members,

Please see below the notes from the meeting today, 11 June 2019. These high-level notes are designed to help WG members navigate through the content of the call and are not a substitute for the recording, transcript, or the chat, which will be posted at: https://community.icann.org/display/NGSPP/2019-06-11+New+gTLD+Subsequent+Procedures+PDP

Kind regards,

Emily

Draft Agenda:

Welcome/Review of the Agenda/Updates to Statements of Interest (SOIs)
Work plan/schedule post-ICANN65 (https://docs.google.com/document/d/1l9pIXkiu_d5zPVqTM09Z5BiJ1Y3-mhnwaZLPfDDcnI4/edit)
Review of Summary Documents

(continued) 2.2.6 Accreditation Programs (e.g., RSP Pre-Approval) - (see Overarching Issues - https://docs.google.com/document/d/1R4zXTH3hIgfbqoxyqsSp19Bl6J96NNeV7oCgxsXKD-w/edit?usp=sharing)
2.3.2 Global Public Interest – (see Foundational Issues - https://docs.google.com/document/d/15rwviHM6AYtqDqyB6_5Yij2dTL6iuou8z7A32yzc7sE/edit?usp=sharing)

Action Items:

None

Notes:

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

2. Work plan/schedule post-ICANN65

One call next week. This will be the final meeting prior to ICANN65.
After ICANN65, the group will move to twice weekly calls on Monday and Thursday (see work plan for details). This will help ensure that we don’t have to extend the group’s work further.
Topics are included in the draft work plan.
The goal is to avoid repeating conversations.
Concern raised by one member that twice weekly meetings require a large time commitment from members and may result in burnout. Request to continue the conversation about the new schedule on the next call when more people can weigh in.
Concern raised by one member that this change will disproportionately impact those representing non-commercial interests. Suggestion to refer this issue to Council.
Concerns also raised that level of participation will decrease with a more intensive meeting schedule.
Conversation will continue over the email list.

3. Review of Summary Documents

a. (continued) 2.2.6 Accreditation Programs (e.g., RSP Pre-Approval) - (see Overarching Issues - https://docs.google.com/document/d/1R4zXTH3hIgfbqoxyqsSp19Bl6J96NNeV7oCgxsXKD-w/edit?usp=sharing)

Draft principle for discussion regarding timing of the program: “Results of an RSP pre-approval program should be available to be used by potential applicants with an adequate amount of time to determine if they wish to apply for a gTLD (and which RSP to use).”
Suggest to let implementation team determine the exact time frame, since there is not agreement in the comments about the time period (draft recommendation suggested 3 months).
Revisiting discussion from last week -- question raised by a WG member -- where did we leave off on the issue of taking an RSP off the list
Leadership response - It didn’t seem to make sense to take someone off the list because in the 2012 round, a backend RSP was approved and that was it. If an RSP or registry operator were in breach or terminated, there was no way to withdraw the approval received in testing, so this approach to the new program would be consistent with the 2012 round. Instead, reapproval would meet the goals and reduce bureaucracy.
Concern from one member that we need to be more proactive. There should be a program to help applicants who need to find an RSP in their jurisdiction. Otherwise power will be too concentrated in certain regions.
Revisiting recent discussion on the mailing list - suggestion was made that registry operators should be informed when there is a problem with their chosen RSP.
Process question - leaders are encouraging members to take discussion to the list. How will conversation on the list be taken into account and weighed vs. contributions on the call and through other channels? Should members restate positions and arguments on the mailing list following a call?
Comment: email conversation was a bit hard to follow, the group may need more structure to have discussion productively on the email list.
One perspective - it is not always clear what we have agreed to as a group.
Leadership response - working documents are regularly being updated to reflect ongoing conversations. All comments, those on the current calls and those previously made, need to be taken into account.
Leadership note - certain topics may require a sub-mailing list. This might not be required for all topics.
Proposed high level agreement - “The Working Group confirms 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; Therefore, all criteria for evaluation and testing (if applicable) should the same.” -- staff noted that if there is agreement of this high level principle, this may provide context for some of the concerns raised in the group.
If the only difference is a function of timing, leadership suggestion to group conversations about evaluation criteria into 2.7.7. Applicant Reviews and 2.11.1 Registry System Testing. Suggestion to create a small group to focus on these topics.
One perspective - it is not a function of timing, it is a function of marketing, so there is a consumer issue involved. Another perspective, the marketing angle should not be the focus of the conversation.
Concern raised - the conversation started as one for creating efficiencies for the applicant, reducing costs, and improving predictability, but the conversation has evolved into how to protect RSPs. Conversation should be refocused on the applicant, as was the original intent.
Under the proposed approach, there would be no ongoing contract between the RSP and ICANN, just as the case today.
Concern reiterated that if an RSP has failed, it should no longer be on the list.
Point reiterated that in 2012, if you were approved in the evaluation, and you later violated your SLAs, this was handled at the contractual level for the individual TLD. The proposed approach would be the same.
Regarding voluntary nature of the program, all comments but one support making the program voluntary. BC expressed divergence - supported mandatory program.
Leadership has started a list of pros and cons of a voluntary program. This can be fleshed out further if it is helpful.
Funding and program costs - leadership recommendation - “We declare policy of Cost-Recovery that the program is self-funding and direct implementation review team / ICANN Staff to determine costs”
Factoring in the number of TLDs an RSP intends to support - if a small group discussion is initiated on this topic, this would be an item for the small group. Leadership recommendation - “Implementation Review Team / ICANN Org should determine a mechanism to measure a potential RSPs ability to Scale to handle self declared number of TLDs, Domain Names, DNS Queries, RDAP Queries, etc. and provide responses as to how each RSP would increase scale to meet unexpected increases in volumes for the TLDs they support.”
Concern reiterated about the proposed agreement that the only difference between a pre-approved RSP and non-pre-approved RSP is timing.
NCSG comment does not agree with the high-level principle. Leadership recommends verifying with the NCSG if this is still the view given common understanding of how the program would work.
Reassessment of RSPs - leadership recommendation - . . . “On balance, it seems more logical to reassess prior to each round. If we ever do go to a first-come, first-served model, then we would need to revisit this.”
Clarification - there would only be a reassessment for the round before the round. It would not be periodic apart from the application cycle.
Suggestion to adjust the wording to ensure that it is clear that ICANN is not assessing the RSP over time. This makes it sound like an accreditation program.
Question for further discussion, does the RSP need to go through the full evaluation process before each round? Or might there be an abridged process in this case.
If timing is really the only difference between a pre-approved and other RSP, it would make sense to reassess before each round. This would give applicants the confidence in the RSPs they select.
Proposed principle - “The RSP Pre-Approval Program should treat incumbent RSPs and prospective RSPs in an equitable manner.” Comments in general did not support grandfathering for incumbent RSPs.
Request from one member to find out from ICANN org what ICANN does after an EBERO triggering event. This might help inform the discussion on reassessment.
Referrals section of the document -- proposes referring a number of comments to other sections, especially if you apply the principle that there is no difference between an RSP that is pre-approved vs. one that is approved during the application process.
Suggestion for an additional principle: “Pre-approval should be required for future rounds.” This can be discussed further by the group.
Leadership recommendation on scalability: “Implementation Review Team / ICANN Org should determine a mechanism to measure a potential RSPs ability to Scale to handle self declared number of TLDs, Domain Names, DNS Queries, RDAP Queries, etc. and provide responses as to how each RSP would increase scale to meet unexpected increases in volumes for the TLDs they support.”

b. 2.3.2 Global Public Interest – (see Foundational Issues - https://docs.google.com/document/d/15rwviHM6AYtqDqyB6_5Yij2dTL6iuou8z7A32yzc7sE/edit?usp=sharing)

Will be discussed next week.

4. AOB

None