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