draft-ietf-nfsv4-rfc3530bis-33.txt   draft-ietf-nfsv4-rfc3530bis-34.txt 
NFSv4 T. Haynes, Ed. NFSv4 T. Haynes, Ed.
Internet-Draft Primary Data Internet-Draft Primary Data
Obsoletes: 3530 (if approved) D. Noveck, Ed. Obsoletes: 3530 (if approved) D. Noveck, Ed.
Intended status: Standards Track Intended status: Standards Track Dell
Expires: October 13, 2014 April 11, 2014 Expires: May 14, 2015 November 10, 2014
Network File System (NFS) Version 4 Protocol Network File System (NFS) Version 4 Protocol
draft-ietf-nfsv4-rfc3530bis-33.txt draft-ietf-nfsv4-rfc3530bis-34.txt
Abstract Abstract
The Network File System (NFS) version 4 is a distributed file system The Network File System (NFS) version 4 is a distributed file system
protocol which builds on the heritage of NFS protocol version 2, RFC protocol which builds on the heritage of NFS protocol version 2, RFC
1094, and version 3, RFC 1813. Unlike earlier versions, the NFS 1094, and version 3, RFC 1813. Unlike earlier versions, the NFS
version 4 protocol supports traditional file access while integrating version 4 protocol supports traditional file access while integrating
support for file locking and the mount protocol. In addition, support for file locking and the mount protocol. In addition,
support for strong security (and its negotiation), compound support for strong security (and its negotiation), compound
operations, client caching, and internationalization have been added. operations, client caching, and internationalization have been added.
skipping to change at page 1, line 49 skipping to change at page 1, line 49
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 13, 2014. This Internet-Draft will expire on May 14, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 47 skipping to change at page 2, line 47
Protocol are Authoritative . . . . . . . . . . . . . . . 8 Protocol are Authoritative . . . . . . . . . . . . . . . 8
1.3. Overview of NFSv4 Features . . . . . . . . . . . . . . . 8 1.3. Overview of NFSv4 Features . . . . . . . . . . . . . . . 8
1.3.1. RPC and Security . . . . . . . . . . . . . . . . . . 9 1.3.1. RPC and Security . . . . . . . . . . . . . . . . . . 9
1.3.2. Procedure and Operation Structure . . . . . . . . . . 9 1.3.2. Procedure and Operation Structure . . . . . . . . . . 9
1.3.3. Filesystem Model . . . . . . . . . . . . . . . . . . 10 1.3.3. Filesystem Model . . . . . . . . . . . . . . . . . . 10
1.3.4. OPEN and CLOSE . . . . . . . . . . . . . . . . . . . 12 1.3.4. OPEN and CLOSE . . . . . . . . . . . . . . . . . . . 12
1.3.5. File Locking . . . . . . . . . . . . . . . . . . . . 12 1.3.5. File Locking . . . . . . . . . . . . . . . . . . . . 12
1.3.6. Client Caching and Delegation . . . . . . . . . . . . 12 1.3.6. Client Caching and Delegation . . . . . . . . . . . . 12
1.4. General Definitions . . . . . . . . . . . . . . . . . . . 13 1.4. General Definitions . . . . . . . . . . . . . . . . . . . 13
1.5. Changes since RFC 3530 . . . . . . . . . . . . . . . . . 15 1.5. Changes since RFC 3530 . . . . . . . . . . . . . . . . . 15
1.6. Changes since RFC 3010 . . . . . . . . . . . . . . . . . 15 1.6. Changes between RFC 3010 and RFC3530 . . . . . . . . . . 15
2. Protocol Data Types . . . . . . . . . . . . . . . . . . . . . 16 2. Protocol Data Types . . . . . . . . . . . . . . . . . . . . . 16
2.1. Basic Data Types . . . . . . . . . . . . . . . . . . . . 16 2.1. Basic Data Types . . . . . . . . . . . . . . . . . . . . 16
2.2. Structured Data Types . . . . . . . . . . . . . . . . . . 18 2.2. Structured Data Types . . . . . . . . . . . . . . . . . . 18
3. RPC and Security Flavor . . . . . . . . . . . . . . . . . . . 22 3. RPC and Security Flavor . . . . . . . . . . . . . . . . . . . 22
3.1. Ports and Transports . . . . . . . . . . . . . . . . . . 23 3.1. Ports and Transports . . . . . . . . . . . . . . . . . . 22
3.1.1. Client Retransmission Behavior . . . . . . . . . . . 23 3.1.1. Client Retransmission Behavior . . . . . . . . . . . 23
3.2. Security Flavors . . . . . . . . . . . . . . . . . . . . 24 3.2. Security Flavors . . . . . . . . . . . . . . . . . . . . 24
3.2.1. Security mechanisms for NFSv4 . . . . . . . . . . . . 24 3.2.1. Security mechanisms for NFSv4 . . . . . . . . . . . . 24
3.3. Security Negotiation . . . . . . . . . . . . . . . . . . 26 3.3. Security Negotiation . . . . . . . . . . . . . . . . . . 25
3.3.1. SECINFO . . . . . . . . . . . . . . . . . . . . . . . 26 3.3.1. SECINFO . . . . . . . . . . . . . . . . . . . . . . . 26
3.3.2. Security Error . . . . . . . . . . . . . . . . . . . 26 3.3.2. Security Error . . . . . . . . . . . . . . . . . . . 26
3.3.3. Callback RPC Authentication . . . . . . . . . . . . . 27 3.3.3. Callback RPC Authentication . . . . . . . . . . . . . 26
4. Filehandles . . . . . . . . . . . . . . . . . . . . . . . . . 28 4. Filehandles . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.1. Obtaining the First Filehandle . . . . . . . . . . . . . 28 4.1. Obtaining the First Filehandle . . . . . . . . . . . . . 28
4.1.1. Root Filehandle . . . . . . . . . . . . . . . . . . . 28 4.1.1. Root Filehandle . . . . . . . . . . . . . . . . . . . 28
4.1.2. Public Filehandle . . . . . . . . . . . . . . . . . . 29 4.1.2. Public Filehandle . . . . . . . . . . . . . . . . . . 28
4.2. Filehandle Types . . . . . . . . . . . . . . . . . . . . 29 4.2. Filehandle Types . . . . . . . . . . . . . . . . . . . . 29
4.2.1. General Properties of a Filehandle . . . . . . . . . 29 4.2.1. General Properties of a Filehandle . . . . . . . . . 29
4.2.2. Persistent Filehandle . . . . . . . . . . . . . . . . 30 4.2.2. Persistent Filehandle . . . . . . . . . . . . . . . . 30
4.2.3. Volatile Filehandle . . . . . . . . . . . . . . . . . 30 4.2.3. Volatile Filehandle . . . . . . . . . . . . . . . . . 30
4.2.4. One Method of Constructing a Volatile Filehandle . . 32 4.2.4. One Method of Constructing a Volatile Filehandle . . 31
4.3. Client Recovery from Filehandle Expiration . . . . . . . 32 4.3. Client Recovery from Filehandle Expiration . . . . . . . 32
5. Attributes . . . . . . . . . . . . . . . . . . . . . . . . . 33 5. Attributes . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.1. REQUIRED Attributes . . . . . . . . . . . . . . . . . . . 34 5.1. REQUIRED Attributes . . . . . . . . . . . . . . . . . . . 34
5.2. RECOMMENDED Attributes . . . . . . . . . . . . . . . . . 35 5.2. RECOMMENDED Attributes . . . . . . . . . . . . . . . . . 34
5.3. Named Attributes . . . . . . . . . . . . . . . . . . . . 35 5.3. Named Attributes . . . . . . . . . . . . . . . . . . . . 35
5.4. Classification of Attributes . . . . . . . . . . . . . . 36 5.4. Classification of Attributes . . . . . . . . . . . . . . 36
5.5. Set-Only and Get-Only Attributes . . . . . . . . . . . . 37 5.5. Set-Only and Get-Only Attributes . . . . . . . . . . . . 37
5.6. REQUIRED Attributes - List and Definition References . . 38 5.6. REQUIRED Attributes - List and Definition References . . 38
5.7. RECOMMENDED Attributes - List and Definition References . 38 5.7. RECOMMENDED Attributes - List and Definition References . 38
5.8. Attribute Definitions . . . . . . . . . . . . . . . . . . 40 5.8. Attribute Definitions . . . . . . . . . . . . . . . . . . 40
5.8.1. Definitions of REQUIRED Attributes . . . . . . . . . 40 5.8.1. Definitions of REQUIRED Attributes . . . . . . . . . 40
5.8.2. Definitions of Uncategorized RECOMMENDED Attributes . 42 5.8.2. Definitions of Uncategorized RECOMMENDED Attributes . 42
5.9. Interpreting owner and owner_group . . . . . . . . . . . 48 5.9. Interpreting owner and owner_group . . . . . . . . . . . 48
5.10. Character Case Attributes . . . . . . . . . . . . . . . . 51 5.10. Character Case Attributes . . . . . . . . . . . . . . . . 51
6. Access Control Attributes . . . . . . . . . . . . . . . . . . 51 6. Access Control Attributes . . . . . . . . . . . . . . . . . . 51
6.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 51 6.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 52
6.2. File Attributes Discussion . . . . . . . . . . . . . . . 52 6.2. File Attributes Discussion . . . . . . . . . . . . . . . 52
6.2.1. Attribute 12: acl . . . . . . . . . . . . . . . . . . 52 6.2.1. Attribute 12: acl . . . . . . . . . . . . . . . . . . 53
6.2.2. Attribute 33: mode . . . . . . . . . . . . . . . . . 67 6.2.2. Attribute 33: mode . . . . . . . . . . . . . . . . . 67
6.3. Common Methods . . . . . . . . . . . . . . . . . . . . . 67 6.3. Common Methods . . . . . . . . . . . . . . . . . . . . . 67
6.3.1. Interpreting an ACL . . . . . . . . . . . . . . . . . 68 6.3.1. Interpreting an ACL . . . . . . . . . . . . . . . . . 67
6.3.2. Computing a Mode Attribute from an ACL . . . . . . . 69 6.3.2. Computing a Mode Attribute from an ACL . . . . . . . 68
6.4. Requirements . . . . . . . . . . . . . . . . . . . . . . 70 6.4. Requirements . . . . . . . . . . . . . . . . . . . . . . 69
6.4.1. Setting the mode and/or ACL Attributes . . . . . . . 70 6.4.1. Setting the mode and/or ACL Attributes . . . . . . . 70
6.4.2. Retrieving the mode and/or ACL Attributes . . . . . . 71 6.4.2. Retrieving the mode and/or ACL Attributes . . . . . . 71
6.4.3. Creating New Objects . . . . . . . . . . . . . . . . 72 6.4.3. Creating New Objects . . . . . . . . . . . . . . . . 71
7. NFS Server Name Space . . . . . . . . . . . . . . . . . . . . 73 7. NFS Server Name Space . . . . . . . . . . . . . . . . . . . . 73
7.1. Server Exports . . . . . . . . . . . . . . . . . . . . . 73 7.1. Server Exports . . . . . . . . . . . . . . . . . . . . . 73
7.2. Browsing Exports . . . . . . . . . . . . . . . . . . . . 74 7.2. Browsing Exports . . . . . . . . . . . . . . . . . . . . 74
7.3. Server Pseudo Filesystem . . . . . . . . . . . . . . . . 74 7.3. Server Pseudo Filesystem . . . . . . . . . . . . . . . . 74
7.4. Multiple Roots . . . . . . . . . . . . . . . . . . . . . 75 7.4. Multiple Roots . . . . . . . . . . . . . . . . . . . . . 75
7.5. Filehandle Volatility . . . . . . . . . . . . . . . . . . 75 7.5. Filehandle Volatility . . . . . . . . . . . . . . . . . . 75
7.6. Exported Root . . . . . . . . . . . . . . . . . . . . . . 75 7.6. Exported Root . . . . . . . . . . . . . . . . . . . . . . 75
7.7. Mount Point Crossing . . . . . . . . . . . . . . . . . . 76 7.7. Mount Point Crossing . . . . . . . . . . . . . . . . . . 75
7.8. Security Policy and Name Space Presentation . . . . . . . 76 7.8. Security Policy and Name Space Presentation . . . . . . . 76
8. Multi-Server Namespace . . . . . . . . . . . . . . . . . . . 77 8. Multi-Server Namespace . . . . . . . . . . . . . . . . . . . 77
8.1. Location Attributes . . . . . . . . . . . . . . . . . . . 77 8.1. Location Attributes . . . . . . . . . . . . . . . . . . . 77
8.2. File System Presence or Absence . . . . . . . . . . . . . 77 8.2. File System Presence or Absence . . . . . . . . . . . . . 77
8.3. Getting Attributes for an Absent File System . . . . . . 78 8.3. Getting Attributes for an Absent File System . . . . . . 78
8.3.1. GETATTR Within an Absent File System . . . . . . . . 79 8.3.1. GETATTR Within an Absent File System . . . . . . . . 78
8.3.2. READDIR and Absent File Systems . . . . . . . . . . . 80 8.3.2. READDIR and Absent File Systems . . . . . . . . . . . 79
8.4. Uses of Location Information . . . . . . . . . . . . . . 80 8.4. Uses of Location Information . . . . . . . . . . . . . . 80
8.4.1. File System Replication . . . . . . . . . . . . . . . 81 8.4.1. File System Replication . . . . . . . . . . . . . . . 81
8.4.2. File System Migration . . . . . . . . . . . . . . . . 82 8.4.2. File System Migration . . . . . . . . . . . . . . . . 81
8.4.3. Referrals . . . . . . . . . . . . . . . . . . . . . . 83 8.4.3. Referrals . . . . . . . . . . . . . . . . . . . . . . 82
8.5. Location Entries and Server Identity . . . . . . . . . . 83 8.5. Location Entries and Server Identity . . . . . . . . . . 83
8.6. Additional Client-Side Considerations . . . . . . . . . . 84 8.6. Additional Client-Side Considerations . . . . . . . . . . 83
8.7. Effecting File System Referrals . . . . . . . . . . . . . 85 8.7. Effecting File System Referrals . . . . . . . . . . . . . 84
8.7.1. Referral Example (LOOKUP) . . . . . . . . . . . . . . 85 8.7.1. Referral Example (LOOKUP) . . . . . . . . . . . . . . 85
8.7.2. Referral Example (READDIR) . . . . . . . . . . . . . 89 8.7.2. Referral Example (READDIR) . . . . . . . . . . . . . 89
8.8. The Attribute fs_locations . . . . . . . . . . . . . . . 92 8.8. The Attribute fs_locations . . . . . . . . . . . . . . . 91
8.8.1. Inferring Transition Modes . . . . . . . . . . . . . 93 8.8.1. Inferring Transition Modes . . . . . . . . . . . . . 93
9. File Locking and Share Reservations . . . . . . . . . . . . . 95 9. File Locking and Share Reservations . . . . . . . . . . . . . 94
9.1. Opens and Byte-Range Locks . . . . . . . . . . . . . . . 96 9.1. Opens and Byte-Range Locks . . . . . . . . . . . . . . . 95
9.1.1. Client ID . . . . . . . . . . . . . . . . . . . . . . 96 9.1.1. Client ID . . . . . . . . . . . . . . . . . . . . . . 95
9.1.2. Server Release of Client ID . . . . . . . . . . . . . 99 9.1.2. Server Release of Client ID . . . . . . . . . . . . . 98
9.1.3. Stateid Definition . . . . . . . . . . . . . . . . . 100 9.1.3. Stateid Definition . . . . . . . . . . . . . . . . . 99
9.1.4. lock-owner . . . . . . . . . . . . . . . . . . . . . 106 9.1.4. lock-owner . . . . . . . . . . . . . . . . . . . . . 105
9.1.5. Use of the Stateid and Locking . . . . . . . . . . . 106 9.1.5. Use of the Stateid and Locking . . . . . . . . . . . 106
9.1.6. Sequencing of Lock Requests . . . . . . . . . . . . . 109 9.1.6. Sequencing of Lock Requests . . . . . . . . . . . . . 108
9.1.7. Recovery from Replayed Requests . . . . . . . . . . . 110 9.1.7. Recovery from Replayed Requests . . . . . . . . . . . 109
9.1.8. Interactions of multiple sequence values . . . . . . 110 9.1.8. Interactions of multiple sequence values . . . . . . 109
9.1.9. Releasing state-owner State . . . . . . . . . . . . . 111 9.1.9. Releasing state-owner State . . . . . . . . . . . . . 110
9.1.10. Use of Open Confirmation . . . . . . . . . . . . . . 112 9.1.10. Use of Open Confirmation . . . . . . . . . . . . . . 111
9.2. Lock Ranges . . . . . . . . . . . . . . . . . . . . . . . 113 9.2. Lock Ranges . . . . . . . . . . . . . . . . . . . . . . . 112
9.3. Upgrading and Downgrading Locks . . . . . . . . . . . . . 113 9.3. Upgrading and Downgrading Locks . . . . . . . . . . . . . 112
9.4. Blocking Locks . . . . . . . . . . . . . . . . . . . . . 114 9.4. Blocking Locks . . . . . . . . . . . . . . . . . . . . . 113
9.5. Lease Renewal . . . . . . . . . . . . . . . . . . . . . . 115 9.5. Lease Renewal . . . . . . . . . . . . . . . . . . . . . . 114
9.6. Crash Recovery . . . . . . . . . . . . . . . . . . . . . 115 9.6. Crash Recovery . . . . . . . . . . . . . . . . . . . . . 115
9.6.1. Client Failure and Recovery . . . . . . . . . . . . . 116 9.6.1. Client Failure and Recovery . . . . . . . . . . . . . 115
9.6.2. Server Failure and Recovery . . . . . . . . . . . . . 116 9.6.2. Server Failure and Recovery . . . . . . . . . . . . . 115
9.6.3. Network Partitions and Recovery . . . . . . . . . . . 118 9.6.3. Network Partitions and Recovery . . . . . . . . . . . 117
9.7. Recovery from a Lock Request Timeout or Abort . . . . . . 126 9.7. Recovery from a Lock Request Timeout or Abort . . . . . . 125
9.8. Server Revocation of Locks . . . . . . . . . . . . . . . 126 9.8. Server Revocation of Locks . . . . . . . . . . . . . . . 125
9.9. Share Reservations . . . . . . . . . . . . . . . . . . . 127 9.9. Share Reservations . . . . . . . . . . . . . . . . . . . 127
9.10. OPEN/CLOSE Operations . . . . . . . . . . . . . . . . . . 128 9.10. OPEN/CLOSE Operations . . . . . . . . . . . . . . . . . . 127
9.10.1. Close and Retention of State Information . . . . . . 129 9.10.1. Close and Retention of State Information . . . . . . 128
9.11. Open Upgrade and Downgrade . . . . . . . . . . . . . . . 129 9.11. Open Upgrade and Downgrade . . . . . . . . . . . . . . . 129
9.12. Short and Long Leases . . . . . . . . . . . . . . . . . . 130 9.12. Short and Long Leases . . . . . . . . . . . . . . . . . . 129
9.13. Clocks, Propagation Delay, and Calculating Lease 9.13. Clocks, Propagation Delay, and Calculating Lease
Expiration . . . . . . . . . . . . . . . . . . . . . . . 131 Expiration . . . . . . . . . . . . . . . . . . . . . . . 130
9.14. Migration, Replication and State . . . . . . . . . . . . 131 9.14. Migration, Replication and State . . . . . . . . . . . . 130
9.14.1. Migration and State . . . . . . . . . . . . . . . . 132 9.14.1. Migration and State . . . . . . . . . . . . . . . . 131
9.14.2. Replication and State . . . . . . . . . . . . . . . 132 9.14.2. Replication and State . . . . . . . . . . . . . . . 132
9.14.3. Notification of Migrated Lease . . . . . . . . . . . 133 9.14.3. Notification of Migrated Lease . . . . . . . . . . . 132
9.14.4. Migration and the Lease_time Attribute . . . . . . . 134 9.14.4. Migration and the Lease_time Attribute . . . . . . . 133
10. Client-Side Caching . . . . . . . . . . . . . . . . . . . . . 134 10. Client-Side Caching . . . . . . . . . . . . . . . . . . . . . 133
10.1. Performance Challenges for Client-Side Caching . . . . . 135 10.1. Performance Challenges for Client-Side Caching . . . . . 134
10.2. Delegation and Callbacks . . . . . . . . . . . . . . . . 136 10.2. Delegation and Callbacks . . . . . . . . . . . . . . . . 135
10.2.1. Delegation Recovery . . . . . . . . . . . . . . . . 137 10.2.1. Delegation Recovery . . . . . . . . . . . . . . . . 137
10.3. Data Caching . . . . . . . . . . . . . . . . . . . . . . 142 10.3. Data Caching . . . . . . . . . . . . . . . . . . . . . . 141
10.3.1. Data Caching and OPENs . . . . . . . . . . . . . . . 142 10.3.1. Data Caching and OPENs . . . . . . . . . . . . . . . 141
10.3.2. Data Caching and File Locking . . . . . . . . . . . 143 10.3.2. Data Caching and File Locking . . . . . . . . . . . 142
10.3.3. Data Caching and Mandatory File Locking . . . . . . 145 10.3.3. Data Caching and Mandatory File Locking . . . . . . 144
10.3.4. Data Caching and File Identity . . . . . . . . . . . 145 10.3.4. Data Caching and File Identity . . . . . . . . . . . 144
10.4. Open Delegation . . . . . . . . . . . . . . . . . . . . 146 10.4. Open Delegation . . . . . . . . . . . . . . . . . . . . 146
10.4.1. Open Delegation and Data Caching . . . . . . . . . . 149 10.4.1. Open Delegation and Data Caching . . . . . . . . . . 148
10.4.2. Open Delegation and File Locks . . . . . . . . . . . 150 10.4.2. Open Delegation and File Locks . . . . . . . . . . . 149
10.4.3. Handling of CB_GETATTR . . . . . . . . . . . . . . . 150 10.4.3. Handling of CB_GETATTR . . . . . . . . . . . . . . . 150
10.4.4. Recall of Open Delegation . . . . . . . . . . . . . 153 10.4.4. Recall of Open Delegation . . . . . . . . . . . . . 153
10.4.5. OPEN Delegation Race with CB_RECALL . . . . . . . . 155 10.4.5. OPEN Delegation Race with CB_RECALL . . . . . . . . 155
10.4.6. Clients that Fail to Honor Delegation Recalls . . . 156 10.4.6. Clients that Fail to Honor Delegation Recalls . . . 155
10.4.7. Delegation Revocation . . . . . . . . . . . . . . . 157 10.4.7. Delegation Revocation . . . . . . . . . . . . . . . 156
10.5. Data Caching and Revocation . . . . . . . . . . . . . . 157 10.5. Data Caching and Revocation . . . . . . . . . . . . . . 157
10.5.1. Revocation Recovery for Write Open Delegation . . . 158 10.5.1. Revocation Recovery for Write Open Delegation . . . 157
10.6. Attribute Caching . . . . . . . . . . . . . . . . . . . 159 10.6. Attribute Caching . . . . . . . . . . . . . . . . . . . 158
10.7. Data and Metadata Caching and Memory Mapped Files . . . 161 10.7. Data and Metadata Caching and Memory Mapped Files . . . 160
10.8. Name Caching . . . . . . . . . . . . . . . . . . . . . . 163 10.8. Name Caching . . . . . . . . . . . . . . . . . . . . . . 162
10.9. Directory Caching . . . . . . . . . . . . . . . . . . . 164 10.9. Directory Caching . . . . . . . . . . . . . . . . . . . 163
11. Minor Versioning . . . . . . . . . . . . . . . . . . . . . . 165 11. Minor Versioning . . . . . . . . . . . . . . . . . . . . . . 164
12. Internationalization . . . . . . . . . . . . . . . . . . . . 167 12. Internationalization . . . . . . . . . . . . . . . . . . . . 165
12.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 167 12.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 165
12.2. Limitations on internationalization-related processing 12.2. Limitations on internationalization-related processing
in the NFSv4 context . . . . . . . . . . . . . . . . . . 169 in the NFSv4 context . . . . . . . . . . . . . . . . . . 166
12.3. Summary of Server Behavior Types . . . . . . . . . . . . 170 12.3. Summary of Server Behavior Types . . . . . . . . . . . . 167
12.4. String Encoding . . . . . . . . . . . . . . . . . . . . 170 12.4. String Encoding . . . . . . . . . . . . . . . . . . . . 168
12.5. Normalization . . . . . . . . . . . . . . . . . . . . . 171 12.5. Normalization . . . . . . . . . . . . . . . . . . . . . 169
12.6. Types with Processing Defined by Other Internet Areas . 172 12.6. Types with Processing Defined by Other Internet Areas . 169
12.7. UTF-8 Related Errors . . . . . . . . . . . . . . . . . . 173 12.7. UTF-8 Related Errors . . . . . . . . . . . . . . . . . . 171
12.8. Servers that accept file component names that are not 12.8. Servers that accept file component names that are not
valid UTF-8 strings . . . . . . . . . . . . . . . . . . 174 valid UTF-8 strings . . . . . . . . . . . . . . . . . . 171
13. Error Values . . . . . . . . . . . . . . . . . . . . . . . . 175 13. Error Values . . . . . . . . . . . . . . . . . . . . . . . . 172
13.1. Error Definitions . . . . . . . . . . . . . . . . . . . 175 13.1. Error Definitions . . . . . . . . . . . . . . . . . . . 172
13.1.1. General Errors . . . . . . . . . . . . . . . . . . . 177 13.1.1. General Errors . . . . . . . . . . . . . . . . . . . 174
13.1.2. Filehandle Errors . . . . . . . . . . . . . . . . . 178 13.1.2. Filehandle Errors . . . . . . . . . . . . . . . . . 175
13.1.3. Compound Structure Errors . . . . . . . . . . . . . 179 13.1.3. Compound Structure Errors . . . . . . . . . . . . . 176
13.1.4. File System Errors . . . . . . . . . . . . . . . . . 180 13.1.4. File System Errors . . . . . . . . . . . . . . . . . 177
13.1.5. State Management Errors . . . . . . . . . . . . . . 182 13.1.5. State Management Errors . . . . . . . . . . . . . . 179
13.1.6. Security Errors . . . . . . . . . . . . . . . . . . 183 13.1.6. Security Errors . . . . . . . . . . . . . . . . . . 180
13.1.7. Name Errors . . . . . . . . . . . . . . . . . . . . 184 13.1.7. Name Errors . . . . . . . . . . . . . . . . . . . . 181
13.1.8. Locking Errors . . . . . . . . . . . . . . . . . . . 184 13.1.8. Locking Errors . . . . . . . . . . . . . . . . . . . 182
13.1.9. Reclaim Errors . . . . . . . . . . . . . . . . . . . 186 13.1.9. Reclaim Errors . . . . . . . . . . . . . . . . . . . 183
13.1.10. Client Management Errors . . . . . . . . . . . . . . 187 13.1.10. Client Management Errors . . . . . . . . . . . . . . 184
13.1.11. Attribute Handling Errors . . . . . . . . . . . . . 187 13.1.11. Attribute Handling Errors . . . . . . . . . . . . . 184
13.2. Operations and their valid errors . . . . . . . . . . . 188 13.2. Operations and their valid errors . . . . . . . . . . . 185
13.3. Callback operations and their valid errors . . . . . . . 195 13.3. Callback operations and their valid errors . . . . . . . 192
13.4. Errors and the operations that use them . . . . . . . . 196 13.4. Errors and the operations that use them . . . . . . . . 193
14. NFSv4 Requests . . . . . . . . . . . . . . . . . . . . . . . 201 14. NFSv4 Requests . . . . . . . . . . . . . . . . . . . . . . . 198
14.1. Compound Procedure . . . . . . . . . . . . . . . . . . . 201 14.1. Compound Procedure . . . . . . . . . . . . . . . . . . . 199
14.2. Evaluation of a Compound Request . . . . . . . . . . . . 202 14.2. Evaluation of a Compound Request . . . . . . . . . . . . 200
14.3. Synchronous Modifying Operations . . . . . . . . . . . . 203 14.3. Synchronous Modifying Operations . . . . . . . . . . . . 200
14.4. Operation Values . . . . . . . . . . . . . . . . . . . . 203 14.4. Operation Values . . . . . . . . . . . . . . . . . . . . 201
15. NFSv4 Procedures . . . . . . . . . . . . . . . . . . . . . . 203 15. NFSv4 Procedures . . . . . . . . . . . . . . . . . . . . . . 201
15.1. Procedure 0: NULL - No Operation . . . . . . . . . . . . 203 15.1. Procedure 0: NULL - No Operation . . . . . . . . . . . . 201
15.2. Procedure 1: COMPOUND - Compound Operations . . . . . . 204 15.2. Procedure 1: COMPOUND - Compound Operations . . . . . . 201
15.3. Operation 3: ACCESS - Check Access Rights . . . . . . . 208 15.3. Operation 3: ACCESS - Check Access Rights . . . . . . . 205
15.4. Operation 4: CLOSE - Close File . . . . . . . . . . . . 210 15.4. Operation 4: CLOSE - Close File . . . . . . . . . . . . 208
15.5. Operation 5: COMMIT - Commit Cached Data . . . . . . . . 211 15.5. Operation 5: COMMIT - Commit Cached Data . . . . . . . . 209
15.6. Operation 6: CREATE - Create a Non-Regular File Object . 214 15.6. Operation 6: CREATE - Create a Non-Regular File Object . 211
15.7. Operation 7: DELEGPURGE - Purge Delegations Awaiting 15.7. Operation 7: DELEGPURGE - Purge Delegations Awaiting
Recovery . . . . . . . . . . . . . . . . . . . . . . . . 217 Recovery . . . . . . . . . . . . . . . . . . . . . . . . 214
15.8. Operation 8: DELEGRETURN - Return Delegation . . . . . . 218 15.8. Operation 8: DELEGRETURN - Return Delegation . . . . . . 215
15.9. Operation 9: GETATTR - Get Attributes . . . . . . . . . 219 15.9. Operation 9: GETATTR - Get Attributes . . . . . . . . . 216
15.10. Operation 10: GETFH - Get Current Filehandle . . . . . . 221 15.10. Operation 10: GETFH - Get Current Filehandle . . . . . . 218
15.11. Operation 11: LINK - Create Link to a File . . . . . . . 221 15.11. Operation 11: LINK - Create Link to a File . . . . . . . 218
15.12. Operation 12: LOCK - Create Lock . . . . . . . . . . . . 223 15.12. Operation 12: LOCK - Create Lock . . . . . . . . . . . . 220
15.13. Operation 13: LOCKT - Test For Lock . . . . . . . . . . 227 15.13. Operation 13: LOCKT - Test For Lock . . . . . . . . . . 224
15.14. Operation 14: LOCKU - Unlock File . . . . . . . . . . . 229 15.14. Operation 14: LOCKU - Unlock File . . . . . . . . . . . 226
15.15. Operation 15: LOOKUP - Lookup Filename . . . . . . . . . 230 15.15. Operation 15: LOOKUP - Lookup Filename . . . . . . . . . 227
15.16. Operation 16: LOOKUPP - Lookup Parent Directory . . . . 232 15.16. Operation 16: LOOKUPP - Lookup Parent Directory . . . . 229
15.17. Operation 17: NVERIFY - Verify Difference in Attributes 233 15.17. Operation 17: NVERIFY - Verify Difference in Attributes 230
15.18. Operation 18: OPEN - Open a Regular File . . . . . . . . 234 15.18. Operation 18: OPEN - Open a Regular File . . . . . . . . 231
15.19. Operation 19: OPENATTR - Open Named Attribute Directory 244 15.19. Operation 19: OPENATTR - Open Named Attribute Directory 241
15.20. Operation 20: OPEN_CONFIRM - Confirm Open . . . . . . . 245 15.20. Operation 20: OPEN_CONFIRM - Confirm Open . . . . . . . 242
15.21. Operation 21: OPEN_DOWNGRADE - Reduce Open File Access . 247 15.21. Operation 21: OPEN_DOWNGRADE - Reduce Open File Access . 244
15.22. Operation 22: PUTFH - Set Current Filehandle . . . . . . 249 15.22. Operation 22: PUTFH - Set Current Filehandle . . . . . . 246
15.23. Operation 23: PUTPUBFH - Set Public Filehandle . . . . . 249 15.23. Operation 23: PUTPUBFH - Set Public Filehandle . . . . . 246
15.24. Operation 24: PUTROOTFH - Set Root Filehandle . . . . . 251 15.24. Operation 24: PUTROOTFH - Set Root Filehandle . . . . . 248
15.25. Operation 25: READ - Read from File . . . . . . . . . . 252 15.25. Operation 25: READ - Read from File . . . . . . . . . . 249
15.26. Operation 26: READDIR - Read Directory . . . . . . . . . 254 15.26. Operation 26: READDIR - Read Directory . . . . . . . . . 251
15.27. Operation 27: READLINK - Read Symbolic Link . . . . . . 258 15.27. Operation 27: READLINK - Read Symbolic Link . . . . . . 255
15.28. Operation 28: REMOVE - Remove Filesystem Object . . . . 259 15.28. Operation 28: REMOVE - Remove Filesystem Object . . . . 256
15.29. Operation 29: RENAME - Rename Directory Entry . . . . . 260 15.29. Operation 29: RENAME - Rename Directory Entry . . . . . 257
15.30. Operation 30: RENEW - Renew a Lease . . . . . . . . . . 262 15.30. Operation 30: RENEW - Renew a Lease . . . . . . . . . . 259
15.31. Operation 31: RESTOREFH - Restore Saved Filehandle . . . 264 15.31. Operation 31: RESTOREFH - Restore Saved Filehandle . . . 261
15.32. Operation 32: SAVEFH - Save Current Filehandle . . . . . 265 15.32. Operation 32: SAVEFH - Save Current Filehandle . . . . . 262
15.33. Operation 33: SECINFO - Obtain Available Security . . . 265 15.33. Operation 33: SECINFO - Obtain Available Security . . . 262
15.34. Operation 34: SETATTR - Set Attributes . . . . . . . . . 269 15.34. Operation 34: SETATTR - Set Attributes . . . . . . . . . 266
15.35. Operation 35: SETCLIENTID - Negotiate Client ID . . . . 271 15.35. Operation 35: SETCLIENTID - Negotiate Client ID . . . . 268
15.36. Operation 36: SETCLIENTID_CONFIRM - Confirm Client ID . 275 15.36. Operation 36: SETCLIENTID_CONFIRM - Confirm Client ID . 272
15.37. Operation 37: VERIFY - Verify Same Attributes . . . . . 278 15.37. Operation 37: VERIFY - Verify Same Attributes . . . . . 275
15.38. Operation 38: WRITE - Write to File . . . . . . . . . . 280 15.38. Operation 38: WRITE - Write to File . . . . . . . . . . 277
15.39. Operation 39: RELEASE_LOCKOWNER - Release Lockowner 15.39. Operation 39: RELEASE_LOCKOWNER - Release Lockowner
State . . . . . . . . . . . . . . . . . . . . . . . . . 284 State . . . . . . . . . . . . . . . . . . . . . . . . . 281
15.40. Operation 10044: ILLEGAL - Illegal operation . . . . . . 285 15.40. Operation 10044: ILLEGAL - Illegal operation . . . . . . 282
16. NFSv4 Callback Procedures . . . . . . . . . . . . . . . . . . 286 16. NFSv4 Callback Procedures . . . . . . . . . . . . . . . . . . 283
16.1. Procedure 0: CB_NULL - No Operation . . . . . . . . . . 286 16.1. Procedure 0: CB_NULL - No Operation . . . . . . . . . . 283
16.2. Procedure 1: CB_COMPOUND - Compound Operations . . . . . 286 16.2. Procedure 1: CB_COMPOUND - Compound Operations . . . . . 283
16.2.6. Operation 3: CB_GETATTR - Get Attributes . . . . . . 288 16.2.6. Operation 3: CB_GETATTR - Get Attributes . . . . . . 285
16.2.7. Operation 4: CB_RECALL - Recall an Open Delegation . 289 16.2.7. Operation 4: CB_RECALL - Recall an Open Delegation . 286
16.2.8. Operation 10044: CB_ILLEGAL - Illegal Callback 16.2.8. Operation 10044: CB_ILLEGAL - Illegal Callback
Operation . . . . . . . . . . . . . . . . . . . . . 290 Operation . . . . . . . . . . . . . . . . . . . . . 287
17. Security Considerations . . . . . . . . . . . . . . . . . . . 291 17. Security Considerations . . . . . . . . . . . . . . . . . . . 288
18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 293 18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 290
18.1. Named Attribute Definitions . . . . . . . . . . . . . . 293 18.1. Named Attribute Definitions . . . . . . . . . . . . . . 290
18.1.1. Initial Registry . . . . . . . . . . . . . . . . . . 294 18.1.1. Initial Registry . . . . . . . . . . . . . . . . . . 291
18.1.2. Updating Registrations . . . . . . . . . . . . . . . 294 18.1.2. Updating Registrations . . . . . . . . . . . . . . . 291
19. References . . . . . . . . . . . . . . . . . . . . . . . . . 294 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 291
19.1. Normative References . . . . . . . . . . . . . . . . . . 294 19.1. Normative References . . . . . . . . . . . . . . . . . . 291
19.2. Informative References . . . . . . . . . . . . . . . . . 296 19.2. Informative References . . . . . . . . . . . . . . . . . 293
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 298 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 295
Appendix B. RFC Editor Notes . . . . . . . . . . . . . . . . . . 299 Appendix B. RFC Editor Notes . . . . . . . . . . . . . . . . . . 296
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 300 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 297
1. Introduction 1. Introduction
1.1. NFS Version 4 Goals 1.1. NFS Version 4 Goals
The Network Filesystem version 4 (NFSv4) protocol is a further The Network Filesystem version 4 (NFSv4) protocol is a further
revision of the NFS protocol defined already by versions 2 [RFC1094] revision of the NFS protocol defined already by versions 2 [RFC1094]
and 3 [RFC1813]. It retains the essential characteristics of and 3 [RFC1813]. It retains the essential characteristics of
previous versions: design for easy recovery, independent of transport previous versions: design for easy recovery, independent of transport
protocols, operating systems and file systems, simplicity, and good protocols, operating systems and file systems, simplicity, and good
skipping to change at page 8, line 32 skipping to change at page 8, line 32
compromise backward compatibility. compromise backward compatibility.
This document, together with the companion XDR description document This document, together with the companion XDR description document
[RFCNFSv4XDR], obsoletes [RFC3530] as the authoritative document [RFCNFSv4XDR], obsoletes [RFC3530] as the authoritative document
describing NFSv4. It does not introduce any over-the-wire protocol describing NFSv4. It does not introduce any over-the-wire protocol
changes, in the sense that previously valid requests remain valid. changes, in the sense that previously valid requests remain valid.
1.2. Definitions in the companion document NFS Version 4 Protocol are 1.2. Definitions in the companion document NFS Version 4 Protocol are
Authoritative Authoritative
[RFCNFSv4XDR], NFS Version 4 Protocol, contains the definitions in [RFCNFSv4XDR], "Network File System (NFS) Version 4 External Data
XDR description language of the constructs used by the protocol. Representation Standard (XDR) Description", contains the definitions
in XDR description language of the constructs used by the protocol.
Inside this document, several of the constructs are reproduced for Inside this document, several of the constructs are reproduced for
purposes of explanation. The reader is warned of the possibility of purposes of explanation. The reader is warned of the possibility of
errors in the reproduced constructs outside of [RFCNFSv4XDR]. For errors in the reproduced constructs outside of [RFCNFSv4XDR]. For
any part of the document that is inconsistent with [RFCNFSv4XDR], any part of the document that is inconsistent with [RFCNFSv4XDR],
[RFCNFSv4XDR] is to be considered authoritative. [RFCNFSv4XDR] is to be considered authoritative.
1.3. Overview of NFSv4 Features 1.3. Overview of NFSv4 Features
To provide a reasonable context for the reader, the major features of To provide a reasonable context for the reader, the major features of
NFSv4 protocol will be reviewed in brief. This will be done to NFSv4 protocol will be reviewed in brief. This will be done to
skipping to change at page 15, line 14 skipping to change at page 15, line 14
Verifier: A 64-bit quantity generated by the client that the server Verifier: A 64-bit quantity generated by the client that the server
can use to determine if the client has restarted and lost all can use to determine if the client has restarted and lost all
previous lock state. previous lock state.
1.5. Changes since RFC 3530 1.5. Changes since RFC 3530
The main changes from RFC 3530 [RFC3530] are: The main changes from RFC 3530 [RFC3530] are:
o The XDR definition has been moved to a companion document o The XDR definition has been moved to a companion document
[RFCNFSv4XDR] [RFCNFSv4XDR].
o Updates for the latest IETF intellectual property statements o The IETF intellectual property statements were updated to the
latest version.
o There is a restructured and more complete explanation of multi- o There is a restructured and more complete explanation of multi-
server namespace features. server namespace features.
o Updating handling of domain names to reflect Internationalized o The handling of domain names were updated to reflect
Domain Names in Applications (IDNA) [RFC5891]. Internationalized Domain Names in Applications (IDNA) [RFC5891].
o The previously required LIPKEY and SPKM-3 security mechanisms have o The previously required LIPKEY and SPKM-3 security mechanisms have
been removed. been removed.
o Some clarification on a client re-establishing callback o Some clarification on a client re-establishing callback
information to the new server if state has been migrated. information to the new server if state has been migrated.
o A third edge case was added for Courtesy locks and network o A third edge case was added for Courtesy locks and network
partitions. partitions.
o The definition of stateid was strengthened. o The definition of stateid was strengthened.
1.6. Changes since RFC 3010 1.6. Changes between RFC 3010 and RFC3530
This definition of the NFSv4 protocol replaces or obsoletes the The definition of the NFSv4 protocol in [RFC3530] replaced and
definition present in [RFC3010]. While portions of the two documents obsoleted the definition present in [RFC3010] While portions of the
have remained the same, there have been substantive changes in two documents remained the same, there were substantive changes in
others. The changes made between [RFC3010] and this document others. The changes made between [RFC3010] and [RFC3530] reflect
represent implementation experience and further review of the implementation experience and further review of the protocol.
protocol. While some modifications were made for ease of
implementation or clarification, most updates represent errors or
situations where the [RFC3010] definition were untenable.
The following list is not all inclusive of all changes but presents The following list is not all inclusive of all changes but presents
some of the most notable changes or additions made: some of the most notable changes or additions made:
o The state model has added an open_owner4 identifier. This was o The state model has added an open_owner4 identifier. This was
done to accommodate Posix based clients and the model they use for done to accommodate Posix based clients and the model they use for
file locking. For Posix clients, an open_owner4 would correspond file locking. For Posix clients, an open_owner4 would correspond
to a file descriptor potentially shared amongst a set of processes to a file descriptor potentially shared amongst a set of processes
and the lock_owner4 identifier would correspond to a process that and the lock_owner4 identifier would correspond to a process that
is locking a file. is locking a file.
skipping to change at page 18, line 8 skipping to change at page 18, line 5
| | UTF-8 encoding for strings. | | | UTF-8 encoding for strings. |
| utf8str_cis | typedef utf8string utf8str_cis; | | utf8str_cis | typedef utf8string utf8str_cis; |
| | Case insensitive UTF-8 string. | | | Case insensitive UTF-8 string. |
| utf8str_cs | typedef utf8string utf8str_cs; | | utf8str_cs | typedef utf8string utf8str_cs; |
| | Case sensitive UTF-8 string. | | | Case sensitive UTF-8 string. |
| utf8str_mixed | typedef utf8string utf8str_mixed; | | utf8str_mixed | typedef utf8string utf8str_mixed; |
| | UTF-8 strings with a case sensitive prefix and | | | UTF-8 strings with a case sensitive prefix and |
| | a case insensitive suffix. | | | a case insensitive suffix. |
| component4 | typedef utf8str_cs component4; | | component4 | typedef utf8str_cs component4; |
| | Represents pathname components. | | | Represents pathname components. |
| linktext4 | typedef opaque linktext4; | | linktext4 | typedef opaque linktext4<>; |
| | Symbolic link contents ("symbolic link" is | | | Symbolic link contents ("symbolic link" is |
| | defined in an Open Group [openg_symlink] | | | defined in an Open Group [openg_symlink] |
| | standard). | | | standard). |
| ascii_REQUIRED4 | typedef utf8string ascii_REQUIRED4; | | ascii_REQUIRED4 | typedef utf8string ascii_REQUIRED4; |
| | String MUST be sent as ASCII and thus is | | | String MUST be sent as ASCII and thus is |
| | automatically UTF-8. | | | automatically UTF-8. |
| pathname4 | typedef component4 pathname4<>; | | pathname4 | typedef component4 pathname4<>; |
| | Represents path name for fs_locations. | | | Represents path name for fs_locations. |
| nfs_lockid4 | typedef uint64_t nfs_lockid4; | | nfs_lockid4 | typedef uint64_t nfs_lockid4; |
| verifier4 | typedef opaque verifier4[NFS4_VERIFIER_SIZE]; | | verifier4 | typedef opaque verifier4[NFS4_VERIFIER_SIZE]; |
skipping to change at page 25, line 4 skipping to change at page 24, line 44
MUST support the Kerberos V5 security mechanism. MUST support the Kerberos V5 security mechanism.
The use of RPCSEC_GSS requires selection of mechanism, quality of The use of RPCSEC_GSS requires selection of mechanism, quality of
protection (QOP), and service (authentication, integrity, privacy). protection (QOP), and service (authentication, integrity, privacy).
For the mandated security mechanisms, NFSv4 specifies that a QOP of For the mandated security mechanisms, NFSv4 specifies that a QOP of
zero is used, leaving it up to the mechanism or the mechanism's zero is used, leaving it up to the mechanism or the mechanism's
configuration to map QOP zero to an appropriate level of protection. configuration to map QOP zero to an appropriate level of protection.
Each mandated mechanism specifies a minimum set of cryptographic Each mandated mechanism specifies a minimum set of cryptographic
algorithms for implementing integrity and privacy. NFSv4 clients and algorithms for implementing integrity and privacy. NFSv4 clients and
servers MUST be implemented on operating environments that comply servers MUST be implemented on operating environments that comply
with the REQUIRED cryptographic algorithms of each REQUIRED with the required cryptographic algorithms of each required
mechanism. mechanism.
3.2.1.1. Kerberos V5 as a Security Triple 3.2.1.1. Kerberos V5 as a Security Triple
The Kerberos V5 GSS-API mechanism as described in [RFC4121] MUST be The Kerberos V5 GSS-API mechanism as described in [RFC4121] MUST be
implemented with the RPCSEC_GSS services as specified in the implemented with the RPCSEC_GSS services as specified in the
following table: following table:
column descriptions: column descriptions:
1 == number of pseudo flavor 1 == number of pseudo flavor
skipping to change at page 25, line 35 skipping to change at page 25, line 27
390005 krb5p 1.2.840.113554.1.2.2 rpc_gss_svc_privacy no yes 390005 krb5p 1.2.840.113554.1.2.2 rpc_gss_svc_privacy no yes
Note that the pseudo flavor is presented here as a mapping aid to the Note that the pseudo flavor is presented here as a mapping aid to the
implementer. Because this NFS protocol includes a method to implementer. Because this NFS protocol includes a method to
negotiate security and it understands the GSS-API mechanism, the negotiate security and it understands the GSS-API mechanism, the
pseudo flavor is not needed. The pseudo flavor is needed for NFSv3 pseudo flavor is not needed. The pseudo flavor is needed for NFSv3
since the security negotiation is done via the MOUNT protocol as since the security negotiation is done via the MOUNT protocol as
described in [RFC2623]. described in [RFC2623].
At the time this document was specified, the Advanced Encryption At the time this document was specified, the Advanced Encryption
Standard (AES) with HMAC-SHA1 was a REQUIRED algorithm set for Standard (AES) with HMAC-SHA1 was a required algorithm set for
Kerberos V5. In contrast, when NFSv4.0 was first specified in Kerberos V5. In contrast, when NFSv4.0 was first specified in
[RFC3530], weaker algorithm sets were REQUIRED for Kerberos V5, and [RFC3530], weaker algorithm sets were REQUIRED for Kerberos V5, and
were REQUIRED in the NFSv4.0 specification, because the Kerberos V5 were REQUIRED in the NFSv4.0 specification, because the Kerberos V5
specification at the time did not specify stronger algorithms. The specification at the time did not specify stronger algorithms. The
NFSv4 specification does not specify REQUIRED algorithms for Kerberos NFSv4 specification does not specify required algorithms for Kerberos
V5, and instead, the implementer is expected to track the evolution V5, and instead, the implementer is expected to track the evolution
of the Kerberos V5 standard if and when stronger algorithms are of the Kerberos V5 standard if and when stronger algorithms are
specified. specified.
3.2.1.1.1. Security Considerations for Cryptographic Algorithms in 3.2.1.1.1. Security Considerations for Cryptographic Algorithms in
Kerberos V5 Kerberos V5
When deploying NFSv4, the strength of the security achieved depends When deploying NFSv4, the strength of the security achieved depends
on the existing Kerberos V5 infrastructure. The algorithms of on the existing Kerberos V5 infrastructure. The algorithms of
Kerberos V5 are not directly exposed to or selectable by the client Kerberos V5 are not directly exposed to or selectable by the client
skipping to change at page 30, line 4 skipping to change at page 29, line 40
by the server. by the server.
4.2.1. General Properties of a Filehandle 4.2.1. General Properties of a Filehandle
The filehandle contains all the information the server needs to The filehandle contains all the information the server needs to
distinguish an individual file. To the client, the filehandle is distinguish an individual file. To the client, the filehandle is
opaque. The client stores filehandles for use in a later request and opaque. The client stores filehandles for use in a later request and
can compare two filehandles from the same server for equality by can compare two filehandles from the same server for equality by
doing a byte-by-byte comparison. However, the client MUST NOT doing a byte-by-byte comparison. However, the client MUST NOT
otherwise interpret the contents of filehandles. If two filehandles otherwise interpret the contents of filehandles. If two filehandles
from the same server are equal, they MUST refer to the same file from the same server are equal, they MUST refer to the same file.
system object. Servers SHOULD try to maintain a one-to-one However, it is not required that two different filehandles refer to
correspondence between filehandles and file system objects but this different file system objects. Servers SHOULD try to maintain a one-
is not required. Clients MUST use filehandle comparisons only to to-one correspondence between filehandles and file system objects but
improve performance, not for correct behavior. All clients need to there may be situations in which the mapping is not one-to-one.
be prepared for situations in which it cannot be determined whether Clients MUST use filehandle comparisons only to improve performance,
two filehandles denote the same object and in such cases, avoid not for correct behavior. All clients need to be prepared for
making invalid assumptions which might cause incorrect behavior. situations in which it cannot be determined whether two different
Further discussion of filehandle and attribute comparison in the filehandles denote the same object and in such cases, avoid assuming
context of data caching is presented in Section 10.3.4. that objects denoted are different, as this might cause incorrect
behavior. Further discussion of filehandle and attribute comparison
in the context of data caching is presented in Section 10.3.4.
As an example, in the case that two different path names when As an example, in the case that two different path names when
traversed at the server terminate at the same file system object, the traversed at the server terminate at the same file system object, the
server SHOULD return the same filehandle for each path. This can server SHOULD return the same filehandle for each path. This can
occur if a hard link is used to create two file names which refer to occur if a hard link is used to create two file names which refer to
the same underlying file object and associated data. For example, if the same underlying file object and associated data. For example, if
paths /a/b/c and /a/d/c refer to the same file, the server SHOULD paths /a/b/c and /a/d/c refer to the same file, the server SHOULD
return the same filehandle for both path names traversals. return the same filehandle for both path names traversals.
4.2.2. Persistent Filehandle 4.2.2. Persistent Filehandle
skipping to change at page 31, line 6 skipping to change at page 30, line 44
4.2.3. Volatile Filehandle 4.2.3. Volatile Filehandle
A volatile filehandle does not share the same longevity A volatile filehandle does not share the same longevity
characteristics of a persistent filehandle. The server may determine characteristics of a persistent filehandle. The server may determine
that a volatile filehandle is no longer valid at many different that a volatile filehandle is no longer valid at many different
points in time. If the server can definitively determine that a points in time. If the server can definitively determine that a
volatile filehandle refers to an object that has been removed, the volatile filehandle refers to an object that has been removed, the
server should return NFS4ERR_STALE to the client (as is the case for server should return NFS4ERR_STALE to the client (as is the case for
persistent filehandles). In all other cases where the server persistent filehandles). In all other cases where the server
determines that a volatile filehandle can no longer be used, it determines that a volatile filehandle can no longer be used, it
should return an error of NFS4ERR_FHEXPIRED. SHOULD return an error of NFS4ERR_FHEXPIRED.
The mandatory attribute "fh_expire_type" is used by the client to The mandatory attribute "fh_expire_type" is used by the client to
determine what type of filehandle the server is providing for a determine what type of filehandle the server is providing for a
particular file system. This attribute is a bitmask with the particular file system. This attribute is a bitmask with the
following values: following values:
FH4_PERSISTENT: The value of FH4_PERSISTENT is used to indicate a FH4_PERSISTENT: The value of FH4_PERSISTENT is used to indicate a
persistent filehandle, which is valid until the object is removed persistent filehandle, which is valid until the object is removed
from the file system. The server will not return from the file system. The server will not return
NFS4ERR_FHEXPIRED for this filehandle. FH4_PERSISTENT is defined NFS4ERR_FHEXPIRED for this filehandle. FH4_PERSISTENT is defined
skipping to change at page 31, line 40 skipping to change at page 31, line 29
FH4_VOL_RENAME: The filehandle will expire during rename. This FH4_VOL_RENAME: The filehandle will expire during rename. This
includes a rename by the requesting client or a rename by any includes a rename by the requesting client or a rename by any
other client. If FH4_VOLATILE_ANY is set, FH4_VOL_RENAME is other client. If FH4_VOLATILE_ANY is set, FH4_VOL_RENAME is
redundant. redundant.
Servers which provide volatile filehandles that may expire while open Servers which provide volatile filehandles that may expire while open
(i.e., if FH4_VOL_MIGRATION or FH4_VOL_RENAME is set or if (i.e., if FH4_VOL_MIGRATION or FH4_VOL_RENAME is set or if
FH4_VOLATILE_ANY is set and FH4_NOEXPIRE_WITH_OPEN not set), should FH4_VOLATILE_ANY is set and FH4_NOEXPIRE_WITH_OPEN not set), should
deny a RENAME or REMOVE that would affect an OPEN file of any of the deny a RENAME or REMOVE that would affect an OPEN file of any of the
components leading to the OPEN file. In addition, the server should components leading to the OPEN file. In addition, the server SHOULD
deny all RENAME or REMOVE requests during the grace period upon deny all RENAME or REMOVE requests during the grace period upon
server restart. server restart.
Note that the bits FH4_VOL_MIGRATION and FH4_VOL_RENAME allow the Note that the bits FH4_VOL_MIGRATION and FH4_VOL_RENAME allow the
client to determine that expiration has occurred whenever a specific client to determine that expiration has occurred whenever a specific
event occurs, without an explicit filehandle expiration error from event occurs, without an explicit filehandle expiration error from
the server. FH4_VOLATILE_ANY does not provide this form of the server. FH4_VOLATILE_ANY does not provide this form of
information. In situations where the server will expire many, but information. In situations where the server will expire many, but
not all filehandles upon migration (e.g., all but those that are not all filehandles upon migration (e.g., all but those that are
open), FH4_VOLATILE_ANY (in this case with FH4_NOEXPIRE_WITH_OPEN) is open), FH4_VOLATILE_ANY (in this case with FH4_NOEXPIRE_WITH_OPEN) is
a better choice since the client may not assume that all filehandles a better choice since the client may not assume that all filehandles
will expire when migration occurs, and it is likely that additional will expire when migration occurs, and it is likely that additional
expirations will occur (as a result of file CLOSE) that are separated expirations will occur (as a result of file CLOSE) that are separated
in time from the migration event itself. in time from the migration event itself.
4.2.4. One Method of Constructing a Volatile Filehandle 4.2.4. One Method of Constructing a Volatile Filehandle
A volatile filehandle, while opaque to the client could contain: A volatile filehandle, while opaque to the client, could contain:
[volatile bit = 1 | server boot time | slot | generation number] [volatile bit = 1 | server boot time | slot | generation number]
o slot is an index in the server volatile filehandle table o slot is an index in the server volatile filehandle table
o generation number is the generation number for the table entry/ o generation number is the generation number for the table entry/
slot slot
When the client presents a volatile filehandle, the server makes the When the client presents a volatile filehandle, the server makes the
following checks, which assume that the check for the volatile bit following checks, which assume that the check for the volatile bit
has passed. If the server boot time is less than the current server has passed. If the server boot time is less than the current server
boot time, return NFS4ERR_FHEXPIRED. If slot is out of range, return boot time, return NFS4ERR_FHEXPIRED. If slot is out of range, return
NFS4ERR_BADHANDLE. If the generation number does not match, return NFS4ERR_BADHANDLE. If the generation number does not match, return
NFS4ERR_FHEXPIRED. NFS4ERR_FHEXPIRED.
skipping to change at page 34, line 45 skipping to change at page 34, line 34
named attribute directory are undefined. named attribute directory are undefined.
5.1. REQUIRED Attributes 5.1. REQUIRED Attributes
These MUST be supported by every NFSv4.0 client and server in order These MUST be supported by every NFSv4.0 client and server in order
to ensure a minimum level of interoperability. The server MUST store to ensure a minimum level of interoperability. The server MUST store
and return these attributes, and the client MUST be able to function and return these attributes, and the client MUST be able to function
with an attribute set limited to these attributes. With just the with an attribute set limited to these attributes. With just the
REQUIRED attributes some client functionality can be impaired or REQUIRED attributes some client functionality can be impaired or
limited in some ways. A client can ask for any of these attributes limited in some ways. A client can ask for any of these attributes
to be returned by setting a bit in the GETATTR request, and the to be returned by setting a bit in the GETATTR request. For each
server MUST return their value. such bit set, the server MUST return the corresponding attribute
value.
5.2. RECOMMENDED Attributes 5.2. RECOMMENDED Attributes
These attributes are understood well enough to warrant support in the These attributes are understood well enough to warrant support in the
NFSv4.0 protocol. However, they may not be supported on all clients NFSv4.0 protocol. However, they may not be supported on all clients
and servers. A client MAY ask for any of these attributes to be and servers. A client MAY ask for any of these attributes to be
returned by setting a bit in the GETATTR request but MUST handle the returned by setting a bit in the GETATTR request but MUST handle the
case where the server does not return them. A client MAY ask for the case where the server does not return them. A client MAY ask for the
set of attributes the server supports and SHOULD NOT request set of attributes the server supports and SHOULD NOT request
attributes the server does not support. A server should be tolerant attributes the server does not support. A server should be tolerant
skipping to change at page 36, line 49 skipping to change at page 36, line 32
o Creating hard links between named attribute directories or between o Creating hard links between named attribute directories or between
named attribute directories and ordinary directories is not named attribute directories and ordinary directories is not
allowed. allowed.
Names of attributes will not be controlled by this document or other Names of attributes will not be controlled by this document or other
IETF Standards Track documents. See Section 18 for further IETF Standards Track documents. See Section 18 for further
discussion. discussion.
5.4. Classification of Attributes 5.4. Classification of Attributes
Each of the REQUIRED and RECOMMENDED attributes can be classified in Each of attributes accessed using SETATTR and GETATTR (i.e., REQUIRED
one of three categories: per server (i.e., the value of the attribute an RECOMMENDED attributes) can be can be classified in one of three
will be the same for all file objects that share the same server), categories:
per file system (i.e., the value of the attribute will be the same
for some or all file objects that share the same fsid attribute 1. per server attributes for which the value of the attribute will
(Section 5.8.1.9) and server owner), or per file system object. Note be the same for all file objects that share the same server.
that it is possible that some per file system attributes may vary
within the file system. Note that it is possible that some per file 2. per file system attributes for whch the value of the attribute
system attributes may vary within the file system, depending on the will be the same for some or all file objects that share the same
value of the "homogeneous" (Section 5.8.2.16) attribute. Note that server and fsid attribute (Section 5.8.1.9). See below for
the attributes time_access_set and time_modify_set are not listed in details regarding when such sharing is in effect.
this section because they are write-only attributes corresponding to
3. per file system object attributes
The handling of per file system attributes depends on the particular
attribute and the setting of the homogeneous (Section 5.8.2.12)
attribute. The following rules apply:
1. The values of the attribute supported_attrs, fsid, homgeneous,
link_support, and symlink_support are always common to all object
within given file system.
2. For other attributes, different values may be returned for
different file system objects if the attribute homogeneous is
supported within the file system in question and has the value
false.
The classification of attributes is as follows. Note that the
attributes time_access_set and time_modify_set are not listed in this
section because they are write-only attributes corresponding to
time_access and time_modify, and are used in a special instance of time_access and time_modify, and are used in a special instance of
SETATTR. SETATTR.
o The per-server attribute is: o The per-server attribute is:
lease_time lease_time
o The per-file system attributes are: o The per-file system attributes are:
supported_attrs, fh_expire_type, link_support, symlink_support, supported_attrs, fh_expire_type, link_support, symlink_support,
skipping to change at page 38, line 16 skipping to change at page 38, line 16
The list of REQUIRED attributes appears in Table 2. The meaning of The list of REQUIRED attributes appears in Table 2. The meaning of
the columns of the table are: the columns of the table are:
o Name: The name of attribute o Name: The name of attribute
o Id: The number assigned to the attribute. In the event of o Id: The number assigned to the attribute. In the event of
conflicts between the assigned number and [RFCNFSv4XDR], the conflicts between the assigned number and [RFCNFSv4XDR], the
latter is authoritative, but in such an event, it should be latter is authoritative, but in such an event, it should be
resolved with Errata to this document and/or [RFCNFSv4XDR]. See resolved with Errata to this document and/or [RFCNFSv4XDR]. See
[ISEG_errata] for the Errata process. [IESG_errata] for the Errata process.
o Data Type: The XDR data type of the attribute. o Data Type: The XDR data type of the attribute.
o Acc: Access allowed to the attribute. R means read-only (GETATTR o Acc: Access allowed to the attribute. R means read-only (GETATTR
may retrieve, SETATTR may not set). W means write-only (SETATTR may retrieve, SETATTR may not set). W means write-only (SETATTR
may set, GETATTR may not retrieve). R W means read/write (GETATTR may set, GETATTR may not retrieve). R W means read/write (GETATTR
may retrieve, SETATTR may set). may retrieve, SETATTR may set).
o Defined in: The section of this specification that describes the o Defined in: The section of this specification that describes the
attribute. attribute.
skipping to change at page 40, line 48 skipping to change at page 40, line 48
Within the explanatory text and operation descriptions, the following Within the explanatory text and operation descriptions, the following
phrases will be used with the meanings given below: phrases will be used with the meanings given below:
o The phrase "is a directory" means that the object's type attribute o The phrase "is a directory" means that the object's type attribute
is NF4DIR or NF4ATTRDIR. is NF4DIR or NF4ATTRDIR.
o The phrase "is a special file" means that the object's type o The phrase "is a special file" means that the object's type
attribute is NF4BLK, NF4CHR, NF4SOCK, or NF4FIFO. attribute is NF4BLK, NF4CHR, NF4SOCK, or NF4FIFO.
o The phrase "is an regular file" means that the object's type o The phrase "is a regular file" means that the object's type
attribute is NF4REG or NF4NAMEDATTR. attribute is NF4REG or NF4NAMEDATTR.
o The phrase "is a symbolic link" means that the object's type
attribute is NF4LNK.
5.8.1.3. Attribute 2: fh_expire_type 5.8.1.3. Attribute 2: fh_expire_type
Server uses this to specify filehandle expiration behavior to the Server uses this to specify filehandle expiration behavior to the
client. See Section 4 for additional description. client. See Section 4 for additional description.
5.8.1.4. Attribute 3: change 5.8.1.4. Attribute 3: change
A value created by the server that the client can use to determine if A value created by the server that the client can use to determine if
file data, directory contents, or attributes of the object have been file data, directory contents, or attributes of the object have been
modified. The server MAY return the object's time_metadata attribute modified. The server MAY return the object's time_metadata attribute
skipping to change at page 42, line 33 skipping to change at page 42, line 37
modification (deprecated in favor of time_backup). modification (deprecated in favor of time_backup).
5.8.2.2. Attribute 15: cansettime 5.8.2.2. Attribute 15: cansettime
TRUE, if the server is able to change the times for a file system TRUE, if the server is able to change the times for a file system
object as specified in a SETATTR operation. object as specified in a SETATTR operation.
5.8.2.3. Attribute 16: case_insensitive 5.8.2.3. Attribute 16: case_insensitive
TRUE, if file name comparisons on this file system are case TRUE, if file name comparisons on this file system are case
insensitive. insensitive. This refers only to comparisons, and not to the case in
which file names are stored.
5.8.2.4. Attribute 17: case_preserving 5.8.2.4. Attribute 17: case_preserving
TRUE, if file name case on this file system is preserved. TRUE, if file name case on this file system is preserved. This
refers only to how file names are stored, and not to how they are
compared. File names stored in mixed case might be compared using
either case-insensitive or case-sensitive comparisons.
5.8.2.5. Attribute 18: chown_restricted 5.8.2.5. Attribute 18: chown_restricted
If TRUE, the server will reject any request to change either the If TRUE, the server will reject any request to change either the
owner or the group associated with a file if the caller is not a owner or the group associated with a file if the caller is not a
privileged user (for example, "root" in UNIX operating environments privileged user (for example, "root" in UNIX operating environments
or in Windows 2000, the "Take Ownership" privilege). or in Windows 2000, the "Take Ownership" privilege).
5.8.2.6. Attribute 20: fileid 5.8.2.6. Attribute 20: fileid
skipping to change at page 44, line 19 skipping to change at page 44, line 23
5.8.2.17. Attribute 31: maxwrite 5.8.2.17. Attribute 31: maxwrite
Maximum amount of data the WRITE operation will accept for this Maximum amount of data the WRITE operation will accept for this
object. This attribute SHOULD be supported if the file is writable. object. This attribute SHOULD be supported if the file is writable.
Lack of this attribute can lead to the client either wasting Lack of this attribute can lead to the client either wasting
bandwidth or not receiving the best performance. bandwidth or not receiving the best performance.
5.8.2.18. Attribute 32: mimetype 5.8.2.18. Attribute 32: mimetype
MIME body type/subtype of this object. MIME media type/subtype of this object.
5.8.2.19. Attribute 55: mounted_on_fileid 5.8.2.19. Attribute 55: mounted_on_fileid
Like fileid, but if the target filehandle is the root of a file Like fileid, but if the target filehandle is the root of a file
system, this attribute represents the fileid of the underlying system, this attribute represents the fileid of the underlying
directory. directory.
UNIX-based operating environments connect a file system into the UNIX-based operating environments connect a file system into the
namespace by connecting (mounting) the file system onto the existing namespace by connecting (mounting) the file system onto the existing
file object (the mount point, usually a directory) of an existing file object (the mount point, usually a directory) of an existing
skipping to change at page 46, line 36 skipping to change at page 46, line 42
e.g., "all files with a given owner", "all files with a given group e.g., "all files with a given owner", "all files with a given group
owner", etc. The server is at liberty to choose any of those sets owner", etc. The server is at liberty to choose any of those sets
when providing the content of the quota_used attribute, but should do when providing the content of the quota_used attribute, but should do
so in a repeatable way. The rule may be configured per file system so in a repeatable way. The rule may be configured per file system
or may be "choose the set with the smallest quota". or may be "choose the set with the smallest quota".
5.8.2.27. Attribute 41: rawdev 5.8.2.27. Attribute 41: rawdev
Raw device number of file of type NF4BLK or NF4CHR. The device Raw device number of file of type NF4BLK or NF4CHR. The device
number is split into major and minor numbers. If the file's type number is split into major and minor numbers. If the file's type
attribute is not NF4BLK or NF4CHR, the value returned SHOULD NOT be attribute is not NF4BLK or NF4CHR, this attribute SHOULD NOT be
considered useful. returned, and any value returned SHOULD NOT be considered useful.
5.8.2.28. Attribute 42: space_avail 5.8.2.28. Attribute 42: space_avail
Disk space in bytes available to this user on the file system Disk space in bytes available to this user on the file system
containing this object -- this should be the smallest relevant limit. containing this object -- this should be the smallest relevant limit.
5.8.2.29. Attribute 43: space_free 5.8.2.29. Attribute 43: space_free
Free disk space in bytes on the file system containing this object -- Free disk space in bytes on the file system containing this object --
this should be the smallest relevant limit. this should be the smallest relevant limit.
skipping to change at page 51, line 25 skipping to change at page 51, line 35
case insensitive comparisons of Unicode characters SHOULD use Unicode case insensitive comparisons of Unicode characters SHOULD use Unicode
Default Case Folding as defined in Chapter 3 of the Unicode Standard Default Case Folding as defined in Chapter 3 of the Unicode Standard
[UNICODE], and MAY override that behavior for specific selected [UNICODE], and MAY override that behavior for specific selected
characters with the case folding defined in the SpecialCasing.txt characters with the case folding defined in the SpecialCasing.txt
[SPECIALCASING] file in section 3.13 of the Unicode Standard. [SPECIALCASING] file in section 3.13 of the Unicode Standard.
The SpecialCasing.txt file replaces the Default Case Folding with The SpecialCasing.txt file replaces the Default Case Folding with
locale and context-dependent case folding for specific situations. locale and context-dependent case folding for specific situations.
An example of locale and context-dependent case folding is that LATIN An example of locale and context-dependent case folding is that LATIN
CAPITAL LETTER I ("I", U+0049) is default case folded to LATIN SMALL CAPITAL LETTER I ("I", U+0049) is default case folded to LATIN SMALL
LETTER I ("i", U+0069); however, Turkish and several other languages) LETTER I ("i", U+0069); however, several languages (e.g. Turkish)
treat an "I" character with a dot as a different letter than an "I" treat an "I" character with a dot as a different letter than an "I"
character without a dot, therefore in such languages, unless an I is character without a dot, therefore in such languages, unless an I is
before a dot_above, the "I" (U+0049) character should be case folded before a dot_above, the "I" (U+0049) character should be case folded
to a different character, LATIN SMALL LETTER DOTLESS I (U+0131). to a different character, LATIN SMALL LETTER DOTLESS I (U+0131).
The [UNICODE] and [SPECIALCASING] references in this RFC are for The [UNICODE] and [SPECIALCASING] references in this RFC are for
version 6.3.0 of the Unicode standard, as that was the latest version version 6.3.0 of the Unicode standard, as that was the latest version
of Unicode when this RFC was published. Implementations SHOULD of Unicode when this RFC was published. Implementations SHOULD
always use the latest version of Unicode (http://www.unicode.org/ always use the latest version of Unicode (http://www.unicode.org/
versions/latest/). versions/latest/).
skipping to change at page 52, line 38 skipping to change at page 52, line 46
o When a mode attribute is set on an object, the ACL attributes may o When a mode attribute is set on an object, the ACL attributes may
need to be modified so as to not conflict with the new mode. In need to be modified so as to not conflict with the new mode. In
such cases, it is desirable that the ACL keep as much information such cases, it is desirable that the ACL keep as much information
as possible. This includes information about inheritance, AUDIT as possible. This includes information about inheritance, AUDIT
and ALARM ACEs, and permissions granted and denied that do not and ALARM ACEs, and permissions granted and denied that do not
conflict with the new mode. conflict with the new mode.
6.2. File Attributes Discussion 6.2. File Attributes Discussion
Support for each of the ACL attributes is RECOMMENED and not
required, since file systems accessed using NFSV4 might not support
ACL's.
6.2.1. Attribute 12: acl 6.2.1. Attribute 12: acl
The NFSv4.0 ACL attribute contains an array of access control entries The NFSv4.0 ACL attribute contains an array of access control entries
(ACEs) that are associated with the file system object. Although the (ACEs) that are associated with the file system object. Although the
client can read and write the acl attribute, the server is client can read and write the acl attribute, the server is
responsible for using the ACL to perform access control. The client responsible for using the ACL to perform access control. The client
can use the OPEN or ACCESS operations to check access without can use the OPEN or ACCESS operations to check access without
modifying or reading data or metadata. modifying or reading data or metadata.
The NFS ACE structure is defined as follows: The NFS ACE structure is defined as follows:
skipping to change at page 53, line 49 skipping to change at page 54, line 16
However, such an approach can render ACLs unusable without special However, such an approach can render ACLs unusable without special
client-side knowledge of the server's mapping, which defeats the client-side knowledge of the server's mapping, which defeats the
purpose of having a common NFSv4 ACL protocol. Therefore servers purpose of having a common NFSv4 ACL protocol. Therefore servers
should accept every ACL that they can without compromising security. should accept every ACL that they can without compromising security.
To help accomplish this, servers may make a special exception, in the To help accomplish this, servers may make a special exception, in the
case of unsupported permission bits, to the rule that bits not case of unsupported permission bits, to the rule that bits not
ALLOWED or DENIED by an ACL must be denied. For example, a UNIX- ALLOWED or DENIED by an ACL must be denied. For example, a UNIX-
style server might choose to silently allow read attribute style server might choose to silently allow read attribute
permissions even though an ACL does not explicitly allow those permissions even though an ACL does not explicitly allow those
permissions. (An ACL that explicitly denies permission to read permissions. (An ACL that explicitly denies permission to read
attributes should still be rejected.) attributes should still result in a denial.)
The situation is complicated by the fact that a server may have The situation is complicated by the fact that a server may have
multiple modules that enforce ACLs. For example, the enforcement for multiple modules that enforce ACLs. For example, the enforcement for
NFSv4.0 access may be different from, but not weaker than, the NFSv4.0 access may be different from, but not weaker than, the
enforcement for local access, and both may be different from the enforcement for local access, and both may be different from the
enforcement for access through other protocols such as Server Message enforcement for access through other protocols such as Server Message
Block (SMB). So it may be useful for a server to accept an ACL even Block (SMB). So it may be useful for a server to accept an ACL even
if not all of its modules are able to support it. if not all of its modules are able to support it.
The guiding principle with regard to NFSv4 access is that the server The guiding principle with regard to NFSv4 access is that the server
must not accept ACLs that appear to make access to the file more must not accept ACLs that give an appearance of more restricted
restrictive than it really is. access to a file than what is actually enforced.
6.2.1.1. ACE Type 6.2.1.1. ACE Type
The constants used for the type field (acetype4) are as follows: The constants used for the type field (acetype4) are as follows:
const ACE4_ACCESS_ALLOWED_ACE_TYPE = 0x00000000; const ACE4_ACCESS_ALLOWED_ACE_TYPE = 0x00000000;
const ACE4_ACCESS_DENIED_ACE_TYPE = 0x00000001; const ACE4_ACCESS_DENIED_ACE_TYPE = 0x00000001;
const ACE4_SYSTEM_AUDIT_ACE_TYPE = 0x00000002; const ACE4_SYSTEM_AUDIT_ACE_TYPE = 0x00000002;
const ACE4_SYSTEM_ALARM_ACE_TYPE = 0x00000003; const ACE4_SYSTEM_ALARM_ACE_TYPE = 0x00000003;
skipping to change at page 56, line 12 skipping to change at page 56, line 12
Servers which support either the ALLOW or DENY ACE type SHOULD Servers which support either the ALLOW or DENY ACE type SHOULD
support both ALLOW and DENY ACE types. support both ALLOW and DENY ACE types.
Clients should not attempt to set an ACE unless the server claims Clients should not attempt to set an ACE unless the server claims
support for that ACE type. If the server receives a request to set support for that ACE type. If the server receives a request to set
an ACE that it cannot store, it MUST reject the request with an ACE that it cannot store, it MUST reject the request with
NFS4ERR_ATTRNOTSUPP. If the server receives a request to set an ACE NFS4ERR_ATTRNOTSUPP. If the server receives a request to set an ACE
that it can store but cannot enforce, the server SHOULD reject the that it can store but cannot enforce, the server SHOULD reject the
request with NFS4ERR_ATTRNOTSUPP. request with NFS4ERR_ATTRNOTSUPP.
Support for any of the ACL attributes is optional (albeit,
RECOMMENDED).
6.2.1.3. ACE Access Mask 6.2.1.3. ACE Access Mask
The bitmask constants used for the access mask field are as follows: The bitmask constants used for the access mask field are as follows:
const ACE4_READ_DATA = 0x00000001; const ACE4_READ_DATA = 0x00000001;
const ACE4_LIST_DIRECTORY = 0x00000001; const ACE4_LIST_DIRECTORY = 0x00000001;
const ACE4_WRITE_DATA = 0x00000002; const ACE4_WRITE_DATA = 0x00000002;
const ACE4_ADD_FILE = 0x00000002; const ACE4_ADD_FILE = 0x00000002;
const ACE4_APPEND_DATA = 0x00000004; const ACE4_APPEND_DATA = 0x00000004;
const ACE4_ADD_SUBDIRECTORY = 0x00000004; const ACE4_ADD_SUBDIRECTORY = 0x00000004;
skipping to change at page 57, line 4 skipping to change at page 56, line 49
ACE4_WRITE_DATA, and ACE4_APPEND_DATA are intended to be used with ACE4_WRITE_DATA, and ACE4_APPEND_DATA are intended to be used with
non-directory objects. non-directory objects.
6.2.1.3.1. Discussion of Mask Attributes 6.2.1.3.1. Discussion of Mask Attributes
ACE4_READ_DATA ACE4_READ_DATA
Operation(s) affected: Operation(s) affected:
READ READ
OPEN OPEN
Discussion: Discussion:
Permission to read the data of the file. Permission to read the data of the file.
Servers SHOULD allow a user the ability to read the data of the Servers SHOULD allow a user the ability to read the data of the
file when only the ACE4_EXECUTE access mask bit is allowed. file when only the ACE4_EXECUTE access mask bit is set.
ACE4_LIST_DIRECTORY ACE4_LIST_DIRECTORY
Operation(s) affected: Operation(s) affected:
READDIR READDIR
Discussion: Discussion:
Permission to list the contents of a directory. Permission to list the contents of a directory.
skipping to change at page 59, line 39 skipping to change at page 59, line 35
Operation(s) affected: Operation(s) affected:
READ READ
Discussion: Discussion:
Permission to execute a file. Permission to execute a file.
Servers SHOULD allow a user the ability to read the data of the Servers SHOULD allow a user the ability to read the data of the
file when only the ACE4_EXECUTE access mask bit is allowed. file when only the ACE4_EXECUTE access mask bit is set. This
This is because there is no way to execute a file without is because there is no way to execute a file without reading
reading the contents. Though a server may treat ACE4_EXECUTE the contents. Though a server may treat ACE4_EXECUTE and
and ACE4_READ_DATA bits identically when deciding to permit a ACE4_READ_DATA bits identically when deciding to permit a READ
READ operation, it SHOULD still allow the two bits to be set operation, it SHOULD still allow the two bits to be set
independently in ACLs, and MUST distinguish between them when independently in ACLs, and MUST distinguish between them when
replying to ACCESS operations. In particular, servers SHOULD replying to ACCESS operations. In particular, servers SHOULD
NOT silently turn on one of the two bits when the other is set, NOT silently turn on one of the two bits when the other is set,
as that would make it impossible for the client to correctly as that would make it impossible for the client to correctly
enforce the distinction between read and execute permissions. enforce the distinction between read and execute permissions.
As an example, following a SETATTR of the following ACL: As an example, following a SETATTR of the following ACL:
nfsuser:ACE4_EXECUTE:ALLOW nfsuser:ACE4_EXECUTE:ALLOW
A subsequent GETATTR of ACL for that file SHOULD return: A subsequent GETATTR of ACL for that file SHOULD return:
nfsuser:ACE4_EXECUTE:ALLOW nfsuser:ACE4_EXECUTE:ALLOW
Rather than: Rather than:
nfsuser:ACE4_EXECUTE/ACE4_READ_DATA:ALLOW nfsuser:ACE4_EXECUTE/ACE4_READ_DATA:ALLOW
ACE4_EXECUTE ACE4_EXECUTE
skipping to change at page 63, line 49 skipping to change at page 63, line 47
ACE4_DELETE on the object itself (the "target"), and ACE4_DELETE on the object itself (the "target"), and
ACE4_DELETE_CHILD on the containing directory (the "parent"). ACE4_DELETE_CHILD on the containing directory (the "parent").
Many systems also take the "sticky bit" (MODE4_SVTX) on a directory Many systems also take the "sticky bit" (MODE4_SVTX) on a directory
to allow unlink only to a user that owns either the target or the to allow unlink only to a user that owns either the target or the
parent; on some such systems the decision also depends on whether the parent; on some such systems the decision also depends on whether the
target is writable. target is writable.
Servers SHOULD allow unlink if either ACE4_DELETE is permitted on the Servers SHOULD allow unlink if either ACE4_DELETE is permitted on the
target, or ACE4_DELETE_CHILD is permitted on the parent. (Note that target, or ACE4_DELETE_CHILD is permitted on the parent. (Note that
this is true even if the parent or target explicitly denies one of this is true even if the parent or target explicitly denies the other
these permissions.) of these permissions.)
If the ACLs in question neither explicitly ALLOW nor DENY either of If the ACLs in question neither explicitly ALLOW nor DENY either of
the above, and if MODE4_SVTX is not set on the parent, then the the above, and if MODE4_SVTX is not set on the parent, then the
server SHOULD allow the removal if and only if ACE4_ADD_FILE is server SHOULD allow the removal if and only if ACE4_ADD_FILE is
permitted. In the case where MODE4_SVTX is set, the server may also permitted. In the case where MODE4_SVTX is set, the server may also
require the remover to own either the parent or the target, or may require the remover to own either the parent or the target, or may
require the target to be writable. require the target to be writable.
This allows servers to support something close to traditional UNIX- This allows servers to support something close to traditional UNIX-
like semantics, with ACE4_ADD_FILE taking the place of the write bit. like semantics, with ACE4_ADD_FILE taking the place of the write bit.
skipping to change at page 68, line 46 skipping to change at page 68, line 35
6.3.1.2. Client Considerations 6.3.1.2. Client Considerations
Clients SHOULD NOT do their own access checks based on their Clients SHOULD NOT do their own access checks based on their
interpretation the ACL, but rather use the OPEN and ACCESS operations interpretation the ACL, but rather use the OPEN and ACCESS operations
to do access checks. This allows the client to act on the results of to do access checks. This allows the client to act on the results of
having the server determine whether or not access should be granted having the server determine whether or not access should be granted
based on its interpretation of the ACL. based on its interpretation of the ACL.
Clients must be aware of situations in which an object's ACL will Clients must be aware of situations in which an object's ACL will
define a certain access even though the server will not enforce it. define a certain access even though the server will not have adequate
In general, but especially in these situations, the client needs to information to enforce it. For example, the server has no way of
do its part in the enforcement of access as defined by the ACL. To determining whether a particular OPEN reflects a user's open for read
do this, the client MAY send the appropriate ACCESS operation prior access, or is done as part of executing the file in question In such
to servicing the request of the user or application in order to situations, the client needs to do its part in the enforcement of
access as defined by the ACL. To do this, the client will send the
appropriate ACCESS operation (or use a cached previous determination)
prior to servicing the request of the user or application in order to
determine whether the user or application should be granted the determine whether the user or application should be granted the
access requested. For examples in which the ACL may define accesses access requested. For examples in which the ACL may define accesses
that the server doesn't enforce see Section 6.3.1.1. that the server does not enforce see Section 6.3.1.1.
6.3.2. Computing a Mode Attribute from an ACL 6.3.2. Computing a Mode Attribute from an ACL
The following method can be used to calculate the MODE4_R*, MODE4_W* The following method can be used to calculate the MODE4_R*, MODE4_W*
and MODE4_X* bits of a mode attribute, based upon an ACL. and MODE4_X* bits of a mode attribute, based upon an ACL.
First, for each of the special identifiers OWNER@, GROUP@, and First, for each of the special identifiers OWNER@, GROUP@, and
EVERYONE@, evaluate the ACL in order, considering only ALLOW and DENY EVERYONE@, evaluate the ACL in order, considering only ALLOW and DENY
ACEs for the identifier EVERYONE@ and for the identifier under ACEs for the identifier EVERYONE@ and for the identifier under
consideration. The result of the evaluation will be an NFSv4 ACL consideration. The result of the evaluation will be an NFSv4 ACL
skipping to change at page 73, line 45 skipping to change at page 73, line 36
set), into two ACEs, one with no inheritance flags, and one with set), into two ACEs, one with no inheritance flags, and one with
ACE4_INHERIT_ONLY_ACE set. This makes it simpler to modify the ACE4_INHERIT_ONLY_ACE set. This makes it simpler to modify the
effective permissions on the directory without modifying the ACE effective permissions on the directory without modifying the ACE
which is to be inherited to the new directory's children. which is to be inherited to the new directory's children.
7. NFS Server Name Space 7. NFS Server Name Space
7.1. Server Exports 7.1. Server Exports
On a UNIX server the name space describes all the files reachable by On a UNIX server the name space describes all the files reachable by
pathnames under the root directory or "/". On a Windows NT server pathnames under the root directory or "/". On a Windows server the
the name space constitutes all the files on disks named by mapped name space constitutes all the files on disks named by mapped disk
disk letters. NFS server administrators rarely make the entire letters. NFS server administrators rarely make the entire server's
server's file system name space available to NFS clients. More often file system name space available to NFS clients. More often portions
portions of the name space are made available via an "export" of the name space are made available via an "export" feature. In
feature. In previous versions of the NFS protocol, the root previous versions of the NFS protocol, the root filehandle for each
filehandle for each export is obtained through the MOUNT protocol; export is obtained through the MOUNT protocol; the client sends a
the client sends a string that identifies an object in the exported string that identifies an object in the exported name space and the
name space and the server returns the root filehandle for it. The server returns the root filehandle for it. The MOUNT protocol
MOUNT protocol supports an EXPORTS procedure that will enumerate the supports an EXPORTS procedure that will enumerate the server's
server's exports. exports.
7.2. Browsing Exports 7.2. Browsing Exports
The NFSv4 protocol provides a root filehandle that clients can use to The NFSv4 protocol provides a root filehandle that clients can use to
obtain filehandles for these exports via a multi-component LOOKUP. A obtain filehandles for these exports via a multi-component LOOKUP. A
common user experience is to use a graphical user interface (perhaps common user experience is to use a graphical user interface (perhaps
a file "Open" dialog window) to find a file via progressive browsing a file "Open" dialog window) to find a file via progressive browsing
through a directory tree. The client must be able to move from one through a directory tree. The client must be able to move from one
export to another export via single-component, progressive LOOKUP export to another export via single-component, progressive LOOKUP
operations. operations.
skipping to change at page 81, line 7 skipping to change at page 80, line 47
event of server failures, communications problems, or other event of server failures, communications problems, or other
difficulties that make continued access to the current file system difficulties that make continued access to the current file system
impossible or otherwise impractical. Under some circumstances, impossible or otherwise impractical. Under some circumstances,
multiple alternative locations may be used simultaneously to provide multiple alternative locations may be used simultaneously to provide
higher-performance access to the file system in question. Provision higher-performance access to the file system in question. Provision
of such alternative locations is referred to as "replication" of such alternative locations is referred to as "replication"
although there are cases in which replicated sets of data are not in although there are cases in which replicated sets of data are not in
fact present, and the replicas are instead different paths to the fact present, and the replicas are instead different paths to the
same data. same data.
When a file system is present and becomes absent, clients can be When a file system is present and subsequently becomes absent,
given the opportunity to have continued access to their data, at an clients can be given the opportunity to have continued access to
alternative location. In this case, a continued attempt to use the their data, at an alternative location. Transfer of the file system
data in the now-absent file system will result in an NFS4ERR_MOVED contents to the new location is referred to as "migration". See
error and, at that point, the successor locations (typically only one Section 8.4.2 for details.
although multiple choices are possible) can be fetched and used to
continue access. Transfer of the file system contents to the new Alternative locations may be be physical replicas of the file system
location is referred to as "migration", but it should be kept in mind data or alternative communication paths to the same server or, in the
that there are cases in which this term can be used, like case of various foms of server clustering, another server providing
"replication", when there is no actual data migration per se. access to the same physical file system. The client's
responsibilities in dealing with this transition depend on the
specific nature of the new access path as well as how and whether
data was in fact migrated. These issues will be discussed in detail
below.
Where a file system was not previously present, specification of file Where a file system was not previously present, specification of file
system location provides a means by which file systems located on one system location provides a means by which file systems located on one
server can be associated with a namespace defined by another server, server can be associated with a namespace defined by another server,
thus allowing a general multi-server namespace facility. A thus allowing a general multi-server namespace facility. A
designation of such a location, in place of an absent file system, is designation of such a location, in place of an absent file system, is
called a "referral". called a "referral".
Because client support for location-related attributes is OPTIONAL, a Because client support for location-related attributes is OPTIONAL, a
server may (but is not required to) take action to hide migration and server may (but is not required to) take action to hide migration and
skipping to change at page 81, line 45 skipping to change at page 81, line 41
fs_locations attribute. fs_locations attribute.
In the event that server failures, communications problems, or other In the event that server failures, communications problems, or other
difficulties make continued access to the current file system difficulties make continued access to the current file system
impossible or otherwise impractical, the client can use the impossible or otherwise impractical, the client can use the
alternative locations as a way to get continued access to its data. alternative locations as a way to get continued access to its data.
Multiple locations may be used simultaneously, to provide higher Multiple locations may be used simultaneously, to provide higher
performance through the exploitation of multiple paths between client performance through the exploitation of multiple paths between client
and target file system. and target file system.
The alternative locations may be physical replicas of the (typically
read-only) file system data, or they may reflect alternative paths to
the same server or provide for the use of various forms of server
clustering in which multiple servers provide alternative ways of
accessing the same physical file system. How these different modes
of file system transition are represented within the fs_locations
attribute and how the client deals with file system transition issues
will be discussed in detail below.
Multiple server addresses, whether they are derived from a single Multiple server addresses, whether they are derived from a single
entry with a DNS name representing a set of IP addresses or from entry with a DNS name representing a set of IP addresses or from
multiple entries each with its own server address, may correspond to multiple entries each with its own server address, may correspond to
the same actual server. the same actual server.
8.4.2. File System Migration 8.4.2. File System Migration
When a file system is present and becomes absent, clients can be When a file system is present and becomes absent, clients can be
given the opportunity to have continued access to their data, at an given the opportunity to have continued access to their data, at an
alternative location, as specified by the fs_locations attribute. alternative location, as specified by the fs_locations attribute.
skipping to change at page 82, line 29 skipping to change at page 82, line 15
to determine the new location of the data. to determine the new location of the data.
Such migration can be helpful in providing load balancing or general Such migration can be helpful in providing load balancing or general
resource reallocation. The protocol does not specify how the file resource reallocation. The protocol does not specify how the file
system will be moved between servers. It is anticipated that a system will be moved between servers. It is anticipated that a
number of different server-to-server transfer mechanisms might be number of different server-to-server transfer mechanisms might be
used with the choice left to the server implementer. The NFSv4 used with the choice left to the server implementer. The NFSv4
protocol specifies the method used to communicate the migration event protocol specifies the method used to communicate the migration event
between client and server. between client and server.
The new location may be an alternative communication path to the same
server or, in the case of various forms of server clustering, another
server providing access to the same physical file system. The
client's responsibilities in dealing with this transition depend on
the specific nature of the new access path as well as how and whether
data was in fact migrated. These issues will be discussed in detail
below.
When an alternative location is designated as the target for When an alternative location is designated as the target for
migration, it must designate the same data. Where file systems are migration, it must designate the same data. Where file systems are
writable, a change made on the original file system must be visible writable, a change made on the original file system must be visible
on all migration targets. Where a file system is not writable but on all migration targets. Where a file system is not writable but
represents a read-only copy (possibly periodically updated) of a represents a read-only copy (possibly periodically updated) of a
writable file system, similar requirements apply to the propagation writable file system, similar requirements apply to the propagation
of updates. Any change visible in the original file system must of updates. Any change visible in the original file system must
already be effected on all migration targets, to avoid any already be effected on all migration targets, to avoid any
possibility that a client, in effecting a transition to the migration possibility that a client, in effecting a transition to the migration
target, will see any reversion in file system state. target, will see any reversion in file system state.
skipping to change at page 94, line 8 skipping to change at page 93, line 32
on the new server. on the new server.
8.8.1. Inferring Transition Modes 8.8.1. Inferring Transition Modes
When fs_locations is used, information about the specific locations When fs_locations is used, information about the specific locations
should be assumed based on the following rules. should be assumed based on the following rules.
The following rules are general and apply irrespective of the The following rules are general and apply irrespective of the
context. context.
o All listed file system instances should be considered as of the o All listed file system instances should be considered as being of
same handle class if and only if the current fh_expire_type the same handle class if and only if the current fh_expire_type
attribute does not include the FH4_VOL_MIGRATION bit. Note that attribute does not include the FH4_VOL_MIGRATION bit. Note that
in the case of referral, filehandle issues do not apply since in the case of referral, filehandle issues do not apply since
there can be no filehandles known within the current file system there can be no filehandles known within the current file system
nor is there any access to the fh_expire_type attribute on the nor is there any access to the fh_expire_type attribute on the
referring (absent) file system. referring (absent) file system.
o All listed file system instances should be considered as of the o All listed file system instances should be considered as being of
same fileid class if and only if the fh_expire_type attribute the same fileid class if and only if the fh_expire_type attribute
indicates persistent filehandles and does not include the indicates persistent filehandles and does not include the
FH4_VOL_MIGRATION bit. Note that in the case of referral, fileid FH4_VOL_MIGRATION bit. Note that in the case of referral, fileid
issues do not apply since there can be no fileids known within the issues do not apply since there can be no fileids known within the
referring (absent) file system nor is there any access to the referring (absent) file system nor is there any access to the
fh_expire_type attribute. fh_expire_type attribute.
o All file system instances servers should be considered as of o All file system instances should be considered as being of
different change classes. different change classes.
o All file system instances servers should be considered as of o All file system instances servers should be considered as being of
different readdir classes. different readdir classes.
For other class assignments, handling of file system transitions For other class assignments, handling of file system transitions
depends on the reasons for the transition: depends on the reasons for the transition:
o When the transition is due to migration, that is, the client was o When the transition is due to migration, that is, the client was
directed to a new file system after receiving an NFS4ERR_MOVED directed to a new file system after receiving an NFS4ERR_MOVED
error, the target should be treated as being of the same write- error, the target should be treated as being of the same write-
verifier class as the source. verifier class as the source.
skipping to change at page 97, line 10 skipping to change at page 96, line 31
latter being the open-owner associated with the open file under which latter being the open-owner associated with the open file under which
the LOCK operation was done. the LOCK operation was done.
Client identification is encapsulated in the following structure: Client identification is encapsulated in the following structure:
struct nfs_client_id4 { struct nfs_client_id4 {
verifier4 verifier; verifier4 verifier;
opaque id<NFS4_OPAQUE_LIMIT>; opaque id<NFS4_OPAQUE_LIMIT>;
}; };
The first field, verifier is a client incarnation verifier that is The first field, verifier, is a client incarnation verifier that is
used to detect client reboots. Only if the verifier is different used to detect client reboots. Only if the verifier is different
from that which the server has previously recorded for the client (as from that which the server has previously recorded for the client (as
identified by the second field of the structure, id) does the server identified by the second field of the structure, id) does the server
start the process of canceling the client's leased state. start the process of canceling the client's leased state.
The second field, id is a variable length string that uniquely The second field, id, is a variable length string that uniquely
defines the client. defines the client.
There are several considerations for how the client generates the id There are several considerations for how the client generates the id
string: string:
o The string should be unique so that multiple clients do not o The string should be unique so that multiple clients do not
present the same string. The consequences of two clients present the same string. The consequences of two clients
presenting the same string range from one client getting an error presenting the same string range from one client getting an error
to one client having its leased state abruptly and unexpectedly to one client having its leased state abruptly and unexpectedly
canceled. canceled.
skipping to change at page 98, line 25 skipping to change at page 97, line 47
information to distinguish the client from other user level information to distinguish the client from other user level
clients running on the same host, such as an universally unique clients running on the same host, such as an universally unique
identifier (UUID). identifier (UUID).
o Additional information that tends to be unique, such as one or o Additional information that tends to be unique, such as one or
more of: more of:
* The client machine's serial number (for privacy reasons, it is * The client machine's serial number (for privacy reasons, it is
best to perform some one way function on the serial number). best to perform some one way function on the serial number).
* A MAC address. * A MAC address (for privacy reasons, it is best to perform some
one way function on the MAC address).
* The timestamp of when the NFSv4 software was first installed on * The timestamp of when the NFSv4 software was first installed on
the client (though this is subject to the previously mentioned the client (though this is subject to the previously mentioned
caution about using information that is stored in a file, caution about using information that is stored in a file,
because the file might only be accessible over NFSv4). because the file might only be accessible over NFSv4).
* A true random number. However since this number ought to be * A true random number. However since this number ought to be
the same between client incarnations, this shares the same the same between client incarnations, this shares the same
problem as that of the using the timestamp of the software problem as that of the using the timestamp of the software
installation. installation.
skipping to change at page 101, line 13 skipping to change at page 100, line 35
operations. operations.
o Stateids may represent sets of byte-range locks. o Stateids may represent sets of byte-range locks.
All locks held on a particular file by a particular owner and all All locks held on a particular file by a particular owner and all
gotten under the aegis of a particular open file are associated gotten under the aegis of a particular open file are associated
with a single stateid with the seqid being incremented whenever with a single stateid with the seqid being incremented whenever
LOCK and LOCKU operations affect that set of locks. LOCK and LOCKU operations affect that set of locks.
o Stateids may represent file delegations, which are recallable o Stateids may represent file delegations, which are recallable
guarantees by the server to the client, that other clients will guarantees by the server to the client that other clients will not
not reference, or will not modify a particular file, until the reference, or will not modify, a particular file until the
delegation is returned. delegation is returned.
A stateid represents a single delegation held by a client for a A stateid represents a single delegation held by a client for a
particular filehandle. particular filehandle.
9.1.3.2. Stateid Structure 9.1.3.2. Stateid Structure
Stateids are divided into two fields, a 96-bit "other" field Stateids are divided into two fields, a 96-bit "other" field
identifying the specific set of locks and a 32-bit "seqid" sequence identifying the specific set of locks and a 32-bit "seqid" sequence
value. Except in the case of special stateids (see Section 9.1.3.3), value. Except in the case of special stateids (see Section 9.1.3.3),
skipping to change at page 143, line 5 skipping to change at page 142, line 15
o First, cached data present on a client must be revalidated after o First, cached data present on a client must be revalidated after
doing an OPEN. Revalidating means that the client fetches the doing an OPEN. Revalidating means that the client fetches the
change attribute from the server, compares it with the cached change attribute from the server, compares it with the cached
change attribute, and if different, declares the cached data (as change attribute, and if different, declares the cached data (as
well as the cached attributes) as invalid. This is to ensure that well as the cached attributes) as invalid. This is to ensure that
the data for the OPENed file is still correctly reflected in the the data for the OPENed file is still correctly reflected in the
client's cache. This validation must be done at least when the client's cache. This validation must be done at least when the
client's OPEN operation includes DENY=WRITE or BOTH thus client's OPEN operation includes DENY=WRITE or BOTH thus
terminating a period in which other clients may have had the terminating a period in which other clients may have had the
opportunity to open the file with WRITE access. Clients may opportunity to open the file with WRITE access. Clients may
choose to do the revalidation more often (i.e., at OPENs choose to do the revalidation more often (such as an OPENs
specifying DENY=NONE) to parallel the NFSv3 protocol's practice specifying DENY=NONE) to parallel the NFSv3 protocol's practice
for the benefit of users assuming this degree of cache for the benefit of users assuming this degree of cache
revalidation. Since the change attribute is updated for data and revalidation.
metadata modifications, some client implementers may be tempted to
use the time_modify attribute and not the change attribute to Since the change attribute is updated for data and metadata
validate cached data, so that metadata changes do not spuriously modifications, some client implementers may be tempted to use the
invalidate clean data. The implementer is cautioned in this time_modify attribute and not the change attribute to validate
approach. The change attribute is guaranteed to change for each cached data, so that metadata changes do not spuriously invalidate
update to the file, whereas time_modify is guaranteed to change clean data. The implementer is cautioned in this approach. The
only at the granularity of the time_delta attribute. Use by the change attribute is guaranteed to change for each update to the
client's data cache validation logic of time_modify and not the file, whereas time_modify is guaranteed to change only at the
change attribute runs the risk of the client incorrectly marking granularity of the time_delta attribute. Use by the client's data
stale data as valid. cache validation logic of time_modify and not the change attribute
runs the risk of the client incorrectly marking stale data as
valid.
o Second, modified data must be flushed to the server before closing o Second, modified data must be flushed to the server before closing
a file OPENed for write. This is complementary to the first rule. a file OPENed for write. This is complementary to the first rule.
If the data is not flushed at CLOSE, the revalidation done after If the data is not flushed at CLOSE, the revalidation done after
the client OPENs a file is unable to achieve its purpose. The the client OPENs a file is unable to achieve its purpose. The
other aspect to flushing the data before close is that the data other aspect to flushing the data before close is that the data
must be committed to stable storage, at the server, before the must be committed to stable storage, at the server, before the
CLOSE operation is requested by the client. In the case of a CLOSE operation is requested by the client. In the case of a
server reboot or restart and a CLOSEd file, it may not be possible server reboot or restart and a CLOSEd file, it may not be possible
to retransmit the data to be written to the file. Hence, this to retransmit the data to be written to the file. Hence, this
skipping to change at page 165, line 25 skipping to change at page 164, line 40
allow for future minor changes or versioning. allow for future minor changes or versioning.
The base assumption with respect to minor versioning is that any The base assumption with respect to minor versioning is that any
future accepted minor version must follow the IETF process and be future accepted minor version must follow the IETF process and be
documented in a standards track RFC. Therefore, each minor version documented in a standards track RFC. Therefore, each minor version
number will correspond to an RFC. Minor version 0 of the NFS version number will correspond to an RFC. Minor version 0 of the NFS version
4 protocol is represented by this RFC. The COMPOUND and CB_COMPOUND 4 protocol is represented by this RFC. The COMPOUND and CB_COMPOUND
procedures support the encoding of the minor version being requested procedures support the encoding of the minor version being requested
by the client. by the client.
The following items represent the basic rules for the development of Future minor versions will extend, rather than replace the XDR for
minor versions. Note that a future minor version may decide to the preceding minor version, as had been done in moving from NFSv2 to
modify or add to the following rules as part of the minor version NFSv3 and from NFSv3 to NFSv4.0.
definition.
1. Procedures are not added or deleted
To maintain the general RPC model, NFSv4 minor versions will not
add to or delete procedures from the NFS program.
2. Minor versions may add operations to the COMPOUND and
CB_COMPOUND procedures.
The addition of operations to the COMPOUND and CB_COMPOUND
procedures does not affect the RPC model.
1. Minor versions may append attributes to the bitmap4 that
represents sets of attributes and to the fattr4 that
represents sets of attribute values.
This allows for the expansion of the attribute model to
allow for future growth or adaptation.
2. Minor version X must append any new attributes after the
last documented attribute.
Since attribute results are specified as an opaque array of
per-attribute XDR encoded results, the complexity of adding
new attributes in the midst of the current definitions would
be too burdensome.
3. Minor versions must not modify the structure of an existing
operation's arguments or results.
Again, the complexity of handling multiple structure definitions
for a single operation is too burdensome. New operations should
be added instead of modifying existing structures for a minor
version.
This rule does not preclude the following adaptations in a minor
version.
* adding bits to flag fields, such as new attributes to
GETATTR's bitmap4 data type, and providing corresponding
variants of opaque arrays, such as a notify4 used together
with such bitmaps
* adding bits to existing attributes like ACLs that have flag
words
* extending enumerated types (including NFS4ERR_*) with new
values
4. Minor versions must not modify the structure of existing
attributes.
5. Minor versions must not delete operations.
This prevents the potential reuse of a particular operation
"slot" in a future minor version.
6. Minor versions must not delete attributes.
7. Minor versions must not delete flag bits or enumeration values.
8. Minor versions may declare an operation MUST NOT be implemented.
Specifying that an operation MUST NOT be implemented is
equivalent to obsoleting an operation. For the client, it means
that the operation MUST NOT be sent to the server. For the
server, an NFS error can be returned as opposed to "dropping"
the request as an XDR decode error. This approach allows for
the obsolescence of an operation while maintaining its structure
so that a future minor version can reintroduce the operation.
1. Minor versions may declare that an attribute MUST NOT be
implemented.
2. Minor versions may declare that a flag bit or enumeration
value MUST NOT be implemented.
9. Minor versions may downgrade features from REQUIRED to
RECOMMENDED, or RECOMMENDED to OPTIONAL.
10. Minor versions may upgrade features from OPTIONAL to RECOMMENDED
or RECOMMENDED to REQUIRED.
11. A client and server that support minor version X SHOULD support
minor versions 0 through X-1 as well.
12. Except for infrastructural changes, no new features may be
introduced as REQUIRED in a minor version.
This rule allows for the introduction of new functionality and
forces the use of implementation experience before designating a
feature as REQUIRED. On the other hand, some classes of
features are infrastructural and have broad effects. Allowing
infrastructural features to be RECOMMENDED or OPTIONAL
complicates implementation of the minor version.
13. A client MUST NOT attempt to use a stateid, filehandle, or Specification of detailed rules for the construction of minor
similar returned object from the COMPOUND procedure with minor versions will be addressed in documents defining early minor versions
version X for another COMPOUND procedure with minor version Y, or, more desirably, in an RFC establishing a versioning framework for
where X != Y. NFSv4 as a whole.
12. Internationalization 12. Internationalization
12.1. Introduction 12.1. Introduction
Internationalization is a complex topic with its own set of Internationalization is a complex topic with its own set of
terminology (see [RFC6365]). The topic is made more complex in terminology (see [RFC6365]). The topic is made more complex in
NFSv4.0 by the tangled history and state of NFS implementations. NFSv4.0 by the tangled history and state of NFS implementations.
This section describes what we might call "NFSv4.0 This section describes what we might call "NFSv4.0
internationalization" (i.e., internationalization as implemented by internationalization" (i.e., internationalization as implemented by
existing clients and servers) as the basis upon which NFSv4.0 clients existing clients and servers) as the basis upon which NFSv4.0 clients
may implement internationalization support. may implement internationalization support.
This section is based on the behavior of existing implementations. This section is based on the behavior of existing implementations.
Note that the behaviors described are each demonstrated by a Note that the behaviors described are each demonstrated by a
combination of an NFSv4 server implementation proper and a server- combination of an NFSv4 server implementation proper and a server-
side physical filesystem. It is common for servers and physical side physical file system. It is common for servers and physical
filesystems to be configurable as to the behavior shown. In the file systems to be configurable as to the behavior shown. In the
discussion below, each configuration that shows different behavior is discussion below, each configuration that shows different behavior is
considered separately. considered separately.
Note that in this section, the keywords "MUST", "SHOULD", and "MAY", Note that in this section, the keywords "MUST", "SHOULD", and "MAY",
retain their normal meanings. However, in deriving this retain their normal meanings. However, in deriving this
specification from implementation patterns, we document below how the specification from implementation patterns, we document below how the
normative terms used derive from the behavior of existing normative terms used derive from the behavior of existing
implementations, in those situations in which existing implementation implementations, in those situations in which existing implementation
behavior patterns can be determined. behavior patterns can be determined.
skipping to change at page 168, line 31 skipping to change at page 165, line 49
described using "MUST NOT", if such behavior poses described using "MUST NOT", if such behavior poses
interoperability problems. interoperability problems.
o Behavior implemented by most existing clients or servers, where o Behavior implemented by most existing clients or servers, where
that behavior is more desirable than any alternative is described that behavior is more desirable than any alternative is described
using "SHOULD", since new implementations need to follow that using "SHOULD", since new implementations need to follow that
existing practice unless there are strong reasons to do otherwise. existing practice unless there are strong reasons to do otherwise.
The converse holds for "SHOULD NOT". The converse holds for "SHOULD NOT".
o Behavior implemented by some not all existing clients or servers, o Behavior implemented by some, but not all existing clients or
is described using "MAY", indicating that new implementations have servers, is described using "MAY", indicating that new
a choice as to whether they will behave in that way. Thus, new implementations have a choice as to whether they will behave in
implementations will have the same flexibility that existing ones that way. Thus, new implementations will have the same
do. flexibility that existing ones do.
o Behavior implemented by all existing clients or servers, so far as o Behavior implemented by all existing clients or servers, so far as
is known, but where there remains some uncertainty as to details is known, but where there remains some uncertainty as to details
is described using "should". Such cases primarily concern details is described using "should". Such cases primarily concern details
of error returns. New implementations should follow existing of error returns. New implementations should follow existing
practice even though such situations generally do not affect practice even though such situations generally do not affect
interoperability. interoperability.
There are also cases in which certain server behaviors, while not There are also cases in which certain server behaviors, while not
known to exist, cannot be reliably determined not to exist. In part, known to exist, cannot be reliably determined not to exist. In part,
skipping to change at page 172, line 24 skipping to change at page 169, line 41
Server implementations MAY normalize file names to conform to a Server implementations MAY normalize file names to conform to a
particular normalization form before using the resulting string when particular normalization form before using the resulting string when
looking up or creating a file. Servers MAY also perform looking up or creating a file. Servers MAY also perform
normalization-insensitive string comparisons without modifying name normalization-insensitive string comparisons without modifying name
to match a particular normalization form. Except in cases in which to match a particular normalization form. Except in cases in which
component names are excluded from normalization-related handling component names are excluded from normalization-related handling
because they are not valid UTF-8 strings, a server MUST make the same because they are not valid UTF-8 strings, a server MUST make the same
choice (as to whether to normalize or not, the target form of choice (as to whether to normalize or not, the target form of
normalization and whether to do normalization-insensitive string normalization and whether to do normalization-insensitive string
comparisons) in the same way for all accesses to a particular comparisons) in the same way for all accesses to a particular file
filesystem. Servers SHOULD NOT reject a file name because it does system. Servers SHOULD NOT reject a file name because it does not
not conform to a particular normalization form as this may deny conform to a particular normalization form as this may deny access to
access to clients that use a different normalization form. clients that use a different normalization form.
12.6. Types with Processing Defined by Other Internet Areas 12.6. Types with Processing Defined by Other Internet Areas
There are two types of strings that NFSv4 deals with that are based There are two types of strings that NFSv4 deals with that are based
on domain names. Processing of such strings is defined by other on domain names. Processing of such strings is defined by other
Internet standards, and hence the processing behavior for such Internet standards, and hence the processing behavior for such
strings should be consistent across all server operating systems and strings should be consistent across all server operating systems and
server file systems. server file systems.
These are as follows: These are as follows:
skipping to change at page 173, line 5 skipping to change at page 170, line 22
o Principal suffixes which are used to denote sets of users and o Principal suffixes which are used to denote sets of users and
groups, and are in the form of domain names. groups, and are in the form of domain names.
The general rules for handling all of these domain-related strings The general rules for handling all of these domain-related strings
are similar and independent of the role of the sender or receiver as are similar and independent of the role of the sender or receiver as
client or server although the consequences of failure to obey these client or server although the consequences of failure to obey these
rules may be different for client or server. The server can report rules may be different for client or server. The server can report
errors when it is sent invalid strings, whereas the client will errors when it is sent invalid strings, whereas the client will
simply ignore invalid string or use a default value in their place. simply ignore invalid string or use a default value in their place.
The string sent SHOULD be in the form of a U-label although it MAY be The string sent SHOULD be in the form of a U-label. If that is
in the form of one or more A-labels or a UTF-8 domain name that is impractical, it can instead be in the form of one or more A-labels or
not a properly formatted U-label. The receiver needs to be able to a UTF-8 domain name that is not a properly formatted U-label. The
accept domain and server names in any of the formats allowed. The receiver needs to be able to accept domain and server names in any of
server MUST reject, using the error NFS4ERR_INVAL, a string which is the formats allowed. The server MUST reject, using the error
not valid UTF-8 or which begins with "xn--" and violates the rules NFS4ERR_INVAL, a string which is not valid UTF-8 or which begins with
for a valid A-label. "xn--" and violates the rules for a valid A-label.
When a domain string is part of id@domain or group@domain, there are When a domain string is part of id@domain or group@domain, there are
two possible approaches: two possible approaches:
1. The server treats the domain string as a U-label (see [RFC5890] 1. The server treats the domain string as a U-label (see [RFC5890]
This happens if the domain string is an A-label (or is a UTF-8- This happens if the domain string is an A-label (or is a UTF-8-
encoded string which is not a U-label) and the server converts encoded string which is not a U-label) and the server converts
the domain string to the corresponding U-label, using the the domain string to the corresponding U-label, using the
functions ToUnicode(domain) or ToUnicode(ToASCII(domain)). As a functions ToUnicode(domain) or ToUnicode(ToASCII(domain)). As a
result, the domain string returned within a userid on a GETATTR result, the domain string returned within a userid on a GETATTR
skipping to change at page 173, line 33 skipping to change at page 170, line 50
although when this happens, the domain will be in the form of an although when this happens, the domain will be in the form of an
U-label. U-label.
2. The server does not attempt to treat the domain string as a 2. The server does not attempt to treat the domain string as a
U-label; specifically, it does not map a domain string which is U-label; specifically, it does not map a domain string which is
not a U-label into a U-label using the ToUnicode function as not a U-label into a U-label using the ToUnicode function as
described above. As a result, the domain string returned on a described above. As a result, the domain string returned on a
GETATTR of the userid MUST be the same as that used when setting GETATTR of the userid MUST be the same as that used when setting
the userid by the SETATTR. the userid by the SETATTR.
A server SHOULD use the first method, but MAY use the second method. A server SHOULD use the first method.
For VERIFY and NVERIFY, additional string processing requirements For VERIFY and NVERIFY, additional string processing requirements
apply to verification of the owner and owner_group attributes, see apply to verification of the owner and owner_group attributes, see
Section 5.9. Section 5.9.
12.7. UTF-8 Related Errors 12.7. UTF-8 Related Errors
Where the client sends an invalid UTF-8 string, the server MAY return Where the client sends an invalid UTF-8 string, the server MAY return
an NFS4ERR_INVAL error. This includes cases in which inappropriate an NFS4ERR_INVAL error. This includes cases in which inappropriate
prefixes are detected and where the count includes trailing bytes prefixes are detected and where the count includes trailing bytes
skipping to change at page 174, line 18 skipping to change at page 171, line 37
while supporting all of the characters within the name, does not while supporting all of the characters within the name, does not
allow that particular name to be used, the error should return the allow that particular name to be used, the error should return the
error NFS4ERR_BADNAME. This includes such situations as file system error NFS4ERR_BADNAME. This includes such situations as file system
prohibitions of "." and ".." as file names for certain operations, prohibitions of "." and ".." as file names for certain operations,
and similar constraints and similar constraints
12.8. Servers that accept file component names that are not valid UTF-8 12.8. Servers that accept file component names that are not valid UTF-8
strings strings
As stated previously, servers MAY accept, on all or on some subset of As stated previously, servers MAY accept, on all or on some subset of
the physical filesystems exported, component names that are not valid the physical file systems exported, component names that are not
UTF-8 strings. A typical pattern is for a server to use valid UTF-8 strings. A typical pattern is for a server to use
UTF-8-unaware physical filesystems that treat component names as UTF-8-unaware physical file systems that treat component names as
uninterpreted strings of bytes, rather than having any awareness of uninterpreted strings of bytes, rather than having any awareness of
the character set being used. the character set being used.
Such servers SHOULD NOT change the stored representation of component Such servers SHOULD NOT change the stored representation of component
names from those received on the wire, and SHOULD use an octet-by- names from those received on the wire, and SHOULD use an octet-by-
octet comparison of component name strings to determine equivalence octet comparison of component name strings to determine equivalence
(as opposed to any broader notion of string comparison). This is (as opposed to any broader notion of string comparison). This is
because the server has no knowledge of the character encoding being because the server has no knowledge of the character encoding being
used. used.
skipping to change at page 203, line 46 skipping to change at page 201, line 20
14.4. Operation Values 14.4. Operation Values
The operations encoded in the COMPOUND procedure are identified by The operations encoded in the COMPOUND procedure are identified by
operation values. To avoid overlap with the RPC procedure numbers, operation values. To avoid overlap with the RPC procedure numbers,
operations 0 (zero) and 1 are not defined. Operation 2 is not operations 0 (zero) and 1 are not defined. Operation 2 is not
defined but reserved for future use with minor versioning. defined but reserved for future use with minor versioning.
15. NFSv4 Procedures 15. NFSv4 Procedures
[RFC Editor: prior to publishing this document as an RFC, please have
every Section that has a title of "Procedure X:" or "Operation Y:"
start at the top of a new page.]
15.1. Procedure 0: NULL - No Operation 15.1. Procedure 0: NULL - No Operation
15.1.1. SYNOPSIS 15.1.1. SYNOPSIS
<null> <null>
15.1.2. ARGUMENT 15.1.2. ARGUMENT
void; void;
15.1.3. RESULT 15.1.3. RESULT
skipping to change at page 215, line 42 skipping to change at page 212, line 45
union CREATE4res switch (nfsstat4 status) { union CREATE4res switch (nfsstat4 status) {
case NFS4_OK: case NFS4_OK:
CREATE4resok resok4; CREATE4resok resok4;
default: default:
void; void;
}; };
15.6.4. DESCRIPTION 15.6.4. DESCRIPTION
The CREATE operation creates a non-regular file object in a directory The CREATE operation creates a non-regular file object in a directory
with a given name. The OPEN operation MUST be used to create a with a given name. The OPEN operation is used to create a regular
regular file. file.
The objname specifies the name for the new object. The objtype The objname specifies the name for the new object. The objtype
determines the type of object to be created: directory, symlink, etc. determines the type of object to be created: directory, symlink, etc.
If an object of the same name already exists in the directory, the If an object of the same name already exists in the directory, the
server will return the error NFS4ERR_EXIST. server will return the error NFS4ERR_EXIST.
For the directory where the new file object was created, the server For the directory where the new file object was created, the server
returns change_info4 information in cinfo. With the atomic field of returns change_info4 information in cinfo. With the atomic field of
the change_info4 struct, the server will indicate if the before and the change_info4 struct, the server will indicate if the before and
skipping to change at page 286, line 13 skipping to change at page 283, line 13
the ILLEGAL4res would not be returned. the ILLEGAL4res would not be returned.
16. NFSv4 Callback Procedures 16. NFSv4 Callback Procedures
The procedures used for callbacks are defined in the following The procedures used for callbacks are defined in the following
sections. In the interest of clarity, the terms "client" and sections. In the interest of clarity, the terms "client" and
"server" refer to NFS clients and servers, despite the fact that for "server" refer to NFS clients and servers, despite the fact that for
an individual callback RPC, the sense of these terms would be an individual callback RPC, the sense of these terms would be
precisely the opposite. precisely the opposite.
[RFC Editor: prior to publishing this document as an RFC, please have
every Section that has a title of "Procedure X:" or "Operation Y:"
start at the top of a new page.]
16.1. Procedure 0: CB_NULL - No Operation 16.1. Procedure 0: CB_NULL - No Operation
16.1.1. SYNOPSIS 16.1.1. SYNOPSIS
<null> <null>
16.1.2. ARGUMENT 16.1.2. ARGUMENT
void; void;
skipping to change at page 293, line 12 skipping to change at page 290, line 12
responsible for the release of client state, it is imperative that responsible for the release of client state, it is imperative that
the principal used for these operations is checked against and match the principal used for these operations is checked against and match
the previous use of these operations. See Section 9.1.1 for further the previous use of these operations. See Section 9.1.1 for further
discussion. discussion.
Unicode in the form of UTF-8 is used for file component names (i.e., Unicode in the form of UTF-8 is used for file component names (i.e.,
both directory and file components), as well as the owner and both directory and file components), as well as the owner and
owner_group attributes; other character sets may also be allowed for owner_group attributes; other character sets may also be allowed for
file component names. String processing (e.g., Unicode file component names. String processing (e.g., Unicode
normalization) raises security concerns for string comparison - see normalization) raises security concerns for string comparison - see
5.9 and 12 for further discussion and see [RFC6943] for related Sections 5.9 and 12 for further discussion and see [RFC6943] for
identifier comparison security considerations. File component names related identifier comparison security considerations. File
are identifiers with respect to the identifier comparison discussion component names are identifiers with respect to the identifier
in [RFC6943] because they are used to identify the objects to which comparison discussion in [RFC6943] because they are used to identify
ACLs are applied, see Section 6. the objects to which ACLs are applied, see Section 6.
18. IANA Considerations 18. IANA Considerations
This section uses terms that are defined in [RFC5226]. This section uses terms that are defined in [RFC5226].
18.1. Named Attribute Definitions 18.1. Named Attribute Definitions
IANA has created a registry called the "NFSv4 Named Attribute IANA has created a registry called the "NFSv4 Named Attribute
Definitions Registry" for [RFC3530] and [RFC5661]. This section Definitions Registry" for [RFC3530] and [RFC5661]. This section
introduces no new changes, but it does recap the intent. introduces no new changes, but it does recap the intent.
skipping to change at page 293, line 43 skipping to change at page 290, line 43
exist. While application developers are allowed to define and use exist. While application developers are allowed to define and use
attributes as needed, they are encouraged to register the attributes attributes as needed, they are encouraged to register the attributes
with IANA. with IANA.
Such registered named attributes are presumed to apply to all minor Such registered named attributes are presumed to apply to all minor
versions of NFSv4, including those defined subsequently to the versions of NFSv4, including those defined subsequently to the
registration. Where the named attribute is intended to be limited registration. Where the named attribute is intended to be limited
with regard to the minor versions for which they are not be used, the with regard to the minor versions for which they are not be used, the
assignment in registry will clearly state the applicable limits. assignment in registry will clearly state the applicable limits.
All assignments to the registry are made on a First Come First Served The registry is to be maintained using the Specification Required
basis, per section 4.1 of [RFC5226]. The policy for each assignment policy as defined in Section 4.1 of [RFC5226].
is Specification Required, per section 4.1 of [RFC5226].
Under the NFSv4 specification, the name of a named attribute can in 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 theory be up to 2^32 - 1 bytes in length, but in practice NFSv4
clients and servers will be unable to handle a string that long. clients and servers will be unable to handle a string that long.
IANA should reject any assignment request with a named attribute that IANA should reject any assignment request with a named attribute that
exceeds 128 UTF-8 characters. To give IESG the flexibility to set up exceeds 128 UTF-8 characters. To give IESG the flexibility to set up
bases of assignment of Experimental Use and Standards Action, the bases of assignment of Experimental Use and Standards Action, the
prefixes of "EXPE" and "STDS" are Reserved. The zero length named prefixes of "EXPE" and "STDS" are Reserved. The zero length named
attribute name is Reserved. attribute name is Reserved.
skipping to change at page 296, line 21 skipping to change at page 293, line 21
19.2. Informative References 19.2. Informative References
[Chet] Juszczak, C., "Improving the Performance and Correctness [Chet] Juszczak, C., "Improving the Performance and Correctness
of an NFS Server", USENIX Conference Proceedings , June of an NFS Server", USENIX Conference Proceedings , June
1990. 1990.
[Floyd] Floyd, S. and V. Jacobson, "The Synchronization of [Floyd] Floyd, S. and V. Jacobson, "The Synchronization of
Periodic Routing Messages", IEEE/ACM Transactions on Periodic Routing Messages", IEEE/ACM Transactions on
Networking 2(2), pp. 122-136, April 1994. Networking 2(2), pp. 122-136, April 1994.
[ISEG_errata] [IESG_errata]
IESG, "IESG Processing of RFC Errata for the IETF Stream", IESG, "IESG Processing of RFC Errata for the IETF Stream",
July 2008. July 2008.
[P1003.1e] [P1003.1e]
Institute of Electrical and Electronics Engineers, Inc., Institute of Electrical and Electronics Engineers, Inc.,
"IEEE Draft P1003.1e", 1997. "IEEE Draft P1003.1e", 1997.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC
793, September 1981. 793, September 1981.
skipping to change at page 300, line 12 skipping to change at page 297, line 12
[RFC Editor: please remove this section prior to publishing this [RFC Editor: please remove this section prior to publishing this
document as an RFC] document as an RFC]
[RFC Editor: prior to publishing this document as an RFC, please [RFC Editor: prior to publishing this document as an RFC, please
replace all occurrences of RFCNFSv4XDR with RFCxxxx where xxxx is the replace all occurrences of RFCNFSv4XDR with RFCxxxx where xxxx is the
RFC number assigned to the XDR document.] RFC number assigned to the XDR document.]
[RFC Editor: Please note that there is also a reference entry that [RFC Editor: Please note that there is also a reference entry that
needs to be modified for the companion document.] needs to be modified for the companion document.]
[RFC Editor: prior to publishing this document as an RFC, please have
every top level subsection of both Section 15 and Section 16 that has
a title of "Procedure X:" or "Operation Y:" start at the top of a new
page.]
Authors' Addresses Authors' Addresses
Thomas Haynes (editor) Thomas Haynes (editor)
Primary Data, Inc. Primary Data, Inc.
4300 El Camino Real Ste 100 4300 El Camino Real Ste 100
Los Altos, CA 94022 Los Altos, CA 94022
USA USA
Phone: +1 408 215 1519 Phone: +1 408 215 1519
Email: thomas.haynes@primarydata.com Email: thomas.haynes@primarydata.com
David Noveck (editor) David Noveck (editor)
26 Locust Ave Dell
Lexington, MA 02421 300 Innovative Way
Nashua, NH 03062
US US
Phone: +1 781 572 8038 Phone: +1 781 572 8038
Email: davenoveck@gmail.com Email: dave_noveck@dell.com
 End of changes. 103 change blocks. 
435 lines changed or deleted 375 lines changed or added

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