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

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

Arnaud AMELINA amelnaud at gmail.com
Tue Oct 27 13:49:24 UTC 2020


Je suis tout à fait d'accord avec tout ce que mes prédécesseurs ont dit
spécialement Mirriam. Un engagement volontaire n'est imposé à personne et
si tu candidates en tant que volontaire tu dois être prêt à tout assumer,
ne rien décider au nom de qui que se soit mais assumé personnellement.
Merci de faire diligence pour publier la proposition de politique, car
actuellement c'est plutôt toi Co-chair qui nous pers le temps.

Cordialement

Arnaud

Le mar. 27 oct. 2020 à 13:01, Fernando Frediani <fhfrediani at gmail.com> a
écrit :


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

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

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

> Noah Maina, noah.maina at seacom.com, SEACOM

> Adeola A. P. Aina, 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.potaroo.net/tools/ipv4/

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

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

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

>

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

>

>

>

> _______________________________________________

> pdwg mailing list

> pdwg at afrinic.net

> 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 https://lists.afrinic.net/mailman/listinfo/rpd

>

>

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

> 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

>

>

>

> 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 listRPD at afrinic.nethttps://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/20201027/04b370e9/attachment-0001.html>


More information about the RPD mailing list