- db-wg - mailman.ripe.net

BOGON => 103.86.68.0/22
by Ronald F. Guilmette 28 May '21

28 May '21

My apologies to all. My interests and attention are getting pulled in so many different directions these days that I tend to forget the answers to questions that I seem to vaguely remember having already asked. So, at the risk of repeating myself, what's the current policy on stale route objects in the data base that refer to current bogon address space? I'm specifically interested in 103.86.68.0/22 at the moment. route: 103.86.68.0/22 origin: AS131477 mnt-by: HUAJUAN-MJJ-MNT created: 2018-02-24T19:00:10Z last-modified: 2018-09-04T19:09:05Z source: RIPE-NONAUTH

4 7

status: LEGACY -- Stranger and stranger
by Ronald F. Guilmette 28 May '21

28 May '21

Regarding one of the "LEGACY" blocks mentioned in my prior email, on a whim I decided to take a look at the full history of the block. That full history is reproduced below. This history causes me to have even more questions than I have already asked. I'm still totally befuddled by the fact that this block apparently is and always was marked as "status: LEGACY", even though it's original allocation date still seems to be 2015-09-23, which seems relatively recent to me. Just as perplexing is the apparent direct transfer of the block from a department of the UK government to a private for-profit Internet company. Has the UK government been so hard up for cash in recent years that it has taken to selling off any spare /16 blocks that it happens to have lying around? If so, who should I talk to about placing a bid for the next one they decide to unload? ======================================================================== % Version 1 of object "51.155.0.0 - 51.155.255.255" % This version was a UPDATE operation on 2015-09-23 15:10 inetnum: 51.155.0.0 - 51.155.255.255 netname: UK-DWP descr: UK Government Department for Work and Pensions country: GB status: LEGACY mnt-by: DWP-MNT created: 2015-09-23T13:10:05Z last-modified: 2015-09-23T13:10:05Z source: RIPE ======================================================================== % Version 2 of object "51.155.0.0 - 51.155.255.255" % This version was a UPDATE operation on 2015-09-23 15:15 inetnum: 51.155.0.0 - 51.155.255.255 netname: UK-DWP descr: UK Government Department for Work and Pensions country: GB org: ORG-DWP1-RIPE status: LEGACY mnt-by: DWP-MNT created: 2015-09-23T13:10:05Z last-modified: 2015-09-23T13:15:16Z source: RIPE ======================================================================== % Version 3 of object "51.155.0.0 - 51.155.255.255" % This version was a UPDATE operation on 2015-11-05 17:51 inetnum: 51.155.0.0 - 51.155.255.255 netname: UK-ZEN descr: Zen Internet Limited country: GB org: ORG-DWP1-RIPE status: LEGACY mnt-by: ZEN-MNT created: 2015-09-23T13:10:05Z last-modified: 2015-11-05T16:51:50Z source: RIPE ======================================================================== % Version 4 of object "51.155.0.0 - 51.155.255.255" % This version was a UPDATE operation on 2015-11-05 18:43 inetnum: 51.155.0.0 - 51.155.255.255 netname: UK-ZEN descr: Zen Internet Limited country: GB org: ORG-ZIL1-RIPE status: LEGACY mnt-by: ZEN-MNT created: 2015-09-23T13:10:05Z last-modified: 2015-11-05T17:43:45Z source: RIPE ======================================================================== % Version 5 of object "51.155.0.0 - 51.155.255.255" % This version was a UPDATE operation on 2019-07-04 12:43 inetnum: 51.155.0.0 - 51.155.255.255 netname: UK-ZEN descr: Zen Internet Limited country: GB org: ORG-ZIL1-RIPE status: LEGACY mnt-by: ZEN-MNT mnt-by: ZEN-NOC-MNT created: 2015-09-23T13:10:05Z last-modified: 2019-07-04T10:43:36Z source: RIPE ======================================================================== % Version 6 (current version) of object "51.155.0.0 - 51.155.255.255" % This version was a UPDATE operation on 2020-02-03 12:55 inetnum: 51.155.0.0 - 51.155.255.255 netname: UK-ZEN descr: Zen Internet Limited country: GB org: ORG-ZIL1-RIPE status: LEGACY mnt-by: RIPE-NCC-LEGACY-MNT mnt-by: ZEN-MNT mnt-by: ZEN-NOC-MNT created: 2015-09-23T13:10:05Z last-modified: 2020-02-03T11:55:22Z source: RIPE

2 1

Questions about status: LEGACY
by Ronald F. Guilmette 28 May '21

28 May '21

Could someone be so kind as to enlighten me about the intended semantics of "status: LEGACY"? I'm back to trying to do parsing of the data base, en mass, and I've just now noticed that the annotation "status: LEGACY" within a given inetnum record may not mean what I thought it meant. (And by the way, there seem to be several tens of thousands of inetnum records in the data base, at present, which are all marked as "status: LEGACY".) Here are just a couple of randomly chosen samples that are confusing me: inetnum: 51.155.0.0 - 51.155.255.255 netname: UK-ZEN descr: Zen Internet Limited country: GB org: ORG-ZIL1-RIPE admin-c: RT1337-RIPE tech-c: ZIRA1-RIPE status: LEGACY mnt-by: RIPE-NCC-LEGACY-MNT mnt-by: ZEN-MNT mnt-by: ZEN-NOC-MNT created: 2015-09-23T13:10:05Z last-modified: 2020-02-03T11:55:22Z source: RIPE inetnum: 51.155.91.64 - 51.155.91.71 netname: ZEN20210525-NOC-NYCOMM-LIMITED descr: Nycomm Limited descr: leased-line country: GB admin-c: RT1337-RIPE tech-c: ZIRA1-RIPE status: LEGACY mnt-by: ZEN-NOC-MNT created: 2021-05-25T16:49:09Z last-modified: 2021-05-25T16:49:09Z source: RIPE In what sense is the first inetnum record above denoting a "LEGACY" block? The block appears to have been first assigned by RIPE to ORG-ZIL1-RIPE on 2015-09-23. Aren't LEGACY blocks just the ones left-over from the very old days? I have the same questions also for the second inetnum record shown above, which is a sub-assignment / sub-allocation of the first one. Well, here's another one. This also seems rather un-LEGACY, based on the apparent creation date. inetnum: 162.55.0.0 - 162.55.255.255 netname: DE-HETZNER-19920803 country: DE org: ORG-HOA1-RIPE admin-c: HOAC1-RIPE tech-c: HOAC1-RIPE status: LEGACY mnt-by: RIPE-NCC-LEGACY-MNT mnt-by: HOS-GUN mnt-lower: HOS-GUN mnt-domains: HOS-GUN mnt-routes: HOS-GUN created: 2019-11-18T15:01:35Z last-modified: 2019-11-18T15:01:35Z source: RIPE I'm sure that there is a perfectly rational explanation for all of this. I would greatly appreciate it if someone would guide me to it. Whatever is going on here, I obviously didn't get (or didn't read) the memo. Regards, rfg

1 0

DBTF final draft postponed
by denis walker 20 May '21

20 May '21

Colleagues Following the recent Bof the DBTF has postponed publication of it's final draft requirements document. You can see details here https://www.ripe.net/ripe/mail/archives/ripe-list/2021-May/002231.html cheers denis co-chair DB-WG

1 0

What is the RIPE Database in 2021?
by denis walker 18 May '21

18 May '21

Colleagues There was an interesting presentation in the Address Policy session at RIPE 82 this morning by Remco. He raised a number of issues about what exactly is the RIPE Database, what does it do and who does it do it for? The history of the RIPE Database is quite well known (within the industry). It developed as a means to assist resource holders and network operators with 'Internet operational issues'. It also helped the RIPE NCC, as a registry, to allocate Internet resources fairly and uniquely as and when needed. It's development and operation was and is funded by the RIPE NCC membership. But what is the RIPE Database now, in 2021? What will it be in the coming years, decades? Who will use it, who will pay for it, who gets to decide what is in it? The RIPE Database has evolved over the last 20+ years. It is much more now than just a tool for 'Internet operational issues'. It has a more diverse collection of data consumers. But is it still locked in the hands of a very small set of vocal users whose mindset is also locked in the historical context of the database? Too often in discussions about policies and database features we hear the phrases "It's not the purpose of the RIPE Database to do 'abc'" and "It's not the function of the RIPE NCC to do 'xyz'". Are the people saying this RIPE NCC members who are paying for the database? Is that an issue? I don't know. Maybe it is time to stop thinking of the RIPE Database only in terms of 'Internet operational issues'. Whether people have accepted it yet or not, the RIPE Database is a Public Registry of Internet resources. It serves a similar important function in society as a Land Registry, Company Registry, Vehicle Registry, but on a pan national scale. It's usage goes beyond the historical resource holders, engineers and network operators. Along with the function of managing the resources is the importance to the wider public of knowing who is the [owner, user, registrant, operator] (pick your own word) of an Internet resource. To fulfill its role as a Public Registry perhaps it needs more data not less data. But that has to be the right data. The Database Task Force (DBTF) is considering a recommendation to make IPv4 assignments in the RIPE Database optional. That could lead to the complete removal of 94% of the IPv4 resource detail in the database. Rather than considering making IPv4 assignments optional, maybe what we should be considering is making more IPv6 assignment detail mandatory. Do we need to know who sits behind any of those aggregated blocks? Do we need to start filling in this detail before we go too far down the IPv6 road making the backlog difficult to fill in? Who should make decisions in the future about the purpose, use, access, content of the RIPE Database? Should it be tied to (historical) address policy? Or should it be based more on a wider scope as a Public Registry for the benefit of society? Should the RIPE NCC members, who are paying for the database, have any priority in defining it's current and future use? If that becomes an issue should the RIPE Database be funded independently of the RIPE NCC membership? These are questions I had expected the DBTF to consider. Unfortunately I feel the scope of their work has been too narrowly focussed on current database operational functionality and historical purposes rather than current and future usage. The first heading in the draft requirements document is "What is the RIPE Database?". But it only talks about operational issues. The DBTF clearly stated it is only reviewing the database functionality. I'm not sure if you can define the requirements of the functionality without first considering the full scope of the purpose and usage and the context of the database in the industry and society. To be fair to the DBTF, their charter also focuses on database functionality. Maybe there has been a misunderstanding of the full meaning of 'functionality': noun (Oxford English Dictionary) 1.the quality of being suited to serve a purpose well; practicality. "I like the feel and functionality of this bakeware" 2.the range of operations that can be run on a computer or other electronic system. "new software with additional functionality" The draft document seems to focus on the second definition based on a historical view of the first definition. Also considering: The Business Requirement Document (BRD) describes the high-level business needs whereas the Functional Requirement Document (FRD) outlines the functions required to fulfill the business need. BRD answers the question what the business wants to do whereas the FRD gives an answer to how should it be done. The draft document from the DBTF is more like the FRD. It outlines the functions required to fulfill the historical operational needs. We are still missing the BRD for the RIPE Database in 2021+. We don't have a clear understanding of what we want the RIPE Database to do and who for. Thanks Remco for a very timely presentation. (Although you did still keep referring to 'operational issues' which keeps the discussion locked into a historical context.) I look forward to further discussion on this topic... cheers denis co-chair DB-WG

1 0

RIPE Database Task Force minutes
by denis walker 13 May '21

13 May '21

Colleagues The Task Force has published minutes of it's most recent meeting on their mailing list. There are also some interesting comments and observations from Daniel. You can find them here https://www.ripe.net/ripe/mail/archives/ripe-db-requirements-tf/2021-May/da… cheers denis co-chair DB-WG

1 0

Route objects for space administered by other RIRs
by Ronald F. Guilmette 13 May '21

13 May '21

Can anyone please explain to me, preferably using small words that I can understand, why route objects such as the following still exist in the data base at the present time? route: 62.61.192.0/18 descr: SRR origin: AS49902 mnt-by: CEGETEL_LA_REUNION created: 2014-09-30T15:01:51Z last-modified: 2018-09-04T18:00:38Z source: RIPE-NONAUTH (Please note that the whole of 62.61.192.0/18 currently appears to be under the administration of AFRINIC.) I understand that pre-existing route objects within the RIPE data base that relate to IP space which is under the administration of other (non-RIPE) RIRs was set to "RIPE-NONAUTH" awhile back, which is certainly a Good Thing, but I wonder if there is a date certain by which even these route objects will be sunsetted and removed from the RIPE db. Regards, rfg

6 14

country field in ORG objects
by Ronald F. Guilmette 13 May '21

13 May '21

It is my understanding that it was decided that country: fields would be added into any & all org objects that did not already contain them. I would just like to inquire about the current status and expected timeline for this project. Is there an expected completion date? Is RIPE NCC doing all of the work? Or is RIPE NCC instead just trying to cajole & browbeat the organizations themselves into adding the country fields themselves? (If the latter, than I have every faith & confidence that the project will be completed no later than Spring of 2173.) Because I have a tool that tries to summarize the name & country of each org that has IP allocations, and because many org records in the RIPE data base still do not have the country information, I find that I still am needing to implement exceptions/workarounds in my code. In any/most/all of these cases, inferring the proper country based on the snail-mail address of the org is what we here on this side of the pond would call a "no brainer". Here are a few examples of that: 'ORG-AA193-RIPE' => [ 'FR', 'GIE AUCHAN INTERNATIONAL TECHNOLOGY' ], 'ORG-LUC7-RIPE' => [ 'DE', 'ZF Active Safety GmbH' ], 'ORG-NNS5-RIPE' => [ 'CH', 'Nestle Nespresso S.A.' ], 'ORG-RSS4-RIPE' => [ 'ES', 'REALE SEGUROS GENERALES, S.A' ], 'ORG-SS244-RIPE' => [ 'FR', 'SOPRA HR Software SA' ], 'ORG-XISG1-RIPE' => [ 'DE', 'Atos IT Services GmbH' ], A quick look at the WHOIS record for any of the above orgs shows that there is no real mystery about which country each one is in. (If there is any doubt, then simply googling the mailing address in the WHOIS clears that right up.) The apparent fact that the country codes for the orgs listed above are altogether easy to reliably infer is only really relevant in the case where RIPE NCC itself (rather than the orgs) is doing the work to add the country fields into the org records that don't already have them. Obviously, doing this on a large scale will be REALLY tedious work, but from a technical perspective, at least, it doesn't seem to be either a particularly hard task or a task which is particularly fraught with difficult-to-resolve ambiguities. (So I guess that's the "good news" part of the story. If RIPE NCC is doing the work, then they just have to find someone to sit and do this, 8 hours a day, until it is either finished or until that person goes blind or commits suicide due to the excessive tedium of the task.) Regards, rfg

2 1

Agenda RIPE82 - Database Working Group
by William Sylvester 12 May '21

12 May '21

Dear Working Group Members, Below is the agenda for the Database Working Group for RIPE82. If you have any questions, comments, or requested changes please let the chairs know. Best regards, William & Denis DB-WG Chairs A. Introduction - 5 min * Welcome * Scribe * Jabber * Agenda B. Operational Update RIPE Database – 10 mins Edward Shryane, RIPE NCC C. Geofeeds – 10 mins Massimo Candela, NTT D. Cloud Migration – 20 mins Sander Buskens, RIPE NCC E. NWI - Open Proposals – 10 mins Z. AOB (open discussion)

1 0

New on RIPE Labs: RPKI Repositories and the RIPE Database in the Cloud
by Alun Davies 10 May '21

10 May '21

Dear colleagues, The mission critical services the RIPE NCC provides to the Internet community require a solid technical foundation. In this new article on RIPE Labs, Felipe Silveira looks at plans to use cloud infrastructure as a means to that end. The full article is available here: https://labs.ripe.net/author/felipe_victolla_silveira/rpki-repositories-and… Kind regards, Alun Davies RIPE Labs Editor RIPE NCC

1 0