[NAIPR] ARIN Proposal
Valdis.Kletnieks at vt.edu
Valdis.Kletnieks at vt.edu
Fri Jan 24 12:17:01 EST 1997
On Thu, 23 Jan 1997 22:54:45 CST, you said:
> As I was typing this, I started wondering what past address block
> allocations really have to do with ARIN. Other than some maintenance
> activities, ARIN's concern is really future address block allocations.
Well, based on other postings made today, there seems to be a large
(or at least vocal) contingent that feel that the past allocation
policy was at least slightly flawed, at least in practice (see the
postings regarding providers who announce hole-punched routes from
a customer who used to be connected to a competitor). We've also seen
discussion of different ways the *new* policy should work. Therefor,
it may be a good idea to review the historic record and see what
worked and what didn't in the old scheme before we start creating
a new one....
Remember that unless we decide otherwise, ARIN will probably use the
same allocation policies that are used now - so if the current ones
are flawed (competitive bias, or CIDR-unfriendly, or inspired by
black helicopters, or whatever your favorite bugaboo is), we should
speak up now, while we can....
The biggest problem with creating an organization to handle the
deceptively simple-looking task of handing out blocks of "<stuff>"
is that we don't have a consensus on how to handle "<stuff>".
For this paragraph "<stuff>" refers to any allocation of electron-movement
related resources (see the FCC botch of the initial cellular phone
space auction, or the NSI hassles with trademarks versus domain names,
or the recent flaps re: the copyright treaties and whether viewing
a work with a Web browser is "copying" or not....)
--
Valdis Kletnieks
Computer Systems Engineer
Virginia Tech
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 284 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/naipr/attachments/19970124/d9d437b0/attachment.sig>
More information about the Naipr
mailing list