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.