Search RPD Archives
[rpd] AFPUB-2019-GEN-006-DRAFT01: "RPKI ROAs for Unallocated and Unassigned AFRINIC Address Space"
Mike Silber
silber.mike at gmail.com
Fri Jan 10 17:29:59 UTC 2020
I don’t think this is a case of “getting it wrong”, but rather a
misunderstanding of the standard.
Kakel - can you please confirm if you have actually read RFC 3779? If so -
can you please explain where in the RFC you derive the source for your wild
and seemingly unsubstantiated statements?
If your objection is to be considered - it needs to be understood.
Accordingly the obligation is on you to explain the substance of your
objection.
Thanks
Mike
On Fri, 10 Jan 2020 at 18:48, JORDI PALET MARTINEZ via RPD <rpd at afrinic.net>
wrote:
> Hi Kakel,
>
>
>
> As I already explained before, you’re getting it wrong.
>
>
>
> There is no such centralization of the control and even less from
> governments.
>
>
>
> Unless you can clearly explain how this can be done, it is not a valid
> objection.
>
>
>
> Regards,
>
> Jordi
>
> @jordipalet
>
>
>
>
>
>
>
> El 10/1/20 15:46, "Kakel Mbumb" <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.
>
> *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
> ************************************
>
> _______________________________________________ RPD mailing list
> RPD at afrinic.net https://lists.afrinic.net/mailman/listinfo/rpd
>
> **********************************************
> IPv4 is over
> Are you ready for the new Internet ?
> 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
> https://lists.afrinic.net/mailman/listinfo/rpd
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20200110/6c19a471/attachment-0001.html>
More information about the RPD
mailing list