[rpd] Implementation of transfer policy AFPUB-2016-V4-003

[David Hilario]

On 25 August 2017 at 17:02, Noah <noah at neo.co.tz> wrote:
>
> On 24 Aug 2017 3:40 p.m., "Alan Barrett" <alan.barrett at afrinic.net> wrote:
>
> Hi Noah,
>
> I am not a lawyer, and this message has not been checked by AFRINIC’s legal
> adviser.  It’s my understanding of the situation.
>
>
> Hi Alan,
>
> We should  get the Legal Counsel to also look at the matter and advise. Too
> sensitive.
>
>
>
> 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.
>
>
>
> RSA is the contractual agreement which introduce and enforce  policies and
> has clearly solved cases of conflict between itself and policies.
> 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.
>
>
>
> 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.
>
>
> 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.
>
>
>
> 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.
>
>
> 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.
>
> In fact, how is this different from the current situation?
>
> 1. RSA set default rules ( prohibits transfers) and bind members to policies
> 2. Members sign RSA
> 3. RSA states Policies supremacy
> 4. Policy allows  certain transfer (intra region only) and states rules and
> conditions
>
> 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.
>
>
>> If I may, what is the final objective of this exercise?
>>
>> 1. To make the RSA more superior over the policies?
>> 2. To make policies comply to the RSA and keep changing RSA before
>> adopting policies?
>
>
> 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.
>
>
> 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 .
>

That one is actually simple, remove any Internet resources related
content from the out of the RSA, this way you will not conflict with
current and future policies.

> Cheers,
> Noah
>
> _______________________________________________
> RPD mailing list
> RPD at afrinic.net
> https://lists.afrinic.net/mailman/listinfo/rpd
>
David Hilario

IP Manager

Larus Cloud Service Limited

p: +852 29888918  m: +359 89 764 1784
f: +852 29888068
a: Flat B5, 11/F, TML Tower, No.3 Hoi Shing Road, Tsuen Wan, HKSAR
w: laruscloudservice.net
e: d.hilario at laruscloudservice.net