Dear Cengiz, you wrote:

Date: Mon, 13 Jan 1997 10:14:20 -0800 Message-Id: <199701131814.AA22919@cat.isi.edu> From: Cengiz Alaettinoglu <cengiz@ISI.EDU> To: noc@noc.dfn.de Cc: woeber@cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet), Carol.Orange@ripe.net, db-wg@ripe.net Subject: Re: Immediate - Date in Changed field

[...]

...

...

Hi DB-folks!

On a slightly different aspect, and assuming that we change things anyway...

How about running the RIPE-DB (and maybe gradually all the others :-) on a UTC basis, according to some recent suggestions?

I think both the 4 digit year presentation and the UTC basis (I estimate this includes hh:mm:ss as well) are a very valuable extension for time stamps in the RIPE-db. This might as well ease some of the troubles in updates within the "near real time" mirrors.

I definitely agree for the need for this. But the changed attribute is inserted by the person who registers the object, not by the database software, he has the full control over which timezone he uses and to lie.

May be what we really want is a timestamp field with the granularity you suggest and in UTC zone, but inserted to the objects automatically by the database software. I see a lot of value in this.

I completely agree with you. This can only be done if the database software sets the time stamp. I guess this also solves most of the race conditions otherwise implied. Regards Joachim [...]

_____________________________________________________________________________ DFN Network Operation Center, Dr. Joachim Schmitz, (finger help@noc.dfn.de) >>>>>> mailto: noc@noc.dfn.de <<<<<< Rechenzentrum Universitaet Stuttgart, Allmandring 30, D-70550 Stuttgart Phone: 0711-685-5810, 0711-685-5576, FAX +711 6788363 (business hours) EMERGENCY phone +711 1319 139 with answering machine and pager _____________________________________________________________________________

Cengiz,

Cengiz Alaettinoglu writes :

I definitely agree for the need for this. But the changed attribute is inserted by the person who registers the object, not by the database software, he has the full control over which timezone he uses and to lie.

May be what we really want is a timestamp field with the granularity you suggest and in UTC zone, but inserted to the objects automatically by the database software. I see a lot of value in this.

I agree with this. I don't think it matters that much if the 'changed' field reflects a UTC time or not. You can as well argue that it is very confusing for the people in the Asean Pacific region when updating the APNIC database and an object gets rejected because a changed line is in the future ... Of course, the year 2000 fix is useful (since I had to do this for RPSL anyway and the NCC seems willing to do it now ;-)) A real serial number is much more useful. I recall that we already discussed a proposal. We never had time to implement this since it was not the highest priority but it was on the todo list. I include the proposal here again for your information, David K. --- Dear all, When I published the release notes of the RIPE database v1.1 beta version I also made some small notes regarding the format of the serial numbers that are needed for the (nearly) real-time mirroring of the RIPE database. Though, I know that you all like debating I didn't get any reactions :-(. Therefore I would like to stir up the discussion somewhat by highlighting the point (again) and formulate a (not the) proposal. If I understand our action list correct, the proposal will also make the historic action point on Marten Terpstra (19.12) about the 'stored:/processed:' attribute obsolete. What is (nearly) real-time mirroring support: The RIPE database software now labels all incoming (atomic) updates with an ever increasing serial number and stores the updates. It is now possible to retrieve all the changes to the database every ten minutes by use of a program that has been added to the RIPE database distribution. Before using the program it is required that you ask the people that maintain the database server near you (at RIPE: <ripe-dbm@ripe.net>), to be put in an accessslist. We haven't had any major problems with the beta version software (so far) except for some small bugs and support files that needed some more explanation. We are now using the software for a mirror server at RIPE and plan to change the roles of mirror and backup somewhere at the end of January. Also, some registries (GARR-NIS, SWITCH, ANS) have already such a mirror server running. Problem description: The current real-time mirroring system stores all updates together with an ever increasing serial number in separate files. Although it works, it doesn't allow for growth (computers tend not to be able to handle ever increasing integer values). Also other features like building a history of an object are not possible and system failures are difficult to handle. From the start of the real-time mirror project we intended to first get the thing working and to make a design that would make adding these features possible. Since it appears to work now, I want to publish a proposal. There are two important things that needs to be addressed: - We need a reliable and unique serial number. - We want to be able to roll back *and* forth to a random date/serial by using the collection of all updates Proposal: We add a 'stored:' attribute to every object in the database that will contain the following information: stored: (NEW|UPD) DATE TIME serialnumber NEW|UPD - are we dealing with a new object or is it already updated once ? DATE - YYYYMMDD date of storing including the leading 19 or 20 TIME - time in HH:MM.SS, UTC time zone SERIAL - serial number to avoid updates with same time & date This should be an (nearly) ever increasing number. It could start from 0 for every date & time combination, but then we still need another ever increasing number for finding out if we missed updates or not. Of course every detail is open to discussion, I just wrote down one of the possibilities. In addition to the stored attribute we need a 'replaced:' attribute that will point to the object that it replaced and will thus nearly have the same syntax: replaced: SOURCE DATE TIME SERIAL We add the SOURCE here, for the time when we start integrating the different registry databases. Furthermore, we need to decide if we want to have both attributes to be visible when doing a whois query, one of them visible or all hidden except when using a special option. As always, please advise! David K.