December 2025 - members-discuss

Consultation on Future RIPE NCC Charging Scheme Models
by thiele＠holomua.de 21 Dec '25

21 Dec '25

Hi to everyone, I have looked at both models. If I have understood the models correctly, it is striking that small and medium-sized LIRs suffer a significant increase in annual fees in both models. Looking at the cost contribution per IP address, it quickly becomes clear that older LIRs with /4 and larger networks in particular are making disproportionately low contributions, even though they have allocated significantly more resources. This should definitely be addressed. Why is the cost contribution per IP not kept linear? Kind regards Peter -- Diese E-Mail wurde von Avast-Antivirussoftware auf Viren geprüft. www.avast.com

13 16

Re: Consultation on Future RIPE NCC Charging Scheme Models
by Denys Fedoryshchenko 16 Dec '25

16 Dec '25

Dear RIPE NCC, After reviewing Phase 1 of the Charging Scheme Consultation, two issues stand out. First, the use of complex Excel spreadsheets as “interactive calculators” is frankly disappointing. In 2025, this approach reduces transparency, makes independent verification harder, and discourages meaningful analysis. I did in 30 minutes a simple web-based comparison that shows the same calculations more clearly and allows direct comparison with other RIR fee models (https://better-ripe.github.io/calculator2025/ ) [1] Second, the results raise a serious equity concern. Model B appears to consistently benefit very large resource holders while increasing the relative burden on small members. Compared with other RIRs, RIPE’s proposal looks less balanced and less fair, despite equity being stated as a core principle. I would like to understand how equity is being measured here, and why RIPE NCC seems comfortable with outcomes that so clearly favor large holders. This feedback is meant constructively, but the direction is worrying. On Mon, 2025-12-15 at 15:14 +0100, Simon-Jan Haytink wrote: > Dear RIPE NCC members, > We have opened Phase 1 of the Charging Scheme Consultation and invite > your feedback on two proposed models for the annual fee, which > represents the significant majority of the RIPE NCC’s income. > *What we are consulting on in Phase 1* The RIPE NCC’s income from > members consists of two parts - together > they make up the Membership Fee: > 1. Annual Fee - the main part of our income > > 2. Additional Fees - currently these are ASN fees, independent > assignment fees and other one-off charges > In Phase 1, our focus is only on the annual fee, because this is the > foundation of the Charging Scheme and the key element for our long- > term financial stability. > We are asking for your input on two possible annual fee models: > - Model A – Category-based model > - Model B – Formula-based model > For each model, we have published an explanation and an interactive > calculator so you can see how your annual fee would be calculated and > explore different scenarios based on your IPv4 and IPv6 holdings. > You can find the consultation details and the calculators at: > https://www.ripe.net/s/cs-model-consultation-phase-1/ > *What feedback we would like to hear* > At this stage, we are interested in how the models work in practice, > not in fixing the final revenue amount. > The figures you see are illustrative and not final. > We would particularly value your views on questions such as: > - Are there too many categories in Model A, or too few? > - Are the category boundaries appropriate > - Is a formula-based approach (Model B) preferable to a category- > based one? > > - Does the current formula setup make sense, or are there better > options? > > - Do the models adequately reflect the principles defined by the > Charging Scheme Task Force, especially the principle of equity? > > - Are there any issues you can see that we’ve overlooked? > Both models are still drafts. Your feedback now is essential before > we further develop the models. > Please share your input on the Members Discuss mailing list by the > end of January 2026. > We will of course follow discussions and we will address queries and > comments in early January after the holiday season. > *Next steps in the consultation* This consultation is part of a > three-phase process: > - Phase 1 (now): Consult on two annual fee models (A and B), with > calculators – published Dec 2025 > - Phase 2: Consult on separate fees (e.g. ASN and independent > resource fees) – planned for Jan/Feb 2026 > > - Phase 3: Publish a combined Charging Scheme proposal (Annual Fee + > separate fees) that incorporates member feedback from Phases 1 and 2 > – planned for April 2026 > The final Charging Scheme proposal will be presented for a vote at > the RIPE NCC General Meeting in May 2026. > I strongly encourage you to review the two models, use the > calculators, and share your perspective. Your participation is vital > in helping us develop a Charging Scheme that is stable, transparent > and equitable. > Kind regards, > Simon-Jan Haytink > Chief Financial Officer > RIPE NCC > > > ----- > To unsubscribe from this mailing list or change your subscription > options, please visit: > https://mailman.ripe.net/mailman3/lists/ncc-announce.ripe.net/ > As we have migrated to Mailman 3, you will need to create an account > with the email matching your subscription before you can change your > settings. > More details at: > https://www.ripe.net/membership/mail/mailman-3-migration/ [1] ) https://github.com/better-ripe/calculator2025

2 1

RIPE NCC Quarterly Planning Q1 2026
by Boris Duval 16 Dec '25

16 Dec '25

Dear colleagues, We have now published the upcoming quarterly plans for our development teams: https://www.ripe.net/quarterly-planning <https://www.ripe.net/support/documentation/quarterly-planning> We publish these plans each quarter to showcase the work items we will be carrying out over the next months. We welcome your feedback and encourage you to suggest items that the RIPE NCC should be working on going forward. The plans cover the following areas: - RIPE Database - Business Applications, including the LIR Portal, Registry Services and other applications - DNS and K-root - RIPE Atlas - RIPEstat - Resource Public Key Infrastructure (RPKI) - Routing Information Service (RIS) - Information Security, Risk, and Compliance - Training and Certification If you have any questions or input on these plans, please share your suggestions on this list or the RIPE NCC Forum: https://forum.ripe.net/ Kind regards, Boris Duval

1 0

Future RIPE NCC Charging Scheme Proposals
by office＠mrejitor.com 15 Dec '25

15 Dec '25

Dear community, I looked at both Category-based and Formula-based models and found a destructive issue with both. The root issue The scheme is too logarithmic. The average fee per IP ranges 5744 times! * The issue leads to the following consequences. Consequence one - market competition Members with fewer addresses should pay a significant share of their income to RIPE. There are many services in the â¬10 or less category in Bulgaria, Romania, and other countries. Small /24 operators should spend at least 4.47% of their income on RIPE fees alone. A prominent /8 owner will spend 0.00001% of that income. The ratio of 5,743 is significant. Consequence two - delaying the move to IPv6 Given the significant historical IPv4 address space, larger companies have fewer reasons to switch to IPv6. If we agree to further multiply this advantage, there will be fewer and fewer economic reasons to switch to IPv6. Consequence three - possible reduction in the number of LIRs With ratios of up to 5,743 times the fees per IP, one can expect the consolidation of LIR accounts to continue. Renting small blocks will be preferable to acquiring them. We already suffer from the declining number of LIR accounts. A decision that leads to future consolidation may require additional rebalancing in the coming years. Possible solutions * Better-balanced fees, with wider boundaries in both directions. A difference of no more than 256 times in per-ip fees. * A fee reduction for big entities if they return address space to RIPE. This reduction will actually pay off by reducing IPv4 queue wait time and, therefore, increasing the number of new members. Best Regards, Alexander 5744 is calculated by dividing the minimum fee per IP for /8 by the cost for /24. It could be up to 11,487 in case the address space is close to /7 IPv4 CIDR Max fee/ IP Discount from /24 /24 to /23 3.41016 0.00% /23 to /22 2.47656 27.38% /22 to /21 1.64746 51.69% /21 to /20 1.03906 69.53% /20 to /19 0.63306 81.44% /19 to /18 0.37598 88.97% /18 to /17 0.21918 93.57% /17 to /16 0.12585 96.31% /16 to /15 0.07143 97.91% /15 to /14 0.04013 98.82% /14 to /13 0.02237 99.34% /13 to /12 0.01237 99.64% /12 to /11 0.00681 99.80% /11 to /10 0.00372 99.89% /10 to /9 0.00203 99.94% /9 to /8 0.00110 99.97% /8 to /7 0.00059 99.98%

1 0

Re: Systematic RIPE DB abuse
by Lu Heng 12 Dec '25

12 Dec '25

You are mixing two fundamentally different things: *1. Community-platform rules (like mailing lists)* *2. Number-resource administration (the registry function)* A registry absolutely may moderate its mailing list or remove someone from a community forum. That is *not* the issue. That is not resource governance. That is not number administration. The problem arises when you conflate the mailing list with the registry function and assume the same “ban power” applies to number resources. It does not. A registry’s authority over number resources is *administrative*, not discretionary: • It has no sovereign power. • It cannot impose penalties outside the law. • It cannot “ban” someone from holding number resources because it dislikes their actions. • It cannot create new enforcement powers through internal rules. Mailing-list rules are internal community guidelines. Number-resource allocation is part of global critical infrastructure. These are not equivalent domains. The fact that a registry can enforce behavior on a mailing list does *not* grant it the authority to punish a member by altering or revoking their number resources. The two functions exist on different legal, operational, and governance layers. If you do not separate these layers, you end up with exactly the instability we see today: registries treating essential resource administration as if it were a social-media moderation problem. A registry is allowed to moderate conversations. A registry is *not* allowed to weaponize the address book. That is the distinction you must not blur. On Thu, 11 Dec 2025 at 12:33, Peering <peering(a)all-for-one.com> wrote: > This is not about punishing or violating laws but violating the rules of > usage of the registry. While doing so, it should be normal to get banned > from that registry and the usage of the abused resources like the Mailing > list. So far fully fits in your position, as the rules of usage are given > by the registry it’s also the only given authority that can enforce them. > > > > *Von:* Lu Heng <h.lu(a)anytimechinese.com> > *Gesendet:* Mittwoch, 10. Dezember 2025 21:49 > *An:* Michele Neylon - Blacknight <michele(a)blacknight.com> > *Cc:* Sergey Myasoedov via members-discuss <members-discuss(a)ripe.net> > *Betreff:* [members-discuss] Re: Systematic RIPE DB abuse > > > > Michele, > > > > Let me clarify, because this is not a question of “no rules.” > > > > My position is straightforward: > > > > A registry is a registry. > > Its mandate is to maintain accurate records—nothing more. > > You do not use an address book as an instrument of punishment. > > > > When a registry begins using essential administrative functions to reward > or punish individuals, the system becomes unpredictable and open to abuse. > This is, in fact, a major reason the RIR environment has struggled with > instability and governance issues: registries have, at times, stepped > outside their neutral role and attempted to use resource administration as > leverage. > > > > Rules absolutely must exist, and compliance is essential. > > But those rules are defined and enforced by sovereign law—courts, > regulators, and proper authorities—not by a voluntary address book. A > registry cannot impose its own rules above nations, nor can it act as > police, prosecutor, and judge. > > > > Punishment, when warranted, must come through established legal channels. > A registry that assumes enforcement powers beyond its mandate ultimately > undermines its own legitimacy and the trust of the global community. > > > > That is the core of my position. > > > > Regards, > > Lu > > > > > > > > > > On Wed, Dec 10, 2025 at 16:19 Michele Neylon - Blacknight < > michele(a)blacknight.com> wrote: > > Lu > > > > Sorry but I cannot agree with your position on this. > > > > By your logic RIPE NCC would have zero right to take action against a > member who was in breach of the policies, rules etc., > > > > Trust in the system is only possible when the system is stable and > predictable, which you seem to agree with, however if there are no rules > then any system will be abused by somebody at some point. > > > > Regards > > > > Michele > > > > -- > > Mr Michele Neylon > > Blacknight Solutions > > Hosting, Colocation & Domains > > *https://www.blacknight.com/ <https://www.blacknight.com/>* > > *https://blacknight.blog/ <https://blacknight.blog/>* > > Intl. *+353 (0) 59 9183072 <+353599183072>* > > Personal blog: *https://michele.blog/ <https://michele.blog/>* > > Some thoughts: *https://ceo.hosting/ <https://ceo.hosting/>* > > ------------------------------- > > Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business > Park,Sleaty Road,Graiguecullen,Carlow,R93 X265,Ireland Company No.: 370845 > > > > I have sent this email at a time that is convenient for me. I do not > expect you to respond to it outside of your usual working hours. > > *From: *Lu Heng <h.lu(a)anytimechinese.com> > *Date: *Wednesday, 10 December 2025 at 13:15 > *To: *Brett Sheffield <ripe(a)gladserv.com> > *Cc: *Sergey Myasoedov via members-discuss <members-discuss(a)ripe.net> > *Subject: *[members-discuss] Re: Systematic RIPE DB abuse > > *[EXTERNAL EMAIL]* Please use caution when opening attachments from > unrecognised sources. > > Hi > > > > I agree entirely NCC should not do anything. A registry’s role is > administrative, not enforcement. Asking a bookkeeping-type institution to > police behavior is simply outside its mandate and purpose. > > > > There are countless legitimate ways to address concerns or resolve > disputes. But withholding a fundamental registry service—such as assigning > an address—because someone “did or did not do X” is irrational and > unprecedented. It is the equivalent of a government refusing to give a home > an address instead of contacting law enforcement or using proper legal > channels. No responsible system operates that way, and no credible > governance framework treats essential registry functions as a tool for > punishment or leverage. > > > > A registry should remain neutral, predictable, and strictly procedural. > Using it as an enforcement mechanism undermines trust in the entire system. > > > > > > -- > Kind regards. > Lu > > > > > > On Wed, Dec 10, 2025 at 14:38 Brett Sheffield <ripe(a)gladserv.com> wrote: > > On 2025-12-08 12:57, Sergey Myasoedov via members-discuss wrote: > > Dear RIPE NCC members, > > > > I’d like to raise the topic of introducing and applying administrative > anti-spam measures against RIPE NCC members who deliberately violate > Article 4 of the RIPE Database Terms and Conditions. > > > > RIPE NCC requires members to publish up-to-date contact email addresses > in the RIPE DB. However, these publicly listed addresses are actively > harvested and used for spam by IPv4 brokers and address traders, while RIPE > NCC does not take any measures to protect members from this type of abuse. > > > > This issue has been around since the IPv4 market appeared, and although > it’s well known, at some point the RIPE NCC staff chose not to act against > members who don’t follow the RIPE Database T&C. > > > > My proposal is to freeze transfer operations for members who are > repeatedly abusing the RIPE Database. > > > > I’d be glad to hear your thoughts and discuss this further. > > Compared to other sources, our RIPE contact address gets a tiny amount of > spam, > and all of it from IPv4 brokers. > > I've now received more emails in this single thread in the past 24 hours > than I > have spam to our RIPE contact address in the past 5 years. No action from > RIPE > is required here. > > Tighten your spam controls if this is a problem for you, and lets move on. > > Cheers, > > > Brett > -- > Brett Sheffield (he/him) > Gladserv > To unsubscribe or manage your subscription, log in to the LIR Portal with > your > RIPE NCC Access account and go to the LIR Account page: > https://my.ripe.net/#/account-details. > > Scroll down to Membership Mailing Lists to update your 'members-discuss' > subscription. > > Having issues unsubscribing? More information about managing your > subscription > can be found at: > https://www.ripe.net/s/members-discuss-subscription-options/ > > -- -- Kind regards. Lu

6 9

Systematic RIPE DB abuse
by Sergey Myasoedov 11 Dec '25

11 Dec '25

Dear RIPE NCC members, I’d like to raise the topic of introducing and applying administrative anti-spam measures against RIPE NCC members who deliberately violate Article 4 of the RIPE Database Terms and Conditions. RIPE NCC requires members to publish up-to-date contact email addresses in the RIPE DB. However, these publicly listed addresses are actively harvested and used for spam by IPv4 brokers and address traders, while RIPE NCC does not take any measures to protect members from this type of abuse. This issue has been around since the IPv4 market appeared, and although it’s well known, at some point the RIPE NCC staff chose not to act against members who don’t follow the RIPE Database T&C. My proposal is to freeze transfer operations for members who are repeatedly abusing the RIPE Database. I’d be glad to hear your thoughts and discuss this further. -- Best regards, Sergey Myasoedov > Begin forwarded message: > > From: "HostM" <info(a)hostmaster.lt> > Subject: Quick question about IPv4 > Date: December 8, 2025 at 04:54:23 EST > To: <for-spammers(a)net-art.cz> > > Hello, > my apologies if this message has arrived at an inconvenient time. > > I wanted to check whether you might be interested in acquiring an IPv4 /24 sub-net registered with RIPE. > I also have IPv6 resources and an ASN available, which can be included (for free) if you are interested in the IPv4 block. > > The ipv4 sub-net is currently unused and fully clean. > > The transfer can be completed securely via an escrow service. > > If this could be of interest, please feel free to reply to this email, and we can discuss the next steps in more detail. > > Regards, > Zydrunas

17 25