Immediate - Date in Changed field

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 at 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.