[members-discuss] [ncc-announce] [GM] Publication of Draft Charging Scheme Models 2024

About *Project Issue
: Re: [members-discuss] [ncc-announce] [GM] Publication of Draft
Charging Scheme Models 2024
*


*Sent by*
[1]*SUNIC*
*using*
None [2]*Odoo*











Hi Lennart,

ok I see. This is my mistake, what I meant was resources hold by a LIR, that what you currently add in the Excel Calculator.

Michael

* Von: * Lennart Seitz <mail at lseitz.de>
*Gesendet:* Dienstag, 18. April 2023 22:19
*An:* members-discuss at ripe.net; info at cowmedia.de
*Betreff:* Re: AW: [members-discuss] [ncc-announce] [GM] Publication of Draft Charging Scheme Models 2024
Hi Michael,
that would be my way of interpreting
having model A based on the number of resources used, instead of fixed categories
But this could be easily avoided by creating fake records, therefore my assumptions of them rising in case this would be deployed.
Regards,
Lennart
On 18.04.2023 22:08, cowmedia.de wrote:
Hi Lennart,
not sure why do you think someone create fake records? The numbers for the calculation are independent from the records in the IP databases, but taken from the internal RIPE Database and not only used or unused ressources are billed, but ALL.
Michael
* Von: * members-discuss <members-discuss-bounces at ripe.net> [3] *Im Auftrag von *Lennart Seitz via members-discuss
*Gesendet:* Montag, 17. April 2023 18:47
*An:* members-discuss at ripe.net [4]
*Betreff:* Re: [members-discuss] [ncc-announce] [GM] Publication of Draft Charging Scheme Models 2024
Although i find this idea interesting, this would IMHO just lead to fake inetnum records in the DB to avoid the costs.
Regards,
Lennart
On 14.04.2023 17:27, Paul Lewis wrote:
I'd like to also say that I think the idea of having model A based on the number of resources used, instead of fixed categories, would be better. It would help encourage unused resources to be transferred or returned.
---
Regards,
Paul Lewis.
On 2023-04-13 19:02, cowmedia.de wrote:
Hi Simon,
by reading this email and checking the calculator again I have the feeling
that the "listening to the members" as you say was not happening. A majority
of the members want a usage based charging scheme (as per the discussions on
this mailing list) and this is completely not reflected. Just adding some
more categories with the highest still only arround 10K is not sufficient.
Also what I do not understand is that my personal account with more or less
one of the lowest resources you can get is already in Category 2?!?
I can just repeat what I have already done:
It should be billed by real resources used and directly calculated not
within categories
Smaller LIRs should pay less and bigger LIRs should pay more
It is important that there is an incentive to get rid of unused resources
and bring them back, this is only possible when you pay for every resource
separate, otherwise no-one will take care.
I think this 3 models are not ready for vote and need to be revised.
Also Model 3 I completely do not understand. Why should someone pay for
transfers? This just means changes are going on and something happens. Why
these companies should then pay more? The "bad" companies are the ones that
do not implement IPv6 and their development just stall so nothing happens.
Michael


On Apr 12, 2023, at 09:45, Simon-Jan Haytink < simonjh at ripe.net [5] > wrote:
Dear RIPE NCC members,
I want to thank all those who contributed to the consultation so far on
the RIPE NCC Charging Scheme 2024 and the model we should use for the coming
years.
We can now share three draft models that we developed based on input from
the members on the Members Discuss mailing list and in the Charging Scheme
Open House, as well as from the discussions at the recent Executive Board
Meeting.
The result is that we are proposing three draft charging scheme models:
one category-based and two that are based on the previous "one LIR account,
one fee" model. We hope to receive feedback on these models by 19 April so
the Executive Board can propose the final versions on 26 April. The members
will then vote on those three models at the upcoming General Meeting on
24-26 May.
The three models all aim to fulfil a budget that is roughly the same as
2023 plus general cost increases including inflation, so EUR 42-45 million.
By doing this, we can ensure that we can meet the potential budgetary
requirements for 2024 while retaining the option for members to redistribute
any excess contributions should we receive excess funds. The Activity Plan
and Budget will be discussed with members this coming Autumn.
The three models are available to review at:
https://www.ripe.net/participate/mail/member-and-community-consultations/cha [6]
rging-scheme-2024-consultation
We also provide an updated calculator where members can see for themselves
how much they might pay under the draft models: https://www.ripe.net/participate/mail/member-and-community-consultations/new [7]
-calculator-charging-scheme-2024.xlsx
To summarise the main features of the three models:
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.
Model B - Price increase and ASN fee
This model is the exact same as in the previous ten years, but there is a
price increase of EUR 150 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.
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.
Further information on the charging scheme models is provided at:
https://www.ripe.net/participate/mail/member-and-community-consultations/cha [8]
rging-scheme-2024-consultation/
The RIPE NCC Executive Board believes that a category-based model is the
best option to help address uncertainty that might be caused by
consolidation with multiple LIRs and to provide greater flexibility and
fairness in how we charge members in the coming years.
On 26 April, the final versions of the charging schemes that members will
vote on will be published for the members to consider and discuss. If you
have comments on the draft charging schemes, we therefore ask you to comment
on the members-discuss mailing list by 19 April so we have time to
incorporate any feedback if necessary.
Importantly, we ask all members to register for the RIPE NCC General
Meeting where the final decision will be in your hands. Register to
participate and vote at:
https://my.ripe.net/#/meetings/active [9]
Simon-Jan Haytink
Chief Financial Officer
RIPE NCC

_______________________________________________
members-discuss mailing list
members-discuss at ripe.net [10]
https://mailman.ripe.net/ [11]
Unsubscribe:
https://lists.ripe.net/mailman/options/members-discuss/info%40cowmedia.de [12]
_______________________________________________
members-discuss mailing list
members-discuss at ripe.net [13]
https://mailman.ripe.net/ [14]
Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/paul.lewis%40fr89.uk [15]


_______________________________________________  members-discuss mailing list  members-discuss at ripe.net [16]   https://mailman.ripe.net/ [17]  Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/mail%40lseitz.de [18]
--  Mit freundlichen Grüßen,  Lennart Seitz  PGP-Schlüssel: 0x187abd76a5660379 ( https://pgp.lseitz.de/key.asc [19] )  --
--  Mit freundlichen Grüßen,  Lennart Seitz  PGP-Schlüssel: 0x187abd76a5660379 ( https://pgp.lseitz.de/key.asc [20] )  --




[1] http://www.sunic.ua
[2] https://www.odoo.com
[3] mailto:members-discuss-bounces at ripe.net
[4] mailto:members-discuss at ripe.net
[5] mailto:simonjh at ripe.net
[6] https://www.ripe.net/participate/mail/member-and-community-consultations/cha
[7] https://www.ripe.net/participate/mail/member-and-community-consultations/new
[8] https://www.ripe.net/participate/mail/member-and-community-consultations/cha
[9] https://my.ripe.net/#/meetings/active
[10] mailto:members-discuss at ripe.net
[11] https://mailman.ripe.net/
[12] https://lists.ripe.net/mailman/options/members-discuss/info%40cowmedia.de
[13] mailto:members-discuss at ripe.net
[14] https://mailman.ripe.net/
[15] https://lists.ripe.net/mailman/options/members-discuss/paul.lewis%40fr89.uk
[16] mailto:members-discuss at ripe.net
[17] https://mailman.ripe.net/
[18] https://lists.ripe.net/mailman/options/members-discuss/mail%40lseitz.de
[19] https://pgp.lseitz.de/key.asc
[20] https://pgp.lseitz.de/key.asc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.ripe.net/ripe/mail/archives/members-discuss/attachments/20230419/716fea64/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: attachment
Type: application/octet-stream
Size: 251 bytes
Desc: not available
URL: <https://www.ripe.net/ripe/mail/archives/members-discuss/attachments/20230419/716fea64/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/octet-stream
Size: 5975 bytes
Desc: not available
URL: <https://www.ripe.net/ripe/mail/archives/members-discuss/attachments/20230419/716fea64/attachment-0003.obj>