Search RPD Archives
[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