idnits 2.17.1 draft-ietf-nfsv4-directory-delegation-01.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 3667, Section 5.1 on line 13. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1159. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ( - It does however have an RFC 2026 Section 10.4(A) Disclaimer.) ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation -- however, there's a paragraph with a matching beginning. Boilerplate error? ( - It does however have an RFC 2026 Section 10.4(B) IPR Disclosure Invitation.) ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The abstract seems to contain references ([RFC3530]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 455 has weird spacing: '...r_entry cha...' == Line 970 has weird spacing: '...r_entry chan...' == Line 974 has weird spacing: '...r_entry old_...' -- 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 (March 2005) is 6983 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3530 (Obsoleted by RFC 7530) Summary: 11 errors (**), 0 flaws (~~), 5 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group S. Khan 2 Internet-Draft Author 3 Document: Network Appliance, Inc. 4 draft-ietf-nfsv4-directory-delegation-01.txt March 2005 6 NFSv4.1: Directory Delegations and Notifications 8 Status of this Memo 10 By submitting this Internet-Draft, I certify that any applicable 11 patent or other IPR claims of which I am aware have been disclosed, 12 or will be disclosed, and any of which I become aware will be 13 disclosed, in accordance with RFC 3668. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as 18 Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other 22 documents at any time. It is inappropriate to use Internet- 23 Drafts as reference material or to cite them other than as 24 "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/1id-abstracts.html 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 ABSTRACT 34 This document proposes adding directory delegations and notifications 35 to NFS Version 4 [RFC3530]. It is hoped that these changes will be 36 part of a new minor version of NFS, such as NFSv4.1. 38 TABLE OF CONTENTS 40 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 41 2. Proposed protocol extensions. . . . . . . . . . . . . . . . . 3 42 3. Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 43 4. New Operation 40: GET_DIR_DELEGATION - Get a directory 44 delegation . . . . . . . . . . . . . . . . . . . . . . . . . . 5 45 5. New Recommended Attributes . . . . . . . . . . . . . . . . . . 8 46 6. New Callback Operation: CB_NOTIFY - Notify directory changes . 9 47 7. Delegation Recall . . . . . . . . . . . . . . . . . . . . . 12 48 8. New Callback Operation: CB_RECALL_ANY - Keep any N 49 delegations . . . . . . . . . . . . . . . . . . . . . . . . 13 50 9. Delegation Recovery . . . . . . . . . . . . . . . . . . . . 14 51 10. Issues . . . . . . . . . . . . . . . . . . . . . . . . . . 14 52 10.1. Synchronous vs. Asynchronous notifications . . . . . . . 14 53 11. RPC Definition File Changes . . . . . . . . . . . . . . . . 14 54 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . 23 55 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 23 56 14. Normative References . . . . . . . . . . . . . . . . . . . 23 57 15. Informative References . . . . . . . . . . . . . . . . . . 24 58 16. Author's Address . . . . . . . . . . . . . . . . . . . . . 24 59 17. IPR Notices . . . . . . . . . . . . . . . . . . . . . . . . 24 60 18. Copyright Notice . . . . . . . . . . . . . . . . . . . . . 24 62 1. Introduction 64 This document assumes understanding of the NFSv4.0 specification. It 65 also assumes that the changes proposed by [talpey] will be present in 66 the same minor version or certain incremental additions to this 67 proposal will be required, as discussed later in the document. 69 The major addition to NFS version 4 in the area of caching is the 70 ability of the server to delegate certain responsibilities to the 71 client. When the server grants a delegation for a file to a client, 72 the client receives certain semantics with respect to the sharing of 73 that file with other clients. At OPEN, the server may provide the 74 client either a read or write delegation for the file. If the client 75 is granted a read delegation, it is assured that no other client has 76 the ability to write to the file for the duration of the delegation. 77 If the client is granted a write delegation, the client is assured 78 that no other client has read or write access to the file. This 79 reduces network traffic and server load by allowing the client to 80 perform certain operations on local file data and can also provide 81 stronger consistency for the local data. 83 Directory caching for the NFS version 4 protocol is similar to 84 previous versions. Clients typically cache directory information for 85 a duration determined by the client. At the end of a predefined 86 timeout, the client will query the server to see if the directory has 87 been updated. By caching attributes, clients reduce the number of 88 GETATTR calls made to the server to validate attributes. Furthermore, 89 frequently accessed files and directories, such as the current 90 working directory, have their attributes cached on the client so that 91 some NFS operations can be performed without having to make an RPC 92 call. By caching name and inode information about most recently 93 looked up entries in DNLC (Directory Name Lookup Cache), clients do 94 not need to send LOOKUP calls to the server every time these files 95 are accessed. 97 This caching approach works reasonably well at reducing network 98 traffic in many environments. However, it does not address 99 environments where there are numerous queries for files that do not 100 exist. In these cases of "misses", the client must make RPC calls to 101 the server in order to provide reasonable application semantics and 102 promptly detect the creation of new directory entries. Examples of 103 high miss activity are compilation in software development 104 environments. The current behavior of NFS limits its potential 105 scalability and wide-area sharing effectiveness in these types of 106 environments. Other distributed stateful filesystem architectures 107 such as AFS and DFS have proven that adding state around directory 108 contents can greatly reduce network traffic in high miss 109 environments. 111 Delegation of directory contents is proposed as an extension for 112 NFSv4. Such an extension would provide similar traffic reduction 113 benefits as with file delegations. By allowing clients to cache 114 directory contents (in a read-only fashion) while being notified of 115 changes, the client can avoid making frequent requests to interrogate 116 the contents of slowly-changing directories, reducing network traffic 117 and improving client performance. 119 These extensions allow improved namespace cache consistency to be 120 achieved through delegations and synchronous recalls alone without 121 asking for notifications. In addition, if time-based consistency is 122 sufficient, asynchronous notifications can provide performance 123 benefits for the client, and possibly the server, under some common 124 operating conditions such as slowly-changing and/or very large 125 directories. 127 2. Proposed protocol extensions. 129 This document includes the definition of protocol extensions to 130 implement directory delegations. It is believed that these extension 131 fit within the minor-versioning framework presented in RFC3530. 133 The NFSv4 Sessions Extensions [talpey] include a new operation 134 (called SEQUENCE) in each COMPOUND procedure which carries the 135 clientid associated with the session to which the procedure belongs. 136 In NFSv4.0, only certain COMPOUND procedures may carry such a 137 clientid. When present, this clientid provides all the necessary 138 context for maintaining directory delegations, and dispatching 139 appropriate callbacks. 141 If the directory delegation protocol described here is not able to 142 leverage any pre-existing clientid present in each COMPOUND request, 143 then the equivalent clientid must be provided where necessary. This 144 could be accomplished by simply including the SEQUENCE operation in 145 each compound of the new minor version, regardless of the status of 146 any session. 148 Mainly in the interests of clarity of presentation, elements within 149 these extensions are assigned numeric identifiers such as operation 150 numbers and attribute identifiers. It should be understood that when 151 these extensions are included in a minor version of NFSv4, the actual 152 numeric identifiers assigned may be different from the ones chosen 153 here. 155 3. Design 157 A new operation GET_DIR_DELEGATION is used by the client to ask for a 158 directory delegation. The delegation covers directory attributes and 159 all entries in the directory. If either of these change the 160 delegation will be recalled synchronously. The operation causing the 161 recall will have to wait before the recall is complete. Any changes 162 to directory entry attributes will not cause the delegation to be 163 recalled. 165 In addition to asking for delegations, a client can also ask for 166 notifications for certain events. These events include changes to 167 directory attributes and/or its contents. If a client asks for 168 notification for a certain event, the server will notify the client 169 when that event occurs. This will not result in the delegation being 170 recalled for that client. The notifications are asynchronous and 171 provide a way of avoiding recalls in situations where a directory is 172 changing enough that the pure recall model may not be effective while 173 trying to allow the client to get substantial benefit. In the absence 174 of notifications, once the delegation is recalled the client has to 175 refresh its directory cache which might not be very efficient for 176 very large directories. 178 The delegation is read only and the client may not make changes to 179 the directory other than by performing NFSv4 operations that modify 180 the directory or the associated file attributes so that the server 181 has knowledge of these changes. In order to keep the client namespace 182 in sync with the server, the server will notify the client holding 183 the delegation of the changes made as a result. This is to avoid any 184 subsequent GETATTR or READDIR calls to the server. If a client 185 holding the delegation makes any changes to the directory, the 186 delegation will not be recalled. 188 Delegations can be recalled by the server at any time. Normally, the 189 server will recall the delegation when the directory changes in a way 190 that is not covered by the notification, or when the directory 191 changes and notifications have not been requested. 193 Also if the server notices that handing out a delegation for a 194 directory is causing too many notifications to be sent out, it may 195 decide not to hand out a delegation for that directory or recall 196 existing delegations. If another client removes the directory for 197 which a delegation has been granted, the server will recall the 198 delegation. 200 Both the notification and recall operations need a callback path to 201 exist between the client and server. If the callback path does not 202 exist, then delegation can not be granted. Note that with the session 203 extensions [talpey] that should not be an issue. In the absense of 204 sessions, the server will have to establish a callback path to the 205 client to send callbacks. 207 4. New Operation 40: GET_DIR_DELEGATION - Get a directory delegation 209 SYNOPSIS 210 (cfh), requested notification -> (cfh), cookieverf, stateid, 211 supported notification 213 ARGUMENT 214 struct GET_DIR_DELEGATION4args { 215 dir_notification_type4 notification_type; 216 attr_notice4 child_attr_delay; 217 attr_notice4 dir_attr_delay; 218 }; 220 /* 221 * Notification types. 222 */ 223 const DIR_NOTIFICATION_NONE = 0x00000000; 224 const DIR_NOTIFICATION_CHANGE_CHILD_ATTRIBUTES = 0x00000001; 225 const DIR_NOTIFICATION_CHANGE_DIR_ATTRIBUTES = 0x00000002; 226 const DIR_NOTIFICATION_REMOVE_ENTRY = 0x00000004; 227 const DIR_NOTIFICATION_ADD_ENTRY = 0x00000008; 228 const DIR_NOTIFICATION_RENAME_ENTRY = 0x00000010; 229 const DIR_NOTIFICATION_CHANGE_COOKIE_VERIFIER = 0x00000020; 231 typedef uint32_t dir_notification_type4; 233 typedef nfstime4 attr_notice4; 235 RESULT 236 struct GET_DIR_DELEGATION4resok { 237 verifier4 cookieverf; 238 /* Stateid for get_dir_delegation */ 239 stateid4 stateid; 240 /* Which notifications can the server support */ 241 dir_notification_type4 supp_notification; 242 bitmap4 child_attributes; 243 bitmap4 dir_attributes; 244 }; 246 union GET_DIR_DELEGATION4res switch (nfsstat4 status) { 247 case NFS4_OK: 248 /* CURRENT_FH: delegated dir */ 249 GET_DIR_DELEGATION4resok resok4; 250 default: 251 void; 252 }; 254 DESCRIPTION: 255 The GET_DIR_DELEGATION operation is used by a client to request 256 a directory delegation. The directory is represented by the 257 current filehandle. The client also specifies whether it wants 258 the server to notify it when the directory changes in certain 259 ways by setting one or more bits in a bitmap. The server may 260 also choose not to grant the delegation. In that case the server 261 will return NFS4ERR_DIRDELEG_UNAVAIL. If the server decides to 262 hand out the delegation, it will return a cookie verifier for 263 that directory. If the cookie verifier changes when the client 264 is holding the delegation, the delegation will be recalled 265 unless the client has asked for notification for this event. In 266 that case a notification will be sent to the client. 268 The server will also return a directory delegation stateid in 269 addition to the cookie verifier as a result of the 270 GET_DIR_DELEGATION operation. This stateid will appear in 271 callback messages related to the delegation, such as 272 notifications and delegation recalls. The client will use this 273 stateid to return the delegation voluntarily or upon recall. A 274 delegation is returned by calling the DELEGRETURN operation. 276 The server may not be able to support notifications of certain 277 events. If the client asks for such notifications, the server 278 must inform the client of its inability to do so as part of the 279 GET_DIR_DELEGATION reply by not setting the appropriate bits in 280 the supported notifications bitmask contained in the reply. 282 The GET_DIR_DELEGATION operation can be used for both normal and 283 named attribute directories. It covers all the entries in the 284 directory except the ".." entry. That means if a directory and 285 its parent both hold directory delegations, any changes to the 286 parent will not cause a notification to be sent for the child 287 even though the child's ".." entry points to the parent. 289 IMPLEMENTATION: 291 Directory delegation provides the benefit of improving cache 292 consistency of namespace information. This is done through 293 synchronous callbacks. A server must support synchronous 294 callbacks in order to support directory delegations. In addition 295 to that, asynchronous notifications provide a way to reduce 296 network traffic as well as improve client performance in certain 297 conditions. Notifications would not be requested when the goal 298 is just cache consitency. 300 Notifications are specified in terms of potential changes to the 301 directory. A client can ask to be notified whenever an entry is 302 added to a directory by setting notification_type to 303 DIR_NOTIFICATION_ADD_ENTRY. It can also ask for notifications on 304 entry removal, renames, directory attribute changes and cookie 305 verifier changes by setting notification_type flag 306 appropriately. In addition to that, the client can also ask for 307 notifications upon attribute changes to children in the 308 directory to keep its attribute cache up to date. However any 309 changes made to child attributes do not cause the delegation to 310 be recalled. If a client is interested in directory entry 311 caching, or negative name caching, it can set the 312 notification_type appropriately and the server will notify it of 313 all changes that would otherwise invalidate its name cache. The 314 kind of notification a client asks for may depend on the 315 directory size, its rate of change and the applications being 316 used to access that directory. However, the conditions under 317 which a client might ask for a notification, is out of the scope 318 of this specification. 320 The client will set one or more bits in a bitmap 321 (notification_type) to let the server know what kind of 322 notification(s) it is interested in. For attribute notifications 323 it will set bits in another bitmap to indicate which attributes 324 it wants to be notified of. If the server does not support 325 notifications for changes to a certain attribute, it should not 326 set that attribute in the supported attribute bitmap 327 (supp_notification) specified in the reply. 329 In addition to that, the client will also let the server know if 330 it wants to get the notification as soon as the attribute change 331 occurs or after a certain delay by setting a delay factor, 332 child_attr_delay for attribute changes to children and 333 dir_attr_delay for attribute changes to the directory. If this 334 delay factor is set to zero, that indicates to the server that 335 the client wants to be notified of any attribute changes as soon 336 as they occur. If the delay factor is set to N, the server will 337 make a best effort guarantee that attribute updates are not out 338 of sync by more than that. One value covers all attribute 339 changes for the directory and another value covers all attribute 340 changes for all children in the directory. If the client asks 341 for a delay factor that the server does not support or that may 342 cause significant resource consumption on the server by causing 343 the server to send a lot of notifications, the server should not 344 commit to sending out notifications for that attribute and 345 therefore must not set the approprite bit in the 346 child_attributes and dir_attributes bitmaps in the response. 348 The server will let the client know about which notifications it 349 can support by setting appropriate bits in a bitmap. If it 350 agrees to send attribute notifications, it will also set two 351 attribute masks indicating which attributes it will send change 352 notifications for. One of the masks covers changes in directory 353 attributes and the other covers atttribute changes to any files 354 in the directory. 356 The client should use a security flavor that the filesystem is 357 exported with. If it uses a different flavor, the server should 358 return NFS4ERR_WRONGSEC. 360 ERRORS 361 NFS4ERR_ACCESS 362 NFS4ERR_BADHANDLE 363 NFS4ERR_BADXDR 364 NFS4ERR_FHEXPIRED 365 NFS4ERR_INVAL 366 NFS4ERR_MOVED 367 NFS4ERR_NOFILEHANDLE 368 NFS4ERR_NOTDIR 369 NFS4ERR_RESOURCE 370 NFS4ERR_SERVERFAULT 371 NFS4ERR_STALE 372 NFS4ERR_DIRDELEG_UNAVAIL 373 NFS4ERR_WRONGSEC 374 NFS4ERR_EIO 375 NFS4ERR_NOTSUPP 377 5. New Recommended Attributes 379 #56 - supp_dir_attr_notice - notification delays on directory 380 attributes 381 #57 - supp_child_attr_notice - notification delays on child 382 attributes 384 DESCRIPTION: 385 These attributes allow the client and server to negotiate the 386 frequency of notifications sent due to changes in attributes. 387 These attributes are returned as part of a GETATTR call on the 388 directory. The supp_dir_attr_notice value covers all attribute 389 changes to the directory and the supp_child_attr_notice covers 390 all attribute changes to any child in the directory. 392 These attributes are per directory. The client needs to get 393 these values by doing a GETATTR on the directory for which it 394 wants notifications. However these attributes are only required 395 when the client is interested in getting attribute 396 notifications. For all other types of notifications and 397 delegation requests without notifications, these attributes are 398 not required. 400 When the client calls the GET_DIR_DELEGATION operation and asks 401 for attribute change notifications, it will request a 402 notification delay that is within the server's supported range. 403 If the client violates what supp_attr_file_notice or 404 supp_attr_dir_notice values are, the server should not commit to 405 sending notifications for that change event. 407 A value of zero for these attributes means the server will send 408 the notification as soon as the change occurs. It is not 409 recommended to set this value to zero since that can put a lot 410 of burden on the server. A value of N means that the server 411 will make a best effort guarentee that attribute notification 412 are not delayed by more than that. nfstime4 values that compute 413 to negative values are illegal. 415 6. New Callback Operation: CB_NOTIFY - Notify directory changes 417 SYNOPSIS 418 stateid, notification -> {} 420 ARGUMENT 421 struct CB_NOTIFY4args { 422 stateid4 stateid; 423 dir_notification4 changes<>; 424 }; 426 /* 427 * Notification information sent to the client. 428 */ 429 union dir_notification4 430 switch (dir_notification_type4 notification_type) { 431 case DIR_NOTIFICATION_CHANGE_CHILD_ATTRIBUTES: 432 dir_notification_attribute4 change_child_attributes; 433 case DIR_NOTIFICATION_CHANGE_DIR_ATTRIBUTES: 434 fattr4 change_dir_attributes; 435 case DIR_NOTIFICATION_REMOVE_ENTRY: 437 dir_notification_remove4 remove_notification; 438 case DIR_NOTIFICATION_ADD_ENTRY: 439 dir_notification_add4 add_notification; 440 case DIR_NOTIFICATION_RENAME_ENTRY: 441 dir_notification_rename4 rename_notification; 442 case DIR_NOTIFICATION_CHANGE_COOKIE_VERIFIER: 443 dir_notification_verifier4 verf_notification; 444 }; 446 /* 447 * Changed entry information. 448 */ 449 struct dir_entry { 450 component4 file; 451 fattr4 attrs; 452 }; 454 struct dir_notification_attribute4 { 455 dir_entry changed_entry; 456 }; 458 struct dir_notification_remove4 { 459 dir_entry old_entry; 460 nfs_cookie4 old_entry_cookie; 461 }; 463 struct dir_notification_rename4 { 464 dir_entry old_entry; 465 dir_notification_add4 new_entry; 466 }; 468 struct dir_notification_verifier4 { 469 verifier4 old_cookieverf; 470 verifier4 new_cookieverf; 471 }; 473 struct dir_notification_add4 { 474 dir_entry new_entry; 475 /* what READDIR would have returned for this entry */ 476 nfs_cookie4 new_entry_cookie; 477 bool last_entry; 478 prev_entry_info4 prev_info; 479 }; 481 union prev_entry_info4 switch (bool isprev) { 482 case TRUE: /* A previous entry exists */ 483 prev_entry4 prev_entry_info; 484 case FALSE: /* we are adding to an empty 485 directory */ 487 void; 488 }; 490 /* 491 * Previous entry information 492 */ 493 struct prev_entry4 { 494 dir_entry prev_entry; 495 /* what READDIR returned for this entry */ 496 nfs_cookie4 prev_entry_cookie; 497 }; 499 RESULT 500 struct CB_NOTIFY4res { 501 nfsstat4 status; 502 }; 504 DESCRIPTION: 505 The CB_NOTIFY operation is used by the server to send 506 notifications to clients about changes in a delegated directory. 507 These notifications are sent over the callback path. The 508 notification is sent once the original request has been 509 processed on the server. The server will send an array of 510 notifications for all changes that might have occurred in the 511 directory. The dir_notification_type4 can only have one bit set 512 for each notification in the array. If the client holding the 513 delegation makes any changes in the directory that cause files 514 or sub directories to be added or removed, the server will 515 notify that client of the resulting change(s). If the client 516 holding the delegation is making attribute or cookie verifier 517 changes only, the server does not need to send notifications to 518 that client. The server will send the following information for 519 each operation: 521 o ADDING A FILE: The server will send information about the 522 new entry being created along with the cookie for that entry. 523 The entry information contains the nfs name of the entry and 524 attributes. If this entry is added to the end of the 525 directory, the server will set a last_entry flag to true. If 526 the file is added such that there is atleast one entry before 527 it, the server will also return the previous entry 528 information along with its cookie. This is to help clients 529 find the right location in their DNLC or directory caches 530 where this entry should be cached. 532 o REMOVING A FILE: The server will send information about the 533 directory entry being deleted. The server will also send the 534 cookie value for the deleted entry so that clients can get to 535 the cached information for this entry. 537 o RENAMING A FILE: The server will send information about both 538 the old entry and the new entry. This includes name and 539 attributes for each entry. This notification is only sent if 540 both entries are in the same directory. If the rename is 541 across directories, the server will send a remove 542 notification to one directory and an add notification to the 543 other directory, assuming both have a directory delegation. 545 o FILE/DIR ATTRIBUTE CHANGE: The client will use the attribute 546 mask to inform the server of attributes for which it wants to 547 receive notifications. This change notification can be 548 requested for both changes to the attributes of the directory 549 as well as changes to any file attributes in the directory by 550 using two separate attribute masks. The client can not ask 551 for change attribute notification per file. One attribute 552 mask covers all the files in the directory. Upon any 553 attribute change, the server will send back the values of 554 changed attributes. Notifications might not make sense for 555 some filesystem wide attributes and it is up to the server to 556 decide which subset it wants to support. The client can 557 negotiate the frequency of attribute notifications by letting 558 the server know how often it wants to be notified of an 559 attribute change. The server will return supported 560 notification frequencies or an indication that no 561 notification is permitted for directory or child attributes 562 by setting the supp_dir_attr_notice and 563 supp_child_attr_notice attributes respectively. 565 o COOKIE VERIFIER CHANGE: If the cookie verifier changes while 566 a client is holding a delegation, the server will notify the 567 client so that it can invalidate its cookies and reissue a 568 READDIR to get the new set of cookies. 570 ERRORS 571 NFS4ERR_BAD_STATEID 572 NFS4ERR_INVAL 573 NFS4ERR_BADXDR 574 NFS4ERR_SERVERFAULT 576 7. Delegation Recall 578 The server will recall the directory delegation by sending a callback 579 to the client. It will use the same callback procedure as used for 580 recalling file delegations. The server will recall the delegation 581 when the directory changes in a way that is not covered by the 582 notification. However the server will not recall the delegation if 583 attributes of an entry within the directory change. Also if the 584 server notices that handing out a delegation for a directory is 585 causing too many notifications to be sent out, it may decide not to 586 hand out a delegation for that directory. If another client tries to 587 remove the directory for which a delegation has been granted, the 588 server will recall the delegation. 590 The server will recall the delegation by sending a CB_RECALL callback 591 to the client. If the recall is done because of a directory changing 592 event, the request making that change will need to wait while the 593 client returns the delegation. 595 8. New Callback Operation: CB_RECALL_ANY - Keep any N delegations 597 SYNOPSIS 598 N -> {} 600 ARGUMENT 601 struct CB_RECALLANYY4args { 602 uint4 dlgs_to_keep; 603 } 605 RESULT 606 struct CB_RECALLANY4res { 607 nfsstat4 status; 608 }; 610 DESCRIPTION: 611 The server may decide that it can not hold all the delegation 612 state without running out of resources. Since the server has no 613 knowledge of which delegations are being used more than others, 614 it can not implement an effective reclaim scheme that avoids 615 reclaiming frequently used delegations. In that case the server 616 may issue a CB_RECALL_ANY callback to the client asking it to 617 keep N delegations and return the rest. The reason why 618 CB_RECALL_ANY specifies a count of delegations the client may 619 keep as opposed to a count of delegations the client must yield 620 is as follows. Were it otherwise, there is a potential for a 621 race between a CB_RECALL_ANY that had a count of delegations to 622 free with a set of client originated operations to return 623 delegations. As a result of the race the client and server would 624 have differing ideas as to how many delegations to return. Hence 625 the client could mistakenly free too many delegations. This 626 operation applies to delegations for a regular file (read or 627 write) as well as for a directory. 629 The client can choose to return any type of delegation as a 630 result of this callback i.e. read, write or directory 631 delegation. The client can also choose to keep more delegations 632 than what the server asked for and it is up to the server to 633 handle this situation. The server must give the client enough 634 time to return the delegations. This time should not be less 635 than the lease period. 637 ERRORS 638 NFS4ERR_RESOURCE 640 9. Delegation Recovery 642 Crash recovery has two main goals, avoiding the necessity of breaking 643 application guarantees with respect to locked files and delivery of 644 updates cached at the client. Neither of these applies to 645 directories protected by read delegations and notifications. Thus, 646 the client is required to establish a new delegation on a server or 647 client reboot. 649 10. Issues 651 10.1. Synchronous vs. Asynchronous notifications 653 Asynchronous notifications are defined as a way of updating namespace 654 information for directories. For example, for directories that are 655 very large or changing very slowly, the recall and subsequent 656 reacquiring of state may be too expensive. In that case if used 657 properly notifications can reduce the overhead of recalling 658 delegations and re-fetching directory contents with a reduction in 659 network traffic. 661 For achieving namespace cache consistency with lower network traffic, 662 delegations along with synchronous callbacks are sufficient. Adding 663 synchronous notifications on top of that does not provide much 664 additional benefits. 666 11. RPC Definition File Changes 668 /* 669 * Copyright (C) The Internet Society (2003) 670 * All Rights Reserved. 671 */ 673 /* 674 * nfs41_prot.x 675 */ 677 %/* $Id: nfs41_prot.x,v 1.1 2004/02/01 05:10:53 saadia Exp $ */ 679 /* new operation, GET_DIR_DELEGATION */ 681 /* 682 * Notification mask for letting the server know which notifications 683 * the client is interested in. 684 */ 685 typedef uint32_t dir_notification_type4; 687 /* 688 * The bitmask constants used for notification_type field 689 */ 690 const DIR_NOTIFICATION_NONE = 0x00000000; 691 const DIR_NOTIFICATION_CHANGE_CHILD_ATTRIBUTES = 0x00000001; 692 const DIR_NOTIFICATION_CHANGE_DIR_ATTRIBUTES = 0x00000002; 693 const DIR_NOTIFICATION_REMOVE_ENTRY = 0x00000004; 694 const DIR_NOTIFICATION_ADD_ENTRY = 0x00000008; 695 const DIR_NOTIFICATION_RENAME_ENTRY = 0x00000010; 696 const DIR_NOTIFICATION_CHANGE_COOKIE_VERIFIER = 0x00000020; 698 typedef nfstime4 attr_notice4; 700 /* 701 * Input arguments passed to the GET_DIR_DELEGATION operation. 702 */ 703 struct GET_DIR_DELEGATION4args { 704 /* CURRENT_FH: directory */ 705 dir_notification_type4 notification_type; 706 attr_notice4 child_attr_delay; 707 attr_notice4 dir_attr_delay; 708 }; 710 /* 711 * Result flags 712 */ 714 struct GET_DIR_DELEGATION4resok { 715 verifier4 cookieverf; 716 /* Stateid for get_dir_delegation */ 717 stateid4 stateid; 718 /* Which notifications can the server support */ 719 dir_notification_type4 supp_notification; 720 /* Which attribute notifications can the server support */ 721 bitmap4 child_attributes; 722 bitmap4 dir_attributes; 723 }; 724 union GET_DIR_DELEGATION4res switch (nfsstat4 status) { 725 case NFS4_OK: 726 /* CURRENT_FH: delegated dir */ 727 GET_DIR_DELEGATION4resok resok4; 728 default: 729 void; 730 }; 732 /* 733 * Operation arrays 734 */ 736 enum nfs_opnum4 { 737 OP_ACCESS = 3, 738 OP_CLOSE = 4, 739 OP_COMMIT = 5, 740 OP_CREATE = 6, 741 OP_DELEGPURGE = 7, 742 OP_DELEGRETURN = 8, 743 OP_GETATTR = 9, 744 OP_GETFH = 10, 745 OP_LINK = 11, 746 OP_LOCK = 12, 747 OP_LOCKT = 13, 748 OP_LOCKU = 14, 749 OP_LOOKUP = 15, 750 OP_LOOKUPP = 16, 751 OP_NVERIFY = 17, 752 OP_OPEN = 18, 753 OP_OPENATTR = 19, 754 OP_OPEN_CONFIRM = 20, 755 OP_OPEN_DOWNGRADE = 21, 756 OP_PUTFH = 22, 757 OP_PUTPUBFH = 23, 758 OP_PUTROOTFH = 24, 759 OP_READ = 25, 760 OP_READDIR = 26, 761 OP_READLINK = 27, 762 OP_REMOVE = 28, 763 OP_RENAME = 29, 764 OP_RENEW = 30, 765 OP_RESTOREFH = 31, 766 OP_SAVEFH = 32, 767 OP_SECINFO = 33, 768 OP_SETATTR = 34, 769 OP_SETCLIENTID = 35, 770 OP_SETCLIENTID_CONFIRM = 36, 771 OP_VERIFY = 37, 772 OP_WRITE = 38, 773 OP_RELEASE_LOCKOWNER = 39, 774 OP_OPENDIR = 40, 775 OP_ILLEGAL = 10044 776 }; 778 union nfs_argop4 switch (nfs_opnum4 argop) { 779 case OP_ACCESS: ACCESS4args opaccess; 780 case OP_CLOSE: CLOSE4args opclose; 781 case OP_COMMIT: COMMIT4args opcommit; 782 case OP_CREATE: CREATE4args opcreate; 783 case OP_DELEGPURGE: DELEGPURGE4args opdelegpurge; 784 case OP_DELEGRETURN: DELEGRETURN4args opdelegreturn; 785 case OP_GETATTR: GETATTR4args opgetattr; 786 case OP_GETFH: void; 787 case OP_LINK: LINK4args oplink; 788 case OP_LOCK: LOCK4args oplock; 789 case OP_LOCKT: LOCKT4args oplockt; 790 case OP_LOCKU: LOCKU4args oplocku; 791 case OP_LOOKUP: LOOKUP4args oplookup; 792 case OP_LOOKUPP: void; 793 case OP_NVERIFY: NVERIFY4args opnverify; 794 case OP_OPEN: OPEN4args opopen; 795 case OP_OPENATTR: OPENATTR4args opopenattr; 796 case OP_OPEN_CONFIRM: OPEN_CONFIRM4args opopen_confirm; 797 case OP_OPEN_DOWNGRADE: OPEN_DOWNGRADE4args opopen_downgrade; 798 case OP_PUTFH: PUTFH4args opputfh; 799 case OP_PUTPUBFH: void; 800 case OP_PUTROOTFH: void; 801 case OP_READ: READ4args opread; 802 case OP_READDIR: READDIR4args opreaddir; 803 case OP_READLINK: void; 804 case OP_REMOVE: REMOVE4args opremove; 805 case OP_RENAME: RENAME4args oprename; 806 case OP_RENEW: RENEW4args oprenew; 807 case OP_RESTOREFH: void; 808 case OP_SAVEFH: void; 809 case OP_SECINFO: SECINFO4args opsecinfo; 810 case OP_SETATTR: SETATTR4args opsetattr; 811 case OP_SETCLIENTID: SETCLIENTID4args opsetclientid; 812 case OP_SETCLIENTID_CONFIRM: SETCLIENTID_CONFIRM4args 813 opsetclientid_confirm; 814 case OP_VERIFY: VERIFY4args opverify; 815 case OP_WRITE: WRITE4args opwrite; 816 case OP_RELEASE_LOCKOWNER: RELEASE_LOCKOWNER4args 817 oprelease_lockowner; 818 case OP_OPENDIR: OPENDIR4args opopendir; 819 case OP_ILLEGAL: void; 820 }; 821 union nfs_resop4 switch (nfs_opnum4 resop){ 822 case OP_ACCESS: ACCESS4res opaccess; 823 case OP_CLOSE: CLOSE4res opclose; 824 case OP_COMMIT: COMMIT4res opcommit; 825 case OP_CREATE: CREATE4res opcreate; 826 case OP_DELEGPURGE: DELEGPURGE4res opdelegpurge; 827 case OP_DELEGRETURN: DELEGRETURN4res opdelegreturn; 828 case OP_GETATTR: GETATTR4res opgetattr; 829 case OP_GETFH: GETFH4res opgetfh; 830 case OP_LINK: LINK4res oplink; 831 case OP_LOCK: LOCK4res oplock; 832 case OP_LOCKT: LOCKT4res oplockt; 833 case OP_LOCKU: LOCKU4res oplocku; 834 case OP_LOOKUP: LOOKUP4res oplookup; 835 case OP_LOOKUPP: LOOKUPP4res oplookupp; 836 case OP_NVERIFY: NVERIFY4res opnverify; 837 case OP_OPEN: OPEN4res opopen; 838 case OP_OPENATTR: OPENATTR4res opopenattr; 839 case OP_OPEN_CONFIRM: OPEN_CONFIRM4res opopen_confirm; 840 case OP_OPEN_DOWNGRADE: OPEN_DOWNGRADE4res opopen_downgrade; 841 case OP_PUTFH: PUTFH4res opputfh; 842 case OP_PUTPUBFH: PUTPUBFH4res opputpubfh; 843 case OP_PUTROOTFH: PUTROOTFH4res opputrootfh; 844 case OP_READ: READ4res opread; 845 case OP_READDIR: READDIR4res opreaddir; 846 case OP_READLINK: READLINK4res opreadlink; 847 case OP_REMOVE: REMOVE4res opremove; 848 case OP_RENAME: RENAME4res oprename; 849 case OP_RENEW: RENEW4res oprenew; 850 case OP_RESTOREFH: RESTOREFH4res oprestorefh; 851 case OP_SAVEFH: SAVEFH4res opsavefh; 852 case OP_SECINFO: SECINFO4res opsecinfo; 853 case OP_SETATTR: SETATTR4res opsetattr; 854 case OP_SETCLIENTID: SETCLIENTID4res opsetclientid; 855 case OP_SETCLIENTID_CONFIRM: SETCLIENTID_CONFIRM4res 856 opsetclientid_confirm; 857 case OP_VERIFY: VERIFY4res opverify; 858 case OP_WRITE: WRITE4res opwrite; 859 case OP_RELEASE_LOCKOWNER: RELEASE_LOCKOWNER4res 860 oprelease_lockowner; 861 case OP_OPENDIR: OPENDIR4res opopendir; 862 case OP_ILLEGAL: ILLEGAL4res opillegal; 863 }; 865 struct COMPOUND4args { 866 utf8str_cs tag; 867 uint32_t minorversion; /* == 1 !!! */ 868 nfs_argop4 argarray<>; 869 }; 870 struct COMPOUND4res { 871 nfsstat4 status; 872 utf8str_cs tag; 873 nfs_resop4 resarray<>; 874 }; 876 /* 877 * New error codes 878 */ 880 enum nfsstat4 { 881 NFS4_OK = 0, /* everything is okay */ 882 NFS4ERR_PERM = 1, /* caller not privileged */ 883 NFS4ERR_NOENT = 2, /* no such file/directory */ 884 NFS4ERR_IO = 5, /* hard I/O error */ 885 NFS4ERR_NXIO = 6, /* no such device */ 886 NFS4ERR_ACCESS = 13, /* access denied */ 887 NFS4ERR_EXIST = 17, /* file already exists */ 888 NFS4ERR_XDEV = 18, /* different filesystems */ 889 /* Unused/reserved 19 */ 890 NFS4ERR_NOTDIR = 20, /* should be a directory */ 891 NFS4ERR_ISDIR = 21, /* should not be directory */ 892 NFS4ERR_INVAL = 22, /* invalid argument */ 893 NFS4ERR_FBIG = 27, /* file exceeds server max */ 894 NFS4ERR_NOSPC = 28, /* no space on filesystem */ 895 NFS4ERR_ROFS = 30, /* read-only filesystem */ 896 NFS4ERR_MLINK = 31, /* too many hard links */ 897 NFS4ERR_NAMETOOLONG = 63, /* name exceeds server max */ 898 NFS4ERR_NOTEMPTY = 66, /* directory not empty */ 899 NFS4ERR_DQUOT = 69, /* hard quota limit reached*/ 900 NFS4ERR_STALE = 70, /* file no longer exists */ 901 NFS4ERR_BADHANDLE = 10001,/* Illegal filehandle */ 902 NFS4ERR_BAD_COOKIE = 10003,/* READDIR cookie is stale */ 903 NFS4ERR_NOTSUPP = 10004,/* operation not supported */ 904 NFS4ERR_TOOSMALL = 10005,/* response limit exceeded */ 905 NFS4ERR_SERVERFAULT = 10006,/* undefined server error */ 906 NFS4ERR_BADTYPE = 10007,/* type invalid for CREATE */ 907 NFS4ERR_DELAY = 10008,/* file "busy" - retry */ 908 NFS4ERR_SAME = 10009,/* nverify says attrs same */ 909 NFS4ERR_DENIED = 10010,/* lock unavailable */ 910 NFS4ERR_EXPIRED = 10011,/* lock lease expired */ 911 NFS4ERR_LOCKED = 10012,/* I/O failed due to lock */ 912 NFS4ERR_GRACE = 10013,/* in grace period */ 913 NFS4ERR_FHEXPIRED = 10014,/* filehandle expired */ 914 NFS4ERR_SHARE_DENIED = 10015,/* share reserve denied */ 915 NFS4ERR_WRONGSEC = 10016,/* wrong security flavor */ 916 NFS4ERR_CLID_INUSE = 10017,/* clientid in use */ 917 NFS4ERR_RESOURCE = 10018,/* resource exhaustion */ 918 NFS4ERR_MOVED = 10019,/* filesystem relocated */ 919 NFS4ERR_NOFILEHANDLE = 10020,/* current FH is not set */ 920 NFS4ERR_MINOR_VERS_MISMATCH = 10021,/* minor vers not supp */ 921 NFS4ERR_STALE_CLIENTID = 10022,/* server has rebooted */ 922 NFS4ERR_STALE_STATEID = 10023,/* server has rebooted */ 923 NFS4ERR_OLD_STATEID = 10024,/* state is out of sync */ 924 NFS4ERR_BAD_STATEID = 10025,/* incorrect stateid */ 925 NFS4ERR_BAD_SEQID = 10026,/* request is out of seq. */ 926 NFS4ERR_NOT_SAME = 10027,/* verify - attrs not same */ 927 NFS4ERR_LOCK_RANGE = 10028,/* lock range not supported*/ 928 NFS4ERR_SYMLINK = 10029,/* should be file/directory*/ 929 NFS4ERR_RESTOREFH = 10030,/* no saved filehandle */ 930 NFS4ERR_LEASE_MOVED = 10031,/* some filesystem moved */ 931 NFS4ERR_ATTRNOTSUPP = 10032,/* recommended attr not sup*/ 932 NFS4ERR_NO_GRACE = 10033,/* reclaim outside of grace*/ 933 NFS4ERR_RECLAIM_BAD = 10034,/* reclaim error at server */ 934 NFS4ERR_RECLAIM_CONFLICT = 10035,/* conflict on reclaim */ 935 NFS4ERR_BADXDR = 10036,/* XDR decode failed */ 936 NFS4ERR_LOCKS_HELD = 10037,/* file locks held at CLOSE*/ 937 NFS4ERR_OPENMODE = 10038,/* conflict in OPEN and I/O*/ 938 NFS4ERR_BADOWNER = 10039,/* owner translation bad */ 939 NFS4ERR_BADCHAR = 10040,/* utf-8 char not supported*/ 940 NFS4ERR_BADNAME = 10041,/* name not supported */ 941 NFS4ERR_BAD_RANGE = 10042,/* lock range not supported*/ 942 NFS4ERR_LOCK_NOTSUPP = 10043,/* no atomic up/downgrade */ 943 NFS4ERR_OP_ILLEGAL = 10044,/* undefined operation */ 944 NFS4ERR_DEADLOCK = 10045,/* file locking deadlock */ 945 NFS4ERR_FILE_OPEN = 10046,/* open file blocks op. */ 946 NFS4ERR_ADMIN_REVOKED = 10047,/* lockowner state revoked */ 947 NFS4ERR_CB_PATH_DOWN = 10048,/* callback path down */ 948 NFS4ERR_DIRDELEG_UNAVAIL= 10049,/* dir dlg. not returned */ 949 }; 951 /* 952 * New Callback operation CB_NOTIFY 953 */ 955 struct CB_NOTIFY4args { 956 stateid4 stateid; 957 dir_notification4 changes<>; 958 }; 960 /* 961 * Changed entry information. 962 */ 963 struct dir_entry { 964 component4 file; 965 fattr4 attrs; 967 }; 969 struct dir_notification_attribute4 { 970 dir_entry changed_entry; 971 }; 973 struct dir_notification_remove4 { 974 dir_entry old_entry; 975 nfs_cookie4 old_entry_cookie; 976 }; 978 struct dir_notification_rename4 { 979 dir_entry old_entry; 980 dir_notification_add4 new_entry; 981 }; 983 struct dir_notification_verifier4 { 984 verifier4 old_cookieverf; 985 verifier4 new_cookieverf; 986 }; 988 struct dir_notification_add4 { 989 dir_entry new_entry; 990 nfs_cookie4 new_entry_cookie; /* what READDIR would 991 have returned 992 for this entry */ 993 bool last_entry; 994 prev_entry_info4 prev_info; 995 }; 997 union prev_entry_info4 switch (bool isprev) { 998 case TRUE: 999 prev_entry4 prev_entry_info; 1000 case FALSE: /* we are adding to an empty directory */ 1001 void; 1002 }; 1004 /* 1005 * Previous entry information 1006 */ 1007 struct prev_entry4 { 1008 dir_entry prev_entry; 1009 /* what READDIR returned for this entry */ 1010 nfs_cookie4 prev_entry_cookie; 1011 }; 1013 /* 1014 * Notification information sent to the client. 1015 */ 1017 union dir_notification4 1018 switch (dir_notification_type4 notification_type) { 1019 case DIR_NOTIFICATION_CHANGE_CHILD_ATTRIBUTES: 1020 dir_notification_attribute4 change_child_attributes; 1021 case DIR_NOTIFICATION_CHANGE_DIR_ATTRIBUTES: 1022 fattr4 change_dir_attributes; 1023 case DIR_NOTIFICATION_REMOVE_ENTRY: 1024 dir_notification_remove4 remove_notification; 1025 case DIR_NOTIFICATION_ADD_ENTRY: 1026 dir_notification_add4 add_notification; 1027 case DIR_NOTIFICATION_RENAME_ENTRY: 1028 dir_notification_rename4 rename_notification; 1029 case DIR_NOTIFICATION_CHANGE_COOKIE_VERIFIER: 1030 dir_notification_verifier4 verf_notification; 1031 }; 1033 struct CB_NOTIFY4res { 1034 nfsstat4 status; 1035 }; 1037 /* 1038 * New Callback operation CB_RECALL_ANY 1039 * 1041 struct CB_RECALLANYY4args { 1042 uint4 dlgs_to_keep; 1043 } 1045 struct CB_RECALLANY4res { 1046 nfsstat4 status; 1047 }; 1049 /* 1050 * Various definitions for CB_COMPOUND 1051 */ 1052 enum nfs_cb_opnum4 { 1053 OP_CB_GETATTR = 3, 1054 OP_CB_RECALL = 4, 1055 OP_CB_NOTIFY = 5, 1056 OP_CB_RECALL_ANY = 6, 1057 OP_CB_ILLEGAL = 10044 1058 }; 1060 union nfs_cb_argop4 switch (unsigned argop) { 1061 case OP_CB_GETATTR: CB_GETATTR4args opcbgetattr; 1062 case OP_CB_RECALL: CB_RECALL4args opcbrecall; 1063 case OP_CB_NOTIFY: CB_NOTIFY4args opcbnotify; 1064 case OP_CB_RECALLANY: CB_RECALLANY4args opcbrecallany; 1065 case OP_CB_ILLEGAL: CB_ILLEGAL4args opcbillegal; 1066 }; 1068 union nfs_cb_resop4 switch (unsigned resop) { 1069 case OP_CB_GETATTR: CB_GETATTR4res opcbgetattr; 1070 case OP_CB_RECALL: CB_RECALL4res opcbrecall; 1071 case OP_CB_NOTIFY: CB_NOTIFY4res opcbnotify; 1072 case OP_CB_RECALLANY: CB_RECALLANY4res opcbrecallany; 1073 case OP_CB_ILLEGAL: CB_ILLEGAL4res opcbillegal; 1074 }; 1076 struct CB_COMPOUND4args { 1077 utf8str_cs tag; 1078 uint32_t minorversion; 1079 uint32_t callback_ident; 1080 nfs_cb_argop4 argarray<>; 1081 }; 1083 struct CB_COMPOUND4res { 1084 nfsstat4 status; 1085 utf8str_cs tag; 1086 nfs_cb_resop4 resarray<>; 1087 }; 1089 12. IANA Considerations 1091 The IANA considerations of NFSv4.0 apply to NFSv4.1. 1093 13. Acknowledgements 1095 David Noveck, Michael Eisler, Carl Burnett, Ted Anderson and Thomas 1096 Talpey for their constructive feedback and critical comments. 1098 14. Normative References 1100 [RFC3530] 1101 S. Shepler, B. Callaghan, D. Robinson, R. Thurlow, C. Beame, M. 1102 Eisler, D. Noveck, "NFS version 4 Protocol", RFC 3530, April, 1103 2003. 1105 [talpey] 1106 T. Talpey, S. Shepler, J. Bauman "NFSv4 Session Extensions", 1107 Internet-Draft, July, 2004. A URL for this Internet-Draft is 1108 available at http://www.ietf.org/internet-drafts/draft-ietf- 1109 nfsv4-sess-00.txt 1111 15. Informative References 1113 None. 1115 16. Author's Address 1117 Saadia Khan 1118 2324 Dubois Street 1119 Milpitas, CA 95035 1120 USA 1122 Phone: 408-957-9626 1123 EMail: saadiak@yahoo.com 1125 17. IPR Notices 1127 The IETF takes no position regarding the validity or scope of any 1128 intellectual property or other rights that might be claimed to 1129 pertain to the implementation or use of the technology described in 1130 this document or the extent to which any license under such rights 1131 might or might not be available; neither does it represent that it 1132 has made any effort to identify any such rights. Information on the 1133 IETF's procedures with respect to rights in standards-track and 1134 standards-related documentation can be found in BCP-11. Copies of 1135 claims of rights made available for publication and any assurances of 1136 licenses to be made available, or the result of an attempt made to 1137 obtain a general license or permission for the use of such 1138 proprietary rights by implementors or users of this specification can 1139 be obtained from the IETF Secretariat. 1141 The IETF invites any interested party to bring to its attention any 1142 copyrights, patents or patent applications, or other proprietary 1143 rights which may cover technology that may be required to practice 1144 this standard. Please address the information to the IETF Executive 1145 Director. 1147 18. Copyright Notice 1149 Copyright (C) The Internet Society (2005). This document is subject 1150 to the rights, licenses and restrictions contained in BCP 78, and 1151 except as set forth therein, the authors retain all their rights. 1153 This document and the information contained herein are provided on an 1154 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1155 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1156 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1157 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1158 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1159 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.