draft-ietf-nfsv4-rfc3530-migration-update-03.txt   draft-ietf-nfsv4-rfc3530-migration-update-04.txt 
NFSv4 D. Noveck, Ed. NFSv4 D. Noveck, Ed.
Internet-Draft EMC Internet-Draft
Updates: 3530 (if approved) P. Shivam Updates: 3530 (if approved) P. Shivam
Intended status: Standards Track C. Lever Intended status: Standards Track C. Lever
Expires: April 15, 2014 B. Baker Expires: September 30, 2014 B. Baker
ORACLE ORACLE
October 12, 2013 March 29, 2014
NFSv4.0 migration: Specification Update NFSv4.0 migration: Specification Update
draft-ietf-nfsv4-rfc3530-migration-update-03 draft-ietf-nfsv4-rfc3530-migration-update-04
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 the NFSv4.0 specification (RFC3530 and
possible successors) to address these problems. possible successors) to address these problems.
skipping to change at page 1, line 38 skipping to change at page 1, line 38
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 April 15, 2014. This Internet-Draft will expire on September 30, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 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
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
skipping to change at page 2, line 21 skipping to change at page 2, line 21
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 . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . 14 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 . . . . . . . . . . 21 4.9. Client id string construction details . . . . . . . . . . 22
5. Locking and Multi-Server Namespace . . . . . . . . . . . . . 22 5. Locking and Multi-Server Namespace . . . . . . . . . . . . . 23
5.1. Changes from Replaced Sections . . . . . . . . . . . . . 22 5.1. Changes from Replaced Sections . . . . . . . . . . . . . 23
5.2. Lock State and Filesystem Transitions . . . . . . . . . . 23 5.2. Lock State and Filesystem Transitions . . . . . . . . . . 24
5.3. Migration and State . . . . . . . . . . . . . . . . . . . 23 5.3. Migration and State . . . . . . . . . . . . . . . . . . . 24
5.3.1. Migration and clientid's . . . . . . . . . . . . . . 24 5.3.1. Migration and clientid's . . . . . . . . . . . . . . 26
5.3.2. Migration and state owner information . . . . . . . . 26 5.3.2. Migration and state owner information . . . . . . . . 27
5.4. Replication and State . . . . . . . . . . . . . . . . . . 29 5.4. Replication and State . . . . . . . . . . . . . . . . . . 31
5.5. Notification of Migrated Lease . . . . . . . . . . . . . 30 5.5. Notification of Migrated Lease . . . . . . . . . . . . . 31
5.6. Migration and the Lease_time Attribute . . . . . . . . . 33 5.6. Migration and the Lease_time Attribute . . . . . . . . . 34
6. Server Implementation Considerations . . . . . . . . . . . . 33 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 . . . . . . . . . . . . . . . . . . . . 33 Filesystem Motion . . . . . . . . . . . . . . . . . . . . 34
6.2. Preventing Locking State Modification During Transfer . . 35 6.2. Preventing Locking State Modification During Transfer . . 36
7. Additional Changes . . . . . . . . . . . . . . . . . . . . . 38 7. Additional Changes . . . . . . . . . . . . . . . . . . . . . 39
7.1. Summary of Additional Changes from Previous Documents . . 38 7.1. Summary of Additional Changes from Previous Documents . . 39
7.2. NFS4ERR_CLID_INUSE definition . . . . . . . . . . . . . . 39 7.2. NFS4ERR_CLID_INUSE definition . . . . . . . . . . . . . . 40
7.3. NFS4ERR_DELAY return from RELEASE_LOCKOWNER . . . . . . . 39 7.3. NFS4ERR_DELAY return from RELEASE_LOCKOWNER . . . . . . . 40
7.4. Operation 35: SETCLIENTID - Negotiate Client ID . . . . . 40 7.4. Operation 35: SETCLIENTID - Negotiate Client ID . . . . . 41
7.5. Security Considerations revision . . . . . . . . . . . . 44 7.5. Security Considerations revision . . . . . . . . . . . . 45
8. Security Considerations . . . . . . . . . . . . . . . . . . . 44 8. Security Considerations . . . . . . . . . . . . . . . . . . . 45
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 44 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 45
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 45 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 46
11.1. Normative References . . . . . . . . . . . . . . . . . . 45 11.1. Normative References . . . . . . . . . . . . . . . . . . 46
11.2. Informative References . . . . . . . . . . . . . . . . . 45 11.2. Informative References . . . . . . . . . . . . . . . . . 46
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46
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 [RFC3530] and the one expected to become definitive (now in
[cur-rfc3530-bis]). Given this fact, one should take the current [cur-rfc3530-bis]). Given this fact, one should take the current
document into account when learning about NFSv4.0, particularly if document into account when learning about NFSv4.0, particularly if
one is concerned with issues that relate to: one is concerned with issues that relate to:
skipping to change at page 14, line 15 skipping to change at page 14, line 15
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.
o Within the uniform client id string approach, an nfs_client_id4 o Within the uniform client id string approach, an nfs_client_id4
designates a globally known client instance, so that the boot designates a globally known client instance, so that the boot
verifier should change if and only if a new client instance is verifier should change if and only if a new client instance is
created, typically as a result of a reboot. created, typically as a result of a reboot.
Clients using the uniform client id string approach are therefore
well advised to use a verifier established only once for each
reboot, typically the reboot time.
The following are advantages for the implementation of using the The following are advantages for the implementation of using the
uniform client id string approach: uniform client id string approach:
o Clients can take advantage of server trunking (and clustering with o Clients can take advantage of server trunking (and clustering with
single-server-equivalent semantics) to increase bandwidth or single-server-equivalent semantics) to increase bandwidth or
reliability. reliability.
o There are advantages in state management so that, for example, we o There are advantages in state management so that, for example, we
never have a delegation under one clientid revoked because of a never have a delegation under one clientid revoked because of a
reference to the same file from the same client under a different reference to the same file from the same client under a different
skipping to change at page 18, line 39 skipping to change at page 18, line 39
known IP addresses trunked with it. The IP address is marked as a known IP addresses trunked with it. The IP address is marked as a
lead IP address for a new server. A SETCLIENTID_CONFIRM is done lead IP address for a new server. A SETCLIENTID_CONFIRM is done
using XC and XV. using XC and XV.
o If a matching clientid4 is found which is marked unresolved, o If a matching clientid4 is found which is marked unresolved,
processing on the new IP address is suspended. In order to processing on the new IP address is suspended. In order to
simplify processing, there can only be one unresolved IP address simplify processing, there can only be one unresolved IP address
for any given clientid4. for any given clientid4.
o If one or more matching clientid4's is found, none of which is o If one or more matching clientid4's is found, none of which is
marked unresolved, the new IP address in entered and marked marked unresolved, the new IP address X is entered and marked
unresolved. After applying the steps below to each of the lead IP unresolved. A SETCLIENTID_CONFIRM is done to X using XC and XV.
addresses with a matching clientid4, the address will have been
resolved: It may been determined to be part of an already known After applying the steps below to each of the lead IP addresses
server as a new IP address to be added to an existing set of IP with a matching clientid4, the address will have been resolved: It
addresses for that server. Otherwise, it will be recognized as a may have been determined to be part of an already known server as
new server. At the point at which this determination is made, the a new IP address to be added to an existing set of IP addresses
for that server. Otherwise, it will be recognized as a new
server. At the point at which this determination is made, the
unresolved indication is cleared and any suspended SETCLIENTID unresolved indication is cleared and any suspended SETCLIENTID
processing is restarted processing is restarted
So for each lead IP address IPn with a clientid4 matching XC, the For each lead IP address IPn with a clientid4 matching XC, the
following steps are done. following steps are done. Because the RPC to do a SETCLIENTID could
take considerable time, it is desirable for the client to perform
these operations in parallel. Note that because the clientid4 is a
64-bit value, the number of such IP addresses that would need to be
tested is expected to be quite small, even when the client is
interacting with many NFSv4.0 servers. Thus, while parallel
processing is desirable, it is not necessary.
o If the principal for IPn does not match that for X, the IP address o If the principal for IPn does not match that for X, the IP address
is skipped, since it is impossible for IPn and X to be trunked in is skipped, since it is impossible for IPn and X to be trunked in
these circumstances. If the principal does match but the these circumstances. If the principal does match but the
authentication flavor does not, the authentication flavor already authentication flavor does not, the authentication flavor already
used should be used for address X as well. This will avoid any used should be used for address X as well. This will avoid any
possibility that NFS4ERR_CLID_INUSE will be returned for the possibility that NFS4ERR_CLID_INUSE will be returned for the
SETCLIENTID and SETCLIENTID_CONFIRM to be done below, as long as SETCLIENTID and SETCLIENTID_CONFIRM to be done below, as long as
the server(s) at IP addresses IPn and X are correctly implemented. the server(s) at IP addresses IPn and X are correctly implemented.
o A SETCLIENTID is done to update the callback parameters to reflect o A SETCLIENTID is done to update the callback parameters to reflect
the possibility that X will be marked as associated with the the possibility that X will be marked as associated with the
server whose lead IP address is IPn. The specific callback server whose lead IP address is IPn. The specific callback
parameters chosen, in terms of cb_client4 and callback_ident, are parameters chosen, in terms of cb_client4 and callback_ident, are
up to the client and should reflect its preferences as to callback up to the client and should reflect its preferences as to callback
handling for the common clientid, in the event that X and IPn are handling for the common clientid, in the event that X and IPn are
trunked together. So assume that we do that SETCLIENTID on IP trunked together. When we do a SETCLIENTID on IP address IPn, we
address IPn and get back a setclientid_confirm value (in the form get back a setclientid_confirm value (in the form of a verifier4),
of a verifier4) SCn. which we call SCn.
Note that the NFSv4.0 specification requires the server to make Note that the NFSv4.0 specification requires the server to make
sure that such verifiers are very unlikely to be regenerated. sure that such verifiers are very unlikely to be regenerated.
Given that it is already highly unlikely that the clientid XC is Given that it is already highly unlikely that the clientid XC is
duplicated by distinct servers, the probability that Sc is duplicated by distinct servers, the probability that SCn is
duplicated as well has to be considered vanishingly small. Note duplicated as well has to be considered vanishingly small. Note
also that the callback update procedure can be repeated multiple also that the callback update procedure can be repeated multiple
times to reduce the probability of spurious matches further. times to reduce the probability of spurious matches further.
o Note that we don't want this to happen if address X is not o We save the setclientid_confirm value SCn for later use in
associated with this server. So we do a SETCLIENTID_CONFIRM on confirming the SETCLIENTID done to IPn.
address X using the setclientid_confirm value SCn.
o If the setclientid_confirm value generated on X is accepted on Once the SCn values are gathered up by the procedure above, they are
IPn, then X and IPn are recognized as connected to the same server each tested by being used as the verifier for a SETCLIENTID_CONFIRM
and the entry for X is marked as associated with IPn. The entry operation directed to the original IP address X, whose trunking
is now resolved and processing can be restarted for IP addresses relationships are to be determined. These RPC operations may be done
whose clientid4 matched XC but whose resolution had been deferred. in parallel.
o If the confirm value generated on IPn is not accepted on X, then X There are a number of things that should be noted at this point.
and IPn are distinct and the callback update will not be
confirmed. So we go on to the next IPn, until we run out of them.
If it happens that we run out of potential matches, then we can
treat X as connected to a distinct server and then update and
confirm its callback parameters on that basis.
Note here that we may set a number of possible values for the o That the SETCLIENTID operations done on the various IPn addresses
callback parameters to be used for XC, one for the possibility that X in the procedure above will never be confirmed by
is untrunked, and others for each potential match with an existing SETCLIENTID_CONFIRM operations directed to the various IPn
IPn. Although there are multiple such updates at most one will be addresses. If these callback updates are to be confirmed, they
confirmed and, if X is untrunked, its original callback parameters will be confirmed by SETCLIENTID_CONFIRM operations directed at
will be put in effect by its SETCLIENTID_CONFIRM. the original IP address X, which can only happen if SCn was
generated by an IPn which trunked with X, allowing the SETCLIENTID
to be successfully confirmed, and allowing us to infer the
existence of that trunking relationship.
o That the number of successful SETCLIENTID_CONFIRM operations done
should never be more than one. If both SCn and SCm are accepted
by X, then it indicates that both IPn and IPm are trunked with X,
but that is only possible if IPn and IPm are trunked together.
Since these two addresses were earlier recognized as not trunked
together, this should be impossible, if the servers in question
are implemented correctly.
Further processing depends on the success or failure of the various
SETCLIENTD_CONFIRM operations done in the step above.
o If the setclientid_confirm value generated by a particular IPn is
accepted on X then X and IPn are recognized as connected to the
same server and the entry for X is marked as associated with IPn.
o If none of the confirm operations are accepted, then X is
recognized as a distinct server. Its callback parameters will
remain as the ones established by the original SETCLIENTID.
In either of the cases, the entry is considered resolved and
processing can be restarted for IP addresses whose clientid4 matched
XC but whose resolution had been deferred.
The procedure described above must be performed so as to exclude the The procedure described above must be performed so as to exclude the
possibility that multiple SETCLIENTID's, done to different server IP possibility that multiple SETCLIENTID's, done to different server IP
addresses and returning the same clientid4 might "race" in such a addresses and returning the same clientid4 might "race" in such a
fashion that there is no explicit determination of whether they fashion that there is no explicit determination of whether they
correspond to the same server. The following possibilities for correspond to the same server. The following possibilities for
serialization are all valid and implementers may choose among them serialization are all valid and implementers may choose among them
based on a tradeoff between performance and complexity. They are based on a tradeoff between performance and complexity. They are
listed in order of increasing parallelism: listed in order of increasing parallelism:
skipping to change at page 20, line 36 skipping to change at page 21, line 15
This prevents the races mentioned above, without adding to delay This prevents the races mentioned above, without adding to delay
except when trunking determination is common. except when trunking determination is common.
o One might avoid much of the serialization implied above, by o One might avoid much of the serialization implied above, by
allowing trunking determination for distinct clientid4 values to allowing trunking determination for distinct clientid4 values to
happen in parallel, with serialization of trunking determination happen in parallel, with serialization of trunking determination
happening independently for each distinct clientid4 value. happening independently for each distinct clientid4 value.
The procedure above has made no explicit mention of the possibility The procedure above has made no explicit mention of the possibility
that server reboot can occur at any time. To address this that server reboot can occur at any time. To address this
possibility the client should periodically use the clientid4 XC in possibility the client should make sure the following steps are
RENEW operations, directed to both the IP address X and the current taken:
lead IP address that is currently being tested for identity.
o When XC becomes invalid on X, the resolution process should be
terminated, subject to being redone later. Before redoing the
resolution, XC should be checked on all the lead IP addresses on
which it was valid. Once a new clientid4 is established on any
servers on which XC became invalid, a new clientid4 can be
established on X and the resolution process for X can be
restarted.
o When XC does not becomes invalid on X, but becomes invalid on the o When a SETCLIENTID_CONFIRM is rejected by a given IPn, the client
current IPn being tested, it should be concluded that X and IPn do should be aware of the possibility that the rejection is due to XC
not match and that it is time to advance to the next IPn, if any. (rather than XV) being invalid. This situation can be addressed
by doing a RENEW specifying XC directed to the IP address X. If
that operation succeeds, then the rejection is to be acted on
normally since either XV is invalid on IPn or XC has become
invalid on IPn while it is valid on X, showing that IPn and X are
not trunked. If, on the other hand, XC is not valid on X, then
the trunking detection process should be restarted once a new
clientid is established on X.
o In the event of a reboot detected on any server lead IP, the set o In the event of a reboot detected on any server lead IP, the set
of IP addresses associated with the server should not change and of IP addresses associated with the server should not change and
state should be re-established for the lease as a whole, using all state should be re-established for the lease as a whole, using all
available connected server IP addresses. It is prudent to verify available connected server IP addresses. It is prudent to verify
connectivity by doing a RENEW using the new clientid4 on each such connectivity by doing a RENEW using the new clientid4 on each such
server address before using it, however. server address before using it, however.
If we have run out of IPn's without finding a matching server, X is Another situation not discussed explicitly above is the possibility
considered as having no existing known IP addresses trunked with it. that a SETCLIENTID done to one of the IPn addresses might take so
The IP address is marked as a lead IP address for a new server. A long that it is necessary to time out the operation, to prevent
SETCLIENTID_CONFIRM is done using XC and XV. unacceptably delaying the MOUNT operation. One simple possibility is
to simply fail the MOUNT at this point. Because the average number
of IP addresses that might have to be tested is quite small, this
will not greatly increase the probability of MOUNT failure. Other
possible approaches are:
o If the IPn has sufficient state in existence, the existing
stateids and sequence values might be validated by being used on
IP address X. In the event of success, X and IPn should be
considered trunked together.
What constitutes "sufficient" state in this context is an
implementation decision which is affected by the implementer's
willingness to fail the MOUNT in an uncertain case, and the
strength of the state verification procedure implemented.
o If IPn has no locking state in existence, X could be recorded as a
lead IP address on a provisional basis, subject to trunking being
tested again, once IPn starts becoming responsive. To avoid
confusion between IPn and X, and the need to merge distinct state
corpora for X and IPn at a later point, this retest of trunking
should occur after RENEWs on IPn are responded to and before
establishing any new state for either IPn as a separate server or
for IPn considered as a server address trunked with X.
o The client locking-related code could be made more tolerant of
what would otherwise be considered anomalous results due to an
unrecognized trunking relationship. The client could use the
appearance of behavior explainable by a previously unknown
trunking relationship as the cue to consider the addresses as
trunked.
This choice has a lot of complexity associated with it, and it is
likely that few implementations will use it. When the set of
locking state on IPn is small (e.g. a single stateid) but not
empty, most client implementations are likely to either fail the
MOUNT or implement a more stringent verification procedure using
the existing stateid on IPn as a basis to generate further state
as raw material for the trunking verification process.
4.9. Client id string construction details 4.9. Client id string construction details
This section gives more detailed guidance on client id construction. This section gives more detailed guidance on client id construction.
Note that among the items suggested for inclusion, there are many Note that among the items suggested for inclusion, there are many
that may conceivably change. In order for the client id string to that may conceivably change. In order for the client id string to
remain valid in such circumstances, the client should either: remain valid in such circumstances, the client should either:
o Use a saved copy of such value, rather than the changeable value o Use a saved copy of such value, rather than the changeable value
itself. itself.
skipping to change at page 40, line 17 skipping to change at page 41, line 17
Thus, a client that is prepared to receive NFS4ERR_MOVED after Thus, a client that is prepared to receive NFS4ERR_MOVED after
creating state associated with a given filesystem, it also needs creating state associated with a given filesystem, it also needs
to be prepared to receive NFS4ERR_DELAY in response to to be prepared to receive NFS4ERR_DELAY in response to
RELEASE_LOCKOWNER, if it has used that owner in connection with a RELEASE_LOCKOWNER, if it has used that owner in connection with a
file on that filesystem. file on that filesystem.
7.4. Operation 35: SETCLIENTID - Negotiate Client ID 7.4. Operation 35: SETCLIENTID - Negotiate Client ID
7.4.1. SYNOPSIS 7.4.1. SYNOPSIS
client, callback, callback_ident -> clientid, setclientid_confirm client, callback, callback_ident -> clientid, setclientid_confirm
7.4.2. ARGUMENT 7.4.2. ARGUMENT
struct SETCLIENTID4args { struct SETCLIENTID4args {
nfs_client_id4 client; nfs_client_id4 client;
cb_client4 callback; cb_client4 callback;
uint32_t callback_ident; uint32_t callback_ident;
}; };
7.4.3. RESULT 7.4.3. RESULT
skipping to change at page 45, line 29 skipping to change at page 46, line 27
[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] [cur-rfc3530-bis]
Haynes, T., Ed. and D. Noveck, Ed., "Network File System Haynes, T., Ed. and D. Noveck, Ed., "Network File System
(NFS) Version 4 Protocol", 2013, <http://www.ietf.org/id/ (NFS) Version 4 Protocol", 2014, <http://www.ietf.org/id/
draft-ietf-nfsv4-rfc3530bis-26.txt>. draft-ietf-nfsv4-rfc3530bis-32.txt>.
Work in progress. 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 ", 2012, <http://www.ietf.org/id/draft- issues to resolve", 2014, <http://www.ietf.org/id/
ietf-nfsv4-migration-issues-03.txt>. draft-ietf-nfsv4-migration-issues-05.txt>.
Work in progress. Work in progress.
Authors' Addresses Authors' Addresses
David Noveck (editor) David Noveck (editor)
EMC Corporation 26 Locust Avenue
228 South Street Lexington, MA 02421
Hopkinton, MA 01748
US US
Phone: +1 508 249 5748 Phone: +1 781 572 8038
Email: david.noveck@emc.com Email: davenoveck@gmail.com
Piyush Shivam Piyush Shivam
Oracle Corporation Oracle Corporation
5300 Riata Park Ct. 5300 Riata Park Ct.
Austin, TX 78727 Austin, TX 78727
US US
Phone: +1 512 401 1019 Phone: +1 512 401 1019
Email: piyush.shivam@oracle.com Email: piyush.shivam@oracle.com
Charles Lever Charles Lever
 End of changes. 26 change blocks. 
94 lines changed or deleted 161 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/