Re: [members-discuss] [ncc-announce] [GM] Publication of Draft Charging Scheme Models 2024
On 18.04.23 16:37, Clement Cavadore wrote:
On Tue, 2023-04-18 at 16:30 +0200, Gert Doering wrote:
So a reclaim mechanism is required - the real question is, of course, what that mechanism should be. Pay NCC staff to go out and ask LIRs "is this ASN still in use? is the data accurate? can you return it?", or create an incentive for them to come back voluntarily. [...] But AFAIK, RIPE NCC already does this kind of mechanism for ASN which are not seen on the DFZ. They ask if it's in use, and why it's not seen on the DFZ (and there are legit use case, for example for IXP route- server ASN, or for out of internet routing domains).
Make it a formal requirement to *either* be publicly connected *or* actively maintain the corresponding aut-num object, send annual reminders to those who seem AWOL, and investigate (+ bill extra?) only those who still haven't edited the "confirmed as of ..." field two months later, then. Speaking more generally, the impression I'm getting from this entire discussion is that we don't have an agreement on what the *basic principle* of RIPE's billing should be, much less on a specific charging scheme implementing any such principle: -- As a not-for-profit org, RIPE has an interest to charge in direct relation to the effort/expenses it has to cover. The *strictest* possible form of doing that would, of course, be to have fees paid for every activity (trouble ticket?) they undertake, possibly not even fixed ones. -- Since they *also* have an interest to generate a prima-facie-known income *before* expenses need to be paid and defaulters hunted down (who here would be willing to pay a fee for being *turned down* by RIPE because of due diligence?), they *actually* propose fees on resources held, as an *estimator*, however poor IMHO, of the activities that those will require/generate. -- For the polar opposite, there are those who said that plentiful resources that were handed RIPE for free should still be free for further distribution. Which essentially is an "eternally fixed prices" model, with IPv4 IPs being the striking example of a resource that *ceased* to be plentiful later on (and is unlikely to return to "free" short of IPv4 getting globally disabled, no matter how and how hard RIRs might try to push for that). -- Then there's the idea of assigning prices as a means of policing distribution/usage, in particular, to cause unused IPv4 to be handed back to RIPE. (Which means that RIPE would need to invoice *more* per IP than you can earn by renting/selling them on the free market - which will happily react by raising the price, etc. ad infinitum -, *or* somehow manage to disrupt said free market ... ho hum.) -- Last not least (though I'm probably still forgetting some), those who would like RIPE to stay with identical fees for all members, independent of their size. Which ultimately translates into "pay per vote" ... Two more thoughts: If there is pressure to give "back" IPv4 space that you don't use yourself (and, again, the price for which you could instead sell them *already is* such pressure), it'll get more fragmented than ever, and thus eat more RAM etc. on every EBGP peer. Are we really *helping* IPv4 there ... or handing it more rope to cut its misery ever shorter? :-3 Finally, I'd like to speak in favor of intentionally "overcharging" members with the charging scheme and "redistributing" the excess back to them (a year) later. Stripping RIPE down to the minimum viable budget may look good on everyone's invoice, but it also creates a representative of the community that is a defenseless pushover as soon as some commercial entity (with some money to spend, contacts to lobby, etc.) deigns to take over. Assuming that the "excess" stays roughly the same and *no* hostile takeover is attempted, it can be considered a deposit for the duration of one's membership, even though the figures on the bill *look* that much higher every year. Kind regards, -- Jochen Bern Systemingenieur Binect GmbH
participants (1)
-
Jochen Bern