[arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate

[Owen DeLong]

On May 24, 2011, at 8:39 AM, Mike Burns wrote:

> 
> Mike -
> 
> Efficient use of address space is a reasonable match to the goal of
> "conservation", but what do you propose with respect to the goal of
> "aggregation" under such a model?
> 
> /John
> 
> 
> 
> 
> Hi John,
> 
> First, I don't see the evidence in the transfers we are aware of that aggregation was much of a consideration.
> And especially with the ARIN staff decision to apply the single aggregate terminology to the needs requirement and not to the actual transfer.
> 

It was somewhat, but, yes, that mistake in the transfer policy should get rectified and I'll be submitting a proposal
to do that shortly.

> Second, it is up to the network operators, who bear the costs of disaggregation, to make the decisions as to what is an acceptable prefix.
> In the long run, we will have disaggregation either way.
> 

This may be true, but, I see no reason for policy to favor increasing it or accelerating it.

> The minimal generally acceptable prefix length may vary, and I think the price of netblocks near the border of the minimum size would reflect their potential routability.
> 

This is less clear and it is even less clear how the market could or would keep pace of knowledge as this shifted.

> I'm unclear on how current transfer policy affects aggregation, can you help?
> 

There are some protections, but, the syntax error in the positioning of the single
aggregate clause definitely reduces the intended effectiveness.

It was intended to (single aggregate clause), but, that turned into an accidental no-op due to
improper syntactic positioning. I'll be submitting policy to fix this shortly.

> If I qualified for a /20 but I found two suppliers with /21s, would I  be allowed to make two purchases under the current policy?

Not entirely clear. You would definitely be able to purchase a pair of /21s from the same supplier in the same transaction, but,
I think that the current policy still prohibits other permutations. The single aggregate clause getting moved to its correct
position will hopefully close the existing loophole.

> If I qualified for a /20 but I found one suppler with two /21s, would I be allowed to make the purchase of both netblocks under current policy?

Yes, so long as you did it in a single transaction.

> If there was a /20 available on STLS but the price was higher, would I be required to make the purchase as a single block?

Due to a syntax error in the current policy, no.

> If it were cheaper to buy some /24s, and some /23s to make up a /20 in aggregate would that be okay?

Under current policy, only if you got them all from one supplier in a single transaction.

> 
> I guess the goal of aggregation can be viewed as applying to the free pool, and with allocations from a free pool it is possible to dole out the most efficient large blocks that would serve the goal of aggregation. But in the trading market, regardless of needs requirements, how can we maintain that goal when we don't have the big block of free pool addresses to carve allocations out of?
> 

By correcting the syntax error in 8.3

> I think aggregation is out of our hands now, and up to the network operator community to deal with.
> 

I think this is true to some extent, but, not completely and there are certainly things we can do that would
accelerate disaggregation. I would argue that removing needs basis is likely to do so, for example.

Owen