AFRINIC-29 | Public Policy Meeting - PPM Minutes - AFRINIC - Regional Internet Registry for Africa

Policy Development Process (PDP)

AFRINIC-29 Public Policy Meeting

Minutes of the PDWG meeting held on 29 November 2018

Hammamet, Tunisia

**PDF Version **

Session Co-Chairs: Sami Salih, Dewole Ajao

Agenda:

Welcome, Introduction & Agenda Overview
The AFRINIC PDP
**Policy Implementation Experience Report **
Policy Development Update from other RIRs
Proposal: AFRINIC Policy Development Process Bis v4
Proposal: Simple Update of the PDP
Proposal: Abuse Contact Policy Update
Proposal: Internet Number Resources review by AFRINIC
Proposal: Clarification on IPv6 Sub-Assignments
Proposal: Inter-RIR Resources Transfer
Proposal: IPv4 Soft Landing BIS
Proposal: SL-Update
Open Policy Microphone

1. Welcome, Introduction & Agenda Overview

The session was introduced by Ernest Byaruhanga who welcomed delegates to the meeting, introduced the co-chairs (Dewole and Sami), thanked them for their efforts and urged delegates to afford them full cooperation.

Sami presented the draft agenda which was adopted without changes.

He also stated that the AFRINIC Code of Conduct shall guide discussions for the day, and that it emphasizes politeness, mutual respect, no discrimination, no personal attacks, respect of the agenda and time, toleration of language differences and the need to always act in the best interests of the AFRINIC community.

2. The AFRINIC PDP

Sami presented the AFRINIC Policy Development Process, and stated that it’s based on the principles of a bottom up approach and openness. A proposal can be posted by anyone to the rpd policy list which is open, discussed for at least 4 weeks, and is then presented at a public policy meeting. A proposal is then sent to last call if it attains consensus at the public policy meeting (else it goes back to list for another 4-week discussion). If no issues during last call, co-chairs send a report to Board recommending ratification, and the Board ratify and ask staff to implement, provided that the process was properly followed.

Reactions and questions received:

How do co-chairs enforce the Code of Conduct? Co-Chairs clarified that this is an internal matter at co-chairs discretion at the moment.
Does Board always ratify a proposal when advised by co-chairs? When can Board object/reject a policy or ask community to make extra inputs? Co-Chairs stated that the Board only ratifies based on whether the proposal followed the process or not. They added that the proposal goes back to the list if the Board does not ratify it.
Some proposals on the agenda appear to be in violation of the PDP, because of the 1-week submission deadline before the PDP. Co-Chairs clarified that the proposal in question was submitted on time, but was not published (nor posted to the list) on time. They proposed that in future, the co-chairs will not wait for website publishing of a received proposal, and will post it to the list right after it is received.

3. Policy Implementation Experience Report

This was presented by James Chirwa, AFRINIC Senior IP Analyst. The report highlights on key policy aspects (and gaps) whose implementation (translating into actual distribution of number resource to members while handling requests) could be better clarified so staff can better understand and interpret those aspects and close those gaps.

Highlights from the report:

Policies recently ratified are as follows:
IPv6 Policy & References Update – which was implemented on 23 November 2018 and is active.
IPv6 Initial Allocation Update – also implemented on 23 November 2018 and is active.
IPv6 PI Update – under implementation, pending automation of some policy requirements (tools to check that IPv6 PI space that has been assigned to members is routed and not disaggregated).
Lame Delegations in the AFRINIC reverse DNS – was implemented (partially) on 28 September 2018. Lame records for domains and name servers are not yet beimg deleted and the statistics page is in the works. AFRINIC is supporting members concerned to correct these lame delegations.
Conflicts and Ambiguities in the Policy Manual:
CPM 5.4.6.1 stipulates 90% utilization of all issued space before a member can receive subsequent space, which conflicts with 5.5.1.4.1 (80% utilization) and 5.6.3 (50% utilization rates in 1 year)
CPM 5.7.1 allows for inter-RIR transfers of IPv4 space, but there are some members that wish to transfer ASN and IPv6 resources due to, for example, mergers.
CPM 7.4.2 on the multi-homing requirement for an ASN to be issued – yet some members need an ASN and are running BGP – but with one connectivity provider.
CPM 5.2.1.2 – the requirement that an LIR registers IP address assignments for its customers. Some of these assignments show names of companies that are not accurate or correct, sometimes intentionally created by the LIR to falsify information.

In the case of the above ambiguities, the community is urged to look into the CPM and propose policy changes to correct these issues.

Reactions:

A member indicated that he is happy to write policy proposals for each of the items listed above, but encouraged individuals that have not authored policies before to come up and write policies to address these issues.
It was suggested that particular AFRINIC members that triggered the above issues (and were directly impacted) could be encouraged to propose policies to address these ambiguities.
It was suggested that staff write a public policy implementation plan containing the different ways the policy will impact members. This document should be announced to members when availed. A participant suggested that this section could be part of the staff assessment report as an initial draft.
On the issue of various conflicts in the CPM, the ARIN method of indicating what has been deleted could be used, such that deletions can easily be known or seen publicly.

4. Policy Development Update from other RIRs

Updates were received from and shared by the respective RIR representatives as follows:

APNIC:

Validation of abuse mailbox policy proposal (similar to the one to be discussed here) was approved at apnic-46 and is waiting the Executive Council’s consideration.
“No need” policy aiming to abolish the needs assessment check on all transfer requests at APNIC did not pass through at APNIC46
Clarification on IPv6 sub-assignments (also similar to the one on the agenda for this meeting) introduces a process that disallows provisioning of v6 space to third party devices outside the network infrastructure of the holder of the PI space. This did not reach consensus at APNIC46.
PDP Update – a proposal that updates the APNIC PDP to include remote participation towards consensus decisions, adjust the time required to submit a proposal ahead of a public policy meeting and put in place a simpler appeals mechanism. It did not reach consensus at APNIC46

ARIN:

Clarification to ISP initial allocation: Adjusts the IPv4 initial allocation policy to allow companies without IPv4 space to qualify for a /24 automatically, and larger if need is demonstrated.
Disallow third party organization record creation: requires that organization records shall be created by the entity represented by the organization record, and only through an explicit request to ARIN.
Clarify reassignment requirements in 4.2.3.7.1: Simplifies reassignment requirements such that only a customer’s name is required and not any other information.

LACNIC:

Inter RIR transfer policy. This establishes a mechanism to allow the transfer of resources (IPv4, IPv6, ASNs) between different regions and to align LACNIC with an existing market in which the region is not currently participating. The proposal is similar to the one on the agenda for AFRINIC29, and allows only legacy IPv4 space to be transferred outside LACNIC
Acceptable Use Policy for the policy mailing list: Proposes an Acceptable Use Policy (AUP) for the Policy List, as no such document currently exists at LACNIC. It is proposed as a result of several incidences of annoying activities that are contrary to the LACNIC policy list’s purpose and spirit, including cases of misuse, various personal attacks and electoral propaganda seen many times on the LACNIC policy list.
Minor Revision of the PDP: Correct a flaw in the LACNIC PDP whereby if a policy proposal does not reach consensus and the comments it receives are not enough to show the author “a way forward,” as written, the current text would force the authors to “artificially” submit a new version in order to keep the original proposal under discussion.
Clarification on IPv6 sub-assignments - also similar to the one on the agenda for this meeting) introduces a process that disallows provisioning of IPv6 PI space to third party devices outside the network infrastructure of the holder of the PI space.
Registration and validation of abuse-c and abuse-mailbox: Because it is not clear whether abuse contact information can be attached to some resource data in the LACNIC whois db. It is not clear whether abuse contact information can be attached to some resource data in the LACNIC whois db.
This proposal aims to solve the problem by ensuring the existence of a proper abuse-c contact and a process for its utilization, this proposal aims to solve the problem by ensuring the existence of a proper abuse-c contact and puts in place a process for its utilization.

RIPE:

Regular abuse-c validation: Gives RIPE NCC the mandate to annually validate abuse email addresses and to follow up when these are invalid. The proposal was approved at the last RIPE meeting.
Organization LIR clarification in the IPv6 policy: Clarifies on LIR allocations per LIR account – the old policy used to state that an IPv6 allocation is given to an organization, and did not clarify the organization type. This is also already implemented.
Fixing outdated information in the IPv4 policy: This proposal removes some outdated references in the relevant IPv4 policies./
PDP clarification: Makes clear what actions can happen in the “review phase”, which was not very clear.
Assignments clarification in IPv6 assignments – aims to clarify the definition of “assign” in IPv6 policy.
Publication of Legal Address of Resource Holders in the RIPE database: The goal is to publish the legal and validated address information of resource holders in the RIPE region. The author has been asked to make some clarifications.
RIPE NCC IRR database non-authoritative route object clean-up: The goal is to delete non-authoritative route objects stored in the RIPE routing registry if it conflicts with an RPKI ROA.

5. Proposal: AFRINIC Policy Development Process Bis v4

The proposal was presented by the authors, who shared the following highlights:

The current PDP is 10 years old, and the authors initiated the process to amend it in April 2017, now at version 4.
Feedback received from the last meeting was to remove anonymity of proposal authors, remove the possibility of policy co-chairs to be document editors, remove inclusion for Council of Elders, and allow about 2 weeks for for co-chairs to declare consensus (after adoption phase) and after the public policy meeting.
The proposal was updated to include all community feedback above.
There have been no substantial discussions on the updated proposal, and no suggestions or inputs from the community (including text promised by some members).
However, a new competing proposal was instead received (Simple PDP Update).
Authors asked co-chairs for a way forward.

Reactions were received as follows:

Co-Chairs indicated that proposals should be looked at in the best interest of the community, not the persons authoring these proposals.
Co-Chairs called for the author of the proposal “Simple Update of the PDP” to also present it, such that discussions on merits of both can take place after both have been presented, allowing community to discuss objectively and co-chairs to take better decision thereafter.

6. Proposal: Simple Update of the PDP

The author shared the following highlights from this proposal:

While anyone may participate to policy discussions either in the mailing list (RPD) and/or at the bi-annual Public Policy Meetings, not all RPD participants are able to attend all the actual face to face meetings where the Chairs determine rough consensus on proposals – and this is the larger section of the community. With this requirement to make consensus decisions at face-to-face meetings, this might be in part the cause of the low levels of community participation to the policy process.
This proposal simplifies the process by not requiring in-person participation to the Public Policy Meetings for a proposal to achieve consensus – instead, consensus would be determined balancing contributions from the mailing list and the meeting – which would therefore increase community participation.
The various timelines are also adapted to this change, with some scenarios as follows
A proposal (or a new version) is submitted 8 weeks (or a longer period) before the PPM. Consensus will be determined by the chairs within a maximum of two weeks.
A proposal (or a new version) is submitted less than 8 weeks before the PPM. Consensus will be determined by the chairs within a maximum of two weeks, once the 8 weeks of discussion time on the list ends.
The minutes timing is also adapted, as it seems unnecessary to wait for 3 weeks, if the consensus determination will be made in 2 weeks.
Proposal therefore eliminates the requirement that consensus must only be reached at the PPM. It adapts the relevant timings and at the same time, clarifies the definition of “consensus” and “last call”.
The definition of consensus is adapted to align with the rough consensus concept of the IETF.
Various changes to the timelines are proposed, including the fact that co-chairs only announce changes to earlier consensus decisions within the 1 week after last call period.
Author indicated that a similar proposal reached consensus in the LACNIC region in May 2018 and has already been implemented.

Reactions received:

The author of the proposal “PDP-bis” indicated that there are many similarities between the two proposals, like staff assessment and process for rough consensus (as it’s not just about the definition). The author of “Simple PDP Update” indicated that the PDP-bis proposal is complex, due to the many (five) different phases, and that it needs to be simplified.
It was noted that proposals in AFRINIC should not be likened to those in the LACNIC region and other regions.
Author of this proposal said he read the PDP-bis proposal carefully and found 15 very weak points and many missing issues that he pointed out to authors and is willing to point these out if both sides can be open to discuss.
Co-Chairs indicated that there is no official record of the above issues on the mailing list.
It was noted by several individuals that there are many points in both policy proposals that are very constructive and therefore the authors from the two sides should work together to come up with one version of the proposal that is much improved.
A few individuals indicated that the current PDP does not have any major problems that need fixing, rather, many individuals are looking for ways to manipulate the process for personal interests – and this issue can remain irrespective.
Some members urged co-chairs from refrain from accepting such competing proposals, but co-chairs pointed out that they have no such mandate according to the PDP, but can encourage parties to work together.
As mentioned before, although the process allows for several competing proposals to be on the table, good-will should be used such that we do not end up in such a situation. The author of “Simple PDP Update” indicated that it is not necessarily a bad idea to have competing proposals as it allows the community to study different view-points.
One of the proposals favours remote participants, and this is a good thing as many people cannot travel due to time and financial constraints.

Co-Chairs advised that authors of the two competing proposals consider working together to come with a unified proposal that combines the two strong points from both proposals, for the benefit of the community having a much broader and improved PDP.

The author of “Simple update of the PDP” decided to withdraw his policy proposal and indicated that he has strong expectation that he will work together with authors of the policy proposal “AFRINIC PDP-bis” in this effort to improve the PDP.

Authors of “AFRINIC PDP-bis” urged that in the effort to work together, there needs to be mutual respect, since this will include merging of strong opinions from two separate parties.

Co-Chairs decided to return the AFRINIC PDP-bis proposal back to the list and initiate a process of engaging the two parties to work towards an improved version taking points from the two proposals into consideration.

7. Proposal: Abuse Contact Policy Update

The author shared the following highlights from the proposal:

The current CPM 8.0 (specification of abuse contact information) doesn’t make it mandatory to register an abuse contact. As a result, many members may not have this contact information for their registered and up to date for their resources.
There could be instances where members use a non-existent e-mail addresses or one that is not actively monitored, which makes it difficult to report abuse from such networks and generally gives rise to security issues and even costs for the victims.
This proposal aims to solve this problem by ensuring existence of a proper abuse contact for each issued resource and also a process for keeping this information accurate. The policy has been proposed at all RIRs to have a uniform method globally for inter-region abuse reporting.
The existing policy at CPM 8.0 references a “Best Practice Paper”, which is not mandatory and does not appear as being used by the community.
The best practice paper suggests an IRT object, and this proposal recommends that the proposed abuse-c and the IRT in the BCP be automatically linked. This way, AFRINIC abuse contact processes will align with other RIRs. APNIC is now using the IRT, but since an equivalent proposal has been accepted, an automated “link” with the existing IRT will be created, so abuse-c and abuse-mailbox will still be prevalent.
There is no need to delete other optional data today included in the IRT. This policy just ensures that the abuse-mailbox is available and verified periodically.
Although the Internet community is based on collaboration, this is in many cases not enough and we all need to be able to contact those ISPs that may be experiencing a problem in their networks and are unaware of the situation.
This proposal creates a new section in the Policy Manual to solve this problem by means of a simple, periodic verification, and establishes the basic rules for performing such verification and thus avoids unnecessary costs to third parties that need to contact the persons responsible for solving the abuses of a specific network.
The proposal guarantees that the cost of processing the abuse falls on the LIR whose client is causing the abuse (and from whom they receive financial compensation for the service), instead of falling on the victim, as would be the case if they had to resort to the courts, thus avoiding costs (lawyers, solicitors, etc.) and saving time for both parties.
For this, the abuse-c attribute becomes 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.
The proposal is expected to be implemented by AFRINIC within a reasonable time frame that allows both the staff to develop the necessary software and the members to update their abuse-c contacts.
Author indicated that although AFRINIC had proposed that operational details and complex verifications be removed from the proposal, it is important that they remain as these are a core function in abuse e-mail verifications.
A similar proposal has been accepted in APNIC (is being implemented) and is under discussion in the LACNIC and RIPE regions.

Reactions from the community were as follows:

Contact information verification is important from the context and work of CERTs.
What happens when members do not respond to verification requests by AFRINIC? Author stated that AFRINIC will block access to MyAFRINIC as indicated in the proposal text.
It was clarified by author that what is blocked is access to MyAFRINIC, not usage of resources by way of revoking them or reclaiming them. However, reclamation is part of the agreement between the member and AFRINIC.
The text in the proposal mentions “blocking account’s access to resources” which can be misinterpreted as revocation of resources”. Author clarified again that this is access to MyAFRINIC.
There was support for the idea of verification of e-mail addresses.
It was noted that a single abuse contact object or attribute is easier to maintain.
It was also noted that during verification, AFRINIC should not take punitive action on members that do not respond to verifications, as it is not the Internet Police. AFRINIC could just tag those that do not respond, and make the list public for the community of operators to decide what to do, such as de-peering.
Blocking access to MyAFRINIC was supported, but there was a proposal to allow log-in, but have a message after login to indicate that the member should first update/verify their abuse contact information before any other functionality can be accessed.
There was a concern about general response rates from members when AFRINIC has attempted to get members to update their inaccurate contacts. The CEO stated that in previous similar effort, there has been a response rate of more than 90%.
It was suggested that it’s better to maintain the current use of the IRT object, as it stores more than just an e-mail address and is already widely in use.
A member noted that AFRINIC must be able to intervene if members are inappropriately using issued resources.
Time-line for an account to be blocked and a blocked account to be unblocked are not indicated, and that this should be clarified in proposal text. Author clarified that the timelines are clear in the proposal text.
It was observed that MyAFRINIC is used to vote, and that blocking access to MyAFRINIC during election time disenfranchises members. The author stated that such are the matters that would motivate members to keep their records up-to-date, but that the login to MyAFRINIC can be used to still vote, but not to manage resources.
AFRINIC staff indicated that the policy needs to be explicitly clear about how the existing IRT will relate with the abuse-c.

Co-Chair decision: No consensus – the proposal returns to the mailing list for more community inputs and refinement.

8. Proposal: Internet Number Resources review by AFRINIC

The authors of this proposal proceeded as follows:

Authors will not dwell too much on the content, as the proposal has evolved over two years (through six different versions) and is considered mature enough in their opinion.
A way forward is therefore the best approach moving ahead.
Co-Chairs concluded from the last Dakar meeting that as a result of both strong opposition and strong support for the policy proposal for a variety of reasons expressed online and at the PPM, the proposal returns to the rpd list for further discussion and refinement. Co-chairs also suggested (after Dakar) that the community discuss further to see if there are better ways for AFRINIC to tackle the perceived/observed problem of irresponsible use of (or fraudulent applications for) Internet numbering resources.
Authors asked on how co-chairs can break the tie between strong support and strong opposition, since many agree that review and audit of allocated resources is necessary. Authors suggested a possible amendment of 13.4b by not requiring a de-facto resource revocation and putting in place provisions for staff to manage non-compliance on case by case basis.

Reactions from the community:

The policy denies end-users internet access yet they would not be aware of any audits and triggers of those audits at the ISP level.
It would also be costly and impractical since AFRINIC would need to hire external parties to conduct audits/reviews. The author responded that only issues are welcome, and statements of support or no support.
Some members indicated that AFRINIC is currently conducting reviews or due diligence efforts on utilization of issued resources, and this is not a new thing, hence this proposal may not be necessary after all.
A member clarified that not many agree that the policy is necessary, and that neither is there consensus that this proposal is needed. It was noted too that the very same proposal version and text failed to pass through at the previous meeting and that it should logically not pass through at this meeting. Also to note that this proposal makes AFRINIC an internet police of sorts, which is not part of its mandate, and that it should focus on its core functions.
The legal advisor for AFRINIC indicated that there are no legal and other issues with this version after having worked with authors to address matters raised in the staff assessments.

Co-Chair decision: The proposal goes to last-call but more community engagements still open during that period.

(Note: Based on discussions and engagements on the list after the meeting, the proposal was returned to the mailing list.)

9. Proposal: Clarification on IPv6 Sub-Assignments

Highlights from the proposal were shared by the author as follows:

The proposal was submitted to all the five RIR communities.
When the initial IPv6 policy was drafted, the concept of assignments/sub- assignments did not consider a practice very common in IPv4 which is replicated and even amplified in IPv6 - the use of IP addresses for point-to-point links or VPNs.
In IPv4, typically, this is not a problem because the usage of NAT.
In the case of IPv6, instead of unique addresses, the use of unique prefixes (/64) is increasingly common. Likewise, the policy failed to consider the use of IP addresses in hotspots, or the use of IP addresses by guests or employees in Bring Your Own Device (BYOD) and many other cases.
There are times when an end-user contracts a third-party to do some services in their own network and they need to deploy their own devices, even servers, network equipment, etc. For example, security surveillance services may require that the contractor provides their own cameras, recording system, even their own firewall and/or router for a dedicated VPN, etc. Of course, in many cases, this surveillance system may need to use the addressing space of the end-user.
The IETF has recently approved the use of a unique /64 prefix per interface/host (RFC8273) instead of a unique address. This, for example, allows users to connect to a hotspot, receive a /64 such that they are isolated from other users (for reasons of security, regulatory requirements, etc.) and they can also use multiple virtual machines on their devices with a unique address for each one (within the same /64).
Section 2.6 (General Definitions/Assignment), explicitly prohibits such assignments, stating that assignments are not to be sub-assigned to other parties. There are two options, firstly - ask the end-users to make sure they correctly use the policy and enforce it, and reclaim resources if misused and secondly, correct our mistakes in the current IPv6 policy – which latter option is the approach taken with the introduction of this proposal.
This proposal clarifies this situation and better defines the concept, particularly considering new uses of IPv6 (RFC 8273), by means of new text at the end of whatever text is available at the IPv6 PI assignments policy. It also clarifies that the usage of sub-assignments in ISPs, data centers and similar cases is not allowed.
In summary, this proposal only stipulates that IPv6 PI space is allowed to be used in the assignment holder network and only third party devices operating strictly within that infrastructure, including any interconnections. It is however not allowed to use issued IPv6 PI space to provide services to customers such an ISPs and data-center or similar cases. Such are the cases considered here as sub-assignments.
A similar proposal is under discussion at LACNIC, RIPE and APNIC communities.
Staff indicated that there were no concerns in its assessment.

Reactions from the community:

There was a statement of support for the proposal and no statements against.
A concern about numbering from the staff was raised – and author clarified that the proposal text should be inserted right after the existing text in CPM article 6.8 as it’s easier to read and interpret.

Co-Chair decision: The proposal moves to last call - but more community engagements still open during that period.

10. Proposal: Inter-RIR Resource Transfers

The proposal was presented by its author - who pointed out as follows:

Allows AFRINIC to enter an existing market for transfers for IPv4, IPv6 and ASN resources.
It was noted that IPv6 transfers help in the case where a company relocates to another RIR region and want to move with their resources to that new RIR.
Not being part of the market during the phases of IPv4 exhaustion will disadvantage AFRINIC ISPs.
To limit much IPv4 space exiting the continent, the proposal only allows outbound transfer of legacy IPv4 space. This is important because accurate registration of these resources is critical, yet they are probably in use out of region.
The minimum transferrable sizes are /24 for IPv4 and /48 for IPv6. In either case, the recipient must demonstrate a need for the resource to be transferred.
In IPv6 block can’t be transferred until 2 years after initial allocation or assignment.
As far as transferring other resource types is concerned, AFRINIC already pointed out (in policy implementation report) that the intra-RIR transfer only allows IPv4 transfers, and not other resource types.
Transferred resources cannot be retransferred until after 1 year of the most recent transfer.
There are equivalent policies in other regions, and LACNIC is discussing near-identical text. ARIN is exporting the largest number of resources in the transfer market.

Reactions and comments were received as follows:

It was noted that a block such as 196 has both legacy and non-legacy space that exists both in AFRINIC and at other regions.
The policy should be only made for inbound transfers, so that AFRINIC resources stay in Africa. The author noted that other regions need reciprocity, hence the need to provide outbound options.
It was noted by some that since the policy only allows outbound IPv4 legacy space only, it is a good policy.
There was support of the policy because it allows AFRINIC to participate in the global market, and the policy as written is acceptable.
It was noted that there needs to be bi-directional transfers in order for the proposal to be reciprocal and compatible with the ARIN transfer policy.
The author was asked why there was no maximum transferrable block (whereas there are minimum sizes). Author indicated that nobody suggested this idea yet, but suggested there may not be a need for it – but is open to suggestions from the community.

Co-Chair decision: No consensus – the proposal returns to the mailing list for more community inputs and refinement.

11. Proposal: IPv4 Soft Landing BIS

Remarks from authors were as follows:

The Soft Landing-bis proposal was meant to update the current soft landing policy adopted in 2011.
It was clear in the AFRINIC policy implementation report that some of the concerns mentioned are addressed by this proposal.
One of the issues to be addressed is already addressed in the authors’ other policy proposal next on the agenda, titled “SL Update”.
The authors therefore decided to allow the proposal “IPv4 Soft Landing bis” to expire.

[Note: The policy proposal expired on 01 December 2018 in line with the PDP]

**12. Proposal: SL-Update

Highlights were shared by the authors as follows:

CPM section 5.4.7.1 of the current soft landing policy reserves a /12 from the last /8 for unforeseen future uses.
CPM section 5.4.7.2 allows the AFRINIC Board at its discretion (considering 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, to 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 interests of the community.
Section 5.4.7.2 therefore gives the Board absolute and sole authority to decide on how to use the reserved block to eventually replenish the exhaustion pool and may be even to determine the allocation/assignment rules.
The problems with this are that if no community-driven policy is adopted to determine how to use the reserved space before the exhaustion of the pool, the Board may act at its discretion with or without community involvement and consent.
The community is therefore in a better position to determine what is in its best interests and this is better discussed through PDP.
This proposal therefore rewords 5.4.7.2 to cancel the Board discretion, to: “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.

Reactions and comments from the community were received as follows:

AFRINIC was asked to clarify if the bits and pieces of small blocks received from IANA will also be issued under the soft landing policy. AFRINIC clarified that the soft landing started when AFRINIC started allocating from the last /8, and that all space within the inventory (and not necessarily only the last /8) would all be issued under the soft landing mechanism.
Nothing indicates that Board must follow soft landing policy when determining what to do with the reserve, hence it’s good to correct this risk and uncertainty should the Board decide to manage the reserve outside soft-landing processes.
Policies should be focused on enhancing and promoting IPv6, and not adding more restrictions to the dwindling IPv4 pool. Authors stated that IPv4 is still relevant as there are active discussions about IPv4 transfers and how the AFRINIC community can still benefit from the market.
It was noted that the ARIN region had no IPv4 soft landing policy and that there is a vibrant market in that region at the same time higher IPv6 adoption rates.

Co-Chair decision: No consensus – the proposal returns to the mailing list for more community inputs and refinement.

13. Open Policy Microphone

The following points were raised by the community during the Open Microphone session:

Regarding the decision to advance proposals to last call, or send them back to the mailing list, it’s better that co-chairs state the reasons why the proposal has been sent back to the list, so that it is clear to everyone. On the issue of the SL-Update proposal, co-chairs clarified that the proposal needs more time to be discussed, although authors noted that the time was enough, in-line with what the PDP provides for. A member pointed out that there are provisions in the PDP to appeal the co-chairs decisions in case of discontent.
It was noted that submitting within the time requirement does not translate to sufficient discussions, and that the face to face meeting also gives community better insights about the spirit of the proposal, which allows for informed and enriched additional discussions.
Jordi offered to help any individuals that have not contributed to the policy process to approach him, so that issues that were raised in the Policy Implementation Report by AFRINIC staff can be addressed through policy proposals by these individuals.
A member applauded co-chairs for their efforts in their work, as well as various policy authors for their efforts.
It was noted that discussions in this meeting were cordial and there were no insulting attacks as may have been the case before, and that the cordial manner of discussions should be maintained both on the mailing list and at future meetings.
A fellow thanked AFRINIC on behalf of all other fellows for the opportunity and exposure by AFRINIC to the engagements that happened during this meeting. Another fellow also appreciated experiencing these discussions face to face as opposed to what he has been seeing on the list, and thanked Jordi for the offer to enlist new policy authors.
The community should focus less on politics and more on enhancing better policies although they may not be 100% perfect, as well as other topics like RPKI.
A remote participant urged co-chairs to reconsider their decision to advance the Internet Number Resources review proposal to last call, and return it to the list, as there were significant issues raised against it, and that some people will definitely appeal – which will create unnecessary exchanges. He also urged the authors to consider withdrawing it, as there may not be any consensus around it in future.
There was an inquiry about the possibility for AFRINIC to pay for policy authors to attend public policy meetings.
It was noted that since the staff pointed out in the Policy Implementation Report about different inconsistencies, there is a need for consistence, and the review proposals sets the path to consistence in the right direction.

Summary of Co-Chair Decisions on Policy Proposals

Proposal	Decision	Comments
AFRINIC Policy Development Process Bis v4	Back to List
Simple Update of the PDP		Withdrawn by Author
Abuse Contact Policy Update	Back to List
Internet Number Resources review by AFRINIC	Back to list	Initial decision changed after the meeting
Clarification on IPv6 Sub-Assignments	Last Call
Inter-RIR Resources Transfer	Back to List
IPv4 Soft Landing BIS		Withdrawn by Authors
SL-Update	Back to List