Hi Job
Again for clarification, I was jumping the gun a bit talking about possible 
solutions. I agree with the problem statement as put forward.
cheersdenis

      From: "[email protected]" <[email protected]>
 To: Job Snijders <[email protected]>; "[email protected]" <[email protected]> 
 Sent: Wednesday, 25 May 2016, 15:40
 Subject: Re: [db-wg] NWI-4 - role of status: field in multivalued status 
context
   
Hi Job
This is another excellent example of how the data model could be improved. 
Currently we are constrained by this issue of the address range being the 
primary key that cannot be duplicated. What we see here is the need for an 
address range to be stored internally as both an allocation and an assignment. 
Then depending on the query the 'information' returned either shows the 
allocation data or the assignment data rather than the 'raw' data held in the 
database.

cheersdenis

      From: Job Snijders <[email protected]>
 To: [email protected] 
 Sent: Wednesday, 25 May 2016, 15:20
 Subject: [db-wg] NWI-4 - role of status: field in multivalued status context
  
Dear Working Group,

(You can review 
https://www.ripe.net/ripe/mail/archives/db-wg/2016-April/005190.html 
to ensure you have an overview of the next steps.)

NWI-4 
---------
    The RIPE NCC was tasked with the following action point: AP70.2
    [RIPE NCC] Come up with a proposal for the status: field to fix the
    requirement that certain objects may need multivalued status.

    Some believe that the main underlying issue here is that it is
    currently not possible to create an assignment that is the same size
    as an allocation in the RIPE Database. And resource holders are of
    course supposed to create an assignment for the address space in an
    allocation that is in use, by address policy.

    The main reason for this limitation is that the INET(6)NUM attribute
    is a primary key. There is a work-around for this problem. Instead
    of creating an assignment of the same size it's possible to create
    two smaller assignments instead. In our (red: RIPE NCC) experience
    this work-around has always been accepted.

    Still if the allocation is used as a whole, having a single
    assignment for the whole block is a more accurate reflection of
    reality, and it reduces the amount of objects to maintain.
----------

The AP70.2 action point refers to a suggest solution, following earlier
discussion. But the chairs believe it would be good to bring this back
to a clear problem statement first, and then suggest different solutions
and their respective benefits and/or problems.

Furthermore address-policy wg policies mention the different statuses
and what the different statusses reflect. Therefore we'll need to inform
the address policy working group as well.

If you agree or disagree with this problem statement, please indicate
your opinion on this mailinglist. Refinements to the text are welcome
too.

Kind regards,

Job



   

  

Reply via email to