[arin-ppml] Statistics regarding NRPM 8.3 Transfers to date

[Owen DeLong]

On Apr 30, 2011, at 8:29 AM, Matthew Kaufman wrote:

> Owen writes:
>> Let's look at another scenario that is what people are actually
>> intending to object to...
>> 
>> Let's say you can justify 980 addresses. The intent of the policy
>> would be for you to get a /22. The thing people are upset about
>> is that when you justify that /22, ARIN staff is apparently willing
>> to satisfy that need by allowing you to acquire through the transfer
>> policy a /23 and two disparate /24s.
> 
> I'm not sure that's a problem.
> 
It is. It will become an obvious problem when it adds another
200,000 or so prefixes to the routing table (note, disaggregating
3 /8s into /24s will be enough to have this effect).

>> The intent of the policy was that you could receive a /22. No more
>> or no less. That is considered the exact amount justified as a
>> single aggregate.
> 
> And so if the seller has a /23 and you can justify 980 addresses you're simply out of luck? Or need to lie and claim you can only justify 450 today in order to get the /23?
> 
Uh, no, the buyer needs to go find a seller that has a /22.

> Clearly *that* would make no sense. You should be able to receive a /22 *or anything smaller* if you justify 980 addresses.
> 
I disagree.

I have no problem with the idea of accepting something smaller, so long as it doesn't result in a revolving door
use of the transfer policy where you subsequently get the rest through additional acquisitions.

This is one of the reasons I didn't like the abandonment of 2008-2 which had minimum times between
 transfers.

> And then once you've justified 980 addresses to ARIN, you should clearly be able to use 8.3 transfers twice in a row, for two separate /23s... it wouldn't make much sense for ARIN to require you to resubmit all the justification paperwork you just sent them a few hours ago, would it?
> 
Again, I disagree. The intent of this phrase was to reduce the amount of disaggregation of the routing
table that will be caused by transfers. Allowing this revolving door use of the transfer policy will
increase disaggregation.

Even without it, I expect transfers to have a devastating affect on our continued ability to route IPv4
in the relatively near future, but, perhaps I shouldn't object as I think the only natural outcome of that
will be a sudden and dramatic shift to IPv6 which I guess is good for me. However, I try to keep the
best interests of the community in mind and I think that would be traumatic on the community level.


> And then once that's going on, why make the transfers happen as two separate transfers? That's just more paperwork for everyone.
> 
Again, the goal and intent is to prevent the double transfer and resulting disaggregation.

> The only other way to "fix" this is to only allow a recipient to use 8.3 once every N months... but there are any number of good reasons to not do this *and* several easy workarounds for the recipient as well.
> 
I'd be interested in identifying (and perhaps eliminating) the workarounds.

I do favor a 6 month transfer moratorium given that transfers allow the transfer
of up to 12 months of need. Sure, your projected need might be off, but, if
it's off by more than 50%, I don't have so much sympathy.

Owen