[members-discuss] RIPE NCC Charging Scheme 2020 - Board Reasoning

I think that this way of "charging per number of delegated IP addresses" 
is the fairest one. It could be based on v4 address usage in a way where 
v6 addresses would be less "expensive" and will therefore (although I 
read and agree with previous comments that the price should not be the 
primary incentive for v4-to-v6 migration) motivate quicker migration to v6.

LIRs that have more addresses, provide more services and are able to pay 
more.

Regards,
Matej Serc

Sebastian Malek je 19.4.2019 ob 11:56 napisal:
> In my opinion we should keep the current scheme.
>
> Splitting allocations in the RIPE DB just for this reason makes *no* 
> sense.
>
> If you want to charge per IP or per allocation, it would be better to 
> take the IP count from the LIR portal and calculate the fee based on that.
>
> Regards,
> Sebastian
>
> On Fri, Apr 19, 2019 at 11:53 AM ivaylo <ivaylo at bglans.net 
> <mailto:ivaylo at bglans.net>> wrote:
>
>
>     >From network point of view nothing will change, Cynthia.
>
>     You can still aggregate your announces. See this document point 7.2
>     https://www.ripe.net/publications/docs/ripe-399
>
>     Ivaylo Josifov
>     Varteh LTD
>
>
>     On Fri, 19 Apr 2019, Cynthia Revstr?m wrote:
>
>     > From a networking point of view, this would be extremely
>     idiotic, you would
>     > fill up routers' memory with routes and take down the internet
>     if you did
>     > this.
>     >
>     > Splitting blocks is just idiotic.
>     >
>     > - Cynthia
>     >
>     > On 2019-04-19 11:03, ivaylo wrote:
>     >>
>     >> Hello,
>     >>
>     >> Scheme B will work good and fair to all only with one condition
>     - If ripe
>     >> split IPV4 ALLOCATED PA blocks dedicated to LIRs in maximum /22
>     (better
>     >> /24) blocks.
>     >>
>     >> Example:
>     >> Now LIR-1 have ALLOCATED-PA
>     >> 10.0.0.0/20 <http://10.0.0.0/20>
>     >>
>     >> After split LIR-1 will have ALLOCATED-PA
>     >> 10.0.0.0/22 <http://10.0.0.0/22>
>     >> 10.0.4.0/22 <http://10.0.4.0/22>
>     >> 10.0.8.0/22 <http://10.0.8.0/22>
>     >> 10.0.12.0/22 <http://10.0.12.0/22>
>     >>
>     >> For IPV6 same splir but based on /32 allocated-pa blocks
>     >>
>     >> From technical point of view this automatic split can be done easy.
>     >> Then Scheme B will be fair for all, and will cover what many of
>     us talking
>     >> for charging scheme based on IP resources. Also will cover that
>     RIPE NCC do
>     >> not "sell" IPV4
>     >>
>     >> Ivaylo Josifov
>     >> Varteh LTD
>     >>
>     >>
>     >> On Thu, 18 Apr 2019, Christian Kaufmann wrote:
>     >>
>     >>> Dear members,
>     >>>
>     >>> First of all, I'd like to thank you for the feedback we
>     received from
>     >>> everyone so far, and special thanks to the people who gave
>     some more
>     >>> context and explanation. Trying to arrive at a charging scheme
>     that will
>     >>> please everyone is not an easy task.
>     >>>
>     >>> The reason the board proposes two charging schemes is because some
>     >>> members requested a real alternative and difference to the
>     existing "one
>     >>> LIR account-one fee" version we have right now and that is
>     more volume
>     >>> based.
>     >>>
>     >>> This came up previously in the charging scheme task force
>     discussions
>     >>> but also from individual members via emails or through
>     personal contact.
>     >>> Nigel and I promised at the last two GMs that we would present
>     a new one
>     >>> before the May GM this year.
>     >>>
>     >>> So what was the board's thinking in proposing these two models?
>     >>>
>     >>> Firstly, many people like the existing model and the board
>     believes that
>     >>> it covers the spirit of what some members want by maintaining the
>     >>> financial stability of the NCC while keeping fairness and
>     equality in
>     >>> mind. The board also does not want a price per IP model
>     because this
>     >>> would have tax implications (the RIPE NCC does not sell IP
>     addresses and
>     >>> the charging scheme should reflect this) and we feel it is not in
>     >>> keeping with the idea of a membership association.
>     >>>
>     >>> We have also found in the past that having more than two
>     options does
>     >>> not work well from a voting perspective. This would add
>     considerable
>     >>> complexity to the voting in which resolutions must be approved
>     by more
>     >>> than 50% of voters to be adopted.
>     >>>
>     >>> The second charging scheme option is one that the board
>     believes offers
>     >>> a real alternative while staying away from the price per IP
>     aspect.
>     >>>
>     >>> The board's thinking in making the Option B proposal is that every
>     >>> registry entry consumes resources such as customer support time,
>     >>> database memory, registration time, etc. regardless of the
>     size of the
>     >>> allocation. A /24 and a /12 are not so different in this
>     regard so we
>     >>> see this as fair in terms of the work required by the RIPE NCC to
>     >>> maintain the registry. The reason we suggest to charge IPv4
>     and IPv6 in
>     >>> the same way follows the same logic - there is no tax designed
>     to move
>     >>> people to IPv6. We did not want to have a political, policy-driven
>     >>> charging scheme because the board believes this is the work of
>     community
>     >>> rather than for the board or membership to decide on.
>     >>>
>     >>> I understand that the "volume-based" description could be seen as
>     >>> misleading and I apologise for the misunderstanding here. The
>     proposed
>     >>> model is based on registrations and not per IP as we do not
>     want to
>     >>> indicate that IP is a sellable product but rather the RIPE NCC
>     should
>     >>> charge members for the registry services it provides.
>     >>>
>     >>> The new charging scheme was also not proposed so that the RIPE
>     NCC could
>     >>> make more money - it takes the current budget and calculates
>     backwards
>     >>> to achieve the amount required to run the RIPE NCC. It is just a
>     >>> different model to share the current cost among members.
>     >>>
>     >>> Despite concerns that were raised on this list, the board took the
>     >>> request of some members to propose a new model very seriously
>     and we
>     >>> spent quite some time to discuss and model the current scenario by
>     >>> trying to be as fair as possible and sticking with the
>     principles of a
>     >>> membership organisation.
>     >>>
>     >>> Again, we are very thankful for your input and the feedback on
>     the two
>     >>> models. We will continue to monitor discussions and we will of
>     course
>     >>> present on the Charging Scheme 2020 at the upcoming GM. We
>     encourage you
>     >>> to register your vote so you can have the final say on the two
>     proposals.
>     >>>
>     >>> Best regards,
>     >>>
>     >>> Christian Kaufmann
>     >>> RIPE NCC Executive Board Chairman
>     >>>
>     >>> _______________________________________________
>     >>> members-discuss mailing list
>     >>> members-discuss at ripe.net <mailto:members-discuss at ripe.net>
>     >>> https://mailman.ripe.net/
>     >>> Unsubscribe:
>     >>>
>     https://lists.ripe.net/mailman/options/members-discuss/ivaylo%40bglans.net
>     >>>
>     >>
>     >> _______________________________________________
>     >> members-discuss mailing list
>     >> members-discuss at ripe.net <mailto:members-discuss at ripe.net>
>     >> https://mailman.ripe.net/
>     >> Unsubscribe:
>     >>
>     https://lists.ripe.net/mailman/options/members-discuss/me%40cynthia.re
>     >
>     > _______________________________________________
>     > members-discuss mailing list
>     > members-discuss at ripe.net <mailto:members-discuss at ripe.net>
>     > https://mailman.ripe.net/
>     > Unsubscribe:
>     >
>     https://lists.ripe.net/mailman/options/members-discuss/ivaylo%40bglans.net
>     >
>
>     _______________________________________________
>     members-discuss mailing list
>     members-discuss at ripe.net <mailto:members-discuss at ripe.net>
>     https://mailman.ripe.net/
>     Unsubscribe:
>     https://lists.ripe.net/mailman/options/members-discuss/malek%40malek.li
>
>
> _______________________________________________
> members-discuss mailing list
> members-discuss at ripe.net
> https://mailman.ripe.net/
> Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/matej.serc%40elmitel.com

-- 
Matej Šerc
ELMITEL d.o.o.
Orehovci 1a
SI-9250 Gornja Radgona
T: +386 (0)2 564 88 60
M: +386 (0)40 167 589
F: +386 (0)2 564 88 61
Company W: www.elmitel.com
E: matej.serc at elmitel.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.ripe.net/ripe/mail/archives/members-discuss/attachments/20190419/159dad13/attachment.html>