[address-policy-wg] 2015-01 Draft Document and Impact Analysis Published (Alignment of Transfer Requirements for IPv4 Allocations)

Hi,

If RIPE would enforce (just like with asn) the announcement of received /22s within a period of 1-2 months after the allocation, hoarding would be stopped. The sellers would not be able to advertise them as "brand new never used", as this detail gives them the most of their value. 
Also, reinforcing the need of justification for requesting the /22, would slow the hoarders, as they would need to come up with (verifyable) justification.

There were lots of valid points against this policy, because it does not address the real problem, and moreso, RIPE NCC directly said that in their opinion it will have no effect over the small hoarding that is going on now. Please read the RIPE NCC impact analysis and you will see this.

Matei Storch
Profisol Telecom
0728.555.004

> On 9 iun. 2015, at 23:18, Marius Catrangiu <catrangiumarius at gmail.com> wrote:
> 
> I fully support this (mail from opteamax gmbh) point of view! and, of course the policy proposal.
> In my opinion it's a bad thing that RIPE did not have strong (backed up with strong detection of unused pools) policies even from the start.
> Thinks are very complicated and i get that, problems can't be foreseen in future and it's easy to judge now how thins could be made easier/simpler but it's not late to start somewhere.
> Another opinion/impression that i have (and this does not affect only RIPE region) is that big providers and content providers do not want ipv6 to be implemented because behind thoese guys are big interests of making profits over the ipv4 exaution and this happened as you saw in Romania (Jump Management) too.
> 
>> On Tue, Jun 9, 2015 at 10:57 PM, Opteamax GmbH <ripe at opteamax.de> wrote:
>> 
>> On 09.06.2015 19:54, Ciprian Nica wrote:>
>> > Come up with a proposal that will really stop this kind of activity and
>> > I'll fully support it.
>> 
>> The only proposal which would actually fully stop this is actually
>> refusing Prefix-Transfers completely and enforce returning to the RIPE-Pool.
>> 
>> The only chance for taking-over Resources then should be a real "merge"
>> of two LIR including the demand of their individual customers justifying
>> why it is important to not being renumbered ... That kind of proposal
>> would actually remove a lot of "profit-making" for brokers etc. on one
>> hand, but on the other hand it offers the opportunity to the ones really
>> needing IPv4-Space to get their need fullfilled by RIPE... at least if
>> that kind of proposal would also enforce withdrawing IP-space which is
>> not being really used for a while.
>> 
>> Actually if that'd be done world-wide with all address-space not
>> publicly routed - and therefore easily to replace with 10.0.0.0/8 - we'd
>> have sufficient IPv4 for the next decades ... Just a brief look into the
>> routing-table on my router and I see 10 complete /8 (so called public
>> IP-Space-prefixes) which are completely not announced and another 4 /8
>> with less then one /21 announced.... and I do not want to know how many
>> of the large /8 to /14 announcements are actually routed into a
>> blackholes, as there are no real users on large parts of those nets.
>> 
>> ... and we discuss about /22 nets being "hoarded"?
>> 
>> Sorry, could not resist to point on that.
>> 
>> Still I support the proposal because it reduces the win for abusers and
>> raises the risk that the now "hoarded" addresses are less worth when
>> they are sellable. Hey, it is on us to make IPv4-Prefixes worthless.
>> 
>> Best regards
>> 
>> --
>> Jens Ott
>> 
>> Opteamax GmbH
>> 
>> Simrockstr. 4b
>> 53619 Rheinbreitbach
>> 
>> Tel.:  +49 2224 969500
>> Fax:   +49 2224 97691059
>> Email: jo at opteamax.de
>> 
>> HRB: 23144, Amtsgericht Montabaur
>> Umsatzsteuer-ID.: DE264133989
> 
> 
> 
> -- 
> Catrangiu Marius
> Mobil: 0770481857
> Mail: catrangiumarius at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20150609/f0eeb10a/attachment.html>