[db-wg] Issue with authorization in hierarchical as-sets

Hi DB-WG,

While looking into the discussion about requiring hierarchical as-sets
I wanted to see if all current hierarchical as-sets were authorized by
the ASN holders and I found two separate issues (in my opinion).

I could find at least two cases of hierarchical as-sets that were
likely created before RIPE and RIPE-NONAUTH split.
They are using APNIC ASNs and there are aut-num objects for both of
them in RIPE-NONAUTH, but the as-sets are still in RIPE.
I am not sure of the scope of this issue or if others consider it an
issue, but it seems like that should possibly get cleaned up, or at
least get checked out.

I only tried to check if there were any occurrences of this, not
trying to find a complete list, so I just checked for any 32-bit APNIC
ASNs in the db dump using grep.
For those who want to look at it, the grep command I used was: grep
'^as\-set:\s*[Aa][Ss][1][3-6][0-9][0-9][0-9][0-9]' ripe.db.as-set

There is also another issue related to authorization when it comes to
hierarchical as-sets.
While authorization by a maintainer listed as mnt-by on the aut-num
object is required to create an as-set, that maintainer can then later
be removed and there is no force-delete option like there is for
inet(6)num delegations.

I think that a force-delete option should be implemented so any
maintainer with mnt-by on the relevant aut-num can delete an as-set.
I think that it would also be helpful to introduce a "associated
as-set objects" list to the DB web UI, just like there is for
associated route objects currently.

Something that could be an issue is the cleanup, what happens with an
hierarchical as-set when the relevant ASN is de-registered?
Maybe someone on the DB team could clarify?

-Cynthia