[db-wg] Decision on NWI-4 INETNUM status values

Hi Nick, Leo,

> On 4 Apr 2022, at 22:19, Nick Hilliard via db-wg <db-wg at ripe.net> wrote:
> 
> Leo Vegoda via db-wg wrote on 04/04/2022 20:50:
>> Why do they need to register this
>> assignment? Why can the allocation not be left as it is and assumed to
>> be used by the organisation holding it?
>> What am I missing?
> 
> it's a fly in the ointment.
> 
> There are three options to handle this situation, possibly more:
> 
> 1. don't allow an allocation + an assignment to encompass exactly the same space. This is a function of the data model, which states that inetnum: is the primary key. This stops organisations from having a 1:1 mapping between their internal assignment databases and the public ripedb view.  This is what we have at the moment.
> 
> 2. change the ripedb data model to key on inetnum+status. This would allow an assignment and an allocation to have the same inetnum, which would allow organisations to have a 1:1 mapping between their internal assignment databases and the public ripedb view.
> 

After Carsten Schiefner first suggested this approach last year, the DB team investigated how to implement a prefix+status tuple for inet(6)num types.

The RIPE database already contains a primary key tuple, i.e. the route and route6 object types combine the prefix and origin as the primary key. So it's possible to extend this to inet(6)num types.

A primary key tuple must be optional for inet(6)num types, so the existing prefix (only) as primary key continues to work for the common case, but allow the prefix & status tuple to differentiate an identically-sized ALLOCATED PA / ASSIGNED PA hierachy as a special case. However this means supporting *two* forms of primary key which increases complexity (a key could match a single object or multiple objects, currently a key can only match a single object).

Adding support for an optional status in the primary key means significant re-work in the Whois application. The code base is currently built around the inet(6)num prefix as the primary key, and a given key matches only a single object. Changing this will involve significant effort and risk of changing core functionality.

For route(6) authorisation, there is an ambiguity in which prefix to use, if there are multiple matches of the same size. Do we allow authorisation against either the ALLOCATED PA prefix or the ASSIGNED PA prefix, or both?

Clients will also need to be updated. If a client queries by prefix alone, this can match one or multiple objects. A client will need to include the status when querying to identify a single object. 

Including a space in the primary key tuple (due to the status value) will also increase complexity, as a space can't be used as a separator but it's part of the key.

In summary, adding support for a primary key and status tuple will be a very expensive (time and effort) change on the Whois server side, and will also necessitate client-side changes.

Regards
Ed Shryane
RIPE NCC