On Tue, Aug 28, 2001 at 07:31:17PM -0700, Cameron Powell wrote:
> John Payne writes:
> "Not the kind of discussion you're after, but I would like to know
> "a) Why this is not on biz-ops rather than discuss-list
> "b) How snapback avoids abusing the registry, but can still scale to the
> volume you need to remain a viable company. (and simply spreading the load
> across various registrars does not count as avoiding abuse, as it won't
> scale)"
>
> a) To my knowledge, we are on this particular part of the list because
> Elliot Noss, who was kind enough to let us begin this discussion, asked us
> to post to this part of the list. If you think this discussion should be
> posted on the biz-ops list, please let us know. We'd be happy to take the
> conversation there if it's appropriate.
Well, I see snapnames in the same light as people selling services to
integrate opensrs code into resellers systems. Those integrators are
asked to keep discussions on biz-ops. I'm just surprised that snapnames
haven't been.
> b) The way we have remained a viable company is by, among other things, (1)
> never abusing the Registry, (2) never, in 9 months of operation, even
> receiving a warning or any other negative comment from the Registry on our
> methods, notwithstanding very frequent contact we have with them. How do we
> avoid abuse? We always stay within the number of connections allowed. When
> our understanding was that there was an unwritten rule of 250 connections
> per registrar, we stayed at 250, even when some others were grabbing
> multiples of that (see June 11, 2001). When the Registry lowered the number
> to 200, we stayed below 200. And now at 50, we help each of our registrar
> partners run technology employing 50 connections. No matter what the
> maximum number is, our consortium of registrars will always have more than
> any registrar acting alone. This volumetric superiority does in fact scale,
> because our volume is always greater and it's always, by definition, within
> the Registry's guidelines at the same time. This will still be true even if
> more solo registrars try to get involved and the Registry feels it must
> lower the maximum number of threads for batch-processing to below 50.
So you will use up the maximum number of sockets per registrar.... to the
exclusion of all the other customers of that registrar? And to guarantee
yourselves access to the registry, you'll use up all the sockets from a
large number of registrars, so that any point you'll have more sockets
into the registry than anybody else? Is that what you're saying? How
does that scale?
> At least as importantly, no one uses their resources as efficiently as our
> partners. All other registrars who attempt to play this game solo do so on
> behalf of a few high-paying customers. It has not been concealed from us or
> our partners that ICANN and the Registry prefer our method of serving the
> maximum number of customers, democratically, per connection, rather than
> those who use the public good that is ICANN-granted connections to the
> Registry to serve a few (speculators).
>From the outside point of view, it seems that ICANN and NSI/Verisign will
prefer whatever method people pay them to prefer. I'm not implying anything
about snapnames there... just that neither ICANN nor Verisign have the
good of the Internet as their top priority.
> Because no other model is as efficient, no other model is as scalable or
> will be as capable of avoiding inviting further Registry regulation.
> Furthermore, some registrars have been competing only by violating their
> ICANN and Registry agreements (including by allowing third parties to run
> scripts through them; see related thread). As we continue to add legitimate
> partners, and build a technology consortium of all registrars, the
> competition will continue to fade. The consortium has more connections to
> the Registry than any individual registrar could ever amass, which pleases
> our partners, and uses its resources in a highly efficient manner, which
> pleases the Registry and the mass market of customers.
Your model is only scalable if you are the only company trying to use
the Registry. You cannot scale simply by adding registrars to bypass
technical restrictions. There is a *reason* there is a limit to the
number of sockets per registrar. A reason you seem to be happy to
overlook.
> Again, all this would merely be a competing theory if we did not have the
> numbers to back us up. Today we are on track to receive another 1000
> SnapBack(tm) orders, at $49 each. These orders come to us at conversion
> rates (a measure of the value proposition to customers) of up to 9%.
> Efficacy on back-orders is historically 76%. And so our rate of repeat
> customers is very high and RPMS for SnapNames often exceed $3000 ($3 per
> click-through).
You know, the more you the more you sound like a usenet or e-mail spammer
trying to justify themselves. They abuse resources to their own benefit.
They try to use numbers to justify what they are doing (granted, they lie
about numbers, and I'm not accusing you of that).
I DON'T CARE WHAT YOUR NUMBERS ARE. I ONLY CARE THAT I CAN GET A SOCKET
TO THE REGISTRY WHEN I WANT ONE. I don't want to have to explain to my
customers that they couldn't register a domain because we couldn't get
access to the registry due to someone else using up all the resources.
I just want my customers to be able to register domains when they want them.
> There are very good reasons we weathered the simultaneous drop of the domain
> market and the investment market, and that we have the partners and
> interested partners that we do, and that, after due diligence by numerous
> major investment banks, we will quickly raise another round in coming weeks:
> there's a shortage of smoke and mirrors here. I look forward to continuing
> the dialogue to give you whatever information we're able to give in order to
> answer your continuing questions.
Fine, just keep the marketing BS out of the conversation.
--
John Payne http://sackheads.org/jpayne/ [EMAIL PROTECTED]
http://sackheads.org/uce/ Fax: +44 870 0547954
To send me mail, use the address in the From: header
