[arin-ppml] 2016-3 Revisited

Mike Burns mike at iptrading.com
Tue Jan 31 11:58:04 EST 2017


Hi Jason,

 

Yes, I would support it without the cap, I don’t think any needs test at all is required for IPv4 transfers and any policy change which makes it simpler and easier to effect transfers will garner my support.

 

In this case the reduction from 80% to 50% is big, and the automatic qualification for newcomer minimums is helpful, and the alternative mechanism for requesting an additional like-sized block as one that is 80% used is helpful.

 

So I support his policy change with or without the cap, as a step towards less uncertainty in transfers, but I would prefer to remove needs testing altogether until and unless some problems arise from that removal.  

 

Regards,
Mike

 

 

From: Jason Schiller [mailto:jschiller at google.com] 
Sent: Tuesday, January 31, 2017 11:48 AM
To: Mike Burns <mike at iptrading.com>
Cc: David R Huberman <daveid at panix.com>; arin-ppml at arin.net
Subject: Re: [arin-ppml] 2016-3 Revisited

 

Mike,

 

I am confused by your email.  

 

You say "I argue that the need to pay money for IP space is sufficient pain to avoid abuse by organizations that don’t actually need IP space."

 

Does than mean you would support the policy as written without the once every six month cap limitation?

 

 

Sounds like you would also support it with the once every six month cap limitation, but would prefer the more simpler version without the cap?  (You will support the cap if that is what is needed to move policy in the right direction)

 

Sounds like you would also support it with the demonstration of 50% utilization of each allocation/assignment, but prefer the more simpler 6 month cap, and very much prefer the even simpler no cap? (You will support demonstration of utilization of greater than 50% if that is what is needed to move the policy in the right direction)

 

You would also support the change if it made no mention of 80% and/or 50% utilization.

 

 

8.5.7 Alternative Additional IPv4 Address Block Criteria

In lieu of 8.5.5 and 8.5.6, organizations may qualify for a specified transfer of IPv4 address blocks up to the smaller of either a /16 or double their current IPv4 address holdings once every 6 months.

 

Is that correct?

 

__Jason

 

On Tue, Jan 31, 2017 at 11:27 AM, Mike Burns <mike at iptrading.com <mailto:mike at iptrading.com> > wrote:

Taking the abuse example above of an organization with a /8 that is is 90% utilized, 

the organization would need to transfer in a /16.  

Then the organization would need to put 32,768 of the new IPs into service, 

or renumber the use of 32,768 of IPs from the older IP space to the new space.

 

I argue that need to show growth or the renumbering of usage into the new IP space 

is of sufficient pain to avoid abuse by organizations that don't actually need the IP space.

 

__Jason

 

 

 

Hi Jason,

 

I argue that the need to pay money for IP space is sufficient pain to avoid abuse by organizations that don’t actually need IP space.  Also any /8 owners have deep pockets and could easily utilize the various policy workarounds which are available, like leases and options. And anybody interested in receiving IP space they don’t need is free to open a RIPE account and do just that. Except nobody does.

 

I support the policy (the re-write and the inclusion of 2016-3) but bemoan the unnecessary complexity required to keep an anachronistic needs test in place in the face of clear evidence from RIPE that it is only there to assuage unsubstantiated fears of hoarding and speculation.  

 

APNIC is considering ending needs tests now, but retaining the RIPE-type language only to ensure ARIN sourced addresses are “needs-tested”, ahem.

 

Regards,

Mike Burns

 

 





 

-- 

_______________________________________________________

Jason Schiller|NetOps|jschiller at google.com <mailto:jschiller at google.com> |571-266-0006

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20170131/6254c650/attachment.htm>


More information about the ARIN-PPML mailing list