Registry Services Outreach Process | Generic Names Supporting Organization

Request for comments

Please send comments to registry-outreach (at) gnso.icann.org

Click here to read comments

This statement on behalf of NeuLevel relates to the GNSO Policy Development Process (PDP) on a procedure for use by ICANN in considering requests made by registry operators or sponsors for consents or related amendments to the agreements these entities have with ICANN. In accordance with Section 7(d) (1) of the GNSO Policy Development Process, ICANN initiated a PDP to develop a predictable procedure to handle such requests. The GNSO Council voted to initiate the PDP subject to additional Terms of Reference (TOR). Both changes to the nature of the agreements between ICANN and the registries/sponsors and non-contractual discussions between registries/sponsors and ICANN are explicitly "out-of scope" of the TOR.

To date, the gTLD Registries Constituency as a whole has been unable to come to a consensus position regarding the Registry Services Policy Development Process. Although many of the concepts set forth herein have been discussed at length within the constituency, this statement reflects the views of only NeuLevel. However, NeuLevel believes that this statement should be submitted in the hopes of moving this important process forward.

NeuLevel welcomes the steps by ICANN and the GNSO Council towards making the Internet more secure and stable, and we would like to co-operate in development of a predictable and timely procedure for ICANN to handle requests for consents required by our contracts or related contractual amendments in which we are interested.

We believe that implementation of a predictable and timely procedure by ICANN to handle changes in the registry agreements is in the best interest of the gTLD Registries Constituency. Such a procedure will limit the uncertainty, improve the timeliness of any changes and allow both the unsponsored registries and the communities served by the sponsored registries to continue development of the gTLDs in a manner that is predictable and best suited to serve the interests of Internet users.

Although we believe it is important to develop a predictable procedure for contractual approvals and amendments, specific contractual changes (or changes in the relationship between the registries and ICANN) should not be considered as part of this Policy Development Process. Rather, once a process has been adopted under this PDP for the introduction of new registry services, a similar process could be used to ensure the timely approval of changes to registry agreements.

Finally, NeuLevel believes that the implementation of a such a procedure must take into consideration differences among TLDs, respect the role of the sponsored communities in sTLDs, appreciate the different levels of impact a change will have on different Internet constituencies, and favor development and innovation while maintaining the stability and security of the Internet.

Process Notes

NeuLevel notes that ICANN has received a number of statements from various constituencies that discuss which matters should and which should not be considered as part of the new "Registry Service Process." The intent of this document, however, is not to address this very important issue, but rather to detail a process that should be implemented once it as been determined that a particular service or action by a Registry Operator falls within the jurisdiction of the "Registry Services Process."

We believe that further work needs to be done to determine precisely which matters should properly be considered by ICANN under the applicable Registry agreements under this new process.

The following information is provided in reference to the Registry Services Outreach Process flow chart (PDF), which has been provided in conjunction with this statement. The item numbers in the table below correlate to shape numbers in the flow chart. Time limits are shown in flow chart shapes where applicable and are always in calendar days. A "yes" in the NDA column indicates that the terms of a nondisclosure agreement apply to the involved parties. Although an NDA is not a fail-safe to ensure that sensitive registry information is kept confidential, we believe it is an essential element in various steps throughout the process.

It should also be noted that the following process is not a final product and considerable work still needs to be done. For example, the process introduces a new body called the Outreach Advisory Panel ("OAP"), which we believe will be a way to ensure appropriate involvement of the various ICANN constituencies (including the SECSAC, GNSO, and relevant technical standards bodies) impacted by the proposed registry service, while at the same time protecting registry confidential information. Specific membership of the OAP and their selection are questions that still need to be explored.

Item	Responsible	Actions	Time Limit	NDA?
1	Registry	Registry first develops a new service concept. At this stage it is presumed that the Registry will have engaged in some or all of the following activities: Initial concept development Market research including price sensitivity analysis Development of business case Identification of impacted parties Technical standards review DNS security, stability & interoperability review Outreach to impacted parties	None	N/A
2	Registry	Does the service fall within the new process? This determination is initially made by the registry. ¹	None	N/A
3	Registry	Deliver to ICANN: Summary Report. Description of the new service. A summary of information related to Item 1 above. Initial Price Proposal: (may include) Quantification of high level one-time product development and market research costs Estimation of ongoing service support costs. Determination of market price points Development of proposed maximum service price Preparation of proposal for maximum service price with high-level one-time costs, high-level ongoing support costs and market price research information as applicable. Proposed launch dates Protocol Change Request (if needed)	None	Yes - under existing NDA in Registry Agreements
4	ICANN	Does this go through the Quick Look process²? This determination is made initially by the ICANN staff. Review of summary report and initial price proposal Request for clarification from registry as necessary ICANN should provide the rationale for its decision in writing to the registry operator.	15 days	Yes - under existing NDA in Registry Agreements
5	Registry	If ICANN decides that the quick look process does not apply, the registry may appeal the decision to the IDR panel³. If registry accepts that "quick look" does not apply, then go to step 13 (on page 2 of the chart).	10 days	Yes - under existing NDA in Registry Agreements
6	IDR Panel	Dispute Resolution	20 days	Yes
7	IDR Panel	Decision: Does the "quick look process" apply?	N/A	Yes
8	ICANN	If ICANN determines that the "quick look" process applies, then the ICANN staff and the registry operator will engage in negotiations regarding the new service. Or if after an appeals process, the IDR Panel determines the "quick look" process applies, then the ICANN staff and the registry operator will engage in negotiations regarding the new service	14 days	Yes - under existing NDA in Registry Agreements
9	ICANN & Registry	Assuming agreement between the ICANN staff and the registry operator, the two parties will amend the Registry Agreement to include the new registry service.	7 days	N/A as the amendment will be public
10	IDR Panel	If the parties are not able to agree on the relevant terms regarding the new service, the registry operator should have the ability to appeal to an IDR panel. If it does not appeal, the process ends.	20 days	Yes
11	IDR Panel	Makes a Recommendation regarding the disputed terms.	See above	Yes
12	Registry	Decision: Does Registry wish to proceed given the IDR Panel recommendation? If so, go to step 9.	None	Yes
13	ICANN	ICANN forms an Outreach Advisory Panel (OAP) and has members sign NDA. Possible guidelines for OAP: Purpose: to review registry outreach efforts, evaluate representativeness of outreach efforts and recommend additional outreach if applicable. It should be small enough to be functional (probably 5 or fewer members). One representative from each of the following would be one approach: registrars, users, SECSAC, ICANN staff, and gTLD registry (not from registry proposing service)	10 days	OAP will sign an NDA with ICANN and Registry.
14	OAP	Review Summary Report & Identify Impacted Parties	10 days	Yes
15	Registry	Continue outreach to Impacted Parties & Prepares Outreach Report	None	N/A
16	OAP	Review Outreach Report & Evaluate Representativeness	10 days	Yes
17	OAP	Recommend additional outreach? If the OAP believes that the registry outreach efforts did not sufficiently represent the impacted community, it may recommend additional outreach. Any such recommendation(s) should provide information specific enough to give the registry adequate direction.	See above
18	OAP	Prepare report: The report should provide detailed information regarding any additional outreach recommended. The report should also provide the OAP opinion with supporting justification regarding the representativeness of the outreach performed by the registry.	15 days	Yes
19	ICANN	Prepare Final Report	10 days	Yes
20	ICANN	Should the service proceed? If yes, proceed to step 22. If no, then registry should have the opportunity to appeal.	See above	Yes
21	IDR Panel	IDR Panel either upholds ICANN decision or overturns ICANN's decision. If upheld, the process ends. If it reverses ICANN's determination, then proceed to 24.	See above	Yes
22	ICANN	The parties engage in negotiations regarding the new service.	14 days	Yes
23	ICANN & Registry	Assuming agreement between the ICANN staff and the registry operator, the two parties will amend the Registry Agreement to include the new registry service.	7 days	N/A as the amendment will be public
24	IDR Panel	If the parties are not able to agree on the relevant terms regarding the new service, the registry operator should have the ability to appeal to an IDR panel. If it does not appeal, the process ends.	20 days	Yes
25	IDR Panel	Makes a Recommendation regarding the disputed terms.	See above	Yes
26	Registry	Decision: Does Registry wish to proceed given the IDR Panel recommendation? If so, go to step 23.	None	Yes

¹This gets into the subject of whether the service falls within the jurisdiction of this new process. We will work with the ICANN and the other relevant stakeholders in the community to help establish objective criteria to aid the registry's determination.

²Objective criteria should be developed to determine which new services go through the "quick look" process and which merit the full blown process set forth in this paper.

³More details would need to be specified as to how the IDR Panel is constituted and the rules by which it needs to operate, including the relevant standard of review.