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

[lucilla fornaro]

Hello everyone,

I find the summary very helpful and clear.
I am glad that the Co-Chairs understood the community concerns around the
need for an Inter RIR transfer policy. I agree with proceeding on the
Resource Transfer Policy and keep working on it as suggested during the
discussion.

For what concerns the Abuse Policy Contact, as I expected it did not reach
a rough consensus, and I am glad of it because right now it does not offer
a solution, on the contrary, it creates even more complications. I hope we
can start from here and work together to find a better solution.

regards,
Lucilla



Il giorno lun 21 set 2020 alle ore 09:06 ABDULKARIM OLOYEDE <
oloyede.aa at unilorin.edu.ng> ha scritto:


>

> 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/20200921/a8401033/attachment-0001.html>