Re: [gnso-vi-feb10] J-Team, some comments

[Eric Brunner-Williams <ebw@xxxxxxxxxxxxxxxxxxxx>]

J-Team,

Like Tim I have some observations, previously made to Jeff Newman
off-list. I'm recycling the electrons, the point numbers refer to
Jeff's original, with corrections.

#1 leaves VGRS free to compete (and quite possibly dominate) the
registrar markets for all-but COM/NET/NAME. This revises the original
VGRS/NSI divestiture allowing a re-merged VGRS+NSI to retain its
legacy registry market, and all but that legacy registrar market.

If this is a good policy choice now, why wasn't it a good policy
choice then?

BTW, I distinguish between 87% and 2%, so I'm open to a rule set for
circa 2000 market survivors, and a rule set for circa 2010 market
entrants, and even a .5 rule for the tweenies.

#2 Community-based (Cb) There is no mention of the current cap, so
I've no way to know how many Cb registries need to agree to form a
cooperative registrar, as an alternative to your 30,000 direct
followed by the competitive registrar regime.

I wish you (and others) would acknowledge that while the one-at-a-time
start-ups registries in the past made N x CAP registry owned
registrars impossible, ICANN's plan of record is that many registries,
many more than N x CAP, will be starting each quarter, beginning in
the 4th quarter after applications are accepted. Therefore the current
CAP (at anywhere between 11.2% and 15%) allows cohorts of Cb
registries to operate without any change in the current rules.

The case you are making is for Cb registries that are so ideosyncratic
that they can't find a club that will let them in, say the "community"
of admirers of William Edward Hickman (Ann Rand's John Galt character
in real life).

If you want to solve that problem, fine, but all of CORE's Cb
applicants are happy with sharing the costs, and the benefits, of a
cooperative registrar as either the only registrar available to their
registrants, or as a registrar that competes with other registrars for
their registrants.

My point is, you're solving a non-problem, cooperation has real
benefits to the registries, and to the registrants, and reduces the
odd-EPP-edge-cases problems significantly.

The registry self-sale model allows all sorts of registry-unique and
generally unnecessary EPP wart stupidity, which we're only just now
getting around to addressing in the circa-2000 to circa-2006
registries. If you really want to test the
let-a-bunch-of-thistles-stick market, free them from having to use
EPP. If they elect for various colored carrier pigeons when they're
small, they won't be switching over to EPP at the 30,001 mark.

#3 retains the equal access language currently in place, which is to
say, we are silent on the "900 registrar" phenomena. I don't think we
should be, we didn't create this mess, we're not looking forward to
the 2pm drop pool being real or interesting for much more than what it
is now, and its not our fault that ICANN staff has allowed this
situation to come into being.

I'm not making this point so much because I'm concerned about Enom's
and Snapname's and Directi's and Dotster's fleets of paper registrars,
but Staff has advanced "900 registrars" to harm our interests, and I
don't want to own any part of their failure to police registrars, or
even understand fundamentals. It is not enough that the "registrar"
has valid current paperwork from ICANN, it has to do more than provide
threads to the secondary market actors.

#4 the definition of an RSP is so broad that it includes an ANYCAST
instance operator, or a WHOIS pretty-printer, or ... heck, it may even
cover CORE's accountant.

The proposal would allow CORE to be a registrar for .cat and .museum,
which we don't currently, so this is a less restrictive condition than
we've chosen.

Again, the question is why are we here? The RSP is unencumbered from
being a registrar to any, and I'll invent a term so that I don't
inadvertently mean something like affiliated or ..., foreign registry,
so we can't be concerned about the viability of the RSP as a
registrar. So why are we concerned about the viability of the registry
absent the RSP acting as a registrar, within the bounds of conditions
4(a) and 4(b)(1)-(5)?

Why do we care?

Now lets suppose the RSP is the DNS provider for the RO. You've
created barriers for the information the RSP could obtain from the RO,
basically, everything from the provisioning path, but not for the
information that it obtains from all of the registrants, and therefore
all of its registrar competition, about use, and non-use. You've not
addressed the publication path. How does this permission prevent the
RSP from monitizing solely all of the RO's common registrar data?

If the RSP-as-registrar can completely enumerate the zonefile,
minutes, hours, or days before any other registrar, what is to keep it
from frontrunning? From any other predictive behavior activity for
which it has a significant, equivalent to the RO's own knowledge, but
through post-publication means, advantage over all other registrars?


I suggest putting a cap into your #1, somewhere between the NeuStar
and Afilias numbers and Verisign's, since it is unlikely that either
or NeuStar or Afilias can easily change the registrar market dominated
by GoDaddy, Enom, TuCows and NetSol.

I suggest dropping #2.

I suggest adding some more-than-paper-registrar condition to #3.

I suggest dropping #4.

Eric