[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
5th iteration ICANN draft articles and bylaws
While the deletion of IV 1(d) and (e) from the NSI/IANA 4th iteration
bylaws is a major improvement, in many respects the articles and bylaws
remain seriously flawed.
The most serious problem is lack of accountability. This is pervasive.
The ICANN initial board is to be appointed by a completely opaque process.
That board will have complete freedom in appointing the supporting
organizations and determining how at-large members on the permanent
board are to be selected. The supporting organizations, which should
be under control of the board, appoint nine members to the board. Each
SO has a veto on all corporate policy. The supporting organizations are
in any case external to ICANN, so they are not bound by its articles and
bylaws. The end result is an organization, ICANN, accountable to no one
whose major function will be to transfer its assets to other entities
who will then proceed to do what they wish with these assets.
SELECTION OF THE INITIAL BOARD
The criteria and methods being used to select the initial board are
perhaps of the gravest concern. The debate that we have been engaged
in over the last two years or so has been extremely complex. It is
impossible to follow much of it without a reasonable grasp of a very
broad spectrum of issues -- not just the Internet's own technology, but
also the interaction of that with other rapidly developing technologies
(eg e-commerce), the interrelationships among existing Internet
organizations, the rapidly growing global ISP infrastructure, the often
perverse effect of regulations, and the impact of the Internet on, for
example, copyright and trademark interests.
Given the breadth and complexity of the issues, it is remarkable that
one of the chief selection factors appears to be involvement in the
debate: if you have been involved in the debate, if you have demonstrated
your understanding of the issues, you cannot be a candidate for the
Initial Board. I personally know of no similar situation where the
rules of the game are not exactly the opposite: before you can set policy,
you must demonstrate an understanding of the issues and make your position
clear.
A necessary result of this perverse policy is that the Initial Board,
selected by unknown parties behind closed doors, will inevitably turn
to the existing IANA staff in setting policy. That is, the board
will have the responsibility and the show of power, but the real
decisions will be made by others, who will have real power but no
responsibility. This is a fundamental and perhaps fatal flaw.
[Disclaimer: I am not a candidate for either the Initial Board nor
the permanent Board of the new corporation.]
RELATIONSHIP BETWEEN IANA, THE RIRs, THE IETF, AND THE DNS
In the current arrangement of things on the Internet, IANA is responsible
for the allocation of IP address space. This is channeled through three
regional organizations, RIPE in Europe, APNIC in Asia, and ARIN in North
America. The relationship between IANA and these three organizations, the
RIRs (regional IP address space registries) is unambiguous: IANA has
oversight over the RIRs and IANA has the final decision over what address
space is allocated to who. The RIRs are service organizations at least
nominally responsible to their customers, the users of large blocks of
address space. These are largely the world's Internet Service Providers,
the ISPs.
This system works and works very well. It is a traditional hierarchical
structure, with policy flowing from the top and feedback flowing from the
bottom. Note however that the ISPs participate in this system
voluntarily, not because they are required to by law or contract, but
because it is to their benefit that they do so. It is a system of
voluntary cooperation for mutual benefit.
In the current arrangement, many Internet protocols are developed by the
IETF. The IETF is a large-scale global cooperative effort running on free
labor. Its operations have little to do with IANA, except that IANA
has edited the RFCs, the fundamental documents of the IETF, and IANA
assigns the numbers used in some protocols. The latter is not a time-
consuming function.
If anything, the IANA is subordinate to the IETF. Once again, the IETF
is a system of voluntary cooperation for mutual benefit. The whole
arrangement has worked very well.
As we all know, IANA is also nominally responsible for the root name
servers and the top level of the domain name system and we all know that
this has not worked well at all recently, in part because of collisions
between the DNS and the holders of trademarks and other intellectual
property rights, in part because of confused claims to the ownership of
gTLDs, and in part because of the way that the US government wrote its
contracts with the operators of the primary root name server and the
InterNIC.
SUPPORTING ORGANIZATIONS
The supporting organizations appear to be an attempt to provide the
new corporation with the benefits that come from a membership while
at the same time forcing the RIRs, the IETF, and the DNS mess into
one uniform structure.
Unfortunately, none of these is an appropriate membership structure
and it seems difficult or impossible to fit them to the same model.
The RIRs
--------
The RIRs are service organizations with ISPs as customers. Their
principal responsibility is allocating IP address space among their
customers fairly. Inevitably this gives the RIRs a great deal of
power over those customers: ISPs cannot do business without IP
address space. ISPs pay the RIRs for their services. In the new
scheme of things, the RIRs will remit part of these payments to
ICANN. That is the RIRs will act as tax collectors.
It is wholly inappropriate that the local tax office should at the
same time be seen as a representative body. It is also, in the opinion
of many, a very bad idea to interject politics into the functioning of
service organizations that now function well. The likely result is
hybrid organizations where politics is confused with administration of
policy to the detriment of both.
What does seem appropriate is a continuation of the current system,
with policy flowing down to the RIRs and feedback (plus some cash)
flowing back up.
The IETF
--------
The IETF is in no way similar to the RIRs. The RIRs have clearly
defined regional responsibilities. They are legally constituted
bodies with formally defined customer/members. The IETF has a very
cloudy membership that changes from meeting to meeting. The identity
of individual members is never checked. You are who you say you are
when you walk through the door. The IETF has no authority over its
members.
The IETF does periodically elect a group, the IAB, that has rather
loosely defined management functions.
It is very difficult to fit the IETF into the same model as the RIRs.
Even more than the RIRs the IETF is not a policy making body. The
large companies that supply the free labor that the IETF runs on
send technical staff to IETF meetings. They do not send staff
lawyers or senior management.
The RIRs receive address space from IANA that they can turn into a
revenue stream, part of which can be remitted to IANA (or ICANN).
The IETF receives nothing from IANA. What it does is produce protocols
which can be used by anyone for nothing.
In summary, the IETF has a highly unstable membership, one which could
be easily packed; it is not a policy making body; in any case it
has no revenue with which to support ICANN; and it has never been
subordinate to IANA -- in fact, in theory the IANA derives its
authority from the IAB.
a DNS SO
--------
It must be obvious that whereas it is difficult to fit the RIRs and the
IETF into the same model, it is impossible to do the same with the
domain names supporting organization, because it doesn't exist. What
is worse, such organizations as do exist are completely disparate in
nature.
Most of the world's TLD registries are country code TLD registries.
The ccTLDs are generally accepted to be under the sovereign power
of the countries and so the ccTLD registries have never been
subordinate to IANA. Furthermore they have never received any
significant services from IANA; all that IANA has ever done is
instruct NSI to add or change a ccTLD entry.
The world's sole gTLD registry, operated by Network Solutions, is on
the other hand cash-rich and obviously under US jurisdiction.
It therefore looks like any names council would have to be split to
recognize the fundamental differences between the ccTLD registries
and the gTLD registry/ies. The relationship between ICANN and the
gTLD registries might be that of a superior to a subordinate (like
that with the RIRs) but the relationship between ICANN and the
ccTLDs would have to be cooperative in nature. ICANN could not
demand funds from the ccTLD registries, although some might choose
to contribute. ICANN should certainly be able to demand license
fees from the gTLD registry/ies.
This makes it likely that most of ICANN's funding would come from the
gTLD registries. However, this leads to a fundamental problem: if
the names council or names supporting organization is to appoint
three board members and to have a veto on all ICANN policy, this
makes any oversight virtually impossible.
POSITION OF THE ISPs
IANA's primary function is to act as a focal point for cooperation
between the ISPs, the operators of the Internet infrastructure.
The ISPs operate the backbone routers of the Internet. They run
tens of thousands of name servers. Most allocations of IP address
space are to ISPs in their role as Local Internet Registries.
Nearly all ISPs are domain name registrars and most registrars are
ISPs. And of course the ISPs use all of the Internet protocols
developed by the IETF and participate in the IETF itself.
Furthermore, it should be obvious that the future of the new
corporation and its proposed supporting organizations depends
absolutely upon the endorsement of the world's ISPs. If the new
corporation is not acceptable to the ISPs, there will be no
revolution; that would be incompatible with the ISPs' basic
concern, which is the operational stability of the Internet.
What will happen instead is a quiet drift to alternative solutions.
Given all of this, given the absolutely central role that the ISPs
play in this process, it is odd that the IANA drafts give no
recognition at all to them in these articles and bylaws.
SOLVING THE PROBLEM
Most or all of the problems outlined above can be dealt with by
removing the circular elements from the structure of the new
corporation. The most basic step is adding a membership.
Then the membership elects the board, has a check on certain acts
of the board, and can remove directors if necessary. This makes
the board accountable to the membership. If the membership is
broad and diverse enough, and if it is structured so as to provide
regional and sectoral balance, the membership will also give the
new corporation diversity.
In particular, it is essential that the world's ISPs, which have
a predominant interest in the operations of the new corporation,
be able to express their interests in policy through membership in
the new corporation.
The second step is providing a proper role to the councils. These
should be brought into the corporation and made advisory committees.
As such they should have the powers to originate policy. Because
they are within the corporation they will be subject to its articles
and bylaws and to the board. That is, they will be accountable.
The third step is to define a logical role for the supporting
organizations. The RIRs collectively should become the IP Address
Supporting Organization. As such they will be licensees of the
fundamental assets of the corporation. They can be expected to pay
fees for such use. Note that this leaves the current IANA/RIRs
relationship little changed, and that is very much to the good.
The IETF can become the Protocol Supporting Organization. The
relationship between this and the new organization would simply
be cooperative. The new corporation would neither be superior nor
subordinate to the IETF; the two would be equals, except that the
IETF might pay the new corporation for editing RFCs and an
appropriately small fee for its work in assigning protocol numbers.
The Protocol Council would then draw many or most of its members
from the IETF or the IAB.
The Names Council would be responsible for defining appropriate
rules for recognizing names supporting organizations. These should
be of two types. The relationship with one would be cooperative;
this would be appropriate for ccTLDs. The ccTLD registries should
be willing to pay a small fee for maintaining their entries in the
root name servers.
The relationship between the new corporation and the gTLD registry/ies
should be vertical. The new corporation will license a gTLD registry
to use a gTLD, will set policy for the operation of such registries,
and will have oversight over the operation of the registry. In return
the licensee will pay a fee, presumably based on the number of domain
names registered in the gTLD.
The current draft articles and bylaws expect a names supporting
organization to be built first, and built outside the new corporation.
That supporting organization is then to appoint a names council.
It makes far more sense to reverse this, for the board to appoint a
names council which in turn will be responsible appointing a number of
supporting organizations.
ADDRESSING THESE CONCERNS IN THE FIFTH ITERATION DRAFTS
All of these concerns are systemic and are of course incompatible with
the current draft bylaws. The argument will be that it is too late to
introduce such large scale chnages. There are two replies to this.
First, the demands for a membership are not at all new. Each IFWP
meeting called for a membership to the new corporation and a board
accountable to that membership. The European Commission-sponsored
Brussels meeting did as well. The NSI "consensus" articles and bylaws
did the same.
Secondly, it is not necessary to amend the bylaws along these lines.
What is important is to amend the articles. The amended articles can
then require that the Initial Board bring the bylaws into line with
the articles.
This means that the nine member Initial Board can use the methods in the
current bylaws to fill out a board of nineteen members, but then this
board of nineteen will be required to create a membership structure and
allow the new members to replace them.
While it is virtually guaranteed that the result will be suboptimal,
because the vested interests recognized by the current drafts will take
the opportunity to engineer a solution favorable to them, it will be
far better than the new corporation envisaged by the current drafts,
which lacks all accountability and has an initial board which will be in
the hands of those it is supposed to have oversight of.
A specific set of changes to the articles along these lines can be
seen at
http://www.euroispa.org/icann.html
While the changes are to the 4th iteration articles, the 5th iteration
articles are so little different that nearly all of the proposals are
still valid. Should there be time, we will produce a set of proposed
changes to the 5th iteration drafts as well.
As far as the selection of the first nine members for the Initial Board
is concerned, there is no doubt that this needs to be opened up and the
rules should be changed. Given the critical role to be played by these
nine people, the first requirement should be an understanding of the
situation. It should be made clear who is to select the initial nine,
what the criteria for selection are, and who the candidates are.
Perhaps most importantly, public discussion on this issue should not
just be permitted, it should be encouraged. You propose that these
people should change the rules governing our Internet: we have the
right to know who these people are and to say what we think about your
choices.
--
Jim Dixon Managing Director
VBCnet GB Ltd http://www.vbc.net tel +44 117 929 1316
---------------------------------------------------------------------------
Member of Council Telecommunications Director
Internet Services Providers Association EuroISPA EEIG
http://www.ispa.org.uk http://www.euroispa.org
tel +44 171 976 0679 tel +32 2 503 22 65
Privacy Policy | Terms of Service | Cookies Policy