To summarise and conclude from the discussion: All comments -also the ones sent to me privately- were unanimous on this: There will be no automatic updates of the RIPE DB. If database information is believed to be inconsistent the rechnical contact persons will be notified together with suggested corrections. They can then decide whether to send in the suggested corrections. What remains open is the question on whether in-addr.arpa zone registrations should be effected automatically by registering the 'rev-srv' field in the RIPE database. I have had quite a few comments from people who want this and I personally agree it would be a nice feature. Some people actually assumed this was the way it was working already and complained that they had to register in-addr.arpa separately with the NIC! I do not see Piet's argument that this would mean a loss of authority of the network contacts. They have the same authority for changing the RIPE database than they have for changing the NIC database which then generates the in-addr.arpa zone information. Just the procedure would be different, and easier: One stop shopping with no additional cost (and no warranty of agency :-), sorry inside joke). So my proposal would be to do this in steps: First clean up the inconsistencies in the RIPE database using the procedure above. Then populate the database with the current in-addr.arpa information, notifying the tech contacts of each change. After these two steps the information in in-addr.arpa and both the NIC and RIPE databases is consistent. Then initiate changes of in-addr.arpa whenever the 'rev-srv' attribute in the RIPE DB is changed. This means the one stop shopping is effective. Until confidence is built we can notify the tech contacts whenever such a change is made. Is this acceptable? Daniel