Re: [db-wg] proposal: new attribute 'geofeed:'
One more question after coffee: > > On deployment update any objects in the RIPE Database containing a > > "remarks: Geofeed" with a correctly formatted url into a "geofeed:" > > attribute. > > Sounds simple enough What happens when someone (or someone's automated system) pushes an object with a "remarks: Geofeed" again? Do an automatic conversion on update? How many scripts will that break (or worse: how many scripts will get stuck in a loop because the object in the database isn't what they believe it should be, so they update it again and again and …) So maybe not do an automatic update after all, and maybe update the web based editor with a helpful "This looks like a Geofeed remark, click here to change it to a geofeed attribute" button Cheers! Sander signature.asc Description: This is a digitally signed message part
Re: [db-wg] proposal: new attribute 'geofeed:'
Hi Denis, > Would you say a possible Solution statement could be as simple as: > > Implement a new "geofeed:" attribute in the INETNUM and INET6NUM > objects based on the IETF draft > https://datatracker.ietf.org/doc/draft-ietf-opsawg-finding-geofeeds/ > On deployment update any objects in the RIPE Database containing a > "remarks: Geofeed" with a correctly formatted url into a "geofeed:" > attribute. Sounds simple enough Let's implement! Sander signature.asc Description: This is a digitally signed message part
Re: [db-wg] proposal: new attribute 'geofeed:'
Hi Job So if we were to create a new NWI with your suggested Problem statement: 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 chosen 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. Would you say a possible Solution statement could be as simple as: Implement a new "geofeed:" attribute in the INETNUM and INET6NUM objects based on the IETF draft https://datatracker.ietf.org/doc/draft-ietf-opsawg-finding-geofeeds/ On deployment update any objects in the RIPE Database containing a "remarks: Geofeed" with a correctly formatted url into a "geofeed:" attribute. cheers denis co-chair DB-WG On Sun, 3 Jan 2021 at 19:11, Job Snijders via db-wg 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 >
Re: [db-wg] proposal: new attribute 'geofeed:'
> 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 https://github.com/massimocandela/geofeed-finder what remains is to go from a remarks: attribute to a first class geofeed: attribute, which i took as the core of job's post. randy
Re: [db-wg] proposal: new attribute 'geofeed:'
hi cynthia >> 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. as i said to job over on the dark side of the force, the ietf, hammer seeks nails, eh? :) geoseekers already mine whois. so we are putting the keys under the streetlight (excuse what may be an american-only idiom). asking someone who wants to publish their geofeed location to first deal with rpki is an artifical barrier to deployment. asking someone who wants to find geofeed data to first deal with rpki is an artificial barrier to deployment. is the rpki to be the next dns/bgp, a place to dump data? have we all looked at https://datatracker.ietf.org/doc/draft-ietf-opsawg-finding-geofeeds/ it's all pretty much layed out there, i hope. improvements solicited, of course. randy
Re: [db-wg] proposal: new attribute 'geofeed:'
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 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 > >
Re: [db-wg] proposal: new attribute 'geofeed:'
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
