Routing tags update procedure

[Marten Terpstra <]

All,

please find below the NCC proposal for updating the routing tags as defined
in Jean-Michel's paper. We would really like to get this procedure in place
and working real fast now.

Please comment. With no comments we assume you agree and will implement the
procedure.

-Marten

---------------------

Introduction

This document describes a procedure for updating the routing attributes
to the RIPE database as defined in ripe-60.  These routing tags are
essential for routing of networks that are known in the RIPE database. 
Therefore updates of these attributes must be:

- properly authorized
- guarded against typing errors
- efficient for both maintainers of the attributes and the maintainers
  of the whole database

With the above in mind, the NCC proposes an update mechanism described
below. 


The procedure

For each of the routing privileges and boundary gateways tags, a list of
all networks having this attribute is kept seperately from the database
proper.  These lists will be the *only* source of routing information
used in the database.  Normal database updates do *never* change these
attributes.  If an update include such an attribute and a discrepancy
between the values in the update and those in the database is found, a
diagnostic will be send to the originator of the update.  The attributes
as defined in the files are incorporated in the database at each normal
update run.  To ensure authorisation, we propose to maintain the lists
on a the central NCC database server, where each of the guardians of a
tag keeps track of his or her own list.  The lists are maintained
through individual logins for each of the guardians.  The guardians can
themselves decide in what manner they want to update their list.  The
NCC will offer interactive logins, ftp logins or any other means that
might be found useful. 

File Format

We propose to keep the file format as simple as possible.  The name of
the file should indicate the name of the attributes.  This means that
there cannot be two attribute with the same name.  The format within the
file we propose as the "inetnum:" entry for each of the networks,
seperated by an empty line.  If a guardian feels that he would want more
fields to identify a network that will get his attribute, he is free to
do so.  An attribute will only be added to a network if all fields
defined in the list match a network in the database. 


Advantages

The update procedure as proposed above has the following advantages:

- Authorisation of adding/deleting is guarenteed
- No need for mailing back and forth of authorisation messages
- Simple procedure for both database maintainers and guardians
- Guardian keeps full control of his attribute
- Could be implemented at the NCC without too much delay


Pilot

When the file format has been decided on, we propose the current
participants in the pilot that make use of the attributes in the CERN
area to start a pilot implementing this update procedure.