/20's for the needy

At 20:23 02-07-97 +0100, you wrote:
>Stephen Sprunk wrote:

>> . Must have an ASN

>1.) Must be a ASN unless new startup, than must apply as part of
>qualification.

I wanted to separate the ASN and PI block application processes, since it's
a totally separate function and has its own list of requirements.  I'd hate
to slip up and give a PI block to someone who never got an ASN.

>> . Must have no more than 4096 PI IPs already

>2.) Must have no more than 4096 PI IPs already, unless it is a new
>startup than based on projected size of startup broke down on RFC2050 specs.

I don't quite understand your added wording here...  If it's a new startup,
it won't have ANY PI IPs.  My intent was to automatically disqualify people
who already have large PI blocks (like, say, BBN who has 3 A's and a dozen
B's) from getting anything from the "New ISP" block.

>> . Must not qualify for a /19 (or shorter) under RFC 2050

>3.) Must be able to qualify for any size dependant on current efficient
>    use of current allocations, unless new ISP start-up, than based on
>    projected size of startup in accordance with breakdown in RFC2050.

Again, what does is mean, and what is the intended effect?

>> . Must be capable of advertising the /20 to peers within 30 days

>4.)  Must be capable of advertising the /? to peers within 60 days

If we're going to go with 60 days, I'd like to see "capable of advertising"
changed to "advertising".  However, I don't see how you can enforce a
future requirement before allocation.  I chose 30 days since that's the
lead time for installing circuits from most LECs.


Stephen