[Gnso-newgtld-wg-wt1] Notes and Action Items Work Track 1 Sub Team Meeting 06 February2018
Julie Hedlund
julie.hedlund at icann.org
Tue Feb 6 20:59:46 UTC 2018
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/1guiX3L0FQAd7ZpwYIJI4FdY3pv09u0EnHMAark84tmg/.
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/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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg-wt1/attachments/20180206/7c89190a/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4630 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg-wt1/attachments/20180206/7c89190a/smime-0001.p7s>
More information about the Gnso-newgtld-wg-wt1
mailing list