Dear all, tl;dr:No, because I agree with the need to understand these several "functionally diverse” DB as ONE holistic concept of RIPE DB. Additional context: Reading the RIPE Database Documentation (https://www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe-datab...) it says that yes, the RIPE Database holds data for three separate registries (RIPE Internet Number Registry (RIPE INR) RIPE Internet Routing Registry (RIPE IRR) Reverse Delegation and ENUM Registry). However, while these could be three independent databases, the information in each of them is related to each other. In the past it was therefore decided to integrate the three registries into one logical database (which is also one physical database). I too substantially agree with the need to understand these several "functionally diverse' DB as one holistic concept of RIPE DB. One of the things I want to stress is that the RIPE Database is in reality used by many members of the RIPE community on a day-to-day basis and for many reasons, and if it is true that the RIPE Database has grown in complexity with more features, we need to keep in mind this practical usage, and perhaps strive for simplicity. Sara From: ripe-db-requirements-tf <ripe-db-requirements-tf-bounces@ripe.net> On Behalf Of Bijal Sanghani Sent: 05 November 2019 17:46 To: Shane Kerr <shane@time-travellers.org> Cc: ripe-db-requirements-tf@ripe.net Subject: Re: [ripe-db-requirements-tf] Requirements for the RIPE Database... or Databases? On 17 Oct 2019, at 14:07, Shane Kerr <shane@time-travellers.org<mailto:shane@time-travellers.org>> wrote: Fellow TF members, tl;dr Do we want to explicitly say that we are making requirements for separate databases? (Probably with separate requirements.) More words follow... I was thinking about starting off a discussion about stakeholders in the RIPE Database, and I quickly remembered that the RIPE Database is at least two and maybe more databases in one. We have the number registry: * IP address assignments (hierarchical) * ASN assignments (semi-hierarchical) We have the routing registry: * Routes * Routers * Other routing policy information in various objects & attributes We have some DNS information, which is used to configure DNS delegation in DNS servers that the RIPE NCC maintains: * Reverse DNS domains We have abuse/security information: * "Incident Response Team" (a.k.a. CERT) * Various attributes (abuse-c, remarks, ...) We have the last remains of attempts at lighthearted fun: * Poems We have contact information used by everything (secondary data, cleaned up automatically if not referenced by something else): * Organisations * Persons * Roles We have the authentication/authorization that protects stuff (also secondary data, although I don't think cleaned up automatically): * Maintainers * PGP & X.509 certificates Finally, I'd like to note that there is a highly-coupled database, which is the RIPE NCC member database. The RIPE NCC keeps all kinds of non-public information, some of which is pushed to the RIPE Database (like organization contact information), some of which the RIPE Database has specific access to (like SSO authentication), and some of which is never entered into the RIPE Database (like billing status). So... do we want to explicitly say that we are making requirements for separate databases? 😄 I believe we should cover all databases that come under the RIPE Database umbrella today and as part of our role we should review their role and need. It would be good to hear what others think, should our work cover ALL databases within the RIPE database? Is there agreement here? Thanks, Bijal Cheers, -- Shane ******************* DISCLAIMER : This message is sent in confidence and is only intended for the named recipient. If you receive this message by mistake, you may not use, copy, distribute or forward this message, or any part of its contents or rely upon the information contained in it. Please notify the sender immediately by e-mail and delete the relevant e-mails from any computer. This message does not constitute a commitment by Europol unless otherwise indicated. *******************