>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
>>
>> After split LIR-1 will have ALLOCATED-PA
>> 10.0.0.0/22
>> 10.0.4.0/22
>> 10.0.8.0/22
>> 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@ripe.net
>>> https://lists.ripe.net/mailman/listinfo/members-discuss
>>> Unsubscribe:
>>> https://lists.ripe.net/mailman/options/members-discuss/ivaylo%40bglans.net
>>>
>>
>> _______________________________________________
>> members-discuss mailing list
>> members-discuss@ripe.net
>> https://lists.ripe.net/mailman/listinfo/members-discuss
>> Unsubscribe:
>> https://lists.ripe.net/mailman/options/members-discuss/me%40cynthia.re
>
> _______________________________________________
> members-discuss mailing list
> members-discuss@ripe.net
> https://lists.ripe.net/mailman/listinfo/members-discuss
> Unsubscribe:
> https://lists.ripe.net/mailman/options/members-discuss/ivaylo%40bglans.net
>
_______________________________________________
members-discuss mailing list
members-discuss@ripe.net
https://lists.ripe.net/mailman/listinfo/members-discuss
Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/malek%40malek.li