Re: [nfsv4] 5.12.2 Attribute 70: retention_set.

[Robert Gordon <Robert.Gordon at Sun.COM>]

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.

On Apr 8, 2008, at 10:25 PM, Mike Eisler wrote:
> 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

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