.net award

["Cross Fire Sales" <xfire_sales@xxxxxxxxxxx>]

After spending some time reviewing the proposals from the five bidders, I
thought I would post a few various observations:


1.  CORE++ seems like awfully nice fellows, but after reading their
proposal, I would have to guess that George W. Bush has a better chance of
being elected President of France than CORE++ has of winning this
procurement.

2.  There seems to be a prevailing theme, especially from Afilias and DENIC,
that if a bidder does not currently manage 5 million-plus names, they should
be eliminated.  It is certainly understandable why they would feel this way,
but in my mind, it doesn't hold water.

Any company with even *modest* technical staff/resources can build a
database to store 5 million domain names and their associated contact data
(depending on whether one is proposing thick, thin or both).  The trick is
being able to build a registry and database that can store the volume of
data, *AND* meet strict performance criteria.  In DENIC's case, while they
certainly have an impressive number of names under management, they
currently operate an asynchronous, e-mail based registration system.  For
those of you scoring at home, that means they haven't proven diddly from a
performance standpoint.  They don't currently operate an EPP or RRP-based,
synchronous system under the duress of high volumes (as one would expect to
find in the .NET space) and high-performance SLA's.  Sure they claim they
are going to build one for .NET (or that they are currently building one),
but either way, for ICANN to hand the keys to a company that hasn't proven
they can operate at that level is a decision fraught with peril.

As far as Afilias goes, sure they have a good number of names, and sure they
claim they perform well within their SLA's.  But if one peeks beneath the
covers, they will note two things:  A) their SLA's are not very tough to
meet for the volumes they currently generate with .INFO and .ORG, and B) if
anyone can makes sense out of how they actually calculate their performance,
then you are way smarter than I (and I have an MBA).  They do some kind of
funky sampling every five minutes, which means their performance could be
awful 48 minutes out of an hour, but if it looks good the 12 times they
"ping it" (for loss of a better term), well hey, all is right with the
world.

3.  Speaking of Afilias, their bid appeared to be thrown together, some sort
mix between a cut and paste of their .ORG proposal, with various and sundry
edits injected to make it .NET-centric.  Well, someone should fire their
proof-readers.  How a company can pay the money they did to bid on .NET,
only to have their proposal laughed at due to grammatical and typographical
errors is quite hard to believe.

Certainly I understand the time frames between RFP draft, final and due date
was short, especially for a procurement of this magnitude.  However, I read
all five proposals, and I did not see any of the same kind of typo's in the
other four proposals that I found in the Afilias proposal.

Someone did call them on it, and they answered that there was a "text
conversion error".  Forgive me, but what?  I believe all bidders had to use
the same mechanism to submit their bids (a web form, I have been told), and
no one else had this problem.

Here's an example:  In section 5b.xi "Escrow", subsection III, Afilias
writes:

>>>>>>

"All data submitted by registrars is in XML format.  This data is encrypted
using OpenPGP as documented in RFC 2440
[http://www.ietf.ORG/rfc/rfc2440.txt]), and sent to the secure servers of
the escrow agent. In addition, full native database dumps, which are in SQL
format, are similarly encrypted and sent to the escrow agent.
Should the data format specification from ICANN change, Afilias is prepared
to adjust accordingly.

DO WE NEED TO ADD IN THE NATIVE FORMAT DATABASE BACKUP REFERENCES IN
APPENDIX
R?"
<<<<<<<


I'm sorry...was that question for me?  Sure guys, go ahead and add that
native format DB backup to the references in Appendix R. :=)

Certainly looks like that text converted ok, doesn't it?

Anyway, my goal here was not to embarrass anyone, but more to point out that
if a potential operator can't take the time to ensure their bid is
proof-read and tight when submitted, how can they be trusted to run
something as important as .NET?  Maybe I'm just old-fashioned, but I'm the
kind of person who believes sloppiness breeds sloppiness.  So to Afilias, I
say "pass".

Which leaves VeriSign and Sentan.

4.  VeriSign is strong technically, no doubt.  Operationally, they have run
.NET well.  However, given how dreadful they are in other areas (awful
customer support, lousy internet citizens, lack of compliance with ICANN
policy), I would just as soon see Vint run this thing in his basement than
it go back to VeriSign.

So that leaves Sentan, the NeuLevel/JPRS combo.  NeuLevel has had their
issues, but overall has been a pretty decent operator of .BIZ.  They don't
have the # of names that Afilias does, however, they also didn't have the
"buy none, get one free sale" that the .INFO folks offered last year.  They
have the strictest current SLA's of any of the bidders, and have performed
well against them.

JPRS has been a model citizen.  They are heavily involved in ICANN policy
groups, and are well respected throughout the internet community.

And of course, there is competition.  If VeriSign loses .NET, they still
have the 800-pound gorilla in .COM.  Competition is good for the industry.
Sentan seems to have laid out a fairly sane transition plan, which requires
very little assistance on the part of VeriSign (which is probably about all
anyone is realistically going to get from them should VeriSign lose).  ICANN
cannot be afraid of this transition, nor can it be afraid of the threats of
lawsuits from the neighborhood bully.  It will take hard work and effort,
but it can be done without impacting end-users, and therefore has to be
done.

One vote for Sentan.

Best wishes,

Maggie Lambrechts
Camden, NJ