a 2nd potential solution

On Wednesday, July 16, 1997 10:28 AM, Tony Li[SMTP:tli at juniper.net] wrote:
@ 
@    In the Coalition approach, ISPs have to understand they will be
@    tied to the coalition. This seems like less of a problem for ISPs than
@    being tied to an upstream provider.
@ 
@ This is part of what's not clear.  If you dislike being tied to an upstream
@ provider, it's because there's insufficient freedom of movement.  Being
@ tied to the coalition, in which (presumably) majority rules can be equally
@ oppressive.
@ 

Yes they can...that is why I point out that ISPs might
wish that they are tied to an upstream or a coalition
of upstream providers....
...or something like IOPS...http://www.iops.org

@    Of course, depending on the stability and greed factor of coalitions,
@    the ISPs may wish they were tied to an upstream provider. This is
@    one of the major concerns about organizations such as ARIN.
@    Supposedly, ARIN is being "given" some unknown /8 delegations
@    to manage. The companies that have allocations in those blocks
@    have not been given any say about this. What happens if ARIN
@    decides to enact policies and change companies allocations or
@    charge high fees ? Small ISPs will probably have as much say as
@    they did with the $50 domain taxes and the future of .COM, .NET
@    and .ORG.
@ 
@ One should then complain about the behavior of ARIN, in much the same way
@ that one would complain about the behavior of a governmental department.
@ 

Yes, just like people complained about the InterNIC and NSI.....
you saw how far that got...

By the way, recently I heard that ARIN may not qualify as an
IRS non-profit company and someone mentioned that ARIN could
then pursue the IPO route...I guess this depends on how the NSI
IPO does...although the @Home IPO seems to have been a
success...

@    Many people feel that the routing tables can be reduced
@    in size with better (and more fair) policies. Without experiments
@    to prove and document this, people will never know.
@ 
@ It's quite easy to see the number of routes generated from a clear
@ technical proposal.  Experiments to determine basic scalability are not
@ necessary until a scalable proposal is in hand.  Especially experiments
@ which in actuality are irrevocable deployment, thinly veiled.
@ 

Maybe this should be the focus of NAIR ?

Open mailing lists and discussions such as
these are great for preventing "thinly veiled" proposals.
--
Jim Fleming
Unir Corporation