Hi Denis, On 06/05/2021 23:17, denis walker wrote:
Does this mean geofeed values are only meaningful when used as a collection and not individually? Take this example with a /16 and a more specific /24 both having a geofeed attribute. If I query for an address within the /16 but outside of the more specific /24 I will get the INETNUM object for the /16 with it's geofeed attribute. But the data contained in the referenced file may not be correct for the more specific /24 range which has it's own referenced file.
The fact you queried a specific IP doesn't allow to conclude anything on the entire prefix, the same goes for an inetnum and its more specifics. This is also the case if you provide geofeed files to a geolocation provider directly without passing for the whois. In that case they will have to validate the boundaries. In the address space there is no way to assign a property to an entire prefix without checking for more specifics.
So for anyone using this data do you have to query for all objects containing a geofeed attribute and download all the referenced files to be sure of having correct information? Having downloaded all the data you would then have to correlate the data to check for overlapping values, discarding the less specific data for the /24 in this example. Is this how it works or have I missed something?
The process is quite simple. If you are interested in a specific IP, you can just query for the IP, retrieve the geofeed and read the location. If you want to get everything: (1) parse the bulk whois data and get all the inetnums having a geofeed; (2) download all the geofeed files and remove all the prefixes not contained in the parent inetnum; (3) accept all geofeed entries which are coming from the most specific parent inetnum. The draft provides more details. Example of point 3: parent-inetnum: 1.2.0.0/16 geofeed-entry: 1.2.3.5,IT,IT-RM,Rome, parent-inetnum: 1.2.3.0/24 geofeed-entry: 1.2.3.5,IT,IT-MI,Milan, 1.2.3.5 is in Milan due to the parent inetnum. Ciao, Massimo