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

[Astrodog]

On Mon, Feb 20, 2012 at 3:53 AM, Owen DeLong <owen at delong.com> wrote:
>>>>>>>
>>>>>>> 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".
>>
>
> Yes... The intent of this provision is to discourage people from using
> partial fills instead of seeking larger (potentially more expensive)
> contiguous blocks.
>
> If you do a partial fill, then, you have to start the process all over to
> get the next part, so, you're better off getting what you actually need.
>
>> 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.
>>
>
> No... That provision is there specifically to avoid that for of incentive
> to fragmentation.
>



>>>>>
>>>>>>
>>>>>>> 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.)
>>
>
> I'm not sure what you mean by controlling an IP address. I've never seen
> an integer with a knob on it.
>
> IP addresses are not owned and are not property. Specifically, what is
> being allocated/issued are unique registrations among cooperating parties.
> The only guarantee on an ARIN registration is that it won't conflict with another
> ARIN registration or a registration from another cooperating RIR (currently
> LACNIC, APNIC, AfriNIC, and RIPE-NCC). This says nothing about whether
> or not anyone will route it or whether or not some other party who has no
> registration from an RIR will attempt to use the block on the internet.
>
> As such, I think that there is a large disconnect between the paradigm
> under which you are considering this and what the paradigm which I
> believe applies to the situation.

Personally, I agree with this assessment. However, it isn't how most
registrants view things.

If the assertion is that IPs are *not* an asset, it seems like ARIN
should be reclaiming the space. If someone doesn't need the space
anymore (and, thus, starts looking for a buyer under 8.3), this would
seem like prima facae evidence that they no longer meet the need
requirements anyway.

Is there community support for the elimination of 8.3 transfers
entirely, to be replaced with a more aggressive audit system for need
testing, post-registration, so that the space may be reclaimed?

--- Harrison