ripedenis--- via db-wg wrote on 01/09/2020 23:56:
Let me try to revive this conversation and see if we have a consensus.
There seemed to be two main issues: 1/ MNTNER names not having a clear 'tag' indicating a MNTNER object 2/ MNTNER names specifically confused with ASNs
For the first part we can add a prefix (MNT-) or suffix (-MNT), or allow both options, and enforce this on all 'new' MNTNER object creations.
there are 12660 (22%) objects starting with MNT-, 36334 (64%) starting with -MNT, and 7844 (14%) with neither MNT- nor -MNT. Curiously, there are 10 objects starting with MNT- and ending with -MNT. I guess some people like to be sure. Someone seems to have registered "MNT" as a maintainer name, which is inventive in a minimalist way. There are 14 objects which match /^AS([0-9]+)$/. This is messy because by convention that regexp describes an ASN. There are 4 objects which match /^AS-/. This is a problem because /^AS-/ is reserved for as-sets. These need to be removed / renamed. There are no objects which match /^(FLTR|RTRS|PRNG)-/. There needs to be code to block /^(AS|FLTR|RTRS|PRNG)-/, and the existing 4 objects probably ought to be changed.
For the second part, if there are specific objects that 'look like' ASNs and not belonging to the organisations holding those ASNs, they can be further investigated, if it is considered necessary. Please also bear in mind that PERSON and ROLE objects can also appear to be ASNs. It is also possible to create MNTNER objects that could be confused as IP ranges to unfamiliar database users. There may be other examples of objects that could be confused as a resource object. So if we go down this route where do we draw the line?
Creating one key which looks like another style of key is going to cause confusion. Some judicious use of regular expressions might be a good to stop this. Nick