May 2021 - db-wg - mailman.ripe.net

New NWI for geofeed?
by denis walker 14 Apr '22

14 Apr '22

Colleagues [Apologies for the length of this email...] The chairs would like to suggest creating a new NWI for the "geofeed:" attribute and suggest the following draft Problem statement and Solution definition. If there is agreement on this the RIPE NCC will do an impact assessment including legal review and summary of what the other RIRs are doing. There has already been quite a discussion in the WG on this issue with a lot of support. So hopefully we can reach a consensus quickly, at least on setting up the NWI and starting the impact assessment. Having read the latest draft IETF docs, there are some outstanding questions. Comments and changes are welcome... cheers denis co-chair DB-WG Problem statement Associating an approximate physical location with an IP address has proven to be a challenge to solve within the current constraints of the RIPE Database. Over the years the community has chosen to consider addresses in the RIPE Database to relate to entities in the assignment process itself, not the subsequent actual use of IP addresses after assignment. The working group is asked to consider whether the RIPE Database can be used as a springboard for parties wishing to correlate geographical information with IP addresses by allowing structured references in the RIPE Database towards information outside the RIPE Database which potentially helps answer Geo IP Location queries The IETF is currently discussing an update to RPSL to add a new attribute "geofeed: url". The url will reference a csv file containing location data. Some users have already started to make use of this feature via the "remarks: geofeed: url". It is never a good idea to try to overload structured data into the free format "remarks:" attribute. This has been done in the past, for example with abuse contact details before we introduced the "abuse-c:" attribute. There is no way to regulate what database users put into "remarks:" attributes. So even if the new "geofeed:" attribute is not agreed, the url data will still be included in the RIPE Database. Currently there are 24,408 INETNUM and 516,354 INET6NUM objects containing a "remarks: geofeed: url" attribute in the database. These have 7,731 distinct values in the INETNUMs and 1,045 distinct values in the INET6NUMs. Solution definition Implement a new "geofeed:" attribute according to the IETF's definition. Although the IETF has not yet concluded discussions on this attribute we can still implement it in the RIPE Database RPSL data definition. The RIPE Database already has many local differences to the RPSL standard. As expressed in the Problem statement, users are already using the geofeed data by overloading the "remarks:" attribute. That is a dirty hack which should be avoided. An invalid formated url will be a syntax error. The RIPE NCC will perform a one time conversion of the existing data to convert "remarks: geofeed: url" to "geofeed: url". If an update then contains a "remarks: geofeed: url" attribute, the update will be successful and the response should include an appropriate Warning message. At some point in the (near) future, this could be changed to an update failure as a syntax error. An update containing a "geofeed:" and a "remarks: geofeed:" attribute or more than one "remarks: geofeed:" will be a syntax error. The resource holder should be able to create, modify, delete the "geofeed:" attribute in allocation objects. Questions: -Should the database software do any checks on the existence/reachability of the url as part of the update with an error if the check fails? -Should the RIPE NCC do any periodic repeat checks on the continued existence/reachability of the url? -Should the RIPE NCC do any periodic checks on the content structure of the csv file referenced by the url? -Should the Solution definition define how this will be adopted into RDAP or should we simply ask the RIPE NCC to define this in their impact assessment? -The RIPE Database contains hierarchical address space objects. Should it be acceptable for "geofeed:" attributes to exist at multiple levels within a specific hierarchy? -Suppose a geofeed csv file referenced by a /16 INETNUM object contains location data for the whole /16. Then a more specific /24 INETNUM object references another geofeed csv file that contains conflicting location data for this /24. Should this be a concern for the RIPE Database? -Should geofeed data be inherited? If you query for a /24 that does not contain a "geofeed:" attribute, but a less specific /16 does contain a "geofeed:" attribute, should this data be returned? In other words could it be used in a similar way to "abuse-c:"? -Thinking ahead to how people will actually deploy this data and what short cuts they could make. It is said that when reading a geofeed csv file, consumers of the data should ignore all data within that file not directly concerning the address space queried in the RIPE Database. Could you therefore create a single csv file with location data for all your address space and reference the same file in all your RIPE Database address objects? The address space owner could rely on the data consumer to pick out the correct piece of data for the relevant address space. The manager of the csv file then only has to work with one file. If this is possible and does happen (which the IETF doc 'Finding geofeeds' seems to suggest is possible for unsigned geofeed data), would it therefore make sense to apply "geofeed:" hierarchically as with "abuse-c:"? Allow a single, default "geofeed:" attribute in the ORGANISATION object to be applied to all that organisations address space, with the option of specific localised "geofeed:" attributes in address space objects. That could be a neater solution, and easier to setup, than applying thousands of references to the same geofeed file at a more specific level in the database. -Relating to the above 3 questions, should geofeed data only be considered applicable if returned by a specific geofeed locater application which takes into account the hierarchical nature of address space in the database? Otherwise do the standard database query mechanisms have to take into account this hierarchy and locate the most specific "geofeed:" attribute from the less specific objects? -Should/could the RIPE Database return the csv file as part of the query? If so should the file be cached (for how long?) to avoid too many downloads? -Should we only allow HTTPS urls? (Which the IETF doc 'Finding geofeeds' seems to suggest) -Should the RIPE NCC go ahead and implement this now, with our own set of RIPE rules? Or should we try to coordinate this and agree a set of common rules between all the RIRs before any deployment in the RIPE Database? -For the legal review, there are 2 statements in the IETF doc 'Finding geofeeds' which may be of concern: *[RFC8805] geofeed data may reveal the approximate location of an IP address, which might in turn reveal the approximate location of an individual user. Unfortunately, [RFC8805] provides no privacy guidance on avoiding or ameliorating possible damage due to this exposure of the user. In publishing pointers to geofeed files as described in this document the operator should be aware of this exposure in geofeed data and be cautious. All the privacy considerations of [RFC8805] Section 4 apply to this document. *It is significant that geofeed data may have finer granularity than the inetnum: which refers to them. It is clear that the RIPE NCC cannot prevent this data being referenced by objects in the RIPE Database. It is already being referenced from "remarks:" attributes. Perhaps the RIPE NCC should require (as part of their service agreement) that it's members obtain written consent from their customers to publish this location data, or at least inform the customers in writing that it will be published. Also, although RFC8805 says postcode is deprecated it is still provided for in the csv files. So anyone can still enter location data to this detail. -The IETF doc 'Finding geofeeds' suggests that geofeed information 'will be' available in bulk accessed whois data. In view of the privacy concerns above, is this likely? -The IETF doc 'Finding geofeeds' says "To minimize the load on RIR whois [RFC3912] services, use of the RIR's FTP [RFC0959] services SHOULD be the preferred access." Is the RIPE NCC expected to download all the geofeed files and make them available through their FTP service? -The IETF doc 'Finding geofeeds' states that consumers of the geofeed data MUST NOT access this data in real time via the RPSL servers 'too frequently' or at 'magic times like midnight'. Some users will do whatever they want to do if they are able to do, regardless of any statements to the contrary. Should the RIPE NCC enforce such access rules by some means? References The IETF doc 'Finding geofeeds': https://datatracker.ietf.org/doc/draft-ietf-opsawg-finding-geofeeds/?includ… geofeed file format: https://www.rfc-editor.org/rfc/rfc8805.html

12 53

NWI-4 - role of status: field in multivalued status context - reprise
by Carsten Schiefner 08 Jun '21

08 Jun '21

Dear all - after a quick chat with Dennis on this, he encouraged me to toss this into the seemingly stalled, but not yet dead debate: Right now, only the "inet[6]num:" attribute is the primary key to, of or for inet[6]num objects. I wonder if it would be possible to make the tuple ("inet[6]num:","status:") the primary key instead: that should solve the challenge to have an assignment that shall have the size of an allocation. In case this has been exhaustedly discussed here already, please excuse my ignorance - I then obviously have failed to spot the respective contribution in the archives. All the best, -C.

6 7

Restricting WHOIS searches to type: netname
by Ronald F. Guilmette 29 May '21

29 May '21

One of the helpful options provided by the RIPE WHOIS server is the --types option which provides a list of what specific object types a given set of query results may be restricted to. That list is as follows: inetnum inet6num as-block aut-num as-set route route6 route-set inet-rtr filter-set peering-set rtr-set domain poetic-form poem mntner irt key-cert organisation role person Can anyone explain to me why "netname" is not on the above list? I would like to be able to query the data base for "ABC" but restrict the query so that I only get back the records for the dozen or so IP blocks whose registrants have (unwisely?) elected to label their networks as "ABC", while NOT also getting back all 16 or so of the organisation objects whose org-name: field contains the substring "ABC", much less the numerous and additional person and role records whose person: and role: fields also and likewise contain the substring "ABC". If I can selectively query just for poems, is there some reason why netnames deserve less respect? And as long as we are on the subject, may I safely infer from the presence, in the data base, of a dozen different networks named "ABC" that no attempt has ever been made to insure uniqueness of netnames within the data base? Are netnames even restricted, as they seem to be, to having a form which is rather strikingly reminicent of actual unique data base handles, i.e. consisting of only alphanumerics and hyphens? Regards, rfg P.S. I do not mean to pick on RIPE specifically here. A quick check reveals that whois.apnic.net and whois.afrinic.net also fail to support selective querying for just netnames... although in those two cases selective quering for poems is also not an option... a sad fact that has left me rather entirely bereft, as I'm sure you can all imagine.

4 4

created: field value
by Ronald F. Guilmette 29 May '21

29 May '21

My apologies to all. I don't intend to be a complainer. I'm just trying to understand fully what's going on in the data base. I must say however that I am getting the impression that the value in the created: field for some (many?) inetnum objects may not be entirely reliable, or even entirely consistant with other available historical data. Example: inetnum: 138.201.0.0 - 138.201.255.255 netname: HETZNER-RZ-BLK-ERX4 descr: Server Block country: DE org: ORG-HOA1-RIPE admin-c: HOAC1-RIPE tech-c: HOAC1-RIPE status: LEGACY mnt-by: HOS-GUN mnt-lower: HOS-GUN mnt-routes: HOS-GUN mnt-domains: HOS-GUN created: 1970-01-01T00:00:00Z last-modified: 2019-12-04T13:10:40Z source: RIPE Given that 1970-01-01T00:00:00Z is rather well known to be the beginning of UNIX time (i.e. time: 0) I could not help but be a bit suspicious of the value in the created: field of the record shown above. A quick look at version #1 of the data base object for the 138.201.0.0/16 block suggests that a rather more appropriate value might have been something more like 2003-12-11T17:11:00Z ======================================================================== % Version 1 of object "138.201.0.0 - 138.201.255.255" % This version was a UPDATE operation on 2003-12-11 17:11 inetnum: 138.201.0.0 - 138.201.255.255 remarks: remarks: This inetnum has been transfered as part of the ERX. remarks: It was present in both the ARIN and RIPE databases, so remarks: the information from both databases has been merged. remarks: If you are the mntner of this object, please update it remarks: to reflect the correct information. remarks: remarks: Please see the information for this process: remarks: http://www.ripe.net/db/erx/erx-ip/network-138.html remarks: remarks: **** INFORMATION FROM ARIN OBJECT **** remarks: netname: NETCS-CUST4 descr: netCS Informationstechnik GmbH descr: Feuerbachstrasse 47/49 descr: D-1000 Berlin 41 remarks: country: DE remarks: changed: hostmaster(a)arin.net 19900523 remarks: changed: hostmaster(a)arin.net 20010220 remarks: **** INFORMATION FROM RIPE OBJECT **** netname: KIEZ-NET1 descr: Kiez-Net WAN country: DE rev-srv: DNS-A.Kiez.Net rev-srv: DNS-B.Kiez.Net status: ASSIGNED PI mnt-by: KIEZ-MNT source: RIPE # Filtered Am I the only one who thinks so? It is certainly my hope that the value in the created: field should accurately reflect the date & time when any given object was in fact created within the RIPE WHOIS data base. Is there any compelling reason why this should ever not be the case? Regards, rfg

4 5

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

Re: [db-wg] Cleanup of route(6) objects in the RIPE NONAUTH database using unregistered space
by denis walker 07 May '21

07 May '21

Hi Arash For most issues we would not come to such a quick conclusion. But deleting ROUTE objects for unallocated address space seems to be a very non-contentious issue. Over this last year it has been difficult to get comments, feedback or any discussion on many issues. So I think two weeks (just before a RIPE Meeting) is a reasonable time frame for objections for this, and none were received. cheers denis co-chair DB-WG On Fri, 7 May 2021 at 12:59, Arash Naderpour <arash.naderpour(a)gmail.com> wrote: > > I have no objection but it looks a bit weird to me to come to this quick conclusion. > > Regards, > > Arash > > On Fri, 7 May 2021, 22:56 denis walker via db-wg, <db-wg(a)ripe.net> wrote: >> >> HI Ed >> >> As no one has objected I think we can assume you can go ahead with this plan. >> >> cheers >> denis >> co-chair DB-WG >> >> On Fri, 7 May 2021 at 09:20, Edward Shryane <eshryane(a)ripe.net> wrote: >> > >> > Hi Cynthia, Denis, >> > >> > Thanks for your feedback. I will plan to implement a cleanup job without an NWI, and will keep the DB-WG informed. >> > >> > Regards >> > Ed Shryane >> > RIPE NCC >> > >> > On 25 Apr 2021, at 13:03, Cynthia Revström <me(a)cynthia.re> wrote: >> > >> > imo an NWI seems unnecessary unless we want it for purposes of referencing back to in the future. >> > >> > -Cynthia >> > >> > On Wed, Apr 21, 2021, 04:02 denis walker via db-wg <db-wg(a)ripe.net> wrote: >> >> >> >> Colleagues >> >> >> >> How do you want to proceed with this suggestion? Do we have support >> >> for deleting these ROUTE(6) objects for deregistered space and where >> >> the objects were created before registration? Does anyone have any >> >> objections to this as an ongoing cleanup? >> >> >> >> Do we even need an NWI or can we just ask the NCC to go ahead with it? >> >> >> >> cheers >> >> denis >> >> co-chair DB-WG >> >> >> >> On Thu, 11 Mar 2021 at 15:07, Edward Shryane via db-wg <db-wg(a)ripe.net> wrote: >> >> > >> >> > Dear colleagues, >> >> > >> >> > In response to the recent discussion on "196.52.0.0/14 revoked, cleanup efforts needed", I'd like to propose a regular automated cleanup of route(6) objects in the RIPE-NONAUTH database using unregistered space. >> >> > >> >> > Regards >> >> > Ed Shryane >> >> > RIPE NCC >> >> > >> >> > >> >> > >> >> > Problem Definition >> >> > ------------------ >> >> > When an RIR deregisters IPv4/IPv6 address space, any route(6) objects in the RIPE-NONAUTH database using that address space are not cleaned up (deleted). >> >> > >> >> > >> >> > Solution Definition >> >> > ------------------- >> >> > Once a day, compare route(6) IPv4/IPv6 prefixes in the RIPE-NONAUTH database against the combined delegated stats from all RIRs. >> >> > >> >> > Only route(6) prefixes that are "allocated" or "assigned" in any RIRs delegated stats should remain in the RIPE NONAUTH database. If a prefix is "available" or "reserved" then it is considered to be unregistered, and any associated route(6) objects will be eligible for deletion. >> >> > >> >> > If a prefix is partially "available" or "reserved" then it is also considered to be unregistered. >> >> > >> >> > If a prefix is not listed in any RIRs delegated stats, that prefix is skipped. >> >> > >> >> > The origin AS status is not considered, only the IPv4/IPv6 prefix. >> >> > >> >> > If a newly unregistered prefix is discovered, first allow a grace period of 1 week. This allows time for mistakes in the delegated stats to be corrected. >> >> > >> >> > After 1 week, contact the route(6) maintainer(s) to notify them that the route(6) object will be deleted. >> >> > >> >> > After a further 2 weeks, delete the route(6) object. >> >> > >> >> > A maintainer can request the RIPE NCC to exclude a route(6) prefix from deletion (for example, the deregistration of the prefix is being disputed). For any excluded prefixes, any associated route(6) objects will not be deleted. >> >> > >> >> > >> >> > Impact Analysis >> >> > ------------------ >> >> > There are approximately 738 routes (out of 56,230) in the RIPE-NONAUTH database using a prefix with status "available" or "reserved" in an RIRs delegated stats, which will be eligible for deletion. >> >> > >> >> > There are approximately 94 route6's (out of 1,564) in the RIPE-NONAUTH database using a prefix with status "available" or "reserved", so also eligible for deletion. >> >> > >> >> > There are approximately 64 routes and 37 route6's with a prefix not listed in any RIR's delegated stats. These will not be affected. >> >> > >> >> > When this cleanup is implemented, the backlog of route(6) objects eligible for deletion will be processed at the same time, leading to a large amount of emails to affected maintainers. Once this backlog is processed, the number of route(6) objects affected is expected to be low. >> >> > >> >> > >> >> > >> >> >> > >>

1 0

Re: [db-wg] Cleanup of route(6) objects in the RIPE NONAUTH database using unregistered space
by Edward Shryane 07 May '21

07 May '21

Hi Cynthia, Denis, Thanks for your feedback. I will plan to implement a cleanup job without an NWI, and will keep the DB-WG informed. Regards Ed Shryane RIPE NCC > On 25 Apr 2021, at 13:03, Cynthia Revström <me(a)cynthia.re> wrote: > > imo an NWI seems unnecessary unless we want it for purposes of referencing back to in the future. > > -Cynthia > > On Wed, Apr 21, 2021, 04:02 denis walker via db-wg <db-wg(a)ripe.net <mailto:db-wg@ripe.net>> wrote: > Colleagues > > How do you want to proceed with this suggestion? Do we have support > for deleting these ROUTE(6) objects for deregistered space and where > the objects were created before registration? Does anyone have any > objections to this as an ongoing cleanup? > > Do we even need an NWI or can we just ask the NCC to go ahead with it? > > cheers > denis > co-chair DB-WG > > On Thu, 11 Mar 2021 at 15:07, Edward Shryane via db-wg <db-wg(a)ripe.net <mailto:db-wg@ripe.net>> wrote: > > > > Dear colleagues, > > > > In response to the recent discussion on "196.52.0.0/14 <http://196.52.0.0/14> revoked, cleanup efforts needed", I'd like to propose a regular automated cleanup of route(6) objects in the RIPE-NONAUTH database using unregistered space. > > > > Regards > > Ed Shryane > > RIPE NCC > > > > > > > > Problem Definition > > ------------------ > > When an RIR deregisters IPv4/IPv6 address space, any route(6) objects in the RIPE-NONAUTH database using that address space are not cleaned up (deleted). > > > > > > Solution Definition > > ------------------- > > Once a day, compare route(6) IPv4/IPv6 prefixes in the RIPE-NONAUTH database against the combined delegated stats from all RIRs. > > > > Only route(6) prefixes that are "allocated" or "assigned" in any RIRs delegated stats should remain in the RIPE NONAUTH database. If a prefix is "available" or "reserved" then it is considered to be unregistered, and any associated route(6) objects will be eligible for deletion. > > > > If a prefix is partially "available" or "reserved" then it is also considered to be unregistered. > > > > If a prefix is not listed in any RIRs delegated stats, that prefix is skipped. > > > > The origin AS status is not considered, only the IPv4/IPv6 prefix. > > > > If a newly unregistered prefix is discovered, first allow a grace period of 1 week. This allows time for mistakes in the delegated stats to be corrected. > > > > After 1 week, contact the route(6) maintainer(s) to notify them that the route(6) object will be deleted. > > > > After a further 2 weeks, delete the route(6) object. > > > > A maintainer can request the RIPE NCC to exclude a route(6) prefix from deletion (for example, the deregistration of the prefix is being disputed). For any excluded prefixes, any associated route(6) objects will not be deleted. > > > > > > Impact Analysis > > ------------------ > > There are approximately 738 routes (out of 56,230) in the RIPE-NONAUTH database using a prefix with status "available" or "reserved" in an RIRs delegated stats, which will be eligible for deletion. > > > > There are approximately 94 route6's (out of 1,564) in the RIPE-NONAUTH database using a prefix with status "available" or "reserved", so also eligible for deletion. > > > > There are approximately 64 routes and 37 route6's with a prefix not listed in any RIR's delegated stats. These will not be affected. > > > > When this cleanup is implemented, the backlog of route(6) objects eligible for deletion will be processed at the same time, leading to a large amount of emails to affected maintainers. Once this backlog is processed, the number of route(6) objects affected is expected to be low. > > > > > > >

3 2

Reminder, join us today for the RIPE Database Requirements Task Force BoF
by Bijal Sanghani 05 May '21

05 May '21

Dear all, The third RIPE Database Requirements Task Force (DBTF) BoF will take place today from 16:00 - 17:30 (UTC +2) via zoom. We will present our latest recommendations and discuss a list of open issues with the community ahead of the publication of our final draft. More information and joining details are available at:https://www.ripe.net/participate/ripe/tf/rdb-requirements-tf/bof-5-may-2… Hope to see many of you online later! Kind regards, Bijal on behalf of the DBTF

2 1

RIPE DB Website template update
by Cynthia Revström 04 May '21

04 May '21

Hi Ed and WG, I am sorry for not looking at this during it's time in RC, but I have some comments on the new website templates. I very much appreciate trying to do a more responsive design, to support mobile and other non-landscape screen layouts etc. (I have actually needed to use the hosted RPKI interface once on my phone in the past) However I think there needs to be some more polish done here, not just for the DB thing but all the pages that seem to be in that UI, that being LIR portal, requests etc, DB, and RPKI UI. But a general overview of the issues I have seen is weird scroll bars, menus sometimes not working on my phone, weird spacing, and the content (RPKI UI, Database Query UI, etc) scaling very weirdly on my phone but not on my desktop computer. A few more things probably but I guess my summary is that it just needs a bunch of polish and more integration with the actual page (the section that has the ID "app-workspace" on the database query page). I am not quite sure if I should bring it up with the DB-WG as it does affect the DB interface or if there is some better person/wg to bring it up with, I would appreciate it if Ed could give me some input here. I have also seen similar comments from others, and if easy to implement, I would appreciate an option stored in a cookie or something to use the old UI until these issues have been sorted out. Once again, sorry for not commenting during the RC, I was a bit busy last week. -Cynthia

2 1

New Website Template Deployed to Release Candidate Environment
by Edward Shryane 03 May '21

03 May '21

Dear Colleagues, We have deployed a test version of the new website interface to the release candidate environment: https://rc.db.ripe.net/db-web-ui/query We have reorganised the left-hand and top menus, and modernised the template so it's more mobile friendly. Please let us know what you think. We plan to deploy to production next Monday, 3rd May. Keep in mind the interface is provisional so expect some changes before we go live. More information on the Release Candidate environment can be found on our website: https://www.ripe.net/manage-ips-and-asns/db/release-notes/rc-release-candid… Regards Ed Shryane RIPE NCC

1 1