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