[arin-ppml] Draft Policy ARIN-2014-20: Transfer Policy Slow Start and Simplified Needs Verification

Wed Sep 17 14:40:53 EDT 2014

Kevin's very cogent call-outs were an eye opener for me.  TPIA has gotten the short-shrift from ARIN policy for a long time, and it's a very complex technical situation that needs careful thought.  MDN is a well-practiced policy that applies to specific situations that need different rules.   2014-20 as written inadvertently stomps on these.  That's fixable with language changes, surely.

But even before Kevin posted, I was concerned about the principles of 2014-20. The position that ARIN policy should somehow trump an organization's 24 month projections was big for me. Current 8.3 *as implemented* gives flexibility to the network operator to buy needed IPv4 addresses with a reasonable and business-sane timeline for building out.  You build a forecast, you show it to ARIN staff during the 8.3 or STLS process, and you go buy addresses to fill that need.

2014-20 seems to say "no, that's wrong. You can't have a 24 month supply based on forecast; you have to show past performance" which is something I don't agree with at all.  Needs basis should never be just looking backwards.  That approach ROYALLY penalizes newer entrants, and ignores networks which have irregular growth but recently did well with a product offering and need to quickly deploy a lot of new capacity.

Put this all together, and I find myself opposed to 2014-20.  I heartily applaud Jason for trying to solve a good problem which needs solving. I hope we can continue thinking and discussing solutions to a better solution for post-exhaustion transfers.

David R Huberman
Microsoft Corporation
Principal, Global IP Addressing

-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Owen DeLong
Sent: Wednesday, September 17, 2014 11:25 AM
To: Kevin Blumberg
Cc: arin-ppml at arin.net List (arin-ppml at arin.net)
Subject: Re: [arin-ppml] Draft Policy ARIN-2014-20: Transfer Policy Slow Start and Simplified Needs Verification

I haven't weighed in on this, but I will now.

I remain opposed to the idea of uncoupling transfer policy from section 4. There were good reasons we tied the original section 8 language to the existing section 4 requirements and I believe that the extent to which we have already uncoupled them has already had negative effects.

The 3 month limit on free pool allocations to ISPs is proving to be very dysfunctional. Creating incentives to move to the transfer market while a free pool remains is beneficial only to those seeking to profit from the IPv4 marketplace and does nothing to benefit the community overall.

Yes, the slow start problems and some other problems need to be solved, but we should be solving them with updates to section 4 so that they are solved for both free pool and transfer applications.

Owen

On Sep 17, 2014, at 12:24 AM, Kevin Blumberg <kevinb at thewire.ca> wrote:

> Jason,
> 
> I'm specifically concerned about section 4.5 (Multiple Discrete Networks) and 4.2.3.8 (Reassignments for Third Party Internet Access (TPIA) over Cable). 
> 
> The criteria for those policies I see as being in conflict with the 80 percent aggregate utilization in 8.3.2.1 text. 
> 
> 8.3.2.1 Minimum requirements
> Prior to qualifying for non-M&A address transfers, an organization must demonstrate an average of 80% utilization, as measured under section 4, across the aggregate of all addresses that are currently allocated, assigned, reallocated, or reassigned to, or otherwise in use by, the organization.
> 
> Thanks,
> 
> Kevin
> 
> 
> From: Jason Schiller [mailto:jschiller at google.com]
> Sent: September 16, 2014 10:45 PM
> To: Kevin Blumberg
> Cc: arin-ppml at arin.net List (arin-ppml at arin.net)
> Subject: Re: [arin-ppml] Draft Policy ARIN-2014-20: Transfer Policy 
> Slow Start and Simplified Needs Verification
> 
> Kevin,
> 
> I am not sure I grasp the question.  If the organization is requesting a direct allocation/assignment from  ARIN then they must qualify under 4.x.  If the organization is requesting approval for transfer space, then they must qualify under 8.x.
> 
> I don't immediately see a case where you might qualify under 4.x but not 8.x other than immediate need (I'll come to that shortly), but I'm guessing you do, and we will need to deal with that.  Maybe something got lost in leveling the playing field between ISP and End-user and if so I'm ok with that (although maybe it should have tipped the other way).
> 
> I consciously made "immediate need" different.  I think actually deployment of in 30 days for ISPs or 25% in 30 days and 50% with in 1 year is a bit burdensome, and I have heard that many Orgs ignore this.  I also think it is problematic to size the block based purely on a future looking projection with little recourse to correct things at the 30 day or 1 year mark.  I wanted to put some teeth into it so I wanted proof of actual things to number (maybe 50% is not the right figure).
> 
> So what is the specific scenario you see?
> 
> __Jason
> 
> On Tue, Sep 16, 2014 at 10:07 PM, Kevin Blumberg <kevinb at thewire.ca> wrote:
> Jason,
>  
> In a situation that a request would be approved under a 4.x section, but not in 8.x, which would take precedence?
>  
> Thanks,
>  
> Kevin Blumberg
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to the ARIN 
> Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
> 
> 
> 
> 
> --
> _______________________________________________________
> Jason Schiller|NetOps|jschiller at google.com|571-266-0006
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to the ARIN 
> Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.

_______________________________________________
PPML
You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact info at arin.net if you experience any issues.