[ripe-db-requirements-tf] Requirements for the RIPE Database... or Databases?

Hi Shane, 

Good question. “RIPE Database” is the common umbrella term for everything you mention and more. Which IMHO is the fundamental mistake that is causing most of the data accuracy and reliability concerns – and confusion – that people are flagging. Would like to already share some improvement ideas that I have been thinking for some time. 

I believe many issues would be significantly mitigated with a major decoupling of the primary databases on the front-end along with their purpose and functions. Give them clearly separated webpages/search boxes, definitions, APIs (more middle-tier) etc. to help users understand what exactly they are looking at. 
Example: 

1. RIPE NCC registry 
Purpose: list top-level IP resources and entities that officially hold them. 
Responsible party for maintaining the data: the RIPE NCC. 
• RIPE NCC to perform periodic checks to uphold integrity of the data 

2. IP holder database 
Purpose: database in which holders manage their IP resources. 
Responsible party for maintaining the data: the IP resource holder. 
• Incl. IRR data 

---

Another potentially significant improvement that I really think we should consider is to limit the number of objects and attributes to simplified but mandatory data sets based on bare-minimum public registration requirements. To make it easier for the RIPE NCC and IP holders to keep the data up-to-date. 
Any other IP management could (and should) be done in org’s internal IPAM solutions, not dumped into the public RIPE database because it becomes very difficult to keep accurate and thus dilutes the integrity of the entire RIPE database system. 

We could review what is/is not required starting with the basics. E.g.: 

1. RIPE NCC registry 
• IP resource object attributes: 
- Top-level IP range or ASN 
- Org object (thinking out of the box – maybe a mechanism could be built that enables org objects to perform the function that MAINTAINERS currently perform and retire MAINTAINERS altogether?)
- Last modified date 

• Org object attributes:
- Legal entity name 
- Chamber of commerce registration number 
- Basic contact info 
- Abuse contact info 
- Last modified date 

2. IP holder database 
• IP resource object attributes:  
- Lower level IP prefix 
- Org object (thinking out of the box – maybe a mechanism could be built that enables org objects to perform the function that MAINTAINERS currently perform and retire MAINTAINERS altogether?)
- Last modified date

• Route object attributes: 
- Route prefix 
- Origin ASN 
- Org object (thinking out of the box – maybe a mechanism could be built that enables org objects to perform the function that MAINTAINERS currently perform and retire MAINTAINERS altogether?)
- Last modified date 

I know all of this is a level or two more specific than the skeleton doc that we need to deliver this year, more appropriate for a workshop. Just want to share my initial thoughts with the group. 


Regards, 
James 


> On October 17, 2019 at 3:07 PM Shane Kerr <shane at 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? 😄
> 
> Cheers,
> 
> --
> Shane
>