Subject: RE: [nfsv4] Issue53 - Add data retention support

From: "Yoder, Alan" <[email-masked]>
Date: Thu, 13 Jul 2006 10:40:44 -0700

Administrative hold makes sense to me.

I'm not as sure about "remove at".  What does
this accomplish that Mike's proposal doesn't?

Some way of expressing "keep until the patient
dies, then three more years", would also be 
useful.  This is event based retention (EBR).
Probably you'd need something like:

	* A bitmap for indicating that events have occurred
	* A mask for indicating which bits must be set
	* An EBR Time Interval to be applied when all required
	  bits in the bitmap are set.

	The Retention Time is not relevant so long as
	the masked-off bitmap is not all 1's.  When the
	last 0 in the masked-off bitmap is set, the server
	sets the Retention Time to the current time plus
	the EBR Time Interval.  [I think the restriction
	that the Retention Time can only be increased can
	still be kept.]

Thoughts?

I also wonder what the security parameters for these
attributes would be.  Shouldn't there be special bits
in the ACL for access to retention information?

Alan 

> -----Original Message-----
> From: Spencer Shepler [mailto:[email-masked]] 
> Sent: Wednesday, July 12, 2006 11:29 PM
> To: [email-masked]
> Subject: Re: [nfsv4] Issue53 - Add data retention support
> 
> On Mon, Mike Eisler wrote:
> 
> ...
> 
> > - Retained. This is a boolean attribute. By default it is FALSE.
> >   Once it is TRUE, a file, its named attributes, and some other
> >   attributes, including modification time, change, meta data time,
> >   MUST NOT change, ever. The Retained attribute once set to TRUE,
> >   MUST stay true.
> > 
> > - Retention Time. This is a time (date really) to which 
> >   a file object (and its named attributes) are guaranteed to 
> >   be retained. The value is provisional until Retained is set 
> >   to TRUE, and thus has no meaning for compliance with 
> >   retention regulations until Retained is TRUE. Once Retained 
> >   is set to TRUE, the Retention Time MAY be changed, but it 
> >   MUST not be set to a new value less than its current 
> value. Once the
> >   retention time is reached:
> ...
> 
> It seems logical that NFSv4.1 should attributes such as these given
> that we have products in the market today that doing this by 
> overloading
> existing attributes.
> 
> Is there any interest in adding attributes to this proposal to
> accomplish "administrative hold" and "remove at" features?
> 
> In the case of administrative hold, a retained file would be held
> regardless of the retention time until the hold is removed.
> In the case of remove at, the file is removed at the specified
> time given that it is greater than the retention time.
> 
> 
> Spencer
> 
> 
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nfsv4
> 

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: Mike Eisler <[email-masked]>
Date: Thu, 13 Jul 2006 10:57:19 -0700 (PDT)

> this accomplish that Mike's proposal doesn't?

As proposed RetentionTime means 
'retain until at least this time'

RemoveAt means 'delete when this time is reached'

So they are different. It sounds like Retention has a different
meaning to you, and given that you spend more time in the
Compliance world, we should probably rename Retention and Retain to
something clearer.

As currently proposed, RetentionTime would be mandatory, but
RemoveAt would be advisory.
 
> 	that the Retention Time can only be increased can

As I noted in my slides, we can get very complex. 
The danger of getting more complex is getting it wrong.
It seems to me that complex applications are needed
to update events, and that these applications could
track the compliance events for a file somewhere else.

> in the ACL for access to retention information?

My head is exploding. :-)

OK, I'm back to proposing just Retained and RetentionTime.

---

From: Spencer Shepler <[email-masked]>
Date: Thu, 13 Jul 2006 13:40:34 -0500

> this accomplish that Mike's proposal doesn't?

It deals with the case for records that must be
kept for no longer than the specified date.
Just as there may be a legal requirement to
keep the data until a date, there may be a requirement
to keep it no longer than.

As mentioned, "remove at" would be fine as advisory.

> in the ACL for access to retention information?

The hold attribute seems to be the one that need special
circumstances.  Specification of what principal has the
rights to set/clear the hold attribute would likely be
best left to the server side administrative interfaces
at this point.

Spencer