Early Feedback Requested on Upcoming Policy Proposal: Clarifying the non-transferability of legacy status
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
Hi Clara, all, In my opinion, it will make sense that if you received the resources as legacy and you want to keep that status, you only get the basic set of services, just to keep the registry updated, unless you are a member and pay for the “total set of services”. I know this is a different point but I think it is related and should be mention as well. APNIC resolved that and also a policy proposal that reached consensus allows those recourses to be reclaimed if there is no response from the holder. The ability to transfer should not be part of the “basic” set of services, so clearly, if a legacy holder want to transfer, need to lose the legacy status for those resources, and following the same rationale, members that have signed a contract (for example they need IPv6 or ASN), they should have lost the legacy status of other resources. Regards, Jordi @jordipalet
El 27 oct 2025, a las 17:12, Wade, Clara via address-policy-wg <address-policy-wg@ripe.net> escribió:
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:
“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. “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:
RIPE registration services fees. The 24-month transfer lock that was introduced by this working group to prevent flipping of scarce resources. 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/ 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/
********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
Hi Clara and Peter, I think this is an excellent idea. We need more equality between our integers in my opinion, and while I'm OK with an exemption status for the original legacy holders (after all, they didn't necessarily choose to set up the RIR system and all it entails), I don't think that exemption should be maintained once that space has touched the RIR system (and has incurred cost) by means of a resource transfer. Kind regards Remco van Mook
On 27 Oct 2025, at 17:12, Wade, Clara via address-policy-wg <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:
“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. “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:
RIPE registration services fees. The 24-month transfer lock that was introduced by this working group to prevent flipping of scarce resources. 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/ 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 Clara and Peter, I agree with Remco. Once legacy space relies on RIPE DB resources or adds to the RIPE NCC’s workload, it’s only fair that there’s a contractual relationship and the corresponding NCC fees apply. Regards, Rinse On 10/27/2025 11:25 PM, Remco van Mook wrote:
Hi Clara and Peter,
I think this is an excellent idea. We need more equality between our integers in my opinion, and while I'm OK with an exemption status for the original legacy holders (after all, they didn't necessarily choose to set up the RIR system and all it entails), I don't think that exemption should be maintained once that space has touched the RIR system (and has incurred cost) by means of a resource transfer.
Kind regards
Remco van Mook
On 27 Oct 2025, at 17:12, Wade, Clara via address-policy-wg <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/ 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 Clara and Peter, Thank you for a quick reminder and another opprotunity to have a look at the Charging Scheme Task Force Final Report. It's only now I've realized the time cost differences in resource transfer scenarios, i.e. 75 minutes to process each intra-RIR transfer ticket, 200 minutes for an inter-RIR or M&A transfer, six hours for a legacy transfer between parties with contractual relationships with the RIPE NCC, seven hours for a legacy transfer between parties without contractual relationships. Do 75 minutes for processing an intra-RIR transfer also apply to (cover) PI address resources? It's a fraction of time for what it takes to transfer a legacy resouce even if both parties are already in a contractual relationship with the RIPE NCC. Also seven vs six hours for a legacy transfer between parties without vs with contractual relationship stays away from an inter-RIR or M&A transfer. Is the extra time required for due diligence wrt transfered (legacy) resources? Or other aspects apply to legacy resources that we have to count in. Thank you for your patience and comments. Kind regards, Martin On Mon, Oct 27, 2025 at 04:12:30PM +0000, Wade, Clara via address-policy-wg 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/ 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/
Thank you all for your feedback so far. Martin, great questions. I will let the Registration Services team expand on specifics as these were the average turnaround times that we were provided during the Task Force's review of the NCC's operational burden. In general, there is more automation of due diligence checks that can be leveraged for (1) parties with contractual relationships with the NCC vs no contractual relationship, and (2) for standard resource transfers vs legacy resource transfers. Legacy resources tend to have a longer history and the NCC needs to take the time to review that the proper "chain of title" so to speak is verified and the terms and conditions are followed. Manually obtaining and verifying these documents can take longer if there was no prior record on file, which the NCC needs to make sure the request is coming from the rightful holder of rights to transfer the space and from a recipient that also complies with the due diligence requirements. Best regards, Clara On 10/28/25, 4:00 AM, "Martin Stanislav" <ms@uakom.sk <mailto:ms@uakom.sk>> wrote: 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. Hi Clara and Peter, Thank you for a quick reminder and another opprotunity to have a look at the Charging Scheme Task Force Final Report. It's only now I've realized the time cost differences in resource transfer scenarios, i.e. 75 minutes to process each intra-RIR transfer ticket, 200 minutes for an inter-RIR or M&A transfer, six hours for a legacy transfer between parties with contractual relationships with the RIPE NCC, seven hours for a legacy transfer between parties without contractual relationships. Do 75 minutes for processing an intra-RIR transfer also apply to (cover) PI address resources? It's a fraction of time for what it takes to transfer a legacy resouce even if both parties are already in a contractual relationship with the RIPE NCC. Also seven vs six hours for a legacy transfer between parties without vs with contractual relationship stays away from an inter-RIR or M&A transfer. Is the extra time required for due diligence wrt transfered (legacy) resources? Or other aspects apply to legacy resources that we have to count in. Thank you for your patience and comments. Kind regards, Martin On Mon, Oct 27, 2025 at 04:12:30PM +0000, Wade, Clara via address-policy-wg 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://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/ <https://www.ripe.net/membership/mail/mailman-3-migration/>
In general, there is more automation of due diligence checks that can be leveraged for (1) parties with contractual relationships with the NCC vs no contractual relationship,
then perhaps what you want is that the recipient of legacy resources must register them as a member, juat as a recipient of non-legacy resources does. keep it simple. painting resources new colors is a bit too reminiscent of a bikeshed. randy
Hi Randy, Thanks for your input. While putting the resources under a membership/contract can be a step in the right direction, it still wouldn't address the issues the NCC (and the membership by extension) is dealing with because of this gap. Resources in legacy status, regardless of whether there is a contractual relationship or not, need to undergo a more stringent diligence process for transfers that puts additional burden on the NCC. As Martin brought up earlier, the difference in average processing time between legacy transfers with vs without a contract is just an hour. Aside from this, that solution wouldn't address the issue of multiple organizations repeatedly using this gap in legacy resource and transfer policy to avoid paying the standard registration services rate and skipping the 24-month transfer lock that prevents the flipping of scarce resources, even though they weren't the original holders of the space and are effectively taking up NCC resources repeatedly to get these processed. Unfortunately, this one's not a bikeshed, and it's why Peter and I have taken the time to work on this proposal after it was deemed out of scope for the task force. We'll give the working group a few more days to provide early feedback and post the draft proposal for review soon. Thank you, Clara On 10/28/25, 2:32 PM, "Randy Bush" <randy@psg.com <mailto:randy@psg.com>> wrote: 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.
In general, there is more automation of due diligence checks that can be leveraged for (1) parties with contractual relationships with the NCC vs no contractual relationship,
then perhaps what you want is that the recipient of legacy resources must register them as a member, juat as a recipient of non-legacy resources does. keep it simple. painting resources new colors is a bit too reminiscent of a bikeshed. randy
hi clara as usual, i am a bit confused; yes, a low bar. have sympathy; you have been doing this *far* longer than i. CSTFR sez:
it takes staff an average of 75 minutes to process each intra-RIR transfer ticket, 200 minutes for an inter-RIR or M&A transfer, six hours for a legacy transfer between parties with contractual relationships with the RIPE NCC
looking at table 7, i think we're comparing "RIPE NCC Region Transfers" with "Legacy Updates," whatever the heck they are. i suspect that they are not inter-member transfers of legacy space. as you were on the CSTF, so i hope you remember what these numbers actually measure and could please whack me with a clue bat. Clara:
legacy status, regardless of whether there is a contractual relationship or not, need to undergo a more stringent diligence process for transfers that puts additional burden on the NCC
i naïvely assume that the extra diligence of provenance is incurred once when the space is first registered, e.g. when the holder becomes a member or it is acquired by a member. and that cost would be a one time cost. from then on, why is it not just space with a different paint job? if member A transfers legacy space to member B why the heck would it take significantly more effort than if A transfers non-legacy space to B? can someone from the registry comment? similarly if A transfers legacy space to B as non-legacy, does it really require less effort than if B receives it as legacy space? randy, trying to understand what problems we really need to solve
Hello Martin, Randy, all Please allow me to provide a bit more context regarding the processing times shown in the report of the Charging Scheme Task Force. First, these figures are averages based on samples and experience in Registration Services. Actual cases may be completed faster, or sometimes significantly slower. Second, the four categories mentioned in the Charging Scheme Task Force report cover a range of scenarios, and this grouping creates some cluster effects that can be confusing. For example, policy transfers of PI resources within the RIPE NCC region can involve: - two members, - a member and a non-member - two non-members. Transfers between two members are usually below the average of 75 minutes, while those involving non-members usually take a bit longer, especially when the receiving party is new to the RIPE NCC and additional checks are required. The Legacy Updates group is similar. Randy is correct, updates of legacy resources under contract between two existing members are typically far below the 360-minute average, but they represent only a small portion of this group. The longer processing times mainly occur when a new contract must be signed with the RIPE NCC or a sponsoring member, or when only one party has a contractual relationship. In particular, cases where the offering party has no contract (while the receiving party has or will have one) can take significantly longer, as the RIPE NCC must perform extensive due-diligence checks before the Legacy update can be completed. I hope this clarifies. Kind regards, Marco Schmidt Manager Registration Services RIPE NCC On 29/10/2025 02:05, Randy Bush wrote:
hi clara
as usual, i am a bit confused; yes, a low bar. have sympathy; you have been doing this *far* longer than i.
CSTFR sez:
it takes staff an average of 75 minutes to process each intra-RIR transfer ticket, 200 minutes for an inter-RIR or M&A transfer, six hours for a legacy transfer between parties with contractual relationships with the RIPE NCC looking at table 7, i think we're comparing "RIPE NCC Region Transfers" with "Legacy Updates," whatever the heck they are. i suspect that they are not inter-member transfers of legacy space. as you were on the CSTF, so i hope you remember what these numbers actually measure and could please whack me with a clue bat.
Clara:
legacy status, regardless of whether there is a contractual relationship or not, need to undergo a more stringent diligence process for transfers that puts additional burden on the NCC i naïvely assume that the extra diligence of provenance is incurred once when the space is first registered, e.g. when the holder becomes a member or it is acquired by a member. and that cost would be a one time cost. from then on, why is it not just space with a different paint job?
if member A transfers legacy space to member B why the heck would it take significantly more effort than if A transfers non-legacy space to B? can someone from the registry comment?
similarly if A transfers legacy space to B as non-legacy, does it really require less effort than if B receives it as legacy space?
randy, trying to understand what problems we really need to solve ----- 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, On Tue, Oct 28, 2025 at 10:02:14PM +0000, Wade, Clara via address-policy-wg wrote:
Aside from this, that solution wouldn't address the issue of multiple organizations repeatedly using this gap in legacy resource and transfer policy to avoid paying the standard registration services rate and skipping the 24-month transfer lock that prevents the flipping of scarce resources, even though they weren't the original holders of the space and are effectively taking up NCC resources repeatedly to get these processed.
So this is about resources that *have* a contractual relationship, and are still tagged "legacy", right? Because there's also real pre-RIR legacy resources where no contracts exist, and I wonder why transferring these would incur any activity at the NCC... Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Karin Schuler, Sebastian Cler Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Gert Doering wrote on 01/11/2025 13:05:
Because there's also real pre-RIR legacy resources where no contracts exist, and I wonder why transferring these would incur any activity at the NCC...
They're still registered at the RIPE NCC and receive services:
https://www.ripe.net/manage-ips-and-asns/legacy-resources/ripe-ncc-services-...
Nick
Hi, Thanks for raising this pain point, Clara and Peter. I would love to close the loopholes you outline, and I completely agree that Registry workloads should be charged consistently and fairly to the parties that generate them. I’m in favour of a level playing field when it comes to RIR handling of IP resources in general but alas, we are where we are when it comes to the special case of legacy resources. Registry accuracy is core to the integrity of the RIR system. Potentially incentivising legacy resource holders to remain outside the RIR system or even carry out transfers in an off-registry “shadow market” are risks that we should approach with eyes wide open. To assess the risk properly, I would suggest looking at indicators such as comparing registry vs routing data of top-level legacy (and for context, non-legacy) prefixes to detect unregistered change of ownerships, past legacy transfer behaviour to previous related RIPE engagement or policy changes, and reviewing outcomes and lessons learned from other RIRs that have already implemented this. Such data and insights can help quantify whether the “shadow market” risk is theoretical or real. Similar analysis on other potential side effects such as pushing parties to use unofficial routing databases would be useful too. Also, not retrofitting the change would create a real split and inconsistency between legacy resources\holders of transfers that have occurred before and after this policy change, which I’m not entirely comfortable with. Those already transferred legacy resources\holders will still be free to take advantage of the loopholes you’re (rightfully) aiming to close and potentially avoid future charging scheme fees. Understood backfilling would increase workload for the NCC but estimating the level of effort involved (# of transferred legacy resources to NCC contracted entries and non-contract entities, avg. time for each) would give a fuller picture. Options to contrast and compare: - Leave policy as-is - Proceed with this policy proposal - Hybrid or phased approach (e.g. apply the rule only to legacy → LIR transfers initially, and extend later to legacy → legacy if certain indicators are positive; enforcement (i.e. requiring a contract for transferred legacy space) only begins after say 12 months. During that time, RIPE NCC informs all known legacy holders of the upcoming change and provides easy paths to compliance; all transferred legacy resources automatically lose their legacy status unless the holder appeals and demonstrates some defined justification) - Introduce fees specifically for legacy transfers - Other? What trade-off(s) are we willing to live with? Regards, James kipa.global ---- On Sat, 01 Nov 2025 13:05:10 +0000 Gert Doering <gert@space.net> wrote ---
Hi,
On Tue, Oct 28, 2025 at 10:02:14PM +0000, Wade, Clara via address-policy-wg wrote:
Aside from this, that solution wouldn't address the issue of multiple organizations repeatedly using this gap in legacy resource and transfer policy to avoid paying the standard registration services rate and skipping the 24-month transfer lock that prevents the flipping of scarce resources, even though they weren't the original holders of the space and are effectively taking up NCC resources repeatedly to get these processed.
So this is about resources that *have* a contractual relationship, and are still tagged "legacy", right?
Because there's also real pre-RIR legacy resources where no contracts exist, and I wonder why transferring these would incur any activity at the NCC...
Gert Doering -- NetMaster -- have you enabled IPv6 on something today...?
SpaceNet AG Vorstand: Sebastian v. Bomhard, Karin Schuler, Sebastian Cler Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 ----- 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/
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> 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: * “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. * “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: * RIPE registration services fees. * The 24-month transfer lock that was introduced by this working group to prevent flipping of scarce resources. * 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
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> Date: Wednesday, October 29, 2025 at 4:54 PM To: "Wade, Clara" <clarawad@amazon.com> Cc: "address-policy-wg@ripe.net" <address-policy-wg@ripe.net>, "peter.hessler@zayo.com" <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> 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
Dear Colleagues, I agree with Max. We don't quite have a horse in this race. Clouvider has 1x legacy subnet and is a member of the RIPE NCC regardless. We use it pretty much in the same way as if it was a PA. Clara,
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.
I believe changing the policy will lead to exactly more of 1 - change won't be registered with the NCC in order for the resource not to loose its legacy status. This is significant especially that these changes don't have to be registered in order to be able to use the space - i.e. be creating route objects in alternate DBs. For that reason I oppose the proposal. If this is more of "extra work required" type of issue - then let's solve it by putting the correct price tag on it. Kind Regards, Dominik ________________________________ From: Wade, Clara via address-policy-wg <address-policy-wg@ripe.net> Sent: 30 October 2025 14:29 To: Max Emig <ripe@emigm.ax> Cc: address-policy-wg@ripe.net <address-policy-wg@ripe.net>; peter.hessler@zayo.com <peter.hessler@zayo.com> Subject: [address-policy-wg] Re: Early Feedback Requested on Upcoming Policy Proposal: Clarifying the non-transferability of legacy status 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> Date: Wednesday, October 29, 2025 at 4:54 PM To: "Wade, Clara" <clarawad@amazon.com> Cc: "address-policy-wg@ripe.net" <address-policy-wg@ripe.net>, "peter.hessler@zayo.com" <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> 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
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> 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? * 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. * 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> Date: Wednesday, October 29, 2025 at 4:54 PM To: "Wade, Clara" <clarawad@amazon.com> Cc: "address-policy-wg@ripe.net" <address-policy-wg@ripe.net>, "peter.hessler@zayo.com" <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> 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: * RIPE registration services fees. * 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
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> 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> 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?
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. 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> Date: Wednesday, October 29, 2025 at 4:54 PM To: "Wade, Clara" <clarawad@amazon.com> Cc: "address-policy-wg@ripe.net" <address-policy-wg@ripe.net>, "peter.hessler@zayo.com" <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> 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:
RIPE registration services fees. 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/ 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 Antonis, thanks for your comment. Do not forget that reclaiming IPv4 PA space is nowadays very rare, but not ruled out while legacy space can only be reclaimed if not in use and no organisation holding it exists anymore. @Clara Please excuse the ad-hominem argument here. A100 ROW Inc, a wholly-owned subsidiary of Amazon is by far the largest holder of transferred Legacy IPv4 space (except for the /8 of a German carmaker now owned by its main legal successor) in the RIPE region: https://bgp.tools/rir-owner/us.a100row You can always convert it to PA or PI but you/your company have chosen to keep it as Legacy until now. I would like to here your thoughts why you treat this in a quod licet Iovi, non licet bovi manner. Sincerely Max On 30 October, 2025 17:04 CET, Antonis Chariton <daknob@daknob.net> wrote: 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> 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> 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? * 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. * 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> Date: Wednesday, October 29, 2025 at 4:54 PM To: "Wade, Clara" <clarawad@amazon.com> Cc: "address-policy-wg@ripe.net" <address-policy-wg@ripe.net>, "peter.hessler@zayo.com" <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> 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: * RIPE registration services fees. * 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/ 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/
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/tran... 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> Date: Thursday, October 30, 2025 at 11:06 AM To: "address-policy-wg@ripe.net" <address-policy-wg@ripe.net> Cc: "Wade, Clara" <clarawad@amazon.com>, "peter.hessler@zayo.com" <peter.hessler@zayo.com>, Max Emig <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> 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> 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> Date: Wednesday, October 29, 2025 at 4:54 PM To: "Wade, Clara" <clarawad@amazon.com> Cc: "address-policy-wg@ripe.net" <address-policy-wg@ripe.net>, "peter.hessler@zayo.com" <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> 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/ 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/
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> 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/tran...
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> 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> 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> Date: Wednesday, October 29, 2025 at 4:54 PM To: "Wade, Clara" <clarawad@amazon.com> Cc: "address-policy-wg@ripe.net" <address-policy-wg@ripe.net>, "peter.hessler@zayo.com" <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> 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:
RIPE registration services fees. 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/ 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 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> 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> 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/tran...
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> *Date: *Thursday, October 30, 2025 at 11:06 AM *To: *"address-policy-wg@ripe.net" <address-policy-wg@ripe.net> *Cc: *"Wade, Clara" <clarawad@amazon.com>, "peter.hessler@zayo.com" < peter.hessler@zayo.com>, Max Emig <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> 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> 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> *Date:* Wednesday, October 29, 2025 at 4:54 PM *To:* "Wade, Clara" <clarawad@amazon.com> *Cc:* "address-policy-wg@ripe.net" <address-policy-wg@ripe.net>, " peter.hessler@zayo.com" <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> 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/ 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/
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> Sent: Thursday, October 30, 2025 4:30 PM To: Antonis Chariton <daknob@daknob.net> Cc: address-policy-wg@ripe.net; peter.hessler@zayo.com; Wade, Clara <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://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/tran... 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 < <mailto:daknob@daknob.net> daknob@daknob.net> Date: Thursday, October 30, 2025 at 11:06 AM To: " <mailto:address-policy-wg@ripe.net> address-policy-wg@ripe.net" < <mailto:address-policy-wg@ripe.net> address-policy-wg@ripe.net> Cc: "Wade, Clara" < <mailto:clarawad@amazon.com> clarawad@amazon.com>, " <mailto:peter.hessler@zayo.com> peter.hessler@zayo.com" < <mailto:peter.hessler@zayo.com> peter.hessler@zayo.com>, Max Emig < <mailto:ripe@emigm.ax> 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/ 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/
Antonis Chariton via address-policy-wg wrote on 30/10/2025 16:04:
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.
this is technically correct, but no more than that. If you want DNS or route objects, the registered holder of the address space needs to engage with the RIPE NCC. Obviously an original registered holder could deal with this for a successor, or any level downstream, but this is honestly a nuisance for them.
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.
And DNS, and the ability to issue number resource LOAs.
This will also affect IXPs and other heavy users of IRR as more members / customers will require something in addition to RIPE’s database.
It won't affect IXPs or other organisations which require accurate IRR registration. It will affect the users of the address space if they can't properly route their addresses. If organisations want to self-harm, that's an issue for them, not an IXP. Nick
Max Emig via address-policy-wg wrote on 30/10/2025 15:17:
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.
Max, ARIN declined to provide services to legacy holders unless they signed the LRSA, which many organisations objected to. The RIPE NCC is not in the same situation.
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.
In relation to RPKI, it is not possible to legally attest to the registration of a number resource unless the number resource holder has formally identified themselves to the RIPE NCC, i.e. unless there's a legal agreement in place. In other words, if the Legacy holder doesn't have a contractual relationship with the RIPE NCC, then they don't have RPKI. Can you explain why this would impact transfers? I don't follow your argument. Nick
On Oct 30, 2025, at 4:17 PM, Nick Hilliard <nick@foobar.org> wrote: ARIN declined to provide services to legacy holders unless they signed the LRSA, which many organisations objected to. The RIPE NCC is not in the same situation. Just for sake of clarity, I’d to point out that ARIN does provide basic registration services to all legacy resource holders without fee or agreement – these basic services include registry updates via ARIN Online, Whois/RDAP publication, reverse DNS services including DNSSEC, etc. (Legacy resource holders who wish RPKI and/or authenticated IRR services are indeed required to enter an RSA agreement and pay service fees, just as any other customer. For more details see here - https://www.arin.net/resources/guide/legacy/) Thanks! /John John Curran President and CEO American Registry for Internet Numbers
On 27 Oct 2025, at 16:12, Wade, Clara via address-policy-wg [wrote][]:
Following the suggestion of the RIPE NCC, we are seeking early feedback on an upcoming policy proposal we currently have in draft status.
I have some observations to make, which I think will need attention before or during the passage of the eventual proposal through the PDP. - Language "proposal to clarify the non-transferability of legacy status" in draft seems inappropriate to me. This is an innovation; it should not be disguised as anything else. Perhaps "clarify the" should read "introduce declaration of". - Making this declaration may be at odds with legacy-resource holders' understanding of the rights included in the original grant of the resources. If so, I believe that principled, as well as pragmatic arguments will be needed as a foundation for the proposal. - As others have pointed out, care will be needed to find an appropriate balance between the advantage of unburdening the NCC, and the disadvantage of potentially losing accuracy. - Decomposing the problem, along the lines Randy suggests, seems to be worth doing in order to simplify our discussions. He seems to me to have identified what I call "onboarding" and "transfer" as the main sub-problems. Prompted by the durations mentioned upthread corresponding to different kinds of transfer request, I suggest a slightly more detailed decomposition. * Onboarding (know your customer) of either or both of the intending donor and recipient of the transfer, unless they are already sufficiently known to the NCC; * Onboarding (proof of title) of the legacy resource to be transferred, if this is not already known to the NCC; * The actual transfer. It seems to me that the burdensome elements are the first and second ones mentioned. I also have some disclosures to make as to my interest in this. - Almost my entire career was spent in the employment of a legacy resource holder; I am still on their (pension) payroll. - I was one of the co-authors of RIPE policy proposal 2012-07, accepted on 6 Feb 2014, saved as RIPE document RIPE-605, and subsequently obsoleted by RIPE document RIPE-639. - For the time being, and until I have refreshed my understanding of the relevant existing RIPE policy proposals and documents, I reserve my personal position on this draft and on the eventual policy proposal. I hope this helps. Niall --- [wrote]: https://mailman.ripe.net/archives/list/address-policy-wg@ripe.net/thread/BUI... [2012-07]: https://www.ripe.net/community/policies/proposals/2012-07/ [RIPE-605]: https://www.ripe.net/publications/docs/ripe-605/ [RIPE-639]: https://www.ripe.net/publications/docs/ripe-639/
participants (17)
-
Antonis Chariton -
denis walker -
Dominik Nowacki -
Gert Doering -
James Kennedy -
John Curran -
jordi.palet＠consulintel.es -
Marco Schmidt -
Martin Stanislav -
Max Emig -
Mike Burns -
Niall O'Reilly -
Nick Hilliard -
Randy Bush -
Remco van Mook -
Rinse Kloek -
Wade, Clara