<div><div dir="auto">Dear community, </div><div dir="auto"><br></div><div dir="auto">As I stated before, the Bylaws have no absolute relevance to the Policy Development Process. Yes, there might be an issue with the number of AC committee membership and given this situation, which will be dealt with I believe. Also, like it has been pointed out, indeed the Bylaws exist to govern the organization but for the AFRINIC to be and function as an RIR, it must have be subject to the recognition of various bodies/stakeholders which the community, etc is part of. This is no fantasy world. The Board does not have any power over the CPM which in its turn cannot be controlled the Bylaws.</div><div dir="auto"><br></div><div dir="auto">Elvis</div></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Mar 4, 2021 at 21:25 Fernando Frediani <<a href="mailto:fhfrediani@gmail.com">fhfrediani@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>
<p>To deal with AC the Board does have these prerogatives to do so
provided by point 3.5 of the CPM.<br>
</p>
<p>What is important here is transparency for the community to know
the reasoning and motivations about it.</p></div><div>
<p>Fernando<br>
</p>
<div>On 04/03/2021 06:31, lucilla fornaro
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">Dear Community,
<div><br>
</div>
<div>
<div>I agree with Fernando on the fact the bylaws shouldn’t
be used to govern the CPM. Bylaws are for AFRINIC Ltd and
do not concern the community. </div>
<div><br>
</div>
<div>I was very bewildered when I saw the board’s email
about the recent appeal committee’s situation , because it
looks like the AC details, including the number of the AC
members is up to the board to design. Therefore, I would
appreciate if the board can provide us a clear update
regarding the AC situation (given that the number of the
AC has been reduced because of the recent consecutive
resignations) and whether the board was responsible behind
suspending the current AC. If the board has indeed played
a role in suspending the AC then we need to know on what
ground and based on what authority they have done so? This
is a community matter and as discussed above, the Bylaws
do not apply to the community.</div>
</div>
<div><br>
</div>
<div>Lucilla</div>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">Il giorno gio 4 mar 2021 alle
ore 11:16 Fernando Frediani <<a href="mailto:fhfrediani@gmail.com" target="_blank">fhfrediani@gmail.com</a>>
ha scritto:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Owen,
I believe you are confusing things here. Perhaps you are
applying <br>
some ARIN specific scenario you may know better to all other
RIRs which <br>
is incorrect.<br>
AfriNic exist as any other institution and have a bylaws that
govern the <br>
organization for legal and financial proposals within a
country. But to <br>
be and operate as a RIR it must have some recognition from
different <br>
stakeholders as for example community, other internet
organizations and <br>
ICANN which requires certain standards of operation and which
are much <br>
beyond what the bylaws do for the organization.<br>
<br>
Different from what you said that PDWG is NOT a concession
that the <br>
Board give to the community. If it was like that and Board by
its own <br>
could make up Internet policies by its own, the organization
would <br>
certainly not be recognized as a RIR, but just a normal
organization and <br>
those policies would be useless.<br>
It the Board of any RIR would ever call that prerogative to
themselves <br>
alone the organization would still exist legally but it would
lack <br>
community, other internet organizations and mainly ICANN
(IANA/PRI <br>
whatever you may like to call) recognition as a RIR which MUST
operate <br>
under certain standards which some of them are guided by ICP2
and which <br>
different from what you believe is the guide document not only
to be <br>
used one-off to form a new RIR by for a RIR to remain
recognized as such <br>
and operate within those principles.<br>
Or do you really thing that if any Board would retain the
prerogative to <br>
make policies only by themselves the community, ICANN and even
many of <br>
its members would still keep recognizing it as a RIR ?<br>
<br>
Therefore CPM is not and cannot be governed by any RIR bylaws
and why <br>
Board cannot adopt policies unless that permission is given by
the <br>
community after due process.<br>
<br>
Fernando<br>
<br>
On 03/03/2021 17:33, Owen DeLong wrote:<br>
> Fernando,<br>
><br>
> You are living in a fantasy world if you believe this.
The bylaws are effectively the constitution<br>
> of the organization and are the primary document by which
the organization is governed. The<br>
> Community does not have standing to control or override
them, nor to change them. The<br>
> Membership may change the bylaws by resolution at a
members meeting. The community<br>
> cannot.<br>
><br>
> The community receives what powers it has by grant from
the bylaws and/or the board. This is<br>
> the way that the corporate governance structure of
AFRINIC is set up and as near as I can tell,<br>
> that’s true across the board of all of the RIRs with the
possible exception of RIPE-NCC (though<br>
> I believe it’s actually true there as well, technically).<br>
><br>
> To the best of my knowledge, this structure is required
for legal compliance in virtually ever<br>
> Jurisdiction and it is not (to the best of my knowledge)
legally possible to create a structure<br>
> where an unaccountable community holds the fiduciary
control of an organization (which<br>
> is what you are essentially claiming here).<br>
><br>
> Owen<br>
><br>
><br>
><br>
><br>
>> On Mar 3, 2021, at 5:50 AM, Fernando Frediani <<a href="mailto:fhfrediani@gmail.com" target="_blank">fhfrediani@gmail.com</a>> wrote:<br>
>><br>
>> 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>
>><br>
>> Fernando<br>
>><br>
>> On 03/03/2021 04:09, Owen DeLong via RPD wrote:<br>
>>> Could the AFRINIC Board please explain this? The
AC should not be under a gag order or prvented<br>
>>> from continuing its processing of the appeals on
its docket (which are in progress as specified in the<br>
>>> ToR).<br>
>>><br>
>>> Also, under the existing rules, it is my opinion
that the AC should either reject this request to reconsider<br>
>>> or accept it in a timely manner. In the event
they accept it, then this is an appeal that remains in
progress<br>
>>> and is no longer complete and they should proceed
with it despite the resignations as specified in the<br>
>>> ToR.<br>
>>><br>
>>> We really must start following the rules we have
established and not having the board and others<br>
>>> making up random new rules as they see fit.<br>
>>><br>
>>> If you don’t like the rules or feel that the
rules do not fit the situation, then there are defined
processes<br>
>>> by which they can be modified. Those processes
have rules and exist to protect the rights of the<br>
>>> community as well as the board. The board has
full power to modify the ToR or the CPM on an<br>
>>> emergency basis if needed, so there really is no
excuse for not doing this properly.<br>
>>><br>
>>><br>
>>><br>
>>> Owen<br>
>>><br>
>>><br>
>>><br>
>>><br>
>>>> On Mar 2, 2021, at 1:21 AM, <a href="mailto:paulos@sdnp.org.mw" target="_blank">paulos@sdnp.org.mw</a> wrote:<br>
>>>><br>
>>>> Diren,<br>
>>>><br>
>>>> Please note that the Appeal Committee has
been gagged by the Afrinic Board Chair and<br>
>>>> hence is currently unable to handle such
requests.<br>
>>>><br>
>>>> Regards,<br>
>>>><br>
>>>> Paulos<br>
>>>> ========================<br>
>>>> Dr Paulos Nyirenda<br>
>>>><br>
>>>> ------- Forwarded message follows -------<br>
>>>> Date sent: Mon, 01 Mar 2021 15:13:39 +0100<br>
>>>> From: <a href="mailto:diren@vanilla.co.za" target="_blank">diren@vanilla.co.za</a><br>
>>>> To: <a href="mailto:pdwg-appeal@afrinic.net" target="_blank">pdwg-appeal@afrinic.net</a><br>
>>>> Subject: Re: [PDWG-Appeal] [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<br>
>>>><br>
>>>><br>
>>>> Good day! As you asked, I´ve collected to you
several necessary<br>
>>>> docs and<br>
>>>> attached them to the email. If you really
will want to find some info,<br>
>>>> you know, whom to ask.<br>
>>>><br>
>>>><br>
>>>> On 2021-02-07 20:48, wrote:<br>
>>>>> Could the Appeal Committee respond to
this, and reconsider the work<br>
>>>>> they are doing, as I just explained in my
previous email, taking the<br>
>>>>> inputs of the Recall Committee?<br>
>>>>><br>
>>>>> Regards,<br>
>>>>><br>
>>>>> Jordi<br>
>>>>><br>
>>>>> @jordipalet<br>
>>>>><br>
>>>>> El 26/1/21 12:14, "JORDI PALET MARTINEZ
via RPD" <<a href="mailto:rpd@afrinic.net" target="_blank">rpd@afrinic.net</a>><br>
>>>>> escribi:<br>
>>>>><br>
>>>>> In case the Appeal Committee is not
subscribed to the RPD list.<br>
>>>>><br>
>>>>> Waiting for your response.<br>
>>>>><br>
>>>>> Regards,<br>
>>>>><br>
>>>>> Jordi<br>
>>>>><br>
>>>>> @jordipalet<br>
>>>>><br>
>>>>> El 26/1/21 11:50, "JORDI PALET MARTINEZ"<br>
>>>>> <<a href="mailto:jordi.palet@consulintel.es" target="_blank">jordi.palet@consulintel.es</a>>
escribi:<br>
>>>>><br>
>>>>> Hi Wafa, all,<br>
>>>>><br>
>>>>> First of all, dont take anything that I
say personally, but in<br>
>>>>> general I see a total failure of the
Appeal Committee and lack of<br>
>>>>> compliance with the PDP.<br>
>>>>><br>
>>>>> Your judgment must be on the grounds of a
correct decision of the<br>
>>>>> chairs.<br>
>>>>><br>
>>>>> In taking such decision the Appeal
Committee must be based on facts,<br>
>>>>> never on personal opinions (from the
community or the chairs or the<br>
>>>>> Appeal Committee itself). Being based on
objective facts means<br>
>>>>> checking if what the policy proposal
said, what were the objections,<br>
>>>>> and if those objections *are real*, not
just illusions or lack of<br>
>>>>> knowledge or untrue or personal
preferences.<br>
>>>>><br>
>>>>> If the Appeal Committee doesnt have the
right knowledge, as I<br>
>>>>> already said I believe was the reason the
chairs took the wrong<br>
>>>>> decision, then they should ask for help
to the staff or third<br>
>>>>> parties.<br>
>>>>><br>
>>>>> Any objection to a policy proposal must
be duly justified and that<br>
>>>>> justification not addressed by the
authors or other community<br>
>>>>> members.<br>
>>>>><br>
>>>>> Any policy proposal that has objections,
the objections MUST BE<br>
>>>>> VALID, even if the objections come from
99% of the community. This<br>
>>>>> is not democracy, is not number of votes
or voices, is based on<br>
>>>>> non-addressed objections. It is not based
on untrue objections. None<br>
>>>>> of the objections to this policy proposal
were valid. They are<br>
>>>>> mostly based on lack of sufficient
knowledge, and never lack of<br>
>>>>> knowledge can be a VALID reason. Again,
not only the authors, but<br>
>>>>> many other expert community members have
confirmed that those<br>
>>>>> objections are invalid.<br>
>>>>><br>
>>>>> A policy proposal never can be based in I
dont like it. You need<br>
>>>>> to state I dont like it because it breaks
this RFC (for example).<br>
>>>>> And even in that cases authors can
respond showing why the<br>
>>>>> perception of breaking this RFC is wrong
(so addressing the<br>
>>>>> objection will nullify it). Policies are
not based on personal<br>
>>>>> preferences, but in what is the best
*technically correct choice*<br>
>>>>> for the community.<br>
>>>>><br>
>>>>> Last but not least, the Appeal Committee
seems to be working as a<br>
>>>>> democratic body, which is wrong. ALL THE
PDP is based in consensus<br>
>>>>> approach. The Appeal Committee must also
follow that approach,<br>
>>>>> otherwise, it is breaking the ICP-2,
which is the higher mandate of<br>
>>>>> how the policy making process works. If 3
members of the Appeal<br>
>>>>> Committee believe that the opposition was
correct, they should<br>
>>>>> *demonstrate with facts why* and this
must be done using the<br>
>>>>> responses provided by the authors and
community to those objections.<br>
>>>>><br>
>>>>> If 3 members of the Appeal Committee
believe that any of the<br>
>>>>> objections has not been addressed, they
need to *demonstrate why*,<br>
>>>>> taking in consideration the community and
author responses, and<br>
>>>>> those must be crystal clear in the
report, which is not the case.<br>
>>>>><br>
>>>>> The Appeal Committee must respond to the
authors, in a consensus<br>
>>>>> based approach, not a democratic one to
all what the authors<br>
>>>>> confirmed in the Appeal Document.<br>
>>>>><br>
>>>>> Note also that there is a paragraph in
the Appeal Report that<br>
>>>>> completely kills the PDP and demonstrates
that the Appeal Committee<br>
>>>>> HAS NOT UNDERSTOOD THEIR JOB AT ALL:<br>
>>>>><br>
>>>>> The 3 members who observed significant
opposition to the policy,<br>
>>>>> however, also observed that it is the
PDWG that builds consensus and<br>
>>>>> decides whether issues of opposition are
addressed to the<br>
>>>>> satisfaction of the PDWG which is where
the PDP requires that<br>
>>>>> consensus is assessed by the Co-Chairs.<br>
>>>>><br>
>>>>> The PDP states clearly that the Appeal
Committee need to review the<br>
>>>>> chairs decision. If the chairs have
considered as VALID objections<br>
>>>>> that OBJECTIVELY ARE INVALID, it is clear
that the Appeal Committee<br>
>>>>> must declare the lack of consensus
declaration is invalid, and<br>
>>>>> consequently, the proposal reached
consensus.<br>
>>>>><br>
>>>>> Lets go the details and I ask the Appeal
Committee to respond to<br>
>>>>> each of the objections included and
refuted in the Appeal Document:<br>
>>>>><br>
>>>>> 2.1. a. Allowing resource holders to
create AS0/ ROA will lead to<br>
>>>>> 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<br>
>>>>> ROA) is an attestation by the holder of a
prefix that the prefix<br>
>>>>> described in the ROA, and any more
specific prefix, should not be<br>
>>>>> used in a routing context) resource
holders, as part of the RPKI<br>
>>>>> system already can and actually do this
(example IXPs), in fact they<br>
>>>>> do. This has been explained several
times, including my presentation<br>
>>>>> at the PPM. The proposal is just adding
light about actual facts<br>
>>>>> regarding this aspect, not changing
anything, so it cant be a valid<br>
>>>>> objection for the policy proposal.<br>
>>>>><br>
>>>>> 2.2. b. Revocation time of AS0 state,
and the time for new<br>
>>>>> allocation doesnt match<br>
>>>>><br>
>>>>> This is not true, again a
misunderstanding about how RPKI works. The<br>
>>>>> authors and other several community
experts have discussed this in<br>
>>>>> the list. If you get number resources
from AFRINIC, normally you<br>
>>>>> dont announce them in minutes, or hours,
or even days. There is<br>
>>>>> some work to do in your network, you need
to do changes in systems<br>
>>>>> and routers, and this takes hours, and
normally you cant touch<br>
>>>>> systems during the day, but only in
maintenance windows in the<br>
>>>>> night. That means that if AFRINIC revokes
an AS0 certificate, it<br>
>>>>> will be done in a few minutes during the
day. So even if the<br>
>>>>> worldwide caches take hours to see that,
there is no negative<br>
>>>>> impact.<br>
>>>>><br>
>>>>> In addition to that, this it can be
improved thru implementation, as<br>
<br>
>>>>> I already explained also in the list. The
staff could tentatively<br>
>>>>> release from the AS0 the resources that
they plan to allocate once a<br>
>>>>> week or every couple of days, etc. For
example, when they are<br>
>>>>> processing a request, and they are
pending on final documentation,<br>
>>>>> the RSA signature for new members, or the
review with the member of<br>
>>>>> the justified need. Many other examples
can be provided about how to<br>
>>>>> do it. The proposal doesnt go into any of
those details, because<br>
>>>>> the understanding is that those are too
depth operational, and in<br>
>>>>> fact the staff could decide an approach
during the implementation,<br>
>>>>> and based on experience improve it
afterwards.<br>
>>>>><br>
>>>>> The conclusion is that there is no such
matching, neither<br>
>>>>> unmatching, so this cant be taken as a
valid objection for the<br>
>>>>> proposal.<br>
>>>>><br>
>>>>> 2.3. c. Other RIRs dont have a similar
the policy therefore, it<br>
>>>>> can not be effective<br>
>>>>><br>
>>>>> All the policies have different
discussions in different RIRs at<br>
>>>>> different times. This policy is already
available (reached consensus<br>
>>>>> and implemented) in APNIC and LACNIC
(reached consensus, being<br>
>>>>> implemented). There is work being done in
ARIN and RIPE (the first<br>
>>>>> proposal was not accepted), not yet
public. So, this is untrue if<br>
>>>>> you look at all the RIRs.<br>
>>>>><br>
>>>>> The effectivity of a policy is not only
related to how many RIRs<br>
>>>>> implement it. In this case, any RIR
having this policy is actually<br>
>>>>> stronger than the other RIRs not having
it, in terms of routing<br>
>>>>> security. It shows the commitment of that
RIR about the RPKI usage<br>
>>>>> with all its possibilities. It
facilitates the operators in the<br>
>>>>> region and outside the region to identify
in a simpler and automated<br>
>>>>> way, what prefixes should not be in the
routing tables and<br>
>>>>> consequently allow them in an opt-in
basis, to discard them. So, it<br>
>>>>> is in the other way around, any RIR with
this policy could be said<br>
>>>>> that it is more effective (even if it is
not probably the right<br>
>>>>> wording for this topic) that the others.
We should rather say that<br>
>>>>> a RIR with this policy is offering a more
secure view of their<br>
>>>>> routing information.<br>
>>>>><br>
>>>>> In addition to that, there are policies
in AFRINIC which arent<br>
>>>>> available in other RIRs. That, clearly,
doesnt make them invalid<br>
>>>>> (or in other words, this is an invalid
objection is good that all<br>
>>>>> RIRs do the same, but is not always the
case, or not at the same<br>
>>>>> time), clearly this shows that this cant
be taken as a valid<br>
>>>>> objection against this policy proposal.<br>
>>>>><br>
>>>>> 2.4. d. This will become a uniform
policy if it is not globally<br>
>>>>> implemented, which causes additional
stress<br>
>>>>><br>
>>>>> This is almost a duplicate of the
previous one. Absolutely not. We<br>
>>>>> can add that the way we suggest the
staff, and they confirmed, with<br>
>>>>> an independent TAL protects, as intended
by the proposal, the<br>
>>>>> resources of the RIR implementing it, not
creating any issues in<br>
>>>>> what is done in other RIRs to any
operator, so it cant be taken as<br>
>>>>> a valid objection against this policy
proposal.<br>
>>>>><br>
>>>>> It is difficult to understand what it
means additional stress in<br>
>>>>> this context, but clearly, it will be in
the other way around. As<br>
>>>>> more RIRs implement it, less manual work
in terms of filtering, is<br>
>>>>> needed to be done by operators, if they
opt to use the AS0 ROA<br>
>>>>> service from the RIRs that have
implemented it. So, it is not<br>
>>>>> correct and thus, not a valid objection.<br>
>>>>><br>
>>>>> If the question is about if this policy
should be a Global Policy,<br>
>>>>> the response has also been provided in
the discussion. Ideally, a<br>
>>>>> Global Policy will be only able to
protect the IANA unallocated<br>
>>>>> resources, but not the resources that
IANA already allocated to each<br>
>>>>> RIR. In fact, Im already working (when
time permits it will be made<br>
>>>>> public) in a Global Policy for that, but
this is irrelevant versus<br>
>>>>> having a policy at every RIR (or a few of
them), so again,<br>
>>>>> objectively not a valid objection.<br>
>>>>><br>
>>>>> 2.5. e. Validity period: if members
decide to implement it, is<br>
>>>>> it not better to recover the space if it
is kept unused for too<br>
>>>>> long?<br>
>>>>><br>
>>>>> This doesnt make sense, at least not as
worded. This is not about<br>
>>>>> recovering space, no relation. It is the
unused space hold by<br>
>>>>> AFRINIC, regardless of if it was never
allocated/assigned, returned<br>
>>>>> by members, or recovered by AFRINIC. Once
more, not a valid<br>
>>>>> objection.<br>
>>>>><br>
>>>>> 2.6. f. How do we revoke the ROA? How
long does it take to revoke<br>
>>>>> it (chain/ refreshing )?<br>
>>>>><br>
>>>>> This looks the same as 2.2 above. It
doesnt matter in practice, if<br>
>>>>> it takes minutes or hours or even days.
Community and staff provided<br>
>>>>> 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" target="_blank">https://lists.afrinic.net/pipermail/rpd/2020/011335.html</a>
[1]<br>
>>>>><br>
>>>>> <a href="https://lists.afrinic.net/pipermail/rpd/2020/011348.html" rel="noreferrer" target="_blank">https://lists.afrinic.net/pipermail/rpd/2020/011348.html</a>
[2]<br>
>>>>><br>
>>>>> 2.7. g. What happens if AFRINIC
accidentally issues a ROA for an<br>
>>>>> address in error?<br>
>>>>><br>
>>>>> What happens if AFRINIC accidentally
issues a ROA without an address<br>
>>>>> already allocated to members?<br>
>>>>><br>
>>>>> Exactly the same if the existing RPKI
fails, and thats why there<br>
>>>>> are monitoring systems in place and as
reported by the staff impact<br>
>>>>> analysis, this proposal will ensure that
the monitoring is improved,<br>
>>>>> so it is actually helping on the right
direction, not in the other<br>
>>>>> way around.<br>
>>>>><br>
>>>>> Further to that, because the systems of
operators have caches, it is<br>
>>>>> all depending (for the existing TAL and
for the new one implemented<br>
>>>>> with this proposal) on how much time it
takes to AFRINIC to resolve<br>
>>>>> the error and the specific configuration
of the operators and if<br>
>>>>> they actually drop invalid prefixes or
they only create alerts,<br>
>>>>> trigger some processes, etc. Note that
RPKI doesnt force the<br>
>>>>> operators to drop the prefixes even if
they are using RPKI, there<br>
>>>>> are different ways to take advantage of
this.<br>
>>>>><br>
>>>>> This proposal doesn't change that, it is
provided as an opt-in<br>
>>>>> service and consequently it is not a
valid objection.<br>
>>>>><br>
>>>>> 2.8. h. It also might affect the
neighbours and involves<br>
>>>>> monitoring of unallocated spaces<br>
>>>>><br>
>>>>> It is not clear if neighbours here is
referring to BGP peering ones.<br>
>>>>><br>
>>>>> The same monitoring that right now is
done AFRINIC for<br>
>>>>> unallocated/unassigned spaces could be
improved with this proposal.<br>
>>>>> AFRINIC already, today, needs to make
sure that they get alerts if<br>
>>>>> unallocated/unassigned space appears in
the routing tables, because<br>
>>>>> that may imply that a member may be
violating the RSA, bylaws,<br>
>>>>> policies, etc.<br>
>>>>><br>
>>>>> Exactly the same as for operators
connected to Internet with BGP.<br>
>>>>> The proposal allows them, as an opt-in
service, to improve if they<br>
>>>>> wish, the automation of all that, and to
use the service in the way<br>
>>>>> they decide. The proposal is not forcing
operators any specific<br>
>>>>> usage for the service, it is entirely at
their own<br>
>>>>> decision/discretion.<br>
>>>>><br>
>>>>> This proposal ensures that the service is
improved so, hijacking of<br>
>>>>> unused space is less prone to occur,
thats the purpose of the<br>
>>>>> proposal and RPKI, increase the routing
security, without making it<br>
>>>>> mandatory for any operator. Consequently,
once more, this cant be<br>
>>>>> considered a valid objection.<br>
>>>>><br>
>>>>> 2.9. i. Possibility of it being used
against a member who is yet<br>
>>>>> to pay dues<br>
>>>>><br>
>>>>> According to AFRINIC bylaws and RSA,
AFRINIC has the obligation to<br>
>>>>> avoid members not paying to stop using
the resources, so they are<br>
>>>>> available to other members.<br>
>>>>><br>
>>>>> It will be unfair and discriminatory to
other members not doing so,<br>
>>>>> and thats the reason, even if we dont
have this proposal, AFRINIC<br>
>>>>> could at any time, following the bylaws
and RSA, do whatever<br>
>>>>> actions, including legal and technical
ones, to make sure that<br>
>>>>> unallocated, or unassigned, or returned,
or recovered resources are<br>
>>>>> not used. As part of those actions,
AFRINIC could even ask in courts<br>
>>>>> to stop routing those resources, even to
other operators. It is<br>
>>>>> AFRINIC duty, practically will probably
not make sense in terms of<br>
>>>>> the cost (unless a major hijacking of
AFRINIC resources occurs).<br>
>>>>> Most probably just the cooperation among
operators, without any<br>
>>>>> legal requirement, will make that happen.
So, this proposal doesnt<br>
>>>>> change that in the sense of adding to
AFRINIC any new prerogative<br>
>>>>> because already have that right and duty
regarding the responsible<br>
>>>>> use of the resources only to the
allocated/assigned parties and in<br>
>>>>> compliance with the legal bindings.<br>
>>>>><br>
>>>>> To further explain this, if a member
decides to stop paying,<br>
>>>>> AFRINIC, following legal bindings, will
follow a procedure to try to<br>
>>>>> fix it, and if it doesnt succeed, will
remove whois data (which in<br>
>>>>> turn will cause the removal of route
objects that depend on them),<br>
>>>>> RDNS (which means the address space
becomes in general unusable),<br>
>>>>> etc.<br>
>>>>><br>
>>>>> Clearly, once more, this cant be
considered a valid objection, on<br>
>>>>> the other way around is a fundamental
AFRINICs right and duty.<br>
>>>>><br>
>>>>> I urge you to respond to each of those
objections, accepted by the<br>
>>>>> chairs to declare the lack of consensus,
that the authors and other<br>
>>>>> community members DEMONSTRATED with
OBJECTIVE information, are<br>
>>>>> invalid.<br>
>>>>><br>
>>>>> Again, please, Appeal Committee members,
respond OBJECTIVELY AND<br>
>>>>> BASED ON FACTS, NOT PERSONAL PREFERENCES.
The report MUST contain<br>
>>>>> detailed demonstration of why the Appeal
Committee (not individual<br>
>>>>> members) say each of those objections has
not been addressed, while<br>
>>>>> the authors and community believe
otherwise.<br>
>>>>><br>
>>>>> This is what we expect from an Appeal
Committee, to OBJECTIVELY<br>
>>>>> review what the chairs objserved, when
the Appeal Document clearly<br>
>>>>> demonstrated that it is invalid and
consequently the chairs took a<br>
>>>>> wrong decision, based on personal
preferences of community members<br>
>>>>> or lack of knowledge, or other not
objective or untrue facts.<br>
>>>>><br>
>>>>> Regards,<br>
>>>>><br>
>>>>> Jordi<br>
>>>>><br>
>>>>> @jordipalet<br>
>>>>><br>
>>>>> El 22/1/21 13:59, "wafa Dahmani" <<a href="mailto:wafatn7604@gmail.com" target="_blank">wafatn7604@gmail.com</a>> escribi:<br>
>>>>><br>
>>>>> Dear Community,<br>
>>>>><br>
>>>>> This is to inform you that the Report on
Appeal against the<br>
>>>>> non-consensus determination on proposal
AFPUB-2019-GEN-006-DRAFT02<br>
>>>>> (RPKI ROAs for Unallocated and Unassigned
AFRINIC Address Space<br>
>>>>> Draft 2) and the minutes have been
published following the links<br>
>>>>> below:<br>
>>>>><br>
>>>>> <a href="https://afrinic.net/ast/pdf/policy/20210121-rpki-roa-appeal-report.p" rel="noreferrer" target="_blank">https://afrinic.net/ast/pdf/policy/20210121-rpki-roa-appeal-report.p</a><br>
>>>>> df<br>
>>>>><br>
>>>>> <a href="https://afrinic.net/policy/appeal-committee#appeals" rel="noreferrer" target="_blank">https://afrinic.net/policy/appeal-committee#appeals</a><br>
>>>>><br>
>>>>> Best Regards<br>
>>>>><br>
>>>>> Wafa Dahmani<br>
>>>>><br>
>>>>> Chair of the Appeal Committee<br>
>>>>><br>
>>>>>
_______________________________________________ RPD mailing
list<br>
>>>>> <a href="mailto:RPD@afrinic.net" target="_blank">RPD@afrinic.net</a> <a href="https://lists.afrinic.net/mailman/listinfo/rpd" rel="noreferrer" target="_blank">https://lists.afrinic.net/mailman/listinfo/rpd</a><br>
>>>>><br>
>>>>>
**********************************************<br>
>>>>> IPv4 is over<br>
>>>>> Are you ready for the new Internet ?<br>
>>>>> <a href="http://www.theipv6company.com" rel="noreferrer" target="_blank">http://www.theipv6company.com</a><br>
>>>>> The IPv6 Company<br>
>>>>><br>
>>>>> This electronic message contains
information which may be privileged<br>
>>>>> or confidential. The information is
intended to be for the exclusive<br>
>>>>> use of the individual(s) named above and
further non-explicilty<br>
>>>>> authorized disclosure, copying,
distribution or use of the contents<br>
>>>>> of this information, even if partially,
including attached files, is<br>
>>>>> strictly prohibited and will be
considered a criminal offense. If<br>
>>>>> you are not the intended recipient be
aware that any disclosure,<br>
>>>>> copying, distribution or use of the
contents of this information,<br>
>>>>> even if partially, including attached
files, is strictly prohibited,<br>
>>>>> will be considered a criminal offense, so
you must reply to the<br>
>>>>> original sender to inform about this
communication and delete it.<br>
>>>>><br>
>>>>>
_______________________________________________ RPD mailing
list<br>
>>>>> <a href="mailto:RPD@afrinic.net" target="_blank">RPD@afrinic.net</a> <a href="https://lists.afrinic.net/mailman/listinfo/rpd" rel="noreferrer" target="_blank">https://lists.afrinic.net/mailman/listinfo/rpd</a><br>
>>>>>
********************************************** IPv4 is over
Are you<br>
>>>>> ready for the new Internet ? <a href="http://www.theipv6company.com" rel="noreferrer" target="_blank">http://www.theipv6company.com</a>
The IPv6<br>
>>>>> Company<br>
>>>>><br>
>>>>> This electronic message contains
information which may be privileged<br>
>>>>> or confidential. The information is
intended to be for the exclusive<br>
>>>>> use of the individual(s) named above and
further non-explicilty<br>
>>>>> authorized disclosure, copying,
distribution or use of the contents<br>
>>>>> of this information, even if partially,
including attached files, is<br>
>>>>> strictly prohibited and will be
considered a criminal offense. If<br>
>>>>> you are not the intended recipient be
aware that any disclosure,<br>
>>>>> copying, distribution or use of the
contents of this information,<br>
>>>>> even if partially, including attached
files, is strictly prohibited,<br>
>>>>> will be considered a criminal offense, so
you must reply to the<br>
>>>>> original sender to inform about this
communication and delete it.<br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>> Links:<br>
>>>>> ------<br>
>>>>> [1] <a href="https://lists.afrinic.net/pipermail/rpd/2020/011335.html" rel="noreferrer" target="_blank">https://lists.afrinic.net/pipermail/rpd/2020/011335.html</a><br>
>>>>> [2] <a href="https://lists.afrinic.net/pipermail/rpd/2020/011348.html" rel="noreferrer" target="_blank">https://lists.afrinic.net/pipermail/rpd/2020/011348.html</a><br>
>>>> ------- End of forwarded message -------<br>
>>>><br>
>>>>
<-><prepared-35.zip><->_______________________________________________<br>
>>>> RPD mailing list<br>
>>>> <a href="mailto:RPD@afrinic.net" target="_blank">RPD@afrinic.net</a><br>
>>>> <a href="https://lists.afrinic.net/mailman/listinfo/rpd" rel="noreferrer" target="_blank">https://lists.afrinic.net/mailman/listinfo/rpd</a><br>
>>> _______________________________________________<br>
>>> RPD mailing list<br>
>>> <a href="mailto:RPD@afrinic.net" target="_blank">RPD@afrinic.net</a><br>
>>> <a href="https://lists.afrinic.net/mailman/listinfo/rpd" rel="noreferrer" target="_blank">https://lists.afrinic.net/mailman/listinfo/rpd</a><br>
>> _______________________________________________<br>
>> RPD mailing list<br>
>> <a href="mailto:RPD@afrinic.net" target="_blank">RPD@afrinic.net</a><br>
>> <a href="https://lists.afrinic.net/mailman/listinfo/rpd" rel="noreferrer" target="_blank">https://lists.afrinic.net/mailman/listinfo/rpd</a><br>
<br>
<br>
_______________________________________________<br>
RPD mailing list<br>
<a href="mailto:RPD@afrinic.net" target="_blank">RPD@afrinic.net</a><br>
<a href="https://lists.afrinic.net/mailman/listinfo/rpd" rel="noreferrer" target="_blank">https://lists.afrinic.net/mailman/listinfo/rpd</a><br>
</blockquote>
</div>
</blockquote>
</div>
_______________________________________________<br>
RPD mailing list<br>
<a href="mailto:RPD@afrinic.net" target="_blank">RPD@afrinic.net</a><br>
<a href="https://lists.afrinic.net/mailman/listinfo/rpd" rel="noreferrer" target="_blank">https://lists.afrinic.net/mailman/listinfo/rpd</a><br>
</blockquote></div></div>