<div dir="ltr"><div dir="auto"><div><div class="gmail_extra"><br><div class="gmail_quote">On 24 Aug 2017 3:40 p.m., "Alan Barrett" <<a href="mailto:alan.barrett@afrinic.net" target="_blank">alan.barrett@afrinic.net</a>> wrote:<br type="attribution"><blockquote class="gmail-m_-4063606384114029795m_9125788993523277127quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Noah,<br>
<br>
I am not a lawyer, and this message has not been checked by AFRINIC’s legal adviser. It’s my understanding of the situation.<br></blockquote></div></div></div><div dir="auto"><br><div dir="auto">Hi Alan<span class="">,<br><br></span></div></div><div dir="auto">We should get the Legal Counsel to also look at the matter and advise. Too sensitive.<br></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail-m_-4063606384114029795m_9125788993523277127quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
The RSA has a clause that says "this agreement shall at all times be subjected to policies adopted and to be adopted by the AFRINIC Internet Community”. “This agreement” means the agreement between AFRINIC and the member who signs the RSA. The member is bound by the RSA that they signed, and the RSA says that the member is also subjected to the policies, so the end result is that the member must simultaneously follow both the RSA and the policies.<br></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">RSA is the contractual agreement which introduce and enforce policies and has clearly solved cases of conflict between itself and policies.<br>What I am trying to say is that we have to be mindful of the fact that the policies supersede the RSA which depends on them and as much as we members are subjected to the RSA, policies reign supreme.</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail-m_-4063606384114029795m_9125788993523277127quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
The RSA also has a clause that says "except in the event of The Applicant becoming the subject of merger and/or acquisition proceedings, the transfer of number resources is strictly prohibited”. Even if there’s a policy that allows transfers, the RSA prohibits transfers, and the member has agreed to follow the RSA, so the member may not make a transfer.<br></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">This is not valid if the RSA is subject to policies. If policies say member can transfer, then policy overrides any provisions of the RSA with regards to this aspect.<br><br></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail-m_-4063606384114029795m_9125788993523277127quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
The RSA was written at a time when transfers were prohibited, and policies to allow transfers had not even been thought of. It’s now necessary to change the RSA to allow transfers, provided the transfers are done in accordance with policy.<br><br></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">Transfer was not an option and was explicitly prohibited by the RSA to avoid interpretation and dispute and the RSA anticipates future changes while being subject to policies.</div><div dir="auto"><br>In fact, how is this different from the current situation? <br><br>1. RSA set default rules ( prohibits transfers) and bind members to policies<br>2. Members sign RSA <br>3. RSA states Policies supremacy<br>4. Policy allows certain transfer (intra region only) and states rules and conditions<br><br>We must avoid creating loopholes by allowing transfer by default. Opens room for abuses, interpretations and legal disputes by people willing to move resources in the absence of policies.<br></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail-m_-4063606384114029795m_9125788993523277127quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="gmail-m_-4063606384114029795m_9125788993523277127quoted-text"><br>
> If I may, what is the final objective of this exercise?<br>
><br>
> 1. To make the RSA more superior over the policies?<br>
> 2. To make policies comply to the RSA and keep changing RSA before adopting policies?<br>
<br>
<br>
</div>The answer is neither 1 nor 2. The objective is not (1), because members already need to comply with both the RSA and the policies. (Today, the only way they can comply with both is by never making a transfer.) The objective is not (2), because changing the RSA before adopting policies would be an unreasonable amount of work. The objective is to remove a problem in the RSA, and to do so in such a way that future changes in the policies around transfers should not need even more changes to the RSA.<br></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">Can we point out this specific problems so that its clearer, before we work on a fix. Lets look at the Pros and Cons of each scenario and mainly avoid bringing new unnecessary risks .<br></div><div dir="auto"><br></div><div>Cheers,<br></div><div dir="auto">Noah</div></div>
</div>