Dear Work Track Members, Please see below the action items and discussion notes from the meeting on 03 October. These high-level notes are designed to help Work Track Sub Team members navigate through the content of the call and are not meant to be a substitute for the recording. Slides are attached and excerpts from the chat room are included for reference. Kind regards, Julie Julie Hedlund, Policy Director Action Items and Notes, Work Track 1, 03 October Actions: ACTION: See if anyone on ICANN legal staff would see anti-competition concerns if RSP incumbents didn't have to go through testing. Notes: Review of CC2 responses to WT1 questions on RSP Program (continuation from Sept 19th call): The CC2 responses are available online at: https://docs.google.com/spreadsheets/d/1427pgTCkguOj2NZZzMnz_H_lPe54dtvUErSJ... 1.1.3 - Who should be responsible for evaluating whether an RSP meets the requirements of the program? (Slide 16) -- Comment by Afilias: Satisfied with the current program, nothing to suggest the evaluation process needs to change. -- Note that an RSP doesn't have a contract with ICANN, so this statement can't be achieved, "Compliance team should also be involved to confirm that all existing RSPs are meeting existing contractual compliance." 1.1.4 - Should there be an continuing obligations for approved RSPs, such as high-level requirements for accreditation? Should the requirements be variable based on the types of TLDs the RSP intends to serve or other factors? (Slides 17 and 18) -- Support and opposition for different requirements for specific TLD types from Nominet and the RySG. -- Additional input on Program requirements from Nominet, BC, BRG, and Valideus. -- Suggestion for improving efficiencies in place of accreditation program from Afilias. 1.1.5 - Should there be an Agreement between an RSP and ICANN? If so, what enforcement mechanisms should be made available to ICANN in the event that such an Agreement is breached? (Slides 19, 20, and 21) -- Opposition to an Agreement between ICANN and RSPs from CIRA, Jim Prendergast, ALAC, RYSG, Afilias, and Valideus. -- Support for an Agreement between ICANN and RSPs from Nominet and BC. -- Support for a limited Agreement from BRG. Discussion: -- See if we can tie some of these together to see if we have agreement. If you look at comments in support of an agreement between ICANN and RSPs, those seem to relate to an accreditation program. Not sure those would be the same if we are talking about a pre-approval program, rather than an accreditation or pre-certification program. Not sure if there is support for an agreement for a pre-approval program. -- One point that could be considered is if the program were in a steady state of first-come, first-served how would that play into pre-approval readiness?
From the chat:
Donna Austin, Neustar: so is our takeaway that no agreement is required between an RSP and ICANN? Ashley Roberts: Donna, I would agree with that. Ashley Roberts: Presumably the ALAC comment should refer to the RA rather than the RAA. 1.1.6 - What, if any, are the potential impacts (both positive and negative) of an RSP Program on ICANN Accrediated Registrars? If there are any negative impacts, what are ways in which those impacts can be mitigated? (Slide 22) -- Nominet, BRG, RySG, and Valideus all stated that if implemented correctly, there should be no impact on ICANN Accredited Registrars. -- Afilias noted no negative impacts and pointed to a potential positive impact. -- Registrar concerns raised during the RySG RSP Discussion in Johannesburg and still need to be addressed. Discussion: -- Re: the Registrar concerns -- Once you are certified you are in a pool of certified registries is a different type of program than we are talking about. We are talking about a pre-approval program (not a certification). In terms of this comment perhaps we can go back to the Registrars and ask that if we do a pre-approval does that address their concerns. -- The transfer to a new RSP is outside of our scope, we would hope that the registries are working on that process.
From the chat:
Rubens Kuhl: Initial testing during the 2012 round also did not test nexus information or post-registration activation. Richard Merdinger: I am satisfied with limiting the scope as Jeff recommended Richard Merdinger: My concerns are tmainly with the movement of domains between RSPs when TLD requirements differ Richard Merdinger: so if there does come a time that TLD moves to a new RSP that all testing as prescribed is done Richard Merdinger: One more comment...I hope further that the RrSG engages with the RySG to make thsi efficient as possible Donna Austin, Neustar: Rich, there is a WG that registrars can join. i'll send you the details. 1.1.7 - Should there be a process to reassess RSPs on a periodic basis? If so, how often should an assessment be conducted and what would the process be for re-approval? (slides 23 and 24) -- Support for regular audits from Nominet, BC, BRG, Afilias, and NCSG. -- Regular audits are not necessary -- Valideus and CIRA. 1.1.8 - If there is an RSP Program, how far in advance should such a program be launched prior to the opening of the next application window? (Slides 25 and 26) -- As soon as practical: CIRA, BRG, RySG, Valideus. -- Within 3-12 months: Nominet, BC, John Poole. -- When the AGB is complete: Afilias. 1.1.9 - Should there be an RSP application "cut-off" date to allow sufficient time for an RSP seeking approval in order for their application to be approved before the opening of an application window? (Slides 27-29) -- Support for a "cut-off date": BC. -- Support for no "cut-off date": RySG, CIRA, and BRG. -- Suggestions for timeframes: Valideu, BRG, CIRA. -- Program should be optional: Nominet. -- Proposal for process improvements without accreditation: Afilias.
From the chat:
Kurt Pritz: Important to the idea of a cutoff date is the requirement of a clear RSP application processing timeline that is always met 1.1.10 - If there is a list of pre-approved RSPs in any RSP Program, should there be a provision granted to organizations that act as an RSP to an existing delegated TLD? If yes, how would such a provision work? If not, could ICANN use an RSP's existing performance to satisfy any of the technical requirements and/or tests used in the approval process? (Slides 30-32) -- Established providers should be considered to meet the minimum qualifications of an RSP Program: RySG, Nominet, and CIRA. -- Follow the same Program requirements: BC and Google. -- Leverage information about the past performance of RSPs: BRG and Afilias. -- John Poole stated that it is up to "ICANN Technical" to decide. Discussion: -- If there are different requirements for the next round and ongoing, not sure how we can say that none of the existing providers would have to go through some form of the pre-approval process. ACTION: See if anyone on ICANN legal staff would see anti-competition concerns if RSP incumbents didn't have to go through testing.
From the chat:
Rubens Kuhl: If the new is a subset of the old, they can be different and still covered by the previous testing. Trang Nguyen: @Jeff, I think the answer to your question depends on the requirements for the RSPs under the approval program. I believe that Francisco previously provided some comments to WT4 regarding additional criteria for RSPs to enhance SSR. jeff neuman: I am not sure that I understand the Afilias comment jeff neuman: From a legal standpoint i am not sure it matters whether there are new requirements or not, but I would love to hear from ICANN legal 1.1.11 - If an RSP program is established, how should it be funded? For instance, should registries pay into the program, which will reduce related ICANN evaluation fees (and associated application fees)? (Slides 33-35) -- Charge RSPs participating in the program: CIRA, BC, BRG, John Poole, RySG, and Valideus. -- Charge new RSPs a fee; no/minimal fee for proven RSPs: Nominet. General Comments (Slide 36) -- Require RSPs to meet Standards in Extensible Provisioning (EPP) extensions, file formats, billing transactions, and Domain Transaction Type Name: RrSG. -- Reduced fees over time: Afilias.
From the chat:
Rubens Kuhl: The E in EPP stands for Extensible, so it will have different extensions... jeff neuman: This comment needs to get referred to WT 4