<div dir="auto">Dear all, <div dir="auto"><br></div><div dir="auto">In my opinion, this new policy proposal is not necessary because the Resource Transfer Policy would already support a bi-directional inter-RIR Transfer Policy which is capable of encouraging growth and smooth business operations within in the region.</div><div dir="auto"><br></div><div dir="auto">Cheers</div><div dir="auto"><div data-smartmail="gmail_signature" dir="auto">Emem William<br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Sep 17, 2020, 11:17 Ahile shagba francis <<a href="mailto:ahilefranc@gmail.com">ahilefranc@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div dir="auto">Lets look at it from another point,</div><div dir="auto">If it is the other region’s policy to be applied when the resources are transferred from that region, it is then glaring that this could cause many confusions.</div><div dir="auto">We don't need to support such.</div><div dir="auto">Let's be guided.</div><div dir="auto"><br></div><div dir="auto"><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Sep 17, 2020, 10:25 AM <<a href="mailto:rpd-request@afrinic.net" target="_blank" rel="noreferrer">rpd-request@afrinic.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Send RPD mailing list submissions to<br>
<a href="mailto:rpd@afrinic.net" rel="noreferrer noreferrer" target="_blank">rpd@afrinic.net</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="https://lists.afrinic.net/mailman/listinfo/rpd" rel="noreferrer noreferrer noreferrer" target="_blank">https://lists.afrinic.net/mailman/listinfo/rpd</a><br>
or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:rpd-request@afrinic.net" rel="noreferrer noreferrer" target="_blank">rpd-request@afrinic.net</a><br>
<br>
You can reach the person managing the list at<br>
<a href="mailto:rpd-owner@afrinic.net" rel="noreferrer noreferrer" target="_blank">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: RPKI ROAs for Unallocated and Unassigned AFRINIC Address<br>
Space AFPUB-2019-GEN-006-DRAFT02 (Ben Maddison)<br>
2. Re: RPKI ROAs for Unallocated and Unassigned AFRINIC Address<br>
Space AFPUB-2019-GEN-006-DRAFT02 (Patrick Okui)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Thu, 17 Sep 2020 11:08:16 +0200<br>
From: Ben Maddison <benm@workonline.africa><br>
To: Mark Elkins <<a href="mailto:mje@posix.co.za" rel="noreferrer noreferrer" target="_blank">mje@posix.co.za</a>><br>
Cc: Marius Andioc via RPD <<a href="mailto:rpd@afrinic.net" rel="noreferrer noreferrer" target="_blank">rpd@afrinic.net</a>><br>
Subject: Re: [rpd] RPKI ROAs for Unallocated and Unassigned AFRINIC<br>
Address Space AFPUB-2019-GEN-006-DRAFT02<br>
Message-ID: <20200917090816.nwkt44vwwjaun6wo@benm-laptop><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Hi all,<br>
<br>
I am currently undecided on this policy.<br>
As others have pointed out, the objections to the proposal on the basis<br>
of centralization of control are bogus: the current policy does not add<br>
any additional control over the routing system beyond that which AFRINIC<br>
already has as the result of RPKI origin validation deployment today.<br>
<br>
I agree with the fundamental basis of the proposal that:<br>
a) it is generally undesirable to route traffic for bogon destinations;<br>
and<br>
b) the RPKI is the best fit we have to securely communicate what is and<br>
isn't a bogon to relying parties in order to implement the necessary<br>
routing policy.<br>
<br>
However, it is also the case that the consequences (in terms of service<br>
availability for end users) of a de-registration would be substantially<br>
greater if the de-registration is accompanied by the issuance of an AS0<br>
ROA for that address space.<br>
<br>
This is true for the following reasons:<br>
- Non-RIR managed IRR databases exist that allow the creation of<br>
route(6) objects that are not covered by an RIR allocation<br>
- Many networks do not filter by prefix based on IRR data at all<br>
- Those that do generally do not filter their transits by prefix<br>
- Transit-free networks generally do not filter their peers (or at least<br>
their transit-free peers) by prefix<br>
<br>
Thus, today, a de-registration probably results in a partial outage that<br>
can be worked-around, rather than a near-total outage that cannot.<br>
This is either a feature or a bug in the policy, depending on your point<br>
of view regarding a specific de-registration case!<br>
<br>
I would suggest the following modifications, in order to alleviate some<br>
of the risks inherent in the current draft:<br>
1. The automatic creation of AS0 ROAs should be limited to space that<br>
has never been allocated by an RIR or part of a legacy allocation.<br>
2. AFRINIC should require the explicit consent of the previous holder<br>
to issue AS0 ROAs in respect of re-claimed, returned, etc, space.<br>
3. Any ROAs issued under this policy should be issued and published in<br>
a way that makes it operationally easy for an relying party to<br>
ignore them (probably by issuing under a separate TA)<br>
<br>
With the above amendments I would be inclined to support the proposal.<br>
<br>
Cheers,<br>
<br>
Ben<br>
<br>
On 09/17, Mark Elkins wrote:<br>
> I support the RPKI ROA policy as written. I understand the technical aspects<br>
> of the policy. I have a feeling that those objecting may not completely<br>
> understand the technical aspects which is why they are objecting.<br>
> <br>
> AFRINIC's job is to properly document the resources they have been provided<br>
> by ICANN/IANA and this is simply part of the job. When new resources are<br>
> provided to AFRINIC, they label it as such (AS0, etc). When it is then<br>
> allocated/assigned to a member, the AS0 RPKI is removed. All this means is<br>
> that the unallocated/unassigned resources that are with AFRINIC can be<br>
> (optionally) identified as such and thus can not be easily misused by bad<br>
> actors. This also means that when they are allocated/assigned to members,<br>
> they are less lightly to have been made "dirty".<br>
> <br>
> On 2020/09/17 08:26, Ibeanusi Elvis wrote:<br>
> > Dear all,<br>
> > <br>
> > The AFRINIC as an organization specifically focuses?on the registration<br>
> > database and thereby?having knowledge of where the prefix belongs to and<br>
> > AFRINIC should just focus on this role and should not engage?in<br>
> > authenticating or the authorization of various services. If such rights<br>
> > are given to any organization, they have?the right to assign prefixes to<br>
> > servers hence, having?control of the routing database at which a<br>
> > technical or human error will lead to an immense catastrophe to the<br>
> > internet society. This control is basically the specific definition of<br>
> > centralization. This centralization is the major reason why most<br>
> > providers do not trust the Resource Public Key Infrastructure (RPKI). I<br>
> > am still in opposition to this policy proposal.<br>
> > <br>
> > Elvis.<br>
> > <br>
> > On Thu, Sep 17, 2020 at 3:01 PM Darwin Costa <<a href="mailto:dc@darwincosta.com" rel="noreferrer noreferrer" target="_blank">dc@darwincosta.com</a><br>
> > <mailto:<a href="mailto:dc@darwincosta.com" rel="noreferrer noreferrer" target="_blank">dc@darwincosta.com</a>>> wrote:<br>
> > <br>
> > Cmon folks?.!<br>
> > <br>
> > @Elvis, I really don?t see your point here and also don?t really<br>
> > understand why are you opposing against this proposal.<br>
> > <br>
> > As mentioned further on the thread - RPKI won?t change Afrnic?s<br>
> > role at all?. Instead this proposal will certainly contribute to a<br>
> > more secure routing advertisement.<br>
> > <br>
> > As such, other RIR?s have successfully implemented this in order<br>
> > to protect our garden so called ?The Internet?.<br>
> > <br>
> > Darwin-.<br>
> > <br>
> > <br>
> > <br>
> > > On 17 Sep 2020, at 05:42, Fernando Frediani <<a href="mailto:fhfrediani@gmail.com" rel="noreferrer noreferrer" target="_blank">fhfrediani@gmail.com</a><br>
> > > <mailto:<a href="mailto:fhfrediani@gmail.com" rel="noreferrer noreferrer" target="_blank">fhfrediani@gmail.com</a>>> wrote:<br>
> > > <br>
> > > I think there is a serious issue by some people totally<br>
> > > misunderstanding what RPKI actually is.<br>
> > > <br>
> > > Some arguments saying something like 'Afrinic will centralize<br>
> > > control of the internet and should not have such power' don't<br>
> > > have relation to what what this proposal intends and the reasons<br>
> > > to oppose it are not tied to real possible problems pointed.<br>
> > > <br>
> > > This proposal only follows what have been done in APNIC and<br>
> > > LACNIC and is a natural move to make an internet more secure and<br>
> > > avoid organizations to use space that is not assigned to anyone else.<br>
> > > Therefore I support this proposal.<br>
> > > <br>
> > > Fernando<br>
> > > <br>
> > > On 16/09/2020 20:42, Noah wrote:<br>
> > > > <br>
> > > > On Thu, Sep 17, 2020 at 2:30 AM Ibeanusi Elvis<br>
> > > > <<a href="mailto:ibeanusielvis@gmail.com" rel="noreferrer noreferrer" target="_blank">ibeanusielvis@gmail.com</a> <mailto:<a href="mailto:ibeanusielvis@gmail.com" rel="noreferrer noreferrer" target="_blank">ibeanusielvis@gmail.com</a>>> wrote:<br>
> > > > <br>
> > > > <br>
> > > > I am strongly in opposition to this RPKI ROA proposal,<br>
> > > > <br>
> > > > <br>
> > > > You oppose yet....<br>
> > > > <br>
> > > > ?issuing an AS0 for AFRINIC address space<br>
> > > > <br>
> > > > <br>
> > > > You must be clear on which AFRINIC address space rather than<br>
> > > > presenting a rather vague statement.<br>
> > > > <br>
> > > > The proposal is very clear and explicit and the AFRINIC space in<br>
> > > > question is that which has not yet been allocated or assigned to<br>
> > > > any entity or resource member.<br>
> > > > <br>
> > > > I will quote for you section 2.0 of the proposal as written below;<br>
> > > > <br>
> > > > *2.0 Summary of how this proposal addresses the problem*<br>
> > > > *<br>
> > > > *This proposal instructs AFRINIC to create ROAs for all<br>
> > > > *unallocated and unassigned address space under its control.*<br>
> > > > This will enable networks performing RPKI-based BGP Origin<br>
> > > > Validation to easily reject all the bogon announcements covering<br>
> > > > resources managed by AFRINIC.<br>
> > > > <br>
> > > > So what are you talking about?<br>
> > > > <br>
> > > > Noah<br>
> > > > <br>
> > > > _______________________________________________<br>
> > > > RPD mailing list<br>
> > > > <a href="mailto:RPD@afrinic.net" rel="noreferrer noreferrer" target="_blank">RPD@afrinic.net</a> <mailto:<a href="mailto:RPD@afrinic.net" rel="noreferrer noreferrer" target="_blank">RPD@afrinic.net</a>><br>
> > > > <a href="https://lists.afrinic.net/mailman/listinfo/rpd" rel="noreferrer noreferrer noreferrer" target="_blank">https://lists.afrinic.net/mailman/listinfo/rpd</a> <<a href="https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.afrinic.net%2Fmailman%2Flistinfo%2Frpd&data=02%7C01%7C%7Ca48324a7026842948aff08d85abbfbd8%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637359110720490840&sdata=mOjgUTIarKfPnsD2h0TtixnR51E4wzIwqoo6rONHW%2FI%3D&reserved=0" rel="noreferrer noreferrer noreferrer" target="_blank">https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.afrinic.net%2Fmailman%2Flistinfo%2Frpd&data=02%7C01%7C%7Ca48324a7026842948aff08d85abbfbd8%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637359110720490840&sdata=mOjgUTIarKfPnsD2h0TtixnR51E4wzIwqoo6rONHW%2FI%3D&reserved=0</a>><br>
> > > _______________________________________________<br>
> > > RPD mailing list<br>
> > > <a href="mailto:RPD@afrinic.net" rel="noreferrer noreferrer" target="_blank">RPD@afrinic.net</a> <mailto:<a href="mailto:RPD@afrinic.net" rel="noreferrer noreferrer" target="_blank">RPD@afrinic.net</a>><br>
> > > <a href="https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.afrinic.net%2Fmailman%2Flistinfo%2Frpd&data=02%7C01%7C%7Ca48324a7026842948aff08d85abbfbd8%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637359110720510827&sdata=jlnsXCK7dATX4Jcg48%2BhurUnj1E5umTa2RZq7IMsb%2Fs%3D&reserved=0" rel="noreferrer noreferrer noreferrer" target="_blank">https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.afrinic.net%2Fmailman%2Flistinfo%2Frpd&data=02%7C01%7C%7Ca48324a7026842948aff08d85abbfbd8%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637359110720510827&sdata=jlnsXCK7dATX4Jcg48%2BhurUnj1E5umTa2RZq7IMsb%2Fs%3D&reserved=0</a><br>
> > <br>
> > _______________________________________________<br>
> > RPD mailing list<br>
> > <a href="mailto:RPD@afrinic.net" rel="noreferrer noreferrer" target="_blank">RPD@afrinic.net</a> <mailto:<a href="mailto:RPD@afrinic.net" rel="noreferrer noreferrer" target="_blank">RPD@afrinic.net</a>><br>
> > <a href="https://lists.afrinic.net/mailman/listinfo/rpd" rel="noreferrer noreferrer 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" rel="noreferrer noreferrer" target="_blank">RPD@afrinic.net</a><br>
> > <a href="https://lists.afrinic.net/mailman/listinfo/rpd" rel="noreferrer noreferrer noreferrer" target="_blank">https://lists.afrinic.net/mailman/listinfo/rpd</a><br>
> -- <br>
> <br>
> Mark James ELKINS? -? Posix Systems - (South) Africa<br>
> <a href="http://mje@posix.co.za????" rel="noreferrer noreferrer noreferrer" target="_blank">mje@posix.co.za????</a>?? Tel: +27.826010496 <tel:+27826010496><br>
> For fast, reliable, low cost Internet in ZA: <a href="https://ftth.posix.co.za" rel="noreferrer noreferrer noreferrer" target="_blank">https://ftth.posix.co.za</a><br>
> <br>
> Posix SystemsVCARD for MJ Elkins<br>
> <br>
<br>
> _______________________________________________<br>
> RPD mailing list<br>
> <a href="mailto:RPD@afrinic.net" rel="noreferrer noreferrer" target="_blank">RPD@afrinic.net</a><br>
> <a href="https://lists.afrinic.net/mailman/listinfo/rpd" rel="noreferrer noreferrer noreferrer" target="_blank">https://lists.afrinic.net/mailman/listinfo/rpd</a><br>
<br>
-------------- next part --------------<br>
A non-text attachment was scrubbed...<br>
Name: signature.asc<br>
Type: application/pgp-signature<br>
Size: 833 bytes<br>
Desc: not available<br>
URL: <<a href="https://lists.afrinic.net/pipermail/rpd/attachments/20200917/77e69095/attachment-0001.sig" rel="noreferrer noreferrer noreferrer" target="_blank">https://lists.afrinic.net/pipermail/rpd/attachments/20200917/77e69095/attachment-0001.sig</a>><br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Thu, 17 Sep 2020 12:24:06 +0300<br>
From: "Patrick Okui" <<a href="mailto:pokui@psg.com" rel="noreferrer noreferrer" target="_blank">pokui@psg.com</a>><br>
To: "Ibeanusi Elvis" <<a href="mailto:ibeanusielvis@gmail.com" rel="noreferrer noreferrer" target="_blank">ibeanusielvis@gmail.com</a>><br>
Cc: Marius Andioc via RPD <<a href="mailto:rpd@afrinic.net" rel="noreferrer noreferrer" target="_blank">rpd@afrinic.net</a>><br>
Subject: Re: [rpd] RPKI ROAs for Unallocated and Unassigned AFRINIC<br>
Address Space AFPUB-2019-GEN-006-DRAFT02<br>
Message-ID: <<a href="mailto:91E9F948-7128-4E24-903B-2033484E1DC3@psg.com" rel="noreferrer noreferrer" target="_blank">91E9F948-7128-4E24-903B-2033484E1DC3@psg.com</a>><br>
Content-Type: text/plain; charset="utf-8"; Format="flowed"<br>
<br>
Dear Elvis,<br>
<br>
Thanks for speaking up and clarifying this viewpoint. Much as your <br>
concerns<br>
aren?t directly connected to this proposal but to RPKI in general I <br>
think<br>
they?re shared by many and worth addressing. (No I?m not one of the <br>
authors of<br>
this proposal).<br>
<br>
To have a mutual understanding (or agreement to disagree) we need to <br>
iron out a<br>
few points. Apologies for the long email that doesn?t discuss the <br>
policy<br>
itself.<br>
<br>
1. Allocation of IP addresses (and other resources) is in your words<br>
_?centralised?_. I prefer the word ?hierarchal?. I.E IANA <br>
has the global pool<br>
of IP(v4 & v6) addresses. It then hands it out to RIRs like <br>
AFRINIC. LIRS like<br>
ISPs then apply from the RIR. End users either get allocated <br>
address space out<br>
of the LIR pool or can get addresses directly from the RIR and get <br>
those<br>
routed. So, AFRINIC (and other RIRs) are not responsible to <br>
allocate IP<br>
addresses to servers, but you can?t allocate a public IP address <br>
to a server<br>
without somehow following this chain. Kindly confirm if you?re <br>
fine with this<br>
state of affairs.<br>
<br>
2. I see you?re using a gmail address and you used the web interface <br>
to compose<br>
your email. To do that your browser used SSL. The system that lets <br>
SSL work is<br>
the X509 certificate system. This is another _?centralised?_ or <br>
hierarchal<br>
system. Your browser or OS has a set of root trust information <br>
(CA?s). These<br>
CAs can create ?signatures? (crypto information) that says that <br>
a particular<br>
key XYZ is allowed to secure a domain (e.g <a href="http://gmail.com" rel="noreferrer noreferrer noreferrer" target="_blank">gmail.com</a>). They also <br>
can create<br>
signatures that say a key ABC can also create signatures like their <br>
own. In<br>
this case, gmail could chose to go to whoever runs ABC to get their <br>
X509<br>
certificate instead of to any of the roots themselves. Your browser <br>
is able to<br>
follow the chain of trust. Note that x509 aka SSL has methods by <br>
which CAs can<br>
publish crypto information that revokes previously assigned <br>
certificates if<br>
they were allocated in error. Please also confirm if this is <br>
something you?re<br>
fine with.<br>
<br>
3. RPKI technically isn?t just for ROA validation. It is just another <br>
public<br>
key infrastructure with *hierarchy* (you prefer the term <br>
centralised). It also<br>
(like x509) requires some sort of root anchor or anchors. These are <br>
what are<br>
installed in each client that wants to verify any of the crypto <br>
information in<br>
the system. This isn?t new, DNSSEC works the same way. Once you <br>
have well<br>
known/established roots each of these systems (DNSSEC, RPKI) have <br>
ways to<br>
delegate authority for some information to the holder of a <br>
different public<br>
key. And this goes down the chain. The decision of who the root <br>
anchors for<br>
RPKI was debated on public lists like these and finally at the NRO <br>
it was<br>
agreed that the easiest and cleanest solution was for all RIRs to <br>
have a root<br>
0/0 anchor. All RPKI validator clients simply have these anchors <br>
configured and<br>
can therefore validate all crypto in the RPKI system.<br>
<br>
Kindly confirm if we?re on the same page (at least via understanding) <br>
of these<br>
three long points. Effectively the RPKI system in my opinion is more<br>
trustworthy than the x509 one that secures the SSL you used to write <br>
your<br>
email. If you look at your OS/browser there are quite a number of root <br>
CAs<br>
there that given the choice I personally wouldn?t trust.<br>
<br>
Just like DNS, all these systems need hierarchy to operate. It is not <br>
logical<br>
to say you trust x509 (SSL) but not RPKI. Or that you?re fine using <br>
the<br>
internet with its allocation of IP but do not want to secure those <br>
allocations<br>
with a system that follows that same heirachy. Note that we haven?t <br>
even<br>
discussed the fact that publishing ROA information in RPKI is optional <br>
for ISPs<br>
and end users. We?re just discussing the trust hierarchy.<br>
<br>
On 17 Sep 2020, at 9:26 EAT, Ibeanusi Elvis wrote:<br>
<br>
> Dear all,<br>
><br>
> The AFRINIC as an organization specifically focuses on the <br>
> registration database and thereby having knowledge of where the prefix <br>
> belongs to and AFRINIC should just focus on this role and should not <br>
> engage in authenticating or the authorization of various services. If <br>
> such rights are given to any organization, they have the right to <br>
> assign prefixes to servers hence, having control of the routing <br>
> database at which a technical or human error will lead to an immense <br>
> catastrophe to the internet society.<br>
> This control is basically the specific definition of centralization. <br>
> This centralization is the major reason why most providers do not <br>
> trust the Resource Public Key Infrastructure (RPKI). I am still in <br>
> opposition to this policy proposal.<br>
><br>
> Elvis.<br>
><br>
> On Thu, Sep 17, 2020 at 3:01 PM Darwin Costa <<a href="mailto:dc@darwincosta.com" rel="noreferrer noreferrer" target="_blank">dc@darwincosta.com</a>> <br>
> wrote:<br>
><br>
>> Cmon folks?.!<br>
>><br>
>> @Elvis, I really don?t see your point here and also don?t really<br>
>> understand why are you opposing against this proposal.<br>
>><br>
>> As mentioned further on the thread - RPKI won?t change Afrnic?s <br>
>> role at<br>
>> all?. Instead this proposal will certainly contribute to a more <br>
>> secure<br>
>> routing advertisement.<br>
>><br>
>> As such, other RIR?s have successfully implemented this in order to<br>
>> protect our garden so called ?The Internet?.<br>
>><br>
>> Darwin-.<br>
>><br>
>><br>
>><br>
>> On 17 Sep 2020, at 05:42, Fernando Frediani <<a href="mailto:fhfrediani@gmail.com" rel="noreferrer noreferrer" target="_blank">fhfrediani@gmail.com</a>> <br>
>> wrote:<br>
>><br>
>> I think there is a serious issue by some people totally <br>
>> misunderstanding<br>
>> what RPKI actually is.<br>
>><br>
>> Some arguments saying something like 'Afrinic will centralize control <br>
>> of<br>
>> the internet and should not have such power' don't have relation to <br>
>> what<br>
>> what this proposal intends and the reasons to oppose it are not tied <br>
>> to<br>
>> real possible problems pointed.<br>
>><br>
>> This proposal only follows what have been done in APNIC and LACNIC <br>
>> and is<br>
>> a natural move to make an internet more secure and avoid <br>
>> organizations to<br>
>> use space that is not assigned to anyone else.<br>
>> Therefore I support this proposal.<br>
>><br>
>> Fernando<br>
>> On 16/09/2020 20:42, Noah wrote:<br>
>><br>
>><br>
>> On Thu, Sep 17, 2020 at 2:30 AM Ibeanusi Elvis <br>
>> <<a href="mailto:ibeanusielvis@gmail.com" rel="noreferrer noreferrer" target="_blank">ibeanusielvis@gmail.com</a>><br>
>> wrote:<br>
>><br>
>>><br>
>>> I am strongly in opposition to this RPKI ROA proposal,<br>
>>><br>
>><br>
>> You oppose yet....<br>
>><br>
>><br>
>>> issuing an AS0 for AFRINIC address space<br>
>>><br>
>><br>
>> You must be clear on which AFRINIC address space rather than <br>
>> presenting a<br>
>> rather vague statement.<br>
>><br>
>> The proposal is very clear and explicit and the AFRINIC space in <br>
>> question<br>
>> is that which has not yet been allocated or assigned to any entity or<br>
>> resource member.<br>
>><br>
>> I will quote for you section 2.0 of the proposal as written below;<br>
>><br>
>> *2.0 Summary of how this proposal addresses the problem*<br>
>><br>
>> This proposal instructs AFRINIC to create ROAs for all *unallocated <br>
>> and<br>
>> unassigned address space under its control.* This will enable <br>
>> networks<br>
>> performing RPKI-based BGP Origin Validation to easily reject all the <br>
>> bogon<br>
>> announcements covering resources managed by AFRINIC.<br>
>><br>
>> So what are you talking about?<br>
>><br>
>> Noah<br>
>><br>
>><br>
>> _______________________________________________<br>
>> RPD mailing <br>
>> listRPD@afrinic.nethttps://<a href="http://lists.afrinic.net/mailman/listinfo/rpd" rel="noreferrer noreferrer noreferrer" target="_blank">lists.afrinic.net/mailman/listinfo/rpd</a> <br>
>> <<a href="https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.afrinic.net%2Fmailman%2Flistinfo%2Frpd&data=02%7C01%7C%7Ca48324a7026842948aff08d85abbfbd8%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637359110720490840&sdata=mOjgUTIarKfPnsD2h0TtixnR51E4wzIwqoo6rONHW%2FI%3D&reserved=0" rel="noreferrer noreferrer noreferrer" target="_blank">https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.afrinic.net%2Fmailman%2Flistinfo%2Frpd&data=02%7C01%7C%7Ca48324a7026842948aff08d85abbfbd8%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637359110720490840&sdata=mOjgUTIarKfPnsD2h0TtixnR51E4wzIwqoo6rONHW%2FI%3D&reserved=0</a>><br>
>><br>
>> _______________________________________________<br>
>> RPD mailing list<br>
>> <a href="mailto:RPD@afrinic.net" rel="noreferrer noreferrer" target="_blank">RPD@afrinic.net</a><br>
>><br>
>> <a href="https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.afrinic.net%2Fmailman%2Flistinfo%2Frpd&data=02%7C01%7C%7Ca48324a7026842948aff08d85abbfbd8%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637359110720510827&sdata=jlnsXCK7dATX4Jcg48%2BhurUnj1E5umTa2RZq7IMsb%2Fs%3D&reserved=0" rel="noreferrer noreferrer noreferrer" target="_blank">https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.afrinic.net%2Fmailman%2Flistinfo%2Frpd&data=02%7C01%7C%7Ca48324a7026842948aff08d85abbfbd8%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637359110720510827&sdata=jlnsXCK7dATX4Jcg48%2BhurUnj1E5umTa2RZq7IMsb%2Fs%3D&reserved=0</a><br>
>><br>
>><br>
>> _______________________________________________<br>
>> RPD mailing list<br>
>> <a href="mailto:RPD@afrinic.net" rel="noreferrer noreferrer" target="_blank">RPD@afrinic.net</a><br>
>> <a href="https://lists.afrinic.net/mailman/listinfo/rpd" rel="noreferrer noreferrer noreferrer" target="_blank">https://lists.afrinic.net/mailman/listinfo/rpd</a><br>
>><br>
<br>
<br>
<br>
> _______________________________________________<br>
> RPD mailing list<br>
> <a href="mailto:RPD@afrinic.net" rel="noreferrer noreferrer" target="_blank">RPD@afrinic.net</a><br>
> <a href="https://lists.afrinic.net/mailman/listinfo/rpd" rel="noreferrer noreferrer noreferrer" target="_blank">https://lists.afrinic.net/mailman/listinfo/rpd</a><br>
<br>
<br>
--<br>
patrick<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="https://lists.afrinic.net/pipermail/rpd/attachments/20200917/63c1c6e8/attachment.html" rel="noreferrer noreferrer noreferrer" target="_blank">https://lists.afrinic.net/pipermail/rpd/attachments/20200917/63c1c6e8/attachment.html</a>><br>
<br>
------------------------------<br>
<br>
Subject: Digest Footer<br>
<br>
_______________________________________________<br>
RPD mailing list<br>
<a href="mailto:RPD@afrinic.net" rel="noreferrer noreferrer" target="_blank">RPD@afrinic.net</a><br>
<a href="https://lists.afrinic.net/mailman/listinfo/rpd" rel="noreferrer noreferrer noreferrer" target="_blank">https://lists.afrinic.net/mailman/listinfo/rpd</a><br>
<br>
<br>
------------------------------<br>
<br>
End of RPD Digest, Vol 168, Issue 82<br>
************************************<br>
</blockquote></div>
_______________________________________________<br>
RPD mailing list<br>
<a href="mailto:RPD@afrinic.net" target="_blank" rel="noreferrer">RPD@afrinic.net</a><br>
<a href="https://lists.afrinic.net/mailman/listinfo/rpd" rel="noreferrer noreferrer" target="_blank">https://lists.afrinic.net/mailman/listinfo/rpd</a><br>
</blockquote></div>