Re: [nfsv4] 5.12.2 Attribute 70: retention_set.

["Mike Eisler" <mre-ietf at eisler.com>]

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

has the proposed changes outlined below.

> 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: nfsv4-bounces at ietf.org [mailto:nfsv4-bounces at ietf.org]
>> 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
>> nfsv4 at ietf.org
>> https://www.ietf.org/mailman/listinfo/nfsv4
>>
>>
> _______________________________________________
> nfsv4 mailing list
> nfsv4 at ietf.org
> https://www.ietf.org/mailman/listinfo/nfsv4
>


_______________________________________________
nfsv4 mailing list
nfsv4 at ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4