Object Metadata Proposal

Dear Janos,

Janos Zsako wrote:

> I just have a further suggestion and a question (I apologize if this has
> already been discussed).
> 
> 
>>  Metadata Contents
>>  ------------------
>>
> 
>>  Other meta-attributes may be added as needed.
>>
> 
> My suggestion would be to add a meta-attribute "creation-time:" which
> would store the date and time the object was created (as opposed to
> "update-time:", which only shows when it was last updated).
> This attribute would never change.
>

> The rationale behind having this attribute is that one would have a
> proof of the existence of the object in the database from (at least)
> creation-date (until at least query time).
> 
> This may help for example auditing LIR assignments to the same end-user
> (which is limited to one AW worth in any 12 months).
> 
>


This may provide some useful indicators for auditing, but cannot be 
considered as data that auditing (or other similar procedures) depends 
on. After implementing this proposal 99.9% of the database objects will 
have no creation-time, nor update-time. Which shouldn't result in 
treating them differently from objects that have such metadata set.

But I agree that having such meta-attribute improves situation in the 
long run.

> 
> My question would be about the generation of the initial values (of
> update-time and ref-time) for the _existing_ objects.
> 
> One aproach would be to use the "changed:" value for "update-time",
> and for "ref-time" the most recent "changed" value of the objects
> referencing the given object. The only problem is that we know
> "changed" is not (very) reliable.
> 
> An other approach would be to use the time of the (initial) creation
> of the meta-attributes as initial value both for "update-time" and
> "ref-time". This is probably misleading. A better approach would
> probably be to leave these values empty, but this would not meet the
> current spec.
>


Current spec is a very early draft, and it allows empty value for 
example for "expire-time:". Or we may display "never", "n/a", etc. in 
such case.

 
> The most exact approach would be to retrieve the exact values from the
> update logs, but this is probably too expensive.
> 


Agree.


> My question is which approach do you plan to take (one of the above or
> one I did not think about)?
> 
> 
> Thanks and regards,
> Janos
> 

Thanks,

-- 
Andrei Robachevsky
RIPE NCC