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

[Wijdane Goubi]

Hello,

I agree with what Anthony said, and it is far more reasonable to consider
the potential consequences of this policy rather than continue to promote
it, and the question posed should have a sufficient answer because the end
purpose is to safeguard resources.

Additionally, regardless of the value of IP addresses on a worldwide scale,
this practice is carried out without adequate compensation. We should be
concerned about the high danger of putting the company in a tough
commercial scenario by having the capacity to withdraw the provided number
of resources at any time, as well as the possibility of creating service
disruption. These are legitimate issues that we should consider. This only
serves to demonstrate that this policy does not provide adequate
compensation, prompting us to ask the following questions: who will ensure
that the asset value of intellectual property is preserved and properly
protected, and who will be ultimately responsible for the financial
consequences of anything that goes wrong with this policy?

Finally, this policy needs to be revisited, and we need to address these
concerns, which are not only dangerous and damaging, but also have a huge
influence on the company's network infrastructure, which must be protected
at all costs.

Regards,
Wijdane

Le dim. 4 juil. 2021 à 02:46, Anthony Ubah <ubah.tonyiyke at gmail.com> a
écrit :


> Hi,

>

> Reading through the back and forth between Noah and Owen, and the well

> stated submission by Mark, it beats me that Afrinic is still interested in

> moving forward with this policy. Beautiful Policy in theory, but

> a potential monster in reality.

>

> In line with Owen's argument in the preceding thread (which is still

> pending address), we are all aware that these "assumptions" have teeth and

> thus have a bite to it. I'll repeat my old question: "When a "staff", or

> machines manned by a staff at afrinic "erroneously" caused service

> disruption, *who bears the final financial brunt for the consequences of

> everything that can go wrong with this policy. Afrinic? or resource owner?"*

>

> This message from the AFRINIC Policy Liaison still conspicuously fails to

> address this issue. Closing our eyes to this doesn't mean it's not there,

> and definitely won't make it disappear.

>

> This policy may be a Nice-To-Have just like tobacco, but a trip down that

> slope is not as easy back up.

> There is a reason some other RIRs are rejecting it, and the region needs

> to know why.

>

> *Best Regards,*

>

> *Anthony Ubah  *

>

>

> On Tue, Jun 29, 2021 at 9:11 AM AFRINIC Policy Liaison <

> policy-liaison at afrinic.net> wrote:

>

>>

>>

>>

>>

>>

>>

>>

>> * Dear PDWG, We have noted your concerns raised during the Last Call in

>> respect of  RPKI ROAs for Unallocated and Unassigned AFRINIC Address Space

>> AFPUB-2019-GEN-006-DRAFT03, and we wish to assure you as follows: 1.

>> AFRINIC’s adopted policies are incorporated by reference to its

>> Registration Service Agreement (RSA) and consequently, both AFRINIC and its

>> Resource Members are bound to the terms thereof; 2. AFRINIC’s staff are

>> bound to act in accordance with and to give effect to the aforesaid RSA; 3.

>> In regard to AFRINIC’s delegated resources, status change updates e.g. from

>> allocated/assigned to ‘reserved’ and at a later stage to ‘available’ are

>> only effected when the concerned resources either have been returned to

>> AFRINIC by the Resource Member or following their de-registration from the

>> WHOIS database of the said Resource Member subsequent to the termination of

>> the RSA; 4. Termination of the RSA is triggered as a last resort pursuant

>> to the terms of the RSA, after having offered the Resource Member the

>> opportunity to remedy any identified breach(es); 5. As a consequence of the

>> WHOIS deregistration, the resources are considered as bogons and those

>> still using the resources will experience connectivity issues; 6. The

>> AFRINIC team has the capacity to implement this policy. Technically, at a

>> high level, this implementation will be quite similar to the current RPKI

>> infrastructure. This same infrastructure has undergone several major

>> changes which the team carried out successfully, examples are;  - Changes

>> from single trust anchor (TAL) to split TAL - RPKI V2.0

>> https://www.afrinic.net/library/news/1407-rpki-v20-announcement-to-the-public

>> <https://www.afrinic.net/library/news/1407-rpki-v20-announcement-to-the-public>

>> - All resources trust anchor

>> https://afrinic.net/rpki-moving-towards-an-all-resources-trust-anchor

>> <https://afrinic.net/rpki-moving-towards-an-all-resources-trust-anchor>  -

>> Additionally there have been operations in recent years where resources

>> received from IANA were added to RPKI. We believe this demonstrates enough

>> capacity. 1. The impact assessment of the aforementioned proposal will be

>> updated to reflect that should this proposal reach consensus and is

>> ratified, the implementation will be done on a new (separate) Trust Anchor

>> so that it becomes an opt-in service and does not impact the current RPKI

>> setup. Regards Policy Liaison Team*

>>

>> --

>> AFRINIC Policy Liaison.

>> t: +230 403 51 00 | f: +230 466 6758 | tt: @afrinic | w:www.afrinic.netfacebook.com/afrinic | flickr.com/afrinic | youtube.com/afrinicmedia

>>

>> _______________________________________________

>> 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/20210705/aff42989/attachment.html>