<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi All,</p>
<p>My understanding of the reciprocity issue is limited.<br>
</p>
<p>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.</p>
<p>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).<br>
</p>
<p>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.<br>
<br>
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:<br>
</p>
<p>4. Donor (source of resources) must comply with the policies of
the donating RIR.</p>
<p>5. Recipient of resources must comply with the policies of the
receiving RIR.</p>
<p>6. Other stuff I missed. But given the below don't particularly
care about.<br>
</p>
<p>In the current CPM 5.7 deals with IPv4 Resources transfer within
the AFRINIC region.</p>
<p>I believe the simplest would be to retain exactly that policy,
with the following changes.</p>
<p>5.7 - title change to: IPv4 Resources transfers where one of the
source or recipient entity is an AFRINIC member.</p>
<p>We change 5.7.3 from "Conditions on the source of the transfer"
to:<br>
</p>
<p><i>5.7.3 Conditions on the source of the transfer where the
source is an AFRINIC member</i><br>
</p>
<p>Similarly 5.7.4 changes from "Conditios on the recipient of the
transfer":</p>
<p><i>5.7.4 Conditions on the recipient of the transfer where the
recipient is an AFRINIC member</i><br>
</p>
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:
<p><strong>5.7.2 IPv4 resources to be transferred</strong> - must be
from an existing AFRINIC member's account or from a Legacy
Resource Holder in the AFRINIC service region</p>
<p>I suggest this:<i><br>
</i></p>
<p><i>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.<br>
</i></p>
<p><i>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.</i></p>
<p>Are Legacy Resource Holders considered members? In which case
the above can be simplified further still.<br>
</p>
<p>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.<br>
</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.<br>
<br>
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.<br>
<br>
Kind Regards,<br>
Jaco<br>
</p>
</body>
</html>