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

Owen DeLong owen at delong.com
Sun Feb 19 18:58:45 EST 2012


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.

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

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

Owen




More information about the ARIN-PPML mailing list