NIC handle reuse in the RIPE Database ------------------------------------- Current situation ----------------- Currently when a database update requests the creation of a new NIC handle for a newly created person or role object, by specifying the AUTO-X (0<=X<=9), the software looks for an unused number in the sequence of nic handles with the same initials. The assignement is not sequential but rather tends to fill in the nic handle space in a pattern with a random component, giving more chances to nic handles with low numbers. Thus, the new NIC handle doesn't necessarily have the biggest sequence number used in the Database so far as it may use one corresponding to a previous existing person or role object that was deleted some time after and is now a "hole" in the sequence. This can lead to misunderstandings and/or inconsistent data due to nic handle replacement (either accidental or intentional). A user may also specify a specific number for the nic handle when sending in a request for creation of a person or role object. If the requested nic handle is not currently in use the database the request for that nic handle will be granted, otherwise an error will be generated. This allows users to undo accidental deletions of person/role objects. Consequences ------------ This has, in the past, lead to some problems where person objects were replaced by unrelated person/role objects therefore making the contact information invalid for some database objects. Recently, the database software has been modified to perform some checks on user actions when the user tries to delete contact information: Person and role objects can only be deleted when they are not being referenced by any other object in the database. This helps to prevent accidental deletions while the object is still needed in the databse. This can't prevent the kind of "mailicious" deletions where all the referencing objects are deleted and then the person object is also deleted. This can only be prevented through a different set of functionality in the Database: the use of proper authentication. Addressing the problem ---------------------- In the past discussions have taken place about proposals to prevent the RIPE DB to reuse low numbered nic handles when generating new ones through the AUTO mechanism, while still allowing users to request specific unused low numbers. Modifying the software to assign new handles that have sequence numbers greater than the "last one used" could be straightforward except for one detail, the definition of the "last one used". >From the non-sequential nature of the current algorithm it is clear that there are a lot of holes (of variable size) in the nic handle space. Also, some users attach special meaning to numbers such as 666, 1000, 2000, 5000, 10000 etc leading to a situation where a particular nic handle sequence can have a more or less compact set with low numbers and then some scattered arbitrarily large ones. Simply picking the biggest number for a particular letter combination at a particular moment will sometimes result in all new nic handles having big numbers. Also, the software would not be able to ensure that an arbitrarily big nic handle was not used and deleted in the past. In short, to ensure that no nic handle gets reused the RIPE DB would have to forbid also specific nic handle assignement or alternately keep track of all nic handles ever assigned. We believe this is not a desired outcome. Two letter combinations are about 700. Three letter combinations are about 17600 and 4 letter combinations are about 457000. The nic handle space is repeated for every possible registry (RIPE, APNIC, ARIN,...) The new DB currently being developed could be engineered to keep a marker for every nic handle that is ever used. However, this can lead to a rather big table since essentially no deletions would occur in the table of nic handles (there are currently over one million entries). Conclusion ---------- We believe there is no perfect solution and that the one taken will depend on the community's perspective on how important this problem is. We suggest to keep the current behaviour. We request the community to evaluate the importance of modifying the current DB behaviour in this regard.