WHOIS SEARCH LOGIN TO MYAFRINIC

AFRINIC-23 | PDWG Meeting Minutes

Policy Development Process (PDP)

AFRINIC-23 - Policy Development Working Group – PDP Session,

Pointe Noire, Congo.

Meeting Minutes - Date: 03 Dec 2015

Agenda:

  1. Welcome & Agenda Review
  2. Overview of the Policy Development Process (PDP)
  3. Report on recently ratified policy proposals.
  4. Summary of policy proposals under discussion in other regions.
  5. Policy Proposal: Out of Region Use of AFRINIC Internet number resources.
  6. Policy Proposal: Number Resources Transfer Policy.
  7. Consensus building in the AFRINIC PDP.
  8. Policy Implementation Experience Report
  9. Open Microphone
  10. Closing

1.0 Welcome

Seun Ojedeji (the PDWG co-Chair) welcomed everyone to the Policy Development Working Group, stated that the session started late due to the lengthy previous agenda item and shared the agenda.

2.0 Overview of the PDP

Seun Ojedeji presented the Policy Development Process (PDP) to the meeting. He stated that the PDP is based on 3 principles of openness, transparency and fairness, and indicated that anyone can participate by initiating new proposals or discussing on already active proposals and policies. He went through the process that a new proposal goes through from the time it is authored, through discussions on the mailing list, presentation at the face-to-face public policy meeting and up until the time it is implemented by AFRINIC.

Seun indicated that there are supposed to be two co-chairs according to the PDP, but the other co-chair (Barry Macharia) resigned on 02 Dec 2015, due to personal reasons. He asked the floor if members feel the other co-chair should be elected before the session can continue. Several persons indicated support that there be two sitting co-chairs before PDP discussions start. Mark Elkins and Andrew Alston nominated Sami Salih as co-chair to complete the rest of Barry’s remaining term. Christian Bope seconded Sami’s nomination.

Seun asked Ernest to co-ordinate the co-chair replacement process. Ernest indicated that  there’s one standing nomination of Sami and asked the floor if there are any more nominations. There was no other nomination and Ernest asked Sami to come to the microphone and speak to the community about his capabilities for the task. After Sami’s speech, Ernest called for a show of hands for and against Sami’s nomination. Sami was selected by the majority and was announced as the replacement co-chair till June 2016. Seun welcomed Sami and thanked Barry for his contribution to the community.

3.0 Report on recently ratified policy proposals

Ernest briefed the community about the following recently implemented policy proposals: • Number Resource Reservations for Internet Exchange Points: The policy was approved by the community (through consensus) in June 2015 during the Tunis meeting, was ratified by the AFRINIC Board in August 2015 and is in the implementation process by AFRINIC staff. Expected implementation is around February 2016. • Anycast Assignments in the AFRINIC service region: This policy proposal has already been implemented.

4.0 Summary of policy proposals under discussion in other regions.

Ernest invited representatives from other Regional Internet Registries (RIRs) to share any interesting policy proposals currently under discussion at their respective policy forums.

Ingrid Witje shared the following from RIPE:

  • Revision of the last /8 allocation criteria is under discussion
  • RIPE Resources transfer policy is “under review”

  • The following policies were recently activated:

  • Policy for inter-RIR transfer of RIPE resources.

  • Alignment of transfer requirements for IPv4

  • Review of assessment criteria for requesting 1st IPv6 allocations.

  • The policy proposal to remove the multi-homing requirement for ASNs was withdrawn by the authors.

Anton Strydom shared the following from APNIC:

  • Proposals that have reached consensus and are pending endorsement by the APNIC Executive Council:

  • Modification of IPv4 eligibility criteria. Once implemented, APNIC will nolonger ask requestors of IPv4 space about their multi-homing and peeringplans.

  • Modification of ASN eligibility criteria: Once implemented, APNIC will nolonger ask requestors of ASNs to provide two peers as the absolute requirement to obtain an ASN.

  • Proposals under discussion on the mailing list:

  • Detailed Assignment Information: The proposal mandates that APNICmembers register detailed information of their customers (that have been assigned IP addresses) in the whois database to help network operators be more specific when filtering unwanted traffic. The proposal failed to reach consensus at APNIC 39 and APNIC 40 

David Huberman shared the following from ARIN:

  • The following have been approved by the Board and will be adopted:

  • Modification to the criteria for initial IPv6 assignments: A company canreceive an IPv6 assignment from ARIN if it has 13 sites where the IPv6 space will be deployed.

  • Modify 8.2 of the ARIN policy manual to better clarify how ARIN handlesreorganizations, mergers and acquisitions.

  • The following are under discussion:

  • Modification of inter-RIR transfer requirements: Currently, transferrecipients can become a transfer source only after a period of 12 months after receiving a transferred resource. This proposal removes the 12-month restriction.

  • Out of Region Use: The proposal allows ARIN resources to be used outsidethe ARIN region.
  • Eliminate needs-based evaluation for transfers: The proposal allowstransfer recipients not to demonstrate the need for IPv4 address space being transferred to them.
  • Minimum IPv6 assignments: The proposal aims to set the minimum IPv6assignment to /56 (from /48).

Ernest shared the following open proposal from LACNIC:

  • IPv4 Exhaustion policy with scheduled return of large unused blocks (IPv4): In order to force migration from IPv4 to IPv6, large IPv4 users should annually return 1/15th of what they have been issued for use by smaller members. This would encourage large users to deploy IPv6.

5.0 Policy Proposal:Out of Region Use of AFRINIC Internet number resources.

Douglas Onyango, the author, shared the following highlights from the proposal:

  • The policy acts as a deterrent for any organization located outside the Africa regionto request for and acquire space from AFRINIC for use outside the region.
  • Author is aware of the fact that some ISPs may be located in Africa but would haveclients outside Africa.
  • The proposal to not be applied in mutual exclusion. Other conditions, such as theneeds-based analysis of evaluating IPv4 requests must remain.
  • Up to 40% of the resources held by an LIR can be used out of the region.
  • AFRINIC staff can carry out periodic research and analysis to verify region-usage ofthe IPv4 number resources.
  • The proposal will be applied retrospectively.
  • Douglas mentioned that some feedback that was received at the previous meetingwas already incorporated into the version that is being discussed.

After Douglas’ presentation, Ernest presented a staff assessment of the proposal which highlighted the following items:

  • The staff indicated that section 3c is difficult to implement – and that the proposal needs to be as clear as possible about what methods staff can use to measure and determine Out-Of-Region use.
  • AFRINIC cannot implement this proposal as written because of this clause (3c). Sami opened the floor for comments and questions from community members present:
  • A number of individuals supported the proposal as it protects Africa’s numberresources but expressed concern about the 40%, stating that this should not be there. (Should be zero).
  • There was a suggestion to reduce the percentage from 40% to 20%.
  • A member stated that Africa’s resources should exclusively remain in Africa andhence does not support the proposal.
  • The process of using the global routing table to determine if a resource is used out of region is flawed, as many numbers can appear in one region yet used elsewhere. 
  • This is something very technical that the staff would find not feasible to use.
  • To understand the context of the problem, it was requested that AFRINIC providesa detailed status of all IPv4 addresses – who uses them and where.
  • Resources should be used based on the initial purpose for which the resources were issued to AFRINIC, irrespective of policy loopholes and exclusions.

The co-chairs determined there was no consensus on the policy proposal which was sent back for discussion on the rpd mailing list in-line with the provisions of the PDP.

6.0 Policy Proposal: Number Resources Transfer Policy

Mark Elkins, the author, presented the proposal to the community. He stated that the proposal is meant to transfer IPv4 addresses both into and outside the AFRINIC region, and also seeks to solve the issue of where an AFRINIC member offering services outside Africa cannot get IPv4 space from the RIR serving that region, leaving the only option to transfer them from AFRINIC to the RIR serving the country where operations of that company are.

He also stated that other RIRs already have transfer policies, and AFRINIC needs one too so as to have consistent processes. Mark indicated that he based this proposal on what ARIN is using, and that most of the content was based on ARIN’s policy.

Mark pointed out that although some people requested that the proposal includes transfers between AFRINIC organizations, the proposal is meant to be an Inter-RIR transfer policy, only for transfers from outside to within the region and likewise.

Sami thanked Mark for the presentation and asked for an assessment of the proposal from AFRINIC staff, if any.

Ernest stated the following observations from the staff assessment:

  • The title of the proposal is vague about whether this is an intra-RIR or inter-RIR transfer policy.
  • Section 2, which is meant to be a summary of how the proposal addresses the problem in Sec 1, introduces a separate topic about transfers of legacy resources. This is a very critical issue that should be introduced separately in Section 3 and be removed from the summary section.
  • Definition or classification of the various types of transfers and a detailed process on how AFRINIC will conduct each of those transfers is missing in Sec 3.
  • Sec 3b mentions “exhaustion” of IPv4 space – this is ambiguous – and should be clear on whether this refers to the start of issuance from the last /8, or the invocation of the soft-landing policy.
  • Sec 3.1b refers to “same business entity”. This needs to be properly defined in order not to confuse AFRINIC staff with interpretation.
  • Sec 3 needs to be a complete description of the proposal. A reader who ignores the title, section 1, and section 2, but reads section 3, needs to be able to understand the entire proposal. 

Sami called for comments from the floor, and the following feedback was received:

  • The proposal has one of the sentences in the problem statement that AFRINIC is one of the RIRs without a transfer policy and we need it because others have it. The speaker said we do not necessarily have to implement something because others have done it, but we must ascertain first that its what we need and its beneficial for the community.
  • Several members stated that the spirit of the proposal is not very good since it createsan opportunity for resources to leave the continent, which is against our interests.
  • Others stated that at our current consumption rates, we shall also eventually run out of IPv4 space and without a transfer policy, we shall not be able to get IPv4 space into 
  • AFRINIC from the market in other regions, which will also be an issue for business inthe region.
  • Some members indicated that since AFRINIC has more than what the others have, it appears against our interests, and that its better to let the policy let us acquire more from out than outsiders being able to easily acquire AFRINIC space.
  • There was a suggestion to review or create an intra-RIR transfer policy such that any members that need space could instead acquire it from other AFRINIC members that do not need it anymore.
  • Several members reiterated that the policy is not suitable for the continent given it creates an opportunity for outsiders to take from the continent, given especially that those outsiders actually have nothing to transfer to us, but rather, only us to them.

Seun indicated that based on the nature of dialogue, there is need for further discussions, and the proposal must go back to the mailing list. There was therefore no consensus and the author was encouraged to take the inputs of the meeting and incorporate them into his next version.

7.0 Consensus Building in the AFRINIC Policy Development Process

Seun Ojedeji introduced the topic by saying that there does not seem a proper and structured consensus building process around the AFRINIC PDP and that as co-chairs, they have been faced with a need to ensure that the views of the community are properly expressed in decisions taken towards determining consensus.

Seun stated that he, Barry and Ernest have taken a step to document a process that attempts to set the guidelines that co-chairs use to determine consensus, and that if the community discusses and endorses it, this could be the starting guideline (and working document) that will help co-chairs towards determining consensus.

From the document, Seun shared the following key issues that co-chairs look for/at to determine consensus.

  • No consensus calls at all: This happens when judging from the discussions, there was a clear sense that there was no general agreement, in which case the co-chairs find no need to gauge for the same from the room by posing any questions.
  • Consensus to last call: When there is adequate clarity that the proposal was generallyliked gauging from discussions in the room.
  • Rough Consensus: The idea is adopted from the IETF approach (in RFC7282) when allof the views have been heard, but not necessarily accommodated, but there is significant accommodation of views to take the proposal to the next level (last call).
  • Objections from the community: There’s a dispute resolution process that is describedin the PDP in case any member of the community disputed the consensus decision by the PDWG co-chairs.

The following questions arouse

  • There was a comment to clarify if this is a guideline or policy proposal. Seun stated that it’s a guideline and not really a policy proposal.
  • It was indicated that there was no ample time for the community to study documentin case any form of approval was sought – and it was suggested that the PDWG cochairs post it to the rpd list to allow the community to discuss it and provide useful feedback.
  • Another suggestion was to base the consensus process on the IETF’s process asdefined in RFC7282. Seun indicated that a few points were picked from the RFC but recommended that more suggestions are welcome from the community.

8.0 Policy Implementation Experience Report

Madhvi (Registration Services Manager – AFRINIC) shared the policy experience implementation report to the meeting, and mentioned the following key highlights:

  • It has been found out that for some members, the criteria on which IPv4 space was acquired have changed, and this is in direct conflict with what the policy and RSA requires, that the original criteria on which the resources were acquired must not change.
  • Many members still hoard and reserve IPv4 space, and while auditing utilization oftheir previous allocations (at the time when they have requested additional space), it’s established that there are several reserved and unused ranges. Members should be informed that reservations are not supported, per the policies.
  • Off shore companies with no infrastructure in the region are increasingly requestingIP address space. They usually have some sort of physical or virtual address within the region yet their entire infrastructure is located outside the region.
  • While evaluating subsequent allocation requests, an audit of registered assignmentsfrom previous allocations is conducted. Some members refuse to register assignments correctly if at all, making it impossible to evaluate their requests for additional resources.
  • There are many requests for ASNs from members that have no concrete multi-homing plans. Members must show the peers they plan to uplink with, with verifiable proof before an ASN can be assigned.
  • Members having rDNS issues could be impacted by the implementation of the “NoReverse Unless Assigned” policy, and should contact AFRINIC if the problem persists.

Madhvi asked members to use the Policy Development Process in case they feel some policies are not well interpreted by staff, or that some issues are not addressed by any particular active policy.

9.0 Open Microphone

A member asked if it is necessary to inform AFRINIC if their infrastructure (where IP resources are deployed) has moved from one city (in the same country) to another. Madhvi stated that the needs and criteria will have changed,and that accordingly, there’s need to review such a scenario to ensure that the need for those resources is still demonstrated. She stated that the RSA and policy have clauses about this and that its very clear.

10.0 Closing

Co-Chairs adjourned the meeting at 1900, thanked everyone for participating actively, and wished everyone a safe trip home and requested that discussions continue on the mailing list.