No, expectation is that people getting AMPR address space should have the subnet they're in registered with the portal. That includes non-connected hosts and /32s.
Is it really a good idea to base the cleanup on data in the portal? I mean, the guy running the portal clearly does not have the resources (or the motivation?) to do even minor maintenance on it, let alone finish work on features like the DNS registration that have been in incompleted state for years. Is it a good idea to make our entire network dependent on that?
I cannot remove a subnet that was erroneously added in the past (and where user subnets where added inside) without deleting those, and a request to the maintainer to do that outside the portal UI that I sent months ago is still not processed.
I also cannot add any regional subnets for which parts are already registered to users. The whole implementation of subnet hierarchy and record ownership is much too strict, it only works when everything is done "the correct way" on the first try, which simply is not realistic. Compare it to HamnetDB where you can simply reshuffle the whole subnetting by inserting, deleting or editing existing records within the existing hierarchy.
I also don't like the idea to send a request to all users to "register themselves" and then being bombarded with allocation request mails from the portal that all need to be manually edited because the requesting user cannot specify an existing allocation to be registered.
Users that do not understand the whole mechanism cannot be ignored, because either you don't process the request and it remains on the todo list, or you reject the request and those users just click the links in the rejection mail which results in the same request being posted again :-(
In 44.137.0.0/16, really only the users that want to run an IPIP tunnel are registered in the portal, there are many other users that connect in a different way. Luckily we are not affected by this cleanup because we are BGP routed, but at the same time that also shows how this method is failing. After all, what does the routing method have to do with the DNS contents? Basically nothing. Why should all our inactive records remain there while those of other countries are deleted even when they may be active?
When we want to clean the DNS, we should look at the situation on a country by country base. I am all for deleting entries for callsigns that have expired, and in fact I regularly do that. Probably other countries also have lists of active callsigns and a quick scan can be made to delete all expired callsigns and probably also those records that are not related to callsigns. We could request all coordinators to send a list of active callsigns, and we could process those lists to generate a deletion list like I already do for my area.
We could also ask each coordinator what is the state of IP packet or other use of those addresses in their country, and maybe get whole networks deleted when they no longer exist.
I will try to dig in the old data I still have saved (for my area) to generate a list of callsigns and the date of last registration or reconfirmation, and try again to contact all callsigns with records before a certain date and delete them when there is no reply. This should clean out more records than the previous run, where I only deleted those registrations where the owner replied they no longer required them.
Rob