Dear people, You have all probably heard that new RIPE database software has been written at the NCC. We are convinced that this software should be used as soon as possible at the NCC, because the current update procedure has had several changes made already to keep it running with the current size of both the database and the amount of updates we receive. Therefore, we have planned to start using the new software at the NCC this Friday September 10th, at 10 AM. The new software has some consequences for whois users and people that send in updates. These consequences have been listed below. Please read the document below carefully. If you have any questions or major objections, please contact me, Daniel or Tony. Cheers, Marten PS All updates sent to the new mail alias before Friday 10 AM will either bounce, or update some test database. These updates will NOT be incorporated in the real RIPE database. ----- Introduction The software for the RIPE database has recently been completely rewritten, and the new implementation will have some effects on the behaviour of the database software as compared to the software currently in use at the NCC. This document describes the impact the new RIPE database software will have on usage of the database and on updates to it. USER IMPACT With the new database software, there will be some changes in the bahaviour of the database whois server. These include: New -s flag The indexed database will still contain information from various sources. As before normally only the RIPE information will be shown. The flag for requesting information from all sources remains the same (-a), and a new flag will be introduced to specify one or more specific source (-s source). The RIPE whois client available from the RIPE document store has been modified to accept this flag. Recursive Lookups Limited to Source of Reference The "-a" flag, or asking for information from multiple sources will show a slightly different behaviour. The old software used to perform recursive lookups on ALL the selected sources. This means that a contact person referenced by a NIC entry would be looked ap and listed from ALL other sources. The new software will ONLY perform recursive lookups in the source where the reference was found. Consequence is that one does not get a mix and match of referenced information from various sources. All references are ONLY looked up in the source where they are referenced. This was done to limit output volume and user confusion. Strict Enforcement of Object Definitions The current database file has objects in it that do not conform to the official object definitions. The new whois server will only output the legal fields for such an object. So, it may be that a network object contains a zone-c attribute in the database file, but the whois server will never show this attribute, because it is not in the network object definition. An overview of the defined attributes per object can be found at the end of this document. UPDATE IMPACT There are a number of changes that will affect people sending in updates for the RIPE database. Real Time Updates The new database software works with on-the-fly updates. This means that accepted and acknowledged database updates will be visible immediately in the whois server running at the NCC. These changes will not be visible immediately in the FTPable database file maintained via the RIPE Document Store. Once a day -or night rather- an automatic "cleanup" procedure will run which generates the FTPable file and adds all the guarded attributes as specified in the guardian files maintained at the NCC. This means that the database available for anonymous FTP does not necessarily have the same information as the running database. Guarded attributes will not be changed using the normal update procedure, they will be added once a day, and remain unchanged until the next cleanup time. New Update Procedure A new mailbox will be installed for direct access to the new database software without RIPE NCC staff intervention. This means fast response times, but since the updates are not looked at by the staff, updates containing errors will be bounced just as fast. The new mailbox will be <auto-dbm@ripe.net>. The old mailboxes will remain, and the NCC staff will look at mails directed to one of these mailboxes and forward updates to the new update procedure, after some very basic checking. The NCC will NOT correct all syntax errors in updates sent to one of these mailboxes, but it might correct some obvious errors. As before all updates and acknowledgements will be logged at the NCC. This means that errors and "strange" updates can be tracked quite easily. Stronger Syntax Checking The syntax checking in the new software has been improved and strengthened. As with the old software, database objects that cause errors will be bounced, and NOT be incorporated in the database. Warning messages are usually used to indicate corrections that have been made to the object sent in. Objects with warnings WILL be incorporated in the database, with the changes made as indicated in the warning messages. In general error and warning messages are descriptive and will give some indication where an error or warning was generated. The new syntax checking has the following rules: Database objects that miss mandatory attributes will generate an error, and will be bounced. An overview of the defined attributes per object can be found at the end of this document. Objects that have attributes that are not defined in the object, will generate an error and will be bounced. Objects that have syntax errors in the values of the various attributes will generate an error, and will be bounced. Objects that have a date in the changed field that is prior to the date in the current database entry will generate an error and will be bounced. Guarded attributes in updates will be ignored other than generating a warning if the values do not match the current value in the database. Currently only the boundary gateway and routing privilege in the network object are guarded attributes. The aut-sys attribute in the network object will be turned into a guarded attribute as soon as possible. Deletions have been made more easy to perform. To delete an object, it is sufficient to send in that object plus a delete: attribute that describes why this object has to be removed from the database. Objects that need to be deleted, will NOT be checked for syntax, but must exactly match the object currently in the database, otherwise an error will be generated, and the object will not be removed from the database. The order of the different attributes in the updates is NO LONGER relevant for the match. The order of different lines in the same attribute is. The new syntax rules have been determined from the original object definitions. It may well be that some syntax rules have been made too strict, or are simply wrong. Please do not hesitate to contact us in these cases. The syntax is not fixed forever. Attribute definition per object as used by the new database software. inetnum object Mandatory: inetnum netname descr country admin-c tech-c connect changed source Optional: aut-sys (will be guarded asap) gateway (obsolete) nsf-in nsf-out (obsolete ?) routpr-l (guarded) bdrygw-l (guarded) remarks rev-srv person object Mandatory: person address phone changed source Optional: e-mail fax-no nic-hdl remarks domain object Mandatory: domain descr admin-c tech-c zone-c changed source Optional: dom-net nserver sub-dom remarks aut-num object Mandatory: aut-num descr admin-c tech-c changed source Optional: guardian as-in as-out default remarks bdry-gw and rout-pr will be obsolete in the near future.