Dear colleagues, I suggest to just look at the facts here.
Local Internet Registries(LIRs) before the 15th September 2012 have received Provider Aggregatable(PA) allocations from the RIPE NCC. Local Internet Registries after the 14th September 2012 have also received Provider Aggregatable(PA) allocations from the RIPE NCC. There is no mention in the Service Agreement that allocations provided after 14th September 2012 are to be treated differently than those handed out before the 15th September 2012. There is also no mention in the respective policies, as was mentioned during one of the talks at RIPE-72 in Denmark, that allocations received after the 14th September 2012 are to be used for the sole purpose of providing legacy connections to IPv4 networks. Therefore it seems inconceivable that this proposal is allowed to go forward any longer than it already has as it would seek to single out already heavily disadvantaged members even more for the sole reason that they happen to be holding an allocation received after the 14th September 2012. Fellow policy shaping participants, I believe we have several options here: a) Modify this proposal to forbid all types of transfers including mergers and acquisitions. This will provide a level playing field for all RIPE NCC members and not single out members solely on the fact that they have received an allocation after the 14th September 2012. b) Modify this proposal to change the allocation status only for new allocations allocated after this proposal has been accepted and implemented. c) Declare that no consensus has been reached. Additionally I would like to mention that some people seem to think that this proposal will stifle the Local Internet Registry application rate. Let me assure you, it will not. Those of you that believe that this would be the result of the acceptance of this proposal don't fully grasp the reality of the situation we are in. People currently need IPv4 resources to run a business. They don't need IPv6 resources yet and won't be requiring IPv6 resources for the foreseeable future either. A business is required to take the necessary steps to secure their survival and let me assure you they will do just that, just as any business should. Now where do we go from here? I am in favour of making sensible policies that will provide IPv4 address space for the foreseeable future for new members however this proposal is certainly not a way to achieve that as it does not solve the problem at hand. I have been giving this quite some thought which is the reason why I will be putting forward the following proposal within the next week: => Lower the initial allocation a new RIPE NCC member receives down to a /24. => A new member may request an additional /24 every twelve months until he has reached a /22. For aggregation purposes the RIPE NCC will reserve a consecutive /22 for as long as it is possible so new members may reach a consecutive /22 after they have requested four /24 subnets over a time span of four years. Additionally, as I understand it this is something that needs to be voted on, I would like to lower the initial signup fee of currently 2000,00 Euros down to just 500,00 Euros. In case they request an additional /24 after twelve months they will need to pay an additional instalment of 500,00 Euros which will bring the total amount still to 2000,00 Euros if they requested 4x /24 allocations over a period of 4 years. After each allocation the RIPE NCC will aggregate the allocation whenever possible. Subsequently if a new member requests a second /24 the allocation will be enlarged to a /23. In the end he will be left with one /22 if there is sufficient consecutive address space left to do so. In cases where the Local Internet Registry does not require any IPv4 address space it should also not be required to pay any fees apart from the membership fees. Kind Regards, Stefan Prager -- Prager-IT e.U. VAT Number: ATU69773505 Austrian Company Register: 438885w Skype: Prager-IT [email protected] +43 680 300 99 80 Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum
