<div dir="auto">The manner in which we are going  about these policies and all that concerns the RIR reflects a picture of the progress we have made as an entity.<div dir="auto"><br></div><div dir="auto">It is obvious that ego and some sentiments have eaten deep that we can barely see reason to come to common grounds on issues which we all know will set a sound foundation for generations to come.</div><div dir="auto"><br></div><div dir="auto">After several summits it is sad we can not tell ourselves that this point the other person is making is reasonable, we have constantly revolved around issues that a sample set would have resolved long time ago.</div><div dir="auto"><br></div><div dir="auto">I will now ask are we really making progress?</div><div dir="auto"><br></div><div dir="auto">For those who come as newcomers every summit are they really learning something from those who have been on ground in the past years or decades?</div><div dir="auto"><br></div><div dir="auto">Forgive me if I have drifted from issues on table but this is how these banters have cobwebbed my mind.</div><div dir="auto"><br></div><div dir="auto">I wish we took things natural and saw points with the other man's point there by making amends. </div><div dir="auto"><br></div><div dir="auto">Msugh ne cir🤗</div><div dir="auto"><br></div><div dir="auto"><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Sep 25, 2020, 12:39 AM  <<a href="mailto:rpd-request@afrinic.net">rpd-request@afrinic.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Send RPD mailing list submissions to<br>
        <a href="mailto:rpd@afrinic.net" target="_blank" rel="noreferrer">rpd@afrinic.net</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
        <a href="https://lists.afrinic.net/mailman/listinfo/rpd" rel="noreferrer noreferrer" target="_blank">https://lists.afrinic.net/mailman/listinfo/rpd</a><br>
or, via email, send a message with subject or body 'help' to<br>
        <a href="mailto:rpd-request@afrinic.net" target="_blank" rel="noreferrer">rpd-request@afrinic.net</a><br>
<br>
You can reach the person managing the list at<br>
        <a href="mailto:rpd-owner@afrinic.net" target="_blank" rel="noreferrer">rpd-owner@afrinic.net</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of RPD digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
   1. Re: Decisions and summary on policy proposals discussed<br>
      during the online Policy meeting (AFRINIC 32) (lucilla fornaro)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Fri, 25 Sep 2020 08:38:38 +0900<br>
From: lucilla fornaro <<a href="mailto:lucillafornarosawamoto@gmail.com" target="_blank" rel="noreferrer">lucillafornarosawamoto@gmail.com</a>><br>
To: JORDI PALET MARTINEZ <<a href="mailto:jordi.palet@consulintel.es" target="_blank" rel="noreferrer">jordi.palet@consulintel.es</a>><br>
Cc: rpd List <<a href="mailto:rpd@afrinic.net" target="_blank" rel="noreferrer">rpd@afrinic.net</a>><br>
Subject: Re: [rpd] Decisions and summary on policy proposals discussed<br>
        during the online Policy meeting (AFRINIC 32)<br>
Message-ID:<br>
        <<a href="mailto:CAKJg62J_xdi9Y99qD0rr1MYMNJDAE15cbZR5otRX6CFW%2BPcktQ@mail.gmail.com" target="_blank" rel="noreferrer">CAKJg62J_xdi9Y99qD0rr1MYMNJDAE15cbZR5otRX6CFW+PcktQ@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Hello Jordi and everyone,<br>
<br>
I have to disagree with pretty much every point, in particular, for what<br>
concerns points 1 and 2.<br>
First of all, the use of words should be highly pondered. Coercion is a<br>
serious business and it is a tactic that violates the principles of<br>
AFRINIC. You seem to say that Co-chairs used coercion as a threat of<br>
penalty to induce authors to agree to avoid unpleasant outcomes. This is<br>
completely wrong!<br>
<br>
Chairs job is to address major objections and suggest changes which is part<br>
of their administrative work and Co-chairs did a very good job in that<br>
sense. Furthermore, it is not forbidden and they did it in good faith. I<br>
see no force and no coercion in any of their suggestions.<br>
<br>
regards,<br>
Lucilla<br>
<br>
<br>
<br>
Il giorno gio 24 set 2020 alle ore 01:06 JORDI PALET MARTINEZ via RPD <<br>
<a href="mailto:rpd@afrinic.net" target="_blank" rel="noreferrer">rpd@afrinic.net</a>> ha scritto:<br>
<br>
> HI AK, all,<br>
><br>
><br>
><br>
> I?ve confronted feelings myself. Somehow, I will like to support how you<br>
> tried to take decisions (pending on a concrete analysis for each proposal,<br>
> that I?ve not got the time to do yet) and the way you declared consensus,<br>
> so we can make some progress, especially for finally resolving the<br>
> Inter-RIR issue which I think it is extremely urgent for AFRINIC assuming<br>
> that it is implementable and functional, otherwise, it is just a waste of<br>
> time.<br>
><br>
><br>
><br>
> However, there are several points that are clearly violations of the PDP.<br>
> And I?m saying this even it is clearly against one of my own proposal which<br>
> reached consensus (based on your decision), but as community, we must be<br>
> clear and honest regardless of being against us as authors.<br>
><br>
><br>
><br>
> Let me try to explain every point, following the PDP in our CPM:<br>
><br>
>    1. Section 3.3. As it has been said earlier the chairs are there to<br>
>    perform administrative functions (manage the meeting, the list, determine<br>
>    consensus). There is no authorization in the PDP to allow you to ?force<br>
>    authors? to ?change this or that? if you want your proposal to reach<br>
>    consensus.<br>
>    2. I fully understand the goal and I applaud it, but then it must be<br>
>    given **the same opportunity** to all the proposals, otherwise you?re<br>
>    acting in a discriminatory way towards different proposals. At the end even<br>
>    in the extreme case, if all the proposal reach consensus, it is not really<br>
>    relevant because if authors agree or not to do changes that still don?t<br>
>    like to the community, they will fail in the last call. So, it is fine that<br>
>    you suggest to authors what do you believe are ?nits? to avoid failure in<br>
>    the last call, but not actually coercing them to apply specific changes. In<br>
>    the meeting, during the open mic, you were suggesting that the ?simple PDP<br>
>    update? can also reach consensus if I agree to some changes. I was not<br>
>    capturing your point until I saw the video a day after. Even in the video<br>
>    you can see that some audio/video is missing, and the actual audio that I<br>
>    was getting during the video was not good at that time. It is not a<br>
>    complain about that specific proposal, just an example. So, do you think<br>
>    that?s fair? If you really want to give the authors a chance during the<br>
>    last call, the way to do it is **before** the open mic, talking to<br>
>    them. In fact, as we discussed a few days ago, you didn?t have to declare<br>
>    consensus in the open mic, as Alain suggested, it can be done a couple of<br>
>    days after, so you?ve time to coordinate with the authors, they can already<br>
>    send a revised version, etc.<br>
>    3. This PDP (3.4.3) doesn?t allow changes for the last call or right<br>
>    before it. In other PDP of other RIRs there is an explicit ?editorial<br>
>    changes are allowed?. We don?t have that. Even if we have that, what is an<br>
>    editorial change? We have actually a problem with that in the last LACNIC<br>
>    meeting. For me an editorial change is only correcting grammar or mistakes,<br>
>    but not amending a full section. The practice that we followed in AFRINIC<br>
>    has been to accept this type of changes only (correct mistakes, remove<br>
>    superfluous text, clarify text) but not **change conditions in the<br>
>    policies**. Again, I applaud the goal, but is not right, and it is a<br>
>    clear matter for a valid appeal.<br>
><br>
><br>
><br>
> Note something else, that I?ve said many times, in all the RIRs. I see the<br>
> chairs as super-heroes. I?m happy to prepare and defend other 100<br>
> proposals, but not to be a chair, so my sincere admiration towards you.<br>
> However, that doesn?t imply that, as humans, you can make mistakes and<br>
> that?s also why the PDP provides (3.5.1) a conflict resolution that<br>
> includes raising the issues with you. Otherwise, anyone in the community is<br>
> able to appeal, not just for any specific proposal, but for the general<br>
> decisions taken in the meeting. So my suggestion to avoid that is that you<br>
> should reconsider your decisions and clarify what is a valid-objection and<br>
> what is not for each proposal.<br>
><br>
><br>
><br>
> In the worst case, if the community is not satisfied we can also follow<br>
> the recall process (3.5.3), but hopefully we don?t need to go for that and<br>
> repeat the full meeting, etc. It will also take time for the board to call<br>
> for the recall committee, etc. Let?s avoid it and that means that you react<br>
> to the different open questions, in general and for each proposal.<br>
><br>
><br>
><br>
> That said, providing solutions, for the most urgent policy that this<br>
> region needs, the Inter-RIR, we can resolve the issue, if it fails the last<br>
> call or there is an valid appeal, using the Varying the process (3.6) PDP<br>
> section. This still will mean we lost 2-3 months. The other alternative is<br>
> what I proposed the other day. Asking the board to call for a focussed<br>
> meeting in December, may be just for Inter-RIR, or may be 3-4 sessions of<br>
> 1-2 hours for sets of proposals, grouped in similar aspects.<br>
><br>
><br>
><br>
> I?m also still wainting your detailed responses, and also from the staff<br>
> (for some points) to my emails on the morning of 21/9/2020 regarding two of<br>
> my proposals. Please follow up ASAP.<br>
><br>
><br>
><br>
> I will be sending, still very busy, sorry about that, specific emails for<br>
> each of the other policy proposals.<br>
><br>
><br>
><br>
> Regards,<br>
><br>
> Jordi<br>
><br>
> @jordipalet<br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
> El 22/9/20 23:46, "ABDULKARIM OLOYEDE" <<a href="mailto:oloyede.aa@unilorin.edu.ng" target="_blank" rel="noreferrer">oloyede.aa@unilorin.edu.ng</a>><br>
> escribi?:<br>
><br>
><br>
><br>
> Dear Gregoire,<br>
><br>
> Thank you. Your concerns are noted. We would endure that we come up with<br>
> the best solution for the region based on openness, transparency and<br>
> fairness.  We have not broken any section of the CPM rather we upheld the<br>
> CPM. 3.2.3 of the CPM says<br>
> 3.2.3 Fairness<br>
><br>
> The policies are to ensure fair distribution of resources and facilitating<br>
> the operation of the Internet. Actions are taken within a reasonable<br>
> period of time.<br>
><br>
> 3.4.2 .... The Chair(s) determine(s) whether rough consensus has been<br>
> achieved during the Public Policy Meeting.<br>
><br>
><br>
><br>
> Co- Chair PDWG<br>
><br>
><br>
><br>
> On Mon, Sep 21, 2020 at 5:30 PM Gregoire EHOUMI <<a href="mailto:gregoire.ehoumi@yahoo.fr" target="_blank" rel="noreferrer">gregoire.ehoumi@yahoo.fr</a>><br>
> wrote:<br>
><br>
> Dear Co-chairs and WG<br>
><br>
><br>
> During the AFRINIC-32 PPM which was held last week, the proceedings and<br>
> decisions made by cochairs, raised many concerns. Below are some of them.<br>
> The video of the meeting is publicly available.<br>
><br>
><br>
><br>
> *Concern-1  objections management????*<br>
> cochairs chose some objections raised and even not-raised, did not say why<br>
> comments and explanations provided by authors and the participants on the<br>
> raised and discussed issues were unsatisfactory.<br>
><br>
> Few examples<br>
><br>
> ? Abuse contact proposal<br>
><br>
> The valid and unresolved objections according to co-chairs decisions were:<br>
> ? Definition of abuse<br>
> ? GDPR compliance<br>
> ? Impact of legacy resources<br>
><br>
><br>
> ? RPKI ROAs for Unallocated and Unassigned AFRINIC Address Spaces<br>
><br>
> The valid and unresolved objections according to cochairs were:<br>
> ? AS0 ROA validity<br>
> ? Certain fear in the community that this proposal may help staff reclaim<br>
> resources if members failed to pay membership fees.<br>
> ? Lack of a certain mitigation provision APNIC  has in their policy<br>
><br>
> -WG guidelines and procedures<br>
><br>
> The valid and unresolved objections according to cochairs were:<br>
><br>
> ? the proposed appointment of cochairs  by consensus will create more<br>
> problems for this community.<br>
> ? Cochairs should not have hands in consensus<br>
> ? also Board interference.<br>
><br>
> ? Inter-RIR transfer proposals<br>
><br>
> On the 3 proposals being discussed<br>
><br>
> Cochairs decided that :<br>
> ? one is far from reaching consensus as incompatible with ARIN as per<br>
> staff.<br>
> ? The other 2 are closer<br>
><br>
><br>
><br>
><br>
> *Concern-2 fairness in the proceeding ??????????????????*<br>
> ? When rendering their decisions and contrary to what was announced,<br>
> Cochairs did not question all authors of transfer policy proposals showing<br>
> bias<br>
><br>
> ? Staff?s demand to the WG  to allow them to request official<br>
> compatibility analysis on each of the proposals from other RIRs was denied<br>
><br>
> ? Authors were not even given chance to respond to the point with ARIN<br>
><br>
><br>
><br>
> *Concern-3 unilateral decisions by cochairs????????????????????*<br>
> ? cochairs decided that Afrinic service region need an inter-RIR transfer<br>
> policy as matter as urgency  and can?t wait anymore<br>
><br>
> ? Cochairs decided that among the 3 proposals, the one which aims to<br>
> establish an efficient and business-friendly mechanism to allow a number of<br>
> resources to be transferred from/to other regions, should be pushed forward<br>
><br>
> ? Cochairs refused to consider the issues and the implementation<br>
> challenges  raised by the staff impact assessment on proposal<br>
><br>
> ? Cochairs decided on which amendments should be made to the selected<br>
> proposal  for it to move forward.<br>
><br>
> 1- Add 12 months delay for a source to be eligible to receive allocation<br>
> from AFRINIC<br>
><br>
> 2- Remove clause for legacy status after transfer<br>
><br>
> 3-Fix clarity on notifications to the other RIRs after the transfer<br>
><br>
> It is obvious that 1) contradicts both problem statement and solution of<br>
> the proposal preferred by cochairs.<br>
><br>
> Cochairs appear to be deciding and injecting new issues not previously<br>
> mentioned in working group. Not following due process of hearing authors<br>
> and the hurry to decide for working group is unacceptable. The cochairs<br>
> report must rather provide an open issues list of outstanding issues for<br>
> working group to deliberate on. There had been no attempt by cochairs to<br>
> gauge consensus throughout the meeting.<br>
><br>
> In the view of all these violations of the PDP, I urge you to reconsider<br>
> all decisions made during the last PPM and give chance to the WG to<br>
> appropriately address the open issues and come to the best conclusions for<br>
> the region.<br>
><br>
> --<br>
> Gregoire Ehoumi ( on behalf of the authors of WG guidelines and procedures<br>
> and AFRINIC Number Ressources transfer proposals)<br>
><br>
><br>
><br>
><br>
><br>
> -------- Original message --------<br>
><br>
> From: ABDULKARIM OLOYEDE <<a href="mailto:oloyede.aa@unilorin.edu.ng" target="_blank" rel="noreferrer">oloyede.aa@unilorin.edu.ng</a>><br>
><br>
> Date: 2020-09-20 8:06 p.m. (GMT-05:00)<br>
><br>
> To: rpd List <<a href="mailto:rpd@afrinic.net" target="_blank" rel="noreferrer">rpd@afrinic.net</a>><br>
><br>
> Subject: [rpd] Decisions and summary on policy proposals discussed during<br>
> the online Policy meeting (AFRINIC 32)<br>
><br>
><br>
><br>
><br>
> Dear PDWG Members,<br>
><br>
>  Please find below a summary for each of the proposal discussed during the<br>
> just concluded online policy meeting of AFRINIC 32<br>
><br>
> 1.       Simple PDP Update<br>
><br>
> This policy defines consensus. It also proposes that a policy discussed at<br>
> the PPM does not need to come back for another PPM for the Co-chairs to<br>
> arrive at a decision. This can help in streamlining the work during the PPM<br>
> and encourages people to use the mailing list.<br>
><br>
> There were lots of irrelevant objections on the mailing list such as<br>
> someone registering many emails. We believe that this does not matter<br>
> because rough consensus is not about numbers but quality objections.<br>
><br>
> However, there is strong opposition to this policy based on the following:<br>
><br>
> a.                   Oppose the policy because of the way the consensus<br>
> is reached. This proposal proposes that the consensus be reached through a<br>
> balance of the mailing list/forum and not at the PPM. This endangers fair<br>
> consensus and hijacks the policymaking process. Based on experience, it is<br>
> during the PPM that most community members focus on policies.<br>
><br>
> b.                  Issues around how the chairs should drop proposals.<br>
><br>
> c.                   Trust in the mailing list: Some strongly believe<br>
> that anonymous contribution should be allowed while some believes it should<br>
> not.<br>
><br>
> d.                  Issues around having more than 1 PPM per year and<br>
> Online PPM because of volunteer burnout. We are all volunteers and it?s a<br>
> night job for us. More PPMs mean more time to volunteer and more chances<br>
> for burnouts<br>
><br>
> e.                  Some members of the Community thinks only burning or<br>
> polarizing issues should be brought to the PPM.<br>
><br>
> Chairs Decision:   No Consensus<br>
><br>
><br>
><br>
><br>
><br>
> 2.       PDP Working Group<br>
><br>
> This proposal aims at allowing most of the decisions including chair<br>
> elections to be determined via consensus.  This can be reasonable when the<br>
> community has the same goal. However, there were a number of objections to<br>
> it. These are:<br>
><br>
> a.                   Entrusting the WG to make their decisions by<br>
> consensus and the appointment of their co-chairs by consensus do not make<br>
> sense and is only utopic.<br>
><br>
> b.                  People are not policy proposals, and thus choosing by<br>
> consensus is splitting hairs with the election process we already have.<br>
> Save the consensus for the proposals, and the election for people.<br>
><br>
> c.                   Consensus may even take months, and this can?t fly<br>
> when we want to put people in the vacant roles.<br>
><br>
> d.                  Co-chairs should not have a hand in the consensus,<br>
> but only sit back and let the community decide for themselves.<br>
> Additionally, the consensus process is not feasible with a deadline.<br>
><br>
> e.                  Focus on polishing the current electoral process<br>
> instead of complicating other untested forms of ?election?.<br>
><br>
> f.                    The current status quo?s election should be the<br>
> only option in choosing for the roles, and not through less transparent<br>
> means.<br>
><br>
> g.                   Board would be interfering too much on issues that<br>
> deal with PDP<br>
><br>
> Chairs Decision:    No Consensus<br>
><br>
><br>
><br>
> 3.       Chairs Election Process<br>
><br>
> This proposal aims at introducing an online voting system for the<br>
> Co-Chairs election. The following are the opposition to this proposal.<br>
><br>
> a.                   This policy reduces participation. Equal<br>
> representation is violated because the board has unprecedented power.<br>
><br>
> b.                  There is also not enough information on the logistics<br>
> of the vote (e-voting).<br>
><br>
> c.                   There is a contradiction on when the term ends<br>
> during the meeting. ?The term ends during the first PPM corresponding to<br>
> the end of the term for which they were appointed? is not clear enough, and<br>
> ?A term may begin or end no sooner than the first day of the PPM and no<br>
> later than the last day of the PPM as determined by mutual agreement of the<br>
> current Chair and the new Chair? contradicts each other.<br>
><br>
> d.                  Gender restriction on 3.3.1.3 , some community<br>
> members argue it is impractical and maybe even unfair if we force both<br>
> chairs to have different genders.<br>
><br>
> e.                  Issues around which voter's register should be<br>
> adopted<br>
><br>
> Chairs Decision: No Consensus<br>
><br>
><br>
><br>
> 4.       Board Prerogatives<br>
><br>
> This proposal aims at clarifying how the board and the PDWG  works.<br>
> However, there were a few oppositions to this proposal except for a<br>
> specific section.<br>
><br>
> a.                   It seems like a piecemeal approach to dealing with<br>
> issues.<br>
><br>
> b.                  Opposition to the section below<br>
><br>
> *?As an exception of the preceding paragraph, in the absence of elections<br>
> processes for aspects related to the PDP (co-chairs, appeal committee),<br>
> those aspects will be still handled by the board in consultation with the<br>
> community. However, this is also a temporary measure and also specific<br>
> draft policy proposals should be introduced for that*?. The authors<br>
> agreed to remove the above section hence<br>
><br>
> Chairs Decision: Consensus provided the above section is removed<br>
><br>
><br>
><br>
> 5.       Policy Compliance Dashboard<br>
><br>
> The policy proposal seeks to provide a framework or a policy compliance<br>
> dashboard be developed by AFRINIC and incorporated in myAFRINIC (and future<br>
> member?s communication platforms).  It will allow a periodic review of the<br>
> policy compliance status of each member. It will also enable members to<br>
> receive automated notifications for any issue. Staff will receive repeated<br>
> warnings of lack of compliance or severe violations enshrined in the CPM.<br>
> However, there are several oppositions to this proposal, such as:<br>
><br>
> a.                   This policy seems to be redundant of the status quo<br>
> as violations are already checked and processed by the human staff.<br>
><br>
> b.                  There is already an existing system of guidelines on<br>
> keeping track of the violations of members.<br>
><br>
> c.                   The policy is not binding and does not enforce<br>
> members actually to follow the rules and not violate policies.<br>
><br>
> d.                  Ignorance could be a convenient excuse for violations<br>
> because one could claim that they never got notified about their violations.<br>
><br>
> e.                  There is no comprehensive system on how the board<br>
> should take proper actions once members violate policies, nor does it give<br>
> guidelines based on the severity of the violations.<br>
><br>
> f.                    This policy takes away resources that could be used<br>
> for more beneficial pursuits to AFRINIC for something existing in the<br>
> system.<br>
><br>
> g.                   It an administrative  process, and this should be<br>
> left to staff<br>
><br>
> Chairs Decision:  NO rough Consensus<br>
><br>
><br>
><br>
> 6.       Abuse Contact Update<br>
><br>
> The proposal makes it mandatory for AFRINIC to include in each resource<br>
> registration, a contact where network abuse from users of those resources<br>
> will be reported.  The proposal whois DB attribute (abuse-c) to be used to<br>
> publish abuse public contact information. There?s also a process to ensure<br>
> that the recipient must receive abuse report and that contacts are<br>
> validated by AFRINIC regularly. However, there some opposition to the<br>
> proposal there are:<br>
><br>
> a.                   Staff analysis on how it affects legacy holder not<br>
> conclusive  (not sure why this should affect legacy holders)<br>
><br>
> b.                  The proposal doesn?t state what will be the<br>
> consequences of one member fails to comply. Why are we creating the abuse<br>
> contact when there is no consequence for not providing the abuse contact<br>
><br>
> c.                   Abuse contact email and issues with GDPR concerning<br>
> the whois database<br>
><br>
> d.                  No proper definition of the term Abuse<br>
><br>
> e.                  To force members to reply to their abuse email is not<br>
> in the scope of AFRINIC.<br>
><br>
> Chairs Decision: No rough consensus<br>
><br>
><br>
><br>
> 7.       RPKI ROAs for Unallocated and Unassigned AFRINIC Address Space<br>
><br>
> The proposal instructs AFRINIC to create ROAs for all unallocated and<br>
> unassigned address space under its control. This will enable networks<br>
> performing RPKI-based BGP Origin Validation to easily reject all the bogon<br>
> announcements covering resources managed by AFRINIC. However, there are<br>
> many oppositions such as:<br>
><br>
> a.                   Allowing resource holders to create AS0/ ROA will<br>
> lead to an increase of even more invalid prefixes in the routing table.<br>
><br>
> b.                  Revocation time of AS0 state, and the time for new<br>
> allocation doesn?t match.<br>
><br>
> c.                   Other RIRs don?t have a similar the policy<br>
> therefore, it can not be effective<br>
><br>
> d.                  This will become a uniform policy if it is not<br>
> globally implemented, which causes additional stress.<br>
><br>
> e.                  Validity period:   if members decide to implement it,<br>
> is it not better to recover the space if it is kept unused for too long?<br>
><br>
> f.                    How do we revoke the ROA? How long does it take to<br>
> revoke it (chain/ refreshing )?<br>
><br>
> g.                   What happens if AFRINIC accidentally issues a ROA<br>
> for an address in error?<br>
><br>
> h.                  It also might affect the neighbours and involves<br>
> monitoring of unallocated spaces.<br>
><br>
> i.                     Possibility of it being used against a member who<br>
> is yet to pay dues.<br>
><br>
> Suggestions were made to improve the policy such as<br>
><br>
> a)                  The automatic creation of AS0 ROAs should be limited<br>
> to space that has never been allocated by an RIR or part of a legacy<br>
> allocation.<br>
><br>
> b)                  AFRINIC should require the explicit consent of the<br>
> previous holder to issue AS0 ROAs in respect of re-claimed, returned, etc,<br>
> space.<br>
><br>
> c)                   Any ROAs issued under this policy should be issued<br>
> and published in a way that makes it operationally easy for a relying party<br>
> to ignore them (probably by issuing under a separate TA).<br>
><br>
> d)                  The proposal should include the clause ?as used in<br>
> APNIC as to dues not paid on time.?<br>
><br>
> Chairs Decision: No consensus<br>
><br>
><br>
><br>
> 8.       IPv4 Inter-RIR Resource Transfers (Comprehensive Scope)<br>
><br>
> The proposal puts in place a mechanism to transfer IPv4 and (some ASN)<br>
> resources between AFRINIC and other RIRs and between AFRINIC<br>
> members/entities. Some conditions are attached to the source and recipient<br>
> based on need and disclosure made. The inter-RIR transfers will be<br>
> suspended if the number of outgoing IPv4 addresses exceeds the incoming<br>
> ones for six consecutive months. However, there are oppositions to it<br>
><br>
> a.                   ASN Transfer is not necessary<br>
><br>
> b.                  Issue of board inferring: no board in all of the five<br>
> RIRs have ever been involved in deciding a transfer or allocating IP<br>
> address. It is not the board's responsibility.<br>
><br>
> c.                   Suspending clause with no reinstalling clause. This<br>
> mainly makes the policy potentially invalid.<br>
><br>
> Chairs Decision: No consensus.<br>
><br>
><br>
><br>
> 9.       AFRINIC Number Resource Transfer<br>
><br>
> a.                   Not realistic for one-way inter RIR resource<br>
> transfer as it has to be reciprocal. One way would never happen as only<br>
> global resources can come in and go out<br>
><br>
> b.                  It would be difficult for the recipient to follow the<br>
> rules of AFRINIC if they are not in the African region.<br>
><br>
> c.                   No need for ASN transfer. If one is moving regions<br>
> and doesn't have an ASN in the new region, it can request and receive from<br>
> the local RIRs<br>
><br>
> d.                  Additional attributes create none-operational<br>
> complexity in the whois database.<br>
><br>
> Chairs Decision: No consensus.<br>
><br>
><br>
><br>
> 10.   Resource Transfer Policy<br>
><br>
> This proposal aims to introduce Inter RIR transfer. However, it has the<br>
> following opposition<br>
><br>
> a.                   Issues with Legacy holder transfer is potentially<br>
> considered none-reciprocal by ARIN<br>
><br>
> b.                  Potential abuse of AFRINIC free pool without the time<br>
> limit of receiving an allocation from AFRINIC.<br>
><br>
> Chairs Decision: The proposal is the least contested of all the 3<br>
> competing proposals. However because of the community?s desire and clear<br>
> expression for the  need for an Inter RIR transfer, we, the Co-chairs,<br>
> believe that in the interest of the community we should focus on a proposal<br>
> rather than several similar ones. This desire was clearly expressed at the<br>
> AFRINIC 31 meeting in Angola. Therefore, We suggest that the authors of<br>
> this proposal make the following amendments:<br>
><br>
> ?         5.7.3.2  Source entities are not eligible to receive further<br>
> IPv4 allocations or assignments from AFRINIC for 12 months period after the<br>
> transfer.<br>
><br>
> ?         5.7.4.3. Transferred legacy resources will still be regarded as<br>
> legacy resources.<br>
><br>
> Chairs Decision: Provided that the above are amended, the decisions is<br>
> Rough Consensus is achieved<br>
><br>
><br>
><br>
> Based on the above, The updated version of the follow proposal which<br>
> achieved rough consensus would be posted on the PDWG website<br>
><br>
> *1.*       *Board Prerogatives *<br>
><br>
> *2.*       *Resource Transfer Policy*<br>
><br>
> Therefore, these two policies are now on last call.<br>
><br>
><br>
> Co-Chair<br>
><br>
> PDWG<br>
><br>
><br>
><br>
> Website <<a href="http://www.unilorin.edu.ng" rel="noreferrer noreferrer" target="_blank">http://www.unilorin.edu.ng</a>>, Weekly Bulletin<br>
> <<a href="http://www.unilorin.edu.ng/index.php/bulletin" rel="noreferrer noreferrer" target="_blank">http://www.unilorin.edu.ng/index.php/bulletin</a>> UGPortal<br>
> <<a href="http://uilugportal.unilorin.edu.ng/" rel="noreferrer noreferrer" target="_blank">http://uilugportal.unilorin.edu.ng/</a>> PGPortal<br>
> <<a href="https://uilpgportal.unilorin.edu.ng/" rel="noreferrer noreferrer" target="_blank">https://uilpgportal.unilorin.edu.ng/</a>><br>
><br>
><br>
><br>
><br>
><br>
> Website <<a href="http://www.unilorin.edu.ng" rel="noreferrer noreferrer" target="_blank">http://www.unilorin.edu.ng</a>>, Weekly Bulletin<br>
> <<a href="http://www.unilorin.edu.ng/index.php/bulletin" rel="noreferrer noreferrer" target="_blank">http://www.unilorin.edu.ng/index.php/bulletin</a>> UGPortal<br>
> <<a href="http://uilugportal.unilorin.edu.ng/" rel="noreferrer noreferrer" target="_blank">http://uilugportal.unilorin.edu.ng/</a>> PGPortal<br>
> <<a href="https://uilpgportal.unilorin.edu.ng/" rel="noreferrer noreferrer" target="_blank">https://uilpgportal.unilorin.edu.ng/</a>><br>
><br>
><br>
><br>
> _______________________________________________ RPD mailing list<br>
> <a href="mailto:RPD@afrinic.net" target="_blank" rel="noreferrer">RPD@afrinic.net</a> <a href="https://lists.afrinic.net/mailman/listinfo/rpd" rel="noreferrer noreferrer" target="_blank">https://lists.afrinic.net/mailman/listinfo/rpd</a><br>
><br>
> **********************************************<br>
> IPv4 is over<br>
> Are you ready for the new Internet ?<br>
> <a href="http://www.theipv6company.com" rel="noreferrer noreferrer" target="_blank">http://www.theipv6company.com</a><br>
> The IPv6 Company<br>
><br>
> This electronic message contains information which may be privileged or<br>
> confidential. The information is intended to be for the exclusive use of<br>
> the individual(s) named above and further non-explicilty authorized<br>
> disclosure, copying, distribution or use of the contents of this<br>
> information, even if partially, including attached files, is strictly<br>
> prohibited and will be considered a criminal offense. If you are not the<br>
> intended recipient be aware that any disclosure, copying, distribution or<br>
> use of the contents of this information, even if partially, including<br>
> attached files, is strictly prohibited, will be considered a criminal<br>
> offense, so you must reply to the original sender to inform about this<br>
> communication and delete it.<br>
><br>
> _______________________________________________<br>
> RPD mailing list<br>
> <a href="mailto:RPD@afrinic.net" target="_blank" rel="noreferrer">RPD@afrinic.net</a><br>
> <a href="https://lists.afrinic.net/mailman/listinfo/rpd" rel="noreferrer noreferrer" target="_blank">https://lists.afrinic.net/mailman/listinfo/rpd</a><br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="https://lists.afrinic.net/pipermail/rpd/attachments/20200925/9bd5d2a3/attachment.html" rel="noreferrer noreferrer" target="_blank">https://lists.afrinic.net/pipermail/rpd/attachments/20200925/9bd5d2a3/attachment.html</a>><br>
<br>
------------------------------<br>
<br>
Subject: Digest Footer<br>
<br>
_______________________________________________<br>
RPD mailing list<br>
<a href="mailto:RPD@afrinic.net" target="_blank" rel="noreferrer">RPD@afrinic.net</a><br>
<a href="https://lists.afrinic.net/mailman/listinfo/rpd" rel="noreferrer noreferrer" target="_blank">https://lists.afrinic.net/mailman/listinfo/rpd</a><br>
<br>
<br>
------------------------------<br>
<br>
End of RPD Digest, Vol 168, Issue 204<br>
*************************************<br>
</blockquote></div>