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
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
@ 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.