[db-wg] NWI-?? Rationalising contact references

Colleagues

I would like to propose a new NWI about contact references in the RIPE
Database. Something that has needed to be cleaned up for a very long
time. I have written a draft Problem Statement and Solution Definition
below. Your comments are appreciated.

cheers
denis

co-chair DB-WG


Problem Statement

The RIPE Database only uses inheritance for references to abuse
contacts. The admin, tech and zone contacts all use local direct
references in every resource object. This has resulted in millions of
unnecessary, repetitive, redundant references throughout the database.
This can make the data difficult to manage and keep up to date if any
referenced contact is replaced. A common problem was referencing a
PERSON object in thousands of resource objects. When that person
leaves the company it requires a mass data update.

Adding inheritance to all contact attributes allows for a cleanup and
removal of massive amounts of redundant data references. There are
millions of assignments to end users with contact references pointing
back to the resource holders contacts. It is confusing to have
unnecessary, repeated contact references in these assignments. This
would simplify the basic structure of the database. I see this
simplification as a first step towards removing unnecessary personal
data from the database.


Solution Definition

I would like to suggest adding inheritance to the other three contacts
for admin, tech and zone. The only syntactical changes needed are to
make "admin-c:", "tech-c:" and "zone-c:" 'optional' in INET(6)NUM,
AUT-NUM and DOMAIN objects and add "zone-c:" as an optional attribute
in the ORGANISATION object.

At the time of implementation nothing needs to be changed. Next time
an ORGANISATION object is updated it needs to have a default
"admin-c:", "tech-c:" and "zone-c:" added (if it doesn't already have
them) if it is a resource holders object (ie if it has an "abuse-c"
attribute).

Creating new resource objects, eg assignments, or receiving new
allocations, won't need to have these contact attributes included if
they are the same as a parent object or the default values in the
ORGANISATION object.

A standard query for a resource object will return the object as it
is, including any optional contact attributes contained within that
object. Three new query flags, '--admin', '--tech' and '--zone' added
to a query for a resource object will return the correct hierarchical
contacts for that resource.

The RIPE NCC can provide tools for doing cleanups of resource
hierarchies to remove redundant contact attributes with an option to
list specific objects that should keep their local values.