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

[rpd] [pdwg] AFRINIC Number Resources Transfer Policy Version 1.0

Fernando Frediani fhfrediani at gmail.com
Tue Oct 27 12:58:02 UTC 2020


I agree with Jordi's and Noah's messages in the sense Co-Chairs cannot
hold the publishing of a new proposal despite their personal beliefs. If
there are/will be issues with the new proposal that will be discussed
afterwards by the Working Group and I also ask the Co-Chairs to let it
go its natural path and not set this precedent.

Regards
Fernando

On 27/10/2020 07:57, JORDI PALET MARTINEZ via RPD wrote:

>

> Hi AK,

>

> I disagree. “The draft policy shall be …” then you have “The Working

> Group Chair(s) may …”.

>

> Note the order, this is plain English. You need to **do** in the

> stated order, not a different one.

>

> And you are missing the previous text in 3.4 which states:

>

> “Anyone can submit a proposal. Policy proposals are submitted to the

> Resource Policy Discussion mailing list (rpd at afrinic.net

> <mailto:rpd at afrinic.net>) by the author. AFRINIC will provide

> administrative support and assist the author(s) in drafting the

> proposal if requested. AFRINIC shall also provide relevant facts and

> statistics if requested during the discussion.”

>

> And you are also missing 3.4.1 previous paragraph:

>

> “During the development of policy, draft versions of the document are

> made available for review and comment by publishing them on the

> AFRINIC website and posting them to the rpd at afrinic.net

> <mailto:rpd at afrinic.net> mailing list. Each draft policy is assigned a

> unique identifier by AFRINIC and the AFRINIC website shall also

> contain the version history and the status of all proposals.”

>

> So, the order is:

>

> 1. Authors send a proposal. AFRINIC staff (not co-chairs) could offer

> support.

> 2. AFRINIC staff shall assign an identifies and publish in the web site.

> 3. Co-chairs could ask the staff for inputs (which it is actually

> done by default by staff already – analysis impact). But of

> course, co-chairs can ask for further clarifications, etc.

>

> The order is **extremely relevant** and if you change it, you violate

> the CPM. As you said, it is written in clear english!

>

> The PDP is our law and the interpretation is only possible **following

> the strict order**. Reordering means breaking it as it happens with

> any law!

>

> An example (a bit exagerated so is easier to see), if you have a law

> for speed limit in the road:

>

> 1. The driving speed limit in this road is 100 Km/h.

> 2. You get a fine.

>

> If you change the order, the consequence is clear, you get a fine,

> even if you aren’t over the speed limit!

>

> You said “*As an author of so many proposals yourself, you know quite

> well that it takes some time to process this thing and announce on the

> mailing list*”. Yes, what I do is to use the staff (staff, not

> co-chairs) path, because I agree that a proposal in the web site is

> **easier** to read, the staff can already provide the proposal

> indentifier, some times they may discover a typo, or do some

> suggestions, etc., and there **usually** there is no need to hurry up

> with the annoucement in the list. However what I’m doing, voluntarely

> is not a **must** for all the proposals/authors which follow the CPM

> just by sending it straitht to the list.

>

> Sometimes, in fact, I should said that this “publication” process is

> extremely slow, and should not be like that. The staff should be able

> to publish a proposal even if there were one every other day (which

> clearly is not the case, I’m just exigerating), because the time it

> takes to a) assign and ID, b) make it in the policy proposal web page,

> **realistically** takes just **minutes**.

>

> I also suggested the staff some time ago, they this can be simplified

> by an automated form (like LACNIC and APNIC is doing), which (if there

> is no inputs from the staff), could just mean the staf just need to

> “click” on the “publish” button to actually make it happen.

>

> I fully understand that this is not your day job, and fully recognize

> it, and I’m very thankful for that. I’ve said this many times: I

> prefer to send another 100 proposals before being a co-chair. However,

> this part of the process is for the **staff** not the co-chairs, so

> even if you have **any** reservation, you can’t do anything about

> that, you **can’t interfere** with this part of the process. Doing so

> it is plain blatant wrong.

>

> Regards,

>

> Jordi

>

> @jordipalet

>

> El 27/10/20 10:48, "ABDULKARIM OLOYEDE" <oloyede.aa at unilorin.edu.ng

> <mailto:oloyede.aa at unilorin.edu.ng>> escribió:

>

> Dear Jordi,

>

> Thanks for your mail. However, the section is not broken, it was

> written in clear English.

>

> Please read it again.

>

> The draft policy shall be available for review for at least four weeks

> before the next Public Policy Meeting. The author(s) shall make the

> necessary changes to the draft policy according to the feedback

> received. *The Working Group Chair(s) may request AFRINIC to provide

> an analysis (technical, financial, legal or other), of the impact of

> the draft policy proposal.***

>

> *Please note however that we never said we are not going to publish

> this proposal.  As an author of so many proposals yourself, you know

> quite well that it takes some time to process this thing and announce

> on the mailing list. We don't work on these things full time and we

> get busy too some times.  We have also had a meeting with you in the

> past before publishing one of your proposals. You know how this thing

> works sometimes. *

>

> *Yes, we have a reservation about this proposal because of a competing

> proposal is on the last call which is not an everyday situation

> therefore it requires that we look into it carefully. *

>

> *We would publish it as required by the CPM we only wanted to

> understand its impact on the community's time so that we can allow the

> community to make an informed decision about it. *

>

> *Please let us be patient and not jump into a quick conclusion. *

>

> Co-Chair

>

> PDWG

>

> On Tue, Oct 27, 2020 at 10:05 AM JORDI PALET MARTINEZ via RPD

> <rpd at afrinic.net <mailto:rpd at afrinic.net>> wrote:

>

> Hi AK, all,

>

> This is a totally broken interpretation of the PDP.

>

> Section 3.4.1 is referring to ask for an impact analysis **after**

> a proposal has been submitted and published.

>

> The PDP doesn’t allow the chairs to “hold” the publication of

> **any** proposal.

>

> The PDP, doesn’t disallow having competing proposals, **never

> mind** they are in any phase or even if they are “competing” with

> a ratified proposal.

>

> In fact, that’s part of the PDP!

>

> We may have a policy, let’s suppose we have already and Inter-RIR

> policy, and part of the community things is wrong. They have the

> right to present another proposal to amend it.

>

> It is just fine, and I will say very good, if you want to

> coordinate among different competing proposals authors to come

> together. Do you remember I asked for this before the Luanda

> meeting? But **that** can’t be used as an excuse to **hold** the

> publication of any proposal.

>

> Regards,

>

> Jordi

>

> @jordipalet

>

> El 27/10/20 6:56, "ABDULKARIM OLOYEDE" <oloyede.aa at unilorin.edu.ng

> <mailto:oloyede.aa at unilorin.edu.ng>> escribió:

>

> Dear Noah,

>

> A Section of 3.4.1 of the CPM reads ... "The Working Group

> Chair(s) may request AFRINIC to provide an analysis (technical,

> financial, legal or other), of the impact of the draft policy

> proposal..."

>

> We are in the process of asking AFRINIC to provide us with

> an analysis/advice of how to handle this proposal since a

> competing proposal is already in the last call.

>

> The community is made up of volunteers whose time are very

> precious. We want to reduce community burnout as much as we can

> and avoid wasting any one's time. You would agree with me that if

> the proposal in the last call is ratified then discussing this

> other one would amount to a waste of time. We have earlier

> received an analysis/advice on this issue and we this morning

> received a more detailed analysis/advice on how to proceed with

> this proposal and we would like to discuss this with you (the

> authors) so that we are all on the same page going forward. 

> Please give us a time that is most suitable for you (the authors)

> and we arrange a zoom meeting.

>

> In the meantime, we shall continue to carry out the necessary

> background work on this proposal.

>

> Please accept our apologies for any delay in communicating this to

> you.

>

>  Thanks

>

> Co-Chair

>

> PDWG

>

> On Mon, Oct 26, 2020 at 1:25 PM Noah <noah at neo.co.tz

> <mailto:noah at neo.co.tz>> wrote:

>

> Hi Co-chairs,

>

> The PDP does not allow Co-chairs to approve draft proposals

> submitted to the WG.

>

> The draft proposal has been submitted and is under discussion

> as per section 3.4 of the CPM and must be published by AFRINIC

> staff.

>

> Can you please tell the WG what you want to discuss with the

> authors during this call which we did try to discuss openly

> after you rejected our motivated submission for version 3.0

> with the reasons being that the proposal had expired.

>

> Cheers,

>

> *./noah*

>

> neo - network engineering and operations

>

> On Mon, Oct 26, 2020 at 7:31 AM ABDULKARIM OLOYEDE

> <oloyede.aa at unilorin.edu.ng

> <mailto:oloyede.aa at unilorin.edu.ng>> wrote:

>

> Dear Noah,

>

> It is not yet published because we are still looking into

> it and we are planning a meeting with the Authors sometime

> soon.

>

> Thanks and Regards

>

> Co-Chair

>

> PDWG

>

> On Sun, 25 Oct 2020, 19:20 Noah via pdwg,

> <pdwg at afrinic.net <mailto:pdwg at afrinic.net>> wrote:

>

> Attention PDWG Co-chairs,

>

> Any reason this proposal has not been posted online on

> the AFRINIC website?

>

> *./noah*

>

> neo - network engineering and operations

>

> On Sat, Oct 17, 2020 at 4:03 PM Noah <noah at neo.co.tz

> <mailto:noah at neo.co.tz>> wrote:

>

> Dear Working Group/Co-Chairs,

>

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

>

> Please find the proposals text below and also

> attached pdf format.

>

> Happiest Weekend,

>

> Noah on behalf of

> The Co-authors

>

> ================================================================

>

> Policy Name: *AFRINIC Number Resources Transfer

> Policy*

> ID: (Assigned by AFRINIC)

> Submission *Date: 17 Oct 2020*

> 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

>       Noah  Maina, noah.maina at seacom.com

> <mailto:noah.maina at seacom.com>, SEACOM

>       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.0 Summary of the problem being addressed by

> this proposal*

>

> *

> *The 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 addresses

> from other members solely within the AFRINIC

> region, based on justified needs. Considering the

> limited IPv4 space initially made available to

> AFRINIC (AFRINIC manages only 7.23 /8s with a very

> low ratio of IPv4 addresses per Internet user),

> there will therefore be a need to allow for unused

> IPv4 from other regions to move into the AFRINIC

> service region °V this without necessarily

> depleting AFRINIC's slim amount of IPv4 addresses

> by transferring space out of the region. 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.

>

>

> *2.0 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 the

> AFRINIC service region; and between the AFRINIC

> service region and other regions 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 resources in different

> categories and defines which transfer rules apply

> to each category.

> Only Legacy resources and resources transferred in

> from other regions will be transferable out of the

> AFRINIC service region.

> The policy also makes the following provisions:

> - Number resources are non-transferable 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.

> - IPv4 addresses and ASNs can be transferred only

> in accordance with this policy.

> - AFRINIC does not recognize transfers outside of

> approved transfer policies and requires

> organizations holding such resources to return

> them to the appropriate registries.

> The goal of this transfer policy is to help

> distribute resources from those who no longer need

> them to organizations that need the resources, but

> cannot obtain them from the AFRINIC free pools.

> AFRINIC recognizes the following types of transfers:

> - merger, acquisition, takeover or consolidation,

> - between AFRINIC members,

> - between an AFRINIC member and an organization in

> another region,

> - between a Legacy resource holder and an AFRINIC

> member,

> - between a Legacy resource holder and an

> organization in another region.

> 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. Currently, the other

> regions are APNIC, ARIN, LACNIC, RIPE NCC.

>

> *3.0 Proposal*

>

> *

> *Insert the following text into the CPM (numbering

> to be changed by staff as appropriate):

> 3.1 Definitions

> 3.1.1 "Resource" refers to IPv4 Address space or

> Autonomous System Numbers.

> "AFRINIC pool" means the 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

> resources distributed during the Exhaustion phases

> of the soft landing policy (section 5.4 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 transfers.

> 3.1.5 "Inter-RIR transfer" means the transfer of

> resources from a resource holder in the AFRINIC

> service region to an organization in another

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

> the resource to be transferred is "Reserved" then

> deny transfer. This restriction excludes mergers,

> acquisitions and takeover transfers.

>

> *3.4 Conditions on resources to be transferred*

>

> - The size of the IPv4 address prefix should be a

> minimum of /24.

> - The resource must qualify for the type of

> transfer requested.

> - The resource will be covered by AFRINIC policies

> after transfer into the region.

>

> *3.5 Conditions on the source

> *- Must be the 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.

>

> *3.6 Conditions on the recipient*

>

> - Will be subject to current AFRINIC policies.

> -  Must sign RSA.

> - Recipient that does not have prior resources must:

> ++ demonstrate a detailed plan for the use of the

> transferred resources

> (in the case of ASN, the 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, the 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

> counterparts RIR transfer policy.

>

> * 4. 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/>

> https://bgp.potaroo.net/iso3166/v4cc.html

> <https://bgp.potaroo.net/iso3166/v4cc.html>

> https://resources.potaroo.net/iso3166/ascc.html

> <https://resources.potaroo.net/iso3166/ascc.html>

> ftp://ftp.afrinic.net/stats/afrinic/transfers/

> <ftp://ftp.afrinic.net/stats/afrinic/transfers/>

>

> ================================================================

>

> _______________________________________________

> pdwg mailing list

> pdwg at afrinic.net <mailto:pdwg at afrinic.net>

> https://lists.afrinic.net/mailman/listinfo/pdwg

> <https://lists.afrinic.net/mailman/listinfo/pdwg>

>

> Website <http://www.unilorin.edu.ng>, Weekly Bulletin

> <http://www.unilorin.edu.ng/index.php/bulletin> UGPortal

> <http://uilugportal.unilorin.edu.ng/> PGPortal

> <https://uilpgportal.unilorin.edu.ng/>

>

> Website <http://www.unilorin.edu.ng>, Weekly Bulletin

> <http://www.unilorin.edu.ng/index.php/bulletin> UGPortal

> <http://uilugportal.unilorin.edu.ng/> PGPortal

> <https://uilpgportal.unilorin.edu.ng/>

>

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

>

>

> **********************************************

> IPv4 is over

> Are you ready for the new Internet ?

> http://www.theipv6company.com <http://www.theipv6company.com>

> The IPv6 Company

>

> This electronic message contains information which may be

> privileged or confidential. The information is intended to be for

> the exclusive use of the individual(s) named above and further

> non-explicilty authorized disclosure, copying, distribution or use

> of the contents of this information, even if partially, including

> attached files, is strictly prohibited and will be considered a

> criminal offense. If you are not the intended recipient be aware

> that any disclosure, copying, distribution or use of the contents

> of this information, even if partially, including attached files,

> is strictly prohibited, will be considered a criminal offense, so

> you must reply to the original sender to inform about this

> communication and delete it.

>

> _______________________________________________

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

>

> Website <http://www.unilorin.edu.ng>, Weekly Bulletin

> <http://www.unilorin.edu.ng/index.php/bulletin> UGPortal

> <http://uilugportal.unilorin.edu.ng/> PGPortal

> <https://uilpgportal.unilorin.edu.ng/>

>

>

> **********************************************

> IPv4 is over

> Are you ready for the new Internet ?

> http://www.theipv6company.com

> The IPv6 Company

>

> This electronic message contains information which may be privileged

> or confidential. The information is intended to be for the exclusive

> use of the individual(s) named above and further non-explicilty

> authorized disclosure, copying, distribution or use of the contents of

> this information, even if partially, including attached files, is

> strictly prohibited and will be considered a criminal offense. If you

> are not the intended recipient be aware that any disclosure, copying,

> distribution or use of the contents of this information, even if

> partially, including attached files, is strictly prohibited, will be

> considered a criminal offense, so you must reply to the original

> sender to inform about this communication and delete it.

>

>

> _______________________________________________

> 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/20201027/e3ae39f5/attachment-0001.html>


More information about the RPD mailing list