idnits 2.17.00 (12 Aug 2021) /tmp/idnits27308/draft-yoder-nfsv4-retention-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 330. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 341. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 348. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 354. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 3 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 25, 2006) is 5741 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. '1' Summary: 6 errors (**), 0 flaws (~~), 1 warning (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NFSv4 A. Yoder 3 Internet-Draft Network Appliance 4 Intended status: Standards Track D. Black 5 Expires: February 26, 2007 EMC 6 August 25, 2006 8 NFSv4.1 Retention Attributes 9 draft-yoder-nfsv4-retention-00.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on February 26, 2007. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 This Internet-Draft describes additional file attributes to be used 43 in NFSv4.1 for data retention semantics. 45 Requirements Language 47 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 48 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 49 document are to be interpreted as described in RFC 2119 [1]. 51 Table of Contents 53 1. NFSv4.1 Data Retention Attributes . . . . . . . . . . . . . . . 3 54 1.1. int64 rtime . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.2. int64 stime . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.3. int64 ertime . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.4. int64 etime . . . . . . . . . . . . . . . . . . . . . . . . 4 58 1.5. int8 retention_flags . . . . . . . . . . . . . . . . . . . 4 59 1.6. int8 admin_hold_flags . . . . . . . . . . . . . . . . . . . 5 60 1.7. int32 srvr_ret_capabilities_flags . . . . . . . . . . . . . 5 61 2. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 3. Further Notes . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 64 5. Normative References . . . . . . . . . . . . . . . . . . . . . 6 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 66 Intellectual Property and Copyright Statements . . . . . . . . . . 8 68 1. NFSv4.1 Data Retention Attributes 70 The FCAS TWG of SNIA met on 1 Aug 2006 and had an extensive 71 discussion regarding alignment of retention models between XAM and 72 NFSv4.1. While there are some areas in which the two standards are 73 unlikely to meet exactly, the consensus is that the following 74 attributes are sufficient to express the retention model under 75 consideration for XAM v1. Mike Eisler and Dave Noveck contributed 76 to the formulation presented here. 78 1.1. uint64_t rtime 80 The minimum retention duration for a file, in seconds. 82 Rtime is expressed as a duration, as it may be set before the 83 initial timestamp which delimits the beginning of the retention 84 interval is known. 86 Rtime MUST have a value of zero upon file creation. It is ignored 87 until RET4_SIMPLE_RETENTION_ENABLED is set. The rtime attribute 88 MAY be increased by a client-side SETATTR operation. The server 89 MUST NOT allow decrease of this quantity under any circumstances. 91 Permission to set and increase rtime is governed by a new NFSv4 92 bitmask ACE4_WRITE_RETENTION (0x00000200). Servers MAY map this to 93 ACE4_WRITE_ATTRIBUTES (0x00000100). 95 1.2. nfstime4 rbtime 97 The timestamp specifying the beginning of the retention period. If 98 rbtime is set, the server MUST NOT allow deletion of or change to a 99 file before the time given by rtime + stime. 101 When the client first sets the rbtime to any value, via SETATTR, the 102 server MUST set it to the current time as perceived by the server, 103 and atomically also set the RET4_SIMPLE_RETENTION_ENABLED flag. 104 Once set, the server MUST NOT permit change to the rbtime or the 105 RET4_SIMPLE_RETENTION_ENABLED flag. 107 Rbtime MUST have a value of zero upon file creation. 109 Permission to "set" rbtime is governed by ACE4_WRITE_RETENTION. 111 1.3. uint64_t etime 113 The minimum retention duration for a file, in seconds, following an 114 application-specified event. The etime MAY be increased by a client- 115 side SETATTR operation. The server MUST NOT allow decrease of this 116 quantity under any circumstances. 118 Etime MUST have an initial value of zero. It is ignored until 119 RET4_EVENT_RETENTION_ENABLED is set. Clients MAY set the flag 120 RET4_EVENT_RETENTION_ENABLED at any time. 122 Permission to set and increase etime is governed by 123 ACE4_WRITE_RETENTION. 125 Clients SHOULD set the etime before setting the 126 RET4_EVENT_RETENTION_ENABLED flag, to avoid windows of mutability. 128 1.4. nfstime4 ebtime 130 The timestamp specifying the beginning of the event-based retention 131 period. If ebtime is set, the server MUST NOT allow deletion of or 132 change to a file before the time given by ebtime + etime. 134 Setting the ebtime is the equivalent to an event notification 135 operation in XAM. 137 Ebtime MUST have a value of zero upon file creation. This indicates 138 that no application-specified event has yet taken place. 140 When the client first sets the ebtime to any value, via SETATTR, the 141 server MUST set it to the current time as perceived by the server, 142 and atomically also set the RET4_EVENT_RETENTION_ENABLED flag. 143 Once set, the server MUST NOT permit change to the ebtime or the 144 RET4_EVENT_RETENTION_ENABLED flag. 146 Permission to "set" ebtime is governed by ACE4_WRITE_RETENTION. 148 1.5. uint32_t retention_flags 150 Flags are as follows: 152 RET4_SIMPLE_RETENTION_ENABLED = 0x01 154 RET4_EVENT_RETENTION_ENABLED = 0x02 156 RET4_SIMPLE_RETENTION_INFINITE = 0x04 158 RET4_EVENT_RETENTION_INFINITE = 0x08 160 If RET4_SIMPLE_RETENTION_ENABLED is set, the server MUST do retention 161 based on the corresponding set of attributes (rtime and stime for 162 RET4_SIMPLE_RETENTION_ENABLED, etime and ertime for 163 RET4_EVENT_RETENTION_ENABLED). 165 The server MUST NOT turn off any of these flags, once set. 167 RET4_SIMPLE_RETENTION_INFINITE and RET4_EVENT_RETENTION_INFINITE 168 override all retention timestamps. The server MUST NOT allow deletion 169 or modification of the file as long as either of these bits are set. 171 The server MUST NOT allow unsetting of either of these bits. 173 Permission to set retention_flags is governed by 174 ACE4_WRITE_RETENTION. 176 1.6. uint32_t admin_hold_flags 178 These 32 flags are used to indicate administrative holds (e.g. holds 179 placed by judicial fiat). These override all other retention 180 expiration mechanisms. The server MUST NOT allow deletion or 181 modification of the file as long as any of the bits in 182 admin_hold_flags are set. Bits MAY be unset by clients with 183 sufficient permission. 185 Permission to set admin_hold_flags is governed by a new NFSv4 bitmask 186 ACE4_WRITE_HOLD (0x00000400). Servers SHOULD NOT map this to 187 ACE4_WRITE_ATTRIBUTES (0x00000100). 189 Admin_hold_flags MUST have a value of zero upon file creation. 191 1.7 uint32_t srvr_ret_capabilities_flags 193 RET4_SIMPLE_RETENTION = 0x01 195 RET4_EVENT_RETENTION = 0x02 197 RET4_SIMPLE_RETENTION_INFINITE = 0x04 199 RET4_EVENT_RETENTION_INFINITE = 0x08 201 RET4_ADMIN_HOLD = 0x10 203 Support for retention attributes is optional. If implemented, the 204 server MUST indicate support for simple retention, event-based 205 retention, infinite retention and administrative holds by setting 206 the respective bit in srvr_ret_capabilities_flags in a GETATTR 207 response. If the server does not support any retention attributes, 208 it MAY return NFS4ERR_ATTRNOTSUPP in response to a GETATTR of 209 srvr_ret_capabilities_flags. 211 The server MUST disallow any attempts to perform a SETATTR on 212 srvr_ret_capabilities_flags. 214 2. Discussion 216 Support for any or all retention attributes is optional. If 217 implemented, they MAY be implemented on a per-filesystem basis. 218 If they are, the server MAY implement a different set of attributes, 219 and return a corresponding srvr_ret_capabilities_flags instance, 220 for each filesystem. 222 On filesystems that do not support a given retention attribute, 223 NFS4ERR_ATTRNOTSUPP shall be returned in response to all GETATTR 224 and SETATTR calls for that attribute. 226 There are numerous interdependencies between flags which introduce 227 requirements on which combinations of them must be supported if 228 any are: 230 If the server supports rtime, then it MUST support rbtime 231 and vice versa. 233 If the server supports etime, then it MUST support ebtime 234 and vice versa. 236 If the server supports rtime, rbtime, etime, or ebtime, 237 it MUST support retention_flags. 239 If the server supports any retention flags, it MUST also support 240 srvr_ret_capabilities_flags. 242 If srvr_ret_capabilities_flags indicate simple retention, the 243 server MUST support rtime and rbtime. 245 If srvr_ret_capabilities_flags indicate event retention, the 246 server MUST support etime and ebtime. 248 If srvr_ret_capabilities_flags indicate ADMIN_HOLD, the server 249 MUST support admin_hold_flags. 251 3. Further Notes 253 Notes 255 If both simple and event-based deletion are active on a file, 256 as indicated by set RET4_SIMPLE_RETENTION_ENABLED and 257 RET4_EVENT_RETENTION_ENABLED flags, deletion MUST NOT be allowed 258 until both retention intervals have expired. 260 The TWG considered a delete-after datestamp instead of the datestamp/ 261 interval mechanism presented here. This can solve problems related 262 to the variable number of seconds in durations such as months. An 263 early reviewer from the NFSv4 WG also expressed a preference for 264 this style. However, the etime cannot be expressed this way, as it 265 may be set before the ebtime. An example is a requirement that a 266 hospital record be kept three years after the death of the patient. 267 In this case, etime would be three years' worth of seconds, and 268 RET4_EVENT_RETENTION_ENABLED would be set, but ebtime would be kept 269 unset until notification of the death of the patient. 271 The TWG also considered allowing ebtime to be set in the past. In 272 the above example, one might like to set ebtime to the actual time 273 of death. However, this capability introduces a hole--a rogue 274 client could set ebtime to Jan 1, 1970 and proceed to delete the 275 file if etime were less than 36 years (as of 2006). 277 An early reviewer also questioned the need for 278 RET4_SIMPLE_RETENTION_INFINITE and RET4_EVENT_RETENTION_INFINITE, 279 saying that 0x7FFFFFFFFFFFFFFF seconds is long enough. Several 280 application writers in the TWG objected to this use of magic 281 constants, as they already have too many of them and fear conflicts. 283 Clients SHOULD use extreme care in setting either 284 RET4_SIMPLE_RETENTION_INFINITE or RET4_EVENT_RETENTION_INFINITE, as 285 setting these cannot be undone, meaning the files will never be 286 deletable or updateable under the retention rules. 288 4. Security Considerations 290 TBD 292 5. Normative References 294 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 295 Levels", March 1997. 297 Authors' Addresses 299 Alan Yoder 300 Network Appliance, Inc. 301 495 E Java Drive 302 Sunnyvale, CA 94089 304 Phone: +1-408-822-6919 305 Email: agy@netapp.com 307 David L. Black 308 EMC Corporation 309 176 South Street 310 Hopkinton, MA 01748 311 USA 313 Phone: +1-978-253-0937 314 Email: black_david@emc.com 316 Full Copyright Statement 318 Copyright (C) The Internet Society (2006). 320 This document is subject to the rights, licenses and restrictions 321 contained in BCP 78, and except as set forth therein, the authors 322 retain all their rights. 324 This document and the information contained herein are provided on an 325 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 326 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 327 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 328 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 329 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 330 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 332 Intellectual Property 334 The IETF takes no position regarding the validity or scope of any 335 Intellectual Property Rights or other rights that might be claimed to 336 pertain to the implementation or use of the technology described in 337 this document or the extent to which any license under such rights 338 might or might not be available; nor does it represent that it has 339 made any independent effort to identify any such rights. Information 340 on the procedures with respect to rights in RFC documents can be 341 found in BCP 78 and BCP 79. 343 Copies of IPR disclosures made to the IETF Secretariat and any 344 assurances of licenses to be made available, or the result of an 345 attempt made to obtain a general license or permission for the use of 346 such proprietary rights by implementers or users of this 347 specification can be obtained from the IETF on-line IPR repository at 348 http://www.ietf.org/ipr. 350 The IETF invites any interested party to bring to its attention any 351 copyrights, patents or patent applications, or other proprietary 352 rights that may cover technology that may be required to implement 353 this standard. Please address the information to the IETF at 354 ietf-ipr@ietf.org. 356 Acknowledgment 358 Funding for the RFC Editor function is provided by the IETF 359 Administrative Support Activity (IASA).