<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>There is no routing data being injected. This is not BGP !<br>
      Please stop spreading misinformation.</p>
    <p>Once again can anyone that fears ASN0 for Unnalocated Space
      answer my questions about what is the fear of using it, what
      problems can it bring and all the points raised regarding the
      objectives of the RIR which all completely match the use of RPKI
      as a tool to protect its members and Internet in the region ?</p>
    <p>Thanks<br>
      Fernando<br>
    </p>
    <div class="moz-cite-prefix">On 30/01/2021 17:05, Wijdane Goubi
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAMcGv+JpffhOyycO3WQo7uAchSigcUwZrAcFZUfhf0v95T091w@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="auto">
        <div dir="auto">Dear community,</div>
        <div dir="auto"><br>
        </div>
        <div dir="auto">I agree on what was mentioned before as it goes
          that whoever uses RPKI can invalidate the unallocated spaces
          with a code and that there is no need to do a completely whole
          policy for it as other regions such as RIPE did not accept to
          apply such approach.</div>
        <div dir="auto">  </div>
        <div dir="auto">As for the ideology point, I totally agree
          because an ideology is a body of ideas, and those who agree
          with the main idea of something take an ideological stand to
          support it therefore whatever policy that is about to be
          applied should take into consideration the ideological part of
          it which makes some facts up to discussion over again. </div>
        <div dir="auto"><br>
        </div>
        <div dir="auto">Indeed, requiring the injection of data routing
          data into the only available routing certification program
          makes it a violation to the RIR’s purpose which makes it again
          an ideological difference.</div>
        <div dir="auto"><br>
        </div>
        <div dir="auto"><br>
        </div>
        <div dir="auto">Regards,</div>
        <div dir="auto">Wijdane</div>
      </div>
      <br>
      <div class="gmail_quote">
        <div dir="ltr" class="gmail_attr">On Fri, Jan 29, 2021, 00:11
          Anthony Ubah <<a href="mailto:ubah.tonyiyke@gmail.com"
            moz-do-not-send="true">ubah.tonyiyke@gmail.com</a>>
          wrote:<br>
        </div>
        <blockquote class="gmail_quote" style="margin:0 0 0
          .8ex;border-left:1px #ccc solid;padding-left:1ex">
          <div dir="auto"><br>
            <div dir="auto">Dear Jord!</div>
            <div dir="auto"><br>
            </div>
            <div dir="auto">I think you may be misunderstanding me when
              I say that they are invalid. It is also quite unfortunate
              to hear you say that ideological differences are an
              “invalid objection”.</div>
            <div dir="auto"><br>
            </div>
            <div dir="auto">The providers, who use RPKI, can invalidate
              (or AS0 as you put it) those unallocated spaces themselves
              with minimal code, so there is no need to have a
              particular policy for it. That is the exact reason why
              such an approach is not accepted in RIPE in the first
              place. I to also note that there is really no need to
              converting BOP (best operating practices) into unnecessary
              policies, as is slowly becominga norm. I am sure that you
              have best interests at heart, but this is not what
              policies are supposed to be.</div>
            <div dir="auto"><br>
            </div>
            <div dir="auto">Contrarywise, requiring RIRs to inject
              routing data into the only available routing certification
              program is a violation of the RIR’s purpose. The RIRs are
              not built for regulating routing – this is the ideological
              difference that I am talking about – (and something I
              believe you have been told regularly in the RIPE region),
              including the most recent appeal you have filed against
              the contact abuse policy in RIPE.</div>
            <div dir="auto"><br>
            </div>
            <div dir="auto">If you ask anyone here to compensate for
              hijacking, the chances are there is an inordinately high
              probability that most of them misunderstand an RIR’s
              fundamental functions. If you want to use RPKI to prevent
              hijacking, you can do it today; moreover, if you wish to
              use RPKI with AS0 functionality, you can also do it today
              with just a few additional lines of code.</div>
            <div dir="auto"><br>
            </div>
            <div dir="auto">Therefore, your argument that the provider
              can’t protect themselves from hijacking because they lack
              AS0 functionality in an RIR-provided space is very
              misleading. On the other hand, the current status quo
              allows the provider to choose whether or not they want
              such functionality instead of forcing it on them. The AS0
              for unallocated space is already an optional function that
              anyone can enable independently, and enabling AS0 is a
              BOF  rather than a policy issue.</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"><br>
            </div>
            <div dir="auto">Anthony</div>
            <div class="gmail_quote" dir="auto">
              <blockquote class="gmail_quote" style="margin:0 0 0
                .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
              </blockquote>
              <blockquote class="gmail_quote" style="margin:0 0 0
                .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
                <br>
                ------------------------------<br>
                <br>
                Date: Thu, 28 Jan 2021 10:06:13 +0100<br>
                From: JORDI PALET MARTINEZ <<a
                  href="mailto:jordi.palet@consulintel.es"
                  rel="noreferrer noreferrer" target="_blank"
                  moz-do-not-send="true">jordi.palet@consulintel.es</a>><br>
                To: <<a href="mailto:rpd@afrinic.net" rel="noreferrer
                  noreferrer" target="_blank" moz-do-not-send="true">rpd@afrinic.net</a>><br>
                Subject: Re: [rpd] REPORT ON Appeal against the
                non-consensus<br>
                        determination on proposal
                AFPUB-2019-GEN-006-DRAFT02 (RPKI ROAs for<br>
                        Unallocated and Unassigned AFRINIC Address Space
                ? Draft 2).<br>
                Message-ID: <<a
                  href="mailto:9149D981-DD95-473D-9D59-DBB705FB712B@consulintel.es"
                  rel="noreferrer noreferrer" target="_blank"
                  moz-do-not-send="true">9149D981-DD95-473D-9D59-DBB705FB712B@consulintel.es</a>><br>
                Content-Type: text/plain; charset="utf-8"<br>
                <br>
                Hi Anthony,<br>
                <br>
                <br>
                <br>
                I don?t recall now if you were in favor or against the
                proposal, anyway, my understanding from your email is
                that you?re trying to explain why the people that don?t
                have the right expertise/knowledge, is opposing to the
                proposal.<br>
                <br>
                <br>
                <br>
                Your text show how wrong is the understanding of how
                RPKI works:<br>
                <br>
                <br>
                RPKI is an opt-in service. There is no enforcement to
                use RPKI. As a consequence, this proposal doesn?t change
                the information already available in the AFRINIC
                database. The database already contains information of
                who is the right resource-holder for every block and
                what blocks should not be ?in use? (unallocated,
                recovered, or whatever are the reasons).<br>
                RPKI is a set of tools. The AS0 is part of this set of
                tools. It is an opt-in service as well. You can use RPKI
                but decide not to trust/use the AS0. It is completely
                optional, but for those that want to have less chances
                of routing hijacked or invalid resources, it simplifies
                a lot their lives. They could build their own ?tools?
                reading the AFRINIC database and creating their own
                filters. AS0 is only simplifying that and making the
                source more trusted and more automated.<br>
                Consequently, it is untrue what you said ?they have no
                choice if this policy passes, so this is a valid
                objection and a critical one? is technically and
                objectively UNTRUE. There is no way to sustain that this
                is a valid objection.<br>
                With RPKI or anything related to this ?tool set? AFRINIC
                doesn?t get involved in routing in any *different* way
                than by having a database holding the information of
                what blocks are ?in use? or otherwise.<br>
                <br>
                <br>
                So, I must insist. The objections are invalid. Please
                demonstrate your words, because they are UNTRUE,
                technically and objectively. They will *only* become
                true if we *force* all the members (and the members of
                all the other RIRs to):<br>
                Use RPKI.<br>
                AND<br>
                Filter the invalids in the AS0<br>
                <br>
                <br>
                As one of my author colleagues said in the discussion
                among us (I modify a bit the text to make it more
                explicit), accepting as valid the clearly *invalid*
                objections means that some community members, the
                chairs, and the Appeal Committee, are responsible of the
                ?blood of the future hijacks that could have been
                avoided by those willing to use RPKI and the AS0?.<br>
                <br>
                <br>
                <br>
                So, the question is, are you going to compensate for the
                damages for that? Because it is a violation of the PDP
                to declare as valid objections that are technically and
                clearly invalid. This is beyond to this policy proposal;
                it is referred to the absolute violation of the PDP when
                declaring consensus/non-consensus. Invalid objections
                must be demonstrated or non-addressed by the authors or
                the community, not based on personal preferences or
                opinions.<br>
                <br>
                <br>
                <br>
                Regards,<br>
                <br>
                Jordi<br>
                <br>
                @jordipalet<br>
                <br>
                <br>
                <br>
                <br>
                <br>
                <br>
                <br>
                El 27/1/21 15:48, "Anthony Ubah" <<a
                  href="mailto:ubah.tonyiyke@gmail.com" rel="noreferrer
                  noreferrer" target="_blank" moz-do-not-send="true">ubah.tonyiyke@gmail.com</a>>
                escribi?:<br>
                <br>
                <br>
                <br>
                Hello Jordi,<br>
                <br>
                <br>
                This is not an opt-in service; this is created as an
                additional element in the RPKI service and forcefully
                asks the operator (who accepts the RPKI) to accept it.
                Taking RPKI as an opt-in service, and claiming the
                element you have added here, are already part of that
                opt-in service. When the operator accepts it then, it
                would be misguiding as they may not admit such
                additional elements. However, they have no choice if
                this policy passes, so this is a valid objection and a
                critical one.<br>
                <br>
                The very fundamental principle which I believe you fail
                to understand (and the most crucial objection) is that
                we do not want to get AFRINIC involved in routing. This
                is an ideological difference, and this is no way to
                address it.<br>
                <br>
                This is the very first policy to ask an RIR to
                proactively inject data into routing (something that was
                never done before), and this also goes beyond what we
                believe an RIR should be, simply offering a registration
                service, and if you think otherwise, that is entirely up
                to you. This would then constitute an ideological
                difference, and there is no acceptable way you can
                address it. This is also why this policy does not have
                consensus because forcing an ideology on others that
                fundamentally disagree with you is not how PDP works,
                regardless of how many appeals filed. Lastly, an
                ideological difference is the very definition of
                nonconsensus.<br>
                <br>
                <br>
                <br>
                Best Regards,<br>
                <br>
                UBAH ANTHONY <br>
                <br>
                <br>
                <br>
                On Tue, Jan 26, 2021 at 4:49 PM <<a
                  href="mailto:rpd-request@afrinic.net" rel="noreferrer
                  noreferrer" target="_blank" moz-do-not-send="true">rpd-request@afrinic.net</a>>
                wrote:<br>
                <br>
                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: REPORT ON Appeal against the non-consensus
                determination<br>
                      on proposal AFPUB-2019-GEN-006-DRAFT02 (RPKI ROAs
                for Unallocated<br>
                      and Unassigned AFRINIC Address Space ? Draft 2).<br>
                      (JORDI PALET MARTINEZ)<br>
                <br>
                <br>
----------------------------------------------------------------------<br>
                <br>
                Message: 1<br>
                Date: Tue, 26 Jan 2021 16:48:18 +0100<br>
                From: JORDI PALET MARTINEZ <<a
                  href="mailto:jordi.palet@consulintel.es"
                  rel="noreferrer noreferrer" target="_blank"
                  moz-do-not-send="true">jordi.palet@consulintel.es</a>><br>
                To: <<a href="mailto:rpd@afrinic.net" rel="noreferrer
                  noreferrer" target="_blank" moz-do-not-send="true">rpd@afrinic.net</a>><br>
                Subject: Re: [rpd] REPORT ON Appeal against the
                non-consensus<br>
                        determination on proposal
                AFPUB-2019-GEN-006-DRAFT02 (RPKI ROAs for<br>
                        Unallocated and Unassigned AFRINIC Address Space
                ? Draft 2).<br>
                Message-ID: <<a
                  href="mailto:5192313B-D19C-4CF9-8D9A-423C0EC8C0C8@consulintel.es"
                  rel="noreferrer noreferrer" target="_blank"
                  moz-do-not-send="true">5192313B-D19C-4CF9-8D9A-423C0EC8C0C8@consulintel.es</a>><br>
                Content-Type: text/plain; charset="utf-8"<br>
                <br>
                Hi Fernando,<br>
                <br>
                <br>
                <br>
                Let me explain how I see it.<br>
                <br>
                <br>
                The PDP is not a vote, and all the processes related to
                the PDP must follow the same way.<br>
                The co-chairs need to follow consensus also among them:
                If a proposal had objections and they?ve been addressed:
                there is no way for any of the co-chairs to disagree on
                that. If that happens, the co-chairs are doing a very
                bad job, because they need to, during the discussion,
                follow it, and ensure that an objection is:<br>
                It is clearly invalid (it is a personal viewpoint or
                hast not been justified, or clearly is untrue or is a
                lack of understanding or knowledge)<br>
                Has been addressed by the authors (or other community
                members), <br>
                Has not been addressed, so it is valid. And in this
                case, they should ensure that the authors or someone
                else in the community has the opportunity to address it.<br>
                Consequently, if a co-chair disagrees with the other
                one, they need to clarify among themselves or ask for
                further clarification to the community, authors, etc.
                There is no need that both co-chairs ?agree?, if one of
                the co-chairs can see the objection as addressed<br>
                The Appeal Committee must review if the co-chairs did
                the job correctly in 2 above. For that, doesn?t matter
                if (in the case of 5 AC members) 4 of them believe an
                objection was invalid if only one of them can see that
                the objection it has been addressed: exactly the same as
                the community and the co-chairs.<br>
                <br>
                <br>
                I fully understand that this is not so easy! But any
                policy proposal can be broken in as many parts as
                objections raised and then resolved one by one.<br>
                <br>
                <br>
                <br>
                Let?s take an example with this proposal. Each objection
                is a different problem and each one should be addressed.
                Let?s take the first one:<br>
                <br>
                <br>
                Allowing resource holders to create AS0/ ROA will lead
                to an increase of even more invalid prefixes in the
                routing table?<br>
                <br>
                <br>
                If you look at the RFC6483, section 4 (?A ROA with a
                subject of AS 0 (AS 0 ROA) is an attestation by the
                holder of a prefix that the prefix described in the ROA,
                and any more specific prefix, should not be used in a
                routing context?) resource holders, as part of the RPKI
                system already can and actually do this (example IXPs),
                in fact they do. This has been explained several times,
                including my presentation at the PPM. The proposal is
                just adding light about actual facts regarding this
                aspect, not changing anything, so it can?t be a valid
                objection for the policy proposal.<br>
                <br>
                <br>
                <br>
                There is no way that *any* of the co-chairs disagree
                with this. If they disagree, they should ask to staff or
                experts, it shows lack of knowledge stating that
                objection. Even if one co-chair agrees and the other
                disagree, it is still an invalid objection and the
                co-chair that has no knowledge must *consent* this is
                the meaning of consensus.<br>
                <br>
                <br>
                <br>
                If the co-chairs still insist that this objection is
                valid, then the Appeal Committee does the same exercise.
                It is a valid objection? If only one of the AC has the
                knowledge to understand this, it is sufficient to make
                it an invalid objection. The others must *consent*
                (again, meaning of consensus).<br>
                <br>
                <br>
                <br>
                Consensus is about only considering acceptable (or
                valid) those objections that nobody can address.<br>
                <br>
                <br>
                <br>
                If the AC makes it based in majority, IT IS NO LONGER
                CONSENSUS, and basically it is basing the decision on
                the expertise of the different AC members, personal
                opinions, etc.<br>
                <br>
                <br>
                <br>
                Regards,<br>
                <br>
                Jordi<br>
                <br>
                @jordipalet<br>
                <br>
                <br>
                <br>
                <br>
                <br>
                <br>
                <br>
                El 26/1/21 15:03, "Fernando Frediani" <<a
                  href="mailto:fhfrediani@gmail.com" rel="noreferrer
                  noreferrer" target="_blank" moz-do-not-send="true">fhfrediani@gmail.com</a>>
                escribi?:<br>
                <br>
                <br>
                <br>
                Hello Jordi<br>
                <br>
                I think that was a very good and detailed email.<br>
                There is however one point I differ on you: the decision
                taken by the AC should be based on majority of votes of
                the members. Obviously they must not take decisions
                based on personal opinions of the merit of the proposal
                but on the facts and if all issues have been resolved.<br>
                Regarding the decisions between the 2 Co-Chairs I don't
                think the consensus model applies there simply because
                there is not how to have a consensus model applied
                between 2 persons. Either they both agree on something
                or that cannot advance.<br>
                <br>
                In resume: The consensus evaluation between 2 Co-Chair
                require both to agree there was consensus. The consensus
                evaluation or analysis if the Co-Chairs committed a
                mistake between all members of the AC is done via
                majority and in this last case that doesn't exclude the
                eventual necessity of explaining in details how every
                evaluation was taken for transparency proposes. The
                consensus model applies only the community while the
                proposals are being discussed and issues are being
                addressed.<br>
                <br>
                Regards<br>
                Fernando<br>
                <br>
                On 26/01/2021 07:50, JORDI PALET MARTINEZ via RPD wrote:<br>
                <br>
                Hi Wafa, all,<br>
                <br>
                <br>
                <br>
                First of all, don?t take anything that I say personally,
                but in general I see a total failure of the Appeal
                Committee and lack of compliance with the PDP.<br>
                <br>
                <br>
                <br>
                Your judgment must be on the grounds of a correct
                decision of the chairs.<br>
                <br>
                <br>
                <br>
                In taking such decision the Appeal Committee must be
                based on facts, never on personal opinions (from the
                community or the chairs or the Appeal Committee itself).
                Being based on objective facts means checking if what
                the policy proposal said, what were the objections, and
                if those objections *are real*, not just ?illusions? or
                ?lack of knowledge? or ?untrue? or ?personal
                preferences?.<br>
                <br>
                <br>
                <br>
                If the Appeal Committee doesn?t have the right
                knowledge, as I already said I believe was the reason
                the chairs took the wrong decision, then they should ask
                for help to the staff or third parties.<br>
                <br>
                <br>
                <br>
                Any objection to a policy proposal must be duly
                justified and that justification not addressed by the
                authors or other community members.<br>
                <br>
                <br>
                <br>
                Any policy proposal that has objections, the objections
                MUST BE VALID, even if the objections come from 99% of
                the community. This is not democracy, is not number of
                votes or voices, is based on non-addressed objections.
                It is not based on untrue objections. None of the
                objections to this policy proposal were valid. They are
                mostly based on lack of sufficient knowledge, and never
                lack of knowledge can be a VALID reason. Again, not only
                the authors, but many other expert community members
                have confirmed that those objections are invalid.<br>
                <br>
                <br>
                <br>
                A policy proposal never can be based in ?I don?t like
                it?. You need to state ?I don?t like it because it
                breaks this RFC? (for example). And even in that cases
                authors can respond showing why the perception of
                ?breaking this RFC? is wrong (so addressing the
                objection will nullify it). Policies are not based on
                personal preferences, but in what is the best
                *technically correct choice* for the community.<br>
                <br>
                <br>
                <br>
                Last but not least, the Appeal Committee seems to be
                working as a democratic body, which is wrong. ALL THE
                PDP is based in consensus approach. The Appeal Committee
                must also follow that approach, otherwise, it is
                breaking the ICP-2, which is the higher mandate of how
                the policy making process works. If 3 members of the
                Appeal Committee believe that the opposition was
                correct, they should *demonstrate with facts why* and
                this must be done using the responses provided by the
                authors and community to those objections.<br>
                <br>
                <br>
                <br>
                If 3 members of the Appeal Committee believe that any of
                the objections has not been addressed, they need to
                *demonstrate why*, taking in consideration the community
                and author responses, and those must be crystal clear in
                the report, which is not the case.<br>
                <br>
                <br>
                <br>
                The Appeal Committee must respond to the authors, in a
                consensus based approach, not a democratic one to all
                what the authors confirmed in the Appeal Document.<br>
                <br>
                <br>
                <br>
                Note also that there is a paragraph in the Appeal Report
                that completely kills the PDP and demonstrates that the
                Appeal Committee HAS NOT UNDERSTOOD THEIR JOB AT ALL:<br>
                <br>
                <br>
                <br>
                ?The 3 members who observed significant opposition to
                the policy, however, also observed that it is the PDWG
                that builds consensus and decides whether issues of
                opposition are addressed to the satisfaction of the PDWG
                which is where the PDP requires that consensus is
                assessed by the Co-Chairs.?<br>
                <br>
                <br>
                <br>
                The PDP states clearly that the Appeal Committee need to
                review the chairs decision. If the chairs have
                considered as VALID objections that OBJECTIVELY ARE
                INVALID, it is clear that the Appeal Committee must
                declare the lack of consensus declaration is invalid,
                and consequently, the proposal reached consensus.<br>
                <br>
                <br>
                <br>
                Let?s go the details and I ask the Appeal Committee to
                respond to each of the objections included and refuted
                in the Appeal Document:<br>
                <br>
                <br>
                <br>
                1.       ?a. Allowing resource holders to create AS0/
                ROA will lead to an increase of even more invalid
                prefixes in the routing table?<br>
                <br>
                Following RFC6483, section 4 (?A ROA with a subject of
                AS 0 (AS 0 ROA) is an attestation by the holder of a
                prefix that the prefix described in the ROA, and any
                more specific prefix, should not be used in a routing
                context?) resource holders, as part of the RPKI system
                already can and actually do this (example IXPs), in fact
                they do. This has been explained several times,
                including my presentation at the PPM. The proposal is
                just adding light about actual facts regarding this
                aspect, not changing anything, so it can?t be a valid
                objection for the policy proposal.<br>
                <br>
                <br>
                <br>
                2.       ?b. Revocation time of AS0 state, and the time
                for new allocation doesn?t match?<br>
                <br>
                This is not true, again a misunderstanding about how
                RPKI works. The authors and other several community
                experts have discussed this in the list. If you get
                number resources from AFRINIC, normally you don?t
                announce them in minutes, or hours, or even days. There
                is some work to do in your network, you need to do
                changes in systems and routers, and this takes hours,
                and normally you can?t ?touch? systems during the day,
                but only in ?maintenance windows? in the night. That
                means that if AFRINIC revokes an AS0 certificate, it
                will be done in a few minutes during the day. So even if
                the worldwide caches take hours to see that, there is no
                negative impact.<br>
                <br>
                <br>
                <br>
                In addition to that, this it can be improved thru
                implementation, as I already explained also in the list.
                The staff could tentatively release from the AS0 the
                resources that they plan to allocate once a week or
                every couple of days, etc. For example, when they are
                processing a request, and they are pending on final
                documentation, the RSA signature for new members, or the
                review with the member of the justified need. Many other
                examples can be provided about how to do it. The
                proposal doesn?t go into any of those details, because
                the understanding is that those are too depth
                operational, and in fact the staff could decide an
                approach during the implementation, and based on
                experience improve it afterwards.<br>
                <br>
                <br>
                <br>
                The conclusion is that there is no such ?matching?,
                neither ?unmatching?, so this can?t be taken as a valid
                objection for the proposal.<br>
                <br>
                <br>
                <br>
                3.       ?c. Other RIRs don?t have a similar the policy
                therefore, it can not be effective?<br>
                <br>
                All the policies have different discussions in different
                RIRs at different times. This policy is already
                available (reached consensus and implemented) in APNIC
                and LACNIC (reached consensus, being implemented). There
                is work being done in ARIN and RIPE (the first proposal
                was not accepted), not yet public. So, this is untrue if
                you look at all the RIRs.<br>
                <br>
                <br>
                <br>
                The effectivity of a policy is not only related to how
                many RIRs implement it. In this case, any RIR having
                this policy is actually stronger than the other RIRs not
                having it, in terms of routing security. It shows the
                commitment of that RIR about the RPKI usage with all its
                possibilities. It facilitates the operators in the
                region and outside the region to identify in a simpler
                and automated way, what prefixes should not be in the
                routing tables and consequently allow them in an opt-in
                basis, to discard them. So, it is in the other way
                around, any RIR with this policy could be said that it
                is more ?effective? (even if it is not probably the
                right wording for this topic) that the others. We should
                rather say that ?a RIR with this policy is offering a
                more secure view of their routing information?.<br>
                <br>
                <br>
                <br>
                In addition to that, there are policies in AFRINIC which
                aren?t available in other RIRs. That, clearly, doesn?t
                make them invalid (or in other words, this is an invalid
                objection ? is good that all RIRs do the same, but is
                not always the case, or not at the same time), clearly
                this shows that this can?t be taken as a valid objection
                against this policy proposal.<br>
                <br>
                <br>
                <br>
                4.       ?d. This will become a uniform policy if it is
                not globally implemented, which causes additional
                stress?<br>
                <br>
                This is almost a duplicate of the previous one.
                Absolutely not. We can add that the way we suggest the
                staff, and they confirmed, with an independent TAL
                protects, as intended by the proposal, the resources of
                the RIR implementing it, not creating any issues in what
                is done in other RIRs to any operator, so it can?t be
                taken as a valid objection against this policy proposal.<br>
                <br>
                <br>
                <br>
                It is difficult to understand what it means ?additional
                stress? in this context, but clearly, it will be in the
                other way around. As more RIRs implement it, less manual
                work in terms of filtering, is needed to be done by
                operators, if they opt to use the AS0 ROA service from
                the RIRs that have implemented it. So, it is not correct
                and thus, not a valid objection.<br>
                <br>
                <br>
                <br>
                If the question is about if this policy should be a
                Global Policy, the response has also been provided in
                the discussion. Ideally, a Global Policy will be only
                able to protect the IANA unallocated resources, but not
                the resources that IANA already allocated to each RIR.
                In fact, I?m already working (when time permits it will
                be made public) in a Global Policy for that, but this is
                irrelevant versus having a policy at every RIR (or a few
                of them), so again, objectively not a valid objection.<br>
                <br>
                <br>
                <br>
                5.       ?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?? <br>
                <br>
                This doesn?t make sense, at least not as worded. This is
                not about recovering space, no relation. It is the
                unused space hold by AFRINIC, regardless of if it was
                never allocated/assigned, returned by members, or
                recovered by AFRINIC. Once more, not a valid objection.<br>
                <br>
                <br>
                <br>
                6.       ?f. How do we revoke the ROA? How long does it
                take to revoke it (chain/ refreshing )?? <br>
                <br>
                This looks the same as 2.2 above. It doesn?t matter in
                practice, if it takes minutes or hours or even days.
                Community and staff provided some facts about this, just
                to cite a couple of them:<br>
                <br>
                <a
                  href="https://lists.afrinic.net/pipermail/rpd/2020/011335.html"
                  rel="noreferrer noreferrer noreferrer" target="_blank"
                  moz-do-not-send="true">https://lists.afrinic.net/pipermail/rpd/2020/011335.html</a><br>
                <br>
                <a
                  href="https://lists.afrinic.net/pipermail/rpd/2020/011348.html"
                  rel="noreferrer noreferrer noreferrer" target="_blank"
                  moz-do-not-send="true">https://lists.afrinic.net/pipermail/rpd/2020/011348.html</a><br>
                <br>
                <br>
                <br>
                7.       ?g. What happens if AFRINIC accidentally issues
                a ROA for an address in error?? <br>
                <br>
                What happens if AFRINIC accidentally issues a ROA
                without an address already allocated to members?<br>
                <br>
                <br>
                <br>
                Exactly the same if the existing RPKI fails, and that?s
                why there are monitoring systems in place and as
                reported by the staff impact analysis, this proposal
                will ensure that the monitoring is improved, so it is
                actually helping on the right direction, not in the
                other way around.<br>
                <br>
                <br>
                <br>
                Further to that, because the systems of operators have
                caches, it is all depending (for the existing TAL and
                for the new one implemented with this proposal) on how
                much time it takes to AFRINIC to resolve the error and
                the specific configuration of the operators and if they
                actually drop invalid prefixes or they only create
                alerts, trigger some processes, etc. Note that RPKI
                doesn?t force the operators to drop the prefixes even if
                they are using RPKI, there are different ways to take
                advantage of this.<br>
                <br>
                <br>
                <br>
                This proposal doesn't change that, it is provided as an
                opt-in service and consequently it is not a valid
                objection.<br>
                <br>
                <br>
                <br>
                8.       ?h. It also might affect the neighbours and
                involves monitoring of unallocated spaces? <br>
                <br>
                It is not clear if neighbours here is referring to BGP
                peering ones.<br>
                <br>
                <br>
                <br>
                The same monitoring that right now is done AFRINIC for
                unallocated/unassigned spaces could be improved with
                this proposal. AFRINIC already, today, needs to make
                sure that they get alerts if unallocated/unassigned
                space appears in the routing tables, because that may
                imply that a member may be violating the RSA, bylaws,
                policies, etc.<br>
                <br>
                <br>
                <br>
                Exactly the same as for operators connected to Internet
                with BGP. The proposal allows them, as an opt-in
                service, to improve if they wish, the automation of all
                that, and to use the service in the way they decide. The
                proposal is not forcing operators any specific usage for
                the service, it is entirely at their own
                decision/discretion.<br>
                <br>
                <br>
                <br>
                This proposal ensures that the service is improved so,
                hijacking of unused space is less prone to occur, that?s
                the purpose of the proposal and RPKI, increase the
                routing security, without making it mandatory for any
                operator. Consequently, once more, this can?t be
                considered a valid objection.<br>
                <br>
                <br>
                <br>
                9.       ?i. Possibility of it being used against a
                member who is yet to pay dues? <br>
                <br>
                According to AFRINIC bylaws and RSA, AFRINIC has the
                obligation to avoid members not paying to stop using the
                resources, so they are available to other members.<br>
                <br>
                <br>
                <br>
                It will be unfair and discriminatory to other members
                not doing so, and that?s the reason, even if we don?t
                have this proposal, AFRINIC could at any time, following
                the bylaws and RSA, do whatever actions, including legal
                and technical ones, to make sure that unallocated, or
                unassigned, or returned, or recovered resources are not
                used. As part of those actions, AFRINIC could even ask
                in courts to stop routing those resources, even to other
                operators. It is AFRINIC duty, practically will probably
                not make sense in terms of the cost (unless a major
                hijacking of AFRINIC resources occurs). Most probably
                just the cooperation among operators, without any legal
                requirement, will make that happen. So, this proposal
                doesn?t change that in the sense of adding to AFRINIC
                any new prerogative because already have that right and
                duty regarding the responsible use of the resources only
                to the allocated/assigned parties and in compliance with
                the legal bindings.<br>
                <br>
                <br>
                <br>
                To further explain this, if a member decides to stop
                paying, AFRINIC, following legal bindings, will follow a
                procedure to try to fix it, and if it doesn?t succeed,
                will remove whois data (which in turn will cause the
                removal of route objects that depend on them), RDNS
                (which means the address space becomes in general
                unusable), etc.<br>
                <br>
                <br>
                <br>
                Clearly, once more, this can?t be considered a valid
                objection, on the other way around is a fundamental
                AFRINIC?s right and duty.<br>
                <br>
                <br>
                <br>
                I urge you to respond to each of those objections,
                accepted by the chairs to declare the lack of consensus,
                that the authors and other community members
                DEMONSTRATED with OBJECTIVE information, are invalid.<br>
                <br>
                <br>
                <br>
                Again, please, Appeal Committee members, respond
                OBJECTIVELY AND BASED ON FACTS, NOT PERSONAL
                PREFERENCES. The report MUST contain detailed
                demonstration of why the Appeal Committee (not
                individual members) say each of those objections has not
                been addressed, while the authors and community believe
                otherwise.<br>
                <br>
                <br>
                <br>
                This is what we expect from an Appeal Committee, to
                OBJECTIVELY review what the chairs objserved, when the
                Appeal Document clearly demonstrated that it is invalid
                and consequently the chairs took a wrong decision, based
                on personal preferences of community members or lack of
                knowledge, or other not objective or untrue facts.<br>
                <br>
                <br>
                <br>
                Regards,<br>
                <br>
                Jordi<br>
                <br>
                @jordipalet<br>
                <br>
                <br>
                <br>
                <br>
                <br>
                <br>
                <br>
                El 22/1/21 13:59, "wafa Dahmani" <<a
                  href="mailto:wafatn7604@gmail.com" rel="noreferrer
                  noreferrer" target="_blank" moz-do-not-send="true">wafatn7604@gmail.com</a>>
                escribi?:<br>
                <br>
                <br>
                <br>
                Dear Community,<br>
                <br>
                <br>
                <br>
                This is to inform you that the Report on Appeal against
                the non-consensus determination on proposal
                AFPUB-2019-GEN-006-DRAFT02 (RPKI ROAs for Unallocated
                and Unassigned AFRINIC Address Space ? Draft 2) and the
                minutes have been published following the links below:<br>
                <br>
                <br>
                <br>
                <a
href="https://afrinic.net/ast/pdf/policy/20210121-rpki-roa-appeal-report.pdf"
                  rel="noreferrer noreferrer noreferrer" target="_blank"
                  moz-do-not-send="true">https://afrinic.net/ast/pdf/policy/20210121-rpki-roa-appeal-report.pdf</a><br>
                <br>
                <br>
                <br>
                <a
                  href="https://afrinic.net/policy/appeal-committee#appeals"
                  rel="noreferrer noreferrer noreferrer" target="_blank"
                  moz-do-not-send="true">https://afrinic.net/policy/appeal-committee#appeals</a><br>
                <br>
                <br>
                <br>
                Best Regards<br>
                <br>
                Wafa Dahmani<br>
                <br>
                Chair of the Appeal Committee<br>
                <br>
                <br>
                <br>
                _______________________________________________ RPD
                mailing list <a href="mailto:RPD@afrinic.net"
                  rel="noreferrer noreferrer" target="_blank"
                  moz-do-not-send="true">RPD@afrinic.net</a> <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>
                IPv4 is over<br>
                Are you ready for the new Internet ?<br>
                <a href="http://www.theipv6company.com" rel="noreferrer
                  noreferrer noreferrer" target="_blank"
                  moz-do-not-send="true">http://www.theipv6company.com</a><br>
                The IPv6 Company<br>
                <br>
                This electronic message contains information which may
                be privileged or confidential. The information is
                intended to be for the exclusive use of the
                individual(s) named above and further non-explicilty
                authorized disclosure, copying, distribution or use of
                the contents of this information, even if partially,
                including attached files, is strictly prohibited and
                will be considered a criminal offense. If you are not
                the intended recipient be aware that any disclosure,
                copying, distribution or use of the contents of this
                information, even if partially, including attached
                files, is strictly prohibited, will be considered a
                criminal offense, so you must reply to the original
                sender to inform about this communication and delete it.<br>
                <br>
                <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>
                _______________________________________________ RPD
                mailing list <a href="mailto:RPD@afrinic.net"
                  rel="noreferrer noreferrer" target="_blank"
                  moz-do-not-send="true">RPD@afrinic.net</a> <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>
                IPv4 is over<br>
                Are you ready for the new Internet ?<br>
                <a href="http://www.theipv6company.com" rel="noreferrer
                  noreferrer noreferrer" target="_blank"
                  moz-do-not-send="true">http://www.theipv6company.com</a><br>
                The IPv6 Company<br>
                <br>
                This electronic message contains information which may
                be privileged or confidential. The information is
                intended to be for the exclusive use of the
                individual(s) named above and further non-explicilty
                authorized disclosure, copying, distribution or use of
                the contents of this information, even if partially,
                including attached files, is strictly prohibited and
                will be considered a criminal offense. If you are not
                the intended recipient be aware that any disclosure,
                copying, distribution or use of the contents of this
                information, even if partially, including attached
                files, is strictly prohibited, will be considered a
                criminal offense, so you must reply to the original
                sender to inform about this communication and delete it.<br>
                <br>
                -------------- next part --------------<br>
                An HTML attachment was scrubbed...<br>
                URL: <<a
href="https://lists.afrinic.net/pipermail/rpd/attachments/20210126/10431eb4/attachment.html"
                  rel="noreferrer noreferrer noreferrer" target="_blank"
                  moz-do-not-send="true">https://lists.afrinic.net/pipermail/rpd/attachments/20210126/10431eb4/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 172, Issue 12<br>
                ************************************<br>
                <br>
                <br>
                <br>
                **********************************************<br>
                IPv4 is over<br>
                Are you ready for the new Internet ?<br>
                <a href="http://www.theipv6company.com" rel="noreferrer
                  noreferrer noreferrer" target="_blank"
                  moz-do-not-send="true">http://www.theipv6company.com</a><br>
                The IPv6 Company<br>
                <br>
                This electronic message contains information which may
                be privileged or confidential. The information is
                intended to be for the exclusive use of the
                individual(s) named above and further non-explicilty
                authorized disclosure, copying, distribution or use of
                the contents of this information, even if partially,
                including attached files, is strictly prohibited and
                will be considered a criminal offense. If you are not
                the intended recipient be aware that any disclosure,
                copying, distribution or use of the contents of this
                information, even if partially, including attached
                files, is strictly prohibited, will be considered a
                criminal offense, so you must reply to the original
                sender to inform about this communication and delete it.<br>
                <br>
                -------------- next part --------------<br>
                An HTML attachment was scrubbed...<br>
                URL: <<a
href="https://lists.afrinic.net/pipermail/rpd/attachments/20210128/c89d2524/attachment.html"
                  rel="noreferrer noreferrer noreferrer" target="_blank"
                  moz-do-not-send="true">https://lists.afrinic.net/pipermail/rpd/attachments/20210128/c89d2524/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 172, Issue 15<br>
                ************************************<br>
              </blockquote>
            </div>
          </div>
          _______________________________________________<br>
          RPD mailing list<br>
          <a href="mailto:RPD@afrinic.net" target="_blank"
            rel="noreferrer" moz-do-not-send="true">RPD@afrinic.net</a><br>
          <a href="https://lists.afrinic.net/mailman/listinfo/rpd"
            rel="noreferrer noreferrer" target="_blank"
            moz-do-not-send="true">https://lists.afrinic.net/mailman/listinfo/rpd</a><br>
        </blockquote>
      </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>