Search RPD Archives
[rpd] Resources transfer policy Proposal
ALAIN AINA
aalain at trstech.net
Mon Sep 16 05:58:28 UTC 2019
Dear community,
Recent posts brought up two main issues related to the proposal. See below our views on them.
1- AFRINIC role is overstretched and should only be for good booking.
In the Internet Registry hierarchy, there is no bookkeeping-only role.
The proposal is in accordance with AFRINIC role and mandate as stated in the bylaws and the RSA signed by members.
2- 2-way transfer is critical
The authors concur with this statement and point out that the proposal is actually a 2-way transfer solution addressing the specific problem described in the problem statement .
Hope this helps
Co-authors
> On 6 Sep 2019, at 11:23, Anthony Ubah <ubah.tonyiyke at gmail.com> wrote:
>
> Hello,
>
> I agree with Taiwo Oyewande. Like I once commented, I feel AfriNIC's role is being overstretched.
> Quoting from the proposed policy (Below), I think it introduces more snags to a process that should be otherwise smooth and seamless.
> AfriNIC does not have the resource to micromanage transfers and this will certainly leave the region with a frustrating process to cope with.
>
> “Number resources are non-transferable and are not assignable to any other organisation unless AFRINIC has expressly and in writing approved a request for transfer. AFRINIC is tasked with making prudent decisions on whether to approve the transfer of number resources.”
>
> Basically I maintain that 2-way transfer of resources is critical, and it is imperative for Afrinic to be looped-in for the sole purpose of good Booking.
> Best Regards,
>
> ANTHONY
>
> E-mail: anthony.ubah at goldspine.com <mailto:anthony.ubah at gloworld.com>.ng
>
>
>
> On Thu, Sep 5, 2019 at 9:04 AM <rpd-request at afrinic.net <mailto:rpd-request at afrinic.net>> wrote:
> Send RPD mailing list submissions to
> rpd at afrinic.net <mailto:rpd at afrinic.net>
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.afrinic.net/mailman/listinfo/rpd <https://lists.afrinic.net/mailman/listinfo/rpd>
> or, via email, send a message with subject or body 'help' to
> rpd-request at afrinic.net <mailto:rpd-request at afrinic.net>
>
> You can reach the person managing the list at
> rpd-owner at afrinic.net <mailto:rpd-owner at afrinic.net>
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of RPD digest..."
>
>
> Today's Topics:
>
> 1. Re: Resources transfer policy Proposal (Fernando Frediani)
> 2. Re: Resources transfer policy Proposal (Taiwo Oyewande)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 4 Sep 2019 13:11:08 -0300
> From: Fernando Frediani <fhfrediani at gmail.com <mailto:fhfrediani at gmail.com>>
> To: rpd at afrinic.net <mailto:rpd at afrinic.net>
> Subject: Re: [rpd] Resources transfer policy Proposal
> Message-ID: <bf55c33f-7c88-88dd-a4e4-51c5b10764b6 at gmail.com <mailto:bf55c33f-7c88-88dd-a4e4-51c5b10764b6 at gmail.com>>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> Hi Lee
>
> On 04/09/2019 12:00, Lee Howard wrote:
> >
> > <clip>
> >
> >> Newcomers are the most important to be privilege in my view in the
> >> future for a question of fairness so make sure they are treated the
> >> same way all others were in the past and give them a chance to exist
> >> in the Internet without any artificial difficulties.
> > I mostly agree with you, but I think this can be handled as well by
> > reserving addresses for IPv6 transition mechanisms.? A newcomer who is
> > building an IPv4 network is saying they only want to grow for one year.
>
> The way I see is the a newcomer wouldn't want (or be able) to build a
> IPv4 network when he is receiving only a /22, but to use most of these
> 1024 addresses for transition mechanisms as he wouldn't have a escape
> anyway. The difference from a dedicated policy for IPv6 transition
> mechanisms is that it gives a little more flexibility to that
> organization to grow and stabilize itself. Then if beyond that they
> still need more address they can go to market.
> A dedicated IPv6 transition policy is more toward those who already have
> some allocation from the RIR and it works in even smaller portions of
> addresses as it is in ARIN for example.
>
> Fernando
>
> >
> > Lee
> >
> >>
> >> Regards
> >> Fernando
> >>
> >>>
> >>> Hope this helps
> >>>
> >>> - Co-authors
> >>>
> >>>
> >>>
> >>>> On 31 Aug 2019, at 18:39, Taiwo Oyewande
> >>>> <taiwo.oyewande88 at gmail.com <mailto:taiwo.oyewande88 at gmail.com>> wrote:
> >>>>
> >>>>
> >>>> A resource transfer policy is required in AFRNIC, but what type of
> >>>> transfer and when should these transfer be implemented are key
> >>>> components to the success of such policy proposals as being discussed.
> >>>>
> >>>> An intra rir transfer policy is required in AFRINIC. The
> >>>> requirements for a transfer in the intra- rir transfer section of
> >>>> this policy proposals are somewhat stiff and can disrupt business
> >>>> flow if implemented. Eg? a transfer of ip between an ISP and a
> >>>> customer will have to wait for a written approval after AFRINIC
> >>>> makes a ?prudent decision?.
> >>>>
> >>>> Also, it is in my opinion that to achieve the said goal in this
> >>>> proposals, a two-way inter-rir policy is required. Most RIRs with
> >>>> transfer policy between regions are on the terms that the other
> >>>> region has a two way transfer policy. E.g ARIN and RIPE-NCC.
> >>>>
> >>>> I recommend a two-way inter-rir policy that has safety caps as
> >>>> recommended by some members of the community.
> >>>>
> >>>> Kind regards
> >>>>
> >>>>> On 30 Aug 2019, at 10:57, Sylvain BAYA <abscoco at gmail.com <mailto:abscoco at gmail.com>> wrote:
> >>>>>
> >>>>> Hi all,
> >>>>>
> >>>>> Hope you are well.
> >>>>>
> >>>>> Please see my comments below (inline)...
> >>>>>
> >>>>>> Le 8/29/2019 ? 12:36 PM, ALAIN AINA via RPD a ?crit :
> >>>>>> Dear community
> >>>>>>
> >>>>>> A new policy proposal? named "AFRINIC? resources transfer policy"
> >>>>>> is submitted for discussions. This proposal obsoletes the
> >>>>>> current? IPv4? transfer within AFRINIC service region policy,?
> >>>>>> defines? rules for transfers of IPv4? and ASNs? within the region
> >>>>>> and between AFRINIC service region and other regions.
> >>>>>>
> >>>>>> The policy allows a category of resources to be transferred out
> >>>>>> of the region, another category of resources to be transferred
> >>>>>> inside and denies the transfer of certain resources.
> >>>>>>
> >>>>>> We expect this to be a response to a harmonised policy which
> >>>>>> addresses some of the limitations of the intra-rir policy and
> >>>>>> proposes a solution for an inter-rir transfer which minimizes the
> >>>>>> foreseen risks of uncontrolled outflow of resources.
> >>>>>>
> >>>>>> The co-authors
> >>>>> Dear Alain,
> >>>>> ...i thank you and your co-authors for this interesting and
> >>>>> comprehensive work you have done.
> >>>>>
> >>>>> Really good draft !
> >>>>>
> >>>>>> =====================begin=================
> >>>>>> Draft Policy Name: AFRINIC Number resources transfer policy
> >>>>>> ID: (Assigned by AFRINIC)
> >>>>>> Submission Date: 29 August 2019
> >>>>>> Version: 1.0
> >>>>>> Author(s): (a) Name, (b) Email address, (c) Affiliation, if
> >>>>>> applicable
> >>>>>> ???? Gregoire Olaotan Ehoumi, gregoire at ehoumi.net <mailto:gregoire at ehoumi.net>, independent
> >>>>>> ???? Mukhangou Noah? Maina, noah.maina at seacom.com <mailto:noah.maina at seacom.com>, SEACOM
> >>>>>> ???? Komi Elitcha,? kelitcha at djesido.africa, Independent
> >>>>>> ???? Adeola A. P. Aina, alain.aina at wacren.net <mailto:alain.aina at wacren.net>, WACREN
> >>>>>>
> >>>>>> Sections of Policy Manual affected
> >>>>>>
> >>>>>> Obsoletes: IPv4 Resources transfer within the AFRINIC Region
> >>>>>> (Section 5.7 of the CPM)
> >>>>>>
> >>>>>> 1.??? Summary of the problem being addressed by this proposal
> >>>>>>
> >>>>>> AFRINIC IPv4 pool is expected to run out soon. Some entities may
> >>>>>> need IPv4 space to support their IPv6 deployments, especially to
> >>>>>> support transition mechanisms, which AFRINIC may not meet. The
> >>>>>> current Intra-RIR policy in force at AFRINIC allows entities to
> >>>>>> receive unused IPv4 address from other members solely within the
> >>>>>> AFRINIC region, based on justified needs. Considering the limited
> >>>>>> IPv4 space initially made available to AFRINIC (AFRINIC managing
> >>>>>> only 7.23 /8 with a very low ratio of IPv4 addresses per Internet
> >>>>>> users), there will therefore be a need to allow for unused IPv4
> >>>>>> from other regions to move into AFRINIC service region ? this
> >>>>>> without necessarily depleting AFRINIC's slim amount of IPv4
> >>>>>> addresses by transferring space out of the region.
> >>>>> ...unless failing under *CPM section 5.4.6.2* ?
> >>>>>
> >>>>>> The current Intra-RIR transfer policy allows all types of IPv4
> >>>>>> allocations/assignments to be transferred, including IPv4 from
> >>>>>> special purpose blocks (reserved blocks for IXPs and DNS root
> >>>>>> ops, Last /8, etc.)
> >>>>>>
> >>>>>> The current intra-RIR transfer policy does not cover ASNs while
> >>>>>> there are cases where transfers of ASNs among AFRINIC members is
> >>>>>> desirable.
> >>>>> ...real problem, but need a different draft policy proposal to
> >>>>> address
> >>>>> it, unless you plan to have
> >>>>> the content of this draft policy proposal (if ratified at end) in a
> >>>>> specific new section for all Internet
> >>>>> Resource Transfers.
> >>>>>
> >>>>> For the latter i will suggest you to also consider IPv6 address space
> >>>>> into your Resources definition.
> >>>>>
> >>>>>> 2.??? Summary of how this proposal addresses the problem
> >>>>>>
> >>>>>> This new policy defines a set of rules to allow transfer of IPv4
> >>>>>> addresses and ASNs within AFRINIC service region and between
> >>>>>> AFRINIC service region and other regions
> >>>>> Please explain me why not also IPv6 addresses ?
> >>>>>
> >>>>>> by specifying what categories of resources are eligible for
> >>>>>> transfer, the location of parties (sources and recipients) and
> >>>>>> the conditions to be met.
> >>>>>> The policy segregates the resources in different categories and
> >>>>>> defines which transfer rules applied to each category.
> >>>>>>
> >>>>>> Only Legacy resources and resources previously transferred from
> >>>>>> other regions will be transferable out of the AFRINIC service
> >>>>>> region.
> >>>>>>
> >>>>>> It also states the following:
> >>>>>>
> >>>>>> Number resources are non-transferable and are not assignable to
> >>>>>> any other organisation unless AFRINIC has expressly and in
> >>>>>> writing approved a request for transfer. AFRINIC is tasked with
> >>>>>> making prudent decisions on whether to approve the transfer of
> >>>>>> number resources.
> >>>>> ...i have not seen this in section 3 below. Is it not mandatory ?
> >>>>>
> >>>>> Or is it just about what we are reading in RSA section 6. (d) (vi) ?
> >>>>>
> >>>>> Also, what do you mean by ?prudent decisions? ? Could you clarify
> >>>>> please.
> >>>>>
> >>>>>> IPv4 addresses and ASNs can be transferred only in accordance
> >>>>>> with the following policy. AFRINIC does not recognise transfers
> >>>>>> outside of this policy and its predecessor and requires
> >>>>>> organisations holding such resources to return them to the
> >>>>>> appropriate registries.
> >>>>> ...almost the same comment as my preceeding :-/
> >>>>> Please can you elaborate on the expected impact of this ?
> >>>>>
> >>>>>> The goal of this transfer policy is to help distribute resources
> >>>>>> from those who no longer need them to organisations that need the
> >>>>>> resources, but cannot obtain them from the AFRINIC? free pools.
> >>>>> Noted !
> >>>>>
> >>>>>> AFRINIC recognizes the following types of transfers:
> >>>>>> - merger, acquisition or takeover,
> >>>>>> - between AFRINIC members,
> >>>>>> - between an AFRINIC member and a member of another RIR,
> >>>>>> - between a Legacy holder and an AFRINIC member,
> >>>>>> - between a Legacy holder and a member of another RIR.
> >>>>> ...have not seen in section 3. Why please ?
> >>>>>
> >>>>>> AFRINIC will process and record Inter-RIR resource transfers only
> >>>>>> when the counterpart RIR has an Inter-RIR transfer policy that
> >>>>>> permits the transfer of IPv4 address space and ASNs between its
> >>>>>> own region and AFRINIC.
> >>>>>>
> >>>>>>
> >>>>>> 3.??? Proposal
> >>>>>>
> >>>>>> 3.1 Definitions
> >>>>>>
> >>>>>> 3.1.1 ?Resource? refers to IPv4 Address space or Autonomous
> >>>>>> System Numbers.
> >>>>>> ?AFRINIC pool? means AFRINIC managed pool of IPv4 and ASNs,
> >>>>>> obtained from IANA (allocated and recovered) or through the ERX
> >>>>>> (Early registration transfers).
> >>>>>>
> >>>>>> 3.1.2 ?Special-Purpose pool? means the pool of resources
> >>>>>> currently reserved for Critical Internet Infrastructures (section
> >>>>>> 5.6.4 of CPM) and last /8 (section 5.4.1 of CPM).
> >>>>>>
> >>>>>> 3.1.3 ?Legacy resources? refer to resources allocated prior to
> >>>>>> the RIR system and tagged as Legacy by AFRINIC.
> >>>>>>
> >>>>>> 3.1.4 ?Others? means resources transferred from other regions
> >>>>>> through Inter-RIR transfer.
> >>>>>>
> >>>>>> 3.1.5 ?Inter-RIR transfer? means the transfer of resources from
> >>>>>> an AFRINIC member to a member of another RIR or vice-versa.
> >>>>>>
> >>>>>>
> >>>>>> 3.2 Marking of the resources
> >>>>>>
> >>>>>> AFRINIC pool == Regional
> >>>>>> Special-Purpose pool == Reserved
> >>>>>> Legacy == Legacy
> >>>>>> Others == Global
> >>>>>>
> >>>>>> 3.3 Rules and procedures for selecting resources eligible for
> >>>>>> transfers
> >>>>>>
> >>>>>> 3.3.1 If source and recipient are AFRINIC members, then allow
> >>>>>> ?Regional?, ?Global? or ?Legacy? for transfer and mark
> >>>>>> transferred ?Legacy? as ?Global?
> >>>>>>
> >>>>>> 3.3.2 If source is Legacy holder and recipient is AFRINIC member,
> >>>>>> then allow ?Legacy? for transfer and mark transferred resources
> >>>>>> as ?Global?
> >>>>>>
> >>>>>> 3.3.3 If source is Legacy holder and recipient is in another
> >>>>>> region, then allow ?Legacy? for transfer
> >>>>>>
> >>>>>> 3.3.4 If source is AFRINIC member and recipient is in another
> >>>>>> region, then allow ?Global? for transfer
> >>>>>>
> >>>>>> 3.3.5 If source is from another region and recipient is AFRINIC
> >>>>>> member, then allow ?Any?, and then mark the transferred resources
> >>>>>> as ?Global?
> >>>>>>
> >>>>>> 3.3.6 Irrespective of the source and recipient, if resource to be
> >>>>>> transferred is ?Reserved? then deny transfer.
> >>>>>>
> >>>>>> 3.4 Conditions on resources to be transferred
> >>>>>>
> >>>>>> - The size of the IPv4 address should be a minimum of /24.
> >>>>>> - The resource must qualify for type of transfer requested.
> >>>>> ...you might consider adding this condition :
> >>>>> ? The resource must not fall under a situation on which it should be
> >>>>> returned to AFRINIC as
> >>>>> clearly stated by the RSA section 6. (d) (vii)
> >>>>>
> >>>>> Please tell me, might it be productive to also add the following
> >>>>> condition here ? or not ? Why ?
> >>>>> ? MUST show past usage rate if applicable.
> >>>>>
> >>>>>> - The resource will be covered by AFRINIC policies after transfer
> >>>>>> into the region.
> >>>>>>
> >>>>>> 3.5 Conditions on the source
> >>>>>>
> >>>>>> - Must be right holder of the resources to be transferred with no
> >>>>>> disputes.
> >>>>>> - If the source is from other regions, conditions on the source
> >>>>>> are defined in the counterpart RIRs transfer policy.
> >>>>> ...question : how this draft policy proposal is dealing with a source
> >>>>> organisation which should normally return (see RSA section 6. (d)
> >>>>> (vii))
> >>>>> such resources to AFRINIC ?
> >>>>>
> >>>>>> 3.6 Conditions on the recipient
> >>>>>>
> >>>>>> - Will be subject to current AFRINIC policies.
> >>>>>> - Must sign RSA.
> >>>>> Why not this alternative : MUST be an AFRINIC resource member in good
> >>>>> standing...
> >>>>>
> >>>>> Thanks.
> >>>>>
> >>>>>> - Recipient that does not have prior resources must:
> >>>>>> ++ demonstrate a detailed plan for the use of the transferred
> >>>>>> resources
> >>>>>> (in the case of ASN, recipient must meet the criteria for
> >>>>>> assignment of ASN).
> >>>>>> - Recipient with prior resources must:
> >>>>>> ++ demonstrate a detailed plan for the use of the transferred
> >>>>>> resources
> >>>>>> (in the case of ASN, recipient must meet the criteria for
> >>>>>> assignment of ASN).
> >>>>>> ++ Show past usage rate.
> >>>>>> ++ Provide evidence of compliance with AFRINIC policies with
> >>>>>> respect to past allocations/assignments.
> >>>>>> - If the recipient is in another region, the conditions on the
> >>>>>> recipient are defined in the counterpart?s RIR transfer policy.
> >>>>>>
> >>>>>> 4.??? Revision History
> >>>>>>
> >>>>>> v1 submitted on 29/08/2019 for discussions
> >>>>>>
> >>>>>> 5.??? References
> >>>>>>
> >>>>>> https://www.nro.net/wp-content/uploads/NRO-Statistics-2019Q2.pdf <https://www.nro.net/wp-content/uploads/NRO-Statistics-2019Q2.pdf>
> >>>>>> https://www.potaroo.net/tools/ipv4/ <https://www.potaroo.net/tools/ipv4/>
> >>>>>> http://bgp.potaroo.net/iso3166/v4cc.html <http://bgp.potaroo.net/iso3166/v4cc.html>
> >>>>>> http://resources.potaroo.net/iso3166/ascc.html <http://resources.potaroo.net/iso3166/ascc.html>
> >>>>>> ftp://ftp.afrinic.net/stats/afrinic/transfers/ <ftp://ftp.afrinic.net/stats/afrinic/transfers/>
> >>>>>>
> >>>>>> ===================end=======================
> >>>>> Shalom,
> >>>>> --sb.
> >>>>>
> >>>>>> [...]
> >>>>> --
> >>>>>
> >>>>> Regards,
> >>>>> Sylvain B.
> >>>>> <http://www.chretiennement.org <http://www.chretiennement.org/>>
> >>>>> __
> >>>>> Website : <https://www.cmnog.cm <https://www.cmnog.cm/>>
> >>>>> Wiki : <https://www.cmnog.cm/dokuwiki <https://www.cmnog.cm/dokuwiki>>
> >>>>> Surveys : <https://survey.cmnog.cm <https://survey.cmnog.cm/>>--------?
> >>>>> Subscribe to Mailing List :
> >>>>> <https://lists.cmnog.cm/mailman/listinfo/cmnog/ <https://lists.cmnog.cm/mailman/listinfo/cmnog/>>
> >>>>> Mailing List's Archives : <https://lists.cmnog.cm/pipermail/cmnog/ <https://lists.cmnog.cm/pipermail/cmnog/>>
> >>>>>
> >>>>> <0x0387408365AC8594.asc>
> >>>>> _______________________________________________
> >>>>> RPD mailing list
> >>>>> RPD at afrinic.net <mailto:RPD at afrinic.net>
> >>>>> https://lists.afrinic.net/mailman/listinfo/rpd <https://lists.afrinic.net/mailman/listinfo/rpd>
> >>>> _______________________________________________
> >>>> RPD mailing list
> >>>> RPD at afrinic.net <mailto:RPD at afrinic.net>
> >>>> https://lists.afrinic.net/mailman/listinfo/rpd <https://lists.afrinic.net/mailman/listinfo/rpd>
> >>>
> >>> _______________________________________________
> >>> RPD mailing list
> >>> RPD at afrinic.net <mailto:RPD at afrinic.net>
> >>> https://lists.afrinic.net/mailman/listinfo/rpd <https://lists.afrinic.net/mailman/listinfo/rpd>
> >>
> >> _______________________________________________
> >> RPD mailing list
> >> RPD at afrinic.net <mailto:RPD at afrinic.net>
> >> https://lists.afrinic.net/mailman/listinfo/rpd <https://lists.afrinic.net/mailman/listinfo/rpd>
> >
> > _______________________________________________
> > RPD mailing list
> > RPD at afrinic.net <mailto:RPD at afrinic.net>
> > https://lists.afrinic.net/mailman/listinfo/rpd <https://lists.afrinic.net/mailman/listinfo/rpd>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 5 Sep 2019 09:03:45 +0100
> From: Taiwo Oyewande <taiwo.oyewande88 at gmail.com <mailto:taiwo.oyewande88 at gmail.com>>
> To: Fernando Frediani <fhfrediani at gmail.com <mailto:fhfrediani at gmail.com>>
> Cc: rpd at afrinic.net <mailto:rpd at afrinic.net>
> Subject: Re: [rpd] Resources transfer policy Proposal
> Message-ID: <827067E2-C1C6-4E7D-855E-0E98277912B5 at gmail.com <mailto:827067E2-C1C6-4E7D-855E-0E98277912B5 at gmail.com>>
> Content-Type: text/plain; charset=utf-8
>
>
> Dear all,
>
> I appreciate the well coordinated reply by the co-authors.
>
> Based on my previous comment, I am still of the opinion that transfer of resources within the region should be less stiff. Afrinic is an Internet registry for Africa centred at distributing Internet number resources and having an updated ledger of its distributed resources. With this, Number resources should be able to move freely within the region as long as a valid need is shown and a written notification is sent to AFRINIC to update her books for proper and up to date record keeping. The decision making process in this proposal is time consuming and can affect business operation.
>
> Kind regards
> Taiwo
>
> > On 4 Sep 2019, at 17:11, Fernando Frediani <fhfrediani at gmail.com <mailto:fhfrediani at gmail.com>> wrote:
> >
> > Hi Lee
> >
> >> On 04/09/2019 12:00, Lee Howard wrote:
> >>
> >> <clip>
> >>
> >>> Newcomers are the most important to be privilege in my view in the future for a question of fairness so make sure they are treated the same way all others were in the past and give them a chance to exist in the Internet without any artificial difficulties.
> >> I mostly agree with you, but I think this can be handled as well by reserving addresses for IPv6 transition mechanisms. A newcomer who is building an IPv4 network is saying they only want to grow for one year.
> >
> > The way I see is the a newcomer wouldn't want (or be able) to build a IPv4 network when he is receiving only a /22, but to use most of these 1024 addresses for transition mechanisms as he wouldn't have a escape anyway. The difference from a dedicated policy for IPv6 transition mechanisms is that it gives a little more flexibility to that organization to grow and stabilize itself. Then if beyond that they still need more address they can go to market.
> > A dedicated IPv6 transition policy is more toward those who already have some allocation from the RIR and it works in even smaller portions of addresses as it is in ARIN for example.
> >
> > Fernando
> >
> >>
> >> Lee
> >>
> >>>
> >>> Regards
> >>> Fernando
> >>>
> >>>>
> >>>> Hope this helps
> >>>>
> >>>> - Co-authors
> >>>>
> >>>>
> >>>>
> >>>>> On 31 Aug 2019, at 18:39, Taiwo Oyewande <taiwo.oyewande88 at gmail.com <mailto:taiwo.oyewande88 at gmail.com>> wrote:
> >>>>>
> >>>>>
> >>>>> A resource transfer policy is required in AFRNIC, but what type of transfer and when should these transfer be implemented are key components to the success of such policy proposals as being discussed.
> >>>>>
> >>>>> An intra rir transfer policy is required in AFRINIC. The requirements for a transfer in the intra- rir transfer section of this policy proposals are somewhat stiff and can disrupt business flow if implemented. Eg a transfer of ip between an ISP and a customer will have to wait for a written approval after AFRINIC makes a ?prudent decision?.
> >>>>>
> >>>>> Also, it is in my opinion that to achieve the said goal in this proposals, a two-way inter-rir policy is required. Most RIRs with transfer policy between regions are on the terms that the other region has a two way transfer policy. E.g ARIN and RIPE-NCC.
> >>>>>
> >>>>> I recommend a two-way inter-rir policy that has safety caps as recommended by some members of the community.
> >>>>>
> >>>>> Kind regards
> >>>>>
> >>>>>> On 30 Aug 2019, at 10:57, Sylvain BAYA <abscoco at gmail.com <mailto:abscoco at gmail.com>> wrote:
> >>>>>>
> >>>>>> Hi all,
> >>>>>>
> >>>>>> Hope you are well.
> >>>>>>
> >>>>>> Please see my comments below (inline)...
> >>>>>>
> >>>>>>> Le 8/29/2019 ? 12:36 PM, ALAIN AINA via RPD a ?crit :
> >>>>>>> Dear community
> >>>>>>>
> >>>>>>> A new policy proposal named "AFRINIC resources transfer policy" is submitted for discussions. This proposal obsoletes the current IPv4 transfer within AFRINIC service region policy, defines rules for transfers of IPv4 and ASNs within the region and between AFRINIC service region and other regions.
> >>>>>>>
> >>>>>>> The policy allows a category of resources to be transferred out of the region, another category of resources to be transferred inside and denies the transfer of certain resources.
> >>>>>>>
> >>>>>>> We expect this to be a response to a harmonised policy which addresses some of the limitations of the intra-rir policy and proposes a solution for an inter-rir transfer which minimizes the foreseen risks of uncontrolled outflow of resources.
> >>>>>>>
> >>>>>>> The co-authors
> >>>>>> Dear Alain,
> >>>>>> ...i thank you and your co-authors for this interesting and
> >>>>>> comprehensive work you have done.
> >>>>>>
> >>>>>> Really good draft !
> >>>>>>
> >>>>>>> =====================begin=================
> >>>>>>> Draft Policy Name: AFRINIC Number resources transfer policy
> >>>>>>> ID: (Assigned by AFRINIC)
> >>>>>>> Submission Date: 29 August 2019
> >>>>>>> Version: 1.0
> >>>>>>> Author(s): (a) Name, (b) Email address, (c) Affiliation, if applicable
> >>>>>>> Gregoire Olaotan Ehoumi, gregoire at ehoumi.net <mailto:gregoire at ehoumi.net>, independent
> >>>>>>> Mukhangou Noah Maina, noah.maina at seacom.com <mailto:noah.maina at seacom.com>, SEACOM
> >>>>>>> Komi Elitcha, kelitcha at djesido.africa, Independent
> >>>>>>> Adeola A. P. Aina, alain.aina at wacren.net <mailto:alain.aina at wacren.net>, WACREN
> >>>>>>>
> >>>>>>> Sections of Policy Manual affected
> >>>>>>>
> >>>>>>> Obsoletes: IPv4 Resources transfer within the AFRINIC Region (Section 5.7 of the CPM)
> >>>>>>>
> >>>>>>> 1. Summary of the problem being addressed by this proposal
> >>>>>>>
> >>>>>>> AFRINIC IPv4 pool is expected to run out soon. Some entities may need IPv4 space to support their IPv6 deployments, especially to support transition mechanisms, which AFRINIC may not meet. The current Intra-RIR policy in force at AFRINIC allows entities to receive unused IPv4 address from other members solely within the AFRINIC region, based on justified needs. Considering the limited IPv4 space initially made available to AFRINIC (AFRINIC managing only 7.23 /8 with a very low ratio of IPv4 addresses per Internet users), there will therefore be a need to allow for unused IPv4 from other regions to move into AFRINIC service region ? this without necessarily depleting AFRINIC's slim amount of IPv4 addresses by transferring space out of the region.
> >>>>>> ...unless failing under *CPM section 5.4.6.2* ?
> >>>>>>
> >>>>>>> The current Intra-RIR transfer policy allows all types of IPv4 allocations/assignments to be transferred, including IPv4 from special purpose blocks (reserved blocks for IXPs and DNS root ops, Last /8, etc.)
> >>>>>>>
> >>>>>>> The current intra-RIR transfer policy does not cover ASNs while there are cases where transfers of ASNs among AFRINIC members is desirable.
> >>>>>> ...real problem, but need a different draft policy proposal to address
> >>>>>> it, unless you plan to have
> >>>>>> the content of this draft policy proposal (if ratified at end) in a
> >>>>>> specific new section for all Internet
> >>>>>> Resource Transfers.
> >>>>>>
> >>>>>> For the latter i will suggest you to also consider IPv6 address space
> >>>>>> into your Resources definition.
> >>>>>>
> >>>>>>> 2. Summary of how this proposal addresses the problem
> >>>>>>>
> >>>>>>> This new policy defines a set of rules to allow transfer of IPv4 addresses and ASNs within AFRINIC service region and between AFRINIC service region and other regions
> >>>>>> Please explain me why not also IPv6 addresses ?
> >>>>>>
> >>>>>>> by specifying what categories of resources are eligible for transfer, the location of parties (sources and recipients) and the conditions to be met.
> >>>>>>> The policy segregates the resources in different categories and defines which transfer rules applied to each category.
> >>>>>>>
> >>>>>>> Only Legacy resources and resources previously transferred from other regions will be transferable out of the AFRINIC service region.
> >>>>>>>
> >>>>>>> It also states the following:
> >>>>>>>
> >>>>>>> Number resources are non-transferable and are not assignable to any other organisation unless AFRINIC has expressly and in writing approved a request for transfer. AFRINIC is tasked with making prudent decisions on whether to approve the transfer of number resources.
> >>>>>> ...i have not seen this in section 3 below. Is it not mandatory ?
> >>>>>>
> >>>>>> Or is it just about what we are reading in RSA section 6. (d) (vi) ?
> >>>>>>
> >>>>>> Also, what do you mean by ?prudent decisions? ? Could you clarify please.
> >>>>>>
> >>>>>>> IPv4 addresses and ASNs can be transferred only in accordance with the following policy. AFRINIC does not recognise transfers outside of this policy and its predecessor and requires organisations holding such resources to return them to the appropriate registries.
> >>>>>> ...almost the same comment as my preceeding :-/
> >>>>>> Please can you elaborate on the expected impact of this ?
> >>>>>>
> >>>>>>> The goal of this transfer policy is to help distribute resources from those who no longer need them to organisations that need the resources, but cannot obtain them from the AFRINIC free pools.
> >>>>>> Noted !
> >>>>>>
> >>>>>>> AFRINIC recognizes the following types of transfers:
> >>>>>>> - merger, acquisition or takeover,
> >>>>>>> - between AFRINIC members,
> >>>>>>> - between an AFRINIC member and a member of another RIR,
> >>>>>>> - between a Legacy holder and an AFRINIC member,
> >>>>>>> - between a Legacy holder and a member of another RIR.
> >>>>>> ...have not seen in section 3. Why please ?
> >>>>>>
> >>>>>>> AFRINIC will process and record Inter-RIR resource transfers only when the counterpart RIR has an Inter-RIR transfer policy that permits the transfer of IPv4 address space and ASNs between its own region and AFRINIC.
> >>>>>>>
> >>>>>>>
> >>>>>>> 3. Proposal
> >>>>>>>
> >>>>>>> 3.1 Definitions
> >>>>>>>
> >>>>>>> 3.1.1 ?Resource? refers to IPv4 Address space or Autonomous System Numbers.
> >>>>>>> ?AFRINIC pool? means AFRINIC managed pool of IPv4 and ASNs, obtained from IANA (allocated and recovered) or through the ERX (Early registration transfers).
> >>>>>>>
> >>>>>>> 3.1.2 ?Special-Purpose pool? means the pool of resources currently reserved for Critical Internet Infrastructures (section 5.6.4 of CPM) and last /8 (section 5.4.1 of CPM).
> >>>>>>>
> >>>>>>> 3.1.3 ?Legacy resources? refer to resources allocated prior to the RIR system and tagged as Legacy by AFRINIC.
> >>>>>>>
> >>>>>>> 3.1.4 ?Others? means resources transferred from other regions through Inter-RIR transfer.
> >>>>>>>
> >>>>>>> 3.1.5 ?Inter-RIR transfer? means the transfer of resources from an AFRINIC member to a member of another RIR or vice-versa.
> >>>>>>>
> >>>>>>>
> >>>>>>> 3.2 Marking of the resources
> >>>>>>>
> >>>>>>> AFRINIC pool == Regional
> >>>>>>> Special-Purpose pool == Reserved
> >>>>>>> Legacy == Legacy
> >>>>>>> Others == Global
> >>>>>>>
> >>>>>>> 3.3 Rules and procedures for selecting resources eligible for transfers
> >>>>>>>
> >>>>>>> 3.3.1 If source and recipient are AFRINIC members, then allow ?Regional?, ?Global? or ?Legacy? for transfer and mark transferred ?Legacy? as ?Global?
> >>>>>>>
> >>>>>>> 3.3.2 If source is Legacy holder and recipient is AFRINIC member, then allow ?Legacy? for transfer and mark transferred resources as ?Global?
> >>>>>>>
> >>>>>>> 3.3.3 If source is Legacy holder and recipient is in another region, then allow ?Legacy? for transfer
> >>>>>>>
> >>>>>>> 3.3.4 If source is AFRINIC member and recipient is in another region, then allow ?Global? for transfer
> >>>>>>>
> >>>>>>> 3.3.5 If source is from another region and recipient is AFRINIC member, then allow ?Any?, and then mark the transferred resources as ?Global?
> >>>>>>>
> >>>>>>> 3.3.6 Irrespective of the source and recipient, if resource to be transferred is ?Reserved? then deny transfer.
> >>>>>>>
> >>>>>>> 3.4 Conditions on resources to be transferred
> >>>>>>>
> >>>>>>> - The size of the IPv4 address should be a minimum of /24.
> >>>>>>> - The resource must qualify for type of transfer requested.
> >>>>>> ...you might consider adding this condition :
> >>>>>> ? The resource must not fall under a situation on which it should be
> >>>>>> returned to AFRINIC as
> >>>>>> clearly stated by the RSA section 6. (d) (vii)
> >>>>>>
> >>>>>> Please tell me, might it be productive to also add the following
> >>>>>> condition here ? or not ? Why ?
> >>>>>> ? MUST show past usage rate if applicable.
> >>>>>>
> >>>>>>> - The resource will be covered by AFRINIC policies after transfer into the region.
> >>>>>>>
> >>>>>>> 3.5 Conditions on the source
> >>>>>>>
> >>>>>>> - Must be right holder of the resources to be transferred with no disputes.
> >>>>>>> - If the source is from other regions, conditions on the source are defined in the counterpart RIRs transfer policy.
> >>>>>> ...question : how this draft policy proposal is dealing with a source
> >>>>>> organisation which should normally return (see RSA section 6. (d) (vii))
> >>>>>> such resources to AFRINIC ?
> >>>>>>
> >>>>>>> 3.6 Conditions on the recipient
> >>>>>>>
> >>>>>>> - Will be subject to current AFRINIC policies.
> >>>>>>> - Must sign RSA.
> >>>>>> Why not this alternative : MUST be an AFRINIC resource member in good
> >>>>>> standing...
> >>>>>>
> >>>>>> Thanks.
> >>>>>>
> >>>>>>> - Recipient that does not have prior resources must:
> >>>>>>> ++ demonstrate a detailed plan for the use of the transferred resources
> >>>>>>> (in the case of ASN, recipient must meet the criteria for assignment of ASN).
> >>>>>>> - Recipient with prior resources must:
> >>>>>>> ++ demonstrate a detailed plan for the use of the transferred resources
> >>>>>>> (in the case of ASN, recipient must meet the criteria for assignment of ASN).
> >>>>>>> ++ Show past usage rate.
> >>>>>>> ++ Provide evidence of compliance with AFRINIC policies with respect to past allocations/assignments.
> >>>>>>> - If the recipient is in another region, the conditions on the recipient are defined in the counterpart?s RIR transfer policy.
> >>>>>>>
> >>>>>>> 4. Revision History
> >>>>>>>
> >>>>>>> v1 submitted on 29/08/2019 for discussions
> >>>>>>>
> >>>>>>> 5. References
> >>>>>>>
> >>>>>>> https://www.nro.net/wp-content/uploads/NRO-Statistics-2019Q2.pdf <https://www.nro.net/wp-content/uploads/NRO-Statistics-2019Q2.pdf>
> >>>>>>> https://www.potaroo.net/tools/ipv4/ <https://www.potaroo.net/tools/ipv4/>
> >>>>>>> http://bgp.potaroo.net/iso3166/v4cc.html <http://bgp.potaroo.net/iso3166/v4cc.html>
> >>>>>>> http://resources.potaroo.net/iso3166/ascc.html <http://resources.potaroo.net/iso3166/ascc.html>
> >>>>>>> ftp://ftp.afrinic.net/stats/afrinic/transfers/ <ftp://ftp.afrinic.net/stats/afrinic/transfers/>
> >>>>>>>
> >>>>>>> ===================end=======================
> >>>>>> Shalom,
> >>>>>> --sb.
> >>>>>>
> >>>>>>> [...]
> >>>>>> --
> >>>>>>
> >>>>>> Regards,
> >>>>>> Sylvain B.
> >>>>>> <http://www.chretiennement.org <http://www.chretiennement.org/>>
> >>>>>> __
> >>>>>> Website : <https://www.cmnog.cm <https://www.cmnog.cm/>>
> >>>>>> Wiki : <https://www.cmnog.cm/dokuwiki <https://www.cmnog.cm/dokuwiki>>
> >>>>>> Surveys : <https://survey.cmnog.cm <https://survey.cmnog.cm/>>--------?
> >>>>>> Subscribe to Mailing List : <https://lists.cmnog.cm/mailman/listinfo/cmnog/ <https://lists.cmnog.cm/mailman/listinfo/cmnog/>>
> >>>>>> Mailing List's Archives : <https://lists.cmnog.cm/pipermail/cmnog/ <https://lists.cmnog.cm/pipermail/cmnog/>>
> >>>>>>
> >>>>>> <0x0387408365AC8594.asc>
> >>>>>> _______________________________________________
> >>>>>> RPD mailing list
> >>>>>> RPD at afrinic.net <mailto:RPD at afrinic.net>
> >>>>>> https://lists.afrinic.net/mailman/listinfo/rpd <https://lists.afrinic.net/mailman/listinfo/rpd>
> >>>>> _______________________________________________
> >>>>> RPD mailing list
> >>>>> RPD at afrinic.net <mailto:RPD at afrinic.net>
> >>>>> https://lists.afrinic.net/mailman/listinfo/rpd <https://lists.afrinic.net/mailman/listinfo/rpd>
> >>>>
> >>>> _______________________________________________
> >>>> RPD mailing list
> >>>> RPD at afrinic.net <mailto:RPD at afrinic.net>
> >>>> https://lists.afrinic.net/mailman/listinfo/rpd <https://lists.afrinic.net/mailman/listinfo/rpd>
> >>>
> >>> _______________________________________________
> >>> RPD mailing list
> >>> RPD at afrinic.net <mailto:RPD at afrinic.net>
> >>> https://lists.afrinic.net/mailman/listinfo/rpd <https://lists.afrinic.net/mailman/listinfo/rpd>
> >>
> >> _______________________________________________
> >> RPD mailing list
> >> RPD at afrinic.net <mailto:RPD at afrinic.net>
> >> https://lists.afrinic.net/mailman/listinfo/rpd <https://lists.afrinic.net/mailman/listinfo/rpd>
> >
> > _______________________________________________
> > RPD mailing list
> > RPD at afrinic.net <mailto:RPD at afrinic.net>
> > https://lists.afrinic.net/mailman/listinfo/rpd <https://lists.afrinic.net/mailman/listinfo/rpd>
>
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> RPD mailing list
> RPD at afrinic.net <mailto:RPD at afrinic.net>
> https://lists.afrinic.net/mailman/listinfo/rpd <https://lists.afrinic.net/mailman/listinfo/rpd>
>
>
> ------------------------------
>
> End of RPD Digest, Vol 156, Issue 6
> ***********************************
> _______________________________________________
> 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/20190916/7982afd7/attachment-0001.html>
More information about the RPD
mailing list