[ncdnhc-discuss] Internet is global=we need central planning

[jefsey]

I am sorry, Michael, but nothing you quote has ever needed centralization. 
And never will. The only need is for a concertation to avoid collision 
between realisticly grown-up network projects, IP blocks and software 
designs. It is time to accept that ICANN is no more than the LegacyNet 
manager, and that no one needs it ouside of the LebacyNet system.

Its problem is only to show what it could bring to the Global Internet 
Community. Questions are :
- which benefits has the GIC derved from the ICANN?
- which benefits will the GIC derive from the ICANN?

 From the responses, you will be able to document the value of that 
benefits, to who.
So you will know who should pay for them, and how much.

As Kent put it clearly, the ICANN's most difficult job is not to perform, 
but to make believe it has authority to perform, and somethng to do. I am 
not interested in what the staff does, but in what I get from them. That 
list is much needed.
The one I have is very short "a waste of time and money, the blocking of 
innovation".
jfc

At 09:42 02/05/02, Michael Froomkin - U.Miami School of Law wrote:

>On Wed, 1 May 2002, Alejandro Pisanty - DGSCA y FQ, UNAM wrote:
>
> > James,
> > >
> > > 1.  Do you believe I am making unrealistic proposals with regard to 
> what can
> > > be decentralized, and what I concede might be centralized?
> >
> > The degree to which you seem to think that some functions can be
> > decentralized appears unrealistic to me. As a prime example, gTLD policy.
>
>**Why** exactly can't this be decentralized?
>
>As far as I can tell, the only functions that require centralization are
>
>1. keeping the master list to prevent collisions;
>2. setting annual quotas for gTLD creation;
>3. setting in motion the processes by which other bodies will choose the
>gTLDs;
>4. (optionally) setting minimum criteria for gTLD operators e.g. adherence
>to the UDRP, data escrow, fixed legal location.
>
>1 is easy.
>
>2 becomes much easier if one accepts that ICANN should look only at the
>engineering issues. IF there is some number beyond which we shouldn't go,
>that imposes constraints.  But after three years, and in the face of some
>fairly strong consensus that if there's a technical limit it is very high,
>I think the burden is quite clearly on those who would leave the limit a 7
>every three years.  ICANN should not engage in the social policies of
>protecting incumbents.
>
>3 is hard. But your committee could certainly enunciate principles for
>this, which we could then communally debate.  The key is to spread the job
>out among very different types of institutions, located in different
>places.  And the second key is to imitate Postel's brilliant strategy of
>piggybacking on the ISO codes for the ccTLDs.  In each case you should
>seek to find a list maintained by someone else for a different purpose.
>Eg. if the the goal is to allocate some gTLD creation rights to NGOs, find
>a list -- even a very partial one will do -- such as the UN's
>accreditation list.  Or concatenate several, e.g. unions, environmental
>groups, bodies accredited to international treaty organizations.
>
>The lists need not be perfect, nor need the list of lists be comprehensive
>provided that the overall variety is great (and I'd auction off a tld or
>two a year too - the market is a very efficient way to allocate scarce
>goods).
>
>4. is basically done.
>
>Incidentally, for the avoidance of doubt, I direct your attention to my
>suggestions on how ICANN should function in pages 5-8 of
>http://www.gmu.edu/conference/itbiotech/papers/PapFroomkin.pdf
>
>And, if it needs saying, the idea the ICANN has security
>*responsibilities* is a total non-starter.  The fact that it has appointed
>a committee -- the prime evidence for this responsibility noted in the
>staff report-- is evidence of nothing other than desires for grandure.
>ICANN might have a role to play encouraging others to develop best
>practices and in disseminating them, but it has no legislative or
>executive role in security policy.
>
>--
>
>[Note: I killfile Cr*cker, Kr*spin, JW*lliams]
>
>                 Please visit http://www.icannwatch.org
>A. Michael Froomkin   |    Professor of Law    |   froomkin at law.tm
>U. Miami School of Law, P.O. Box 248087, Coral Gables, FL 33124 USA
>+1 (305) 284-4285  |  +1 (305) 284-6506 (fax)  |  http://www.law.tm
>                        -->It's cool here.<--
>
>_______________________________________________
>Discuss mailing list
>Discuss at icann-ncc.org
>http://www.icann-ncc.org/mailman/listinfo/discuss
>
>
>
>---
>Incoming mail is certified Virus Free.
>Checked by AVG anti-virus system (http://www.grisoft.com).
>Version: 6.0.351 / Virus Database: 197 - Release Date: 19/04/02
-------------- next part --------------

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.351 / Virus Database: 197 - Release Date: 19/04/02