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

On Wed, Oct 07, 2020 at 04:50:43PM +0200, Horváth Ágoston János via db-wg wrote:
> You are aware you ignored 90% of my points and picked a single one out of
> my email?

Correct. The rest of the email is interesting but directly related to
the contents of a geofeed file, which is a discussion more suitable for
OPSAWG in IETF. https://datatracker.ietf.org/wg/opsawg/about/

Some of your remarks were redundant, for instance "A clear specification
of the geofeed: property is necessary to forego abuse." - in the initial
email I pointed out that the [red: whois server side] attribute value
should be validated using for example "org.apache.commons.validator.UrlValidator"
Inserting HTML code in the attribute value would not consitute a valid
URL.

> 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.

The proposal is to make it possible to include a structured reference to
a geofeed file. Geofeed file consumption & parsing is something I
consider outside the scope of the RIPE database working group.

More discussion is helpful, but the topic at hand for RIPE DB-WG really
is no more than "can a new optional attribute be introduced ("geofeed:")
whose attribute value will contain a URL.

Kind regards,

Job