[rpd] Last Call - RPKI ROAs for Unallocated and Unassigned AFRINIC Address Space AFPUB-2019-GEN-006-DRAFT03.

Tue Jun 15 22:02:04 UTC 2021

I suppose I can state my opinion without been hoodwinked. In the 
academic world your argument is substantially wrong. You can't continue 
investigating a matter so long the basis - problem is faulty, because 
the outcome will definitely be incorrect.

That aside, I have from day one unimpressed with the policy and hence I 
have no reason to agree otherwise.

*Consensus *here is highly subjective, and I have seen and learnt about 
that here in this PWDG.

Simply,

Daniel

On 15/06/2021 7:06 pm, Fernando Frediani wrote:
>
> Hi, could please stop trying to fish minor reasons to stop this policy 
> which already reached consensus ?
>
> Throughout the entire discussion which has happened for almost 18 
> months I don't remember of a single person complaining about the 
> problem statement as a reason to oppose this proposal. Then one person 
> who supports it says that in *his vision* some information lacked then 
> that becomes a reason to discard a proposal which already reached 
> consensus ?
> Furthermore understanding of problem statement is subjective. Some 
> people may have difficulty some not, based on their technical 
> understanding. And above all problem statement alone is not a reason 
> to invalid a proposal. I personally understood the problem well and 
> benefited from the discussion to getter a better understanding with 
> the help of the technical understand about the subject.
>
> If there were critical issues in there that would have been pointed 
> throughout the discussion and it wasn't.
>
> Let's just be more rational and also discuss things within the 
> appropriate timeframe.
> Regards
> Fernando
>
> On 15/06/2021 14:03, Daniel Yakmut via RPD wrote:
>> If I will add, if the problem wasn't well stated or defined, could it 
>> also mean that there was no problem in the first instance?
>>
>> Then we can possibly say that the policy is a non issue and should be 
>> discarded.
>>
>> Simply
>> Daniel
>>
>> On Tue, Jun 15, 2021, 4:59 PM Paschal Ochang <pascosoft at gmail.com 
>> <mailto:pascosoft at gmail.com>> wrote:
>>
>>     Hello, Find my comments inline.
>>
>>     On Tuesday, June 15, 2021, Noah <noah at neo.co.tz
>>     <mailto:noah at neo.co.tz>> wrote:
>>
>>         Hi Job,
>>
>>         On Mon, Jun 14, 2021 at 2:12 PM Job Snijders <job at fastly.com
>>         <mailto:job at fastly.com>> wrote:
>>
>>             On Sat, Jun 12, 2021 at 09:01:03PM +0300, Noah wrote:
>>             > While this was resolved within 10mins, were there
>>             measures put in place by
>>             > the NCC as mitigation process to curb a repeat of the
>>             incident?
>>
>>             This problem lasted more than 70 minutes!
>>
>>             The point I am trying to make: once an RIR automatically
>>             creates AS0
>>             ROAs for unallocated/unassigned space, any database
>>             incidents where the
>>             registration status of a resource accidentally (and
>>             temporarily) lapses,
>>             can result in blocklisting via AS0.
>>
>>             The risk of things going wrong at a future point in time
>>             versus the
>>             perceived benefits of such ROAs don't align well.
>>
>>             The best measure to put in place to curb incidents is to
>>             not implement
>>             this type of policy.
>>
>>
>>         There are several of us who support this policy for valid
>>         reasons, some of which are founded on the premise [1] that
>>         you shared with the APNIC region back in 2019.
>>
>>
>>         [1]
>>         https://mailman.apnic.net/mailing-lists/sig-policy/archive/2019/08/msg00065.html
>>         <https://mailman.apnic.net/mailing-lists/sig-policy/archive/2019/08/msg00065.html>
>>
>>
>>         And if you look at the bogons [2] currently seen in the
>>         global routing table, one can easily find the prefixes from
>>         AFRINIC pool, some being advertised by unassigned ASNs.
>>
>>
>>         [2] http://thyme.rand.apnic.net/current/data-add-IANA
>>         <http://thyme.rand.apnic.net/current/data-add-IANA>
>>
>>
>>         It isunfortunate that the problem statement of the proposal
>>         is not well defined to allow a better understanding of the
>>         problem being addressed andthe assessment of the benefits vs
>>         risks.
>>
>>
>>     Well if the problem statement of the proposal is not Well defined
>>     as you said, then the proposal is not well drafted  and that's a
>>     problem. In research if your problem statement is not well
>>     defined your research justification is also not tenable.
>>
>>
>>         Yes.....Thingscan go wrong at many layers and at different
>>         levels, however, the entitled parties shall play their
>>         roleand we all learn from incidents and keep improving.
>>
>>     Well there are some lessons you don't wonna experience or learn
>>     from you might come out too charred to survive.
>>
>>
>>         The issuance of AS0 ROAs should follow the conservative
>>         approach RIRs use in managing changes in number ressources
>>         status, the addition of INRs to bogon list, subject to AS0 ROAs.
>>
>>
>>         In my humble opinion.
>>
>>
>>         Cheers,
>>
>>         Noah
>>
>>
>>
>>     -- 
>>     Kind regards,
>>
>>     Paschal.
>>
>>     _______________________________________________
>>     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
>
> _______________________________________________
> 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/20210615/e7b319c6/attachment.html>