[Gnso-newgtld-wg] Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 03 June 2019

[Julie Hedlund]

Dear Working Group members,



Please see below the notes from the meeting today, 03 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-03+New+gTLD+Subsequent+Procedures+PDP.



Please also see the referenced documents at:  https://docs.google.com/document/d/1R4zXTH3hIgfbqoxyqsSp19Bl6J96NNeV7oCgxsXKD-w/edit?usp=sharing.



Kind regards,

Julie

Julie Hedlund, Policy Director



Notes and 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:

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

2. Review of Summary Documents

a. 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg/attachments/20190603/d3b84a19/attachment-0001.html>