Before beginning, let me thank all those who spent a significant effort
creating these documents.  I know how difficult and time consuming it is,
having been involved in the drafting of one version of the ICANN Bylaws.
This is especially true under their apparent schedule constraints.

        Due to the time urgency that was communicated to me, I will provide
only the most significant NSI suggestions on the two proposals at this time.
We would like to meet with the respective sponsors' as soon as is possible
to clarify our understanding of the drafts, and to provide specific
suggestions for improvement of the drafts.

        For the purposes of my comments today, the two drafts are more alike
than different, and therefore, my comments apply equally to both.  I believe
that they both suffer from two connected problems, which relate closely to
how the SO and ICANN will operate in developing standards or policy
guidelines.  Let me take them in order:

        1) Consensus not democracy. The emphasis of both drafts is to
describe rather complex approaches to define "membership" in the SO and to
"democratically" select a body called the Names Council. While there are
significant provisions for diversity, it is rather transparent to an
outsider that there is a risk that some particular constituency may end up
controlling the majority of seats on this Names Council. Further, it is
apparent to the thoughtful reader that each proposal views this Names
Council as the deciding body regarding which proposal go to the ICANN board
for decision and possible implementation.  This approach is historically
common in the Internet and has been referred to as the "Council of Elders"
approach to policy development.  It is wrong for today, and it is wrong for
ICANN.

        Neither proposal addresses in any way the "process" that will be
used to develop policy and standards proposals that are consensus based.
That is what the SO is all about.  The Names Council is not the "governing
body" of the SO, it is the administrator of a consensus building.  That
process must be described and agreed upon, for it is the essence of the SO
function.

        A fundamental question might be "Why are all the affected
constituencies concerned with controlling the proposals that go to ICANN for
decision?"  Obviously, they have different views of the proposal that are
needed and have different objectives that they desire to accomplish.  That
is not the most important point here.  The real issue is that the drafts
fail to reflect one of the most fundamental realities of self-governance on
the Internet.  This is a reality that the ICANN board, and the USG, no
doubt, realizes in silence.  And that reality is that a proposal that is not
supported by a consensus of the affected constituencies cannot be
implemented.  ICANN has no authority today outside of consensus support of
the affected constituencies. This is not heresy, nor rebellion; it is
reality. There are no enforcement mechanisms in place today that have the
force of law. If you need convincing, imagine a proposal from the ASO
concerning IP addresses that is opposed by the Regional IP Registries, ARIN,
RIPE and APNIC, or the major of ISP community. Or suppose there is a
proposal from the Names SO that is opposed by the DNS Registries. What can
ICANN do?  Cut off IP addresses to the Regional IP Registries, or remove DNS
Registries from the "root?" I think not, since these measures would be
catastrophically destabilizing, precisely the opposite of what we want ICANN
to achieve.

        So, faced with this reality, how should the SO policy and standards
development process relate to the affected constituencies?  And how can
ICANN policies be implemented in the future with the force of law? What is
the enforcement mechanism?  These questions are intimately related and the
answer to these questions leads to my second point.

2) SO Policy Development and ICANN Implementation involving Contractual
Commitments. The reality, that no proposal from an SO can be implemented
unless a consensus of the "affected constituencies" supports it, leads to an
alternative approach to SO structure and process.  It suggests that the
process in SO policy and standards development should provide for an
impacted and implementing "Constituency Review" before going to ICANN.  With
this modification much could change.  All of a sudden it is not so important
for disagreeing constituencies to control the Names Council, and we can
relax the "democracy" exercise and select people for the Names Council who
will work the consensus process not the constituency agenda.  The power will
have been reserved for the affected constituencies, and the process will
have been converted to a bottom-up consensus building effort-- rather than a
top-down decision process by the Names Council of "elders."  So this answers
my first question in the last paragraph of 1). What about the other two
questions?

        One of the difficult lessons that NSI learned early in its
registration services work was how difficult it was to legally enforce
acceptable registration standards with a geographically diverse set of
registrants from hundreds of sovereign countries.  The only mechanism that
worked for us was a bilateral contract between the Registry and the
Registrant.  This is exactly the same problem that ICANN faces.  How does it
enforce acceptable standards and policies with the affected constituencies
especially the IP and DNS Registries?  Bilateral contracts!

        As a first term in each such contract, ICANN should guarantee a
"Constituency Review" process at the SO level. This should be in exchange
for an agreement that the individual constituent will implement any proposal
that is supported by a super-majority of the implementing constituency and
is equitably applied to all. Even if the constituent is opposed to the
proposal.  Let me give a real example. Assume ICANN has a contract with each
DNS Registry. Further, assume that in the "Registry Review" of a particular
Names-SO proposal, that proposal is supported by a super-majority of the DNS
Registries.  Then (if the ICANN board approves the proposal) those DNS
Registries who opposed the proposal would still be bound by contract with
ICANN to implement that proposal.  This is an ICANN implementation mechanism
with the force of law.

This approach respects the "affected constituencies," but it cherishes the
"consensus view."  This modification modernizes the time-honored Internet
approach of "rough consensus."  It is right for ICANN and it is right for
the Internet today.

 
don

Donald N. Telage, Ph. D.
Senior Vice President and Director
Network Solution, Inc
dont@netsol.com
don@telage.com
Phone 703 742 4707