Database - Database objects and attributes In AFRINIC Database  

1. Object representation

1.1 Object representation

1.2 Object types supported by AFRINIC DB

2. Object types description

2.1 as-block

2.2 as-set

2.3 aut-num

2.4 domain

2.5 inet6num

2.6 inetnum

2.7 key-cert

2.8 limerick

2.9 mntner

2.10 person

2.11 role
2.12 organisation

1.0 Database objects and attributes

The AFRINIC Network Management Database (often called the "AFRINIC Database") contains records of:

* allocations and assignments of IP address space (the IP address registry);
* contact information (details of people who are responsible for the operation of networks or routers, and those who are responsible for maintaining information in the AFRINIC Database).

1.1 Object representation

Records in the AFRINIC Database are known as "objects". The syntax of the database objects is defined by RPSL, which is described in [1]. An object belongs to one of the object types, or classes. These two terms are used interchangeably through the document. The following object types are stored in the AFRINIC Database:

1.2 Object types supported by AFRINIC DB

Table 1 Object types supported in the AFRINIC Database

A database object is defined as a list of attribute-value pairs in text. Each attribute-value pair is written on a separate line. The attribute name starts at column 0, followed by the character " : " and followed by the value of the attribute. The attribute that has the same name as the object's class should be specified first. An attribute's value can be split over multiple lines, by having a space, a tab or a plus ("+") character as the first character of the continuation lines. The character "+" for line continuation allows attribute values to contain blank lines. More spaces may optionally be used after the continuation character to increase readability. The order of attribute-value pairs is significant. An object's description may contain comments. A comment can be anywhere in an object's definition, it starts at the first "#" character on a line and ends at the first end-of-line character. A comment cannot start at column 0. White space characters can be used to improve readability. The object's representation ends when a blank line is encountered.

Attributes can be mandatory or optional: A mandatory attribute MUST be defined for all objects of the class; optional attributes can be skipped. Attributes can also be single or multiple-valued. Multiple-valued attributes may have several attribute-value records in an object, while a single valued attribute may appear only once. Each object is uniquely identified by a set of attributes, referred to as the class primary key.

The value of an attribute has a type, which defines the syntax of the attribute value. Please refer to Appendix A1 "Object attributes" for a detailed description of the attributes supported in the AFRINIC Database.

2 Object types

This section describes object types (classes) supported in the AFRINIC Database along with the object templates. The following definitions are used in the templates:

In an object template the first column represents an attribute, the second and third columns specify the type of the attribute and the fourth column tells whether the attribute is (part of) a database key for the object.

2.1 as-block

An as-block object is needed to delegate a range of AS numbers to a given repository. This object may be used for authorisation of the creation of aut-num objects within the range specified by the "as-block:" attribute. The template of as-block class is shown in Figure 2.1.

as-block: [mandatory] [single] [primary/lookup key]

descr: [optional] [multiple] [ ]

remarks: [optional] [multiple] [ ]

tech-c: [mandatory] [multiple] [inverse key]

admin-c: [mandatory] [multiple] [inverse key]

notify: [optional] [multiple] [inverse key]

mnt-lower: [optional] [multiple] [inverse key]

mnt-by: [mandatory] [multiple] [inverse key]

changed: [mandatory] [multiple] [ ]

source: [mandatory] [single] [ ]

Fig. 2.1 as-block template

2.2 as-set

An as-set object defines a set of aut-num objects. The attributes of the as-set class are shown in Figure 2.2. The "as-set:" attribute defines the name of the set. It is an RPSL name that starts with "as-". The "members:" attribute lists the members of the set. The "members:" attribute is a list of AS numbers, or other as-set names. The name of an as-set object can be hierarchical. A hierarchical as-set name is a sequence of as-set names and AS numbers separated by colons ":". At least one component of such a name must be an actual as-set name (i.e. start with "as-").

as-set: [mandatory] [single] [primary/lookup key]

descr: [mandatory] [multiple] [ ]

members: [optional] [multiple] [ ]

mbrs-by-ref: [optional] [multiple] [inverse key]

remarks: [optional] [multiple] [ ]

tech-c: [mandatory] [multiple] [inverse key]

admin-c: [mandatory] [multiple] [inverse key]

notify: [optional] [multiple] [inverse key]

mnt-by: [mandatory] [multiple] [inverse key]

changed: [mandatory] [multiple] [ ]

source: [mandatory] [single] [ ]

Fig..2.2 as-set template

2.3 aut-num

An object of the aut-num class is a database representation of an Autonomous System (AS), which is a group of IP networks operated by one or more network operators that has a single and clearly defined external routing policy.

Objects of this class are used to register as number and specify routing policies. The attributes of the aut-num class are shown in Figure 1.2.3. The value of the "aut-num:" attribute is the AS number of the AS described by this object. The "as-name:" attribute is a symbolic name (in RPSL name syntax) of the AS. As AFRINIC is not running a routing registry yet, the import, export and default attribute (routing policies) are removed in AFRINIC database and should be provided as remarks only.

aut-num: [mandatory] [single] [primary/lookup key]

as-name: [mandatory] [single] [ ]

descr: [mandatory] [multiple] [ ]

member-of: [optional] [multiple] [inverse key]

remarks: [optional] [multiple] [ ] --- put in your routing policy.

admin-c: [mandatory] [multiple] [inverse key]
tech-c: [mandatory] [multiple] [inverse key]

notify: [optional] [multiple] [inverse key]
mnt-lower: [optional] [multiple] [inverse key]

mnt-routes: [optional] [multiple] [inverse key]
mnt-by: [mandatory] [multiple] [inverse key]

changed: [mandatory] [multiple] [ ]
source: [mandatory] [single] [ ]

Fig. 2.3 aut-num template

2.4 domain

The domain object represents Top Level Domain (TLD) and other domain registrations. In AFRINIC's case it is ONLY used for Reverse Delegations. The domain name is written in fully qualified format, without a trailing ". The template of this class is shown in Figure 2.4.

domain: [mandatory] [single] [primary/lookup key]
descr: [mandatory] [multiple] [ ]

admin-c: [mandatory] [multiple] [inverse key]
tech-c: [mandatory] [multiple] [inverse key]
zone-c: [mandatory] [multiple] [inverse key]

nserver: [optional] [multiple] [inverse key]

sub-dom: [optional] [multiple] [inverse key]

dom-net: [optional] [multiple] [ ]

remarks: [optional] [multiple] [ ]

notify: [optional] [multiple] [inverse key]

mnt-by: [mandatory] [multiple] [inverse key]

mnt-lower: [optional] [multiple] [inverse key]

refer: [optional] [single] [ ]

changed: [mandatory] [multiple] [ ]

source: [mandatory] [single] [ ]

Fig. 2.4 domain template

2.5 inet6num

An inet6num object contains information on allocations and assignments of IPv6 address space. The template of this class is shown in Figure 2.5.

inet6num: [mandatory] [single] [primary/lookup key]
netname: [mandatory] [single] [lookup key]
descr: [mandatory] [multiple] [ ]
country: [mandatory] [multiple] [ ]
admin-c: [mandatory] [multiple] [inverse key]
tech-c: [mandatory] [multiple] [inverse key]

org: [optional] [multiple] [inverse key]
status: [mandatory] [single] [ ]
remarks: [optional] [multiple] [ ]
notify: [optional] [multiple] [inverse key]
mnt-by: [mandatory] [multiple] [inverse key]

mnt-lower: [optional] [multiple] [inverse key]
mnt-irt: [optional] [multiple] [inverse key]
changed: [mandatory] [multiple] [ ]
source: [mandatory] [single] [ ]

Fig. 2.5 inet6num template

2.6 inetnum

An inetnum object contains information on allocations and assignments of IPv4 address space. The template of this class is shown in Figure 2.6.

inetnum: [mandatory] [single] [primary/lookup key]
netname: [mandatory] [single] [lookup key]
descr: [mandatory] [multiple] [ ]
country: [mandatory] [multiple] [ ]
admin-c: [mandatory] [multiple] [inverse key]
tech-c: [mandatory] [multiple] [inverse key]

org: [optional] [multiple] [inverse key]
status: [mandatory] [single] [ ]
remarks: [optional] [multiple] [ ]
notify: [optional] [multiple] [inverse key]
mnt-by: [mandatory] [multiple] [inverse key]
mnt-lower: [optional] [multiple] [inverse key]
mnt-routes: [optional] [multiple] [inverse key]
mnt-irt: [optional] [multiple] [inverse key]
changed: [mandatory] [multiple] [ ]
source: [mandatory] [single] [ ]

Fig. 2.6 inetnum template

2.7 key-cert

A key-cert object is a database public key certificate that is stored on the server and may
be used with a mntner object for authentication when performing updates. Currently only
keys compliant with the proposed Open PGP Internet standard [RFC 2440] are supported.
The template of this class is shown in Figure 2.7.

key-cert: [mandatory] [single] [primary/lookup key]

method: [generated] [single] [ ]

owner: [generated] [single] [ ]

fingerpr: [generated] [single] [ ]

certif: [mandatory] [multiple] [ ]

remarks: [optional] [multiple] [ ]

notify: [optional] [multiple] [inverse key]

mnt-by: [mandatory] [multiple] [inverse key]

changed: [mandatory] [multiple] [ ]

source: [mandatory] [single] [ ]

Fig. 2.7 key-cert template

2.8 limerick

The limerick object represents a humorous poem that has five lines and the rhyme scheme
"aabba". The template of this class is shown in Figure 2.8.

limerick: [mandatory] [single] [primary/lookup key]

descr: [optional] [multiple] [ ]

text: [mandatory] [multiple] [ ]

admin-c: [mandatory] [multiple] [inverse key]

author: [mandatory] [multiple] [inverse key]

remarks: [optional] [multiple] [ ]

notify: [optional] [multiple] [inverse key]

mnt-by: [mandatory] [multiple] [inverse key]

changed: [mandatory] [multiple] [ ]

source: [mandatory] [single] [ ]

Fig. 2.8 limerick template

2.9 mntner

Objects in the AFRINIC Database may be protected using mntner (pronounced "maintainer")
objects. A mntner object specifies authentication information required to authorise creation,
deletion or modification of the objects protected by the mntner. mntner objects are not created
automatically, but are forwarded to the AFRINIC Database Administration for manual processing.
The template of this class is shown in Figure 2.9. ¹

mntner: [mandatory] [single] [primary/lookup key]

descr: [mandatory] [multiple] [ ]

admin-c: [mandatory] [multiple] [inverse key]

tech-c: [optional] [multiple] [inverse key]

upd-to: [mandatory] [multiple] [inverse key]

mnt-nfy: [optional] [multiple] [inverse key]

auth: [mandatory] [multiple] [ ]

remarks: [optional] [multiple] [ ]

notify: [optional] [multiple] [inverse key]

mnt-by: [mandatory] [multiple] [inverse key]

changed: [mandatory] [multiple] [ ]

source: [mandatory] [single] [ ]

Fig. 2.9 mntner template

2.10 person

A person object contains information about technical or administrative contact responsible
for the object where it is referenced. Once the object is created, the value of the "person:"
attribute cannot be changed. The template of this class is shown in Figure 2.10.

person: [mandatory] [single] [lookup key]

address: [mandatory] [multiple] [ ]

phone: [mandatory] [multiple] [ ]

fax-no: [optional] [multiple] [ ]

e-mail: [mandatory] [multiple] [lookup key]

nic-hdl: [mandatory] [single] [primary/lookup key]

remarks: [optional] [multiple] [ ]

notify: [optional] [multiple] [inverse key]

mnt-by: [optional] [multiple] [inverse key]

changed: [mandatory] [multiple] [ ]

source: [mandatory] [single] [ ]

Fig. 2.10 person template

2.11 role

The role class is similar to the person class. However, instead of describing a human being,
it describes a role performed by one or more human beings. Examples include help desks,
network monitoring centres, system administrators, etc. A role object is particularly useful
since often a person performing a role may change; however the role itself remains. The
"nic-hdl:" attributes of the person and role classes share the same name space. Once the
object is created, the value of the "role:" attribute cannot be changed. The template of this
class is shown in Figure 2.11.

role: [mandatory] [single] [lookup key]

address: [mandatory] [multiple] [ ]

phone: [optional] [multiple] [ ]

fax-no: [optional] [multiple] [ ]

e-mail: [mandatory] [multiple] [lookup key]

admin-c: [mandatory] [multiple] [inverse key]

tech-c: [mandatory] [multiple] [inverse key]

nic-hdl: [mandatory] [single] [primary/lookup key]

remarks: [optional] [multiple] [ ]

notify: [optional] [multiple] [inverse key]

mnt-by: [optional] [multiple] [inverse key]

changed: [mandatory] [multiple] [ ]

source: [mandatory] [single] [ ]

Fig. 2.11 role template

2.12 organisation

The organisation class provides information identifying an organisation such as a company, charity or university, that is a holder of a network resource whose data is stored in the whois database. The template of this
class is shown in Figure 2.12.

organisation: [mandatory] [single] [primary/look-up key]
org-name: [mandatory] [single] [lookup key]
org-type: [mandatory] [single] [ ]
descr: [optional] [multiple] [ ]
remarks: [optional] [multiple] [ ]
address: [mandatory] [multiple] [ ]
phone: [optional] [multiple] [ ]
fax-no: [optional] [multiple] [ ]

country: [mandatory] [multiple] [ ]
e-mail: [mandatory] [multiple] [lookup key]
org: [optional] [multiple] [inverse key]
admin-c: [mandatory] [multiple] [inverse key]
tech-c: [mandatory] [multiple] [inverse key]
ref-nfy: [optional] [multiple] [inverse key]
mnt-ref: [mandatory] [multiple] [inverse key]
notify: [optional] [multiple] [inverse key]
mnt-by: [mandatory] [multiple] [inverse key]
changed: [mandatory] [multiple] [ ]
source: [mandatory] [single] [ ]

Fig. 2.12 organisation template