Skip to main content

RySG Alternative Proposal for Continuity Operations Instrument

Comment Period Important Information Links
Open Date: 17 October 2011
Close Date: 2 December 2011 Public Comment Announcement To Submit Your Comments (Forum Closed)
Time (UTC): 23:59 View Comments Submitted Report of Public Comments
Originating Organization: Registry Stakeholder Group

Public comment is requested concerning the recently received from the proposal for Establishment of a Continued Operations Fund. This proposal comes from the Registries Stakeholder Group (RySG) and is accompanied by an addendum (Proposed Continuity Operations Instrument) produced by the Afilias and PIR, supported by some other registries, registry applicants and other interested parties.

The RySG proposal offers an alternative approach to the existing Continuing Operations Instrument that is part of the New gTLD Program. 

Here are some questions that public comment respondents could consider regarding the RySG alternative proposal as well as the existing continuing instrument model offered by ICANN.

  1. Considering ICANN's Mission, what is the appropriate role for ICANN to create a fund or act as an insurer? Under which circumstances?
    • Can the same end be accomplished through a third party?
    • Will an insurance company underwrite this?
  2. The current COI model outlined on the Applicant Guidebook (see: is designed to provide some safeguards regardless of the number of gTLD registries that fail.

    For the existing COI model:

    • There will be an incentive to underestimate the projected size of the new registry, and therefore lower the cost of the COI to below what it should be to protect registrants. How could this be addressed?

    For the COF model:

    • Who should determine how much reserve must be set aside?
    • What criteria should be used to ensure sufficient funding and a mechanism to provide registrant protections?
  3. In the estimates shown in the addendum (Proposed Continuity Operations Instrument), what are the assumptions can be made in creating the basis for the proposed fund?
  4. How should the both the existing COI model and the newly proposed COF model ensure that it appropriately meets the needs of multiple registries sizes from small to large?
  5. Will the allocation of costs need to be adjusted over time if new registries enter the pool after the target balance is achieved? How can this account for some level of predictability and fairness for all registries?
  6. What appropriate level of internal resources should ICANN have for collections, tracking of deposits and outlays from the fund?
  7. What are the foreseeable challenges to move funds in timely manner to various parties as required responding to emergency situations?
Current Status:

The current model proposed by ICANN is outlined in the Applicant Guidebook, in particular the module 2, evaluation criteria attachment and the spec 8 of the Registry Agreement.  Respondents to the public comment that wish to learn more about this topic are also encouraged to read the gTLD Registry Transition Process Memorandum ( [PDF, 747 KB]) and the recently posted Emergency Back-End Registry Operator Request for Information (EBERO RFI):

Next Steps: Those interested in the topic, in addition to submitting public comments, should try to attend the ICANN Dakar "Continuing Operations Instrument (COI) - Discussion on RySG proposal" session. In this session, experts from the Registry Constituency and ICANN community will discuss the proposal as well as some of the questions outlined. The session will have remote participation for those unable to attend. Click here for session and remote participation details. The session will be recorded and the recording will be available soon after the Dakar Meeting ends.
Staff Contact: Karla Valente Email:
Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as"""" is not an IDN."