<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <div class="moz-cite-prefix">On 25/09/2020 18:07, Anthony Ubah
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAHcb0ASq2Wtxpi3zJDo=V4D1SBT3Pov6Ps3zXDC7CDtdxqjMxQ@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="auto"><clip>
        <div dir="auto"><br>
        </div>
        <div dir="auto"><br>
        </div>
        <div dir="auto">With respect to my policy proposal on Number
          resource Transfer, a questions was asked about legacy
          resources. This is relatively trivial to the idea of the
          policy in general. This can be subject to a new Legacy policy
          in its own right. However this proposal was done with the
          grand intention of gaining reciprocity with the key donor of
          IPv4s which is ARIN. The issues raised shouldn't halt this
          policy. Jordi made some valid recommendations which can be
          considered.</div>
      </div>
    </blockquote>
    <p>It is definitively not. Letting them remain considered legacy is
      a *major issue* that only benefit a few actors who gain
      financially with it, plus incentives the continuation of a
      historic internet issue that must end and bring all resources
      under common rules that any other organization is bounded to on
      the top of helping ending possible abuses from those who are still
      not subject to the rules of any RIR.<br>
      <br>
      On the top of that this has never been mentioned in *any* message
      for months of discussion and has never been raised as an issue.
      Suddenly someone goes to the PPM, mentions that, it becomes a
      mandatory change in order for the proposal to reach rough
      consensus and the rest of the people who discussed it in details
      have no chance oppose and properly put up their points ? It
      doesn't make sense !<br>
      If the logic is that then people that have financial means to
      attend a future event may be in advantage of others that
      participate only in the RPD list if willing to change something
      substantial in the proposal at the very last minute. <br>
    </p>
    <p>FYI the Inter-RIR transfer policy in LACNIC states any legacy
      resources transferred loses its status and it is still reciprocal
      to any other RIR that have an Inter-RIR policy.</p>
    <p>Fernando<br>
    </p>
    <blockquote type="cite"
cite="mid:CAHcb0ASq2Wtxpi3zJDo=V4D1SBT3Pov6Ps3zXDC7CDtdxqjMxQ@mail.gmail.com">
      <div dir="auto">
        <div dir="auto"><br>
        </div>
        <div dir="auto">Lastly a comments was made about our problem
          statement. I think it is clearly stated. The use of the term
          "Business" has raised a few eyebrows and instigated ominous
          thoughts. I urge everyone to read again with an open mind.
          Internet is a global enterprise, and Number resources,
          internet, IT infrastructure and business are an integral part
          of our world today. It is impractical to separate the use of
          number resources from business.</div>
        <div dir="auto"><br>
        </div>
        <div dir="auto"><br>
        </div>
        <div dir="auto">These are my 10Cents.</div>
        <div dir="auto"><br>
        </div>
        <div dir="auto"><br>
        </div>
        <div dir="auto">Kind regards, </div>
        <div dir="auto"><br>
        </div>
        <div dir="auto">Anthony Ubah</div>
        <br>
        <br>
        <div class="gmail_quote" dir="auto">
          <div dir="ltr" class="gmail_attr">On Fri, Sep 25, 2020, 5:03
            PM <<a href="mailto:rpd-request@afrinic.net"
              target="_blank" rel="noreferrer" moz-do-not-send="true">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" rel="noreferrer
              noreferrer" target="_blank" moz-do-not-send="true">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 noreferrer" target="_blank"
              moz-do-not-send="true">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"
              rel="noreferrer noreferrer" target="_blank"
              moz-do-not-send="true">rpd-request@afrinic.net</a><br>
            <br>
            You can reach the person managing the list at<br>
                    <a href="mailto:rpd-owner@afrinic.net"
              rel="noreferrer noreferrer" target="_blank"
              moz-do-not-send="true">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) (Blaise
            Fyama)<br>
            <br>
            <br>
----------------------------------------------------------------------<br>
            <br>
            Message: 1<br>
            Date: Fri, 25 Sep 2020 18:02:20 +0200<br>
            From: Blaise Fyama <<a href="mailto:bfyama@gmail.com"
              rel="noreferrer noreferrer" target="_blank"
              moz-do-not-send="true">bfyama@gmail.com</a>><br>
            To: ABDULKARIM OLOYEDE <<a
              href="mailto:oloyede.aa@unilorin.edu.ng" rel="noreferrer
              noreferrer" target="_blank" moz-do-not-send="true">oloyede.aa@unilorin.edu.ng</a>><br>
            Cc: rpd List <<a href="mailto:rpd@afrinic.net"
              rel="noreferrer noreferrer" target="_blank"
              moz-do-not-send="true">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>
                    <CAPehF5dv=<a
              href="mailto:5yc_bHR6OEJwtr7V28qNhTk-tK-sf1C_eAxWGLmVQ@mail.gmail.com"
              rel="noreferrer noreferrer" target="_blank"
              moz-do-not-send="true">5yc_bHR6OEJwtr7V28qNhTk-tK-sf1C_eAxWGLmVQ@mail.gmail.com</a>><br>
            Content-Type: text/plain; charset="utf-8"<br>
            <br>
            Chers co-chairs,<br>
            Sans ?tre virulents ? votre ?gard j'ai juste deux remarques
            ? faire d'abord:<br>
            <br>
            1. L'aspect multilinguiste devrait ?tre respect? dans la
            prise en compte de<br>
            vos d?cisions, et je n'en ai pas le sentiment, ce qui
            implique que pour<br>
            accompagner solidement vos conclusions et vos inf?rences, un
            tableau<br>
            transparent regroupant sommairement les r?actions de chaque
            membre<br>
            politique apr?s politique serait le bienvenu car il
            permettrait ? tout le<br>
            monde d'avoir une vue claire et optimale de vos d?cisions.<br>
            ?tant un acad?mique de carri?re, je constate que sur 10
            politiques<br>
            seulement 2 sont adopt?es ou en voie de l'?tre ce qui laisse
            sous-entendre<br>
            que les 8 autres politiques, qui pourtant r?sultent de
            grands efforts,<br>
            donnent un sentiment d'?chec ? leurs auteurs. Pourriez-vous
            ?couter un peu<br>
            plus leurs auteurs?<br>
            Je reconnais par exemple que Jordi a longuement interagis et
            ?chang? avec<br>
            plusieurs d'entre nous sa proposition m?riterait d'?voluer.<br>
            <br>
            2. Lorsqu'une remarque techniquement et valablement soutenue
            vous est<br>
            adress?e pourriez-vous aussi donner des explications<br>
            proportionnellement longues? Vos r?ponses courtes et
            laconiques laissent un<br>
            sentiment de manque de consid?ration de ce qui vous est
            adress? par les<br>
            membres. Sinon vous risquez d'inspirer ? leur tour les
            membres du PDWG que<br>
            nous sommes ? concevoir des politiques qui limitent votre
            propre r?le.<br>
            <br>
            La note positive dans tout ?a est que les 2 politiques ?
            savoir les "Les<br>
            pr?rogatives du conseil" et "Politique de transfert des
            ressources" au vu<br>
            des longues discussions pendant des mois ont quand m?me fait
            du chemin. Je<br>
            note seulement que nous devons rester alerte pour  "Les
            pr?rogatives du<br>
            conseil"  afin de ne pas affaiblir non plus le conseil qui
            devrait demeurer<br>
            un organe de prise des d?cisions, pour plus d'efficience et
            d'efficacit?<br>
            dans le fonctionnement de la communaut?.<br>
            J'en f?licite les auteurs, surtout Taiwo avec qui j'ai eu
            l'opportunit?<br>
            d'?changer lors de l'avant-dernier sommet en Angola.<br>
            <br>
            Pour finir chers co-chairs efforcez-vous d'?tre multilingues
            pour nous<br>
            ?crire en Fran?ais comme nous aussi on vous ?crit parfois en
            Anglais.<br>
            <br>
            Cordialement,<br>
            Blaise.<br>
            <br>
            <br>
            <br>
                                 Blaise FYAMA<br>
            Msc, PhD.<br>
            Professeur Associ?<br>
            Secr?taire G?n?ral Acad?mique Honoraire/UL<br>
            Doyen de la Facult? des Sciences Informatiques/UPL<br>
            Doyen a.i de la Facult? Polytechnique/UPL<br>
            Chef de D?partement G?nie Electrique/ESI-UNILU<br>
            Chef de Service Informatique/Polytech-UNILU<br>
            Consultant Informatique BIT/PAEJK<br>
            Membre de International Research Conference IRC/WASET<br>
            Tel: +243995579515<br>
            Num?ro O.N.I.CIV: 00460<br>
            <br>
            MSc, PhD.<br>
            <br>
            Associate Professor<br>
            <br>
            Honorary Academic Secretary General / UL<br>
            <br>
            Dean of the Faculty of Computer Science / UPL<br>
            <br>
            Dean a.i of the Polytechnic Faculty / UPL<br>
            <br>
            Head of Department of Electrical Engineering / ESI-UNILU<br>
            <br>
            IT Service Manager / Polytech-UNILU<br>
            <br>
            IT Consultant BIT / PAEJK<br>
            <br>
            Member of International Research Conference IRC/WASET<br>
            <br>
            Phone: +243995579515<br>
            <br>
            O.N.I.CIV number: 00460<br>
            <br>
            <br>
            Le lun. 21 sept. 2020 ? 02:06, ABDULKARIM OLOYEDE <<br>
            <a href="mailto:oloyede.aa@unilorin.edu.ng" rel="noreferrer
              noreferrer" target="_blank" moz-do-not-send="true">oloyede.aa@unilorin.edu.ng</a>>
            a ?crit :<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>
            > Co-Chair<br>
            > PDWG<br>
            ><br>
            > Website <<a href="http://www.unilorin.edu.ng"
              rel="noreferrer noreferrer noreferrer" target="_blank"
              moz-do-not-send="true">http://www.unilorin.edu.ng</a>>,
            Weekly Bulletin<br>
            > <<a
              href="http://www.unilorin.edu.ng/index.php/bulletin"
              rel="noreferrer noreferrer noreferrer" target="_blank"
              moz-do-not-send="true">http://www.unilorin.edu.ng/index.php/bulletin</a>>
            UGPortal<br>
            > <<a href="http://uilugportal.unilorin.edu.ng/"
              rel="noreferrer noreferrer noreferrer" target="_blank"
              moz-do-not-send="true">http://uilugportal.unilorin.edu.ng/</a>>
            PGPortal<br>
            > <<a href="https://uilpgportal.unilorin.edu.ng/"
              rel="noreferrer noreferrer noreferrer" target="_blank"
              moz-do-not-send="true">https://uilpgportal.unilorin.edu.ng/</a>><br>
            ><br>
            > _______________________________________________<br>
            > RPD mailing list<br>
            > <a href="mailto:RPD@afrinic.net" rel="noreferrer
              noreferrer" target="_blank" moz-do-not-send="true">RPD@afrinic.net</a><br>
            > <a
              href="https://lists.afrinic.net/mailman/listinfo/rpd"
              rel="noreferrer noreferrer noreferrer" target="_blank"
              moz-do-not-send="true">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/a8a5d980/attachment.html"
              rel="noreferrer noreferrer noreferrer" target="_blank"
              moz-do-not-send="true">https://lists.afrinic.net/pipermail/rpd/attachments/20200925/a8a5d980/attachment.html</a>><br>
            <br>
            ------------------------------<br>
            <br>
            Subject: Digest Footer<br>
            <br>
            _______________________________________________<br>
            RPD mailing list<br>
            <a href="mailto:RPD@afrinic.net" rel="noreferrer noreferrer"
              target="_blank" moz-do-not-send="true">RPD@afrinic.net</a><br>
            <a href="https://lists.afrinic.net/mailman/listinfo/rpd"
              rel="noreferrer noreferrer noreferrer" target="_blank"
              moz-do-not-send="true">https://lists.afrinic.net/mailman/listinfo/rpd</a><br>
            <br>
            <br>
            ------------------------------<br>
            <br>
            End of RPD Digest, Vol 168, Issue 213<br>
            *************************************<br>
          </blockquote>
        </div>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <pre class="moz-quote-pre" wrap="">_______________________________________________
RPD mailing list
<a class="moz-txt-link-abbreviated" href="mailto:RPD@afrinic.net">RPD@afrinic.net</a>
<a class="moz-txt-link-freetext" href="https://lists.afrinic.net/mailman/listinfo/rpd">https://lists.afrinic.net/mailman/listinfo/rpd</a>
</pre>
    </blockquote>
  </body>
</html>