<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hello Anthony</p>
<p>I fully understand your reasoning below and is well written and
explained, however I doubt that main reasons some rejected this
proposal was to 'avoid the RIR going into routing area'.<br>
RPKI in this context serves only to protect the resources
allocated to the RIR which are not yet allocated to any
organization which is pretty obvious as nobody should be using
these resources without they being registered in the RIR's
database (not sure if anyone would ever defend the contrary). In
other others serves to protect the main propose of the RIR and
make sure that what is registered in its database is accurate to
the reality.</p>
<p>Best regards<br>
Fernando<br>
</p>
<div class="moz-cite-prefix">On 27/01/2021 11:47, Anthony Ubah
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAHcb0ATzeB3DHJqr9qV6fDKdWFUSoEmCSx9UDhy4uAFCGPx++g@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div dir="ltr">Hello Jordi,
<div><br clear="all">
<div>
<div dir="ltr" data-smartmail="gmail_signature">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">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>
<p style="line-height:150%"><b
style="line-height:150%;font-size:12.8px"><span
style="line-height:150%"><span
style="font-size:small;font-weight:normal">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.</span></span></b></p>
<p style="line-height:150%"><b
style="line-height:150%;font-size:12.8px"><span
style="line-height:150%"><font
face="garamond, serif"><br>
</font></span></b></p>
<p style="line-height:150%"><b
style="line-height:150%;font-size:12.8px"><span
style="line-height:150%"><font
face="garamond, serif">Best Regards,</font></span></b></p>
<p style="line-height:150%"><font face="garamond,
serif"><b
style="line-height:150%;font-size:12.8px"><span
style="line-height:150%">UBAH ANTHONY </span></b></font></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Tue, Jan 26, 2021 at 4:49
PM <<a href="mailto:rpd-request@afrinic.net"
target="_blank" moz-do-not-send="true">rpd-request@afrinic.net</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">Send RPD mailing list
submissions to<br>
<a href="mailto:rpd@afrinic.net" 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" 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"
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"
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" target="_blank"
moz-do-not-send="true">jordi.palet@consulintel.es</a>><br>
To: <<a href="mailto:rpd@afrinic.net" 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"
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" 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" 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" 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" 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" 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" 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" target="_blank"
moz-do-not-send="true">RPD@afrinic.net</a> <a
href="https://lists.afrinic.net/mailman/listinfo/rpd"
rel="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"
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" target="_blank"
moz-do-not-send="true">RPD@afrinic.net</a><br>
<a href="https://lists.afrinic.net/mailman/listinfo/rpd"
rel="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" target="_blank"
moz-do-not-send="true">RPD@afrinic.net</a> <a
href="https://lists.afrinic.net/mailman/listinfo/rpd"
rel="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"
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" 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" target="_blank"
moz-do-not-send="true">RPD@afrinic.net</a><br>
<a href="https://lists.afrinic.net/mailman/listinfo/rpd"
rel="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>
</blockquote>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
RPD mailing list
<a class="moz-txt-link-abbreviated" href="mailto:RPD@afrinic.net">RPD@afrinic.net</a>
<a class="moz-txt-link-freetext" href="https://lists.afrinic.net/mailman/listinfo/rpd">https://lists.afrinic.net/mailman/listinfo/rpd</a>
</pre>
</blockquote>
</body>
</html>