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