draft-ietf-nfsv4-minorversion2-32.txt   draft-ietf-nfsv4-minorversion2-33.txt 
NFSv4 T. Haynes NFSv4 T. Haynes
Internet-Draft Primary Data Internet-Draft Primary Data
Intended status: Standards Track March 04, 2015 Intended status: Standards Track March 05, 2015
Expires: September 5, 2015 Expires: September 6, 2015
NFS Version 4 Minor Version 2 NFS Version 4 Minor Version 2
draft-ietf-nfsv4-minorversion2-32.txt draft-ietf-nfsv4-minorversion2-33.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 5, 2015. This Internet-Draft will expire on September 6, 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 51 skipping to change at page 2, line 51
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 . . . . . . . . . . . . . 20 4.10.1. Inter-Server Copy Security . . . . . . . . . . . . . 20
5. Support for Application IO Hints . . . . . . . . . . . . . . 28 5. Support for Application IO Hints . . . . . . . . . . . . . . 27
6. Sparse Files . . . . . . . . . . . . . . . . . . . . . . . . 28 6. Sparse Files . . . . . . . . . . . . . . . . . . . . . . . . 27
6.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 28 6.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 27
6.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 29 6.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 28
6.3. New Operations . . . . . . . . . . . . . . . . . . . . . 29 6.3. New Operations . . . . . . . . . . . . . . . . . . . . . 28
6.3.1. READ_PLUS . . . . . . . . . . . . . . . . . . . . . . 29 6.3.1. READ_PLUS . . . . . . . . . . . . . . . . . . . . . . 28
6.3.2. DEALLOCATE . . . . . . . . . . . . . . . . . . . . . 30 6.3.2. DEALLOCATE . . . . . . . . . . . . . . . . . . . . . 29
7. Space Reservation . . . . . . . . . . . . . . . . . . . . . . 30 7. Space Reservation . . . . . . . . . . . . . . . . . . . . . . 29
8. Application Data Block Support . . . . . . . . . . . . . . . 32 8. Application Data Block Support . . . . . . . . . . . . . . . 31
8.1. Generic Framework . . . . . . . . . . . . . . . . . . . . 33 8.1. Generic Framework . . . . . . . . . . . . . . . . . . . . 32
8.1.1. Data Block Representation . . . . . . . . . . . . . . 33 8.1.1. Data Block Representation . . . . . . . . . . . . . . 32
8.2. An Example of Detecting Corruption . . . . . . . . . . . 34 8.2. An Example of Detecting Corruption . . . . . . . . . . . 33
8.3. Example of READ_PLUS . . . . . . . . . . . . . . . . . . 35 8.3. Example of READ_PLUS . . . . . . . . . . . . . . . . . . 34
8.4. An Example of Zeroing Space . . . . . . . . . . . . . . . 36 8.4. An Example of Zeroing Space . . . . . . . . . . . . . . . 35
9. Labeled NFS . . . . . . . . . . . . . . . . . . . . . . . . . 36 9. Labeled NFS . . . . . . . . . . . . . . . . . . . . . . . . . 35
9.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 36 9.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 35
9.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 37 9.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 36
9.3. MAC Security Attribute . . . . . . . . . . . . . . . . . 38 9.3. MAC Security Attribute . . . . . . . . . . . . . . . . . 37
9.3.1. Delegations . . . . . . . . . . . . . . . . . . . . . 39 9.3.1. Delegations . . . . . . . . . . . . . . . . . . . . . 38
9.3.2. Permission Checking . . . . . . . . . . . . . . . . . 39 9.3.2. Permission Checking . . . . . . . . . . . . . . . . . 38
9.3.3. Object Creation . . . . . . . . . . . . . . . . . . . 39 9.3.3. Object Creation . . . . . . . . . . . . . . . . . . . 38
9.3.4. Existing Objects . . . . . . . . . . . . . . . . . . 39 9.3.4. Existing Objects . . . . . . . . . . . . . . . . . . 38
9.3.5. Label Changes . . . . . . . . . . . . . . . . . . . . 40 9.3.5. Label Changes . . . . . . . . . . . . . . . . . . . . 39
9.4. pNFS Considerations . . . . . . . . . . . . . . . . . . . 40 9.4. pNFS Considerations . . . . . . . . . . . . . . . . . . . 39
9.5. Discovery of Server Labeled NFS Support . . . . . . . . . 40 9.5. Discovery of Server Labeled NFS Support . . . . . . . . . 39
9.6. MAC Security NFS Modes of Operation . . . . . . . . . . . 41 9.6. MAC Security NFS Modes of Operation . . . . . . . . . . . 40
9.6.1. Full Mode . . . . . . . . . . . . . . . . . . . . . . 41 9.6.1. Full Mode . . . . . . . . . . . . . . . . . . . . . . 40
9.6.2. Guest Mode . . . . . . . . . . . . . . . . . . . . . 42 9.6.2. Guest Mode . . . . . . . . . . . . . . . . . . . . . 41
9.7. Security Considerations for Labeled NFS . . . . . . . . . 43 9.7. Security Considerations for Labeled NFS . . . . . . . . . 42
10. Sharing change attribute implementation details with NFSv4 10. Sharing change attribute implementation details with NFSv4
clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
11. Error Values . . . . . . . . . . . . . . . . . . . . . . . . 44 11. Error Values . . . . . . . . . . . . . . . . . . . . . . . . 43
11.1. Error Definitions . . . . . . . . . . . . . . . . . . . 44 11.1. Error Definitions . . . . . . . . . . . . . . . . . . . 43
11.1.1. General Errors . . . . . . . . . . . . . . . . . . . 44 11.1.1. General Errors . . . . . . . . . . . . . . . . . . . 43
11.1.2. Server to Server Copy Errors . . . . . . . . . . . . 44 11.1.2. Server to Server Copy Errors . . . . . . . . . . . . 43
11.1.3. Labeled NFS Errors . . . . . . . . . . . . . . . . . 45 11.1.3. Labeled NFS Errors . . . . . . . . . . . . . . . . . 44
11.2. New Operations and Their Valid Errors . . . . . . . . . 45 11.2. New Operations and Their Valid Errors . . . . . . . . . 44
11.3. New Callback Operations and Their Valid Errors . . . . . 49 11.3. New Callback Operations and Their Valid Errors . . . . . 48
12. New File Attributes . . . . . . . . . . . . . . . . . . . . . 50 12. New File Attributes . . . . . . . . . . . . . . . . . . . . . 49
12.1. New RECOMMENDED Attributes - List and Definition 12.1. New RECOMMENDED Attributes - List and Definition
References . . . . . . . . . . . . . . . . . . . . . . . 50 References . . . . . . . . . . . . . . . . . . . . . . . 49
12.2. Attribute Definitions . . . . . . . . . . . . . . . . . 50 12.2. Attribute Definitions . . . . . . . . . . . . . . . . . 49
13. Operations: REQUIRED, RECOMMENDED, or OPTIONAL . . . . . . . 53 13. Operations: REQUIRED, RECOMMENDED, or OPTIONAL . . . . . . . 52
14. Modifications to NFSv4.1 Operations . . . . . . . . . . . . . 56 14. Modifications to NFSv4.1 Operations . . . . . . . . . . . . . 55
14.1. Operation 42: EXCHANGE_ID - Instantiate Client ID . . . 56 14.1. Operation 42: EXCHANGE_ID - Instantiate Client ID . . . 55
14.2. Operation 48: GETDEVICELIST - Get All Device Mappings 14.2. Operation 48: GETDEVICELIST - Get All Device Mappings
for a File System . . . . . . . . . . . . . . . . . . . 58 for a File System . . . . . . . . . . . . . . . . . . . 57
15. NFSv4.2 Operations . . . . . . . . . . . . . . . . . . . . . 59 15. NFSv4.2 Operations . . . . . . . . . . . . . . . . . . . . . 58
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 . . . . . . . . . . . . . . . . . . . . . . . . . . 58
15.2. Operation 60: COPY - Initiate a server-side copy . . . . 60 15.2. Operation 60: COPY - Initiate a server-side copy . . . . 59
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 . . . . . . . . . . . . . . . . . . . . . . 64
15.4. Operation 62: DEALLOCATE - Unreserve Space in a Region 15.4. Operation 62: DEALLOCATE - Unreserve Space in a Region
of a File . . . . . . . . . . . . . . . . . . . . . . . 67 of a File . . . . . . . . . . . . . . . . . . . . . . . 66
15.5. Operation 63: IO_ADVISE - Application I/O access pattern 15.5. Operation 63: IO_ADVISE - Application I/O access pattern
hints . . . . . . . . . . . . . . . . . . . . . . . . . 68 hints . . . . . . . . . . . . . . . . . . . . . . . . . 67
15.6. Operation 64: LAYOUTERROR - Provide Errors for the 15.6. Operation 64: LAYOUTERROR - Provide Errors for the
Layout . . . . . . . . . . . . . . . . . . . . . . . . . 74 Layout . . . . . . . . . . . . . . . . . . . . . . . . . 73
15.7. Operation 65: LAYOUTSTATS - Provide Statistics for the 15.7. Operation 65: LAYOUTSTATS - Provide Statistics for the
Layout . . . . . . . . . . . . . . . . . . . . . . . . . 77 Layout . . . . . . . . . . . . . . . . . . . . . . . . . 76
15.8. Operation 66: OFFLOAD_CANCEL - Stop an Offloaded 15.8. Operation 66: OFFLOAD_CANCEL - Stop an Offloaded
Operation . . . . . . . . . . . . . . . . . . . . . . . 78 Operation . . . . . . . . . . . . . . . . . . . . . . . 77
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 . . . . . . . . . . . . . . . . . 78
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 79
15.11. Operation 69: SEEK - Find the Next Data or Hole . . . . 85 15.11. Operation 69: SEEK - Find the Next Data or Hole . . . . 84
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 . . . . . . . . . . . . . . . . . . . . . . . 85
16. NFSv4.2 Callback Operations . . . . . . . . . . . . . . . . . 90 16. NFSv4.2 Callback Operations . . . . . . . . . . . . . . . . . 89
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 . . . . . . . . . . . . . . . . . 89
17. Security Considerations . . . . . . . . . . . . . . . . . . . 91 17. Security Considerations . . . . . . . . . . . . . . . . . . . 90
18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 92 18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 91
19. References . . . . . . . . . . . . . . . . . . . . . . . . . 92 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 91
19.1. Normative References . . . . . . . . . . . . . . . . . . 92 19.1. Normative References . . . . . . . . . . . . . . . . . . 91
19.2. Informative References . . . . . . . . . . . . . . . . . 92 19.2. Informative References . . . . . . . . . . . . . . . . . 91
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 94 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 93
Appendix B. RFC Editor Notes . . . . . . . . . . . . . . . . . . 95 Appendix B. RFC Editor Notes . . . . . . . . . . . . . . . . . . 94
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 95 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 94
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
minor version of the NFS version 4 (NFSv4) protocol. The first minor minor version of the NFS version 4 (NFSv4) protocol. The first minor
version, NFSv4.0, is described in [I-D.ietf-nfsv4-rfc3530bis] and the version, NFSv4.0, is described in [I-D.ietf-nfsv4-rfc3530bis] and the
second minor version, NFSv4.1, is described in [RFC5661]. second minor version, NFSv4.1, is described in [RFC5661].
skipping to change at page 18, line 36 skipping to change at page 18, line 36
this are given in Section 4.10.1.3. this are given in Section 4.10.1.3.
4.8. netloc4 - Network Locations 4.8. netloc4 - Network Locations
The server-side copy operations specify network locations using the The server-side copy operations specify network locations using the
netloc4 data type shown below: netloc4 data type shown below:
<CODE BEGINS> <CODE BEGINS>
enum netloc_type4 { enum netloc_type4 {
NL4_NAME = 0, NL4_NAME = 1,
NL4_URL = 1, NL4_URL = 2,
NL4_NETADDR = 2 NL4_NETADDR = 3
}; };
union netloc4 switch (netloc_type4 nl_type) { union netloc4 switch (netloc_type4 nl_type) {
case NL4_NAME: utf8str_cis nl_name; case NL4_NAME: utf8str_cis nl_name;
case NL4_URL: utf8str_cis nl_url; case NL4_URL: utf8str_cis nl_url;
case NL4_NETADDR: netaddr4 nl_addr; case NL4_NETADDR: netaddr4 nl_addr;
}; };
<CODE ENDS> <CODE ENDS>
If the netloc4 is of type NL4_NAME, the nl_name field MUST be If the netloc4 is of type NL4_NAME, the nl_name field MUST be
skipping to change at page 26, line 36 skipping to change at page 26, line 36
AUTH_SYS MAY be used. If a host-based security flavor is used, a AUTH_SYS MAY be used. If a host-based security flavor is used, a
minimal level of protection for the server-to-server copy protocol is minimal level of protection for the server-to-server copy protocol is
possible. possible.
In the absence of a strong security mechanism designed for the In the absence of a strong security mechanism designed for the
purpose, the challenge is how the source server and destination purpose, the challenge is how the source server and destination
server identify themselves to each other, especially in the presence server identify themselves to each other, especially in the presence
of multi-homed source and destination servers. In a multi-homed of multi-homed source and destination servers. In a multi-homed
environment, the destination server might not contact the source environment, the destination server might not contact the source
server from the same network address specified by the client in the server from the same network address specified by the client in the
COPY_NOTIFY. This can be overcome using the procedure described COPY_NOTIFY. The cnr_stateid returned from the COPY_NOTIFY can be
below. used to uiniquely identify the destination server to the source
server. The use of cnr_stateid provides initial authentication of
When the client sends the source server the COPY_NOTIFY operation, the destination server, but cannot defend against man-in-the-middle
the source server may reply to the client with a list of target attacks after authentication or an eavesdropper that observes the
addresses, names, and/or URLs and assign them to the unique opaque stateid on the wire. Other secure communication techniques
quadruple: <random number, source fh, user ID, destination address (e.g., IPsec) are necessary to block these attacks.
Y>. If the destination uses one of these target netlocs to contact
the source server, the source server will be able to uniquely
identify the destination server, even if the destination server does
not connect from the address specified by the client in COPY_NOTIFY.
The level of assurance in this identification depends on the
unpredictability, strength and secrecy of the random number.
For example, suppose the network topology is as shown in Figure 3.
If the source filehandle is 0x12345, the source server may respond to
a COPY_NOTIFY for destination 203.0.113.56 with the URLs:
nfs://203.0.113.18//_COPY/FvhH1OKbu8VrxvV1erdjvR7N/203.0.113.56/
_FH/0x12345
nfs://192.0.2.18//_COPY/FvhH1OKbu8VrxvV1erdjvR7N/203.0.113.56/_FH/
0x12345
The name component after _COPY is 24 characters of base 64, more than
enough to encode a 128 bit random number.
The client will then send these URLs to the destination server in the
COPY operation. Suppose that the 192.0.2.0/24 network is a high
speed network and the destination server decides to transfer the file
over this network. If the destination contacts the source server
from 192.0.2.56 over this network using NFSv4.1, it does the
following:
COMPOUND { PUTROOTFH, LOOKUP "_COPY" ; LOOKUP
"FvhH1OKbu8VrxvV1erdjvR7N" ; LOOKUP "203.0.113.56"; LOOKUP "_FH" ;
OPEN "0x12345" ; GETFH }
Provided that the random number is unpredictable and has been kept
secret by the parties involved, the source server will therefore know
that these NFSv4.x operations are being issued by the destination
server identified in the COPY_NOTIFY. This random number technique
only provides initial authentication of the destination server, and
cannot defend against man-in-the-middle attacks after authentication
or an eavesdropper that observes the random number on the wire.
Other secure communication techniques (e.g., IPsec) are necessary to
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 cnr_stateid in the COPY_NOTIFY reply
encrypted. For the same reason, clients SHOULD send COPY requests to is encrypted. For the same reason, clients SHOULD send COPY requests
the destination using RPCSEC_GSS with privacy. to 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.
5. Support for Application IO Hints 5. Support for Application IO Hints
Applications can issue client I/O hints via posix_fadvise() Applications can issue client I/O hints via posix_fadvise()
skipping to change at page 61, line 16 skipping to change at page 60, line 16
<CODE BEGINS> <CODE BEGINS>
struct write_response4 { struct write_response4 {
stateid4 wr_callback_id<1>; stateid4 wr_callback_id<1>;
length4 wr_count; length4 wr_count;
stable_how4 wr_committed; stable_how4 wr_committed;
verifier4 wr_writeverf; verifier4 wr_writeverf;
}; };
struct COPY4res { struct copy_requirements4 {
nfsstat4 cr_status;
write_response4 cr_response;
bool cr_consecutive; bool cr_consecutive;
bool cr_synchronous; bool cr_synchronous;
}; };
struct COPY4resok {
write_response4 cr_response;
copy_requirements4 cr_requirements;
};
union COPY4res switch (nfsstat4 cr_status) {
case NFS4_OK:
COPY4resok cr_resok4;
case NFS4ERR_OFFLOAD_NO_REQS:
copy_requirements4 cr_requirements;
default:
void;
};
<CODE ENDS> <CODE ENDS>
15.2.3. DESCRIPTION 15.2.3. DESCRIPTION
The COPY operation is used for both intra-server and inter-server The COPY operation is used for both intra-server and inter-server
copies. In both cases, the COPY is always sent from the client to copies. In both cases, the COPY is always sent from the client to
the destination server of the file copy. The COPY operation requests the destination server of the file copy. The COPY operation requests
that a file be copied from the location specified by the SAVED_FH that a file be copied from the location specified by the SAVED_FH
value to the location specified by the CURRENT_FH. value to the location specified by the CURRENT_FH.
skipping to change at page 67, line 13 skipping to change at page 66, line 13
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 The cnr_stateid is a copy stateid which uniquely describes the state
needed on the source server to track the proposed copy. As defined 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 in Section 8.2 of [RFC5661], a stateid is tied to the current
filehandle and if the same stateid is presented by two different filehandle and if the same stateid is presented by two different
clients, it may refer to different state. As the source does not clients, it may refer to different state. As the source does not
know which netloc4 network location the destinaton might use to know which netloc4 network location the destinaton might use to
establish the copy operation, it can use the cnr_stateid to identify establish the copy operation, it can use the cnr_stateid to identify
that the destination is operating on behalf of the client. Thus the that the destination is operating on behalf of the client. Thus the
source server SHOULD construct copy stateids such that they are source server MUST construct copy stateids such that they are unique
unique from all other stateids handed out to clients. These copy from all other stateids handed out to clients. These copy stateids
stateids MUST equate to each of the earlier delegation, locking, and MUST equate to each of the earlier delegation, locking, and open
open states for the client on the given file (see Section 4.4.1). 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.
 End of changes. 23 change blocks. 
138 lines changed or deleted 103 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/