Re: Events of Tuesday, 27 October 1998.

[Daniel Karrenberg <]

Harvard ,

thank you for your support. It is indeed not straightforward
to roll back specific changes in a database that
receives thousands of upates each day which are not independent
of each other. One thing we have leared from this is that 
it may be a good idea not to re-use handles before some
time period has expired in order to facilitate tis process.
However there are other interdependencies as well and it will be
impossible to design a system to roll back any amount of changes 
consistently and repecting constraints such as authorisation.

I further would like to point out to everyone that we do provide
authorisation and authentication methods *for more than five years*
already. Those who used them properly weree not affected by this
mistake at all! If you want to be safe, all you have to do is to
use authorisation on your objects. See ripe-120 on how to do that.

mLaswly, and maybe unnecessarily, I'd like to  stress that we indeed 
have backup procedures in place which are designed to  cope with 
failures under our responsibility, such as machine or storage media 
problems.

If you have any further questions, please do not hesitate to contact us. 

Kind regards

Daniel Karrenberg 
RIPE NCC Manager

  > Havard.Eidnes@localhost writes:
  > 
  > It is important to understand that the data in the RIPE database is
  > maintained by the users of the database, and not by the RIPE NCC
  > itself.
  > 
  > I suspect that the problem is that a backup cannot easily be used to
  > restore the current "desired" state (minus the unfortunate update).
  > The reason is that old NIC handles may have been recycled, i.e.
  > reassigned to another object, and that object can subsequently have
  > been referenced by an explicit use of that recycled NIC handle in an
  > update.  Sure, the subsequent updates could perhaps be doctored to
  > remedy this, but that is perhaps not easily or quickly done, and would
  > also mean "intervention in the data maintenance" by the RIPE NCC.
  > 
  > I would thus tend to turn the argument above on its head and say that
  > we collectively, the maintainers of the data in the RIPE database,
  > have made inadequate use of the already available methods for
  > protecting the data we maintain there from unauthorized updates or
  > removals.