Hi Massimo On Fri, 29 Jul 2022 at 04:11, Massimo Candela via db-wg <db-wg@ripe.net> wrote:
Hi,
On 28/07/2022 15:52, Randy Bush via db-wg wrote:
and, being a researcher, i have no clue about this research spin at all.
I also don't understand where the research context is coming from. Usually, researchers don't have the need to correct the geolocation of so many prefixes to require something like geofeeds.
I think this was an attempt by the legal team to find some way to justify having the "geofeed:" attribute based on the current defined purposes.
And I really don't understand why the geofeed attribute would not be covered by the current purpose of the RIPE database, as described in the article 3.
Geofeed matches "Facilitating coordination between network operators (network problem resolution, outage notification etc.)"
Geofeed wants to correct geolocation problems. The geofeed attribute is exactly a way to "coordinate between network operators" (with, or without, the intermediation of geolocation providers). Geolocation problems impact the availability/performance of content/services. The medium is the network. Geolocation problems are network problems.
No, "geofeed:" is not covered by this purpose. It may be provided by network operators but it is not 'used' by them. It has nothing to do with 'network problem resolution, outage notification etc'. It is, as I suggested, data that is used by external services. As are all the other items I mentioned in that list.
On 28/07/2022 16:58, Laurent Pellegrino via db-wg wrote:
It's sad to see real solutions around geolocation (which helps users in many ways) overthought and killed in the eggs.
In general, the solution has not been killed.
It would have been nice to have a neat "geofeed" attribute. However, geofeeds are successfully used with remarks in LACNIC, APNIC, AFRINIC, and RIPE. Comments are used in ARIN.
Add a remark/comment "Geofeed https://url-to-my-file" and you are good to go. At the moment most of the data is produced with this approach anyway.
This is not the way to go. We should never accept the overloading of a free text attribute with structured data as a solution to any problem. Let's fix the core problem and bring the purposes into line with the contents and usage of the database. cheers denis co-chair DB-WG
Ciao, Massimo
--
To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg