idnits 2.17.1 draft-shepler-nfsv4-dirnotify-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC2119], [RFC3530]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 (May 2003) is 7652 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) == Missing Reference: 'RFC2119' is mentioned on line 52, but not defined ** Obsolete normative reference: RFC 3530 (Obsoleted by RFC 7530) Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Spencer Shepler 3 Internet Draft Editor 4 Document: draft-shepler-nfsv4-dirnotify-00.txt Sun Microsystems 5 May 2003 7 NFS version 4 Directory Notifications 9 Status of this Memo 11 This document is an Internet-Draft and is subject to all provisions 12 of Section 10 of RFC2026. 14 This document is an Internet-Draft. Internet-Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its areas, 16 and its working groups. Note that other groups may also distribute 17 working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet- Drafts as reference 22 material or to cite them other than as "work in progress." 24 To view the entire list of current Internet-Drafts, please check the 25 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 26 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 27 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 28 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 30 Abstract 32 NFSv4 [RFC3530] contains within it a mechanism for the delegation of 33 file data to a client. The intent of this feature is to reduce the 34 necessary interaction between a client and server such that overall 35 performance is improved. The same type of mechanism does not exist 36 for directory contents and to determine validity of cached directory 37 contents an NFSv4 client is left with polling the server to determine 38 if updates have occurred. 40 The proposal described here is for an NFSv4 minor version that would 41 allow a client to register interest in a directory and to receive a 42 callback RPC upon update of that directory. This type of interaction 43 would reduce or eliminate the polling that occurs between client and 44 server and improve scalability of the server's resources along with 45 improved performance for the client's directory content caching. 47 Key Words 49 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 50 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 51 document are to be interpreted as described in [RFC2119]. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 56 2. Design . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 4. GETDIR_NOTIFICATION - Request notification on a Directory . 6 59 5. CLIENTID - Notify server of clientid associated with request 8 60 6. Security Considerations . . . . . . . . . . . . . . . . . . 9 61 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 9 62 8. Normative References . . . . . . . . . . . . . . . . . . . 10 63 9. Informative References . . . . . . . . . . . . . . . . . . 10 64 10. Authors Address . . . . . . . . . . . . . . . . . . . . . 11 65 10.1. Editor's Address . . . . . . . . . . . . . . . . . . . 11 66 10.2. Author's Addresses . . . . . . . . . . . . . . . . . . 11 67 11. Copyright . . . . . . . . . . . . . . . . . . . . . . . . 12 69 1. Introduction 71 Directory caching for the NFS (Network File System) version 4 72 [RFC3530] protocol is similar to previous versions of NFS. Directory 73 information is cached on the client for a duration determined by the 74 client. At the end of a predefined timeout, the client will query the 75 server to see if the directory has been updated. In order to reduce 76 network traffic, NFS version 4 defines delegations on file data. 77 Traffic reduction is also the motivation behind directory 78 notifications. 80 A client registers interest in a directory by use of a specific 81 operation and will be notified if that directory is modified in the 82 future. While this directory nofication mechanism uses the 83 delegation structure of the NFSv4 protocol, it differs from file 84 delegations in that the server is not required to notify registered 85 clients before a directory modification can proceed. While a 86 directory notification doesn't provide strict notification behaviors, 87 this allows the client to locally service certain directory 88 operations (LOOKUP, LOOKUPP, READDIR) from its directory cache 89 without querying the server at periodic predefined intervals. 91 2. Design 93 Directory notification design is based on file delegation. 95 o Use the existing file data delegation callback mechanism 97 o Use stateid's as in file data delegation 99 o DELEGRETURN will be used to return a directory delegation. 101 o Server decides when to accept directory notification 102 registrations. 104 o Unlike file delegations which piggy-back on the file OPEN call, 105 the client will request a directory notification with a new 106 operation GETDIR_NOTIFICATION. 108 o directory notifications delegates what set of attributes? e.g. 109 ACL, change, space_avail, time_access. What attributes should 110 not be delegated. 112 o directory notification covers contents: filehandles, fileid, 113 fsid, cookies cached as part of directory, read the rest later 114 even with a delegation 116 o when a server receives a change in a directory with a registered 117 notification, it doesn't have to wait for all DELEGRETURNs to 118 occur before allowing the modification. 120 3. Issues 122 o should we include the change attributes of the directory 123 contents? 124 problem: it's hard for the server to bookkeep. 125 - singlely linked: keep track of parent 126 - multiply linked: hard to keep track of 128 o renaming 129 - grandparent renamed - directory read delegation still ok. 130 - parent renamed? 131 - content reneame? recall delegation. 133 o callback vrs change notify 134 - should we allow a change notify operation over the callback 135 communication link so that a small number of contents in a 136 big directory can be updated without recalling the 137 delegation? 139 4. GETDIR_NOTIFICATION - Request notification on a Directory 141 SYNOPSIS 143 (cfh), dir_delegation_type4 -> stateid 145 ARGUMENT 147 enum dir_delegation_type4 { 148 DIRECTORY_NOTIFY = 0 149 }; 151 struct GETDIR_NOTIFICATION4args { 152 clientid4clientid; 153 dir_delegation_type4 type; 154 } 156 RESULT 158 union GETDIR_NOTIFICATION4res (bool_t available){ 159 case TRUE: 160 stateid4 dir_stateid; 161 case FALSE: 162 default: 163 void; 164 } 166 DESCRIPTION 168 The client issues a GETDIR_NOTIFICATION operation to request a 169 notification on the direcory represented by the current filehandle. 170 If the server is unable or unwilling to provide the directory 171 notification, the result will indicate this by setting the 172 "available" value to FALSE. In the case "available" is TRUE, the 173 server provides a directory notification stateid. This stateid is 174 used by the client to match CB_RECALL calls from server to client. 175 It is also used by the client for DELEGRETURN to indicate to the 176 server that the directory notification is no longer needed. 178 IMPLEMENTATION 180 Since a server is not required to return directory notifications, 181 the client must be prepared to never receive a directory 182 notification stateid. This also allows the server to avoid 183 returning an error for GETDIR_NOTIFICATION when it otherwise may be 184 required. This would potentially allow for a COMPOUND request to 185 succeed in the case that subsequent operations would not encounter 186 an error. 188 PUTFH (directory filehandle) 189 GETDIR_NOTIFICATION 190 READDIR or LOOKUP 192 5. CLIENTID - Notify server of clientid associated with request 194 SYNOPSIS 196 clientid -> () 198 ARGUMENT 200 struct CLIENTID4args { 201 clientid4 clientid; 202 }; 204 RESULT 206 struct CLIENTID4res { 207 nfsstat4 status; 208 }; 210 DESCRIPTION 212 The CLIENTID operation is uesd to identify the client by the server 213 supplied clientid. This operation (used within a COMPOUND prior to 214 operations that either deal with file delegations or directory 215 notifications) can be used as an optimization for interaction 216 between client and server. The use of the operation is not 217 required but the client should expect that the server may generate 218 callbacks because it can not differentiate the client holding the 219 delegation or directory notification from a client that does not 220 hold the delegation or directory notification. 222 An example of use would be something like: 224 PUTFH 225 CLIENTID 226 CREATE 228 In this scenario, the server is able to identify the client and 229 associate a directory notification for the target directory of 230 CREATE and avoid a notification callback as a result of the object 231 creation. 233 The client is implicitly agreeing to managing its knowledge of the 234 directory notification in this case by the use of the CLIENTID 235 operation. Therefore, the client must not rely on the server's 236 callback and update its directory information as appropriate. 238 IMPLEMENTATION 240 ERRORS 242 NFS4ERR_ADMIN_REVOKED 243 NFS4ERR_BADXDR 244 NFS4ERR_CB_PATH_DOWN 245 NFS4ERR_EXPIRED 246 NFS4ERR_LEASE_MOVED 247 NFS4ERR_RESOURCE 248 NFS4ERR_SERVERFAULT 249 NFS4ERR_STALE_CLIENTID 251 6. Security Considerations 253 Note: security issues have yet to be considered and documented 255 7. IANA Considerations 257 Note: IANA issues have yet to be documented. 259 8. Normative References 261 [RFC3530] S. Shepler, B. Callaghan, D. Robinson, R. Thurlow, C. 262 Beame, M. Eisler, D. Noveck, RFC3530, "Network File System 263 (NFS) version 4 Protocol", April 2003. 265 9. Informative References 266 10. Authors Address 268 Address comments related to this memorandum to: 270 nfsv4@ietf.org 272 10.1. Editor's Address 274 Spencer Shepler 275 7808 Moonflower Drive 276 Austin, Texas 78750 278 Phone: 512-349-9376 279 E-mail: spencer.shepler@sun.com 281 10.2. Author's Addresses 283 Andy Adamson 284 Center for Information Technology Integration 285 The University of Michigan 286 519 W.William 287 Ann Arbor, MI 48103-4943 289 Phone: 734.764.9465 290 E-mail: andros@citi.umich.edu 292 David Noveck 293 Network Appliance 294 375 Totten Pond Road 295 Waltham, MA 02451 297 Phone: +1 781-768-5347 298 E-mail: dnoveck@netapp.com 300 11. Copyright 302 "Copyright (C) The Internet Society (date). All Rights Reserved. 304 This document and translations of it may be copied and furnished to 305 others, and derivative works that comment on or otherwise explain it 306 or assist in its implmentation may be prepared, copied, published and 307 distributed, in whole or in part, without restriction of any kind, 308 provided that the above copyright notice and this paragraph are 309 included on all such copies and derivative works. However, this 310 document itself may not be modified in any way, such as by removing 311 the copyright notice or references to the Internet Society or other 312 Internet organizations, except as needed for the purpose of 313 developing Internet standards in which case the procedures for 314 copyrights defined in the Internet Standards process must be 315 followed, or as required to translate it into languages other than 316 English. 318 The limited permissions granted above are perpetual and will not be 319 revoked by the Internet Society or its successors or assigns. 321 This document and the information contained herein is provided on an 322 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 323 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 324 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 325 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 326 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."