Orphan/Expire

On Fri, 16 Apr 1999, Ulf Kieber wrote:

kieber> I'd propose a machine generated ``orphan'' timestamp on each person
kieber> object.  This would allow to kick out all orphaned objects after a
kieber> certain grace period (maybe 6 month), which probably will get rid of
kieber> quite a number of person objects no longer needed.

kieber> I can think of several ways to implement an ``orphan'' timestamp--it
kieber> doesn't nessecarily need to be a real _timestamp_, it might be a count
kieber> down timer of some sort, which would even allow reducing its size.

The following is a generic solution, and could be applied by the database
when an object is found to be 'orphaned'.

-- 
  Bruce Campbell <bruce.campbell at apnic.net>                +61-7-3367-0490
                 Systems Administrator (#2)     Regional Internet Registry
    Asia Pacific Network Information Centre    For the Asia Pacific Region

Proposal:

The addition of an 'expire:' field which sets out a time when the database
will send a reminder notice to the listed contacts/notify requesting
continuing confirmation of the object's existence, and indirectly checking
the validity of the contacts supplied. 

I see the primary use of this as being for objects (inetnums/as/domains) 
describing assignments by LIRs to their customers, setting a time when a
contract between the two expires (or two weeks after, the exact
usage/timing of the field would be left up to the member).

Specifics:

	expire: action date [frequency]    (optional, multiple)

Multiple occurences of this field may be present.

--

'Action' is one of:

 'notify': Send a message to the address in the notify field, and also to
           the admin-c address(es) advising of the existence of the
           object and a copy thereof.  Primary use of this would be to 
           advise of the objects existence with a view to making sure that
           the details are still correct, and only makes sense if the
           optional frequency subfield is also set. 

 'delete': Send a message to the address in the notify field, and also to
           the admin-c address(es) advising of the impending deletion of
           the object (in 14 days, this being a global database setting in
	   ripedb.conf) unless further information is forthcoming, and a
           copy of the object. Primary use of this would be to ensure the
           validity of database information in the event of a short-term,
           but possibly ongoing assignment.

	   For security reasons, if the object is protected by a
	   maintainer, the 'do not delete this object' response should be
	   authorised as set out by the maintainer.  The same applies to
	   sending messages out if (for example) pgp encrpytion of
	   messages is enabled.

--

'Date' is an standard date string in the same format of the 'changed:'
 attribute which outlines the base date from which the above
 recurring times are calculated, or the date on which once-only action
 occurs. This would be reset by the database if required.

 (Note: maybe add another 'changed' attribute implying when the expire
  attribute was first set on that object, providing a bit of history on
  when the object (or the contract it possibly represents) was created?)

--

'Frequency' is an optional field containing either the string 'once'
 (meaning that the action happens once only, this is the default if
 'frequency' is not specified) or a recurring time interval (signified by
 '+'), expressed in days, months or years, eg:

	 '+30d': The action occurs every 30 days.
	 '+1m': The action occurs every month (on the same date).
	 '+1y': The action occurs every year (on the same date).

 More complicated expressions could be added (eg, 3rdMonday for the 3rd
 Monday of each month), although this might be seen as making this
 functionality of the database a large calender routine.

--

A 'grace' period of warning before an object is deleted can be enacted by
using multiple 'expire:' fields, one being an 'expire: notify' with a
date one month before the following 'expire: delete' field.  It would be
expected that the database would (in the notify message), outline any
other expire events, such as a recurring notify, or an immenient delete
action.

--