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]