Dear Colleagues,
Please review the proposal below. This proposal is supposed to provide
means for reliable timestamping, and also support garbage collection
procedure (please see "Automatic DB cleanup proposal" following this one).
But of course the functionality can be expanded when needed.
Your comments are welcome as always,
Best regards,
Andrei Robachevsky
RIPE NCC
-------------------------------------------------------------
Object metadata proposal
========================
Motivation
----------
Several proposals already exist that require reliable status information
about an object in the database, such as last update time, number of
references, etc. These are requests for reliable timestamping and
automatic cleanup procedure.
In order to be reliable this information should be automatically
generated by the database software and be outside users' control.
Storing this information as part of the object data was generally
considered not a good idea since this requires modifications to the
object not solicited by the user, and breaks some basic principles of
the RIPE Database.
But in fact these attributes/facilities do not represent an object, but
rather status information about the object. Extending Ulf Kieber's
analogy with the Unix FS, they are part of the inode, not the data blocks.
Object metadata
---------------
Status information, or object metadata, will be automatically generated
by the database, but stored and accessed separately from the object
itself. This will not affect any object template, preserve users' data
and add flexibility to the RIPE Database.
Metadata Contents
------------------
Metadata contents will be presented as metadata attribute-value pairs,
or meta-attributes. The initial set of meta-attributes is required by
the above mentioned proposals and will include:
update-time: <YYYY-MM-DD> <HH:MM:SS>
This meta-attribute will store the time when the update (object creation
or subsequent updates) was processed by the database software (when
modification was made to the Database).
ref-count: <number>
The number of references to this object from other objects in the RIPE
Database. Zero means the object is not referenced.
ref-time: <YYYY-MM-DD> <HH:MM:SS>
Last time the "ref-count:" was updated. It is empty if ref-count has
never been updated.
expire-time: <YYYY-MM-DD> <HH:MM:SS>
This meta-attribute displays the time after which the object will be
automatically deleted from the database overriding authorisation checks.
Empty value of the meta-attribute means "not set". Please see "Automatic
DB cleanup" proposal for more information.
Other meta-attributes may be added as needed.
Metadata will not propagate through NRTM. It is up to a NRTM client to
generate the metadata as updates are processed.
Querying Metadata
------------------
Object metatdata may be accessed by using "-q meta" flag when
interrogating the database. This flag is can be used together with other
queries, except other "-q" flags. Metadata of all objects returned will
be displayed.
An object metadata will be displayed after the object with a blank like
between them. It is displayed as meta-attributes preceded by a '%' sign.
According to RIPE whois definition a line starting with '%' sign should
be generally considered as a comment and should be parsed at client's
own risk.
For example:
$ whois -q meta RC1234-RIPE
...
person: Referenced Contact
nic-hdl: RC1234-RIPE
...
changed: refcon(a)somedom.dom 20011005
source: RIPE
%metainfo: RC1234-RIPE
%update-time: 2001-10-05 16:50:07
%ref-time: 2001-10-06 09:17:33
%expire-time:
%ref-count: 3
Using Metadata
--------------
The metadata may be consulted by humans or metadata-aware clients for
different purposes.
The database software may use metadata for its garbage collection
routine, or other internal processes.