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

hi Martin,

maybe I should have started my first e-mail to this proposal with the 
links of the recordings at RIPE69 in London where we have discussed the 
creation of this policy proposal:
https://ripe69.ripe.net/archives/video/200/
https://ripe69.ripe.net/archives/video/10147/

On 20/02/15 18:26, Martin Millnert wrote:
> Hi Elvis!
>
> On Fri, 2015-02-20 at 15:10 +0100, Elvis Daniel Velea wrote:
>> 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.
> Thank you.
>
> <snip>
>> This means that new entrants will have a method to at least receive
>> a /22 from the RIPE NCC for the foreseeable future.
> At the current burn-rate, 8 years.
Want to bet it's going to be more than 10? I would even dare to say 15 
at a normal pace.
But only if this policy proposal does not get approved and the type of 
speculation this policy proposal tries to prevent doesn't speed up even 
more than it has in the few months since RIPE69.
>
>> When the last /22 policy was discussed and approved, the members of
>> this community [...] I see there is enough space for even more than
>> 10k new entrants.
> I have no argument against that this is what the community has decided.
But you would like to change it... Please do start a separate topic if 
you feel like you would maybe want to come up with a proposal in that 
direction.
>
>>> 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.
> Nod.  On your website, http://v4escrow.net/policy-development/ , I
> learned that your organisation was asked by some in the room to produce
> this (and other?) policy proposals, referring to slide 10 of
> https://ripe69.ripe.net/presentations/72-APWG_RS_Feedback_Final.pdf .
Well, as mentioned above, the video is also available, you could have 
found it easily if you wanted to (it is in the presentation archives of 
the RIPE Meeting).
https://ripe69.ripe.net/archives/video/200/
You can see Andrea's presentation there, the interesting part starts at 
7:50, the discussion of this topic starts at: 18:00 and lasts until the end.

Further discussion where I have been asked to 'volunteer and 'be the 
target for the tomatoes':
https://ripe69.ripe.net/archives/video/10147/
(30 more minutes :)

>   I
> wasn't there, but on your website you're talking about that there is
> "speculation" going on with this address space and that it is the
> speculation that you want to stop with this policy proposal.
That is actually what I also mentioned in the policy proposal.
> Could you elaborate or provide evidence for that? The slide referenced
> doesn't support the claim.
If you want to ask for the evidence for the 70 cases the RIPE NCC has 
observed, well you could ask Andrea.

some things that I have noticed, and this is public data:

1. see the example of registries ru.ibulavkin* on one side. I think they 
have opened about 27 registries in a few months. They have 6 opened at 
this moment and I believe #23 and #25 will be closed to make room for 
more harvesting.
ftp://ftp.ripe.net/ripe/stats/membership/alloclist.txt
I think all of their /22s are merged into ru.srv2013 (as they have 24 of 
those /22s) which is on the same name. I could also bet that the 4 /22s 
they have in registries #22, #24, #26 and #27 will be merged into the 
big one and I am not sure that we could ever prevent that. I kinda see 
it as a legitimate way to getting addresses if they really use them and 
not stockpile.

However...

2.have a look at the transfer list and filter for QuickSoft LLC.
https://www.ripe.net/lir-services/resource-management/ipv4-transfers/table-of-transfers

How can _one_ company transfer (up until now) 12 /22s from the last /8 
and 3 of them only in February 2015.

3. If you further verify the list of transfers and the 
delegated-extended files, filter for /22s from 185/8 you will even find 
allocations that have been made by the RIPE NCC and transferred within a 
week from the allocation date.
>    Buying and selling address space isn't at all necessarily
> "speculation". It's just reselling, right? Just like your business.
I would not compare them, but I'll take this bullet for the sake of the 
proposal...
(Gert, you said tomatoes, not bullets directed to my business :)... heh, 
should have expected it.
>
> (I also learned on your website that your organisation is involved with
> making policies -- transfer policies I assume -- better.  I approve of
> that work!)
Well, not only. I/we also volunteered (along with a few other 
co-authors) to unify the IPv6 policies into one simple document (as also 
requested by the community at a few RIPE Meetings). However, that policy 
proposal was withdrawn after RIPE67 because the changes it proposed were 
too complex.
https://ripe67.ripe.net/archives/video/36/

[...]
>
>> 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.
> I'll retreat and think a bit about it. :)
I would also welcome a constructive approach to this proposal :)
>
> /M
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/bc7d7548/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/bc7d7548/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/bc7d7548/attachment-0001.png>