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