ICANN ICANN Email List Archives


<<< Chronological Index >>>    <<< Thread Index >>>

More comments on "Revisiting Vertical Separation of Registries and Registrars"

  • To: crai-report@xxxxxxxxx
  • Subject: More comments on "Revisiting Vertical Separation of Registries and Registrars"
  • From: Eric Brunner-Williams <ebw@xxxxxxxxxxxxxxxxxxxx>
  • Date: Fri, 05 Dec 2008 22:33:49 -0500

My previous note covered five critical comments about the CRAI-1 model. Here I try to be more positive about the model, or differently negative.

1. We have the $75,000 per year number for the recurring ICANN fee, in lieu of the $0.20 per domain fee for most, but not all, of the gTLD contracts. This number looks wicked high if we think of the CRAI-1 model as a defensive buy, or a vanity buy, and absurd, but tolerable if a brand management buy, and by the time we get to a large trade union and its membership, we get down towards the $0.20 price point.

But is that as big as it gets? Suppose Google "inverts" its search engine, and under .google, a CRAI-1 entity, dumps gazillions of search strings into its name space, and not just today's search strings, but yesterday's, and the day before's, and so on. At this point the per-leafnode cost for Google's tree is wicked close to zero, and everyone's eyes are glazed. But is the value of all of those leafnodes zero?

At present, the PPC model works by populating jay-random tasted, or otherwise trafficked nodes, and here's the key point, pre-existing, mostly static content or templated garbage nodes, with tasteful Google ads.

Why should Google searches result in anything other than links to .google nodes with all content created on-the-fly?

So I think there are ways to make a great deal of money gaming the single-registrant-with-flat-fee model and we shouldn't assume the CRAI-1 model is just corporations giving email to employees or managing product CRM.

2. We have the claim in the CRAI paper that the registrar cost is an inefficiency, which I read as the authors of the CRAI-1 model can't think of ways to use the DNS to make product with a per-node/per-year value greater than the margin charged by the large, highly automated registrars. That's point #3 of my prior, unreservedly critical note.

I suspect that there are applications that require a clean namespace that have a greater per-node ROI than $1/yr, and since these are clean namespaces, PPC is obviously not the application. Actually I'm sure of it, so much so that I don't see the registrar margin as a fatal defect to the application, and the registrars do market the application, not for my value, or the registrant's value, but for the value of their dollar margin.

3. While its simply insane to imagine, as the CRAI-1 authors did, that an entity could usefully attempt "information security" by not allowing 3rd party disclosure (and the notion that Corp X, mortal competitor to Corp Y, would become ICANN accredited, and pass Corp Y's OT&E, for the purpose of garnering critical information through node add/mod/delete commands, is the most creative exercise in ICANN fiction ever), it is easier to introduce DNSSEC without gTLD registrars for whom the Y tld and all its private hoopla, key management inparticular, is a distraction from the DNSSEC-free-forever COM honey pot.

There actually are rationals other than registrar disinterest to want to be able to impose some coherent policy recursively. Suppose the contrary. Suppose the registry has no policy control except over second level domains, but not recursively. The only "safe" outcome is a flat namespace full of hyphens and driven by search engine key words rather than recursive descent on standard label taxonomies. That way lies HOSTTABLES, and we engineered our way out of that a long time ago.

4. "Corporate TLDs" will be a bonanza for consultants, and while they will have an adverse affect on the IANA root's ability to accommodate future for-profit and non-profit public services, point #1 of my prior, unreservedly critical note, the current recession in the dollar and euro zones will be at least as destabilizing on the market as the bubble bust at the beginning of the decade.

A problem the CRAI-1 author overlooked is what is the correct metric to vet a would-be-registry-operator for the typical CRAI-1 class of on-going operations? At Rome I pointed out to that Board that we who drafted 2000 round applications, and .net and .org redel bids, were forced to lie about the actual capitalization and the actual capabilities of our organizations in our bids, and less fiction would (a) make application drafting less expensive, (b) make application evaluation less expensive, and (c) increase the honesty of the system, each of which would probably be a very good thing.

So does a defensive buy have the same registry-operator requirements as a brand buy? How about a provision-the-products-and-employees buy? How about a vertical application with a sparce, but highly secure tree? How about a wicked bushy tree with no added bells and whistles, other than the minor nuisance of being able to on-the-fly create custom content at bazillions of leaf nodes? It seems to me the real requirements range from the original .museum kitchen table PC to VGRS's Atlas platform.

The CRAI-1 model is a mix of good and bad, sold as unleavened good, as consultants usually do. A bazillion soap and cereal labels stuffed into the IANA root would leave us all looking at the Google keyword API like it was the next best thing, and our discomfort would not cost a moment's sleep for the scores of people who would have made a killing "helping" brand managers move into the best ad buy ever.

Eric Brunner-Williams
Disclaimer: I work for CORE Internet Concil of Registrars as CTO, and I have to plan for both possible outcomes, so read my comments with those interests in mind.

<<< Chronological Index >>>    <<< Thread Index >>>

Privacy Policy | Terms of Service | Cookies Policy