On Fri, 2015-02-20 at 20:43 +0100, Elvis Daniel Velea wrote:
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/
Thanks - will watch later, and yes I and others could have found them myself of course, but the pointers to timestamps are really helpful - thanks for that. I am genuinely interested in understanding well the situation.
On 20/02/15 18:26, Martin Millnert wrote:
<snip>
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.
Yes, fair. Nothing more to add in this thread on that.
If you want to ask for the evidence for the 70 cases the RIPE NCC has observed, well you could ask Andrea.
I'll watch the videos first and then we'll see.
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-o...
How can _one_ company transfer (up until now) 12 /22s from the last /8 and 3 of them only in February 2015.
Where's the speculation in that? Seems they are just basically transferring space from RIPE /8 pool to customers of theirs. Obviously, this could be something that the community would want to stop, screwing RIPE NCC over the LIR membership fees. But I can't call it "speculation".
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.
Again, since the transfers take effect so quickly, there seems to be zero speculation. The transferring party knows with very high precision that they're going to sell the space to a customer.
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 see how your can interpret my comment as a bullet, but I'm really not against your "industry" at all (if done correctly). And you seem to be behaving well, engaging the policy process / community etc., from what I have seen here. Obviously there is a question of some in your industry sort-of abusing what could be the spirit of the final /8 rule, which in essence is that if you want a /22 from the RIPE NCC free pool, you are supposed to stay a LIR member and feed the NCC with membership fees, lowering the fees for all members since revenue surpasses expenses by too much. And that's what this is really about, right? "Speculation" is to not be certain of the outcome of what you're doing. But if you have a customer waiting list for address space, it isn't speculation, it's merely a pretty useful service optimized within the existing rules.
(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/
Will check later -- divide and conquer, perhaps? /M