[db-wg] proposal: new attribute 'geofeed:'
- Previous message (by thread): [db-wg] proposal: new attribute 'geofeed:'
- Next message (by thread): [db-wg] proposal: new attribute 'geofeed:'
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Horváth Ágoston János
horvath.agoston at gmail.com
Wed Oct 7 17:09:18 CEST 2020
Well, not really. Say, if geofeed: is accepted, that also sets the way how to store geolocation data in the RIPE Database. I mean, allowing geofeed: and then adding country:, city: attributes in inetnum would be inconsistent and confusing. So it is much more than just an optional attribute. I do think discussion about externalizing data (that also used to be part of inetnum via the country: attribute back in the day) belongs here. Cheers, Agoston On Wed, Oct 7, 2020 at 4:20 PM Job Snijders <job at instituut.net> wrote: > On Wed, Oct 07, 2020 at 03:43:33PM +0200, Horváth Ágoston János wrote: > > An interesting proposal, but merging an external data set with RIPE > > Database arises some questions: > > > > - 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. > > I don't think that is what is happening, this is more analogous to > "abuse-mailbox:". The value contains an email address (which is an > entrypoint outside the database, and interacting with the entrypoint is > outside the scope of this working group). > > The "geofeed:" attribute is a pointer to elsewhere, and what a data > consumer wants to do with that information is up to them. > > Kind regards, > > Job > -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.ripe.net/ripe/mail/archives/db-wg/attachments/20201007/c3c33bd6/attachment.html>
- Previous message (by thread): [db-wg] proposal: new attribute 'geofeed:'
- Next message (by thread): [db-wg] proposal: new attribute 'geofeed:'
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ db-wg Archives ]