RIPE Handles And The 'status' Attribute In The RIPE-database
RIPE-126
- Publication date:
- 18 May 1995
- State:
- Obsoleted
- Author
.
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