Feedback for potential policy proposal on IPv6
Dear colleagues, I would like to follow up on a topic I raised during RIPE 92 regarding the IPv6 Address Allocation and Assignment Policy [1]. Over the years, this working group discussed a number of policy proposals to update the IPv6 policy framework. However, during recent reviews and audit activities, Registration Services found that some parts of the policy relating to the post-provisioning lifecycle could be clarified and made more consistent through a policy discussion. For example, while the term "audit" appears in some sections of the policy text, there is no general reference to the audit procedure itself (unlike in the IPv4 policy). While such reference is not a requirement to perform an audit on IPv6 resources, it would make the RIPE NCC mandate clearer to everyone. In addition, the section dealing with policy compliance and non-compliance has remained unchanged since 2002 and uses relatively complex wording: "[...] The policies in this document are based upon the understanding that globally unique IPv6 unicast address space is licensed for use rather than owned. Specifically, IP addresses will be allocated and assigned on a license basis, with licenses subject to renewal on a periodic basis. The granting of a license is subject to specific conditions applied at the start or renewal of the license. RIRs will generally renew licenses automatically, provided requesting organisations are making a “good faith” effort at meeting the criteria under which they qualified for or were granted an allocation or assignment. However, in those cases where a requesting organisation is not using the address space as intended, or is showing bad faith in following through on the associated obligation, RIRs reserve the right to not renew the license. Note that when a license is renewed, the new license will be evaluated under and governed by the applicable IPv6 address policies in place at the time of renewal, which may differ from the policy in place at the time of the original allocation or assignment." [2] While the intent of this text remains valid, some parts may be difficult to grasp, particularly for those less familiar with RIPE policies and their historical context. As these sections primarily affect the RIPE NCC's role in assessing and maintaining policy compliance after resources have been issued, I am considering creating a policy proposal aimed at improving clarity and consistency. The intention would be to clearly define the existing framework rather than make substantive changes to the policy’s intent. Before creating this proposal, I welcome feedback from the working group. Do you think these parts of the IPv6 policy could benefit from review? Are there other areas that you believe should be clarified, updated, or taken into account if a proposal were developed? Kind regards, Marco Schmidt Manager Registration Services RIPE NCC [1] https://pretalx.ripe.net/media/ripe-92/submissions/JZ3KEL/resources/RIPE_92_... [2] https://www.ripe.net/publications/docs/ripe-738/#41-address-space-not-to-be-...
Dear colleagues, I would like to follow up on my email below regarding a possible review of the IPv6 Address Allocation and Assignment Policy. 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. My intention would be to clarify and improve the existing framework, rather than to introduce substantive policy changes. So far, I have not received any feedback. Before considering a policy proposal, I would very much appreciate hearing the your views. Do you think these areas would benefit from clarification or review, or are there maybe other aspects of the policy that also should be considered? Even brief feedback would be very helpful. Kind regards, Marco Schmidt Manager Registration Services RIPE NCC On 02/07/2026 14:31, Marco Schmidt wrote:
Dear colleagues,
I would like to follow up on a topic I raised during RIPE 92 regarding the IPv6 Address Allocation and Assignment Policy [1].
Over the years, this working group discussed a number of policy proposals to update the IPv6 policy framework. However, during recent reviews and audit activities, Registration Services found that some parts of the policy relating to the post-provisioning lifecycle could be clarified and made more consistent through a policy discussion.
For example, while the term "audit" appears in some sections of the policy text, there is no general reference to the audit procedure itself (unlike in the IPv4 policy). While such reference is not a requirement to perform an audit on IPv6 resources, it would make the RIPE NCC mandate clearer to everyone.
In addition, the section dealing with policy compliance and non-compliance has remained unchanged since 2002 and uses relatively complex wording:
"[...] The policies in this document are based upon the understanding that globally unique IPv6 unicast address space is licensed for use rather than owned. Specifically, IP addresses will be allocated and assigned on a license basis, with licenses subject to renewal on a periodic basis. The granting of a license is subject to specific conditions applied at the start or renewal of the license. RIRs will generally renew licenses automatically, provided requesting organisations are making a “good faith” effort at meeting the criteria under which they qualified for or were granted an allocation or assignment. However, in those cases where a requesting organisation is not using the address space as intended, or is showing bad faith in following through on the associated obligation, RIRs reserve the right to not renew the license. Note that when a license is renewed, the new license will be evaluated under and governed by the applicable IPv6 address policies in place at the time of renewal, which may differ from the policy in place at the time of the original allocation or assignment." [2]
While the intent of this text remains valid, some parts may be difficult to grasp, particularly for those less familiar with RIPE policies and their historical context.
As these sections primarily affect the RIPE NCC's role in assessing and maintaining policy compliance after resources have been issued, I am considering creating a policy proposal aimed at improving clarity and consistency. The intention would be to clearly define the existing framework rather than make substantive changes to the policy’s intent.
Before creating this proposal, I welcome feedback from the working group.
Do you think these parts of the IPv6 policy could benefit from review? Are there other areas that you believe should be clarified, updated, or taken into account if a proposal were developed?
Kind regards, Marco Schmidt Manager Registration Services RIPE NCC
[1] https://pretalx.ripe.net/media/ripe-92/submissions/JZ3KEL/resources/RIPE_92_... [2] https://www.ripe.net/publications/docs/ripe-738/#41-address-space-not-to-be-...
On 8 Sep 2026, at 06:07, Marco Schmidt <mschmidt@ripe.net> wrote: […]
My intention would be to clarify and improve the existing framework, rather than to introduce substantive policy changes.
+1 to making policy text easier to understand. Thanks, Leo
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
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 <nick@foobar.org> To: "Marco Schmidt"<mschmidt@ripe.net> Cc: "address-policy-wg@ripe.net"<address-policy-wg@ripe.net> 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/
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-... 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 <address-policy-wg@ripe.net> 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 <nick@foobar.org> To: "Marco Schmidt"<mschmidt@ripe.net> Cc: "address-policy-wg@ripe.net"<address-policy-wg@ripe.net> 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/
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-... 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 <address-policy-wg@ripe.net> 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 <nick@foobar.org> To: "Marco Schmidt"<mschmidt@ripe.net> Cc: "address-policy-wg@ripe.net"<address-policy-wg@ripe.net> 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/
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 <nick@foobar.org> 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-... 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 <address-policy-wg@ripe.net> <mailto:address-policy-wg@ripe.net> 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 <nick@foobar.org> <mailto:nick@foobar.org> To: "Marco Schmidt"<mschmidt@ripe.net> <mailto:mschmidt@ripe.net> Cc: "address-policy-wg@ripe.net" <mailto:address-policy-wg@ripe.net><address-policy-wg@ripe.net> <mailto:address-policy-wg@ripe.net> 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/
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 <nick@foobar.org> 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-... 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 <address-policy-wg@ripe.net> <mailto:address-policy-wg@ripe.net> 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 <nick@foobar.org> <mailto:nick@foobar.org> To: "Marco Schmidt"<mschmidt@ripe.net> <mailto:mschmidt@ripe.net> Cc: "address-policy-wg@ripe.net" <mailto:address-policy-wg@ripe.net><address-policy-wg@ripe.net> <mailto:address-policy-wg@ripe.net> 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/
participants (5)
-
James Kennedy -
Leo Vegoda -
Marco Schmidt -
Nick Hilliard -
Remco van Mook