At Cloud Registry, we believe in empowering our partners by providing them with intuitive tools, industry knowledge, and insights into the business. It is part of our Flexibility · Visibility · Control value proposition. That’s why we make it a point that information sharing and education are a large part of our consultation with clients. Encouraged by the positive feedback we have received from clients — seasoned industry players and newcomers to the industry alike — we would like to share our experience with the wider ICANN community with this series of blog posts.

Registry Services

In this instalment, we will explore the core functions of a registry. Being the registry operator for a TLD means offering services in conjunction with the TLD. While the registry can offer a variety of services, ICANN provides guidance on what constitute registry services:

A. those services that are both:

1. operations of the registry critical to the following tasks: the receipt of data from registrars concerning registrations of domain names and name servers; provision to registrars of status information relating to the zone servers for the TLD; dissemination of TLD zone files; operation of the registry zone servers; and dissemination of contact and other information concerning domain name server registrations in the TLD as required by the Registry Agreement; and 
2. provided by the Registry Operator as of the Effective Date of the Registry Agreement, as the case may be;

B. other products or services that the Registry Operator is required to provide because of the establishment of a Consensus Policy (as defined above);

C. any other products or services that only a registry operator is capable of providing, by reason of its designation as the registry operator; 

D. and material changes to any Registry Service within the scope of (A), (B) or (C) above. (Definition comes from .NET Agreement, as specified by the ICANN Board on 8 November 2005, http://www.icann.org/minutes/resolutions-08nov05.htm).

The guidebook cites some customary services:

1. Receipt of data from registrars concerning registration of domain names and name servers.
2. Dissemination of TLD zone files.
3. Dissemination of contact or other information concerning domain name registrations (Whois service).
4. Internationalized Domain Names, where offered.
5. DNS Security Extensions (DNSSEC). 

which roughly translates to EPP, DNS, Whois, IDN and DNSSEC — the core well-known services.

Mapping it out

It helps to think about the registry in two parts: provisioning and publication.

Or, thinking in terms of an Input/output paradigm, the “Provisioning” subsystem, as we call it at Cloud Registry, encompasses the “input” and “processing” part of the equation; the “Publication” subsystem correponds to the “output” of a registry.

Why Should Applicants Care?

While all TLDs essentially perform the same core functions of accepting registrations and publishing info onto the DNS and Whois, etc., this is one of the main areas in which a gTLD applicant can distinguish itself from the competition.

Registry services are mostly covered by Question 23 of the Applicant Guidebook. Being a non-scoring question, applicants may defer to their technical operator to provide a boilerplate response. While likely to be safe, this will lead to a very unimaginative registry.

At the other end of the spectrum, applicants should be mindful of the Registry Services Review and not trigger an extended evaluation by RSTEP, which will incur additional costs and delay to the application approval process.

What about Critical Registry Functions?

Some have expressed confusion between registry services and the “five critical functions of a registry” stated in the guidebook: DNS, SRS, Whois, data escrow, DNSSEC. It’s important to note that critical registry functions is a tangential topic that is mostly related to continuity and registrant protection in the event of a potential continuity threat.

Examples of Other Registry Services

Following are some examples of registry services beyond the basics:

• name reservation and correponding release / allocation plan
• registry lock service
• grace periods
• registrant verification or nexus requirements
• enhanced rights protection mechanisms
• any non-standard form of access to registry data offered to other parties such as law enforcements

The registry services offered by a TLD is a defining attribute, and should be one of the key strategies for any would-be applicant.

In some inexplicable ways, we are really fond of policy-making and standardisation bodies. Sure, they may be slow-moving creatures and convene working groups filled with conflicting interests, politics and other nasties. Nevertheless, they are the necessary evils without which the industry would not mature and flourish. Think about each of the organisations and imagine the DNS without the work that they have produced: ICANN, IETF, and the Unicode Consortium.

For a technology-focused company, our work is directly affected by the policies made by ICANN through its multi-stakeholder model, and the standards produced at the IETF through rough consensus building. The impact of those policies and standards is a positive one — we gain interoperability by implementing and promoting the use of these standards. The industry as a whole is better for it for that reason alone.

Doing our bit

In the same spirit, we are always looking for practical ways to give back to the community. Here are two projects that we have initiated, with more in the pipelines.

EPP Launch Phase Extension

We contributed our EPP launch phase extension and spearheaded the effort at the IETF.

Sunrise and Land rush are common processes in a TLD’s launch strategy. Typically, during these launch phases the registry operates in a mode that differs from steady state in that it may accept multiple applications for a given domain name. At the end of the launch phase window, it allocates the domain to one of the applications according to its policies. Due to this unique mode of operation, the standard EPP protocol is not sufficient to capture its semantics. As a result, various registry operators have invented their own extensions to meet their needs.

At a recent launch that we managed, it was apparent that we had to invent a new EPP extension that is modern and generic enough to meet the needs of others in the industry. In particular, we needed an extension that complies with the new gTLD program’s requirement to use the trademark clearinghouse for validation of trademark claims. To alleviate the guilt for what could be labelled as NIH syndrome, we had planned to write an Internet Draft and steward the efforts at the IETF to hopefully get it to standards track RFC.

The benefits of having a standard launch phase extension is clear:

• Registrars only have to implement it once and use it for all future TLDs that support it
• It saves new registry operators from having to reinvent the wheel
• It saves old registry operators who are in need of an updated extension from having to reinvent the wheel

So, we meticulously documented it and together with CentraNic, published the first version of the draft.

The document is discussed on the IETF Provreg mailing list, and document source is hosted here:
https://github.com/cloudregistry/EPP-Launch-Phase-Extension-Specification

ICANN Meeting Schedule iCal Feed and iPhone Site

At every ICANN meeting since Cartagena, we have provided an iCal feed of the meeting schedule, as well as an intelligent iPhone-optimized mobile site to help fellow attendees organise their time and make the most out of the meeting.

Since the San Francisco meeting, we have also been tweeting updates to the schedule to alert people of significant changes to the schedule (room change, time change, new or cancelled events.) While the changes are reflected on both the official meeting schedule page as well as our iCal feed, it won’t be immediately obvious unless one scrutinise the schedule.

All of these efforts have been very well received by the community and we are proud of our contributions.

Future

We are committed to interoperability and open standards. Work is already underway for us to participate in, and lead efforts that may benefit the community. Stay tuned!