[address-policy-wg] 2015-01 New Policy Proposal (Alignment ofTransfer Requirements for IPv4 Allocations)

Hi everyone,

I have thinking at what to answer regarding the comments on this proposal.

Firstly, the /22 from the last /8 policy proposal aimed to create a 
method for anyone to receive at least a few (1024) IPv4 addresses by 
becoming a member of the RIPE NCC.
Even then, the proposers had noted that anyone can open multiple LIRs 
and receive from the RIPE NCC more than 1024 IP addresses and asked the 
RIPE NCC to be vigilant. [1]

What happens now is not in the spirit of that policy proposal as the /22 
from the RIPE NCC does not have the two years holding period so a few 
found a way to make a business using this loophole.
This policy proposal is just trying to add the same holding period for a 
transfer of the /22 as it is already for the rest of the allocations 
made by the RIPE NCC.


While I do agree that if the RIPE NCC free pool would be depleted, the 
market would takeover and normalize the price, the community has decided 
to have IPv4 addresses available for anyone that
  wants to become a member of the RIPE NCC and therefore request & 
receive a /22.
I think that a separate proposal could tackle this issue, there were 
some discussions last year (if I remember correctly) and some members of 
this community suggested the increasing the limit from /22 to /21. That 
may deplete the free pool faster, but it will still slowly bleed out in 
a few years.

If we do not agree that this policy proposal is fair and needed, I 
predict that we will see more and more companies opening LIRs just to 
make use of this loophole and make a profit from selling one or more 
/22s from the last /8.
Actually, this policy proposal may have already harmed the free pool 
because if it does not get approved, more people have found out of the 
loophole and nothing will stop them from using it, they will have the 
endorsement of the community to just go ahead and open multiple LIRs.
I would not be surprised to see a very large ISP or (content) hosting 
company setting up 1.000 LIRs to get 1million IP addresses.. and if they 
setup 1024 LIRs in the same 'day' they may even get a /12 as a 
contiguous block.
In that case, would you find it fair that if someone wants to use a 
loophole (1024 times) they can get a /12 from the RIPE NCC while others 
need to use the market?

Considering these, Martin (and whoever else does not like this policy 
proposal), please let me know if you oppose to to this proposal as it is 
written and if you have any suggestion on what would be acceptable.

regards,
Elvis


[1] https://www.ripe.net/ripe/policies/proposals/2010-02
"Some organisations may set up multiple LIR registrations in an effort 
to get more address space than proposed. The RIPE NCC must be vigilant 
regarding these, but the authors accept that it is hard to ensure 
complete compliance."

-- 
<http://v4escrow.net> 	


  Elvis Daniel Velea


    Chief Executive Officer

Email: elvis at V4Escrow.net <mailto:elvis at v4escrow.net>
US Phone: +1 (702) 475 5914
EU Phone: +31 (0) 61458 1914

Recognised IPv4 Broker/Facilitator in:

This message is for the designated recipient only and may contain 
privileged, proprietary, or otherwise private information. If you have 
received this email in error, please notify the sender immediately and 
delete the original.Any other use of this email is strictly prohibited.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20150309/578d326b/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 5043 bytes
Desc: not available
URL: </ripe/mail/archives/address-policy-wg/attachments/20150309/578d326b/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 11971 bytes
Desc: not available
URL: </ripe/mail/archives/address-policy-wg/attachments/20150309/578d326b/attachment-0001.png>