WHOIS SEARCH LOGIN TO MYAFRINIC

AFRINIC-33 | Public Policy Meeting

Policy Development Process (PDP)

1) Agenda

  1. Welcome, Introduction & Agenda Overview
  2. The AFRINIC PDP & Building Consensus
  3. Policy Update from other RIRs
  4. Policy Implementation Experience Report
  5. Proposal #1: Abuse Contact Policy Update
  6. Proposal #2: General Abuse Contact
  7. Proposal #3: RPKI ROAs for Unallocated and Unassigned AFRINIC Address Space

  8. AFRINIC-34 Competing Policy Proposals:

  9. Simple PDP Update for the new “Normal”

  10. Chairs Elections Process
  11. PDP Working Group(WG) Guidelines and Procedures

  12. Open Discussion with the PDWG on the Way Forward

  13. Open Microphone on the PPM

2) Welcome, Introduction & Agenda Overview

Delegates were welcomed to the meeting (by Vincent Ngundi, PDWG Chair). The agenda was presented and there were no modification requests.

The agenda is as follows:

  • 10:10 - 10:15 Welcome, Introduction & Agenda Overview
  • 10:15 - 10:35 The AFRINIC PDP & Building Consensus

  • 10:35 - 10:47 Policy Update from other RIRs:

  • ARIN (video to be played)

  • RIPE NCC (video to be played)

  • LACNIC

  • 10:50 - 11:00 Policy Implementation Experience Report

  • 11:00 - 11:10 Questions & Answers
  • 11:10 - 12:00 Proposal #1: Abuse Contact Policy Update
  • 12:00 - 12:10 TEA BREAK
  • 12:10 - 13:00 Proposal #2: General Abuse Contact
  • 13:00 Closing Remarks for Day 1

3) The AFRINIC PDP & Building Consensus

Darwin Da Costa, PDWG Chair, advised that as a participant to this AFRINIC PPM, delegates are expected to adhere to the AFRINIC code of conduct by being professional, respectful at all times in the best interest of the community. He also discourages the following behaviour during the same; (harassment, intimidation and offensive behaviour). Before his presentation, Darwin, first of all, commented on the guideline to participate in this AFRINIC PPM and then explained the AFRINIC Policy Development Process based on these key points:

  • Definition of the AFRINIC Internet Number Resource Policies
  • How the Policy Development Working Group (PDWG) is Coordinated
  • The roles of the PDP Co-Chairs
  • The Policy Development Process (PDP)
  • The PDP Principles

Darwin Da Costa also went through the PDP simplified process. He also urged the community to refer to AFRINIC’s Consolidated Policy Manual (CPM) and highlighted that the manual is updated once new policies are ratified and implemented.

Vincent Ngundi thereafter presented on ‘Building and determining Consensus’. Further to challenges noticed amongst the Policy Development Working Group with regards to ‘Building and Determining Consensus’ and discussions happening on the RPD mailing list, the Co-chairs felt it is important to have an overview on ‘Building and Determining Consensus’. Reference was made to AFRINIC’s Consolidated Policy Manual (CPM), specifically, Section 3.0 which highlights the objective of the PDP, and Section 3.4.2 of the CPM which stipulates that the Chairs determine whether consensus has been achieved during the Public Policy Meeting.

Vincent Ngundi emphasized the Co-chairs’ role in building and determining consensus. He highlighted the following:

  • RFC 7282 which provides a guide to building and determining consensus, developed for the IETF which is an environment similar to ours
  • Moderation of DPP Discussions - the role of Co-chairs are defined as 1) to identity objections and contentious issues and secondly to track open issues that are yet to be addressed by the Author(s) and participants
  • The roles and focus of the Co-chairs in Building Consensus: 1) to direct the working group towards areas which are contentious, which were identified during the moderation process 2) to encourage participants to focus and seek consensus on contentious areas 3) to ascertain whether staff impact assessment raises or addresses the contentious issues.

Vincent Ngundi further elaborated on ‘Determining Consensus’. Key elements were as follows:

  • Determining consensus is a process that starts from the time a policy is proposed.
  • The objective is to always aim for rough consensus, if not consensus
  • Rough consensus is not built/determined through a VOTING mechanism
  • Rather by ensuring that all objections/concerns are adequately addressed
  • Look/seek consensus throughout the process (for each contentious issue)
  • No VOTING mechanism was applied at any point in time (to avoid “vote stuffing”)
  • 100 people for and 5 people against might not be “rough consensus”. If a minority of participants have a valid objection, that objection must be dealt with before rough consensus can be declared
  • 5 people for and 100 people against might still be a rough consensus, as long as there are no valid objections that have not been addressed.

4) Policy Update from other RIRs

Sean Hopkins, the Senior Policy Analyst at ARIN, mentioned that:-

  • 2 policies(2020-7 & 2020-8) are pending Board of Trustees review. They have been through most of the PDP already.
  • 3 draft policies are under discussion- AC has shepherded them to the point where they are ready for community discussion and are receiving feedback from the community.
  • 3 items are classified as editorial changes under discussion and do not impact policies in a substantive way.

Angela Dall'ara, Policy Officer at RIPE NCC, presented a brief overview of the topics discussed in the RIPE Community. Highlights are as follows:-

RIPE discussions about policy proposals are open to everybody. They are held mainly on the mailing lists of different working groups, dedicated to specific topics. Even if views can be exchanged in the WG sessions at the RIPE meetings, the consensus is determined by Chairs based on discussions on the mailing list.

Currently, there are no policy proposals under discussion. In the address policy working group announced their intention to undertake a systematic review of address policy documents;

The RIPE Database Working Group asked for feedback to determine whether there is consensus on multiple numbered work items, some of which are the possible introduction of a new Geo feed attribute, the option to allow registration of multiple inet(6)nums objects with different status within the same address range and NRTM service

The anti-abuse working group enquired whether the community had comments about the abuse contact validation.

All the session recordings are available online.

The discussion about these and other topics will of course continue in the relevant mailing lists.

The RIPE Taskforce are dedicated teams working on recommendation reports that may change the policies in the near future

RIPE Chair Team is currently reviewing the PDP, documentation between RIPE NCC and RIPE as well as the RIPE NCC vision and purpose.

For the LACNIC region, a total of 11 proposals are currently being processed. They have eight policy proposals that are in the initial discussion stage. Consensus is being evaluated on three other proposals notably:-

  1. impact analysis is mandatory;
  2. authorised recipients of delegated blocks to sign ROA's,
  3. Modify section “2.3.2.19 and 4.3 Inclusion of origin ASN in WHOIS responses when available”

The LACNIC 35 policy forum happened a couple of weeks ago, nine proposals were presented. This time the Public Policy Forum took place over two days and participants were given the opportunity to use their microphones as part of the improvements that are being implemented for the online meeting environment.

5) Policy Implementation Experience Report

Presentation URL- https://static.sched.com/hosted_files/ais21/e7/PIER-AIS21.pdf

Dev Jeenia, AFRINIC Staff, presented the Policy Implementation Experience Report (PIER).

He mentioned that the purpose of the PIER is to provide feedback to members and the community regarding recently implemented policies and experiences faced by hostmasters while handling requests governed by currently implemented policies.

He announced that the following policies are implemented:-

  • Adjusting IPv6 PA Policy - AFPUB-2019-IPv6-002-DRAFT01 and incorporated in the Consolidated Policy Manual (version 1.6).
  • IPv6 PI Clarification - AFPUB-2019-V6-001-DRAFT02 - Prefixes that are not meant to be announced, such as IXP Peering prefixes, are exempted from the announcement checks.
  • Lame Delegations in AFRINIC Reverse DNS - 3 notifications are sent to the registered contacts and the lame nameservers are removed after 30 days. He also presented the statistics about the number of lame delegations. They have considerably dropped.
  • The experiences faced by Hostmasters were mainly on abuse and were as follows:-
  • Section 8 of the CPM mentions a non-mandatory clause in regard to the abuse of contact information.
  • 40 IRT objects exist in the AFRINIC database and very few members have actually published their abuse information
  • This has led to AFRINIC Missing abuse contact complaints receiving the abuse complaints about most of its members.
  • Blocklist Operators have submitted a request for bulk access to retrieve contact information. However, the data does not contain contact information. We have not yet set aside their request yet but on the other hand, it would be better to have a policy that enforced the use of abuse contacts and to publish the abused contacts.

6) Questions and Answers

Highlights of the Q&A session are as follows:-

  1. In response to a query as to whether discussions on the list are considered in the determination of consensus, Vincent Ngundi PDWG Chair mentioned that only valid objections, concerns or comments on the mailing list are considered.
  2. In regard to the comment that the appeal committee is ignoring the list discussions which in his opinion is against the PDP 3.4.2 of the CPM, this query should be handled by the appeal committee. No response was received from any Appeal Committee representative if they were present in the meeting.
  3. In response to the query about the appeal results regarding the PDWG Chairs. Vincent Ngundi responded that this should be handled either by the appeal committee or the Board. Madhvi from the AFRINIC Secretariat affirmed that there are no results yet.
  4. A participant had a question about the sudden drop in abuse complaints in August 2020. James Chirwa from AFRINIC Member Services responded that the sudden drop is attributed to the IP addresses that have been reclaimed last year.
  5. In response to the query as to whether the missing reports for the two proposals that have reached a consensus - according to the previous PDWG Chairs - have been sent to the Board, Vincent Ngundi mentioned that the co-chairs have never received the reports prepared by the previous co-chairs. Hence they will compile the reports based on the discussion on the RPD and the recorded minutes for the last PPM where consensus was reached and also the Last Call. He also mentioned that this should be available by the end of June. He emphasized that the main focus of the co-chairs so far has been to make sure that they are properly prepared for the PPM.
  6. There was a request for clarification on 3 points that were shared during the presentation made by Darwin Da Costa on the PDP Process, namely 1) what does it mean by ‘anyone’ can participate? does it mean that anyone can come and disrupt or is there any requirements for people to participate because this openness can create an abuse; 2) What is meant by ‘fair’ distribution of resources; 3) what is considered as ‘valid objections’ since what one can consider as valid objections may not be the same for someone else. He mentioned that he does not require the co-chairs to respond to these questions immediately but to consider these points as we move on. The co-chairs responded that they took note of these comments.

After the Q&A sessions, PDWG Chair Vincent Ngundi presented the 3 Draft Policy Proposals that will be discussed during the AFRINIC-33 PPM, namely:

  • Proposal #1: Abuse Contact Policy Update
  • Proposal #2: General Abuse Contact
  • Proposal #3: RPKI ROAs for Unallocated and Unassigned AFRINIC Address Space

He further gave an overview of how the discussion will be carried out for each proposal and encouraged the participants to adhere to the timeframe presented.

7) Proposal #1: Abuse Contact Policy Update

ID - AFPUB-2018-GEN-001-DRAFT07

7.1) PDWG Chair introduction of the DPP and Discussion Flow

Vincent Ngundi announced the proposal which will be discussed and gave an overview of the flow of discussion.

7.2) PDWG Chairs Summary

Vincent Ngundi mentioned that there have been ongoing discussions on the RPD regarding this draft policy proposal since the AFRINIC-32 meeting in 2020, and hence leading to the authors' review of the proposal and consequently they came up with version 7 of the draft policy proposal. He further highlighted that as of that day, there have been no further discussions on Version 7 of the draft policy proposal.

According to the PDWG Chairs, the key concerns about this draft policy proposal are as follows:

  1. The proposal asks AFRINIC to manage the mailbox’s subject line.
  2. This concern has been addressed by the author and some members of the Working Group. The response to this concern was that the proposal is asking AFRINIC to implement an abuse-c attribute, and the mailbox shouldn't be filtered to only receive from AFRINIC or a specific subject. Secondly, the mailbox is to be validated periodically.
  3. Redundant proposal - Members should already have abuse contact or alternative if they really needed it. Vincent Ngundi mentioned that this matter is still pending and can be addressed by the author during the meeting.
  4. RIRs have no ability to define what is ‘abuse’, one abuse or even criminal activity could be entirely a legal operation in different jurisdictions and secondly the proposal does not include a definition of ‘abuse. This concern was addressed and it was emphasized that RIRs do not need to define “abuse”, they only need to publish the contacts that will be used to report ‘abuse’ cases. It was further stated that the RFC2142 includes a definition of ‘abuse’.
  5. Making a member forcefully reply to abuse contact emails is a waste of resources, and totally pointless. It's entirely up to the member to define what they think is acceptable in their network. This concern has been addressed. Firstly, AFRINIC is paying for the cost of abuse handling and secondly, the AFRINIC staff are handling abuse complaints about IP addresses that have already been delegated to AFRINIC members.
  6. AFRINIC has no mandate to force any member to reply to an ‘abuse’ since AFRINIC doesn't even have the ability to identify what is considered an ‘abuse’ This concern has been addressed. It has been stated that this proposal is mandating AFRINIC to publish the valid and working abuse contacts of its members to which it has or will delegate resources.
  7. Another concern is that it will only be a waste of resources as it will cost extra to have this policy pointlessly worked on or implemented. This was addressed since AFRINIC is paying for the cost of abuse handling and further to the staff assessment of version 7 of the policy proposal, no concern was raised with regards to additional staff.
  8. Abuse enforcement is out of the scope for RIRs. This concern has been addressed. The proposal enforces that a valid abuse contact exists.
  9. The policy is capable of bringing complications, misunderstanding, and/or problems among AFRINIC resource members with regards to the use of Internet Resources. Secondly, there is no need to make it mandatory as it would lead to further unforeseen and avoidable complications. This is a vague and unclear objection as the concerns raised cannot be ascertained.
  10. AFRINIC only has the mandate to manage the registration of IP numbers, it does not have the capacity or mandate to manage networks. Networks have already shown technical need during the application process and done correct registration of their numbers, and they are done with AFRINIC from this point on. How they manage a network is entirely out of the scope of AFRINIC. This concern has been addressed since members are bound to comply with the policies as well as the RSA, which stipulates that the applicants shall provide and ensure accurate contact information is stored in AFRINIC databases.
  11. Redundant Proposal. Members should already have abuse contact or alternative if they really needed it. Vincent Ngundi pointed out that this concern is pending and will leave it to the author to address this issue during their presentation. Vincent Ngundi gave the floor to the Author, namely Jordi Palet Martínez for the presentation of the Draft Policy Proposal.

7.3) Author’s presentation of DPP

Jordi Palet Martinez proceeded with his presentation.

The author started by underlying the concerns raised and how this has been addressed.

  1. The current policy does not mandate the members to register an abuse contact. He highlighted that the proposal in itself responds to this concern since the policy does not imply the obligation to register an abuse contact.
  2. Based on what AFRINIC Staff has communicated, the Author pointed out that there are approximately only 20 members who have shared contacts known as abuse contact. Furthermore, there is no verification done to ensure that these contacts are valid.
  3. Furthermore, he mentioned the following reports from AFRINIC Staff, records from 2017 show the number of abuse complaints connected to AFRINIC members and this is costing money to AFRINIC.
  4. There is an existing reference to the ‘Best Practice Paper’, which is not deemed to be mandatory and in fact, is not actually being used by the community.
  5. The Author mentioned other RIRs such as LACNIC and APNIC who are actually following the same policy proposal but with some minor changes because they have endorsed this policy before AFRINIC.
  6. In response to the query about the need to delete the data in the existing IRT, the Author stated that this is not necessary since there are only approximately 20 members registering their IRT and in any case, it can be duplicated.

The author emphasized that this proposal is only trying to make abuse-c mandatory. Any member can be contacted in case of abuse. The proposal is not defining what is ‘abuse’. The proposal aims to make it possible to contact any members in case of presumable abuse cases. The author further presented the proposed changes in the policy text from the existing proposal and his recommendation.

8.7 Slow Start and progress follow-up has been introduced in this version of the proposal in response to the explanation given in the impact analysis. There is no mandatory implementation period, hence AFRINIC can change the period depending on how much they can invest in implementing this proposal and having all the members to agree to this.

Due to time constraints, the Author could not provide additional information and went directly to the impact analysis.

Response to Impact Analysis

The Author stated that there is nothing pending for further clarification based on the latest version of the impact analysis.

7.4) Staff Impact Assessment

Presentation URL - https://static.sched.com/hosted_files/ais21/39/AIS21-AF33-Proposals-Impact-Assessment.pdf

Madhvi Gokool from the AFRINIC secretariat presented the impact assessment of the proposal. She stated that the following points are derived from the staff’s interpretation and understanding of version 7 of the proposal:

1) The Proposal is requesting AFRINIC to implement a proper abuse contact mailbox under AFRINIC multi-validation.

2) Impact on Registry functions will be as follows:-

  • If this proposed policy reaches consensus, an improvement on the accuracy and currency of registry data is expected, as the “abuse-mailbox:” attributes are expected to be current and correct. This will also reduce the number of abuse emails that are currently directed to AFRINIC queues due to lack of abuse contacts.
  • MS procedures will require updates as follows:- New procedure/sub-process to be developed for the validation of the abuse-c/abuse-mailbox. 

3) WHOIS

  • The abuse-c shall be a person/role object on the WHOIS database. abuse-mailbox is already an attribute of the person/role object.
  • The abuse-c attribute shall be added on the WHOIS database as an attribute to inetnum, inet6num and aut-num objects
  • Deprecate IRT object
  • Remove mnt-irt attributes from inetnum, inet6num and aut-num objects.
  • Add validation rules to force abuse-mailbox on person and role objects which are referenced via the abuse-c attribute.
  • A WHOIS query of the inetnum, inet6num and aut-num shall provide the abuse contact in the response.

4) MyAFRINIC

  1. Coding will be required to ensure creation/updates/import of abuse contacts
  2. Abuse contacts shall not have login credentials on MyAFRINIC unless if it is being used in another role as well and hence will be maintained by admin/tech contacts
  3. Update of the resource issuance/update business rules to make abuse-c mandatory for all
  4. Updates of the sub-allocation and assignment forms with business rules around abuse-c
  5. A tool to validate the mailboxes as mandated by this policy proposal will have to be implemented and abuse contacts flagged as valid/invalid
  6. A tool to enable members to implement the abuse-c will be developed 

5) No financial impact

6) Legal impact - In case this policy reaches consensus, non-compliance with this policy by an AFRINIC member will be considered a breach of the RSA clause and the member will be encouraged to remedy the breach. Persistent non-compliance may entail revocation of the RSA as per the clause 

7) Implementation - AFRINIC shall update its current whois database accuracy initiatives with its members with the abuse contact adoption. Considering the phased approach that the Author made reference to, the policy shall be implemented in a phased approach and the community will be informed about the progress.

7.5) Open Microphone Discussion on the Proposal

Open microphone discussion on the proposal was open for 20 minutes. They are summarised as follows :

A. Elvis - individual representative - wanted to clarify that the term ‘abuse’ may be different subject to the country where the person lives or works. What is the essence of this policy if AFRINIC cannot define what is considered as ‘abuse’. To this, the Author responded by saying that from previous discussions, the question about whether AFRINIC can define what is abuse was addressed. The policy is unchanged in that aspect, for e.g for one country sending spam is considered as an ‘abuse’, whereas for another country the ISP can decide that they cannot disallow customers to send SPAM. More and more countries and ISPs need to become responsible for such decisions, but the policy is not going to define that.

B. Meriam - Is soft landing IP be used outside of the region and how does AFRINIC position itself in managing this? The second question is, is AFRINIC reclaiming IP's for free instead of utilizing their commercial value. The co-chairs intervened stating that these questions do not relate to the proposal.

C. Frank from the Tanzania Internet Exchange Point shared his support for the proposal and that the last AFRINIC presentation highlighting that IPs that are no longer in use are being reclaimed.

D. Anthony stated that given that the scope of abuse is undefined, the timeline given to respond to abuse might be too tight to the people as well as for AFRINIC, and secondly, these timelines are putting much more responsibility on people and AFRINIC. In response to these questions, Author Jordi clarified that the periods he mentioned are for the validation and not for the response to an abuse report. He also mentioned that the difference between version 6 and version 7 is that AFRINIC can opt for phased implementation. Hence, if 15 days is not good enough for confirming the abuse mailbox, then AFRINIC can change and report back to the community. 

Vincent Ngundi read out the comments in the Q&A section of the conference Tool:

E. Prof Nii Quaynor stated that mandated abuse contact is required for a safer Internet, in fact, we have the responsibility to the African Internet that we further commit that abuse reports are responded to as soon as possible.

F. Noah Maina wrote that we ought to be responsible, and this is one such policy that will contribute to Internet security and a safer Internet. 

Further comments at the open microphone are as follows:-

G. Patrick Okui - a member of the Internet community - commented in support of the policy and the adjustments made by Jordi to make sure that AFRINIC staff can come back to the community if they will adjust the timelines.

Questions from the Q&A

H. Taiwo said that since RSA is compulsory and abuse contact is stated, why is policy a necessity? In response to this, Jordi mentioned that he does not think that the RSA talks about abuse contact, and that's the reason we need this policy.

I. Anthony - does this imply that network holders must provide AFRINIC with their confidential data even when they have already shown technical needs during the application process and have done correct registration of their numbers? Author Jordi stated these are not confidential data since these are data that are already in the WHOIS and can be the same as the technical contact that the point is to make sure that there is a specific abuse mailbox.

Back to the open microphone

J. Alain Aina - speaking for himself - commented that he hears that implementing this policy will be an overhead on AFRINIC Staff and Staff never said so and has clearly stated that this is implementable. The second point being said is that this is beyond the scope of AFRINIC. AFRINIC has the responsibility to distribute the numbers, and this community also has the mandate to discuss and adopt policy and he would like to hear from Staff and Board that what is being done here is within scope.

Jordi responded to the comment made by Alain saying that indeed the impact analysis confirmed that there are no legal or financial implications.

Further to this, Jordi asked the co-chairs whether he has correctly addressed the question of the redundant proposal and that the actual proposal is only a recommendation and this is not a redundant proposal.

Vincent Ngundi read out a comment from Mark Elkins who mentioned that ‘one would assume an address of abuse would be used, which is then locally managed at the ISP’. Jordi responded by saying that this comment is in reference to confidential information and that this is not applicable since you don’t have to state a person’s name, and you can have a team of people or an internal mailing list. Vincent Ngundi further stressed out that this is also a recommendation from the RFC2142 and that it also alludes to the comments made by Mark Elkins.

7.6) PWDG Chairs decision

After deliberation, the PDWG Co-chairs made the following decision:

***“Having considered the discussions in the RPD mailing list and the current PPM, and the authors have addressed the concerns raised by the PDWG, the Co-chairs have determined that rough consensus has been reached. ***

The draft policy proposal, therefore, moves to the Last Call. The community can engage more on this during the Last-Call period.”

8) Proposal #2: General Abuse Contact Policy

ID - AFPUB-2020-GEN-005-DRAFT01

8.1) PDWG Chair Introduction of the DPP and Discussion Flow

Co-chair Darwin Da Costa announced the Proposal which will be discussed and proceeded with an overview of the flow of discussion and handed over the microphone to one of the authors for the presentation of the Draft Policy Proposal.

8.2) Author’s Presentation of the Draft Policy Proposal

The General Abuse Contact Policy (Draft -1) was presented by Widjane Goubi.

  • It has been highlighted that the current policy presents a multitude of shortcomings and hence these problems are being addressed by this proposal. Below is a list of the current policy limitations:
  • It fails to improve data accuracy in the WHOIS database and compliance for what concerns addressing issues.
  • It does not support members actively using the object for declaring abuse contact information.
  • It does not decrease the number of abuse emails that are directed to AFRINIC tickets, which means that it is not operationally smooth.
  • Section 8 does not offer a valid method on how to host reports about not working and not specific objects.
  • The main concept is that it is inefficient to treat the abuse-c separately from the other mandatory contacts, admin -c or tech -c

  • The author further explained the objectives of this proposal :

  • Removing entirely section 8.X. because it mostly gives AFRINIC a control role that is out of its scope

  • Including abuse-c as part of whois registration by adding it under section 7.5.1 "Registering contact persons" that already covers the other mandatory contact - admin-c or tech-c
  • This addition will allow the system to return to errors if someone creates an object without the mandatory contact attribute, which means that if something goes wrong (creating an object without the mandatory contact attribute) while the members report abuse, the system will return an error to inform the user.

  • If the policy has specific parameter requirements, the system will also report an error if they are not correct.

  • The author presented the advantages of this policy:

  • AFRINIC clearly needs to implement a new method to detect non-specific objects, for the purpose of decreasing the amount of received abuse emails.

  • It allows the community to reach the right person and solve the problem easily and rapidly.

  • From the staff’s perspective, this new addition can lessen the workload and ensure an effective task division, so that every appointed contact can provide the best assistance to the community.

  • The Author further explained that AFRINIC will be able to better monitor the accuracy of any created object and that all members will have to incorporate a mandatory contact attribute to any object, which will save a lot of time for members to report/submit a complaint in case of abuse, violation, or any related matter.

  • The Author outlined the process as follows:

  • The abuse contact("abuse -c") should be a person who can handle abuse issues on the network, and it is for the network to communicate with each other on abuse issues.

  • An abuse -c, admin -c, and tech -c should all be available under the “Registering contact persons” section, to achieve a certain diversification for the entities submitting abuse complaints.
  • The main goal here is to provide as many channels as possible available for the community to resolve their issues in the most efficient/up-to-date way.

8.3) Staff Impact Assessment

Presentation URL - https://static.sched.com/hosted_files/ais21/39/AIS21-AF33-Proposals-Impact-Assessment.pdf

Madhvi Gokool from the AFRINIC Secretariat presented the Staff Impact Assessment of the proposal. She mentioned the staff’s interpretation and understanding of the proposal as follows:-

  • ● The proposal requests AFRINIC to implement an abuse-c contact - similar to the existing admin-c and tech-c - for autonomous system numbers. It is understood that this proposal is addressing Section 7.5 of the CPM

  • ● Madhvi further outlined the points which need clarification requests from the authors as follows:

  • 1) Author, to clarify if the removal of Section 8 of the CPM implies that the IRT object should be deprecated from the AFRINIC whois database?

  • 2) The proposal as worded will not ensure that inet(6)nums will not contain an abuse-c. Author to clarify if this is what the proposal aims to achieve.
  • 3) The proposal as written contains some statements that are not comprehensible and can easily lead to erroneous interpretations & implementation concerns as follows "Section 8.X does not offer a valid method on how to host reports about not working and not specific objects.", "This addition will allow the system to return to errors if someone creates an object without the mandatory contact attribute, which means that if something goes wrong (creating an object without the mandatory contact attribute) while the members report abuse, the system will return an error to inform the user. If the policy has specific parameter requirements, the system will also report an error if they are not correct." , "The abuse contact("abuse-c") should be a person who can handle abuse issues on the network, and it is for the network to communicate with each other on abuse issues.
  • 4) Authors mentioned that "The current policy fails to improve data accuracy in the WHOIS database and compliance for what concerns addressing issues." How will this proposal as written improve data accuracy in the WHOIS database and compliance for what concerns addressing issues?

  • 5) Can an aut-num have more than one abuse-c contact? This clarification is required for the purpose of determining if the abuse-c on an aut-num object will be: abuse-c: [mandatory] [multiple] [inverse key] OR abuse-c: [single] [multiple] [inverse key]

  • The impact is further outlined as follows:

  • Process reviews will be required to ensure that abuse-c information is received for the ASNs. A proper migration plan for those members currently using IRT in case the authors state that the proposal's removal of section 8 entails deprecating IRT.

  • Systems WHOIS: A new mandatory attribute abuse-c will be required for aut-num objects. IRT object phased deprecation - subject to clarification received from the authors

  • Systems - MyAFRINIC: Coding updates to add the abuse-c to the ASN forms

  • The impact on Resource Holders would be that the 1738 resources members that have ASNs delegated to them @May 2021 will be requested to comply with this policy by providing their abuse-c contact and new members will be required to provide their abuse-c at the time of membership application

  • No financial impact for this proposal
  • Legal impact: The legal Team advises on the need for compliance with the Data Protection Act (DPA) in case personal data of the abuse-c are intended to be published on the WHOIS database. Alternatively, in order to ensure full DPA compliance, the authors may consider specifying the need for role-based email addresses so that no individual (data subject) may be identified through email addresses being adopted for that purpose.
  • In regards to implementation timelines, the proposal as written contains a number of unclear implications that need to be clarified. If implemented as drafted, would result in operational issues based on varying interpretation.

8.4) PDWG Chairs Summary

Darwin Da Costa went through the areas of the concerns for this proposal as follows:

Concern 1:

What is more intrusive, asking for validation or allowing victims to pay for the abuses? The concern is still pending and yet to be addressed by the author

**Concern 2: **

What is more intrusive, asking for validation or because it doesn’t exist and you don’t even bother to say “this is not abuse for me”, get the full network filtered by the rest of the world, or even worst, many AFRICAN networks become filtered?

The concern is still pending and yet to be addressed by the author

**Concern 3: **

What is more intrusive, asking for validation to the resource holders, or imposing the cost into AFRINIC, which is covered by members? The concern is still pending and yet to be addressed by the author

**Concern 4: **

What is more intrusive, asking for validation or enforcing the RSA, which stands for appropriate use of the resources? Is it appropriate to ignore abuses from your customers?

The concern is still pending and yet to be addressed by the author Darwin Da Costa mentioned that there are several points pending clarification from the authors.

8.5) Open microphone discussions on the proposal

Open microphone discussions on the proposal were open for 20 minutes. They are summarised as follows:-

  1. Dr Nii from Ghana DotCom - commented that the statements are confusing about which problems are being addressed. He further stated that AFRINIC should have control and should be in scope. We should focus on making the Internet good. He mentioned that the problem statements should be further discussed and properly state which particular problem it is trying to solve and hence it can be properly addressed.
  2. Alain Aina - speaking for himself - mentioned that the problem statement is not clear at all, the reason why we see all these clarification requests. The problem statement mentioned that the current policy fails to improve data accuracy, to which he mentioned that the current policy is not meant for that. It has never been about data accuracy. He also mentioned that for the first policy we could not define what abuse is and that it can hold different meanings depending on the country, and now with a second policy but still with no particular definition of ‘abuse’. He pointed out that we cannot, on one hand, discuss ‘ abuse’ and on the other hand, we fail to define what is ‘abuse’.
  3. Jordi Palet Martinez - mentioned that he is against this proposal and seeking clarifications from the authors and he pointed out that what is written in the proposal and what has been presented contains certain ambiguities. Firstly, they are asking the staff to do verification for all the contacts. His response to that is that if the previous proposal passes through the last call, the staff is free to use the same systems which will be implemented for the abuse-c for validating the contacts. If the staff believe this to be done by policy proposal, this can be worked on. His second concern is about the statement in the proposal which mentions that the abuse contact should be a person who can handle abuse. To this, he responded that this is a privacy issue, and this is not allowing the ISPs to put a list of people to manage the abuse and hence this will be a strong point against this proposal.
  4. Alain Aina - speaking for himself - stated that the proposal states that there is no need to treat the abuse contact particularly, that is, all contracts should be treated in the same way. To this, he responded that each contact has a dedicated role and now handling abuse has its own specificity.
  5. Patrick - a member of the Internet community - asked the author how removing an entire existing section addresses the actual problem statement that they mentioned which says that the problem is that we don't have mandatory contacts. How does this solution address the problem set out stated inside the policy?
  6. Jaco - on the Q&A - who asked the following question: What is the advantage of the secondary proposal over that from Jordi? It implies that the abuse contract must be a person which means that we cannot point this out to a support desk that has multiple people handling issues. This is oversimplified and I believe we will need to have a validation of contacts for example.
  7. Noah Maina - requested detailed clarification from the authors in regards to the problem statement in the proposal which says that the current policy fails to improve data accuracy in the WHOIS database. Darwin Da Costa gave the microphone to the Authors to respond to concerns/questions which have been raised.

The Author responded to the concern about the difference between this policy and the one presented by Jordi Palet Martinez as follows:

  1. This policy does not ask for verification every six months
  2. This policy is in the scope of AFRINIC to impose or to show network holders on how how to manage or to use their abusive mailbox

Darwin Da Costa requested the Authors to respond to the other concerns which have been highlighted on the mailing list.

The Author mentioned that these concerns will be addressed on the RPD mailing list.

8.6) PWDG Chairs decision

After deliberation, the PDWG Co-chairs made the following decision:

“Having considered the discussions in the RPD and the current Public Policy Meeting, the Co-chairs have determined that consensus has not been reached because a number of valid concerns/objections have not been addressed. The draft policy proposal will therefore go back to the RPD mailing list for further discussions and community inputs, and refinement.”

Before closing the meeting, the co-chairs gave the microphone to the participants who were on the open mic queue.

These are summarised as follows:

  1. Abdulkarim - from Nigeria - wanted to find out about the issue of the position of the Co-chairs and how consensus was raised. To this query, Darwin Da Costa mentioned that his question should be related to the proposal. The conversation was interrupted.
  2. Alain Aina - commented that one policy is being to the last call and the other policy- which included an unclear problem statement -is going back to the mailing list, that these should be carefully and properly handled so that we do not come back again with these discussions.

The Co-chairs closed DAY ONE of the PPM.

9) Proposal #3: RPKI ROAs for Unallocated and Unassigned AFRINIC Address Space

ID - AFPUB-2019-GEN-006-DRAFT03

9.1) PDWG Chair Introduction of the DPP and Discussion Flow

Darwin Da Costa gave a brief overview of the flow of the discussion and handed over the microphone to one of the authors for the presentation of the Draft Policy Proposal.

9.2) Author’s Presentation of the Draft Policy Proposal

Jordi Palet Martinez presented the proposal. This is version 3 of the proposal as 2 versions have been presented in previous meetings.

Bogons are unallocated and unassigned IP address spaces that are used for bad practices, hijackings, etc. The proposal aims at requesting AFRINIC to create AS0 ROAs for unallocated and/or unassigned space that is under its control. Space that has been already allocated is not covered by this proposal. ISPs can automatically filter these bogons if they so wish.

The process for ROAs validity periods and release of ROAs before assignment/allocation is left to AFRINIC staff to define, following usual internal procedures.

The Author highlighted the normative texts of the proposal notably:-

  1. AFRINIC will create ROAs with origin AS0 for all the unallocated and unassigned address space (IPv4 and IPv6) for which it is the current administrator
  2. Only AFRINIC has the authority to create RPKI ROAs for address space that is not yet allocated/assigned to its members
  3. If AFRINIC wants to allocate the address space to one of its members, the RPKI ROA or ROAs with origin AS0 will have to be revoked beforehand.
  4. AFRINIC should only add reclaimed resources at the end of the reclamation process (only change from version 2 of the DPP to this version)

The above sentence (d) is important as it helps to clarify what is the situation in the case of resource reclamations.

The Author mentioned that for v1 and v2 of this proposal, there were unsubstantiated objections (governments using RPKI/AS0 to censor networks) and they cannot change the proposal based on these unsubstantiated claims. Impact Analysis of v3 of this DPP is clear. The Author mentioned that they had cleared the inputs from both the community and previous policy impacts

The Author also provided references of the implementation of the proposal in the other RIRs (LACNIC and APNIC). AS0 is documented in Section 4 of RFC 6483.

9.3) Staff Impact Assessment

Presentation URL - https://static.sched.com/hosted_files/ais21/39/AIS21-AF33-Proposals-Impact-Assessment.pdf

Brice Abba from the AFRINIC Secretariat presented the impact assessment of the proposal. He mentioned the staff’s interpretation and understanding of the proposal as follows:-

  1. a) This proposal requires AFRINIC to create ROAs with origin AS0 for all its unallocated and unassigned IPv4 and IPv6 address space that it currently administers. Unallocated and unassigned space here means available and reserved space as per the AFRINIC extended delegated stats file.

  2. b) The 26 May 2021 these are the numbers of prefixes of available and reserved space

  3. IPv4 reserved: 339

  4. IPv4 available: 16
  5. IPv6 available: 736

  6. IPv6 reserved: 2994

  7. c) New prefixes received from IANA/PTI would immediately have AS0 ROA's.

  8. d) Any prefixes returned by or reclaimed from members will also have AS0 ROAs only at the end of the reclamation process
  9. e) When AFRINIC allocates address space to one of its Resource Members, the RPKI ROA or ROAs with origin AS0 covering the space will first have to be revoked AND not be visible in the repositories before the allocation/assignment can happen.
  10. f) The process for ROA validity periods and release of ROAs before assignment/allocation by AFRINIC is left for AFRINIC staff to define in internal procedures.

Impact on Registry Functions will be as follows:-

  1. An upgrade of the AFRINIC inventory management system will be required in order to implement this policy
  2. Automation of the creation of AS0 ROAs for resources currently unallocated in its inventory as well as incoming resources (either from resource reclamation, returns or replenishment of its pool from IANA/PTI)
  3. Adjustments of resource issuance process as well as timeframes to ensure that ROAs are revoked and that the revoked ROAs are removed from the validators repositories before the resources are issued.
  4. An update on AFRINIC systems interfaces & internal controls used for resource & transfer management will be required
  5. Improve overall monitoring to ensure that members do not consistently create ROAs with AS0 with the prefixes they need to announce in compliance with the policies under which they received these resources.
  6. Existing policies implemented or undergoing implementation will be put into consideration so that a check is run to determine which prefixes' usage does not require an announcement in the global routing
  7. Member documentation for ROAs management shall be updated
  8. No comments from Legal for this proposal
  9. Financial assessment mentions that No CAPEX will be required for the implementation of this policy proposal.

  10. 1On the RPKI side, 3 options have been scoped notably,

    1. Use the existing AFRINIC RPKI Tree
    2. Additional Production certificate (0/0) for unallocated space only
    3. New Trust Anchor with a single Production Certificate

The AFRINIC Secretariat’s recommendation is that a new TAL is implemented (option c).

  1. In regard to the implementation, AFRINIC has planned the migration to myafrinic v2 in Q4-2021. The AFRINIC inventory of unallocated and unassigned resources will be integrated on the myafrinicv2 platform and the technical team will be able to implement the AS0 ROAs on them. We have been advised that the policy can be fully implemented by Q2-2022.

9.4) PDWG Chairs Summary

Darwin da Costa mentioned that version 3 of the DPP was not discussed on the mailing list. There have been some concerns that were raised.

Concern 1 which is related to “I believe this policy would extend AFRINIC's power way beyond its control. AFRINIC is a registration entity and should not have authority over RPKI” has been addressed and the URL of the mailing list post covering the technical understanding of RPKI was provided.

Concern 2 related to ‘It is going to create a centralization on the control of the Internet which can result in an abuse of power. The risk of Internet centralization and undermine the legitimacy of AFRINIC as an impartial institution.” has also been addressed according to the archives that we have seen for the last couple of months and weeks.

Another major concern brought up on the list was in regard to “The current state of the RPKI infrastructure does not provide a sufficient period between the revocation of ROA and notification that a given prefix has been allocated to an organisation which can have a huge effect on the allocation. It takes time to revoke AS0 state for one IP address, not to mention many of the resources are allocated in blocks. So it will be extremely inconvenient to the end-users and ISPs if their network takes a very long period to “recover”. Is the imperviousness of the current proposed policy when it comes to human/computer error when revoking the AS0 state.”

This concern has been addressed by the staff response on the mailing list that it will take one day in the worst-case scenario and at best case scenario 5 minutes.

The concern regarding “Policy that potentially asks AFRINIC to proactively interfere with routing” has also been addressed. AFRINIC is only providing a service, like the WHOIS, to provide accuracy of what resources have been allocated to members and what are unallocated.

9.5) Open Microphone Discussions on the Proposal

Open microphone discussions on the proposal were opened for 20 minutes. They are summarised as follows:-

  1. Emem William from the University of Ilorin in Nigeria mentioned AFRINIC is a Regional Internet Registry and more like a record-keeping institution concerned with the registration of who owns IP addresses. Consequently, it will be out of the scope of AFRINIC’s operational responsibility to start being concerned about how and where IP resources are being used. If this policy is implemented, AFRINIC will now have the right to inject AS0(non-existing ASN) in the routing database. Deliberate and non-deliberate mistakes/human errors can happen and cause disruptions at the end-user end. This policy should be discarded completely.
  2. Widjane Goubi stated that she opposes the policy as it misunderstands RIRs’ role. RIRs cannot oversee the resource routing process. Insertion of AS0 in routing database wrongly reclaims space resulting in connection loss. This policy is also not accepted by other RIRs.
  3. Meriam from Mohamed VI Polytechnic from Morocco - opposes the policy and mentioned RIRs cannot interfere with routing. Enabling AS0 is not a policy issue and should be handled by a specialised entity.
  4. The author, Jordi clarified that resources can still create AS0 ROAs for resources that they hold. This policy does not change that. The policy proposal is not mandating anything about routing but about registration data represented in a different way. Only RIPE NCC rejected the proposal and LACNIC/APNIC accepted the policy. There is no obligation for ISPs to use the data. The AS0 is a standard way to present the information, instead of each AS getting the data from the WHOIS database.
  5. AFRINIC has mentioned that the impact is minimal. mistakes may happen but they can also happen with the WHOIS. We are presenting the same information that we have in the WHOIS in a single way.
  6. Alain Aina, speaking for himself mentioned that he has no concerns with the proposal. He suggested that the Cochairs present the objections and add who submitted the objection and if the objection is considered valid or not. He asked staff about why the upgrade of the inventory will be needed. In regard to the policy, he asked the author for clarification and education of those who have no knowledge about the proposal, that the problem statement is made clearer. He would like to see why the bogon filtering is not enough and why we need AS0. We need to make sure that we align with the AFRINIC and policy system. The proposal mentions unallocated and unassigned. Statistics data published by AFRINIC mentions available and reserved. Anyone wanting to look for the numbers that will be covered by AS0 will find them under reserved and available.
  7. Prof Nii Quaynor, from GDC commented that those who run networks are able to see what’s good for them because they can see all the issues and avoid them and that those who are opposing the proposal can answer if they can run networks. He stated his concerns that if the text should be similar to other RIRs, then this is the route to be taken for global policies. Else it would be preferable that we use our own text. AFRINIC can decide when to add the AS0 as details about the reclamation process are not known.
  8. Author Jordi mentioned that mechanisms for bogons do not come from an official registry. Same text across the regions for the sake of clarity. Global policy is not the objective now as in principle, it is not needed. The global policy will be related to the resources held by IANA if the decision to go for that is made. The text was included to clarify the objection. In response to the Question from Anthony in Q&A, legal assessment in impact assessment mentioned no comments.
  9. The legal Advisor of AFRINIC commented on the statement that AFRINIC is a mere bookkeeper and recommended the reading of the ICP-2 document, Bylaws, and RSA to know what is the real mandate of AFRINIC, before trying to limit its mandate to be a mere bookkeeper.
  10. Vincent Ngundi, PDWG Chair, mentioned that the comments be restricted to unaddressed objections and referred participants to an email from Nishal in September that clarified the concerns.
  11. Madhvi Gokool, the AFRINIC staff, responded to the question from Alain and stated that the implementation of this proposal requires the unallocated/unassigned, i.e. available and reserved space. Myafrinicv2 implementation is in progress and will facilitate the integration of the inventory system and RPKI.
  12. Darwin Da Costa, PDWG chair also stated that the mailing list archives contain informative emails from Nishal and Amreesh.

9.6) PWDG Chairs decision

After deliberation, the PDWG Co-chairs made the following decision:

***“The Co-Chairs note that the latest version of this policy proposal was submitted on the RPD mailing list on 19th April 2021, which is more than two months ago. ***

***We further note that no comments were made on the latest version of this policy proposal in the RPD mailing list. ***

***We also note that the contentious issues raised have already been adequately addressed by either the Authors or members of PDWG. ***

Having considered the above, the discussions during the current PPM, and the authors have addressed the concerns raised by the PDWG, the Co-chairs have determined that rough consensus has been reached.

***The draft policy proposal, therefore, moves to the Last Call. We further encourage the PDWG to actively participate and engage in the RPD mailing list discussions. ***

While the policy proposal will be progressed to the Last Call, we encourage the PWDG to raise any further valid objections during this the Last Call period in order to inform the progress of the policy proposal going forward.”

10) AFRINIC-34 Competing Policy Proposals

Vincent Ngundi, the PDWG Chair, opened this session. He stated that each author of the proposals will be given 15 mins to give an overview of their proposal, followed by a presentation of the Cochairs on the aspect of competing elements of the DPPs. The PDWG will then be able to discuss and map the way forward. 

Ther Co-chair also mentioned that there were four (4) DPPs aiming at updating Section 3 of the CPM.

10.1) PDP Working Group(WG) Guidelines and Procedures

Presentation URL - https://static.sched.com/hosted_files/ais21/a1/AIS21-AF33-PDP%20Working-Group-Guidelines-and-Procedures.pdf

Authors Alain Aina and Noah Maina presented on the DPP PDP Working Group(WG) Guidelines and Procedures. Alain Aina stated that PDP is based on a Working Group and the latter must have its procedures, how it operates, and moderate discussions. This is one coherent document that holistically addresses & proposes how the WG should be administered including a Co-chair appointment, rather than piecemeal fixing.

PDP is not being redesigned. Some sections of the PDP are being updated.

Noah Maina mentioned that:-

  1. the Current PDP does not have clear procedures for its operations that it can follow for its activities, which has led to misinterpretations and challenges in the PDP.
  2. Problem Statement - Ensure that there are clear and specific guidelines and procedures that can be followed by Co-chairs and the WG. Amends Section 3.3 of current CPM
  3. The proposal serves as a guideline on how the PDWG shall operate, defines clear roles and responsibilities for the Co-chairs, and clear procedures for the Working Group administration. It also defines the appointment process of Co-chairs, notably starting by consensus-based appointment as WG operates within the mandate of consensus on policy proposals, secret ballot(Rank preferential Method) is another approach and Interim Appointment which can be done by the Directors. The proposal also addresses the behaviour of the members of the WG.
  4. Version 1 of the proposal was submitted in July 2020 and version 2 was submitted in July 2021. The update to version 3 will now be addressed.
  5. Issues raised with version 2 are the appointments by consensus and Board Chair appointing interim Co-chairs
  6. Impact assessment - no issues received for v2.0 and authors clarified the requests for clarifications.

  7. Updates for v3.0 addressed the following:-

  8. Some amendments were made (editorial), notably the appointment of interim Co-chairs by the Board Chair, time limits for same and set the ranking voting college ( to consist of past PDWG Chairs, past Board Chairs, and past CEOs).

  9. Provisions for the recall of Co-chairs have also been added. The AFRINIC staff analysis of this version is in progress and expecting staff response after this presentation. The flow of the entire process for co-chair appointments was shown. Once the nomination is complete, in the case of no candidate, within 2 weeks, the Board Chair shall appoint interim Co-chairs.

If there is more than 1 candidate, the candidates are slated for appointment happens in the PPM. Else if consensus is reached, PDWG Co-chairs are appointed and if appointment by consensus fails, the seat remains vacant and within 2 weeks the Board Chair appoints the interim Co-chairs.

In the case of non-consensus, the preferential rank voting method by secret ballot is used by the voting college to select the Co-chair, within the scope of procedures for voting. If this fails as well, the Board Chair shall appoint interim Co-chairs within 2 weeks.

In the case of misbehaviour from WG, the individual is warned by the Co-chairs, and if severe and disruptive behaviour is observed, the Co-chairs will warn privately, publicly or suspend the individual. The individual can also appeal the suspension.

In regard to the recall of Co-chairs (section 3.3.4. of the proposal), there is an added provision that if a Co-chair does not attend two consecutive AFRINIC Public Policy Meetings without reasons or has been publicly reported by the other Co-chair as no longer attending to the working group’s affairs without reasons, the Co-chair will be removed from its role.

Also, anyone may request for the recall of a Working Group Co-chair. The proposed change is that the request must be supported by at least 10 other persons.

The author gave an overview of the Appeal process in Section 3.3.10 as follows:-

A WG member may file an appeal against the decision of the Co-chairs to suspend his posting privileges to the Chair of the AFRINIC Board. The latter’s decision is final and binding. Should a member of the WG disagree with the Co-chair decisions, there is a conflict resolution process provided in the PDP. Actions are taken by the AFRINIC Board Chair regarding the appointment process of Co-chairs are final and binding.

10.2) Simple PDP Update for the new “Normal

Presentation URL - https://static.sched.com/hosted_files/ais21/24/AFPUB-2020-GEN-003-DRAFT01-PS-v2.pdf

Author Jordi mentioned that he misunderstood the PDWG Chairs request and had prepared slides regarding the problem statement only. He will also present the slides regarding this proposal that was discussed at the previous meeting.

In regard to the problem statement, the PDP is good in general and simple, easy to follow. Learning from experience, there is always room for improving the PDP and we should keep it simple.

The issues that are observed by the Author in the existing PDP are as follows:-

  1. explicitly make it inclusive and non-discriminatory
  2. in respect to whether mailing list discussions are taken into consideration in the determinations for consensus/non-consensus, a reading of the PDP does not make this clear and in fact the Appeal Committee (AC) does not read the PDP that way.
  3. The meaning of Consensus and Last Call are not explicitly mentioned.
  4. There is a need to allow exceptional situations, such as the Covid-19 pandemic - Flexibilisation of the timings and even the number of PPMs per year.
  5. Problem faced sometimes is that all policy proposals cannot be discussed in a meeting unless we have 10-15 minutes per proposal which does not make sense.
  6. Proposals can have a shorter process for reaching consensus. It is not necessary when we have several versions of a proposal to go into a meeting to present them to reach a consensus. Sometimes if issues to do with a policy proposal had been discussed at a PPM and are clearly resolved in the list, it may not be presented again in a PPM. This is currently done at LACNIC. This avoids more and more proposals that don’t reach consensus and less time per proposal in PPM.
  7. Impact analysis to be mandatory and timely. 4 weeks are sufficient.
  8. Chairs need time to decide - 5 minutes or a week may be too short. Timelines of 2 weeks after a PPM is enough to allow the Co-chairs to analyse deeply pro’s and cons and make a better determination of consensus which may lead to fewer appeals.
  9. Judging the same way in 2 different ways - the ToR of AC needs to be determined by PDP.
  10. Tackling the issue of Co-chair selection/recall in the same process is too complex. Better to split the problem.
  11. Expiry of DPP in 6 months.
  12. Provide the definition of the Last Call - explained the same way of consensus in IETF.
  13. The timing of proposals was also explained for new proposals or new versions of an existing proposal.

10.3) Chair Selection Process

Presentation URL - https://static.sched.com/hosted_files/ais21/bc/AFPUB-2019-GEN-007-DRAFT02-PS-v2.pdf

The Author mentioned that the Co-chair selection process needs improvement based on recent events. Actual

PDP lacks sufficient detail. Issues are as follows:-

  • How are Co-chairs selected?
  • Who can be a Co-chair?
  • What is the process of selection?
  • How much time do we have for selection?
  • How can we ensure experience & diversity?
  • Who selects the Co-chairs?
  • What if they step down or are recalled?
  • How do we have a resolution in exceptional situations?

The proposal suggests the following changes:- - Chairs should be nominated by members or members themselves. - Chairs should have been participating on the list at least 12 months before the start of the selection. - People electing the Chairs to have been on the list for at least six months. - To note that this has been already implemented somehow by staff in the previous elections.

The author suggests that the authors of competitive proposals sit together and come up with a single proposal for PDP Update and a single proposal for Co-chair selection. Two different proposals will make it easier to reach a consensus.

10.4) Open Discussion with the PDWG on the Way Forward

Vincent Ngundi, PDWG Chair, made a presentation on the competing proposals. The presentation is available from Slide 45 at https://static.sched.com/hosted_files/ais21/27/AIS21-AF33-PPM-AFRINIC-PDP-and-Building-Consensus.pdf

The Co-chairs prepared a table that maps what areas the various policy proposals seek to review (or introduce) as regards Section 3.0 of the CPM which covers the AFRINIC PDP.

  • The table should not be misconstrued as the opinion (or endorsement) of the Co-Chairs but a way for the community to realise that the four policy proposals compete in one aspect or the other.
  • The intention is to assist the PDWG as well as the authors in charting a way forward. The table has 6 columns:- Column 1 identifies the Section of CPM being reviewed, Column 2 provides a summary of new provisions to the CPM for the various policy proposals & the last four columns are for policy proposals sections that address the provisions. All the proposals have very good ideas but cannot go through unless there is a harmonised way of looking at the provisions.

Vincent Ngundi elaborated on the sections of the CPM that were being addressed as follows:-

  1. Responsibilities of PDWG Co-chairs - 2 competing proposals that seek to address this, by making them more detailed
  2. Terms of Co-chairs - One proposal introduces conditions for ‘returning Co-chairs
  3. Eligibility Criteria of cochairs - 2 competing proposals Document the eligibility criteria of Co-chairs
  4. Selection of Co-chairs - 2 competing proposals mention how co-chairs shall be selected? Various methods (consensus, elections, elections(IRV)
  5. Voting Register - 2 competing proposals have sections as to Who can vote?
  6. Resignation of Co-chairs - one proposal mentions Resignation of 1 and both Co-chairs
  7. Absence of Co-chairs in PPM - 2 competing proposals cater for the absence of 1 and both Co-chairs
  8. Role of temporary Chair - One proposal defines what the temporary Chair can do
  9. Operations working group (PDWG) - One proposal defines how moderation of working group discussions and sessions shall happen
  10. Application of Code of Conduct - One proposal Introduces a clause regarding Code of Conduct on RPD mailing list - based on the experience lived in the last months/year
  11. Definition of “Rough Consensus” - One proposal defines rough consensus so that it is not ambiguous
  12. Draft Policy Proposal - One proposal makes changes to timelines of submission
  13. Expiry of DPP - One proposal introduces a modification to the lifetime of a DPP
  14. Impact Assessments - One proposal makes Impact Assessments mandatory
  15. Discussion Timing - One proposal introduces changes to discussion timings
  16. Public Policy Meeting - More PPM online - competing proposals
  17. Participation at PPM - In one proposal, Co-chairs can restrict participation in PPMs under certain conditions (restricted participation but not restricted attendance!)
  18. Consensus Determination - Can also happen outside a PPM on the RPD list, after a DPP has been discussed at a PPM - competing for proposals
  19. Last Call - One proposal introduces a timeline of 1 week to confirm consensus. Any new objections must also be substantiated and must therefore not be based on opinions lacking a technical justification.
  20. Conflict Resolution (Appeals) - One proposal introduces a role for the Board Chair in the appeal process
  21. Conflict Resolution (Co-chairs Appointment) - One proposal introduces a role for the Board Chair in the appointment process of Co-chairs
  22. Conflict Resolution (Recall of Co-chairs) - Introduces a role for the Board Chair in the appointment process of interim Co-chairs, Updates to the Co-chairs recall process section of the CPM. Competing proposals.

The open microphone discussion then followed. An overview of the contributions are as follows:-

  1. Jordi, the author of 2 competing proposals, mentioned that the proposals are based on actual experience of active participation in the 5 registries. Similar proposals have been implemented in LACNIC 2 years ago with very good results. He suggests that the appeal and code of conduct be different proposals to simplify consensus. These have been proposed in the LACNIC region. He also suggested that should all of the authors agree to get together, 4 policy proposals will simplify reaching consensus - One for selection, one for the PDP, one for the code of conduct and one for the appeals to be proposed as they are not related.
  2. Noah, an author of one competing proposal, mentioned that a piecemeal approach as being suggested by Jordi may introduce contentious situations. The proposal guidelines and procedures holistically cover some of these areas. He encouraged the authors of all four proposals to consider one single proposal which can be updated with the elections and recall of Co-chairs. This proposal is based on past experience within our region and considering how the working group has been managing itself and operating in the past few years.
  3. Alain, the co-author of one competing proposal on guidelines and procedures, mentioned that the issue needs to be looked at holistically as looking at issues one by one will lead to inconsistencies. He proposes first an agreement to all the issues and problems globally and then works on how they can be solved one by one. Splitting into small groups to work on the issues and decide in the end to merge into one document or have a different document.
  4. Jordi mentioned that splitting into parts is his recommendation as they are differentiated.
  5. Prof Nii Quaynor mentioned that competing proposals suggest that another process is required to make a holistic upgrade. The Simple PDP Update. He has a big issue with making I. A mandatory and asked whether it has been a problem. We should stop trying to do elections - if policies use consensus, the latter can be used to select the Co-chairs.
  6. Gregoire Ehoumi mentioned that the table presented by PDWG Co-chairs provided a good summary. He suggested that a merging be done on the RPD mailing list. He stated that what is being done in other regions may not fit within the AFRINIC PDP reality and processes. He suggests that there is a need to agree on each section.
  7. Jordi mentioned that he had proposed his proposal in AFRINIC after finding that the one he submitted in LACNIC years ago worked. With regard to I.A, staff always provide impact analysis, but raised the concern of late submission of the I.A, resulting in no time for updating a DPP before a PPM resulting in a DPP staying in discussion for an additional 6 months and this leads to accumulation of proposals. The mandatory requirement is so that I.A’s are submitted on time. He argues that shorter discussion times help both the community and authors.

  8. Caleb, the co-author of one competing proposal, offered the following suggestions:-

  9. Open to hold meetings with the other authors to develop the sections.

  10. There is a lack of inclusion.

  11. Gender/region balance to be infused in the policies

  12. Prof. Nii Quaynor mentioned that it is better to have fewer well thought out proposals and take into consideration that a faster pace will bring in problems. Increase participation of PDWG by making the problem something they can own.

Vincent Ngundi mentioned that there is now a need to map the way forward. It is clear that some changes are needed in the PDP and that some form of collaboration for proposals is required. There is a need to keep the end in mind and if that end is to enhance the AFRINIC policy development, it becomes the community’s proposal. A responsible Working Group can correct the issues of the past.

Alain Aina requested the PDWG Chairs to lead the Working Group on the issue of the problems and help with the agreement of problem statements so that the community agrees on the problem(s) to be solved and then the solution to each of the problems can be sought.

11) Open Microphone on the PPM

The highlights of the open microphone session are as follows:-

  1. The PDWG Co-chairs were thanked for managing the sessions but that there is still room for improvement. Moving forward, more changes in the process are expected.
  2. The format of online meetings needs to be looked at, especially in terms of time limits, time management.
  3. Once a policy proposal is submitted, the Working Group can then take the lead and contribute.
  4. One challenge experienced, according to PDWG Co-chairs, is how to strike a balance between the number of proposals and the time.
  5. The PDWG Co-chairs were commended for doing a great job over a remote system.
  6. A comment from an author is that they work for the community and that once the community likes a proposal, his role switches to that of an editor.
  7. Webinars to be organised. PDWG Co-chairs mentioned that they will consider this and come back to the WG with proposals for the way forward.
  8. On the subject of Impact Analysis, Section 3.4.1 mentions that Co-chairs may request. There is no need to have more Impact Analysis if changes are not made to a proposal.
  9. Use of Working Groups to look at some of the technical issues and report back.
  10. Webinars should not be part of the decision mechanism of the PDP.
  11. It’s a good thing that the PDWG Co-chairs are dealing with issues.
  12. A comment was made regarding the policy draft maturity process and the PPM process to be looked at so that there is a way to agree and accept to work on the problem.
  13. Discussions on policy proposals have to be brought back to the RPD mailing list, even if discussed in webinars.
  14. During proposals discussion, issues that have been raised perhaps addressed shouldn't be repeated, unless they are serious & really needs the PDWG’s attention
  15. Response with courtesy and appreciation of challenges the organisation faces.
  16. The chat panel contains useful comments. Staff confirmed that a copy of the contributions can be obtained.

12) Close of the AFRINIC PPM

Vincent Ngundi and Darwin da Costa, PDWG Co-chairs, thanked the AFRINIC Board and everyone who contributed to making the PPM a success, before closing the Public Policy Meeting.

Summary of Co-Chair Decisions on Draft Policy Proposals

Proposal Decision Comments
Abuse Contact Policy Update Last Call
General Abuse Contact Back to the RPD List for further discussion
RPKI ROAs for Unallocated and Unassigned AFRINIC Address Space Last Call