You are aware you ignored 90% of my points and picked a single one out of my email?

But let me answer this with an example.

Say, 192.168/16 has 5 children, each a /24.

You put in the geofeed file for a single 192.168/16 a /20, covering four of these.

The /20 does not exist in the RIPE DB. So a client has to be smart enough to match the prefixes from the RIPE DB, while also checking the children of 192.168/16 for more specific geofeed: attributes.

Doable, of course, but this is left open in the draft.

And there is the issue with inetnum ranges. What if 192.168/16 has a child 192.168.0.7-192.168.0.25. You make a geofeed prefix for 192.168.0.0/27? Or /28? What should the client do when it encounters prefixes 192.168.0.0/30 and 192.168.0.24/30 in the geofeed file ?

Again, open question.

Read my email.

Agoston

On Wed, Oct 7, 2020 at 4:03 PM Randy Bush via db-wg <db-wg@ripe.net> wrote:

> - RIPE Database is set up to contain hierarchical data already. With this
> proposal, we would take some of this data outside the database in a manner
> that does not guarantee consistency with the database itself. For example,
> 192.168/16 specifies a geofeed file that has different prefixes in it than
> the children of said inetnum (or cover a range that is not even listed in
> the RIPE Database).

from the i-d

When using data from a geofeed file, one MUST ignore data outside of
the inetnum: object's inetnum: attribute's address range.

please read the draft

randy