Page History

At the ICANN public meeting held in Singapore, the ICANN approved an initial seed fund of $2m to implement the recommendations of the JAS WG. Several interested persons -- Bruce Tonkin, Dennis Jennings, and the author, among others, independently thought that one or more Registry Service Platform (RSP) was a feasible form of providing support to the broad class of qualified applicants, meeting also the capacity building needs identified by the GAC participants in the contemporaneous ad hoc ALAC-GAC drafting party. A draft proposal in issue memo form follows.

ISSUE

Can JAS-qualified applicants share existing resources to provide Registry Services Platform (RSP) capabilities, and related capabilities, consistent with capacity building and diversity goals of Resolution 20, to participating JAS-qualified applicants?

BRIEF ANSWER

Yes.  JAS-Qualified applicants can create, and share, RSP capabilities, within the time and cost constraints of the new gTLD round now scheduled to begin in 1Q2012.  Several technically feasible choices are available, and the $2m initial seed fund allocated by ICANN improves the economic feasibility of such a program.

Regional deployments of RSP capabilities to sites with adequate infrastructure, providing capacity building in developing economies and diversity of technology, location, and working languages of the instances of RSP capabilities are technically and economically feasible.

One or more instance of RSP capabilities would allow JAS-Qualified applicants to provide common, correct technical proposals, benefiting both ICANN and the applicants, and provide significant additional legal and operational benefits to both ICANN and the applicants, as well as the benefit of operational readiness and common, correct core practice, benefiting ICANN, applicants-as-operators, registrars and registrants.

FACTS

The Joint Application Support Working Group is recommending both general and specific forms of assistance.  Some forms of assistance address the application preparation needs of applicants, some the application fee requirement, some the post-preparation requirements such as extended evaluation and objection, some the transition to delegation requirements, and some one time and recurring operational requirements.

A registry services platform of reference capability would assist applicants preparing their applications, reduce their extended technical evaluation risk and cost, reduce their transition to delegation risk and cost, and assist in meeting some of their subsequent one time and recurring operational requirements.

Use by applicants of a registry services platform of reference capability would reduce one time cost and risk to ICANN as an evaluator, and one time and recurring cost and risk to ICANN as a counter-party to contracts with reporting and service level obligations.

A registry services platform of reference is fee neutral, and objection neutral, and dispositive of extended technical evaluation requirements, whether supplied by this program, or offered under commercial terms by existing registry service platform operators.

Several registry services platform implementations have non-restrictive licensing and accessible technologies, four of which are enumerated here:

1. FRED, implemented in Python/Postgresql, GNU GPL licensing
2. DNRS, implemented in Perl/Postgresql, GNU GPL licensing
3. CoCCA, implemented in Java/Postgresql, other non-restrictive licensing
4. CODEV-NIC, implemented in Python/Postgresql, GNU GPL licensing
   

Extensions to support client-side DS provisioning (DNSSEC), variant provisioning (IDN), marks authority provisioning (CLEARINGHOUSE), and other new programmatic functionalities is feasible within the time available as skilled coding in any of these idioms (Python, Perl, Java, etc., over some SQL database), sufficient to implement initial and subsequent registry policy goals is available and affordable in developing economies.

Additional requirements such as IPv6 accessibility, zone signing, uptime, performance, and other new non-programmatic functionalities are also feasible within the time available.

Pre-provisioning requirements common to classes of applicants-as-operators, e.g., registrar support in bidirectional and combining scripts, regional registrar network latency and bandwidth, etc., and post-provisioning requirements common to classes of applicants-as-operators, e.g., regional ANYCAST publication, heterogeneous publication, etc., are also feasible if a registry services platform is available and adopted.

Each of the enumerated example registry services platforms is known to be fully operational on modest machine resources, minimally, a single, possibly virtualized, machine, and known to be fully scalable to distributed, replicated, highly available machine resources.

Exercise of registry capability is required in the transition to delegation, which may occur at the election of the applicant, as early as three fiscal quarters after the application period ends, or as late as eight fiscal quarters after the application period ends.

One or more registry services platforms reduces technical causes for risk of Continuity Operations, benefiting applicants and ICANN, and creates an infrastructure available for subsequent rounds, benefiting future applicants, ICANN, and allowing future donors to address other areas of applicant need. 

DISCUSSION

The JAS Working Group initially conceptualized support as a per-applicant allocation from a finite financial resource, addressing the $185,000 application fee, and a per-applicant allocation of “in-kind” support, addressing other applicant assistance opportunities.

The Working Group did not have any estimates of the financial resource available, nor of the number of applicants, nor the inventory of “in-kind” services. This has resulted in considerable non-progress, as members of the Working Group attempt to allocate unknown financial resources and unknown “in-kind” resources to unknown numbers of applicants.

An obvious problem was how to provide either divisible resources to individual applicants, meeting “rationing” assumptions, or integrated resources to pools of applicants. 

At the Singapore meeting the ICANN Board voted to allocate $2,000,000 to applicant support, and several persons – Bruce Tonkin, Dennis Jennings, Eric Brunner-Williams, and others – independently suggested the use recommended in this memo.

This memo proposes a form of assistance common to all qualified applicants, working around the “rationing” assumption, and reducing the unknowns of an “in-kind” inventory that persistently does not actually take definite form or scale.

The proposed assistance is capable of providing registry services platform capacity sufficient to meet the initial transition to operations requirements of all qualified applicants, and the ongoing operational requirements of all qualified applicants-as-operators.

The proposed assistance provides capacity building, meeting an objective identified by the GAC-ALAC mini-group meeting at the Singapore meeting.

The likely cost of implementing the recommendation is initially estimated at a quarter of the ICANN Board’s allocation.

Additional downstream benefits to applicants-as-operators are shared, or cooperative access to registrar functions, and other cooperative agreements.

Objections to this recommendation are likely from those who view this – and any other use of the initial fund – as worsening the “rationing” problem, and from those who view this – and any other programmatic cooperation among qualified applicants – reducing qualified applicant dependence upon providers.

CONCLUSION

A program which offers RSP capacity to JAS-qualified applicants is feasible, assuming some allocation from the initial $2m fund, and can provide significant, cost-effective operational assistance to JAS qualified applicants.  The capacity may be distributed, replicated, and contribute substantially to capacity building in developing economies, assuming some replication of this allocation from the initial $2m fund.

The JAS addenda to the Staff Applicant Guidebook can inform applicants that they may designate one or more RSP platforms and the associated pro forma response for questions 23 – 44 in their application – providing significant, cost-effective application assistance to JAS qualified applicants.

The JAS addenda to the Staff Applicant Guidebook can also inform applicants that they may designate one or more RSP platforms as Continuity Providers, and may provide the associated pro forma response for questions 45 – 50 in their application – providing additional significant, cost-effective application assistance to JAS qualified applicants.

Recommendations:

1. That a program to offer RSP services be included in the support that is available to JAS-qualified applicants.
2.  That the program establish a pilot project to demonstrate technical feasibility at the Dakar ICANN meeting.
3. That the program establish instances of an RSP in at least two of the five ICANN regions by the end of 4Q2011.
4. That the program provide common, and instance specific user guides for applicants, including pro forma response for questions 23 – 44, and the pro forma response for questions 45 – 50, by the end of 4Q2011.
5. That the program meet site-specific non-functional requirements (performance, v6 accessibility, etc.) by the end of 2Q2012.
6. That the program implement common, and instance specific programmatic functional extensions, to be code complete by the end of 2Q2012, and production ready by the end of 4Q2012.
7. That the program conduct periodic general accountability reviews.