[arin-ppml] ARIN-prop-165 Eliminate Needs-Based Justification

[Astrodog]

On Sun, Feb 19, 2012 at 5:58 PM, Owen DeLong <owen at delong.com> wrote:
>
> On Feb 18, 2012, at 9:48 AM, Astrodog wrote:
>
>> On Fri, Feb 17, 2012 at 7:31 PM, Owen DeLong <owen at delong.com> wrote:
>>>
>>> On Feb 17, 2012, at 1:59 PM, Astrodog wrote:
>>>
>>>> On Fri, Feb 17, 2012 at 3:30 PM, Owen DeLong <owen at delong.com> wrote:
>>>>> Why in such a circumstance would the seller not choose one of these alternatives:
>>>>>
>>>>> 1.      Fragment the space, sell the /20 to the original buyer and move on to looking for
>>>>>        additional buyers.
>>>>
>>>> Any sale will have administrative overhead. The value realized from a
>>>> /20 may not cover the costs incurred to get it sold. As the space is
>>>> fragmented, it requires more and more administrative overhead to sell.
>>>> This makes attempting to sell the space less attractive in the first
>>>> place, given the risk that the transfer may not be approved.
>>>>
>>>
>>> At $10+/address, if you're willing to give up even a /24, it pretty well
>>> covers any likely administrative overhead, so, I have trouble believing
>>> the increasing COGS argument.
>>>
>>
>> Just looking at the legal side of things, at many organizations,
>> they'd be looking at spending a few thousand dollars to work out a
>> sale. Plus whatever time is involved with the rest of their staff to
>> make it happen. (Making sure they really don't use any of the space,
>> finding someone to sell it to, etc, etc.)
>>
>
> Yes, but, most of that expense only has to happen once even if their first attempt at a sale doesn't go through exactly as planned. The incremental cost of the redux for a different sale isn't so high.
>

It isn't as high, but it certainly still exists. The legal costs
working out the sale will pretty much be fixed per transaction. An
organization is much less likely to attempt the transfer in the first
place if there is a significant risk that they will lose money the
first time around, and will be even less likely to attempt a second
transfer after being bitten trying the first.

>>>>>
>>>>> 2.      Find a buyer that does have legitimate need for a /16 (If there's value to not carving it up,
>>>>>        isn't that defined in terms of market demand for the space as a whole?)
>>>>
>>>> The seller is not ARIN. Presumably in the hypothetical, they believed
>>>> that their original buyer had a legitimate need and ARIN disagreed.
>>>> The seller has no way to be sure of which way such a determination
>>>> would go, and incurs all of the administrative cost of attempting a
>>>> sale again, while still having the risk that the transfer would be
>>>> rejected.
>>>
>>> STLS provides an ability for organizations to get ARIN pre-approved for block
>>> sizes, so, this statement is not true. Sellers can choose to work with buyers
>>> that have pre-approval for the size they need.
>>
>> STLS does appear to address some of the concerns with buyers. I do
>> have a couple of concerns with how it works, though. Primarily that an
>> STLS approval does not appear to expire and that any transfer to an
>> organization on STLS regardless of size will require another
>> assessment. That's a whole other discussion, though, so, for the
>> purposes of this one, lets stick with STLS addresses a big part of my
>> concern.
>>
>
> Yes, that's exactly how it works. I agree that an expiration on STLS entries would be a good thing.
>
> The re-qual. is an important safeguard as far as I am concerned. It discourages partial fills and excessive fragmentation due to multiple partial fills.
>
> Glad to hear that STLS mostly addresses your concern. Hopefully that means we can abandon 165 soon.
>

STLS certainly smoothes things over for sellers. I do agree that
fragmentation is undesirable, but if the suggestion here is that
transfers are all need based, the quantity of space an entity needs
does not decrease simply because a partially filled transaction
occurred. If one *needs* a /18, and instead gets a /19, the remaining
/19 is still "needed".

If the intent of the community is to drive transfers based on need,
then an approval for an /18 is also an approval for 2 /19s, 4 /20s,
etc. If an organization is approved for an /18, and gets a /19
instead... and is subsequently denied for another /19, then it sounds
like the original approval for an /18 was incorrect.

>>>
>>>>
>>>>> 3.      Return the /16 to ARIN so that it can be used elsewhere.
>>>>
>>>> While I believe that this is the "right" thing to do in this case, it
>>>> is unlikely that most organizations would choose this path. It offers
>>>> no return, and still has administrative overhead, both in returning
>>>> the space, and in ensuring that they really do not use any of the
>>>> space. It also precludes them from attempting to use the space in the
>>>> future, and does not offer them any direct return.
>>>>
>>>
>>> Agreed, but, I felt the list would be incomplete without this option.
>>>
>>
>> Given how well this option actually solves  the problem, it's
>> unfortunate that I'm guessing almost no one does it.
>>
>
> Actually, ARIN does get more space back than I would have guessed, but, yes, it is an option that is not used nearly as often as it should be.

I think the fundamental problem here is that IP addresses, for better
or worse, have become an "asset" to those organizations that control
them. ARIN may be able to rectify this problem through audits, but
this may be a legal rabbithole that no one actually wants to explore.
If the community has decided that IP space *is* an asset, then the
needs-based allocation doesn't make much sense. If IP space is not an
asset, then I don't understand why 8.3 transfers would be permitted in
the first place. (It becomes something akin to trading food stamps for
cash.)

>
> Owen
>

--- Harrison