[arin-ppml] Draft Policy ARIN-2014-20: Transfer Policy Slow Start and Simplified Needs Verification
jcurran at arin.net
Mon Sep 22 08:42:50 EDT 2014
On Sep 22, 2014, at 5:12 AM, David Huberman <David.Huberman at microsoft.com> wrote:
> Regarding TPIA and MDN, John wrote:
>> 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.
> If I have a MDN buildout in Toronto, Calgary, Montreal, Winnipeg, and Vancouver, and Toronto hit 85% quickly and needs more space, but the other sites aren't at 80%, I'm not going to be at 80% overall utilization. TPIA examples are even more complex, as they deal with more granular buildouts. 2014-20 should not attempt to simplify this, as there are operational realities that should not be ignored.
If we're talking about transfers (as opposed to allocations from the
IPv4 free pool), couldn't those "operation realities" be addressed by
using a lower utilization threshold than 80% for qualifying for a new
I am not for or against the present approach, but want to understand
the community thinking on why enterprises should be prevented from doing
transfers and subject to architecture-specific constraints in order to
receive approval. I have heard concerns expressed about risk of brave
parties engaging in 'hoarding' but is that realistic if the constraints
are relatively easy to comply with but still prevent a hard upper limit?
One might argue that more aggressive constraints actually encourage
folks to hoard, i.e. once you decide to go outside of the registry
system, there would appear to be every reason to maximize the size
of any transaction without regard to registry policy limitations...
> Regarding forward-looking projections, John wrote:
>> 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.
> ARIN staff have been performing this since 8.3 was created, and in general, since the beginning for end-users. In my experience, this step has rarely been the holdup if transfers or end-user requests are taking time. There are exceptions, of course, but that's life running a registry, no?
Yes, this has been the existing practice. I am also personally and
painfully aware that prior to DHCP, IP address assignment within a
local network was done manually, but do not see many folks continuing
that practice simply because of that history...
If there are to be constraints on transfers to new entrants, I will ask
the same question as above - is it better than they be based on directly
evidenced need (equipment and customers in hand) or based on speculative
assertions of future need? ARIN staff can verify a forward-looking plan,
but in the end, it is verification of intentions rather present state of
affairs, and that limits ability to anchor approvals to verifiable data.
> WRT new-entrants, John writes:
>> 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?
> It is not, and it is grossly inequitable. You don't plan and build a network with the intent of using
> 50% of the requested address space "upon receipt". You have a responsibility to your colleagues,
> your customers, and your investors to plan and build for the future - one and two year (and longer)
> timeframes if possible.
Would that be solved by a "33% or 25% utilized on receipt" criteria,
or is the present linkage to IP initial assignment policy superior?
>> 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.
> A simple fix solves this: remove the "25% immediately" from 8.3.3 and continue the staff practice of
> interpreting "50% within one year" as "50% within two years". It's sound math, consistent with the
> original RFC2050's intent of proper conservation.
You've make some passionate arguments for maintaining manual processes
for transfer review based on forward-looking assertions of applicants;
effectively maintaining the for approval regime used for space issuance
from the free pool indefinitely for transfers in the future. Do you see
(per the proposal intent) any opportunities for simplification of present
transfer policy, either by changing the existing proposal or otherwise?
President and CEO
More information about the ARIN-PPML