Hello Simon-Jan, On Wed, 12 Apr 2023, Simon-Jan Haytink wrote:

Model A - Category Model

This model has ten categories to provide greater granularity. It also charges separately for independent and legacy resources in exactly the same way as in previous years. Additionally, a separate 50 EUR ASN assignment fee has been added. Both separately charged resources do not contribute to the category scores. This means there is no double charging and no specific charging for transfers or administrative work carried out by the RIPE NCC. There is a New /24 IPv4 administration fee to ensure there is a financial consequence to joining the IPv4 Waiting List. The fee would be payable upon receipt of the /24, and members joining the waiting list who do not have an eligible LIR account, would pay the new LIR sign-up fee to open a new LIR account and join the waiting list.

With this model, approximately 68% of members would pay less than the current annual fee, with the remaining 32% paying more.

The discussion with members helped us to see that a category-based model would receive significant support from members if the version was simplified. Should members see the need to charge for other elements, then that can be incorporated into the category model in the coming years. Any such additional charges could potentially then reduce the fees per category.

thank you for the explanation and the analysis. However from my point of view, the RIPE NCC offers with this model an unfair incentive to members with IPv4 allocations (in total) of more than a /15 equivalent, because they are simply capped at 10k EUR per year. Deutsche Telekom, Orange, Societe Francaise Du Radiotelephone and Telecom Italia (if I did my research right, they should be the 4 largest members in the RIPE region) have each in total IPv4 allocations somewhere between /8 and /7 equivalent. And sorry, I might be totally wrong, but I think if a member needs these really large IPv4 allocations, the member should easily be able to pay much more than only 10k EUR per year. And a member still could charge its customers for their IPv4 usage (or make them simply moving to IPv6). But once it comes to IPv6, I think charging 350 EUR per year for a /29 is a very bad idea. In the past, RIPE NCC employees even encouraged RIPE members to extend their /32 up to a /29 ("because it's free", just informally and in non-written form e.g. during an Assisted Registry Check, but Maximilian Wilhelm mentioned on 2023-04-13 that it also happened in a documented way). Aside of this: Does the RIPE NCC currently see any lack of IPv6 address space to come up with this proposal? If a /29 leads to extra charging, I expect quite some members to return their IPv6 allocation (above /29), and especially in cases where it was advertised as "free benefit" in the past. Other than that: +1 to Gert Doering's e-mail from 2023-04-13. As longer I am looking to the IPv6 category scale, as more I am wondering why largest IPv6 allocations in the RIPE region to Deutsche Telekom, UK Ministry of Defence and Orange (each a /19) are just category 7 instead of 10. Honestly, I expect Deutsche Telekom and Orange made their homework before requesting an IPv6 allocation, thus I seriously wonder how realistic it is that the RIPE NCC allocates something even larger to another member in the next years (or maybe even ever?). So shouldn't the scale be adjusted to cover the largest members with the largest category? If my research was correct, the RIPE NCC in total has IPv6 allocations of /11 + /17 + /21 currently. A /11 allows up to 16 /15 allocations (this + 1 more IPv6 address is the minimum size for IPv6 category 10). I am not sure which huge future address needs by members the RIPE NCC is expecting. And seriously: If there is such a need in 5+ years, we anyway will discuss the next charging scheme, right?

From my point of view, both, the IPv4 and the IPv6 category scale should be aligned more to the current maximum of actual IP allocations of RIPE. This would, from my point of view, distribute the overall costs over the members somehow "per usage" (and be in-line with historical allocation requests).

Do 32 bit ASNs cause costs to the RIPE NCC? Or is the RIPE NCC running out of them anytime soon? I understand that the situation for 16 bit ASNs is different, but I'm not sure what the benefit is to charge for 32 bit ASNs.

Model C - Transfer fee and ASN fee

This model is the exact same as in the previous ten years, but there is a charge of EUR 1,000 per transfer to be paid by the receiving party and a 50 EUR ASN fee to ensure we can meet our budgetary requirements while retaining the option for members to redistribute any excess contribution should we receive excess funds.

While I consider a transfer fee of 1000 EUR to be somehow fair for larger IPv4 networks, it feels quite unfair to me for e.g. a IPv4 /24 or /23, or for a 32 bit ASN. Outside of the models, I am still worried about RIPE NCC having 172 FTEs, while other LIRs can operate with around the half (or even less). What is so unique/special with RIPE NCC that requires so many more FTEs? Is it the projects and activity outside of the RIR job (e.g. RIPE Atlas or RIPE NCC Certified Professionals)? While this question was raised in general earlier on this list already, I didn't notice a real answer so far. What I didn't see so far either is an overview/table for the FTEs similarly detailed like for the budget (page 27 of ripe-796 for FTEs is quite brief compared to page 43 of ripe-795 for budgets), thus "per activity". Did I overlook this? If not, could it be provided for the future, maybe for the RIPE 86 GM? It would be interesting to compare these details with the ones of the other RIRs. Kind regards Robert Scheck -- Robert Scheck Mail: robert.scheck@etes.de ETES GmbH Fon : +49 (7 11) 48 90 83 - 12 Talstraße 106 Fax : +49 (7 11) 48 90 83 - 50 D-70188 Stuttgart Web : http://www.etes.de/ Registergericht: Amtsgericht Stuttgart HRB 721182 Geschäftsführender Gesellschafter: Markus Espenhain Sitz der Gesellschaft: Stuttgart USt.-Id.Nr.: DE814767446