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