2019-06-03 New gTLD Subsequent Procedures PDP

Notes/ Action Items

Action Items:

ACTION ITEM 1: 2.2.6 Accreditation Programs (e.g. RSP Pre-Approval): Ask a clarifying question to the GAC re: GAC: New Idea - RSP Program should consider security threats and use tools such as ICANN’s DAAR to identify any potential security risks for an application.  Question from Jeff:  How exactly would DAAR be used for this purpose? DAAR looks at current activity within a particular string, not at the likelihood of security threats in future applications.

Notes:

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

Review of Summary Documents: 2.2.6 Accreditation Programs (e.g., RSP Pre-Approval) - (see - https://docs.google.com/document/d/1R4zXTH3hIgfbqoxyqsSp19Bl6J96NNeV7oCgxsXKD-w/edit?usp=sharing)

Outstanding Items:

General Considerations for Program Implementation:

-- GAC Comment - How would DAAR be used be used for this purpose?  Not an RSP pre-approval issue -- ACTION ITEM: Ask for clarification.

-- RrSG: New Idea - Program should take into consideration interoperability with ICANN-accredited registrars and there should be additional standardization of certain operational requirements.  Note from Jeff:  In discussion with Registrars at GDD Summit, they indicated that this comment was meant for all RSPs and not just those in the Pre-Approval Program. So to the extent that in general we adopt this requirement, it would be adopted for all RSPs.

-- NCSG: New Idea - The program should be clear and transparent. Supports public cataloging of receipts against RSPs, and investigation and response taken to the complaints, as well as a process for rejecting approved RSPs. Comment from Jeff:  Generally there are no compliance actions against an RSP, but rather against Registry Operators. How would this information be used?

Discussion:

-- The third-parties don’t have a contract with ICANN so don’t see how you could have a publicly available list.  Not sure there is any value.

-- Issues: 1) public cataloging of complaints; 2) Once you are on a pre-approved list how is a company removed and how is that communicated?  Focus on the second question.

-- Don’t think the pre-approval process would be public -- you are either on the list or not.

-- If we are going to talk about a mechanism to get a company off the pre-approved list, we should think about what is the point and what are the impacts.

-- Could indicate whether part of the question is not implementable.

-- The pre-approval is you are pre-approved or you are not. If you provide back end services for a registry operator and the RO breaches SLAs there will be consequences for the RSP, but those consequences are determined by the RO.


-- These are private contracts.  Mechanisms for un-preapproval don't really have a place.

-- The intent of the pre-approval is to overcome the repetitive nature of the technical evaluation experienced in the 2012 round.

-- There isn’t a concept of an “unapproved” RSP.  When we talk about RSPs and if they become “unapproved” that is a business proposition.  This isn’t a certification process, but you are qualified to do business in the accreditation program.

-- Maybe instead call them “pre-evaluated” RSPs.

-- QUESTION: Does RSP pre-approval apply regardless of the services to be provided in connection with a particular application or is the ability to meet the needs related to proposed new services part of the evaluation even if the RSP is Pre-approved?  QUESTION

-- What might be at issue here is what's the term of the pre-approval? It holds until the completion of the application and evaluation process. From then on the registry operator is responsible for meeting the technical requirements.

-- How is the applicant protected if there is a problem?

-- If there are new registry services proposed then there would need to be a new evaluation.

-- In terms of the applicant, one of the solutions could be if the applicant picked a RSP that had been taken off the list then the applicant could have time to pick another pre-approved RSP.  

-- On the EBERO and what it takes to get someone off the list, we haven’t agreed on that yet.  Not sure what process that would be.

-- The pre-approval holds until the completion of the application/evaluation process.  After that the RO is responsible for meeting the technical requirements.  Not sure how you would remove pre-approval.

-- Whether an RSP is on a pre-approved list or not: Should be that at a point in time this RSP has qualified against a standard set of questions and that this stands for a period of time.  There still would need to be monitoring by the RO.

-- Agreement on the need for more information from ICANN on the EBERO-triggering incidents.

-- This was supposed to provide efficiencies in the process.  This was never meant to be an accreditation.

-- Need to decide how long the pre-approval lasts and when another evaluation is required.

-- the assumption was that the RSPs would retain their quality for that period of time, subject to pre-delegation testing.

Timing of Program Launch:

-- Set up principles: 1) That applicants should be able to use the results of a pre-approval program should allow sufficient time for an applicant to be able to use the results when they are deciding to apply for a new string.

-- Not consistent with the comments of RySG -- the pre-approval is a condition for the next round.

Next meeting: Start with Factoring in the Number of TLDs the RSP Intends to Support.