Requirements for the RIPE Database... or Databases?
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
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@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
On 17 Oct 2019, at 14:07, Shane Kerr <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
Bijal, all, On Tue, Nov 05, 2019 at 04:45:31PM +0000, Bijal Sanghani wrote:
It would be good to hear what others think, should our work cover ALL databases within the +RIPE database? If there is not agreement here, we should look at bringing the call forward.
I don't completely disagree, but i don't agree, either. We should take one more step back and look at the question what the core function of the RIR as a number resource registry is, especially under aspecty of "unique identifiers". From there we should indeed look at what other databases or what other views on teh data exist and again try to relate this top the core function. That leads to the question what data we need for what purpose (and again, 'purpose' should not trigger a GDPR trauma). As a start, far from completeness, the registry has to record who the resource holder is, especially to prevent and/or solve contention; More in the past, rather than for v6, the DB was also used to document assignments (out of allocations) to justify new assignments. At least iunitially, there was also an operational component, thus tech-c. Ideally, there'd be tangible references for my claims above, but I'm sure we need to go back and consult institutional/collective memory for some of the design objectives. -Peter
participants (4)
-
Bijal Sanghani -
james＠kennedyipam.com james＠kennedyipam.com -
Peter Koch -
Shane Kerr