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

hi Martin,

I will try to answer some of the points you have raised in the e-mails 
sent to this list in the past couple of days.

On 19/02/15 19:26, Martin Millnert wrote:
> I also oppose this proposal.
>
> I believe the best thing that can happen is for IPv4 to run out
> completely, as fast as possible.
[...]
>    I'm generally in favour of any proposal that hastens the run-out of
> the final /8.
This community has decided to allow any new member to request and 
receive a /22. It is quite clear that the RIPE community has chosen a 
different approach than the one you are in favor of (and which is, if I 
am not mistaken) the chosen path of the ARIN community.

When the last /8 policy kicked in, the RIPE NCC had a /8 in its free 
pool. Since September 2012 the RIPE NCC has made more than 5500 /22 
allocations and the free pool is now even bigger (1.09 /8) than when the 
policy got in effect. [1] shows that there are still 18.36 million IP 
addresses in the free pool.
This means that new entrants will have a method to at least receive a 
/22 from the RIPE NCC for the foreseeable future.

When the last /22 policy was discussed and approved, the members of this 
community knew that even if all the existing members would get the last 
/22, there would still be enough addresses to support 6-8k new entrants 
(considering that at that time there were 9-10k members). Looking at the 
free pool now, I see there is enough space for even more than 10k new 
entrants.
> Increasing the RIPE NCC IPv4 price is counter-productive to that goal.
This policy proposal does not intend to increase the IPv4 price. It only 
wants to close a loophole where someone could just open an LIR only for 
the reason to request and sell the /22 allocation immediately.

I will not try to comment on your conspiracy theories about the 
'Internet world order' and how the community is trying to buy RIPE NCC 
time to adjust to this 'world order'.
I will also not comment on your idea of 'anti-competitive' limitations. 
I think you should have had this discussion when the 'last /22 from the 
last /8' policy proposal was discussed.
I will also not comment on your ideas that the RIPE NCC implements 
'policies without any deliberation at all in the community'. Firstly, 
because I know it's not true as all policy changes have been going 
through this PDP process. Secondly, because I think it's the RIPE NCC 
and the WG chairs who should respond to this 'accusation'. Thirdly, 
because this has nothing to do with this policy proposal.

Finally, If you think that the last /8 policy is bad and that the RIPE 
NCC should implement a policy where all the free pool is depleted as 
soon as possible, feel free to come up with a new policy proposal.

[1] 
https://www.ripe.net/internet-coordination/ipv4-exhaustion/ipv4-available-pool-graph

regards,
elvis
-- 
<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/20150220/2b8a77c6/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: logo.png
Type: image/png
Size: 5043 bytes
Desc: not available
URL: </ripe/mail/archives/address-policy-wg/attachments/20150220/2b8a77c6/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 1.png
Type: image/png
Size: 11971 bytes
Desc: not available
URL: </ripe/mail/archives/address-policy-wg/attachments/20150220/2b8a77c6/attachment-0001.png>