This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
Events of Tuesday, 27 October 1998.
- Previous message (by thread): Events of Tuesday, 27 October 1998.
- Next message (by thread): Big delays with <auto-dbm>.
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Daniel Karrenberg
Daniel.Karrenberg at ripe.net
Sat Oct 31 01:07:32 CET 1998
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 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.
- Previous message (by thread): Events of Tuesday, 27 October 1998.
- Next message (by thread): Big delays with <auto-dbm>.
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ db-wg Archives ]