Single character domain allocation process

ICANN is establishing a forum on allocation methods for single character ([A-Z0-9]) second level registrations in the gTLDs.

There are 16 gTLDs that have single character registrations restricted, of which .COM, .NET, and .ORG have only six registrations within that predated the rule to establish the restriction (q.com – Qwest, x.com – Paypal, z.com – Nissan, i.net – Oxide, q.net – Q Networks, and x.org – X Windows open source).

 The net result of the current process could allow for a thundering herd of registrants clamoring for these domain registrations, or there could be an auction process introduced to accomodate the process, should there be a change from the status quo.

More here at ICANN’s Website

Three new TLDs in the Root: .KP, .ME, .RS

Please welcome North Korea (aka Korea, Democratic People’s Republic) (.KP), Montenegro (.ME), and Serbia (.RS) to the root zone.

Delegation was approved at the recent Special ICANN Board of Director meeting on September 11.

My compliments to Kim Davies and David Conrad at IANA on a smooth process from board approval to root addition.

It appears that the zones were added to the root, but the IANA whois does not yet list the administrative entities for these published yet.

.KP was delegated to “Korea Computer Center”.

.RS and .ME are going to be replacements for the former .YU namespace (formerly Yugoslavia – and YU left the ISO3166-1 list), with a 2-3 year responsible transition of that namespace as .YU is sunsetted. .RS is to be operated by the same adminstrator of the .YU ccTLD.

New TLDs – What’s Your Idea?

What are your ideas for new top level domains?

Because of my tenure in the namespace market, I have the privilege of being a person that folks trust for open feedback on their TLD applications for the upcoming rounds next year.

I’ve heard or seen over 50 different pitches or business concepts at this point for new TLDs.
Some are great and have a ton of commercial appeal, some are not bad in that there is a good premise behind what they provide as an experience for the end user, and some are not going to get over a thousand registrations in their lifetime (and they’re good with that).

Lots of duplications…   Of the over 50 that I have seen, there’s 1 that I have seen 4 separate potential applicants for, 2 that  I have seen triples of, and 9 that I have seen duplicates of, and the rest are individual strings.

Great minds think alike, and I am certain I have not seen every application out there.

I know most every registry platform, the various providers who outsource these capabilities, and technical requirements for resolution and registration services, and also understand the registrar channel well, because I have operated registries and registrars.

If you are a person could benefit from a chat, I’ll put it out there that I am discretely reviewing these on a pro-bono basis, and am glad to offer any feedback privately.

Registry Failover Planning Should include Registrar Provisioning

I commented on a public document.   Let me be more specific…

Recently, there has been some talk over what a registry failover would need to look like, in the event that a new registry provider would need to be designated.

As new Top Level Domains (TLD) are introduced, many of them include failover testing or have described their disaster recovery plans, but these typically are focused upon natural disasters or acts of god, etc.

It is vital infrastructure, to be sure. As vital as the number of registrants or users that utilize the TLD, at least.

I spent some time reviewing the current registry failover plan, and noticed that it was very well written and prepared. I commend ICANN staff for their very thorough and hard work.

The place where I commented about perhaps adding some specificity is in trying to ensure that registrars can quickly unplug and re-plug their connections (and I am super-oversimplifying the actual process) to minimize registrant impacts for domains under management.

I’d also note that the likely driver of this document was not natural disaster or act of god, but rather the potential financial failure of the publicly-traded parent company to the registry.

While the circumstances that were likely driving the urgency of this planning have been relieved in the near term, this is an important proactive measure to ensure that effects to the namespace and users are minimized to the fullest extent, and then all of that security and stability is present in transition.