[db-wg] New NWI for geofeed?

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 <db-wg at ripe.net> 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
>
>
>
>