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 <[email protected]> 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 > >
