Search RPD Archives
Limit search to: Subject & Body Subject Author
Sort by:

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

David Hilario d.hilario at laruscloudservice.net
Fri Sep 1 07:52:49 UTC 2017


On 1 September 2017 at 09:51, Noah <noah at neo.co.tz> wrote:
>
>
>
>
> On 1 Sep 2017 6:13 a.m., "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.
>
>
> The RSA is not a permanent legal document and its subject to changes based
> on policies implemented by the community.
>

No documents are permanent, no rules are permanent.

RSA is a legal document defining the rules for AFRINIC Ltd, it is not
a community document, it honestly should not be touched unless we
really have to.
It is a members document, but not a community one.

Leaving it open for changes whenever a policy change is made is just
asking for trouble.

> Ref: transfers, the current RSA prohibited them accept for
> mergers/acquisitions.
>
> The suggestion is for the updated RSA to only deal with recently ratified
> intra-transfer policy ref: IPv4 transfers.
>

So not fixing the problem at hand and with your suggestion further
perpetuating the problem.

> If in future new policies come along, then changes should be made to the RSA

So knowingly leaving future point of conflict in the RSA?
Basically, leaving any resource management related part of the RSA is a
potential conflict with any current or future policies.


> then without introducing misinterpretations and loopholes.

What "misinterpretations"?
What "loopholes"?

RSA is the legal document to pay money to AFRINIC, why should that
document have any resource management rules in it?



>
> Cheers,
> Noah


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



More information about the RPD mailing list