[members-discuss] RIPE NCC Charging Scheme 2020 - Board Reasoning

Hi all,

scheme B will be better for very small LIRs with just a v4 /22 and a v6 assignment, since (if I understand the new scheme the right way) it will grant a saving of 150€/year (1250€/year vs 1400€/year).

It’s a small saving but it’s a saving anyway.

Br,
Francesco.

[cid:image001.png at 01D4F6AD.B5E70BA0]

Francesco Cristofori
Solution Design & PM Manager
T +39 059 7470500
@francesco.cristofori at adcgroup.com<mailto:francesco.cristofori at adcgroup.com>




AD Consulting S.p.A.
Via Natalia Ginzburg, 40
41123 Modena
www.adcgroupspa.com<http://www.adcgroupspa.com/>



From: members-discuss <members-discuss-bounces at ripe.net> On Behalf Of Stuart Willet
Sent: venerdì 19 aprile 2019 12:01
To: Sebastian Malek <malek at malek.li>; ivaylo <ivaylo at bglans.net>
Cc: members-discuss at ripe.net
Subject: Re: [members-discuss] RIPE NCC Charging Scheme 2020 - Board Reasoning

All option B would do is increase revenue.
Nobody is going to return a block for the sake of 50 Euros, given their current value with IPv4 demand so high.
All this will do is sting the newest members who have had to buy blocks to build up IP space.

Regards,
Stuart.

From: members-discuss [mailto:members-discuss-bounces at ripe.net] On Behalf Of Sebastian Malek
Sent: Friday, 19 April 2019 10:56
To: ivaylo <ivaylo at bglans.net<mailto:ivaylo at bglans.net>>
Cc: members-discuss at ripe.net<mailto:members-discuss at ripe.net>
Subject: Re: [members-discuss] RIPE NCC Charging Scheme 2020 - Board Reasoning

In my opinion we should keep the current scheme.

Splitting allocations in the RIPE DB just for this reason makes *no* sense.

If you want to charge per IP or per allocation, it would be better to take the IP count from the LIR portal and calculate the fee based on that.

Regards,
Sebastian

On Fri, Apr 19, 2019 at 11:53 AM ivaylo <ivaylo at bglans.net<mailto:ivaylo at bglans.net>> wrote:

From network point of view nothing will change, Cynthia.

You can still aggregate your announces. See this document point 7.2
https://www.ripe.net/publications/docs/ripe-399

Ivaylo Josifov
Varteh LTD


On Fri, 19 Apr 2019, Cynthia Revstr?m wrote:

> From a networking point of view, this would be extremely idiotic, you would
> fill up routers' memory with routes and take down the internet if you did
> this.
>
> Splitting blocks is just idiotic.
>
> - Cynthia
>
> On 2019-04-19 11:03, ivaylo wrote:
>>
>> Hello,
>>
>> Scheme B will work good and fair to all only with one condition - If ripe
>> split IPV4 ALLOCATED PA blocks dedicated to LIRs in maximum /22 (better
>> /24) blocks.
>>
>> Example:
>> Now LIR-1 have ALLOCATED-PA
>> 10.0.0.0/20<http://10.0.0.0/20>
>>
>> After split LIR-1 will have ALLOCATED-PA
>> 10.0.0.0/22<http://10.0.0.0/22>
>> 10.0.4.0/22<http://10.0.4.0/22>
>> 10.0.8.0/22<http://10.0.8.0/22>
>> 10.0.12.0/22<http://10.0.12.0/22>
>>
>> For IPV6 same splir but based on /32 allocated-pa blocks
>>
>> From technical point of view this automatic split can be done easy.
>> Then Scheme B will be fair for all, and will cover what many of us talking
>> for charging scheme based on IP resources. Also will cover that RIPE NCC do
>> not "sell" IPV4
>>
>> Ivaylo Josifov
>> Varteh LTD
>>
>>
>> On Thu, 18 Apr 2019, Christian Kaufmann wrote:
>>
>>> Dear members,
>>>
>>> First of all, I'd like to thank you for the feedback we received from
>>> everyone so far, and special thanks to the people who gave some more
>>> context and explanation. Trying to arrive at a charging scheme that will
>>> please everyone is not an easy task.
>>>
>>> The reason the board proposes two charging schemes is because some
>>> members requested a real alternative and difference to the existing "one
>>> LIR account-one fee" version we have right now and that is more volume
>>> based.
>>>
>>> This came up previously in the charging scheme task force discussions
>>> but also from individual members via emails or through personal contact.
>>> Nigel and I promised at the last two GMs that we would present a new one
>>> before the May GM this year.
>>>
>>> So what was the board's thinking in proposing these two models?
>>>
>>> Firstly, many people like the existing model and the board believes that
>>> it covers the spirit of what some members want by maintaining the
>>> financial stability of the NCC while keeping fairness and equality in
>>> mind. The board also does not want a price per IP model because this
>>> would have tax implications (the RIPE NCC does not sell IP addresses and
>>> the charging scheme should reflect this) and we feel it is not in
>>> keeping with the idea of a membership association.
>>>
>>> We have also found in the past that having more than two options does
>>> not work well from a voting perspective. This would add considerable
>>> complexity to the voting in which resolutions must be approved by more
>>> than 50% of voters to be adopted.
>>>
>>> The second charging scheme option is one that the board believes offers
>>> a real alternative while staying away from the price per IP aspect.
>>>
>>> The board's thinking in making the Option B proposal is that every
>>> registry entry consumes resources such as customer support time,
>>> database memory, registration time, etc. regardless of the size of the
>>> allocation. A /24 and a /12 are not so different in this regard so we
>>> see this as fair in terms of the work required by the RIPE NCC to
>>> maintain the registry. The reason we suggest to charge IPv4 and IPv6 in
>>> the same way follows the same logic - there is no tax designed to move
>>> people to IPv6. We did not want to have a political, policy-driven
>>> charging scheme because the board believes this is the work of community
>>> rather than for the board or membership to decide on.
>>>
>>> I understand that the "volume-based" description could be seen as
>>> misleading and I apologise for the misunderstanding here. The proposed
>>> model is based on registrations and not per IP as we do not want to
>>> indicate that IP is a sellable product but rather the RIPE NCC should
>>> charge members for the registry services it provides.
>>>
>>> The new charging scheme was also not proposed so that the RIPE NCC could
>>> make more money - it takes the current budget and calculates backwards
>>> to achieve the amount required to run the RIPE NCC. It is just a
>>> different model to share the current cost among members.
>>>
>>> Despite concerns that were raised on this list, the board took the
>>> request of some members to propose a new model very seriously and we
>>> spent quite some time to discuss and model the current scenario by
>>> trying to be as fair as possible and sticking with the principles of a
>>> membership organisation.
>>>
>>> Again, we are very thankful for your input and the feedback on the two
>>> models. We will continue to monitor discussions and we will of course
>>> present on the Charging Scheme 2020 at the upcoming GM. We encourage you
>>> to register your vote so you can have the final say on the two proposals.
>>>
>>> Best regards,
>>>
>>> Christian Kaufmann
>>> RIPE NCC Executive Board Chairman
>>>
>>> _______________________________________________
>>> members-discuss mailing list
>>> members-discuss at ripe.net<mailto:members-discuss at ripe.net>
>>> https://mailman.ripe.net/
>>> Unsubscribe:
>>> https://lists.ripe.net/mailman/options/members-discuss/ivaylo%40bglans.net
>>>
>>
>> _______________________________________________
>> members-discuss mailing list
>> members-discuss at ripe.net<mailto:members-discuss at ripe.net>
>> https://mailman.ripe.net/
>> Unsubscribe:
>> https://lists.ripe.net/mailman/options/members-discuss/me%40cynthia.re
>
> _______________________________________________
> members-discuss mailing list
> members-discuss at ripe.net<mailto:members-discuss at ripe.net>
> https://mailman.ripe.net/
> Unsubscribe:
> https://lists.ripe.net/mailman/options/members-discuss/ivaylo%40bglans.net
>

_______________________________________________
members-discuss mailing list
members-discuss at ripe.net<mailto:members-discuss at ripe.net>
https://mailman.ripe.net/
Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/malek%40malek.li
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.ripe.net/ripe/mail/archives/members-discuss/attachments/20190419/6df5dd36/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 6606 bytes
Desc: image001.png
URL: <https://www.ripe.net/ripe/mail/archives/members-discuss/attachments/20190419/6df5dd36/attachment.png>