<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>