- members-discuss - mailman.ripe.net

My thoughts about the proposed Charging Scheme Models A and B (2027–2031)
by Akayo 20 Jan '26

20 Jan '26

Dear colleagues, though I'm a few weeks too late I want to wish you a Happy New Year! As far as I understand there are currently two proposed models for the RIPE NCC charging scheme for the period 2027–2031. Model A is category based where Model B is formula based. Here are my thoughts: 1. I do not support Model B for the simple reason that I think a formula based model is too complicated and therefore intransparent. Members should be able to immediately see (on paper, not being required to use a calculator) how many fees they are required to pay. 2. I support keeping the flat fee model (only) in case the fees are not increased. If the flat fee is increased all few years due to higher costs, I do not support it any more because it will be a financial burden for smaller LIRs. For instance, I think it would be a imposition for smaller LIRs to pay €3,000 per year one day. The hosting business is not getting easier—it's getting harder. 3. If a category based scheme is used, I think many categories are better than less categories. The current Model A has 21 categories (counting the €500 category in case the LIR has no resources at all) which is good. However, I think Model A is extremely unfair: 4. First, from what I can see, the largest single allocation is IPv4 /10 and there is not a single IPv4 /8 or even /9 allocation. So it is doubtful that even the largest LIRs will fall into the uppermost categories. That means there are categories which from the beginning on will never be relevant. 5. Also there is a big gap between the smallest and the largest LIRs. That means that the vast majority of fees continue to be paid by the smallest, small and medium-sized LIRs whereas the large and largest LIRs still contribute only a small amount (in relative terms). For instance, I own about an IPv4 /19 equivalent (= 32 x /24s). With this new model, my fees are increased from €1,800 to €3,080 which is quite much. If I would have an IPv4 /13 equivalent I would not be a sole trader but own a large company. I would not have 32 x /24s but 2,048 x /24s which is 64 times as much—but with this new model I would only pay €6,488. And if I would have an IPv4 /10, which is equivalent to 16,384 (sixteen thousand) IPv4 /24s I would only pay €8,503 though I would have 512 times as much space. This is not fair. And there is no simple middle course. If the stated goal is to make the scheme more fair then the larger and largest LIRs unfortunately need to pay way more because they are the only group which is not fee sensitive. It makes (almost) no difference for them whereas it does make a huge difference for us. Thank you for your time. --Kayo

3 3

Re: Minor issues in Sponsoring LIR Agreement
by Maria Stafyla 15 Jan '26

15 Jan '26

Hi Antonis, all Thank you for your email. We will review the template agreement in the coming period and make improvements where necessary. Kind regards, Maria Stafyla Specialist Legal Counsel RIPE NCC ---------- Forwarded message ---------- From: Antonis Chariton < <https://mailman.ripe.net/archives/list/members-discuss-unmoderated@ripe.net…> daknob(a)daknob.net> To: members-discuss(a)ripe.net Cc: Bcc: Date: Mon, 5 Jan 2026 20:36:20 +0100 Subject: Minor issues in Sponsoring LIR Agreement Hello everyone and happy new year! I was reading the Sponsoring LIR Agreement over at https://www.ripe.net/manage-ips-and-asns/resource-management/number-resourc… and I wanted to point out two minor issues: 1) Typo in Article 1 Definitions (Independent Internet Number Resources): “IPv6)” should be “IPv6” 2) Correction in Article 1 Definitions (Reverse DNS Delegation): "and ipv6.arpa (IPv6).” - the correct zone is ip6.arpa I think we should fix them, but I’m sending this here in case anyone considers these important enough to amend their contracts :) Antonis <https://mailman.ripe.net/archives/list/members-discuss-unmoderated@ripe.net…>

1 0

No Resource Transfers Allowed in January?
by Patterson, Richard (Senior IP Architect) 14 Jan '26

14 Jan '26

Hi Members, We've hit a kafkaesque bug with the RIPE NCC's policies, and I was wondering if anyone else has run into it? We've had a resource transfer request blocked until the 2026 membership fees are all paid up, the 2026 membership fees for which the invoices have not yet been generated or sent out yet......... This requirement is not specified in the Transfer Policy, but it is mentioned in the 2026 Billing Procedure. Do we think this requirement—effectively restricting transfers during the month of January—is sane and I just need to be more patient, or does it require a policy update or maybe just for a bit of common sense to be applied when requests are processed? -Rich Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trademarks of Sky Limited and Sky International AG and are used under licence. Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited (Registration No. 2067075), Sky Subscribers Services Limited (Registration No. 2340150) and Sky CP Limited (Registration No. 9513259) are direct or indirect subsidiaries of Sky Limited (Registration No. 2247735). All of the companies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD

4 5

Minor issues in Sponsoring LIR Agreement
by Antonis Chariton 06 Jan '26

06 Jan '26

Hello everyone and happy new year! I was reading the Sponsoring LIR Agreement over at https://www.ripe.net/manage-ips-and-asns/resource-management/number-resourc… and I wanted to point out two minor issues: 1) Typo in Article 1 Definitions (Independent Internet Number Resources): “IPv6)” should be “IPv6” 2) Correction in Article 1 Definitions (Reverse DNS Delegation): "and ipv6.arpa (IPv6).” - the correct zone is ip6.arpa I think we should fix them, but I’m sending this here in case anyone considers these important enough to amend their contracts :) Antonis

1 0

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 17 Dec '25

17 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 16 Dec '25

16 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 13 Dec '25

13 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