[rpd] AFPUB-2019-GEN-006-DRAFT01: "RPKI ROAs for Unallocated and Unassigned AFRINIC Address Space"

[Anthony Ubah]

Got it. Thanks for the clarification.


On Tue, Jan 7, 2020, 16:22 Owen DeLong <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> 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> wrote:

>

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

>> To: <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>

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

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

>>

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

>>

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

>>

>> Skype: kakel.mbumb1

>>

>>

>>

>>

>>

>>

>>

>> Le sam. 4 janv. 2020 ? 12:07, <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. 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>

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

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

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

>> >

>> >

>> >> On Dec 30, 2019, at 06:38 , Paschal Ochang <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

>> > 24

>> > 65550

>> > 192.0.2.0/24

>> > 64498

>> > Invalid

>> >

>> > 192.0.2.0/24

>> > 24

>> > 65550

>> > 192.0.2.0/28

>> > 64498

>> > Invalid

>> >

>> > 192.0.2.0/24

>> > 24

>> > 65550

>> > 192.0.2.0/24

>> > 65550

>> > Valid

>> >

>> > 192.0.2.0/24

>> > 24

>> > 65550

>> > 192.0.2.0/28

>> > 65550

>> > Invalid

>> >

>> > 192.0.2.0/28

>> > 28

>> > 65550

>> > 192.0.2.0/24

>> > 64498

>> > Unknown

>> >

>> > 192.0.2.0/28

>> > 28

>> > 65550

>> > 192.0.2.0/24

>> > 65550

>> > Unknown

>> >

>> > 192.0.2.0/28

>> > 28

>> > 65550

>> > 192.0.2.0/28

>> > 64498

>> > Invalid

>> >

>> > 192.0.2.0/28

>> > 28

>> > 65550

>> > 192.0.2.0/28

>> > 65550

>> > Valid

>> >

>> > 192.0.2.0/24

>> > 24

>> > 65550

>> > 192.0.2.64/26

>> > 65550

>> > Invalid

>> >

>> > 192.0.2.0/24

>> > 28

>> > 65550

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

>>

>> >

>> > 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>> wrote:

>> >> Hi Sylvain,

>> >>

>> >>

>> >>

>> >>

>> >>

>> >>

>> >>

>> >> El 5/11/19 6:11, "Sylvain Baya" <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>> 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>

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

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

>> >

>> >

>>

>>

>>

>> --

>> Best Regards !

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

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

>> Subscribe to Mailing List : <

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

>> To: Paschal Ochang <pascosoft at gmail.com>, "rpd >> AfriNIC Resource

>>         Policy" <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>

>> 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>> 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>> wrote:

>> >>

>> >>         Hi Sylvain,

>> >>

>> >>         El 5/11/19 6:11, "Sylvain Baya" <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>> 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

>> >>

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

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

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

>> >

>> >

>> > _______________________________________________

>> > 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/20200104/a1cf786d/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 5

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

>>

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

>>

>>

>>

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

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

>>

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

>> An HTML attachment was scrubbed...

>> URL: <

>> https://lists.afrinic.net/pipermail/rpd/attachments/20200106/1c079e32/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 15

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

>>

> _______________________________________________

> 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/20200107/1d51abab/attachment-0001.html>