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

[John Curran]

On Sep 17, 2014, at 2:40 PM, David Huberman <David.Huberman at microsoft.com> wrote:

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

David - 

2014-20 appears to have an intent of "policy simplification", so it 
is not surprising that it makes present allocation policy for specific
situations inapplicable when proposing policy text to be used only for 
transfers.

If it were to be adopted, it would provide for any organization at 80% 
overall utilization to transfer at least as much address space as is 
presently held.  

Given that, is it possible that is sufficient for networks who have 
transfer needs, even if those needs would have been considered TPIA- 
or MDN- driven in the past?  For nearly any operational network, the 
ability to transfer in the same number of network resources as 
presently held is likely to be a very substantial quantity.  

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

Correct, but that flexibility comes at a cost, as it creates a burden 
of demonstrating your projected need via an inherently a manual process 
of engagement and review with ARIN staff.  

One of the frequently noted concerns on this list is the desire to move 
towards more straightforward transfer processing, which does appear to 
be picked up in this draft policy, i.e.  if adopted, _any network_ at 
80% utilization would know in advance that it would be approved to 
receive resources of size at least equal to current address holdings 
(and networks growing faster have the option to show their utilization 
history for larger approvals, if desired)

I don't know if the above simplicity is "good" or "bad" from a policy 
perspective, but it certainly would increase certainty on transfer 
approvals, which has been raised as a concern by some in the community.

> 2014-20 seems to say "no, that's wrong. You can't have a 24 month supply based on forecast; you hve 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.

The new entrant situation is a a very important one to consider, but 
the draft policy appears to provide language specifically covering 
new organizations with ability for them to transfer space so long 
it will be at least 50% utilized on receipt. Is that not sufficient?

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

Present transfer policy will effectively preclude new entrants from 
obtaining any IPv4 address space via transfer (unless they can somehow 
first get resources allocated from their upstream ISPs during this 
time of increasing scarcity), so continued thinking and discussion 
on solutions would indeed be prudent.  

Thanks!
/John

John Curran
President and CEO
ARIN