Events of Tuesday, 27 October 1998.

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 at runit.sintef.no 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.
>