Dear colleagues,
Thank you very much for your feedback.
The part of the policy that I will propose to change is relatively small
and should have limited impact on the other parts of the IPv6 policy. In
alignment with the Address Policy WG co-chairs, I will now work on the
actual policy proposal and aim to have it published before RIPE 93.
I think that once the draft policy text is available, it will also be
easier for the working group to discuss the merits of the proposed change.
Regarding the idea of a complete rewrite of the IPv6 policy and other
policy documents, if the working group decides to take on such a task,
the RIPE NCC would be happy to provide support. As such a rewrite would
likely take quite some time, I still think it would be useful to discuss
my proposal separately first.
I believe the proposed change would provide some needed clarification
around audits and policy compliance in the IPv6 policy. It would also
bring the IPv6 policy more in line with the IPv4 policy for these
topics, which could be also beneficial if there is ever an effort to
create a single policy manual, as Remco suggested.
Kind regards,
Marco Schmidt
Manager Registration Services
RIPE NCC
On 08/09/2026 17:42, Remco van Mook wrote:
Hi Nick,
I think you're misreading my assessment as frustration. I'd applaud any and all
incremental improvement to the current set of documents, with exactly the
caveat James describes: even minor changes need the rigour of thinking through
all implications, documented and undocumented.
The breakage you describe, and the tolerance involved, is something we're
already living: we've just come to terms with it. We don't have text that
unambiguously and consistently describes our current policies; we make it work
by being incredibly nice people and letting the RIPE NCC absorb the ambiguity.
That's not a stable arrangement, it's an undocumented dependency.
A straw man of what a single policy manual would look like (covering the policy
stack, the NCC's interpretations, the NWIs, and harmonised terminology) would
give us a scope of the potential breakage and its consequences, and give this
working group something concrete to discuss and decide on. I understand that
falls under your description of 'kitchen sink proposals', but at this point I'd
like a picture of what a new kitchen would look like before we keep calling for
the plumber to come in.
Your DB Task Force experience is, if anything, the argument for doing it this
way: a small group went in with chainsaws revving and came out with a
considered, evolutionary result, without burning PDP cycles to get there. I'd
support chartering something similar for the policy manual question, and I'm
willing to put time into it.
We're burning significant amounts of human capital and willingness to engage in
the process. We don't have that much left to spend.
Remco
On 8 Sep 2026, at 15:56, Nick Hilliard <[email protected]> wrote:
Hi Remco,
Frustration can be a good driver for change, but the question is: how high is
everyone's tolerance for breakage, and who gets to put up with the consequences?
A couple of years ago, several of us started out in the DB Task Force with
chain saws revving and ready for action, but we walked out with a strong sense
that evolution was a better approach than revolution.
I don't think, incidentally, that there's a problem making smaller changes of
the sort that Marco is proposing, and in fact changes like this are much needed
and would be much appreciated. The reason I suggested breaking things out into
separate updates is that kitchen sink proposals are often a nuisance to handle
and non-contentious changes end up being blocked by other changes. This is not
a good use of peoples' time or resources.
Nick
Remco van Mook wrote on 08/09/2026 14:05:
Hi all,
actually I'd argue the opposite (as I already did at AP during RIPE89:
https://ripe89.ripe.net/wp-content/uploads/presentations/83-ripe-89-address-policy.pdf
I think discussions in AP over the last years have shown that our current set
of policies is now so hard to have a common understanding about and so hard to
actually produce updates for, that I think we'd do very well to go and turn our
current policy stack, how the NCC interprets those policies, the NWIs, and an
all-over harmonisation of terms into a single consistent policy manual, ARIN
style. It would also help us to finally get an actual definition of
'assignment' in the IPv6 context.
If it's not feasible at this point to do a rewrite, waiting longer will
certainly not make matters better. The observation that even minor changes have
a chance to cause a major ripple in the reading of our current policy set
demonstrates the predicament we're in. If seasoned policy experts have trouble
getting this right at this point, how can we expect any newcomers to make a
contribution?
Kind regards
Remco
On 8 Sep 2026, at 14:40, James Kennedy via address-policy-wg
<[email protected]> <mailto:[email protected]> wrote:
As a general comment,
my inclination would either be to do a complete top-down rewrite of
specific documents, or else approach rewrites with changes only to small
areas. Otherwise you end up with the risk of minor changes derailing
other, and potentially more important, changes.
I tend to favour the latter. A complete top-down rewrite of RIPE policy
documents sounds tempting but I'm not sure how feasible that would be in
practice.
Either way, even minor changes must have their impact on existing policies
properly identified and taken into account. On mitigating the risk of derailing
other ongoing changes, I trust the WG chairs to coordinate that with the
proposers :)
Best,
James
From: Nick Hilliard <[email protected]> <mailto:[email protected]>
To: "Marco Schmidt"<[email protected]> <mailto:[email protected]>
Cc: "[email protected]"
<mailto:[email protected]><[email protected]>
<mailto:[email protected]>
Date: Tue, 08 Sep 2026 11:05:53 +0100
Subject: [address-policy-wg] Re: Feedback for potential policy proposal on IPv6
Marco Schmidt wrote on 08/09/2026 06:07:
The main points I raised were the lack of a general reference to the
audit procedure in the IPv6 policy, and the wording of the section
dealing with policy compliance and non-compliance, which has remained
unchanged since 2002 and might be difficult to understand without the
historical context.
for sure, the existing section of policy that you quoted is not well
written and doesn't look like it reflects how ipv6 address resources are
handled. It would benefit from a rewrite.
In terms of other RIPE policy document changes, there's no shortage of
material that could be improved: many of the documents are the product
of organic growth, and show all the signs of it. As a general comment,
my inclination would either be to do a complete top-down rewrite of
specific documents, or else approach rewrites with changes only to small
areas. Otherwise you end up with the risk of minor changes derailing
other, and potentially more important, changes.
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/
-----
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/
-----
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/
-----
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/
