[db-wg] Clear up of old issues - NWI-4 role of status: field

Colleagues

The co-chairs recently had a zoom meeting with the RIPE NCC. One of
the things we discussed was clearing up a number of old issues. We
need to clear the deck and move on with new and perhaps more relevant
issues. We will address a number of issues for the last time. In some
cases the chairs will make a recommendation. As these are quite old
issues, we will take silence as consensus for the chair's
recommendation.

NWI-4
https://www.ripe.net/ripe/mail/archives/db-wg/2016-May/005242.html
This item has been 'open' for 6 years, and it was talked about before
then. So we do need to come to a decision on how to move forward or
drop it and just accept the constraints.

To describe it in simple terms, it is about documenting an assignment
the same size as an allocation.

One idea that was put forward was to allow a twin attribute primary
key for the INETNUM object: range/status similar to the primary key of
a ROUTE object: prefix/origin. The RIPE NCC's impact analysis ruled
out this option. This change would cut so deep into the software,
changing core functionality of the data model with a ripple effect
right across the system.

The only other option currently on the table is one I put forward to
allow the "status:" attribute to be 'multiple'. Business rules would
then limit the use of this feature to only one use case. If the status
is 'ALLOCATED PA' a second "status:" attribute would be allowed with
the value 'ASSIGNED PA'. I don't think any other use case would
require it. Where 2 status attributes exist, only the one with
'ASSIGNED PA' could be removed. This would be a relatively
straightforward change to the software.

Whilst "descr:", "country:", "admin-c:" and "tech-c:" are already
multiple attributes, "org:" and "abuse-c:" are only single. They could
also be made multiple in this one use case but that may have further
consequences. It depends how far you want to go in fully defining an
assignment or just documenting the fact that this allocation is also
an assignment.

Any change to allow a range to be dually represented as both an
allocation and an assignment may break scripts people use to parse the
objects returned by a database query. That is unavoidable. But it may
affect some users' views on whether or not this is a sufficiently
important problem that needs to be solved. Perhaps now there are so
many /24 allocations, it raises the importance of being able to
document an allocation as an assignment.

There is of course an even simpler (pseudo) option, following on from
the geofeed discussion, to define a convention to add:
"remarks: status: ASSIGNED PA"
Which throws us straight back into the debate on parsing "remarks:"
attributes. The database software should not do so. But users querying
this data can do whatever they wish. As Randy says, its interpretation
is in the eye of the beholder.

The chairs make no recommendation on this item. But if there is no
discussion we will simply mark NWI-4 as cancelled.

cheers
denis
co-chair DB-WG