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
-----
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/
