[arin-ppml] Draft Policy ARIN-2014-20: Transfer Policy Slow Start and Simplified Needs Verification
jcurran at arin.net
Thu Sep 18 12:04:35 EDT 2014
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.
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
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
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.
President and CEO
More information about the ARIN-PPML