[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