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

[lucilla fornaro]

I agree with your idea that basically corruption may occur (like in any
other policy and in any other RIR) but there are instruments to avoid it
and supervise.

I believe that by not supporting organizations that need it due to possible
dishonesty, we only generate damage and a dangerous precedent.


Lucilla

Il giorno lun 14 set 2020 alle ore 11:49 Fernando Frediani <
fhfrediani at gmail.com> ha scritto:


> This type of justification in my view is a justification that only

> benefits brokers and those who are willing to financially speculate from IP

> space instead of using it for what they should be, and goes on the opposite

> direction of other regions even after their respective exhaustion phases.

>

> Fernando

>

>

> On Sun, 13 Sep 2020, 23:38 lucilla fornaro, <

> lucillafornarosawamoto at gmail.com> wrote:

>

>> I think that with this proposal AFRINIC would fully be able to support

>> any kind of organization in this uncertain period. In fact, due to the

>> pandemic situation it is clear that unexpected problems may occur any time.

>> AFRINIC should be able to transfer resources even to those that gave up

>> assigned resources during the previous 12 months. Only this way it’s

>> possible to facilitate the flow of resources from those who have them in

>> excess ( and don’t use them) to those who need them and cannot afford to

>> wait 12 months.

>>

>>

>> The issue concerning workload is relevant because as the proposal

>> supports, transfers won’t need approval from Afrinic. This and the section

>> 5.7.5 will help a lot to make the overall working system more efficient.

>>

>>

>> I also think that “no upper limit regarding the amount of transfers”

>> (section 5.7.3.3) will make a difference when IPv4 will be definitely

>> depleted.

>>

>>

>> Lucilla

>>

>> Il giorno ven 11 set 2020 alle ore 02:53 Fernando Frediani <

>> fhfrediani at gmail.com> ha scritto:

>>

>>> Releasing organizations from 12 months period doesn't make any sense and

>>> goes in the opposite way of good sense. So someone who gave up their just

>>> assigned resources transferring to someone else. What is the sense of it ?

>>>

>>> Smaller organizations can receive resources from AfricNic directly in

>>> Phase 2, so why would they need to make such transfers ? Also I don't think

>>> anyone is against allowing transfers Intra and Inter-RIR at the current

>>> stage. That's not the problem.

>>>

>>> I cannot understand what type of "issue" it can cause in terms of

>>> workload to the RIR and the time required for each request ? What does one

>>> thing have to do with the other ? If a request fulfill the minimal

>>> requirements there are no delays or extra workload do process the request.

>>>

>>> Regarding the "enrichment of its own financial pocket by Allocation

>>> Fees" this is still possible for any organizations who requests blocks

>>> according to Phase 2 so that statement is not correct either.

>>>

>>> There is a better well written proposal to allow Inter-RIR transfers

>>> under discussion which is and I invite others to support it instead which

>>> is "IPv4 Inter-RIR Resource Transfers (Comprehensive Scope) Draft-4 ". This

>>> one fulfill completely the need of Inter-RIR transfers for the region.

>>>

>>> Regards

>>> Fernando

>>> On 10/09/2020 11:31, lucilla fornaro wrote:

>>>

>>> 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> <fhfrediani at gmail.com>

>>> *Inviato:* Thursday, September 10, 2020 1:49:44 PM

>>> *A:* rpd at afrinic.net <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 listRPD at afrinic.nethttps://lists.afrinic.net/mailman/listinfo/rpd

>>>

>>> _______________________________________________

>>> 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

>

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