[rpd] Inter-RIR transfer Policy

[Jaco Kroon]

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/20201022/5deddfe3/attachment.html>