add rir_* fields to keep track of ASN status

[grizz]

Currently, the list is:

rir_status: string "ok" for good
rir_status_updated: timestamp of when last checked
rir_cc: country code for the ASN

[arnoldnipper]

+1 and please make them visible via API as well

[arnoldnipper]

Having RIR information for networks would be really nice as it allows

• auto-deleting unassigned ASN
• running stats

@peeringdb/pc, what's your mind?

[shane-kerr]

rir_status and rir_status_updated as auto-populated fields sound good to me.

Do we need rir_cc though? There are so many cases where an ASN and/or the organization that manages it are in more than one country, I'm not sure that it has any real value.

[job]

I don't think we need rir_cc - if you look at the RIPE Database Working Group it appears that there is a stronger and stronger consensus to remove the country/geoloc attributes all together from that DB because the values of those attributes often are wildly inaccurate.

[arnoldnipper]

Do we need rir_cc though? There are so many cases where an ASN and/or the organization that manages it are in more than one country, I'm not sure that it has any real value.

@shane-kerr, if you look at the stats published daily by the RIR, there is a unique mapping between ASN and CC (see e.g. ftp://ftp.ripe.net/pub/stats/)

[job]

we should not aspire to copy and build a data model around that mapping I think

…

On Mon, Jan 6, 2020 at 11:05 PM Arnold Nipper ***@***.***> wrote: Do we need rir_cc though? There are so many cases where an ASN and/or the organization that manages it are in more than one country, I'm not sure that it has any real value. @shane-kerr, if you look at the stats published daily by the RIR, there is a unique mapping between ASN and CC (see e.g. ftp://ftp.ripe.net/pub/stats/) — You are receiving this because you are on a team that was mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[arnoldnipper]

@shane-kerr and @job, the Outreach Committee is using rir_cc for its presentation. And it gives a rough indication of how PeeringDB is used in a country. When retrieving rir_status and rir_status_updated it's easy also to extract rir_cc. From the field name and documentation, it will also be clear what this field is for.

[shane-kerr]

I'm afraid this discussion matches pretty closely discussions about assigning country codes to IP addresses in the RIR database itself.

It goes like this:

1. People point out that it doesn't make sense.
2. Other people reply that they really want it even if it does not make sense. 😄

If we want to know about countries, shouldn't we be looking at facilities, which are physical locations and are almost always associated with a country code (I suppose there may be some ships that this doesn't apply to)? These seem much more likely to be correct than RIR information. We already have this in PeeringDB and don't have to copy it from the various RIR databases....

[arnoldnipper]

If we want to know about countries, shouldn't we be looking at facilities, which are physical locations and are almost always associated with a country code (I suppose there may be some ships that this doesn't apply to)? These seem much more likely to be correct than RIR information. We already have this in PeeringDB and don't have to copy it from the various RIR databases

How do facilities correspond to networks? And rir_cc is a statistical value. The meaning is not that this ASN is operating in this country (while in practice I guess this is true for 90+%). It is nice to say 5237 ASN have been assigned to country AB and 3876 of them are in PeeringDB. That's motivating!

[grizz]

In light of that information, I'd say let's not have rir_cc, and start with auto populated rir_status and rir_status_updated as there's a clear value for those two.

If the cc information is inaccurate, it's useless at best and misleading at worst -- plus it's easy to add a field and needs a major release to remove one, so let's let the RIRs figure it out and then we can add if needed. :)

How do facilities correspond to networks? And rir_cc is a statistical value. The meaning is not that this ASN is operating in this country (while in practice I guess this is true for 90+%). It is nice to say 5237 ASN have been assigned to country AB and 3876 of them are in PeeringDB. That's motivating!

Sure, but if RIPE, for example, is saying it's inaccurate, what real value is there?

An interesting (and unique to PDB) stat could be a list of countries that an ASN is operating in.

[arnoldnipper]

Sure, but if RIPE, for example, is saying it's inaccurate, what real value is there?

RIPE NCC != RIPE ... these matching between ASN and CC are done by RIPE NCC and has nothing to do with the RIPE DB. The RIPE DB aut-num does not have a cc field.

whois -t aut-num | grep -c ^country:
0

While for e.g. organisation there is such a field.

whois -t organisation | grep -c ^country:
1

An interesting (and unique to PDB) stat could be a list of countries that an ASN is operating in.

But that then would be a PeeringDB field, set by the network.

[arnoldnipper]

To get this moved forward I give in :)

Summary: Add two new fields to object net

• rir_status: string "ok" for good
• rir_status_updated: timestamp of when last checked

The purpose is to auto-delete unassigned networks.

@grizz, @job and @shane-kerr: ok with you?

[grizz]

+1

[shane-kerr]

+1

[grizz]

@peeringdb/pc This will require regular ASN lookups, how often should it run? It should probably limit to X networks at a time, or just run continuously with some sort of sleep in there. Does anyone have a preference?

Status doesn't appear to be in the RDAP data, are we to assume that if the data is there, it's status is valid?

[arnoldnipper]

@peeringdb/pc This will require regular ASN lookups, how often should it run? It should probably limit to X networks at a time, or just run continuously with some sort of sleep in there. Does anyone have a preference?

Status doesn't appear to be in the RDAP data, are we to assume that if the data is there, it's status is valid?

My idea was to do

 DODATE=$(date -u +%s) 
 RIR="afrinic apnic arin lacnic ripencc"
 for i in $RIR
 do
  curl -sGL ftp://ftp.ripe.net/pub/stats/"${i}"/delegated-"${i}"-extended-latest > "${DODATE}"-delegated-"${i}"-extended-latest
 done

on a daily/bidaily/weekly basis and then update the status. The format is

 afrinic|EG|asn|8524|1|20070920|allocated|F362AF0D
 afrinic|ZZ|asn|8770|1||available|

[arnoldnipper]

@grizz @vegu @egfrank ... any comments?

[arnoldnipper]

@grizz @vegu @egfrank ... what's missing? @mcmanuss8 and @leovegoda please step in!

[leovegoda]

@grizz @vegu @egfrank ... what's missing? @mcmanuss8 and @leovegoda please step in!

I think this is a good way of telling users how fresh the data for the AS Number is. My one question is what we want the country code to mean. What should users infer? The legal home country of the registrant, the country in which most of their network is located, or something else?

[arnoldnipper]

My one question is what we want the country code to mean.

My dear colleagues already refused to have the field rir_cc. But to answer your question. See my comment above

[arnoldnipper]

@leo, please push forward. This is hanging around for ages now.

[leovegoda]

@leo, please push forward. This is hanging around for ages now.

To push this forward it needs to move from "3a Needs Implementation discussion" status to "Ready for implementation." Are we decided that it is ready for implementation?

[arnoldnipper]

@leo, please push forward. This is hanging around for ages now.

To push this forward it needs to move from "3a Needs Implementation discussion" status to "Ready for implementation." Are we decided that it is ready for implementation?

What's missing, @grizz and @vegu?

[vegu]

summary

• Add two new fields to object net on both API and UX
  • rir_status: string "ok" for good
  • rir_status_updated: timestamp of when last checked
• Implement script that retrieves and updates those fields based on logic outlined in this comment

[Yo-Robinson]

Personally excited for the enhancement!

…

On Fri, May 27, 2022 at 4:12 PM Stefan Pratter ***@***.***> wrote: *summary* - Add two new fields to object net on both API and UX - rir_status: string "ok" for good - rir_status_updated: timestamp of when last checked - Implement script that retrieves and updates those fields based on logic outlined in this comment <#473 (comment)> — Reply to this email directly, view it on GitHub <#473 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AOZM2AKNV2R3MR2LJUPCGBLVMDJ5NANCNFSM4HFYUX4Q> . You are receiving this because you are on a team that was mentioned.Message ID: ***@***.***>

-- Yours Sincerely, Yolandi Robinson Email: ***@***.*** Skype: yolandi.robinson97