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

Sat Sep 9 05:08:52 UTC 2017

I support this.

Frank

On 9/8/2017 5:48 AM, Owen DeLong wrote:
> 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
> 
> 
> _______________________________________________
> RPD mailing list
> RPD at afrinic.net
> https://lists.afrinic.net/mailman/listinfo/rpd
> 