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

[Arnaud AMELINA]

+1 @Gregoire

Le lun. 21 sept. 2020 à 16:33, Gregoire EHOUMI via RPD <rpd at afrinic.net> a
écrit :


> Dear Co-chairs and WG

>

> During the AFRINIC-32 PPM which was held last week, the proceedings and

> decisions made by cochairs, raised many concerns. Below are some of them.

> The video of the meeting is publicly available.

>

>

>

> *Concern-1  objections management————*

> cochairs chose some objections raised and even not-raised, did not say why

> comments and explanations provided by authors and the participants on the

> raised and discussed issues were unsatisfactory.

>

> Few examples

>

> ⁃ Abuse contact proposal

>

> The valid and unresolved objections according to co-chairs decisions were:

> • Definition of abuse

> • GDPR compliance

> • Impact of legacy resources

>

>

> ⁃ RPKI ROAs for Unallocated and Unassigned AFRINIC Address Spaces

>

> The valid and unresolved objections according to cochairs were:

> • AS0 ROA validity

> • Certain fear in the community that this proposal may help staff reclaim

> resources if members failed to pay membership fees.

> • Lack of a certain mitigation provision APNIC  has in their policy

>

> -WG guidelines and procedures

>

> The valid and unresolved objections according to cochairs were:

>

> • the proposed appointment of cochairs  by consensus will create more

> problems for this community.

> • Cochairs should not have hands in consensus

> • also Board interference.

>

> ⁃ Inter-RIR transfer proposals

>

> On the 3 proposals being discussed

>

> Cochairs decided that :

> • one is far from reaching consensus as incompatible with ARIN as per

> staff.

> • The other 2 are closer

>

>

>

> *Concern-2 fairness in the proceeding ——————————————————*

> • When rendering their decisions and contrary to what was announced,

> Cochairs did not question all authors of transfer policy proposals showing

> bias

>

> • Staff’s demand to the WG  to allow them to request official

> compatibility analysis on each of the proposals from other RIRs was denied

>

> • Authors were not even given chance to respond to the point with ARIN

>

>

>

> *Concern-3 unilateral decisions by cochairs————————————————————*

> • cochairs decided that Afrinic service region need an inter-RIR transfer

> policy as matter as urgency  and can’t wait anymore

>

> • Cochairs decided that among the 3 proposals, the one which aims to

> establish an efficient and business-friendly mechanism to allow a number of

> resources to be transferred from/to other regions, should be pushed forward

>

> • Cochairs refused to consider the issues and the implementation

> challenges  raised by the staff impact assessment on proposal

>

> • Cochairs decided on which amendments should be made to the selected

> proposal  for it to move forward.

>

> 1- Add 12 months delay for a source to be eligible to receive allocation

> from AFRINIC

>

> 2- Remove clause for legacy status after transfer

>

> 3-Fix clarity on notifications to the other RIRs after the transfer

>

> It is obvious that 1) contradicts both problem statement and solution of

> the proposal preferred by cochairs.

>

> Cochairs appear to be deciding and injecting new issues not previously

> mentioned in working group. Not following due process of hearing authors

> and the hurry to decide for working group is unacceptable. The cochairs

> report must rather provide an open issues list of outstanding issues for

> working group to deliberate on. There had been no attempt by cochairs to

> gauge consensus throughout the meeting.

>

> In the view of all these violations of the PDP, I urge you to reconsider

> all decisions made during the last PPM and give chance to the WG to

> appropriately address the open issues and come to the best conclusions for

> the region.

>

> --

> Gregoire Ehoumi ( on behalf of the authors of WG guidelines and procedures

> and AFRINIC Number Ressources transfer proposals)

>

>

> -------- Original message --------

> From: ABDULKARIM OLOYEDE <oloyede.aa at unilorin.edu.ng>

> Date: 2020-09-20 8:06 p.m. (GMT-05:00)

> To: rpd List <rpd at afrinic.net>

> Subject: [rpd] Decisions and summary on policy proposals discussed during

> the online Policy meeting (AFRINIC 32)

>

>

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

>

> _______________________________________________

> 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/20200922/bb50af62/attachment-0001.html>