Hi Massimo Does this mean geofeed values are only meaningful when used as a collection and not individually? Take this example with a /16 and a more specific /24 both having a geofeed attribute. If I query for an address within the /16 but outside of the more specific /24 I will get the INETNUM object for the /16 with it's geofeed attribute. But the data contained in the referenced file may not be correct for the more specific /24 range which has it's own referenced file.
So for anyone using this data do you have to query for all objects containing a geofeed attribute and download all the referenced files to be sure of having correct information? Having downloaded all the data you would then have to correlate the data to check for overlapping values, discarding the less specific data for the /24 in this example. Is this how it works or have I missed something? cheers denis co-chair DB-WG On Thu, 6 May 2021 at 20:27, Massimo Candela via db-wg <[email protected]> wrote: > > Hi Hank, > > > On 06/05/2021 07:18, Hank Nussbacher via db-wg wrote: > > > What if you have a /16 as recorded by inetnum: as well as an RPKI > > certificate for that /16 but within the /16 there is a /24 that has been > > assigned to some other ASN? Can you publish a geofeed file for the /16? > > > What if there is no inetnum: listed for that /24 yet in the global BGP > > tables there is an announcement of that /24 from a different ASN - would > > you still accept the geofeed announcement for the /16 based on inetnum: > > and RPKI cert? > > ASNs and BGP announcements do not come into play. > If a /16 inetnum has a geofeed link, the pointed file can specify > entries covering the /16. If a /24 inetnum with geofeed link exists, > this takes priority for that /24 portion. RPKI signature (optional) can > be used -after- the inetnum hierarchy is resolved to verify ownership of > the prefix. > > > Ciao, > Massimo > > > >
