Re: Early Feedback Requested on Upcoming Policy Proposal: Clarifying the non-transferability of legacy status
Hello Clara, We have always appreciate your contributions to the community; they have never gone unnoticed. Thank you for the opportunity to review the draft proposal. After evaluating the rationale presented, we would like to offer several important considerations before this moves forward. 1. The proposal seems to extend beyond a simple clarification of legacy status Framing this as a clarification minimizes the actual substantive change being introduced. The draft attempts to modify how legacy resources are treated within RIPE. This looks like more of a policy change request — rather than a clarification — and should probably be evaluated as such. 2. RIPE service fees already apply when members choose to adopt additional services such as RPKI Opting into RPKI is a voluntary operational decision and already incurs a RIPE service fee. This is not an example of a loophole or unfair circumvention. The current system already aligns incentives without requiring a change to legacy status inheritance. 3. The operational burden described does not appear to represent a systemic or material issue The referenced 0.5 FTE and the stated processing times should be evaluated in context. The minimal legacy transfers annually (which can be clarified as a percentage of total requests by RIPE) does not constitute a large-scale operational problem. Before moving forward with a policy change of this magnitude, it would be prudent to directly audit the RIPE NCC Registration Services teams workload to determine if these transfers materially impede normal levels of service level as compared to previous years. A policy change intended to reduce operational strain should be based on explicit confirmation from the impacted teams that the strain is significant enough to warrant structural change. All the best, Jake Brander President | Brander Group Inc. O: (702) 560-5616 x700 | M: (310) 595-6266 jake@brandergroup.net<mailto:jake@brandergroup.net> | www.brandergroup.net<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.brandergroup.net&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=8HXWKAES8qv8aCy_hbszPEUvLmmOuFEEX3sDyVHhRhY&m=tXs7R8vlY1Um5InAocu2IRGe-W0KmQE21IQm2_kk0Yg1EBN8U58kYYIMhcvrOtUI&s=Q7O97dg2Iee6SZMjKTcKumO5Mb4vtSTU1ymSVoeWABk&e=> Take Advantage of our Free IPAM Software– Learn More<https://urldefense.proofpoint.com/v2/url?u=https-3A__brandergroup.net_brandervision-2Dipam-2Dipv4-2Dmanagement_&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=8HXWKAES8qv8aCy_hbszPEUvLmmOuFEEX3sDyVHhRhY&m=tXs7R8vlY1Um5InAocu2IRGe-W0KmQE21IQm2_kk0Yg1EBN8U58kYYIMhcvrOtUI&s=pVTDsUMgqSpj10zbILKptcgqsmjJ6BaBVbZZMbw0ajE&e=> Award Winners for Revenue Growth & Support – Read More<https://urldefense.proofpoint.com/v2/url?u=https-3A__brandergroup.net_press-2Dreleases&d=DwMF-g&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=8HXWKAES8qv8aCy_hbszPEUvLmmOuFEEX3sDyVHhRhY&m=a5e7FGnBPcCoUPbvZ8VgBs6SAukDUZSNB14kHnsOgbBA-2TE9-xvHBGUR2Gnw_Xd&s=8UcQoSJsaboF6kwX9r2P2j50-7M3ZFhMGNJiBonTuz8&e=> Provider Agnostic Solutions with Wholesale Prices – Learn More<https://urldefense.proofpoint.com/v2/url?u=https-3A__brandergroup.net_solutions&d=DwMF-g&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=8HXWKAES8qv8aCy_hbszPEUvLmmOuFEEX3sDyVHhRhY&m=a5e7FGnBPcCoUPbvZ8VgBs6SAukDUZSNB14kHnsOgbBA-2TE9-xvHBGUR2Gnw_Xd&s=ng-5_ggLSoS7FXEOy8jLOV0nIB-QLXdiW6p21O11NgY&e=> From: Mike Burns <mike@iptrading.com<mailto:mike@iptrading.com>> Sent: Monday, November 17, 2025 6:56 PM To: 'denis walker' <ripedenis@gmail.com<mailto:ripedenis@gmail.com>>; 'Antonis Chariton' <daknob@daknob.net<mailto:daknob@daknob.net>> Cc: 'address-policy-wg@ripe.net<mailto:address-policy-wg@ripe.net>' <address-policy-wg@ripe.net<mailto:address-policy-wg@ripe.net>>; 'peter.hessler@zayo.com<mailto:peter.hessler@zayo.com>' <peter.hessler@zayo.com<mailto:peter.hessler@zayo.com>>; 'Wade, Clara' <clarawad@amazon.com<mailto:clarawad@amazon.com>> Subject: RE: [address-policy-wg] Re: Early Feedback Requested on Upcoming Policy Proposal: Clarifying the non-transferability of legacy status Hello, My problem with the upcoming proposal is this inaccurate statement: “This is currently being used as a loophole by certain actors to opt out of having a contractual relationship with the RIPE NCC in order to circumvent: RIPE registration services fees. 1. The 24-month transfer lock that was introduced by this working group to prevent flipping of scarce resources. 2. Needs-based inter-RIR transfer policy utilization requirements in the case of transfers from another RIR to a recipient of a legacy resource transfer in the RIPE region.” Point 2 is plainly incorrect. Please take this as feedback that this should be removed from any policy proposal. The truth is that utilization requirements apply only to inbound transfers from ARIN, and those transfers are treated the same whether legacy status or not. Regards, Mike Burns IPTrading. From: denis walker <ripedenis@gmail.com<mailto:ripedenis@gmail.com>> Sent: Thursday, October 30, 2025 4:30 PM To: Antonis Chariton <daknob@daknob.net<mailto:daknob@daknob.net>> Cc: address-policy-wg@ripe.net<mailto:address-policy-wg@ripe.net>; peter.hessler@zayo.com<mailto:peter.hessler@zayo.com>; Wade, Clara <clarawad@amazon.com<mailto:clarawad@amazon.com>> Subject: [address-policy-wg] Re: Early Feedback Requested on Upcoming Policy Proposal: Clarifying the non-transferability of legacy status Hi Antonis Maybe I am missing something here. But all I am hearing is: LEGACY-GREED LEGACY-MONEY LEGACY-PROFIT LEGACY-LOW SECURITY LEGACY-ATTRACTIVE TO PEOPLE WHO DON'T WANT TO BE IDENTIFIED Maybe it is time to end any LEGACY special considerations. There is nothing special about LEGACY space. These people were just lucky to be given a huge chunk of address space at a time when people didn't understand the potential or value of addresses. Since then society, technology, internet structures, e-governance have all moved on. We became more organised and structured, Everything has moved on except LEGACY holders. Maybe it is time we had one simple rule. ALL address space usage must be registered and managed in the same way, with an RIR, regardless of how you acquired it. You say this will force LEGACY holders to operate outside of the RIR system. What if all the RIR members blocked all addresses that are not properly registered (with one of the RIRs) and accountable? I have no operator experience so I don't know if it is technically (or politically / financially) possible to shut out ALL un-registered address space. If it is, I think we should do it. Have one last showdown. Join the club or stay out in the cold. I don't want your insecure, unaccountable customers connected to my internet. I am not an operator or routing expert, so I may be talking complete rubbish here. But I think you understand the principle I am suggesting. Maybe someone more knowledgeable can outline if/how we can collectively shut out LEGACY space if they refuse to join the club? There is of course another path that may be forced onto LEGACY holders and the RIRs...legislation. LEAs are getting more involved now in registry activities. While they have one foot in our camp, maybe their other foot is in the legislators camp. Especially the European Commision (EC). Operators no longer have full control over operations. Some of the LEGACY space is trying to operate outside of 'the system'. In an area where they are less accountable and they may attract 'undesirable' customers who are not easy to identify or locate. I suspect the timespan for the RIPE community to sort this out is shrinking. Look at some of the legislation that has come from the EC in recent years. Things like the e-evidence act. They have adopted ways of spreading the impact of their legislation beyond the borders of the EU. Another thought came to mind. I have never seen one of these agreements under which LEGACY holders were 'given' this address space. Do these agreements say that the terms and conditions are transferable? Can someone who 'buys' LEGACY space legitimately claim to 'own' it under the same conditions as the previous owner? Just a few thoughts... cheers denis On Thu, 30 Oct 2025 at 17:53, Antonis Chariton via address-policy-wg <address-policy-wg@ripe.net<mailto:address-policy-wg@ripe.net>> wrote: Thanks for the quick response Clara! Perhaps my feedback was not too clear, no worries :) — Existing resource holders will indeed keep their status, but I see a couple of things here: 1) When / if you transfer IPv4 you’ll be faced with a decision (and I guess most people will choose the status over RPKI) 2) When / if the charging scheme changes and doesn’t take the status into account (e.g. legacy counts towards the tier / membership fee) people will cancel the RIPE NCC legacy agreement (and just lose IRR / RPKI) The only reason I brought up #2 here, despite it not being related to your policy proposal, is that since both are public documents enough entities may connect the dots and realize that their legacy status is far more valuable than before. I’d argue that this current proposal increases the value of legacy, especially when combined with a new charging scheme. I hope that’s clearer now. Finally, in my experience at least, money is always a good reason to follow anti-patterns :( It’s true that there’s increased risk from IPv4 legacy but I’d argue that for most entities that will be affected this risk is lower than the costs that are or will be associated with it. Legacy cannot (easily?) be touched today by RIRs (we can only make the holders’ life more difficult) while PA is far more “vulnerable” to new policies and changes. PA also carries some risk at the end of the day and comes without any warranty. Antonis On 30 Oct 2025, at 17:38, Wade, Clara via address-policy-wg <address-policy-wg@ripe.net<mailto:address-policy-wg@ripe.net>> wrote: Antonis, Thanks for taking the time to provide feedback. It seems there’s a misunderstanding here. This policy proposal is forward-looking. We are not going to attempt to backfill/retrofit this change as we are trying to reduce overhead for the NCC, not generate more. We are simply trying to close a loophole that keeps getting exploited. As I mentioned in my response to Dominik, changing the holdership without going through due process is an anti-pattern and it also goes explicitly against the RIPE NCC process for legacy resource transfers outlined here: https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/transfer-of-ip-addresses-and-as-numbers/legacy-resources/<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ripe.net_manage-2Dips-2Dand-2Dasns_resource-2Dtransfers-2Dand-2Dmergers_transfer-2Dof-2Dip-2Daddresses-2Dand-2Das-2Dnumbers_legacy-2Dresources_&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=8HXWKAES8qv8aCy_hbszPEUvLmmOuFEEX3sDyVHhRhY&m=iPrYsbWzGEKOCyFCLAte9zZfMaFib9We0VmuFw4yhpT2uMySV9uZM2H_EkDLQeoG&s=ljnEUx6OKBT9usIbwXVgYxav_t5s-ErsNqbzgZs298o&e=> As I said before, hopefully, anyone engaging in these practices understands the risks they are assuming (for them and their customers if they are a service provider) by doing so. I would hope the community strives to build reliable networks rather than go against database accuracy and routing security best practices to avoid paying very reasonable registration service fees to safekeep important resources (especially in the case of most organizations where they do not pose a material cost). Thank you, Clara From: Antonis Chariton <daknob@daknob.net<mailto:daknob@daknob.net>> Date: Thursday, October 30, 2025 at 11:06 AM To: "address-policy-wg@ripe.net<mailto:address-policy-wg@ripe.net>" <address-policy-wg@ripe.net<mailto:address-policy-wg@ripe.net>> Cc: "Wade, Clara" <clarawad@amazon.com<mailto:clarawad@amazon.com>>, "peter.hessler@zayo.com<mailto:peter.hessler@zayo.com>" <peter.hessler@zayo.com<mailto:peter.hessler@zayo.com>>, Max Emig <ripe@emigm.ax<mailto:ripe@emigm.ax>> Subject: RE: [EXTERNAL] [address-policy-wg] Early Feedback Requested on Upcoming Policy Proposal: Clarifying the non-transferability of legacy status CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. Hello everyone, Although I’m not an expert in this area I’d also like to voice my agreement with Max’ point. Due to the nature of legacy IPv4 and ASes there’s no requirement for registration or notification of an RIR as far as I understand. That said, any sale can be conducted with a single contract between two parties and nobody is required to know about it. As far as I see it, these holders will face the following dilemma: RIPE IRR + RPKI or lower membership fees and retaining this status / flexibility. I think for most organizations the choice will be clear and they’ll choose the second, with the database slowly drifting away from the truth and fewer spaces being covered by ROAs. If someone has or buys an IPv4 /16 they’ll probably choose to opt-out of higher membership fees and will be fine losing a ROA or using RADB / ALTDB. This will also affect IXPs and other heavy users of IRR as more members / customers will require something in addition to RIPE’s database. If more and more entities start requesting the use of non-RIR sources of route objects this will undo progress for routing security. Finally, I expect that such policy can affect any votes for the proposed charging scheme that you’ve been working hard for all this time. Legacy blocks are usually larger and they will increase the cost / tier of someone significantly, making them naturally opposed to this change even if they believe it’s the right direction. Based on what Randy suggested and Marco’s information about the resources we spend I think keeping everything the same between LIRs and adding a transfer fee paid once as Capex / acquisition cost when e.g. the recipient is not an LIR would probably work better. If a fee cannot be applied, I’d also explore the possibility of only allowing inter-LIR transfers which means that either or both parties would have to create an LIR and the setup fee would more than cover the cost of the transaction, even if it’s only kept for a year and we get 1'000+1'800 = 2'800 EUR. That’s probably less than 1 EUR / address, reusable within the calendar year, and could cover the 0.5 FTE. I understand that a legacy-free world would simplify things for everyone, especially RIPE, and it sounds more fair, but we need to model the impact of every policy like this one realistically. Are we certain that RPKI is that good and worth the large cost we plan to impose? Are we causing harmful side effects by re-increasing the reliance and dependency on data sources we know are not meeting the same quality criteria? My personal belief is that this RIR is investing a lot more than 0.5 / 1 FTE for the benefit of the Internet so even if we treat this as a public service it may still be worth it. As an LIR and IXP member and operator I’d get more value than the cost of leaving everything as is completely. It centralizes some costs to RIPE instead of externalizing them, but economies of scale work here. Do you have any predictions as to which % of transfers or addresses will opt-in to this policy instead of just doing everything outside the RIR world? My expectation is that most transfers will opt-out at no cost to them and probably > 1 FTE worth of cost across all LIRs or IXPs / providers outside our service region. Antonis On 30 Oct 2025, at 16:17, Max Emig via address-policy-wg <address-policy-wg@ripe.net<mailto:address-policy-wg@ripe.net>> wrote: Hi Clara, a large Tier 1 carrier in the ARIN region did not update the ARIN Whois in 20 years and did not offer RPKI ROA until very recently over legal concerns and maintained their own whois along with the non-authoritative RADB. I would like to avoid any situations where organisations would have to choose between RIPE DB accuracy and routing security using RPKI ROA and legal-risks regarding out-of-region use among other concerns. Thanks Max On 30 October, 2025 15:29 CET, "Wade, Clara" <clarawad@amazon.com<mailto:clarawad@amazon.com>> wrote: Hi Max, I’m a little confused by the counter-argument here. Could you clarify how you believe this proposal would this lead to out-of-date data and less RPKI adoption? 1. Keeping legacy status when the resources are no longer held by the organization that received these pre-RIR administration is not really keeping the database accurate/up-to-date. 2. Legacy resource holders by default do not have access to RPKI. (You may get access by signing an agreement with the NCC, but unless you do, RPKI services are not included in the basic package offered to legacy resource holders who are not members.) Thank you, Clara From: Max Emig <ripe@emigm.ax<mailto:ripe@emigm.ax>> Date: Wednesday, October 29, 2025 at 4:54 PM To: "Wade, Clara" <clarawad@amazon.com<mailto:clarawad@amazon.com>> Cc: "address-policy-wg@ripe.net<mailto:address-policy-wg@ripe.net>" <address-policy-wg@ripe.net<mailto:address-policy-wg@ripe.net>>, "peter.hessler@zayo.com<mailto:peter.hessler@zayo.com>" <peter.hessler@zayo.com<mailto:peter.hessler@zayo.com>> Subject: RE: [EXTERNAL] [address-policy-wg] Early Feedback Requested on Upcoming Policy Proposal: Clarifying the non-transferability of legacy status CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. Good evening all, I oppose this policy proposal as it may lead to an increase on out-of-date data and less RPKI adoption. However, I would support adding a fee or another disincentive for keeping legacy status. Thanks Max On 27 October, 2025 17:12 CET, "Wade, Clara via address-policy-wg" <address-policy-wg@ripe.net<mailto:address-policy-wg@ripe.net>> wrote: Hello everyone, Following the suggestion of the RIPE NCC, we are seeking early feedback on an upcoming policy proposal we currently have in draft status. As mentioned last week after the Registration Services update from Marco at the AP-WG session - Peter Hessler and I, members of the now concluded Charging Scheme Task Force, are drafting a policy proposal to clarify the non-transferability of legacy status to address the issues of increasing overhead for the RIPE NCC, increasing market speculation around a scarce resource and its impact on the adoption of best practices like RPKI. Our proposal will modify these existing policies: 1. “RIPE Resource Transfer Policies” (RIPE-807) with additional clarifications in the Transfer Restrictions section and the Inter-RIR policy section. M&A/org restructuring transfers will be explicitly excluded. 2. “RIPE NCC Services to Legacy Internet Resource Holders” (RIPE-639) with modifications to remove the language implying new holders can keep legacy status after transfer. For background, legacy status was meant to indicate when an Internet resource had been directly assigned to the holder by IANA, before the RIRs were established. As such, ARIN, LACNIC and AFRINIC policies dictate that IPv4 legacy resources will no longer be regarded as legacy resources after a policy transfer takes place (excluding M&A transfers). RIPE is the only RIR that currently allows the recipient of a legacy transfer the ability to inherit the legacy status that was assigned to the original holder by IANA. This is currently being used as a loophole by certain actors to opt out of having a contractual relationship with the RIPE NCC in order to circumvent: 1. RIPE registration services fees. 2. The 24-month transfer lock that was introduced by this working group to prevent flipping of scarce resources. 3. Needs-based inter-RIR transfer policy utilization requirements in the case of transfers from another RIR to a recipient of a legacy resource transfer in the RIPE region. Following the publication of the Report of the RIPE NCC Charging Scheme Task Force, the membership learned that the RIPE NCC currently needs to dedicate a 0.5FTE to process legacy transfers. There are currently around 2,400 legacy resources held by 1,600 holders with no contractual relationship with the RIPE NCC (neither direct nor via a sponsor). That is around 40M IPs total or 5% of RIPE IPv4 space. In the last four years, NCC staff have processed between 370-280 legacy transfers per year, of which roughly a third do not involve a party with a contractual relationship with the NCC. Legacy transfers are more labor-intensive than other transfer types because the due diligence process requires the Registration Services team to manually source and verify pertaining documentation without the benefits of the automated processes for standard allocations. Legacy transfers take an average seven working hours to process when neither party has a contractual relationship with the NCC (around a third of legacy transfers), and six working hours to process when the parties have a contractual relationship with the NCC. If resources lost their legacy status after a transfer, these would then become standard allocations and staff could leverage enhanced compliance checks and automated processes to facilitate any future updates/transfers. These just take 1-3 working hours to process instead. Given that the task force was deemed out of scope for a policy change to address this gap, this is being brought to the attention of the Address Policy Working Group for action. If there are any concerns, questions or considerations you would like to bring up before we submit this proposal for discussion in the next week or two, we would really appreciate hearing from you so we can address these and/or incorporate them. Thanks in advance, Clara Wade ----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/address-policy-wg.ripe.net/<https://urldefense.proofpoint.com/v2/url?u=https-3A__mailman.ripe.net_mailman3_lists_address-2Dpolicy-2Dwg.ripe.net_&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=8HXWKAES8qv8aCy_hbszPEUvLmmOuFEEX3sDyVHhRhY&m=iPrYsbWzGEKOCyFCLAte9zZfMaFib9We0VmuFw4yhpT2uMySV9uZM2H_EkDLQeoG&s=gwIuOvsfL9o6eBToS0VCzFU3_0zxHsQO7knSPCkmJzw&e=> 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/<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ripe.net_membership_mail_mailman-2D3-2Dmigration_&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=8HXWKAES8qv8aCy_hbszPEUvLmmOuFEEX3sDyVHhRhY&m=iPrYsbWzGEKOCyFCLAte9zZfMaFib9We0VmuFw4yhpT2uMySV9uZM2H_EkDLQeoG&s=b43tZG1n9F6SvJpgwD6ZqSO6GXM1XQUSYDFrnWRaCb4&e=> ----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/address-policy-wg.ripe.net/<https://urldefense.proofpoint.com/v2/url?u=https-3A__mailman.ripe.net_mailman3_lists_address-2Dpolicy-2Dwg.ripe.net_&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=8HXWKAES8qv8aCy_hbszPEUvLmmOuFEEX3sDyVHhRhY&m=iPrYsbWzGEKOCyFCLAte9zZfMaFib9We0VmuFw4yhpT2uMySV9uZM2H_EkDLQeoG&s=gwIuOvsfL9o6eBToS0VCzFU3_0zxHsQO7knSPCkmJzw&e=> 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/<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ripe.net_membership_mail_mailman-2D3-2Dmigration_&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=8HXWKAES8qv8aCy_hbszPEUvLmmOuFEEX3sDyVHhRhY&m=iPrYsbWzGEKOCyFCLAte9zZfMaFib9We0VmuFw4yhpT2uMySV9uZM2H_EkDLQeoG&s=b43tZG1n9F6SvJpgwD6ZqSO6GXM1XQUSYDFrnWRaCb4&e=> ----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/address-policy-wg.ripe.net/<https://urldefense.proofpoint.com/v2/url?u=https-3A__mailman.ripe.net_mailman3_lists_address-2Dpolicy-2Dwg.ripe.net_&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=8HXWKAES8qv8aCy_hbszPEUvLmmOuFEEX3sDyVHhRhY&m=iPrYsbWzGEKOCyFCLAte9zZfMaFib9We0VmuFw4yhpT2uMySV9uZM2H_EkDLQeoG&s=gwIuOvsfL9o6eBToS0VCzFU3_0zxHsQO7knSPCkmJzw&e=> 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/<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ripe.net_membership_mail_mailman-2D3-2Dmigration_&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=8HXWKAES8qv8aCy_hbszPEUvLmmOuFEEX3sDyVHhRhY&m=iPrYsbWzGEKOCyFCLAte9zZfMaFib9We0VmuFw4yhpT2uMySV9uZM2H_EkDLQeoG&s=b43tZG1n9F6SvJpgwD6ZqSO6GXM1XQUSYDFrnWRaCb4&e=>
Hi Clara, all, Thank you for your feedback request. In short, I appreciate the proposal but disagree with the approach of this proposal. I believe there is a more elegant ways of resolving the time spent by RIPE NCC on legacy transfers without requiring a mandatory conversion to ALLOCATED PA/ASSIGNED PI status. RIPE NCC already offers services to LEGACY resource holders under a Legacy Registration Services Agreement[1]. Instead of requiring a mandatory conversion to ALLOCATED PA/ASSIGNED PI status upon transfer, I propose adding a requirement that the recipient of a LEGACY resource transfer needs to become a RIPE LIR member (or already have a RIPE LIR membership) and sign a Legacy Registration Services Agreement with RIPE NCC for the LEGACY resource being transferred. This way a contractual relationship with the NCC is present, and NCC can utilize its existing compliance checks and automated processes just like they would with the existing PA/PI allocations. Regards, Wessel 1: https://www.ripe.net/manage-ips-and-asns/legacy-resources/ripe-ncc-services-... Van: Brander Group via address-policy-wg <address-policy-wg@ripe.net> Verzonden: dinsdag 25 november 2025 22:28 Aan: address-policy-wg@ripe.net Onderwerp: [address-policy-wg] Re: Early Feedback Requested on Upcoming Policy Proposal: Clarifying the non-transferability of legacy status Hello Clara, We have always appreciate your contributions to the community; they have never gone unnoticed. Thank you for the opportunity to review the draft proposal. After evaluating the rationale presented, we would like to offer several important considerations before this moves forward. 1. The proposal seems to extend beyond a simple clarification of legacy status Framing this as a clarification minimizes the actual substantive change being introduced. The draft attempts to modify how legacy resources are treated within RIPE. This looks like more of a policy change request — rather than a clarification — and should probably be evaluated as such. 2. RIPE service fees already apply when members choose to adopt additional services such as RPKI Opting into RPKI is a voluntary operational decision and already incurs a RIPE service fee. This is not an example of a loophole or unfair circumvention. The current system already aligns incentives without requiring a change to legacy status inheritance. 3. The operational burden described does not appear to represent a systemic or material issue The referenced 0.5 FTE and the stated processing times should be evaluated in context. The minimal legacy transfers annually (which can be clarified as a percentage of total requests by RIPE) does not constitute a large-scale operational problem. Before moving forward with a policy change of this magnitude, it would be prudent to directly audit the RIPE NCC Registration Services teams workload to determine if these transfers materially impede normal levels of service level as compared to previous years. A policy change intended to reduce operational strain should be based on explicit confirmation from the impacted teams that the strain is significant enough to warrant structural change. All the best, Jake Brander President | Brander Group Inc. O: (702) 560-5616 x700 | M: (310) 595-6266 jake@brandergroup.net<mailto:jake@brandergroup.net> | www.brandergroup.net<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.brandergroup.net&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=8HXWKAES8qv8aCy_hbszPEUvLmmOuFEEX3sDyVHhRhY&m=tXs7R8vlY1Um5InAocu2IRGe-W0KmQE21IQm2_kk0Yg1EBN8U58kYYIMhcvrOtUI&s=Q7O97dg2Iee6SZMjKTcKumO5Mb4vtSTU1ymSVoeWABk&e=> Take Advantage of our Free IPAM Software– Learn More<https://urldefense.proofpoint.com/v2/url?u=https-3A__brandergroup.net_brandervision-2Dipam-2Dipv4-2Dmanagement_&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=8HXWKAES8qv8aCy_hbszPEUvLmmOuFEEX3sDyVHhRhY&m=tXs7R8vlY1Um5InAocu2IRGe-W0KmQE21IQm2_kk0Yg1EBN8U58kYYIMhcvrOtUI&s=pVTDsUMgqSpj10zbILKptcgqsmjJ6BaBVbZZMbw0ajE&e=> Award Winners for Revenue Growth & Support – Read More<https://urldefense.proofpoint.com/v2/url?u=https-3A__brandergroup.net_press-2Dreleases&d=DwMF-g&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=8HXWKAES8qv8aCy_hbszPEUvLmmOuFEEX3sDyVHhRhY&m=a5e7FGnBPcCoUPbvZ8VgBs6SAukDUZSNB14kHnsOgbBA-2TE9-xvHBGUR2Gnw_Xd&s=8UcQoSJsaboF6kwX9r2P2j50-7M3ZFhMGNJiBonTuz8&e=> Provider Agnostic Solutions with Wholesale Prices – Learn More<https://urldefense.proofpoint.com/v2/url?u=https-3A__brandergroup.net_solutions&d=DwMF-g&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=8HXWKAES8qv8aCy_hbszPEUvLmmOuFEEX3sDyVHhRhY&m=a5e7FGnBPcCoUPbvZ8VgBs6SAukDUZSNB14kHnsOgbBA-2TE9-xvHBGUR2Gnw_Xd&s=ng-5_ggLSoS7FXEOy8jLOV0nIB-QLXdiW6p21O11NgY&e=> From: Mike Burns <mike@iptrading.com<mailto:mike@iptrading.com>> Sent: Monday, November 17, 2025 6:56 PM To: 'denis walker' <ripedenis@gmail.com<mailto:ripedenis@gmail.com>>; 'Antonis Chariton' <daknob@daknob.net<mailto:daknob@daknob.net>> Cc: 'address-policy-wg@ripe.net<mailto:address-policy-wg@ripe.net>' <address-policy-wg@ripe.net<mailto:address-policy-wg@ripe.net>>; 'peter.hessler@zayo.com<mailto:peter.hessler@zayo.com>' <peter.hessler@zayo.com<mailto:peter.hessler@zayo.com>>; 'Wade, Clara' <clarawad@amazon.com<mailto:clarawad@amazon.com>> Subject: RE: [address-policy-wg] Re: Early Feedback Requested on Upcoming Policy Proposal: Clarifying the non-transferability of legacy status Hello, My problem with the upcoming proposal is this inaccurate statement: “This is currently being used as a loophole by certain actors to opt out of having a contractual relationship with the RIPE NCC in order to circumvent: RIPE registration services fees. 1. The 24-month transfer lock that was introduced by this working group to prevent flipping of scarce resources. 2. Needs-based inter-RIR transfer policy utilization requirements in the case of transfers from another RIR to a recipient of a legacy resource transfer in the RIPE region.” Point 2 is plainly incorrect. Please take this as feedback that this should be removed from any policy proposal. The truth is that utilization requirements apply only to inbound transfers from ARIN, and those transfers are treated the same whether legacy status or not. Regards, Mike Burns IPTrading. From: denis walker <ripedenis@gmail.com<mailto:ripedenis@gmail.com>> Sent: Thursday, October 30, 2025 4:30 PM To: Antonis Chariton <daknob@daknob.net<mailto:daknob@daknob.net>> Cc: address-policy-wg@ripe.net<mailto:address-policy-wg@ripe.net>; peter.hessler@zayo.com<mailto:peter.hessler@zayo.com>; Wade, Clara <clarawad@amazon.com<mailto:clarawad@amazon.com>> Subject: [address-policy-wg] Re: Early Feedback Requested on Upcoming Policy Proposal: Clarifying the non-transferability of legacy status Hi Antonis Maybe I am missing something here. But all I am hearing is: LEGACY-GREED LEGACY-MONEY LEGACY-PROFIT LEGACY-LOW SECURITY LEGACY-ATTRACTIVE TO PEOPLE WHO DON'T WANT TO BE IDENTIFIED Maybe it is time to end any LEGACY special considerations. There is nothing special about LEGACY space. These people were just lucky to be given a huge chunk of address space at a time when people didn't understand the potential or value of addresses. Since then society, technology, internet structures, e-governance have all moved on. We became more organised and structured, Everything has moved on except LEGACY holders. Maybe it is time we had one simple rule. ALL address space usage must be registered and managed in the same way, with an RIR, regardless of how you acquired it. You say this will force LEGACY holders to operate outside of the RIR system. What if all the RIR members blocked all addresses that are not properly registered (with one of the RIRs) and accountable? I have no operator experience so I don't know if it is technically (or politically / financially) possible to shut out ALL un-registered address space. If it is, I think we should do it. Have one last showdown. Join the club or stay out in the cold. I don't want your insecure, unaccountable customers connected to my internet. I am not an operator or routing expert, so I may be talking complete rubbish here. But I think you understand the principle I am suggesting. Maybe someone more knowledgeable can outline if/how we can collectively shut out LEGACY space if they refuse to join the club? There is of course another path that may be forced onto LEGACY holders and the RIRs...legislation. LEAs are getting more involved now in registry activities. While they have one foot in our camp, maybe their other foot is in the legislators camp. Especially the European Commision (EC). Operators no longer have full control over operations. Some of the LEGACY space is trying to operate outside of 'the system'. In an area where they are less accountable and they may attract 'undesirable' customers who are not easy to identify or locate. I suspect the timespan for the RIPE community to sort this out is shrinking. Look at some of the legislation that has come from the EC in recent years. Things like the e-evidence act. They have adopted ways of spreading the impact of their legislation beyond the borders of the EU. Another thought came to mind. I have never seen one of these agreements under which LEGACY holders were 'given' this address space. Do these agreements say that the terms and conditions are transferable? Can someone who 'buys' LEGACY space legitimately claim to 'own' it under the same conditions as the previous owner? Just a few thoughts... cheers denis On Thu, 30 Oct 2025 at 17:53, Antonis Chariton via address-policy-wg <address-policy-wg@ripe.net<mailto:address-policy-wg@ripe.net>> wrote: Thanks for the quick response Clara! Perhaps my feedback was not too clear, no worries :) — Existing resource holders will indeed keep their status, but I see a couple of things here: 1) When / if you transfer IPv4 you’ll be faced with a decision (and I guess most people will choose the status over RPKI) 2) When / if the charging scheme changes and doesn’t take the status into account (e.g. legacy counts towards the tier / membership fee) people will cancel the RIPE NCC legacy agreement (and just lose IRR / RPKI) The only reason I brought up #2 here, despite it not being related to your policy proposal, is that since both are public documents enough entities may connect the dots and realize that their legacy status is far more valuable than before. I’d argue that this current proposal increases the value of legacy, especially when combined with a new charging scheme. I hope that’s clearer now. Finally, in my experience at least, money is always a good reason to follow anti-patterns :( It’s true that there’s increased risk from IPv4 legacy but I’d argue that for most entities that will be affected this risk is lower than the costs that are or will be associated with it. Legacy cannot (easily?) be touched today by RIRs (we can only make the holders’ life more difficult) while PA is far more “vulnerable” to new policies and changes. PA also carries some risk at the end of the day and comes without any warranty. Antonis On 30 Oct 2025, at 17:38, Wade, Clara via address-policy-wg <address-policy-wg@ripe.net<mailto:address-policy-wg@ripe.net>> wrote: Antonis, Thanks for taking the time to provide feedback. It seems there’s a misunderstanding here. This policy proposal is forward-looking. We are not going to attempt to backfill/retrofit this change as we are trying to reduce overhead for the NCC, not generate more. We are simply trying to close a loophole that keeps getting exploited. As I mentioned in my response to Dominik, changing the holdership without going through due process is an anti-pattern and it also goes explicitly against the RIPE NCC process for legacy resource transfers outlined here: https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/transfer-of-ip-addresses-and-as-numbers/legacy-resources/<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ripe.net_manage-2Dips-2Dand-2Dasns_resource-2Dtransfers-2Dand-2Dmergers_transfer-2Dof-2Dip-2Daddresses-2Dand-2Das-2Dnumbers_legacy-2Dresources_&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=8HXWKAES8qv8aCy_hbszPEUvLmmOuFEEX3sDyVHhRhY&m=iPrYsbWzGEKOCyFCLAte9zZfMaFib9We0VmuFw4yhpT2uMySV9uZM2H_EkDLQeoG&s=ljnEUx6OKBT9usIbwXVgYxav_t5s-ErsNqbzgZs298o&e=> As I said before, hopefully, anyone engaging in these practices understands the risks they are assuming (for them and their customers if they are a service provider) by doing so. I would hope the community strives to build reliable networks rather than go against database accuracy and routing security best practices to avoid paying very reasonable registration service fees to safekeep important resources (especially in the case of most organizations where they do not pose a material cost). Thank you, Clara From: Antonis Chariton <daknob@daknob.net<mailto:daknob@daknob.net>> Date: Thursday, October 30, 2025 at 11:06 AM To: "address-policy-wg@ripe.net<mailto:address-policy-wg@ripe.net>" <address-policy-wg@ripe.net<mailto:address-policy-wg@ripe.net>> Cc: "Wade, Clara" <clarawad@amazon.com<mailto:clarawad@amazon.com>>, "peter.hessler@zayo.com<mailto:peter.hessler@zayo.com>" <peter.hessler@zayo.com<mailto:peter.hessler@zayo.com>>, Max Emig <ripe@emigm.ax<mailto:ripe@emigm.ax>> Subject: RE: [EXTERNAL] [address-policy-wg] Early Feedback Requested on Upcoming Policy Proposal: Clarifying the non-transferability of legacy status CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. Hello everyone, Although I’m not an expert in this area I’d also like to voice my agreement with Max’ point. Due to the nature of legacy IPv4 and ASes there’s no requirement for registration or notification of an RIR as far as I understand. That said, any sale can be conducted with a single contract between two parties and nobody is required to know about it. As far as I see it, these holders will face the following dilemma: RIPE IRR + RPKI or lower membership fees and retaining this status / flexibility. I think for most organizations the choice will be clear and they’ll choose the second, with the database slowly drifting away from the truth and fewer spaces being covered by ROAs. If someone has or buys an IPv4 /16 they’ll probably choose to opt-out of higher membership fees and will be fine losing a ROA or using RADB / ALTDB. This will also affect IXPs and other heavy users of IRR as more members / customers will require something in addition to RIPE’s database. If more and more entities start requesting the use of non-RIR sources of route objects this will undo progress for routing security. Finally, I expect that such policy can affect any votes for the proposed charging scheme that you’ve been working hard for all this time. Legacy blocks are usually larger and they will increase the cost / tier of someone significantly, making them naturally opposed to this change even if they believe it’s the right direction. Based on what Randy suggested and Marco’s information about the resources we spend I think keeping everything the same between LIRs and adding a transfer fee paid once as Capex / acquisition cost when e.g. the recipient is not an LIR would probably work better. If a fee cannot be applied, I’d also explore the possibility of only allowing inter-LIR transfers which means that either or both parties would have to create an LIR and the setup fee would more than cover the cost of the transaction, even if it’s only kept for a year and we get 1'000+1'800 = 2'800 EUR. That’s probably less than 1 EUR / address, reusable within the calendar year, and could cover the 0.5 FTE. I understand that a legacy-free world would simplify things for everyone, especially RIPE, and it sounds more fair, but we need to model the impact of every policy like this one realistically. Are we certain that RPKI is that good and worth the large cost we plan to impose? Are we causing harmful side effects by re-increasing the reliance and dependency on data sources we know are not meeting the same quality criteria? My personal belief is that this RIR is investing a lot more than 0.5 / 1 FTE for the benefit of the Internet so even if we treat this as a public service it may still be worth it. As an LIR and IXP member and operator I’d get more value than the cost of leaving everything as is completely. It centralizes some costs to RIPE instead of externalizing them, but economies of scale work here. Do you have any predictions as to which % of transfers or addresses will opt-in to this policy instead of just doing everything outside the RIR world? My expectation is that most transfers will opt-out at no cost to them and probably > 1 FTE worth of cost across all LIRs or IXPs / providers outside our service region. Antonis On 30 Oct 2025, at 16:17, Max Emig via address-policy-wg <address-policy-wg@ripe.net<mailto:address-policy-wg@ripe.net>> wrote: Hi Clara, a large Tier 1 carrier in the ARIN region did not update the ARIN Whois in 20 years and did not offer RPKI ROA until very recently over legal concerns and maintained their own whois along with the non-authoritative RADB. I would like to avoid any situations where organisations would have to choose between RIPE DB accuracy and routing security using RPKI ROA and legal-risks regarding out-of-region use among other concerns. Thanks Max On 30 October, 2025 15:29 CET, "Wade, Clara" <clarawad@amazon.com<mailto:clarawad@amazon.com>> wrote: Hi Max, I’m a little confused by the counter-argument here. Could you clarify how you believe this proposal would this lead to out-of-date data and less RPKI adoption? 1. Keeping legacy status when the resources are no longer held by the organization that received these pre-RIR administration is not really keeping the database accurate/up-to-date. 2. Legacy resource holders by default do not have access to RPKI. (You may get access by signing an agreement with the NCC, but unless you do, RPKI services are not included in the basic package offered to legacy resource holders who are not members.) Thank you, Clara From: Max Emig <ripe@emigm.ax<mailto:ripe@emigm.ax>> Date: Wednesday, October 29, 2025 at 4:54 PM To: "Wade, Clara" <clarawad@amazon.com<mailto:clarawad@amazon.com>> Cc: "address-policy-wg@ripe.net<mailto:address-policy-wg@ripe.net>" <address-policy-wg@ripe.net<mailto:address-policy-wg@ripe.net>>, "peter.hessler@zayo.com<mailto:peter.hessler@zayo.com>" <peter.hessler@zayo.com<mailto:peter.hessler@zayo.com>> Subject: RE: [EXTERNAL] [address-policy-wg] Early Feedback Requested on Upcoming Policy Proposal: Clarifying the non-transferability of legacy status CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. Good evening all, I oppose this policy proposal as it may lead to an increase on out-of-date data and less RPKI adoption. However, I would support adding a fee or another disincentive for keeping legacy status. Thanks Max On 27 October, 2025 17:12 CET, "Wade, Clara via address-policy-wg" <address-policy-wg@ripe.net<mailto:address-policy-wg@ripe.net>> wrote: Hello everyone, Following the suggestion of the RIPE NCC, we are seeking early feedback on an upcoming policy proposal we currently have in draft status. As mentioned last week after the Registration Services update from Marco at the AP-WG session - Peter Hessler and I, members of the now concluded Charging Scheme Task Force, are drafting a policy proposal to clarify the non-transferability of legacy status to address the issues of increasing overhead for the RIPE NCC, increasing market speculation around a scarce resource and its impact on the adoption of best practices like RPKI. Our proposal will modify these existing policies: 1. “RIPE Resource Transfer Policies” (RIPE-807) with additional clarifications in the Transfer Restrictions section and the Inter-RIR policy section. M&A/org restructuring transfers will be explicitly excluded. 2. “RIPE NCC Services to Legacy Internet Resource Holders” (RIPE-639) with modifications to remove the language implying new holders can keep legacy status after transfer. For background, legacy status was meant to indicate when an Internet resource had been directly assigned to the holder by IANA, before the RIRs were established. As such, ARIN, LACNIC and AFRINIC policies dictate that IPv4 legacy resources will no longer be regarded as legacy resources after a policy transfer takes place (excluding M&A transfers). RIPE is the only RIR that currently allows the recipient of a legacy transfer the ability to inherit the legacy status that was assigned to the original holder by IANA. This is currently being used as a loophole by certain actors to opt out of having a contractual relationship with the RIPE NCC in order to circumvent: 1. RIPE registration services fees. 2. The 24-month transfer lock that was introduced by this working group to prevent flipping of scarce resources. 3. Needs-based inter-RIR transfer policy utilization requirements in the case of transfers from another RIR to a recipient of a legacy resource transfer in the RIPE region. Following the publication of the Report of the RIPE NCC Charging Scheme Task Force, the membership learned that the RIPE NCC currently needs to dedicate a 0.5FTE to process legacy transfers. There are currently around 2,400 legacy resources held by 1,600 holders with no contractual relationship with the RIPE NCC (neither direct nor via a sponsor). That is around 40M IPs total or 5% of RIPE IPv4 space. In the last four years, NCC staff have processed between 370-280 legacy transfers per year, of which roughly a third do not involve a party with a contractual relationship with the NCC. Legacy transfers are more labor-intensive than other transfer types because the due diligence process requires the Registration Services team to manually source and verify pertaining documentation without the benefits of the automated processes for standard allocations. Legacy transfers take an average seven working hours to process when neither party has a contractual relationship with the NCC (around a third of legacy transfers), and six working hours to process when the parties have a contractual relationship with the NCC. If resources lost their legacy status after a transfer, these would then become standard allocations and staff could leverage enhanced compliance checks and automated processes to facilitate any future updates/transfers. These just take 1-3 working hours to process instead. Given that the task force was deemed out of scope for a policy change to address this gap, this is being brought to the attention of the Address Policy Working Group for action. If there are any concerns, questions or considerations you would like to bring up before we submit this proposal for discussion in the next week or two, we would really appreciate hearing from you so we can address these and/or incorporate them. Thanks in advance, Clara Wade ----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/address-policy-wg.ripe.net/<https://urldefense.proofpoint.com/v2/url?u=https-3A__mailman.ripe.net_mailman3_lists_address-2Dpolicy-2Dwg.ripe.net_&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=8HXWKAES8qv8aCy_hbszPEUvLmmOuFEEX3sDyVHhRhY&m=iPrYsbWzGEKOCyFCLAte9zZfMaFib9We0VmuFw4yhpT2uMySV9uZM2H_EkDLQeoG&s=gwIuOvsfL9o6eBToS0VCzFU3_0zxHsQO7knSPCkmJzw&e=> 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/<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ripe.net_membership_mail_mailman-2D3-2Dmigration_&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=8HXWKAES8qv8aCy_hbszPEUvLmmOuFEEX3sDyVHhRhY&m=iPrYsbWzGEKOCyFCLAte9zZfMaFib9We0VmuFw4yhpT2uMySV9uZM2H_EkDLQeoG&s=b43tZG1n9F6SvJpgwD6ZqSO6GXM1XQUSYDFrnWRaCb4&e=> ----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/address-policy-wg.ripe.net/<https://urldefense.proofpoint.com/v2/url?u=https-3A__mailman.ripe.net_mailman3_lists_address-2Dpolicy-2Dwg.ripe.net_&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=8HXWKAES8qv8aCy_hbszPEUvLmmOuFEEX3sDyVHhRhY&m=iPrYsbWzGEKOCyFCLAte9zZfMaFib9We0VmuFw4yhpT2uMySV9uZM2H_EkDLQeoG&s=gwIuOvsfL9o6eBToS0VCzFU3_0zxHsQO7knSPCkmJzw&e=> 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/<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ripe.net_membership_mail_mailman-2D3-2Dmigration_&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=8HXWKAES8qv8aCy_hbszPEUvLmmOuFEEX3sDyVHhRhY&m=iPrYsbWzGEKOCyFCLAte9zZfMaFib9We0VmuFw4yhpT2uMySV9uZM2H_EkDLQeoG&s=b43tZG1n9F6SvJpgwD6ZqSO6GXM1XQUSYDFrnWRaCb4&e=> ----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/address-policy-wg.ripe.net/<https://urldefense.proofpoint.com/v2/url?u=https-3A__mailman.ripe.net_mailman3_lists_address-2Dpolicy-2Dwg.ripe.net_&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=8HXWKAES8qv8aCy_hbszPEUvLmmOuFEEX3sDyVHhRhY&m=iPrYsbWzGEKOCyFCLAte9zZfMaFib9We0VmuFw4yhpT2uMySV9uZM2H_EkDLQeoG&s=gwIuOvsfL9o6eBToS0VCzFU3_0zxHsQO7knSPCkmJzw&e=> 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/<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ripe.net_membership_mail_mailman-2D3-2Dmigration_&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=8HXWKAES8qv8aCy_hbszPEUvLmmOuFEEX3sDyVHhRhY&m=iPrYsbWzGEKOCyFCLAte9zZfMaFib9We0VmuFw4yhpT2uMySV9uZM2H_EkDLQeoG&s=b43tZG1n9F6SvJpgwD6ZqSO6GXM1XQUSYDFrnWRaCb4&e=>
participants (2)
-
Brander Group -
Wessel Sandkuijl