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)

Arnaud AMELINA amelnaud at gmail.com
Tue Sep 22 06:26:59 UTC 2020


+1

Le mar. 22 sept. 2020 à 01:17, Fernando Frediani <fhfrediani at gmail.com> a
écrit :

> I fully agree with Gregoire comments.
>
> I want to highlight perhaps the most important part: "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. "
>
> I also I urge the co-chairs 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. Such unilateral decisions
> by the co-chair are very concerning and unprecedented.
>
> Fernando
> On 21/09/2020 13:30, Gregoire EHOUMI via RPD wrote:
>
> 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>
> <oloyede.aa at unilorin.edu.ng>
> Date: 2020-09-20 8:06 p.m. (GMT-05:00)
> To: rpd List <rpd at afrinic.net> <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 achiev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20200922/5833a835/attachment.html>


More information about the RPD mailing list