Info! Please note that this translation has been provided at best effort, for your convenience. The English page remains the official version.

AFRINIC-30 | Public Policy Meeting

 Date:   19th June 2019

Where:  Kampala, Uganda

Co-chairs:       Adewole Ajao, Sami Salih (remote) 

 

PDF Version

 

Agenda

  1. Welcome, Introduction & Agenda Overview
  2. Code of Conduct, The AFRINIC PDP
  3. Policy Implementation Experience Report
  4. Policy Proposal: Multihoming not required for ASN
  5. Policy Proposal: IPv4 Inter-RIR Legacy Resource Transfers

Policy Proposal: IPv4 Inter-RIR Resource Transfers (Comprehensive Scope)

  1. Policy Proposal: SL-Update
  2. Policy Proposal: IPv6 PI Clarification
  3. Policy Proposal: Abuse Contact Policy Update
  4. Policy Proposal: Internet Number Resources review by AFRINIC
  5. Policy Proposal: Provisions for Resource Hijacking
  6. Policy Proposal: AFRINIC Policy Development Process Bis
  7. PDWG Elections
  8. ASO/AC Elections
  9. Open Policy Microphone

 

1.0 Welcome, Introduction & Agenda Overview

Dewole welcomed delegates to the meeting, informed that this would be his last meeting as co-chair and went through the day’s agenda.

 

2.0 Code of Conduct, The AFRINIC PDP

A brief description of the PDP was shared as follows:

  • It’s an open, bottom-up and transparent process where anyone can submit a proposal and anyone can participate to policy discussions.
  • A policy proposal is submitted to the This email address is being protected from spambots. You need JavaScript enabled to view it. mailing list
  • The proposal is discussed on the list for a minimum of four weeks and presented at a public policy meeting for face-to-face discussions and consensus seeking.
  • If there is consensus at the face-to-face meeting, the proposal advances to a “last call period” that should last a minimum duration of 2 weeks, just in case there are issues from individuals that did not get a chance to participate. If there is no consensus at the face-to-face meeting, the proposal goes back to the mailing list discussion phase.
  • If consensus is maintained after close of last call, co-chairs recommend for the Board to ratify the policy proposal. The Board will ratify it and AFRINIC will implement it as a policy.

 

On the code of conduct, it was noted that:

  • The community is has people from different backgrounds and cultures
  • Anyone that participates in discussions either in person or remotely is expected to behave professionally and respectfully.
  • Harrassment, intimidation or offensive behaviour is not tolerated. Participants should treat others with politeness and respect.
  • Behaviour or remarks that give offence or discriminate based on gender, sexual orientation, religion, race or ethnic origin, language, or other perceived social, cultural, or personal differences should be avoided.
  • Personal attacks should be avoided.
  • Remarks should remain on-topic while respecting time allowed.

 

3.0 Policy Implementation Experience Report (PIER) 

Presentation: https://2019.internetsummit.africa/components/com_afmeeting/speakers/5785/1-2019%20PIER%20AIS19%20(1).pdf

This was presented by Kheesun Fookeerah (AFRINIC staff) who informed that the PIER contains information about recently implemented policies in one part, and staff experiences and recommendations while putting implemented policies in practice on the other part. The PIER also as usual will highlight on section of the CPM (Consolidated Policy manual) that are still ambiguous for staff to correctly interpret.

Keesun pointed out that policies recently implemented are IPv6 PI Update, Clarification on IPv6 sub-assignments and Lame Delegations in the reverse DNS. Implementation for some is not yet 100% as there are still some automation activities as yet ongoing.

Highlights from the PIER on ambiguous CPM content: 

  • CPM section 5.4 (Soft Landing) is assumed to be the default policy used in this exhaustion phase of IPv4 space, however, it does not align with some other sections of the CPM, such as the 90% utilization in 5.4 to qualify for additional addresses vs the 80% utilization in other sections.
  • CPM 5.7.1 allows for Intra-RIR transfers of IPv4 space, and does not cater for other resources such as ASN and IPv6. It is also not clear about how to cater for transfers as a result of mergers and acquisitions.
  • The section on Sub-Allocation windows with a 12 months cap on allowed space to be sub-allocated does not align with the 8-months cap in the Soft Landing policy.
  • During phase 2 of soft landing, the maximum allowable IPv4 space to be issued is /22 vs the other sections where /22 is the minimum.

 

Kheesun urged community members to study the above and if some new proposals to align CPM content are needed, members are encouraged to participate towards authoring proposals that will improve understanding and interpretation of the CPM. 

 

4.0 Policy Proposal: Multihoming not required for ASN 

Proposal URL: https://www.afrinic.net/policy/proposals/2019-asn-001-d2#proposal
Presentation: https://2019.internetsummit.africa/components/com_afmeeting/speakers/3283/2-Jordi-AFPUB-2019-ASN-DRAFT02.pdf

 

The author shared the following points with regard to this proposal:

  • When the ASN assignment policy was originally designed, the main concern was that 16 bits is a limited address space (RFC1930, section 9).
  • This is no longer an issue with 32-bit AS numbers (RFC6793). If each of the five RIRs were to assign 100 AS Numbers a day, 365 days a year, it would take over 20,000 years to deplete the 32-bit space.
  • When initial ASN policies were developed, the reliability of networks was not so good back then and it made sense that companies needing an ASN be multihomed.
  • Today this is not necessarily a reasonable requirement. Some networks may require an ASN while not willing to be multihomed.
  • The increased IPv6 deployment has also mandated the need for companies to announce their IPv6 space with their own ASN without the need to be multihomed.
  • The author stated that ARIN and LACNIC already have such a policy in place, and that an equivalent proposal reached consensus at APNIC47. He also stated that he will submit a similar proposal to the RIPE community very soon.

 

This proposal modifies the CPM by inserting a clause in 7.2, stating that organizations needing a globally unique ASN must demonstrate a unique routing policy or a plan to interconnect with one or more other Autonomous Systems. If the organization also demonstrates that it will meet any of these requirements criteria within six months upon receiving the ASN, then it will be eligible.

An overview of reactions from delegates: 

  • Multihoming or not has nothing to do with the number of bits, as this is no longer a concern or of any significance because all ASNs are issued by all RIRs from a 32-bit ASN pool, making the problem statement inaccurate.
  • RFC1930 contains guidelines for evaluating ASN requests and this proposal does not follow those guidelines. The evaluation processes need to continue sticking to RFC1930 guidelines as has always been the case.
  • An equivalent proposal adopted by some RIRs has not caused significant impact towards ASN consumption at those RIRs.
  • The proposal seems to suggest that every organization with IPv6 space can approach AFRINIC for an ASN and get it straight away.
  • The proposal seems to take away the need to evaluate ASN requests based on the need for those resources which presents some concerns.
  • Some noted that there is no need to align with RFC1930 and that policy should be flexible and not depend on RFCs.

 

Co-Chair Decision:

No consensus - The proposal needs additional discussion, therefore returns to the discussion stage on the mailing list. 

 

5.0 Policy Proposals: IPv4 Inter-RIR Legacy Resource Transfers

IPv4 Inter-RIR Resource Transfers (Comprehensive Scope)

Proposal URLs:

https://www.afrinic.net/policy/proposals/2019-v4-001-d1#proposal

https://www.afrinic.net/policy/proposals/2019-v4-002-d1#proposal

Presentation: https://2019.internetsummit.africa/components/com_afmeeting/speakers/3283/3-Jordi-AFPUB-2019-v4-001-002.pdf 

 

The author explained that these two proposals both allow for the transfer of IPv4 space to and from AFRINIC, but one allows only for the transfer of legacy IPv4 space from within AFRINIC while the other allows for all types of IPv4 space.

He stated that these are two different policy proposals trying to approach the same problem and instead of doing two presentations, it is much easier to have a single slide set because the difference between the content in these two policy proposals is only one sentence.

The first policy proposal - IPv4 Inter-RIR Legacy Resource Transfers allows for AFRINIC to receive any kind of IPv4 resources, but be able to transfer only to other regions, those IPv4 resources which are strictly legacy.

The second policy proposal -  IPv4 Inter-RIR Resource Transfers (Comprehensive Scope)

Allows for bi-directional transfer any kind of IPv4 resources.

The reason for having these two proposals is because there is a lot of concern by some people that if the door for transfers is opened, all IPv4 resources that we have in the region will go out. Such people’s concerns is addressed by the first proposal, so that only legacy space can go out of the continent. Author noted that whichever proposal is accepted will automatically get the other proposal abandoned.

More remarks from the author:

  • At the moment, all the other regions have already in place a policy proposal for transfers, and all those have no restrictions.
  • With Africa not having sufficient IPv4 resources, limiting the option for incoming transfers of IPv4 space makes difficult the opportunity to create new businesses that will need IPv4 resources. To make matters worse, phase 2 of soft-landing will make the number of resources that organisations within AFRINIC can get much smaller.
  • There is already a market situation where AFRINIC member organisations are selling resources illegally and under the table, this policy only makes it official such that such transactions are actually reflected officially in the whois db when they happen.
  • Deploying IPv6 now requires some IPv4 space. If there isn’t any left and no transfer mechanism to bring some into the continent, IPv6 adoption will stagnate.

 

Reactions from the floor and remotely:

  • There were several statements read in support of the proposal to allow for Inter RIR transfers of IPv4 space.
  • Concerns were raised about the fact that we do not necessarily have to do what the other RIRs have done as their specificities may not apply to Africa and AFRINIC.
  • It was noted that AFRINIC resources should be strictly used in Africa as the region is still growing in internet connectivity.
  • There were requests that an audit of resource usage especially those in the market as stated by the author be conducted to guide the community on a way forward.
  • It was noted that the problem statement is not accurate and contains some content that should be removed.
  • Some speakers stated that when IPv4 space eventually gets depleted in AFRINIC, this proposal will enable inward movement of space into Africa, which is a good thing for the continent.
  • AFRINIC resources should be transferred only within the continent for now even after exhaustion, and not outside. However incoming resources should do no harm as long as there is none outgoing.
  • It was pointed out that communities like ARIN will insist on reciprocity for fairness, so they will not allow to transfer into Africa if Africa cannot transfer to them.

 

Co-Chair Decision:

No consensus - These two proposals need additional discussion, therefore return to the discussion stage on the mailing list.

 

6.0 Policy Proposal: SL-Update 

Proposal URL:

https://www.afrinic.net/policy/2018-v4-001-d1#proposal

Presentation: https://2019.internetsummit.africa/components/com_afmeeting/speakers/3283/3-Jordi-AFPUB-2019-v4-001-002.pdf

Authors shared the following highlights for this proposal:

  • In CPM section 5.4.7.1 (soft landing policy) a /12 is reserved from the last /8 for some unforeseen future uses.
  • In the same CPM 5.4.7.2, the Board at its discretion and considering the demand and other factors at the time when AFRINIC can no longer meet any more requests for address space from the last /8 or any other available address space, can replenish the exhaustion pool with whatever address space (or part thereof), that may be available at the time and do this in a manner that is in the best interest of the community. 

Section 5.4.7.2 therefore gives board the sole authority to decide on how to use the reserved /12 block to eventually replenish the exhaustion pool and determine its  allocation and assignment rules. This mandate should be determined by the community and not by the board.

  • If no community-driven policy is adopted to determine how to use the reserved space before the exhaustion of the pool, board may act at its discretion with or without community involvement and consent.
  • The community is in better position to determine what is in its best interest and this is better discussed through PDP.

 

Authors therefore propose that 5.4.7.2 be worded like “If the reserved /12 remains unused by the time the remaining available space has been allocated, the /12 will be returned to the AFRINIC pool for distribution under the conditions of the phase 2 of the soft landing policy” – hence giving community power to decide how to use this /12.

Authors further pointed out that this policy proposal was initially presented at Hammamet in Tunisia but sent back to the mailing list for more community inputs and refinements. However, none were received hence it is still the same version from Hammamet.

 

Co-Chair Decision:

Consensus – The proposal advances to Last Call.

 

7.0 Policy Proposal: IPv6 PI Clarification

Proposal URL: https://www.afrinic.net/policy/proposals/2019-v6-001-d2#proposal

Presentation: https://2019.internetsummit.africa/components/com_afmeeting/speakers/3283/2-Jordi-AFPUB-2019-v6-001-DRAFT02.pdf

The author shared the following highlights from this policy proposal:

  • A policy proposal called “IPv6 PI Update” was passed in Hammamet at the last AFRINIC meeting and has been implemented.
  • That proposal overlooked some issues from the existing policy, notably - the need to demonstrate that the PI IPv6 space issued must be announced within twelve months and that if not announced, the space should be reclaimed and returned to the free pool by AFRINIC.
  • In some use cases however such as IXPs, space will never be announced.
  • This proposal therefore corrects this with new proposed text : “If the addressing space issued under this policy is to be announced, to the extent practicable, the organization should aggregate any announcements of prefixes so as to minimize global routing table growth”

Reactions received were mostly statements of support for the policy proposal.

 

Co-Chair Decision:

Consensus – The proposal advances to Last Call. 

 

8.0 Policy Proposal: Abuse Contact Policy Update

Proposal URL: https://www.afrinic.net/policy/proposals/2018-gen-001-d3#proposal

Presentation: https://2019.internetsummit.africa/components/com_afmeeting/speakers/3283/3-Jordi-AFPUB-2018-GEN-001-DRAFT03.pdf

Summary of the problem as shared by the author: 

  • The current abuse contact registration policy doesn’t have the simple obligation to register an abuse contact towards one single email address meant for this purpose.
  • As a result, some members may not have this contact information registered and up to date for their resources. In fact, there are even cases of members that use a non-existent mailbox or one that is not actively monitored.
  • In practice, this contact becomes ineffective for reporting network abuse activity and generally gives rise to security issues and related costs to the victims.
  • This proposal aims to solve this problem and ensure the existence of a proper abuse contact and a process for its validation, which makes it uniform across all RIRs. This in turn facilitates cross-region abuse reporting.
  • The existing policy refers to a “Best Practice Paper”, which is not deemed mandatory - in fact, is not being used by the community. This proposal doesn’t change the scope of that document, and in fact, a link between the few existing IRT objects and the new abuse-mailbox proposed here should be automatically established.
  • This proposal allows for a simple, periodic verification of a stated abuse contact, and establishes the basic rules for performing such verifications.

 

The author stated that the proposed abuse-c attribute will be mandatory in the “aut-num”, "inetnum" and "inet6num" objects, as well as in any others that may be used in the future. This attribute is an abuse contact, which must contain at least the "abuse-mailbox" attribute. 

Reactions were received as follows: 

  • The staff commented that there is already an IRT object in the database which can hold more information other than an e-mail address and recommended that it is better to make the IRT mandatory.
  • Author clarified that the IRT can stay and it can be made an alias. He also stated that other RIRs are not using the IRT.
  • The staff clarified that it is confusing to use IRT as an alias and would not know how to implement such a requirement.
  • It was noted that AFRINIC as a registry must make sure that by contract with members it has most accurate information about these members. Staff pointed out that abuse contact information is not usually requested in the signed contracts with members.
  • It was pointed out that before, there was denial or right to vote if abuse contacts cannot be verified, which punishment is not proportional to the cause.
  • There were several concerns that this policy may not be needed and that AFRINIC can internally have such a mechanism through the RSA. It was proposed that this be made an internal AFRINIC process (rather than a policy) to collect and validate abuse contacts, just like AFRINIC must be collecting and validating other types of contacts without need for a policy.
  • Some statements opposing the proposal were received, some noting that AFRINIC is a registry, not the internet police and should act as a registry.

 

Co-Chair Decision:

No consensus - The proposal needs additional discussion, therefore returns to the discussion stage on the mailing list.

 

9.0 Policy Proposal: Internet Number Resources review by AFRINIC

Proposal URL: https://www.afrinic.net/policy/proposals/2016-gen-001-d8#proposal

Presentation: N/A

The authors shared these remarks:

  • This policy proposal enables AFRINIC to conduct an audit or review of all resources held by members.
  • Authors noted that resources at AFRINIC are not for sale – but are communal and are in place for the sake of the needs of the continent. It is against this belief that this proposal and its sentiments are based.
  • It is very important that member resources comply with the RSA as signed by the same members.
  • The proposal has evolved through many changes until the latest version.
  • For most of the policy provisions in the proposal, it is the authors belief that despite the politics and sentiments, all issues have so far been addressed.

Reactions from the floor and remote participants:

  • At the last AFRINIC meeting, authors attempted to force audience to accept the proposal which was not right.
  • The proposal will lead to instability in the community if resources will be taken back whenever a member appears to violate the policy.
  • AFRINIC may not have the resources to handle the volume of audits or reviews that could come up if this proposal passes.
  • The proposal may not be enforceable by AFRINIC. The proposal could be improved to target those using the addresses in a black market in order to minimize the black market. Although authors stated that resources are not for sale, actual sales are happening in a secondary market.
  • There is need to establish why some resources may not be used for the original purpose for which they were issued, as this seems to be the basis for the policy. The need may have changed but could still be legitimate.
  • Many arguments against this proposal have been submitted to the mailing list several times, are on record and the proposal has failed to achieve consensus many times before and should be abandoned.
  • It was proposed that due to the many times the proposal has been presented and not gained consensus, authors should withdraw it.
  • The RSA already has provisions for reviews that are suggested by this proposal hence the proposal is a duplication of the RSA which is unnecessary. The RSA mandates resources to be recovered if a member is in breach.
  • This proposal aligns with the needs-based approach that the policy requires, and hence an audit for need is always relevant to check that this is still the case.
  • There were several other statements against, and a few others in support.

 

Co-Chair Decision:

No consensus - The proposal needs additional discussion, therefore returns to the discussion stage on the mailing list.

 

10.0 Policy Proposal: Provisions for Resource Hijacking

Proposal URL: https://www.afrinic.net/policy/proposals/provisions-for-resource-hijacking#proposal

Presentation: https://2019.internetsummit.africa/components/com_afmeeting/speakers/3283/Provision%20for%20Resource%20Hijacking.pdf 

Author remarked that this proposal is about respecting members’ exclusive rights to the allocated/assigned resources where other parties aren’t authorized to use those resources without consent.

The author acknowledged that this proposal is not a matter of routing because AFRINIC is not the routing police, and that policy violations will be considered as those cases where there was clear and intentional hijack and use of resources by another party.

The author proposed a simple process where a victim reports a resource hijack, involved parties get notified about the matter, experts review and investigate based on data available and issue a report from their investigation. A period is allowed for parties to submit any objections, and an appeal could be submitted after this. If the appeal fails, the report is ratified and the issue is considered a policy violation, otherwise the matter is dismissed. This whole process should take a maximum of 6 weeks.

The author noted that it is better for the community to have such a process rather than leave it to governments to control and intervene. He also stated that he has submitted a similar proposal to each RIR community.

 

Reactions:

  • It was noted by a few people that although the problem of hijacking IP address space is real, the PDP in an RIR community is the wrong forum to address it as there is no mechanism for enforcement.
  • RIRs do not have the right to determine the right-to-use the address space although through accurate registration some verification is possible.
  • Others noted that the RIR can determine right-to-use of those resources, and that the LIR too can determine to some extent.
  • There were some statements opposing the proposal and none in support.

 

Co-Chair Decision:

No consensus - The proposal needs additional discussion, therefore returns to the discussion stage on the mailing list. 

 

11.0 Policy Proposal: AFRINIC Policy Development Process Bis

Proposal URL: https://www.afrinic.net/policy/proposals/2017-gen-002-d5#proposal

Presentation: https://2019.internetsummit.africa/components/com_afmeeting/speakers/3283/Provision%20for%20Resource%20Hijacking.pdf

Authors indicated that in this 5th version of the proposal, the problem statement has largely remained the same. Policies for managing IP number resources in the AFRINIC service region are created through a Policy Development Process which describes the steps through which policy proposals are submitted, considered, debated and adopted. The current consolidated policy manual does not have provision for proposal adoption, which looks at duplication of proposals dealing with the same problem, lack of clarity of problem statements and proposals out of scope of the PDP. It also does not define clear methods for moving proposals forward.

The consensus process for decision-making is also not defined, opening doors for differing interpretations and inactions. The current PDP also does not have provisions for board adopting policies as per section 11.4 of the AFRINIC by-laws in varying of the process. 

It was stated that since the AFRINIC public policy meeting in Hammamet, co-chairs invited those objecting to work with authors, and issued a request to improve the last call definition as well as the definition of consensus.

Authors also attempted to clarify implementation time after ratification and proposed to offer a 2 week maximum duration for chairs to move a proposal to last call. The issue of competing proposals is therefore addressed from the start. There was also the need for staff to provide more information in their assessment reports.

New additions in version 5 also include the fact that consensus is declared after last call (concluding phase) and that appeals can be filed against the results of the adoption phase.

There is a guidelines document included with this proposal and will be part and parcel of the proposal and finally the CPM if adopted. This document contains addition of travel assistance to proposal authors (at staff discretion).

Reactions received were as follows:

  • The proposal addresses many current problems in the PDP, many of them witnessed by the appeals we have had so far and the many threats to appeal.
  • The proposal was opposed by some due to its complexity. The several phases and separate documentation only make it more complex to implement.
  • A PDP that does not allow for competing proposals is not good, since competition is healthy and allows for improvements.
  • An appeal should be started by several community members and not just one person.
  • The chairs should not decide on the content of the problem statement as this would mean they are micromanaging the community and the process.
  • The process needs to allow for mailing list discussions to contribute equally to face to face discussions.
  • Some statements supporting the proposal as a step in the right direction to improve the current PDP.
  • It was pointed out that specific problems of the current PDP have not been adequately addressed one at a time, and a complex attempt like this one will not be effective.

 

Co-Chair Decision:

No consensus - The proposal needs additional discussion, therefore returns to the discussion stage on the mailing list. 

 

12.0 PDWG co-Chair Elections 

The election was for PDWG co-chairs to replace both Sami Salih and Dewole Ajao. The session was led by Serge-Parfait Goma, the chairperson of the 2019 Nominations committee who informed that there were 8 nominees for the 2 positions. The nominees presented were:

 

Mark Elkins

Caleb Ogundele

Komi ELitcha

Sami Hassan

Moses Serugo

Taiwo Oyewande

Ikechukwu Anthony Ubah

Abdulkarim Oloyede

 

After candidates spoke to the delegates, the elections committee conducted a voting exercise where participants were asked to select their two preferred candidates - the candidate with the highest number of votes getting the two-year term, and the runner-up getting a 1 year term.

Voting returned the following winners:

Moses Serugo (UG) was elected for a two-year term, from June 2019 to June 2021;

Abdulkarim Oloyede (NG) was elected for a one-year term from June 2019 to June 2020.

 

13.0 ASO/AC Elections

The chair of the nominations committee presented the candidates as follows:

Mike Silber

Mustafa Ben Jemaa

 

The elections committee conducted a secret ballot voting exercise to select one person that will replace Omo Oaiya whose term expires at the end of 2019. After the voting, Mike Silber (ZA) was elected for a three-year term, from January 2020 to December 2022.

 

14.0 Open Policy Microphone

Dewole informed that the open MIC is to allow for comments that were deferred during the day, as well as others from the remote participants and those that could have been raised on the mailing list.

  • Revisit the code of conduct and how it is enforced. Many comments on the list and meeting violate this code. We should not be hostile and rude to each other, which makes the PDP environment also an unhealthy one.
  • Co-chairs were advised to use their powers to call to order anyone that is rude and disrespectful to others.
  • CPM does not state how the PDWG co-chair election process should be. It states that community should participate but does not state who constitutes the community. This needs a clear process moving forward.
  • There were several congrats messages to new co-chairs, as well as votes of thanks to the outgoing co-chairs for a job well done.
  • A vote of thanks to Alan for doing a great job as the outgoing CEO.
  • The code of conduct at LACNIC had similar issues and they made an Acceptable Use Policy which solved these issues. It would be nice for a volunteer to bring up something similar. The LACNIC region also proposed a process for co-chairs election in order to have it organized and it is working well.
  • There is a need to involve more people into the mailing list discussions.
  • There could also be some informal but open meetings to discuss policy proposals days before they are presented, as this could improve involvement.
  • A participant mentioned that he is happy to assist anyone with an idea of a policy proposal to help them do it, even if he will not be recognized as co-author.
  • The AFRINIC Board chair thanked outgoing co-chairs for a job well done and congratulated new co-chairs.
  • There is a need for recognizing remote participants into both the policy discussions and voting towards all elections.
  • Outgoing co-chairs were urged to provide support to the incoming ones. Incoming co-chairs were advised to not be afraid to seek advice and consult where necessary. 
Print Friendly, PDF & Email
Last Modified on -