How can we help you?

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

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

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]

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

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] [ ]

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

refer: [optional] [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] [ ]

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] [ ]

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

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] [ ]

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

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

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

auth: [mandatory] [multiple] [ ]

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]

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

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]

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

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

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