[rpd] Revised Proposal | Resource Transfer Policy (Draft-2)

[lucilla fornaro]

Hello everyone,

My name is Lucilla, I graduated in Law and I am currently attending a Master Degree in International Business. I would like to give my contribution to the discussion.

For 5.7.3.2: The barrier of 12 months represents an issue for many entities that need to face unexpected problems. AFRINIC needs to allow a smoother and faster resource transfer to support both smaller organizations’ growth, as well as enrich its own financial pocket by the Allocation Fees that need to be covered by entities that are not member yet.

And for what concerns other RIR like LACNIC, its policy is proving to create some issue. They, as well as the other RIRs, are facing a heavy workload because of the dilatation of time required for each request, that once approved need to be included into another waiting list due to quarantine reasons. These complications cannot be smoothly managed by AFRINIC due its shortage of workforce. The section 5.7.3.2 would make the overall working system more efficient. Furthermore, LACNIC entered phase 3 (back in 2017) of the IPv4 Exhaustion, meanwhile AFRINIC is facing a different situation.

I strongly support Section 5.7.3.3: it is positive not to have an upper limit regarding the amount of transfer because this will facilitate the flow of addresses. IPv4 addresses within the region will soon be depleted, transfer policy for IPv4 resources within and outside the region is strongly needed.

Lucilla

________________________________
Da: Fernando Frediani <fhfrediani at gmail.com>
Inviato: Thursday, September 10, 2020 1:49:44 PM
A: rpd at afrinic.net <rpd at afrinic.net>
Oggetto: Re: [rpd] Revised Proposal | Resource Transfer Policy (Draft-2)


I see that point 5.7.3.2 goes in the opposite way of the obvious.
If an organization gave up of its IP address space because it doesn't have usage for it anymore, why would it be allowed to receive more resources from AfriNic in short term ?
Organizations receive IP space upon justification expected to be used to serve their customers in a certain time frame ahead. If sudden it realizes these addresses are not necessary anymore and transfer them to some other organization who really need them why would the source entity be allowed to receive even further space ?
It is not correct to say it drags Afrinic service region backwards in comparison to other RIRs. LACNIC and ARIN for example have similar policies in regards this topic.

5.7.3.3. doesn't make sense either to be changed. The current text is correct and has a proper reason to be like this, otherwise it opens doors to fraud and to organizations to receive IP space form Afrinic and immediately to transfer to someone else who cannot receive them anymore under the current exhaustion rules.

Therefore I oppose this proposal.

Fernando

On 09/09/2020 11:40, Ibeanusi Elvis wrote:
Hello Everyone,

My Name is Ibeanusi Elvis. I am a Masters student of Global Law, Politics and Peace and Conflict Studies at the Tokyo University of Foreign Studies. Highly Interested in Internet Governance and Policy Making specifically within the AFRINIC service region.

In regards to this proposal, I support the Proposed Section 5.7.3.2 as source entities are eligible to receive further IPv4 allocations or assignments from AFRINIC as long as it complies with current policy because a 12 month non-eligibility delay period after transfer approval diminishes, hinders and is detrimental to the operational, developmental and growth of businesses within the AFRINIC region. Hence, dragging the African continent and AFRINIC service region backwards in comparison with other RIRs.

Additionally, Section 5.7.3.2 and Section 5.7.5.3 ensures a swift communication between the transferring and receiving RIRs to enhance a smooth transfer and receive of allocations and assignments.

Best regards,
Ibeanusi Elvis .C.



_______________________________________________
RPD mailing list
RPD at afrinic.net<mailto:RPD at afrinic.net>
https://lists.afrinic.net/mailman/listinfo/rpd

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20200910/86f040f0/attachment.html>