Hacker News Reader

Comment by robalfonso | Hacker News Reader

Its great that google is open sourcing this, however, its a bit curious as anyone who is going to be operating a registry really has the resources and expertise to manage this kind of thing (both hw and sw). Unless the end game is to get big resource users (like registries) onto GCE, its a bit odd.

View on HN

It is a bit odd, but I have friends in African countries with TLDs that need to be registered via paper forms / GPG-signed emails only.

This move by Google just massively simplified the barriers to entry for small countries running their own ccTLDs in a more modern way.

(I work for a registrar, dealing with ccTLD idiosyncracies all day. If more registries adopt common premium price extensions, etc, it will make my life a lot easier, too.)

I work for a registrar as well. You are right, I hadn't considered ccTLD's What I find really insidious about ccTLD registries is the crazy rules they have (and therefore the crazy business rules I must use to support them) this doesn't fix that, but as you pointed out it might help some of those small ones that are otherwise out of luck.

Well, unlike gTLDs, ICANN have no control over what ccTLD registries do. Personally, I much prefer dealing with ccTLD registries who behave like gTLD registries (.me, .co, &c.), but those are few and far between.

Smaller ccTLDs are unlikely to use this though: it makes more sense for them to contract out the technical side of things than run their own, with .cm being an example of a registry that shouldn't run their own infrastructure.

Incidentally I find that to be a smart business move for them as well. I mean if you behave like a gTLD you integrate much faster than say .es where you have all kinds of offset rules you must apply to their expiration or .nl who give you a one day window to renew!

You'd think that, but trying to convince registries to go down that route is head wrecking.

And then you have the likes of the .ie domain registry (IEDR) who use their own vaguely EPP-like protocol that works nothing like normal registries with a set of needlessly bizarre policies specific to them.

Ugh.

There's one big obvious advantage of open source registries, from the perspective of registrars: You can look at our source code and figure out exactly what we're doing.

You'll be happy to know that we support Gavin Brown's fee extension: https://tools.ietf.org/html/draft-brown-epp-fees-00

The implementation is here: https://github.com/google/nomulus/tree/master/java/google/re...

And a sample domain create EPP message with an attached fee from our test suite: https://github.com/google/nomulus/blob/master/javatests/goog...

Can I just say, anyone who uses the fee extension over crazy price api's or downloaded lists is my friend!

Yup! And I wish the likes of Rightside would scrap their extension and just use Gavin's work.

We support downloadable static premium price lists too (it's all that some registrars can handle), but yes, obviously we prefer the price extension too. Here's the entry point into the static premium pricing lists if you're curious: https://github.com/google/nomulus/blob/master/java/google/re...

Said lists are imported into the system from the CSV file format that is given to registrars by this command-line tool: https://github.com/google/nomulus/blob/master/java/google/re...

By the way, can I just say as an aside, that it's so awesome that I can finally link to and discuss our code in the open (I wrote this pricing stuff under stuff).

From my experience, that's the most common fee extension. Thanks!

I saw that donuts has a test EPP endpoint to try nomulus. I will probably connect to it soon for some integration testing.

My only issues when using this extension:

* It's super flexible. I have to guess if a fee is an EAP fee based on the description, for example. (Registries haven't standardised on anything.)

* Querying for all operations * terms is very verbose.

* The extension itself has multiple versions. We support fee-0.5 - fee-0.8.

> anyone who is going to be operating a registry really has the resources and expertise to manage this kind of thing

Broadly speaking, this only holds true for a limited number of large legacy gTLDs (e.g. .com, .net) and the largest ccTLDs.

Not in practice, the reality is most of the new gTLD's went shopping for industry people - you have to, there are so many unique technical, regulatory, and industry specific items you just buy the expertise, trying to learn on the fly is a monumental task.

FYI, speaking of industry goings-on: http://finance.yahoo.com/news/donuts-collaborates-googles-ne...

I should clarify at this point that I am the author of original linked blog post.

Can we imagine new gTLD Entrepreneurs with a minimum technical knowlege to become their own back-end Registry AND Registry in round 2 of the ICANN new gTLD program?

OTOH, one of the justifications for why domains cost $7 instead of $2 is all the quadruple-redundant Oracle databases and such that Verisign uses. If a registry can be built cheaper it argues for lower prices.

I disagree. The com/net zone is 144mm records, thats about a billion dollars per year in revenue. The technical requirements to store 144mm records with metadata and have multiple redundancy, backup datacenter failover etc. does not come close to that in costs even if those costs are 10%. The cost is completely divoriced from the technical requirements, its simply what the market bears and is use to. They have momentum on their side.

Some of the new tld's are very inexpensive right now, but that is only the short term business model to get market share. Their renewal prices are often higher and will stay that way.

Besides the post of rdrey, this is also a nice PR/marketing move targeting the open source community.

Registrars.

That is the goal. This runs on App Engine, Google's PAAS, if the Java lock-in is anything like the Python lock-in I have experienced this won't be very useful outside of their infrastructure. At least not without a major rewrite.

Reply on news.ycombinator.com