[nfsv4] Issue53 - Add data retention support
Mike Eisler <email2mre-ietf@yahoo.com> Mon, 10 July 2006 18:57 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G00wf-0001C1-RF; Mon, 10 Jul 2006 14:57:25 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G00we-0001Bw-Vu for nfsv4@ietf.org; Mon, 10 Jul 2006 14:57:24 -0400
Received: from web31805.mail.mud.yahoo.com ([68.142.207.68]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G00wc-0000YU-Kh for nfsv4@ietf.org; Mon, 10 Jul 2006 14:57:24 -0400
Received: (qmail 65495 invoked by uid 60001); 10 Jul 2006 18:57:21 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=MHKUX6Llp5MEduPa7vUQ1t+qG9GUVPph3qBvQCNYQnkPn2ADeOiMEoaCOMPRmYgqvfLbfy4I5G3zdtpQPQFPupBaT1L3z64WMXFzH/boTy3FdA6sgctvXCMkTpkpwoDVlu+qYYo9rG5/nEDeszMhyc5dC7Pn2QuHTgF7x2te0X0= ;
Message-ID: <20060710185721.65493.qmail@web31805.mail.mud.yahoo.com>
Received: from [198.95.226.224] by web31805.mail.mud.yahoo.com via HTTP; Mon, 10 Jul 2006 11:57:21 PDT
Date: Mon, 10 Jul 2006 11:57:21 -0700
From: Mike Eisler <email2mre-ietf@yahoo.com>
To: nfsv4@ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15
Subject: [nfsv4] Issue53 - Add data retention support
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: email2mre-ietf@yahoo.com
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/nfsv4>
List-Post: <mailto:nfsv4@ietf.org>
List-Help: <mailto:nfsv4-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=subscribe>
Errors-To: nfsv4-bounces@ietf.org
Here is an outline of a proposal, which is based on conversations with Alan Yoder and Jay Moorthi of Network Appliance, who work on NetApp's data retention feature. Errors are mine. I'm sure Alan will correct me. My understanding is that Data Retention is a concept that has been driven by legislation and regulations passed by many countries in recent years. The rationale is political and other jurisdictions have decided that some data (e.g. health records) must be retained for a sufficient period of time in order for the stake holders associated with data to not be harmed due to deletion (unintended or otherwise) of the data. I'm told it would be difficult to impossible to normalize all these regulations and support a full range of retention attributes. That seems more like the place for applications using higher level APIs than what NFSv4 is intended to support, such as the work that SNIA is doing ( http://www.snia-dmf.org/xam/faq.shtml ). That said, the "low hanging fruit" consists of two attributes: - 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: - the file MAY be deleted. However, individual named attributes MUST NOT be deleted. - the contents of the file, its named attributes, and some other attributes MUST NOT change as long as the file exists. Normally only the owner of a file can set Retained or Retention Time, though the use of ACLs may extend modification rights for these attributes to other principals. Just having attribute modification rights to the file object does not guarantee the right to set Retained or update Retention Time. NFSv4.1 server implementations MAY support policies that allow the storage administrator to limit the capability of users can set retention attributes (including whether a user can set a retention attribute and the range of retention times). I look forward to discussion on this mailing list. I see I am on the agenda (http://www3.ietf.org/proceedings/06jul/agenda/nfsv4.txt ) to discuss this tommorrow, so I look forward to the discussion in Montreal too. -mre _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4
- [nfsv4] Issue53 - Add data retention support Mike Eisler
- Re: [nfsv4] Issue53 - Add data retention support Brent Callaghan
- Re: [nfsv4] Issue53 - Add data retention support Mike Eisler
- RE: [nfsv4] Issue53 - Add data retention support Yoder, Alan
- RE: [nfsv4] Issue53 - Add data retention support Noveck, Dave
- RE: [nfsv4] Issue53 - Add data retention support Mike Eisler
- Re: [nfsv4] Issue53 - Add data retention support Benny Halevy
- Re: [nfsv4] Issue53 - Add data retention support Benny Halevy
- RE: [nfsv4] Issue53 - Add data retention support Noveck, Dave
- RE: [nfsv4] Issue53 - Add data retention support Everhart, Craig
- RE: [nfsv4] Issue53 - Add data retention support Mike Eisler
- Re: [nfsv4] Issue53 - Add data retention support Spencer Shepler
- Re: [nfsv4] Issue53 - Add data retention support Mike Eisler
- Re: [nfsv4] Issue53 - Add data retention support Spencer Shepler
- RE: [nfsv4] Issue53 - Add data retention support Yoder, Alan
- RE: [nfsv4] Issue53 - Add data retention support Mike Eisler
- Re: [nfsv4] Issue53 - Add data retention support Spencer Shepler
- RE: [nfsv4] Issue53 - Add data retention support Noveck, Dave