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-requ...@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][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 > > > > [ftp.ripe.net]: http://ftp.ripe.net [db-wg_ripe.net]: mailto:db-wg@ripe.net
signature.asc
Description: OpenPGP digital signature
