On Sep 17, 2014, at 2:40 PM, David Huberman <[email protected]> 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 _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List ([email protected]). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact [email protected] if you experience any issues.
