public inbox for location@lists.ipfire.org
 help / color / mirror / Atom feed
From: Michael Tremer <michael.tremer@ipfire.org>
To: location@lists.ipfire.org
Subject: Re: [PATCH] location-importer.in: treat AQ and BV as invalid countries
Date: Wed, 14 Apr 2021 09:58:44 +0100	[thread overview]
Message-ID: <32E9519B-895B-4514-A14B-5A9307A5907D@ipfire.org> (raw)
In-Reply-To: <da70c495-3b9c-349e-61d2-062697aaee92@ipfire.org>

[-- Attachment #1: Type: text/plain, Size: 4320 bytes --]

Hi,

> On 12 Apr 2021, at 18:26, Peter Müller <peter.mueller(a)ipfire.org> wrote:
> 
> Hello Michael,
> 
> thanks for your reply.
> 
> I believe you are mixing up two distinct scenarios here:

I am trying not to. I just added the name because I struggle to remember some country codes.

> (a) Historic ISO-3166-X abbreviations for countries no longer existing anymore, such as YU.

They technically do.

They are still reserved in the ISO 3166 database and they show up (in this case) in the RIPE database. So we will have to handle them no matter what.

YU does not have a succeeding national body (like Eastern Germany would have the Federal Republic of Germany) so we cannot automatically rewrite them.

> (b) Country codes for existing nations, where we believe with a high level of confidence no
>    IP networks are located in any way, either physically or legally. AQ and BV are the most
>    notable examples known to me at the time of writing.
> 
> Since it does not make sense to add historic country codes, I would suggest to leave networks
> assigned to (a) countries as they are, manually creating overrides for them, as I did before.
> 
> For (b), simply scrubbing out the country or region they belong to seems to be too harsh to
> me, as we use this information for several things, and should not abuse it for our own purposes.

(I assume) we still have AS information about those networks and we should keep at least that.

> Therefore, I rather suggest adding an additional column to countries.txt for indicating whether
> this country code is acceptable to us or not.

Okay. What would you suggest?

-Michael

> 
> Thanks, and best regards,
> Peter Müller
> 
>> Hello,
>> 
>> How about we add the country to the list and mark the continent with a “-“:
>> 
>>  AF      AS      Afghanistan
>>  YU      -       Yugoslavia
>> 
>> -Michael
>> 
>>> On 10 Apr 2021, at 13:32, Peter Müller <peter.mueller(a)ipfire.org> wrote:
>>> 
>>> Hello Michael,
>>> 
>>> thanks for your reply.
>>> 
>>> Yes, having this configurable in countries.txt would be nice indeed. Do you propose a certain syntax for this?
>>> 
>>> And yes, a tuple is a better idea here. I will wait for your reply and submit a second version of this patch then.
>>> 
>>> Thanks, and best regards,
>>> Peter Müller
>>> 
>>> 
>>>> Hello,
>>>> 
>>>> * would we not want this to be configurable in countries.txt?
>>>> 
>>>> * The list should probably be a tuple.
>>>> 
>>>> -Michael
>>>> 
>>>>> On 1 Apr 2021, at 20:57, Peter Müller <peter.mueller(a)ipfire.org> wrote:
>>>>> 
>>>>> Both the Bouvet Island (BV) and Antarctica (AQ) are unpopulated at the
>>>>> time of writing. Network owners/operators putting these countries into
>>>>> their RIR data objects are either completely braindead or doing so for
>>>>> hostile reasons.
>>>>> 
>>>>> While we might correct these locations to something useful by manually
>>>>> creating overrides for them, the rationale behind this patch is not to
>>>>> let these countries appear on productive systems in the first place, as
>>>>> we know they _cannot_ be true.
>>>>> 
>>>>> Therefore, this patch skips any network object that has either AQ or BV
>>>>> country code set.
>>>>> 
>>>>> See also: https://lists.ipfire.org/pipermail/location/2020-October/000199.html
>>>>> 
>>>>> Signed-off-by: Peter Müller <peter.mueller(a)ipfire.org>
>>>>> ---
>>>>> src/python/location-importer.in | 2 +-
>>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>> 
>>>>> diff --git a/src/python/location-importer.in b/src/python/location-importer.in
>>>>> index 1e08458..ac678dc 100644
>>>>> --- a/src/python/location-importer.in
>>>>> +++ b/src/python/location-importer.in
>>>>> @@ -624,7 +624,7 @@ class CLI(object):
>>>>> 			return
>>>>> 
>>>>> 		# Skip objects with unknown country codes
>>>>> -		if validcountries and inetnum.get("country") not in validcountries:
>>>>> +		if validcountries and (inetnum.get("country") not in validcountries or inetnum.get("country") in ["AQ", "BV"]):
>>>>> 			log.warning("Skipping network with bogus country '%s': %s" % \
>>>>> 				(inetnum.get("country"), inetnum.get("inet6num") or inetnum.get("inetnum")))
>>>>> 			return
>>>>> -- 
>>>>> 2.26.2
>>>> 
>> 


  reply	other threads:[~2021-04-14  8:58 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-01 19:57 Peter Müller
2021-04-07 20:49 ` Michael Tremer
2021-04-10 12:32   ` Peter Müller
2021-04-12  9:21     ` Michael Tremer
2021-04-12 17:26       ` Peter Müller
2021-04-14  8:58         ` Michael Tremer [this message]
2021-05-14 16:15           ` Peter Müller
2021-05-18 10:47             ` Michael Tremer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=32E9519B-895B-4514-A14B-5A9307A5907D@ipfire.org \
    --to=michael.tremer@ipfire.org \
    --cc=location@lists.ipfire.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox