| A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z | |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
1 | Community Comment 2 | |||||||||||||||||||||||||
2 | Public Comment Review Tool | |||||||||||||||||||||||||
3 | ||||||||||||||||||||||||||
4 | 1.1 (Registry Service Provider) Accreditation Programs | |||||||||||||||||||||||||
5 | # | Comment | Contributor | WG Response | ||||||||||||||||||||||
6 | 1 | [Voluntary and can use own RSP] As currently envisioned by the WG, such a program would be on a voluntary basis and would not preclude the approval of a Registry Operator’s acting as its own RSP or the approval of additional new RSPs. | Nominet | |||||||||||||||||||||||
7 | 2 | [Efficiency and security through accreditation program and testing] Efficiency, security, and stability are principles that must be guaranteed, therefore we strongly believe in the (a) accreditation processes for the Registry Service Providers (RSPs), (b) periodic evaluations for the RSPs in order to see if they meet the requirements of the program, and (c) the importance of creating a process through which to continually and consistently reassess the approved RSPs on a periodic basis. | NCSG | |||||||||||||||||||||||
8 | 1.1.1 - Benefits and risks have been identified by the WG as provided above in the Context section. What additional benefits or risks do you see in implementing such a program? Are there other considerations that need to be considered? | |||||||||||||||||||||||||
9 | 1 | [Notes additionally that discount should apply if applications using same RSP] As the goal of such an “accreditation of RSPs” mechanism seems to be to lower costs for applicants and to decrease the administrative burden of applying for a new gTLD, as well as to grant applicants a certainty that their application will pass the evaluation, I recommend simply to allow for applicants to request that their applications (in case they have more than one) be evaluated in one work stream (if all are with same RSPs). ICANN should grant a significant discount in application fees in such cases. In the application guidebook (or similar guidance in the next application phase) ICANN could link to a list of current RSP providers. Then the applicant would of course still risk that an RSP currently operating a new gTLD would not qualify in the next round, however the risk of a “race to the bottom” or the risk of any ICANN liability issues related to “accrediting” RSPs would be avoided. Also, the entry barriers to new RSPs – who may otherwise be perceived as “too expensive to choose” would also be reduced, although still of course in a less favorable position. De Facto RSPs not currently operating a new gTLD/Legacy TLD/ccTLD would still face the same challenge (and such a list of current RSPs is not that difficult to find) | Jannik Skou | |||||||||||||||||||||||
10 | 2 | [Current EBERO maybe not be needed RSP accreditation] We would suggest approved RSPs have their own version of "EBERO" in their pre-validation process/accreditation and remove that as part of the Registry Agreement altogether if a "known"/prevalidated registry service provider is used, thus removing another redundancy double-checking per-application, if not removing the COI, EBERO, Data Escrow entirely as per answer 2.3.1. The reason to single out EBERO under the RSP model is they are generally acting as RSP for multiple registry operators and if the technical registry backend were to fail there is no call for having multiple separate agreements with each registry operator as that would only make things more difficult. | Demys | |||||||||||||||||||||||
11 | 3 | [Increase competition, reduce prices] The establishment of a Registry Certification program, through which a potential registry services provider (RSP) could pre-qualify as meeting the programs technical requirements, has the potential to significantly improve the participation in any subsequent new gTLD process and we strongly support it. Such an approach would increase competition amongst RSPs thereby encouraging efficiency, stimulating innovation, disciplining prices and providing much needed transparency and clarity to potential applicants on what registry costs will be. This would free applicants to focus on their own business plans and market innovation. This would be of particular benefit to groups who might have less experience in the industry, allowing them to put proposals together without the need to have often expensive technical advice. This could be of particular benefit to applicants from underserved regions. This will also reduce overall program costs for ICANN and applicants, as it will obviate the need for RSPs to be certified multiple times. Most important is the notion that an RSP should need only complete a certification process once regardless of the number of strings they may ultimately support. We have provided some additional commentary in response to selected specific questions below. | CIRA | |||||||||||||||||||||||
12 | 4 | [Could improve efficiency in processes, conditional support if it streamlines process] Having experienced first-hand the multiple repetitive testing required for identical or very similar processes during round 1, we agree with the observation that this introduced unnecessary delay, cost and operational bottlenecks. Whilst we appreciate that these processes were designed in good faith in order to maintain technical and operational stability in the DNS, we believe that they also created risk by extending the timeframe of the whole program and introducing many complications. Contrary to ICANN’s mission, the barriers to entry created by these lengthy and complicated processes in fact reduced choice and competition, particularly in the secondary market for registry services provision and for subsequent rounds. It should be possible to make this much better in future. We therefore see the benefits of having a lighter touch regulatory regime for established providers with an exemplary track record, for example a waiver from pre-delegation testing (PDT) or material subcontracting changes where the provider’s exact same processes have already been thoroughly checked and audited by ICANN within the past 12 months. Having followed the discussions of the PDP WG we do however understand the concerns voiced that an accreditation or certification scheme would in practice add additional layers of bureaucracy, reduce any incentive to raise standards and in fact act as an unintended further barrier to competition or operational excellence. So, our support for any such scheme would be conditional on the outcomes of such a scheme actually reducing red tape and streamlining the current processes. In addition, we agree with the WG comment that accreditation should be optional, not mandatory, and applicants should have the option to use a non-accredited provider following the existing procedures for PDT etc. | Nominet | |||||||||||||||||||||||
13 | 5 | [Some RSPs having trouble meeting SLAs, other ways to gain efficiencies] As I have mentioned in WG calls, I do not believe there should be an accreditation or pre-approval program. It has recently come to light that existing registry operators and their RSPs for the 2012 round continue to have challenges meeting the existing SLAs in the Registry Agreement. This results in ICANN having to intervene, but not trigger EBERO, to provide consultations on how to come into compliance. It proves that even once a RSP is “approved” or accredited by ICANN, issues do arise and that necessitates ongoing testing by ICANN to ensure RSPs are performing at adequate levels. See this presentation from ICANN that outlines the problems they are seeing from their monitoring. https://www.icann.org/en/system/files/files/presentation-slam-13may17-en.pdf Now this does not preclude the need to find efficiencies in the program, such as eliminating the repeated testing of identical registry set ups (identical meaning same deployment with exact Schedule A of registry services) or finding a way to ease the switching of back end providers. But that is completely different than a precertification or pre-approval program. For applicants looking for a “level of comfort” in their choice of RSPs, that is not something ICANN should be in the business of providing. For ICANN to provide a Good Housekeeping-like seal of approval is beyond their mission. Differentiation in the marketplace happens in many forms, including previous experience in running a registry. | Jim Prendergast | |||||||||||||||||||||||
14 | 6 | [Supports, as it would improve efficiency. Must maintain security and stability] The BRG supports the concept of a RSP program which can remove unnecessary duplication, improve predictability, streamline the process and reduce the time through post-application to delegation. However, the criteria must be set at the appropriate levels (which may differ across the different registry models) and administered in a manner which does not introduce risks to security and stability or create a barrier to new entrants or competition. For example, any RSP that has exceeded the emergency thresholds and the EBERO was initiated should be disqualified from any RSP program and be required to undergo full evaluation. There would also be benefits beyond the application process, whereby a RSP program could streamline the process for assignment changes. | BRG | |||||||||||||||||||||||
15 | 7 | [Not ready to establish a minimum level of service, given various business models] Afilias agrees that there are process efficiencies to be gained in the technical component of the application process and agrees that this could provide additional options to an applicant. However, this is vastly different than providing an accreditation program. The primary benefits of process efficiencies would be reducing the duplication of work on the part of a registry service provider and the application review time perceived by the applicant. Neither of these align with the primary benefit of an accreditation program: establishing an appropriately high, minimum level of service. The risk inherent in a “minimum level of service” is the assumption that all registries, or TLDs, are the same, even at some baseline level. One goal of the new gTLD program was to promote innovation, new models and programs for domain names. Afilias does not believe that this first new, expanded round is sufficient to establish a foundation for a minimum level of service that should automatically apply to all new, subsequent TLDs. The vast variety of business models and proposals for new gTLDs makes this self-evident. | Afilias | |||||||||||||||||||||||
16 | 8 | [RSP Program would promote efficiency and not result in race to the bottom] Identify opportunities to streamline repeat processes for applicants for multiple gTLDs and Registry Service Providers. We believe that many of the topics raised with respect to technical evaluation are not matters of policy and would be better addressed through a parallel implementation review track led by ICANN staff with community consultation. However, in response to the questions posed by the Working Group we agree that there were overall inefficiencies in evaluation and testing procedures, as well as in application systems that created undue work and financial burden for multiple-TLD applicants and Registry Service Providers (“RSPs”). There is little benefit to having evaluators review multiple sets of identical technical documentation as part of Initial Evaluation, nor to carry out a pre-delegation test for each TLD an applicant launches, where there are no differences in the TLDs’ proposed registry operations that could have implications for the test. Further, testing these TLDs individually is not a meaningful way to measure scalability of a registry. A better approach is to identify service level expectations related to scalability, and have a mechanism for notifying the registry and, potentially, initiating additional tests once the platform reaches identified thresholds. We are generally supportive of the proposal to create an RSP Accreditation Program to improve efficiency for RSPs and applicants alike, and disagree with the notion that such a program would create a “race to the bottom.” Beyond operational efficiency we believe that an RSP Accreditation Program could help bring competition to the market for providing registry services by providing a well-defined path into the business for potential RSPs and at the same time providing greater certainty for registry operators that a given RSP will be accepted by ICANN. Just as the introduction of a streamlined accreditation program dramatically increased competition in the provision of registrar services beginning in 1999, the PDP should resist calls for unnecessary or overly burdensome restrictions on RSPs, or for ICANN endorsements based on incumbency in the space. | ||||||||||||||||||||||||
17 | 9 | [Existing RSPs should qualify. Need to avoid race to the bottom] We support the notion, for the purposes of providing process efficiencies for applicants and ICANN in future new gTLD rounds, that there is value in establishing a pre-approval process for Registry Service Providers (RSPs) independent of the next new gTLD application process. We do not believe that standards for providing registry services should change as part of this pre-approval process; RSPs that have been through technical evaluation and monitoring as part of the 2012 application process should be considered to meet the minimum qualification under any RSP program provided that such RSPs have not undergone an emergency transition of the registry, and continue to perform in accordance with the service levels set in the Registry Agreement. Future applicants could engage any RSP from the existing pool and would not be required to undertake any evaluation or testing by ICANN to substantiate their credentials as an RSP. We are sensitive to the use of the term RSP Program and consider RSP Pre-Approval Process to be more appropriate. For the purposes of the remainder of our responses, RSP Program is read as Pre-Approval Process. A key risk to deal with, or mitigate, is the potential “race to the bottom” identified in the Context. This is particularly so when the use of terms such as “program”, “accreditation” or “certification” are used since such terms imply a form of guaranteed or certified performance or reliability when in fact, what is being tested, is a minimum acceptable performance. Testing identifies a minimum performance level at which satisfactory operation may occur. More strongly institutionalizing a minimum performance level in the form of an accreditation or certification could set too low a benchmark when security, stability and registry performance are best served by the market exceeding the minimum performance level. Being able to operate at a minimum level is a useful test to subject service providers to but it does not certify or guarantee that an operator will be able to continue to operate effectively regardless of domains under management or other changes in circumstance or environment. Therefore, the focus of any such pre-approval process should be for ICANN to ensure that a minimum standard for operation is set, consistent with that set for the 2012 new gTLD round, but that should not necessarily be construed or communicated in any way to be a certification or accreditation by ICANN. Rather it is a minimum satisfactory performance to operate. That way, there is neither a barrier to competition by new entrants nor an artificially low standard benchmark of operation for the registry service providers. ICANN is not in the business of certifying operators in the entire value chain. If it were, then consideration would have to extend to certification of registrar resellers, DNS providers and others. ICANN could readily improve efficiency by improving operations and not repeat testing registry service providers for exactly the same function across multiple registry operators. Such an approach likely would be far more fruitful than introducing a new form of contracted party via certification or accreditation. | RySG | |||||||||||||||||||||||
18 | 10 | The At-Large Community is generally dubious of the value of ongoing expansion in gTLDs, given that the benefit from the previous round is yet to be proven. Documentation provided to the CCT-RT suggests that gTLD expansion actually exerts a negative effect on Internet users (that is, suppliers of Internet-based services and the end-users who partake of these services). As such, the internal relationships between contracted parties and their service providers is of relatively little import to Internet users. | ALAC | |||||||||||||||||||||||
19 | 11 | Benefits: a. The primary purpose and benefit of an RSP Program would be to increase efficiency in the TLD application, evaluation, and PDT processes by limiting the need for multiple submissions and evaluations of the same technical answers, and multiple PDTs for the same RSP. b. It would speed up the overall process time for an application by moving evaluation and PDT testing to before the application window opens, and by likely reducing the number of Clarifying Questions issued. c. By eliminating multiple evaluations and PDTs of the same RSP it would, by definition, remove inconsistency among results for the same RSP (as was experienced in the 2012 round). d. It would increase predictability for both applicants and RSPs: it would allow applicants to know prior to the submission of their TLD application that their chosen RSP would meet ICANN’s technical criteria; RSPs would be able to offer the same assurance to potential clients when seeking their business. e. By increasing efficiency of evaluations it should naturally lead to lower application costs (assuming a cost-recovery pricing model). In 2012 approximately $60,000 of each application fee covered evaluations, of which a substantial amount was allocated to technical evaluations. If only one of these evaluations is performed per RSP – rather than one per TLD – the total application fee per TLD should decrease. f. A properly designed approval process could also remedy flaws in the evaluation process by testing the ability of RSPs to scale. Challenges: a. Some have argued that having a pre-approval process will lead to a “race to the bottom” in technical standards as RSPs will only shoot to meet the minimum requirements and not innovate. Moreover, this race to the bottom will cause their services to be commoditized and ultimately threaten the security and stability of the Internet. However, it is not clear why setting minimum standards would stifle innovation or threaten security and stability. It ignores the fact that minimum technical standards have been in place for the 2012-round TLDs with no evidence of a lack of innovation or of threats to the security and stability of the DNS. In fact, these are the same arguments that AT&T made in the 1990s and early 2000s to against cell phone portability. Yet in that case the evidence has shown that services have greatly improved for consumers, prices have dropped substantially, and competition amongst new providers (Sprint, Verizon, Leap/Cricket) has greatly increased. b. The argument that setting a minimum set of technical standards will lead to an overall degradation of standards is built on the misconception that the RSP Program is somehow looking to change the current (2012-round) technical standards; it is not. The RSP Program is simply about process and making it more efficient. Any pre-approval of RSPs would need to meet with whatever technical standards are agreed by the ICANN community as being required for ROs (whether that be the current standard or some other agreed standard). c. Another argument that has been made charges that an RSP Program would create a contractual relationship between ICANN and RSPs, thus creating a new set of contracted parties within ICANN. To be clear, it does not follow that an RSP Program would require a new contractual relationship between ICANN and RSPs, and we do not agree that one should be created (see 1.1.5). Other Considerations: Our view is that in addition to the selection and evaluation process of RSPs for subsequent application windows, such an accreditation, certification or pre-approval program for Registry Service Providers (RSPs) would provide equal benefit if applied retroactively to current Registry Operators in transitioning from one RSP to another. Background: a. Section 7.5 of the Registry Agreement (RA) states that a change of a Material Subcontracting arrangement, which includes the change of any subcontractor providing one or more Critical Functions for the registry, must obtain ICANN’s consent. b. ICANN has created a bureaucratic process through an “Application for Assignment Form” where Registry Operators seek consent from ICANN to change RSPs. c. There is a lack of transparency with ICANN’s evaluation process both in terms of timing and requirements. d. Anecdotally, irrespective of who the gaining RSP is, the evaluation has been lengthy and incurs fees, estimated by ICANN to be $5,000 for a technical evaluation, even when moving to an existing RSP that operates other TLDs. e. Once approval for the change is received, there is also a requirement for the equivalent of pre-delegation testing of the RSP, again irrespective of who the gaining RSP is and how many TLDs it already operates. Benefits: a. All of the above makes the exercise of changing RSPs time consuming, costly and inconvenient. Reducing the time and financial costs when switching RSPs by means of some form of pre-approval process would be expected to assist in increasing competition between existing back-end RSPs. b. In the case of a Registry Operator with multiple TLDs, it would reduce the overall costs paid to ICANN (if not eliminate the costs) of switching RSPs. Currently ICANN charges $4,500 - $5,000 per TLD to Registry Operators that want to switch RSPs. In the case of a Registry Operator that has 50 TLDs, for example, this could cost up to $250,000 (a huge impediment to switching). If there is a list of pre-approved RSPs, ICANN could automatically approve such transfers without any cost (or at a much more reduced cost than currently). | Valideus | |||||||||||||||||||||||
20 | 1.1.2 - If an RSP program is established for new gTLDs, do you have any suggestions for some of the details or requirements of the program? For instance, how would the scalability of the RSP be measured across a variable numbers of registries? | |||||||||||||||||||||||||
21 | 1 | The process in Round One did not consider scalability as part of the evaluation process. In our own experience, this has not proven to be an issue. We would support keeping the evaluation criteria as close as possible to the original testing requirements to ensure a level playing field for potential players which would suggest not adding additional elements for scalability. It is understood however that each Registry Operator is obligated to meet specific performance targets that clearly will ultimately fall under the purview of the RSP. ICANN, through its contracted monitoring requirements are able to monitor and assess performance and may take remedial action when and where required per the Registry Agreement (RA). One specific suggestion is to allow divorcing the application process from the requirement to have a specific RSP identified in your application. Instead, applicants would have the option to select a certified RSP only in the event their application is approved. This reduces the workload on potential RSPs not needing to be involved with applications which may never be awarded and allows applicants to have a more certain business case to present to potential RSP providers when seeking their services. Freeing applicants from the need to identify a specific RSP at the time of their application would allow them to concentrate their energy and resources on developing innovative business models, and potentially reduce the overall cost of participating in the process, thereby encouraging more applicants. | CIRA | |||||||||||||||||||||||
22 | 2 | Any RSP program should pre-certify the service provider’s capacity to handle a certain number (or tiers) of new gTLDs, with a ceiling to the number of domains under management. This assessment would be based on the RSP’s infrastructure, management track record, financial stability and resources. An existing RSP should be trusted to be a competent provider to new gTLDs without further testing within this certification, with re-certification required on a periodic basis or when any ceiling/ tier is reached. As above this should not be a mandatory scheme, but should be an optional process for established providers to achieve a waiver from the majority of the duplicative technical checks required as part of the applicant evaluation process. | Nominet | |||||||||||||||||||||||
23 | 3 | The BC suggests creating a certification program for entities that would like to participate in the new gTLD program as a Registry Service Provider. This would require that the certification be audited on a regular basis and should include auditable information on security measures and scalability capacity of the RSP. | BC | |||||||||||||||||||||||
24 | 4 | ICANN should leverage the qualifying criteria and pre-delegation testing used in 2012 round, combined with the output of any subsequent reviews undertaken and lessons learnt. An understanding and appreciation of different models should also be considered to determine different thresholds that can be applied. For instance, new models that do not depend on selling or distributing domains to third parties may have lower thresholds applied, particularly where the domains are controlled by the registry operator and their affiliates. As a single RSP grows in terms of the number of registries it supports and/or the result of significant growth within those registries, these aggregate changes should also trigger a re-assessment, as this may create additional risks, particularly as a single point of failure. | BRG | |||||||||||||||||||||||
25 | 5 | An RSP program - not a pre-accreditation program - that focused on requirements to improve process efficiencies could be appropriate. For example, rather than repeating a technical test the detailed results could be passed forward from one application review to the next application review. The review team could then evaluate whether or not the current application had essential differences that needed additional technical testing rather than blindly assuming it was required. There are details about when to “renew” a test that would need broad discussion, but the fundamental requirement of eliminating the duplication of work would be met. With respect to measuring scalability, there is no single test for measuring the scalability of an RSP. On the one hand, all RSPs could be scaled since they are limited only by the amount of investment they make (or are willing to make) in actual infrastructure and experience they have in operating a large infrastructure. On the other hand, this past round of applications has empirically shown that not all registries require the same infrastructures to succeed. An application review team should consider the scalability needs of each application on its own merits, and apply testing accordingly. Similarly, the operational experience of existing RSPs through the mandatory reporting already provided to ICANN could be summarized and more conveniently made available to the Internet community, especially registry operators, to assist in the evaluation of potential registry service providers. | Afilias | |||||||||||||||||||||||
26 | 6 | Proposed RSP program. While the RrSG welcomes innovation and we have seen multiple new business models come out of the current nTLD program, the RrSG encourages ICANN to concurrently consider the importance of standardisation for the domain industry. The RrSG recommends that Standards in the future should be required of RSPs in aspects such as Extensible Provisioning Protocol (EPP) extensions, file formats, billing transactions and Domain Transaction Type Name. This will ultimately reduce operational costs and consequently reduce end user fees. | RrSG | |||||||||||||||||||||||
27 | 7 | We reiterate our comments from 1.1.1 above regarding the term RSP Program. It would be beneficial to review the process used by ICANN to test or establish the technical capability of applicants in the 2012 round of new gTLDs. For example, were the technical 1 questions and the answers a good indicator of the technical capabilities of the applicant? Was the pre-delegation testing (PDT) undertaken valuable in testing/examining the actual technical capability of the applicant? If not, what improvements or enhancements could be made to either the technical questions or the PDT to more accurately assess technical competency to run a registry? Given that, to our knowledge, no applicant, and by extension no RSP was deemed to fail the evaluation of the technical aspect of the application including PDT; and that since the delegation of more than 1000 TLDs has not seen an emergency transition, it is reasonable to conclude that the design of the technical component of the application is adequate and as such is a good starting point for an RSP Pre-Approval Process. The ability of an RSP to scale across a number of TLDs or domains under management is difficult to assess in any Pre-Approval Process. We note that this not currently done for the RSPs supporting the 2012 round of new gTLDs and nor is there any data or evidence, after a number of years of operation, to suggest that the ability of an RSP to scale is problematic. The RySG is actively engaged in discussions with GDD staff on this issue and we recommend that the PDP WG defer to the work of this group. | RySG | |||||||||||||||||||||||
28 | 8 | While At-Large does not see any benefits from the further expansion of new gTLDs into the domain system, benefits could be achieved by the proposed programme to develop and enhance the technical and knowledge capacity of RSPs, especially for underdeveloped economies. In order to achieve the objectives of the GNSO recommendation there is a dire need for high level technical capacity building as well as ensuring that applicants have the appropriate operational management knowledge, skills and understanding required to run a successful registry operation. Training and preparedness even for the preapproval and the Pre-Delegation Testing must be a prerequisite level of entry for entrants as RSPs from underdeveloped economies considering such a venture. There would be value in ICANN providing such capacity development support covering all the appropriate criteria requirements for a RSP. Having an external regulatory body would also ensure that RSPs in developing regions especially, met the minimum standards for redundancy, capacity, monitoring, reaction time to threats, reporting and statistical process controls. In developing regions, monitoring and support to ensure that these standards are maintained by a regional regulatory body, perhaps under the auspices of ICANN, to regulate the performance of new RSPs and ensuring consistently high level of technical and governance processes. | ALAC | |||||||||||||||||||||||
29 | 9 | From a process point of view, at the time of seeking pre-approval, an RSP could state that its system can scale for up to XX number of TLDs (which could be based on estimated demand). They could then be evaluated, tested, and pre-approved based on this number. If they subsequently wish to scale for a higher number of TLDs then this would warrant an additional test by ICANN. | Valideus | |||||||||||||||||||||||
30 | 1.1.3 - Who should be responsible for evaluating whether an RSP meets the requirements of the program? | |||||||||||||||||||||||||
31 | 1 | The model in Round One worked well from an overall evaluation perspective. The selection of the testing provider was completed by a competitive process and the resulting platform worked well. We are not aware of any issues that resulted from this approach. Given that it is already well understood by the registry community, it would help to streamline the subsequent process were it to remain unchanged. Overall, we see no reason for that element of the program to change. | CIRA | |||||||||||||||||||||||
32 | 2 | We don’t see any option other than that ICANN should be responsible for such evaluations. | Nominet | |||||||||||||||||||||||
33 | 3 | ICANN should be responsible. | BC | |||||||||||||||||||||||
34 | 4 | ICANN should use the same provider for performing both the technical evaluation of a gTLD application and determining if aa RSP meets the program requirements. | BRG | |||||||||||||||||||||||
35 | 5 | Afilias is satisfied with the current program using contracted third parties to conduct the technical reviews. Additional guidance in support of process efficiencies would be necessary. The ICANN Compliance team should also be involved to confirm that all existing RSPs are meeting existing contractual requirements. | Afilias | |||||||||||||||||||||||
36 | 6 | ICANN used independent evaluators during the 2012 round to assess the answers provided to the technical questions and engaged an independent contractor to conduct the PDT. There is nothing to suggest that this needs to change. | RySG | |||||||||||||||||||||||
37 | 7 | See response to 1.1.1 | ALAC | |||||||||||||||||||||||
38 | 8 | In the 2012 round ICANN outsourced the evaluation and PDT to third parties. We see no reason why this should change, with the proviso that quality and consistency of both the evaluations and PDT is maintained. | Valideus | |||||||||||||||||||||||
39 | 1.1.4 - Should there be any 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? Please explain. | |||||||||||||||||||||||||
40 | 1 | There should not be any continuing obligations as such, other than as above periodic (annual?) audit for re-certification and tier changes should an RSP take on more TLDs or experience an significant increase in the total number of domains administered. Existing contractual SLAs and reporting for registry operators would presumably continue to be required with the Registry Operator as the primary party responsibility for compliance. However breaches of these where the RSP is at fault would be taken into account and potentially trigger a periodic audit being brought forward. Clearly the security and stability requirements for closed .BRAND new gTLDs will be of a lesser degree than open new gTLDs where the failure of a TLD (for whatever reason) will impact individual/ business registrants. Arguably a closed .BRAND new gTLD should not be subject to technical performance SLAs. | Nominet | |||||||||||||||||||||||
41 | 2 | There should be a minimum set of requirements that an RSP must comply with, but ICANN should encourage RSPs to exceed minimum requirements in order to compete in meeting the needs of their customers. | BC | |||||||||||||||||||||||
42 | 3 | As above (1.1.2) an understanding and appreciation of different models should also be considered to determine different thresholds to be applied. New models that do not depend on selling or distributing high volumes of second-level domains to third parties will have less impact on capacity requirements and lower thresholds could be applied, particularly where the domains are controlled by the registry operator and their affiliates. Consideration of scalability should be included on an ongoing basis, whereby the aggregate of the RSP operations may introduce risks that will not be identified against an individual registry operation the RSP supported. Reviews may also be prompted at the time of any significant change, such as the switching of significant or multiple registry operations to a specific RSP. | BRG | |||||||||||||||||||||||
43 | 4 | Afilias does not support an accreditation program. We do support improved process efficiencies including allowing an application review team to consider whether or not a registry operator’s selected registry service provider needs additional testing if the RSP has already been recently tested. In particular, variable testing requirements based on the specific needs of a registry operator’s application would be appropriate, provided this meets a threshold that considers minimum security and scalability capabilities. | Afilias | |||||||||||||||||||||||
44 | 5 | Meeting rigorous SLAs are a continuing obligation of all RSPs. We do not agree with making the technical security and stability requirements variable based on the types of TLDs. For more, see our response to 1.1.2. | RySG | |||||||||||||||||||||||
45 | 6 | The onus of compliance with the RAA is on the registry. AtLarge is of no opinion on the benefits or drawbacks of separate regulation of service providers. | ALAC | |||||||||||||||||||||||
46 | 7 | Continuing technical obligations should be placed upon the Registry Operator (RO) through their Registry Agreements, and by consequence, through the RO’s commercial contract with their RSP. In other words, the status quo from the 2012 round should be maintained. | Valideus | |||||||||||||||||||||||
47 | 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? | |||||||||||||||||||||||||
48 | 1 | We see no need or benefit from there being a contractual agreement between ICANN and the RSP. We are not aware of any issues that could arise, which could not be resolved using the existing compliance mechanisms and agreements. The RSP has a contractual relationship with the Registry Operator which should be sufficient. The Registry Operator will ensure that all terms of the RA as related to the RSP (particularly as related to performance service levels) would be included in any such agreement, either explicitly or by reference and if necessary, ICANN could make such an inclusion an explicit requirement with the Registry Operator. ICANN has enforcement mechanisms built in to the RA with respect to registry performance targets; these should be the necessary and sufficient elements to ensure the ongoing technical performance of the registry. | CIRA | |||||||||||||||||||||||
49 | 2 | In a pre-accreditation scenario there would presumably need to be a contract between the RSP and ICANN for the accreditation, or perhaps in practice simply a standard application form subject to T&Cs. Ultimately ICANN’s enforcement mechanism would be to remove accreditation, requiring the Registry Operator to move to a new RSP and/or go through the PDT processes. However we consider that any process leading to removal of accreditation should mirror the existing registry SLA and escalations and reporting mechanisms, under which ultimately a registry would be moved to an EBERO provider. | Nominet | |||||||||||||||||||||||
50 | 3 | Yes, there should be an agreement between ICANN and the certified RSP. David Conrad’s team would be a likely candidate for managing breaches of this certification. | BC | |||||||||||||||||||||||
51 | 4 | There should not a contract between RSPs and ICANN. The registry operator is the party who signs the Registry Agreement. Some can provide their own registry services. Some cannot. Those who cannot outsource that function. Those providers should not be forced to contract directly with ICANN for that service. They are responsible to their client, which in these cases is the Registry Operator, not ICANN. | Jim Prendergast | |||||||||||||||||||||||
52 | 5 | The agreement should remain only between the Registry Operator and ICANN. However, the Registry Operator may authorise the RSP to engage with ICANN directly for certain technical issues. There may need to be a separate, limited agreement between the RSP and ICANN if the RSP wants to avail itself of this program, which would cover the ongoing eligibility requirements. | BRG | |||||||||||||||||||||||
53 | 6 | Yes. Loss of Accreditation of RSP. | John Poole | |||||||||||||||||||||||
54 | 7 | Afilias concurs with the opinions of the RySG and defers to that response. | Afilias | |||||||||||||||||||||||
55 | 8 | An agreement suggests a legal relationship between ICANN and the RSPs, which we believe has the potential to create another 'contracted party' category in the ICANN construct that may result in some unintended consequences. The existing RSPs have a contractual relationship with the registry operator and are responsible to the respective registry operators for meeting certain SLAs contained in the Registry Agreement. We acknowledge that this creates some challenges associated with enabling direct communication between ICANN and the RSP on technical matters. We believe that the RSPs as contracted service providers to the registry operator (RO) (the ICANN contracted party) and the RO itself should determine how and when the RSP may communicate with ICANN. For example, one mechanism could be for the RO to supply a standard form written permission for ICANN to have direct contact with the RSP for certain specified matters that could be limited on a per-TLD basis, and to be included on all ICANN-RSP communications. This approach would provide for a formalization of the relationship between ICANN and the RSP without undermining the primary contractual relationship between ICANN and the registry operator. We also note that by virtue of the 2012 new gTLD program, ICANN has the ability to activate an Emergency Back-End Registry Operator (EBERO) in the event that ICANN considers a registry operator is at risk of failing to sustain any of the five critical registry functions, namely: ● DNS resolution for registered domain names ● Operation of Shared Registration System ● Operation of Registration Data Directory Services (e.g., Whois) ● Registry data escrow deposits ● Maintenance of a properly signed zone in accordance with DNSSEC requirements ICANN is yet to activate EBERO, but we note that it does serve as a viable and readily available option available to ICANN in the event that a registry operator is at risk of failure. | RySG | |||||||||||||||||||||||
56 | 9 | No. The onus of RAA compliance – and contact with ICANN – should remain with the Registry. | ALAC | |||||||||||||||||||||||
57 | 10 | No. ICANN already has a contract with the RO through which it enforces technical SLAs, and in turn the RO has a contract with its RSP through which it enforces the same (or higher) technical SLAs. Creating an additional contractual relationship between two of these three parties would complicate the authorisation and enforcement lines, i.e. with both ICANN and the RO having contractual enforcement power over the RSP for technical SLAs. It may become less clear who is primarily responsible for enforcing technical SLAs on the RSP, and the communication chain would also become blurred. Instead of an agreement between the RSP and ICANN, measures should be sought to improve the ability of ICANN to communicate with the RSPs (see for example the suggestion raised by the RySG in their comment). We also note that for 2012-round registries, ICANN already has the power to engage the EBERO and migrate a TLD to a different RSP if SLAs are breached. | Valideus | |||||||||||||||||||||||
58 | 1.1.6 - What, if any, are the potential impacts (both positive and negative) of an RSP Program on ICANN Accredited Registrars? If there are any negative impacts, what are ways in which those impacts can be mitigated? | |||||||||||||||||||||||||
59 | 1 | Correctly implemented, there should not be any impact on ICANN Accredited Registrars. | Nominet | |||||||||||||||||||||||
60 | 2 | The introduction of an RSP should not affect ICANN-Accredited Registrars in any way. | BRG | |||||||||||||||||||||||
61 | 3 | Afilias does not foresee any negative impact to registrars with this program. There is the positive impact of the registrar onboarding process being reviewed for possible improvements, specifically providing for a more efficient onboarding of registrars to new TLDs. | Afilias | |||||||||||||||||||||||
62 | 4 | The RySG is unaware of any documented potential impacts of a Pre-Approval Process on ICANN Accredited Registrars. | RySG | |||||||||||||||||||||||
63 | 5 | See response to 1.1.1 | ALAC | |||||||||||||||||||||||
64 | 6 | We are not aware of any notable impacts upon ICANN Accredited Registrars (either positive or negative) as the result of an RSP Program. | Valideus | |||||||||||||||||||||||
65 | 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 a re-approval? | |||||||||||||||||||||||||
66 | 1 | There is no need to reassess RSPs on a periodic basis given that ICANN requires the Registry Operator to meet specific performance objectives on a continual basis. ICANN may consider aggregating registry operator provided data by RSP in order to have a better vision of an RSP’s overall performance. But this information would be used only in the context of informing and dealing with the registry operator who may be in danger of breaching their performance obligations as a result of an RSP’s inability to meet those service levels. | CIRA | |||||||||||||||||||||||
67 | 2 | Yes. An annual audit would be reasonable. However where there have been no SLA breaches or other cause for concern this does not need to be a repeat of the initial approval process, but only a proportionate check by exception and perhaps even a straightforward desktop exercise. (As per the existing mechanisms for ICANN Accredited Registrars). | Nominet | |||||||||||||||||||||||
68 | 3 | An annual technical and security audit. | BC | |||||||||||||||||||||||
69 | 4 | Yes. This is particularly important for Registry Operators that will rely on the ongoing capabilities of an RSP that supports their registry but does not have the perspective that ICANN has when assessing the overall technical and scalable capabilities of an RSP supporting multiple registries. Consideration should also be given towards communicating the result of periodic reviews to all the Registry Operators that utilise the RSP, both in terms of assurance that the requirements continue to be met but particularly if any failings are identified that could impact the Registry Operators obligations towards ICANN. | BRG | |||||||||||||||||||||||
70 | 5 | In general, ongoing reviews are and should remain under the purview of the ICANN Compliance team. As needed, consensus policies are developed by registries and this process should be employed to create any new or additional parameters for this program. Such a consensus policy should define both the term for a periodic review and the process in which ICANN Compliance identifies breaches and how those are treated in terms of this program. | Afilias | |||||||||||||||||||||||
71 | 6 | See our response to 1.1.2. | RySG | |||||||||||||||||||||||
72 | 7 | See response to 1.1.1 | ALAC | |||||||||||||||||||||||
73 | 8 | There already is a continual process to assess the technical capability of RSPs, namely through ICANN Compliance’s SLA monitoring. ICANN’s SLA monitoring system provides round the clock monitoring of a TLD’s SLAs and alerts ICANN when SLAs for a given TLD are approaching breach level and when they hit breach level. At this point, ICANN have the ability to invoke the EBERO and migrate a TLD to a different RSP. Therefore, it is not clear that any arbitrary periodic “assessment” of an RSP would add anything which is not already being covered by ICANN Compliance’s SLA monitoring. | Valideus | |||||||||||||||||||||||
74 | 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? | |||||||||||||||||||||||||
75 | 1 | Any RSP certification program must be launched well in advance of the next application window to allow any potential RSP to obtain certification in time to be able to pursue potential registry operators as customers. An early decision on the RSP certification program should be taken and then immediately announced, ideally as early as by the end of calendar 2017. The earlier registry service providers can become certified, the earlier potential gTLD applicants can engage with them meaningfully to determine registry features and costs, thereby allowing the development and refinement of new gTLD business models. | CIRA | |||||||||||||||||||||||
76 | 2 | This sort of detail will depend very much on the application process decided upon for subsequent rounds. However, as implied by the question, clearly if existing RSP providers were not to be automatically pre-approved (on the basis that ICANN has already in effect reviewed their technical operations and there are no material SLA breaches) there would need to be an additional 3-6 months for RSPs to obtain accreditation ahead of the opening of the next application window. Ideally this would be in parallel with other activities (outreach, case studies, beta testing of the application system) in order that the next application window is not delayed. | Nominet | |||||||||||||||||||||||
77 | 3 | 6 months | BC | |||||||||||||||||||||||
78 | 4 | As soon as is practical, so that new applicants can be prepared at the earliest stage and incorporate into their business plans. | BRG | |||||||||||||||||||||||
79 | 5 | 12 months unless ICANN needs longer. | John Poole | |||||||||||||||||||||||
80 | 6 | The launch of a Program is largely dependent on the completion of an Applicant Guidebook with all terms, process improvements and procedures finalized, not on any arbitrary range of dates. Insofar as drafts of an Applicant Guidebook have been shared and the community and relevant parties have an opportunity to opine, the Program would effectively begin on publication of the final Applicant Guidebook and run into perpetuity. | Afilias | |||||||||||||||||||||||
81 | 7 | As much time as possible; however, we do not consider it appropriate to specify an arbitrary period of time that could become a constraint to opening any future application windows. For clarity, under no circumstances should this be a pre-requisite to the opening the next application window. | RySG | |||||||||||||||||||||||
82 | 8 | See response to 1.1.1 | ALAC | |||||||||||||||||||||||
83 | 9 | As soon as possible in order to provide RSPs with enough time to seek pre-approval (if they so desire) before the application window opens. However, not having preapproval should not be an impediment to a TLD applicant selecting a particular RSP. Therefore, the 2012-round method of submitting technical answers at the time of application and going through evaluation on a TLD basis should also be an option (this would only apply for applicants who have selected a non pre-approved RSP). | Valideus | |||||||||||||||||||||||
84 | 1.1.9 - Should there be an RSP application “cut-off” date to allow sufficient time for an RSP seeking approval to receive approval in order for their application to be approved before the opening of an application window? | |||||||||||||||||||||||||
85 | 1 | We would suggest that RSP certification not have a cut-off date. Instead, a deadline would be established that would ensure certification was possible prior to the opening of the application window but the certification process would remain open, perhaps indefinitely on the assumption the required infrastructure for testing could be easily set-up and torn-down (as may be possible if deployed in the cloud). It is not clear yet that the “next round” will indeed be a “round” or will represent an opening of an ongoing process. In the latter case, the potential for an RSP to certify will also need to be ongoing. Further, if an applicant is allowed to submit an application without a specific commitment to any one particular RSP (as mentioned previously yin our responses to 1.1.1 and 1.1.8), then again the certification process will need to remain available. | CIRA | |||||||||||||||||||||||
86 | 2 | We don’t think that RSP Program should be mandatory, in which case the urgency and importance of a cut off diminishes. Arguably the RSP Program could run concurrently with the application window but these sorts of logistics points we think are more operational in nature and should follow from the policy principles. | Nominet | |||||||||||||||||||||||
87 | 3 | Yes, but could also envision this as a rolling application window. If an RSP was not ready at the beginning of an application period they could still request certification within the open application period. This would encourage participation by RSP’s who were late in becoming aware of the program. | BC | |||||||||||||||||||||||
88 | 4 | No, an RSP application cut-off date is not necessary. However, the administrator of a RSP Program may wish to provide indications of timeframes to inform RSP candidates who may wish to target operational dates imposed by future application windows. | BRG | |||||||||||||||||||||||
89 | 5 | Yes. | John Poole | |||||||||||||||||||||||
90 | 6 | As noted in the response to 1.1.8, the Program is largely about process improvements and will hinge on finalizing the Applicant Guidebook. As an RSP proceeds through testing, any duplicate testing is eliminated until a test must be renewed. Thus it is an ordinary part of the application process and there is no begin or end date except as may be present in the next “application window” unless the Program simply runs into perpetuity. For the purposes of a registry operator that wants to seek an experienced RSP, as suggested in the response to question 1.1.2, ICANN could seek to summarize and make more conveniently available the mandatory reporting already provided by registry service providers. ICANN’s Open Data Initiative is a candidate solution to this suggestion and it would inform the decision to be made by a registry operator. | Afilias | |||||||||||||||||||||||
91 | 7 | The RySG does not believe that a “cut-off” is warranted. | RySG | |||||||||||||||||||||||
92 | 8 | See response to 1.1.1 | ALAC | |||||||||||||||||||||||
93 | 9 | For practical purposes it may be advisable to have a cut-off date in advance of the application window opening, in order to prevent a situation where an RSP fails to achieve pre-approval by the start of the application window, leaving them and the TLD applicant a relatively short period of time to compile answers to the technical section of the TLD application (being the only other approval method available). | Valideus | |||||||||||||||||||||||
94 | 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? | |||||||||||||||||||||||||
95 | 1 | Yes, absolutely. Existing RSPs who have already conducted Pre-Delegation testing (some have done so numerous times), have also demonstrated their capability to run a registry by virtue of being in production for a number of years. Under the scrutiny of ICANN RA performance requirements, these RSPs have fully demonstrated what would otherwise be tested in any kind of certification process (unless the criteria are expanded in a critical way as a result of the review process). Simply put, existing RSPs that are providing service to one or more registry operators, have previously conducted the PDT testing and are meeting the performance targets stipulated under the ICANN RA should be offered RSP Certification without the need for further testing. | CIRA | |||||||||||||||||||||||
96 | 2 | There should be a presumption that existing RSPs with a strong track record and competencies should be given a waiver from most if not all technical requirements checks. | Nominet | |||||||||||||||||||||||
97 | 3 | All RSP’s should be required to request certification and adhere to the requirements of the program. | BC | |||||||||||||||||||||||
98 | 4 | Yes. As per response to 1.1.7, this is important for existing Registry Operators that will rely on the ongoing capabilities of an RSP that supports their registry but does not have the perspective that ICANN has when assessing the overall technical and scalable capabilities of an RSP supporting multiple registries. Consideration should also be given towards communicating the result of periodic reviews to all the Registry Operators that utilise the RSP, both in terms of assurance that the requirements continue to be met but particularly if any failings are identified that could impact the Registry Operators obligations towards ICANN. RSPs that have exceeded the emergency thresholds for existing ‘new gTLDs’ and initiated EBERO should be excluded from the program. | BRG | |||||||||||||||||||||||
99 | 5 | That’s up to ICANN technical. | John Poole | |||||||||||||||||||||||
100 | 6 | Afilias does not support a pre-approved list. As an administrative task, ICANN could maintain detailed testing results and pass them along to review teams, whether reviewing new applications or registries to be transferred. This should be done as a part of managing this Program and in conjunction with the scope of ICANN Compliance staff. Afilias does believe that an RSP’s existing performance as documented in the mandated reports already provided to ICANN could be used to satisfy some of the technical requirements of an application review, but more discussion among registry services provider would be necessary to ensure that all potential issues are properly considered. Further, reports can not be looked at in isolation, but require context by ICANN Compliance staff. | Afilias | |||||||||||||||||||||||