Search RPD Archives
Limit search to: Subject & Body Subject Author
Sort by:

[rpd] RPD Digest, Vol 160, Issue 23

Kakel Mbumb kakelmbumb at gmail.com
Fri Jan 10 14:36:46 UTC 2020


The proposal for RPKI is not applicable as it centralises the control of
internet; and also represents a potential risk for government to overtake
it.
We are a community and need to be independent on the way we treat our
resources.
*KAKEL MBUMB*
*Chargé du Département Entrepreneuriat au Forum National de la Jeunesse
(FNJ)*

*Coordinator, YPARD-RDC Grand Katanga, Agricultural Development through
Youths*

*Project Vice Coordinator, Agribusiness Cooperative - CAAPJECO*
*Consultant, RESOJEC, Youth Chamber of Commerce*
*Country Representative, Mashinani Hub ,ICT skills for rural communities*
*Yali RLC EA Cohort 6 Alumnus, Business & Entrepreneurship*
*Lubumbashi, Haut-Katanga Province*
*Democratic Republic of the Congo (Congo, DRC)*

*Phone: +243 993 656 038 (Whatsapp) *
*Facebook: **https://www.facebook.com/kakelmbumb
<https://www.facebook.com/kakelmbumb>*
*Twitter: **https://twitter.com/KakelMbumb <https://twitter.com/KakelMbumb>*
*Linked in: **https://www.linkedin.com/in/kakel-mbumb-240534ba/
<https://www.linkedin.com/in/kakel-mbumb-240534ba/>*
*Skype: kakel.mbumb1*




Le ven. 10 janv. 2020 à 10:28, <rpd-request at afrinic.net> a écrit :


> Send RPD mailing list submissions to

> rpd at afrinic.net

>

> To subscribe or unsubscribe via the World Wide Web, visit

> https://lists.afrinic.net/mailman/listinfo/rpd

> or, via email, send a message with subject or body 'help' to

> rpd-request at afrinic.net

>

> You can reach the person managing the list at

> rpd-owner at afrinic.net

>

> When replying, please edit your Subject line so it is more specific

> than "Re: Contents of RPD digest..."

>

>

> Today's Topics:

>

> 1. Re: New policy proposals and updated ones - RPKI-ROAs

> (Nishal Goburdhan)

> 2. Re: AFPUB-2019-GEN-006-DRAFT01: "RPKI ROAs for Unallocated

> and Unassigned AFRINIC Address Space" (Nishal Goburdhan)

> 3. Re: AFPUB-2019-GEN-006-DRAFT01: "RPKI ROAs for Unallocated

> and Unassigned AFRINIC Address Space" (Owen DeLong)

>

>

> ----------------------------------------------------------------------

>

> Message: 1

> Date: Thu, 09 Jan 2020 15:06:52 +0200

> From: "Nishal Goburdhan" <nishal at controlfreak.co.za>

> To: "rpd >> AfriNIC Resource Policy" <rpd at afrinic.net>

> Subject: Re: [rpd] New policy proposals and updated ones - RPKI-ROAs

> Message-ID: <CCB6F55D-64DA-4ADC-BB10-89609642A905 at controlfreak.co.za>

> Content-Type: text/plain; charset="UTF-8"; format=flowed

>

> On 4 Jan 2020, at 12:05, Daniel Yakmut via RPD wrote:

>

> > The current state of RPKI infrastructure, does not provide a

> > sufficient period between revocation of ROA and notification that a

> > given prefix has been allocated to an organization, which can impact

> > considerably on allocations.

>

> if you?re going to make broad statements like this, you?d better

> have evidence to support it. so, can you point to a study, or

> documented operational experience that corroborates what you?ve just

> written?

>

> having actually done my fair share of mucking around with rpki, i would

> say that what you wrote, has not been *my* experience. by that i mean

> that there?s been no appreciable delay that i?ve noticed with

> revocations that?s i?ve done, in a manner similar to what i expect

> afrinic would need to do. but, ymmv.

>

> (for the record, even though i don?t believe this to be a problem, i

> would still like to have seen that done as part of the impact

> assessment, but, let?s move than along .. )

>

>

> > Except we can be able to provide a sufficient period or create a

> > different procedure, the proposal for the RPKI-ROAs does not fly.

>

> why? perhaps, you are of the mistaken belief that, being given a prefix

> by afrinic means that you can use this prefix on the internet

> *immediately*? in fact, up until when the netop decides to get their

> initial route object into an IRR (which, btw, you can *not* do *before*

> you get the magic allocation email from afrinic..) you should almost

> expect that you can *NOT* get the prefix routed via any self-respecting

> transit, or IXP operator; most of whom, only update filters once a day.

>

> given that sensible network operators run multiple validators, that

> upgrade considerably faster (!) than IRR filters (and here, we are

> talking about minutes vs. a once a day update) i don?t see the problem

> you?re alluding to. in my relatively simple view of the world, the

> process is something like:

> t=0; afrinic does internal approval of requested space after their due

> diligence process

> t=1; afrinic revokes the ROA covering this space (can be automated)

> t=2; afrinic issues a new ROA (or set of ROAs) covering the master

> prefix space, but without this prefix (can be automated)

> t=3; (well, not quite; it?s more like t=+15min..) afrinic confirms

> revocation from an external source and that rpki_state=not_found (can be

> automated)

> t=4; afrinic sends you the magic e mail to say that your netblock has

> been allocated

>

> i think you?re getting confused at the t=3 marker; because there is

> *always* the risk that someone?s validator cache broke. that risk

> still exists today, just in a different form (ie. a broken IRR filter,

> or any one of ten other things that could break). if anything, this is

> actually an improvement given how quickly most validators update, vs.

> IRR filters.

>

> (before you nitpick this, that?s not a complete process; just an

> indication of the significant bits..)

>

> whilst i don?t particularly care for this policy, i *do* care that

> what?s been used to assess it?s viability (use of rpki) is correct;

> and, in at least two cases, i?ve seen comments which appear to be

> ?against? the policy make assumptions and expectations, and allude

> to operations of the rpki that are simply incorrect.

>

> unless, of course, you have data to show otherwise.

>

> ?n.

>

>

>

> ------------------------------

>

> Message: 2

> Date: Thu, 09 Jan 2020 15:24:36 +0200

> From: "Nishal Goburdhan" <nishal at controlfreak.co.za>

> To: rpd at afrinic.net

> Subject: Re: [rpd] AFPUB-2019-GEN-006-DRAFT01: "RPKI ROAs for

> Unallocated and Unassigned AFRINIC Address Space"

> Message-ID: <9EDB60BB-C841-4AEB-ABD6-4CF354C5E943 at controlfreak.co.za>

> Content-Type: text/plain; charset="UTF-8"; format=flowed

>

> On 9 Jan 2020, at 13:21, Anthony Ubah wrote:

>

> > Quoting my previous comment, " I'm not abreast of staff impact

> > assessment

> > in the previous presentations, so please offer me some clarity"

> > Do we have data on the operational implication/Impact of other RIRs

> > that

> > have this ion consideration, and/or that which has adopted and

> > implemented

> > it?

>

> considering that this has just been adopted in the APNIC region, i doubt

> that there?s operational data. however, this is not difficult to

> figure out. someone has to write a series of hooks into the database

> to:

> # revoke previous AS0 ROA for parent prefix a/b that covers prefix P

> # reissue new AS0 ROA for prefix c/d that does not include P

> # confirm that rpki_state=not_found for P

>

> and, in the upcoming myafrinic2.0 there could even be a button that you

> can push, that would show you the RPKI state for P. for those that are

> too lazy to look it up themselves (which you can do now quite easily

> anyway).

>

> none of this is rocket science.

>

>

> > Also, I'm still curious about the effectiveness of this policy if it

> > is

> > implemented on RIR to RIR basis. I think it will be of no great

> > impact,

> > judging by the number of resources within the jurisdiction of AfriNIC.

>

> probably. but you start with fixing something small, in your own

> backyard, and going on from there ..

>

>

> > I honestly think this policy is very operational and should be

> > reviewed

> > Only a global policy will be reasonable because a none uniform policy

> > might

> > create additional and unreasonable stress.

>

> you are ignoring that there *is* already global consensus, at least in

> the routing world, on what to do with AS0 ROAs. see:

> https://tools.ietf.org/html/rfc6483#section-4. so, all that is

> necessary is to get the RIR in question to agree to publish the AS0 ROAs

> for their blocks. i really don?t understand why people keep beating

> this ?global policy? issue, because, honestly, that?s really not

> relevant. what this *does* do, is protect unassigned afrinic prefixes

> from misuse.

>

> ?n.

>

>

>

> ------------------------------

>

> Message: 3

> Date: Fri, 10 Jan 2020 00:27:37 -0800

> From: Owen DeLong <owen at delong.com>

> To: Anthony Ubah <ubah.tonyiyke at gmail.com>

> Cc: rpd at afrinic.net

> Subject: Re: [rpd] AFPUB-2019-GEN-006-DRAFT01: "RPKI ROAs for

> Unallocated and Unassigned AFRINIC Address Space"

> Message-ID: <477D264E-E529-4123-B370-A3579AE2B5F7 at delong.com>

> Content-Type: text/plain; charset="utf-8"

>

>

>

> > On Jan 9, 2020, at 03:21 , Anthony Ubah <ubah.tonyiyke at gmail.com> wrote:

> >

> > Hello Owen,

> >

> > Although you haven't provided adequate clarity on impact, which I think

> must be put into good consideration.

>

> From my perspective, there is effectively 0 impact unless AfriNIC blunders

> the process.

>

> The proposed policy allows/requires AfriNIC staff to create and issue AS0

> ROAs for all space under AfriNIC management which is not allocated or

> assigned.

>

> Presumably, this would also require them to withdraw and/or replace such

> ROAs upon issuance (allocation or assignment) of any space covered by an

> AS0 ROA.

>

> Further, as has been mentioned previously, any impact is limited to ISPs

> that choose to accept and make routing decisions based on these ROAs.

>

> The odds of AfriNIC blundering this are relatively low IMHO, but it?s not

> entirely blunder-proof, so there is some risk. I think the risk is

> negligible and the proposal is good policy.

>

> I?m not sure what other clarity on impact you might be looking for as

> everything here has been previously stated.

>

> > Quoting my previous comment, " I'm not abreast of staff impact

> assessment in the previous presentations, so please offer me some clarity?

>

> Honestly, neither am I if any such impact assessment has been issued (I?m

> not convinced this has yet happened).

>

> I did follow the discussions in the APNIC region. My questions on the

> matter were quickly and effectively addressed and I supported the proposal

> at that point.

>

> > Do we have data on the operational implication/Impact of other RIRs that

> have this ion consideration, and/or that which has adopted and implemented

> it?

>

> I don?t believe it is yet implemented anywhere. What is written above is,

> to the best of my knowledge, all we know so far. However, I think you are

> getting wrapped around the axel on perceived impacts which simply don?t

> hold true for RPKI in general, let alone for this proposal.

>

> > Also, I'm still curious about the effectiveness of this policy if it is

> implemented on RIR to RIR basis. I think it will be of no great impact,

> judging by the number of resources within the jurisdiction of AfriNIC.

>

> I?m not even sure what ?implemented on RIR to RIR basis? would mean in

> this context.

>

> Basically, the same proposal is being floated in all of the RIRs as Jordi

> mentioned.

>

> Each RIR will implement it independently if they adopt the policy.

>

> In each case, the RIR in question would begin issuing AS0 ROAs for all

> prefixes in their inventory which have not been issued to another party and

> are not in use by the RIR itself.

>

> In other words, these AS0 ROAs would (theoretically) cover only

> unallocated prefixes and not space which has been issued.

>

> > I honestly think this policy is very operational and should be reviewed.

> Only a global policy will be reasonable because a none uniform policy might

> create additional and unreasonable stress.

>

> The policy is only minimally operational. It has been reviewed by many

> people. Who do you think additionally needs to review it?

>

> A non-uniform policy does not create any additional or unreasonable

> stress. It creates an RIR that doesn?t provide an easy way to identify

> space which is being squatted.

>

> Owen

>

> >

> >

> > Best Regards,

> >

> > UBAH ANTHONY

> >

> >

> >

> > On Tue, Jan 7, 2020 at 4:22 PM Owen DeLong <owen at delong.com <mailto:

> owen at delong.com>> wrote:

> > RPKI in general involves AfriNIC in the routing process.

> >

> > This proposal does not significantly expand that.

> >

> > Without any change in policy, anyone can issue an AS0 ROA for their

> holdings.

> >

> > This proposal merely creates the ability for AfriNIC to issue AS0 ROAs

> for space which is both under AfriNIC administration and not issued to

> anyone.

> >

> > This is a good thing.

> >

> > It does not create any new opportunities for DOS.

> >

> > Owen

> >

> >

> >> On Jan 6, 2020, at 01:18 , Anthony Ubah <ubah.tonyiyke at gmail.com

> <mailto:ubah.tonyiyke at gmail.com>> wrote:

> >>

> >> Hello Jordi,

> >>

> >> An observation. I might be wrong, so correct me if I am.

> >> From my understanding, if the policy involves AfriNIC in the routing

> process, it is impacting on staff as there must be multiple checks

> post-implementation to mitigate accidental/malicious DOS. In this case,

> don't you think AfriNIC's operational details should also be considered as

> well in certain policies like this which are impacting?

> >> I'm not abreast of staff impact assessment in the previous

> presentations, so please offer me some clarity.

> >>

> >> Finally looking at this from the AfriNIC lens, with our single-digit

> percentile of resource allocation, how effective will this policy be if

> other RIRs with bigger resources don not have an equivalent implementation?

> I think this will only be truly efficient if implemented on a global scope,

> starting from the RIRs with the bulk of resources.

> >>

> >> A Happy New year to everyone

> >>

> >>

> >>

> >> Best Regards,

> >>

> >> UBAH ANTHONY

> >>

> >>

> >>

> >>

> >> On Mon, Jan 6, 2020 at 8:53 AM <rpd-request at afrinic.net <mailto:

> rpd-request at afrinic.net>> wrote:

> >> Send RPD mailing list submissions to

> >> rpd at afrinic.net <mailto:rpd at afrinic.net>

> >>

> >> To subscribe or unsubscribe via the World Wide Web, visit

> >> https://lists.afrinic.net/mailman/listinfo/rpd <

> https://lists.afrinic.net/mailman/listinfo/rpd>

> >> or, via email, send a message with subject or body 'help' to

> >> rpd-request at afrinic.net <mailto:rpd-request at afrinic.net>

> >>

> >> You can reach the person managing the list at

> >> rpd-owner at afrinic.net <mailto:rpd-owner at afrinic.net>

> >>

> >> When replying, please edit your Subject line so it is more specific

> >> than "Re: Contents of RPD digest..."

> >>

> >>

> >> Today's Topics:

> >>

> >> 1. Re: AFPUB-2019-GEN-006-DRAFT01: "RPKI ROAs for Unallocated

> >> and Unassigned AFRINIC Address Space" (JORDI PALET MARTINEZ)

> >>

> >>

> >> ----------------------------------------------------------------------

> >>

> >> Message: 1

> >> Date: Mon, 06 Jan 2020 08:52:20 +0100

> >> From: JORDI PALET MARTINEZ <jordi.palet at consulintel.es <mailto:

> jordi.palet at consulintel.es>>

> >> To: <rpd at afrinic.net <mailto:rpd at afrinic.net>>

> >> Subject: Re: [rpd] AFPUB-2019-GEN-006-DRAFT01: "RPKI ROAs for

> >> Unallocated and Unassigned AFRINIC Address Space"

> >> Message-ID: <F8A958E3-701E-43A5-9236-6067083B51C6 at consulintel.es

> <mailto:F8A958E3-701E-43A5-9236-6067083B51C6 at consulintel.es>>

> >> Content-Type: text/plain; charset="utf-8"

> >>

> >> Hi Taiwo,

> >>

> >>

> >>

> >> In the policy we don?t talk about specific operational details, such as

> timing. This up to the staff to set.

> >>

> >>

> >>

> >> Human errors are possible even without this policy, right? The

> implementation should make sure that that doesn?t happen.

> >>

> >>

> >>

> >> An human error can make allocated/assigned space to appear back as

> unnallocated/unnasigned space and given to another member. So this policy

> doesn?t change that. But of course, there should be sufficient checks in

> the implementation to avoid that.

> >>

> >>

> >>

> >> According to what you say, *any* policy should wait for the

> implementation so we decide if we agree on the consensus of *not just the

> policy* but the *implementation as well* ?

> >>

> >>

> >>

> >> Regards,

> >>

> >> Jordi

> >>

> >> @jordipalet

> >>

> >>

> >>

> >>

> >>

> >>

> >>

> >> El 6/1/20 7:19, "Taiwo Oyewande" <taiwo.oyewande88 at gmail.com <mailto:

> taiwo.oyewande88 at gmail.com>> escribi?:

> >>

> >>

> >>

> >>

> >>

> >> Are resources reclaimed by Afrinic regarded as bogons, how long after

> reclaim of such resources will they be given a ROA with origin AS0?

> >>

> >>

> >>

> >> What happens in the case of human or machine error in revoking the AS0

> state. Which can lead to DOS of the resource holder. I think there are some

> technicalities unresolved that affect the implication of this policy which

> needs to be looked at before moving forward with this policy

> >>

> >>

> >> On 4 Jan 2020, at 12:40, JORDI PALET MARTINEZ via RPD <rpd at afrinic.net

> <mailto:rpd at afrinic.net>> wrote:

> >>

> >> Hi Kakel,

> >>

> >>

> >>

> >> I believe you?re getting it wrong.

> >>

> >>

> >>

> >> I can?t see how this proposal has any implications in any government

> manipulation over Internet. Can you explain it?

> >>

> >>

> >>

> >> Remember that to oposse to any proposal, you need to reasonably

> justifiy your opossition, specially during the last-call, in case something

> hasn?t been discovered in the previous stage, when the proposal already

> reached consensus.

> >>

> >>

> >>

> >> Regards,

> >>

> >> Jordi

> >>

> >> @jordipalet

> >>

> >>

> >>

> >>

> >>

> >>

> >>

> >> El 4/1/20 12:23, "Kakel Mbumb" <kakelmbumb at gmail.com <mailto:

> kakelmbumb at gmail.com>> escribi?:

> >>

> >>

> >>

> >> The proposal for RPKI is not applicable as it centralises the control

> of internet; and also represents a potential risk for government to

> overtake it.

> >>

> >> We are a community and need to be independent on the way we treat our

> resources; so i oppose this proposal.

> >>

> >> KAKEL MBUMB

> >>

> >> Charg? du D?partement Entrepreneuriat au Forum National de la Jeunesse

> (FNJ)

> >>

> >> Coordinator, YPARD-RDC Grand Katanga, Agricultural Development through

> Youths

> >>

> >> Project Vice Coordinator, Agribusiness Cooperative - CAAPJECO

> >>

> >> Consultant, RESOJEC, Youth Chamber of Commerce

> >>

> >> Country Representative, Mashinani Hub ,ICT skills for rural communities

> >>

> >> Yali RLC EA Cohort 6 Alumnus, Business & Entrepreneurship

> >>

> >> Lubumbashi, Haut-Katanga Province

> >>

> >> Democratic Republic of the Congo (Congo, DRC)

> >>

> >> Phone: +243 993 656 038 (Whatsapp)

> >>

> >> Facebook: https://www.facebook.com/kakelmbumb <

> https://www.facebook.com/kakelmbumb>

> >>

> >> Twitter: https://twitter.com/KakelMbumb <https://twitter.com/KakelMbumb

> >

> >>

> >> Linked in: https://www.linkedin.com/in/kakel-mbumb-240534ba/ <

> https://www.linkedin.com/in/kakel-mbumb-240534ba/>

> >>

> >> Skype: kakel.mbumb1

> >>

> >>

> >>

> >>

> >>

> >>

> >>

> >> Le sam. 4 janv. 2020 ? 12:07, <rpd-request at afrinic.net <mailto:

> rpd-request at afrinic.net>> a ?crit :

> >>

> >> Send RPD mailing list submissions to

> >> rpd at afrinic.net <mailto:rpd at afrinic.net>

> >>

> >> To subscribe or unsubscribe via the World Wide Web, visit

> >> https://lists.afrinic.net/mailman/listinfo/rpd <

> https://lists.afrinic.net/mailman/listinfo/rpd>

> >> or, via email, send a message with subject or body 'help' to

> >> rpd-request at afrinic.net <mailto:rpd-request at afrinic.net>

> >>

> >> You can reach the person managing the list at

> >> rpd-owner at afrinic.net <mailto:rpd-owner at afrinic.net>

> >>

> >> When replying, please edit your Subject line so it is more specific

> >> than "Re: Contents of RPD digest..."

> >>

> >>

> >> Today's Topics:

> >>

> >> 1. AFPUB-2019-GEN-006-DRAFT01: "RPKI ROAs for Unallocated and

> >> Unassigned AFRINIC Address Space" (Sylvain Baya)

> >> 2. Re: New policy proposals and updated ones - RPKI-ROAs

> >> (Daniel Yakmut)

> >>

> >>

> >> ----------------------------------------------------------------------

> >>

> >> Message: 1

> >> Date: Sat, 4 Jan 2020 00:01:55 +0100

> >> From: Sylvain Baya <abscoco at gmail.com <mailto:abscoco at gmail.com>>

> >> To: Owen DeLong <owen at delong.com <mailto:owen at delong.com>>, "PDWG's

> Mailing List"

> >> <rpd at afrinic.net <mailto:rpd at afrinic.net>>

> >> Subject: [rpd] AFPUB-2019-GEN-006-DRAFT01: "RPKI ROAs for Unallocated

> >> and Unassigned AFRINIC Address Space"

> >> Message-ID:

> >> <

> CAJjTEvEDJog_EvR8O5VYvi6uf+yhdN-tsWhzaxnhkDH4mGSTwg at mail.gmail.com

> <mailto:

> CAJjTEvEDJog_EvR8O5VYvi6uf%2ByhdN-tsWhzaxnhkDH4mGSTwg at mail.gmail.com>>

> >> Content-Type: text/plain; charset="UTF-8"

> >>

> >> Hi all,

> >>

> >> Best wishes for this new year ; added in the Grace era !

> >>

> >> Please my comments are below (inline)...

> >>

> >> 2020-01-03 17:46 UTC+01:00, Owen DeLong <owen at delong.com <mailto:

> owen at delong.com>>:

> >> >

> >> >

> >> >> On Dec 30, 2019, at 06:38 , Paschal Ochang <pascosoft at gmail.com

> <mailto:pascosoft at gmail.com>> wrote:

> >> >>

> >> >> Hello Jordi,

> >> >> feliz Navidad y un Feliz A?o Nuevo.

> >> >>

> >> >> I have some concerns regarding this proposal and also some

> clarifications

> >> >> .

> >> >>

> >> >> I think statistically AFRINIC has a good percentage of IPv4 address

> space

> >> >> covered by route origin authorization as compared to APNIC. APNIC

> has a

> >> >> very low percentage statically hence it's hurried acceptance of the

> >> >> proposal.

> >> >

> >> > I corrected the subject line to be descriptive of what is meant by

> ?the

> >> > proposal/this proposal??

> >> >

> >>

> >> Dear Owen,

> >>

> >> Thanks for your email.

> >>

> >> ...yes ! adjusting the subject line helps to focus the discussion,

> >> but i'm not sure that there was a real need in this particular case :-/

> >>

> >> ...btw, your timing is perfect, with the new year :-D

> >>

> >> >

> >> > There?s no relationship between your statement and the proposal.

> >> >

> >>

> >> ...not sure !

> >> But if you append ?intent? to ?proposal? ; then i'll certainly agree ;

> -)

> >>

> >> ...please see below.

> >>

> >> >

> >> > The proposal creates AS0 ROAs for addresses in the RIR inventory

> which have

> >> > not been issued or which have been reclaimed or returned.

> >> >

> >>

> >> Exact !

> >>

> >> ...but don't forget that usually, in this PDWG, the title and problem

> statement

> >> (and even the description of the proposed solution) of a DPP (Draft

> Policy

> >> Proposal) means nothing.

> >>

> >> Yes, that's sad ! but true :'-(

> >>

> >> >

> >> > It has nothing to do with addresses which have been issued but are not

> >> > covered by an ROA.

> >> >

> >> > As such, I see no problem with the proposal.

> >> >

> >> >> I think using the approach in this policy is majorly to handle

> accidental

> >> >> incidents rather than malicious attacks whereby someone might try to

> >> >> manipulate an AS path.

> >> >

> >> > RPKI does nothing at all to help with manipulated AS Paths. It is only

> >> > effective against prefixes originated from the wrong ASN.

> >> >

> >> > In the case of this policy, it will aid in the prevention/detection of

> >> > unauthorized use of unallocated number resources.

> >> >

> >> >> It is suggested to always drop invalid announcements, rather than

> applying

> >> >> a lower preference. This is because sub-prefix hijackings would be

> still

> >> >> possible if invalids are accepted and this would go against the

> purpose of

> >> >> RPKI validation. However I think the text should state how invalids

> >> >> should be dropped in order not to trigger loosing connectivity.

> >> >

> >> > I?m not sure how many different ways you think there are to drop a

> route. At

> >> > least on the routers I?ve run (Cisco, Juniper, Mikrotik, Vyatta,

> Ascend,

> >> > Livingston, Foundry, etc.), you can either drop a prefix or accept

> it. The

> >> > decision is binary and there are not multiple ?ways? to drop on. In

> some

> >> > cases, you can choose additional behaviors such as logging, but I

> hardly see

> >> > that as relevant to whether connectivity is preserved or not.

> >> >

> >> > I think what you may be missing in your understanding is that Invalid

> is not

> >> > the same as Unknown. RPKI validation provides three possible results:

> >> > 1. Valid ? The route matches a ROA and the ROA matches the

> Origin ASN.

> >> > Further, the ROA signature chain is cryptographically valid.

> >> > 2. Invalid ? The route matches a ROA, but either the ROA

> signature fails

> >> > validation or the Origin ASN does not match or the prefix length is

> longer

> >> > than the specified maximum.

> >> > 3. Not Found/Unknown ? The route does not match a ROA

> >> >

> >> > Note that a prefix which is shorter than an intersecting ROA is

> considered

> >> > not to match. See table below for details on how this works out:

> >> >

> >> >

> >> > ROA Prefix

> >> > MAX Length

> >> > Origin AS

> >> > Received Prefix

> >> > Origin AS

> >> > Result

> >> >

> >> > 192.0.2.0/24 <http://192.0.2.0/24>

> >> > 24

> >> > 65550

> >> > 192.0.2.0/24 <http://192.0.2.0/24>

> >> > 64498

> >> > Invalid

> >> >

> >> > 192.0.2.0/24 <http://192.0.2.0/24>

> >> > 24

> >> > 65550

> >> > 192.0.2.0/28 <http://192.0.2.0/28>

> >> > 64498

> >> > Invalid

> >> >

> >> > 192.0.2.0/24 <http://192.0.2.0/24>

> >> > 24

> >> > 65550

> >> > 192.0.2.0/24 <http://192.0.2.0/24>

> >> > 65550

> >> > Valid

> >> >

> >> > 192.0.2.0/24 <http://192.0.2.0/24>

> >> > 24

> >> > 65550

> >> > 192.0.2.0/28 <http://192.0.2.0/28>

> >> > 65550

> >> > Invalid

> >> >

> >> > 192.0.2.0/28 <http://192.0.2.0/28>

> >> > 28

> >> > 65550

> >> > 192.0.2.0/24 <http://192.0.2.0/24>

> >> > 64498

> >> > Unknown

> >> >

> >> > 192.0.2.0/28 <http://192.0.2.0/28>

> >> > 28

> >> > 65550

> >> > 192.0.2.0/24 <http://192.0.2.0/24>

> >> > 65550

> >> > Unknown

> >> >

> >> > 192.0.2.0/28 <http://192.0.2.0/28>

> >> > 28

> >> > 65550

> >> > 192.0.2.0/28 <http://192.0.2.0/28>

> >> > 64498

> >> > Invalid

> >> >

> >> > 192.0.2.0/28 <http://192.0.2.0/28>

> >> > 28

> >> > 65550

> >> > 192.0.2.0/28 <http://192.0.2.0/28>

> >> > 65550

> >> > Valid

> >> >

> >> > 192.0.2.0/24 <http://192.0.2.0/24>

> >> > 24

> >> > 65550

> >> > 192.0.2.64/26 <http://192.0.2.64/26>

> >> > 65550

> >> > Invalid

> >> >

> >> > 192.0.2.0/24 <http://192.0.2.0/24>

> >> > 28

> >> > 65550

> >> > 192.0.2.64/26 <http://192.0.2.64/26>

> >> > 65550

> >> > Valid

> >> >

> >> >

> >> >> Finally I dont think it will be a nice idea allowing resource

> holders to

> >> >> create AS0 ROA as I think this scenario might increase the issue of

> >> >> invalid prefixes in the routing tables.

> >> >

> >> > This proposal does not allow resource holders to create AS0 ROAs. It

> expects

> >> > AfriNIC to create AS0 ROAs for space which is within AfriNIC

> administration,

> >> > but which is not currently issued.

> >> >

> >>

> >> ...i think the following portion of the [1] text explains the concerns

> >> raised by Paschal :

> >>

> >> ?[...] Any resource holder can create AS0 (zero) ROAs for the

> >> resources they have

> >> under their account/administration.

> >>

> >> An RPKI ROA is a positive attestation that a prefix holder has

> >> authorized an Autonomous System to originate a route for this prefix

> >> to the global BGP routing table. An RPKI ROA for the same prefixes

> >> with AS0 (zero) origin shows a negative intent from the resource

> >> holder to have the prefixes advertised in the global BGP routing

> >> table. [...]?

> >> __

> >> [1]: <https://afrinic.net/policy/proposals/2019-gen-006-d1/amp <

> https://afrinic.net/policy/proposals/2019-gen-006-d1/amp>>

> >>

> >> >

> >> > I hope that clarifies the situation.

> >> >

> >>

> >> ...not sure, but you did more for most of the participants, in

> >> promoting RPKI (Resource Public Key Infrastructure), ROA (Route Origin

> >> Autorisation) and ROV (RPKI-based route Origin Validation). So,

> >> validate and drop non-valid routes...

> >>

> >> IMHO, what would clarify is to :

> >>

> >> ??/

> >> ?'drop'/remove that portion of the text :-)

> >> ? (eventually) create a sub-section to provide definitions

> >> for new concepts. The definition sub-section would remove

> >> any ambiguity.

> >> ? (even if i think that this proposal is too much operational)

> >> simplify the core policy text like this :

> >> ?1| ?AFRINIC MUST/will create ROAs with origin AS0 for all

> >> the unallocated and unassigned address space (IPv4 & IPv6)

> >> for which it is the current administrator.?

> >> ?2| (i prefer this less operational version) ?AFRINIC MUST/will

> >> flag/mark all the unused (unallocated & unassigned) address

> >> space (IPv4 & IPv6) for which it is the current administrator.

> >> In order to render its unused address space unsquattable

> >> in a global secured routing context.?

> >> ? ...

> >> ??\

> >>

> >> The difference with my version (2|) is that it's more agnostic

> >> (technologcally/operationally speaking) and portable then it

> >> could (probably) more easily pass in all RIRs with the same

> >> text. To be proposed as a global policy : final/first goal of the

> >> authors :-)

> >>

> >> ...to be clearer, i prefer ?resource? rather than ?address space? ;-)

> >>

> >> Shalom,

> >> --sb.

> >>

> >> >

> >> > Owen

> >> >

> >> >>

> >> >> On Tuesday, November 5, 2019, JORDI PALET MARTINEZ via RPD

> >> >> <rpd at afrinic.net <mailto:rpd at afrinic.net> <mailto:rpd at afrinic.net

> <mailto:rpd at afrinic.net>>> wrote:

> >> >> Hi Sylvain,

> >> >>

> >> >>

> >> >>

> >> >>

> >> >>

> >> >>

> >> >>

> >> >> El 5/11/19 6:11, "Sylvain Baya" <abscoco at gmail.com <mailto:

> abscoco at gmail.com>

> >> >> <mailto:abscoco at gmail.com <mailto:abscoco at gmail.com>>> escribi?:

> >> >>

> >> >>

> >> >>

> >> >> Hi all,

> >> >>

> >> >>

> >> >>

> >> >> Hope you are doing well.

> >> >>

> >> >>

> >> >>

> >> >> Please comments below (inline)...

> >> >>

> >> >>

> >> >>

> >> >> Le mardi 5 novembre 2019, JORDI PALET MARTINEZ via RPD <

> rpd at afrinic.net <mailto:rpd at afrinic.net>

> >> >> <mailto:rpd at afrinic.net <mailto:rpd at afrinic.net>>> a ?crit :

> >> >>

> >> >> Hi all,

> >> >>

> >> >> [...]

> >> >> This is the list of new policy proposals (note that the numbering

> can be

> >> >> modified by the staff when published).

> >> >>

> >> >> 1) AFPUB-2019-IPv6-002-DRAFT01: "Adjusting IPv6 PA Policy"

> >> >> Solves a discrepancy between IPv6 PI and IPv6 PA regarding the

> >> >> announcement of aggregated addressing space.

> >> >>

> >> >> 2) AFPUB-2019-GEN-003-DRAFT01: "Chairs Elections Process"

> >> >> Including in the CPM a detailed procedure for the chair's elections.

> >> >>

> >> >> 3) AFPUB-2019-GEN-004-DRAFT01: "M&A Resource Transfers"

> >> >> Including in the CPM intra-RIR M&A for ASN, IPv4 and IPv6.

> >> >>

> >> >> 4) AFPUB-2019-GEN-005-DRAFT01: "Impact Analysis is Mandatory"

> >> >>

> >> >> 5) AFPUB-2019-GEN-006-DRAFT01: "RPKI ROAs for Unallocated and

> Unassigned

> >> >> AFRINIC Address Space"

> >> >>

> >> >>

> >> >>

> >> >> ...i like this one. I recall that i was thinking ok how to solve the

> >> >> problem of 'Internet resources

> >> >>

> >> >> squatting'. I was naively imagining a solution where a RIR will have

> to

> >> >> flag all their

> >> >>

> >> >> unallocated|unassigned Address Space ; via a particular attribute of

> the

> >> >> IRR (Internet Routing

> >> >>

> >> >> Registry). Now i understand that i was not too dummy or even crazy

> :-)

> >> >>

> >> >>

> >> >>

> >> >> Oh no! In that case the crazy one is me :-) !

> >> >>

> >> >>

> >> >>

> >> >> Please send me your DPP (Draft Policy Proposal), i can not wait more

> to

> >> >> review it ;-)

> >> >>

> >> >> Thanks.

> >> >>

> >> >>

> >> >>

> >> >> I was thinking in sending them in order (2 more today, 2 more

> tomorrow),

> >> >> but as you have interest in this one. My next one will be this one, I

> >> >> promise! Give me first a few minutes to respond to all the emails I

> got

> >> >> till now ?

> >> >>

> >> >>

> >> >>

> >> >> Shalom,

> >> >>

> >> >> --sb.

> >> >>

> >> >>

> >> >>

> >> >> Updated policy proposals:

> >> >>

> >> >> a) AFPUB-2019-ASN-001-DRAFT03: "Multihoming not required for ASN"

> >> >>

> >> >> b) AFPUB-2019-IPv4-002-DRAFT02: "IPv4 Inter-RIR Resource Transfers

> >> >> (Comprehensive Scope)"

> >> >>

> >> >> c) AFPUB-2018-GEN-001-DRAFT04: "Abuse Contact Policy Update"

> >> >>

> >> >> Regards,

> >> >> Jordi

> >> >> @jordipalet

> >> >>

> >> >> [...]

> >> >>

> >> >>

> >> >>

> >> >> --

> >> >>

> >> >>

> >> >>

> >> >>

> >> >>

> >> >> --

> >> >>

> >> >>

> >> >>

> >> >> Best Regards !

> >> >>

> >> >>

> >> >>

> >> >> Sylvain BAYA

> >> >>

> >> >> cmNOG's Co-Founder & Coordinator

> >> >>

> >> >> (+237) 677005341

> >> >>

> >> >> PO Box 13107 YAOUNDE / CAMEROON

> >> >>

> >> >> baya.sylvain [AT cmNOG DOT cm]

> >> >>

> >> >> abscoco2001 [AT yahoo DOT fr]

> >> >>

> >> >> http://www.cmnog.cm <http://www.cmnog.cm/> <http://www.cmnog.cm/ <

> http://www.cmnog.cm/>>

> >> >> https://cmnog.wordpress.com <https://cmnog.wordpress.com/> <

> https://cmnog.wordpress.com/ <https://cmnog.wordpress.com/>>

> >> >> ************************

> >> >>

> >> >> ?#?LASAINTEBIBLE(?#?Romains15:33):"Que LE ?#?DIEU de ?#?Paix soit

> avec

> >> >> vous tous!?#?Amen!"

> >> >>

> >> >> ?#?MaPri?re est que tu naisses de nouveau.

> >> >>

> >> >> ?#?Chr?tiennement

> >> >>

> >> >> ? Comme une biche soupire apr?s des courants d?eau,

> Ainsi mon

> >> >> ?me soupire apr?s toi, ? DIEU! ? (Psaumes 42 :2)

> >> >>

> >> >>

> >> >>

> >> >>

> >> >> _______________________________________________ RPD mailing list

> >> >> RPD at afrinic.net <mailto:RPD at afrinic.net> <mailto:RPD at afrinic.net

> <mailto:RPD at afrinic.net>>

> >> >> https://lists.afrinic.net/mailman/listinfo/rpd <

> https://lists.afrinic.net/mailman/listinfo/rpd>

> >> >> <https://lists.afrinic.net/mailman/listinfo/rpd <

> https://lists.afrinic.net/mailman/listinfo/rpd>>

> >> >> **********************************************

> >> >> IPv4 is over

> >> >> Are you ready for the new Internet ?

> >> >> http://www.theipv6company.com <http://www.theipv6company.com/> <

> http://www.theipv6company.com/ <http://www.theipv6company.com/>>

> >> >> The IPv6 Company

> >> >>

> >> >> 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.

> >> >>

> >> >> _______________________________________________

> >> >> RPD mailing list

> >> >> RPD at afrinic.net <mailto:RPD at afrinic.net>

> >> >> https://lists.afrinic.net/mailman/listinfo/rpd <

> https://lists.afrinic.net/mailman/listinfo/rpd>

> >> >

> >> >

> >>

> >>

> >>

> >> --

> >> Best Regards !

> >> baya.sylvain [AT cmNOG DOT cm] | <https://www.cmnog.cm <

> https://www.cmnog.cm/>> |

> >> <https://survey.cmnog.cm <https://survey.cmnog.cm/>>

> >> Subscribe to Mailing List : <

> https://lists.cmnog.cm/mailman/listinfo/cmnog/ <

> https://lists.cmnog.cm/mailman/listinfo/cmnog/>>

> >> __

> >> #?LASAINTEBIBLE?|?#?Romains15?:33?*Que LE ?#?DIEU? de ?#?Paix? soit avec

> >> vous tous! ?#?Amen?!*?

> >> ?#?MaPri?re? est que tu naisses de nouveau. #Chr?tiennement?

> >> ?*Comme une biche soupire apr?s des courants d?eau, ainsi mon ?me

> soupire

> >> apr?s TOI, ? DIEU!*? (#Psaumes42:2)

> >>

> >>

> >>

> >> ------------------------------

> >>

> >> Message: 2

> >> Date: Sat, 4 Jan 2020 11:05:58 +0100

> >> From: Daniel Yakmut <yakmutd at googlemail.com <mailto:

> yakmutd at googlemail.com>>

> >> To: Paschal Ochang <pascosoft at gmail.com <mailto:pascosoft at gmail.com>>,

> "rpd >> AfriNIC Resource

> >> Policy" <rpd at afrinic.net <mailto:rpd at afrinic.net>>

> >> Subject: Re: [rpd] New policy proposals and updated ones - RPKI-ROAs

> >> Message-ID: <af4aee1c-37a2-fd08-1672-e4b02f124de5 at gmail.com <mailto:

> af4aee1c-37a2-fd08-1672-e4b02f124de5 at gmail.com>>

> >> Content-Type: text/plain; charset="utf-8"; Format="flowed"

> >>

> >> The current state of RPKI infrastructure, does not provide a sufficient

> >> period between revocation of ROA and notification that a given prefix

> >> has been allocated to an organization, which can impact considerably on

> >> allocations. Except we can be able to provide a sufficient period or

> >> create a different procedure, the proposal for the RPKI-ROAs does not

> fly.

> >>

> >> On 30/12/2019 6:12 pm, Paschal Ochang wrote:

> >> > Yes in a way.

> >> >

> >> > On Monday, December 30, 2019, Fernando Frediani <fhfrediani at gmail.com

> <mailto:fhfrediani at gmail.com>

> >> > <mailto:fhfrediani at gmail.com <mailto:fhfrediani at gmail.com>>> wrote:

> >> >

> >> > On 30/12/2019 11:38, Paschal Ochang wrote:

> >> >>

> >> >> It is suggested to always drop invalid announcements, rather than

> >> >> applying a lower preference. This is because sub-prefix

> >> >> hijackings would be still possible if invalids are accepted and

> >> >> this would go against the purpose of RPKI validation. However? I

> >> >> think the text should state how invalids should be dropped in

> >> >> order not to trigger loosing connectivity.

> >> >

> >> > If I understand correctly what you are willing to say, no proposal

> >> > should have on the text a way Autonomous Systems must treat

> >> > announcements they receive as it's their own decision. Some may

> >> > decide to drop what is recommended and some might just lower

> >> > preference at their own discretion right ?

> >> >

> >> >

> >> >>

> >> >>

> >> >> On Tuesday, November 5, 2019, JORDI PALET MARTINEZ via RPD

> >> >> <rpd at afrinic.net <mailto:rpd at afrinic.net> <mailto:

> rpd at afrinic.net <mailto:rpd at afrinic.net>>> wrote:

> >> >>

> >> >> Hi Sylvain,

> >> >>

> >> >> El 5/11/19 6:11, "Sylvain Baya" <abscoco at gmail.com <mailto:

> abscoco at gmail.com>

> >> >> <mailto:abscoco at gmail.com <mailto:abscoco at gmail.com>>>

> escribi?:

> >> >>

> >> >> Hi all,

> >> >>

> >> >> Hope you are doing well.

> >> >>

> >> >> Please comments below (inline)...

> >> >>

> >> >>

> >> >>

> >> >> Le mardi 5 novembre 2019, JORDI PALET MARTINEZ via RPD

> >> >> <rpd at afrinic.net <mailto:rpd at afrinic.net> <mailto:

> rpd at afrinic.net <mailto:rpd at afrinic.net>>> a ?crit?:

> >> >>

> >> >> Hi all,

> >> >>

> >> >> [...]

> >> >> This is the list of new policy proposals (note that the

> >> >> numbering can be modified by the staff when published).

> >> >>

> >> >> 1) AFPUB-2019-IPv6-002-DRAFT01: "Adjusting IPv6 PA

> Policy"

> >> >> Solves a discrepancy between IPv6 PI and IPv6 PA

> >> >> regarding the announcement of aggregated addressing

> space.

> >> >>

> >> >> 2) AFPUB-2019-GEN-003-DRAFT01: "Chairs Elections Process"

> >> >> Including in the CPM a detailed procedure for the chair's

> >> >> elections.

> >> >>

> >> >> 3) AFPUB-2019-GEN-004-DRAFT01: "M&A Resource Transfers"

> >> >> Including in the CPM intra-RIR M&A for ASN, IPv4 and

> IPv6.

> >> >>

> >> >> 4) AFPUB-2019-GEN-005-DRAFT01: "Impact Analysis is

> Mandatory"

> >> >>

> >> >> 5) AFPUB-2019-GEN-006-DRAFT01: "RPKI ROAs for Unallocated

> >> >> and Unassigned AFRINIC Address Space"

> >> >>

> >> >> ...i like this one. I recall that i was thinking ok how to

> >> >> solve the problem of 'Internet resources

> >> >>

> >> >> squatting'. I was naively imagining a solution where a RIR

> >> >> will have to flag all their

> >> >>

> >> >> unallocated|unassigned Address Space ; via a particular

> >> >> attribute of the IRR (Internet Routing

> >> >>

> >> >> Registry). Now i understand that i was not too dummy or even

> >> >> crazy :-)

> >> >>

> >> >> Oh no! In that case the crazy one is me :-) !

> >> >>

> >> >> Please send me your DPP (Draft Policy Proposal), i can not

> >> >> wait more to review it ;-)

> >> >>

> >> >> Thanks.

> >> >>

> >> >> I was thinking in sending them in order (2 more today, 2 more

> >> >> tomorrow), but as you have interest in this one. My next one

> >> >> will be this one, I promise! Give me first a few minutes to

> >> >> respond to all the emails I got till now ?

> >> >>

> >> >> Shalom,

> >> >>

> >> >> --sb.

> >> >>

> >> >> Updated policy proposals:

> >> >>

> >> >> a) AFPUB-2019-ASN-001-DRAFT03: "Multihoming not required

> >> >> for ASN"

> >> >>

> >> >> b) AFPUB-2019-IPv4-002-DRAFT02: "IPv4 Inter-RIR Resource

> >> >> Transfers (Comprehensive Scope)"

> >> >>

> >> >> c) AFPUB-2018-GEN-001-DRAFT04: "Abuse Contact Policy

> Update"

> >> >>

> >> >> Regards,

> >> >> Jordi

> >> >> @jordipalet

> >> >>

> >> >> [...]

> >> >>

> >> >>

> >> >>

> >> >> --

> >> >>

> >> >> --

> >> >>

> >> >> ?Best Regards !

> >> >>

> >> >> Sylvain BAYA

> >> >>

> >> >> ?cmNOG's Co-Founder & Coordinator

> >> >>

> >> >> ?(+237) 677005341

> >> >>

> >> >> ?PO Box 13107 YAOUNDE / CAMEROON

> >> >>

> >> >> baya.sylvain [AT cmNOG DOT cm]

> >> >>

> >> >> ?abscoco2001 [AT yahoo DOT fr]

> >> >>

> >> >> http://www.cmnog.cm <http://www.cmnog.cm/>

> >> >>

> >> >> https://cmnog.wordpress.com <https://cmnog.wordpress.com/>

> >> >>

> >> >> ?************************

> >> >>

> >> >> ?#?LASAINTEBIBLE(?#?Romains15:33):"Que LE ?#?DIEU de ?#?Paix

> >> >> soit avec vous tous!?#?Amen!"

> >> >>

> >> >> ?#?MaPri?re est que tu naisses de nouveau.

> >> >>

> >> >> ?#?Chr?tiennement

> >> >>

> >> >> ? ? ? ? ? ?? Comme une biche soupire apr?s des courants

> >> >> d?eau, Ainsi mon ?me soupire apr?s toi, ? DIEU! ? (Psaumes

> 42 :2)

> >> >>

> >> >>

> >> >> _______________________________________________ RPD mailing

> >> >> list RPD at afrinic.net <mailto:RPD at afrinic.net> <mailto:

> RPD at afrinic.net <mailto:RPD at afrinic.net>>

> >> >> https://lists.afrinic.net/mailman/listinfo/rpd <

> https://lists.afrinic.net/mailman/listinfo/rpd>

> >> >> <https://lists.afrinic.net/mailman/listinfo/rpd <

> https://lists.afrinic.net/mailman/listinfo/rpd>>

> >> >>

> >> >>

> >> >> **********************************************

> >> >> IPv4 is over

> >> >> Are you ready for the new Internet ?

> >> >> http://www.theipv6company.com <

> http://www.theipv6company.com/>

> >> >> The IPv6 Company

> >> >>

> >> >> 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.

> >> >>

> >> >>

> >> >> _______________________________________________

> >> >> RPD mailing list

> >> >> RPD at afrinic.net <mailto:RPD at afrinic.net> <mailto:

> RPD at afrinic.net <mailto:RPD at afrinic.net>>

> >> >> https://lists.afrinic.net/mailman/listinfo/rpd <

> https://lists.afrinic.net/mailman/listinfo/rpd> <

> https://lists.afrinic.net/mailman/listinfo/rpd <

> https://lists.afrinic.net/mailman/listinfo/rpd>>

> >> >

> >> >

> >> > _______________________________________________

> >> > RPD mailing list

> >> > RPD at afrinic.net <mailto:RPD at afrinic.net>

> >> > https://lists.afrinic.net/mailman/listinfo/rpd <

> https://lists.afrinic.net/mailman/listinfo/rpd>

> >> -------------- next part --------------

> >> An HTML attachment was scrubbed...

> >> URL: <

> https://lists.afrinic.net/pipermail/rpd/attachments/20200104/a1cf786d/attachment.html

> <

> https://lists.afrinic.net/pipermail/rpd/attachments/20200104/a1cf786d/attachment.html

> >>

> >>

> >> ------------------------------

> >>

> >> Subject: Digest Footer

> >>

> >> _______________________________________________

> >> RPD mailing list

> >> RPD at afrinic.net <mailto:RPD at afrinic.net>

> >> https://lists.afrinic.net/mailman/listinfo/rpd <

> https://lists.afrinic.net/mailman/listinfo/rpd>

> >>

> >>

> >> ------------------------------

> >>

> >> End of RPD Digest, Vol 160, Issue 5

> >> ***********************************

> >>

> >> _______________________________________________ RPD mailing list

> RPD at afrinic.net <mailto:RPD at afrinic.net>

> https://lists.afrinic.net/mailman/listinfo/rpd <

> https://lists.afrinic.net/mailman/listinfo/rpd>

> >>

> >>

> >> **********************************************

> >> IPv4 is over

> >> Are you ready for the new Internet ?

> >> http://www.theipv6company.com <http://www.theipv6company.com/>

> >> The IPv6 Company

> >>

> >> 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.

> >>

> >> _______________________________________________

> >> RPD mailing list

> >> RPD at afrinic.net <mailto:RPD at afrinic.net>

> >> https://lists.afrinic.net/mailman/listinfo/rpd <

> https://lists.afrinic.net/mailman/listinfo/rpd>

> >>

> >>

> >>

> >> **********************************************

> >> IPv4 is over

> >> Are you ready for the new Internet ?

> >> http://www.theipv6company.com <http://www.theipv6company.com/>

> >> The IPv6 Company

> >>

> >> 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.

> >>

> >> -------------- next part --------------

> >> An HTML attachment was scrubbed...

> >> URL: <

> https://lists.afrinic.net/pipermail/rpd/attachments/20200106/1c079e32/attachment.html

> <

> https://lists.afrinic.net/pipermail/rpd/attachments/20200106/1c079e32/attachment.html

> >>

> >>

> >> ------------------------------

> >>

> >> Subject: Digest Footer

> >>

> >> _______________________________________________

> >> RPD mailing list

> >> RPD at afrinic.net <mailto:RPD at afrinic.net>

> >> https://lists.afrinic.net/mailman/listinfo/rpd <

> https://lists.afrinic.net/mailman/listinfo/rpd>

> >>

> >>

> >> ------------------------------

> >>

> >> End of RPD Digest, Vol 160, Issue 15

> >> ************************************

> >> _______________________________________________

> >> RPD mailing list

> >> RPD at afrinic.net <mailto:RPD at afrinic.net>

> >> https://lists.afrinic.net/mailman/listinfo/rpd <

> https://lists.afrinic.net/mailman/listinfo/rpd>

> >

>

> -------------- next part --------------

> An HTML attachment was scrubbed...

> URL: <

> https://lists.afrinic.net/pipermail/rpd/attachments/20200110/b9431148/attachment.html

> >

>

> ------------------------------

>

> Subject: Digest Footer

>

> _______________________________________________

> RPD mailing list

> RPD at afrinic.net

> https://lists.afrinic.net/mailman/listinfo/rpd

>

>

> ------------------------------

>

> End of RPD Digest, Vol 160, Issue 23

> ************************************

>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20200110/b100d22e/attachment-0001.html>


More information about the RPD mailing list