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

[Owen DeLong]

On May 1, 2011, at 10:44 AM, Stephen Sprunk wrote:

> 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.
> 
I believe that would be acceptable, but I would need to know how staff
would interpret the language and some assurance that said statement
of interpretation would be binding. (Would staff interpretation of
the former paragraph match the example in the latter?) How would
it perform against the examples I posted a few moments ago?

(Since we thought we understood how staff would interpret 8.3 at
the time and it turned out not to work as we thought).

> 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.
> 
This intrigues me. Please elaborate on your desired 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?
> 
I posted some examples a few minutes ago. Hopefully those will
help. Let me know if you ned something else.

I am very concerned that your assumption about the value of aggregation
to buyers is wrong.

Owen

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20110502/ed0d5de5/attachment.htm>