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 ]