[Gnso-newgtld-wg] Correction - Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 19 November 15:00 UTC

Thu Nov 19 18:49:40 UTC 2020

Dear Working Group members,

Please see below the corrected notes (changes in red) from the WG meeting on 19 November at 15:00 UTC. 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/2020-11-19+New+gTLD+Subsequent+Procedures+PDP.

Kind regards,
Julie
==
Notes and Action Items:

Action Items:

Topic 6: RSP Pre-Evaluation<https://docs.google.com/spreadsheets/d/11HrbnRk2Sf5FvdOuynJyXfkLrzQAD1jkYpRyaAE1ctI/edit#gid=1688811020>

Row 10 – Thomas Barrett (Individual) re: Optional to name selected pre-approved RSP in application; Row 11 – IPC; Row 12 -- PETILLION Law Firm; Row 13 – GoDaddy Registry; Row 19 -- RrSG
ACTION ITEM: Send to the WG list the question of whether the recommendations should be updated to clarify that an applicant must select the pre-evaluated RSP and nominate them in the application.  Ask also if it should be disclosed, but confidential.

Row 18 – ICANN org re: Recommendation 6.2: Our understanding is that this would not replace pre-delegation testing (PDT) which tests the technical and operational infrastructure for each gTLD as a prerequisite for delegation.
ACTION ITEMS: 1) specify in more detail which of the elements are required at or around the time of delegation; 2) which elements only need to be evaluated one time and in the pre-delegation process.  We may not be able to be specific, so perhaps capture as a principle of streamlining for the IRT to work out the details.

Topic 27: Applicant Reviews<https://docs.google.com/spreadsheets/d/1YJJDm9mdmSssXav1P08Uhw6Ofyp0KtfTX8QSRChrVNI/edit#gid=1163822586>

Row 16 – ALAC re: “support a permissible level of differential treatment for applicants that apply for Applicant Support which should take into account comment on the question in Topic 17 Applicant Support in respect of whether the scope of financial support for applicants what quality for Applicant Support should be expanded to also costs associated with operating the TLD.”
ACTION ITEM: Add a clarification.

Row 17 – ICANN org re: states that “Evaluation scores on all questions should be limited to a pass/fail scale (0-1 points only).” It’s not clear why this implementation detail should be the subject of generally applicable policy binding on ICANN, and therefore ICANN org suggests recategorizing this Recommendation as Implementation Guidance.
ACTION ITEM: Change to Implementation Guidance.

Re: Implementation Guidance 27.18: Need to look at the language.  Need to define “default” more clearly and in connection with the 5 critical functions.
ACTION ITEM: re: Implementation Guidance 27.18: Define “default” more clearly and in connection with the 5 critical functions.

Topic 39: Registry System Testing<https://docs.google.com/spreadsheets/d/1YimiR8dKA2F76QO_36hfDRCFE7-l5syuQ2zAKSn5rH8/edit#gid=1163822586>

Row 12 – ICANN org

Recommendation 39.1:
ACTION ITEM: Include “and its supporting/subcontracted Registry Service Providers (RSPs).” That is to say, the registry system tests should demonstrate the technical capabilities of the registry operator or its supporting RSP, as required.

Implementation Guidance 39.5
ACTION ITEM: Clarify by rephrasing “tables that are pre-vetted by the community” to “reference LGRs.”

 Notes:

1. Updates to Statements of Interest: None provided.

2. Review draft Final Report Public Comments – to prepare see the links to the Public Comment Review Tool on the wiki at: https://community.icann.org/display/NGSPP/h.+Published+Draft+reports and review the following topics and comments:

Topic 6: RSP Pre-Evaluation<https://docs.google.com/spreadsheets/d/11HrbnRk2Sf5FvdOuynJyXfkLrzQAD1jkYpRyaAE1ctI/edit#gid=1688811020>

Row 10 – Thomas Barrett (Individual) re: Optional to name selected pre-approved RSP in application; Row 11 – IPC; Row 12 -- PETILLION Law Firm; Row 13 – GoDaddy Registry; Row 19 -- RrSG
Leadership Comments: Clarify whether recommendations require you to name the operator or just state that you have an operator? In the text of the recommendation we say that you have to say that you are using one, but not name it.

Discussion:
-- Couple of reasons why this should be mandatory (to name the operator): 1) If you have an applicant that is applying for 20 TLDs and you don’t name your RSP, that could be suspicious; 2) when ICANN org evaluates applications and testing with RSPs re: capacity to manage X number of TLDs, important to know how many TLDs the operator will be supporting.
-- If an applicant wanted to change its back-end provider prior to contract would that have to be an application change request, or could it be changed in contracting?  Could depend on what the change was – whether it was to another pre-approved RSP.
-- There is a benefit to confidentiality regarding an RSP.
-- It can still be a factor of consideration if applicants decide to identify their pre-evaluated RSPs voluntarily – if we have a factor about bona fide in the application.
-- Don’t put too much weight into having an agreement with an RSP as an intent to operate.  When you operate an agreement for one or 2 strings, maybe but when its for 10, 20 50 or 200, its a one time deal.

ACTION ITEM: Send to the WG list the question of whether the recommendations should be updated to clarify that an applicant must select the pre-evaluated RSP and nominate them in the application.  Ask also if it should be disclosed, but confidential.

Row 11 – IPC re: appeals mechanism allowing RSPs who are denied pre-evaluation status to request the reconsideration of the decision
Leadership Comments: We considered this during our Appeals discussion and for the following reasons did not adopt an appeals process: (a) Evaluators can ask clarifying questions during process, (b) the remedy for winning a challenge is to be re-evaluated which is what happens anyway during the evaluation period, (c) allotting time for an appeal could delay the commencement of the actual round for applications.

Row 14 -- InfoNetworks LLC
Leadership Comments: Perhaps rewording stating that the RSP as an RSP is not a contracting party, but if the RSP is a Registry Operator in another context, then it would be one for that other purpose.

Row 18 – ICANN org re: Recommendation 6.2: Our understanding is that this would not replace pre-delegation testing (PDT) which tests the technical and operational infrastructure for each gTLD as a prerequisite for delegation.
Leadership Comments: Confirm whether this would replace parts of pre-delegation testing.

Discussion:
-- Was part of the intent of the pre-evaluation was to replace a technical part of the evaluation as well as the need for PDT.
-- It was to replace part of the PDT, such as language tables and the ability to do EPP commands.
-- May need to delve into this a little more and clarify/confirm the PDT elements it would replace, and what it wouldn’t.
-- Not sure we can be more specific than that the pre-evaluation replaces “aspects” of the PDT.  Seems to be a judgement call involved here.
-- Question: So if PDT is required the RSP will need to be known at the time of submitting the application in order to complete the evaluation process, no?  Answer: It has to be known at the time of contracting.
-- An idea on PDT: perhaps it be done on a timeline basis that provides that an RSP is only required to submit to testing no more than once every three months and this will be decided by the PDT queue.

ACTION ITEMS: 1) specify in more detail which of the elements are required at or around the time of delegation; 2) which elements only need to be evaluated one time and in the pre-delegation process.  We may not be able to be specific, so perhaps capture as a principle of streamlining for the IRT to work out the details.

Row 18 – ICANN org re: Recommendation 6.5: We understand this Recommendation to suggest that once the registry service provider (RSP) is pre-evaluated, the pre-evaluation status will continue for the duration of the related application round even if substantial issues with the RSP are found during TLD operations. ICANN org seeks guidance on what conditions would allow for a “pre-approval” status to be revoked.
Leadership Comments: Just as today once a Registry is approved, there is no revocation, there would be no revocation of an RSP that was successfully re-evaluated.

Discussion:
-- But if new evaluation criteria appears, that could lead to an update of pre-evaluation.
-- Don’t know if there would be new evaluation criteria in the middle of the round.
-- Make it clear that an RSP needs to be pre-evaluated during each round.

Topic 27: Applicant Reviews<https://docs.google.com/spreadsheets/d/1YJJDm9mdmSssXav1P08Uhw6Ofyp0KtfTX8QSRChrVNI/edit#gid=1163822586>

Row 10 – GoDaddy Registry re: Require applicant to identify pre-approved RSP in application or delete Recommendation 27.14.
Leadership Comments: They were supposed to address their scalability in their application and ICANN has to be satisfied.

Row 11 -- Dotzon GmbH
Leadership Comments: Discussed that if you are an existing business on one of the financial markets you don't need the financial review, but they are suggesting a new criteria that is not consistent with what the Work Track said/or supported.

Row 14 – RrSG re: Include "streamlined application process".
Leadership Comments: That seems like a clarification. See if the WG agrees to include

Row 16 – ALAC re: “support a permissible level of differential treatment for applicants that apply for Applicant Support which should take into account comment on the question in Topic 17 Applicant Support in respect of whether the scope of financial support for applicants what quality for Applicant Support should be expanded to also costs associated with operating the TLD.”
Leadership Comments: ALAC comment makes a good point/clarification.

ACTION ITEM: Add a clarification.

Row 17 – ICANN org re: states that “Evaluation scores on all questions should be limited to a pass/fail scale (0-1 points only).” It’s not clear why this implementation detail should be the subject of generally applicable policy binding on ICANN, and therefore ICANN org suggests recategorizing this Recommendation as Implementation Guidance.
ACTION ITEM: Change to Implementation Guidance.

Leadership Comments:
-- Recommendation 27.5: WG addresses this. If public info then public question, if private then private.

Discussion: On clarifying questions: ICANN should have the discretion to redact information they consider confidential. I think the intent of the publishing the CQs was transparency and potentially giving other applicants a 'heads up'.

-- Recommendation 27.14: We are talking about scalability.
-- Implementation Guidance 27.16: Think we saying that we aren't telling you whether you have a good or bad business model, just how you would handle a business failure.  Don’t see the inconsistency with the Implementation Guidance.
-- Implementation Guidance 27.18: Need to look at the language.  Need to define “default” more clearly and in connection with the 5 critical functions.

ACTION ITEM: re: Implementation Guidance 27.18: Define “default” more clearly and in connection with the 5 critical functions.

Topic 39: Registry System Testing<https://docs.google.com/spreadsheets/d/1YimiR8dKA2F76QO_36hfDRCFE7-l5syuQ2zAKSn5rH8/edit#gid=1163822586>

Row 12 – ICANN org

Recommendation 39.1:
ACTION ITEM: Include “and its supporting/subcontracted Registry Service Providers (RSPs).” That is to say, the registry system tests should demonstrate the technical capabilities of the registry operator or its supporting RSP, as required.

Implementation Guidance 39.5
ACTION ITEM: Clarify by rephrasing “tables that are pre-vetted by the community” to “reference LGRs.”
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg/attachments/20201119/32f19eef/attachment-0001.html>