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/[email protected]/
[members-discuss] [ncc-announce] [GM] Consultation on RIPE NCC Charging Scheme
- Previous message (by thread): [members-discuss] [ncc-announce] [GM] Consultation on RIPE NCC Charging Scheme
- Next message (by thread): [members-discuss] [ncc-announce] [GM] Consultation on RIPE NCC Charging Scheme
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Sander Steffann
sander at steffann.nl
Sat Apr 15 00:14:54 CEST 2023
Hi, > On 13 Apr 2023, at 17:20, Gert Doering <gert at space.net> wrote: > > Hi, > > On Wed, Apr 12, 2023 at 04:21:48PM +0200, David Br??ha wrote: >> But after seeing the new updated calculator we would definitely return part of our IPv6 >> allocation if the charging scheme category A should be chosen. The "free" enlargement >> from /32 to /29 suddenly costs 350 Euro per year. > > Uh. I did not see this, but this looks like a very very bad idea. I missed that as well. > ARIN does this ("a /36 costs less than a /32") and it's a very bad idea, > because it encourages conservation where IPv6 should bring in sufficient > address space to enjoy the benefits, like, simplicity in end user > assignments. > > So NCC, are you serious about that? This suggestion affects address policy, > which is not your job to do, and the *size* of an IPv6 allocation does not > affect the costs caused by it. > > Very bad idea. +1 I have the feeling the boundaries are set by looking at the bookkeeping consequences, not networking practices. If a boundary is needed, I’d suggest to set it at /44 (a handful of /48 assignments) for the smaller categories. If a boundary is necessary for the higher categories, set it at something that requires actual effort. So Everything from /32 to /29 shouldn’t affect the category. And I like nibble boundaries, so boundaries at /28 and/or /24 would be kind of ok. I would prefer clear explanations for the “meaning” of all the categories. Now it feels some nice fee amounts were chosen, and then some arbitrary limits were placed to make the budget fit. I’l like to see the opposite approach. First define the categories (like 1: PI holder with a few small resources like a handful of IPv4/24 and IPv6/48, 2: Small LIR with IPv4/21 and IPv6/29, 3: Larger ISP … etc) and *then* see what the membership fees need to be. What I also strongly object to is to include independent resources in the category system. As a smaller company, with the proposed scheme, I have to really be careful not to push myself into a larger category (and thereby doubling the base yearly fee) by becoming the sponsoring LIR for one extra resource, while larger members have it “included” in their fee already and don’t run that risk. This benefits larger companies and discourages smaller companies from being someone’s Sponsoring LIR. I am Sponsoring LIR some some fellow network engineers, and I don’t make any profit on those resources. If those “charity” sponsorships can suddenly raise my base membership fee I won’t be able to do that anymore. I think that is very wrong. Independent resources are already charged separately. Leave it at that. I don’t mind if the fee for each resource is raised to compensate. That is cost I can charge to the customer. But my membership fee going up isn’t. Cheers, Sander
- Previous message (by thread): [members-discuss] [ncc-announce] [GM] Consultation on RIPE NCC Charging Scheme
- Next message (by thread): [members-discuss] [ncc-announce] [GM] Consultation on RIPE NCC Charging Scheme
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]