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

[rpd] AFRINIC Number Resources Transfer Policy Policy Proposal: Impact Assessment & Summary of Objections

Gaby Giner gabyginernetwork at
Sat Nov 13 03:22:13 UTC 2021

Hello all,

Honestly this seems like a lot of steps just to transfer resources from one
RIR to another. Since the region currently does not have one, you'd think
this would solve problems but instead this allows for greater AFRINIC
interference in a supposedly interference-free transfer. This is still not
addressed. Additionally, the staff themselves has pointed out glaring vague
and open-ended definitions that should also be addressed. I would
definitely support a policy that has less "interference" with RIR than the
current one.

Sincerely, Gabrielle.

On Sat, 13 Nov 2021 at 02:35, Owen DeLong via RPD <rpd at> wrote:

> On Nov 12, 2021, at 00:21 , JORDI PALET MARTINEZ via RPD <rpd at>
> wrote:
> Hi Chairs, all,
> I’m responding to this email considering the version 7 of the proposal
> (AFPUB-2019-IPv4-002-DRAFT07), which was edited precisely to respond to the
> issues from the impact analysis and inputs from the list. Actually, my
> response and new version had an additional delay, because the IA published
> was from another proposal, so I couldn’t read the IA when I was expecting
> to do it.
> By the way, those emails from the chairs are very useful, however, it will
> be more useful if either plain text or html is used, so then we can respond
> in-line to each of the points. The are images, which make that impossible.
>    1. Regarding the absence of the “hold down”. I was not convinced
>    myself it that’s needed and I double-checked what other RIRs equivalent
>    policies have on that. The only one that has this is LACNIC, and
>    unfortunatelly I don’t recall the discussion (if any) for the need for
>    that. However, I’ve asked the AFRINIC staff for examples about why this may
>    be required and how the abuse may be produced, and I didn’t got any
>    response on that. My rationale is that if there are some resources
>    transferred, and then after weeks or months, the justification for the need
>    dissapear (for example, bussiness model change, or they have deployed IPv6
>    and they need less IPv4 resources), why not those resources can be
>    transferred again? In fact this is good for the community because instead
>    of someone having resources that aren’t being used, someone else could make
>    use of them. So in summary, this observation from the IA is not justified
>    and can’t be considered as a valid objection.
> The bigger concern is speculators who might be buying resources just to
> flip them for profit, much like speculative real estate buyers which have
> been a rather persistent problem in the US housing market.
> Another concern is so long as the free pool persists, there is a concern
> about artificial justifications for low-cost resources being obtained and
> then rapidly turn around and sell them for profit.
> Finally, there is the concern of selling resources for profit and then
> turning around and back filling the need from the free pool.
> Chairs shall notice that even if the impact analysis is extremely useful
> to authors and community, the staff can have a totally different view from
> the community, so the impact analysis is good as a point for discussion but
> never can be considered “per se” as objections unless duly justitified
> Here, I mostly agree, but with greater constraints. The impact analysis
> should be limited in scope to those impacts which the staff sees as a
> predictable impact to the RIR from the proposed policy. It shouldn’t go
> into speculation or ideology. It should stick to the facts and be a neutral
> report of the reasonably predictable results of implementing the policy and
> document how staff would interpret the policy as written and how it would
> be implemented.
> It should not be considered an objection unless there is a legal or
> fiduciary concern expressed and any such concern should be clearly called
> out as such and its basis should be well documented.
>    1. Regarding the AFRINIC role, while this is not considered in any
>    other RIR, because in my opinion is something very obvious (the role of the
>    RIR is just helping, and the final responsibility is on the source and
>    recipient of the transfers), I understand that having some text that
>    clarify that is not harming, so I’ve added section 5.7.6 (Due digilence) in
>    the new version of the proposal to address it.
> 5.7.6 is utterly unnecessary. It has nothing to do with number resource
> policy and should be stricken.
> AFRINIC is a registry. They keep track of who is the registrant of a set
> of number resources within a cooperating set of entities (the RIR system
> and those ISPs who choose to implement their networks in accordance with
> the RIR system). They are there to guarantee uniqueness among those
> cooperating entities, manage the registrations within that database
> according to policies set by the community, and provide a forum for the
> community to develop said policies.
> They are not a governing body. They are not a regulator. They are not
> kings of the internet, gods, or even a court of arbitration. They are just
> an NGO with a mission. That mission is to provide unique registrations of
> internet number resources according to community developed policies and
> facilitate the use of those registrations among cooperating entities who
> choose to work within the system.
> Recent attempts to weaponize AFRINIC are proof that some, including many
> among AFRINIC leadership have either lost sight of this or have an
> alternate agenda seeking to enrich themselves. I honestly don’t know which
> is the case at this point, but it is clear that there are problems which
> need to be addressed.
>    1. Regarding the RSA signature, again, while I believe this is obvious
>    and once more is not explicit in other RIRs, I’ve added text to clarify it.
>    Note that there is no such 3.6 in the proposal, so I believe there is some
>    mismatch in your text, may be chairs also reading the wrong IA? So, in
>    summary, section of the proposal, already was clear, but now has
>    been eddited to be even more exlicit on this in
> I think you mean edited and explicit.
>    1. Section 5.7.5 has been updated to be more clear and now explicitly
>    allows that other violations of the RSA/CPM aren’t “protected” by the
>    pre-check.
> Section 5.7.5 is getting worse instead of better. This entire pre-check
> provision is an opportunity to weaponize AFRINIC to hold resources captive
> in the case that some staff member or leadership person dislikes a transfer
> source for whatever reason. It provides broad latitude to inflict arbitrary
> judgment.
> Given recent weaponization of AFRINIC processes against certain members, I
> must strenuously object to any policy proposal that contains this provision.
>    1. There is an additional point in this version of the proposal that I
>    noticed while doing other edits. I’ve amended across all the text
>    “organization” with “entity” because organization is the wrong term and it
>    will be discriminatory. If we use “organization”, it may be understood (in
>    laws terms) as only legally constituted organizations (in law terminology
>    “juridical person”). If an “individual” has resources (even legacy), under
>    its own “personal” (“natural person” in law terminology), “organization”
>    will NOT allow the transfers in that case. In other RIRs the
>    terminology/wording being used doesn’t create this problem. So using
>    “entity”, doesn’t create this problem or any other problems. I’ve asked the
>    staff about that and at the moment got no response.
> The term should probably be “registrant”. Alternatively, “ORG-ID” would be
> fine since that would clearly represent an entity in the database
> represented by an ORG-ID.
>    1. Finally, in my understanding the changes apllied to this version of
>    the proposal doesn’t change the already confirmed recipocity status vs.
>    other RIRs (reciprocal with all the other RIRs), as it is not impossing any
>    condition that affer the other RIRs.
> I believe the current version would still be considered reciprocal by the
> RIRs where that matters.
> Owen
> _______________________________________________
> RPD mailing list
> RPD at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the RPD mailing list