Folks, here is my long promised writeup on the "notify" and "maintainer" attributes. I hope it is clear enough. It will be discussed at the next RIPE meeting. Hopefully no substantive changes will be necessary. Suggestions on how to improve clarity are always welcome of course. Daniel Authorisation and Notification of Changes in the RIPE Database Daniel Karrenberg RIPE NCC ABSTRACT Two new attributes for all objects in the RIPE database are proposed 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 authorisation method provides a convenient way for distributed maintenance of the database. The Notify Attribute Each RIPE database object will have an optional attribute called notify. The value of the notify attribute is one valid RFC822 e-mail address. There can be multiple notify attributes. 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. - 2 - The Maintainer Attribute Each RIPE database object will have an optional attribute called maintainer. 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 examined. 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 needs to 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 Application 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 can be achieved by creating two maintainer names: - 3 - INTERNIC and RIPE-NCC and tagging all European objects with RIPE-NCC and vice versa. The tags can be phased in slowly, avoiding a flag day with the associated massive consistency problems. Over time all objects in the RIPE database would 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 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.