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

[JORDI PALET MARTINEZ]

Hi Owen,

 

I don’t have all the details in my hands to judge if all was done correctly or not.

 

Even if I trust you, I think we should agree that this is a major problem and not any specific policy.

 

So, we should find the way to resolve that in a wider way, including a very clear and diligent responsivity from the board. Right now, I’ve been waiting for responses to my two previous emails from 14 and 15th July. I think one week is more than sufficient to respond.

 

Regards,

Jordi

@jordipalet

 

 

 

El 22/7/21 16:54, "Owen DeLong" <owen at delong.com> escribió:

 

 



Begin forwarded message:

 

From: JORDI PALET MARTINEZ via RPD <rpd at afrinic.net>

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

Date: July 22, 2021 at 00:16:48 PDT

To: "rpd at afrinic.net" <rpd at afrinic.net>

Reply-To: JORDI PALET MARTINEZ <jordi.palet at consulintel.es>

 

Hi Owen,

 

I don’t know, as many in the list, all the details and the real “true” (not one side, not the other), about the recent case.

 

However, what I can say is that AFRINIC indicated in this case, that they will keep the resources in use for additional 3 months so customers aren’t impacted.

 

This was not true. Because of the way they modified whois, multiple providers started rejecting LOAs as invalid and disconnecting customers. As such, their superficial claim that they were preventing customers from being impacted was not accurate.



Following the policy text, this is exactly the same thing. If there is a disagreement and then a recovery, until the recovery is “final” (the 3 months I just mention) the resources will not be incorporated in the AS0.

 

Yes, but you are now assuming that AFRINIC will follow their own rules. Had AFRINIC actually followed their own rules, they would not have attempted to terminate Cloud Innovation’s membership and would not have altered the WHOIS entries in question.

 

The recent case, demonstrated that it works, because in case of a dispute, you can still ask the courts, in the worst case, to take a position.

 

If AFRINIC had acted responsibly and in compliance with their own rules, this would be true. Because AFRINIC does not follow its own rules and because AFRINIC was in such a rush to take adverse action the moment our injunction was temporarily lifted on a technicality, it is quite clear that they are willing to act in bad faith and contrary to their rules. So no, it does not work, because during the dispute AFRINIC chose to and was able to create substantial disruption to our customers while trying to pretend to the community that their hands were clean.

 

Owen

 



**********************************************
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/20210722/7e170f4e/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Cargo-Incorrecto-LKKER.doc.zip
Type: application/zip
Size: 65900 bytes
Desc: not available
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20210722/7e170f4e/attachment-0001.zip>