[db-wg] Source GRS vs RIPE

> 
> If I go by the list published the RIPE NCC themself.
> https://ftp.ripe.net/pub/stats/ripencc/delegated-ripencc-latest
> The 188.64.224.0/21 prefix is not allocated at all.
> 
> Why Twitter is announcing it. < scratching head for answers >
> https://stat.ripe.net/188.64.224.0-188.64.231.255?sourceapp=ripedb#tabId=database

I see 7 such announcements originated by AS13414:

188.64.224.0/24 AS13414 Prefix is within unallocated space: 188.64.224.0 - 188.64.231.255
188.64.225.0/24 AS13414 Prefix is within unallocated space: 188.64.224.0 - 188.64.231.255
188.64.226.0/23 AS13414 Prefix is within unallocated space: 188.64.224.0 - 188.64.231.255
188.64.226.0/24 AS13414 Prefix is within unallocated space: 188.64.224.0 - 188.64.231.255
188.64.227.0/24 AS13414 Prefix is within unallocated space: 188.64.224.0 - 188.64.231.255
188.64.228.0/24 AS13414 Prefix is within unallocated space: 188.64.224.0 - 188.64.231.255
188.64.229.0/24 AS13414 Prefix is within unallocated space: 188.64.224.0 - 188.64.231.255

Of course Twitter is doing nothing uniquely unusual in this respect, as these are just 7 examples from a pool of some 300 announcements of unallocated address space (a list of such bogons can be found at http://www.cidr-report.org/as2.0/#Bogons)

- Why is Twitter announcing these prefixes? 

   I have no idea. Something has gone wrong here and the address has come back to the RIR and Twitter apper to be unaware of this.

- How and why is this prefix in RADB, given that it is unallocated space? 

   Good question - I wonder what periodic checks the RADB undertakes on the data held in its registry?

- Why do upstream AS’s accept these advertised prefixes? 

   Maybe they chose to believe that RADB performs robust periodic integrity checks? 
   Or <insert reason here>?

Geoff