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