draft-ietf-nfsv4-rfc5661sesqui-msns-01.txt   draft-ietf-nfsv4-rfc5661sesqui-msns-02.txt 
NFSv4 D. Noveck, Ed. NFSv4 D. Noveck, Ed.
Internet-Draft NetApp Internet-Draft NetApp
Obsoletes: 5661 (if approved) C. Lever Obsoletes: 5661 (if approved) C. Lever
Intended status: Standards Track ORACLE Intended status: Standards Track ORACLE
Expires: February 5, 2020 August 4, 2019 Expires: April 5, 2020 October 3, 2019
Network File System (NFS) Version 4 Minor Version 1 Protocol Network File System (NFS) Version 4 Minor Version 1 Protocol
draft-ietf-nfsv4-rfc5661sesqui-msns-01 draft-ietf-nfsv4-rfc5661sesqui-msns-02
Abstract Abstract
This document describes the Network File System (NFS) version 4 minor This document describes the Network File System (NFS) version 4 minor
version 1, including features retained from the base protocol (NFS version 1, including features retained from the base protocol (NFS
version 4 minor version 0, which is specified in RFC 7530) and version 4 minor version 0, which is specified in RFC 7530) and
protocol extensions made subsequently. The later minor version has protocol extensions made subsequently. The later minor version has
no dependencies on NFS version 4 minor version 0, and is considered a no dependencies on NFS version 4 minor version 0, and is considered a
separate protocol. separate protocol.
skipping to change at page 1, line 40 skipping to change at page 1, line 40
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 5, 2020. This Internet-Draft will expire on April 5, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 27 skipping to change at page 2, line 27
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7
1.1. Introduction to this Update . . . . . . . . . . . . . . . 7 1.1. Introduction to this Update . . . . . . . . . . . . . . . 7
1.2. The NFS Version 4 Minor Version 1 Protocol . . . . . . . 8 1.2. The NFS Version 4 Minor Version 1 Protocol . . . . . . . 9
1.3. Requirements Language . . . . . . . . . . . . . . . . . . 9 1.3. Requirements Language . . . . . . . . . . . . . . . . . . 9
1.4. Scope of This Document . . . . . . . . . . . . . . . . . 9 1.4. Scope of This Document . . . . . . . . . . . . . . . . . 9
1.5. NFSv4 Goals . . . . . . . . . . . . . . . . . . . . . . . 9 1.5. NFSv4 Goals . . . . . . . . . . . . . . . . . . . . . . . 10
1.6. NFSv4.1 Goals . . . . . . . . . . . . . . . . . . . . . . 10 1.6. NFSv4.1 Goals . . . . . . . . . . . . . . . . . . . . . . 10
1.7. General Definitions . . . . . . . . . . . . . . . . . . . 10 1.7. General Definitions . . . . . . . . . . . . . . . . . . . 11
1.8. Overview of NFSv4.1 Features . . . . . . . . . . . . . . 13 1.8. Overview of NFSv4.1 Features . . . . . . . . . . . . . . 13
1.9. Differences from NFSv4.0 . . . . . . . . . . . . . . . . 17 1.9. Differences from NFSv4.0 . . . . . . . . . . . . . . . . 17
2. Core Infrastructure . . . . . . . . . . . . . . . . . . . . . 18 2. Core Infrastructure . . . . . . . . . . . . . . . . . . . . . 19
2.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 18 2.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 19
2.2. RPC and XDR . . . . . . . . . . . . . . . . . . . . . . . 18 2.2. RPC and XDR . . . . . . . . . . . . . . . . . . . . . . . 19
2.3. COMPOUND and CB_COMPOUND . . . . . . . . . . . . . . . . 22 2.3. COMPOUND and CB_COMPOUND . . . . . . . . . . . . . . . . 22
2.4. Client Identifiers and Client Owners . . . . . . . . . . 22 2.4. Client Identifiers and Client Owners . . . . . . . . . . 23
2.5. Server Owners . . . . . . . . . . . . . . . . . . . . . . 28 2.5. Server Owners . . . . . . . . . . . . . . . . . . . . . . 28
2.6. Security Service Negotiation . . . . . . . . . . . . . . 29 2.6. Security Service Negotiation . . . . . . . . . . . . . . 29
2.7. Minor Versioning . . . . . . . . . . . . . . . . . . . . 34 2.7. Minor Versioning . . . . . . . . . . . . . . . . . . . . 34
2.8. Non-RPC-Based Security Services . . . . . . . . . . . . . 36 2.8. Non-RPC-Based Security Services . . . . . . . . . . . . . 37
2.9. Transport Layers . . . . . . . . . . . . . . . . . . . . 37 2.9. Transport Layers . . . . . . . . . . . . . . . . . . . . 38
2.10. Session . . . . . . . . . . . . . . . . . . . . . . . . . 40 2.10. Session . . . . . . . . . . . . . . . . . . . . . . . . . 40
3. Protocol Constants and Data Types . . . . . . . . . . . . . . 86 3. Protocol Constants and Data Types . . . . . . . . . . . . . . 86
3.1. Basic Constants . . . . . . . . . . . . . . . . . . . . . 86 3.1. Basic Constants . . . . . . . . . . . . . . . . . . . . . 87
3.2. Basic Data Types . . . . . . . . . . . . . . . . . . . . 87 3.2. Basic Data Types . . . . . . . . . . . . . . . . . . . . 87
3.3. Structured Data Types . . . . . . . . . . . . . . . . . . 89 3.3. Structured Data Types . . . . . . . . . . . . . . . . . . 89
4. Filehandles . . . . . . . . . . . . . . . . . . . . . . . . . 97 4. Filehandles . . . . . . . . . . . . . . . . . . . . . . . . . 98
4.1. Obtaining the First Filehandle . . . . . . . . . . . . . 98 4.1. Obtaining the First Filehandle . . . . . . . . . . . . . 98
4.2. Filehandle Types . . . . . . . . . . . . . . . . . . . . 99 4.2. Filehandle Types . . . . . . . . . . . . . . . . . . . . 99
4.3. One Method of Constructing a Volatile Filehandle . . . . 101 4.3. One Method of Constructing a Volatile Filehandle . . . . 102
4.4. Client Recovery from Filehandle Expiration . . . . . . . 102 4.4. Client Recovery from Filehandle Expiration . . . . . . . 102
5. File Attributes . . . . . . . . . . . . . . . . . . . . . . . 103 5. File Attributes . . . . . . . . . . . . . . . . . . . . . . . 103
5.1. REQUIRED Attributes . . . . . . . . . . . . . . . . . . . 104 5.1. REQUIRED Attributes . . . . . . . . . . . . . . . . . . . 104
5.2. RECOMMENDED Attributes . . . . . . . . . . . . . . . . . 104 5.2. RECOMMENDED Attributes . . . . . . . . . . . . . . . . . 104
5.3. Named Attributes . . . . . . . . . . . . . . . . . . . . 105 5.3. Named Attributes . . . . . . . . . . . . . . . . . . . . 105
5.4. Classification of Attributes . . . . . . . . . . . . . . 106 5.4. Classification of Attributes . . . . . . . . . . . . . . 106
5.5. Set-Only and Get-Only Attributes . . . . . . . . . . . . 107 5.5. Set-Only and Get-Only Attributes . . . . . . . . . . . . 107
5.6. REQUIRED Attributes - List and Definition References . . 107 5.6. REQUIRED Attributes - List and Definition References . . 107
5.7. RECOMMENDED Attributes - List and Definition References . 108 5.7. RECOMMENDED Attributes - List and Definition References . 108
5.8. Attribute Definitions . . . . . . . . . . . . . . 110 5.8. Attribute Definitions . . . . . . . . . . . . . . 110
skipping to change at page 4, line 36 skipping to change at page 4, line 36
11.7. Additional Client-Side Considerations . . . . . . . . . 243 11.7. Additional Client-Side Considerations . . . . . . . . . 243
11.8. Overview of File Access Transitions . . . . . . . . . . 244 11.8. Overview of File Access Transitions . . . . . . . . . . 244
11.9. Effecting Network Endpoint Transitions . . . . . . . . . 244 11.9. Effecting Network Endpoint Transitions . . . . . . . . . 244
11.10. Effecting File System Transitions . . . . . . . . . . . 245 11.10. Effecting File System Transitions . . . . . . . . . . . 245
11.11. Transferring State upon Migration . . . . . . . . . . . 253 11.11. Transferring State upon Migration . . . . . . . . . . . 253
11.12. Client Responsibilities when Access is Transitioned . . 255 11.12. Client Responsibilities when Access is Transitioned . . 255
11.13. Server Responsibilities Upon Migration . . . . . . . . . 264 11.13. Server Responsibilities Upon Migration . . . . . . . . . 264
11.14. Effecting File System Referrals . . . . . . . . . . . . 270 11.14. Effecting File System Referrals . . . . . . . . . . . . 270
11.15. The Attribute fs_locations . . . . . . . . . . . . . . . 277 11.15. The Attribute fs_locations . . . . . . . . . . . . . . . 277
11.16. The Attribute fs_locations_info . . . . . . . . . . . . 280 11.16. The Attribute fs_locations_info . . . . . . . . . . . . 280
11.17. The Attribute fs_status . . . . . . . . . . . . . . . . 293 11.17. The Attribute fs_status . . . . . . . . . . . . . . . . 294
12. Parallel NFS (pNFS) . . . . . . . . . . . . . . . . . . . . . 297 12. Parallel NFS (pNFS) . . . . . . . . . . . . . . . . . . . . . 297
12.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 297 12.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 297
12.2. pNFS Definitions . . . . . . . . . . . . . . . . . . . . 298 12.2. pNFS Definitions . . . . . . . . . . . . . . . . . . . . 299
12.3. pNFS Operations . . . . . . . . . . . . . . . . . . . . 304 12.3. pNFS Operations . . . . . . . . . . . . . . . . . . . . 304
12.4. pNFS Attributes . . . . . . . . . . . . . . . . . . . . 305 12.4. pNFS Attributes . . . . . . . . . . . . . . . . . . . . 305
12.5. Layout Semantics . . . . . . . . . . . . . . . . . . . . 305 12.5. Layout Semantics . . . . . . . . . . . . . . . . . . . . 305
12.6. pNFS Mechanics . . . . . . . . . . . . . . . . . . . . . 320 12.6. pNFS Mechanics . . . . . . . . . . . . . . . . . . . . . 320
12.7. Recovery . . . . . . . . . . . . . . . . . . . . . . . . 322 12.7. Recovery . . . . . . . . . . . . . . . . . . . . . . . . 322
12.8. Metadata and Storage Device Roles . . . . . . . . . . . 327 12.8. Metadata and Storage Device Roles . . . . . . . . . . . 327
12.9. Security Considerations for pNFS . . . . . . . . . . . . 327 12.9. Security Considerations for pNFS . . . . . . . . . . . . 327
13. NFSv4.1 as a Storage Protocol in pNFS: the File Layout Type . 329 13. NFSv4.1 as a Storage Protocol in pNFS: the File Layout Type . 329
13.1. Client ID and Session Considerations . . . . . . . . . . 329 13.1. Client ID and Session Considerations . . . . . . . . . . 329
13.2. File Layout Definitions . . . . . . . . . . . . . . . . 332 13.2. File Layout Definitions . . . . . . . . . . . . . . . . 332
skipping to change at page 5, line 20 skipping to change at page 5, line 20
13.11. Layout Revocation and Fencing . . . . . . . . . . . . . 352 13.11. Layout Revocation and Fencing . . . . . . . . . . . . . 352
13.12. Security Considerations for the File Layout Type . . . . 353 13.12. Security Considerations for the File Layout Type . . . . 353
14. Internationalization . . . . . . . . . . . . . . . . . . . . 354 14. Internationalization . . . . . . . . . . . . . . . . . . . . 354
14.1. Stringprep Profile for the utf8str_cs Type . . . . . . . 355 14.1. Stringprep Profile for the utf8str_cs Type . . . . . . . 355
14.2. Stringprep Profile for the utf8str_cis Type . . . . . . 357 14.2. Stringprep Profile for the utf8str_cis Type . . . . . . 357
14.3. Stringprep Profile for the utf8str_mixed Type . . . . . 358 14.3. Stringprep Profile for the utf8str_mixed Type . . . . . 358
14.4. UTF-8 Capabilities . . . . . . . . . . . . . . . . . . . 360 14.4. UTF-8 Capabilities . . . . . . . . . . . . . . . . . . . 360
14.5. UTF-8 Related Errors . . . . . . . . . . . . . . . . . . 360 14.5. UTF-8 Related Errors . . . . . . . . . . . . . . . . . . 360
15. Error Values . . . . . . . . . . . . . . . . . . . . . . . . 361 15. Error Values . . . . . . . . . . . . . . . . . . . . . . . . 361
15.1. Error Definitions . . . . . . . . . . . . . . . . . . . 361 15.1. Error Definitions . . . . . . . . . . . . . . . . . . . 361
15.2. Operations and Their Valid Errors . . . . . . . . . . . 380 15.2. Operations and Their Valid Errors . . . . . . . . . . . 382
15.3. Callback Operations and Their Valid Errors . . . . . . . 396 15.3. Callback Operations and Their Valid Errors . . . . . . . 398
15.4. Errors and the Operations That Use Them . . . . . . . . 399 15.4. Errors and the Operations That Use Them . . . . . . . . 401
16. NFSv4.1 Procedures . . . . . . . . . . . . . . . . . . . . . 414 16. NFSv4.1 Procedures . . . . . . . . . . . . . . . . . . . . . 415
16.1. Procedure 0: NULL - No Operation . . . . . . . . . . . . 414 16.1. Procedure 0: NULL - No Operation . . . . . . . . . . . . 415
16.2. Procedure 1: COMPOUND - Compound Operations . . . . . . 414 16.2. Procedure 1: COMPOUND - Compound Operations . . . . . . 416
17. Operations: REQUIRED, RECOMMENDED, or OPTIONAL . . . . . . . 426 17. Operations: REQUIRED, RECOMMENDED, or OPTIONAL . . . . . . . 427
18. NFSv4.1 Operations . . . . . . . . . . . . . . . . . . . . . 429 18. NFSv4.1 Operations . . . . . . . . . . . . . . . . . . . . . 430
18.1. Operation 3: ACCESS - Check Access Rights . . . . . . . 429 18.1. Operation 3: ACCESS - Check Access Rights . . . . . . . 430
18.2. Operation 4: CLOSE - Close File . . . . . . . . . . . . 435 18.2. Operation 4: CLOSE - Close File . . . . . . . . . . . . 436
18.3. Operation 5: COMMIT - Commit Cached Data . . . . . . . . 436 18.3. Operation 5: COMMIT - Commit Cached Data . . . . . . . . 437
18.4. Operation 6: CREATE - Create a Non-Regular File Object . 439 18.4. Operation 6: CREATE - Create a Non-Regular File Object . 440
18.5. Operation 7: DELEGPURGE - Purge Delegations Awaiting 18.5. Operation 7: DELEGPURGE - Purge Delegations Awaiting
Recovery . . . . . . . . . . . . . . . . . . . . . . . . 442 Recovery . . . . . . . . . . . . . . . . . . . . . . . . 443
18.6. Operation 8: DELEGRETURN - Return Delegation . . . . . . 443 18.6. Operation 8: DELEGRETURN - Return Delegation . . . . . . 444
18.7. Operation 9: GETATTR - Get Attributes . . . . . . . . . 443 18.7. Operation 9: GETATTR - Get Attributes . . . . . . . . . 444
18.8. Operation 10: GETFH - Get Current Filehandle . . . . . . 445 18.8. Operation 10: GETFH - Get Current Filehandle . . . . . . 446
18.9. Operation 11: LINK - Create Link to a File . . . . . . . 446 18.9. Operation 11: LINK - Create Link to a File . . . . . . . 447
18.10. Operation 12: LOCK - Create Lock . . . . . . . . . . . . 449 18.10. Operation 12: LOCK - Create Lock . . . . . . . . . . . . 450
18.11. Operation 13: LOCKT - Test for Lock . . . . . . . . . . 454 18.11. Operation 13: LOCKT - Test for Lock . . . . . . . . . . 455
18.12. Operation 14: LOCKU - Unlock File . . . . . . . . . . . 455 18.12. Operation 14: LOCKU - Unlock File . . . . . . . . . . . 456
18.13. Operation 15: LOOKUP - Lookup Filename . . . . . . . . . 457 18.13. Operation 15: LOOKUP - Lookup Filename . . . . . . . . . 458
18.14. Operation 16: LOOKUPP - Lookup Parent Directory . . . . 459 18.14. Operation 16: LOOKUPP - Lookup Parent Directory . . . . 460
18.15. Operation 17: NVERIFY - Verify Difference in Attributes 460 18.15. Operation 17: NVERIFY - Verify Difference in Attributes 461
18.16. Operation 18: OPEN - Open a Regular File . . . . . . . . 461 18.16. Operation 18: OPEN - Open a Regular File . . . . . . . . 462
18.17. Operation 19: OPENATTR - Open Named Attribute Directory 481 18.17. Operation 19: OPENATTR - Open Named Attribute Directory 482
18.18. Operation 21: OPEN_DOWNGRADE - Reduce Open File Access . 483 18.18. Operation 21: OPEN_DOWNGRADE - Reduce Open File Access . 484
18.19. Operation 22: PUTFH - Set Current Filehandle . . . . . . 484 18.19. Operation 22: PUTFH - Set Current Filehandle . . . . . . 485
18.20. Operation 23: PUTPUBFH - Set Public Filehandle . . . . 485 18.20. Operation 23: PUTPUBFH - Set Public Filehandle . . . . 486
18.21. Operation 24: PUTROOTFH - Set Root Filehandle . . . . . 487 18.21. Operation 24: PUTROOTFH - Set Root Filehandle . . . . . 488
18.22. Operation 25: READ - Read from File . . . . . . . . . . 488 18.22. Operation 25: READ - Read from File . . . . . . . . . . 489
18.23. Operation 26: READDIR - Read Directory . . . . . . . . . 490 18.23. Operation 26: READDIR - Read Directory . . . . . . . . . 491
18.24. Operation 27: READLINK - Read Symbolic Link . . . . . . 494 18.24. Operation 27: READLINK - Read Symbolic Link . . . . . . 495
18.25. Operation 28: REMOVE - Remove File System Object . . . . 495 18.25. Operation 28: REMOVE - Remove File System Object . . . . 496
18.26. Operation 29: RENAME - Rename Directory Entry . . . . . 498 18.26. Operation 29: RENAME - Rename Directory Entry . . . . . 499
18.27. Operation 31: RESTOREFH - Restore Saved Filehandle . . . 501 18.27. Operation 31: RESTOREFH - Restore Saved Filehandle . . . 502
18.28. Operation 32: SAVEFH - Save Current Filehandle . . . . . 502 18.28. Operation 32: SAVEFH - Save Current Filehandle . . . . . 503
18.29. Operation 33: SECINFO - Obtain Available Security . . . 503 18.29. Operation 33: SECINFO - Obtain Available Security . . . 504
18.30. Operation 34: SETATTR - Set Attributes . . . . . . . . . 507 18.30. Operation 34: SETATTR - Set Attributes . . . . . . . . . 508
18.31. Operation 37: VERIFY - Verify Same Attributes . . . . . 510 18.31. Operation 37: VERIFY - Verify Same Attributes . . . . . 511
18.32. Operation 38: WRITE - Write to File . . . . . . . . . . 511 18.32. Operation 38: WRITE - Write to File . . . . . . . . . . 512
18.33. Operation 40: BACKCHANNEL_CTL - Backchannel Control . . 516 18.33. Operation 40: BACKCHANNEL_CTL - Backchannel Control . . 517
18.34. Operation 41: BIND_CONN_TO_SESSION - Associate 18.34. Operation 41: BIND_CONN_TO_SESSION - Associate
Connection with Session . . . . . . . . . . . . . . . . 517 Connection with Session . . . . . . . . . . . . . . . . 518
18.35. Operation 42: EXCHANGE_ID - Instantiate Client ID . . . 520 18.35. Operation 42: EXCHANGE_ID - Instantiate Client ID . . . 521
18.36. Operation 43: CREATE_SESSION - Create New Session and 18.36. Operation 43: CREATE_SESSION - Create New Session and
Confirm Client ID . . . . . . . . . . . . . . . . . . . 538 Confirm Client ID . . . . . . . . . . . . . . . . . . . 539
18.37. Operation 44: DESTROY_SESSION - Destroy a Session . . . 549 18.37. Operation 44: DESTROY_SESSION - Destroy a Session . . . 550
18.38. Operation 45: FREE_STATEID - Free Stateid with No Locks 550 18.38. Operation 45: FREE_STATEID - Free Stateid with No Locks 551
18.39. Operation 46: GET_DIR_DELEGATION - Get a Directory 18.39. Operation 46: GET_DIR_DELEGATION - Get a Directory
Delegation . . . . . . . . . . . . . . . . . . . . . . . 551 Delegation . . . . . . . . . . . . . . . . . . . . . . . 552
18.40. Operation 47: GETDEVICEINFO - Get Device Information . . 555 18.40. Operation 47: GETDEVICEINFO - Get Device Information . . 556
18.41. Operation 48: GETDEVICELIST - Get All Device Mappings 18.41. Operation 48: GETDEVICELIST - Get All Device Mappings
for a File System . . . . . . . . . . . . . . . . . . . 558 for a File System . . . . . . . . . . . . . . . . . . . 559
18.42. Operation 49: LAYOUTCOMMIT - Commit Writes Made Using a 18.42. Operation 49: LAYOUTCOMMIT - Commit Writes Made Using a
Layout . . . . . . . . . . . . . . . . . . . . . . . . . 560 Layout . . . . . . . . . . . . . . . . . . . . . . . . . 561
18.43. Operation 50: LAYOUTGET - Get Layout Information . . . . 564 18.43. Operation 50: LAYOUTGET - Get Layout Information . . . . 565
18.44. Operation 51: LAYOUTRETURN - Release Layout Information 573 18.44. Operation 51: LAYOUTRETURN - Release Layout Information 574
18.45. Operation 52: SECINFO_NO_NAME - Get Security on Unnamed 18.45. Operation 52: SECINFO_NO_NAME - Get Security on Unnamed
Object . . . . . . . . . . . . . . . . . . . . . . . . . 578 Object . . . . . . . . . . . . . . . . . . . . . . . . . 579
18.46. Operation 53: SEQUENCE - Supply Per-Procedure Sequencing 18.46. Operation 53: SEQUENCE - Supply Per-Procedure Sequencing
and Control . . . . . . . . . . . . . . . . . . . . . . 579 and Control . . . . . . . . . . . . . . . . . . . . . . 580
18.47. Operation 54: SET_SSV - Update SSV for a Client ID . . . 585 18.47. Operation 54: SET_SSV - Update SSV for a Client ID . . . 586
18.48. Operation 55: TEST_STATEID - Test Stateids for Validity 587 18.48. Operation 55: TEST_STATEID - Test Stateids for Validity 588
18.49. Operation 56: WANT_DELEGATION - Request Delegation . . . 589 18.49. Operation 56: WANT_DELEGATION - Request Delegation . . . 590
18.50. Operation 57: DESTROY_CLIENTID - Destroy a Client ID . . 593 18.50. Operation 57: DESTROY_CLIENTID - Destroy a Client ID . . 594
18.51. Operation 58: RECLAIM_COMPLETE - Indicates Reclaims 18.51. Operation 58: RECLAIM_COMPLETE - Indicates Reclaims
Finished . . . . . . . . . . . . . . . . . . . . . . . . 594 Finished . . . . . . . . . . . . . . . . . . . . . . . . 595
18.52. Operation 10044: ILLEGAL - Illegal Operation . . . . . . 597 18.52. Operation 10044: ILLEGAL - Illegal Operation . . . . . . 598
19. NFSv4.1 Callback Procedures . . . . . . . . . . . . . . . . . 598 19. NFSv4.1 Callback Procedures . . . . . . . . . . . . . . . . . 599
19.1. Procedure 0: CB_NULL - No Operation . . . . . . . . . . 598 19.1. Procedure 0: CB_NULL - No Operation . . . . . . . . . . 599
19.2. Procedure 1: CB_COMPOUND - Compound Operations . . . . . 598 19.2. Procedure 1: CB_COMPOUND - Compound Operations . . . . . 599
20. NFSv4.1 Callback Operations . . . . . . . . . . . . . . . . . 603 20. NFSv4.1 Callback Operations . . . . . . . . . . . . . . . . . 604
20.1. Operation 3: CB_GETATTR - Get Attributes . . . . . . . . 603 20.1. Operation 3: CB_GETATTR - Get Attributes . . . . . . . . 604
20.2. Operation 4: CB_RECALL - Recall a Delegation . . . . . . 604 20.2. Operation 4: CB_RECALL - Recall a Delegation . . . . . . 605
20.3. Operation 5: CB_LAYOUTRECALL - Recall Layout from Client 605 20.3. Operation 5: CB_LAYOUTRECALL - Recall Layout from Client 606
20.4. Operation 6: CB_NOTIFY - Notify Client of Directory 20.4. Operation 6: CB_NOTIFY - Notify Client of Directory
Changes . . . . . . . . . . . . . . . . . . . . . . . . 608 Changes . . . . . . . . . . . . . . . . . . . . . . . . 609
20.5. Operation 7: CB_PUSH_DELEG - Offer Previously Requested 20.5. Operation 7: CB_PUSH_DELEG - Offer Previously Requested
Delegation to Client . . . . . . . . . . . . . . . . . . 612 Delegation to Client . . . . . . . . . . . . . . . . . . 613
20.6. Operation 8: CB_RECALL_ANY - Keep Any N Recallable 20.6. Operation 8: CB_RECALL_ANY - Keep Any N Recallable
Objects . . . . . . . . . . . . . . . . . . . . . . . . 613 Objects . . . . . . . . . . . . . . . . . . . . . . . . 614
20.7. Operation 9: CB_RECALLABLE_OBJ_AVAIL - Signal Resources 20.7. Operation 9: CB_RECALLABLE_OBJ_AVAIL - Signal Resources
for Recallable Objects . . . . . . . . . . . . . . . . . 616 for Recallable Objects . . . . . . . . . . . . . . . . . 617
20.8. Operation 10: CB_RECALL_SLOT - Change Flow Control 20.8. Operation 10: CB_RECALL_SLOT - Change Flow Control
Limits . . . . . . . . . . . . . . . . . . . . . . . . . 617 Limits . . . . . . . . . . . . . . . . . . . . . . . . . 618
20.9. Operation 11: CB_SEQUENCE - Supply Backchannel 20.9. Operation 11: CB_SEQUENCE - Supply Backchannel
Sequencing and Control . . . . . . . . . . . . . . . . . 618 Sequencing and Control . . . . . . . . . . . . . . . . . 619
20.10. Operation 12: CB_WANTS_CANCELLED - Cancel Pending 20.10. Operation 12: CB_WANTS_CANCELLED - Cancel Pending
Delegation Wants . . . . . . . . . . . . . . . . . . . . 621 Delegation Wants . . . . . . . . . . . . . . . . . . . . 622
20.11. Operation 13: CB_NOTIFY_LOCK - Notify Client of Possible 20.11. Operation 13: CB_NOTIFY_LOCK - Notify Client of Possible
Lock Availability . . . . . . . . . . . . . . . . . . . 622 Lock Availability . . . . . . . . . . . . . . . . . . . 623
20.12. Operation 14: CB_NOTIFY_DEVICEID - Notify Client of 20.12. Operation 14: CB_NOTIFY_DEVICEID - Notify Client of
Device ID Changes . . . . . . . . . . . . . . . . . . . 623 Device ID Changes . . . . . . . . . . . . . . . . . . . 624
20.13. Operation 10044: CB_ILLEGAL - Illegal Callback Operation 625 20.13. Operation 10044: CB_ILLEGAL - Illegal Callback Operation 626
21. Security Considerations . . . . . . . . . . . . . . . . . . . 626 21. Security Considerations . . . . . . . . . . . . . . . . . . . 627
22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 630 22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 631
22.1. IANA Actions Neeeded . . . . . . . . . . . . . . . . . . 630 22.1. IANA Actions Neeeded . . . . . . . . . . . . . . . . . . 631
22.2. Named Attribute Definitions . . . . . . . . . . . . . . 630 22.2. Named Attribute Definitions . . . . . . . . . . . . . . 631
22.3. Device ID Notifications . . . . . . . . . . . . . . . . 631 22.3. Device ID Notifications . . . . . . . . . . . . . . . . 632
22.4. Object Recall Types . . . . . . . . . . . . . . . . . . 633 22.4. Object Recall Types . . . . . . . . . . . . . . . . . . 634
22.5. Layout Types . . . . . . . . . . . . . . . . . . . . . . 635 22.5. Layout Types . . . . . . . . . . . . . . . . . . . . . . 636
22.6. Path Variable Definitions . . . . . . . . . . . . . . . 637 22.6. Path Variable Definitions . . . . . . . . . . . . . . . 638
23. References . . . . . . . . . . . . . . . . . . . . . . . . . 641 23. References . . . . . . . . . . . . . . . . . . . . . . . . . 642
23.1. Normative References . . . . . . . . . . . . . . . . . . 641 23.1. Normative References . . . . . . . . . . . . . . . . . . 642
23.2. Informative References . . . . . . . . . . . . . . . . . 644 23.2. Informative References . . . . . . . . . . . . . . . . . 645
Appendix A. Need for this Update . . . . . . . . . . . . . . . . 647 Appendix A. Need for this Update . . . . . . . . . . . . . . . . 648
Appendix B. Changes in this Update . . . . . . . . . . . . . . . 649 Appendix B. Changes in this Update . . . . . . . . . . . . . . . 650
B.1. Revisions Made to Section 11 of [RFC5661] . . . . . . . . 649 B.1. Revisions Made to Section 11 of [RFC5661] . . . . . . . . 650
B.2. Revisions Made to Operations in [RFC5661] . . . . . . . . 652 B.2. Revisions Made to Operations in [RFC5661] . . . . . . . . 653
B.3. Revisions Made to Error Definitions in [RFC5661] . . . . 655 B.3. Revisions Made to Error Definitions in [RFC5661] . . . . 656
B.4. Other Revisions Made to [RFC5661] . . . . . . . . . . . . 655 B.4. Other Revisions Made to [RFC5661] . . . . . . . . . . . . 656
Appendix C. Security Issues that Need to be Addressed . . . . . 656 Appendix C. Security Issues that Need to be Addressed . . . . . 657
Appendix D. Acknowledgments . . . . . . . . . . . . . . . . . . 658 Appendix D. Acknowledgments . . . . . . . . . . . . . . . . . . 659
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 661 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 662
1. Introduction 1. Introduction
1.1. Introduction to this Update 1.1. Introduction to this Update
The revised description of the NFS version 4 minor version 1 The revised description of the NFS version 4 minor version 1
(NFSv4.1) protocol presented in this update is necessary to enable (NFSv4.1) protocol presented in this update is necessary to enable
full use of trunking in connection with multi-server namespace full use of trunking in connection with multi-server namespace
features and to enable the use of transparent state migration in features and to enable the use of transparent state migration in
connection with NFSv4.1. See Appendix A for a discussion of the need connection with NFSv4.1. This document is in the form of an updated
for this modified treatment and Appendix B for a description of the description of the NFS 4.1 protocol previously defined in RFC5661
specific changes made to arrive at the current text. [60]. RFC5661 is obsoleted by this document. However, the update
has a limited scope and is focused on enabling full use of trunking
and transparent state migration. The need for these changes is
discussed in Appendix A. Appendix B describes the specific changes
made to arrive at the current text.
This document is in the form of a complete updated description of the This limited scope update is applied to the main NFSv4.1 RFC with the
protocol, rather than a series of updated sections. However, it is intention of providing an authoritative complete specification, the
not, as the term has generally been used with regard to NFSv4 minor motivation for which is discussed in [I.D-roach-bis-documents],
versions, a "bis document", which contains a full description of the addressing the issues within the scope of the update. However, it
protocol, with no documents updating it. Production of such a will not address issues that are known but outside of this limited
document would require completion of the work items listed below. scope as could expected by a full update of the protocol. Below are
This would include work with regard to documents which curently some areas which are known to need addressing in a future update of
update RFC5661 [60], which will also update this document. In the protocol.
addition, it is believed that there are areas for which the
description in RFC5661 [60] is either incorrect or inadequate.
o Work would have to be done with regard to RFC8178 [61] with which o Work would have to be done with regard to RFC8178 [61] which
RFC5661 [60] is curretly inconsistent, in order to arrive at a establishes NFSv4-wide versioning rules. As RFC5661 is curretly
situation in which there would be no need for RFC8178 to update inconsistent with this document, changes are needed in order to
the NFSv4.1 specfication. arrive at a situation in which there would be no need for RFC8178
to update the NFSv4.1 specfication.
o Work would have to be done with regard to RFC8434 [64] which o Work would have to be done with regard to RFC8434 [64], which
curently updates RFC5661 [60]. When that work is done and the establishes the requirements for pNFS layout types, which are not
resulting document approved, the new NFSv4.1 specfication will clearly defined in RFC5661. When that work is done and the
obsolete RFC8434 as well as RFC5661. resulting documents approved, the new NFSv4.1 specfication
document will provide a clear set of requirements for layout types
and a description of the file layout type that conforms to those
requirements. Other layout types will have their own specfication
documents that conforms to those requirements as well.
o Work would have to be done to address many erratas relevant to RFC
5661, other than errata 2006 which is addressed in this document.
That errata was not deferrable because of the interaction of the
changes suggested in that errata and handling of state and session
migration. The erratas that have been deferred include changes
originally suggested by a particular errata, which change
consensus decisions made in RFC 5661, which need to be changed to
ensure compatibility with existing implementations that do not
follow the handling delineated in RFC 5661. Note that it is
expected that such erratas will remain relevant to implementers
and the authors of an eventual rfc5661bis, despite the fact that
this document, when approved, will obsolete RFC 5661.
o There is a need for a new approach to the description of o There is a need for a new approach to the description of
internationalization since the current internationalization internationalization since the current internationalization
section (Section 14) has never been implemented and does not meet section (Section 14) has never been implemented and does not meet
the needs of the NFSv4 protocol. Possible solutions are to create the needs of the NFSv4 protocol. Possible solutions are to create
a new internationalization section modeled on that in [62] or to a new internationalization section modeled on that in [62] or to
create a new document describing internationalization for all create a new document describing internationalization for all
NFSv4 minor versions and reference that document in the RFCs NFSv4 minor versions and reference that document in the RFCs
defining both NFSv4.0 and NFSv4.1. defining both NFSv4.0 and NFSv4.1.
o There is a need for a revised treatment of security of in NFSv4.1. o There is a need for a revised treatment of security in NFSv4.1.
The issues with the existing treatment are discussed in The issues with the existing treatment are discussed in
Appendix C. Appendix C.
Until the above work is done, there will not be a full, correct Until the above work is done, there will not be a consistent set of
description of the NFSv41 protocol in a single document and any full documents providing a description of the NFSv4.1 protocol and any
description would involves documents updating the specification, just full description would involve documents updating other documents
as RFC8434 [64] and RFC8178 [61] do today. within the specification, just as RFC 8434 [64] and RFC 8178 [61] do
today.
1.2. The NFS Version 4 Minor Version 1 Protocol 1.2. The NFS Version 4 Minor Version 1 Protocol
The NFS version 4 minor version 1 (NFSv4.1) protocol is the second The NFS version 4 minor version 1 (NFSv4.1) protocol is the second
minor version of the NFS version 4 (NFSv4) protocol. The first minor minor version of the NFS version 4 (NFSv4) protocol. The first minor
version, NFSv4.0, is now described in RFC7530 [62]. It generally version, NFSv4.0, is now described in RFC 7530 [62]. It generally
follows the guidelines for minor versioning that are listed in follows the guidelines for minor versioning that are listed in
Section 10 of RFC 3530. However, it diverges from guidelines 11 ("a Section 10 of RFC 3530. However, it diverges from guidelines 11 ("a
client and server that support minor version X must support minor client and server that support minor version X must support minor
versions 0 through X-1") and 12 ("no new features may be introduced versions 0 through X-1") and 12 ("no new features may be introduced
as mandatory in a minor version"). These divergences are due to the as mandatory in a minor version"). These divergences are due to the
introduction of the sessions model for managing non-idempotent introduction of the sessions model for managing non-idempotent
operations and the RECLAIM_COMPLETE operation. These two new operations and the RECLAIM_COMPLETE operation. These two new
features are infrastructural in nature and simplify implementation of features are infrastructural in nature and simplify implementation of
existing and other new features. Making them anything but REQUIRED existing and other new features. Making them anything but REQUIRED
would add undue complexity to protocol definition and implementation. would add undue complexity to protocol definition and implementation.
skipping to change at page 267, line 35 skipping to change at page 267, line 35
o Implement Transparent State Migration, except for the lock with o Implement Transparent State Migration, except for the lock with
the conflicting stateid. In this case, the client will be aware the conflicting stateid. In this case, the client will be aware
of a lost lock (through the SEQ4_STATUS flags) and be allowed to of a lost lock (through the SEQ4_STATUS flags) and be allowed to
reclaim it. reclaim it.
When transferring state between the source and destination, the When transferring state between the source and destination, the
issues discussed in Section 7.2 of [63] must still be attended to. issues discussed in Section 7.2 of [63] must still be attended to.
In this case, the use of NFS4ERR_DELAY may still necessary in In this case, the use of NFS4ERR_DELAY may still necessary in
NFSv4.1, as it was in NFSv4.0, to prevent locking state changing NFSv4.1, as it was in NFSv4.0, to prevent locking state changing
while it is being transferred. while it is being transferred. See Section 15.1.1.3 for information
about appropriate client retry approaches in the event that
NFS4ERR_DELAY is returned.
There are a number of important differences in the NFS4.1 context: There are a number of important differences in the NFS4.1 context:
o The absence of RELEASE_LOCKOWNER means that the one case in which o The absence of RELEASE_LOCKOWNER means that the one case in which
an operation could not be deferred by use of NFS4ERR_DELAY no an operation could not be deferred by use of NFS4ERR_DELAY no
longer exists. longer exists.
o Sequencing of operations is no longer done using owner-based o Sequencing of operations is no longer done using owner-based
operation sequences numbers. Instead, sequencing is session- operation sequences numbers. Instead, sequencing is session-
based based
skipping to change at page 269, line 43 skipping to change at page 269, line 43
returned by the source server may not be relevant when the request returned by the source server may not be relevant when the request
was reissued, directed to the destination server. was reissued, directed to the destination server.
An important issue is that the specification needs to take note of An important issue is that the specification needs to take note of
all potential COMPOUNDs, even if they might be unlikely in practice. all potential COMPOUNDs, even if they might be unlikely in practice.
For example, a COMPOUND is allowed to access multiple file systems For example, a COMPOUND is allowed to access multiple file systems
and might perform non-idempotent operations in some of them before and might perform non-idempotent operations in some of them before
accessing a file system being migrated. Also, a COMPOUND may return accessing a file system being migrated. Also, a COMPOUND may return
considerable data in the response, before being rejected with considerable data in the response, before being rejected with
NFS4ERR_DELAY or NFS4ERR_MOVED, and may in addition be marked as NFS4ERR_DELAY or NFS4ERR_MOVED, and may in addition be marked as
sa_cachethis. sa_cachethis. However, note that if the client and server adhere to
rules in Section 15.1.1.3, there is no possibility of non-idempotent
operations being spuriouly reissued after receiving NFS4ERR_DELAY
response.
To address these issues, a destination server MAY do any of the To address these issues, a destination server MAY do any of the
following when implementing session transfer. following when implementing session transfer.
o Avoid enforcing any sequencing semantics for a particular slot o Avoid enforcing any sequencing semantics for a particular slot
until the client has established the starting sequence for that until the client has established the starting sequence for that
slot on the destination server. slot on the destination server.
o For each slot, avoid returning a cached reply returning o For each slot, avoid returning a cached reply returning
NFS4ERR_DELAY or NFS4ERR_MOVED until the client has established NFS4ERR_DELAY or NFS4ERR_MOVED until the client has established
the starting sequence for that slot on the destination server. the starting sequence for that slot on the destination server.
o Until the client has established the starting sequence for a o Until the client has established the starting sequence for a
particular slot on the destination server, avoid reporting particular slot on the destination server, avoid reporting
NFS4ERR_SEQ_MISORDERED or return a cached reply returning NFS4ERR_SEQ_MISORDERED or returning a cached reply returning
NFS4ERR_DELAY or NFS4ERR_MOVED, where the reply consists solely of NFS4ERR_DELAY or NFS4ERR_MOVED, where the reply consists solely of
a series of operations where the response is NFS4_OK until the a series of operations where the response is NFS4_OK until the
final error. final error.
Because of the considerations mentioned above, the destination server Because of the considerations mentioned above including the rules for
can respond appropriately to SEQUENCE operations received from the the handling of NFS4ERR_DELAY included in Section 15.1.1.3, the
client by adopting the three policies listed below: destination server can respond appropriately to SEQUENCE operations
received from the client by adopting the three policies listed below:
o Not responding with NFS4ERR_SEQ_MISORDERED for the initial request o Not responding with NFS4ERR_SEQ_MISORDERED for the initial request
on a slot within a transferred session, since the destination on a slot within a transferred session, since the destination
server cannot be aware of requests made by the client after the server cannot be aware of requests made by the client after the
server handoff but before the client became aware of the shift. server handoff but before the client became aware of the shift.
o Replying as it would for a retry whenever the sequence matches o Replying as it would for a retry whenever the sequence matches
that transferred by the source server, even though this would not that transferred by the source server, even though this would not
provide retry handling for requests issued after the server provide retry handling for requests issued after the server
handoff, under the assumption that when such requests are issued handoff, under the assumption that when such requests are issued
they will never be responded to in a state-changing fashion, they will never be responded to in a state-changing fashion,
making retry support for them unnecessary. making retry support for them unnecessary.
o Once a non-retry SEQUENCE is received for a given slot, using that o Once a non-retry SEQUENCE is received for a given slot, using that
as the basis for further sequence checking, with no further as the basis for further sequence checking, with no further
reference to the sequence value transferred by the sour server. reference to the sequence value transferred by the source.
server.
11.14. Effecting File System Referrals 11.14. Effecting File System Referrals
Referrals are effected when an absent file system is encountered and Referrals are effected when an absent file system is encountered and
one or more alternate locations are made available by the one or more alternate locations are made available by the
fs_locations or fs_locations_info attributes. The client will fs_locations or fs_locations_info attributes. The client will
typically get an NFS4ERR_MOVED error, fetch the appropriate location typically get an NFS4ERR_MOVED error, fetch the appropriate location
information, and proceed to access the file system on a different information, and proceed to access the file system on a different
server, even though it retains its logical position within the server, even though it retains its logical position within the
original namespace. Referrals differ from migration events in that original namespace. Referrals differ from migration events in that
skipping to change at page 364, line 18 skipping to change at page 364, line 18
For any of a number of reasons, the replier could not process this For any of a number of reasons, the replier could not process this
operation in what was deemed a reasonable time. The client should operation in what was deemed a reasonable time. The client should
wait and then try the request with a new slot and sequence value. wait and then try the request with a new slot and sequence value.
Some examples of scenarios that might lead to this situation: Some examples of scenarios that might lead to this situation:
o A server that supports hierarchical storage receives a request to o A server that supports hierarchical storage receives a request to
process a file that had been migrated. process a file that had been migrated.
o An operation requires a delegation recall to proceed, and waiting o An operation requires a delegation recall to proceed, so that the
for this delegation recall makes processing this request in a need to wait for for this delegation to be recalled makes
timely fashion impossible. processing this request in a timely fashion impossible.
In such cases, the error NFS4ERR_DELAY allows these preparatory o A request is being performed on a session being migrated from
operations to proceed without holding up client resources such as a another server as described in Section 11.13.3, and the lack of
session slot. After delaying for period of time, the client can then full information about the state of the session on the source
re-send the operation in question (but not with the same slot ID and makes it impossible to process the request immediately.
sequence ID; one or both MUST be different on the re-send).
In such cases, returning the error NFS4ERR_DELAY allows necessary
preparatory operations to proceed without holding up requester
resources such as a session slot. After delaying for period of time,
the client can then re-send the operation in question, often as part
of a nearly identical request. Because of the need to avoid spurious
reissues of non-idempotent operations and to avoid acting in response
to NFS4ERR_DELAY errors returned on responses returned from the
replier's replay cache, integration with the session-provided replay
cache is necessary. There are a number of cases to deal with, each
of which requires different sorts of handling by the requester and
replier:
o If NFS4ERR_DELAY is returned on a SEQUENCE operation, the request
is retried in full with the SEQUENCE operation containing the same
slot and sequece values. In this case, the replier MUST avoid
returning a response containing NFS4ERR_DELAY as the response to
SEQUENCE solely on the basis of its presence in the replay cache.
If the replier did this, the retries would not be effective as
there would be no opportunity for the replier to see whether the
condition that generated the NFS4ERR_DELAY had been rectified
during the interim between the original request and the retry.
o If NFS4ERR_DELAY is returned on an operation other than SEQUENCE
which validly appears as the first operation of a request,
handling is similar. The request can be retired in full without
modification. In this case as well, the replier MUST avoid
returning a response containing NFS4ERR_DELAY as the response to
an intial operation of a request solely on the basis of its
presence in the replay cache. If the replier did this, the
retries would not be effective as there would be no opportunity
for the replier to see whether the condition that generated the
NFS4ERR_DELAY had been rectified during the interim between the
original request and the retry.
o If NFS4ERR_DELAY is returned on an operation other than the first
in the request, the request when retried MUST contain a SEQUENCE
operation which is different than the original one, with either
the bin id or the sequence value different from that in the
original request. Because requesters do this, there is no need
for the replier to take special care to avoid returning an
NFS4ERR_DELAY error, obtained from the replay cache. When no non-
idempotent operations have been processed before the NFS4ERR_DELAY
was returned, the requester should retry the request in full, with
the only difference from the original request being the
modfication to the slot id or sequence value in the reissued
SEQUENCE operation.
o When NFS4ERR_DELAY is returned on an operation other than the
first within a request and there has been a non-idempotent
operation processed before the NFS4ERR_DELAY was returned, the
reissued request should avoid the non-idempotent operation. The
request still must use a SEQUENCE operation with either a
different slot id or sequence value from the SEQUENCE in the
original request. Because this is done, there is no way the
replier could avoid spuriously re-executing the non-idempotent
operation since the different SEQUENCE parameters prevent the
requester from recognizing that the non-idempotent operation is
being retried.
Note that without the ability to return NFS4ERR_DELAY and the Note that without the ability to return NFS4ERR_DELAY and the
client's willingness to re-send when receiving it, deadlock might requester's willingness to re-send when receiving it, deadlock might
result. For example, if a recall is done, and if the delegation result. For example, if a recall is done, and if the delegation
return or operations preparatory to delegation return are held up by return or operations preparatory to delegation return are held up by
other operations that need the delegation to be returned, session other operations that need the delegation to be returned, session
slots might not be available. The result could be deadlock. slots might not be available. The result could be deadlock.
15.1.1.4. NFS4ERR_INVAL (Error Code 22) 15.1.1.4. NFS4ERR_INVAL (Error Code 22)
The arguments for this operation are not valid for some reason, even The arguments for this operation are not valid for some reason, even
though they do match those specified in the XDR definition for the though they do match those specified in the XDR definition for the
request. request.
skipping to change at page 630, line 17 skipping to change at page 631, line 17
invalid address as if it were a NFSv4 server. The specifics will invalid address as if it were a NFSv4 server. The specifics will
vary depending on the degree of network isolation and whether the vary depending on the degree of network isolation and whether the
request is to the referring or destination servers. request is to the referring or destination servers.
22. IANA Considerations 22. IANA Considerations
This section uses terms that are defined in [58]. This section uses terms that are defined in [58].
22.1. IANA Actions Neeeded 22.1. IANA Actions Neeeded
This update does not require any actions by IANA. This update does not require any modification of or additions to
registry entries or registry rules associated with NFSv4.1. However,
since this document is intended to obsolete RFC5661, it will be
necessary for IANA to update all registry entries and registry rules
references that points to RFC5661 to point to this document instead.
Previous actions by IANA related to NFSv4.1 are listed in the Previous actions by IANA related to NFSv4.1 are listed in the
remaining subsections of Section 22. remaining subsections of Section 22.
22.2. Named Attribute Definitions 22.2. Named Attribute Definitions
IANA created a registry called the "NFSv4 Named Attribute Definitions IANA created a registry called the "NFSv4 Named Attribute Definitions
Registry". Registry".
The NFSv4.1 protocol supports the association of a file with zero or The NFSv4.1 protocol supports the association of a file with zero or
skipping to change at page 649, line 15 skipping to change at page 650, line 15
o The description of some existing errors has been modified to more o The description of some existing errors has been modified to more
clearly explain certain errors situations to reflect the existence clearly explain certain errors situations to reflect the existence
of trunking and the possible use of fs-specific grace periods. of trunking and the possible use of fs-specific grace periods.
For details, see Appendix B.3. For details, see Appendix B.3.
o New descriptions of certain existing operations are provided, o New descriptions of certain existing operations are provided,
either because the existing treatment did not account for either because the existing treatment did not account for
situations that would arise in dealing with transparent state situations that would arise in dealing with transparent state
migration, or because some types of reclaim issues were not migration, or because some types of reclaim issues were not
adequately dealt with in the context of fs-specific grace periods. adequately dealt with in the context of fs-specific grace periods.
For details, see Appendix B.3. For details, see Appendix B.2.
Appendix B. Changes in this Update Appendix B. Changes in this Update
B.1. Revisions Made to Section 11 of [RFC5661] B.1. Revisions Made to Section 11 of [RFC5661]
A number of areas needed to be revised or extended, in many case A number of areas needed to be revised or extended, in many case
replacing existing sub-sections within section 11 of RFC5661 [60]: replacing existing sub-sections within section 11 of RFC5661 [60]:
o New introductory material, including a terminology section, o New introductory material, including a terminology section,
replaces the existing material in RFC5661 [60] ranging from the replaces the existing material in RFC5661 [60] ranging from the
skipping to change at page 655, line 35 skipping to change at page 656, line 35
replicas while only a single file system instance might be replicas while only a single file system instance might be
involved. The updated description appears in Section 15.1.2.4 involved. The updated description appears in Section 15.1.2.4
below. below.
o Because of the need to accommodate use of fs-specific grace o Because of the need to accommodate use of fs-specific grace
periods, it is necessary to clarify some of the error definitions periods, it is necessary to clarify some of the error definitions
of reclaim-related errors in Section 15 of RFC5661 [60], so the of reclaim-related errors in Section 15 of RFC5661 [60], so the
text applies properly to reclaims for all types of grace periods. text applies properly to reclaims for all types of grace periods.
The updated descriptions appear within Section 15.1.9 below. The updated descriptions appear within Section 15.1.9 below.
o Because of the need to provide the clarifications in errata 2006
and to adapt these to properly explain the interaction of
NFS4ERR_DELAY with the replay cache, a revised description of
NFS4ERR_DELAY appears in Section 15.1.1.3. This errata, unlike
many other RFC5661 erratas, is addressed in this document because
of the extensive use of NFS4ERR_DELAY in connection with state
migration and session migration.
B.4. Other Revisions Made to [RFC5661] B.4. Other Revisions Made to [RFC5661]
Beside the major reworking of Section 11 and the associated revisions Beside the major reworking of Section 11 and the associated revisions
to existing operations and errors, there are a number of related to existing operations and errors, there are a number of related
changes that are necessary: changes that are necessary:
o The summary that appeared in Section 1.7.3.3 of RFC5661 [60] was o The summary that appeared in Section 1.7.3.3 of RFC5661 [60] was
revised to reflect the changes made in the revised Section 11 revised to reflect the changes made in the revised Section 11
above. The updated summary appears as Section 1.8.3.3 above. above. The updated summary appears as Section 1.8.3.3 above.
 End of changes. 51 change blocks. 
159 lines changed or deleted 257 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/