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

[John Curran]

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.

David - 

   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 
   transfer?  

   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?

Thanks!
/John

John Curran
President and CEO
ARIN