It's interesting to note the staffing concerns that you point out.ICANN stated
that it felt that the pool of available talent was limited in our case, and then
praised Afilias for having a great pool of talent. This flies in the face of reality.
In
the case of Afilias, where are they located? To my knowledge, they've not stated
where they will locate themselves. How can they hire people, not knowing where they
will be? IOD is in San Luis Obispo, California, which is equidistant between Los
Angeles and San Francisco. Many of our contractors live in San Francisco and commute
to San Luis Obispo to work for us. We compensate them accordingly, and none have
complained so far. Where will Afilias's contractors have to go?
We identified Cal
Poly SLO as a pool of talent. ICANN presumed that we meant to use them for our top-level
staffing. This is not only unrealistic, but one must question the evaluators who
would think this. Cal Poly will provide us with more than enough customer service
personnel, as well as entry-level IT staff. This is a proven fact. For our higher-level
staffing, we will hire from out of the area. I already have many top-notch networking
and development professionals who have indicated that they wish to accept a position
with us. Since we've put a small jobs list on our web site, we've received inquiries
on just about all of them, and multiple ones at that.
It is unrealistic to presume
that just because Afilias is comprised of 19 companies with competant staffing, that
Afilias itself will benefit. Does anyone actually believe that Register.com will
allow their head of IT or their CTO to quit and become an Afilias employee? With
member companies all over the world, they'd have to travel extensively. More likely,
the member companies will loan out their employees on an as-needed basis. That's
called contracting, and it's exactly what IOD is doing now. We have contractors performing
most of the critical tasks, and quite a few of them wish to turn their contracting
positions into full-time positions as soon as possible.
Had ICANN actually asked
us about this, rather than just assuming the worst (as they appear to have done in
almost all cases), it would have been clear.
Why would ICANN's independant reviewers
presume the best in the case of the other applications, yet presume the worst in
the case of ours? I'm not making this up, read the evaluation for yourself and you'll
see. Can someone explain this to me?
In each and every case of criticism, we have
shown that it was based on error or erroneous assumption on the part of ICANN.
In
all cases, these asumptions are presented as fact, when they are nothing more than
opinion, and there's no documentation to back it up. Where is the Arthur Anderson
report? Where is the write-up from the actual technical reviewers that were listed?
Is
this fair?
Christopher Ambler