<html> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> </head> <body text="#000000" bgcolor="#FFFFFF"> 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 <div class="moz-cite-prefix">Sebastian Malek je 19.4.2019 ob 11:56 napisal: </div> <blockquote type="cite" cite="mid:CANvJe7A42xbCwgB5ErsGnR+Ow_t+3XnPVZj2SP_V9gR0GLdFQA@mail.gmail.com"> <meta http-equiv="content-type" content="text/html; charset=UTF-8"> <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" moz-do-not-send="true">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" moz-do-not-send="true">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" moz-do-not-send="true">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" moz-do-not-send="true">10.0.0.0/22</a> >> <a href="http://10.0.4.0/22" rel="noreferrer" target="_blank" moz-do-not-send="true">10.0.4.0/22</a> >> <a href="http://10.0.8.0/22" rel="noreferrer" target="_blank" moz-do-not-send="true">10.0.8.0/22</a> >> <a href="http://10.0.12.0/22" rel="noreferrer" target="_blank" moz-do-not-send="true">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" moz-do-not-send="true">members-discuss@ripe.net</a> >>> <a href="https://lists.ripe.net/mailman/listinfo/members-discuss" rel="noreferrer" target="_blank" moz-do-not-send="true">https://lists.ripe.net/mailman/listinfo/members-discuss</a> >>> Unsubscribe: >>> <a href="https://lists.ripe.net/mailman/options/members-discuss/ivaylo%40bglans.net" rel="noreferrer" target="_blank" moz-do-not-send="true">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" moz-do-not-send="true">members-discuss@ripe.net</a> >> <a href="https://lists.ripe.net/mailman/listinfo/members-discuss" rel="noreferrer" target="_blank" moz-do-not-send="true">https://lists.ripe.net/mailman/listinfo/members-discuss</a> >> Unsubscribe: >> <a href="https://lists.ripe.net/mailman/options/members-discuss/me%40cynthia.re" rel="noreferrer" target="_blank" moz-do-not-send="true">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" moz-do-not-send="true">members-discuss@ripe.net</a> > <a href="https://lists.ripe.net/mailman/listinfo/members-discuss" rel="noreferrer" target="_blank" moz-do-not-send="true">https://lists.ripe.net/mailman/listinfo/members-discuss</a> > Unsubscribe: > <a href="https://lists.ripe.net/mailman/options/members-discuss/ivaylo%40bglans.net" rel="noreferrer" target="_blank" moz-do-not-send="true">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" moz-do-not-send="true">members-discuss@ripe.net</a> <a href="https://lists.ripe.net/mailman/listinfo/members-discuss" rel="noreferrer" target="_blank" moz-do-not-send="true">https://lists.ripe.net/mailman/listinfo/members-discuss</a> Unsubscribe: <a href="https://lists.ripe.net/mailman/options/members-discuss/malek%40malek.li" rel="noreferrer" target="_blank" moz-do-not-send="true">https://lists.ripe.net/mailman/options/members-discuss/malek%40malek.li</a> </blockquote> </div> <fieldset class="mimeAttachmentHeader"></fieldset> <pre class="moz-quote-pre" wrap="">_______________________________________________ members-discuss mailing list <a class="moz-txt-link-abbreviated" href="mailto:members-discuss@ripe.net">members-discuss@ripe.net</a> <a class="moz-txt-link-freetext" href="https://lists.ripe.net/mailman/listinfo/members-discuss">https://lists.ripe.net/mailman/listinfo/members-discuss</a> Unsubscribe: <a class="moz-txt-link-freetext" href="https://lists.ripe.net/mailman/options/members-discuss/matej.serc%40elmitel.com">https://lists.ripe.net/mailman/options/members-discuss/matej.serc%40elmitel.com</a> </pre> </blockquote> <pre class="moz-signature" cols="72">-- 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: <a class="moz-txt-link-abbreviated" href="http://www.elmitel.com">www.elmitel.com</a> E: <a class="moz-txt-link-abbreviated" href="mailto:matej.serc@elmitel.com">matej.serc@elmitel.com</a> </pre> </body> </html>