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

[rpd] Decisions and summary on policy proposals discussed during the online Policy meeting (AFRINIC 32)

ABDULKARIM OLOYEDE oloyede.aa at unilorin.edu.ng
Mon Sep 21 00:04:28 UTC 2020


Dear PDWG Members,

Please find below a summary for each of the proposal discussed during the
just concluded online policy meeting of AFRINIC 32

1. Simple PDP Update

This policy defines consensus. It also proposes that a policy discussed at
the PPM does not need to come back for another PPM for the Co-chairs to
arrive at a decision. This can help in streamlining the work during the PPM
and encourages people to use the mailing list.

There were lots of irrelevant objections on the mailing list such as
someone registering many emails. We believe that this does not matter
because rough consensus is not about numbers but quality objections.

However, there is strong opposition to this policy based on the following:

a. Oppose the policy because of the way the consensus is
reached. This proposal proposes that the consensus be reached through a
balance of the mailing list/forum and not at the PPM. This endangers fair
consensus and hijacks the policymaking process. Based on experience, it is
during the PPM that most community members focus on policies.

b. Issues around how the chairs should drop proposals.

c. Trust in the mailing list: Some strongly believe that
anonymous contribution should be allowed while some believes it should not.

d. Issues around having more than 1 PPM per year and
Online PPM because of volunteer burnout. We are all volunteers and it’s a
night job for us. More PPMs mean more time to volunteer and more chances
for burnouts

e. Some members of the Community thinks only burning or
polarizing issues should be brought to the PPM.

Chairs Decision: No Consensus





2. PDP Working Group

This proposal aims at allowing most of the decisions including chair
elections to be determined via consensus. This can be reasonable when the
community has the same goal. However, there were a number of objections to
it. These are:

a. Entrusting the WG to make their decisions by consensus
and the appointment of their co-chairs by consensus do not make sense and
is only utopic.

b. People are not policy proposals, and thus choosing by
consensus is splitting hairs with the election process we already have.
Save the consensus for the proposals, and the election for people.

c. Consensus may even take months, and this can’t fly
when we want to put people in the vacant roles.

d. Co-chairs should not have a hand in the consensus, but
only sit back and let the community decide for themselves. Additionally,
the consensus process is not feasible with a deadline.

e. Focus on polishing the current electoral process
instead of complicating other untested forms of “election”.

f. The current status quo’s election should be the only
option in choosing for the roles, and not through less transparent means.

g. Board would be interfering too much on issues that
deal with PDP

Chairs Decision: No Consensus



3. Chairs Election Process

This proposal aims at introducing an online voting system for the Co-Chairs
election. The following are the opposition to this proposal.

a. This policy reduces participation. Equal
representation is violated because the board has unprecedented power.

b. There is also not enough information on the logistics
of the vote (e-voting).

c. There is a contradiction on when the term ends during
the meeting. “The term ends during the first PPM corresponding to the end
of the term for which they were appointed” is not clear enough, and “A term
may begin or end no sooner than the first day of the PPM and no later than
the last day of the PPM as determined by mutual agreement of the current
Chair and the new Chair” contradicts each other.

d. Gender restriction on 3.3.1.3 , some community members
argue it is impractical and maybe even unfair if we force both chairs to
have different genders.

e. Issues around which voter's register should be adopted

Chairs Decision: No Consensus



4. Board Prerogatives

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



5. Policy Compliance Dashboard

The policy proposal seeks to provide a framework or a policy compliance
dashboard be developed by AFRINIC and incorporated in myAFRINIC (and future
member’s communication platforms). It will allow a periodic review of the
policy compliance status of each member. It will also enable members to
receive automated notifications for any issue. Staff will receive repeated
warnings of lack of compliance or severe violations enshrined in the CPM.
However, there are several oppositions to this proposal, such as:

a. This policy seems to be redundant of the status quo as
violations are already checked and processed by the human staff.

b. There is already an existing system of guidelines on
keeping track of the violations of members.

c. The policy is not binding and does not enforce members
actually to follow the rules and not violate policies.

d. Ignorance could be a convenient excuse for violations
because one could claim that they never got notified about their violations.

e. There is no comprehensive system on how the board
should take proper actions once members violate policies, nor does it give
guidelines based on the severity of the violations.

f. This policy takes away resources that could be used
for more beneficial pursuits to AFRINIC for something existing in the
system.

g. It an administrative process, and this should be left
to staff

Chairs Decision: NO rough Consensus



6. Abuse Contact Update

The proposal makes it mandatory for AFRINIC to include in each resource
registration, a contact where network abuse from users of those resources
will be reported. The proposal whois DB attribute (abuse-c) to be used to
publish abuse public contact information. There’s also a process to ensure
that the recipient must receive abuse report and that contacts are
validated by AFRINIC regularly. However, there some opposition to the
proposal there are:

a. Staff analysis on how it affects legacy holder not
conclusive (not sure why this should affect legacy holders)

b. The proposal doesn’t state what will be the
consequences of one member fails to comply. Why are we creating the abuse
contact when there is no consequence for not providing the abuse contact

c. Abuse contact email and issues with GDPR concerning
the whois database

d. No proper definition of the term Abuse

e. To force members to reply to their abuse email is not
in the scope of AFRINIC.

Chairs Decision: No rough consensus



7. RPKI ROAs for Unallocated and Unassigned AFRINIC Address Space

The proposal instructs AFRINIC to create ROAs for all unallocated and
unassigned address space under its control. This will enable networks
performing RPKI-based BGP Origin Validation to easily reject all the bogon
announcements covering resources managed by AFRINIC. However, there are
many oppositions such as:

a. Allowing resource holders to create AS0/ ROA will lead
to an increase of even more invalid prefixes in the routing table.

b. Revocation time of AS0 state, and the time for new
allocation doesn’t match.

c. Other RIRs don’t have a similar the policy therefore,
it can not be effective

d. This will become a uniform policy if it is not globally
implemented, which causes additional stress.

e. Validity period: if members decide to implement it,
is it not better to recover the space if it is kept unused for too long?

f. How do we revoke the ROA? How long does it take to
revoke it (chain/ refreshing )?

g. What happens if AFRINIC accidentally issues a ROA for
an address in error?

h. It also might affect the neighbours and involves
monitoring of unallocated spaces.

i. Possibility of it being used against a member who is
yet to pay dues.

Suggestions were made to improve the policy such as

a) The automatic creation of AS0 ROAs should be limited to
space that has never been allocated by an RIR or part of a legacy
allocation.

b) AFRINIC should require the explicit consent of the
previous holder to issue AS0 ROAs in respect of re-claimed, returned, etc,
space.

c) Any ROAs issued under this policy should be issued and
published in a way that makes it operationally easy for a relying party to
ignore them (probably by issuing under a separate TA).

d) The proposal should include the clause “as used in
APNIC as to dues not paid on time.”

Chairs Decision: No consensus



8. IPv4 Inter-RIR Resource Transfers (Comprehensive Scope)

The proposal puts in place a mechanism to transfer IPv4 and (some ASN)
resources between AFRINIC and other RIRs and between AFRINIC
members/entities. Some conditions are attached to the source and recipient
based on need and disclosure made. The inter-RIR transfers will be
suspended if the number of outgoing IPv4 addresses exceeds the incoming
ones for six consecutive months. However, there are oppositions to it

a. ASN Transfer is not necessary

b. Issue of board inferring: no board in all of the five
RIRs have ever been involved in deciding a transfer or allocating IP
address. It is not the board's responsibility.

c. Suspending clause with no reinstalling clause. This
mainly makes the policy potentially invalid.

Chairs Decision: No consensus.



9. AFRINIC Number Resource Transfer

a. Not realistic for one-way inter RIR resource transfer
as it has to be reciprocal. One way would never happen as only global
resources can come in and go out

b. It would be difficult for the recipient to follow the
rules of AFRINIC if they are not in the African region.

c. No need for ASN transfer. If one is moving regions and
doesn't have an ASN in the new region, it can request and receive from the
local RIRs

d. Additional attributes create none-operational
complexity in the whois database.

Chairs Decision: No consensus.



10. Resource Transfer Policy

This proposal aims to introduce Inter RIR transfer. However, it has the
following opposition

a. Issues with Legacy holder transfer is potentially
considered none-reciprocal by ARIN

b. Potential abuse of AFRINIC free pool without the time
limit of receiving an allocation from AFRINIC.

Chairs Decision: The proposal is the least contested of all the 3 competing
proposals. However because of the community’s desire and clear expression
for the need for an Inter RIR transfer, we, the Co-chairs, believe that in
the interest of the community we should focus on a proposal rather than
several similar ones. This desire was clearly expressed at the AFRINIC 31
meeting in Angola. Therefore, We suggest that the authors of this proposal
make the following amendments:

· 5.7.3.2 Source entities are not eligible to receive further IPv4
allocations or assignments from AFRINIC for 12 months period after the
transfer.

· 5.7.4.3. Transferred legacy resources will still be regarded as
legacy resources.

Chairs Decision: Provided that the above are amended, the decisions is
Rough Consensus is achieved



Based on the above, The updated version of the follow proposal which
achieved rough consensus would be posted on the PDWG website

*1. **Board Prerogatives *

*2. **Resource Transfer Policy*

Therefore, these two policies are now on last call.

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/>


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


More information about the RPD mailing list