Search RPD Archives
Limit search to: Subject & Body Subject Author
Sort by:

[rpd] Minutes of PPM held online during the AIS 20

Gregoire EHOUMI gregoire.ehoumi at yahoo.fr
Mon Oct 12 21:38:54 UTC 2020


Dear Co-chairs,

The minutes were due for the 8th October 2020 according to the PDP, came in today and are not accurate.
In my email on of September 21, 2020 on behalf of the authors of WG guidelines and procedures and AFRINIC Number Resources transfer proposals (https://lists.afrinic.net/pipermail/rpd/2020/011396.html <https://lists.afrinic.net/pipermail/rpd/2020/011396.html> ) I mentioned that co-chairs chose some objections raised and non-raised.

For example objections below were in summary and decisions, but are NOT in the minutes :

1⁃ Abuse contact proposal
GDPR compliance
2- Resource Transfer Policy AFPUB-2019-V4-003-DRAFT02
· 5.7.4.3. Transferred legacy resources will still be regarded as
legacy resources.


They are NOT mentioned anywhere in the contributions from participants and staff, but co-chairs did mention them, and later added them in the "Decisions and summary on policy proposals discussed during the online Policy meeting (AFRINIC 32)" (https://lists.afrinic.net/pipermail/rpd/2020/011372.html <https://lists.afrinic.net/pipermail/rpd/2020/011372.html> ).

The co-chairs conclusion's on this video : https://youtu.be/Wt6-fYwKhxs <https://youtu.be/Wt6-fYwKhxs>
does not fully reflect the decision summary and the minutes.


Best regards,

Gregoire Ehoumi



> On Oct 12, 2020, at 5:02 AM, ABDULKARIM OLOYEDE <oloyede.aa at unilorin.edu.ng> wrote:

>

> Dear PDWG,

> Please find below and attached the minute of the PPM held online during the AIS 2020. Please let us have your comments on the document.

>

> <>DAY 1

> 16 Sep 2020

> <>Agenda

> 1. Simple PDP Update for the new “Normal” AFPUB-2020-GEN-003-DRAFT01

> 2. PDP Working Group (WG) Guidelines and Procedures AFPUB-2020-GEN-002-DRAFT01

> 3. Chairs Elections Process AFPUB-2019-GEN-007-DRAFT02

> 4. Board Prerogatives on the PDP AFPUB-2020-GEN-004-DRAFT01

> 5. Policy Compliance Dashboard AFPUB-2020-GEN-001-DRAFT01

> 6. PDP co-chair election Results

>

>

> <>1. Introduction to the AFRINIC PDP

> Presentation URL :https://2020.internetsummit.africa/components/com_afmeeting/speakers/98/1600274447_tmpphpwXyLct.pdf <https://2020.internetsummit.africa/components/com_afmeeting/speakers/98/1600274447_tmpphpwXyLct.pdf>

>

> Session started at 11h24 UTC

> Madhvi Gokool welcomed the participants to the AFRINIC Public Policy Meeting.

> She provided an introduction to the AFRINIC development process as well as proposals at public policy meetings. The policy development includes a set of steps for a community proposal that liberates and adapts the policies that guides the resources of the service region.

>

>

> A brief description of the PDP was shared as follows:

> ● It’s an open, bottom-up and transparent process where anyone can submit a proposal and anyone can participate to policy discussions.

> ● A policy proposal is submitted to the rpd at afrinic.net <mailto:rpd at afrinic.net> mailing list

> ● The proposal is discussed on the list for a minimum of four weeks and presented at a public policy meeting for face-to-face discussions and consensus seeking.

> ● If there is consensus at the face-to-face meeting, the proposal advances to a “last call period” that should last a minimum duration of 2 weeks, just in case there are issues from individuals that did not get a chance to participate.

> ● If there is no consensus at the face-to-face meeting, the proposal goes back to the mailing list discussion phase.

> ● If consensus is maintained after close of last call, co-chairs recommend for the Board to ratify the policy proposal. The Board of Directors will ratify it and AFRINIC will implement it as a policy.

>

> All ratified policies are documented in a manual 0 CPM on the AFRINIC website

>

> PDWG - which is composed of anyone involved in discussing a proposal. All the participants today will form part of the Policy Development Working group

>

>

>

> <>

> <>Status of ratified policies

> Multihoming not required for ASN(AFPUB-2019-ASN-001-DRAFT04) - Implemented

> IPv6 PI clarification(AFPUB-2019-v6-001-DRAFT02) - Partly Implemented with an implementation date of 30 Sep 2020

> Adjusting IPv6 PA Policy(AFPUB-2019-v6-002-DRAFT01) - Under Implementation 30 Sep 2020

>

>

> <>An overview of reactions from Participants:

> In the light of incidents in which participants are trying to harm the process , how can this be fixed ?

> The PDWG needs to take into consideration the new era where most discussions would happen online . Perhaps use the open mic and future sessions to discuss this.

> <>2. Code of conduct

> Presentation URL : https://2020.internetsummit.africa/components/com_afmeeting/speakers/2755/1600274612_tmpphpwArKBy.pdf <https://2020.internetsummit.africa/components/com_afmeeting/speakers/2755/1600274612_tmpphpwArKBy.pdf>

>

> Abdulkarim Oloyede , PDP co-chair spoke about the Code of Conduct and introduced the agenda over the 2 days.

> The sessions were kickstarted with the Policy Implementation Experience Report.

>

> <>3.. Policy Implementation Experience Report (Presented by Dev Jeenia)

> Presentation URL :https://2020.internetsummit.africa/components/com_afmeeting/speakers/913/1600274633_tmpphpvMXHOk.pdf <https://2020.internetsummit.africa/components/com_afmeeting/speakers/913/1600274633_tmpphpvMXHOk.pdf>

>

> Dev mentioned that his presentation will cover the experiences of Member Services staff when they refer to the policy manual, issues concerning current policies that are found to be vague and ambiguous, or which have conflicting text in different sections. We will also talk about recently implemented policies.

> In return, the community may assist by updating the policies.

> Recently implemented policies,

>

> - IPv6 PI clarification.

>

> Section 6.8 of CPM - members don't need to announce their Iv6 prefix, e.g critical infrastructures or root server operators.

>

> This policy is partially implemented and it is expected to be fully implemented by the end of September 2020 . Members can request rectification of any of the IPv6 prefixes if required at the moment

>

>

> - multihoming not required for ASN.

> This is fully implemented. It is no longer required to be multihomed to be eligible for an AS Number. Unique routing policy or demonstrate technical need for an AS Number.

>

> - AFRINIC entered phase 2 of the implementation on 13 January 2020.

> Section 5.4.3.2 and related subsections were implemented. There were several changes which were made, such as the minimum IPV4 a prefix size which is /24 and the maximum is /22.

>

> Also, the allocation and assignment period is now based on needs for eight months.

>

> Some contradictory text currently exist in the policy manual.

> - Section 5.4.3.2, it states the minimum allocation size will be /24 and the maximum will be /22. However, in the policy manual 5.5.1.2.1, it mentions the minimum allocation is /22, which is not relevant any more.

>

> - In section 5.4.5, which states the current allocation and assignment period of 12 months shall be changed to 8 months, but in another section, 5.6.3, specifically for PI assignment, it mentions a one year growth protection, which is not relevant since AFRINIC now looks at needs for the eight months .

>

> - For members who need additional IPv4 resources. As for section 5.4.6.1, the member must have used at least 90% of all previous allocations or assignments. But in section 5.5.1.4.1, it states about 80% of address space has been used to be considered eligible for IPv4 resources.

> This is problematic as many members tend to choose what fits their current situation and request for additional IPv4 when they are at around 80% usage. So it becomes challenging for AFRINIC staff to clarify certain situations.

>

> Since any change to the Policy Manual has to go through the Policy Development Process, AFRINIC once again requests the community to decide whether to propose a change for removal of the conflicting text or obsolete policy text, or even propose a new policy.

>

> - Abuse complaints. The section 8 of the CPM recommends publishing and abuse contact in IP resources and is a non-mandatory policy. That is, the members are not obliged to comply with this section of the manual. This could be the reason why we have a very low adoption of IRT objects. Since very few members have an abuse contact, AFRINIC is receiving most of the abuse complaints.

> - To note that some operators who will start filtering traffic from our region because of missing abuse contact. So, each time AFRINIC receives abuse complaints, the sender is informed on how to look at the contact of the members who are managing those particular IP ranges.

>

>

> <>An overview of reactions from Participants:

> - Conflicts with text in the CPM should not normally exist . New policies amend old sections and the latter can be removed if amended/obsolete in the CPM.

> <>Simple PDP Update for the new “Normal” AFPUB-2020-GEN-003-DRAFT01

> Proposal URL : https://afrinic.net/policy/proposals/2020-gen-003-d1 <https://afrinic.net/policy/proposals/2020-gen-003-d1>

> Presentation URL : https://2020.internetsummit.africa/components/com_afmeeting/speakers/3283/1600275636_tmpphpOsXL1i.pdf <https://2020.internetsummit.africa/components/com_afmeeting/speakers/3283/1600275636_tmpphpOsXL1i.pdf>

> Impact Assessment URL : https://afrinic.net/policy/proposals/2020-gen-003-d1#impact <https://afrinic.net/policy/proposals/2020-gen-003-d1#impact>

>

>

> <>Introduction by Author(s): Jordi Palet Martinez

> The author

> ❖ has more slides than what he will use in the session for the sake of time. The policy can be consulted on the website

> ❖ Considering the Covd-19 situation , this proposal is being presented

> ❖ Consensus is determined by co-chairs assessing the inputs of the mailing lists and the discussions at the PPM

> ❖ Virtual meetings are to be considered as part of the PDP

> ❖ Clarified on the definition of consensus and Last Call

> ❖ Timing of decision making - co-chairs have very less time to assess and determine consensus

> ❖ there are three possibilities:

>

> 1) 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.

> 2) 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 in the list ends.

> 3) A new version of an existing proposal that has been already presented in a previous PPM, could reach consensus on the list, without the need for a new presentation. This possibility depends on the co-chair's decision, for example, when the reasons for not having reached consensus in the last PPM may have been already addressed by a new version. This new version must have been discussed in the list also during 8 weeks.

> ❖ 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.

>

>

> <>Staff Impact Assessment

> Madhvi Gokool, AFRINIC Policy Liaison presented the impact assessment of this policy proposal. She mentioned that :-

>

>

>

> ❖ Upon the receipt of a policy proposal, which is usually quite detailed, several staff members would assess it and reach out to authors if the language is ambiguous. The assessment also covers the impact of the policy proposal should it reach consensus and be ratified on the registry functions and systems. Where some policies are editorial updates, the impact could be minimum but some policies are technical. A variation of the impact assessments will be observed as they have been adapted to the context of the proposal.

> ❖ The clarifications being requested are :-

> Section 3.3 mentions that at least 2 PPM will be held per calendar year and this is also mentioned in the CPM. The bylaws mention that a PPM shall be held at least once a year. We recommend to align with the bylaws.

> What do the authors mean bt DPP/version and a clarification regarding the timelines.

>

> The author, Jordi Palet then clarified that :-

>

> ❖ There is no misalignment with bylaws.. At least one PPM shall be done and AFRINIC does 2 meetings per year except for this year

> ❖ Editorial clarification - timings are based on the date of submission of the proposal

> ❖ DPP/version is a new version or new Policy proposal

>

> <>An overview of reactions from Participants:

>

> ❖ Mailing list was a right tool 10 yrs ago and now there is a trust issue - recommend vetting of subscribers to the mailing list

> ❖ Manipulation if mailing list is used to determine consensus

> ❖ Someone with various accounts can manipulate the entire process.

> ❖ No essence at having a PPM

> ❖ Face to face meetings are used to solve the issues , while most discussions happen on mailing list

> ❖ Consensus can be easy to reach if a summary of mailing list discussions is brought to the PPM and the issues are broken down. Wrong problem may be trying to be solved at this time

>

> <>Response by Authors to contributions from participants

> The author summarised that :-

>

>

> ❖ consensus is based on justified objections so less possibility of manipulation

> ❖ IETF and other RIRs only use the mailing list and anonymity exist there

> ❖ Non-anonymous participation is a possibility but not needed

> <>Chairs Decision

> AbdulKarim, PDP co-chair mentioned that their decisions will be kept until the second proposal has been presented as it is similar to this one.

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

>

>

>

> <>PDP Working Group (WG) Guidelines and Procedures AFPUB-2020-GEN-002-DRAFT01

> Proposal URL : https://afrinic.net/policy/proposals/2020-gen-002-d2 <https://afrinic.net/policy/proposals/2020-gen-002-d2>

> Presentation URL : https://2020.internetsummit.africa/components/com_afmeeting/speakers/246/1600275767_tmpphpYMad3T.pdf <https://2020.internetsummit.africa/components/com_afmeeting/speakers/246/1600275767_tmpphpYMad3T.pdf>

> Impact Assessment URL : https://afrinic.net/policy/proposals/2020-gen-002-d2#impact <https://afrinic.net/policy/proposals/2020-gen-002-d2#impact>

>

> <>Introduction by Author(s): Noah Maina

> ❖ The proposal serves a guideline on how the PDWG shall operate

> ❖ Defines clear roles and responsibilities for the PDWG co-chairs.

> ❖ Defines clear procedures for the working group administration.

> ❖ Defines the appointment process of co-chairs

> ❖ • Consensus based appointment • Secret Ballot (Ranked-Preferential Selection) • Interim Appointment

> ❖ Individual Behaviour of members of the working group.

>

>

>

> <>Staff Impact Assessment

> Madhvi Gokool, AFRINIC Policy Liaison presented the impact assessment of this policy proposal. She mentioned that :-.

> ❖ Clarification requests are lengthy , so cannot be covered quickly and based on the feedback from authors, the impact assessment on the website will be updated.

>

>

> <>An overview of reactions from Participants:

> ❖ Adds in scenario which is not necessarily complexity

> ❖ There needs to be clear as to the advantage that consensus has over voting system

> ❖ majority voting, or even ranked voting is more efficient, straightforward and transparent

> ❖ Brings complexities

> ❖ Chair by consensus will not work in this region

> ❖ Work done by mailing list would reduce the transparency

> ❖ Consensus in a large and diverse community will be something not may be painful but difficult to reach, if reachable, because it does not mean it is reachable all the time.

> <> Co-Chairs Decision

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

>

>

>

> <>Chairs Election Process

> Proposal URL : https://afrinic.net/policy/proposals/2019-gen-007-d2 <https://afrinic.net/policy/proposals/2019-gen-007-d2>

> Presentation URL : https://2020.internetsummit.africa/components/com_afmeeting/speakers/3283/1600275814_tmpphpwYdPzw.pdf <https://2020.internetsummit.africa/components/com_afmeeting/speakers/3283/1600275814_tmpphpwYdPzw.pdf>

> Impact Assessment URL : https://afrinic.net/policy/proposals/2019-gen-007-d2#impact <https://afrinic.net/policy/proposals/2019-gen-007-d2#impact>

>

> <>Introduction by Author(s): Jordi Palet Martinez

> ❖ This proposal tries to update the existing process , giving some specific timings, including it in the PDP

> ❖ Consensus in elections is still possible with this proposal and it happened this year for the PDP co-chair elections

> ❖ Elections start 3 months in advance of a PPM , where ratification is needed. The 3 months are needed in case of a type we need additional time to rank the rest of the candidates.

>

> <>Staff Impact Assessment

> Madhvi Gokool, AFRINIC Policy Liaison presented the impact assessment of this policy proposal. She mentioned that :-

> ❖ Diversity requirements and who can nominate co-chairs

> ❖ Who can participate in the selection can be verified from the nailing list in the back end

> ❖ there is no impact on any registry function. If online elections (inaudible), we have the systems that can be customised for that

> ❖ Authors to clarify what are the roles that are directly involved in the PDP.

> ❖ Can the authors clarify what "The board may delegate some or all of the required functions into the Election and Nomination Committees." means in Section 3.3.2.15

> ❖ Section 3.3.2.15 also states that "the Board is the highest instance of appeal for matters related to the election". Does this mean that conflicts related to election shall not be handled in accordance with Section 3.5 of the CPM?

>

> The author, Jordi Palet then clarified that :-

>

> ❖ Roles that are directly involved in PDP - Board, appeal, election committee, ASO-AC, ICANN Board

> ❖ Bylaws do not make mention of the PDP co-chair election

> ❖ Bylaws and PDP do not explicitly mention that the board can empower committees to handle the election process and hence we would like to make it explicit in the proposal

>

>

> <>An overview of reactions from Participants:

>

> ❖ Section 3.3.2.2 - does not clarify the mechanism that shall bring in fairness in the elections

> ❖ Discriminatory to limit electors as it will not allow someone twho has actively taken part in ⅘ months to participate.

> ❖ Avoid election fever

> ❖ Twisting Mailing list into voter register is not appropriate

> <>Response by Authors to contributions from participants

> The author summarised that :-

>

> ❖ .fall back mechanism in case fraud is detected is an exceptional situation

> ❖ Difference between elections and consensus (the latter needs justifications)

> ❖ Electronic way to choose co-chairs, just like it’s been done this time

> ❖ Voters register is taken a number of months from the mailing list

> <>Chairs Decision

> AbdulKarim, PDP co-chair called all authors to come back. He requested the community to understand these 2 proposals and inform the working group as to what they think about these policies within the next 24 hours.

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

> <>Board prerogatives on the PDP

> Proposal URL : https://afrinic.net/policy/proposals/2020-gen-004-d2 <https://afrinic.net/policy/proposals/2020-gen-004-d2>

> Presentation URL : https://2020.internetsummit.africa/components/com_afmeeting/speakers/3283/1600275852_tmpphpdUF13h.pdf <https://2020.internetsummit.africa/components/com_afmeeting/speakers/3283/1600275852_tmpphpdUF13h.pdf>

> Impact Assessment URL : https://afrinic.net/policy/proposals/2020-gen-004-d1#impact <https://afrinic.net/policy/proposals/2020-gen-004-d1#impact>

>

> <>Introduction by Author(s): Jordi Palet Martinez

> ❖ Board is about members and oversight of the community PDP process

> ❖ There was recently an appeal that failed because the terms of reference that the board had not brought to the PDP had a discrimination regarding it to be taken in consideration as part of the appeal itself.

> ❖ If the board wants to adopt a policy that amends somehow the PDP, they should submit it at the next meeting for the community to approve it. Otherwise, it will be invalid since that point.

> ❖ That is basically trying to comply with with ICANN ICP-2, the mandate of all of the registries, including AFRINIC, to oversight the community consensus basis process of the PDP.

>

> <>Staff Impact Assessment

> Madhvi Gokool, AFRINIC Policy Liaison presented the impact assessment of this policy proposal. She mentioned that :-

> ❖ no impact on the system and operation

> ❖ According to the AFRINIC archives, In the absence of the terms of reference, one was drafted and shared with the community. They had implemented and set up the appeal committee in terms of reference. At the time the impact assessment was published, there was no other policy proposal that was under discussion or reached consensus about the terms of reference about the committee.

>

> The author, Jordi Palet then clarified that :-

>

> ❖ No need to have a ToR . Other registries do not have these.

> ❖ Self contained

> ❖ Anything that modifies the PDP must be done by following the PDP

>

>

> <>An overview of reactions from Participants:

>

> Section 3.6.1 is not satisfactory. We should be discussing a finished proposal

> The ToR may not necessarily be a violation of the PDP

> <>Response by Authors to contributions from participants

> The author summarised that :-

>

>

> ❖ .For the case of appeals , the ToR is not needed

> ❖ This proposal cannot be held until we have processes to solve the problem

> ❖ Terms of Reference are being used as an example and were not done according to the PDP

> <>Chairs Decision

> While no consensus was announced on Day 1, the co-chairs mentioned the following on Day 2 , when they were announcing their decisions on all policies.

>

> This proposal aims at clarifying how the board and the PDWG works. However, there were a few oppositions to this proposal except for a specific section.

>

> a. It seems like a piecemeal approach to dealing with issues.

> b. Opposition to the section below

>

> “As an exception of the preceding paragraph, in the absence of elections processes for aspects related to the PDP (co-chairs, appeal committee), those aspects will be still handled by the board in consultation with the community. However, this is also a temporary measure and also specific draft policy proposals should be introduced for that”. The authors agreed to remove the above section hence

>

> Chairs Decision: Consensus provided the above section is removed

>

>

>

>

>

>

>

>

>

>

> <>Policy Compliance Dashboard

> Proposal URL : https://www.afrinic.net/policy/proposals/2020-gen-001-d1 <https://www.afrinic.net/policy/proposals/2020-gen-001-d1>

> Presentation URL : https://2020.internetsummit.africa/components/com_afmeeting/speakers/3283/1600275872_tmpphpQxpay0.pdf <https://2020.internetsummit.africa/components/com_afmeeting/speakers/3283/1600275872_tmpphpQxpay0.pdf>

> Impact Assessment URL : https://afrinic.net/policy/proposals/2020-gen-001-d1#impact <https://afrinic.net/policy/proposals/2020-gen-001-d1#impact>

>

> <>Introduction by Author(s):Jordi Palet Martinez

>

> The author, Jordi P. Martinez introduced the policy proposal mentioning that the policy can be read by the PDWG on the AFRINIC website. He mentioned that :-

> ❖ AFRINIC RSA mandates members to comply with the AFRINIC policies which are developed via the PDP.

> ❖ In some situations, this is well defined but it happens that not all the members are following changes to existing policies on the mailing list. While members can be alerted by staff, the process is manual.

> ❖ In order to save money and facilitate the work of the staff, the policy compliance dashboard will verify periodically and automatically, every policy that needs to be complied with by members. The dashboard will be a help to the members

> ❖ When the dashboard detects something that doesn't match the policies, it will notify the members.

> ❖ Manual notification costs staff and money.

> ❖ While the implementation of the dashboard will cost and take some time, in the mid term, automation will save resources.

> ❖ In addition, The idea is also to take the opportunity to define what happens with resources, which is not actually defined in the PDP.

> ❖ Staff can still take exceptional measures .

>

> <>Staff Impact Assessment

> Madhvi Gokool, AFRINIC Policy Liaison presented the impact assessment of this policy proposal. She mentioned that :-

>

>

> ❖ Clarification requests to the authors were as follows :-

> - Author(s) to clarify if Section 5 means that :- Two months after the resources are published, AFRINIC will back up and then remove the domain objects linked to the resources from its whois database. Once the member re-establishes contact and resolves its non-compliance issues, the domain objects will be registered in the AFRINIC whois database.

> - Tracking of repeated and/or continued policy violations. - For consistency, policy authors may propose a threshold that mandates action and also clarify when and how the counters get reset.

> - AFRINIC shall publish resources under breach for a maximum of 3 months, where would the publishing ideally happen: as WHOIS remark/comments in the inet(6)num objects? Or Publicly accessible web page?

> - The policy proposal mentions a quarantine period of 2 years for ASN/IPv6. The quarantine period is currently 12 months and AFRINIC staff suggests that the quarantine period would best be left as an operational decision rather than have it specifically stated in the policy, as some factors may arise requiring urgent review of such a time frame.

> - The policy proposal has an impact on AFRINIC members.

>

> - The impact on systems and procedures are as follows :- Internal procedures are internally being used to help the members will be reviewed. staff will have to follow up with resource members in regard to persistent non-compliance.

> - Whois - There is no perceived impact on whois unless the author clarifies that we will update the whois objects in the remarks for the publication of non-compliance.

> - myAFRINIC, significant development is required for the dashboard. Myafrinicv2 is currently under development within AFRINIC at the moment.

> ❖ Timeline - If this proposal reaches consensus , six months after the deployment of AFRINIC version 2 is the most likely timeline of implementation. The reason being, the scope for the first deployment of myAFRINICv2 has already been finalised and is currently under implementation.

>

> The author, Jordi Palet then clarified that :-

>

> ❖ Compliance and non-compliance are clear as every CPM section identifies what is correct and what is not.

> ❖ The policy is a list of examples of possible violations. That is why we have an informative section in the policy

> ❖ Every CPM lack of compliance can be different and therefore it’s best left to staff to decide on the threshold.

> ❖ Publishing of the resources under breach should be a staff operational decision.

> ❖ Two years for quarantine gives sufficient time to make sure that they are clean and it’s a security mechanism.

> ❖ For resources that are no longer available, no need to quarantine for a year. It may be more important to get the resources than clean them.

> ❖ Staff can also take the decision in case a 16-bit ASN is needed.

> ❖ Implementation of the policy can be progressive as automation of every policy compliance is being requested here.

>

> <>Contributions from participants

> ❖ Some member do not follow policy

> ❖ it is important that we acknowledge compliance is really important

> ❖ Policy is important and AFRINIC members need to comply with policies and RSA

> ❖ an effort in the right direction to have some better Internet for Africa

> ❖ Acting responsibly by ensuring compliance . Criteria involved can be discussed in operations

> ❖ Community should not complain for staff.

> ❖ The proposal is more of an operational matter

> ❖ Will entail more resources to develop & maintain the platform

> ❖ Duty of AFRINIC staff to inform members about non-compliance.

> ❖ redundant because as far as I know it is the duty of AFRINIC staff to notify members of violations.

> ❖ Is there enough data to support the cost benefits? Need to be careful to not overwhelm the AFRINIC budget

> ❖ Members can dismiss automatic notifications

> ❖ Administrative function

> <>Response by Authors to contributions from participants

> The author summarised that :-

>

>

> 1. Staff can partially undertake manual part of the work

> 2. No scarcity of ASNs and IPv6 is not a problem

> 3. PDP is about efficient use of resources

> 4. Cost of implementation is towards keeping resources and better than cost of going to the Courts to recover the resources.

>

> <>Chairs Decision

> No Consensus - The proposal needs additional discussion and therefore returns to the discussion stage on the mailing list.

>

> <>PDP co-chair election Results

> The chairperson of the election committee for this year, Mrs Guylaine Layra gave a brief overview of the election process that was carried out for the election of the PDP co-chair.

> The process was announced .during August 2020. That provides a virtual election for all of the open seats this year. In terms of the steps followed for the PDP co-chair and the election, we did a registration period and proposed the voters register. Subsequently the elections started for the PDP and NRO on 14 September 2020. That started on September 14 and closes today , 16 September at 12:0O UTC.

> The ECOM thanks all those participated and that they have done their best to ensure that the election is fair for everyone.

>

>

> Mark Elkins, Chair of the Nomination Committee for 2020 mentioned that a few minutes ago, a private zoom meeting was held with the following persons present :-

> Eddy Kayihura, AFRINIC CEO, Mark Elkins, Guylaine Layra, Ashok Radhakissoon, Cedrick Mbeyet, David Njuki and Kishna Dhondee.

> Observers were Paul Wilson, Lucky Masilela and Jean-Robert Hountomey.

>

> NRO-NC/ASO-AC election result - Saul Stein won with 59 votes. Janvier came second with 34 votes. Saul Stein is the elected representative of AFRINIC to the NRO-NC/ASO-AC

> Policy Development Working Group chair - Abdulkarim Oloyede is elected.

>

>

>

> <>

> <>DAY 2

> Date : 17 sep 2020

> The session was opened by Moses Serugo, PDP co-chair at 09h15 UTC. He covered the agenda (5 policies) that will be discussed and reminded that the interventions in the queue will be First Come First Served and requested that they are limited to 1 minute

>

> <>Agenda

>

> 1) Abuse Contact Policy Update AFPUB-2018-GEN-001-DRAFT06

> (2) RPKI ROAs for Unallocated and Unassigned AFRINIC Address Space AFPUB-2019-GEN-006-DRAFT02

> (3) IPv4 Inter-RIR Resource Transfers (Comprehensive Scope) AFPUB-2019-IPv4-002-DRAFT04

> (4) AFRINIC Number Resources Transfer Policy AFPUB-2019-GEN-002-DRAFT02 - Gregoire Olaotan Ehoumi, Mukhangu Noah Maina, Komi Elitcha, Adeola A. P. Aina, and

> (5)Resource Transfer Policy AFPUB-2019-V4-003-DRAFT02- Anthony Ikechukwu Uba

> (6) Open Mic

>

> <>1) Abuse Contact Policy Update AFPUB-2018-GEN-001-DRAFT06

> Proposal URL: https://afrinic.net/policy/proposals/2018-gen-001-d6 <https://afrinic.net/policy/proposals/2018-gen-001-d6>

> Presentation URL: https://2020.internetsummit.africa/components/com_afmeeting/speakers/3283/1600367426_tmpphpmdWy3J.pdf <https://2020.internetsummit.africa/components/com_afmeeting/speakers/3283/1600367426_tmpphpmdWy3J.pdf>

> URL of staff impact assessment - https://afrinic.net/policy/proposals/2018-gen-001-d6#impact <https://afrinic.net/policy/proposals/2018-gen-001-d6#impact>

>

>

> <>Introduction by Author(s):Jordi Palet Martinez

>

> ❖ Mnt-irt object in the whois database for abuse reporting and a minimum fraction of members use it. Impact analysis has numbers for this.

> ❖ The policy makes mandatory object for abuse reporting. Rename mnt-irt to abuse -c and requests AFRINIC to validate it every six months.

> ❖ If validation fails , after 15 days, AFRINIC shall receive a notification so they can escalate to other contacts of the organisation .

> ❖ The 6 month and 15 days validation periods - AFRINIC can update according to operational experience and report it back to AFRINIC community.

> ❖ AFRINIC shall decide when the policy can be implemented , taking into consideration time and resources .

> ❖ The first validation may not be concluded in 6 months it does not matter and , but the main goal is to ensure that the database is as accurate as possible

> ❖ An equivalent proposal has been implemented in APNIC region, is under implementation in LACNIC region and under discussion in the RIPE region.

>

> <>Staff Impact Assessment

> Madhvi Gokool, AFRINIC Policy Liaison presented the impact assessment of this policy proposal. She mentioned that :-

>

> ❖ Impact assessment is determined collectively by a group of staff who go through the policy proposal and identify ambiguous text, clarifications from authors before determining the impact on the systems.

> ❖ If coding is required , staff will also try and determine the amount of time implementation shall take and if the time exceeds the timelines mentioned in the CPM, staff will inform the authors . We also note that at times, authors are flexible and allow for phased implementation.

> ❖ In regard to the abuse contact policy proposal , members will be impacted. IA is documented on the website next to the policy proposal .

> ❖ Clarification regarding the policy does not impact the Legacy resources.

> ❖ Implementation of the policy will require AFRINIC to update its procedures and improvement to accuracy and currency of registry data are expected.

> ❖ Myafrinic and whois will be impacted as abuse-c will have to be enforced on the objects

> ❖ Members will be provided with a tool to implement the abuse-c and to validate the mailbox.

> ❖ A table summarising the number of objects covered by mnt-irt was shown and only 28 members out of 1857 resource members adopted the mnt-irt (currently abuse-c) at the moment.

> ❖ The policy can be implemented within 6 months from Last Call and an input from the MS team is that compliance for members shall take

>

> The author has clarified that :-

> ❖ the proposal is silent on whether the abuse contact shall apply to Legacy Holders.

> ❖ Criteria adopted for staff is good for them

> ❖ Staff shall accommodate their resources to implement the policy.

>

>

> <>Contributions from participants

> ❖ AFRINIC has not launched a campaign/webinar to encourage its members to adopt the mnt-irt.

> ❖ Abuse-c as person object and used as an attribute -- for orgs ? or on inetnums etc

> ❖ This should be mandatory and it should have been done a long time ago. It is needed for a safe Internet operation in the region.

> ❖ Those running networks need to act responsibly , be reachable and noone can respond for them

> ❖ Those running networks are supposed to be the service of your end users and means that many things(contacts) are publicly known and verifiable.

> ❖ RIRs have no ability and the proposal does not offer a specific and regulated description of the term abuse

> ❖ Afrinic is not entitled to force members to report abuses since Afrinic doesn't hold the ability to identify what is considered an abuse

> ❖ No accountability mechanisms to make it work

>

>

> <>Response by Authors to contributions from participants

> ❖ Definition of an abuse - anything against your network that you did not authorise is not an abuse

> ❖ Policy ensures that every member has an abuse mailbox.

> ❖ Cost of abuse is taken by AFRINIC at the moment as it receives all the abuse reports

> ❖ AFRINIC resources are being filtered more and more

> ❖ The policy is working in other RIRs

> ❖ Abuse are cross-borders and responsibility to make proper the usage of resources is up to the registry. Misuse of resources and allowing customers to misuse the resources in other regions is against the contract

>

> <>Chairs Decision

> Moses Serugo , PDP co-chair, mentioned that they will get back on this so as to take more time to process all the information.

> No Consensus -The proposal needs additional discussion and therefore returns to the discussion stage on the mailing list.

>

>

>

>

> <>(2) RPKI ROAs for Unallocated and Unassigned AFRINIC Address Space AFPUB-2019-GEN-006-DRAFT02

> Proposal URL: https://afrinic.net/policy/proposals/2019-gen-006-d2 <https://afrinic.net/policy/proposals/2019-gen-006-d2>

> Presentation URL: https://2020.internetsummit.africa/components/com_afmeeting/speakers/3283/1600367442_tmpphpB5D3dx.pdf <https://2020.internetsummit.africa/components/com_afmeeting/speakers/3283/1600367442_tmpphpB5D3dx.pdf>

> URL of staff impact assessment : https://afrinic.net/policy/proposals/2018-gen-001-d6#impact <https://afrinic.net/policy/proposals/2018-gen-001-d6#impact>

>

>

> <>Introduction by Author(s):

> The author introduced the policy proposal and raised the following elements :-

> a) Reason for conflicts and questions is that people don’t understand

> b) RPKI is an opt-in service

> c) Objectiove of AS0 is to ensue that bad people are not announcing available resources of AFRINIC

> d) Secure network if you wish

> e) This is not for the space that belongs already to a resource member

> f) A member who does not want to use part of its resources at the moment can still create and AS0

> g) Based on implementation report of APNIC, this proposal is telling AFRINIC that if it wants to implement a separate TAL, this becomes an opt-in service and provides separate measurements

> h) Authors are unable to update their proposal if the co-chairs do not declare consensus and state what is wrong.

>

> <>Staff Impact Assessment

> Madhvi Gokool, AFRINIC Policy Liaison presented the impact assessment of this policy proposal. She mentioned that :-

>

> ❖ 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.

> ❖ New prefixes received from IANA/PTI would immediately have AS0 ROA's.

> ❖ Any prefixes returned by or reclaimed from members will also have AS0 ROAs

> ❖ 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.

> ❖ 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.

> ❖ A clarification as to what will be the validity period of these AS0 ROAs? 10 years? was put forward to the author.

> ❖ The prefix sanity checker of AfRINIC verifies that the unallocated space of AFRINIC is not being routed on the internet and that it is able to delegate clean resources to its members. If the policy proposal reaches consensus, it will reinforce the checks.

> ❖ Impact will be on systems, registry functions and AFRINIC will ensure that AS0 ROAs will be created for an resources that come into the AFRINIC inventory from IANA/PTI and also reclaimed and returned resources

> ❖ Tests were done and it takes about 5 minutes for AS0s to be revoked before the resources can be issued

> ❖ Policy can be implemented within 6 months from Last Call .

>

> The author has clarified that :-

> ❖ Validity period of ROAs can be at staff’s discretion.

>

> <>Contributions from participants

> ❖ Support the proposal provided confirmation is received that the process can be trusted fully to prevent the unissued resources from being misused by AFRINIC staff

> ❖ Easy to be implemented

> ❖ Impact on resource holders is not just determined by their decision to opt-in and opt-out and dependent on the neighbours routing policy. Downsides on reclaimed space.Not clear that routing traffic towards bogons are a significant challenge. Bogons are already filtered on some networks. Be careful of not introducing any downsides.

> ❖ In terms of monitoring unauthorised announcements of unallocated space, this will be more complicated . Monitoring has to be done from a specific vantage point that did not use origin validation in order to see the unauthorised announcements . 5 min time alluded to is only true when publishing and revoking new objects. Several other factors are involved

>

> <>Response by Authors to contributions from participants

> ❖ Implementation shall be done carefully and staff Impact assessment also covered that

> ❖ No negative impact on members

> ❖ If AFRINIC wants to reclaim space from a member who has not paid, the AS0 will cover the space and this is good for the member

> ❖ 5 mins is the time for the registry and for 99.99% of the time, a few days are needed to announce them. If this is the case, benefits are higher. Get resources and wait for one day to route them

> <>Chairs Decision

> Moses - PDP co-chair mentioned that decision will be announced at the end of the day .

> No Consensus - The proposal needs additional discussion and therefore returns to the discussion stage on the mailing list.

>

> <>(3) IPv4 Inter-RIR Resource Transfers (Comprehensive Scope) AFPUB-2019-IPv4-002-DRAFT04

> Proposal URL: https://afrinic.net/policy/proposals/2019-ipv4-002-d4 <https://afrinic.net/policy/proposals/2019-ipv4-002-d4>

> Presentation URL: https://2020.internetsummit.africa/components/com_afmeeting/speakers/3283/1600367459_tmpphp8vEqdC.pdf <https://2020.internetsummit.africa/components/com_afmeeting/speakers/3283/1600367459_tmpphp8vEqdC.pdf>

> URL of staff impact assessment : https://afrinic.net/policy/proposals/2019-ipv4-002-d4#impact <https://afrinic.net/policy/proposals/2019-ipv4-002-d4#impact>

>

>

> Author Jordi Palet Martinez presented on his policy proposal as follows :-

>

> ● AFRINIC is the only region in the world that cannot receive resources from other regions. Key problem is that those that need some IPv4 to deploy IPv6(for new members) and AFRINIC has run out of IPv4 resources . Hence new members can get complete disconnection from the rest of the Internet. Regions that have advanced in deploying IPv6 have less need for IPv4 . They are therefore able to provide more IPv4 resources.

> ● ARIN region is giving more resources to other regions as they have a bigger chunk of IPv4 addresses and to some degree have advanced their IPv6 deployment.

> ● It is therefore important that the policy is reciprocal with other regions.

> ● The statistics from NRO(30/06/2020) for transfers was then shown in the slides . Millions of IPv4 addresses were given by ARIN as compared to few thousands of IPv4 transfers from the other RIRs.

> ● The author then proceeded to compare his proposal with the other 2 proposals. Suspension has been incorporated in this proposal based on community requests in previous discussions. Can be used in case most IPv4 resources of AFRINIC are being sold.

> ● ARIN policies state that transfers from other regions can only happen if they are reciprocal.

> ● Staff mentioned ASN transfers in the past in the Experience Reports and therefore ASN transfers have been included in the proposal.

>

>

>

> <>Staff Impact Assessment

>

> ❖ Policy proposal allows intra and inter-RIR transfer of IPv4 and ASNs

> ❖ Incoming legacy resources in intra/inter RIR transfers to AFRINIC will lose their legacy status.

> ❖ Proposal excludes M&A and author confirmed that this proposal is silent in this regard. There is another proposal for M&A but that proposal was not updated. Guidelines for M&A will be followed in the meantime.

> ❖ Recipients of transfers in AFRINIC region will have to undergo the assessments and approval against the same policies and procedures as if the request were being satisfied from the AFRINIC pool

> ❖ Staff will be monitoring resources being transferred and report to Board. In case the board suspends the transfer policy, how shall AFRINIC implement the Board’s decision - go through the PPM? According to the author, Proposal is silent on this and author stated that he expects the Board to follow the bylaws and PDP once the decision to suspend is taken . he expects that either Board will send a policy proposal or ask the community -- strictly following PDP and bylaws.

> ❖ AFRINIC is requesting 5.7.4 to be updated to remove staff discretion and a section depicting the transfer of ASN to be included. Author mentioned that the proposal is silent , but that AFRINIC will assess the ASN transfer based on the ASN policies.

> ❖ Impact on internal systems, systems and procedures ,tool to manage 5.7.6 section of proposal

> ❖ Around 12 months to implement policy should it reach consensus

>

> <>An overview of reactions from Participants:

>

> ❖ Problem statement is not correct.

> ❖ Can the author provide some data in regard to the problem statement?

> ❖ Fallback plan of Board intervening may create a panic and what shall be the duration to implement the fallback ?

> ❖ AFRINIC is the only RIR where plenty of IPv4 addresses are available. Once the resources have left AFRINIC region, it is unsure what type of mechanism is in place to reclaim the resources

> ❖ Not support this policy as it allow transfers of AFRINIC resources . Okay if legacy resources are transferred.

> ❖ Virtues of own policy to be covered by authors and to avoid comparison with other policy proposals

> ❖ Analysis of Methodology as how the intent to display reciprocity is required

>

>

> <>Response by Authors to contributions from participants

> ❖ Reciprocity questions about policy text can be requested from ARIN

> ❖ Merging of proposals was not agreed upon by other authors

> ❖ LACNIC Analysis impact is public.

> ❖ According to author, ARIN policy manual - transfer and share reciprocal policies. If a policy says that resources from AFRINIC to other regions will not be legacy, ARIN will not like it

>

> <>Chairs Decision

> Co-chairs concluded the session saying that they will confer and announce their decision after the other proposals have been discussed.

>

> No Consensus - The proposal needs additional discussion and therefore returns to the discussion stage on the mailing list.

>

> <>

> <>(4) AFRINIC Number Resources Transfer Policy AFPUB-2019-GEN-002-DRAFT02

> Authors : Gregoire Olaotan Ehoumi, Mukhangu Noah Maina, Komi Elitcha, Adeola A. P. Aina

> Proposal URL: https://afrinic.net/policy/proposals/2019-gen-002-d2 <https://afrinic.net/policy/proposals/2019-gen-002-d2>

> Presentation URL: https://2020.internetsummit.africa/components/com_afmeeting/speakers/920/1600367610_tmpphpTUMyQJ.pdf <https://2020.internetsummit.africa/components/com_afmeeting/speakers/920/1600367610_tmpphpTUMyQJ.pdf>

> Impact Assessment URL : https://afrinic.net/policy/proposals/2019-gen-002-d2#impact <https://afrinic.net/policy/proposals/2019-gen-002-d2#impact>

>

>

> <>Introduction by Author(s): Gregoire Ehoumi

> ❖ Gregoire Ehoumi presented the policy proposal. With the expected runout of IPv4 addresses in the AFRINIC service region, entities will need IPv4 resources to support their IPv6 deployments.

> ❖ AFRINIC has a limited amount of IPv4 resources(~7 /8s) and there will therefore be a need for IPv4 addresses to flow into the AFRINIC service region without depleting the AFRINIC pool by transferring IPv4 addresses out of the region.

> ❖ Proposal has defined a set of rules to allow transfers of IPv4 and ASN

> ❖ Resources are segregated in different categories and the proposal defines the transfer rules per category.

> ❖ Legacy resources and resources transferred IN from other regions will be allowed to be transferred out of the AFRINIC service region.

> ❖ Legacy and non-legacy from other RIRs can be transferred into AFRINIC

> ❖ Legacy resources and resources transferred IN from other regions will be allowed to be transferred out of the AFRINIC service region.

> ❖ Resources can be transferred within AFRINIC service region

> ❖ Reserved resources as defined in the proposal cannot be transferred

> ❖ Up to the community to decide what is good and definition of compatible/reciprocal.

> <>Staff Impact Assessment

> Madhvi Gokool, AFRINIC Policy Liaison presented the impact assessment of this policy proposal. She mentioned that :-

> ❖ Impact assessment is on AFRINIC website

> ❖ ASN's shall be transferrable both inter and intra-region

> ❖ Legacy IPv4 space in the AFRINIC region can be transferred out. Transferred IPv4 space from other regions into AFRINIC can also be transferred out.

> ❖ Number resources are non-transferable and are not assignable to any other organisation unless AFRINIC has expressly and in writing approved a request for transfer. AFRINIC's approval is usually documented electronically in tickets.

> ❖ IPv4 addresses and ASNs can be transferred only if the transfer requests are evaluated against and in accordance with this policy.

> ❖ AFRINIC does not recognise transfers outside of approved transfer policies and requires organisations holding such resources to return them to the appropriate registries. Meaning that any transfers that happened outside any approved AFRINIC policies are not valid and the recipient organisations will be required to return the space to AFRINIC or the RIRs

> ❖ Policy will require some resource categoriastion

> ❖ Legacy resources transferred to AFRINIC will entail the loss of legacy status.

>

>

> <>An overview of reactions from Participants

>

> ❖ Proposal is a progressive extension of the intra-RIR transfer policy

> ❖ Policy will not encourage business growth

> ❖ If not compatible with ARIN, AFRINIC will not receive resources from ARIN which has the largest IP supplier in world

>

> <>Response by Authors to contributions from participants

> The author(s) summarised that :-

>

>

> ❖ AFRINIC community needs to know what it would want to do

> ❖ Proposal wants resources to come in and go out with caution

> ❖ Staff to get response from other RIRs and if there is a need for changes, they will adjust

> Madhvi Gokool replied to a query from the co-chair that this proposal is not compatible with the ARIN policies and that AFRINIC shall reach out to the other RIRs to seek compatibility of all 3 policies under discussion with their inter-RIR transfer policies.

> <>

>

> <>Chairs Decision

> Co-chairs concluded the session saying that they will confer and announce their decision after the other proposals have been discussed.

>

> No Consensus - The proposal needs additional discussion and therefore returns to the discussion stage on the mailing list.

>

> <>5) Resource Transfer Policy AFPUB-2019-V4-003-DRAFT02

> Proposal URL : https://afrinic.net/policy/proposals/2019-v4-003-d2 <https://afrinic.net/policy/proposals/2019-v4-003-d2>

> Presentation URL : https://2020.internetsummit.africa/components/com_afmeeting/speakers/4955/1600367656_tmpphpOCUw4p.pdf <https://2020.internetsummit.africa/components/com_afmeeting/speakers/4955/1600367656_tmpphpOCUw4p.pdf>

> Impact Assessment URL : https://afrinic.net/policy/proposals/2019-v4-003-d2#impact <https://afrinic.net/policy/proposals/2019-v4-003-d2#impact>

>

> <>Introduction by Authors - Taiwo Oyewande & Anthony Ubah

> ❖ AFRINIC has an intra-RIR transfer policy but does not have an inter-RIR policy

> ❖ IPv4 resources are scarce and the needs for these resources are increasing at the moment

> ❖ CPM does not discuss how these transfers take place

> ❖ Resource holder initiates a transfer if the resources are not in dispute, resources are registered in RIR registry and it has an agreement with the receiving entity

> ❖ No upper limit - free flow of resources between regions

> ❖ Transfer to AFRINIC needs to be evaluated with AFRINIC based on need before a transfer is initiated

> ❖ Transfer to another region must follow the policy of the receiving region

> ❖ Legacy resources will not be considered as legacy after the transfer

> ❖ NRO stats @30 June 2020 was shown.

>

> <>Staff Impact Assessment

> Madhvi Gokool, AFRINIC Policy Liaison presented the impact assessment of this policy proposal. She mentioned that :-

>

> ❖ In the case of transfers within the region, i.e intra-RIR transfer , Certain conditions have to be met

> ❖ In the case of transfers from AFRINIC to another RIR (inter-RIR transfer), It is not clear as to why the source entity shall comply with the policies of the receiving RIR when it operates in the service region of the source RIR.

> ❖ In the case of transfers from another RIR to AFRINIC (inter-RIR transfer), Since AFRINIC has no relationship with the source of a transfer that exists outside its service region, it will not accept any communication from the source organisation(resource holder).

>

> Clarifications were requested from the authors on the following :-

>

> 1. 5.7.3.1 - The source must be the current rights holder of the IPv4 address resources registered with any RIR and shall be in compliance with the policies of the receiving RIR?

> ○ This statement is not clear as source entities exist in and subject to the policies of either AFRINIC (intra) or another RIR (inter), which are the source RIRs. The source entity has no relationship with the receiving RIR. Can the authors clarify as to what they exactly mean here?

> 2. 5.7.5.1 speaks of using a standard template. Clarification is needed on this standard template - Is it a globally accepted standard template across all regions?

> 3. The proposal lacks a guideline on disputed resources - Can the authors clarify how AFRINIC shall handle any resources involved in transfers that are in dispute?

>

> Some Perceived Implementation challenges were also raised

>

> 1. "5.7.3.2 Source entities are eligible to receive further IPv4 allocations or assignments from AFRINIC as long as it complies with current policy". is bound to lead to abuse . Resources can be transferred and the source entity immediately requests for resources from AFRINIC based on needs.

> 2. 5.7.4.2 practically conflicting with 5.7.4.1.

> 3. ASN transfer is mentioned only in the summary of the problem but all text in the policy clauses refers to IPv4 only, this is confusing and will lead to misinterpretation. It is important to have ASN inclusion clearly stated in the policy text

>

> Impact will be on several systems and in case of consensus, at least 12 months will be required

>

> The author, then clarified that :-

>

>

> ❖ Source and receiving entity would sit and align the agreement with AFRINIC and align with the policies of the receiving RIR because of reciprocity. Resources can only be transferred between RIRs if there is reciprocity.

>

> ❖ Policy text contains the dispute clause (Note from AFRINIC - proposal https://afrinic.net/policy/proposals/2019-v4-003-d2#proposal <https://afrinic.net/policy/proposals/2019-v4-003-d2#proposal> does not have a dispute clause)

> ❖ 5.7.5.1 - Author referred to his slides “ If both parties agree, the transferring party will send a request to the RIR with which the resources are registered”

> Note from AFRINIC - https://afrinic.net/policy/proposals/2019-v4-003-d2#proposal <https://afrinic.net/policy/proposals/2019-v4-003-d2#proposal> does not have this clause as written

>

> <>An overview of reactions from Participants:

>

>

> ❖ Authors quickly move away from problem statement. Proposal states that establishes an efficient business-friendly mechanism to allow transfers of resources - not a problem for us to be solved.

> ❖ Other RIRs need to be queried for reciprocity of each of the policy - focus should not only on ARIN.

> ❖ Need for the policy has to be clearly established . if there is demand, show that demand

> ❖ Futile to be comparing what APNIC will get with what AFRINIC will get (needs differ)

> ❖ Every company runs a business to use numbers to serve its customers , operators are performing well and they have their needs)

> ❖ This is the only policy that gives unlimited resources and is exceptional for pricing investment in the region

> ❖ Policy opens up room for abuse

> ❖ Section 3.4 , subsection 3, “the intention is to promote responsible management of Internet resources about the African region. As well as the responsible development and operation of Internet infrastructure in this region. “

> ❖ Resources were received so that they can contribute to the growth of internet in the region

> ❖ Authors of the other 2 proposals should come together with these authors and work out 1 proposal

> ❖ The RIRs to be contacted as to whether all three policies(intra-RIR) are compatible with their respective policies.

>

> Madhvi, AFRINIC staff, confirmed :-

> ● that she will be reaching out to all the RIRs on the 3 policies & summarised .Impact assessments of each policy will also be updated.

> ● Section 5.7.3.1 of was checked on the version 2 of the Resource Transfer Policy on the AFRINIC website and differs from what the authors mentioned. Recommend that authors clarify with AFRINIC by email.

>

> .

> <>

> <>Chairs Decision

>

>

> <>Open Mic

> Open mic will run for 10 mins and then continue after the cochairs have announced their decisions :-

>

> 1. Abdulkarim(PDP co-chair) thanked community for his election

> 2. Clear misunderstanding of proposals for many in the community - cochairs had started online webinars and these webinars will be started so that the proposals are discussed and no consensus will be determined in these webinars.

> 3. Modalities of bringing webinars will be discussed.participation within the community is required

> 4. Where some proposals can have couple of lines that are problematic, the community needs to discuss how to solve these problems , instead of opposing the whole policy

> 5. Conflicts in the CPM to be resolved

> 6. To resolve problem of inter-rir, if all 3 proposals do not reach consensus - Recommendation from a participant regarding reciprocity of the 3 inter-RIR policy proposals and to work a single one by mid-october. Co-chairs to facilitate the discussion on the list by end of October. Ask for a new online PDP as latest by December to only resolve the inter-RIR problem . If no consensus is reached, the Board may propose a policy and bring it to the next PPM in accordance with the Bylaws.

> 7. Openness has been promoted for quite some time - new people are welcome but when they start saying they oppose. Awkward. Pattern was observed enough to mention publicly -- consistent opposition of certain policies . PDP requires individual participation so if some member is trying to influence the PDP, complicit .

> 8. IP addresses and businesses cannot be separated as they are required for economic growth

>

> Co-chairs then announced their decisions regarding all policies & documented these in an email to the rpd list .

> https://lists.afrinic.net/pipermail/rpd/2020/011372.html <https://lists.afrinic.net/pipermail/rpd/2020/011372.html>

>

> Session was closed by the co-chairs.

>

>

> Thanks

> Co-Chair PDWG

>

>

>

> Website <http://www.unilorin.edu.ng/>, Weekly Bulletin <http://www.unilorin.edu.ng/index.php/bulletin> UGPortal <http://uilugportal.unilorin.edu.ng/> PGPortal <https://uilpgportal.unilorin.edu.ng/>

>

> <AF32 -PPM Minutes -Final.pdf>_______________________________________________

> RPD mailing list

> RPD at afrinic.net

> https://lists.afrinic.net/mailman/listinfo/rpd


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20201012/2666f71c/attachment-0001.html>


More information about the RPD mailing list