RIPE Database Template for Networks and Persons Anne Lord Marten Terpstra Document ID: ripe-119 Obsoletes: ripe-050 & ripe-051 ABSTRACT This paper describes the format and syntax for the representation for Internet network numbers and associated contact persons in the RIPE database. 1. Introduction The features described in this document will be usable in the RIPE database at a time specified in [3]. Please refer to this document for more details. RIPE (Reseaux IP Europeens) coordinates TCP/IP networking for the research community in Europe. One of the activities of RIPE is to maintain a database of European IP networks, DNS domains and their contact persons along with various other kinds of network management infor- mation. This database content is public information for agreed Internet operational purposes. This supports NICs/NOCs all over Europe and beyond to perform their respective tasks. This document describes the format and syntax for Internet network number assignment information and the closely related contact person information. Each object in the database describes a single entity in the real world. This basic principle means that information about that entity should only be represented in the corresponding database object and not be repeated in other objects. Objects are described by attributes value pairs, one per line. Objects are separated by empty lines. An attribute that consists of multiple lines should have the attribute ripe-119.txt October, 1994 - 2 - name repeated on consecutive lines. The information stored about network 192.87.45.0 consists of three objects, one network object and two person objects and looks like this: inetnum: 192.87.45.0 netname: RIPE-NCC descr: RIPE Network Coordination Centre descr: Amsterdam, Netherlands country: NL admin-c: Daniel Karrenberg tech-c: Marten Terpstra rev-srv: ns.ripe.net rev-srv: ns.eu.net notify: ops@ripe.net changed: tony@ripe.net 940110 source: RIPE person: Daniel Karrenberg 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: dfk@ripe.net nic-hdl: DK58 changed: ripe-dbm@ripe.net 920826 source: RIPE person: Marten Terpstra address: RIPE Network Coordination Centre (NCC) address: PRIDE Project address: Kruislaan 409 address: NL-1098 SJ Amsterdam address: Netherlands phone: +31 20 592 5064 fax-no: +31 20 592 5090 e-mail: Marten.Terpstra@ripe.net nic-hdl: MT2 notify: marten@ripe.net changed: marten@ripe.net 931230 source: RIPE 1.1. How to access the Database ? The database is public information for agreed Internet operational purposes. It can be accessed via a whois server on host whois.ripe.net (tcp port 43). The whole database is also available via anonymous ftp from ftp.ripe.net as file ripe.db in directory ripe/dbase. There is also a compressed version of the database available in that same directory, as ripe-119.txt October, 1994 - 3 - well as a version of the database in which the different objects have been collected in different files. This "split" version of the database can be found in the subdirectory split. 1.2. How to submit information to the database ? Database updates should be sent via electronic mail to auto-dbm@ripe.net Below you find two templates, one for network objects and one for person objects. Be sure to supply a person object for each contact person mentioned in the network objects. Of course you need not supply person objects if they are already present in the database and the information is still correct. Updates sent in should only contain the objects that need to be updated. The mail is automatically parsed by software that cannot intercept any messages that may be in the mail. If an update needs human intervention, or you have general questions on the procedures, please refer to ripe- dbm@ripe.net. Currently no special authorisation is needed to create, modify or delete objects that describe persons or address space. However extensive audit trails of all changes are being kept. 2. Format and syntax of the network number object The network number object is often referred to as the inet- num object, because the line containing the network number information has the name inetnum. In a short summary below, the attribute column indicates the name of the attribute inside the object, the second column indicates whether this attribute is optional or mandatory, and the third column indicates whether this attribute can appear more than once per object: attribute optional/mandatory multiple/single inetnum: mandatory single netname: mandatory single descr: mandatory multiple country: mandatory single admin-c: mandatory multiple tech-c: mandatory multiple rev-srv: optional multiple remarks: optional multiple notify: optional multiple ripe-119.txt October, 1994 - 4 - mnt-by: optional mutliple changed: mandatory multiple source: mandatory single Below each of these attributes and their format and syntax are described in more detail, and examples are given. inetnum: The inetnum attribute contains the range of IP address space this object gives information on. The syntax of this attribute can be either of the fol- lowing: inetnum: 192.87.45.0 This indicates one class C network number, which covers IP address space 192.87.45.0 up to 192.87.45.255. The network number can be a class A, class B or class C network number. inetnum: 192.87.44.0 - 192.87.45.0 This indicates a block of (2) class C network numbers, which covers IP address space 192.87.44.0 up to 192.87.45.255. The spaces between the begin- ning address, the dash ("-") and the end address of this classful range must be present. The range can consist of any block of class A, class B or class C network numbers. inetnum: 192.87.45.0 > 192.87.45.255 This notation represents a classless range of IP address space, and does not make any assumptions on the class (A, B or C) of this specific piece of address space. See [1] for more details of the various classful versus classless IP address representations. Where this above example covers exactly the same address space as the first class- ful class C example, it is only in this syntax pos- sible to specify any other range of address space that is not aligned on the conventional class A, B or C boundaries. Again, the spaces between the start address, the greater-than sign (">") and the end address must be present. Please also note that in the dotted quad notation of IP addresses, all trailing zeros must be present. Status: mandatory, only one line allowed netname: The netname attribute specifies a name for this ripe-119.txt October, 1994 - 5 - range of IP address space. It should be a reason- ably descriptive name, consisting of capitals, dashes ("-") and digits, but must start with a cap- ital. The network name used to be a unique name identifying the address space. Nowadays it is mainly used to guard against errors by requiring both the address and the name for certain opera- tions. You will most likely never find this name anywhere else than in a database like the RIPE database. An example: netname: RIPE-NCC Status: mandatory, only one line allowed descr: The descr attribute consists of a short description of the organisation and location where this address space is used. The description can have multiple lines. It need not contain the full postal address as this is required in the contact person object (see further in this document). Free text is allowed. An example: descr: RIPE Network Coordination Centre descr: Amsterdam, Netherlands Status: mandatory, multiple lines allowed country: The country attribute gives the two letter ISO 3166 country code for the country where the organisation is located. An up-to-date version of ISO 3166 can be obtained using anonymous ftp from ftp.ripe.net:iso3166-codes. In cases where the address space is used across national boundaries, it should contain the most appropriate country, usually based on the address of the administrative contact person. The format is two letter uppercase country code. An example: country: NL Status: mandatory, only one line allowed admin-c: The admin-c attribute contains the name or the NIC handle of the administrative contact person. Whev- erever possible, this should be a person that works at the organisation the address space has been allocated to. A NIC handle (if known) is preferred. Please do not use formal titles like 'Dr', 'Prof' or 'Sir'. Do not add full stops between names or initials. This value should be exactly the same as the attribute in the person object (see further below). More than one administrative contact person can be specified, by simply repeating the ripe-119.txt October, 1994 - 6 - attribute.An example of both the NIC handle and normal name use: admin-c: Daniel Karrenberg or (preferred) admin-c: DK58 Status: mandatory, multiple lines allowed tech-c: The tech-c attribute contains the name or the NIC handle of the technical contact person. The format and syntax is the same as the admin-c attribute above. Status: mandatory, multiple lines allowed rev-srv: The rev-srv attribute contains the fully qualified domain name of the machine that runs a reverse domain name service for the address space. If there are multiple reverse name servers for this address space, they should all be specified on dif- ferent lines. Only one hostname is allowed per line. An example: rev-srv: ns.ripe.net rev-srv: ns.eu.net Status: optional, multiple lines allowed remarks: The remarks attribute contains any remarks about this address space that cannot be expressed in any of the other attributes. Although multiple lines are allowed, it should be only be used if it pro- vides extra information to users of the database, and usage should be kept to a minimum. For format is like the description attribute free text. An example: remarks: will be returned to NIC 950101 Status: optional, multiple lines allowed notify: The notify attribute contains an email address to which notifications of changes to this object should be send. This can be useful if more than one person manage the same object. A more detailed description can be found in [2]. The format is one RFC822 electronic mail address per line. Although multiple lines are allowed, usage should be kept to a minimum. An example: notify: operations@ripe.net Status: optional, multiple lines allowed ripe-119.txt October, 1994 - 7 - mnt-by: The maintainer attribute contains a registered maintainer name. This attribute is used for author- isation of database update requests. It is described in more detail in [2]. The format is a registered maintainer name. An example: mnt-by: RIPE-DBM Status: optional, multiple lines allowed changed: The changed field contains information on who last changed this object, and when this change was made. The format is an RFC 822 electronic mail address of the person who made the change, and the date of change in YYMMDD format. Multiple lines are allowed and shows the update history of an object. An exam- ple: changed: marten@ripe.net 940328 Status: mandatory, multiple lines allowed source: The source contains a source of information. For the RIPE database, the value should always be "RIPE". This field is used to combine and exchange information between various database sources around the world. Fixed value: source: RIPE Status: mandatory, only one line allowed, fixed value 3. Format and syntax of the person object The person object contains details for the technical and administrative contact persons specified in the inetnum object (and in other objects not described in this docu- ment). A short form overview of the person object is: attribute optional/mandatory multiple/single person: mandatory single address: mandatory multiple phone: mandatory multiple fax-no: optional multiple e-mail: optional multiple nic-hdl: optional single remarks: optional multiple notify: optional multiple mnt-by: optional mutliple changed: mandatory multiple source: mandatory single ripe-119.txt October, 1994 - 8 - Below each of these attributes and their format and syntax are described in more detail, and examples are given. person: The person attribute contains the full name as specified as a technical or administrative contact in another object. The name must be written identi- cally to those given in the tech-c and admin-c attribute of for example the inetnum object (but must NOT be the NIC handle). Again here, official titles like 'Dr', 'Prof' or 'Sir' should not be used. An example: person: Daniel Karrenberg Status: mandatory, only one line allowed address: The address attribute contains the full postal address of this person. It should be written down as you would for ordinary postal mail using one line for each part of the address. An example: address: RIPE Network Coordination Centre address: Kruislaan 409 address: NL-1098 SJ Amsterdam address: The Netherlands Status: mandatory, multiple lines allowed phone: The phone attribute contains the telephone number for this person. It has the following format: + . The can be split with spaces to denote exchange and subscriber number. Most countries should drop a leading zero when specifying their area code. Multiple phone numbers should be speci- fied in order of preference on different lines. An extension reachable only through an operator can be specified by adding "ext." and the phone extension to the phone number. An example: phone: +31 20 592 5065 phone: +31 20 592 5000 ext. 5089 Status: mandatory, multiple lines allowed fax-no: The fax-no attribute contains the telefax number for this person. It has the same format as the phone number explained above. An example: fax-no: +31 20 592 5090 e-mail: The e-mail attribute contains the electronic mail address for this person if applicable. This should ripe-119.txt October, 1994 - 9 - be a valid RFC 822 electronic mail address, prefer- ably in full domain syntax. An example: e-mail: Daniel.Karrenberg@ripe.net Status: optional, multiple lines allowed nic-hdl: The nic-hdl attribute contains the officially assigned NIC handle for this person, if applicable. NIC handles are unique identifiers assigned and used by the InterNIC to unambiguously refer to Internet people. An example: nic-hdl: DK58 Status: optional, only one line allowed The rest of the attributes in the person object have the same syntax and meaning as in the inetnum object, but are repeated for completeness. remarks: The remarks attribute contains any remarks about this address space that cannot be expressed in any of the other attributes. Although multiple lines are allowed, it should be only be used if it pro- vides extra information to users of the database, and usage should be kept to a minimum. For format is like the description attribute free text. An example: remarks: will be returned to NIC 950101 Status: optional, multiple lines allowed notify: The notify attribute contains an email address to which notifications of changes to this object should be send. This can be useful if more than one person manage the same object. A more detailed description can be found in [2]. The format is one RFC822 electronic mail address per line. Although multiple lines are allowed, usage should be kept to a minimum. An example: notify: operations@ripe.net Status: optional, multiple lines allowed mnt-by: The mnt-by attribute contains a registered main- tainer name. This attribute is used for authorisa- tion of database update requests. It is described in more detail in [2]. The format is a registered ripe-119.txt October, 1994 - 10 - maintainer name. An example: maintainer: RIPE-DBM Status: optional, multiple lines allowed changed: The changed field contains information on who last changed this object, and when this change was made. The format is an RFC 822 electronic mail address of the person who made the change, and the date of change in YYMMDD format. Multiple lines are allowed and shows the update history of an object. An exam- ple: changed: marten@ripe.net 940328 Status: mandatory, multiple lines allowed source: The source contains a source of information. For the RIPE database, the value should always be "RIPE". This field is used to combine and exchange information between various database sources around the world. Fixed value: source: RIPE Status: mandatory, only one line allowed, fixed value 4. References [1] Bates, T., Karrenberg, D., Terpstra, M., "Support for Classless Internet Addresses in the RIPE Database", ripe-121, October 1994. [2] Karrenberg, D., Terpstra, M., "Authorisation and Notif- ication of Changes in the RIPE Database", ripe-120, October 1994. [3] Bates, T., Karrenberg, D., Terpstra, M., "RIPE Database Transition Plan", ripe-123, October 1994. ripe-119.txt October, 1994