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!