[arin-ppml] ARIN-prop-176 Increase Needs-Based Justification to 60 months on 8.3 Specified Transfers

[Owen DeLong]

Sent from my iPad

On Jun 29, 2012, at 5:13 PM, David Farmer <farmer at umn.edu> wrote:

> 
> 
> On 6/29/12 10:06 CDT, jeffmehlenbacher at ipv4marketgroup.com wrote:
>> As I previously told you Owen, we are asked once per week by a
>> prospective buyer or seller how these transactions can be accommodated
>> without enduring the rigors of justification.  When we identify the
>> risks for both buyers and sellers alike, they go quiet.  You wonder
>> where they go don't you?  I have a pretty good idea they simply seek
>> alternative means and providers.  So it's not fear mongering to suggest
>> people will disregard the registry.  Some do.  I cannot quantify it
>> because we neither endorse nor monitor.
> 
> We need to find middle ground here guys.
> 

24 months _IS_ middle ground. Continuing to negotiate for half-way to infinity in an iterative process is a perversion of Zeno's paradox designed to effectively achieve infinity over time.

Calling for iterative middle ground is equivalent to calling for infinity.

> John, and others,
> 
> Needs justifications are not going to go away, so stop asking for the community to make it go away, its not going to happen.
> 
> However, on the flip side,
> 
> Owen, and others
> 
> The community does need to find way of simplifying the process and make needs justification less of a burden if transfers are going to work the way we need them too.  If we don't then people will find a way around the process.  Owen, you're fond of John Gilmore's quote about the "Internet routing around damage," well if our policies create damage they will get routed around too and that's not fear mongering.

True, but at 24 months, I am not convinced we are creating damage. (other than the damage caused by the extended dichotomy between free pool justification and transfer justification periods). Going to 36 months or 60 months would only exacerbate that damage.


> So trying to think outside the box here, what if we created some special rules that simplified demonstrating operational need for smaller transfers but still fundamentally kept reasonable needs justifications in place overall.

I'm amenable to discussing that. It sounds reasonable on the surface. However, I don't find it terribly difficult to justify operational need for a smaller allocation/assignment and I believe that the bar for operational need for a transfer is identical to that for an allocation/assignment.

> - Allow any organization to receive a transfer of an unaggregated /24, that the original assignment was a single class C or a /24 that is not part of a larger range of addresses held by the same organization originating the transfer, on the condition that the recipient puts it into operational use within 6 month and they cannot receive another such transfer for 24 months without demonstrating justified need.

I would be OK with that if they can show that it is at least 50% utilized within 6 months and not merely routed.

> - Allow any organization to receive a transfer of up to 50% of their current holdings or /16 which is ever is smaller on the condition that the recipient puts it into operational use within 6 month and they cannot receive another such transfer for 24 months without demonstrating justified need.

I could accept this with the same caveat above if it were limited to /20.

> - All transfers larger than /16 require demonstrating justified need with a window of 24 or maybe 36 months.

24 months, yes. (current policy already). 36 months, uh, no. See my above concern about damage.

> This probably needs work on the details, but is something like this a workable compromise?

Within the constraints I described above, perhaps.

Owen