[db-wg] mntner with misleading primary key

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