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

[Stephen Sprunk]

On 02-May-11 15:41, Owen DeLong wrote:
> On May 1, 2011, at 10:44 AM, Stephen Sprunk wrote:
>> On 01-May-11 11:05, Owen DeLong wrote:
>>> 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?)

That, of course, would fall to Mr. Curran to answer, but I can't see any
valid alternate interpretation.

> How would it perform against the examples I posted a few moments ago?

1. Not allowed, because bisecting past /19 would exceed what was
necessary to meet Org B's justified need.

2. Not allowed, because bisecting past /19 would exceed what was
necessary to meet Org B's justified need.

3. Allowed.  Since no division is required, the above text does not
activate.

4. Allowed.  The /20 would be divided into one /21, one /22, one /23,
and two /24s.  The two /24s would be transferred to Orgs B and C.  The
/23 would be divided into two /24s.  Those two /24s would be transferred
to Orgs D and E.

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

You might have; I knew I didn't understand it, but I also knew that
getting a possibly-broken policy passed ASAP was necessary to avoid
establishing that going around ARIN was the only way to get things done.

>> 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?

My main priority would be changing it from one long, complicated block
of text into something more structured (subsections, lists, etc.) with
shorter, simpler sentences.  The result would almost certainly be
longer, but that's the only way to get clarity.

>> 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 am very concerned that your assumption about the value of
> aggregation to buyers is wrong.

The main value, in my view, comes from the greater likelihood of one's
prefix being accepted in the DFZ both today and in the future.  One /20
is obviously more valuable than sixteen /24s.  However, how high could
ISPs really raise the bar before their customers screamed about not
being able to reach the "entire Internet"?  Is one /19 really more
valuable than two /20s?

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 --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20110502/48d0109e/attachment.htm>
-------------- 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/20110502/48d0109e/attachment.p7s>