Re: Events of Tuesday, 27 October 1998.
- Date: Sun, 1 Nov 1998 16:56:51 +0100
- Organization: Computer Service Langenbach GmbH
On 31 Oct 98, at 1:07, Daniel Karrenberg wrote:
>
>
> 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.
why reuse it at all?
siegfried
> 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.
>
