Hi Ed, I really appreciate the detailed impact analysis and there are some things in there that I hadn't considered before. Among those things is the effect on RDAP which for me honestly feels like a showstopper (especially in combination with the rest of the issues).
I was initially for this idea of using a tuple as the primary key as "ALLOCATED-ASSIGNED PA" has several issues which you also mentioned. I also still believe that the tuple solution is the proper way this should be implemented, had it been done that way from the start. However, when it would break RDAP and quite likely require a fair amount of reworking in all kinds of external software using RDAP, the REST API, and possibly port 43, it just doesn't make sense to me. Given the scale of the issue being quite small to my knowledge I have to say that I think that a partial solution like "ALLOCATED-ASSIGNED PA" is better as the impact is negligible in comparison. Maybe we could also allow for an "enduser-org" attribute or something for those inetnums which would probably have a very small impact I imagine. I am saying this as someone who has both had to think about how to deal with this issue and someone who has worked with software that uses several of the APIs/datasets that would be impacted. So to make my position clear, I cannot currently support the tuple solution due to the massive impact. -Cynthia On Fri, Sep 29, 2023 at 4:25 PM Edward Shryane via db-wg <db-wg@ripe.net> wrote: > > Dear colleagues, > > Following is the impact analysis for NWI-4 "Role of status: field in > multivalued status context" based on the use of the "inetnum:" and "status:" > tuple as a primary key. > > Please let me know any questions, corrections or suggestions, in particular > if there is impact to any functionality that I haven't considered. I will > update the impact analysis as needed. > > Regards > Ed Shryane > RIPE NCC > > > Summary > ------- > Firstly, refer to the Problem Statement for NWI-4: > https://www.ripe.net/ripe/mail/archives/db-wg/2016-May/005242.html > > "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." > > We investigated the impact of allowing a Provider Aggregatable ("PA") > assignment to be the same size as its parent allocation to satisfy NWI-4, > using a tuple of the prefix and status as the primary key to differentiate > between them. > > This change will have a major impact on querying and updating inetnum objects > in the RIPE database. > > A previous impact analysis of a new status value "ALLOCATED-ASSIGNED PA" was > proposed in December 2022: > https://www.ripe.net/ripe/mail/archives/db-wg/2022-December/007722.html > but has a number of drawbacks, in particular: > * The LIR and end-user organisations cannot both be added to the > inetnum > * The LIR and End User cannot both co-maintain the inetnum > So we do not consider this as a feasible solution for NWI-4. > > General > ------- > The inetnum primary key tuple will consist of an "inetnum:" attribute value > in prefix *or* range notation, immediately followed by the "status:" > attribute value. > > Using the status as part of the inetnum primary key is *optional* and only > necessary if there are multiple inetnums with the same prefix. > > There are space characters in the inetnum "status:" values "ALLOCATED PA" and > "ASSIGNED PA", meaning the tuple (primary key) will have a space in it. > > Sorting inetnums in a hiearchy will take *both* the prefix and the status > into account, e.g. an inetnum with "ALLOCATED PA" status will be ordered > before an "ASSIGNED PA" status. > > Only "ALLOCATED PA" and "ASSIGNED PA" status values can be used in the > primary key tuple. > > Only a single "ASSIGNED PA" inetnum can have the same prefix as the > "ALLOCATED PA" inetnum. > > Whois (Port 43) Queries > ----------------------- > Support will be added for an inetnum tuple in Whois queries. Adding the > status to an inetnum prefix or range will be optional. > > If an exact match (i.e. returning a single inetnum) is needed in the query > response, a client may have to specify the tuple (i.e. both the inetnum > prefix and status) in the query. > > If both an allocation and assignment are returned with the same prefix or > range, then the client needs to match which inetnum it was querying for based > on the status. > > Querying for only an inetnum prefix or range without any hierarchical flags > may return multiple inetnum objects in the response, where previously only > one was returned. The allocation is returned first, followed by the > assignment. > > If using the exact match (-x) flag and only specifying the inetnum prefix or > range, multiple inetnum objects may be returned in the response, where > previously only one was returned. The allocation is returned first, followed > by the assignment. > > If using the less specific (-L, -l) flag, if both an assignment and > allocation with the same prefix or range are matched, then first the > less-specific assignment is returned, followed by the allocation. > > If using the more specific (-M, -m) flag, if both an assignment and > allocation with the same prefix or range are matched, then first the > more-specific allocation is returned, followed by the assignment. > > RDAP API > -------- > Querying RDAP for an "ip" resource in the RDAP protocol can only be done by > prefix, not by prefix and status. Hence using a tuple as the primary key is > incompatible with the RDAP protocol. > > If there are multiple matches in RDAP for the same inetnum prefix or range > key, then an error is returned. > > To support querying RDAP for a single "ip" resource, we will need to extend > the protocol to include the inetnum prefix and (optional) status tuple. > > REST API > -------- > The REST API will be updated to allow a tuple to be optionally used in the > URL for an inetnum primary key. The status must immediately follow the > inetnum prefix or range in the URL path and all spaces are URL-encoded. > > REST API requests may have to use a tuple as the inetnum primary key, if > there are multiple matches on the prefix alone. REST API responses containing > an inetnum may contain a tuple as the primary key. > > REST API Create > --------------- > There is no change when creating an allocation via the REST API, as it is > assumed that no assignment will exist yet. Creating an allocation is only > allowed by the RIPE NCC. > > Creating an assignment the same size as an existing allocation will be > allowed. > > The primary key is not included in the request URL when creating an object. > > For example: > (POST) https://rest.db.ripe.net/ripe/inetnum > > REST API Lookup > --------------- > Performing a REST API lookup for an inetnum object requires the tuple to be > specified only if both an allocation and assignment exist with the same > prefix. > For example: > (GET) https://rest.db.ripe.net/ripe/inetnum/192.0.2.0/24ASSIGNED%20PA > (GET) > https://rest.db.ripe.net/ripe/inetnum/192.0.2.0%20-%20192.0.2.255ASSIGNED%20PA > (GET) https://rest.db.ripe.net/ripe/inetnum/192.0.2.0/24ALLOCATED%20PA > > Performing a lookup for a single inetnum prefix or range will fail if the > status is not specified and there are multiple matches (i.e. a REST API GET > request must not match multiple objects). > > REST API Query (Search) > ----------------------- > Refer to the Whois Query (port 43) section above, as the query behaviour is > the same for REST API search. > > Searching for an inetnum prefix or range alone may return multiple inetnum > matches (i.e. both an allocation and an assignment) where previously only a > single inetnum was returned. > For example: > (GET) https://rest.db.ripe.net/search?query-string=192.0.2.0 > > The client will need to match which inetnum it was querying for using the > status. > > Searching for an inetnum prefix or range and status tuple will be supported > and will return a single inetnum match. > For example: > (GET) > https://rest.db.ripe.net/search?query-string=192.0.2.0/24ASSIGNED%20PA > (GET) > https://rest.db.ripe.net/search?query-string=192.0.2.0%20-%20192.0.2.255ASSIGNED%20PA > > REST API Update and Delete > -------------------------- > Specifying the tuple as a primary key in the URL when updating or deleting an > inetnum is optional (using PUT or DELETE methods). > > Updating or deleting an inetnum will only require the tuple to be specified > if there are multiple objects matching the prefix. > > Syncupdates > ----------- > There is no impact on Syncupdates. Objects are submitted in RPSL format and a > tuple is not used. > > Mailupdates > ----------- > There is no impact on Mailupdates. Objects are submitted in RPSL format and a > tuple is not used. > > Nightly Dump and Split Files > ---------------------------- > In the nightly dump and split files (made available on the FTP site), > multiple inetnum objects may have the same "inetnum:" prefix but with > different "status:" values. Clients parsing these files may need to be > updated to match an inetnum based on the tuple of prefix and status. > > Delegated Stats File > -------------------- > In the RIPE delegated stats file (made available on the FTP site), multiple > inetnum objects may share the same prefix but with different "status:" > values. Clients parsing the delegated stats file may need to be updated to > match an inetnum based on the tuple of prefix and status. > > Refer to the delegated stats format specification: > https://ftp.ripe.net/ripe/stats/RIR-Statistics-Exchange-Format.txt > > An IPv4 resource is specified including the start (address), value (size) and > status. > > Authorisation rules for creating route objects > ---------------------------------------------- > To create a route object in the RIPE database, you must authenticate against > the address space you are referring to. > > First an existing exactly matching route object is checked. If there is none, > then any less specific route is checked. If there is none, then an exactly > matching or less specific inetnum is checked. > > If the exactly matching or less specific inetnum is an allocation and > assignment with the same prefix, then (both) the assignment is checked first > followed by the allocation. > > Ref. > https://apps.db.ripe.net/docs/Authorisation/Protection-of-Route-Object-Space/#authorisation-rules-for-creating-route-objects > > Authorisation rules for creating domain objects > ----------------------------------------------- > The creation of domain objects for "in-addr.arpa" domains must satisfy a > hierarchical authorisation against inetnum address space. > > First an existing exactly matching inetnum object is checked. If there is > none, then a less specific inetnum is checked. > > If the exactly matching or less specific inetnum is an allocation and > assignment with the same prefix, then (both) the assignment is checked first > followed by the allocation. > > Ref. > https://apps.db.ripe.net/docs/Authorisation/Protection-of-Reverse-Delegation-Objects/ > > Force deleting inetnum objects > ------------------------------ > Force delete allows you to delete inet(6)num, route(6) and domain objects by > using the maintainer of a covering address space object, instead of the > maintainer of the object itself. This means the "mnt-lower:" of an allocation > or the "mnt-by:" of a provider independent (PI) or anycast assignment or > legacy under contract, each have the authority to force delete any more > specific or related object. > > There is no impact on force delete. If an assignment exists with the same > prefix as an allocation, only the allocation is checked for authentication > during force delete. > > An assignment with the same prefix as an allocation can be deleted using > force delete. > > Ref. https://apps.db.ripe.net/docs/Authorisation/Force-Delete-Functionality/ > > Force deleting route objects > ---------------------------- > If this route object has a maintainer that you do not have the credentials > for, it can block you from creating a new route(6) object. In this case you, > as the resource holder, can simply delete the blocking route(6) object. > > When creating a route object, if an existing exactly matching or less > specific route object has a maintainer that you do not have credentials for, > then it can block you from creating the route object. In this case you, as > the resource holder, can simply delete the blocking route(6) object. > > The force delete functionality will look for an exact matching, encompassing > or less specific inetnum object that is co-maintained by the RIPE NCC in the > hierarchy of the object that is to be deleted. > > If the exactly matching or less specific inetnum is an allocation and > assignment with the same prefix, then (both) the assignment is checked first > followed by the allocation. > > Ref. > https://apps.db.ripe.net/docs/Authorisation/Protection-of-Route-Object-Space/#force-deleting-blocking-route-objects > > > -- > > To unsubscribe from this mailing list, get a password reminder, or change > your subscription options, please visit: > https://lists.ripe.net/mailman/listinfo/db-wg -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
