What is the RIPE Database in 2021?
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
participants (1)
-
denis walker