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