The next call for the New gTLD Subsequent Procedures Sub Team – Track 1 - Overall Process/Support/Outreach Issue will take place on Tuesday, 20 September 2016 at 20:00 UTC.
14:00 PDT, 16:00 EDT, 21:00 London, 22:00 CEST
For other times: http://tinyurl.com/gs9ehqt
PROPOSED AGENDA:
- Welcome
- SOIs
- Work Plan Schedule/Subject Area Prioritization (continued)
- Accreditation Discussion (continued)
- Application Support (if time permits)
- AOB
Apologies: Ashley Roberts, Jon Nevett , Christa Taylor
On audio only: none
Action Items/Discussion Notes
Notes and Action Items: 20 September 2016 - New gTLD Subsequent Procedures Sub Team – Track 1 - Overall Process/Support/Outreach Issue
1. Welcome
2. SOIs
3. Work Plan Schedule/Subject Area and 4. Prioritization (continued)
- Sara did a rough first pass at ordering categories and setting timeline, welcomes input (attached).
- Current schedule: Alternate Tuesdays, rotating 3:00 UTC, 15:00 UTC, 20:00 UTC.
- Sub team leads added timeline for community feedback to the overall timeline. The co-chairs have suggested providing 1-2 questions for CC2 or the group can send out its own request for community feedback.
- Sara created a working document for the group, available in Google docs to help guide discussion.
[Action Item: WG members are encouraged to add comments: https://docs.google.com/document/d/1KTHsQSjMSmutsY2WMmQG1DNsNp6cX7k4oQEwKveU338/edit?usp=sharing]
- Topics/Questions for Work Track 1 -- no initial feedback provided.
- The document originally had more background information. It is now more concise. Background information on each topic is available in the wiki.
- Avri Doria: this is a good approximation for the topics for us to work on.
5. Accreditation Discussion (continued)
- Sara Bockey: Task for today for the group: nail down terminology around accreditation program -- what are we looking to approve or certify them to do?
- Paul McGrady: Primary goal if we decide to go forward with it - streamline the process, cut down number of people ICANN needs to review an application, drive down costs, increase accessibility of the marketplace for more businesses and organizations, including those unable to apply in the first round due to costs.
- Jeff Neuman: We would be certifying that the provider meets or exceeds the technical requirements for the application process, so that applicants know there is a pool of providers that meet these criteria. We still need to determine those requirements.
- Paul McGrady: Is this beneficial to backend providers or just applicants?
- Jeff: It’s good for backend providers, too. They have certainty going in that they meet or exceed ICANN's requirements and can demonstrate this to applicants. Cheryl Langdon-Orr agrees.
- Sara Bockey: Question 4 asks whether we should differentiate between new and existing providers who have already been through this process.
- Jeff Neuman: Initially, he would require all backend providers to go through testing. He would not create criteria that go beyond those in the last applicant guidebook. It would be fair for everyone to go through the process at least once. Presumably it would be easy for existing providers to demonstrate they meet or exceed requirements.
- Avri Doria: Wouldn't we need to consider the need for a periodic re-check?
- Jeff Neuman: If this group determines that periodic checks are necessary, then yes. But maybe the periodic check can be satisfied by the fact that they are up and running, almost as more of an audit. Personal view: existing providers should not be treated differently from new providers.
- Kurt Pritz: The accreditation program could be different than the requirements in the applicant guidebook. The accreditation program could demonstrate not only that the provider can operate the registry in accordance with technical requirements, but could also be a guarantee towards resiliency and stability. The criteria could include multiples of capacity to resist DDoS attacks and could address the latest threat matrices. These requirements might change over time, so the providers would need to prove that they are up to date.
- Jeff Neuman: He likes what Kurt said. It would be good for the industry to have a check. But the fear is that ICANN is acting as a guarantor rather than certifying that providers meet minimum requirements. There is a risk of exposing ICANN to liability. If there's a way to do it that is voluntary or avoids having ICANN vouch for the providers’ capabilities, it’s a great idea. Maybe a third party could play a part in establishing the higher standard, or maybe this is left to the market.
- Kurt Pritz: Correct, we are trying to improve resiliency but not guarantee it.
- Laura Watkins: There are some concerns with the term “accredited,” as it has other connotations. Perhaps there is another more neutral term.
- Jeff Neuman: Agrees that this term has raised concerns on the mailing list, as it implies that you have a legal agreement with ICANN. He prefers to move away from this term and prefers to say that ICANN is certifying that the provider meets or exceeds requirements. Does the term "certify" also have connotations that may raise concerns? Cheryl Langdon-Orr agrees with Jeff.
- Sara Bockey: It sounds like we are talking about something between certification and accreditation. Certification is often a program to test and evaluate and accreditation is a formal declaration by a third party that the provider meets the standards. But what are the criteria we think are most important and who would perform the certification/accreditation?
- Jeff Neuman: We don’t need to resolve criteria now. One option is to make a policy recommendation that it meets or exceeds requirements, and then kick it out to an implementation group or get input from WT4. WT4 could have some recommendations regarding criteria. We do not need to agree upon the specific criteria within this group. We can talk about the processes and procedures as appropriate.
- Donna Austin: This is why we wanted to understand the problems we were trying to solve before we started talking about the solution. There may be more than one solution to the problems we believe accreditation or certification would solve.
- Kurt Pritz: Agrees that writing the criteria is an implementation issue. Vanda agrees, as well.
- Avri Doria: There may also be criteria that we would want to add regarding the capability to support multiple applicants. That might be a criterion we would want to add beyond basic pre-testing.
- Donna Austin: ICANN identified that the ability to test for multiple registry operators was a fail in the first round and something that should be remedied. For those RSPs that have been operating ROs from the first round they have been doing so in accordance with the requirements of the RA after going through PDT. There may be ways to adjust PDT to test for x number of registry operations and domains under management.
- Jeff Neuman: It would be possible to ask questions on capacity and scalability. There may be ways to make educated predictions based on responses to written questions. But it is hard to directly test that.
- Cheryl Landon-Orr: Do we need an action item to summarize issues for sub team 4?
- Jeff Neuman: If this sub team makes a recommendation on this issue, it would go to the full group and then be referred to sub team 4. No immediate action item needed now.
- Yasmin Omer: Has this group made a distinction between 1) a RSP demonstrating its ability to manage the critical registry functions (effectively what the application process was) and 2) the RSPs ability to actually manage the critical registry functions (what Pre-Delegation Testing was). Is the scope of this group limited to point 1 or does it extend to point 2?
- Jeff Neuman: At this point, the only recommendation we have agreed upon is #1 in Yasmin's comment, but #1 could include pre-delegation testing. Jeff wouldn't want to go much further, as #2 might create liability for ICANN.
- Paul McGrady: Is there a lesson to be learned from academia or health care regarding whether accreditation by a third party results in liability for the third party in the event that the accredited party does not end up being “up to snuff?” Could we dig around in some of these spaces?
- Jeff Neuman: The first thing that comes to mind is an auditor. An auditor will certify that you’re able to do what you said you could do, but not that what you can do meets a certain standard. They do this for same reason related to liability. Someone can do this research if they want.
- Donna Austin: As the entity responsible for security and stability of the Internet, isn't ICANN going to be liable if a registry fails or compromises SSR in some way?
- Jeff Neuman: He does not believe that it is the case with the certification process carefully designed.
- Laura Watkins: When we refer to the process of "Accreditation" are we inventing a new process for future rounds? Or was this something that took place as part of pre-delegation testing last time and the discussion is just about moving it to earlier in the process in the future?
- Jeff Neuman: The question gets to the heart of the criteria. We talked about this as a way to go through the process once instead of hundreds or thousands of time. It would be great to move the application process and pre-delegation testing process to being at the same point (to be required for approval). But we are not setting the criteria now. We first need to all agree on the policy.
- Sara Bockey: How would this program be funded?
- Jeff Neuman: He believes it should be strictly cost recovery funded by the RSPs.
- Donna Austin: This assumes one solution and I'm not sure this is a question we need to get into at this point. Katrin Ohlmer agrees.
- Jeff Neuman: If this is a program we agree on, this would be a voluntary program, on a cost recovery basis. We have to define what costs are included in cost recovery and make sure it doesn’t go beyond costs for administering the program itself.
- Avri Doria: Cost recovery is dangerous since that leaves so many costs up to interpretations. If we are going to say cost recovery, we have to be careful how we say it and specify what is included.
- Vanda: Agrees with Avri on costs.
- Katrin Ohlmer 2: The cost should be fixed.
- Cheryl Langdon-Orr: Fixed costs are ok where they are agreed and predictable.
- Jeff Neuman: Asked for clarification from Donna on the list regarding points raised in the chat. He wants to make sure that if they develop a proposal, everyone is behind it. Otherwise, it looks like the group is headed towards preliminary recommendations.
Steve Chan (Staff): Echoing Donna's comment, he suggests identifying and document the problem we are trying to solve and then come up with requirements.
[Action Item: Go back to notes about this topic in previous conversation including pros and cons identified by the Contracted Parties at the GDD Summit]
Jeff Neuman: We have had conversations about pros/cons/issues in the full group. Kurt also put out a paper on pros/cons.
Kurt Pritz: Here are some problems we are trying to solve: (1) the application process was clunky and repetitive w/o any benefit for the extra cost; (2) little in the existing PDT criteria serves stability and resiliency, i.e., capacity in excess of activity or addressing threats; (3) the process for R.O. switching backend providers in unpredictable;
6. Application Support (if time permits)
- This topic was not discussed
7. AOB
- none
