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

As I understand it, RIPE are going through a cost cutting exercise to reduce overheads (the removal of quarterly billing for example due to “complexity” and reducing manpower requirements) …. Obviously this is laudable (if not annoying for those of us with tiny cashflows)… and perhaps they should look at some of the internal projects which have previously burned through cash for limited benefit (I’m thinking the RPKI project which cost over €500,000 and was then shelved in favour of another solution developed elsewhere?)

Perhaps more attention should be focussed on the continuing reduction of RIPE operating costs … reducing the number of staff required, reducing the wage bill, reducing the size of the board and reducing costs there … again passing those savings on to the membership.

RIPE are already returning funds to the LIRs because they have too much cash … Perhaps they should be looking at reducing costs and the cost of being an LIR by reducing the fees we’re paying, not coming up with charging scheme which will actually increase revenues … 

RIPE repeatedly state that IP assignments are not billable resources, that they cannot (for tax reasons) charge for IP addresses … which is fine

They’re basing costs on the amount of paperwork (resource requests) a member makes … they should therefore (imho) be basing any fees on the number of requests a member makes each year .. the more prolific a user of the system, the more that member should pay

As a small ISP we make very little use of RIPE and tbh €1400 seems a lot to pay for membership, but it seems we have no choice as without membership we lose our assignments?  I think on the basis of requests we’ve made of the last few years, we’re probably paying on average about €2500 a request .. which seems crazy

Personally, I would prefer to see a scheme which meant that those using the system were paying for it and those who rarely use the system aren’t penalised … I would certainly like to see the Small ISP membership fee reduce, probably to about €200 a year.  Even if we have to pay a fee for any new resources, if and when we request them … even if this were €50 a request …. It would still mean our RIPE costs were more in line with our usage of the system that’s there

I don’t like the idea that we’re basically subsidising the Larger ISPs who are making hundreds or thousands of requests a year 

Just my 2c

Jon Morby
FidoNet
AS8282



> On 19 Apr 2019, at 11:43, Francesco Cristofori <Francesco.Cristofori at adcgroup.com> wrote:
> 
> 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.
>  
> <image001.png>  
> 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 <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 <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/ <https://mailman.ripe.net/>
> >>> Unsubscribe: 
> >>> https://lists.ripe.net/mailman/options/members-discuss/ivaylo%40bglans.net <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/ <https://mailman.ripe.net/>
> >> Unsubscribe: 
> >> https://lists.ripe.net/mailman/options/members-discuss/me%40cynthia.re <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/ <https://mailman.ripe.net/>
> > Unsubscribe: 
> > https://lists.ripe.net/mailman/options/members-discuss/ivaylo%40bglans.net <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/ <https://mailman.ripe.net/>
> Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/malek%40malek.li <https://lists.ripe.net/mailman/options/members-discuss/malek%40malek.li>_______________________________________________
> members-discuss mailing list
> members-discuss at ripe.net
> https://mailman.ripe.net/
> Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/jon%40fido.net

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.ripe.net/ripe/mail/archives/members-discuss/attachments/20190419/c286883e/attachment.html>