Page History
...
Tip | ||
---|---|---|
| ||
Attendance Apologies: Heath Dixon, Vanda Scartezini, Maxim Alzoba, Flip Petillion, Katrin Ohlmer |
Note |
---|
Notes/ Action Items 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. |