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
