Hi all, I want to address the underlying logic behind this proposal, because several arguments being used to justify a policy change actually demonstrate something else. The data about processing times and the 0.5 FTE burden are symptoms of a process that has not been modernized. They are no evidence that the policy itself is flawed.
We have seen this dynamic before. The workflow for legacy transfers still resembles something from the 1990s, where everything relied on manual checks, email loops, and individual hostmasters. The operational Internet has long since evolved into an automated environment. Yet here we are trying to solve process gaps with policy restrictions instead of technology. That approach does not move the community forward. Marco confirmed that manual provenance checks and fragmented historical documentation create an additional workload. This is precisely the type of work that disappears once resources are onboarded into standardized and automated processes. Gaps in onboarding and documentation primarily drive the lengthy processing time for legacy cases. Once a resource is fully onboarded, it behaves exactly like any other allocation. This shows clearly that the bottleneck is procedural, not policy-based. It is worth recognizing that RIPE NCC has already taken meaningful steps in the right direction. The new fully automated process for ending PI sponsorship shows that automation can reduce workload while improving accuracy. This is exactly the mindset we should encourage, and it would be great to see the same approach applied to legacy onboarding and transfers. Multiple people in this thread have raised legitimate concerns that this proposal would effectively push transfers off the registry altogether. If that happens, we lose accuracy in the RIPE Database, we lose RPKI coverage, and we increase reliance on non-authoritative IRRs. That is real harm to routing security. Trying to close loopholes by tightening restrictions may feel tidy, but it ignores predictable side effects. Regarding John Curran’s comment about ARIN providing basic services to legacy holders, I do not think ARIN’s model should be held up as a success story. ARIN’s strict transfer and needs-based environment has created prolonged processing timelines, significant procedural friction, and one of the most burdensome governance models in the RIR system. I do not think that is something the industry should replicate or admire, and I hope RIPE does not follow that path. If the goal here is to reduce NCC workload, then the answer is obvious. It is automation, not new restrictions, not rebranding resources, and not creating incentives for people to avoid the registry altogether. Modernizing the legacy transfer workflow with the same automated checks used for standard resources would eliminate most of the processing burden without compromising transparency or routing security. Before moving this proposal forward, I strongly recommend that the working group step back and evaluate what a fully automated legacy onboarding and transfer model looks like, and how it can preserve accuracy without pushing operators into the shadows. Policy should not replace engineering. Policy should enable it. One final point, Clara. You mentioned that legacy status is being used as a loophole to increase market speculation. Can you provide concrete evidence for this statement? Before the community proceeds, we need to see the specific data or cases that clearly show legacy space being used as a speculative instrument. Best regards, Vincentas Grinius IPXO
----- 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/
