<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hello Jordi</p>
<p>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.</p>
<p>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>
</p>
<p>Regards<br>
Fernando<br>
</p>
<div class="moz-cite-prefix">On 26/01/2021 07:50, JORDI PALET
MARTINEZ via RPD wrote:<br>
</div>
<blockquote type="cite"
cite="mid:BCC06141-A765-4D66-A445-E5D72D909832@consulintel.es">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta name="Generator" content="Microsoft Word 15 (filtered
medium)">
<style>@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}@font-face
{font-family:"Times New Roman \(Cuerpo en alfa";
panose-1:2 2 6 3 5 4 5 2 3 4;}p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}span.EstiloCorreo18
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}div.WordSection1
{page:WordSection1;}ol
{margin-bottom:0cm;}ul
{margin-bottom:0cm;}</style>
<div class="WordSection1">
<p class="MsoNormal"><span
style="font-size:12.0pt;mso-fareast-language:EN-US"
lang="EN-US">Hi Wafa, all,<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:12.0pt;mso-fareast-language:EN-US"
lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:12.0pt;mso-fareast-language:EN-US"
lang="EN-US">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:12.0pt;mso-fareast-language:EN-US"
lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:12.0pt;mso-fareast-language:EN-US"
lang="EN-US">Your judgment must be on the grounds of a
correct decision of the chairs.<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:12.0pt;mso-fareast-language:EN-US"
lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:12.0pt;mso-fareast-language:EN-US"
lang="EN-US">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 *<b>are real</b>*, not just “illusions” or “lack
of knowledge” or “untrue” or “personal preferences”.<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:12.0pt;mso-fareast-language:EN-US"
lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:12.0pt;mso-fareast-language:EN-US"
lang="EN-US">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:12.0pt;mso-fareast-language:EN-US"
lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:12.0pt;mso-fareast-language:EN-US"
lang="EN-US">Any objection to a policy proposal must be duly
justified and that justification not addressed by the
authors or other community members.<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:12.0pt;mso-fareast-language:EN-US"
lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:12.0pt;mso-fareast-language:EN-US"
lang="EN-US">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:12.0pt;mso-fareast-language:EN-US"
lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:12.0pt;mso-fareast-language:EN-US"
lang="EN-US">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 *<b>technically correct choice</b>* for the
community.<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:12.0pt;mso-fareast-language:EN-US"
lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:12.0pt;mso-fareast-language:EN-US"
lang="EN-US">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 *<b>demonstrate
with facts why</b>* and this must be done using the
responses provided by the authors and community to those
objections.<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:12.0pt;mso-fareast-language:EN-US"
lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:12.0pt;mso-fareast-language:EN-US"
lang="EN-US">If 3 members of the Appeal Committee believe
that any of the objections has not been addressed, they need
to *<b>demonstrate why</b>*, taking in consideration the
community and author responses, and those must be crystal
clear in the report, which is not the case.<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:12.0pt;mso-fareast-language:EN-US"
lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:12.0pt;mso-fareast-language:EN-US"
lang="EN-US">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:12.0pt;mso-fareast-language:EN-US"
lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:12.0pt;mso-fareast-language:EN-US"
lang="EN-US">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:<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:12.0pt;mso-fareast-language:EN-US"
lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:12.0pt;mso-fareast-language:EN-US"
lang="EN-US">“</span><span lang="EN-US">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.</span><span
style="font-size:12.0pt;mso-fareast-language:EN-US"
lang="EN-US">”<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:12.0pt;mso-fareast-language:EN-US"
lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:12.0pt;mso-fareast-language:EN-US"
lang="EN-US">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.</span><span
lang="EN-US"><o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:12.0pt;mso-fareast-language:EN-US"
lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:12.0pt;mso-fareast-language:EN-US"
lang="EN-US">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:<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:12.0pt;mso-fareast-language:EN-US"
lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"
style="margin-left:39.6pt;text-indent:-21.6pt;mso-list:l0
level2 lfo1"><!--[if !supportLists]--><span
style="font-size:12.0pt;font-family:"Arial",sans-serif;color:black"
lang="EN-US"><span style="mso-list:Ignore">2.1.<span
style="font:7.0pt "Times New Roman""> </span></span></span><!--[endif]--><span
style="font-family:"Arial",sans-serif;color:#00B0F0"
lang="EN-US">“a. Allowing resource holders to create AS0/
ROA will lead to an increase of even more invalid prefixes
in the routing table”</span><span
style="font-size:12.0pt;font-family:"Arial",sans-serif;color:black"
lang="EN-US"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:39.6pt"><span
style="font-family:"Arial",sans-serif;color:black"
lang="EN-US">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 <b>can’t be a valid objection for the
policy proposal</b>.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span
style="font-family:"Arial",sans-serif;color:black"
lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"
style="margin-left:39.6pt;text-indent:-21.6pt;mso-list:l0
level2 lfo1"><!--[if !supportLists]--><span
style="font-family:"Arial",sans-serif;color:black"
lang="EN-US"><span style="mso-list:Ignore">2.2.<span
style="font:7.0pt "Times New Roman""> </span></span></span><!--[endif]--><span
style="font-family:"Arial",sans-serif;color:#00B0F0"
lang="EN-US">“b. Revocation time of AS0 state, and the time
for new allocation doesn’t match”</span><span
style="font-family:"Arial",sans-serif;color:black"
lang="EN-US"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:39.6pt"><span
style="font-family:"Arial",sans-serif;color:black"
lang="EN-US">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.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:39.6pt"><span
style="font-family:"Arial",sans-serif;color:black"
lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:39.6pt"><span
style="font-family:"Arial",sans-serif;color:black"
lang="EN-US">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.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:39.6pt"><span
style="font-family:"Arial",sans-serif;color:black"
lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:39.6pt"><span
style="font-family:"Arial",sans-serif;color:black"
lang="EN-US">The conclusion is that there is no such
“matching”, neither “unmatching”, so this <b>can’t be taken
as a valid objection for the proposal</b>.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span
style="font-family:"Arial",sans-serif;color:black"
lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"
style="margin-left:39.6pt;text-indent:-21.6pt;mso-list:l0
level2 lfo1"><!--[if !supportLists]--><span
style="font-family:"Arial",sans-serif;color:black"
lang="EN-US"><span style="mso-list:Ignore">2.3.<span
style="font:7.0pt "Times New Roman""> </span></span></span><!--[endif]--><span
style="font-family:"Arial",sans-serif;color:#00B0F0"
lang="EN-US">“c. Other RIRs don’t have a similar the policy
therefore, it can not be effective”</span><span
style="font-family:"Arial",sans-serif;color:black"
lang="EN-US"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:39.6pt"><span
style="font-family:"Arial",sans-serif;color:black"
lang="EN-US">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.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:39.6pt"><span
style="font-family:"Arial",sans-serif;color:black"
lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:39.6pt"><span
style="font-family:"Arial",sans-serif;color:black"
lang="EN-US">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”.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:39.6pt"><span
style="font-family:"Arial",sans-serif;color:black"
lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:39.6pt"><span
style="font-family:"Arial",sans-serif;color:black"
lang="EN-US">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 <b>can’t be taken as a valid objection
against this policy proposal</b>.<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-family:"Arial",sans-serif"
lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"
style="margin-left:39.6pt;text-indent:-21.6pt;mso-list:l0
level2 lfo1"><!--[if !supportLists]--><span
style="font-family:"Arial",sans-serif;color:black"
lang="EN-US"><span style="mso-list:Ignore">2.4.<span
style="font:7.0pt "Times New Roman""> </span></span></span><!--[endif]--><span
style="font-family:"Arial",sans-serif;color:#00B0F0"
lang="EN-US">“d. This will become a uniform policy if it is
not globally implemented, which causes additional stress“</span><span
style="font-family:"Arial",sans-serif;color:black"
lang="EN-US"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:39.6pt"><span
style="font-family:"Arial",sans-serif;color:black"
lang="EN-US">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 <b>can’t be taken as a
valid objection against this policy proposal</b>.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:39.6pt"><span
style="font-family:"Arial",sans-serif;color:black"
lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:39.6pt"><span
style="font-family:"Arial",sans-serif;color:black"
lang="EN-US">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, <b>not a valid objection</b>.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:39.6pt"><span
style="font-family:"Arial",sans-serif;color:black"
lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:39.6pt"><span
style="font-family:"Arial",sans-serif;color:black"
lang="EN-US">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 <b>not a valid objection</b>.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span
style="font-family:"Arial",sans-serif;color:black"
lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"
style="margin-left:39.6pt;text-indent:-21.6pt;mso-list:l0
level2 lfo1"><!--[if !supportLists]--><span
style="font-family:"Arial",sans-serif;color:black"
lang="EN-US"><span style="mso-list:Ignore">2.5.<span
style="font:7.0pt "Times New Roman""> </span></span></span><!--[endif]--><span
style="font-family:"Arial",sans-serif;color:#00B0F0"
lang="EN-US">“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?”</span><span
style="font-family:"Arial",sans-serif;color:black"
lang="EN-US"> <o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:39.6pt"><span
style="font-family:"Arial",sans-serif;color:black"
lang="EN-US">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. </span><span
style="font-family:"Arial",sans-serif;color:black">Once
more, <b>not a valid objection</b>.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:39.6pt"><span
style="font-family:"Arial",sans-serif;color:black"><o:p> </o:p></span></p>
<p class="MsoNormal"
style="margin-left:39.6pt;text-indent:-21.6pt;mso-list:l0
level2 lfo1"><!--[if !supportLists]--><span
style="font-family:"Arial",sans-serif;color:black"
lang="EN-US"><span style="mso-list:Ignore">2.6.<span
style="font:7.0pt "Times New Roman""> </span></span></span><!--[endif]--><span
style="font-family:"Arial",sans-serif;color:#00B0F0"
lang="EN-US">“f. How do we revoke the ROA? How long does it
take to revoke it (chain/ refreshing )?”</span><span
style="font-family:"Arial",sans-serif;color:black"
lang="EN-US"> <o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:39.6pt"><span
style="font-family:"Arial",sans-serif;color:black"
lang="EN-US">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:<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:39.6pt"><a
href="https://lists.afrinic.net/pipermail/rpd/2020/011335.html"
moz-do-not-send="true"><span
style="font-family:"Arial",sans-serif"
lang="EN-US">https://lists.afrinic.net/pipermail/rpd/2020/011335.html</span></a><span
style="font-family:"Arial",sans-serif;color:black"
lang="EN-US"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:39.6pt"><a
href="https://lists.afrinic.net/pipermail/rpd/2020/011348.html"
moz-do-not-send="true"><span
style="font-family:"Arial",sans-serif"
lang="EN-US">https://lists.afrinic.net/pipermail/rpd/2020/011348.html</span></a><span
style="font-family:"Arial",sans-serif;color:black"
lang="EN-US"><o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-family:"Arial",sans-serif;color:black"
lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"
style="margin-left:39.6pt;text-indent:-21.6pt;mso-list:l0
level2 lfo1"><!--[if !supportLists]--><span
style="font-family:"Arial",sans-serif;color:black"
lang="EN-US"><span style="mso-list:Ignore">2.7.<span
style="font:7.0pt "Times New Roman""> </span></span></span><!--[endif]--><span
style="font-family:"Arial",sans-serif;color:#00B0F0"
lang="EN-US">“g. What happens if AFRINIC accidentally issues
a ROA for an address in error?”</span><span
style="font-family:"Arial",sans-serif;color:black"
lang="EN-US"> <o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:39.6pt"><span
style="font-family:"Arial",sans-serif;color:black"
lang="EN-US">What happens if AFRINIC accidentally issues a
ROA without an address already allocated to members?<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:39.6pt"><span
style="font-family:"Arial",sans-serif;color:black"
lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:39.6pt"><span
style="font-family:"Arial",sans-serif;color:black"
lang="EN-US">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.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:39.6pt"><span
style="font-family:"Arial",sans-serif;color:black"
lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:39.6pt"><span
style="font-family:"Arial",sans-serif;color:black"
lang="EN-US">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.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:39.6pt"><span
style="font-family:"Arial",sans-serif;color:black"
lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:39.6pt"><span
style="font-family:"Arial",sans-serif;color:black"
lang="EN-US">This proposal doesn't change that, it is
provided as an opt-in service and consequently it is <b>not
a valid objection</b>.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:39.6pt"><span
style="font-family:"Arial",sans-serif;color:black"
lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"
style="margin-left:39.6pt;text-indent:-21.6pt;mso-list:l0
level2 lfo1"><!--[if !supportLists]--><span
style="font-family:"Arial",sans-serif;color:black"
lang="EN-US"><span style="mso-list:Ignore">2.8.<span
style="font:7.0pt "Times New Roman""> </span></span></span><!--[endif]--><span
style="font-family:"Arial",sans-serif;color:#00B0F0"
lang="EN-US">“h. It also might affect the neighbours and
involves monitoring of unallocated spaces”</span><span
style="font-family:"Arial",sans-serif;color:black"
lang="EN-US"> <o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:39.6pt"><span
style="font-family:"Arial",sans-serif;color:black"
lang="EN-US">It is not clear if neighbours here is referring
to BGP peering ones.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:39.6pt"><span
style="font-family:"Arial",sans-serif;color:black"
lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:39.6pt"><span
style="font-family:"Arial",sans-serif;color:black"
lang="EN-US">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.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:39.6pt"><span
style="font-family:"Arial",sans-serif;color:black"
lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:39.6pt"><span
style="font-family:"Arial",sans-serif;color:black"
lang="EN-US">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.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:39.6pt"><span
style="font-family:"Arial",sans-serif;color:black"
lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:39.6pt"><span
style="font-family:"Arial",sans-serif;color:black"
lang="EN-US">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 <b>can’t be
considered a valid objection</b>.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:39.6pt"><span
style="font-family:"Arial",sans-serif;color:black"
lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"
style="margin-left:39.6pt;text-indent:-21.6pt;mso-list:l0
level2 lfo1"><!--[if !supportLists]--><span
style="font-family:"Arial",sans-serif;color:black"
lang="EN-US"><span style="mso-list:Ignore">2.9.<span
style="font:7.0pt "Times New Roman""> </span></span></span><!--[endif]--><span
style="font-family:"Arial",sans-serif;color:#00B0F0"
lang="EN-US">“i. Possibility of it being used against a
member who is yet to pay dues”</span><span
style="font-family:"Arial",sans-serif;color:black"
lang="EN-US"> <o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:39.6pt"><span
style="font-family:"Arial",sans-serif;color:black"
lang="EN-US">According to AFRINIC bylaws and RSA, AFRINIC
has the <b>obligation</b> to avoid members not paying to
stop using the resources, so they are available to other
members.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:39.6pt"><span
style="font-family:"Arial",sans-serif;color:black"
lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:39.6pt"><span
style="font-family:"Arial",sans-serif;color:black"
lang="EN-US">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.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:39.6pt"><span
style="font-family:"Arial",sans-serif;color:black"
lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:39.6pt"><span
style="font-family:"Arial",sans-serif;color:black"
lang="EN-US">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.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:39.6pt"><span
style="font-family:"Arial",sans-serif;color:black"
lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:39.6pt"><span
style="font-family:"Arial",sans-serif;color:black"
lang="EN-US">Clearly, once more, this <b>can’t be
considered a valid objection, on the other way around is a
fundamental AFRINIC’s right and duty</b>.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:39.6pt"><span
style="font-family:"Arial",sans-serif;color:black"
lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:12.0pt;mso-fareast-language:EN-US"
lang="EN-US">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:12.0pt;mso-fareast-language:EN-US"
lang="EN-US"><o:p> </o:p></span></p>
<div>
<p class="MsoNormal"><span
style="font-size:12.0pt;color:black" lang="EN-US">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:12.0pt;color:black" lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:12.0pt;color:black" lang="EN-US">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:12.0pt;color:black" lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:12.0pt;color:black" lang="EN-US">Regards,<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span
style="font-size:12.0pt;color:black;mso-fareast-language:EN-US"
lang="EN-US">Jordi<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span
style="font-size:12.0pt;color:black;mso-fareast-language:EN-US"
lang="EN-US">@jordipalet<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span
style="font-size:12.0pt;color:black;mso-fareast-language:EN-US"
lang="EN-US"><o:p> </o:p></span></p>
</div>
<p class="MsoNormal"><span
style="font-size:12.0pt;mso-fareast-language:EN-US"
lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:12.0pt;mso-fareast-language:EN-US"
lang="EN-US"><o:p> </o:p></span></p>
<div>
<div>
<p class="MsoNormal" style="margin-left:35.4pt">El 22/1/21
13:59, "wafa Dahmani" <<a
href="mailto:wafatn7604@gmail.com"
moz-do-not-send="true">wafatn7604@gmail.com</a>>
escribió:<o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal" style="margin-left:35.4pt"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:35.4pt">Dear
Community,<o:p></o:p></p>
<div>
<p class="MsoNormal" style="margin-left:35.4pt"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:35.4pt">This is to
inform you that the Report on <span
style="font-size:12.0pt;font-family:"Times New
Roman",serif">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:</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:35.4pt"><o:p> </o:p></p>
</div>
<div>
<div>
<p class="MsoNormal" style="margin-left:35.4pt"><a
href="https://afrinic.net/ast/pdf/policy/20210121-rpki-roa-appeal-report.pdf"
target="_blank" moz-do-not-send="true">https://afrinic.net/ast/pdf/policy/20210121-rpki-roa-appeal-report.pdf</a><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:35.4pt"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:35.4pt"><a
href="https://afrinic.net/policy/appeal-committee#appeals"
target="_blank" moz-do-not-send="true">https://afrinic.net/policy/appeal-committee#appeals</a><o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal" style="margin-left:35.4pt"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:35.4pt"><span
style="font-size:12.0pt;font-family:"Times New
Roman",serif">Best Regards</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:35.4pt"><span
style="font-size:12.0pt;font-family:"Times New
Roman",serif">Wafa Dahmani</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:35.4pt"><span
style="font-size:12.0pt;font-family:"Times New
Roman",serif">Chair of the Appeal Committee</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:35.4pt"><o:p> </o:p></p>
</div>
</div>
<p class="MsoNormal" style="margin-left:35.4pt">_______________________________________________
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> <o:p></o:p></p>
</div>
<br>
**********************************************<br>
IPv4 is over<br>
Are you ready for the new Internet ?<br>
<a class="moz-txt-link-freetext" href="http://www.theipv6company.com">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>
<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>