ICANN ICANN Email List Archives

[gnso-vi-feb10]


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

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

  • To: "'randruff@xxxxxxxxxxxxxxx'" <randruff@xxxxxxxxxxxxxxx>, "'ebw@xxxxxxxxxxxxxxxxxxxx'" <ebw@xxxxxxxxxxxxxxxxxxxx>, "'Gnso-vi-feb10@xxxxxxxxx'" <Gnso-vi-feb10@xxxxxxxxx>
  • Subject: Re: [gnso-vi-feb10] J-Team, some comments
  • From: "Neuman, Jeff" <Jeff.Neuman@xxxxxxxxxx>
  • Date: Tue, 6 Apr 2010 16:20:14 -0400

I believe the safeguards I put forth in my proposal along with a meaningful 
sanctions program against the registry, registrar and its afiliates engaging in 
this behavior will go a long way.
Jeffrey J. Neuman, Esq.
Vice President, Law & Policy
NeuStar, Inc.
Jeff.Neuman@xxxxxxxxxxx


________________________________
From: owner-gnso-vi-feb10@xxxxxxxxx
To: 'Eric Brunner-Williams' ; Gnso-vi-feb10@xxxxxxxxx
Sent: Tue Apr 06 16:08:04 2010
Subject: RE: [gnso-vi-feb10] J-Team, some comments

To Eric’s point:



>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?



Here is the question...  If we can resolve the issue that Eric so clearly 
stated, then we can resolve the task of this WG.  Until such clear examples of 
gaming can be addressed – knowing gaming will occur wherever it can get a 
foothold – consensus will be difficult.



I’d like to add this key issue to the gestalt of information that the Proposers 
are putting forward.



RA



Ronald N. Andruff

RNA Partners, Inc.









-----Original Message-----
From: owner-gnso-vi-feb10@xxxxxxxxx [mailto:owner-gnso-vi-feb10@xxxxxxxxx] On 
Behalf Of Eric Brunner-Williams
Sent: Monday, April 05, 2010 6:26 PM
To: Gnso-vi-feb10@xxxxxxxxx
Subject: Re: [gnso-vi-feb10] J-Team, some comments





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


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

Privacy Policy | Terms of Service | Cookies Policy