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

[rpd] End of LAST call

Daniel Yakmut yakmutd at googlemail.com
Sat Feb 1 21:38:33 UTC 2020


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>


More information about the RPD mailing list