While trying to update a route-set, get "RS- is a reserved prefix"

[dhutchin-ctl]

Describe the bug
While trying to update a route-set, via email or via /v1/submit interface, I get "RS- is a reserved prefix". Likely due to maintainer object by same name.

To Reproduce
First, notice contents of DB:
irrd=> select pk, rpsl_pk, object_class from rpsl_objects where rpsl_pk = 'RS-AS14566';
pk | rpsl_pk | object_class
--------------------------------------+------------+--------------
0277b414-07fd-47ab-bc51-3b429c17dad6 | RS-AS14566 | mntner
f3865eaf-48c0-4b9b-a865-099c947d880a | RS-AS14566 | route-set
(2 rows)

Then post the following JSON to /v1/submit:
{"objects":[{"route-set":"RS-AS14566","descr":["XeroxBusinessServices0620292"],"members":["13.28.0.0/16,\n 13.29.0.0/16,\n 13.30.0.0/16,\n 63.87.170.0/23,\n 63.97.180.0/22,\n 63.101.150.0/23,\n 63.160.118.0/23,\n 64.40.232.0/24,\n 64.40.233.0/24,\n 64.40.236.0/24,\n 64.40.237.0/24,\n 65.172.222.0/23,\n 65.198.132.0/23,\n 65.248.100.0/22,\n 66.111.138.0/23,\n 66.111.140.0/23,\n 142.11.150.0/24,\n 142.11.152.0/24,\n 204.110.65.0/24,\n 204.110.68.0/24,\n 204.110.71.0/24,\n 205.244.8.0/23,\n 208.7.160.0/23,\n 8.40.209.0/24,\n 63.86.4.0/24,\n 66.111.177.0/24,\n 66.111.18\3.0/24,\n 66.111.188.0/24,\n 66.111.190.0/24,\n 66.111.191.0/24,\n 205.144.56.0/24,\n 138.69.200.0/23,\n 63.160.119.0/24,\n 66.111.150.0/23,\n 66.111.152.0/23,\n 204.144.55.0/24,\n 138.69.199.0/24,\n 138.69.227.0/24,\n 138.69.198.0/24,\n 138.69.251.0/24,\n 138.69.180.0/24,\n 138.69.210.0/23,\n 138.69.224.0/24,\n 198.148.129.0/24,\n 138.69.222.0/24,\n 138.69.204.0/23,\n 138.69.73.0/24,\n 138.69.213.0/24,\n 138.69.214.0/24,\n 138.69.239.0/24,\n 149.55.24.0/24,\n 149.55.25.0/24,\n 149.55.26.0/24,\n 149.55.27.0/24,\n 149.55.28.0/24,\n 162.128.6.0/24,\n 162.128.7.0/24,\n 162.128.8.0/24,\n 162.128.9.0/24,\n 205.235.96.0/24,\n 205.235.104.0/24,\n 162.128.11.0/24,\n 162.128.3.0/24,\n 162.128.23.0/24,\n 149.55.0.0/16,\n 147.116.0.0/16,\n 104.166.24.0/22,\n 156.150.36.0/24,\n 138.69.206.0/24,\n 138.69.221.0/24,\n
104.166.28.0/23"],"admin-c":["MIH9-LEVEL3"],"tech-c":["MIH9-LEVEL3"],"notify":["hidden"],"mnt-by":["RS-AS14566"],"changed":["hidden\nchanged: hidden\nchanged: hidden 20230326"],"source":"LEVEL3"}],"passwords":[""],"override":""}","timestamp":"2023-03-27T13:28:11.259Z"}

To which I get a response of:
Invalid name: RS-AS14566: RS- is a reserved prefix

Expected behaviour
Even though there is a maintainer object of the same name (admittedly, poor form), I should be able to update the route-set. All route-set names should be prefixed with 'RS-'. RFC2622 does not have a restriction for a maintainer to NOT be prefixed by 'RS-'. I did not find such a restriction in IRRd V4 documentation. There are 27 examples of maintainers prefixed with 'RS-' in the RIPE registry and 5 in the LEVEL3 registry.

IRRd version you are running
4.2.6

[dhutchin-ctl]

I did not test it, but I assume the same problem exists with maintainers whose rpslname starts with "AS-". There are 2 of those @ LEVEL3, 7 @Ripe, and 1 @ AFRINIC.

[mxsasha]

RFC 2622 section 2 says:

Names starting with certain prefixes are reserved for certain object types. Names starting with "as-" are reserved for as set names. Names starting with "rs-" are reserved for route set names.

The error you are seeing is not caused by whether or not such a maintainer object exists, but because it makes the syntax of the route-set invalid. The mnt-by of a route-set must contain a valid mntner name, a mntner name can not begin with RS-, therefore syntax validation on the route-set fails.

[dhutchin-ctl]

Ahha, I missed section 2. The problem is, IRRd allows the import of objects that don't meet the requierment (I guess it pretty much had to). irrd=> select rpsl_pk, object_class, source from rpsl_objects where (object_class != 'as-set' and upper(rpsl_pk) like 'AS-%') or (object_class != 'route-set' and upper(rpsl_pk) like 'RS-%') order by source; rpsl_pk | object_class | source ------------------------+--------------+--------- AS-AFRINIC | person | AFRINIC RS-BELCAN-MNT | mntner | LEVEL3 AS-40459-MAINT | mntner | LEVEL3 RS-KTC2C | mntner | LEVEL3 AS-COMTECSOL | mntner | LEVEL3 RS-IPNETWORKED | mntner | LEVEL3 RS-AS394900-MN01 | mntner | LEVEL3 RS-BPPING-1-MNT | mntner | RIPE RS-DELSYSTEMS-1-MNT | mntner | RIPE RS-EOFFICE-1-MNT | mntner | RIPE RS-EP-ENTEL-1-MNT | mntner | RIPE RS-INFOSTUD-1-MNT | mntner | RIPE RS-KABLOTEL-1-MNT | mntner | RIPE RS-MAXBET-1-MNT | mntner | RIPE RS-MCLOUD-1-MNT | mntner | RIPE RS-MTSDOO-1-MNT | mntner | RIPE RS-PARKINGSERVIS-1-MNT | mntner | RIPE AS-DONNATRANS | mntner | RIPE RS-RRC-1-MNT | mntner | RIPE RS-MASKO-1-MNT | mntner | RIPE RS-MNT | mntner | RIPE RS-NINET-1-MNT | mntner | RIPE RS-NLBBANKA-1-MNT | mntner | RIPE AS-202723 | mntner | RIPE RS-RNIDS-1-MNT | mntner | RIPE RS-CITADELA-1-MNT | mntner | RIPE RS-IBS-1-MNT | mntner | RIPE AS-CU-MNT | mntner | RIPE AS-MNT | mntner | RIPE RS-ASTRATELEKOM-1-MNT | mntner | RIPE RS-GROMNET-1-MNT | mntner | RIPE RS-MIRABANK-1-MNT | mntner | RIPE RS-NELTCO-1-MNT | mntner | RIPE RS-NELTCO-3-MNT | mntner | RIPE RS-NELTCO-SHARE-MNT | mntner | RIPE RS-ROUNDGLOBE-1-MNT | mntner | RIPE RS-UZZPPO-1-MNT | mntner | RIPE AS-1DOTFM | mntner | RIPE RS-YUVIDEOSERVIS-1-MNT | mntner | RIPE AS-1FOTFM | mntner | RIPE AS-37558-AFRINIC-MNT | mntner | RIPE (41 rows) This only matters for authoritative sources, so I can work around the few instances by hacking directly to the database when the issue occurs.