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
Fri Sep 1 03:10:26 UTC 2017

On 31 August 2017 at 23:18, Noah <noah at> wrote:
> On Thu, Aug 31, 2017 at 12:39 PM, Alan Barrett <alan.barrett at>
> wrote:
>> > On 25 Aug 2017, at 16:02, Noah <noah at> 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]
> [2]
> _______________________________________________
> RPD mailing list
> RPD at
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
e: d.hilario at

More information about the RPD mailing list