draft-ietf-nfsv4-minorversion2-31.txt   draft-ietf-nfsv4-minorversion2-32.txt 
NFSv4 T. Haynes NFSv4 T. Haynes
Internet-Draft Primary Data Internet-Draft Primary Data
Intended status: Standards Track March 03, 2015 Intended status: Standards Track March 04, 2015
Expires: September 4, 2015 Expires: September 5, 2015
NFS Version 4 Minor Version 2 NFS Version 4 Minor Version 2
draft-ietf-nfsv4-minorversion2-31.txt draft-ietf-nfsv4-minorversion2-32.txt
Abstract Abstract
This Internet-Draft describes NFS version 4 minor version two, This Internet-Draft describes NFS version 4 minor version two,
describing the protocol extensions made from NFS version 4 minor describing the protocol extensions made from NFS version 4 minor
version 1. Major extensions introduced in NFS version 4 minor version 1. Major extensions introduced in NFS version 4 minor
version two include: Server Side Copy, Application I/O Advise, Space version two include: Server Side Copy, Application I/O Advise, Space
Reservations, Sparse Files, Application Data Blocks, and Labeled NFS. Reservations, Sparse Files, Application Data Blocks, and Labeled NFS.
Requirements Language Requirements Language
skipping to change at page 1, line 40 skipping to change at page 1, line 40
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at 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 September 4, 2015. This Internet-Draft will expire on September 5, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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 50 skipping to change at page 2, line 50
4.4.2. Client Caches . . . . . . . . . . . . . . . . . . . . 12 4.4.2. Client Caches . . . . . . . . . . . . . . . . . . . . 12
4.5. Intra-Server Copy . . . . . . . . . . . . . . . . . . . . 12 4.5. Intra-Server Copy . . . . . . . . . . . . . . . . . . . . 12
4.6. Inter-Server Copy . . . . . . . . . . . . . . . . . . . . 13 4.6. Inter-Server Copy . . . . . . . . . . . . . . . . . . . . 13
4.7. Server-to-Server Copy Protocol . . . . . . . . . . . . . 17 4.7. Server-to-Server Copy Protocol . . . . . . . . . . . . . 17
4.7.1. Considerations on Selecting a Copy Protocol . . . . . 17 4.7.1. Considerations on Selecting a Copy Protocol . . . . . 17
4.7.2. Using NFSv4.x as the Copy Protocol . . . . . . . . . 17 4.7.2. Using NFSv4.x as the Copy Protocol . . . . . . . . . 17
4.7.3. Using an Alternative Copy Protocol . . . . . . . . . 17 4.7.3. Using an Alternative Copy Protocol . . . . . . . . . 17
4.8. netloc4 - Network Locations . . . . . . . . . . . . . . . 18 4.8. netloc4 - Network Locations . . . . . . . . . . . . . . . 18
4.9. Copy Offload Stateids . . . . . . . . . . . . . . . . . . 19 4.9. Copy Offload Stateids . . . . . . . . . . . . . . . . . . 19
4.10. Security Considerations . . . . . . . . . . . . . . . . . 19 4.10. Security Considerations . . . . . . . . . . . . . . . . . 19
4.10.1. Inter-Server Copy Security . . . . . . . . . . . . . 19 4.10.1. Inter-Server Copy Security . . . . . . . . . . . . . 20
5. Support for Application IO Hints . . . . . . . . . . . . . . 27 5. Support for Application IO Hints . . . . . . . . . . . . . . 28
6. Sparse Files . . . . . . . . . . . . . . . . . . . . . . . . 28 6. Sparse Files . . . . . . . . . . . . . . . . . . . . . . . . 28
6.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 28 6.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 28
6.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 29 6.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 29
6.3. New Operations . . . . . . . . . . . . . . . . . . . . . 29 6.3. New Operations . . . . . . . . . . . . . . . . . . . . . 29
6.3.1. READ_PLUS . . . . . . . . . . . . . . . . . . . . . . 29 6.3.1. READ_PLUS . . . . . . . . . . . . . . . . . . . . . . 29
6.3.2. DEALLOCATE . . . . . . . . . . . . . . . . . . . . . 30 6.3.2. DEALLOCATE . . . . . . . . . . . . . . . . . . . . . 30
7. Space Reservation . . . . . . . . . . . . . . . . . . . . . . 30 7. Space Reservation . . . . . . . . . . . . . . . . . . . . . . 30
8. Application Data Block Support . . . . . . . . . . . . . . . 32 8. Application Data Block Support . . . . . . . . . . . . . . . 32
8.1. Generic Framework . . . . . . . . . . . . . . . . . . . . 33 8.1. Generic Framework . . . . . . . . . . . . . . . . . . . . 33
8.1.1. Data Block Representation . . . . . . . . . . . . . . 33 8.1.1. Data Block Representation . . . . . . . . . . . . . . 33
8.2. An Example of Detecting Corruption . . . . . . . . . . . 34 8.2. An Example of Detecting Corruption . . . . . . . . . . . 34
8.3. Example of READ_PLUS . . . . . . . . . . . . . . . . . . 35 8.3. Example of READ_PLUS . . . . . . . . . . . . . . . . . . 35
8.4. An Example of Zeroing Space . . . . . . . . . . . . . . . 36 8.4. An Example of Zeroing Space . . . . . . . . . . . . . . . 36
9. Labeled NFS . . . . . . . . . . . . . . . . . . . . . . . . . 36 9. Labeled NFS . . . . . . . . . . . . . . . . . . . . . . . . . 36
9.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 36 9.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 36
9.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 37 9.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 37
9.3. MAC Security Attribute . . . . . . . . . . . . . . . . . 38 9.3. MAC Security Attribute . . . . . . . . . . . . . . . . . 38
9.3.1. Delegations . . . . . . . . . . . . . . . . . . . . . 38 9.3.1. Delegations . . . . . . . . . . . . . . . . . . . . . 39
9.3.2. Permission Checking . . . . . . . . . . . . . . . . . 39 9.3.2. Permission Checking . . . . . . . . . . . . . . . . . 39
9.3.3. Object Creation . . . . . . . . . . . . . . . . . . . 39 9.3.3. Object Creation . . . . . . . . . . . . . . . . . . . 39
9.3.4. Existing Objects . . . . . . . . . . . . . . . . . . 39 9.3.4. Existing Objects . . . . . . . . . . . . . . . . . . 39
9.3.5. Label Changes . . . . . . . . . . . . . . . . . . . . 39 9.3.5. Label Changes . . . . . . . . . . . . . . . . . . . . 40
9.4. pNFS Considerations . . . . . . . . . . . . . . . . . . . 40 9.4. pNFS Considerations . . . . . . . . . . . . . . . . . . . 40
9.5. Discovery of Server Labeled NFS Support . . . . . . . . . 40 9.5. Discovery of Server Labeled NFS Support . . . . . . . . . 40
9.6. MAC Security NFS Modes of Operation . . . . . . . . . . . 40 9.6. MAC Security NFS Modes of Operation . . . . . . . . . . . 41
9.6.1. Full Mode . . . . . . . . . . . . . . . . . . . . . . 41 9.6.1. Full Mode . . . . . . . . . . . . . . . . . . . . . . 41
9.6.2. Guest Mode . . . . . . . . . . . . . . . . . . . . . 42 9.6.2. Guest Mode . . . . . . . . . . . . . . . . . . . . . 42
9.7. Security Considerations for Labeled NFS . . . . . . . . . 42 9.7. Security Considerations for Labeled NFS . . . . . . . . . 43
10. Sharing change attribute implementation details with NFSv4 10. Sharing change attribute implementation details with NFSv4
clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
11. Error Values . . . . . . . . . . . . . . . . . . . . . . . . 43 11. Error Values . . . . . . . . . . . . . . . . . . . . . . . . 44
11.1. Error Definitions . . . . . . . . . . . . . . . . . . . 44 11.1. Error Definitions . . . . . . . . . . . . . . . . . . . 44
11.1.1. General Errors . . . . . . . . . . . . . . . . . . . 44 11.1.1. General Errors . . . . . . . . . . . . . . . . . . . 44
11.1.2. Server to Server Copy Errors . . . . . . . . . . . . 44 11.1.2. Server to Server Copy Errors . . . . . . . . . . . . 44
11.1.3. Labeled NFS Errors . . . . . . . . . . . . . . . . . 45 11.1.3. Labeled NFS Errors . . . . . . . . . . . . . . . . . 45
11.2. New Operations and Their Valid Errors . . . . . . . . . 45 11.2. New Operations and Their Valid Errors . . . . . . . . . 45
11.3. New Callback Operations and Their Valid Errors . . . . . 49 11.3. New Callback Operations and Their Valid Errors . . . . . 49
12. New File Attributes . . . . . . . . . . . . . . . . . . . . . 49 12. New File Attributes . . . . . . . . . . . . . . . . . . . . . 50
12.1. New RECOMMENDED Attributes - List and Definition 12.1. New RECOMMENDED Attributes - List and Definition
References . . . . . . . . . . . . . . . . . . . . . . . 49 References . . . . . . . . . . . . . . . . . . . . . . . 50
12.2. Attribute Definitions . . . . . . . . . . . . . . . . . 50 12.2. Attribute Definitions . . . . . . . . . . . . . . . . . 50
13. Operations: REQUIRED, RECOMMENDED, or OPTIONAL . . . . . . . 53 13. Operations: REQUIRED, RECOMMENDED, or OPTIONAL . . . . . . . 53
14. Modifications to NFSv4.1 Operations . . . . . . . . . . . . . 56 14. Modifications to NFSv4.1 Operations . . . . . . . . . . . . . 56
14.1. Operation 42: EXCHANGE_ID - Instantiate Client ID . . . 56 14.1. Operation 42: EXCHANGE_ID - Instantiate Client ID . . . 56
14.2. Operation 48: GETDEVICELIST - Get All Device Mappings 14.2. Operation 48: GETDEVICELIST - Get All Device Mappings
for a File System . . . . . . . . . . . . . . . . . . . 57 for a File System . . . . . . . . . . . . . . . . . . . 58
15. NFSv4.2 Operations . . . . . . . . . . . . . . . . . . . . . 59 15. NFSv4.2 Operations . . . . . . . . . . . . . . . . . . . . . 59
15.1. Operation 59: ALLOCATE - Reserve Space in A Region of a 15.1. Operation 59: ALLOCATE - Reserve Space in A Region of a
File . . . . . . . . . . . . . . . . . . . . . . . . . . 59 File . . . . . . . . . . . . . . . . . . . . . . . . . . 59
15.2. Operation 60: COPY - Initiate a server-side copy . . . . 60 15.2. Operation 60: COPY - Initiate a server-side copy . . . . 60
15.3. Operation 61: COPY_NOTIFY - Notify a source server of a 15.3. Operation 61: COPY_NOTIFY - Notify a source server of a
future copy . . . . . . . . . . . . . . . . . . . . . . 65 future copy . . . . . . . . . . . . . . . . . . . . . . 65
15.4. Operation 62: DEALLOCATE - Unreserve Space in a Region 15.4. Operation 62: DEALLOCATE - Unreserve Space in a Region
of a File . . . . . . . . . . . . . . . . . . . . . . . 66 of a File . . . . . . . . . . . . . . . . . . . . . . . 67
15.5. Operation 63: IO_ADVISE - Application I/O access pattern 15.5. Operation 63: IO_ADVISE - Application I/O access pattern
hints . . . . . . . . . . . . . . . . . . . . . . . . . 67 hints . . . . . . . . . . . . . . . . . . . . . . . . . 68
15.6. Operation 64: LAYOUTERROR - Provide Errors for the 15.6. Operation 64: LAYOUTERROR - Provide Errors for the
Layout . . . . . . . . . . . . . . . . . . . . . . . . . 73 Layout . . . . . . . . . . . . . . . . . . . . . . . . . 74
15.7. Operation 65: LAYOUTSTATS - Provide Statistics for the 15.7. Operation 65: LAYOUTSTATS - Provide Statistics for the
Layout . . . . . . . . . . . . . . . . . . . . . . . . . 76 Layout . . . . . . . . . . . . . . . . . . . . . . . . . 77
15.8. Operation 66: OFFLOAD_CANCEL - Stop an Offloaded 15.8. Operation 66: OFFLOAD_CANCEL - Stop an Offloaded
Operation . . . . . . . . . . . . . . . . . . . . . . . 78 Operation . . . . . . . . . . . . . . . . . . . . . . . 78
15.9. Operation 67: OFFLOAD_STATUS - Poll for Status of 15.9. Operation 67: OFFLOAD_STATUS - Poll for Status of
Asynchronous Operation . . . . . . . . . . . . . . . . . 79 Asynchronous Operation . . . . . . . . . . . . . . . . . 79
15.10. Operation 68: READ_PLUS - READ Data or Holes from a File 80 15.10. Operation 68: READ_PLUS - READ Data or Holes from a File 80
15.11. Operation 69: SEEK - Find the Next Data or Hole . . . . 85 15.11. Operation 69: SEEK - Find the Next Data or Hole . . . . 85
15.12. Operation 70: WRITE_SAME - WRITE an ADB Multiple Times 15.12. Operation 70: WRITE_SAME - WRITE an ADB Multiple Times
to a File . . . . . . . . . . . . . . . . . . . . . . . 86 to a File . . . . . . . . . . . . . . . . . . . . . . . 86
16. NFSv4.2 Callback Operations . . . . . . . . . . . . . . . . . 90 16. NFSv4.2 Callback Operations . . . . . . . . . . . . . . . . . 90
16.1. Operation 15: CB_OFFLOAD - Report results of an 16.1. Operation 15: CB_OFFLOAD - Report results of an
asynchronous operation . . . . . . . . . . . . . . . . . 90 asynchronous operation . . . . . . . . . . . . . . . . . 90
17. Security Considerations . . . . . . . . . . . . . . . . . . . 91 17. Security Considerations . . . . . . . . . . . . . . . . . . . 91
18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 91 18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 92
19. References . . . . . . . . . . . . . . . . . . . . . . . . . 91 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 92
19.1. Normative References . . . . . . . . . . . . . . . . . . 91 19.1. Normative References . . . . . . . . . . . . . . . . . . 92
19.2. Informative References . . . . . . . . . . . . . . . . . 92 19.2. Informative References . . . . . . . . . . . . . . . . . 92
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 94 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 94
Appendix B. RFC Editor Notes . . . . . . . . . . . . . . . . . . 95 Appendix B. RFC Editor Notes . . . . . . . . . . . . . . . . . . 95
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 95 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 95
1. Introduction 1. Introduction
1.1. The NFS Version 4 Minor Version 2 Protocol 1.1. The NFS Version 4 Minor Version 2 Protocol
The NFS version 4 minor version 2 (NFSv4.2) protocol is the third The NFS version 4 minor version 2 (NFSv4.2) protocol is the third
skipping to change at page 17, line 30 skipping to change at page 17, line 30
may prefer the traditional copy mechanism such that it can meet those may prefer the traditional copy mechanism such that it can meet those
requirements. requirements.
4.7.2. Using NFSv4.x as the Copy Protocol 4.7.2. Using NFSv4.x as the Copy Protocol
The destination server MAY use standard NFSv4.x (where x >= 1) The destination server MAY use standard NFSv4.x (where x >= 1)
operations to read the data from the source server. If NFSv4.x is operations to read the data from the source server. If NFSv4.x is
used for the server-to-server copy protocol, the destination server used for the server-to-server copy protocol, the destination server
can use the source filehandle and ca_src_stateid provided in the COPY can use the source filehandle and ca_src_stateid provided in the COPY
request with standard NFSv4.x operations to read data from the source request with standard NFSv4.x operations to read data from the source
server. server. Note that the ca_src_stateid MUST be the cnr_stateid
returned from the source via the COPY_NOTIFY.
4.7.3. Using an Alternative Copy Protocol 4.7.3. Using an Alternative Copy Protocol
In a homogeneous environment, the source and destination servers In a homogeneous environment, the source and destination servers
might be able to perform the file copy extremely efficiently using might be able to perform the file copy extremely efficiently using
specialized protocols. For example the source and destination specialized protocols. For example the source and destination
servers might be two nodes sharing a common file system format for servers might be two nodes sharing a common file system format for
the source and destination file systems. Thus the source and the source and destination file systems. Thus the source and
destination are in an ideal position to efficiently render the image destination are in an ideal position to efficiently render the image
of the source file to the destination file by replicating the file of the source file to the destination file by replicating the file
skipping to change at page 27, line 35 skipping to change at page 27, line 35
Provided that the random number is unpredictable and has been kept Provided that the random number is unpredictable and has been kept
secret by the parties involved, the source server will therefore know secret by the parties involved, the source server will therefore know
that these NFSv4.x operations are being issued by the destination that these NFSv4.x operations are being issued by the destination
server identified in the COPY_NOTIFY. This random number technique server identified in the COPY_NOTIFY. This random number technique
only provides initial authentication of the destination server, and only provides initial authentication of the destination server, and
cannot defend against man-in-the-middle attacks after authentication cannot defend against man-in-the-middle attacks after authentication
or an eavesdropper that observes the random number on the wire. or an eavesdropper that observes the random number on the wire.
Other secure communication techniques (e.g., IPsec) are necessary to Other secure communication techniques (e.g., IPsec) are necessary to
block these attacks. block these attacks.
Note that the cnr_stateid returned from the COPY_NOTIFY can be used
to uiniquely identify the destination server to the source server.
Part of this stateid could be randomly generated in the same manner
and the destination server could avoid using the above URL and
instead open the file directly via NFSv4.x (where x >= 1) using a
CLAIM_FH on the OPEN (see Section 18.16.3 of [RFC5661]).
Servers SHOULD reject COPY_NOTIFY requests that do not use RPCSEC_GSS Servers SHOULD reject COPY_NOTIFY requests that do not use RPCSEC_GSS
with privacy, thus ensuring the URL in the COPY_NOTIFY reply is with privacy, thus ensuring the URL in the COPY_NOTIFY reply is
encrypted. For the same reason, clients SHOULD send COPY requests to encrypted. For the same reason, clients SHOULD send COPY requests to
the destination using RPCSEC_GSS with privacy. the destination using RPCSEC_GSS with privacy.
4.10.1.3. Inter-Server Copy without ONC RPC 4.10.1.3. Inter-Server Copy without ONC RPC
The same techniques as Section 4.10.1.2, using unique URLs for each The same techniques as Section 4.10.1.2, using unique URLs for each
destination server, can be used for other protocols (e.g., HTTP destination server, can be used for other protocols (e.g., HTTP
[RFC2616] and FTP [RFC959]) as well. [RFC2616] and FTP [RFC959]) as well.
skipping to change at page 61, line 45 skipping to change at page 62, line 12
If either PUTFH or SAVEFH checked the validity of the filehandle, the If either PUTFH or SAVEFH checked the validity of the filehandle, the
operation would likely fail and return NFS4ERR_STALE. operation would likely fail and return NFS4ERR_STALE.
If a server supports the inter-server-to-server COPY feature, a PUTFH If a server supports the inter-server-to-server COPY feature, a PUTFH
followed by a SAVEFH MUST NOT return NFS4ERR_STALE for either followed by a SAVEFH MUST NOT return NFS4ERR_STALE for either
operation. These restrictions do not pose substantial difficulties operation. These restrictions do not pose substantial difficulties
for servers. The CURRENT_FH and SAVED_FH may be validated in the for servers. The CURRENT_FH and SAVED_FH may be validated in the
context of the operation referencing them and an NFS4ERR_STALE error context of the operation referencing them and an NFS4ERR_STALE error
returned for an invalid file handle at that point. returned for an invalid file handle at that point.
For an intra-server copy, both the ca_src_stateid and ca_dst_stateid For an inter-server copy, the ca_dst_stateid MUST refer to either
MUST refer to either open or locking states provided earlier by the delegation, locking, or open states provided earlier by the server
server. If either stateid is invalid, then the operation MUST fail. (see Section 4.4.1). The order of selection is explained in
If the request is for a inter-server copy, then the ca_src_stateid Section 8.2.5 of [RFC5661]. And the ca_src_stateid MUST be the
can be ignored. If ca_dst_stateid is invalid, then the operation cnr_stateid returned from the earlier COPY_NOTIFY. If either stateid
MUST fail. is invalid, then the operation MUST fail. If the request is for an
intra-server copy, then the ca_src_stateid can be ignored. If
ca_dst_stateid is invalid, then the operation MUST fail.
The CURRENT_FH specifies the destination of the copy operation. The The CURRENT_FH specifies the destination of the copy operation. The
CURRENT_FH MUST be a regular file and not a directory. Note, the CURRENT_FH MUST be a regular file and not a directory. Note, the
file MUST exist before the COPY operation begins. It is the file MUST exist before the COPY operation begins. It is the
responsibility of the client to create the file if necessary, responsibility of the client to create the file if necessary,
regardless of the actual copy protocol used. If the file cannot be regardless of the actual copy protocol used. If the file cannot be
created in the destination file system (due to file name created in the destination file system (due to file name
restrictions, such as case or length), the COPY operation MUST NOT be restrictions, such as case or length), the COPY operation MUST NOT be
called. called.
skipping to change at page 65, line 23 skipping to change at page 66, line 4
/* CURRENT_FH: source file */ /* CURRENT_FH: source file */
stateid4 cna_src_stateid; stateid4 cna_src_stateid;
netloc4 cna_destination_server; netloc4 cna_destination_server;
}; };
<CODE ENDS> <CODE ENDS>
15.3.2. RESULT 15.3.2. RESULT
<CODE BEGINS> <CODE BEGINS>
struct COPY_NOTIFY4resok { struct COPY_NOTIFY4resok {
nfstime4 cnr_lease_time; nfstime4 cnr_lease_time;
stateid4 cnr_stateid;
netloc4 cnr_source_server<>; netloc4 cnr_source_server<>;
}; };
union COPY_NOTIFY4res switch (nfsstat4 cnr_status) { union COPY_NOTIFY4res switch (nfsstat4 cnr_status) {
case NFS4_OK: case NFS4_OK:
COPY_NOTIFY4resok resok4; COPY_NOTIFY4resok resok4;
default: default:
void; void;
}; };
skipping to change at page 66, line 27 skipping to change at page 67, line 5
o The client has not issued a OFFLOAD_CANCEL for the same o The client has not issued a OFFLOAD_CANCEL for the same
combination of user, filehandle, and destination server. combination of user, filehandle, and destination server.
The cnr_lease_time is chosen by the source server. A cnr_lease_time The cnr_lease_time is chosen by the source server. A cnr_lease_time
of 0 (zero) indicates an infinite lease. To avoid the need for of 0 (zero) indicates an infinite lease. To avoid the need for
synchronized clocks, copy lease times are granted by the server as a synchronized clocks, copy lease times are granted by the server as a
time delta. To renew the copy lease time the client should resend time delta. To renew the copy lease time the client should resend
the same copy notification request to the source server. the same copy notification request to the source server.
The cnr_stateid is a copy stateid which uniquely describes the state
needed on the source server to track the proposed copy. As defined
in Section 8.2 of [RFC5661], a stateid is tied to the current
filehandle and if the same stateid is presented by two different
clients, it may refer to different state. As the source does not
know which netloc4 network location the destinaton might use to
establish the copy operation, it can use the cnr_stateid to identify
that the destination is operating on behalf of the client. Thus the
source server SHOULD construct copy stateids such that they are
unique from all other stateids handed out to clients. These copy
stateids MUST equate to each of the earlier delegation, locking, and
open states for the client on the given file (see Section 4.4.1).
A successful response will also contain a list of netloc4 network A successful response will also contain a list of netloc4 network
location formats called cnr_source_server, on which the source is location formats called cnr_source_server, on which the source is
willing to accept connections from the destination. These might not willing to accept connections from the destination. These might not
be reachable from the client and might be located on networks to be reachable from the client and might be located on networks to
which the client has no connection. which the client has no connection.
For a copy only involving one server (the source and destination are For a copy only involving one server (the source and destination are
on the same server), this operation is unnecessary. on the same server), this operation is unnecessary.
15.4. Operation 62: DEALLOCATE - Unreserve Space in a Region of a File 15.4. Operation 62: DEALLOCATE - Unreserve Space in a Region of a File
skipping to change at page 94, line 25 skipping to change at page 94, line 44
For the Sharing change attribute implementation details with NFSv4 For the Sharing change attribute implementation details with NFSv4
clients, the original draft was by Trond Myklebust. clients, the original draft was by Trond Myklebust.
For the NFS Server Side Copy, the original draft was by James For the NFS Server Side Copy, the original draft was by James
Lentini, Mike Eisler, Deepak Kenchammana, Anshul Madan, and Rahul Lentini, Mike Eisler, Deepak Kenchammana, Anshul Madan, and Rahul
Iyer. Tom Talpey co-authored an unpublished version of that Iyer. Tom Talpey co-authored an unpublished version of that
document. It was also was reviewed by a number of individuals: document. It was also was reviewed by a number of individuals:
Pranoop Erasani, Tom Haynes, Arthur Lent, Trond Myklebust, Dave Pranoop Erasani, Tom Haynes, Arthur Lent, Trond Myklebust, Dave
Noveck, Theresa Lingutla-Raj, Manjunath Shankararao, Satyam Vaghani, Noveck, Theresa Lingutla-Raj, Manjunath Shankararao, Satyam Vaghani,
and Nico Williams. Anna Schumaker's early prototyping experience and Nico Williams. Anna Schumaker's early prototyping experience
helped us avoid some traps. helped us avoid some traps. Also, both Olga Kornievskaia and Andy
Adamson brought implementation experience to the use of copy stateids
in inter-server copy.
For the NFS space reservation operations, the original draft was by For the NFS space reservation operations, the original draft was by
Mike Eisler, James Lentini, Manjunath Shankararao, and Rahul Iyer. Mike Eisler, James Lentini, Manjunath Shankararao, and Rahul Iyer.
For the sparse file support, the original draft was by Dean For the sparse file support, the original draft was by Dean
Hildebrand and Marc Eshel. Valuable input and advice was received Hildebrand and Marc Eshel. Valuable input and advice was received
from Sorin Faibish, Bruce Fields, Benny Halevy, Trond Myklebust, and from Sorin Faibish, Bruce Fields, Benny Halevy, Trond Myklebust, and
Richard Scheffenegger. Richard Scheffenegger.
For the Application IO Hints, the original draft was by Dean For the Application IO Hints, the original draft was by Dean
 End of changes. 24 change blocks. 
30 lines changed or deleted 55 lines changed or added

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