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-minute...
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