Search RPD Archives
[rpd] Implementation of transfer policy AFPUB-2016-V4-003
Owen DeLong
owen at delong.com
Fri Sep 8 02:48:33 UTC 2017
Wouldn’t it make the most sense for the RSA to eliminate all language referencing
resource management directly and instead include language to the effect of:
This RSA is subject to the community developed consensus policies contained in
the consolidated policy manual which is incorporated here by reference. This
agreement shall be considered amended in accordance to each subsequent change
to those policies and the signatories accept in advance all such amendments
as determined appropriate by the consensus of the community and ratified by
the AfriNIC board.
Please feel free to word-smith or improve upon the general idea above, but I believe
this would create a long-term solution to the issues of the RSA while still preserving
the policy supremacy and keeping the policy control in the hands of the current process.
Owen
> On Aug 31, 2017, at 20:10 , David Hilario <d.hilario at laruscloudservice.net> wrote:
>
> On 31 August 2017 at 23:18, Noah <noah at neo.co.tz> wrote:
>>
>>
>> On Thu, Aug 31, 2017 at 12:39 PM, Alan Barrett <alan.barrett at afrinic.net>
>> wrote:
>>>
>>>
>>>> On 25 Aug 2017, at 16:02, Noah <noah at neo.co.tz> wrote:
>>>> We should get the Legal Counsel to also look at the matter and advise.
>>>> Too sensitive.
>>>
>>> The legal adviser has provided advice to me on many occasions. When I try
>>> to summarise his advice, I may make mistakes in minor details, but I am not
>>> making a mistake about the main point: The current RSA prohibits transfers
>>> (except for mergers and acquisitions), and removing that prohibition will
>>> require changing the RSA.
>>
>>
>>
>> Remove the prohibitions to transfers to allow only specific transfers which
>> are "IPv4 Resources transfer within the AFRINIC Region".
>>
>>
>>
>>>
>>>> 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 policies express the will of the community. The RSA is a legal
>>> agreement. If the will of the community conflicts with the RSA, then the
>>> community will expext the RSA to be changed. That’s what’s about to happen.
>>
>>
>>
>> The changes have to be specific to the will of the community in this case
>> "IPv4 Resources transfer within the AFRINIC Region" and not generic transfer
>> or any other transfers.
>>
>>
>>>
>>>>> 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.
>>>
>>> “This agreement is subject to policies” means “policies can add additional
>>> restrictions”; it does not mean that policies can remove restrictions.
>>
>>
>>
>> I am not sure I understood your statement above and disclaimer: 'as much as
>> am not a lawyer', and others in the community could advice but "subject to"
>> means... conditional and being dependent upon something... see [1] [2]
>>
>> Therefore IMHO, RSA is subject to policies and that would mean in this case,
>> subject to specifically the ratified policies only, and for this case the
>> AFPUB-2016-V4-003 "IPv4 Resources transfer within the AFRINIC Region".
>>
>> So the modification and wording of the updated RSA, ref: transfers , should
>> be specific to this policy to avoid creating loopholes using the word
>> "transfer" as the only tranfers allowed per policy will be
>> Intra/within/inside Afrinic service region and nothing else.
>>
>>
>
> Using this logic, we would still be using the RSA as a resource
> management document and Policy enforcement.
> We would basically never get rid of the initial problem.
>
> The RSA being a legal document and not a community document, it should
> only describe the legal premise of signing up with the AFRINIC and not
> get involved into the resource management.
>
> Implying that removing this restriction would allow inter-RIR transfer
> is a bit far fetched, plus as far as I know, all RIRs have something
> in the lines that they can only do inter-RIR transfers with RIR who
> have a compatible inter-RIR transfer policy, no policy at AFRINIC,
> means no transfers to or from other RIR.
>
> Don't manage resources through the RSA, that would even be
> incompatible with other RIR, manage resources through policies.
>
> Following your logic, we would remain in a perpetual problem, and the
> RSA will be in need of updates at any future policy update that
> touches any resource topics that are in the RSA.
>
>>>
>>>> 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
>>>
>>> But your point 3 does not apply. Perhaps it might be useful to say
>>> something like that in a future version of the RSA, but it’s not in the
>>> current RSA.
>>>
>>
>> Why future versions of RSA. If current is being updated to reflect other
>> changes, then add that there.
>>
>> Cheers,
>> Noah
>>
>> [1] https://definitions.uslegal.com/s/subject-to/
>>
>> [2] http://thelawdictionary.org/subject-to/
>>
>>
>> _______________________________________________
>> 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
>
> _______________________________________________
> RPD mailing list
> RPD at afrinic.net
> https://lists.afrinic.net/mailman/listinfo/rpd
More information about the RPD
mailing list