draft-ietf-nfsv4-rfc3530-migration-update-05.txt   draft-ietf-nfsv4-rfc3530-migration-update-06.txt 
NFSv4 D. Noveck, Ed. NFSv4 D. Noveck, Ed.
Internet-Draft Dell Internet-Draft Dell
Updates: 3530 (if approved) P. Shivam Updates: 3530bis (if approved) P. Shivam
Intended status: Standards Track C. Lever Intended status: Standards Track C. Lever
Expires: March 26, 2015 B. Baker Expires: July 8, 2015 B. Baker
ORACLE ORACLE
September 22, 2014 January 4, 2015
NFSv4.0 migration: Specification Update NFSv4.0 migration: Specification Update
draft-ietf-nfsv4-rfc3530-migration-update-05 draft-ietf-nfsv4-rfc3530-migration-update-06
Abstract Abstract
The migration feature of NFSv4 allows for responsibility for a single The migration feature of NFSv4 allows for responsibility for a single
filesystem to move from one server to another, without disruption to filesystem to move from one server to another, without disruption to
clients. Recent implementation experience has shown problems in the clients. Recent implementation experience has shown problems in the
existing specification for this feature in NFSv4.0. This document existing specification for this feature in NFSv4.0. This document
clarifies and corrects the NFSv4.0 specification (RFC3530 and clarifies and corrects RFC3530bis (the NFSv4.0 specification) to
possible successors) to address these problems. address these problems.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 March 26, 2015. This Internet-Draft will expire on July 8, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Client Identity Definition . . . . . . . . . . . . . . . . . 5 4. Client Identity Definition . . . . . . . . . . . . . . . . . 5
4.1. Differences from Replaced Sections . . . . . . . . . . . 5 4.1. Differences from Replaced Sections . . . . . . . . . . . 5
4.2. Client Identity Data Items . . . . . . . . . . . . . . . 6 4.2. Client Identity Data Items . . . . . . . . . . . . . . . 5
4.3. Server Release of Client Id . . . . . . . . . . . . . . . 10 4.3. Server Release of Client ID . . . . . . . . . . . . . . . 10
4.4. Client Id String Approaches . . . . . . . . . . . . . . . 10 4.4. Client Id String Approaches . . . . . . . . . . . . . . . 10
4.5. Non-Uniform Client Id String Approach . . . . . . . . . . 12 4.5. Non-Uniform Client Id String Approach . . . . . . . . . . 12
4.6. Uniform Client Id String Approach . . . . . . . . . . . . 13 4.6. Uniform Client Id String Approach . . . . . . . . . . . . 13
4.7. Mixing Client Id String Approaches . . . . . . . . . . . 15 4.7. Mixing Client Id String Approaches . . . . . . . . . . . 15
4.8. Trunking Determination when Using Uniform Client Id 4.8. Trunking Determination when Using Uniform Client Id
Strings . . . . . . . . . . . . . . . . . . . . . . . . . 16 Strings . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.9. Client Id String Construction Details . . . . . . . . . . 22 4.9. Client Id String Construction Details . . . . . . . . . . 22
5. Locking and Multi-Server Namespace . . . . . . . . . . . . . 23 5. Locking and Multi-Server Namespace . . . . . . . . . . . . . 23
5.1. Changes from Replaced Sections . . . . . . . . . . . . . 24 5.1. Changes from Replaced Sections . . . . . . . . . . . . . 23
5.2. Lock State and Filesystem Transitions . . . . . . . . . . 24 5.2. Lock State and Filesystem Transitions . . . . . . . . . . 24
5.3. Migration and State . . . . . . . . . . . . . . . . . . . 24 5.3. Migration and State . . . . . . . . . . . . . . . . . . . 24
5.3.1. Migration and Clientid's . . . . . . . . . . . . . . 26 5.3.1. Migration and Clientid's . . . . . . . . . . . . . . 26
5.3.2. Migration and State Owner Information . . . . . . . . 27 5.3.2. Migration and State Owner Information . . . . . . . . 27
5.4. Replication and State . . . . . . . . . . . . . . . . . . 31 5.4. Replication and State . . . . . . . . . . . . . . . . . . 31
5.5. Notification of Migrated Lease . . . . . . . . . . . . . 31 5.5. Notification of Migrated Lease . . . . . . . . . . . . . 31
5.6. Migration and the Lease_time Attribute . . . . . . . . . 34 5.6. Migration and the Lease_time Attribute . . . . . . . . . 34
6. Server Implementation Considerations . . . . . . . . . . . . 35 6. Server Implementation Considerations . . . . . . . . . . . . 34
6.1. Relation of Locking State Transfer to Other Aspects of 6.1. Relation of Locking State Transfer to Other Aspects of
Filesystem Motion . . . . . . . . . . . . . . . . . . . . 35 Filesystem Motion . . . . . . . . . . . . . . . . . . . . 34
6.2. Preventing Locking State Modification During Transfer . . 36 6.2. Preventing Locking State Modification During Transfer . . 36
7. Additional Changes . . . . . . . . . . . . . . . . . . . . . 39 7. Additional Changes . . . . . . . . . . . . . . . . . . . . . 39
7.1. Summary of Additional Changes from Previous Documents . . 40 7.1. Summary of Additional Changes from Previous Documents . . 39
7.2. NFS4ERR_CLID_INUSE definition . . . . . . . . . . . . . . 40 7.2. NFS4ERR_CLID_INUSE definition . . . . . . . . . . . . . . 40
7.3. NFS4ERR_DELAY return from RELEASE_LOCKOWNER . . . . . . . 40 7.3. NFS4ERR_DELAY return from RELEASE_LOCKOWNER . . . . . . . 40
7.4. Operation 35: SETCLIENTID - Negotiate Client ID . . . . . 41 7.4. Operation 35: SETCLIENTID - Negotiate Client ID . . . . . 41
7.5. Security Considerations for Inter-server Information 7.5. Security Considerations for Inter-server Information
Transfer . . . . . . . . . . . . . . . . . . . . . . . . 45 Transfer . . . . . . . . . . . . . . . . . . . . . . . . 45
7.6. Security Considerations Revision . . . . . . . . . . . . 46 7.6. Security Considerations Revision . . . . . . . . . . . . 45
8. Security Considerations . . . . . . . . . . . . . . . . . . . 46 8. Security Considerations . . . . . . . . . . . . . . . . . . . 46
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 46 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 46
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 46 10.1. Normative References . . . . . . . . . . . . . . . . . . 46
11.1. Normative References . . . . . . . . . . . . . . . . . . 47 10.2. Informative References . . . . . . . . . . . . . . . . . 46
11.2. Informative References . . . . . . . . . . . . . . . . . 47 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 46
Appendix B. RFC Editor Notes . . . . . . . . . . . . . . . . . . 47
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47
1. Introduction 1. Introduction
This document is a standards track document which corrects the This document is a standards track document which corrects the
existing definitive specification of the NFSv4.0 protocol, in existing definitive specification of the NFSv4.0 protocol, in
[RFC3530] and the one expected to become definitive (now in [RFC3530bis]. Given this fact, one should take the current document
[cur-rfc3530-bis]). Given this fact, one should take the current into account when learning about NFSv4.0, particularly if one is
document into account when learning about NFSv4.0, particularly if concerned with issues that relate to:
one is concerned with issues that relate to:
o Filesystem migration, particularly when it involves transparent o Filesystem migration, particularly when it involves transparent
state migration. state migration.
o The construction and interpretation of the nfs_clientid4 structure o The construction and interpretation of the nfs_clientid4 structure
and particularly the requirements on the id string within it, and particularly the requirements on the id string within it,
referred to below as a "client id string". referred to below as a "client id string".
2. Conventions 2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Background 3. Background
Implementation experience with transparent state migration has Implementation experience with transparent state migration has
exposed a number of problems with the existing specification of this exposed a number of problems with the then-existing specifications of
feature, in [RFC3530] and in RFC3530bis (see the draft at this feature, in [RFC3530bis] and predecessors. The symptoms were:
[cur-rfc3530-bis]). The symptoms were:
o After migration of a filesystem, a reboot of the associated client o After migration of a filesystem, a reboot of the associated client
was not appropriately dealt with, in that the state associated was not appropriately dealt with, in that the state associated
with the rebooting client was not promptly freed. with the rebooting client was not promptly freed.
o Situations can arise whereby a given server has multiple leases o Situations can arise whereby a given server has multiple leases
with the same nfs_client_id4 (id and verifier), when the protocol with the same nfs_client_id4 (id and verifier), when the protocol
clearly assumes there can be only one. clearly assumes there can be only one.
o Excessive client implementation complexity since clients have to o Excessive client implementation complexity since clients have to
skipping to change at page 4, line 14 skipping to change at page 4, line 14
failure to describe how migrating state is to be integrated with failure to describe how migrating state is to be integrated with
existing client definition structures on the destination server. existing client definition structures on the destination server.
Specification of requirements for the server to appropriately merge Specification of requirements for the server to appropriately merge
stateids associated with a common client boot instance encounters a stateids associated with a common client boot instance encounters a
difficult problem. The issue is that the common client practice with difficult problem. The issue is that the common client practice with
regard to the presentation of unique strings specifying client regard to the presentation of unique strings specifying client
identity makes it essentially impossible for the client to determine identity makes it essentially impossible for the client to determine
whether or not two stateids, originally generated on different whether or not two stateids, originally generated on different
servers are referable to the same client. This practice is allowed servers are referable to the same client. This practice is allowed
and endorsed, although not "RECOMMENDED", by existing NFSv4.0 and endorsed, although not "RECOMMENDED", by the existing NFSv4.0
specifications ([RFC3530] and RFC3530bis, whose current draft is at specification, [RFC3530bis]).
[cur-rfc3530-bis]).
To further complicate matters, upon prototyping of clients To further complicate matters, upon prototyping of clients
implementing an alternative approach, it has been found that there implementing an alternative approach, it has been found that there
exist servers which do not work well with these new clients. It exist servers which do not work well with these new clients. It
appears that current circumstances, in which a particular client appears that current circumstances, in which a particular client
implementation pattern had been adopted universally, has resulted in implementation pattern had been adopted universally, has resulted in
servers not being able to interoperate against alternate client servers not being able to interoperate against alternate client
implementation patterns. As a result, we have a situation which implementation patterns. As a result, we have a situation which
requires careful attention to compatibility issues to untangle. requires careful attention to compatibility issues to untangle.
This document updates the existing NFSv4.0 specifications ([RFC3530] This document updates the existing NFSv4.0 specification
and RFC3530bis, whose current draft is at [cur-rfc3530-bis]) as [RFC3530bis]) as follows:
follows:
o It makes clear that NFSv4.0 supports multiple approaches to the o It makes clear that NFSv4.0 supports multiple approaches to the
construction of client id strings, including that formerly construction of client id strings, including that formerly
endorsed by existing NFSV4.0 specifications, and currently widely endorsed by existing NFSV4.0 specifications, and currently widely
deployed. deployed.
o It addresses the potential compatibility issues that might arise o It addresses the potential compatibility issues that might arise
for clients adopting a previously non-favored client id for clients adopting a previously non-favored client id
construction approach including the existence of servers which construction approach including the existence of servers which
have problems with the new approach. have problems with the new approach.
skipping to change at page 5, line 15 skipping to change at page 5, line 12
o It makes further clarifications and corrections to address cases o It makes further clarifications and corrections to address cases
where the specification text does not take proper account of the where the specification text does not take proper account of the
issues raised by state migration or where it has been found that issues raised by state migration or where it has been found that
the existing text is insufficiently clear. the existing text is insufficiently clear.
For a more complete explanation of the choices made in addressing For a more complete explanation of the choices made in addressing
these issues, see [info-migr]). these issues, see [info-migr]).
4. Client Identity Definition 4. Client Identity Definition
This chapter is a replacement for sections 8.1.1 and 8.1.2 in This chapter is a replacement for sections 9.1.1 and 9.1.2 in
[RFC3530] and for sections 9.1.1 and 9.1.2 in RFC3530bis (see the [RFC3530bis]). The replaced sections are named "client ID" and
draft at [cur-rfc3530-bis]). The replaced sections are named "client "Server Release of Clientid."
ID" and "Server Release of Clientid."
It supersedes the replaced sections. It supersedes the replaced sections.
4.1. Differences from Replaced Sections 4.1. Differences from Replaced Sections
Because of the need for greater attention to and careful description Because of the need for greater attention to and careful description
of this area, this chapter is much larger than the sections it of this area, this chapter is much larger than the sections it
replaces. The principal changes/additions made by this chapter are: replaces. The principal changes/additions made by this chapter are:
o It corrects inconsistencies regarding the possible role or non- o It corrects inconsistencies regarding the possible role or non-
skipping to change at page 10, line 8 skipping to change at page 10, line 5
The client must also employ the SETCLIENTID operation when it The client must also employ the SETCLIENTID operation when it
receives a NFS4ERR_STALE_STATEID error using a stateid derived from receives a NFS4ERR_STALE_STATEID error using a stateid derived from
its current clientid4, since this indicates a situation, such as its current clientid4, since this indicates a situation, such as
server reboot which has invalidated the existing clientid4 and server reboot which has invalidated the existing clientid4 and
associated stateids (see the section entitled "lock-owner" for associated stateids (see the section entitled "lock-owner" for
details). details).
See the detailed descriptions of SETCLIENTID and SETCLIENTID_CONFIRM See the detailed descriptions of SETCLIENTID and SETCLIENTID_CONFIRM
for a complete specification of these operations. for a complete specification of these operations.
4.3. Server Release of Client Id 4.3. Server Release of Client ID
If the server determines that the client holds no associated state If the server determines that the client holds no associated state
for its clientid4, the server may choose to release that clientid4. for its clientid4, the server may choose to release that clientid4.
The server may make this choice for an inactive client so that The server may make this choice for an inactive client so that
resources are not consumed by those intermittently active clients. resources are not consumed by those intermittently active clients.
If the client contacts the server after this release, the server must If the client contacts the server after this release, the server must
ensure the client receives the appropriate error so that it will use ensure the client receives the appropriate error so that it will use
the SETCLIENTID/SETCLIENTID_CONFIRM sequence to establish a new the SETCLIENTID/SETCLIENTID_CONFIRM sequence to establish a new
identity. It should be clear that the server must be very hesitant identity. It should be clear that the server must be very hesitant
to release a client ID since the resulting work on the client to to release a client ID since the resulting work on the client to
skipping to change at page 11, line 41 skipping to change at page 11, line 37
server to be aware when two requests come from the same client server to be aware when two requests come from the same client
(they are on sessions sharing a clientid4) and the client to be (they are on sessions sharing a clientid4) and the client to be
aware when two server IP addresses are connected to the same aware when two server IP addresses are connected to the same
server (they return the same server name in responding to an server (they return the same server name in responding to an
EXCHANGE_ID). EXCHANGE_ID).
NFSv4.0 is unfortunately halfway between these two. The two client NFSv4.0 is unfortunately halfway between these two. The two client
id string approaches have arisen in attempts to deal with the id string approaches have arisen in attempts to deal with the
changing requirements of the protocol as implementation has proceeded changing requirements of the protocol as implementation has proceeded
and features that were not very substantial in early implementations and features that were not very substantial in early implementations
of [RFC3530], became more substantial as implementation proceeded. of NFSv4.0, became more substantial as implementation proceeded.
o In the absence of any implementation of the fs_locations-related o In the absence of any implementation of the fs_locations-related
features (replication, referral, and migration), the situation is features (replication, referral, and migration), the situation is
very similar to that of NFSv3, with the addition of state but with very similar to that of NFSv3, with the addition of state but with
no concern to provide accurate client and server identity no concern to provide accurate client and server identity
determination. This is the situation that gave rise to the non- determination. This is the situation that gave rise to the non-
uniform client id string approach. uniform client id string approach.
o In the presence of replication and referrals, the client may have o In the presence of replication and referrals, the client may have
occasion to take advantage of knowledge of server trunking occasion to take advantage of knowledge of server trunking
skipping to change at page 14, line 5 skipping to change at page 13, line 45
difference in behavior allows the client to infer the server IP difference in behavior allows the client to infer the server IP
address trunking configuration, even though NFSv4.0 does not address trunking configuration, even though NFSv4.0 does not
explicitly provide this information. explicitly provide this information.
The approach given in the section below shows one example of how The approach given in the section below shows one example of how
this might be done. this might be done.
The uniform client id string approach makes it necessary to exercise The uniform client id string approach makes it necessary to exercise
more care in the definition of the nfs_client_id4 boot verifier: more care in the definition of the nfs_client_id4 boot verifier:
o In [RFC3530], the client is told to change the boot verifier when o In [RFC3530bis], the client is told to change the boot verifier
reboot occurs, but there is no explicit statement as to the when reboot occurs, but there is no explicit statement as to the
converse, so that any requirement to keep the verifier constant converse, so that any requirement to keep the verifier constant
unless rebooting is only present by implication. unless rebooting is only present by implication.
o Many existing clients change the boot verifier every time they o Many existing clients change the boot verifier every time they
destroy and recreate the data structure that tracks an <IP- destroy and recreate the data structure that tracks an <IP-
address, clientid4> pair. This might happen if the last mount of address, clientid4> pair. This might happen if the last mount of
a particular server is removed, and then a fresh mount is created. a particular server is removed, and then a fresh mount is created.
Also, note that this might result in each <IP-address, clientid4> Also, note that this might result in each <IP-address, clientid4>
pair having its own boot verifier that is independent of the pair having its own boot verifier that is independent of the
others. others.
skipping to change at page 15, line 30 skipping to change at page 15, line 23
o Some existing NFSv4.0 server implementations of IP address o Some existing NFSv4.0 server implementations of IP address
failover depend on clients' use of a non-uniform client id string failover depend on clients' use of a non-uniform client id string
approach. In particular, when a server supports both its own IP approach. In particular, when a server supports both its own IP
address and one failed over from a partner server, it may have address and one failed over from a partner server, it may have
separate sets of state applicable to the two IP addresses, owned separate sets of state applicable to the two IP addresses, owned
by different servers but residing on a single one. by different servers but residing on a single one.
In this situation, some servers have relied on clients' use of the In this situation, some servers have relied on clients' use of the
non-uniform client id string approach, as suggested but not non-uniform client id string approach, as suggested but not
mandated by [RFC3530], to keep these sets of state separate, and mandated by [RFC3530bis], to keep these sets of state separate,
will have problems in handling clients using the uniform client id and will have problems in handling clients using the uniform
string approach, in that such clients will see changes in trunking client id string approach, in that such clients will see changes
relationships whenever server failover and giveback occur. in trunking relationships whenever server failover and giveback
occur.
o Some existing servers incorrectly return NFS4ERR_CLID_INUSE simply o Some existing servers incorrectly return NFS4ERR_CLID_INUSE simply
because there already exists a clientid for the same client, because there already exists a clientid for the same client,
established using a different IP address. This causes difficulty established using a different IP address. This causes difficulty
for a multi-homed client using the uniform client id string for a multi-homed client using the uniform client id string
approach. approach.
Although this behavior is not correct, such servers still exist Although this behavior is not correct, such servers still exist
and the spec should give clients guidance about dealing with the and the spec should give clients guidance about dealing with the
situation, as well as making the correct behavior clear. situation, as well as making the correct behavior clear.
skipping to change at page 23, line 45 skipping to change at page 23, line 36
* 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, generally established once and saved. * A true random number, generally established once and saved.
5. Locking and Multi-Server Namespace 5. Locking and Multi-Server Namespace
This chapter is a replacement for section 7.7.6, "Lock State and File This chapter is a replacement for section 7.7.6, "Lock State and File
System transitions", in RFC3530bis (see the draft at System transitions", in [RFC3530bis]).
[cur-rfc3530-bis]).
With respect to [RFC3530], it serves as a replacement for section
8.14, "Migration, Replication, and State".
It supersedes the replaced sections. It supersedes the replaced sections.
5.1. Changes from Replaced Sections 5.1. Changes from Replaced Sections
These changes can be briefly summarized as follows: These changes can be briefly summarized as follows:
o Adding text to address the case of stateid conflict on migration. o Adding text to address the case of stateid conflict on migration.
o Specifying that when leases are moved, as a result of filesystem o Specifying that when leases are moved, as a result of filesystem
skipping to change at page 40, line 43 skipping to change at page 40, line 30
7.3. NFS4ERR_DELAY return from RELEASE_LOCKOWNER 7.3. NFS4ERR_DELAY return from RELEASE_LOCKOWNER
The existing error tables should be considered modified to allow The existing error tables should be considered modified to allow
NFS4ERR_DELAY to be returned by RELEASE_LOCKOWNER. However, the NFS4ERR_DELAY to be returned by RELEASE_LOCKOWNER. However, the
scope of this addition is limited and is not to be considered as scope of this addition is limited and is not to be considered as
making this error return generally acceptable. making this error return generally acceptable.
It needs to be made clear that servers may not return this error to It needs to be made clear that servers may not return this error to
clients not prepared to support filesystem migration. Such clients clients not prepared to support filesystem migration. Such clients
may be following the error specifications in [RFC3530] and may be following the error specifications in [RFC3530bis] and so
[cur-rfc3530-bis] and so might not expect NFS4ERR_DELAY to be might not expect NFS4ERR_DELAY to be returned on RELEASE_LOCKOWNER.
returned on RELEASE_LOCKOWNER.
The following constraint applies to this additional error return, as The following constraint applies to this additional error return, as
if it were a note appearing together with the newly allowed error if it were a note appearing together with the newly allowed error
code: code:
In order to make server state fixed for a filesystem being In order to make server state fixed for a filesystem being
migrated, a server MAY return NFS4ERR_DELAY in response to a migrated, a server MAY return NFS4ERR_DELAY in response to a
RELEASE_LOCKOWNER that will affect locking state being propagated RELEASE_LOCKOWNER that will affect locking state being propagated
to a destination server. The source server MUST NOT do so unless to a destination server. The source server MUST NOT do so unless
it is likely that it will later return NFS4ERR_MOVED for the it is likely that it will later return NFS4ERR_MOVED for the
skipping to change at page 46, line 35 skipping to change at page 46, line 15
8. Security Considerations 8. Security Considerations
Is to be modified as specified in Section 7.6. Is to be modified as specified in Section 7.6.
In addition, the material in Section 7.5 should be noted. In addition, the material in Section 7.5 should be noted.
9. IANA Considerations 9. IANA Considerations
This document does not require actions by IANA. This document does not require actions by IANA.
10. Acknowledgements 10. References
The editor and authors of this document gratefully acknowledge the
contributions of Trond Myklebust of Primary Data and Robert Thurlow
of Oracle. We also thank Tom Haynes of Primary Data and Spencer
Shepler of Microsoft for their guidance and suggestions.
Special thanks go to members of the Oracle Solaris NFS team,
especially Rick Mesta and James Wahlig, for their work implementing
an NFSv4.0 migration prototype and identifying many of the issues
addressed here.
11. References 10.1. Normative References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., [RFC3530bis]
Beame, C., Eisler, M., and D. Noveck, "Network File System Haynes, T., Ed. and D. Noveck, Ed., "Network File System
(NFS) version 4 Protocol", RFC 3530, April 2003. (NFS) Version 4 Protocol", December 2014,
<http://www.ietf.org/id/
draft-ietf-nfsv4-rfc3530bis-35.txt>.
11.2. Informative References Work in progress.
10.2. Informative References
[RFC1813] Callaghan, B., Pawlowski, B., and P. Staubach, "NFS [RFC1813] Callaghan, B., Pawlowski, B., and P. Staubach, "NFS
Version 3 Protocol Specification", RFC 1813, June 1995. Version 3 Protocol Specification", RFC 1813, June 1995.
[RFC5661] Shepler, S., Eisler, M., and D. Noveck, "Network File [RFC5661] Shepler, S., Eisler, M., and D. Noveck, "Network File
System (NFS) Version 4 Minor Version 1 Protocol", RFC System (NFS) Version 4 Minor Version 1 Protocol", RFC
5661, January 2010. 5661, January 2010.
[cur-rfc3530-bis]
Haynes, T., Ed. and D. Noveck, Ed., "Network File System
(NFS) Version 4 Protocol", 2014, <http://www.ietf.org/id/
draft-ietf-nfsv4-rfc3530bis-33.txt>.
Work in progress.
[info-migr] [info-migr]
Noveck, D., Ed., Shivam, P., Lever, C., and B. Baker, Noveck, D., Ed., Shivam, P., Lever, C., and B. Baker,
"NFSv4 migration: Implementation experience and spec "NFSv4 migration: Implementation experience and spec
issues to resolve", 2014, <http://www.ietf.org/id/ issues to resolve", september 2014,
<http://www.ietf.org/id/
draft-ietf-nfsv4-migration-issues-06.txt>. draft-ietf-nfsv4-migration-issues-06.txt>.
Work in progress. Work in progress.
Appendix A. Acknowledgements
The editor and authors of this document gratefully acknowledge the
contributions of Trond Myklebust of Primary Data and Robert Thurlow
of Oracle. We also thank Tom Haynes of Primary Data and Spencer
Shepler of Microsoft for their guidance and suggestions.
Special thanks go to members of the Oracle Solaris NFS team,
especially Rick Mesta and James Wahlig, for their work implementing
an NFSv4.0 migration prototype and identifying many of the issues
addressed here.
Appendix B. RFC Editor Notes
[RFC Editor: please remove this section prior to publishing this
document as an RFC]
[RFC Editor: prior to publishing this document as an RFC, please
replace all occurrences of RFC3530bis with RFCxxxx where xxxx is the
RFC number assigned to that dpcument.]
[RFC Editor: prior to publishing this document as an RFC, please
change the specfication of the document that this document updates
from "3530bis" to xxxx where xxxx is the RFC number assigned to
RFC3530bis.
Authors' Addresses Authors' Addresses
David Noveck (editor) David Noveck (editor)
Dell Dell
300 Innovative Way 300 Innovative Way
Nashua, NH 03062 Nashua, NH 03062
US US
Phone: +1 781 572 8038 Phone: +1 781 572 8038
Email: dave_noveck@dell.com Email: dave_noveck@dell.com
 End of changes. 32 change blocks. 
78 lines changed or deleted 82 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/