[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [cmis] Fwd: [cmis-comment] Question on the proposed CMIS Retention/Hold Extension
|
Hi Stephane, Thank You for sharing these thoughts. Perhaps I did not fully get your issues and concerns but in my opinion the managed retentions are suitable for the scenarios you describe below. The idea is to provide a high-level and abstract notion that a client or an application can provide the minimal information to declare a record. It is then fully up to the repository to decide what rules are derived from that and what restrictions will apply. The Retention proposal does not make an attempt to standardize all the behavior what a record means. Basically I see as main use case an application deriving from a business context (lets say: this is an invoice from provider A in country/region B belonging to order C. This context can be mapped to a classification XYZ123). This step can either be rule based or by a human person interactively. This classification is passed to a records managing repository and only the repository knows all the rules (including the retention periods behind XVY123). If the record policy is something like “keep 10 years after contract is terminated” it is up to the repository to track when “contract is terminated” occurs and adjust behavior then for the next 10 years. The standard only tries to define “for classifying a CMIS object as a record these are the fields to use”. What this classification means I agree that implementations vary and there are specific standards like for example MoReq2010 that define these in much more detail. Once a record is created the repository is responsible for guaranteeing the integrity of a record. There can be as many clients as you want. The notion of a record is maintained inside the repository and there is always only one record at one place. All the information belonging to a record are stored inside of the RM repository. In such a scenario a hold in my opinion would be set by a records manager and usually not by an application. The scenario of a full fledged distributed RM system introduces more complexity and was not scope of the proposal so far. I am not sure if we should make this part of a CMIS specification. From: cmis@lists.oasis-open.org [mailto:cmis@lists.oasis-open.org] On Behalf Of CROISIER Stéphane Thanks a lot for your explanation Martin, What I wanted to mention is that “Information Governance” and ILM policies is generally much more than just retention and disposition (e.g: relocate, remove from indexes, declassify secret information, redact and transfer to National Archives, etc.). And there is no easy way to delegate the management of these “information policies” to a third party client. We can of course discuss if the lifecycle of the client (basically a federated record management system) will be shorter or longer than the one of the repository itself. But this is more a chicken and egg problem and ideally speaking the content and associated policies should be abstracted from any system. However standardizing “information policies” (including retention and disposition) will be a tough and long term challenge. In a “federated RM” scenario where the client aims to unify information lifecycle to ensure that similar policies are applied across multiple repositories, how would you “delegate” these tasks to a 3rd party client? How can we make sure that the same content will not be governed by two or more Federated RM systems simultaneously with perhaps contradictory rules? Of course a given client can put an hold on an object and only release it after having applied its own rules, but nothing prevent another RM client to put another hold on this object. So the content will be immutable but the Repository does not know which Client is currently governing the content object. And I am not sure we should mix the notion of Hold with the one of information policies (and the problem of releasing Hold from a CMIS client which does not exist any more is the same). So perhaps we would need a way to delegate ILM policies to a given client without allowing multiple delegation (federated RM scenario). This client would then be able to apply retention and disposition both on collaborative content (= no immutability on the content – the user can still delete the content before the end of the retention period which is usually the case in mailbox scenario for instance) or on frozen content (= the client would be able to turn the content immutable so that it becomes a record). This client will then be able to properly propagate certain dates or actions in the Repository, when he knows them, without risking another client to bypass its rules or to apply “Holds” to bypass other information policies rules engine. Bit by bit CMIS could standardize more information policies. The Repository will be of course able to remove this delegation to a 3rd party governance client at any time if the client was suddenly decommissioned. Just to say that perhaps a notion of “Master Lifecycle Manager” (be it the Repository or a given Client) is perhaps currently missing to ensure that there is only one governing tool per content item at a given time. TBC. Best Regards, Stéphane From: Hermes, Martin [mailto:martin.hermes@sap.com] Hi Stephane, welcome to the TC from my side as well and thank you for your comments. The Client Managed Retentions allow you to apply a retention type without setting a concrete expiration date. In this case the document cannot be deleted until a concrete date is set. In your scenario the client would just apply a Client Managed Retention Type without a concrete expiration date. As soon as the corresponding event occurs, the client can set the expiration date. Nevertheless, setting a fixed Expiration Date is required for other scenarios which can’t be supported with just setting documents to immutable. The Client Managed Retentions are intended to be used in long term archiving or end-of-live system scenarios. In such scenarios the client must be able to set a concrete expiration date, as the client may not exist anymore at the time the expiration date is reached. Hence the client has to set the retention time in advance. In general the Repository Managed Retentions are more suitable for such “rule based” scenarios, assuming that the repository has means to create such rules. In this case the client would just apply the Repository Managed Retention Type which corresponds to the rule and the repository would manage all the rest. Best regards, Martin From: cmis@lists.oasis-open.org [mailto:cmis@lists.oasis-open.org] On Behalf Of David Choy Hello Stephane, ---------- Forwarded message ---------- Hello, I was going through the new CMIS Retention and Hold Management and have a question about Client Managed Retention: As mentioned on the Repository Managed Retention part or on the JIRA CMIS-714, retention and disposition rules might rapidly become much more complex than just setting a fixed retention/disposition schedule. Rules can be event-based (e.g: “if an employee leaves the company, dispose of his records one year after this event else dispose after 10 yrs” or “keep forever until a certain event occurs”). Such federated RM mechanisms will then be difficult to implement only with the current cmis:rm:expirationDate and cmis:rm:startOfRetention. In the second case scenario the CMIS client will either try to assign a huge retention value to ensure proper long term retention (but will not be able to properly dispose of the content when the event occurs which might then cause some legal risk for the organization) or may see the object deleted because it did not properly set the cmis:rm:expirationDate and another client or the Repository itself will set such an expiration date afterwards. The CMIS client will then try to bypass these obstacles by assigning an Hold on all concerned object to enforce proper immutability. Wouldn’t it be more easy, at least in a first phase, to only implement a “cmis:rm:declareAsRecord” and a “cmis:rm:unDeclareAsRecord” interface (or a “cmis:rm:setImmutability” and a “cmis:rm:releaseImmutability” in order to freeze a given content item and let the client decides when this content item should be released independently of any retention and disposition rule? Best Regards, Stéphane Croisier __________________________________ Stéphane Croisier RSD SA Email: s.croisier@rsd.com Twitter: @scroisier |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]