2019-01-31 New gTLD Subsequent Procedures PDP - Sub Group A

Notes/ Action Items

Actions:

ACTION ITEM 1: 2.2.6.c.4: Line 43, Business Constituency -- Divergence: Should be mandatory for all RSP.  -- Request for clarification.

Notes:

1. Updates to Statements of Interest (SOIs): No updates.

2. Discussion of Public Comments: 2.2.6 Accreditation Programs

General Comments:

Line 4, GAC -- New Idea (though may not directly relate to RSP pre-approval as the WG preliminarily recommended using the same technical criteria) -- May be applicable to 2.7.6 Security and Stability and 2.7.7 Applicant Reviews

2.2.6.c.1: Summary: everyone agreed, but some new ideas/concerns

Line 11, RrSG -- Agreement New Idea (though may not directly relate to RSP pre-approval as the WG preliminarily recommended using the same technical criteria)

Line 12, NCSG -- Agreement, New Idea: As part of our consent to 2.2.6.1, the pre-approval process should be clear and transparent. The checklist from which ICANN Staff evaluates an RSP for pre-approval should be clear and its results published, along with the dates on which the review took place.

Line 13, LEMARIT -- New Idea (believes the term can selected once the process is determined)

Line 14, Google -- Agreement Concerns -- preference to incumbents

Line 15, MarkMonitor -- Agreement Concerns -- preference to incumbents

Line 16, ICANN org -- Concerns (or rather, request for clarification)

Line 17, Christopher Wilkinson -- Divergence (moved from General Comments)

2.2.6.c.2:

Lines 19-20, BRG and Neustar -- Agreement

Line 21, Valideus -- Agreement (including details of their understanding)

Line 22, NCSG -- Agreement New Idea Divergence (on the length of time)

Line 23, Business Constituency -- New Idea (on the length of time)

Line 24, ICANN Org -- In order to allow prospective applicants sufficient time to plan accordingly, the PDP Working Group might want to consider making the program available earlier so that there would be a number of pre-approved RSPs ready three (3) months prior to the opening of the application window for prospective applicants to select from.

Line 25, RySG -- New Idea Concerns

Line 26, LEMARIT -- New Idea Concerns Divergence (though this is in relation to the pre-approval process itself)

2.2.6.c.3:

Line 28, Neustar -- Agreement

Line 29, Brand Registry Group -- Agreement New Idea - example, may need to loop back and go through a further review if they go through an EBERO.

Line 30, Valideus -- Agreement New Idea

Line 31, NCSG -- Agreement Divergence New  Line 32, RySG -- Agreement Concerns (about data on RSPs being able to scale, as well as existing work already underway)

WG Response:

Line 33, Business Constituency -- Concerns (though preliminary recommendation 2.2.6.c.4 seems to answer their question)

-- May need clarity from the BC.

Line 34, ICANN Org -- New Idea Concerns (or more precisely, request for clarity)

Line 35, LEMARIT -- Divergence: The level of the registry operator support is relative to the Type of managed TLDs and should not be included as a criteria for a pre-approval. As we mentioned above the same rules and conditions should be applicable to all of the RSPs.

2.2.6.c.4:

Lines 37-40, Brand Registry Group, Neustar, LEMARIT, Valideus -- Agreement

Line 41, ICANN Org -- New Idea: Similar to the input provided in 2.2.6.c.3, to encourage innovation, the PDP Working Group might want to consider providing applicants with the flexibility to specify if they want to perform a service offered by the pre-approved RSP in a modified manner.

Line 42, NCSG -- Concerns: regarding point 2.2.6.c.4 The request here is contradictory and should be made clear and consistent.

Line 43, Business Constituency -- Divergence: Should be mandatory for all RSP. Specific criteria pertaining to providing registry services should be established and a mechanism in place to audit and track the criteria.

2.2.6.c.5:

Lines 45-47, Brand Registry Group, Business Constituency, Valideus -- Agreement

Line 48, Neustar -- Agreement Concerns: While we support the concept that RSPs should fund the pre-approval process in principle we believe that more detail is required to understand the costs associated with undertaken the pre-approval process.

Line 49, LEMARIT -- Agreement Concerns: Agree, but the entry fee should be reasonable low not to limit competition.

Line 50, RySG -- Concerns: Absent an understanding of how much it will cost to establish the pre-approval process, cost- recovery by the RSPs along may make the pre-appvoal concept unworkable as it may prove too expensive to participate. The cost to ICANN of PDT in the 2012 round is significant and the cost was recovered as a portion of the application fee. While the 2012 round anticipated a large number of potential RSPs the reality was that only 12 or so emerged.

2.2.6.e.1:

Line 52, Brand Registry Group: Agreement New Idea

Line 53, RrSG -- Agreement New Idea: Testing needs to be emphasized; use requirements must be addressed, and standardization between backends is needed. Additionally, if an RSP is planning to support a significant increase in TLDs, that should be reviewed.

Line 54, Neustar -- Agreement New Idea Concerns

Line 55, Valideus -- Concerns: but reiterate our point about equal treatment of RSPs and applicants.

Line 56, RySG -- Divergence: No. The pre-approval process is limited in scope to a technical review of competence. It is only an indication that an RSP can support the 5 core services for a single TLD. It is not designed to ascertain if the RSP is fit-for-purpose i.e.can the RSP support the specific business requirements of a TLD or TLDs that are being applied for. Such qualities are not tested or ascertained by the pre-approval process. For the avoidance of doubt, scale and scalability is explicitly not tested and not guaranteed by pre-approval.

Line 57, LEMARIT -- Divergence: No, it should not be taken into consideration as a RSP can not intend which and how many applicants it will support.

2.2.6.e.2:

Line 59, Brand Registry Group -- New Idea (see 2.2.6.e.1 for details)

Line 60, Neustar -- New Idea: At the conclusion of an application process and prior to commencing evaluation, the RSP could be asked to confirm its ability to support the number of applications.

Line 61, RySG -- Divergence -- It is not appropriate for the pre-approval testing to require specification of scale and nor should this be tested for in the pre-approval process. Scale being either the number of TLDs and/or the number of SLDs on a given RSPs systems. Scale and scalability is a business issue between the RSP and the RO / Applicant.

Line 62, LEMARIT -- Divergence: No, it should not be taken into consideration as a RSP can not intend which and how many applicants it will support.

2.2.6.e.3:

Line 64, Brand Registry Group -- Agreement New Idea (see 2.2.6.e.1 for details)

Line 65, NCSG -- Agreement New Idea

Line 66, RrSG -- Agreement New Idea: Yes, periodic reassessment should occur and be tied to the type/characteristic of gTLDs offered to ensure technical requirements for the TLD are being met.

Line 67, ICANN Org -- Concerns (or more precisely, additional considerations)

Line 68, Valideus -- New Idea Divergence (or more precisely, preference for reliance on SLA monitoring)

Line 69, Business Constituency -- Divergence (preference for ongoing testing)

Line 70, Neustar -- Divergence -- Divergence (or more precisely, suggestion for different mechanism than periodic testing - SLA monitoring)

Line 71, RySG -- Divergence: Divergence (or more precisely, preference for fixed approval time and reliance on SLA monitoring)

Line 72, LEMARIT -- Divergence (or more precisely, preference for fixed approval time and reliance on SLA monitoring)

2.2.6.e.4:

Line 74, Valideus -- Agreement

Line 75, RySG -- Agreement (or more precisely, suggestion that all RSPs should be treated the same)

Line 76, Business Constituency -- Concerns (or more precisely, suggestion that testing should be on the registry, or the contracted party)

Line 77, ICANN Org -- Concerns (or more precisely, additional considerations)

Line 78, LEMARIT -- Divergence -- an reassessment of not pre-approved RSPs doesn't make any sense, as the reassessment only regards the pre-approval status and not the general capability to service as an RSP.

2.2.6.e.5:

Line 80, Business Constituency -- Agreement (for pre-approval)

Line 81, XYZ -- Agreement (for pre-approval)

Line 82, RySG -- New Idea:  it is important to take into consideration and address characteristics of individual new gTLDs being offered by the RSP. Testing needs to be emphasized; use requirements must be addressed, and standardization between backends is needed.

Line 83, RySG -- New Idea: existing RSPs should be subject to the reassessment process as indicated in 2.2.6.e.3. Thus, an RSP that has been operating at least one of its TLDs for at least 3 years in GA and has not had any breach (or 80% SLA violation) in any of its TLDs during the last 5 years would be effectively (automatically) pre-approved.

Line 84, ICANN Org -- Concerns (or more precisely, additional considerations): ssess whether the changes and new requirements in preliminary recommendation 2.2.6.c.3 and Registry System Testing section of the Initial Report would necessitate existing RSPs to go through the new RSP pre-approval process.

Line 85, Valideus -- Divergence New Idea

Line 86, SSAC -- Divergence Concerns

Line 87, Neustar -- Divergence (or more precisely, suggestion that existing registries are subject to SLA monitoriing)

Line 88, LEMARIT -- Divergence: All RSPs should be treated equally as the next round does not necessarily have the same technical requirements and SLAs

Line 89, Google -- Divergence: he Working Group should avoid processes and structures that show undue preference to incumbent RSPs versus prospective RSPs. Programs should be equally available to incumbents and new RSPs provided that they are able to meet objective criteria established for the program.

2.2.6.e.6:

Line 91, Business Constituency -- New Idea

Line 92, Valideus -- New Idea