- db-wg - mailman.ripe.net

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 14 May '21

14 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

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

26 Apr '21

Thanks for the input Cynthia. As you are one of the few people who regularly comment on DB issues at the moment, maybe you could take a look at the request for feedback from the DB Task Force recently. Any comments would be appreciated, who knows it may even start a discussion :) cheers denis co-chair DB-WG On Sun, 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

input from community???
by denis walker 22 Apr '21

22 Apr '21

Colleagues Over recent months several important issues have been raised on this mailing list. We have seen comments from maybe 1 or 2 people to some of them. No comments at all to others. We appreciate that covid issues affect many businesses in many ways. So perhaps some of you have far more important issues to deal with than the RIPE Database. It is very difficult for the chairs to see consensus with only a couple of comments. The DB Task Force has also asked for feedback on a number of issues to help them finalise their recommendations. With 3 weeks to the RIPE Meeting and 2 weeks to the DBTF bof, if any of you have some spare moments to review any of the issues raised over the past months it really would help if you can offer some feedback, even better if that promotes some real discussion. cheers denis co-chair DB-WG

1 0

Call for Presentations / DRAFT Agenda RIPE82 - Database Working Group
by William Sylvester 22 Apr '21

22 Apr '21

Dear Working Group Members, Below is the proposed agenda for the Database Working Group for RIPE82. If you would like to present please submit your content as soon as possible to the chairs. 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 – XX mins Edward Shryane, RIPE NCC C. Geofeeds – YY mins Massimo Candela, NTT D. YOUR PRESENTATION HERE – ZZ mins Community Member, RIPE Community E. NWI - Open Proposals – 5 mins Z. AOB (open discussion)

1 0

Whois Release 1.100
by Edward Shryane 22 Apr '21

22 Apr '21

Dear Working Group, RIPE Database release 1.100 has been deployed to the Release Candidate environment. We plan to deploy to production on Thursday 22nd April. This release includes the following main changes: * Separate email address and leading/trailing space during Punycode conversion (#782) * Use status index during update validation (#725) * Fixed aut-num attribute managed flag in lookup and search response (#749) * Added client flag to API for proxying requests (#728) * RDAP nameserver not implemented (#711) * Fixed delete object bug (#723) In addition to other small improvements and bug fixes. The release notes are on the website: https://www.ripe.net/manage-ips-and-asns/db/release-notes/ripe-database-rel… 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… Please let us know if you find any issues with this release in the RC environment. Regards Ed Shryane RIPE NCC

1 1

Cleanup of route(6) objects in the RIPE NONAUTH database using unregistered space
by Edward Shryane 21 Apr '21

21 Apr '21

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.

2 1

RIPE Database Requirements Task Force BoF, 5 May 2021
by Bijal Sanghani 15 Apr '21

15 Apr '21

Dear all, The RIPE Database Requirements Task Force (DBTF) will organise its third BoF on Wednesday, 5 May 2021 from 16:00-17:30 (UTC+2) via Zoom. During this BoF, the DBTF will present its latest recommendations and discuss open issues. More information and joining details are available at: https://www.ripe.net/participate/ripe/tf/rdb-requirements-tf/bof-5-may-2021 Kind regards, Bijal on behalf of the DBTF

1 0

RIPE Database - Historical Information
by Bijal Sanghani 14 Apr '21

14 Apr '21

Dear colleagues, As part of our work in the RIPE Database Requirements Task Force (DBTF), we are trying to understand if providing historical data is one of the requirements the RIPE Database must fulfil. Currently some attributes are filtered out to limit the exposure of unnecessary personal data. If providing historical data is a requirement the RIPE Database must fulfill, we will recommend the RIPE NCC to examine if additional filtering can be applied to limit further the unnecessary exposure of personal data in attributes that are not meant to contain personal data. We are looking specifically for arguments pro or against this recommendation. We’ll then discuss each argument with the task force and make a decision. Kind regards, Bijal on behalf of the DBTF

3 3

RIPE Database - Legal Address
by Bijal Sanghani 14 Apr '21

14 Apr '21

Dear colleagues, As part of our work in the RIPE Database Requirements Task Force (DBTF), we are trying to evaluate if we should recommend that the RIPE NCC publish the legal address of resource holders in the RIPE Database. It will include everybody that is directly receiving resources from the RIPE NCC. This information is already stored in the RIPE Registry but not available in the RIPE Database. However it’s good to note that since the implementation of NWI-10, a new attribute was added to the ORGANISATION object with the Country Code for the country in which the resource holder is legally based. As a reminder, this is our current recommendation: “The task force recommends that the legal address of resource holders who are legal persons be published in the RIPE Database. This will clarify which organisation holds which Internet number resources and ensure quick action from incident responders such as CSIRTs and LEAs in case of abuse.” The task force is aware that there are legal and technical constraints attached to this recommendation. The main challenge is to find a system that can clearly separate natural and legal persons across our service region, so that the privacy of natural persons in the RIPE Database is respected. This also includes corner cases such as SMEs using their home addresses as their legal addresses. We are looking specifically for arguments pro or against this recommendation. We’ll then discuss each argument with the task force and make a decision. Kind regards, Bijal on behalf of the DBTF

3 2

RIPE Database - PERSON Objects
by Bijal Sanghani 14 Apr '21

14 Apr '21

Dear colleagues, As part of our work in the RIPE Database Requirements Task Force (DBTF), we are trying to understand where there is a requirement to keep allowing PERSON objects to be created. We have received arguments for both pro and against this and we propose the following recommendation: promote ROLE objects instead of PERSON objects but still make it possible for users to create PERSON objects. We want to recommend the RIPE NCC to implement stricter checks and measures to prevent users from unknowingly entering personal data in both object types. We are looking specifically for arguments pro or against this recommendation. We’ll then discuss each argument with the task force and make a decision. Kind regards, Bijal on behalf of the DBTF

1 0

Comments on RIPE Database requirements progress
by denis walker 09 Apr '21

09 Apr '21

Colleagues For the benefit of those who don't often check the mail archives of the RIPE Database Task Force there have been 4 meetings in February and March with 3 sets of minutes published so far on their mail archive which can be found here: https://www.ripe.net/ripe/mail/archives/ripe-db-requirements-tf/ The chairs really appreciate the work done by the TF and acknowledge that it is a long and complex task. I have read through these last sets of minutes and feel some things need to be clarified. It may just be language but the minutes suggest the TF has or will make decisions on a number of items, rather than decisions on their recommendations for these items. As it says in their charter "The task force is a small and focused drafting team of up to six persons and not a representative body....Consensus building will take place in the appropriate RIPE working groups". Up to now there has been very little discussion in any working group and certainly no consensus on any of the issues raised as yet. I see the TF making a number of very important recommendations which can then be discussed publicly in appropriate WGs to see if there is a consensus. Let me try to clarify or question some specific issues from recent minutes. I am doing this here, rather than privately with the TF as I have done in the past, as I feel more public discussion is needed on this document the TF is producing. "The task force also discussed what will happen after their final report is published. They agreed that the implementation of the requirements could be delegated to the relevant working groups but mentioned that it will be up to the RIPE Chair team to decide what to do next with it." This implies that the requirements, as suggested by the TF, 'will be' implemented and that the implementation details 'could be' delegated to WGs. The requirements and recommendations themselves, from the TF, need to be discussed in WGs to see if the community even agrees with them. That needs to happen before any discussion on possible implementation. "Ed asked if the task force was considering to make a recommendation regarding assignments as it seems to drive the creation of a lot of unmaintained objects (especially PERSON objects). The task force replied that they were working on a recommendation dealing with assignments but didn’t reach a final decision yet." Firstly it should not be possible to create any unmaintained objects in the database now. If creating assignments is causing too much personal data to be entered into the database it may be the issue of personal data that needs to be addressed. The issue of assignments (whether or not they are needed) should not be confused with that of personal data. These two issues should be considered completely separately. "They [TF] also decided to only publish a final draft ahead of RIPE 82 and skip the publication of an intermediate draft." This is unfortunate as it again reduces community discussion and the chances for the community to offer any feedback to the TF to be incorporated into the final draft. "The task force discussed Randy and Denis’s recent comments on the db-wg mailing list about NWI-2 [historical data]. Ed mentioned that this was one final call from Denis to see if there are any interest from the community to move NWI-2 forward. As the task force is already working on this topic, Ed proposed to inform the db-wg that they can close NWI-2. The task force agreed." The NWIs are action points on the DB-WG. It is for the co-chairs to decide on these action points based on discussion and consensus by the WG members. The issue of historical data queries has been on and off the agenda of the WG for a number of years. I am sure the members of the DB-WG will have more to say yet on this issue. There have been many individual comments. The key to resolving this issue is to get all interested parties to discuss it, openly, at the same time. "The task force decided to keep the current baseline [registration] information data" I presume you mean 'the TF recommends keeping...'. There has been no discussion in any WG on changing this registration data so no consensus either way as yet. "The task force didn’t get enough information and arguments from the questionnaire survey results to decide whether or not the legal address of resource holders should be published in the RIPE Database. The task force will therefore ask the community via email to get more feedback on this topic before making a decision." Again this is an important issue which cannot be decided behind closed doors, based on private comments to a non representative body. There are some major issues in this list of points. In an open, transparent, bottom up, community driven industry these issues can only be decided by open discussion and consensus within WGs. We all welcome the recommendations put forward by the TF but they are by no means final decisions on these issues. They will be the starting points for open, public discussion leading to community consensus. In the meantime, please feel free to comment on and discuss publicly on this WG mailing list any issues regarding the TF draft requirements document which can be found here https://www.ripe.net/participate/ripe/tf/rdb-requirements-tf/the-ripe-datab… cheers denis co-chair DB-WG

3 2

RIPE Database requirements progress
by denis walker 08 Apr '21

08 Apr '21

Colleagues For the benefit of those who don't often check the mail archives of the RIPE Database Task Force there have been 4 meetings in February and March and the TF has just published the minutes of their most recent meeting on their mail archive which can be found here: https://www.ripe.net/ripe/mail/archives/ripe-db-requirements-tf/ Their latest draft requirements document can be found here: https://www.ripe.net/participate/ripe/tf/rdb-requirements-tf/the-ripe-datab… It would be helpful if more people would read this document and comment or discuss publicly on this WG mailing list any issues regarding the TF draft document before they publish their final version of the requirements. They also plan to hold a BOF sometime in May where you can make comments. cheers denis co-chair DB-WG

1 0

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

31 Mar '21

Hi Cynthia, Thanks for your support, my proposal is to automatically delete route(6) objects using de-registered prefixes from the NONAUTH database. For example, this would apply to the routes using the revoked 196.52.0.0/14 prefix which was discussed in January. If there is no objection from the DB-WG, I'd like to turn this proposal into a Numbered Work Item. Regards Ed Shryane RIPE NCC > On 31 Mar 2021, at 07:36, Cynthia Revström <me(a)cynthia.re> wrote: > > Hi Ed, > > I am not sure if this was something to discuss or just something you wanted to mention. > > Anyways as I saw this while looking through older emails, this sounds like a good idea to me. > > -Cynthia > > On Thu, Mar 11, 2021, 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. > > >

1 0