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(a)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.
