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

[Stephen Sprunk]

On 01-May-11 11:05, Owen DeLong wrote:
> On Apr 30, 2011, at 17:13, Stephen Sprunk <stephen at sprunk.org> wrote:
>> On 30-Apr-11 10:40, Owen DeLong wrote:
>>> On Apr 30, 2011, at 8:29 AM, Matthew Kaufman wrote:
>>>> 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.
>> Imagine you qualify to receive a /23 but there are no /23s available on the market.  AIUI, the policy's intent was to prohibit you buying half of someone else's /22.  However, is there any harm in ARIN fulfilling your request with my two disjoint /24s in that scenario?  Keep in mind you could get my /24s (or one from me and one from someone else) anyway via two separate transfer requests.
> No, that intent went out the window early in the debate. It was replaced with an intent to prevent you from creating a /18 equivalent out of disparate /24 sized chunks of someone else's /8.

Hmm.  I was concerned about the latter as well, but I didn't realize we
had agreed to allow deaggregation in the first place.  That makes things
easier.

>> This interpretation, which could be creatively read into the policy text, could easily explain the statistics recently posted and, IMHO, doesn't violate the policy's intent or goals.
> While I would be fine with ARIN fulfilling your request with 2 /24s that were already disjoint, however, I don't want to see someone with, say, 44/8 find a buyer that needs a /20 and sell them 44.0.5/24, 44.0.8/24, 44.15.23/24, 44.28.6/24, etc.

How about this:

"The transferor's resources may be recursively bisected the minimum
number of times necessary to create one CIDR block equal to the
transferee's justified need."

So, if someone with a /8 wants to sell you a /20, their /8 would be
divided into one /9, one /10, one /11, one /12, one /13, one /14, one
/15, one /16, one /17, one /18, one /19 and two /20s, and then you would
get one of those /20s.

If you agree with that, I'll figure out how to shoehorn it into the
existing text of NRPM 8.3, though I'd prefer a complete restructuring.

I also see several ugly possibilities when the transferor has multiple
blocks of different sizes available to sell, but I'd need to see
examples of how you'd want those handled before I could address them (no
pun intended).  However, assuming that aggregation has inherent value to
buyers, sellers will avoid them out of self-interest, so we may not need
to put anything into policy.  Is anyone seriously concerned that
assumption is wrong?

S
 

-- 
Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3646 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20110501/c008dba3/attachment.p7s>