<div dir="ltr">In my opinion we should keep the current scheme.<div> </div><div>Splitting allocations in the RIPE DB just for this reason makes *no* sense.</div><div> </div><div>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.</div><div> </div><div>Regards,</div><div>Sebastian</div></div> <div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Apr 19, 2019 at 11:53 AM ivaylo <<a href="mailto:ivaylo@bglans.net">ivaylo@bglans.net</a>> wrote: </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> >From network point of view nothing will change, Cynthia. You can still aggregate your announces. See this document point 7.2 <a href="https://www.ripe.net/publications/docs/ripe-399" rel="noreferrer" target="_blank">https://www.ripe.net/publications/docs/ripe-399</a> 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 >> <a href="http://10.0.0.0/20" rel="noreferrer" target="_blank">10.0.0.0/20</a> >> >> After split LIR-1 will have ALLOCATED-PA >> <a href="http://10.0.0.0/22" rel="noreferrer" target="_blank">10.0.0.0/22</a> >> <a href="http://10.0.4.0/22" rel="noreferrer" target="_blank">10.0.4.0/22</a> >> <a href="http://10.0.8.0/22" rel="noreferrer" target="_blank">10.0.8.0/22</a> >> <a href="http://10.0.12.0/22" rel="noreferrer" target="_blank">10.0.12.0/22</a> >> >> 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 >>> <a href="mailto:members-discuss@ripe.net" target="_blank">members-discuss@ripe.net</a> >>> <a href="https://mailman.ripe.net/" rel="noreferrer" target="_blank">https://mailman.ripe.net/</a> >>> Unsubscribe: >>> <a href="https://lists.ripe.net/mailman/options/members-discuss/ivaylo%40bglans.net" rel="noreferrer" target="_blank">https://lists.ripe.net/mailman/options/members-discuss/ivaylo%40bglans.net</a> >>> >> >> _______________________________________________ >> members-discuss mailing list >> <a href="mailto:members-discuss@ripe.net" target="_blank">members-discuss@ripe.net</a> >> <a href="https://mailman.ripe.net/" rel="noreferrer" target="_blank">https://mailman.ripe.net/</a> >> Unsubscribe: >> <a href="https://lists.ripe.net/mailman/options/members-discuss/me%40cynthia.re" rel="noreferrer" target="_blank">https://lists.ripe.net/mailman/options/members-discuss/me%40cynthia.re</a> > > _______________________________________________ > members-discuss mailing list > <a href="mailto:members-discuss@ripe.net" target="_blank">members-discuss@ripe.net</a> > <a href="https://mailman.ripe.net/" rel="noreferrer" target="_blank">https://mailman.ripe.net/</a> > Unsubscribe: > <a href="https://lists.ripe.net/mailman/options/members-discuss/ivaylo%40bglans.net" rel="noreferrer" target="_blank">https://lists.ripe.net/mailman/options/members-discuss/ivaylo%40bglans.net</a> > _______________________________________________ members-discuss mailing list <a href="mailto:members-discuss@ripe.net" target="_blank">members-discuss@ripe.net</a> <a href="https://mailman.ripe.net/" rel="noreferrer" target="_blank">https://mailman.ripe.net/</a> Unsubscribe: <a href="https://lists.ripe.net/mailman/options/members-discuss/malek%40malek.li" rel="noreferrer" target="_blank">https://lists.ripe.net/mailman/options/members-discuss/malek%40malek.li</a> </blockquote></div>