[ppml] Restrictions on transferor deaggregation in 2008-2: IPv4Transfer Policy Proposal

> Right now I can go to any colo provider and say "I want a 
> half dozen racks, power, and connectivity for my 150 
> servers." and pretty easily get a /23 or larger. Now what 
> happens if I say "You know, why don't you forget about the 
> racks, power, bandwidth and everything else...  
> How much would just the /23 be per month?"

NRPM 
4.2.3.4 Downstream customer adherence
ISPs must require their downstream customers to adhere to the 
following criteria:
4.2.3.4.1 Utilization
Reassignment information for prior allocations must show that each
customer meets the 80% utilization criteria and must be available
via SWIP/RHWOIS prior to your issuing them additional space.
. . .
4.2.3.6 Reassignments to multihomed downstream customers
Under normal circumstances an ISP is required to determine the prefix
size of their reassignment to a downstream customer according to the
guidelines set forth in RFC 2050. Specifically, a downstream customer
justifies their reassignment by demonstrating they have an immediate
requirement for 25% of the IP addresses being assigned, and that they
have a plan to utilize 50% of their assignment within one year of its
receipt. 
. . .


> 
> This is possible right now, and as far as I can tell not 
> breaking any policies. 

Looks like it breaks at least one of the above policies.

You can't get a /23 because you're getting rack space.  You can 
get a /23 because you're hosting a bunch of equipment with 
several subnets (for various, inversely proportional values of
"bunch" and "several").

> Require that the address space come with some kind of 
> service? Okay, throw in a dialup PPP line with it. Where do 
> you draw the line that won't take more time to verify than it's worth?

Every time you need more space, either under existing policy or
under the proposed transfer policy.

> This is possible already, with no policy changes.

Not the way I read it.

> I'd actually be surprised if it's not happening already for 
> networks that were denied by their RIR.

If it is, it's in small pockets around the industry.  The 
reputable carriers don't do this.

Lee

> -- Kevin
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to 
> the ARIN Public Policy Mailing List (PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml
> Please contact the ARIN Member Services Help Desk at 
> info at arin.net if you experience any issues.
>