Hi,  For Profit or Non-Profit, the type of organization shouldn’t influence RIPE fees. If a non-profit cannot get that minimal amount of revenue in, it probably is not worth operating and does not bring sufficient amount of value to its members to be able to even raise enough for increased RIPE costs.  We are not operating in a vacuum; unless fee increases are matched by ARIN, APNIC, and others, any increase would further disadvantage European operators. That would make us Europeans even more the memeable "Europoors" and at even further disadvantage in the market place (taxation and bureaucracy being heavy, VAT etc. are already a huge disadvantage for those of us whose target audience is global. European private customers significantly avoid us because of VAT; We have to sell at lower prices than competitor by roughly the amount of average VAT.)  Perhaps upkeep of IPs should cost more, that would eventually start vacating addresses due to upkeep cost, which would lower the acquire costs. However, RIPE does not operate in a vacuum. If RIPE is the first to increase fees and others don’t follow...  Capitalism is by far the best known way to man to distribute resources efficiently. There's nothing else which comes even close for resource distribution efficiency. ----  As a small business owner we have not implemented IPv6 at all, nor have plans for such. It's too costly for little to no benefit. All our customers need IPv4 regardless, and no-IPv4 address drops the marketable price so so very low it's not worth the effort to do. From our customer base, maybe 1% or less of traffic would go over IPv6, and in ~every case, IPv4 is also available. Even the most prolific IPv6 advocate customer we've had, had to ultimately admit it would be at most 4-4.5% which would go over IPv6 -- and on his case, i'm certain he was exaggerating by multitudes.  Many of our business decisions are driven by the cost of acquiring IPv4 addresses, and admittedly we've been hoarding a little bit in order to do a project, and expect to exhaust our available addresses very soon after launch.  As costly as IPv4 addresses are, IPv6 addresses cost orders of magnitude more, even before accounting for the (lack of) usefulness factor. This despite over 2 decades since first time using IPv6 (Since the early implementations of IPv6, using HE.NET tunnel service). IPv6 would actually decrease the performance and value for our end users, only perception of value would increase.  Costs are not in hardware, that's cheapest and easiest portion actually -- even if you have to buy a brand new router. The true cost is in the administrative side, all of the extra steps and processes needed to maintain IPv6 addressing, extra security precautions (some people demand a /56 for themselves, and then uses a new IPv6 address for each new application start, exhausting switch/router caches, essentially DOS'ng the network). It all is a continuous drag and extra work. What's most expensive is human effort, and if you now take something which used to take 3 seconds each time, and expand it to be 30 seconds, or even 10 seconds, multiply it by X times per day, for Y years -- it all becomes really really rather expensive. You might say "but you can automate this" -- Someone has to create that automation and rules first still. All of which exists, is abundant, and well tested for IPv4 but not for IPv6.  Personally i do not believe IPv6 will become mainstream ever, for the basic fact that not everyone will ever support it, therefore IPv4 is always required. You'd be surprised from what kind of places i hear customers/end users being instructed to actually remove IPv6 to have their network operating more smoothly. Places you'd never expect, and would actually expect to be advocates for IPv6. ----  Technical solution; There's been some proposals for "IPv4e", extending IPv4 addressing by a few bits, as an addon. All of those proposals have also mixed features and layers, tried to put stuff not belonging in this layer to it. Just like IPv6. It's easy to think complicated == good, but reality is, the simplest solution is almost always the right answer.  I don't know the low level well enough to do a proof of concept, but have postulated for more than a decade now that it could be possible to add "extension", and keep routing the same, only software updates on the extension area; gateways, client and server. 10.10.10.10 could have 2 additional segments, extra 16 bits used per packet + how many bits to identify in header this is extended address. A packet arrives to 10.10.10.10 and have extension segments of .5.5 set in the packet headers, therefore target is 10.10.10.10.5.5, and only the 10.10.10.10+10.10.10.10.5 gateway/routers, and 10.10.10.10.5.5 server along with the client needs to understand the extension. Reaching for 10.10.10.10 would not have those extra bits set. In the extended network area devices have to understand this tho, but only in the extended area, otherwise ARP tables etc. would not work.  Since it's just software for the most part, and for the most part only client & server, this would get distributed over time like "magic", automatically. Old routers with old software, old ASICs would continue to work, it's only what comes after them needing to understand what those bits in the header mean. In other words; For the first steps of mass adoption, only OSs need to be updated. Would get adopted more than IPv6 in manner of a OS lifecycle, initially people could utilize those more like ports, assign an IP per application as an example, or for IoT. A decade later, this would automatically have probably 95+% adoption rate on the OS side, which is more than sufficient for switching chip manufacturers to add the support for that 16-24bits required.  Even the network admins don't need to know this is running at all, if they don't want to. End users can still benefit from it. Even better, this probably could be made dynamic, add extension 8 bit segments on as needed basis to a certain maximum. so a /32 could have added /24 or /16 or /8 of added IPs, however many bits we'd decide as the maximum depth. 16? 24? another 32? maybe even 48 or 64? -- and everyone currently working in networking (or even somewhat close to) would understand this methodology, it's just added segments of addressing. KISS - Keep It Simple, St***d!  For Legacy stuff, NAT works fine, but it could be extended further to have just translation of extended address to a internal IP and vice-versa. Computationally, would cost very little, less than typical NAT.  Ultimately, everyone would understand this, and would probably still fit into the working memory of most normal human beings :) This would not be a paradigm shift in thinking, and could be metaphorically be described as "special NAT". Just an extension, an extended range.  And all this "IPv4e" would do is just extended addressing, nothing else, nothing more, nothing less. Only that, and nothing else. No confusion, no ifs, no buts, just Keep It Simple.  To be fair, this might be Dunning-Kruger effect, i haven't worked at that low level really ever (a little bit maybe early 00s crafting packets manually) and there are far more knowleadgable people who could immediately say do we have means to add those packet headers. We should, since we got things like LACP, VLANs etc etc. all of which takes packet header space. Despite this, I have yet to speak with a network engineer who has explained why this wouldn't work. Some have even suggested that I should write an RFC on this topic. However, i digressed here a little bit off topic ... Best Regards,  Aleksi  Magna Capax Finland Oy PS. I typically only lurk on this mailing list and read only a few random responses, if you want to discuss IPv4e further feel free to contact me directly. With your feedback, perhaps an RFC shall finally be written, a RFC more than a decade in the making. On 01/04/2024 12.35, Mihail Fedorov wrote:

Hi Hank!

No one is assuming any disrespect to IUCC and it’s part in building internet here. But I just bothered checking (sorry, did it just for an example) - IUCC owns two /16’s, one /18 and lots of /20-/22s. Can you check for us how many of them are actually assigned to some interfaces?

Typically it will be below 10%. If I’m right - that means that IUCC alone stops at least 576 small non-profit or startup networks from being legitimate part of routing table.

If I’m wrong - please forgive me and just give me /24 to subrent :-)

And yes, I assume that any company who administer 65000 interfaces (65000 computers or routers) should feel affordable paying ~6500 - ~65000 USD - effectively solving all possible RIPE financing problems. Except very rare cases of large non-profit networks.

P.S.: Each and every small network I see on IX has already appreciated and implemented IPv6 support. But realistically they still need some v4. And only large v4 space holders sometimes do not bother implementing IPv6 at all.

...

On 1 Apr 2024, at 11:49, Hank Nussbacher <hank@interall.co.il> wrote:

On 29/03/2024 14:49, Gert Doering wrote:

IUCC was the first paying member to RIPE NCC in 1995 (since we realized the importance of supporting such a fledgling organization) and we have paid for our resources for the past 29 years.

See attached (page 3 of 4 pages - if anyone wants to see the full 4 page document - drop me an email off-list).

Regards, Hank

...

...

Hi,

On Thu, Mar 28, 2024 at 07:04:30PM +0100, Andrea Borghi wrote:

...

My humble proposal is to class basing on how many additional resources a company have beyond the basics that was valid at the time of joining Ripe.

... and possibly how old these resources are... we got our blocks in 1995/1996, and they are considered "large" by today's standards.  Back then, it was what you got as a fast-growing small ISP...

So if we really go for something based on allocation size, adding a yearly depreciation factor in would make this "more fair" (... we've been paying our share for the last 29(!) years already).

Gert Doering -- NetMaster

_______________________________________________ members-discuss mailing list members-discuss@ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe:https://lists.ripe.net/mailman/options/members-discuss/hank%40interall.co.il

<ripe.jpg>_______________________________________________ members-discuss mailing list members-discuss@ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe:https://lists.ripe.net/mailman/options/members-discuss/mihail%40fedorov.net

_______________________________________________ members-discuss mailing list members-discuss@ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe:https://lists.ripe.net/mailman/options/members-discuss/aleksi%40magnacapax.f...

Hi,  "IPv4e" -- You probably missed the point about it not needing hardware updates initially at all? Only software. Routing etc. would all remain identical, those extra bits would be in the packet header and only end points need to understand those headers. 52% is not sufficient IPv6 connectivity, even 100% would not be -- It needs to match or exceed IPv4 performance. ie. routing has to be better. Unfortunately, due to design, i don't think that's feasible ever either because the routing tables will grow exponentially larger than IPv4. Right now, IPv6 route is often weaker than IPv4 to my experience. IPv6 OpEx is much higher than IPv4, to our experience as well. It's not even a competition. Br,  Aleksi  Magna Capax Finland Oy On 01/04/2024 15.37, ivaylo wrote:

The subject of this discussion go a lot ofside. I dont know why you bloat the theme (maybe it is intensionly ?) leading it to IPV4 holding. Our main focus _SHOULD_ be RIPE budget and financing + sustainabla operation in the next year and in the future at all. This of course is related with the members fee.

I done a little research and calculations, to tune my initial propousal so: By IANA public documents current delegated resources to RIPE are:

86016     IPV4 /19 blocks 66624     IPV6 /27 blocks 42882     ASN

If we have a hard coded limits for each LIR, equal steps up, and member fee of 750 EURO per year, each LIR can hold up to:

1 x /19 IPV4 BLOCK (sumary = 32 x /24 networks) 1 x /27 IPV6 BLOCK (sumary = 32 x /32 networks) 16 ASN numbers

After pass one of the above parameters even with one /24 IPV4, /32 IPV6, or ASN, +750 euro (1500 euro RIPE fee) up to the next proporcional limit:

2 x /19 IPV4 BLOCK (sumary = 64 x /24 networks) 2 x /27 IPV6 BLOCK (sumary = 64 x /32 networks) 32 ASN numbers

and so on...

This will generate 64 512 000 euros annual budget for RIPE which is absolutely enough for normal operations in each of the next 10 years, without need to increse members fee each year.

If somebody is afraid, that other RIRs will not keep going with RIPE fees, and there will be posibly leave of the big resource holders, keep in mind that all small members from the other RIRs will move to RIPE. Also good luck moving to ARIN db mess, the risk to lost route of your prefixes is nearly 90%.

---------- Off topic: About IPV4/IPV6 resources, it is imposible to create kind of ipv4 adress space extension. Many hardware do lookup over the ip header, it is not only software related. Even somebody develope a public standart about that, will take decades before all replacing equipment all over the world and another decades all to be workable. We have working IPV6, right now more than 52% has IPV6 connectivity. Biggest EU access operator already give dual stack IPV4/IPV6 even to their end users, and activlly deploy IPV6 stack into their networks. It is much more cheaper in long perspective than to buy/rent IPV4 (NAT/proxy your clients/services over IPV4 and give them IPV6 real addresses). After 2-3 years the core of the Internet will be over IPV6, yes we will need to support IPV4 for the next 10-15 years to provide backward connectivity, but it is a dead end. All who thinks they will do a big profit from IPV4 adresses they hold, do seriously mistake in their logic, but anyway it is their problem. Those who dont implement IPV6 because "yay it is so scary and not working" in one moment will have to do this fast without experience, because will have seroius troubles with IPV4 connectivity.

Ivaylo Josifov VarnaIX / Varteh LTD +359 52 969393 Varna, Bulgaria

_______________________________________________ members-discuss mailing list members-discuss@ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/aleksi%40magnacapax.f...

Yes, by all means. Let's stop all research and development globally, because we already know every possible further development will fail because of previous failures, therefore any attempts for further development on anything would be futile and fruitless. -- That logic does not compute, sorry. Do you know how many attempts Edison had to do to make the first light bulb? Maybe he should've just stopped after a couple of attempts and deem it impossible? Just because prior proposals/methods/ideas didn't work, doesn't mean a new one wouldn't or that all avenues have been explored. Like i stated earlier, all the prior proposals i have seen are convoluted and complicated, mixing up things that don't belong there. So what's the complete unworkable thing on this? It requires zero network upgrades, only end points need to understand this. Therefore, adept coder makes a patch, it gets included in Linux kernel after a while of testing, and just couple years down the line you have what 90-95% of servers supporting it already? Please by all means, show how this would not work. I am curious as to why? Br,  Aleksi  Magna Capax Finland Oy On 01/04/2024 16.38, Q Misell wrote:

...

 "IPv4e" -- You probably missed the point about it not needing hardwareupdates initially at all?

Can we please stop discussing upgrades to IPv4. Every single suggestion that anyone has presented in recent years has been proven entirely unworkable. It's not worth even discussing them at this point. ------------------------------------------------------------------------

Any statements contained in this email are personal to the author and are not necessarily the statements of the company unless specifically stated. AS207960 Cyfyngedig, having a registered office at 13 Pen-y-lan Terrace, Caerdydd, Cymru, CF23 9EU, trading as Glauca Digital, is a company registered in Wales under № 12417574 <https://e.as207960.net/w4bdyj/LMqmSZRX>, LEI 875500FXNCJPAPF3PD10. ICO register №: ZA782876 <https://e.as207960.net/w4bdyj/AmZwGXyq>. UK VAT №: GB378323867. EU VAT №: EU372013983. Turkish VAT №: 0861333524. South Korean VAT №: 522-80-03080. AS207960 Ewrop OÜ, having a registered office at Lääne-Viru maakond, Tapa vald, Porkuni küla, Lossi tn 1, 46001, trading as Glauca Digital, is a company registered in Estonia under № 16755226. Estonian VAT №: EE102625532. Glauca Digital and the Glauca logo are registered trademarks in the UK, under № UK00003718474 and № UK00003718468, respectively.

On Mon, 1 Apr 2024 at 13:54, Aleksi <aleksi@magnacapax.fi> wrote:

Hi,

  "IPv4e" -- You probably missed the point about it not needing hardware updates initially at all? Only software. Routing etc. would all remain identical, those extra bits would be in the packet header and only end points need to understand those headers.

52% is not sufficient IPv6 connectivity, even 100% would not be -- It needs to match or exceed IPv4 performance. ie. routing has to be better. Unfortunately, due to design, i don't think that's feasible ever either because the routing tables will grow exponentially larger than IPv4. Right now, IPv6 route is often weaker than IPv4 to my experience.

IPv6 OpEx is much higher than IPv4, to our experience as well. It's not even a competition.

Br,   Aleksi   Magna Capax Finland Oy

On 01/04/2024 15.37, ivaylo wrote: > > The subject of this discussion go a lot ofside. I dont know why you > bloat the theme (maybe it is intensionly ?) leading it to IPV4 > holding. Our main focus _SHOULD_ be RIPE budget and financing + > sustainabla operation in the next year and in the future at all. This > of course is related with the members fee. > > I done a little research and calculations, to tune my initial > propousal so: By IANA public documents current delegated resources to > RIPE are: > > 86016     IPV4 /19 blocks > 66624     IPV6 /27 blocks > 42882     ASN > > If we have a hard coded limits for each LIR, equal steps up, and > member fee of 750 EURO per year, each LIR can hold up to: > > 1 x /19 IPV4 BLOCK (sumary = 32 x /24 networks) > 1 x /27 IPV6 BLOCK (sumary = 32 x /32 networks) > 16 ASN numbers > > After pass one of the above parameters even with one /24 IPV4, /32 > IPV6, or ASN, +750 euro (1500 euro RIPE fee) up to the next > proporcional limit: > > 2 x /19 IPV4 BLOCK (sumary = 64 x /24 networks) > 2 x /27 IPV6 BLOCK (sumary = 64 x /32 networks) > 32 ASN numbers > > and so on... > > This will generate 64 512 000 euros annual budget for RIPE which is > absolutely enough for normal operations in each of the next 10 years, > without need to increse members fee each year. > > If somebody is afraid, that other RIRs will not keep going with RIPE > fees, and there will be posibly leave of the big resource holders, > keep in mind that all small members from the other RIRs will move to > RIPE. Also good luck moving to ARIN db mess, the risk to lost route of > your prefixes is nearly 90%. > > ---------- > Off topic: About IPV4/IPV6 resources, it is imposible to create kind > of ipv4 adress space extension. Many hardware do lookup over the ip > header, it is not only software related. Even somebody develope a > public standart about that, will take decades before all replacing > equipment all over the world and another decades all to be workable. > We have working IPV6, right now more than 52% has IPV6 connectivity. > Biggest EU access operator already > give dual stack IPV4/IPV6 even to their end users, and activlly deploy > IPV6 stack into their networks. It is much more cheaper in long > perspective than to buy/rent IPV4 (NAT/proxy your clients/services > over IPV4 and give them IPV6 real addresses). After 2-3 years the core > of the Internet will be over IPV6, yes we will need to support IPV4 > for the next 10-15 years to provide backward connectivity, but it is a > dead end. All who thinks they will do a big profit from IPV4 adresses > they hold, do seriously mistake in their logic, but anyway it is their > problem. Those who dont implement IPV6 because "yay it is so scary and > not working" in one moment will have to do this fast without > experience, because will have seroius troubles with IPV4 connectivity. > > > > > Ivaylo Josifov > VarnaIX / Varteh LTD > +359 52 969393 > Varna, Bulgaria > > _______________________________________________ > members-discuss mailing list > members-discuss@ripe.net > https://lists.ripe.net/mailman/listinfo/members-discuss <https://e.as207960.net/w4bdyj/JqounabO> > Unsubscribe: > https://lists.ripe.net/mailman/options/members-discuss/aleksi%40magnacapax.f... <https://e.as207960.net/w4bdyj/bXMhzevz>

_______________________________________________ members-discuss mailing list members-discuss@ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss <https://e.as207960.net/w4bdyj/Z54J0XCc> Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/q%40as207960.net <https://e.as207960.net/w4bdyj/koxbybwf>

On 04.04.24 12:09, Aleksi wrote:

So what's the complete unworkable thing on this? It requires zero network upgrades, only end points need to understand this.

Go ahead and *prove* that. Grab a bunch of middleboxes - plain NAT implementations, commercial firewalls, IPSes, application level gateways, even just routers that do fragmentation and/or reassembly, some of which have the *explicit task* to "normalize the bytestream" (as long as we're talking TCP) and thus regenerate packet headers from the info they gleaned from the original ones - and demonstrate that your "extension segments", wherever in the packet headers you plan to hide them, get through all of that unscathed, in spite of the boxes having no idea of what you're doing. (And *then*, for sake of completeness, demonstrate that *somehow*, having the relevant "unextended" IP address NATed away also causes the corresponding extension to get dropped/invalidated - *still* with no pertinent update to the middleboxes to teach them about your scheme.) Kind regards, -- Jochen Bern Systemingenieur Binect GmbH

I'm fine with paying a simple flat fee of 0.1 € per v4 address per year if that means one IPv4 Equals one vote. If I pay more, then my vote counts for more, plain and simple. If you don't think that will come to pass, then you don't understand the magnitude of politics and money as a driving force. Daniel~ On 4/1/24 08:06, Mihail Fedorov wrote:

Which, by strange coincidence, almost identical to simple flat fee of 0.1 € per v4 address per year.

The only difference is that owner of single /24 can pay 25 € per year and owner of /16 - 6375 € without steps or limitations required.

Still giving RIPE approx 60 mil budget together.

Literally everyone benefits - including companies that actually need a lot of addresses and currently buying them on aftermarket terribly overpriced.

...

On 1 Apr 2024, at 15:38, ivaylo <ivaylo@bglans.net> wrote:

 The subject of this discussion go a lot ofside. I dont know why you bloat the theme (maybe it is intensionly ?) leading it to IPV4 holding. Our main focus _SHOULD_ be RIPE budget and financing + sustainabla operation in the next year and in the future at all. This of course is related with the members fee.

I done a little research and calculations, to tune my initial propousal so: By IANA public documents current delegated resources to RIPE are:

86016 IPV4 /19 blocks 66624 IPV6 /27 blocks 42882 ASN

If we have a hard coded limits for each LIR, equal steps up, and member fee of 750 EURO per year, each LIR can hold up to:

1 x /19 IPV4 BLOCK (sumary = 32 x /24 networks) 1 x /27 IPV6 BLOCK (sumary = 32 x /32 networks) 16 ASN numbers

After pass one of the above parameters even with one /24 IPV4, /32 IPV6, or ASN, +750 euro (1500 euro RIPE fee) up to the next proporcional limit:

2 x /19 IPV4 BLOCK (sumary = 64 x /24 networks) 2 x /27 IPV6 BLOCK (sumary = 64 x /32 networks) 32 ASN numbers

and so on...

This will generate 64 512 000 euros annual budget for RIPE which is absolutely enough for normal operations in each of the next 10 years, without need to increse members fee each year.

If somebody is afraid, that other RIRs will not keep going with RIPE fees, and there will be posibly leave of the big resource holders, keep in mind that all small members from the other RIRs will move to RIPE. Also good luck moving to ARIN db mess, the risk to lost route of your prefixes is nearly 90%.

---------- Off topic: About IPV4/IPV6 resources, it is imposible to create kind of ipv4 adress space extension. Many hardware do lookup over the ip header, it is not only software related. Even somebody develope a public standart about that, will take decades before all replacing equipment all over the world and another decades all to be workable. We have working IPV6, right now more than 52% has IPV6 connectivity. Biggest EU access operator already give dual stack IPV4/IPV6 even to their end users, and activlly deploy IPV6 stack into their networks. It is much more cheaper in long perspective than to buy/rent IPV4 (NAT/proxy your clients/services over IPV4 and give them IPV6 real addresses). After 2-3 years the core of the Internet will be over IPV6, yes we will need to support IPV4 for the next 10-15 years to provide backward connectivity, but it is a dead end. All who thinks they will do a big profit from IPV4 adresses they hold, do seriously mistake in their logic, but anyway it is their problem. Those who dont implement IPV6 because "yay it is so scary and not working" in one moment will have to do this fast without experience, because will have seroius troubles with IPV4 connectivity.

Ivaylo Josifov VarnaIX / Varteh LTD +359 52 969393 Varna, Bulgaria

_______________________________________________ members-discuss mailing list members-discuss@ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/mihail%40fedorov.net

---

members-discuss mailing list members-discuss@ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/daniel%40privatesyste...

Dear Ivaylo, We believe that such big immediate increase will have impact in any case. The budget planned globally and costs calculated for every contract offer and for every price have been made based on the existing situation, so we can change it for future cases but not for the existing ones. And all the resource administration surely has been made based on the current model not depending on the resources hold and can not be modified immediately. Considering your observations, agree that with consolidation of LIRs and dropping their number we will have membership fee increase in coming years in any case, however that will be step-by-step increase and will not have immediate impact, and also will enable timeframe to make necessary adjustments. Regards, Naira -----Original Message----- From: ivaylo <ivaylo@bglans.net> Sent: Monday, April 1, 2024 6:48 PM To: Naira Kuroyan <NKuroyan@telecomarmenia.am> Cc: Hank Nussbacher <hank@interall.co.il>; members-discuss@ripe.net; interconnect <interconnect@telecomarmenia.am>; core-network <core-network@telecomarmenia.am> Subject: Re: [members-discuss] RIPE NCC Charging Scheme 2025 Open House: Recording and Slides Available Hello, It is change and will change more rapid, with consolidation of LIRs and dropping their number, we will get 20% membership fee increse if not for 2025 but for 2026. With resources Telecom Armenia holds right now and with flat steps up charging scheme I offer, the annual RIPE fee for your company will be: 16500 Euros With other words 1375 Euros per month ! Lets be serious you really think that such money will cut your long therm company contracts ? Or will affect prices in some way your company gives to the customers ? How much % of your company annual turnover are 16500 euros ? We need to create much more sustainable and predictable future of RIPE. In same time to fix all mistakes done by now (because or because not someones interests) and make things fair for all members. Also it is very very posible RIPE to attract new members wich automaticaly will lower the fee your company will have to pay after time. Ivaylo Josifov VarnaIX / Varteh LTD +359 52 969393 Varna, Bulgaria On Mon, 1 Apr 2024, Naira Kuroyan via members-discuss wrote:

Hello!

We believe that in any case the cost of membership charge may not increase significantly, when nothing has changed in Company's business activities and in resources assigned. This is not acceptable for any business. The significant increase of the price level is challenging and stuggleing for the Members (and their customers), especially from not stable and economically less developed regions, where polytical, economical, country development situation can have a significant impact on the local economy, with the ability of their members and their customers to pay increased charges, especially during difficult times. We can not imagine any case in the world when the charge for services increases more than the maximum increase level limited to 20%.

You can imagine how the significant increase will impact the Company's business activities. E.g. the Company has planned its business cases and budget and requested resources from RIPE NCC with the existing charge level. Moreover, with signed long-term contracts (3 years and more) with customers with prices calculated based on the existing costs, in some cases it may be challenging or even not possible to change the pricing terms without risking a breach of contracts. So it is not acceptable to switch to model where RIPE NCC in fact starts charging for already assigned resources currently in use in the business. We believe that new charges can be applicable to the new resources to be assigned, but not impact the existing ones. Agree that some discounts or other options for the fee adjustment for a long-standing members also can be applied.

Regards, Naira Kuroyan

GLOBAL NETWORK CONNECTIVITY MANAGER TEAM Telecom Armenia www.telecomarmenia.am

-----Original Message----- From: members-discuss <members-discuss-bounces@ripe.net> On Behalf Of Hank Nussbacher Sent: Monday, April 1, 2024 12:49 PM To: members-discuss@ripe.net Subject: Re: [members-discuss] RIPE NCC Charging Scheme 2025 Open House: Recording and Slides Available

On 29/03/2024 14:49, Gert Doering wrote:

IUCC was the first paying member to RIPE NCC in 1995 (since we realized the importance of supporting such a fledgling organization) and we have paid for our resources for the past 29 years.

See attached (page 3 of 4 pages - if anyone wants to see the full 4 page document - drop me an email off-list).

Regards, Hank

...

...

Hi,

On Thu, Mar 28, 2024 at 07:04:30PM +0100, Andrea Borghi wrote:

...

My humble proposal is to class basing on how many additional resources a company have beyond the basics that was valid at the time of joining Ripe.

... and possibly how old these resources are... we got our blocks in 1995/1996, and they are considered "large" by today's standards.? Back then, it was what you got as a fast-growing small ISP...

So if we really go for something based on allocation size, adding a yearly depreciation factor in would make this "more fair" (... we've been paying our share for the last 29(!) years already).

Gert Doering ???????? -- NetMaster

_______________________________________________ members-discuss mailing list members-discuss@ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/hank%40intera l l.co.il

_______________________________________________ members-discuss mailing list members-discuss@ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/ivaylo%40bglans.net