<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Mar 9, 2021, at 3:06 PM, Fernando Frediani <<a href="mailto:fhfrediani@gmail.com" class="">fhfrediani@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" class="">
<div class=""><p class="">Unfortunatelly, you keep confusing things and making certain
assumptions that aren't correct.<br class="">
First ARIN is an exotic scenario different from everything else.
Thing that apply there (thankfully) don't apply to any other RIR.</p></div></div></blockquote>No, you keep assuming that I am applying ARIN standards elsewhere and I am not. I just went through a comparison for you of</div><div>each of the 5 RIR’s policies in this regard, hoping you’d realize that I actually do have a broader understanding and experience</div><div>than just ARIN. Unfortunately, you seem to fail to recognize that I can make the exact same statement about RIPE, yet you keep</div><div>attempting to apply your RIPE-NCC based perspective to the world.</div><div><blockquote type="cite" class=""><div class=""><div class=""><p class="">Expedited process in LACNIC does NOT mean the same thing we are
discussing here. Expedited process in LACNIC means shorter times
for discussion, Chairs reviews, ratification by the Board to then
be presented in a Public Forum afterwards (the last one is what
makes it to be more expedited). Also and more importantly all this
is fully covered by the PDP which has been previously approved by
the community and ratified by the Board. Nowhere in the LACNIC PDP
mentions anything related to the possibility that Board can adopt
policies by itself without any input of the community, exactly as
it is expected by ICP-2 a base condition for any RIR to start
exist as a RIR to always have the involvement of all stakeholders.<br class=""></p></div></div></blockquote><div>I didn’t say that it does. I believe I provided a fair summary of the LACNIC process below statin that it is community driven.</div><blockquote type="cite" class=""><div class=""><div class=""><p class="">
</p><p class="">It does not matter that bylaws give the Board authority to
implement emergency policies. That is a void thing. Bylaws do not
govern the PDP and will never. If someone one day had the idea to
put that in the bylaws of any RIR that person probably didn't know
what he was doing as that cannot exist in practice. If a Board
would dare to assume they can do that by themselves they would put
the RIR in big trouble against not only its own regional community
but also international community that would seriously dispute that
action.</p></div></div></blockquote>You continue to make this claim and you continue to be wrong. The board, whether you like it or not, is in charge of appointing the CEO and the CEO is accountable to manage the organization according to the directives of the board. The bylaws make this very clear and the bylaws are the legal governing document of the corporation. Thus, AFRINIC employees are held to account to the CEO to operate in accordance with the policies set forth by the board. That’s one of the reasons that the PDP requires board ratification of any policy passed by the community.</div><div><blockquote type="cite" class=""><div class=""><div class=""><p class="">I fail to understand why you seem to defend this prerogative is
valid just because they are written in the bylaws. Have already
discussed that bylaws govern the organization for legal effects
only. Policy Development and Internet business in general concerns
much broader audience is something that is much beyond the bylaws
of an organization.<br class=""></p></div></div></blockquote><div>I’m not defending anything. I’m describing the factual situation as it exists, whether it is to either of our liking or not. Personally, I have some of the same issues with it that you do, but denying the reality of it will not resolve anything. If we wish to change this reality, we must first face the reality and recognize it for what it is. Your refusal to do so does nothing to advance your cause.</div><div><br class=""></div><div>Owen</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div class=""><p class="">
</p><p class="">Fernando<br class="">
</p>
<div class="moz-cite-prefix">On 09/03/2021 19:46, Owen DeLong wrote:<br class="">
</div>
<blockquote type="cite" cite="mid:BBC22984-F6FA-4B7C-A52B-4CCA1BCDC4B8@delong.com" class="">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" class="">
It has already happened more than once within the ARIN region and
in both cases, the boards emergency action was subsequently
ratified by the AC based on positive feedback from the community.
<div class=""><br class="">
</div>
<div class="">I have not found examples of use of this emergency
authority in other RIRs, though I believe the expedited
community process has been used in LACNIC at least once.<br class="">
<div class=""><br class="">
</div>
<div class="">APNIC put this slide deck out in 2013:</div>
<div class=""><a href="https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=&ved=2ahUKEwi46vrEmqTvAhVUHTQIHSVfBuUQFjADegQIBBAD&url=https%3A%2F%2Fwww.apnic.net%2Fwp-content%2Fuploads%2Ficann-aso%2Fassets%2Fapnic-policy-process-ga4.pdf&usg=AOvVaw2csuvQ3OmT4Hs5Guu9lsnk" class="" moz-do-not-send="true">Policy Development Processes
in the APNIC Regionwww.apnic.net › assets ›
apnic-policy-process-ga4</a></div>
<div class=""><br class="">
</div>
<div class="">Search for Emergency and you will find a slide
that clearly states that the bylaws in APNIC give the board
authority to implement emergency policies. In fact, the bylaws
grant the APNIC</div>
<div class="">EC even broader powers than that, Part V, section
30 paragraph “e”:</div>
<blockquote style="margin: 0 0 0 40px; border: none; padding:
0px;" class="">
<div class=""><span style="font-family: "Whitney SSm
A", "Whitney SSm B", Arial, sans-serif;
font-size: 16px;" class="">e. to consider broad Internet
policy issues in order to ensure that APNIC’s policies and
strategies fully respond to the constantly changing
Internet environment;</span></div>
</blockquote>
<div class=""><br class="">
</div>
<div class="">RIPE appears to have no emergency process.</div>
<div class="">LACNIC has an expedited policy process, but it is
community driven.</div>
<div class=""><br class="">
</div>
<div class="">We’ve already covered the details of the AFRINIC
Bylaws and what is specified there in previous posts.</div>
<div class=""><br class="">
</div>
<div class="">
<div class="">
<div class="">
<blockquote type="cite" class="">
<div class="">On Mar 8, 2021, at 6:32 PM, Fernando
Frediani <<a href="mailto:fhfrediani@gmail.com" class="" moz-do-not-send="true">fhfrediani@gmail.com</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div class="">Hi Owen<br class="">
<br class="">
I believe your understanding is very wrong regarding
RIR prerogatives regarding PDP, but I will not
continue this discussion as we are starting to go in
circles.<br class="">
</div>
</div>
</blockquote>
<div class=""><br class="">
</div>
I’m aware of this. I’ve presented documents, bylaws, and
other information which shows my understanding to be
correct. You continue to deny these facts, yet you’ve
offered nothing concrete to support your position.</div>
<div class=""><br class="">
<blockquote type="cite" class="">
<div class="">
<div class="">I just hope no Board on any RIR ever
commit the mistake to believe they can make policies
by themselves just because they believe this is
their right to do for "some emergency or noble
reason" and "for the good of community".<br class="">
</div>
</div>
</blockquote>
<div class=""><br class="">
</div>
I think that the likelihood of a board going rogue in an
RIR is relatively low, but even if that does happen, there
are safeguards in place to limit how rogue they can go. In
all cases, the membership can eventually replace a rogue
board through the election process. Most of the emergency
policy authorities of the board(s) have limits and/or
requirements for subsequent review and usually
ratification by the community of their actions. The
community generally has the power to reverse any such
policy through the applicable PDP.</div>
<div class=""><br class="">
</div>
<div class="">Owen</div>
<div class=""><br class="">
<blockquote type="cite" class="">
<div class="">
<div class=""><br class="">
Fernando<br class="">
<br class="">
On 08/03/2021 17:14, Owen DeLong wrote:<br class="">
<blockquote type="cite" class=""><br class="">
<blockquote type="cite" class="">On Mar 3, 2021,
at 18:15 , Fernando Frediani <<a href="mailto:fhfrediani@gmail.com" class="" moz-do-not-send="true">fhfrediani@gmail.com</a>>
wrote:<br class="">
<br class="">
Owen, I believe you are confusing things here.
Perhaps you are applying some ARIN specific
scenario you may know better to all other RIRs
which is incorrect.<br class="">
</blockquote>
Please stop making assumptions about me. You are
not correct.<br class="">
<br class="">
<blockquote type="cite" class="">AfriNic exist as
any other institution and have a bylaws that
govern the organization for legal and financial
proposals within a country. But to be and
operate as a RIR it must have some recognition
from different stakeholders as for example
community, other internet organizations and
ICANN which requires certain standards of
operation and which are much beyond what the
bylaws do for the organization.<br class="">
</blockquote>
Actually, ICANN does not have the authority to
sanction new RIRs. The IANA is involved in that
process.<br class="">
<br class="">
As I understand it, the empowered community
through the NRO controls the awarding of the IANA
functions contract which is currently awarded to
ICANN and subcontracted too PTI. (I’m still not
100% clear on the relationship between ICANN and
PTI).<br class="">
<br class="">
<blockquote type="cite" class="">Different from
what you said that PDWG is NOT a concession that
the Board give to the community. If it was like
that and Board by its own could make up Internet
policies by its own, the organization would
certainly not be recognized as a RIR, but just a
normal organization and those policies would be
useless.<br class="">
</blockquote>
I did not say that the PDWG is a concession given
to the community to the board. I stated that in
terms of corporate governance and operation, any
authority that the PDWG has is granted to it by
the board and/or the bylaws of the organization.<br class="">
<br class="">
This is technically true of every RIR, whether you
like it or not. It’s also true that in order to
become accredited through ICP-2, something like
the PDWG must be a structural component of the
organization at the time sanction is granted by
the NRO and IANA.<br class="">
<br class="">
<blockquote type="cite" class="">It the Board of
any RIR would ever call that prerogative to
themselves alone the organization would still
exist legally but it would lack community, other
internet organizations and mainly ICANN
(IANA/PRI whatever you may like to call)
recognition as a RIR which MUST operate under
certain standards which some of them are guided
by ICP2 and which different from what you
believe is the guide document not only to be
used one-off to form a new RIR by for a RIR to
remain recognized as such and operate within
those principles.<br class="">
</blockquote>
That’s not entirely clear. I do agree that there
is some power of ISPs to disregard the RIR system
or a particular RIR and develop some other basis
for registering unique numeric identifiers.
However, I think that in reality, any such event
occurring in any cohesive way would be nearly
impossible in the most collegial of situations,
let alone the current environment.<br class="">
<br class="">
<blockquote type="cite" class="">Or do you really
thing that if any Board would retain the
prerogative to make policies only by themselves
the community, ICANN and even many of its
members would still keep recognizing it as a RIR
?<br class="">
</blockquote>
Every RIR board has the prerogative to make
policies by themselves (with the possible
exception of RIPE-NCC, I have not reviewed their
bylaws). It is rarely used, but every RIR has an
emergency policy process where the board can enact
a policy change. Each of those processes also has
a procedure for subsequent review, input, comment,
and/or revision/repeal by the community, but given
that there is a limit to the speed with which the
community can act and the boards have no such
limitation, a board that wanted to act in bad
faith could easily abuse this authority.<br class="">
<br class="">
<blockquote type="cite" class="">Therefore CPM is
not and cannot be governed by any RIR bylaws and
why Board cannot adopt policies unless that
permission is given by the community after due
process.<br class="">
</blockquote>
The CPM is absolutely governed by the bylaws and
the board can absolutely do so. The CPM is a
corporate operational document of the
organization, whether you like it or not. Sure,
the community could create some other structure
with a fork of the CPM or even a brand new version
and call that new structure authoritative for
number resource registrations in the region.
However, getting that new structure accepted by
consensus of the community, let alone sanctioned
under ICP-2 would be a pretty hard uphill battle.<br class="">
<br class="">
Owen<br class="">
<br class="">
<blockquote type="cite" class="">Fernando<br class="">
<br class="">
On 03/03/2021 17:33, Owen DeLong wrote:<br class="">
<blockquote type="cite" class="">Fernando,<br class="">
<br class="">
You are living in a fantasy world if you
believe this. The bylaws are effectively the
constitution<br class="">
of the organization and are the primary
document by which the organization is
governed. The<br class="">
Community does not have standing to control or
override them, nor to change them. The<br class="">
Membership may change the bylaws by resolution
at a members meeting. The community<br class="">
cannot.<br class="">
<br class="">
The community receives what powers it has by
grant from the bylaws and/or the board. This
is<br class="">
the way that the corporate governance
structure of AFRINIC is set up and as near as
I can tell,<br class="">
that’s true across the board of all of the
RIRs with the possible exception of RIPE-NCC
(though<br class="">
I believe it’s actually true there as well,
technically).<br class="">
<br class="">
To the best of my knowledge, this structure is
required for legal compliance in virtually
ever<br class="">
Jurisdiction and it is not (to the best of my
knowledge) legally possible to create a
structure<br class="">
where an unaccountable community holds the
fiduciary control of an organization (which<br class="">
is what you are essentially claiming here).<br class="">
<br class="">
Owen<br class="">
<br class="">
<br class="">
<br class="">
<br class="">
<blockquote type="cite" class="">On Mar 3,
2021, at 5:50 AM, Fernando Frediani <<a href="mailto:fhfrediani@gmail.com" class="" moz-do-not-send="true">fhfrediani@gmail.com</a>>
wrote:<br class="">
<br class="">
Owen, the Board does not have the power to
modify the CPM even on a emergency basis.
This applies on ARIN where you may be more
used with but not here in AfriNic as the
community didn't gave that prerogative to
them and it does not matter they are the
responsible for the RIR. CPM is not
something regulated by the bylaws.<br class="">
<br class="">
Fernando<br class="">
<br class="">
On 03/03/2021 04:09, Owen DeLong via RPD
wrote:<br class="">
<blockquote type="cite" class="">Could the
AFRINIC Board please explain this? The AC
should not be under a gag order or
prvented<br class="">
from continuing its processing of the
appeals on its docket (which are in
progress as specified in the<br class="">
ToR).<br class="">
<br class="">
Also, under the existing rules, it is my
opinion that the AC should either reject
this request to reconsider<br class="">
or accept it in a timely manner. In the
event they accept it, then this is an
appeal that remains in progress<br class="">
and is no longer complete and they should
proceed with it despite the resignations
as specified in the<br class="">
ToR.<br class="">
<br class="">
We really must start following the rules
we have established and not having the
board and others<br class="">
making up random new rules as they see
fit.<br class="">
<br class="">
If you don’t like the rules or feel that
the rules do not fit the situation, then
there are defined processes<br class="">
by which they can be modified. Those
processes have rules and exist to protect
the rights of the<br class="">
community as well as the board. The board
has full power to modify the ToR or the
CPM on an<br class="">
emergency basis if needed, so there really
is no excuse for not doing this properly.<br class="">
<br class="">
<br class="">
<br class="">
Owen<br class="">
<br class="">
<br class="">
<br class="">
<br class="">
<blockquote type="cite" class="">On Mar 2,
2021, at 1:21 AM, <a href="mailto:paulos@sdnp.org.mw" class="" moz-do-not-send="true">paulos@sdnp.org.mw</a>
wrote:<br class="">
<br class="">
Diren,<br class="">
<br class="">
Please note that the Appeal Committee
has been gagged by the Afrinic Board
Chair and<br class="">
hence is currently unable to handle such
requests.<br class="">
<br class="">
Regards,<br class="">
<br class="">
Paulos<br class="">
========================<br class="">
Dr Paulos Nyirenda<br class="">
<br class="">
------- Forwarded message follows
-------<br class="">
Date sent:<span class="Apple-tab-span" style="white-space:pre"> </span>Mon,
01 Mar 2021 15:13:39 +0100<br class="">
From:<span class="Apple-tab-span" style="white-space:pre"> </span><a href="mailto:diren@vanilla.co.za" class="" moz-do-not-send="true">diren@vanilla.co.za</a><br class="">
To:<span class="Apple-tab-span" style="white-space:pre"> </span><a class="moz-txt-link-abbreviated" href="mailto:pdwg-appeal@afrinic.net">pdwg-appeal@afrinic.net</a><br class="">
Subject:<span class="Apple-tab-span" style="white-space:pre"> </span>Re:
[PDWG-Appeal] [rpd] REPORT ON Appeal
against the non-consensus<br class="">
<span class="Apple-tab-span" style="white-space:pre"> </span>determination
on proposal AFPUB-2019-GEN-006-DRAFT02
(RPKI ROAs for<br class="">
<span class="Apple-tab-span" style="white-space:pre"> </span>Unallocated
and Unassigned AFRINIC Address Space<br class="">
<br class="">
<br class="">
Good day! As you asked, I´ve collected
to you several necessary<br class="">
docs and<br class="">
attached them to the email. If you
really will want to find some info,<br class="">
you know, whom to ask.<br class="">
<br class="">
<br class="">
On 2021-02-07 20:48, wrote:<br class="">
<blockquote type="cite" class="">Could
the Appeal Committee respond to this,
and reconsider the work<br class="">
they are doing, as I just explained in
my previous email, taking the<br class="">
inputs of the Recall Committee?<br class="">
<br class="">
Regards,<br class="">
<br class="">
Jordi<br class="">
<br class="">
@jordipalet<br class="">
<br class="">
El 26/1/21 12:14, "JORDI PALET
MARTINEZ via RPD"
<a class="moz-txt-link-rfc2396E" href="mailto:rpd@afrinic.net"><rpd@afrinic.net></a><br class="">
escribi:<br class="">
<br class="">
In case the Appeal Committee is not
subscribed to the RPD list.<br class="">
<br class="">
Waiting for your response.<br class="">
<br class="">
Regards,<br class="">
<br class="">
Jordi<br class="">
<br class="">
@jordipalet<br class="">
<br class="">
El 26/1/21 11:50, "JORDI PALET
MARTINEZ"<br class="">
<a class="moz-txt-link-rfc2396E" href="mailto:jordi.palet@consulintel.es"><jordi.palet@consulintel.es></a>
escribi:<br class="">
<br class="">
Hi Wafa, all,<br class="">
<br class="">
First of all, dont take anything that
I say personally, but in<br class="">
general I see a total failure of the
Appeal Committee and lack of<br class="">
compliance with the PDP.<br class="">
<br class="">
Your judgment must be on the grounds
of a correct decision of the<br class="">
chairs.<br class="">
<br class="">
In taking such decision the Appeal
Committee must be based on facts,<br class="">
never on personal opinions (from the
community or the chairs or the<br class="">
Appeal Committee itself). Being based
on objective facts means<br class="">
checking if what the policy proposal
said, what were the objections,<br class="">
and if those objections *are real*,
not just illusions or lack of<br class="">
knowledge or untrue or personal
preferences.<br class="">
<br class="">
If the Appeal Committee doesnt have
the right knowledge, as I<br class="">
already said I believe was the reason
the chairs took the wrong<br class="">
decision, then they should ask for
help to the staff or third<br class="">
parties.<br class="">
<br class="">
Any objection to a policy proposal
must be duly justified and that<br class="">
justification not addressed by the
authors or other community<br class="">
members.<br class="">
<br class="">
Any policy proposal that has
objections, the objections MUST BE<br class="">
VALID, even if the objections come
from 99% of the community. This<br class="">
is not democracy, is not number of
votes or voices, is based on<br class="">
non-addressed objections. It is not
based on untrue objections. None<br class="">
of the objections to this policy
proposal were valid. They are<br class="">
mostly based on lack of sufficient
knowledge, and never lack of<br class="">
knowledge can be a VALID reason.
Again, not only the authors, but<br class="">
many other expert community members
have confirmed that those<br class="">
objections are invalid.<br class="">
<br class="">
A policy proposal never can be based
in I dont like it. You need<br class="">
to state I dont like it because it
breaks this RFC (for example).<br class="">
And even in that cases authors can
respond showing why the<br class="">
perception of breaking this RFC is
wrong (so addressing the<br class="">
objection will nullify it). Policies
are not based on personal<br class="">
preferences, but in what is the best
*technically correct choice*<br class="">
for the community.<br class="">
<br class="">
Last but not least, the Appeal
Committee seems to be working as a<br class="">
democratic body, which is wrong. ALL
THE PDP is based in consensus<br class="">
approach. The Appeal Committee must
also follow that approach,<br class="">
otherwise, it is breaking the ICP-2,
which is the higher mandate of<br class="">
how the policy making process works.
If 3 members of the Appeal<br class="">
Committee believe that the opposition
was correct, they should<br class="">
*demonstrate with facts why* and this
must be done using the<br class="">
responses provided by the authors and
community to those objections.<br class="">
<br class="">
If 3 members of the Appeal Committee
believe that any of the<br class="">
objections has not been addressed,
they need to *demonstrate why*,<br class="">
taking in consideration the community
and author responses, and<br class="">
those must be crystal clear in the
report, which is not the case.<br class="">
<br class="">
The Appeal Committee must respond to
the authors, in a consensus<br class="">
based approach, not a democratic one
to all what the authors<br class="">
confirmed in the Appeal Document.<br class="">
<br class="">
Note also that there is a paragraph in
the Appeal Report that<br class="">
completely kills the PDP and
demonstrates that the Appeal Committee<br class="">
HAS NOT UNDERSTOOD THEIR JOB AT ALL:<br class="">
<br class="">
The 3 members who observed significant
opposition to the policy,<br class="">
however, also observed that it is the
PDWG that builds consensus and<br class="">
decides whether issues of opposition
are addressed to the<br class="">
satisfaction of the PDWG which is
where the PDP requires that<br class="">
consensus is assessed by the
Co-Chairs.<br class="">
<br class="">
The PDP states clearly that the Appeal
Committee need to review the<br class="">
chairs decision. If the chairs have
considered as VALID objections<br class="">
that OBJECTIVELY ARE INVALID, it is
clear that the Appeal Committee<br class="">
must declare the lack of consensus
declaration is invalid, and<br class="">
consequently, the proposal reached
consensus.<br class="">
<br class="">
Lets go the details and I ask the
Appeal Committee to respond to<br class="">
each of the objections included and
refuted in the Appeal Document:<br class="">
<br class="">
2.1. a. Allowing resource holders to
create AS0/ ROA will lead to<br class="">
an increase of even more invalid
prefixes in the routing table<br class="">
<br class="">
Following RFC6483, section 4 (A ROA
with a subject of AS 0 (AS 0<br class="">
ROA) is an attestation by the holder
of a prefix that the prefix<br class="">
described in the ROA, and any more
specific prefix, should not be<br class="">
used in a routing context) resource
holders, as part of the RPKI<br class="">
system already can and actually do
this (example IXPs), in fact they<br class="">
do. This has been explained several
times, including my presentation<br class="">
at the PPM. The proposal is just
adding light about actual facts<br class="">
regarding this aspect, not changing
anything, so it cant be a valid<br class="">
objection for the policy proposal.<br class="">
<br class="">
2.2. b. Revocation time of AS0
state, and the time for new<br class="">
allocation doesnt match<br class="">
<br class="">
This is not true, again a
misunderstanding about how RPKI works.
The<br class="">
authors and other several community
experts have discussed this in<br class="">
the list. If you get number resources
from AFRINIC, normally you<br class="">
dont announce them in minutes, or
hours, or even days. There is<br class="">
some work to do in your network, you
need to do changes in systems<br class="">
and routers, and this takes hours, and
normally you cant touch<br class="">
systems during the day, but only in
maintenance windows in the<br class="">
night. That means that if AFRINIC
revokes an AS0 certificate, it<br class="">
will be done in a few minutes during
the day. So even if the<br class="">
worldwide caches take hours to see
that, there is no negative<br class="">
impact.<br class="">
<br class="">
In addition to that, this it can be
improved thru implementation, as<br class="">
I already explained also in the list.
The staff could tentatively<br class="">
release from the AS0 the resources
that they plan to allocate once a<br class="">
week or every couple of days, etc. For
example, when they are<br class="">
processing a request, and they are
pending on final documentation,<br class="">
the RSA signature for new members, or
the review with the member of<br class="">
the justified need. Many other
examples can be provided about how to<br class="">
do it. The proposal doesnt go into any
of those details, because<br class="">
the understanding is that those are
too depth operational, and in<br class="">
fact the staff could decide an
approach during the implementation,<br class="">
and based on experience improve it
afterwards.<br class="">
<br class="">
The conclusion is that there is no
such matching, neither<br class="">
unmatching, so this cant be taken as a
valid objection for the<br class="">
proposal.<br class="">
<br class="">
2.3. c. Other RIRs dont have a
similar the policy therefore, it<br class="">
can not be effective<br class="">
<br class="">
All the policies have different
discussions in different RIRs at<br class="">
different times. This policy is
already available (reached consensus<br class="">
and implemented) in APNIC and LACNIC
(reached consensus, being<br class="">
implemented). There is work being done
in ARIN and RIPE (the first<br class="">
proposal was not accepted), not yet
public. So, this is untrue if<br class="">
you look at all the RIRs.<br class="">
<br class="">
The effectivity of a policy is not
only related to how many RIRs<br class="">
implement it. In this case, any RIR
having this policy is actually<br class="">
stronger than the other RIRs not
having it, in terms of routing<br class="">
security. It shows the commitment of
that RIR about the RPKI usage<br class="">
with all its possibilities. It
facilitates the operators in the<br class="">
region and outside the region to
identify in a simpler and automated<br class="">
way, what prefixes should not be in
the routing tables and<br class="">
consequently allow them in an opt-in
basis, to discard them. So, it<br class="">
is in the other way around, any RIR
with this policy could be said<br class="">
that it is more effective (even if it
is not probably the right<br class="">
wording for this topic) that the
others. We should rather say that<br class="">
a RIR with this policy is offering a
more secure view of their<br class="">
routing information.<br class="">
<br class="">
In addition to that, there are
policies in AFRINIC which arent<br class="">
available in other RIRs. That,
clearly, doesnt make them invalid<br class="">
(or in other words, this is an invalid
objection is good that all<br class="">
RIRs do the same, but is not always
the case, or not at the same<br class="">
time), clearly this shows that this
cant be taken as a valid<br class="">
objection against this policy
proposal.<br class="">
<br class="">
2.4. d. This will become a uniform
policy if it is not globally<br class="">
implemented, which causes additional
stress<br class="">
<br class="">
This is almost a duplicate of the
previous one. Absolutely not. We<br class="">
can add that the way we suggest the
staff, and they confirmed, with<br class="">
an independent TAL protects, as
intended by the proposal, the<br class="">
resources of the RIR implementing it,
not creating any issues in<br class="">
what is done in other RIRs to any
operator, so it cant be taken as<br class="">
a valid objection against this policy
proposal.<br class="">
<br class="">
It is difficult to understand what it
means additional stress in<br class="">
this context, but clearly, it will be
in the other way around. As<br class="">
more RIRs implement it, less manual
work in terms of filtering, is<br class="">
needed to be done by operators, if
they opt to use the AS0 ROA<br class="">
service from the RIRs that have
implemented it. So, it is not<br class="">
correct and thus, not a valid
objection.<br class="">
<br class="">
If the question is about if this
policy should be a Global Policy,<br class="">
the response has also been provided in
the discussion. Ideally, a<br class="">
Global Policy will be only able to
protect the IANA unallocated<br class="">
resources, but not the resources that
IANA already allocated to each<br class="">
RIR. In fact, Im already working (when
time permits it will be made<br class="">
public) in a Global Policy for that,
but this is irrelevant versus<br class="">
having a policy at every RIR (or a few
of them), so again,<br class="">
objectively not a valid objection.<br class="">
<br class="">
2.5. e. Validity period: if
members decide to implement it, is<br class="">
it not better to recover the space if
it is kept unused for too<br class="">
long?<br class="">
<br class="">
This doesnt make sense, at least not
as worded. This is not about<br class="">
recovering space, no relation. It is
the unused space hold by<br class="">
AFRINIC, regardless of if it was never
allocated/assigned, returned<br class="">
by members, or recovered by AFRINIC.
Once more, not a valid<br class="">
objection.<br class="">
<br class="">
2.6. f. How do we revoke the ROA?
How long does it take to revoke<br class="">
it (chain/ refreshing )?<br class="">
<br class="">
This looks the same as 2.2 above. It
doesnt matter in practice, if<br class="">
it takes minutes or hours or even
days. Community and staff provided<br class="">
some facts about this, just to cite a
couple of them:<br class="">
<br class="">
<a class="moz-txt-link-freetext" href="https://lists.afrinic.net/pipermail/rpd/2020/011335.html">https://lists.afrinic.net/pipermail/rpd/2020/011335.html</a> [1]<br class="">
<br class="">
<a class="moz-txt-link-freetext" href="https://lists.afrinic.net/pipermail/rpd/2020/011348.html">https://lists.afrinic.net/pipermail/rpd/2020/011348.html</a> [2]<br class="">
<br class="">
2.7. g. What happens if AFRINIC
accidentally issues a ROA for an<br class="">
address in error?<br class="">
<br class="">
What happens if AFRINIC accidentally
issues a ROA without an address<br class="">
already allocated to members?<br class="">
<br class="">
Exactly the same if the existing RPKI
fails, and thats why there<br class="">
are monitoring systems in place and as
reported by the staff impact<br class="">
analysis, this proposal will ensure
that the monitoring is improved,<br class="">
so it is actually helping on the right
direction, not in the other<br class="">
way around.<br class="">
<br class="">
Further to that, because the systems
of operators have caches, it is<br class="">
all depending (for the existing TAL
and for the new one implemented<br class="">
with this proposal) on how much time
it takes to AFRINIC to resolve<br class="">
the error and the specific
configuration of the operators and if<br class="">
they actually drop invalid prefixes or
they only create alerts,<br class="">
trigger some processes, etc. Note that
RPKI doesnt force the<br class="">
operators to drop the prefixes even if
they are using RPKI, there<br class="">
are different ways to take advantage
of this.<br class="">
<br class="">
This proposal doesn't change that, it
is provided as an opt-in<br class="">
service and consequently it is not a
valid objection.<br class="">
<br class="">
2.8. h. It also might affect the
neighbours and involves<br class="">
monitoring of unallocated spaces<br class="">
<br class="">
It is not clear if neighbours here is
referring to BGP peering ones.<br class="">
<br class="">
The same monitoring that right now is
done AFRINIC for<br class="">
unallocated/unassigned spaces could be
improved with this proposal.<br class="">
AFRINIC already, today, needs to make
sure that they get alerts if<br class="">
unallocated/unassigned space appears
in the routing tables, because<br class="">
that may imply that a member may be
violating the RSA, bylaws,<br class="">
policies, etc.<br class="">
<br class="">
Exactly the same as for operators
connected to Internet with BGP.<br class="">
The proposal allows them, as an opt-in
service, to improve if they<br class="">
wish, the automation of all that, and
to use the service in the way<br class="">
they decide. The proposal is not
forcing operators any specific<br class="">
usage for the service, it is entirely
at their own<br class="">
decision/discretion.<br class="">
<br class="">
This proposal ensures that the service
is improved so, hijacking of<br class="">
unused space is less prone to occur,
thats the purpose of the<br class="">
proposal and RPKI, increase the
routing security, without making it<br class="">
mandatory for any operator.
Consequently, once more, this cant be<br class="">
considered a valid objection.<br class="">
<br class="">
2.9. i. Possibility of it being used
against a member who is yet<br class="">
to pay dues<br class="">
<br class="">
According to AFRINIC bylaws and RSA,
AFRINIC has the obligation to<br class="">
avoid members not paying to stop using
the resources, so they are<br class="">
available to other members.<br class="">
<br class="">
It will be unfair and discriminatory
to other members not doing so,<br class="">
and thats the reason, even if we dont
have this proposal, AFRINIC<br class="">
could at any time, following the
bylaws and RSA, do whatever<br class="">
actions, including legal and technical
ones, to make sure that<br class="">
unallocated, or unassigned, or
returned, or recovered resources are<br class="">
not used. As part of those actions,
AFRINIC could even ask in courts<br class="">
to stop routing those resources, even
to other operators. It is<br class="">
AFRINIC duty, practically will
probably not make sense in terms of<br class="">
the cost (unless a major hijacking of
AFRINIC resources occurs).<br class="">
Most probably just the cooperation
among operators, without any<br class="">
legal requirement, will make that
happen. So, this proposal doesnt<br class="">
change that in the sense of adding to
AFRINIC any new prerogative<br class="">
because already have that right and
duty regarding the responsible<br class="">
use of the resources only to the
allocated/assigned parties and in<br class="">
compliance with the legal bindings.<br class="">
<br class="">
To further explain this, if a member
decides to stop paying,<br class="">
AFRINIC, following legal bindings,
will follow a procedure to try to<br class="">
fix it, and if it doesnt succeed, will
remove whois data (which in<br class="">
turn will cause the removal of route
objects that depend on them),<br class="">
RDNS (which means the address space
becomes in general unusable),<br class="">
etc.<br class="">
<br class="">
Clearly, once more, this cant be
considered a valid objection, on<br class="">
the other way around is a fundamental
AFRINICs right and duty.<br class="">
<br class="">
I urge you to respond to each of those
objections, accepted by the<br class="">
chairs to declare the lack of
consensus, that the authors and other<br class="">
community members DEMONSTRATED with
OBJECTIVE information, are<br class="">
invalid.<br class="">
<br class="">
Again, please, Appeal Committee
members, respond OBJECTIVELY AND<br class="">
BASED ON FACTS, NOT PERSONAL
PREFERENCES. The report MUST contain<br class="">
detailed demonstration of why the
Appeal Committee (not individual<br class="">
members) say each of those objections
has not been addressed, while<br class="">
the authors and community believe
otherwise.<br class="">
<br class="">
This is what we expect from an Appeal
Committee, to OBJECTIVELY<br class="">
review what the chairs objserved, when
the Appeal Document clearly<br class="">
demonstrated that it is invalid and
consequently the chairs took a<br class="">
wrong decision, based on personal
preferences of community members<br class="">
or lack of knowledge, or other not
objective or untrue facts.<br class="">
<br class="">
Regards,<br class="">
<br class="">
Jordi<br class="">
<br class="">
@jordipalet<br class="">
<br class="">
El 22/1/21 13:59, "wafa Dahmani"
<a class="moz-txt-link-rfc2396E" href="mailto:wafatn7604@gmail.com"><wafatn7604@gmail.com></a> escribi:<br class="">
<br class="">
Dear Community,<br class="">
<br class="">
This is to inform you that the Report
on Appeal against the<br class="">
non-consensus determination on
proposal AFPUB-2019-GEN-006-DRAFT02<br class="">
(RPKI ROAs for Unallocated and
Unassigned AFRINIC Address Space<br class="">
Draft 2) and the minutes have been
published following the links<br class="">
below:<br class="">
<br class="">
<a class="moz-txt-link-freetext" href="https://afrinic.net/ast/pdf/policy/20210121-rpki-roa-appeal-report.p">https://afrinic.net/ast/pdf/policy/20210121-rpki-roa-appeal-report.p</a><br class="">
df<br class="">
<br class="">
<a class="moz-txt-link-freetext" href="https://afrinic.net/policy/appeal-committee#appeals">https://afrinic.net/policy/appeal-committee#appeals</a><br class="">
<br class="">
Best Regards<br class="">
<br class="">
Wafa Dahmani<br class="">
<br class="">
Chair of the Appeal Committee<br class="">
<br class="">
_______________________________________________ RPD mailing list<br class="">
<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><br class="">
<br class="">
**********************************************<br class="">
IPv4 is over<br class="">
Are you ready for the new Internet ?<br class="">
<a class="moz-txt-link-freetext" href="http://www.theipv6company.com/">http://www.theipv6company.com</a><br class="">
The IPv6 Company<br class="">
<br class="">
This electronic message contains
information which may be privileged<br class="">
or confidential. The information is
intended to be for the exclusive<br class="">
use of the individual(s) named above
and further non-explicilty<br class="">
authorized disclosure, copying,
distribution or use of the contents<br class="">
of this information, even if
partially, including attached files,
is<br class="">
strictly prohibited and will be
considered a criminal offense. If<br class="">
you are not the intended recipient be
aware that any disclosure,<br class="">
copying, distribution or use of the
contents of this information,<br class="">
even if partially, including attached
files, is strictly prohibited,<br class="">
will be considered a criminal offense,
so you must reply to the<br class="">
original sender to inform about this
communication and delete it.<br class="">
<br class="">
_______________________________________________ RPD mailing list<br class="">
<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><br class="">
********************************************** IPv4 is over Are you<br class="">
ready for the new Internet ?
<a class="moz-txt-link-freetext" href="http://www.theipv6company.com/">http://www.theipv6company.com</a> The IPv6<br class="">
Company<br class="">
<br class="">
This electronic message contains
information which may be privileged<br class="">
or confidential. The information is
intended to be for the exclusive<br class="">
use of the individual(s) named above
and further non-explicilty<br class="">
authorized disclosure, copying,
distribution or use of the contents<br class="">
of this information, even if
partially, including attached files,
is<br class="">
strictly prohibited and will be
considered a criminal offense. If<br class="">
you are not the intended recipient be
aware that any disclosure,<br class="">
copying, distribution or use of the
contents of this information,<br class="">
even if partially, including attached
files, is strictly prohibited,<br class="">
will be considered a criminal offense,
so you must reply to the<br class="">
original sender to inform about this
communication and delete it.<br class="">
<br class="">
<br class="">
<br class="">
Links:<br class="">
------<br class="">
[1]
<a class="moz-txt-link-freetext" href="https://lists.afrinic.net/pipermail/rpd/2020/011335.html">https://lists.afrinic.net/pipermail/rpd/2020/011335.html</a><br class="">
[2]
<a class="moz-txt-link-freetext" href="https://lists.afrinic.net/pipermail/rpd/2020/011348.html">https://lists.afrinic.net/pipermail/rpd/2020/011348.html</a><br class="">
</blockquote>
------- End of forwarded message -------<br class="">
<br class="">
<-><prepared-35.zip><->_______________________________________________<br class="">
RPD mailing list<br class="">
<a class="moz-txt-link-abbreviated" href="mailto:RPD@afrinic.net">RPD@afrinic.net</a><br class="">
<a class="moz-txt-link-freetext" href="https://lists.afrinic.net/mailman/listinfo/rpd">https://lists.afrinic.net/mailman/listinfo/rpd</a><br class="">
</blockquote>
_______________________________________________<br class="">
RPD mailing list<br class="">
<a href="mailto:RPD@afrinic.net" class="" moz-do-not-send="true">RPD@afrinic.net</a><br class="">
<a class="moz-txt-link-freetext" href="https://lists.afrinic.net/mailman/listinfo/rpd">https://lists.afrinic.net/mailman/listinfo/rpd</a><br class="">
</blockquote>
_______________________________________________<br class="">
RPD mailing list<br class="">
<a href="mailto:RPD@afrinic.net" class="" moz-do-not-send="true">RPD@afrinic.net</a><br class="">
<a class="moz-txt-link-freetext" href="https://lists.afrinic.net/mailman/listinfo/rpd">https://lists.afrinic.net/mailman/listinfo/rpd</a><br class="">
</blockquote>
</blockquote>
<br class="">
_______________________________________________<br class="">
RPD mailing list<br class="">
<a href="mailto:RPD@afrinic.net" class="" moz-do-not-send="true">RPD@afrinic.net</a><br class="">
<a class="moz-txt-link-freetext" href="https://lists.afrinic.net/mailman/listinfo/rpd">https://lists.afrinic.net/mailman/listinfo/rpd</a><br class="">
</blockquote>
</blockquote>
<br class="">
<br class="">
_______________________________________________<br class="">
RPD mailing list<br class="">
<a href="mailto:RPD@afrinic.net" class="" moz-do-not-send="true">RPD@afrinic.net</a><br class="">
<a class="moz-txt-link-freetext" href="https://lists.afrinic.net/mailman/listinfo/rpd">https://lists.afrinic.net/mailman/listinfo/rpd</a><br class="">
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
</div>
</div>
</blockquote>
</div>
_______________________________________________<br class="">RPD mailing list<br class=""><a href="mailto:RPD@afrinic.net" class="">RPD@afrinic.net</a><br class="">https://lists.afrinic.net/mailman/listinfo/rpd<br class=""></div></blockquote></div><br class=""></body></html>