On 21/02/2013 11:11, Andrea Cima wrote:
- According to the initial ERX transfer list, 339 inetnum objects have been deleted. This may however mean that more specific objects have been created by the maintainer.
- 393 inetnum objects have RIPE-NCC-LOCKED-MNT in the mnt-by line. These objects were registered in the RIPE DB before the ERX transfer took place, and were maintained using RIPE-NCC-NONE-MNT. When this was deprecated the RIPE NCC locked all objects referencing it. As these objects are still locked, no one is currently managing this data.
- 851 inetnum objects have the ERX auto-generated maintainer (in the form ERX-NET-138-81-MNT) as mnt-by. The holders 'may' have been given the password and are 'able' to manage this data, but may or may not have done so. Others were not given the password and are not managing the data. Without deeper analysis we can't separate these groups.
Interesting. So at the moment, it looks like between 30%-40% (i.e. from (393+851)/4050 to (339+393+851)/4050) of the ERX address space is arguably abandoned from the point of view of RIPE-DB maintainership - although obviously not necessarily from other points of view. This would lend some support to my speculation that there was a substantial quantity of address space in the dead / lost category, and that it may be a good idea to take this into account in the policy formation. I tried playing around with a local copy of ripe.db.inetnum.gz earlier, but couldn't reproduce these numbers because some (many?) of the status: lines in the public DB are wrong. Do you have the raw data here? I.e. a canonical list of the ERX inetnums, and which category out of the 6 mentioned above that each falls into? Nick