past vs future use

[Jeff Williams]

Karl Auerbach wrote:
> 
> > [direct quote from the rfc]
> > ---
> > 3.1  Common Registry Requirements
> >
> >    Because the number of available IP addresses on the Internet is
> >    limited,
> 
> It's interesting that RFC2050 is premised on a limitation of addresses.
> 
> The real issue that started all off this is not that we are running out of
> addressing space (Frank Solenski's projections show we have about 20 years
> before we hit the wall -- ask me sometime about how and where the original
> calculation was made, it's an interesting story.)  Rather, the real issue
> is the routing table expansion.

  Exactly!  Whew!  Finaly someone sees the light!  >;)
> 
> While efficient utilization of addresses is important, it is not the only
> concern.
> 
> Perhaps an additional metric is whether an
> allocation/delegation/assignment can be made that doesn't add additional
> routing table entries.

  Good suggestion, and possible.  I believe this suggestion has been
mentioned not to long ago.  Not sure where or who mad it however.  It
has been a thought on my mind for some time...
> 
> For example an ISP that needs an additional /19 to add to their existing
> /19 might need to trade in their old /19 in order to get a /18.  That way
> the number of routing table entries remains constant.

  Yes sir.  Could work this way.  I think however that some flexibility
will need to be built in.
> 
> That would change the system to one in which the registry (ARIN or an
> intermediate level ISP) might have to withdraw previously delegated
> address blocks and assign replacements in order to aggregate assignments.
> 
> So perhaps an additional metric is whether one who desires an additioanl
> block of addresses is willing to give up existing blocks in order to
> obtain a larger, aggregated allocation.

  This is where the rub is going to be Karl.  Maybe it could be
finnessed
a bit by allowing some change over time.
> 
>                 --karl--

Regards,
-- 
Jeffrey A. Williams
DIR. Internet Network Eng/SR. Java Development Eng.
Information Eng. Group. IEG. INC. 
Phone :913-294-2375 (v-office)
E-Mail jwkckid1 at ix.netcom.com