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
