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] Charging scheme 2025 proposal (logarithmic)
- Previous message (by thread): [members-discuss] Charging scheme 2025 proposal (logarithmic)
- Next message (by thread): [members-discuss] Charging scheme 2025 proposal (logarithmic)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Jochen Bern
ripe at binect.de
Wed Apr 17 13:32:18 CEST 2024
On 17.04.24 11:50, Evgeniy Brodskiy via members-discuss wrote: > I think there is one more circle. Some members simply want to increase > the cost of ownership IPv4 address space. > > From: members-discuss <...> On Behalf Of Kurtis Lindqvist > Sent: Wednesday, April 17, 2024 11:56 AM > > Isn’t this really at the heart of the problem. In a Venn diagram there > are (at least) three circles here, the members with an opinion the > mailinglist who want to crystalise the core services and keep RIPE NCC > costs lower and see greater efficiency gains, there is the circle of > members who respond to the membership survey and are happy and want to > keep all services as they are and then there is a circle of the members > who actually vote (and possibly manage the payments). I am not convinced > there is a great overlap of these circles and so we end up in a situation > with very little guidance. Actually, the *most* important circle is *still* missing in the picture you paint: The "big corp" members of RIPE that so many suspect of intentionally mooching off the small LIRs. Because whatever your/our first move is, they'll *still* be present, be RIPE members (possibly *several*), have deeper pockets, and (supposedly) want to spend it to counteract you. Which has an overwhelming effect on the timelines: -- It takes half an hour to take your personal definition of "fair" (or whatever term you prefer), do an off-the-cuff computation based on it, and post your favorite alternative charging scheme asking to have it put to vote as well. -- It takes maybe a couple hours for someone to play advocatus diaboli and point out how "big corp" could react so as to game that scheme and turn it *against* you. (Yes, there have been several such replies in the current spate of list mails, too, essentially falling on deaf ears.) -- It takes until a GM - *ideally* the next, but don't hold your breath - to have a vote on what definition *RIPE* and its executives shall have and use for "fair" so that we can hold all future proposed charging schemes against it *beforehand*. -- It probably will take *several years* of refinement to get all the loopholes ironed out before we have a, so to say, "scheme of charging schemes" that actually prevents "big evil corp" rolling it back from *within* RIPE. -- We will *NEVER* get to the point where "big corp" cannot use their means to launch, e.g., a political campaign a la "let's replace RIPE with Something Better™, thanks to the power of Good Legislation™!" (Which, in my book, means that we *should not* cut RIPE down to the budget covering the bare necessities and not more. Ask for the extra to be refunded at the end of the fiscal year if unused, but reacting to such a campaign with "ah, let's have a budget to fight that *next* year" is literally a nonstarter.) -- (In the meantime, the charging schemes that'll get the votes will likely still be the ones proposed by RIPE executives, because the simple mechanism of "he made that bed, knowing that he'll have to lie in it" makes it more trustworthy to the average voter than some other random guy's suggestion.) Kind regards, -- Jochen Bern Systemingenieur Binect GmbH
- Previous message (by thread): [members-discuss] Charging scheme 2025 proposal (logarithmic)
- Next message (by thread): [members-discuss] Charging scheme 2025 proposal (logarithmic)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]