Subject: Re: [nfsv4] 5.12.2 Attribute 70: retention_set.

From: [email-masked]
Date: Fri, 4 Apr 2008 19:06:21 -0400

Just in case you thought this had vanished into a crevasse
somewhere, Mike Eisler diligently pinged me to figure out
what to do about this.  The summary of the result of the
discussion between Mike and I is:

- the duration can be decreased as long as retention is not enabled

- the duration can always be set to an equal or higher value,
  even if enabled

- when retention is enabled, attempts to:
-- disable retention result in NFS4ERR_INVAL
-- decrease retention duration result in NFS4ERR_INVAL

- If the principal attempting to change a retention attribute
  does not have ACE4_WRITE_RETENTION or ACE4_WRITE_RETENTION_HOLD
  permissions (where the former applies to retention_set and
  retentevt_set, and the latter applies to retention_hold),
  it gets NFS4ERR_ACCESS.

The two uses of _INVAL match restrictions in the XAM API.
XAM also forbids retention duration decrease when retention
is not enabled.  XAM is a write-once (fixed content) interface,
whereas NFS is read/write (obviously), and as long as a file
is writable, it can't have been sent through the XAM API,
and hence it seems ok to not enforce restrictions on content
that hasn't become fixed content yet.

Also XAM does not have retention-attribute-specific access
controls like ACE4_WRITE_RETENTION - the corresponding XAM
element (called an authorization granule) is considerably
broader.  NFS can hence provide specific control over changes
to the retention attributes, protecting them in that fashion.

Thanks,
--David 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Robert Gordon
> Sent: Friday, March 07, 2008 6:57 PM
> To: NFSv4
> Subject: Re: [nfsv4] 5.12.2 Attribute 70: retention_set.
> 
> 
> On Mar 2, 2008, at 9:35 PM, Robert Gordon wrote:
> 
> >
> > I'm trying to understand the use of rs_enable and rs_duration.
> > As i read the text it seems possible for Client A to issue
> > 	{ rs_enable = FALSE, rs_duration = 120 }
> > and Client B to issue
> > 	 { rs_enable = TRUE, rs_duration = 60 }...
> 
> I'm not sure who authored the retention attributes; however, i'm not
> advocating the removal of rs_enable but rather i'd like some more
> explanation as to how a client may use it and what the expected
> behavior is for the above, and what the error code should be when say
> a client attempts to set a retention duration when a duration is
> all ready in effect (NFS4ERR_PERM ?? )
> 
> Robert.
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4
> 
> 
_______________________________________________
nfsv4 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/nfsv4

---

From: "Mike Eisler" <[email-masked]>
Date: Tue, 8 Apr 2008 20:25:13 -0700 (PDT)

http://eisler.com/nfsv4-wg/2008-04-08-retention.html

has the proposed changes outlined below.

---

From: Robert Gordon <[email-masked]>
Date: Wed, 09 Apr 2008 20:09:57 -0500

Thanks Mike and David; That makes things clearer.

Nit:

5.12.5

    If the principal attempting to change retention_hold or not have

to:

   If the principal attempting to change retention_hold does not have

Robert.