Dear WG,
Please review the below problem statement:
--------
NWI-6 - Applicable data model not clear from contextless objects
Currently it is not possible to derive what semantics or data model
applies to a RPSL object in the RIPE database. This disadvantageous
property introduces complexity all across the board:
- redefining the semantics of an existing RPSL attribute
introduces operational complexity.
- operators have precisely align their client-side software
deployment with the RIPE database deployment timeline.
- deprecating RPSL attributes which are "mandatory" (as defined
in the RPSL dictionary) is challenging as a client cannot know
if the object stems from a time in which the attribute was
mandatory or not.
- objects which are provided without historical context are hard
to parse, one cannot programmatically know how to interpret
the attributes or assess which attributes should have been
there.
-------
As author of this problem statement and co-chair of this Working Group I
have the following notes I'd like to share. Reflecting on the past
period in which I was tasked to assist the group in helping the database
progress, I've observed that any change or even proposal for change in
the database is easily met with detestation.
A recurring theme is that post-deployment people comment "I was not
expecting this", and before in the proposal phase other stakeholders
state "this is too complex to deploy, we'll break old clients".
I believe that if we somehow address the issue of introducing change
_itself_, we'll garner a crucial feature which will be rewarding in
whatever direction the database takes in future.
