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
Colleagues "documenting an assignment the same size as an allocation" Is this a problem that you think needs to be solved? If 'yes' then we need to hear your thoughts. If 'no' then the chairs will cancel NWI-4 and move on... cheers denis co-chair DB-WG ---------- Forwarded message --------- From: denis walker <ripedenis@gmail.com> Date: Wed, 23 Feb 2022 at 15:53 Subject: Clear up of old issues - NWI-4 role of status: field To: Database WG <db-wg@ripe.net> 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
participants (1)
-
denis walker