[rpd] End of LAST call

[Daniel Yakmut]

My  perceptions and understanding can be different, but that doesn't 
mean lack of understanding, because your effort at explaining shows that 
my concerns touch on the subject of ROA.

I have seen a similar opposing argument on the same policy proposal in 
RIPE NCC. Possibly my argument was not clear enough, but yes revocation 
can be impactful.

Simply,

Daniel


On 31/01/2020 7:03 am, Owen DeLong wrote:

>

>

>> On Jan 30, 2020, at 21:51 , Daniel Yakmut <yakmutd at googlemail.com 

>> <mailto:yakmutd at googlemail.com>> wrote:

>>

>> I don't agree with your submission that; "All of the “objections” I 

>> saw seemed to indicate a clear lack of understanding of RPKI in 

>> general and the proposal in specific."

>>

>> I particularly raised a concern "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"

>>

>>

> I’m not sure where to start with this… It clearly does indicate a lack 

> of understanding of both RPKI and of the proposed policy.

>

> RPKI in its current state can operate near real time. In general, I 

> believe operators are updating their caches at least once every 24 hours.

>

> As such, a revocation would (in the vast majority of cases) take 

> effect within 24 hours of the block being issued.

>

> Further, a new ROA created by the recipient of a block would override 

> the less specific ROA issued by the RIR.

>

> The worst possible outcome of any such delay is that the AS0 ROA 

> delays the useful deployment of a newly issued block. It will not harm 

> the continued use of an existing block.

>

> Such delay would be less than 24 hours in the vast majority of cases. 

> I don’t see this as a problem.

>

>> and I did not receive any response from the author(s), I suspect this 

>> is a concern that is critical and important to possible adoption and 

>> implementation this proposal

>>

> Interesting… I thought I recalled the authors responding to this along 

> the lines of what I stated above.

>

>> However, I will agree that the author(s) may have been overwhelm with 

>> the number of "objections" raised and could not keep track of it and 

>> response, hence I will suggest that the co-chairs could help by 

>> summarising the objections for the action of the author(s).

>>

> I don’t think your objection requires action by the authors. The 

> current process is adequate despite your claims to the contrary.

>

> Owen

>

>> Simply.

>>

>> Dan

>>

>>

>>

>>

>> On 31/01/2020 3:18 am, Owen DeLong wrote:

>>> I agree with Nishal, Jordi, and Frank.

>>>

>>> All of the “objections” I saw seemed to indicate a clear lack of understanding of RPKI in general and the proposal in specific.

>>>

>>> All of them raised concerns that simply don’t fit the facts of what is being proposed.

>>>

>>> I did not see any legitimate or critical objections. If there is something I missed, please enumerate it (them) for the edification of the list.

>>>

>>> Owen

>>>

>>>

>>>> On Jan 29, 2020, at 03:58 , Nishal Goburdhan<nishal at controlfreak.co.za>  wrote:

>>>>

>>>> On 29 Jan 2020, at 12:35, ABDULKARIM AYOPO OLOYEDE wrote:

>>>>

>>>>> Dear PDWG,

>>>>> The following policy proposals have been on the Last call for about 4 weeks

>>>>> 1.  Multihoming not required for ASN

>>>>> 2.  Adjusting IPv6 PA Policy

>>>>> 3. RPKI ROAs for Unallocated and Unassigned AFRINIC Address Space

>>>>>

>>>>> However, we received some critical objections that should be addressed on

>>>>> the policy named  "RPKI ROAs for Unallocated and Unassigned AFRINIC Address

>>>>> Space" therefore we believe it requires more discussion.

>>>> could you enumerate those “critical objections” please.  that would help the authors to fix this for round two.

>>>> from my perspective, the last series of responses, came from a fundamental misunderstanding of what RPKI is, and how it works.

>>>>

>>>> (bear in mind, that it’s not the authors’ - or this list’s - responsibility to explain RPKI ..)

>>>>

>>>> -n.

>>>>

>>>> _______________________________________________

>>>> 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/20200201/f4a5959e/attachment-0002.html>