From mboxrd@z Thu Jan  1 00:00:00 1970
From: nusenu <nusenu-lists@riseup.net>
To: location@lists.ipfire.org
Subject: Re: location db mismatch
Date: Wed, 26 Jan 2022 00:10:05 +0100
Message-ID: <a57fb807-3ae6-09c4-3ce7-bf5e5a8152eb@riseup.net>
In-Reply-To: <c18f93cd-3c31-e61e-a7c6-06bff82bbe8a@ipfire.org>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============0236698129747962892=="
List-Id: <location.lists.ipfire.org>

--===============0236698129747962892==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Hi Peter,

Peter M=C3=BCller:
> Hello Michael,
> hello nusenu,
> hello Martin (???),
>=20
> sorry for my late reply.
>=20
> Yes, this change is due to an override of mine, committed as f3901759ede298=
e49cf5c056d0655b97e86cd211,
> affecting all location databases generated after January 9th, 2022.

thanks for your thorough reply.
For me the relevant part was that this is due to a manual override.
Maybe something I'll try to understand further: how can I easily determine if=
 some information
is provided due to a manual override vs. the raw WHOIS information? And if it=
 was a manual override:
What information did trigger that manual override?

I don't have any information on where these prefixes are actually located.

btw: I'm surprised that you read individual provider company websites to dete=
rmine and manually override the
location of individual ASNs or prefixes of a fiven AS, I didn't expect that t=
o be feasible :)

kind regards,
nusenu




--=20
https://nusenu.github.io

--===============0236698129747962892==--