[ncdnhc-discuss] Re: Decentalization proposal for ICANN Evolution and Reform

Karl Auerbach karl at cavebear.com
Thu Apr 4 20:49:02 CEST 2002


On Thu, 4 Apr 2002, James Love wrote:

> This is a specific proposal for ICANN decentralization.
> 
> 1.   Get ICANN out of the protoccal and numbering business, and focus on the
> names issues, where the lack of an accepted decision making structure is the
> most problematic.  Let the ASO and PSO be independent and sort our their own
> issues.

I'd have to disagree with you here - While I do believe that there is no 
need for any public body to handle what is essentially a clerical job of 
writting down "protocol parameters", there need for a rational policy on 
IP address allocation is essential for the net to get IP packets from 
sources to destinations.

IP address allocation policy is frought with public policy issues - but so 
far nobody except ISPs and router vendors have noticed.  Fortunately they 
are issues that don't carry the additional burdens, such as trademark 
concerns, that have so bedeviled anything to do with DNS.  Today the RIR 
system of allocating addresses is working acceptably well - the RIR folks 
have dulled the sharp edge of their early policies so that there are not a 
lot of divergent points of views on the allocation policies except at the 
very edges, and hence least vocal parts, of the net.  And IPv6, if it 
ever gets here, will significantly reduce even those complaints.

Last night I was having a discussion with someone we all know and I 
suggested a division into four distinct and completely separate entities.

 A. An IP address allocation policy body.  The RIRs would still exist
    under this body.  Funding would come from the RIRs.

 B. An essentially clerical body to do the non-discretionary parts of
    IANA.  This would be funded by those who use it, primarily the IETF.
    No need for public participation here.

 C. A body to administer a DNS root zone file and to either manage or 
    operate (or both) the collection of root servers for that zone file.
    This body would deal with routine zone file maintaince, like
    updating records, but would have no authority to add, remove, or
    redelegate any delegation.  It could only do that per instructions
    from the fourth body, below.

    I don't see this as a big or expensive operation, apart from its
    own administrative elements, the actual work could be performed
    by a very small number of people.  The biggest cost  issue is
    that of the root server operations themselves, something that I
    believe can cost relatively little (apart from possible one-time 
    startup costs) if we realize that 24x7 oversight of root servers can 
    be accomplished by two or three people with pagers as long as there
    is some means to invoke a trustworthy set of hands at each server site
    to do things like power cycle a box or insert/eject a CD.  And a lot
    of the better co-los into which one might consider placing a root
    server have such people.

    My own quick estimate for this was $3,000,000 one time cost to 
    establish 12 fully owned, co-lo located root servers.  (This number
    doesn't have a huge amount of safety margin - I was assuming each 
    root server would be built using solid PC or Sun class servers fronted 
    by some sort of load balancer, F5 or Cisco local director or 
    whatever.)  $250,000 per site buys a lot of hardware these days 
    including a trip to install it wherever it is to be.

    I estimated yearly operational costs to be anywhere from 4 FTE's - 
    for a total of $500,000 to $1,000,000 year depending on salary rates 
    and overhead - to as much as 3x that, i.e. a max of $3,000,000/year.
    Co-lo space rental for 12 servers at $1,000/month per site still
    amounts to only $144,000/year, i.e. it's a small percentage of the
    labor cost.

    There is nothing special about the facilities, so they don't need to 
    be armor clad - if they burn down or there's an earthquake, as long 
    as the access keys are kept safe, one could actually administer the
    remote servers via SSH from a laptop in a coffee house. ;-)
    (That's not really that weird - we did that kind of thing here in
    Santa Cruz after the 1989 earthquake.)

    Funding for this would come from a number of sources - such as an 
    override fee on TLDs (much like ICANN does today), update transaction
    fees, etc.

 D. A DNS policy body.  This is where the trouble would continue to exist.
    But at least it would be in a smaller, and less expensive, container. 

By-the-way, when drawing the line as to what is technical and what is 
policy, I have suggested the following metric:

  A matter is "technical coordination" of the Internet if:

  - A wrong decision has an immediate and direct impact on the
    ability of the Internet to deliver its fundamental service, i.e.
    the end-to-end transport of IP packets.

  Otherwise it is a policy matter.

> 2.    Begin with an ICANN/DNSO, I'll call ICANN-1, that is particularly US
> Centric, and according to observors, tends to do, for better or worse, the
> following things.
 
>      b.  Embraces US style approaches to protection of consumers and in
> areas where it has a responsibility, trademark issues.

I find the injection of trademark issues into network operation to be one 
of the single worst things done to ICANN.  From a US legal perspective, 
there is still no reason to believe that the agency of the US government, 
the Dept of Commerce, which itself has now power to regulate trademarks, 
has any authority to empower a private body to do the job that it can not.

I'd suggest that we abandon that failed experiment of private lawmaking
and let national legislatures do what they are supposed to do.  Sure the
trademark people will yell and scream that their inexpensive and fast UDRP
has gone away - but we have to remember that the UDRP is inexpensive and
fast because the concepts of due process, effective review, and even
handed procedures have been eliminated.

		--karl--





More information about the Ncuc-discuss mailing list