Hi, I think this thread got stalled last time by getting outside the scope of the db-wg. There was more talk of if Geofeed is good or bad etc, but really the question for the db-wg is the following...
geofeed: <url> or remarks: Geofeed <url>
And if we limit it to that question, and realize that the rest is for the relevant IETF WGs to deal with, what do we think is the best solution? I would say that adding a geofeed attribute rather than just saying that people should just the remarks attribute is a lot more sensible. Please remember that the db-wg's job is to maintain and improve the quality of the database, not to judge if RFC8805 is a good idea or not. -Cynthia -Cynthia On Thu, Mar 25, 2021 at 1:16 PM Tyrasuki via db-wg <db-wg@ripe.net> wrote:
I approve implementation of this, and already use geofeeds in "remark" attributes.
I've not seen much movement about this in a while so i think it might be a good idea to bring up again.
Has there been any further discussion anywhere about this?
- Jori (Tyrasuki)
-------- Original Message -------- On Jan 4, 2021, 4:18 AM, < db-wg-request@ripe.net> wrote:
Hi Job and db-wg,
I just want to start out by saying that I think this is a very worthwhile endeavour IMO, and thank you Job for reminding me of this thread. :)
I have also written some opinions about your questions and ideas below, and I would like to hear some input from people on the WG as this is sort of my initial thoughts but have not been thoroughly considered.
Why not use the RPKI to distribute geofeed information?
I think using RPKI for this will make it needlessly complicated for people to use. I think we want to make this as simple as possible for someone to find.
To me it seems like it might be a good idea to add it as an attribute in the RIPE DB and then additionally having some like the HTTP API for finding abuse contacts but for geofeed ( https://github.com/RIPE-NCC/whois/wiki/WHOIS-REST-API-abuse-contact ).
What downsides/risks/challenges down the road might exist?
As I noted in the comment above, I think the main challenge will be to make it simple and basic enough to implement for people wanting to publish geofeed URLs and people wanting to fetch geofeed URLs. I think having a basic HTTP JSON API to get this URL would really help with implementation as it would be really easy for data consumers to query for the URL and not have to parse WHOIS data or read RDAP RFCs or whatever.
Additionally, WHOIS is not encrypted/authenticated (which HTTPS/TLS is) and as such while the risk for malicious activity here might be low, I think having it authenticated would help (as in making sure you get the URL that the resource holder provided, not that the data in there is necessarily correct).
I think that if this is implemented, only HTTPS urls should be allowed, as in no plain text HTTP. (I don't have very strong feelings but it seems reasonable to me)
And on the note of the main challenge, I also think a part of making it simple to implement is to try to have the same API for this between all of the RIRs, because I don't think this will really succeed if only RIPE NCC has it. I think that if the RIPE NCC implements this, the next step will be to try to coordinate this with other RIRs so it can be a workable system for all RIRs.
Will this be the final and full solution to GeoIP challenges?
I would say that this is probably not something that can easily be figured out other than by implementing it and waiting for a few years.
Have any of the GeoIP aggregators/vendors responded to the 'geofeed:' initiative? What do the likes of amazon/google/maxmind think of the format?
I am also very curious about this, in particular to what the people wanting to use this data think of it (aka google, amazon, etc). I don't think maxmind is likely to approve of it as it basically destroys their product if successful.
Additionally I think this would be quite useful if it succeeded as if I recall correctly, the BBC uses the delegated list files on ftp.ripe.net for GeoIP. This sort of became problematic when the whole delegated list file country code has to correspond to legal address thing happened, as this broke for some cases.
- Cynthia
On Sun, Jan 3, 2021 at 7:30 PM Job Snijders via db-wg <db-wg@ripe.net> wrote:
Dear DB-WG chairs,
Today an acquaintance (who works at an ISP) reached out to me describing some annoying Geo IP location issues they were facing.
I thought to myself "didn't we have a solution to such issues?" and was reminded of this thread.
Chairs, how do we proceed to work towards the deployment of this new RPSL 'geofeed:' attribute? What is the next step?
strawman problem statement for NWI process:
"Associating an approximate physical location with an IP address has proven to be a challenge to solve within the current constraints of the RIPE database. Over the years the community has choosen to consider addresses in the RIPE database to relate to entities in the assignment process itself, not the subsequent actual use of IP addresses after assignment.
The working group is asked to consider whether the RIPE database can be used as a springboard for parties wishing to correlate geographical information with IP addresses by allowing structured references in the RIPE database towards information outside the RIPE database which potentially helps answer Geo IP Location queries."
Outstanding questions to the group & authors of the geofeed draft:
- What would the RDAP integration look like? (as per George: ideally WHOIS and RDAP stay aligned) - Why not use the RPKI to distribute geofeed information? - What downsides/risks/challenges down the road might exist? Will this be the final and full solution to GeoIP challenges? - Have any of the GeoIP aggregators/vendors responded to the 'geofeed:' initiative? What do the likes of amazon/google/maxmind think of the format?
Kind regards,
Job