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 <[email protected]> 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/ ----- 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/
