[db-wg] proposal: new attribute 'geofeed:'

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 at 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/db-wg/attachments/20201007/b63919e4/attachment.html>