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