/20's for the needy

[Jeff Williams]

Stephen,

  Sorry it took me so long to respond to this.

Stephen Sprunk wrote:
> 
> 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.

  I understand.  But my suggestion doesn't preclude this at all.  In
fact
it is a hand and glove arrangment.  
> 
> >> . 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.

  Yes, but your suggestion did not "CLEARLY" state this which leaves
it to interpretation.  I was trying to clarify it a bit.  In addition
there is not spicific provision within RFC2050 for "New ISP's", hence
my wording.
> 
> >> . 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?

  This means that, as I have said several times now, the RFC2050 makes
NO spicific provision for "NEW ISP's"  hence my wording to be more 
spicific as to your refrence "under RFC2050".  Otherwise much is
left to interpratation.  This makes it unclear and subject to a whim
interpratation.  RFC1918 also needs to be amended to this effect,
or ARIN's policies in respect to RFC2050 and RFC1918 should be more
spicific along these lines.
> 
> >> . 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.

  BUt it usually takes longer than 30 days.
> 
> Stephen

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