Internet DRAFT - draft-yoder-nfsv4-retention
draft-yoder-nfsv4-retention
NFSv4 A. Yoder
Internet-Draft Network Appliance
Intended status: Standards Track D. Black
Expires: February 26, 2007 EMC
August 25, 2006
NFSv4.1 Retention Attributes
draft-yoder-nfsv4-retention-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on February 26, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This Internet-Draft describes additional file attributes to be used
in NFSv4.1 for data retention semantics.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1].
Yoder & Black Expires February 26, 2007 [Page 1]
Internet-Draft NFSv4.1 Retention Attributes August 2006
Table of Contents
1. NFSv4.1 Data Retention Attributes . . . . . . . . . . . . . . . 3
1.1. int64 rtime . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. int64 stime . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. int64 ertime . . . . . . . . . . . . . . . . . . . . . . . 3
1.4. int64 etime . . . . . . . . . . . . . . . . . . . . . . . . 4
1.5. int8 retention_flags . . . . . . . . . . . . . . . . . . . 4
1.6. int8 admin_hold_flags . . . . . . . . . . . . . . . . . . . 5
1.7. int32 srvr_ret_capabilities_flags . . . . . . . . . . . . . 5
2. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Further Notes . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
5. Normative References . . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6
Intellectual Property and Copyright Statements . . . . . . . . . . 8
Yoder & Black Expires February 26, 2007 [Page 2]
Internet-Draft NFSv4.1 Retention Attributes August 2006
1. NFSv4.1 Data Retention Attributes
The FCAS TWG of SNIA met on 1 Aug 2006 and had an extensive
discussion regarding alignment of retention models between XAM and
NFSv4.1. While there are some areas in which the two standards are
unlikely to meet exactly, the consensus is that the following
attributes are sufficient to express the retention model under
consideration for XAM v1. Mike Eisler and Dave Noveck contributed
to the formulation presented here.
1.1. uint64_t rtime
The minimum retention duration for a file, in seconds.
Rtime is expressed as a duration, as it may be set before the
initial timestamp which delimits the beginning of the retention
interval is known.
Rtime MUST have a value of zero upon file creation. It is ignored
until RET4_SIMPLE_RETENTION_ENABLED is set. The rtime attribute
MAY be increased by a client-side SETATTR operation. The server
MUST NOT allow decrease of this quantity under any circumstances.
Permission to set and increase rtime is governed by a new NFSv4
bitmask ACE4_WRITE_RETENTION (0x00000200). Servers MAY map this to
ACE4_WRITE_ATTRIBUTES (0x00000100).
1.2. nfstime4 rbtime
The timestamp specifying the beginning of the retention period. If
rbtime is set, the server MUST NOT allow deletion of or change to a
file before the time given by rtime + stime.
When the client first sets the rbtime to any value, via SETATTR, the
server MUST set it to the current time as perceived by the server,
and atomically also set the RET4_SIMPLE_RETENTION_ENABLED flag.
Once set, the server MUST NOT permit change to the rbtime or the
RET4_SIMPLE_RETENTION_ENABLED flag.
Rbtime MUST have a value of zero upon file creation.
Permission to "set" rbtime is governed by ACE4_WRITE_RETENTION.
1.3. uint64_t etime
The minimum retention duration for a file, in seconds, following an
application-specified event. The etime MAY be increased by a client-
side SETATTR operation. The server MUST NOT allow decrease of this
quantity under any circumstances.
Etime MUST have an initial value of zero. It is ignored until
RET4_EVENT_RETENTION_ENABLED is set. Clients MAY set the flag
Yoder & Black Expires February 26, 2007 [Page 3]
Internet-Draft NFSv4.1 Retention Attributes August 2006
RET4_EVENT_RETENTION_ENABLED at any time.
Permission to set and increase etime is governed by
ACE4_WRITE_RETENTION.
Clients SHOULD set the etime before setting the
RET4_EVENT_RETENTION_ENABLED flag, to avoid windows of mutability.
1.4. nfstime4 ebtime
The timestamp specifying the beginning of the event-based retention
period. If ebtime is set, the server MUST NOT allow deletion of or
change to a file before the time given by ebtime + etime.
Setting the ebtime is the equivalent to an event notification
operation in XAM.
Ebtime MUST have a value of zero upon file creation. This indicates
that no application-specified event has yet taken place.
When the client first sets the ebtime to any value, via SETATTR, the
server MUST set it to the current time as perceived by the server,
and atomically also set the RET4_EVENT_RETENTION_ENABLED flag.
Once set, the server MUST NOT permit change to the ebtime or the
RET4_EVENT_RETENTION_ENABLED flag.
Permission to "set" ebtime is governed by ACE4_WRITE_RETENTION.
1.5. uint32_t retention_flags
Flags are as follows:
RET4_SIMPLE_RETENTION_ENABLED = 0x01
RET4_EVENT_RETENTION_ENABLED = 0x02
RET4_SIMPLE_RETENTION_INFINITE = 0x04
RET4_EVENT_RETENTION_INFINITE = 0x08
If RET4_SIMPLE_RETENTION_ENABLED is set, the server MUST do retention
based on the corresponding set of attributes (rtime and stime for
RET4_SIMPLE_RETENTION_ENABLED, etime and ertime for
RET4_EVENT_RETENTION_ENABLED).
The server MUST NOT turn off any of these flags, once set.
RET4_SIMPLE_RETENTION_INFINITE and RET4_EVENT_RETENTION_INFINITE
override all retention timestamps. The server MUST NOT allow deletion
or modification of the file as long as either of these bits are set.
Yoder & Black Expires February 26, 2007 [Page 4]
Internet-Draft NFSv4.1 Retention Attributes August 2006
The server MUST NOT allow unsetting of either of these bits.
Permission to set retention_flags is governed by
ACE4_WRITE_RETENTION.
1.6. uint32_t admin_hold_flags
These 32 flags are used to indicate administrative holds (e.g. holds
placed by judicial fiat). These override all other retention
expiration mechanisms. The server MUST NOT allow deletion or
modification of the file as long as any of the bits in
admin_hold_flags are set. Bits MAY be unset by clients with
sufficient permission.
Permission to set admin_hold_flags is governed by a new NFSv4 bitmask
ACE4_WRITE_HOLD (0x00000400). Servers SHOULD NOT map this to
ACE4_WRITE_ATTRIBUTES (0x00000100).
Admin_hold_flags MUST have a value of zero upon file creation.
1.7 uint32_t srvr_ret_capabilities_flags
RET4_SIMPLE_RETENTION = 0x01
RET4_EVENT_RETENTION = 0x02
RET4_SIMPLE_RETENTION_INFINITE = 0x04
RET4_EVENT_RETENTION_INFINITE = 0x08
RET4_ADMIN_HOLD = 0x10
Support for retention attributes is optional. If implemented, the
server MUST indicate support for simple retention, event-based
retention, infinite retention and administrative holds by setting
the respective bit in srvr_ret_capabilities_flags in a GETATTR
response. If the server does not support any retention attributes,
it MAY return NFS4ERR_ATTRNOTSUPP in response to a GETATTR of
srvr_ret_capabilities_flags.
The server MUST disallow any attempts to perform a SETATTR on
srvr_ret_capabilities_flags.
2. Discussion
Support for any or all retention attributes is optional. If
implemented, they MAY be implemented on a per-filesystem basis.
If they are, the server MAY implement a different set of attributes,
and return a corresponding srvr_ret_capabilities_flags instance,
for each filesystem.
Yoder & Black Expires February 26, 2007 [Page 5]
Internet-Draft NFSv4.1 Retention Attributes August 2006
On filesystems that do not support a given retention attribute,
NFS4ERR_ATTRNOTSUPP shall be returned in response to all GETATTR
and SETATTR calls for that attribute.
There are numerous interdependencies between flags which introduce
requirements on which combinations of them must be supported if
any are:
If the server supports rtime, then it MUST support rbtime
and vice versa.
If the server supports etime, then it MUST support ebtime
and vice versa.
If the server supports rtime, rbtime, etime, or ebtime,
it MUST support retention_flags.
If the server supports any retention flags, it MUST also support
srvr_ret_capabilities_flags.
If srvr_ret_capabilities_flags indicate simple retention, the
server MUST support rtime and rbtime.
If srvr_ret_capabilities_flags indicate event retention, the
server MUST support etime and ebtime.
If srvr_ret_capabilities_flags indicate ADMIN_HOLD, the server
MUST support admin_hold_flags.
3. Further Notes
Notes
If both simple and event-based deletion are active on a file,
as indicated by set RET4_SIMPLE_RETENTION_ENABLED and
RET4_EVENT_RETENTION_ENABLED flags, deletion MUST NOT be allowed
until both retention intervals have expired.
The TWG considered a delete-after datestamp instead of the datestamp/
interval mechanism presented here. This can solve problems related
to the variable number of seconds in durations such as months. An
early reviewer from the NFSv4 WG also expressed a preference for
this style. However, the etime cannot be expressed this way, as it
may be set before the ebtime. An example is a requirement that a
hospital record be kept three years after the death of the patient.
In this case, etime would be three years' worth of seconds, and
RET4_EVENT_RETENTION_ENABLED would be set, but ebtime would be kept
unset until notification of the death of the patient.
Yoder & Black Expires February 26, 2007 [Page 6]
Internet-Draft NFSv4.1 Retention Attributes August 2006
The TWG also considered allowing ebtime to be set in the past. In
the above example, one might like to set ebtime to the actual time
of death. However, this capability introduces a hole--a rogue
client could set ebtime to Jan 1, 1970 and proceed to delete the
file if etime were less than 36 years (as of 2006).
An early reviewer also questioned the need for
RET4_SIMPLE_RETENTION_INFINITE and RET4_EVENT_RETENTION_INFINITE,
saying that 0x7FFFFFFFFFFFFFFF seconds is long enough. Several
application writers in the TWG objected to this use of magic
constants, as they already have too many of them and fear conflicts.
Clients SHOULD use extreme care in setting either
RET4_SIMPLE_RETENTION_INFINITE or RET4_EVENT_RETENTION_INFINITE, as
setting these cannot be undone, meaning the files will never be
deletable or updateable under the retention rules.
4. Security Considerations
TBD
5. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", March 1997.
Authors' Addresses
Alan Yoder
Network Appliance, Inc.
495 E Java Drive
Sunnyvale, CA 94089
Phone: +1-408-822-6919
Email: agy@netapp.com
David L. Black
EMC Corporation
176 South Street
Hopkinton, MA 01748
USA
Phone: +1-978-253-0937
Email: black_david@emc.com
Yoder & Black Expires February 26, 2007 [Page 7]
Internet-Draft NFSv4.1 Retention Attributes August 2006
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Yoder & Black Expires February 26, 2007 [Page 8]
