Dear Work Track members, Please see below the notes from the meeting today. 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 or transcript. See the chat transcript and recording at: https://community.icann.org/x/VAtyB. See the referenced document at: https://docs.google.com/document/d/1guiX3L0FQAd7ZpwYIJI4FdY3pv09u0EnHMAark84.... Kind regards, Julie Julie Hedlund, Policy Director Notes/Action Items from Work Track 1 Sub Team Meeting 06 February 2018: 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/1guiX3L0FQAd7ZpwYIJI4FdY3pv09u0EnHMAark84..., 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.