--- 1/draft-ietf-nfsv4-rfc3530bis-12.txt 2011-08-17 04:16:58.000000000 +0200 +++ 2/draft-ietf-nfsv4-rfc3530bis-13.txt 2011-08-17 04:16:58.000000000 +0200 @@ -1,34 +1,35 @@ NFSv4 T. Haynes, Ed. Internet-Draft NetApp Intended status: Standards Track D. Noveck, Ed. -Expires: October 10, 2011 EMC - April 08, 2011 +Expires: February 17, 2012 EMC + August 16, 2011 Network File System (NFS) Version 4 Protocol - draft-ietf-nfsv4-rfc3530bis-12.txt + draft-ietf-nfsv4-rfc3530bis-13.txt Abstract The Network File System (NFS) version 4 is a distributed filesystem protocol which owes heritage to NFS protocol version 2, RFC 1094, and version 3, RFC 1813. Unlike earlier versions, the NFS version 4 protocol supports traditional file access while integrating support for file locking and the mount protocol. In addition, support for strong security (and its negotiation), compound operations, client caching, and internationalization have been added. Of course, attention has been applied to making NFS version 4 operate well in an Internet environment. This document, together with the companion XDR description document, - replaces RFC 3530 as the definition of the NFS version 4 protocol. + RFCNFSv4XDR, replaces RFC 3530 as the definition of the NFS version 4 + protocol. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1]. Status of this Memo This Internet-Draft is submitted in full conformance with the @@ -37,21 +38,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on October 10, 2011. + This Internet-Draft will expire on February 17, 2012. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -90,268 +91,268 @@ 1.5.6. Client Caching and Delegation . . . . . . . . . . . 15 1.6. General Definitions . . . . . . . . . . . . . . . . . . 16 2. Protocol Data Types . . . . . . . . . . . . . . . . . . . . . 18 2.1. Basic Data Types . . . . . . . . . . . . . . . . . . . . 18 2.2. Structured Data Types . . . . . . . . . . . . . . . . . 20 3. RPC and Security Flavor . . . . . . . . . . . . . . . . . . . 25 3.1. Ports and Transports . . . . . . . . . . . . . . . . . . 25 3.1.1. Client Retransmission Behavior . . . . . . . . . . . 26 3.2. Security Flavors . . . . . . . . . . . . . . . . . . . . 27 3.2.1. Security mechanisms for NFSv4 . . . . . . . . . . . 27 - 3.3. Security Negotiation . . . . . . . . . . . . . . . . . . 29 - 3.3.1. SECINFO . . . . . . . . . . . . . . . . . . . . . . 30 - 3.3.2. Security Error . . . . . . . . . . . . . . . . . . . 30 - 3.3.3. Callback RPC Authentication . . . . . . . . . . . . 30 - 4. Filehandles . . . . . . . . . . . . . . . . . . . . . . . . . 32 - 4.1. Obtaining the First Filehandle . . . . . . . . . . . . . 32 - 4.1.1. Root Filehandle . . . . . . . . . . . . . . . . . . 33 - 4.1.2. Public Filehandle . . . . . . . . . . . . . . . . . 33 - 4.2. Filehandle Types . . . . . . . . . . . . . . . . . . . . 33 - 4.2.1. General Properties of a Filehandle . . . . . . . . . 34 - 4.2.2. Persistent Filehandle . . . . . . . . . . . . . . . 34 - 4.2.3. Volatile Filehandle . . . . . . . . . . . . . . . . 35 - 4.2.4. One Method of Constructing a Volatile Filehandle . . 36 - 4.3. Client Recovery from Filehandle Expiration . . . . . . . 36 - 5. File Attributes . . . . . . . . . . . . . . . . . . . . . . . 37 - 5.1. REQUIRED Attributes . . . . . . . . . . . . . . . . . . 38 - 5.2. RECOMMENDED Attributes . . . . . . . . . . . . . . . . . 39 - 5.3. Named Attributes . . . . . . . . . . . . . . . . . . . . 39 - 5.4. Classification of Attributes . . . . . . . . . . . . . . 41 - 5.5. Set-Only and Get-Only Attributes . . . . . . . . . . . . 41 - 5.6. REQUIRED Attributes - List and Definition References . . 42 + 3.3. Security Negotiation . . . . . . . . . . . . . . . . . . 28 + 3.3.1. SECINFO . . . . . . . . . . . . . . . . . . . . . . 28 + 3.3.2. Security Error . . . . . . . . . . . . . . . . . . . 28 + 3.3.3. Callback RPC Authentication . . . . . . . . . . . . 29 + 4. Filehandles . . . . . . . . . . . . . . . . . . . . . . . . . 30 + 4.1. Obtaining the First Filehandle . . . . . . . . . . . . . 30 + 4.1.1. Root Filehandle . . . . . . . . . . . . . . . . . . 30 + 4.1.2. Public Filehandle . . . . . . . . . . . . . . . . . 31 + 4.2. Filehandle Types . . . . . . . . . . . . . . . . . . . . 31 + 4.2.1. General Properties of a Filehandle . . . . . . . . . 31 + 4.2.2. Persistent Filehandle . . . . . . . . . . . . . . . 32 + 4.2.3. Volatile Filehandle . . . . . . . . . . . . . . . . 32 + 4.2.4. One Method of Constructing a Volatile Filehandle . . 34 + 4.3. Client Recovery from Filehandle Expiration . . . . . . . 34 + 5. File Attributes . . . . . . . . . . . . . . . . . . . . . . . 35 + 5.1. REQUIRED Attributes . . . . . . . . . . . . . . . . . . 36 + 5.2. RECOMMENDED Attributes . . . . . . . . . . . . . . . . . 36 + 5.3. Named Attributes . . . . . . . . . . . . . . . . . . . . 37 + 5.4. Classification of Attributes . . . . . . . . . . . . . . 38 + 5.5. Set-Only and Get-Only Attributes . . . . . . . . . . . . 39 + 5.6. REQUIRED Attributes - List and Definition References . . 39 5.7. RECOMMENDED Attributes - List and Definition - References . . . . . . . . . . . . . . . . . . . . . . . 43 - 5.8. Attribute Definitions . . . . . . . . . . . . . . . . . 44 - 5.8.1. Definitions of REQUIRED Attributes . . . . . . . . . 44 + References . . . . . . . . . . . . . . . . . . . . . . . 40 + 5.8. Attribute Definitions . . . . . . . . . . . . . . . . . 41 + 5.8.1. Definitions of REQUIRED Attributes . . . . . . . . . 41 5.8.2. Definitions of Uncategorized RECOMMENDED - Attributes . . . . . . . . . . . . . . . . . . . . . 46 - 5.9. Interpreting owner and owner_group . . . . . . . . . . . 52 - 5.10. Character Case Attributes . . . . . . . . . . . . . . . 55 - 6. Access Control Attributes . . . . . . . . . . . . . . . . . . 55 - 6.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . 55 - 6.2. File Attributes Discussion . . . . . . . . . . . . . . . 56 - 6.2.1. Attribute 12: acl . . . . . . . . . . . . . . . . . 56 - 6.2.2. Attribute 33: mode . . . . . . . . . . . . . . . . . 70 - 6.3. Common Methods . . . . . . . . . . . . . . . . . . . . . 71 - 6.3.1. Interpreting an ACL . . . . . . . . . . . . . . . . 71 - 6.3.2. Computing a Mode Attribute from an ACL . . . . . . . 72 - 6.4. Requirements . . . . . . . . . . . . . . . . . . . . . . 73 - 6.4.1. Setting the mode and/or ACL Attributes . . . . . . . 73 - 6.4.2. Retrieving the mode and/or ACL Attributes . . . . . 75 - 6.4.3. Creating New Objects . . . . . . . . . . . . . . . . 75 - 7. Multi-Server Namespace . . . . . . . . . . . . . . . . . . . 77 - 7.1. Location Attributes . . . . . . . . . . . . . . . . . . 77 - 7.2. File System Presence or Absence . . . . . . . . . . . . 77 - 7.3. Getting Attributes for an Absent File System . . . . . . 78 - 7.3.1. GETATTR Within an Absent File System . . . . . . . . 79 - 7.3.2. READDIR and Absent File Systems . . . . . . . . . . 80 - 7.4. Uses of Location Information . . . . . . . . . . . . . . 80 - 7.4.1. File System Replication . . . . . . . . . . . . . . 81 - 7.4.2. File System Migration . . . . . . . . . . . . . . . 82 - 7.4.3. Referrals . . . . . . . . . . . . . . . . . . . . . 82 - 7.5. Location Entries and Server Identity . . . . . . . . . . 83 - 7.6. Additional Client-Side Considerations . . . . . . . . . 84 - 7.7. Effecting File System Transitions . . . . . . . . . . . 85 - 7.7.1. File System Transitions and Simultaneous Access . . 86 - 7.7.2. Filehandles and File System Transitions . . . . . . 86 - 7.7.3. Fileids and File System Transitions . . . . . . . . 87 - 7.7.4. Fsids and File System Transitions . . . . . . . . . 88 - 7.7.5. The Change Attribute and File System Transitions . . 88 - 7.7.6. Lock State and File System Transitions . . . . . . . 89 - 7.7.7. Write Verifiers and File System Transitions . . . . 91 + Attributes . . . . . . . . . . . . . . . . . . . . . 44 + 5.9. Interpreting owner and owner_group . . . . . . . . . . . 50 + 5.10. Character Case Attributes . . . . . . . . . . . . . . . 53 + 6. Access Control Attributes . . . . . . . . . . . . . . . . . . 53 + 6.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . 53 + 6.2. File Attributes Discussion . . . . . . . . . . . . . . . 54 + 6.2.1. Attribute 12: acl . . . . . . . . . . . . . . . . . 54 + 6.2.2. Attribute 33: mode . . . . . . . . . . . . . . . . . 68 + 6.3. Common Methods . . . . . . . . . . . . . . . . . . . . . 69 + 6.3.1. Interpreting an ACL . . . . . . . . . . . . . . . . 69 + 6.3.2. Computing a Mode Attribute from an ACL . . . . . . . 70 + 6.4. Requirements . . . . . . . . . . . . . . . . . . . . . . 71 + 6.4.1. Setting the mode and/or ACL Attributes . . . . . . . 71 + 6.4.2. Retrieving the mode and/or ACL Attributes . . . . . 73 + 6.4.3. Creating New Objects . . . . . . . . . . . . . . . . 73 + 7. Multi-Server Namespace . . . . . . . . . . . . . . . . . . . 75 + 7.1. Location Attributes . . . . . . . . . . . . . . . . . . 75 + 7.2. File System Presence or Absence . . . . . . . . . . . . 75 + 7.3. Getting Attributes for an Absent File System . . . . . . 76 + 7.3.1. GETATTR Within an Absent File System . . . . . . . . 77 + 7.3.2. READDIR and Absent File Systems . . . . . . . . . . 78 + 7.4. Uses of Location Information . . . . . . . . . . . . . . 78 + 7.4.1. File System Replication . . . . . . . . . . . . . . 79 + 7.4.2. File System Migration . . . . . . . . . . . . . . . 80 + 7.4.3. Referrals . . . . . . . . . . . . . . . . . . . . . 80 + 7.5. Location Entries and Server Identity . . . . . . . . . . 81 + 7.6. Additional Client-Side Considerations . . . . . . . . . 82 + 7.7. Effecting File System Transitions . . . . . . . . . . . 83 + 7.7.1. File System Transitions and Simultaneous Access . . 84 + 7.7.2. Filehandles and File System Transitions . . . . . . 84 + 7.7.3. Fileids and File System Transitions . . . . . . . . 85 + 7.7.4. Fsids and File System Transitions . . . . . . . . . 86 + 7.7.5. The Change Attribute and File System Transitions . . 86 + 7.7.6. Lock State and File System Transitions . . . . . . . 87 + 7.7.7. Write Verifiers and File System Transitions . . . . 89 7.7.8. Readdir Cookies and Verifiers and File System - Transitions . . . . . . . . . . . . . . . . . . . . 91 - 7.7.9. File System Data and File System Transitions . . . . 91 - 7.8. Effecting File System Referrals . . . . . . . . . . . . 93 - 7.8.1. Referral Example (LOOKUP) . . . . . . . . . . . . . 93 - 7.8.2. Referral Example (READDIR) . . . . . . . . . . . . . 97 - 7.9. The Attribute fs_locations . . . . . . . . . . . . . . . 99 - 7.9.1. Inferring Transition Modes . . . . . . . . . . . . . 101 - 8. NFS Server Name Space . . . . . . . . . . . . . . . . . . . . 102 - 8.1. Server Exports . . . . . . . . . . . . . . . . . . . . . 103 - 8.2. Browsing Exports . . . . . . . . . . . . . . . . . . . . 103 - 8.3. Server Pseudo Filesystem . . . . . . . . . . . . . . . . 103 - 8.4. Multiple Roots . . . . . . . . . . . . . . . . . . . . . 104 - 8.5. Filehandle Volatility . . . . . . . . . . . . . . . . . 104 - 8.6. Exported Root . . . . . . . . . . . . . . . . . . . . . 104 - 8.7. Mount Point Crossing . . . . . . . . . . . . . . . . . . 105 - 8.8. Security Policy and Name Space Presentation . . . . . . 105 - 9. File Locking and Share Reservations . . . . . . . . . . . . . 106 - 9.1. Opens and Byte-Range Locks . . . . . . . . . . . . . . . 107 - 9.1.1. Client ID . . . . . . . . . . . . . . . . . . . . . 107 - 9.1.2. Server Release of Client ID . . . . . . . . . . . . 110 - 9.1.3. Stateid Definition . . . . . . . . . . . . . . . . . 111 - 9.1.4. lock-owner . . . . . . . . . . . . . . . . . . . . . 118 - 9.1.5. Use of the Stateid and Locking . . . . . . . . . . . 119 - 9.1.6. Sequencing of Lock Requests . . . . . . . . . . . . 121 - 9.1.7. Recovery from Replayed Requests . . . . . . . . . . 122 - 9.1.8. Releasing state-owner State . . . . . . . . . . . . 122 - 9.1.9. Use of Open Confirmation . . . . . . . . . . . . . . 123 - 9.2. Lock Ranges . . . . . . . . . . . . . . . . . . . . . . 124 + Transitions . . . . . . . . . . . . . . . . . . . . 89 + 7.7.9. File System Data and File System Transitions . . . . 89 + 7.8. Effecting File System Referrals . . . . . . . . . . . . 91 + 7.8.1. Referral Example (LOOKUP) . . . . . . . . . . . . . 91 + 7.8.2. Referral Example (READDIR) . . . . . . . . . . . . . 95 + 7.9. The Attribute fs_locations . . . . . . . . . . . . . . . 97 + 7.9.1. Inferring Transition Modes . . . . . . . . . . . . . 99 + 8. NFS Server Name Space . . . . . . . . . . . . . . . . . . . . 100 + 8.1. Server Exports . . . . . . . . . . . . . . . . . . . . . 101 + 8.2. Browsing Exports . . . . . . . . . . . . . . . . . . . . 101 + 8.3. Server Pseudo Filesystem . . . . . . . . . . . . . . . . 101 + 8.4. Multiple Roots . . . . . . . . . . . . . . . . . . . . . 102 + 8.5. Filehandle Volatility . . . . . . . . . . . . . . . . . 102 + 8.6. Exported Root . . . . . . . . . . . . . . . . . . . . . 102 + 8.7. Mount Point Crossing . . . . . . . . . . . . . . . . . . 103 + 8.8. Security Policy and Name Space Presentation . . . . . . 103 + 9. File Locking and Share Reservations . . . . . . . . . . . . . 104 + 9.1. Opens and Byte-Range Locks . . . . . . . . . . . . . . . 105 + 9.1.1. Client ID . . . . . . . . . . . . . . . . . . . . . 105 + 9.1.2. Server Release of Client ID . . . . . . . . . . . . 108 + 9.1.3. Stateid Definition . . . . . . . . . . . . . . . . . 109 + 9.1.4. lock-owner . . . . . . . . . . . . . . . . . . . . . 116 + 9.1.5. Use of the Stateid and Locking . . . . . . . . . . . 117 + 9.1.6. Sequencing of Lock Requests . . . . . . . . . . . . 119 + 9.1.7. Recovery from Replayed Requests . . . . . . . . . . 120 + 9.1.8. Interactions of multiple sequence values . . . . . . 120 + 9.1.9. Releasing state-owner State . . . . . . . . . . . . 121 + 9.1.10. Use of Open Confirmation . . . . . . . . . . . . . . 122 + 9.2. Lock Ranges . . . . . . . . . . . . . . . . . . . . . . 123 9.3. Upgrading and Downgrading Locks . . . . . . . . . . . . 124 - 9.4. Blocking Locks . . . . . . . . . . . . . . . . . . . . . 125 + 9.4. Blocking Locks . . . . . . . . . . . . . . . . . . . . . 124 9.5. Lease Renewal . . . . . . . . . . . . . . . . . . . . . 125 9.6. Crash Recovery . . . . . . . . . . . . . . . . . . . . . 126 - 9.6.1. Client Failure and Recovery . . . . . . . . . . . . 127 + 9.6.1. Client Failure and Recovery . . . . . . . . . . . . 126 9.6.2. Server Failure and Recovery . . . . . . . . . . . . 127 9.6.3. Network Partitions and Recovery . . . . . . . . . . 129 9.7. Recovery from a Lock Request Timeout or Abort . . . . . 135 - 9.8. Server Revocation of Locks . . . . . . . . . . . . . . . 136 + 9.8. Server Revocation of Locks . . . . . . . . . . . . . . . 135 9.9. Share Reservations . . . . . . . . . . . . . . . . . . . 137 - 9.10. OPEN/CLOSE Operations . . . . . . . . . . . . . . . . . 138 + 9.10. OPEN/CLOSE Operations . . . . . . . . . . . . . . . . . 137 9.10.1. Close and Retention of State Information . . . . . . 138 9.11. Open Upgrade and Downgrade . . . . . . . . . . . . . . . 139 9.12. Short and Long Leases . . . . . . . . . . . . . . . . . 140 9.13. Clocks, Propagation Delay, and Calculating Lease Expiration . . . . . . . . . . . . . . . . . . . . . . . 140 9.14. Migration, Replication and State . . . . . . . . . . . . 141 9.14.1. Migration and State . . . . . . . . . . . . . . . . 141 9.14.2. Replication and State . . . . . . . . . . . . . . . 142 - 9.14.3. Notification of Migrated Lease . . . . . . . . . . . 143 + 9.14.3. Notification of Migrated Lease . . . . . . . . . . . 142 9.14.4. Migration and the Lease_time Attribute . . . . . . . 143 10. Client-Side Caching . . . . . . . . . . . . . . . . . . . . . 144 - 10.1. Performance Challenges for Client-Side Caching . . . . . 145 - 10.2. Delegation and Callbacks . . . . . . . . . . . . . . . . 146 + 10.1. Performance Challenges for Client-Side Caching . . . . . 144 + 10.2. Delegation and Callbacks . . . . . . . . . . . . . . . . 145 10.2.1. Delegation Recovery . . . . . . . . . . . . . . . . 147 10.3. Data Caching . . . . . . . . . . . . . . . . . . . . . . 149 - 10.3.1. Data Caching and OPENs . . . . . . . . . . . . . . . 150 - 10.3.2. Data Caching and File Locking . . . . . . . . . . . 151 + 10.3.1. Data Caching and OPENs . . . . . . . . . . . . . . . 149 + 10.3.2. Data Caching and File Locking . . . . . . . . . . . 150 10.3.3. Data Caching and Mandatory File Locking . . . . . . 152 - 10.3.4. Data Caching and File Identity . . . . . . . . . . . 153 - - 10.4. Open Delegation . . . . . . . . . . . . . . . . . . . . 154 + 10.3.4. Data Caching and File Identity . . . . . . . . . . . 152 + 10.4. Open Delegation . . . . . . . . . . . . . . . . . . . . 153 10.4.1. Open Delegation and Data Caching . . . . . . . . . . 156 10.4.2. Open Delegation and File Locks . . . . . . . . . . . 157 - 10.4.3. Handling of CB_GETATTR . . . . . . . . . . . . . . . 158 - 10.4.4. Recall of Open Delegation . . . . . . . . . . . . . 161 - 10.4.5. OPEN Delegation Race with CB_RECALL . . . . . . . . 163 + 10.4.3. Handling of CB_GETATTR . . . . . . . . . . . . . . . 157 + 10.4.4. Recall of Open Delegation . . . . . . . . . . . . . 160 + 10.4.5. OPEN Delegation Race with CB_RECALL . . . . . . . . 162 10.4.6. Clients that Fail to Honor Delegation Recalls . . . 163 10.4.7. Delegation Revocation . . . . . . . . . . . . . . . 164 - 10.5. Data Caching and Revocation . . . . . . . . . . . . . . 165 + 10.5. Data Caching and Revocation . . . . . . . . . . . . . . 164 10.5.1. Revocation Recovery for Write Open Delegation . . . 165 - 10.6. Attribute Caching . . . . . . . . . . . . . . . . . . . 166 - 10.7. Data and Metadata Caching and Memory Mapped Files . . . 168 + 10.6. Attribute Caching . . . . . . . . . . . . . . . . . . . 165 + 10.7. Data and Metadata Caching and Memory Mapped Files . . . 167 10.8. Name Caching . . . . . . . . . . . . . . . . . . . . . . 170 10.9. Directory Caching . . . . . . . . . . . . . . . . . . . 171 - 11. Minor Versioning . . . . . . . . . . . . . . . . . . . . . . 172 - 12. Internationalization . . . . . . . . . . . . . . . . . . . . 175 - 12.1. Use of UTF-8 . . . . . . . . . . . . . . . . . . . . . . 176 - 12.1.1. Relation to Stringprep . . . . . . . . . . . . . . . 176 - 12.1.2. Normalization, Equivalence, and Confusability . . . 177 + 11. Minor Versioning . . . . . . . . . . . . . . . . . . . . . . 171 + 12. Internationalization . . . . . . . . . . . . . . . . . . . . 174 + 12.1. Use of UTF-8 . . . . . . . . . . . . . . . . . . . . . . 175 + 12.1.1. Relation to Stringprep . . . . . . . . . . . . . . . 175 + 12.1.2. Normalization, Equivalence, and Confusability . . . 176 12.2. String Type Overview . . . . . . . . . . . . . . . . . . 179 - 12.2.1. Overall String Class Divisions . . . . . . . . . . . 180 - 12.2.2. Divisions by Typedef Parent types . . . . . . . . . 181 + 12.2.1. Overall String Class Divisions . . . . . . . . . . . 179 + 12.2.2. Divisions by Typedef Parent types . . . . . . . . . 180 12.2.3. Individual Types and Their Handling . . . . . . . . 181 - 12.3. Errors Related to Strings . . . . . . . . . . . . . . . 183 - 12.4. Types with Pre-processing to Resolve Mixture Issues . . 184 - 12.4.1. Processing of Principal Strings . . . . . . . . . . 184 - 12.4.2. Processing of Server Id Strings . . . . . . . . . . 184 - 12.5. String Types without Internationalization Processing . . 185 - 12.6. Types with Processing Defined by Other Internet Areas . 185 - 12.7. String Types with NFS-specific Processing . . . . . . . 186 - 12.7.1. Handling of File Name Components . . . . . . . . . . 187 - 12.7.2. Processing of Link Text . . . . . . . . . . . . . . 196 - 12.7.3. Processing of Principal Prefixes . . . . . . . . . . 197 - 13. Error Values . . . . . . . . . . . . . . . . . . . . . . . . 198 - 13.1. Error Definitions . . . . . . . . . . . . . . . . . . . 198 + 12.3. Errors Related to Strings . . . . . . . . . . . . . . . 182 + 12.4. Types with Pre-processing to Resolve Mixture Issues . . 183 + 12.4.1. Processing of Principal Strings . . . . . . . . . . 183 + 12.4.2. Processing of Server Id Strings . . . . . . . . . . 183 + 12.5. String Types without Internationalization Processing . . 184 + 12.6. Types with Processing Defined by Other Internet Areas . 184 + 12.7. String Types with NFS-specific Processing . . . . . . . 185 + 12.7.1. Handling of File Name Components . . . . . . . . . . 186 + 12.7.2. Processing of Link Text . . . . . . . . . . . . . . 195 + 12.7.3. Processing of Principal Prefixes . . . . . . . . . . 196 + 13. Error Values . . . . . . . . . . . . . . . . . . . . . . . . 197 + 13.1. Error Definitions . . . . . . . . . . . . . . . . . . . 197 13.1.1. General Errors . . . . . . . . . . . . . . . . . . . 199 - 13.1.2. Filehandle Errors . . . . . . . . . . . . . . . . . 201 - 13.1.3. Compound Structure Errors . . . . . . . . . . . . . 202 - 13.1.4. File System Errors . . . . . . . . . . . . . . . . . 203 - 13.1.5. State Management Errors . . . . . . . . . . . . . . 205 - 13.1.6. Security Errors . . . . . . . . . . . . . . . . . . 206 - 13.1.7. Name Errors . . . . . . . . . . . . . . . . . . . . 206 - 13.1.8. Locking Errors . . . . . . . . . . . . . . . . . . . 207 - 13.1.9. Reclaim Errors . . . . . . . . . . . . . . . . . . . 208 - 13.1.10. Client Management Errors . . . . . . . . . . . . . . 209 - 13.1.11. Attribute Handling Errors . . . . . . . . . . . . . 209 - 13.2. Operations and their valid errors . . . . . . . . . . . 210 - 13.3. Callback operations and their valid errors . . . . . . . 217 - 13.4. Errors and the operations that use them . . . . . . . . 217 - 14. NFSv4 Requests . . . . . . . . . . . . . . . . . . . . . . . 222 - 14.1. Compound Procedure . . . . . . . . . . . . . . . . . . . 222 - 14.2. Evaluation of a Compound Request . . . . . . . . . . . . 223 - 14.3. Synchronous Modifying Operations . . . . . . . . . . . . 224 - 14.4. Operation Values . . . . . . . . . . . . . . . . . . . . 224 - 15. NFSv4 Procedures . . . . . . . . . . . . . . . . . . . . . . 224 - 15.1. Procedure 0: NULL - No Operation . . . . . . . . . . . . 224 - 15.2. Procedure 1: COMPOUND - Compound Operations . . . . . . 225 - 15.3. Operation 3: ACCESS - Check Access Rights . . . . . . . 230 - 15.4. Operation 4: CLOSE - Close File . . . . . . . . . . . . 233 - 15.5. Operation 5: COMMIT - Commit Cached Data . . . . . . . . 234 - 15.6. Operation 6: CREATE - Create a Non-Regular File Object . 236 + 13.1.2. Filehandle Errors . . . . . . . . . . . . . . . . . 200 + 13.1.3. Compound Structure Errors . . . . . . . . . . . . . 201 + 13.1.4. File System Errors . . . . . . . . . . . . . . . . . 202 + 13.1.5. State Management Errors . . . . . . . . . . . . . . 204 + 13.1.6. Security Errors . . . . . . . . . . . . . . . . . . 205 + 13.1.7. Name Errors . . . . . . . . . . . . . . . . . . . . 205 + 13.1.8. Locking Errors . . . . . . . . . . . . . . . . . . . 206 + 13.1.9. Reclaim Errors . . . . . . . . . . . . . . . . . . . 207 + 13.1.10. Client Management Errors . . . . . . . . . . . . . . 208 + 13.1.11. Attribute Handling Errors . . . . . . . . . . . . . 208 + 13.2. Operations and their valid errors . . . . . . . . . . . 209 + 13.3. Callback operations and their valid errors . . . . . . . 216 + 13.4. Errors and the operations that use them . . . . . . . . 216 + 14. NFSv4 Requests . . . . . . . . . . . . . . . . . . . . . . . 221 + 14.1. Compound Procedure . . . . . . . . . . . . . . . . . . . 221 + 14.2. Evaluation of a Compound Request . . . . . . . . . . . . 222 + 14.3. Synchronous Modifying Operations . . . . . . . . . . . . 223 + 14.4. Operation Values . . . . . . . . . . . . . . . . . . . . 223 + 15. NFSv4 Procedures . . . . . . . . . . . . . . . . . . . . . . 223 + 15.1. Procedure 0: NULL - No Operation . . . . . . . . . . . . 223 + 15.2. Procedure 1: COMPOUND - Compound Operations . . . . . . 224 + 15.3. Operation 3: ACCESS - Check Access Rights . . . . . . . 229 + 15.4. Operation 4: CLOSE - Close File . . . . . . . . . . . . 232 + 15.5. Operation 5: COMMIT - Commit Cached Data . . . . . . . . 233 + 15.6. Operation 6: CREATE - Create a Non-Regular File Object . 235 15.7. Operation 7: DELEGPURGE - Purge Delegations Awaiting - Recovery . . . . . . . . . . . . . . . . . . . . . . . . 239 - 15.8. Operation 8: DELEGRETURN - Return Delegation . . . . . . 240 - 15.9. Operation 9: GETATTR - Get Attributes . . . . . . . . . 240 - 15.10. Operation 10: GETFH - Get Current Filehandle . . . . . . 242 - 15.11. Operation 11: LINK - Create Link to a File . . . . . . . 243 - 15.12. Operation 12: LOCK - Create Lock . . . . . . . . . . . . 244 - 15.13. Operation 13: LOCKT - Test For Lock . . . . . . . . . . 248 - 15.14. Operation 14: LOCKU - Unlock File . . . . . . . . . . . 250 - 15.15. Operation 15: LOOKUP - Lookup Filename . . . . . . . . . 251 - 15.16. Operation 16: LOOKUPP - Lookup Parent Directory . . . . 253 + Recovery . . . . . . . . . . . . . . . . . . . . . . . . 238 + 15.8. Operation 8: DELEGRETURN - Return Delegation . . . . . . 239 + 15.9. Operation 9: GETATTR - Get Attributes . . . . . . . . . 239 + 15.10. Operation 10: GETFH - Get Current Filehandle . . . . . . 241 + 15.11. Operation 11: LINK - Create Link to a File . . . . . . . 242 + 15.12. Operation 12: LOCK - Create Lock . . . . . . . . . . . . 243 + 15.13. Operation 13: LOCKT - Test For Lock . . . . . . . . . . 247 + 15.14. Operation 14: LOCKU - Unlock File . . . . . . . . . . . 249 + 15.15. Operation 15: LOOKUP - Lookup Filename . . . . . . . . . 250 + 15.16. Operation 16: LOOKUPP - Lookup Parent Directory . . . . 252 15.17. Operation 17: NVERIFY - Verify Difference in Attributes . . . . . . . . . . . . . . . . . . . . . . . 253 - 15.18. Operation 18: OPEN - Open a Regular File . . . . . . . . 255 + 15.18. Operation 18: OPEN - Open a Regular File . . . . . . . . 254 15.19. Operation 19: OPENATTR - Open Named Attribute - Directory . . . . . . . . . . . . . . . . . . . . . . . 265 - 15.20. Operation 20: OPEN_CONFIRM - Confirm Open . . . . . . . 266 - 15.21. Operation 21: OPEN_DOWNGRADE - Reduce Open File Access . 268 - 15.22. Operation 22: PUTFH - Set Current Filehandle . . . . . . 269 - 15.23. Operation 23: PUTPUBFH - Set Public Filehandle . . . . . 270 - 15.24. Operation 24: PUTROOTFH - Set Root Filehandle . . . . . 271 - 15.25. Operation 25: READ - Read from File . . . . . . . . . . 272 - 15.26. Operation 26: READDIR - Read Directory . . . . . . . . . 274 - 15.27. Operation 27: READLINK - Read Symbolic Link . . . . . . 278 - 15.28. Operation 28: REMOVE - Remove Filesystem Object . . . . 279 - 15.29. Operation 29: RENAME - Rename Directory Entry . . . . . 281 - 15.30. Operation 30: RENEW - Renew a Lease . . . . . . . . . . 283 - 15.31. Operation 31: RESTOREFH - Restore Saved Filehandle . . . 284 - 15.32. Operation 32: SAVEFH - Save Current Filehandle . . . . . 285 + Directory . . . . . . . . . . . . . . . . . . . . . . . 264 + 15.20. Operation 20: OPEN_CONFIRM - Confirm Open . . . . . . . 265 + 15.21. Operation 21: OPEN_DOWNGRADE - Reduce Open File Access . 267 + 15.22. Operation 22: PUTFH - Set Current Filehandle . . . . . . 268 + 15.23. Operation 23: PUTPUBFH - Set Public Filehandle . . . . . 269 + 15.24. Operation 24: PUTROOTFH - Set Root Filehandle . . . . . 270 + 15.25. Operation 25: READ - Read from File . . . . . . . . . . 271 + 15.26. Operation 26: READDIR - Read Directory . . . . . . . . . 273 + 15.27. Operation 27: READLINK - Read Symbolic Link . . . . . . 277 + 15.28. Operation 28: REMOVE - Remove Filesystem Object . . . . 278 + 15.29. Operation 29: RENAME - Rename Directory Entry . . . . . 280 + 15.30. Operation 30: RENEW - Renew a Lease . . . . . . . . . . 282 + 15.31. Operation 31: RESTOREFH - Restore Saved Filehandle . . . 283 + 15.32. Operation 32: SAVEFH - Save Current Filehandle . . . . . 284 15.33. Operation 33: SECINFO - Obtain Available Security . . . 285 15.34. Operation 34: SETATTR - Set Attributes . . . . . . . . . 288 15.35. Operation 35: SETCLIENTID - Negotiate Client ID . . . . 291 - 15.36. Operation 36: SETCLIENTID_CONFIRM - Confirm Client ID . 295 + 15.36. Operation 36: SETCLIENTID_CONFIRM - Confirm Client ID . 294 15.37. Operation 37: VERIFY - Verify Same Attributes . . . . . 298 - 15.38. Operation 38: WRITE - Write to File . . . . . . . . . . 300 + 15.38. Operation 38: WRITE - Write to File . . . . . . . . . . 299 15.39. Operation 39: RELEASE_LOCKOWNER - Release Lockowner - State . . . . . . . . . . . . . . . . . . . . . . . . . 304 - 15.40. Operation 10044: ILLEGAL - Illegal operation . . . . . . 305 + State . . . . . . . . . . . . . . . . . . . . . . . . . 303 + 15.40. Operation 10044: ILLEGAL - Illegal operation . . . . . . 304 16. NFSv4 Callback Procedures . . . . . . . . . . . . . . . . . . 305 - 16.1. Procedure 0: CB_NULL - No Operation . . . . . . . . . . 306 + 16.1. Procedure 0: CB_NULL - No Operation . . . . . . . . . . 305 16.2. Procedure 1: CB_COMPOUND - Compound Operations . . . . . 306 16.2.6. Operation 3: CB_GETATTR - Get Attributes . . . . . . 308 16.2.7. Operation 4: CB_RECALL - Recall an Open Delegation . 309 16.2.8. Operation 10044: CB_ILLEGAL - Illegal Callback Operation . . . . . . . . . . . . . . . . . . . . . 310 - 17. Security Considerations . . . . . . . . . . . . . . . . . . . 311 + 17. Security Considerations . . . . . . . . . . . . . . . . . . . 310 18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 312 18.1. Named Attribute Definitions . . . . . . . . . . . . . . 312 18.1.1. Initial Registry . . . . . . . . . . . . . . . . . . 313 18.1.2. Updating Registrations . . . . . . . . . . . . . . . 313 18.2. ONC RPC Network Identifiers (netids) . . . . . . . . . . 313 - 18.2.1. Initial Registry . . . . . . . . . . . . . . . . . . 315 - 18.2.2. Updating Registrations . . . . . . . . . . . . . . . 315 + 18.2.1. Initial Registry . . . . . . . . . . . . . . . . . . 314 + 18.2.2. Updating Registrations . . . . . . . . . . . . . . . 314 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 315 19.1. Normative References . . . . . . . . . . . . . . . . . . 315 - 19.2. Informative References . . . . . . . . . . . . . . . . . 316 + 19.2. Informative References . . . . . . . . . . . . . . . . . 315 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 318 - Appendix B. RFC Editor Notes . . . . . . . . . . . . . . . . . . 319 + Appendix B. RFC Editor Notes . . . . . . . . . . . . . . . . . . 318 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 319 1. Introduction 1.1. Changes since RFC 3530 This document, together with the companion XDR description document - [2], obsoletes RFC 3530 [11] as the authoritative document describing + [2], obsoletes RFC 3530 [10] as the authoritative document describing NFSv4. It does not introduce any over-the-wire protocol changes, in the sense that previously valid requests requests remain valid. However, some requests previously defined as invalid, although not generally rejected, are now explicitly allowed, in that internationalization handling has been generalized and liberalized. The main changes from RFC 3530 are: o The XDR definition has been moved to a companion document [2] o Updates for the latest IETF intellectual property statements @@ -359,47 +360,47 @@ o There is a restructured and more complete explanation of multi- server namespace features. In particular, this explanation explicitly describes handling of inter-server referrals, even where neither migration nor replication is involved. o More liberal handling of internationalization for file names and user and group names, with the elimination of restrictions imposed by stringprep, with the recognition that rules for the forms of these name are the province of the receiving entity. - o Updating handling of domain names to reflect IDNA. + o Updating handling of domain names to reflect IDNA [3]. o Restructuring of string types to more appropriately reflect the reality of required string processing. - o LIPKEY SPKM/3 has been moved from being REQUIRED to OPTIONAL. + o LIPKEY SPKM/3 has been moved from being REQUIRED to being removed. o Some clarification on a client re-establishing callback information to the new server if state has been migrated. o A third edge case was added for Courtesy locks and network partitions. o The definition of stateid was strengthened, which had the side effect of introducing a semantic change in a COMPOUND structure having a current stateid and a saved stateid. 1.2. Changes since RFC 3010 This definition of the NFSv4 protocol replaces or obsoletes the - definition present in [12]. While portions of the two documents have + definition present in [11]. While portions of the two documents have remained the same, there have been substantive changes in others. - The changes made between [12] and this document represent + The changes made between [11] and this document represent implementation experience and further review of the protocol. While some modifications were made for ease of implementation or clarification, most updates represent errors or situations where the - [12] definition were untenable. + [11] definition were untenable. The following list is not all inclusive of all changes but presents some of the most notable changes or additions made: o The state model has added an open_owner4 identifier. This was done to accommodate Posix based clients and the model they use for file locking. For Posix clients, an open_owner4 would correspond to a file descriptor potentially shared amongst a set of processes and the lock_owner4 identifier would correspond to a process that is locking a file. @@ -435,21 +436,21 @@ o Remove use of the pathname4 data type from LOOKUP and OPEN in favor of having the client construct a sequence of LOOKUP operations to achieve the same effect. o Clarification of the internationalization issues and adoption of the new stringprep profile framework. 1.3. NFS Version 4 Goals The NFSv4 protocol is a further revision of the NFS protocol defined - already by versions 2 [13] and 3 [14]. It retains the essential + already by versions 2 [12] and 3 [13]. It retains the essential characteristics of previous versions: design for easy recovery, independent of transport protocols, operating systems and filesystems, simplicity, and good performance. The NFSv4 revision has the following goals: o Improved access and good performance on the Internet. The protocol is designed to transit firewalls easily, perform well where latency is high and bandwidth is low, and scale to very large numbers of clients per server. @@ -485,38 +486,36 @@ authoritative. 1.5. Overview of NFSv4 Features To provide a reasonable context for the reader, the major features of NFSv4 protocol will be reviewed in brief. This will be done to provide an appropriate context for both the reader who is familiar with the previous versions of the NFS protocol and the reader that is new to the NFS protocols. For the reader new to the NFS protocols, there is still a fundamental knowledge that is expected. The reader - should be familiar with the XDR and RPC protocols as described in [3] - and [15]. A basic knowledge of filesystems and distributed + should be familiar with the XDR and RPC protocols as described in [4] + and [14]. A basic knowledge of filesystems and distributed filesystems is expected as well. 1.5.1. RPC and Security As with previous versions of NFS, the External Data Representation (XDR) and Remote Procedure Call (RPC) mechanisms used for the NFSv4 - protocol are those defined in [3] and [15]. To meet end to end - security requirements, the RPCSEC_GSS framework [4] will be used to + protocol are those defined in [4] and [14]. To meet end to end + security requirements, the RPCSEC_GSS framework [5] will be used to extend the basic RPC security. With the use of RPCSEC_GSS, various mechanisms can be provided to offer authentication, integrity, and privacy to the NFS version 4 protocol. Kerberos V5 will be used as - described in [16] to provide one security framework. The LIPKEY GSS- - API mechanism described in [5] will be used to provide for the use of - user password and server public key by the NFSv4 protocol. With the - use of RPCSEC_GSS, other mechanisms may also be specified and used - for NFS version 4 security. + described in [15] to provide one security framework. With the use of + RPCSEC_GSS, other mechanisms may also be specified and used for NFS + version 4 security. To enable in-band security negotiation, the NFSv4 protocol has added a new operation which provides the client a method of querying the server about its policies regarding which security mechanisms must be used for access to the server's filesystem resources. With this, the client can securely match the security mechanism that meets the policies specified at both the client and server. 1.5.2. Procedure and Operation Structure @@ -581,36 +580,35 @@ filehandle being provided by the server and can be prepared to deal with the semantics of each. 1.5.3.2. Attribute Types The NFSv4 protocol has a rich and extensible file object attribute structure, which is divided into REQUIRED, RECOMMENDED, and named attributes (see Section 5). Several (but not all) of the REQUIRED attributes are derived from the - attributes of NFSv3 (see definition of the fattr3 data type in [14]). + attributes of NFSv3 (see definition of the fattr3 data type in [13]). An example of a REQUIRED attribute is the file object's type (Section 5.8.1.2) so that regular files can be distinguished from directories (also known as folders in some operating environments) and other types of objects. REQUIRED attributes are discussed in Section 5.1. - An example of three RECOMMENDED attributes are acl, sacl, and dacl. - These attributes define an Access Control List (ACL) on a file object - ((Section 6). An ACL provides directory and file access control - beyond the model used in NFSv3. The ACL definition allows for - specification of specific sets of permissions for individual users - and groups. In addition, ACL inheritance allows propagation of - access permissions and restriction down a directory tree as file - system objects are created. RECOMMENDED attributes are discussed in - Section 5.2. + An example of the RECOMMENDED attributes is an acl. This attribute + defines an Access Control List (ACL) on a file object ((Section 6). + An ACL provides file access control beyond the model used in NFSv3. + The ACL definition allows for specification of specific sets of + permissions for individual users and groups. In addition, ACL + inheritance allows propagation of access permissions and restriction + down a directory tree as file system objects are created. + RECOMMENDED attributes are discussed in Section 5.2. A named attribute is an opaque byte stream that is associated with a directory or file and referred to by a string name. Named attributes are meant to be used by client applications as a method to associate application-specific data with a regular file or directory. NFSv4.1 modifies named attributes relative to NFSv4.0 by tightening the allowed operations in order to prevent the development of non- interoperable implementations. Named attributes are discussed in Section 5.3. @@ -778,96 +776,104 @@ server for a specific open-owner or lock-owner/open-owner pair for a specific file and type of lock. Verifier: A 64-bit quantity generated by the client that the server can use to determine if the client has restarted and lost all previous lock state. 2. Protocol Data Types The syntax and semantics to describe the data types of the NFS - version 4 protocol are defined in the XDR [15] and RPC [3] documents. + version 4 protocol are defined in the XDR [14] and RPC [4] documents. The next sections build upon the XDR data types to define types and structures specific to this protocol. 2.1. Basic Data Types These are the base NFSv4 data types. - +----------------+--------------------------------------------------+ + +----------------------+--------------------------------------------+ | Data Type | Definition | - +----------------+--------------------------------------------------+ + +----------------------+--------------------------------------------+ | int32_t | typedef int int32_t; | | uint32_t | typedef unsigned int uint32_t; | | int64_t | typedef hyper int64_t; | | uint64_t | typedef unsigned hyper uint64_t; | | attrlist4 | typedef opaque attrlist4<>; | | | Used for file/directory attributes. | | bitmap4 | typedef uint32_t bitmap4<>; | | | Used in attribute array encoding. | | changeid4 | typedef uint64_t changeid4; | | | Used in the definition of change_info4. | | clientid4 | typedef uint64_t clientid4; | - | | Shorthand reference to client identification. | + | | Shorthand reference to client | + | | identification. | | count4 | typedef uint32_t count4; | - | | Various count parameters (READ, WRITE, COMMIT). | + | | Various count parameters (READ, WRITE, | + | | COMMIT). | | length4 | typedef uint64_t length4; | | | Describes LOCK lengths. | | mode4 | typedef uint32_t mode4; | | | Mode attribute data type. | | nfs_cookie4 | typedef uint64_t nfs_cookie4; | | | Opaque cookie value for READDIR. | | nfs_fh4 | typedef opaque nfs_fh4; | | | Filehandle definition. | | nfs_ftype4 | enum nfs_ftype4; | | | Various defined file types. | | nfsstat4 | enum nfsstat4; | | | Return value for operations. | | offset4 | typedef uint64_t offset4; | - | | Various offset designations (READ, WRITE, LOCK, | - | | COMMIT). | + | | Various offset designations (READ, WRITE, | + | | LOCK, COMMIT). | | qop4 | typedef uint32_t qop4; | - | | Quality of protection designation in SECINFO. | + | | Quality of protection designation in | + | | SECINFO. | | sec_oid4 | typedef opaque sec_oid4<>; | - | | Security Object Identifier. The sec_oid4 data | - | | type is not really opaque. Instead it contains | - | | an ASN.1 OBJECT IDENTIFIER as used by GSS-API in | - | | the mech_type argument to GSS_Init_sec_context. | - | | See [6] for details. | + | | Security Object Identifier. The sec_oid4 | + | | data type is not really opaque. Instead | + | | it contains an ASN.1 OBJECT IDENTIFIER as | + | | used by GSS-API in the mech_type argument | + | | to GSS_Init_sec_context. See [6] for | + | | details. | | seqid4 | typedef uint32_t seqid4; | | | Sequence identifier used for file locking. | | utf8string | typedef opaque utf8string<>; | | | UTF-8 encoding for strings. | - | utf8_should | typedef utf8string utf8_should; | - | | String expected to be UTF8 but no validation | - | utf8val_should | typedef utf8string utf8val_should; | - | | String SHOULD be sent UTF8 and SHOULD be | + | utf8_expected | typedef utf8string utf8_expected; | + | | String expected to be UTF-8 but no | + | | validation | + | utf8val_RECOMMENDED4 | typedef utf8string utf8val_RECOMMENDED4; | + | | String SHOULD be sent UTF-8 and SHOULD be | | | validated | - | utf8val_must | typedef utf8string utf8val_must; | - | | String MUST be sent UTF8 and MUST be validated | - | ascii_must | typedef utf8string ascii_must; | + | utf8val_REQUIRED4 | typedef utf8string utf8val_REQUIRED4; | + | | String MUST be sent UTF-8 and MUST be | + | | validated | + | ascii_REQUIRED4 | typedef utf8string ascii_REQUIRED4; | | | String MUST be sent as ASCII and thus is | - | | automatically UTF8 | - | comptag4 | typedef utf8_should comptag4; | - | | Tag should be UTF8 but is not checked | - | component4 | typedef utf8val_should component4; | + | | automatically UTF.8 | + | comptag4 | typedef utf8_expected comptag4; | + | | Tag should be UTF.8 but is not checked | + | component4 | typedef utf8val_RECOMMENDED4 component4; | | | Represents path name components. | - | linktext4 | typedef utf8val_should linktext4; | + | linktext4 | typedef utf8val_RECOMMENDED4 linktext4; | | | Symbolic link contents. | | pathname4 | typedef component4 pathname4<>; | | | Represents path name for fs_locations. | | nfs_lockid4 | typedef uint64_t nfs_lockid4; | - | verifier4 | typedef opaque verifier4[NFS4_VERIFIER_SIZE]; | - | | Verifier used for various operations (COMMIT, | - | | CREATE, EXCHANGE_ID, OPEN, READDIR, WRITE) | - | | NFS4_VERIFIER_SIZE is defined as 8. | - +----------------+--------------------------------------------------+ + | verifier4 | typedef opaque | + | | verifier4[NFS4_VERIFIER_SIZE]; | + | | Verifier used for various operations | + | | (COMMIT, CREATE, EXCHANGE_ID, OPEN, | + | | READDIR, WRITE) NFS4_VERIFIER_SIZE is | + | | defined as 8. | + +----------------------+--------------------------------------------+ End of Base Data Types Table 1 2.2. Structured Data Types 2.2.1. nfstime4 struct nfstime4 { @@ -930,21 +936,21 @@ uint64_t major; uint64_t minor; }; This type is the filesystem identifier that is used as a mandatory attribute. 2.2.6. fs_location4 struct fs_location4 { - utf8val_must server<>; + utf8val_REQUIRED4 server<>; pathname4 rootpath; }; 2.2.7. fs_locations4 struct fs_locations4 { pathname4 fs_root; fs_location4 locations<>; }; @@ -988,23 +994,23 @@ struct clientaddr4 { /* see struct rpcb in RFC 1833 */ string r_netid<>; /* network id */ string r_addr<>; /* universal address */ }; The clientaddr4 structure is used as part of the SETCLIENTID operation to either specify the address of the client that is using a client ID or as part of the callback registration. The r_netid and - r_addr fields are specified in [17], but they are underspecified in + r_addr fields are specified in [16], but they are underspecified in - [17] as far as what they should look like for specific protocols. + [16] as far as what they should look like for specific protocols. For TCP over IPv4 and for UDP over IPv4, the format of r_addr is the US-ASCII string: h1.h2.h3.h4.p1.p2 The prefix, "h1.h2.h3.h4", is the standard textual form for representing an IPv4 address, which is always four octets long. Assuming big-endian ordering, h1, h2, h3, and h4, are respectively, the first through fourth octets each converted to ASCII-decimal. @@ -1018,23 +1024,23 @@ over IPv4 the value of r_netid is the string "udp". For TCP over IPv6 and for UDP over IPv6, the format of r_addr is the US-ASCII string: x1:x2:x3:x4:x5:x6:x7:x8.p1.p2 The suffix "p1.p2" is the service port, and is computed the same way as with universal addresses for TCP and UDP over IPv4. The prefix, "x1:x2:x3:x4:x5:x6:x7:x8", is the standard textual form for - representing an IPv6 address as defined in Section 2.2 of [18]. + representing an IPv6 address as defined in Section 2.2 of [17]. Additionally, the two alternative forms specified in Section 2.2 of - [18] are also acceptable. + [17] are also acceptable. For TCP over IPv6 the value of r_netid is the string "tcp6". For UDP over IPv6 the value of r_netid is the string "udp6". 2.2.11. cb_client4 struct cb_client4 { unsigned int cb_program; clientaddr4 cb_location; }; @@ -1100,31 +1106,32 @@ is read-only. The starting value of the seqid field is undefined. The server is required to increment the seqid field monotonically at each transition of the stateid. This is important since the client will inspect the seqid in OPEN stateids to determine the order of OPEN processing done by the server. 3. RPC and Security Flavor The NFSv4 protocol is a Remote Procedure Call (RPC) application that uses RPC version 2 and the corresponding eXternal Data Representation - (XDR) as defined in [3] and [15]. The RPCSEC_GSS security flavor as - defined in [4] MUST be used as the mechanism to deliver stronger - security for the NFSv4 protocol. + (XDR) as defined in [4] and [14]. The RPCSEC_GSS security flavor as + defined in [5] MUST be implemented as the mechanism to deliver + stronger security for the NFSv4 protocol. However, deployment of + RPCSEC_GSS is optional. 3.1. Ports and Transports Historically, NFSv2 and NFSv3 servers have resided on port 2049. The - registered port 2049 [19] for the NFS protocol SHOULD be the default + registered port 2049 [18] for the NFS protocol SHOULD be the default configuration. Using the registered port for NFS services means the NFS client will not need to use the RPC binding protocols as - described in [17]; this will allow NFS to transit firewalls. + described in [16]; this will allow NFS to transit firewalls. Where an NFSv4 implementation supports operation over the IP network protocol, the supported transports between NFS and IP MUST be among the IETF-approved congestion control transport protocols, which include TCP and SCTP. To enhance the possibilities for interoperability, an NFSv4 implementation MUST support operation over the TCP transport protocol, at least until such time as a standards track RFC revises this requirement to use a different IETF-approved congestion control transport protocol. @@ -1145,21 +1152,21 @@ AUTH_SYS, AUTH_DH, RPCSEC_GSS or any other flavor. Similarly, NFS over TCP server implementations have assumed such a model and thus scale the implementation of TCP connection management in proportion to the number of expected client machines. It is intended that NFSv4 will not modify this connection management model. NFSv4 clients that violate this assumption can expect scaling issues on the server and hence reduced service. Note that for various timers, the client and server should avoid inadvertent synchronization of those timers. For further discussion - of the general issue refer to [20]. + of the general issue refer to [19]. 3.1.1. Client Retransmission Behavior When processing a request received over a reliable transport such as TCP, the NFSv4 server MUST NOT silently drop the request, except if the transport connection has been broken. Given such a contract between NFSv4 clients and servers, clients MUST NOT retry a request unless one or both of the following are true: o The transport connection has been broken @@ -1182,39 +1189,39 @@ or it can break the transport connection and reconnect before re- sending the original request. For callbacks from the server to the client, the same rules apply, but the server doing the callback becomes the client, and the client receiving the callback becomes the server. 3.2. Security Flavors Traditional RPC implementations have included AUTH_NONE, AUTH_SYS, - AUTH_DH, and AUTH_KRB4 as security flavors. With [4] an additional + AUTH_DH, and AUTH_KRB4 as security flavors. With [5] an additional security flavor of RPCSEC_GSS has been introduced which uses the functionality of GSS-API [6]. This allows for the use of various security mechanisms by the RPC layer without the additional implementation overhead of adding RPC security flavors. For NFSv4, the RPCSEC_GSS security flavor MUST be used to enable the mandatory security mechanism. Other flavors, such as, AUTH_NONE, AUTH_SYS, and AUTH_DH MAY be implemented as well. 3.2.1. Security mechanisms for NFSv4 The use of RPCSEC_GSS requires selection of: mechanism, quality of protection, and service (authentication, integrity, privacy). The remainder of this document will refer to these three parameters of the RPCSEC_GSS security as the security triple. 3.2.1.1. Kerberos V5 as a security triple - The Kerberos V5 GSS-API mechanism as described in [16] MUST be + The Kerberos V5 GSS-API mechanism as described in [15] MUST be implemented and provide the following security triples. column descriptions: 1 == number of pseudo flavor 2 == name of pseudo flavor 3 == mechanism's OID 4 == mechanism's algorithm(s) 5 == RPCSEC_GSS service @@ -1227,90 +1234,29 @@ and 56 bit DES for privacy. Note that the pseudo flavor is presented here as a mapping aid to the implementor. Because this NFS protocol includes a method to negotiate security and it understands the GSS-API mechanism, the pseudo flavor is not needed. The pseudo flavor is needed for NFSv3 since the security negotiation is done via the MOUNT protocol. For a discussion of NFS' use of RPCSEC_GSS and Kerberos V5, please - see [21]. + see [20]. Users and implementors are warned that 56 bit DES is no longer considered state of the art in terms of resistance to brute force - attacks. Once a revision to [16] is available that adds support for + attacks. Once a revision to [15] is available that adds support for AES, implementors are urged to incorporate AES into their NFSv4 over Kerberos V5 protocol stacks, and users are similarly urged to migrate to the use of AES. -3.2.1.2. LIPKEY as a security triple - - The LIPKEY GSS-API mechanism as described in [5] MAY be implemented - and provide the following security triples. The definition of the - columns matches those in Section 3.2.1.1. - - 1 2 3 4 5 - -------------------------------------------------------------------- - 390006 lipkey 1.3.6.1.5.5.9 negotiated rpc_gss_svc_none - 390007 lipkey-i 1.3.6.1.5.5.9 negotiated rpc_gss_svc_integrity - 390008 lipkey-p 1.3.6.1.5.5.9 negotiated rpc_gss_svc_privacy - - The mechanism algorithm is listed as "negotiated". This is because - LIPKEY is layered on SPKM-3 and in SPKM-3 [5] the confidentiality and - integrity algorithms are negotiated. Since SPKM-3 specifies HMAC-MD5 - for integrity as MANDATORY, 128 bit cast5CBC for confidentiality for - privacy as MANDATORY, and further specifies that HMAC-MD5 and - cast5CBC MUST be listed first before weaker algorithms, specifying - "negotiated" in column 4 does not impair interoperability. In the - event an SPKM-3 peer does not support the mandatory algorithms, the - other peer is free to accept or reject the GSS-API context creation. - - Because SPKM-3 negotiates the algorithms, subsequent calls to - LIPKEY's GSS_Wrap() and GSS_GetMIC() by RPCSEC_GSS will use a quality - of protection value of 0 (zero). See section 5.2 of [22] for an - explanation. - - LIPKEY uses SPKM-3 to create a secure channel in which to pass a user - name and password from the client to the server. Once the user name - and password have been accepted by the server, calls to the LIPKEY - context are redirected to the SPKM-3 context. See [5] for more - details. - -3.2.1.3. SPKM-3 as a security triple - - The SPKM-3 GSS-API mechanism as described in [5] MAY be implemented - and provide the following security triples. The definition of the - columns matches those in Section 3.2.1.1. - - 1 2 3 4 5 - -------------------------------------------------------------------- - 390009 spkm3 1.3.6.1.5.5.1.3 negotiated rpc_gss_svc_none - 390010 spkm3i 1.3.6.1.5.5.1.3 negotiated rpc_gss_svc_integrity - 390011 spkm3p 1.3.6.1.5.5.1.3 negotiated rpc_gss_svc_privacy - - For a discussion as to why the mechanism algorithm is listed as - "negotiated", see Section 3.2.1.2. - - Because SPKM-3 negotiates the algorithms, subsequent calls to - SPKM-3's GSS_Wrap() and GSS_GetMIC() by RPCSEC_GSS will use a quality - of protection value of 0 (zero). See section 5.2 of [22] for an - explanation. - - Even though LIPKEY is layered over SPKM-3, SPKM-3 is specified as a - mandatory set of triples to handle the situations where the initiator - (the client) is anonymous or where the initiator has its own - certificate. If the initiator is anonymous, there will not be a user - name and password to send to the target (the server). If the - initiator has its own certificate, then using passwords is - superfluous. - 3.3. Security Negotiation With the NFSv4 server potentially offering multiple security mechanisms, the client needs a method to determine or negotiate which mechanism is to be used for its communication with the server. The NFS server may have multiple points within its filesystem name space that are available for use by NFS clients. In turn the NFS server may be configured such that each of these entry points may have different or multiple security mechanisms in use. @@ -1326,32 +1272,31 @@ per filehandle basis, what security triple is to be used for server access. In general, the client will not have to use the SECINFO operation except during initial communication with the server or when the client crosses policy boundaries at the server. It is possible that the server's policies change during the client's interaction therefore forcing the client to negotiate a new security triple. 3.3.2. Security Error Based on the assumption that each NFSv4 client and server MUST - support a minimum set of security (i.e., LIPKEY, SPKM-3, and - Kerberos-V5 all under RPCSEC_GSS), the NFS client will start its - communication with the server with one of the minimal security - triples. During communication with the server, the client may - receive an NFS error of NFS4ERR_WRONGSEC. This error allows the - server to notify the client that the security triple currently being - used is not appropriate for access to the server's filesystem - resources. The client is then responsible for determining what - security triples are available at the server and choose one which is - appropriate for the client. See Section 15.33 for further discussion - of how the client will respond to the NFS4ERR_WRONGSEC error and use - SECINFO. + support a minimum set of security (i.e., Kerberos-V5 under + RPCSEC_GSS), the NFS client will start its communication with the + server with one of the minimal security triples. During + communication with the server, the client may receive an NFS error of + NFS4ERR_WRONGSEC. This error allows the server to notify the client + that the security triple currently being used is not appropriate for + access to the server's filesystem resources. The client is then + responsible for determining what security triples are available at + the server and choose one which is appropriate for the client. See + Section 15.33 for further discussion of how the client will respond + to the NFS4ERR_WRONGSEC error and use SECINFO. 3.3.3. Callback RPC Authentication Except as noted elsewhere in this section, the callback RPC (described later) MUST mutually authenticate the NFS server to the principal that acquired the client ID (also described later), using the security flavor the original SETCLIENTID operation used. For AUTH_NONE, there are no principals, so this is a non-issue. @@ -1361,106 +1306,66 @@ For AUTH_DH, one commonly used convention is that the server uses the credential corresponding to this AUTH_DH principal: unix.host@domain where host and domain are variables corresponding to the name of server host and directory services domain in which it lives such as a Network Information System domain or a DNS domain. - Because LIPKEY is layered over SPKM-3, it is permissible for the - server to use SPKM-3 and not LIPKEY for the callback even if the - client used LIPKEY for SETCLIENTID. - Regardless of what security mechanism under RPCSEC_GSS is being used, the NFS server, MUST identify itself in GSS-API via a GSS_C_NT_HOSTBASED_SERVICE name type. GSS_C_NT_HOSTBASED_SERVICE names are of the form: service@hostname For NFS, the "service" element is nfs Implementations of security mechanisms will convert nfs@hostname to - various different forms. For Kerberos V5 and LIPKEY, the following - form is RECOMMENDED: + various different forms. For Kerberos V5, the following form is + RECOMMENDED: nfs/hostname For Kerberos V5, nfs/hostname would be a server principal in the Kerberos Key Distribution Center database. This is the same principal the client acquired a GSS-API context for when it issued the SETCLIENTID operation, therefore, the realm name for the server principal must be the same for the callback as it was for the SETCLIENTID. - For LIPKEY, this would be the username passed to the target (the NFS - version 4 client that receives the callback). - - It should be noted that LIPKEY may not work for callbacks, since the - LIPKEY client uses a user id/password. If the NFS client receiving - the callback can authenticate the NFS server's user name/password - pair, and if the user that the NFS server is authenticating to has a - public key certificate, then it works. - - In situations where the NFS client uses LIPKEY and uses a per-host - principal for the SETCLIENTID operation, instead of using LIPKEY for - SETCLIENTID, it is RECOMMENDED that SPKM-3 with mutual authentication - be used. This effectively means that the client will use a - certificate to authenticate and identify the initiator to the target - on the NFS server. Using SPKM-3 and not LIPKEY has the following - advantages: - - o When the server does a callback, it must authenticate to the - principal used in the SETCLIENTID. Even if LIPKEY is used, - because LIPKEY is layered over SPKM-3, the NFS client will need to - have a certificate that corresponds to the principal used in the - SETCLIENTID operation. From an administrative perspective, having - a user name, password, and certificate for both the client and - server is redundant. - - o LIPKEY was intended to minimize additional infrastructure - requirements beyond a certificate for the target, and the - expectation is that existing password infrastructure can be - leveraged for the initiator. In some environments, a per-host - password does not exist yet. If certificates are used for any - per-host principals, then additional password infrastructure is - not needed. - - o In cases when a host is both an NFS client and server, it can - share the same per-host certificate. - 4. Filehandles The filehandle in the NFS protocol is a per server unique identifier for a filesystem object. The contents of the filehandle are opaque to the client. Therefore, the server is responsible for translating the filehandle to an internal representation of the filesystem object. 4.1. Obtaining the First Filehandle The operations of the NFS protocol are defined in terms of one or more filehandles. Therefore, the client needs a filehandle to - initiate communication with the server. With the NFSv2 protocol [13] - and the NFSv3 protocol [14], there exists an ancillary protocol to + initiate communication with the server. With the NFSv2 protocol [12] + and the NFSv3 protocol [13], there exists an ancillary protocol to obtain this first filehandle. The MOUNT protocol, RPC program number 100005, provides the mechanism of translating a string based filesystem path name to a filehandle which can then be used by the NFS protocols. The MOUNT protocol has deficiencies in the area of security and use via firewalls. This is one reason that the use of the public - filehandle was introduced in [23] and [24]. With the use of the + filehandle was introduced in [21] and [22]. With the use of the public filehandle in combination with the LOOKUP operation in the NFSv2 and NFSv3 protocols, it has been demonstrated that the MOUNT protocol is unnecessary for viable interaction between NFS client and server. Therefore, the NFSv4 protocol will not use an ancillary protocol for translation from string based path names to a filehandle. Two special filehandles will be used as starting points for the NFS client. @@ -1797,25 +1702,23 @@ normal READ and WRITE operations using the filehandles and stateids returned by OPEN. Named attributes and the named attribute directory may have their own (non-named) attributes. Each of these objects must have all of the REQUIRED attributes and may have additional RECOMMENDED attributes. However, the set of attributes for named attributes and the named attribute directory need not be, and typically will not be, as large as that for other objects in that file system. - Named attributes and the named attribute directory might be the - target of delegations (in the case of the named attribute directory - these will be directory delegations). However, since granting of - delegations is at the server's discretion, a server need not support - delegations on named attributes or the named attribute directory. + Named attributes might be the target of delegations. However, since + granting of delegations is at the server's discretion, a server need + not support delegations on named attributes. It is RECOMMENDED that servers support arbitrary named attributes. A client should not depend on the ability to store any named attributes in the server's file system. If a server does support named attributes, a client that is also able to handle them should be able to copy a file's data and metadata with complete transparency from one location to another; this would imply that names allowed for regular directory entries are valid for named attribute names as well. @@ -1901,21 +1804,21 @@ 5.6. REQUIRED Attributes - List and Definition References The list of REQUIRED attributes appears in Table 2. The meaning of the columns of the table are: o Name: The name of attribute o Id: The number assigned to the attribute. In the event of conflicts between the assigned number and [2], the latter is likely authoritative, but should be resolved with Errata to this - document and/or [2]. See [25] for the Errata process. + document and/or [2]. See [23] for the Errata process. o Data Type: The XDR data type of the attribute. o Acc: Access allowed to the attribute. R means read-only (GETATTR may retrieve, SETATTR may not set). W means write-only (SETATTR may set, GETATTR may not retrieve). R W means read/write (GETATTR may retrieve, SETATTR may set). o Defined in: The section of this specification that describes the attribute. @@ -2031,21 +1933,21 @@ Within the explanatory text and operation descriptions, the following phrases will be used with the meanings given below: o The phrase "is a directory" means that the object's type attribute is NF4DIR or NF4ATTRDIR. o The phrase "is a special file" means that the object's type attribute is NF4BLK, NF4CHR, NF4SOCK, or NF4FIFO. - o The phrase "is an ordinary file" means that the object's type + o The phrase "is an regular file" means that the object's type attribute is NF4REG or NF4NAMEDATTR. 5.8.1.3. Attribute 2: fh_expire_type Server uses this to specify filehandle expiration behavior to the client. See Section 4 for additional description. 5.8.1.4. Attribute 3: change A value created by the server that the client can use to determine if @@ -2332,21 +2234,21 @@ 5.8.2.33. Attribute 47: time_access The time_access attribute represents the time of last access to the object by a READ operation sent to the server. The notion of what is an "access" depends on the server's operating environment and/or the server's file system semantics. For example, for servers obeying Portable Operating System Interface (POSIX) semantics, time_access would be updated only by the READ and READDIR operations and not any of the operations that modify the content of the object [16], [17], - [26], [27], [28]. Of course, setting the corresponding + [24], [25], [26]. Of course, setting the corresponding time_access_set attribute is another way to modify the time_access attribute. Whenever the file object resides on a writable file system, the server should make its best efforts to record time_access into stable storage. However, to mitigate the performance effects of doing so, and most especially whenever the server is satisfying the read of the object's content from its cache, the server MAY cache access time updates and lazily write them to stable storage. It is also acceptable to give administrators of the server the option to disable @@ -2381,21 +2283,21 @@ 5.8.2.40. Attribute 54: time_modify_set Sets the time of last modification to the object. SETATTR use only. 5.9. Interpreting owner and owner_group The RECOMMENDED attributes "owner" and "owner_group" (and also users and groups within the "acl" attribute) are represented in terms of a UTF-8 string. To avoid a representation that is tied to a particular underlying implementation at the client or server, the use of the - UTF-8 string has been chosen. Note that section 6.1 of RFC 2624 [29] + UTF-8 string has been chosen. Note that section 6.1 of RFC 2624 [27] provides additional rationale. It is expected that the client and server will have their own local representation of owner and owner_group that is used for local storage or presentation to the end user. Therefore, it is expected that when these attributes are transferred between the client and server, the local representation is translated to a syntax of the form "user@dns_domain". This will allow for a client and server that do not use the same local representation the ability to translate to a common syntax that can be interpreted by both. @@ -2458,71 +2360,71 @@ Internationalization issues (for a general discussion of which see Section 12) make this impossible and the client needs to take note of the following situations: o The string representing the domain may be converted to equivalent U-label, if presented using a form other a a U-label. See Section 12.6 for details. o The user or group may be returned in a different form, due to normalization issues, although it will always be a canonically - equivalent string. See See Section 12.7.3 for details. + equivalent string. See Section 12.7.3 for details. In the case where there is no translation available to the client or server, the attribute value will be constructed without the "@". Therefore, the absence of the "@" from the owner or owner_group attribute signifies that no translation was available at the sender and that the receiver of the attribute should not use that string as a basis for translation into its own internal format. Even though the attribute value cannot be translated, it may still be useful. In the case of a client, the attribute string may be used for local display of ownership. To provide a greater degree of compatibility with NFSv3, which identified users and groups by 32-bit unsigned user identifiers and - group identifiers, owner and group strings that consist of decimal - numeric values with no leading zeros can be given a special - interpretation by clients and servers that choose to provide such - support. The receiver may treat such a user or group string as + group identifiers, owner and group strings that consist of ASCII- + encoded decimal numeric values with no leading zeros can be given a + special interpretation by clients and servers that choose to provide + such support. The receiver may treat such a user or group string as representing the same user as would be represented by an NFSv3 uid or gid having the corresponding numeric value. A server SHOULD reject such a numeric value if the security mechanism is kerberized. I.e., in such a scenario, the client will already need to form "user@domain" strings. For any other security mechanism, the server SHOULD accept such numeric values. As an implementation note, the server could make such an acceptance be configurable. If the server does not support numeric values or if it is configured off, then it MUST return an NFS4ERR_BADOWNER error. If the security mechanism is kerberized and the client attempts to use the special form, then the server SHOULD return an NFS4ERR_BADOWNER error when there is a valid translation for the user or owner designated in this way. In that case, the client must use the appropriate user@domain string and not the special form for compatibility. The client MUST always accept numeric values if the security - mechanism is not kerberized. A client can determine if a server - supports such a mechanism by first attempting to provide a numeric - value and only if it is rejected with an NFS4ERR_BADOWNER error, then - providing a name value. After the first detection of such an error, - the client should only use the special form. + mechanism is not RPCSEC_GSS. A client can determine if a server + supports numeric identifiers by first attempting to provide a numeric + identifier. If this attempt rejected with an NFS4ERR_BADOWNER error, + the the client should only use named identifiers of the form "user@ + dns_domain". The owner string "nobody" may be used to designate an anonymous user, which will be associated with a file created by a security principal that cannot be mapped through normal means to the owner attribute. 5.10. Character Case Attributes With respect to the case_insensitive and case_preserving attributes, each UCS-4 character (which UTF-8 encodes) has a "long descriptive - name" RFC1345 [30] which may or may not include the word "CAPITAL" or + name" RFC1345 [28] which may or may not include the word "CAPITAL" or "SMALL". The presence of SMALL or CAPITAL allows an NFS server to implement unambiguous and efficient table driven mappings for case insensitive comparisons, and non-case-preserving storage, although there are variations that occur additional characters with a name including "SMALL" or "CAPITAL" are added in a subsequent version of Unicode. For general character handling and internationalization issues, see Section 12. For details regarding case mapping, see the section Case-based Mapping Used for Component4 Strings. @@ -2587,22 +2489,23 @@ typedef uint32_t acetype4; typedef uint32_t aceflag4; typedef uint32_t acemask4; struct nfsace4 { acetype4 type; aceflag4 flag; acemask4 access_mask; - utf8val_must who; + utf8val_REQUIRED4 who; }; + To determine if a request succeeds, the server processes each nfsace4 entry in order. Only ACEs which have a "who" that matches the requester are considered. Each ACE is processed until all of the bits of the requester's access have been ALLOWED. Once a bit (see below) has been ALLOWED by an ACCESS_ALLOWED_ACE, it is no longer considered in the processing of later ACEs. If an ACCESS_DENIED_ACE is encountered where the requester's access still has unALLOWED bits in common with the "access_mask" of the ACE, the request is denied. When the ACL is fully processed, if there are bits in the requester's mask that have not been ALLOWED or DENIED, access is denied. @@ -2869,30 +2773,20 @@ exists depends on the ability to look it up, therefore, users also need the ACE4_READ_NAMED_ATTRS permission in order to create a named attribute directory. ACE4_EXECUTE Operation(s) affected: READ - OPEN - - REMOVE - - RENAME - - LINK - - CREATE - Discussion: Permission to execute a file. Servers SHOULD allow a user the ability to read the data of the file when only the ACE4_EXECUTE access mask bit is allowed. This is because there is no way to execute a file without reading the contents. Though a server may treat ACE4_EXECUTE and ACE4_READ_DATA bits identically when deciding to permit a READ operation, it SHOULD still allow the two bits to be set @@ -2913,20 +2807,30 @@ Rather than: nfsuser:ACE4_EXECUTE/ACE4_READ_DATA:ALLOW ACE4_EXECUTE Operation(s) affected: LOOKUP + OPEN + + REMOVE + + RENAME + + LINK + + CREATE + Discussion: Permission to traverse/search a directory. ACE4_DELETE_CHILD Operation(s) affected: REMOVE @@ -3024,22 +2927,41 @@ chgrp(). ACE4_SYNCHRONIZE Operation(s) affected: NONE Discussion: - Permission to access file locally at the server with - synchronized reads and writes. + Permission to use the file object as a synchronization + primitive for interprocess communication. This permission is + not enforced or interpreted by the NFSv4.0 server on behalf of + the client. + + Typically, the ACE4_SYNCHRONIZE permission is only meaningful + on local file systems, i.e., file systems not accessed via + NFSv4.0. The reason that the permission bit exists is that + some operating environments, such as Windows, use + ACE4_SYNCHRONIZE. + + For example, if a client copies a file that has + ACE4_SYNCHRONIZE set from a local file system to an NFSv4.0 + server, and then later copies the file from the NFSv4.0 server + to a local file system, it is likely that if ACE4_SYNCHRONIZE + was set in the original file, the client will want it set in + the second copy. The first copy will not have the permission + set unless the NFSv4.0 server has the means to set the + ACE4_SYNCHRONIZE bit. The second copy will not have the + permission set unless the NFSv4.0 server has the means to + retrieve the ACE4_SYNCHRONIZE bit. Server implementations need not provide the granularity of control that is implied by this list of masks. For example, POSIX-based systems might not distinguish ACE4_APPEND_DATA (the ability to append to a file) from ACE4_WRITE_DATA (the ability to modify existing contents); both masks would be tied to a single "write" permission. When such a server returns attributes to the client, it would show both ACE4_APPEND_DATA and ACE4_WRITE_DATA if and only if the write permission is enabled. @@ -3922,21 +3844,21 @@ limit the changes seen by the client, to those that are less aggressive, use more standard methods of replicating data, and impose a greater burden on the client to adapt to the transition. The NFSv4 protocol does not impose choices on clients and servers with regard to that spectrum of transition methods. In fact, there are many valid choices, depending on client and application requirements and their interaction with server implementation choices. The NFSv4.0 protocol does not provide the servers a means of communicating the transition methods. In the NFSv4.1 protocol - [31], an additional attribute "fs_locations_info" is presented, which + [29], an additional attribute "fs_locations_info" is presented, which will define the specific choices that can be made, how these choices are communicated to the client, and how the client is to deal with any discontinuities. In the sections below, references will be made to various possible server implementation choices as a way of illustrating the transition scenarios that clients may deal with. The intent here is not to define or limit server implementations but rather to illustrate the range of issues that clients may face. Again, as the NFSv4.0 protocol does not have an explicit means of communicating these @@ -4599,21 +4521,21 @@ The attributes for entry "path" will not contain size or time_modify because these attributes are not available within an absent file system. 7.9. The Attribute fs_locations The fs_locations attribute is structured in the following way: struct fs_location4 { - utf8val_must server<>; + utf8val_REQUIRED4 server<>; pathname4 rootpath; }; struct fs_locations4 { pathname4 fs_root; fs_location4 locations<>; }; The fs_location4 data type is used to represent the location of a file system by providing a server name and the path to the root of @@ -4898,21 +4821,21 @@ For the case of the use of multiple, disjoint security mechanisms in the server's resources, the security for a particular object in the server's namespace should be the union of all security mechanisms of all direct descendants. 9. File Locking and Share Reservations Integrating locking into the NFS protocol necessarily causes it to be stateful. With the inclusion of share reservations the protocol becomes substantially more dependent on state than the traditional - combination of NFS and NLM (Network Lock Manager) [32]. There are + combination of NFS and NLM (Network Lock Manager) [30]. There are three components to making this state manageable: o clear division between client and server o ability to reliably detect inconsistency in state between client and server o simple and robust recovery mechanisms In this model, the server owns the state information. The client @@ -4978,20 +4901,25 @@ CLAIM_DELEGATE_PREV claim type, all delegation state associated with same client with the same identity. For discussion of delegation state recovery, see Section 10.2.1. Owners of opens and owners of byte-range locks are separate entities and remain separate even if the same opaque arrays are used to designate owners of each. The protocol distinguishes between open- owners (represented by open_owner4 structures) and lock-owners (represented by lock_owner4 structures). + Both sorts of owners consist of a clientid and an opaque owner + string. For each client, the set of distinct owner values used with + that client constitutes the set of owners of that type, for the given + client. + Each open is associated with a specific open-owner while each byte- range lock is associated with a lock-owner and an open-owner, the latter being the open-owner associated with the open file under which the LOCK operation was done. Client identification is encapsulated in the following structure: struct nfs_client_id4 { verifier4 verifier; opaque id; @@ -5640,33 +5567,34 @@ for the first request issued for any given state-owner. Note that for requests that contain a sequence number, for each state-owner, there should be no more than one outstanding request. If a request (r) with a previous sequence number (r < L) is received, it is rejected with the return of error NFS4ERR_BAD_SEQID. Given a properly-functioning client, the response to (r) must have been received before the last request (L) was sent. If a duplicate of last request (r == L) is received, the stored response is returned. + If a request beyond the next sequence (r == L + 2) is received, it is rejected with the return of error NFS4ERR_BAD_SEQID. Sequence history is reinitialized whenever the SETCLIENTID/SETCLIENTID_CONFIRM sequence changes the client verifier. Since the sequence number is represented with an unsigned 32-bit integer, the arithmetic involved with the sequence number is mod 2^32. For an example of modulo arithmetic involving sequence numbers - see [33]. + see [31]. It is critical the server maintain the last response sent to the client to provide a more reliable cache of duplicate non-idempotent - requests than that of the traditional cache described in [34]. The + requests than that of the traditional cache described in [32]. The traditional duplicate request cache uses a least recently used algorithm for removing unneeded requests. However, the last lock request and response on a given state-owner must be cached as long as the lock state exists on the server. The client MUST monotonically increment the sequence number for the CLOSE, LOCK, LOCKU, OPEN, OPEN_CONFIRM, and OPEN_DOWNGRADE operations. This is true even in the event that the previous operation that used the sequence number received an error. The only exception to this rule is if the previous operation received one of @@ -5681,41 +5609,106 @@ the methods described above, there are no risks of a Byzantine router re-sending old requests. The server need only maintain the (state- owner, sequence number) state as long as there are open files or closed files with locks outstanding. LOCK, LOCKU, OPEN, OPEN_DOWNGRADE, and CLOSE each contain a sequence number and therefore the risk of the replay of these operations resulting in undesired effects is non-existent while the server maintains the state-owner state. -9.1.8. Releasing state-owner State +9.1.8. Interactions of multiple sequence values + + Some Operations may have multiple sources of data for request + sequence checking and retrannsmision determination. Some Operations + have multiple sequence values associated with multiple types of + state-owners. In addition, such Operations may also have a stateid + with its own seqid value, that will be checked for validity. + + As noted above, there may be multiple sequence values to check The + following rules should be followed by the server in processing these + multiple sequence values within a single operation. + + o When a sequence value associated with a state-owner is unavailable + for checking because the state-owner is unknown to the server, it + take no part in the comparison. Similarly, when the stateid seqid + is given as zero, the stateid seqid takes no part in the checking. + + o When any of the state-owner sequence values are invalid, + NFS4ERR_BADSEQ is returned. When a stateid sequence is checked, + NFSS4ERR_BAD_STATEID, or NFS4ERR_OLDSTATEID is returned as + appropriate, but NFS4ERR_BADSEQ has priority. + + o When any one of the sequence values matches a previous request, + for a state-owner, it is treated a retransmission and not re- + executed. When the type of the operation doe not match that + originally used, NFS4ERR_BADSEQ is returned. When the server can + determine that the request differs from the original it may return + NFS4ERR_BADSEQ. + + o When multiple of the sequence values match previous operations, + but the operations are not the same, NFS4ERR_BADSEQ is returned. + + o When there are no available sequence values available for + comparison and the operation is an OPEN, the server indicates to + the client that an OPEN_CONFRIM is required, unless it can + conclusively determine that confirmation is not required (e.g., by + knowing that no open-owner state has ever been released for the + current clientid). + + For other operations, lack of available sequence values for + checking can only result from specification of a stateid with a + sequence value of zero. + + Because specification of stateids with a sequence value of zero can + result in no sequence checking under certain conditions, clients + should avoid using them in connection with operations in which state- + owners are used together with state-owner sequence values. + +9.1.9. Releasing state-owner State When a particular state-owner no longer holds open or file locking state at the server, the server may choose to release the sequence number state associated with the state-owner. The server may make this choice based on lease expiration, for the reclamation of server - memory, or other implementation specific details. In any event, the - server is able to do this safely only when the state-owner no longer - is being utilized by the client. The server may choose to hold the - state-owner state in the event that retransmitted requests are - received. However, the period to hold this state is implementation - specific. + memory, or other implementation specific details. Note that when + this is done, a retransmitted request, normally identified by a + matching state-owner sequence may not be correctly recognized, so + that the client will not receive the original response that it would + have if the state-owner state was not released. + + If the server were able to be sure that a given state-owner would + never again be used by a client, such an issue could not arise. Even + when the state-owner state is released and the client subsequently + uses that state-owner, retransmitted requests will be detected as + invalid and the request not executed, although the client may have a + recovery path that is more complicated than simply getting the + original response back transparently. + + In any event, the server is able to safely release state-owner state + (in the sense that retransmitted requests will not be erroneously + acted upon) when the state-owner no currently being utilized by the + client (i.e., there are no open files associated with an open-owner + and no lock stateids associated with a lock-owner). The server may + choose to hold the state-owner state in order to simplify the + recovery path, in the case in which retransmissions of currently + active requests are received. However, the period it chooses to hold + this state is implementation specific. In the case that a LOCK, LOCKU, OPEN_DOWNGRADE, or CLOSE is retransmitted after the server has previously released the state- owner state, the server will find that the state-owner has no files open and an error will be returned to the client. If the state-owner does have a file open, the stateid will not match and again an error is returned to the client. -9.1.9. Use of Open Confirmation +9.1.10. Use of Open Confirmation In the case that an OPEN is retransmitted and the open-owner is being used for the first time or the open-owner state has been previously released by the server, the use of the OPEN_CONFIRM operation will prevent incorrect behavior. When the server observes the use of the open-owner for the first time, it will direct the client to perform the OPEN_CONFIRM for the corresponding OPEN. This sequence establishes the use of a open-owner and associated sequence number. Since the OPEN_CONFIRM sequence connects a new open-owner on the server with an existing open-owner on a client, the sequence number @@ -5992,21 +5985,21 @@ requests to be processed during the grace period, it MUST determine that no lock subsequently reclaimed will be rejected and that no lock subsequently reclaimed would have prevented any I/O operation processed during the grace period. Clients should be prepared for the return of NFS4ERR_GRACE errors for non-reclaim lock and I/O requests. In this case the client should employ a retry mechanism for the request. A delay (on the order of several seconds) between retries should be used to avoid overwhelming the server. Further discussion of the general issue is included in - [20]. The client must account for the server that is able to perform + [19]. The client must account for the server that is able to perform I/O and non-reclaim locking requests within the grace period as well as those that cannot do so. A reclaim-type locking request outside the server's grace period can only succeed if the server can guarantee that no conflicting lock or I/O request has been granted since reboot or restart. A server may, upon restart, establish a new value for the lease period. Therefore, clients should, once a new client ID is established, refetch the lease_time attribute and use it as the basis @@ -6058,21 +6051,21 @@ o Server's responsibility: A server MUST NOT allow a client to reclaim a lock unless it knows that it could not have since granted a conflicting lock. However, in deciding whether a conflicting lock could have been granted, it is permitted to assume its clients are responsible, as above. A server may consider a client's lease "successfully established" once it has received an open operation from that client. The next sections give examples showing what can go wrong if these - responsibilites are neglected, and provides examples of server + responsibilities are neglected, and provides examples of server implementation strategies that could meet a server's responsibilities. 9.6.3.1.1. First Server Edge Condition The first edge condition has the following scenario: 1. Client A acquires a lock. 2. Client A and server experience mutual network partition, such @@ -7782,21 +7772,21 @@ sufficient disk space is available within the target filesystem. Such saving may also be restricted to situations when the client has sufficient buffering resources to keep the cached copy available until it is properly stored to the target filesystem. 10.6. Attribute Caching The attributes discussed in this section do not include named attributes. Individual named attributes are analogous to files and caching of the data for these needs to be handled just as data - caching is for ordinary files. Similarly, LOOKUP results from an + caching is for regular files. Similarly, LOOKUP results from an OPENATTR directory are to be cached on the same basis as any other pathnames and similarly for directory contents. Clients may cache file attributes obtained from the server and use them to avoid subsequent GETATTR requests. Such caching is write through in that modification to file attributes is always done by means of requests to the server and should not be done locally and cached. The exception to this are modifications to attributes that are intimately connected with data caching. Therefore, extending a file by writing data to the local data cache is reflected immediately @@ -8356,21 +8345,21 @@ equivalence classes defined by the chosen equivalence relation. In the NFSv4 protocol, handling of issues related to internationalization with regard to normalization follows one of two basic patterns: o For strings whose function is related to other internet standards, such as server and domain naming, the normalization form defined by the appropriate internet standards is used. For server and domain naming, this involves normalization form NFKC as specified - in [10] + in [3] o For other strings, particular those passed by the server to file system implementations, normalization requirements are the province of the file system and the job of this specification is not to specify a particular form but to make sure that interoperability is maximized, even when clients and server-based file systems have different preferences. A related but distinct issue concerns string confusability. This can occur when two strings (including single-character strings) having a @@ -8402,21 +8391,21 @@ (U+0070) (also with MATHEMATICAL BOLD SMALL P (U+1D429) and GREEK SMALL LETTER RHO (U+1D56, for good measure). NFSv4, as it does with normalization, takes a two-part approach to this issue: o For strings whose function is related to other internet standards, such as server and domain naming, any string processing to address the confusability issue is defined by the appropriate internet standards is used. For server and domain naming, this is the - responsibility of IDNA as described in [10]. + responsibility of IDNA as described in [3]. o For other strings, particularly those passed by the server to file system implementations, any such preparation requirements including the choice of how, or whether to address the confusability issue, are the responsibility of the file system to define, and for this specification to try to add its own set would add unacceptably to complexity, and make many files accessible locally and by other remote file access protocols, inaccessible by NFSv4. This specification defines how the protocol maximizes interoperability in the face of different file system @@ -8477,57 +8467,57 @@ specific Processing". 12.2.2. Divisions by Typedef Parent types There are a number of different string types within NFSv4 and internationalization handling will be different for different types of strings. Each the types will be in one of four groups based on the parent type that specifies the nature of its relationship to utf8 and ascii. - utf8_should/USHOULD: indicating that strings of this type SHOULD be - UTF-8 but clients and servers will not check for valid UTF-8 + utf8_expected/USHOULD: indicating that strings of this type SHOULD + be UTF-8 but clients and servers will not check for valid UTF-8 encoding. - utf8val_should/UVSHOULD: indicating that strings of this type SHOULD - be and generally will be in the form of the UTF-8 encoding of - Unicode. Strings in most cases will be checked by the server for - valid UTF-8 but for certain file systems, such checking may be + utf8val_RECOMMENDED4/UVSHOULD: indicating that strings of this type + SHOULD be and generally will be in the form of the UTF-8 encoding + of Unicode. Strings in most cases will be checked by the server + for valid UTF-8 but for certain file systems, such checking may be inhibited. - utf8val_must/UVMUST: indicating that strings of this type MUST be in - the form of the UTF-8 encoding of Unicode. Strings will be + utf8val_REQUIRED4/UVMUST: indicating that strings of this type MUST + be in the form of the UTF-8 encoding of Unicode. Strings will be checked by the server for valid UTF-8 and the server SHOULD ensure that when sent to the client, they are valid UTF-8. - ascii_must/ASCII: indicating that strings of this type MUST be pure - ASCII, and thus automatically UTF-8. The processing of these - string must ensure that they are only have ASCII characters but - this need not be a separate step if any normally required check - for validity inherently assures that only ASCII characters are - present. + ascii_REQUIRED4/ASCII: indicating that strings of this type MUST be + sent and validated as ASCII, and thus are automatically UTF-8. + The processing of these string must ensure that they are only have + ASCII characters but this need not be a separate step if any + normally required check for validity inherently assures that only + ASCII characters are present. In those cases where UTF-8 is not required, USHOULD and UVSHOULD, and strings that are not valid UTF-8 are received and accepted, the receiver MUST NOT modify the strings. For example, setting particular bits such as the high-order bit to zero MUST NOT be done. 12.2.3. Individual Types and Their Handling The first table outlines the handling for the primary string types, i.e., those not derived as a prefix or a suffix from a mixture type. +-----------------+----------+-------+------------------------------+ | Type | Parent | Class | Explanation | +-----------------+----------+-------+------------------------------+ - | comptag4 | USHOULD | NIP | Should be utf8 but no | - | | | | validation by server or | + | comptag4 | USHOULD | NIP | Tag expected to be UTF-8but | + | | | | no validation by server or | | | | | client is to be done. | | component4 | UVSHOULD | NFS | Should be utf8 but clients | | | | | may need to access file | | | | | systems with a different | | | | | name structure, such as file | | | | | systems that have non-utf8 | | | | | names. | | linktext4 | UVSHOULD | NFS | Should be utf8 since text | | | | | may include name components. | | | | | Because of the need to | @@ -8580,26 +8569,26 @@ | | | | domain. | +----------+--------+------+----------------------------------------+ Table 7 12.3. Errors Related to Strings When the client sends an invalid UTF-8 string in a context in which UTF-8 is REQUIRED, the server MUST return an NFS4ERR_INVAL error. Within the framework of the previous section, this applies to strings - whose type is defined as utf8val_must or ascii_must. When the client - sends an invalid UTF-8 string in a context in which UTF-8 is - RECOMMENDED and the server should test for UTF-8, the server SHOULD - return an NFS4ERR_INVAL error. Within the framework of the previous - section, this applies to strings whose type is defined as - utf8val_should. These situations apply to cases in which + whose type is defined as utf8val_REQUIRED4 or ascii_REQUIRED4. When + the client sends an invalid UTF-8 string in a context in which UTF-8 + is RECOMMENDED and the server should test for UTF-8, the server + SHOULD return an NFS4ERR_INVAL error. Within the framework of the + previous section, this applies to strings whose type is defined as + utf8val_RECOMMENDED4. These situations apply to cases in which inappropriate prefixes are detected and where the count includes trailing bytes that do not constitute a full UCS character. Where the client-supplied string is valid UTF-8 but contains characters that are not supported by the server file system as a value for that string (e.g., names containing characters that have more than two octets on a file system that supports UCS-2 characters only, file name components containing slashes on file systems that do not allow them in file name components), the server MUST return an NFS4ERR_BADCHAR error. @@ -8727,21 +8716,21 @@ When a domain string is part of id@domain or group@domain, the server SHOULD map domain strings which are A-labels or are UTF-8 domain names which are not U-labels, to the corresponding U-label, using ToUnicode(domain) or ToUnicode(ToASCII(domain)). As a result, the domain name returned within a userid on a GETATTR may not match that sent when the userid is set using SETATTR, although when this happens, the domain will be in the form of a U-label. When the server does not map domain strings which are not U-labels into a U-label, which it MAY do, it MUST NOT modify the domain and the domain returned on a GETATTR of the userid MUST be the same as that - used when setting the userid by the SETATTTR. + used when setting the userid by the SETATTR. The server MAY implement VERIFY and NVERIFY without translating internal state to a string form, so that, for example, a user principal which represents a specific numeric user id, will match a different principal string which represents the same numeric user id. 12.7. String Types with NFS-specific Processing For a number of data types within NFSv4, the primary responsibility for internationalization-related handling is that of some entity @@ -9206,28 +9194,28 @@ returning NFS4ERR_BADNAME. Clients may encounter names with bidirectional strings returned in responses from the server. If clients treat such strings as not valid file name components, it is up to the client whether it simply ignores these files or modifies the name component to meet its own rules for acceptable name component strings. 12.7.2. Processing of Link Text - Symbolic link text is defined as utf8val_should and therefore the - server SHOULD validate link text on a CREATE and return NFS4ERR_INVAL - if it is is not valid UTF-8. Note that file systems which treat - names as strings of byte are an exception for which such validation - need not be done. One other situation in which an NFSv4 might choose - (or be configured) not to make such a check is when links within file - system reference names in another which is configured to treat names - as strings of bytes. + Symbolic link text is defined as utf8val_RECOMMENDED4 and therefore + the server SHOULD validate link text on a CREATE and return + NFS4ERR_INVAL if it is is not valid UTF-8. Note that file systems + which treat names as strings of byte are an exception for which such + validation need not be done. One other situation in which an NFSv4 + might choose (or be configured) not to make such a check is when + links within file system reference names in another which is + configured to treat names as strings of bytes. On the other hand, UTF-8 validation of symbolic link text need not be done on the data resulting from a READLINK. Such data might have been stored by an NFS Version 4 server configured to allow non-UTF-8 link text or it might have resulted from symbolic link text stored via local file system access or access via another remote file access protocol. Note that because of the role of the symbolic link, as data stored and read by the user, other sorts of validations or modifications @@ -9629,21 +9616,21 @@ accounting purposes), and where cross-connection between the regions are not allowed. 13.1.5. State Management Errors These errors indicate problems with the stateid (or one of the stateids) passed to a given operation. This includes situations in which the stateid is invalid as well as situations in which the stateid is valid but designates revoked locking state. Depending on the operation, the stateid when valid may designate opens, byte-range - locks, file or directory delegations, layouts, or device maps. + locks, file delegations, layouts, or device maps. 13.1.5.1. NFS4ERR_ADMIN_REVOKED (Error Code 10047) A stateid designates locking state of any type that has been revoked due to administrative interaction, possibly while the lease is valid. 13.1.5.2. NFS4ERR_BAD_STATEID (Error Code 10026) A stateid generated by the current server instance, but which does not designate any locking state (either current or superseded) for a @@ -9776,21 +9763,21 @@ A locking request was attempted which would require the upgrade or downgrade of a lock range already held by the owner when the server does not support atomic upgrade or downgrade of locks. 13.1.8.8. NFS4ERR_LOCK_RANGE (Error Code 10028) A lock request is operating on a range that overlaps in part a currently held lock for the current lock owner and does not precisely match a single such lock where the server does not support this type - of request, and thus does not implement POSIX locking semantics [35]. + of request, and thus does not implement POSIX locking semantics [33]. See Section 15.12.5, Section 15.13.5, and Section 15.14.5 for a discussion of how this applies to LOCK, LOCKT, and LOCKU respectively. 13.1.8.9. NFS4ERR_OPENMODE (Error Code 10038) The client attempted a READ, WRITE, LOCK or other operation not sanctioned by the stateid passed (e.g., writing to a file opened only for read). @@ -11007,21 +10994,21 @@ verifier at each server event or instantiation that may lead to a loss of uncommitted data. Most commonly this occurs when the server is rebooted; however, other events at the server may result in uncommitted data loss as well. On success, the current filehandle retains its value. 15.5.5. IMPLEMENTATION The COMMIT operation is similar in operation and semantics to the - POSIX fsync() [36] system call that synchronizes a file's state with + POSIX fsync() [34] system call that synchronizes a file's state with the disk (file data and metadata is flushed to disk or stable storage). COMMIT performs the same operation for a client, flushing any unsynchronized data and metadata on the server to the server's disk or stable storage for the specified file. Like fsync(), it may be that there is some modified data or no modified data to synchronize. The data may have been synchronized by the server's normal periodic buffer synchronization activity. COMMIT should return NFS4_OK, unless there has been an unexpected error. COMMIT differs from fsync() in that it is possible for the client to @@ -11076,21 +11063,21 @@ left to the implementor. The above description applies to page-cache-based systems as well as buffer-cache-based systems. In those systems, the virtual memory system will need to be modified instead of the buffer cache. 15.6. Operation 6: CREATE - Create a Non-Regular File Object 15.6.1. SYNOPSIS - (cfh), name, type, attrs -> (cfh), change_info, attrs_set + (cfh), name, type, attrs -> (cfh), cinfo, attrset 15.6.2. ARGUMENT union createtype4 switch (nfs_ftype4 type) { case NF4LNK: linktext4 linkdata; case NF4BLK: case NF4CHR: specdata4 devdata; case NF4SOCK: @@ -11162,21 +11149,21 @@ from the principal indicated in the RPC credentials of the call, but the server's operating environment or filesystem semantics may dictate other methods of derivation. Similarly, if createattrs includes neither the group attribute nor a group ACE, and if the server's filesystem both supports and requires the notion of a group attribute (or group ACE), the server MUST derive the group attribute (or the corresponding owner ACE) for the file. This could be from the RPC call's credentials, such as the group principal if the credentials include it (such as with AUTH_SYS), from the group identifier associated with the principal in the credentials (e.g., - POSIX systems have a user database [37] that has the group identifier + POSIX systems have a user database [35] that has the group identifier for every user identifier), inherited from directory the object is created in, or whatever else the server's operating environment or filesystem semantics dictate. This applies to the OPEN operation too. Conversely, it is possible the client will specify in createattrs an owner attribute or group attribute or ACL that the principal indicated the RPC call's credentials does not have permissions to create files for. The error to be returned in this instance is NFS4ERR_PERM. This applies to the OPEN operation too. @@ -11374,21 +11361,21 @@ its filehandle then the following request is needed. PUTFH (directory filehandle) LOOKUP (entry name) GETFH 15.11. Operation 11: LINK - Create Link to a File 15.11.1. SYNOPSIS - (sfh), (cfh), newname -> (cfh), change_info + (sfh), (cfh), newname -> (cfh), cinfo 15.11.2. ARGUMENT struct LINK4args { /* SAVED_FH: source object */ /* CURRENT_FH: target directory */ component4 newname; }; 15.11.3. RESULT @@ -11587,32 +11574,51 @@ LOCK operation where the server is implementing mandatory locking semantics MUST result in the recall of all such delegations. The LOCK operation may not be granted until all such delegations are returned or revoked. Except where this happens very quickly, one or more NFS4ERR_DELAY errors will be returned to requests made while the delegation remains outstanding. The locker argument specifies the lock-owner that is associated with the LOCK request. The locker4 structure is a switched union that indicates whether the client has already created byte-range locking - state associated with the current open file and lock-owner. In the - case in which it has, the argument is just a stateid representing the - set of locks associated with that open file and lock-owner, together - with a lock_seqid value that MAY be any value and MUST be ignored by - the server. In the case where no byte-range locking state has been - established, or the client does not have the stateid available, the - argument contains the stateid of the open file with which this lock - is to be associated, together with the lock-owner with which the lock - is to be associated. The open_to_lock_owner case covers the very - first lock done by a lock-owner for a given open file and offers a - method to use the established state of the open_stateid to transition - to the use of a lock stateid. + state associated with the current open file and lock-owner. There + are multiple cases to be considered, corresponding to possible + combinations of whether locking state has been created for the + current open file and lock-owner, and whether the boolean + new_lock_owner is set. In all of the cases, there is a lock_seqid + specified, whether the lock-owner is specified explicitly or + implicitly. This seqid value is used for checking lockowner + sequencing/replay issues. When the given lockowner is not known to + the server, this establishes an initial sequence value for the new + lockowner. + + o In the case in which the state has been created and the boolean is + false, the only part of the argument other than lock_seqid is just + a stateid representing the set of locks associated with that open + file and lock-owner. + + o In the case in which the state has been created and the boolean is + true, the server rejects the request with the error + NFS4ERR_BADSEQ. The only exception is where there is a + retransmission of a previous request in which the boolean was + true. In this case, the lock_seqid will match the original + request and the response will reflect the final case, below. + + o In the case where no byte-range locking state has been established + and the boolean is true, the argument contains an + open_to_lock_owner structure which specifies the stateid of the + open file and the lock-owner to be used for the lock. Note that + although the open-owner is not given explicitly, the open_seqid + associated with it is used to check for open-owner sequencing + issues. This case provides a method to use the established state + of the open_stateid to transition to the use of a lock stateid. 15.13. Operation 13: LOCKT - Test For Lock 15.13.1. SYNOPSIS (cfh) locktype, offset, length, owner -> {void, NFS4ERR_DENIED -> owner} 15.13.2. ARGUMENT @@ -11717,21 +11723,21 @@ On success, the current filehandle retains its value. 15.14.5. IMPLEMENTATION If the area to be unlocked does not correspond exactly to a lock actually held by the lock-owner the server may return the error NFS4ERR_LOCK_RANGE. This includes the case in which the area is not locked, where the area is a sub-range of the area locked, where it overlaps the area locked without matching exactly or the area specified includes multiple locks held by the lock-owner. In all of - these cases, allowed by POSIX locking [35] semantics, a client + these cases, allowed by POSIX locking [33] semantics, a client receiving this error, should if it desires support for such operations, simulate the operation using LOCKU on ranges corresponding to locks it actually holds, possibly followed by LOCK requests for the sub-ranges not being unlocked. When a client holds an OPEN_DELEGATE_WRITE delegation, it may choose (see Section 15.12.5)) to handle LOCK requests locally. In such a case, LOCKU requests will similarly be handled locally. 15.15. Operation 15: LOOKUP - Lookup Filename @@ -12216,21 +12219,22 @@ reclaim (CLAIM_PREVIOUS) case, in which a delegation type is claimed. In this case, delegation will always be granted, although the server may specify an immediate recall in the delegation structure. The rflags returned by a successful OPEN allow the server to return information governing how the open file is to be handled. OPEN4_RESULT_CONFIRM indicates that the client MUST execute an OPEN_CONFIRM operation before using the open file. OPEN4_RESULT_LOCKTYPE_POSIX indicates the server's file locking - behavior supports the complete set of Posix locking techniques [35]. + behavior supports the complete set of Posix locking techniques [33]. + From this the client can choose to manage file locking state in a way to handle a mis-match of file locking management. If the component is of zero length, NFS4ERR_INVAL will be returned. The component is also subject to the normal UTF-8, character support, and name checks. See Section 12.3 for further discussion. When an OPEN is done and the specified open-owner already has the resulting filehandle open, the result is to "OR" together the new share and deny status together with the existing status. In this @@ -12257,21 +12261,21 @@ does not have authorization to create files for, then the server may return NFS4ERR_PERM. In the case of a OPEN which specifies a size of zero (e.g., truncation) and the file has named attributes, the named attributes are left as is. They are not removed. 15.18.6. IMPLEMENTATION The OPEN operation contains support for EXCLUSIVE4 create. The - mechanism is similar to the support in NFSv3 [14]. As in NFSv3, this + mechanism is similar to the support in NFSv3 [13]. As in NFSv3, this mechanism provides reliable exclusive creation. Exclusive create is invoked when the how parameter is EXCLUSIVE4. In this case, the client provides a verifier that can reasonably be expected to be unique. A combination of a client identifier, perhaps the client network address, and a unique number generated by the client, perhaps the RPC transaction identifier, may be appropriate. If the object does not exist, the server creates the object and stores the verifier in stable storage. For filesystems that do not provide a mechanism for the storage of arbitrary file attributes, the @@ -12477,43 +12481,43 @@ an implementation choice. The time period should certainly be no less than the lease time plus any grace period the server wishes to implement beyond a lease time. The OPEN_CONFIRM operation allows the server to safely dispose of unused open_owner4 data structures. In the case that a client issues an OPEN operation and the server no longer has a record of the open_owner4, the server needs to ensure that this is a new OPEN and not a replay or retransmission. Servers must not require confirmation on OPENs that grant delegations - or are doing reclaim operations. See Section 9.1.9 for details. The - server can easily avoid this by noting whether it has disposed of one - open_owner4 for the given client ID. If the server does not support - delegation, it might simply maintain a single bit that notes whether - any open_owner4 (for any client) has been disposed of. + or are doing reclaim operations. See Section 9.1.10 for details. + The server can easily avoid this by noting whether it has disposed of + one open_owner4 for the given client ID. If the server does not + support delegation, it might simply maintain a single bit that notes + whether any open_owner4 (for any client) has been disposed of. The server must hold unconfirmed OPEN state until one of three events occur. First, the client sends an OPEN_CONFIRM request with the appropriate sequence id and stateid within the lease period. In this case, the OPEN state on the server goes to confirmed, and the open_owner4 on the server is fully established. Second, the client sends another OPEN request with a sequence id that is incorrect for the open_owner4 (out of sequence). In this case, the server assumes the second OPEN request is valid and the first one is a replay. The server cancels the OPEN state of the first OPEN request, establishes an unconfirmed OPEN state for the second OPEN request, and responds to the second OPEN request with an indication that an OPEN_CONFIRM is needed. The process then repeats itself. While there is a potential for a denial of service attack on the client, it is mitigated if the client and server require the use of a - security flavor based on Kerberos V5, LIPKEY, or some other flavor - that uses cryptography. + security flavor based on Kerberos V5 or some other flavor that uses + cryptography. What if the server is in the unconfirmed OPEN state for a given open_owner4, and it receives an operation on the open_owner4 that has a stateid but the operation is not OPEN, or it is OPEN_CONFIRM but with the wrong stateid? Then, even if the seqid is correct, the server returns NFS4ERR_BAD_STATEID, because the server assumes the operation is a replay: if the server has no established OPEN state, then there is no way, for example, a LOCK operation could be valid. Third, neither of the two aforementioned events occur for the @@ -12628,56 +12632,56 @@ nfsstat4 status; }; 15.23.4. DESCRIPTION Replaces the current filehandle with the filehandle that represents the public filehandle of the server's name space. This filehandle may be different from the "root" filehandle which may be associated with some other directory on the server. - The public filehandle represents the concepts embodied in [23], [24], - [38]. The intent for NFSv4 is that the public filehandle + The public filehandle represents the concepts embodied in [21], [22], + [36]. The intent for NFSv4 is that the public filehandle (represented by the PUTPUBFH operation) be used as a method of providing WebNFS server compatibility with NFSv2 and NFSv3. The public filehandle and the root filehandle (represented by the PUTROOTFH operation) should be equivalent. If the public and root filehandles are not equivalent, then the public filehandle MUST be a descendant of the root filehandle. 15.23.5. IMPLEMENTATION Used as the first operator in an NFS request to set the context for following operations. With the NFSv2 and 3 public filehandle, the client is able to specify whether the path name provided in the LOOKUP should be evaluated as either an absolute path relative to the server's root or relative to - the public filehandle. [38] contains further discussion of the + the public filehandle. [36] contains further discussion of the functionality. With NFSv4, that type of specification is not directly available in the LOOKUP operation. The reason for this is because the component separators needed to specify absolute vs. relative are not allowed in NFSv4. Therefore, the client is responsible for constructing its request such that the use of either PUTROOTFH or PUTPUBFH are used to signify absolute or relative evaluation of an NFS URL respectively. - Note that there are warnings mentioned in [38] with respect to the + Note that there are warnings mentioned in [36] with respect to the use of absolute evaluation and the restrictions the server may place on that evaluation with respect to how much of its namespace has been made available. These same warnings apply to NFSv4. It is likely, therefore that because of server implementation details, an NFSv3 absolute public filehandle lookup may behave differently than an NFSv4 absolute resolution. - There is a form of security negotiation as described in [39] that + There is a form of security negotiation as described in [37] that uses the public filehandle a method of employing SNEGO. This method is not available with NFSv4 as filehandles are not overloaded with special meaning and therefore do not provide the same framework as NFSv2 and NFSv3. Clients should therefore use the security negotiation mechanisms described in this RFC. 15.24. Operation 24: PUTROOTFH - Set Root Filehandle 15.24.1. SYNOPSIS @@ -13071,21 +13074,21 @@ target is also subject to the normal UTF-8, character support, and name checks. See Section 12.3 for further discussion. On success, the current filehandle retains its value. 15.28.5. IMPLEMENTATION NFSv3 required a different operator RMDIR for directory removal and REMOVE for non-directory removal. This allowed clients to skip checking the file type when being passed a non-directory delete - system call (e.g., unlink() [40] in POSIX) to remove a directory, as + system call (e.g., unlink() [38] in POSIX) to remove a directory, as well as the converse (e.g., a rmdir() on a non-directory) because they knew the server would check the file type. NFSv4 REMOVE can be used to delete any directory entry independent of its file type. The implementor of an NFSv4 client's entry points from the unlink() and rmdir() system calls should first check the file type against the types the system call is allowed to remove before issuing a REMOVE. Alternatively, the implementor can produce a COMPOUND call that includes a LOOKUP/VERIFY sequence to verify the file type before a REMOVE operation in the same COMPOUND call. @@ -13110,22 +13113,21 @@ o If the file was not opened with OPEN4_SHARE_DENY_WRITE or OPEN4_SHARE_DENY_BOTH, the server SHOULD delete the file's directory entry. However, until last CLOSE of the file, the server MAY continue to allow access to the file via its filehandle. 15.29. Operation 29: RENAME - Rename Directory Entry 15.29.1. SYNOPSIS - (sfh), oldname, (cfh), newname -> source_change_info, - target_change_info + (sfh), oldname, (cfh), newname -> source_cinfo, target_cinfo 15.29.2. ARGUMENT struct RENAME4args { /* SAVED_FH: source directory */ component4 oldname; /* CURRENT_FH: target directory */ component4 newname; }; @@ -13386,27 +13389,27 @@ not have the appropriate access to LOOKUP the name then SECINFO must behave the same way and return NFS4ERR_ACCESS. The result will contain an array which represents the security mechanisms available, with an order corresponding to server's preferences, the most preferred being first in the array. The client is free to pick whatever security mechanism it both desires and supports, or to pick in the server's preference order the first one it supports. The array entries are represented by the secinfo4 structure. The field 'flavor' will contain a value of AUTH_NONE, - AUTH_SYS (as defined in [3]), or RPCSEC_GSS (as defined in [4]). + AUTH_SYS (as defined in [4]), or RPCSEC_GSS (as defined in [5]). For the flavors AUTH_NONE and AUTH_SYS, no additional security information is returned. For a return value of RPCSEC_GSS, a security triple is returned that contains the mechanism object id (as defined in [6]), the quality of protection (as defined in [6]) and - the service type (as defined in [4]). It is possible for SECINFO to + the service type (as defined in [5]). It is possible for SECINFO to return multiple entries with flavor equal to RPCSEC_GSS with different security triple values. On success, the current filehandle retains its value. If the name has a length of 0 (zero), or if name does not obey the UTF-8 definition, the error NFS4ERR_INVAL will be returned. 15.33.5. IMPLEMENTATION @@ -14191,37 +14194,43 @@ 15.39.3. RESULT struct RELEASE_LOCKOWNER4res { nfsstat4 status; }; 15.39.4. DESCRIPTION This operation is used to notify the server that the lock_owner is no - longer in use by the client. This allows the server to release - cached state related to the specified lock_owner. If file locks, - associated with the lock_owner, are held at the server, the error + longer in use by the client and that future client requests will not + reference this lock_owner. This allows the server to release cached + state related to the specified lock_owner. If file locks, associated + with the lock_owner, are held at the server, the error NFS4ERR_LOCKS_HELD will be returned and no further action will be taken. 15.39.5. IMPLEMENTATION The client may choose to use this operation to ease the amount of - server state that is held. Depending on behavior of applications at - the client, it may be important for the client to use this operation - since the server has certain obligations with respect to holding a - reference to a lock_owner as long as the associated file is open. + server state that is held. Information that can be released when a + RELEASE_LOCKOWNER is done includes the specified lock-owner string, + the seqid associated with the lock-owner, any saved reply for the + lock-owner, and any lock stateids associated with that lock-owner. + Depending on the behavior of applications at the client, it may be + important for the client to use this operation since the server has + certain obligations with respect to holding a reference to lock- + owner-associated state as long as an associated file is open. Therefore, if the client knows for certain that the lock_owner will - no longer be used under the context of the associated open_owner4, it - should use RELEASE_LOCKOWNER. + no longer be used, either to reference existing lock stateids + associated with the lock-owner to create new ones, it should use + RELEASE_LOCKOWNER. 15.40. Operation 10044: ILLEGAL - Illegal operation 15.40.1. SYNOPSIS -> () 15.40.2. ARGUMENT void; @@ -14545,21 +14554,21 @@ server controlled by the attacker. Because the operations SETCLIENTID/SETCLIENTID_CONFIRM are responsible for the release of client state, it is imperative that the principal used for these operations is checked against and match the previous use of these operations. See Section 9.1.1 for further discussion. 18. IANA Considerations - This section uses terms that are defined in [41]. + This section uses terms that are defined in [39]. 18.1. Named Attribute Definitions IANA will create a registry called the "NFSv4 Named Attribute Definitions Registry". The NFSv4 protocol supports the association of a file with zero or more named attributes. The name space identifiers for these attributes are defined as string names. The protocol does not define the specific assignment of the name space for these file attributes. @@ -14568,22 +14577,22 @@ attributes as needed, they are encouraged to register the attributes with IANA. Such registered named attributes are presumed to apply to all minor versions of NFSv4, including those defined subsequently to the registration. Where the named attribute is intended to be limited with regard to the minor versions for which they are not be used, the assignment in registry will clearly state the applicable limits. All assignments to the registry are made on a First Come First Served - basis, per section 4.1 of [41]. The policy for each assignment is - Specification Required, per section 4.1 of [41]. + basis, per section 4.1 of [39]. The policy for each assignment is + Specification Required, per section 4.1 of [39]. Under the NFSv4 specification, the name of a named attribute can in theory be up to 2^32 - 1 bytes in length, but in practice NFSv4 clients and servers will be unable to a handle string that long. IANA should reject any assignment request with a named attribute that exceeds 128 UTF-8 characters. To give IESG the flexibility to set up bases of assignment of Experimental Use and Standards Action, the prefixes of "EXPE" and "STDS" are Reserved. The zero length named attribute name is Reserved. @@ -14668,22 +14677,22 @@ 527), then complete universal address is "10.1.3.7.2.15". For the "tcp6" and "udp6" Network Identifiers the Universal Address or r_addr (for IPv6) is a US-ASCII string and is of the form: x1:x2:x3:x4:x5:x6:x7:x8.p1.p2 The suffix "p1.p2" is the service port, and is computed the same way as with universal addresses for "tcp" and "udp". The prefix, "x1:x2: x3:x4:x5:x6:x7:x8", is the standard textual form for representing an - IPv6 address as defined in Section 2.2 of [18]. Additionally, the - two alternative forms specified in Section 2.2 of [18] are also + IPv6 address as defined in Section 2.2 of [17]. Additionally, the + two alternative forms specified in Section 2.2 of [17] are also acceptable. 18.2.1. Initial Registry There is no initial registry. 18.2.2. Updating Registrations The registrant is always permitted to update the point of contact field. To make any other change will require Expert Review or IESG @@ -14693,155 +14702,149 @@ 19.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", March 1997. [2] Haynes, T. and D. Noveck, "NFSv4 Version 0 XDR Description", draft-ietf-nfsv4-rfc3530bis-dot-x-02 (work in progress), Feb 2011. - [3] Thurlow, R., "RPC: Remote Procedure Call Protocol Specification + [3] Klensin, J., "Internationalized Domain Names in Applications + (IDNA): Protocol", draft-ietf-idnabis-protocol-18 (work in + progress), January 2010. + + [4] Thurlow, R., "RPC: Remote Procedure Call Protocol Specification Version 2", RFC 5531, May 2009. - [4] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol + [5] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol Specification", RFC 2203, September 1997. - [5] Eisler, M., "LIPKEY - A Low Infrastructure Public Key Mechanism - Using SPKM", RFC 2847, June 2000. - [6] Linn, J., "Generic Security Service Application Program Interface Version 2, Update 1", RFC 2743, January 2000. [7] International Organization for Standardization, "Information Technology - Universal Multiple-octet coded Character Set (UCS) - Part 1: Architecture and Basic Multilingual Plane", ISO Standard 10646-1, May 1993. [8] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998. [9] Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings ("stringprep")", RFC 3454, December 2002. - [10] Klensin, J., "Internationalized Domain Names in Applications - (IDNA): Protocol", draft-ietf-idnabis-protocol-18 (work in - progress), January 2010. - 19.2. Informative References - [11] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame, + [10] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame, C., Eisler, M., and D. Noveck, "Network File System (NFS) version 4 Protocol", RFC 3530, April 2003. - [12] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame, + [11] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame, C., Eisler, M., and D. Noveck, "Network File System (NFS) version 4 Protocol", RFC 3010, December 2000. - [13] Nowicki, B., "NFS: Network File System Protocol specification", + [12] Nowicki, B., "NFS: Network File System Protocol specification", RFC 1094, March 1989. - [14] Callaghan, B., Pawlowski, B., and P. Staubach, "NFS Version 3 + [13] Callaghan, B., Pawlowski, B., and P. Staubach, "NFS Version 3 Protocol Specification", RFC 1813, June 1995. - [15] Eisler, M., "XDR: External Data Representation Standard", + [14] Eisler, M., "XDR: External Data Representation Standard", RFC 4506, May 2006. - [16] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC 1964, + [15] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC 1964, June 1996. - [17] Srinivasan, R., "Binding Protocols for ONC RPC Version 2", + [16] Srinivasan, R., "Binding Protocols for ONC RPC Version 2", RFC 1833, August 1995. - [18] Hinden, R. and S. Deering, "IP Version 6 Addressing + [17] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998. - [19] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by an On- + [18] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by an On- line Database", RFC 3232, January 2002. - [20] Floyd, S. and V. Jacobson, "The Synchronization of Periodic + [19] Floyd, S. and V. Jacobson, "The Synchronization of Periodic Routing Messages", IEEE/ACM Transactions on Networking 2(2), pp. 122-136, April 1994. - [21] Eisler, M., "NFS Version 2 and Version 3 Security Issues and + [20] Eisler, M., "NFS Version 2 and Version 3 Security Issues and the NFS Protocol's Use of RPCSEC_GSS and Kerberos V5", RFC 2623, June 1999. - [22] Adams, C., "The Simple Public-Key GSS-API Mechanism (SPKM)", - RFC 2025, October 1996. - - [23] Callaghan, B., "WebNFS Client Specification", RFC 2054, + [21] Callaghan, B., "WebNFS Client Specification", RFC 2054, October 1996. - [24] Callaghan, B., "WebNFS Server Specification", RFC 2055, + [22] Callaghan, B., "WebNFS Server Specification", RFC 2055, October 1996. - [25] IESG, "IESG Processing of RFC Errata for the IETF Stream", + [23] IESG, "IESG Processing of RFC Errata for the IETF Stream", July 2008. - [26] The Open Group, "Section 'read()' of System Interfaces of The + [24] The Open Group, "Section 'read()' of System Interfaces of The Open Group Base Specifications Issue 6, IEEE Std 1003.1, 2004 Edition", 2004. - [27] The Open Group, "Section 'readdir()' of System Interfaces of + [25] The Open Group, "Section 'readdir()' of System Interfaces of The Open Group Base Specifications Issue 6, IEEE Std 1003.1, 2004 Edition", 2004. - [28] The Open Group, "Section 'write()' of System Interfaces of The + [26] The Open Group, "Section 'write()' of System Interfaces of The Open Group Base Specifications Issue 6, IEEE Std 1003.1, 2004 Edition", 2004. - [29] Shepler, S., "NFS Version 4 Design Considerations", RFC 2624, + [27] Shepler, S., "NFS Version 4 Design Considerations", RFC 2624, June 1999. - [30] Simonsen, K., "Character Mnemonics and Character Sets", + [28] Simonsen, K., "Character Mnemonics and Character Sets", RFC 1345, June 1992. - [31] Shepler, S., Eisler, M., and D. Noveck, "Network File System + [29] Shepler, S., Eisler, M., and D. Noveck, "Network File System (NFS) Version 4 Minor Version 1 Protocol", RFC 5661, January 2010. - [32] The Open Group, "Protocols for Interworking: XNFS, Version 3W, + [30] The Open Group, "Protocols for Interworking: XNFS, Version 3W, ISBN 1-85912-184-5", February 1998. - [33] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, + [31] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. - [34] Juszczak, C., "Improving the Performance and Correctness of an + [32] Juszczak, C., "Improving the Performance and Correctness of an NFS Server", USENIX Conference Proceedings , June 1990. - [35] The Open Group, "Section 'fcntl()' of System Interfaces of The + [33] The Open Group, "Section 'fcntl()' of System Interfaces of The Open Group Base Specifications Issue 6 IEEE Std 1003.1, 2004 Edition, HTML Version (www.opengroup.org), ISBN 1931624232", 2004. - [36] The Open Group, "Section 'fsync()' of System Interfaces of The + [34] The Open Group, "Section 'fsync()' of System Interfaces of The Open Group Base Specifications Issue 6 IEEE Std 1003.1, 2004 Edition, HTML Version (www.opengroup.org), ISBN 1931624232", 2004. - [37] The Open Group, "Section 'getpwnam()' of System Interfaces of + [35] The Open Group, "Section 'getpwnam()' of System Interfaces of The Open Group Base Specifications Issue 6 IEEE Std 1003.1, 2004 Edition, HTML Version (www.opengroup.org), ISBN 1931624232", 2004. - [38] Callaghan, B., "NFS URL Scheme", RFC 2224, October 1997. + [36] Callaghan, B., "NFS URL Scheme", RFC 2224, October 1997. - [39] Chiu, A., Eisler, M., and B. Callaghan, "Security Negotiation + [37] Chiu, A., Eisler, M., and B. Callaghan, "Security Negotiation for WebNFS", RFC 2755, January 2000. - [40] The Open Group, "Section 'unlink()' of System Interfaces of The + [38] The Open Group, "Section 'unlink()' of System Interfaces of The Open Group Base Specifications Issue 6 IEEE Std 1003.1, 2004 Edition, HTML Version (www.opengroup.org), ISBN 1931624232", 2004. - [41] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA + [39] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. Appendix A. Acknowledgments A bis is certainly built on the shoulders of the first attempt. Spencer Shepler, Brent Callaghan, David Robinson, Robert Thurlow, Carl Beame, Mike Eisler, and David Noveck are responsible for a great deal of the effort in this work. Rob Thurlow clarified how a client should contact a new server if a @@ -14860,39 +14863,46 @@ James Lentini graciously read the rewrite of Section 7 and his comments were vital in improving the quality of that effort. Rob Thurlow, Sorin Faibish, James Lentini, Bruce Fields, and Trond Myklebust were faithful attendants of the biweekly triage meeting and accepted many an action item. Bruce Fields was a good sounding board for both the Third Edge Condition and Courtsey Locks in general. + Marcel Telka was a champion of straightening out the difference + between a lock-owner and an open-owner. He has also been diligent in + reviewing the final document. + Appendix B. RFC Editor Notes [RFC Editor: please remove this section prior to publishing this document as an RFC] [RFC Editor: prior to publishing this document as an RFC, please - replace all occurrences of RFCTBD10 with RFCxxxx where xxxx is the - RFC number of this document] + replace all occurences of RFCNFSv4XDR with RFCxxxx where xxxx is the + RFC number assigned to the XDR document.] + + [RFC Editor: Please note that there is also a reference entry that + needs to be modified for the companion document.] Authors' Addresses Thomas Haynes (editor) NetApp 9110 E 66th St Tulsa, OK 74133 USA Phone: +1 918 307 1415 Email: thomas@netapp.com URI: http://www.tulsalabs.com David Noveck (editor) EMC Corporation - 32 Coslin Drive - Southborough, MA 01772 + 228 South Street + Hopkinton, MA 01748 US - Phone: +1 508 305 8404 - Email: novecd@emc.com + Phone: +1 508 249 5748 + Email: david.noveck@emc.com