It took a while, but I finally nagged ICANN Board Chair Vint Cerf into taking time out from his travels to sit down and reply to questions selected from those submitted by ICANNWatch readers. You can read our earlier discussion thread concerning what questions to pose here with more here; and you can see the perhaps too-long list of questions I sent Dr. Cerf. "I had time to answer some, but not all," he writes. Recall, as you read this, that these questions were posed a several weeks ago - a few things have changed since then.
Dr. Cerf's answers, unedited in any way other than formatting, are inside.
1. Technical coordination?
ICANN describes itself as a "technical coordination body"; it has now
been operating for close to two and a half years. In that time, what has
ICANN accomplished that is actually technical? And -- out of the total
human-hours ICANN's staff, officers, and board of directors have
expended thus far -- please give a rough guesstimate of the percentage
occupied by enacting those technical accomplishments.
My interpretation is that ICANN exercises its responsibilities in a
technical framework - that is, its decisions are guided by the standards
of the Internet, specifically those related to the Domain Name System
and recommended Internet Address allocation practices. Most of ICANN's
work is aimed at assuring that agreements it reaches with address and
domain name registries and registrars are consonant with technical
standards. In the course of striking these agreements, many other issues
of practice and procedure have to be documented as well, but the core
purpose of the work is to assure that these practices and procedures are
consistent with the technical recommendations of the IETF and IAB and
the recommendations of ICANN's supporting organizations.
All of the IANA activity is essentially technical and it is instructive
to read agreements with registries, for instance, to find how much
is technical specification. See http://www.icann.org/tlds/agreements/verisign/
as an example.
To the extent that consensus development is largely about technical
policy, that, too is a technical activity. The one area that isn't
purely technical has to do with the development of funding models
and agreements for their implementation. Of course, the end-result,
funding, is used to support ICANN's technical coordination role,
as is outlined in the founding White Paper (which is worth referencing
if you've not had an opportunity to read it).
I would very much like to know what 'consensus' means in ICANN's
terminology. Is ICANN seriously attempting to 'govern by consensus'?
There's lots of talk to that effect, but really -- is ICANN trying to
develop consensus about, say, the Verisign deal? How can that possibly
happen in the 10 days or so before the ICANN meeting in Melbourne? In
general, do you think that ICANN gives anywhere near enough time for
consensus to be devoloped on important policy questions, and, if not,
shouldn't we conclude that it is not serious about the consensus model?
Based on the very helpful inputs from interested constituents at the
public meetings of ICANN and through email exchanges with its supporting
organizations, the VeriSign/ICANN agreements underwent some significant
changes. In my view, that represents a practical exercise in adapting
agreements to comport with consensus. Because consensus is not
necessarily unanimity, there can always be disagreement about the degree
of consensus reached. I believe ICANN staff and board are working
diligently and with good faith towards community consensus on practices
3. Role of Supporting Organizations?
What are the proper roles for the Supporting Organizations in creating
policy, the Board in recognizing consensus policies, and the Staff in
implementing those policies? At what point does an implementation detail
become a policy issue that itself should be referred back to the
relevant Supporting Organization for review or approval?
There can be varying views as to what is policy versus something that is
an implementation detail and I'm not sure one can establish very simple
definitions. The Board has the responsibility for determining what is
policy, in its best judgment and conveying that to ICANN staff. The
Board has sought and continues to seek input from the appropriate ICANN
supporting organizations when matters it considers to be policy-related
arise. Ultimately, the Board has fiduciary responsibility to ICANN and
to the community for establishing policy. The Board has followed DNSO
recommendations on all policies discussed (such as UDRP and the scale
of new TLD authorizations) for example. With time and effort, I hope
that ICANN policies will be well-enough defined and documented that
the Board will not be required to determine policy very often and
that the staff of ICANN will have sufficient policy guidance to be
able to implement the policies without uncertainty. That will take the
concerted efforts of all the support organizations and the board.
4. Overhaul DNS?
I may be painfully stupid, but it seems to me that DNS itself needs an
overhaul. hostname.domain.TLD is just not human enough for the needs of
the general populace. Why not invest all this time, effort and money in
coming up with a truly novel "proof of concept," i.e. natural language
addressing on the Internet. There have been some feeble stabs at it by various
search engines and directories, but for it to really work would take the kind
of orchestrated research effort that a body like ICANN could sponsor and
help along. Wouldn't the Internet be a lot better off without the squabbling
over gTLDs and trademarks and the like, and with the ability for the
user to type "The Wall Street Journal" or "Grameen Bank" or "Yahoo!" into
their browser and get a web page in return?
I am a strong proponent of exploring new directory-oriented ways of
finding information in the Internet. I would also recommend review of the
presentation made by IAB Chairman, John Klensin, citing some of the very
difficult technical challenges posed by trying to adapt the DNS to work
with internationalized domain names. DNS identifiers are NOT intended to be
"language" but they are interpreted that way and in some sense, that is
part of the problem. The indirect addressing aspect of DNS has been
a very important feature of Internet's architecture so something like
it is almost certainly still going to be necessary to provide that
ICANN staff have repeatedly indicated that no amendments to the proposed
Verisign contracts are possible. In fact, though, when the last set of
contracts between ICANN and NSI were adopted, in November 1999, they
were changed in response to public comment. Why are the new contracts
As should be clear by now, though staff had no reason to believe
that there could be further compromise, it proved possible to make a few
more amendments to the proposed agreements, as suggested by inputs from
the ICANN supporting organizations. There were no guarantees, however,
that such changes could be agreed. In negotiations with VeriSign leading
up to the draft proposals debated and ultimately approved by the Board,
VeriSign indicated that no further changes were possible and that was
the origin of the observation made by ICANN to that effect.
Along the same lines, you have stated that it would be impossible to
negotiate an extension to the current May 2001 divestiture deadline to
allow the Internet community to comment on these contracts on a
reasonable timeframe. Is that because Verisign would not agree to such
Verisign states (in Stratton Sclavos's 2/28/01 letter) that you have
committed, if the Board does not accept the proposed contracts, to "seek
formal Board approval for an appropriate extension of the [divestiture
deadline] under the existing agreement." If Verisign will be seeking an
extension of the deadline if the proposal is rejected, why should ICANN
not seek an extension of the deadline so as to decide?
My understanding of Sclavos' language was that it was to protect
VeriSign's ability to complete divestiture in the event that
deliberations on the proposed alternative encroached on the time
available to complete divestiture should there not be an agreement on
the alternative. Of course, there was no guarantee that the Board and
DOC would agree to such an extension but it seemed fair to agree
to request it if it were needed in the event agreement on the proposed
alternative were not reached and the original conditions put into
jeopardy as a consequence of a good faith effort to explore an alternative.
6. What Concept is Being Proved?
from tbyfield :
If the introduction of new TLDs is a "proof of concept," what concept is
essentially that it is possible to introduce new top-level domains
in the DNS at a time when the economic importance/value of domains is
very different from the time when the first gTLDs were created, without
serious disruption in Internet operation. Concerns over who has the
ability to register names in new TLDs continue to occupy the attention
of registrants, registrars, registries and ICANN for example.
In fact, there are many different concepts to be evaluated,
and they differ for the various new TLDs. There is an Appendix (U)
in each gTLD agreement that will enumerate the concepts on which each
operator must periodically report. In my honest opinion, we are all
still learning what it means to operate TLDs in the rapidly evolving
commercial context of today's (and tomorrow's) Internet.
7. Contractual Control?
The proposed "unsponsored TLD agreements" recently posted by ICANN staff
bind the new TLD registries in detail, on matters including the UDRP; a
"sunrise" preference for trademark holders (with a detailed dispute
resolution process of its own); fees levied by ICANN; fees paid by
registrants; the registry-registrar relationship; functional and
performance specifications for registry services; bulk access to zone
files; whois (with ICANN control over availability, data elements,
response format, query types, etc.); extensive reporting requirements;
and much, much more. This regulatory regime is quite different from
anything historically imposed by IANA. (Indeed, it's quite different
from anything in the ICANN-ccTLD relationship today; a majority of the
ccTLDs don't even run whois.) Is this sort of centralized control
consistent with your vision of ICANN as a body restricted to
First, I would observe that in the IANA period, most if not all of
the DNS activity was non-commercial. Volunteers operated the registries.
In today's world things are markedly different and call for clearer
definitions of many of these details. The whole process of commercialization
has significantly changed the conditions under which Internet and its
various parts operate. Companies are depending on ICANN to help formulate
a framework in which they will operate and interact and ICANN is seeking
to make that framework as fair and uniform as possible. Actually a number
of issues of operational character used to come up in the IANA context
but they were dealt with one at a time by IANA and written policies were
relatively high level in nature.
8. Pioneer Registries?
What about the pioneer registries? Is it possible to find a formula that
will bring these non-ICANN TLDs into the ICANN framework?
I don't know whether that is possible. In some sense they were
created entirely outside the IANA, and now ICANN, framework and it isn't
clear how to incorporate them - especially if there are conflicts
among registries offering the same TLD. It seems to me that the
only thing ICANN can do is set forth the consensus rules by which
new registries are formed and integrated into the ICANN-sponsored
root system. Registries that operate outside that structure are
simply outside the structure.
9. ORSC Root?
Have you used the ORSC DNS settings, and experienced the rest of the
No I haven't
10. Why question at-large?
Dear Vint Cerf,
before the At Large elections, (not only) the Membership Advisory
Committee (MAC) has been working on recommendations to the Board
about the concept of At Large membership. E.g. in the MAC Singapore
Report it stated MAC consensus on the purpose of the at-large membership:
"To ensure representation on the ICANN board of directors of those individual and
organizational users that are not already represented by the Supporting
Now, there is a post-election study questioning the whole At Large
structure. (By the way, the anonymized election data has not yet been
released by ICANN. There are obviously ways of anonymizing the election
data without restricting it to simple aggregates or pre-election data.)
Why do you (or do you at all) see the need to study this part of the
ICANN structure -- and not others? E.g. the DNSO review is taking place
because there is a widespread perception, even within the DNSO, that the
structure is not working too well. What do you think is wrong or broken
when it comes to Internet user participation on the ICANN Board?
Best regards, - Alexander
What the White Paper said (and I believe that the MAC was
generally along the same lines) is that there should be representation
of Internet users. This is not the same as direct elections; there are
many ways to promote representation. And the ALSC is looking at all the
alternatives, since the online election uncovered a number of problems.
Holding global elections is an extraordinary task for any organization,
especially if the scale is measured in millions of potential participants.
ICANN is a small organization with a constrained charter and it is not
clear whether global elections are the only or even best way to gain
useful access to the views and concerns of the Internet's users.
I'm looking forward to hearing what the At-Large Study Committee reports
on these and the many other questions on its agenda.
11. Personal support?
You have stated repeatedly that "The net is for everyone". That is an
admirable concept. But, as we all know, the devil is in the details.
Suppose that the "clean sheet" study committee recommends the
elimination of direct elections for the At Large seats, or even the
elimination of some or all of the At Large seats. 1. Would you
personally be willing to support the elimination of direct elections? 2.
Would you personally be willing to support the elimination of some or
all of the At Large seats on the Board? 3. If democratic elections
were to be eliminated, how do you propose to involve the users of the
Internet in ICANN's decision making process?
This is an area of great interest to me, but I don't have any
strongly held views yet and I'm eager to hear what the study committee recommends
or at least reports.
12. ICANN's errors?
What are the three biggest mistakes ICANN has made to date? Why and how
were they mistakes?
[To respond, or start a new comment thread, click the "Send Your Comment" button in the yellow box to the right.]
This discussion has been archived.
No new comments can be posted.
Vint Cerf Replies to (most of) Your Questions
Log in/Create an Account
| 4 comments
The Fine Print:
The following comments are owned by whoever posted them.
We are not responsible for them in any way.
Just to be clear, Question 7 (a very good question, by the way) was not sent by me, to whom it is attributed, but by Jon_Weinberg. -- Bret
[ Reply to This | Parent
What about the pioneer registries? Is it possible to find a formula that will bring these non-ICANN TLDs into the ICANN framework?
I don't know whether that is possible. In some sense they were created entirely outside the IANA, and now ICANN, framework and it isn't clear how to incorporate them - especially if there are conflicts among registries offering the same TLD. It seems to me that the only thing ICANN can do is set forth the consensus rules by which new registries are formed and integrated into the ICANN-sponsored root system. Registries that operate outside that structure are simply outside the structure.
Except... Image Online Design has never gone outside of the IANA process, has been involved with it since 1995, the only conflicts with the name were from last-minute applications by entrenched participants, and they still didn't get the string, at Dr. Cerf's own objections. I don't see any of these points relating to Image Online Design and .Web.
Ambler On The Net [ambler.net]
[ Reply to This | Parent
|1 reply beneath your current threshold.|