Re: Early Feedback Requested on Upcoming Policy Proposal: Clarifying the non-transferability of legacy status
Hi All, I'm a bit perplexed about whether or how much this proposal would actually do much to lessen RIPE's workload. Marco wrote:
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."
Correct me if I'm wrong, but it seems that if a legacy holder with no contract transfers space to another legacy holder who wants no contract, as current policy allows, we might expect long processing times since RIPE must, to some degree, vet the recipient for the first time. If this policy were in effect, we have the case where a new contract must be signed by the recipient (no more legacy status), but this also incurs longer processing times, so in this case I don't see any workload savings. Now if, under current policy, a recipient of a legacy transfer with no contract later decided to transfer the space elsewhere, I would expect the initial vetting of the recipient of the first transfer would extend so it wouldn't require RIPE to start from scratch in vetting them as the source of the 2nd transfer. I guess in principle it's possible the RIPE workload would be greater if the same space were being transferred over and over again to different, new, unvetted recipients who would keep the space as legacy. Is this something we could get some statistics on? Are there a significant number of cases where the same legacy space is churned over and over again to different recipients who all need to be vetted by RIPE, or are these just fringe cases? Otherwise, it seems the policy doesn't do much to mitigate the higher "legacy workload". Regarding RPKI and its cost-load, ARIN chose the path of requiring legacy holders to sign a Registration Services Agreement and relinquish legacy status to receive RPKI services. While this incentivizes entities to become ARIN members and reduces the amount of legacy space out there, it also incentivizes legacy holders who wish to remain legacy holders to forego RPKI entirely, reducing RPKI adoption. RIPE chose the path of allowing legacy holders to adopt RPKI without foregoing legacy status, as long as they enter into a contractual agreement with RIPE, generally as a member or via a sponsoring LIR. So they pay the same fees to receive the service as non-legacy holders, but aren't dissuaded by being forced to give up their legacy status. I think the current system strikes the perfect middle-ground in encouraging legacy holders to adopt RPKI and to pay for it. Finally, I agree with Niall's comment that "clarifying" should not be the operative word in the proposal's title. It implies that this policy was RIPE's actual intent when it formulated the rules governing legacy transfers, but I don't think that's the case at all. For these reasons, I'm opposed to the policy as written. Best Regards, Tom Fantacone
On Nov 17, 2025, at 10:16 AM, Tom Fantacone via address-policy-wg <address-policy-wg@ripe.net> wrote: ... Regarding RPKI and its cost-load, ARIN chose the path of requiring legacy holders to sign a Registration Services Agreement and relinquish legacy status to receive RPKI services. While this incentivizes entities to become ARIN members and reduces the amount of legacy space out there, it also incentivizes legacy holders who wish to remain legacy holders to forego RPKI entirely, reducing RPKI adoption. I’d like to take a moment to clarify ARIN’s handling of legacy resource holders over time, as I’ve heard occasional confusion and want to ensure everyone is working from the same base of background information. ARIN was formed as the successor registry for the number registry services previously performed by the InterNIC (which at the time was operated by Network Solutions, Inc. under a cooperative agreement with the US National Science Foundation.) When ARIN was established, it was agreed that organizations already holding number resources in the registry would continue to receive registry services without the need to enter into an agreement or pay fees. Going forward, however, the registry would operate on a contractual, cost-recovery basis, with parties receiving new number resources entering into a services agreement and paying associated fees. On ARIN’s first day of operation, therefore, zero percent of the number resources in the registry were under agreement, and they were all considered to be “legacy number resources” – defined as the number resources in the registry held by organizations at the time ARIN’s formation, and again with the understanding being that those organization would continue to receive registry services from ARIN for those resources without fee or contract. For legacy resource holders that undergo mergers or acquisitions, ARIN continues to provide their legal successor with these basic registry services for their legacy resources without fee or contract. For resources transferred to others, they are not legacy number resources since they no longer held by the organization that was receiving registry services at the time of ARIN’s formation. ARIN created a version of its Registration Services Agreement, the LRSA, with more favorable terms and fees, and has always encouraged legacy resource holders to bring their resources under agreement. ARIN operates the entire registry according to community-developed policy, so in the ARIN region there is no difference in policy application between resources under agreement and those without; i.e. having a registry services agreement simply provides contractual certainty regarding rights, services, and fees that a legacy resource holder might otherwise lack. The LRSA was similar to the RSA, but the earliest versions of these agreements were quite conservative due to the fledgling nature of the registry. This posed little difficulty for organizations that received resources directly from ARIN, but some legacy holders – whose resources originated from ARIN’s predecessor registries – found certain terms to be an impediment to entering an agreement. Over time, as the Internet number registry system matured, ARIN released successive versions of both the RSA and LRSA with more customer-friendly terms, ultimately harmonizing them into a single agreement (RSA Version 12.0 / LRSA Version 4.0) effective 7 October 2015. Throughout this period, the ARIN Board of Trustees has consistently maintained that all legacy resource holders continue to receive the same basic services – including update of registry records via ARIN Online, Whois/RDAP publication, reverse DNS, and related functions – but that organizations wishing to access advanced services whose development has been funded by the community (such as RPKI) should enter into an agreement and pay fees like any other organization benefiting from those services. Even this principle was generally not contentious and many legacy resource holders brought their resources under agreement. However, some legacy holders remained concerned about specific RSA provisions that did not align with their particular view of their rights in their legacy number resources, particularly when combined with the inability to revert to a prior “uncontracted” state if ARIN were to make some adverse fee, service, or policy changes in the future. ARIN made additional refinements in subsequent RSA versions, culminating in Version 14.0 – released on 15 August 2025 – which addresses many of these long-standing concerns, including a provision allowing for return to prior uncontracted status as a result of an adverse change at the registry. We have since seen a dramatic increase in legacy resource holders choosing to bring their resources under agreement, and at this point more than 93 percent of the number resources in the ARIN registry are under agreement. None of the above should be construed as a statement in favor or opposed to any policy or practice in the RIPE region, but rather just an attempt to provide a common foundation for informed discourse to the extent that ARIN and our legacy number resource practices should happen to arise… :-) Thanks! /John John Curran President and CEO American Registry for Internet Numbers
participants (2)
-
John Curran -
Tom Fantacone