<div dir="ltr"><div>Hi Job and db-wg,</div><div><br></div><div>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. :)</div><div></div><div><br></div><div>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.</div><div><br></div><div>> Why not use the RPKI to distribute geofeed information?</div><div><br></div><div>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.</div><div><br></div><div>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 ( <a href="https://github.com/RIPE-NCC/whois/wiki/WHOIS-REST-API-abuse-contact">https://github.com/RIPE-NCC/whois/wiki/WHOIS-REST-API-abuse-contact</a> ).</div><div><br></div><div>> What downsides/risks/challenges down the road might exist?</div><div><br></div><div>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.</div><div>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.</div><div><br></div><div>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).</div><div><br></div><div>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)</div><div><br></div><div>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.</div><div>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.</div><div><br></div><div>> Will this be the final and full solution to GeoIP challenges?</div><div><br></div><div>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.</div><div><br></div><div>> Have any of the GeoIP aggregators/vendors responded to the 'geofeed:' initiative? What do the likes of amazon/google/maxmind think of the format?</div><div><br></div><div>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).</div><div>I don't think maxmind is likely to approve of it as it basically destroys their product if successful.</div><div><br></div><div>Additionally I think this would be quite useful if it succeeded as if I recall correctly, the BBC uses the delegated list files on <a href="http://ftp.ripe.net">ftp.ripe.net</a> for GeoIP.</div><div>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.</div><div><br></div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">- Cynthia</div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Jan 3, 2021 at 7:30 PM Job Snijders via db-wg <<a href="mailto:db-wg@ripe.net">db-wg@ripe.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Dear DB-WG chairs,<br> <br> Today an acquaintance (who works at an ISP) reached out to me describing<br> some annoying Geo IP location issues they were facing.<br> <br> I thought to myself "didn't we have a solution to such issues?" and was<br> reminded of this thread.<br> <br> Chairs, how do we proceed to work towards the deployment of this new<br> RPSL 'geofeed:' attribute? What is the next step?<br> <br> strawman problem statement for NWI process:<br> <br> "Associating an approximate physical location with an IP address<br> has proven to be a challenge to solve within the current constraints<br> of the RIPE database. Over the years the community has choosen<br> to consider addresses in the RIPE database to relate to entities in<br> the assignment process itself, not the subsequent actual use of IP<br> addresses after assignment.<br> <br> The working group is asked to consider whether the RIPE database can<br> be used as a springboard for parties wishing to correlate<br> geographical information with IP addresses by allowing structured<br> references in the RIPE database towards information outside the RIPE<br> database which potentially helps answer Geo IP Location queries."<br> <br> Outstanding questions to the group & authors of the geofeed draft:<br> <br> - What would the RDAP integration look like? (as per George: ideally<br> WHOIS and RDAP stay aligned)<br> - Why not use the RPKI to distribute geofeed information?<br> - What downsides/risks/challenges down the road might exist? Will<br> this be the final and full solution to GeoIP challenges?<br> - Have any of the GeoIP aggregators/vendors responded to the<br> 'geofeed:' initiative? What do the likes of amazon/google/maxmind<br> think of the format?<br> <br> Kind regards,<br> <br> Job<br> <br> </blockquote></div>