Authorisation and Notification of Changes in the
RIPE Database
Daniel Karrenberg
RIPE NCC
Document ID: ripe-96
ABSTRACT
Two new attributes are defined for all
objects in the RIPE database in order to implement
a generalised method for authorising changes and
to notify interested parties of any changes made
to a specific object. In addition the authorisa-
tion method provides a convenient way for distri-
buted maintenance of the database.
The Notify Attribute
Each RIPE database object has an optional attribute called
notify. The value of the notify attribute is one valid
RFC822 e-mail address. There can be multiple notify attri-
butes. Whenever the object concerned is changed in the
database a notification message will be sent to each e-mail
addresses appearing in a notify attribute.
This makes it straightforward to keep track of changes to
specific objects and prevent changes from going unnoticed.
Multiple notify attributes make it possible to notify a
number of interested parties. This could be used to alert
all contact persons for an object or the local contact per-
sons as well as the relevant service provider. Although it
may be tempting to put many notify attributes on database
objects in order to notify everyone even remotely
interested, this is not recommended. A very few key
addresses should be sufficient. Prior to entering any mail
address here, the explicit or implicit consent of the person
responsible for that particular mailbox needs to be
obtained.
ripe-96.txt
- 2 -
The Maintainer Attribute
Each RIPE database has an optional attribute called main-
tainer. The value of the maintainer attribute is a
registered maintainer name. There can only be one main-
tainer attribute per object. Whenever a change to the
object concerned is attempted in a copy of the database the
maintainer attribute of the current database object is exam-
ined.
If there is no maintainer attribute or the maintainer name
is authorised to make changes in the copy of the database
the update proceeds causing the necessary notifications as
per the notify attribute.
If the maintainer name has no authorisation to change the
local copy of the database, the update request is forwarded
to the maintainer for processing. No notifications are per-
formed in this case.
The following data will be maintained locally about each
maintainer:
Maintainer name
Authority none
change whole database
change only own objects
Forwarding Info mail/RFC822-address
other/address
Authorisation none
mail/RFC-822-address
other/key
Example 1: Regional Registries
In order to align the InterNIC and RIPE databases it has
been agreed that European objects will be maintained in
Europe. The RIPE NCC will provide the data for these objects
to the InterNIC for inclusion in their database without
further processing. The RIPE NCC will refer all updates for
non-European objects to the InternNIC and the InterNIC will
refer all updates for European objects to the RIPE NCC for
processing.
This will be achieved by creating two maintainer names:
INTERNIC and RIPE-NCC and tagging all European objects with
RIPE-NCC and vice versa. The tags will be phased in slowly,
avoiding a flag day with the associated massive consistency
ripe-96.txt
- 3 -
problems. Over time all objects in the RIPE database will be
thus tagged.
Updates from third parties for objects with the maintainer
attribute added can now be referred correctly. Updates from
the other registry for objects it maintains can be accepted
without further checking.
Example 2: Local Registries
Some European local registries keep their own copies(1) of
the database containing the objects within their area. This
leads to consistency problems as updates can be sent both to
the RIPE NCC and to the local registry. Referrals are per-
formed by ad hoc methods. Frequently only one of the data-
bases is updated and alignment needs to be done manually.
By registering maintainer names for the local registries and
tagging the appropriate objects this can be automated and
made more reliable. The NCC would forward update requests
for locally maintained objects to the local registry unless
they come from that local registry itself.
Example 3: Guarded Objects
Some objects such as the autonomous-system object (see
ripe-81) need to be protected against changes by anyone but
a designated guardian since changes to these objects have a
direct operational impact.
By registering appropriate maintainer names for the guardi-
ans and tagging the objects to be protected this functional-
ity can be provided in a canonical way. Any change by third
parties to such an object will not only be prevented but
cause automatic notification of the guardian through the
forwarding mechanism.
_________________________
(1): In fact some European local registries maintain
their own database of registrations within their area.
Selected fields of this database are sent on an ad-hoc
or regular basis to RIPE to be included in the RIPE
whois database. The selected fields may be subject to
further processing before being sent to the RIPE data-
base.
ripe-96.txt