RIPE handles and the 'status' attribute in the RIPE-database Document: ripe-126 Updated by: ripe-127 ('status:' attribute) RIPE-126 Introduction This document describes two additions to the RIPE database, which were implemented during the last weeks that Marten Terpstra maintained the RIPE database software: RIPE-handles, and the status-attribute. RIPE-handles The design of the RIPE-database stores contact info on networks in separate 'person' objects: inetnum: 193.0.1.0 netname: RIPE-EXP descr: Sample database-assignment, RIPE NCC descr: Amsterdam, Netherlands country: NL admin-c: Anne Lord tech-c: Mirjam Kuehne changed: GeertJan.deGroot@ripe.net 950310 source: RIPE person: Anne Lord address: RIPE Network Coordination Centre (NCC) address: Kruislaan 409 address: NL-1098 SJ Amsterdam address: Netherlands phone: +31 20 592 5065 fax-no: +31 20 592 5090 e-mail: anne@ripe.net changed: anne@ripe.net 941207 source: RIPE This works only if the name of the person is unique, as the name of the person is used as search key to locate the person-object. With the growth of the Internet, this gives problems as it becomes more and more likely that person names are no longer unique. May 19, 1995 - 2 - To overcome this problem, handles are introduced as unique search key to locate person-objects: inetnum: 193.0.1.0 netname: RIPE-EXP descr: Sample database-assignment, RIPE NCC descr: Amsterdam, Netherlands country: NL admin-c: AL12-RIPE <------ tech-c: MK16-RIPE <------ changed: GeertJan.deGroot@ripe.net 950310 source: RIPE person: Anne Lord address: RIPE Network Coordination Centre (NCC) address: Kruislaan 409 address: NL-1098 SJ Amsterdam address: Netherlands phone: +31 20 592 5065 fax-no: +31 20 592 5090 e-mail: anne@ripe.net nic-hdl: AL12-RIPE notify: anne@ripe.net changed: ripe-dbm@ripe.net 920826 changed: anne@ripe.net 941207 source: RIPE A RIPE-handle consists of 3 parts: - prefix the prefix is built from the first letters of each word of a person's name, e.g. John Doe would yield JD as prefix. - index the index is used to make the handle unique. It consists of a decimal number that is incremented to obtain a letter/digit combination that is unique. If JD1 is already assigned, then the next available handle would be JD2, JD3, et cetera. - suffix the suffix is used to avoid clashes between the regional registries, without the need to check if a handle is already assigned on a global scale. The suffix has the fixed value '-RIPE' for new handles that are generated by the RIPE community. (handles generated by APNIC have a two-letter country code suffix (e.g. '-JP'), and the Internic does not use a suffix for historical reasons). For example, John Doe could yield JD1-RIPE. If this handle is already assigned, then JD2-RIPE is a candidate, or JD3-RIPE, until a free slot is found. Note that the actual value of the handle is not important as long as it is unique. May 19, 1995 - 3 - It is perfectly legal to use a handle already assigned by another regional registry if this handle is already assigned to the same person. To find the next free slot, extra functionality has been added to the RIPE finger server: $ finger handle.jd@whois.ripe.net [dbase.ripe.net] First free handle: JD14-RIPE This locates the next free slot, but does not do any reservation: the handle can be assigned by another party between the finger and the actual database update. The database rejects an update if the update would assign the same handle to two different names. If the database-update uses the same person name, then the second update overwrites the first. This problem is to be addressed in future changes in the database-software. Note also, that a person-object with a handle is a different object than a person-object without handle. As a result of this, if one would assign a handle to John Doe later (after the person is already entered in the database), one should also delete the old person-object without handle. For a person's name, words like 'van', 'von', 'de' are excluded from the prefix if these words are common (Piet de Boer would yield PB, because his name is sorted under B, not D). May 19, 1995 - 4 - The status-attribute of the inet-num object The old classfull RIPE-database did not allow for overlapping inet-num objects, thus the following was not possible: inetnum: 193.0.0.0 - 193.0.31.0 descr: Inter-net service provider descr: Delegated address space ... inetnum: 193.0.0.0 descr: Wizbang company descr: (customer of Inter-net network services) ... With the deployment of the classless database however, this construction is possible and even desired to document delegations of address space to local registries. However, it also creates an ambigiuity as the record inetnum: 193.0.0.0 - 193.0.31.0 descr: Inter-net service provider descr: Delegated address space ... does not document that the address space is delegated, in contrast to assigned, in a machine-readable way. This makes utilisation measurement, as done by the RIPE NCC to evaluate requests for additional delegated address space, difficult to do by software. For this reason, a 'status' attribute has been added to the inetnum-object. The status attribute has 2 possible values: - Delegated (shown as 'D') indicates that the address space listed is delegated to a registry for assignment to its customers. The InterNIC uses 'allocated' instead of delegated. - Assigned (shown as 'A') indicates that the address space listed is assigned to the end user. This is the default if the status attribute is missing. Currently, the RIPE database suppresses 'status: A' to minimize compatibility problems with software that does not know how to handle this. May 19, 1995