From mboxrd@z Thu Jan  1 00:00:00 1970
From: Peter =?utf-8?q?M=C3=BCller?= <peter.mueller@ipfire.org>
To: location@lists.ipfire.org
Subject: override entries change network prefix length
Date: Sun, 28 Mar 2021 08:43:24 +0200
Message-ID: <34be8969-6856-e446-4e06-020d64c99bb5@ipfire.org>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============1606643425735897784=="
List-Id: <location.lists.ipfire.org>

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

Hello Michael,
hello location folks (CC'ed),

finally having some spare time to spend on ${things}, I thought working on #1=
1754, #12594 and #12595
might be a good idea to improve the results of our location database. :-)

Since #11754 and #12594 involve something like automated overrides to fetched=
 RIR data, I recently noticed
adding overrides is changing the displayed network length in a "location look=
up" output:

> [root(a)maverick ~]# location lookup 176.10.99.192
> 176.10.99.192:
>   Network                 : 176.10.99.192/27
>   Country                 : Switzerland
>   Autonomous System       : AS51395 - Datasource AG
>   Anonymous Proxy         : yes

176.10.99.192 is part of 176.10.96.0/19, which is announced as such by AS5139=
5, hence the output is
misleading. A better result would be to display the original size of a BGP an=
nouncement, adding some
flags if needed without stripping down the IP network size to the override.

This is a minor issue as far as I am concerned, but before I create code that=
 generates overrides en
masse, I would like to discuss whether or not it is a good idea to keep the c=
urrent behaviour.

Thanks, and best regards,
Peter M=C3=BCller

--===============1606643425735897784==--