NWI-6 Applicable data model not clear from contextless objects
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.
On Thu, Jun 16, 2016 at 07:46:20PM -0500, Job Snijders wrote:
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.
I agree with the problem statement. Piotr -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski@polsl.pl
On 2016 Jun 16 (Thu) at 19:46:20 -0500 (-0500), Job Snijders wrote: :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. : I agree with the problem statement -- Whom computers would destroy, they must first drive mad.
participants (3)
-
Job Snijders -
Peter Hessler -
Piotr Strzyzewski