This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/members-discuss@ripe.net/
[members-discuss] RIPE NCC Charging Scheme 2020 - Board Reasoning
- Previous message (by thread): [members-discuss] RIPE NCC Charging Scheme 2020 - Board Reasoning
- Next message (by thread): [members-discuss] RIPE NCC Charging Scheme 2020 - Board Reasoning
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Radu-Adrian Feurdean
ripe-ncc at radu-adrian.feurdean.net
Fri Apr 19 14:22:46 CEST 2019
On Thu, Apr 18, 2019, at 18:19, Christian Kaufmann wrote: > 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 Hi, I only partly agree. Database-wise it is only valid at allocation-by-NCC time. A /24 can further generate up to 256 inetnums, supposing somebody crazy/motivated enough to create an inetnum object for every IP address (if that's even possible). A /12 can further generate a lot more inetnum objects, 4096 if the average size of a declared object is a /24. Obviously, this only applies for "ALLOCATED PA"/"ALLOCATED BY RIR", which can contain more specific "assignments". So the fact that all allocations are the same is open to some more debate. But I do understand the idea behind the rest of the argument for "option B". -- Radu-Adrian FEURDEAN
- Previous message (by thread): [members-discuss] RIPE NCC Charging Scheme 2020 - Board Reasoning
- Next message (by thread): [members-discuss] RIPE NCC Charging Scheme 2020 - Board Reasoning
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]