Remco van Mook wrote on 25/08/2026 16:07:
Implementation cost:
Software, processes, documentation and training/exam material would
need to be changed.
It's valid to raise implementation costs. In the RIPE community, we're
within our rights to demand things in policy proposals, including
unicorns, but the NCC is charged with execution and the NCC Board is
charged with governance. Part of their jobs is to raise concerns if they
feel that there are policy proposal issues that are problematic from
their point of view, and that includes fiscal management.
If they didn't do this, they wouldn't be doing the jobs we asked them to do.
If "We would have to change things and that costs
money" becomes a sufficient argument against a proposed policy change
we might as well stop doing them. Nothing in this line of reasoning
tells me anything about the substance of the proposal, and the merits
of it.
There's a good deal of member scrutiny about RIPE NCC expenditure at the
moment. You may not have meant to do this, but this is putting the board
in a damned-if-you-do, damned-if-you-don't situation (but see next para
below).
I am also somewhat disappointed that the Executive board thought it
fitting to advise revision in a single sentence without any stated
reasoning - and I'm not going to dig through the board minutes to
find the reasoning, if it exists. I would very much like to hear the
board's reasoning; both for the comment itself and the way they
decided to present it.
There was apparently an update to the board provided by Mirjam on June 22:
https://www.ripe.net/about-us/executive-board/minutes/executive-board-minutes-2026/194th-executive-board-meeting-minutes/
I read their comment as: "we support the analysis of the NCC, for the
reasons provided by the NCC", which is ok as a response from the board
if that's what it was. Maybe someone from the board could confirm if
this reading was wrong.
Ignoring the other two substantial points (which I agree with):
3 - Internal consistency. Proposed 2.6 permits conditional
sub-assignment and the untouched text of article 7 still states that
PI cannot be further sub-assigned, and the interaction with 7.2 would
put an End User who later becomes a member/LIR themselves in
automatic violation.
This is a fairly fundamental problem with the policy, which changes the
terms of an address assignment from "may not be sub-assigned", to "it's
ok for small amounts".
On the NCC's enforcement dilemma: this is the permanent shape of
every needs-based policy we've ever had, going back all the way to
the original IPv4 policy. The same goes for the ambiguity of the term
'end site': I see that that will become a policy proposal in its own
right and I'm very much looking forward to reading it - it is overdue
by decades, in my opinion.
This kinda gets into the meat of it, and I'm struggling with two things
here:
1. this policy substantially changes the meaning of an IP number
resource assignment from end-user-only to end-user-mostly. That might
or might not be a reasonable thing to do, but it doesn't belong in a
housekeeping policy like 2024-01. If it's the intention of the authors
to change the semantics of this term, then this is a substantial policy
change which needs to be handled as a standalone proposal.
2. If there's an appetite for changing the meaning of an "assignment"
for ipv6, then something comparable needs to be applied to ipv4 assignments.
Nick
-----
To unsubscribe from this mailing list or change your subscription options,
please visit:
https://mailman.ripe.net/mailman3/lists/address-policy-wg.ripe.net/
As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings.
More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
