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/
