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.

If you have been following the recent tumulltuous developments on ICANN’s New gTLD Program, you will find comfort in the latest blog post from ICANN’s CEO, Rod Beckstrom, confirming that the program will launch on schedule and as planned.

In other words, ICANN will begin accepting applications for new gTLD’s on January 12th, 2012.

There’s still time, but not a whole lot

The application window is open for three months ending April 12th, 2012. However, the final date for registering an account on the TLD Application System is March 29th, 2012.

While many providers (including ourselves) have the capability to provide you with a “standard” set of answers for your gTLD application, it is far from the ideal way to spend that $185,000 application fee. If anything the domain industry has learnt over the past two new gTLD rounds, is that the cookie-cutter approach doesn’t work. As an applicant, you need to think long and hard about your unique value propositions, your market and its stakeholders, as well as your business and marketing strategies.

We are flexible enough to support you

Given that we espouse the values of being creative and innovative with new gTLDs, it is no coincidence that Cloud Registry was founded with the core value of being flexible. Being flexible means that our software and processes can perfectly complement your strategies on day dot, with the elasticity to grow and evolve with your needs into the future. Our platform and services are truly built for the 2012 New gTLD round, and proven through production use by ccTLDs that are operated on the Cloud Registry platform.

Let us help you

Get in touch now.

_{Photo credit: NASA/KSC - Space Shuttle Discovery launches from pad 39B at Kennedy Space Center, Fla.}

Cloud Registry, in partnership with Sedari and CoCCA, submitted our response to the RFP for .sydney, .melbourne and .victoria gTLDs.

The governments of New South Wales and Victoria have shown great leadership and foresight by tracking the ICANN new gTLD program from its early days and championing a well-designed RFP structure for these geographic TLDs. As an Australian-based registry operator, we are grateful for the opportunity to respond to the RFP, and potentially operate the TLDs.

The Sedari team complements our technical expertise with strong project management skills and detailed ICANN knowledge, and CoCCA brings more than a decade of invaluable experience working with governments, public administrations and country code administrators. Together, we will work with the stakeholders and governments to implement an integrated plan for the application and operation of these TLDs.

We are really looking forward to seeing .sydney, .melbourne and .victoria (and .nsw) addresses come to live in 2013!

This is the fifth ICANN meeting for which we’re providing the meeting schedule in iCalendar (.ics) format. By now, the ICANN community pretty much expects us to do it and we’re once again happy to be of service.

So, without further ado, here are the ways in which you can use it:

1. Subscribe to it from your desktop or mobile calendar software. If you’re using Apple iCal, click on the “Calendar” -> “Subscribe…” menu item and paste the following URL in: http://dakar.cloudregistry.net/cal.ics
2. Add to your Google Calendar. Click the following button:
   

By using this method, your calendar will be automatically refreshed with the latest updates from ICANN. As usual, we’ll also be broadcasting non-trivial schedule changes on our @CloudRegistry Twitter account to keep you up-to-date.

Just to whet your appetite, below are some screen shots from my iCal:

and Google Calendar account (notice the dual timezone setup, which is really handy!)

If you encounter any issue, please leave a comment here.

Enjoy!

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!

In this first ever official blog post, we’re going to answer the most frequently asked question in our travels to various ICANN meetings — “why the name Cloud Registry?” Most of these questions stemmed from the “cloud” buzzword. While the term means different things to different people, it aptly describes the values that we stand behind.

The Spirit

To us, “cloud” embodies the spirit of being agile, streamlined, and adaptable to changes. We set out to redefine registry operations and empower would-be new gTLD applicants to set themselves apart by offering an innovative registry platform that will evolve with the needs of the market without significant technical expertise. We firmly believe that in order for a TLD to be successful, there needs to be an interdependent relationship between the registry operator and the back end service provider. To that end, we’ve mostly succeeded in finding the right balance between arming the applicants with enough tools and intelligence to make informed decisions and shielding the operational details from them.

The Form

The DNS is a core component of the Internet, and the registry system provides the authoritative data store and associated services for the TLD it hosts. It is therefore no surprise that registry operations demand air-tight security, robustness, scalability and high availability. These properties impose costs in terms of expertise and infrastructural resources.

Our unique blend of infrastructure and domain name expertise, coupled with a registry platform that was built from the ground up to be cloud-ready, we are able to deploy and effectively manage our registry to a variety of infrastructure configurations — traditional data centres, public or private clouds, as well as hybrid environment.

The Substance

The software and the infrastructure on which it is hosted work in tandem.

Systems that were not written with cloud based environments in mind will generally make many fatal assumptions leading to impedance mismatch that manifests as teething problems, security issues and prolonged outage when planted in such environments.

All too often, we hear software engineers make remarks like “it runs in the LAN, so this operation should be snappy”, or “server is behind the firewall, so we’re fine”. At Cloud Registry, we live by Murphy’s Law and practise Defense in depth. Our platform was written to be secure and resilient to failure.

Another negative outcome of impedance mismatch between infrastructure and software is the lack of scalability. While cloud infrastructure generally provides on-demand computing resources, monolithic software cannot take advantage of the dynamic resource availability. Again, our platform was carefully designed to take full advantage of cloud computing environment by having loosely-coupled components. Each component has a well-defined purpose, and may be duplicated giving rise to immense scalability and eliminating single points of failure.

The Silver Lining

For new gTLD applicants and ccTLD operators — our clients — you stand to benefit directly from our know-how, technology choices and our awesome platform. More tangibly, it translates to more control over your TLD, better service, more features and increased readiness to respond to market needs at a great price.

Ultimately, we are here to help you succeed by reducing friction and giving you the tools to complement your business model and policies so your TLD can fly!