The call for the New gTLD Subsequent Procedures Sub Team – Track 1 - Overall Process/Support/Outreach Issue will take place on 06 February 2018 at 20:00 UTC for 60 minutes.
PROPOSED AGENDA
- Welcome & Agenda Overview
- SOIs
- Review of potential recommendations for Accreditation Programs (RSP Program) (4.2.8)
- Review of potential recommendations for Support for Applicants from Developing Countries (4.2.14)
- Next Meeting
- AOB
BACKGROUND DOCUMENTS
RECORDINGS
PARTICIPATION
Notes/ Action Items
1. SOI Updates: No Updates.
2. Review of potential recommendations for Accreditation Programs (RSP Program) (4.2.8)
See the document at: https://docs.google.com/document/d/1guiX3L0FQAd7ZpwYIJI4FdY3pv09u0EnHMAark84tmg/, page 19
-- Considered the policy question: was the repetitive, resource intentive technical evaluation and pre-delegation testing an interpretation of the rules -- a form of application rather than the fault with the rules themselves?
-- General Agreements: More detail will be needed in this section.
Discussion:
-- Footnote on accreditation - why we moved away from this term in favor of RSP Pre-Approval.
-- Pre-approval process: Said it would be largely consistent with pre-delegation testing, and only do that testing once.
-- Add the areas where we don't have agreement, i.e., intent was to say that whatever testing we apply in the next round should be those requirements that are tested and evaluated as part of this pre-approval process.
-- Discussion about grandfathering, but don't think we have agreement on that approach. Describe the concept.
-- How does pre-approval work when you have one registry service provider with multiple applicants and multiple schedule A filing -- do they go through multiple pre-delegation testing. Good to get public input on this.
-- Could be registries that have been pre-approved for a set of services.
-- Beside pre-approval, there should be some requirement for monitoring or statistical process control before registries reach an SLA, and a rapid response to threats.
-- There might be some assurances to registry operators when the want to transition from one back-end provider they goes smoothly, that there is a process in place where the losing RSP participates in the process.
-- One service RSPs could be required to provide is EBERO.
-- If an RSP has shown experience and meets SLA they should be given the presumption that they are capable of provide the service.
-- If there are new requirements in the next round there may be a need for approval.
From the chat:
Jim Prendergast: Im still not clear what the difference between accrediation and pre-approval are. An RSP still submits to testing by ICANN (or their designated 3rd party) in exchange for a designation (certified or pre-approved) How are they different?
Jeff Neuman: Everyone felt that the terms accreditation implied signing up to a separate agreement
Kurt Pritz: I dont like this footnote: “In the original charter, the term ”accreditation” was used as opposed to pre-approval. However, for the reasons discussed in the discussion section below, the terms “Accreditation” or “certification” were considered to be too politically charged and to many implied a number of elements which were unintended. After considerable debate, the terms “RSP Pre-Approval” or “RSP Program” were deemed less incendiary“ We should not turn away from an accreditation program for political reasons or because it is incendiary. We should state sound business / technical reasons for going away from accreditation and toward something else. Use of "political" and "incendiary" make s our reasoning sound less than sound.
Jeff Neuman: This does not envision a new agreement
Jim Prendergast: so the difference is a contract with ICANN?
Jeff Neuman: @Kurt - I agree we should give other reasons. It was one of the things I wanted to add to the General Agreements section
Jeff Neuman: Namely what the term accreditation implies (an agreement)
Vanda Scartezini: Kurt, I beleive you right
Kurt Pritz: Stop reading - just stick it in the record
Jim Prendergast: not everyone is in adobe
Christa Taylor: There was concern on the term 'accreditation' due to the implied certification/implications and the legalities around the diff parties
Cheryl Langdon-Orr (CLO): lengthy discussion on the nomenclature indeed
Jonathan Robinson: Agree with Jeff. We discussed this extensively
Jonathan Robinson: @Jeff. That is an interesting point. Will there be added or different technical requirements? If so, these may reflect real-world experience from the current 2012 round
Jeff Neuman: @Jonathan - I dont know
Donna Austin, Neustar: I agree, that we have not reached any agreement on grandfathering.
Jonathan Robinson: Not a question per se. More a recognition of the question to be determined.
Jeff Neuman: I am just accounting for the possibility that there may be
Jeff Neuman: That's why I dont want to just use the 2012 round as the base
Jeff Neuman: @Jim - That is a great question to solicit public input on
Jeff Neuman: in the initial report
Jim Prendergast: I dont have ideas - thats sort of why I asked the question
Jeff Neuman: @Jim - Neither do I (Thats why I punted back to you) :)
Phil Buckingham: a technical audit each year going forward ?
Jeff Neuman: I will note that the RySG has a document that has been going around but because it has not been approved by the SG it has not been submitted here yet. But some registries have made the point that if there are SLA breaches that those may be used against the pre-approval process. Again that is NOT a position of the SG, but an idea that was floated
Jonathan Robinson: @Kurt. Current experience does appear to show that ongoing monitoring is important
Jeff Neuman: @Kurt - Interesting - A pre-approved provider must agree to be an EBERO for any TLD that it supports
Maxim Alzoba (FAITID): if the RO fails, TLD goes to an EBERO
Ken Stubbs - Afilias: yes
Maxim Alzoba (FAITID): and I am not sure there is a process for EBERO to be non-operational
Kurt Pritz: If RO fails, the RSP is the EBERO
3. Review of potential recommendations for Support for Applicants from Developing Countries (4.2.14): Working Group members should review the document and provide feedback on the mailing list.