[rpd] Inter-RIR transfer Policy

[Mike Burns]

Hi Jaco,

 

I understand these policies and use them in my business.

Your understanding of legacy status is incorrect in number 2 below, but in general you are correct that each RIR prescribes only its own actions.

The other RIRs do not specify in their inter-regional transfer policies whether legacy status is to be retained on outbound transfers.

They only specify whether addresses received into their RIR require a change in that status, or to be brought under contract.

So AFRINIC could say any addresses received lose their legacy status and that won’t change the reciprocity anywhere.

Likewise AFRINIC could say any addresses received retain legacy status and that won’t change the reciprocity anywhere.

 

The only concern about reciprocity related to the requirement that the recipient be a member of an RIR. This language is not required in an inter-regional transfer policy because some resource holders are not in fact members of an RIR. It’s best that AFRINIC leaves the dealings with recipients outside the region to the recipient RIRs.  AFRINIC needs only concern itself with how it treats addresses received into AFRINIC.

 

This still leaves the other RIR requirements for reciprocity, but this issue has really meant, in practice, that RIRs with a needs-test in place do require a needs-test by the receiving RIR. This means for inter-rir transfers into RIPE, a needs test is applied even though needs-tests are not required for RIPE intra-regional transfers. The needs test also applies for legacy addresses transferred into RIPE. All other RIRs already have a needs-test for received addresses.

 

Regards,

Mike Burns

IPTrading.com

 

 

From: Jaco Kroon <jaco at uls.co.za> 
Sent: Thursday, October 22, 2020 6:16 AM
To: rpd at afrinic.net
Subject: [rpd] Inter-RIR transfer Policy

 

Hi All,

My understanding of the reciprocity issue is limited.

I believe that's the big concern.  Can someone else that understands the policies from the other RIRs please confirm my understanding of the below.

1.  Transfers are only allowed if the policies are reciprocal (in other words, transfers can happen in both directions, and it's possible to comply with both policies as at the time of transfer, in a manner of speaking).

2.  Other RIRs (ARIN as I understand) allow legacy space to retain legacy status, and as such, in order to allow outbound transfers of legacy space to those RIRs we must allow those transfers to retain legacy status.

3.  We cannot prescribe process to other RIRs, and we leave the actual process of handling the transfers to staff (in other words, we shall not prescribe HOW to do the transfers, but merely WHEN it should be permitted and the CONDITIONS of transfer that must be enforced). Resulting in:

4.  Donor (source of resources) must comply with the policies of the donating RIR.

5.  Recipient of resources must comply with the policies of the receiving RIR.

6.  Other stuff I missed.  But given the below don't particularly care about.

In the current CPM 5.7 deals with IPv4 Resources transfer within the AFRINIC region.

I believe the simplest would be to retain exactly that policy, with the following changes.

5.7 - title change to:  IPv4 Resources transfers where one of the source or recipient entity is an AFRINIC member.

We change 5.7.3 from "Conditions on the source of the transfer" to:

5.7.3 Conditions on the source of the transfer where the source is an AFRINIC member

Similarly 5.7.4 changes from "Conditios on the recipient of the transfer":

5.7.4 Conditions on the recipient of the transfer where the recipient is an AFRINIC member

5.7.2 must by implication go away/be amended since both the source and recipient now need not be an AFRINIC member.  This currently reads: 

5.7.2 IPv4 resources to be transferred - must be from an existing AFRINIC member's account or from a Legacy Resource Holder in the AFRINIC service region

I suggest this:

5.7.2 Both the source and recipient of the transfer must be members of a RIR as recognised by IANA, in compliance with the policies of the relevant RIR, such that at least one of the entities involved in the transfer is an AFRINIC member.  Alternatively the source can be Legacy Resource Holder.

5.7.2.1 In the case where one of the source or recipient entity is a member from another RIR, transfers are only possible where that RIR has a reciprocal policy in place enabling the transfer, and the entity is in full compliance with the policies of the RIR involved.

Are Legacy Resource Holders considered members?  In which case the above can be simplified further still.

It's clear that with that simple change, all of our requirements are on our own members only, reciprocity sorted as far as I can tell, since we only impose conditions on the source if the source is an AFRINIC member, and similarly for recipients.  The legacy issue is under recipient, as such, legacy status being maintained is only enforced in the case where the *recipient* is an AFRINIC member.

There cannot be reciprocity issues (that I can envision) with the above since we're not placing any constraints on the members of other RIRs other than the source must be a member of the source/recipient RIR by implication of complying with the policies of said RIR.

The only issues could be if outbound transfers are to an RIR that implies conditions on the source of a transfer where the source is an AFRINIC member, and we're not enforcing same, but a transfer would still be possible if the source happens to comply with those terms in the recipient RIR.

Similar for inbound if conditions are imposed by the source RIR on the recipient that we're not enforcing (eg, if ARIN states that for resources that's currently considered legacy the recipient RIR must still consider it legacy, but the wording above would still permit majority of transfers, just not legacy resources from the ARIN region).  I can however not imagine that ARIN should be permitted to enforce legacy status such as expressed here.

Yes, I realise this is potentially yet another proposal.  It's not a proposal yet.  Happy to make it one, but I'd prefer to not do that unless feedback I get from the ML in response to this indicates that it's a suitable solution, and even then I'd prefer to get feedback from authors of existing proposals indicating that this covers all concerns from them that they're addressing/trying to address.

No, this was written very much out of hand on impulse and I really should spend some time this evening reading thoroughly through all three the other proposals either way.

Would still like feedback as I believe the above is actually very simple, very effective, and since it really doesn't change anything, I don't foresee a lot of controversy unlike everything else currently on the table.  If there is, I'll happily retract if we can show similar simplicity on one of the other proposals that achieve the same.

Kind Regards,
Jaco

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20201023/819eefb4/attachment.html>