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
