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

[Owen DeLong]

> On Jul 27, 2021, at 02:37 , Sylvain Baya <abscoco at gmail.com> wrote:

> 

> Dear PDWG,

> 

> Le mar. 27 juil. 2021 à 5:34 AM, Owen DeLong via RPD <rpd at afrinic.net <mailto:rpd at afrinic.net>> a écrit :

> 

>> [...]

> 

> As you wish:

> 

> AFRINIC may only issue AS0 ROAs for addresses which have never been issued. Any

> space returned to the registries free pool post allocation shall not have an AS0 ROA

> applied until such time as:

> 	1.	Any existing ROA is voluntarily repealed by the previous resource registrant.

> and	2.	The previous resource registrant has issued a duly apostilled notice from a

> 		corporate officer authorizing AFRINIC to reissue the space to other parties.

> and	3.	No party has any pending litigation or dispute regarding the space in question.

> 

> How’s that for safe policy?

> 

> 

> Hi Owen,

> Thanks for your email, brother.

> 

> ...if that is your safer version of this DPP, 

> which is about to be ratified; then i would recommend you to submit a new DPP,  if you dislike the *ratifying* one.

> 

> What is the benefit of a policy which might not be able to fix the problem it was writen to solve?

> 

> ...possible scenario:

> 

> ~°~

> 1. A resource member (RM) failed to 

> conform to either the CPM or the RSA.


Alternative scenario as is currently an active case:

AFRINIC misinterprets their own policy documents and goes on a vindictive witch hunt
claiming a member violated the CPM and/or RSA and/or bylaws despite them being in
compliance with all of the above.


> 2. The regional RIR exercice its duty and 

> enforce the procedure which apply to 

>  that situation.


Alternatively: The RIR enforces procedures which are not authorized.


> 3. After hardly try all what is prescribed 

> to help the said RM; RIR's Staff proceed 


Alternatively: After utterly and completely ignoring the contrary arguments from the RM.


> 4. The service seize to be delivered 


Thus forcing the RM to seek injunctive relief (hopefully before the RIR is able to act in
this manner)


> 5. No more IRR objects, attached to the 

> INRs holded by the said RM are available

>  under the RIR's database: deregistration!


In this case, they only defaced the WHOIS records and made a defamatory public announcement,
but even that had far reaching and unjustified consequences to the RM.


> 6. The said RM go to an open IRR 

> database maintainer and subscribe to an

>  alternative service.


Not sure how this is relevant to the discussion.


> 7. The price out there is far higher than 

> the fee previously paid to the RIR office 

> for the full registration, including that 

> very service.


Again, not sure how this is relevant to the discussion.


> 8. The alternate/open IRR maintainer 

> receive the expected money and satisfy 

> the needs of the previous RIR's RM:


IRRs only provide route objects and aut-num objects. They don’t run whois and don’t
provide RPKI services. They don’t provide network registration WHOIS data.


> 9. all the desired IRR objects are inserted

>  into the alternate/open IRR's database, 

> and advertised.


Anyone can put pretty much anything into most IRR databases.


> 10. Problem solved for the former RIR's 

> RM.


Hardly.


> 11. RIR's System bypassed! :'-(


I guess the question here boils down to the fundamental nature of RIRs. While I know it is common place for people to talk about them as if
they were regulatory bodies, in reality, they are not. They have no force of law and their only authority comes from the willingness of operators
who run actual routers to listen to them. If an RIR begins issuing malicious and invalid AS0 ROAs, it is just as likely to lead to the discrediting
of that RIR’s AS0 ROAs as it is to the destruction of the targeted Resource Member. It’s a total loose-loose situation, but the first few targeted
resource members lose hard while the RIR loses only the credibility of one service it provides in the process.


> 12. The End! ???


Only if you ignore recent history.

Owen

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20210727/7d54a447/attachment.html>