Events of Tuesday, 27 October 1998.
Siegfried Langenbach svl at nrw.net
Sun Nov 1 16:56:51 CET 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. >
[ lir-wg Archives ]