draft-ietf-nfsv4-rfc5661sesqui-msns-02.txt   draft-ietf-nfsv4-rfc5661sesqui-msns-03.txt 
NFSv4 D. Noveck, Ed. NFSv4 D. Noveck, Ed.
Internet-Draft NetApp Internet-Draft NetApp
Obsoletes: 5661 (if approved) C. Lever Obsoletes: 5661 (if approved) C. Lever
Intended status: Standards Track ORACLE Intended status: Standards Track ORACLE
Expires: April 5, 2020 October 3, 2019 Expires: April 22, 2020 October 20, 2019
Network File System (NFS) Version 4 Minor Version 1 Protocol Network File System (NFS) Version 4 Minor Version 1 Protocol
draft-ietf-nfsv4-rfc5661sesqui-msns-02 draft-ietf-nfsv4-rfc5661sesqui-msns-03
Abstract Abstract
This document describes the Network File System (NFS) version 4 minor This document describes the Network File System (NFS) version 4 minor
version 1, including features retained from the base protocol (NFS version 1, including features retained from the base protocol (NFS
version 4 minor version 0, which is specified in RFC 7530) and version 4 minor version 0, which is specified in RFC 7530) and
protocol extensions made subsequently. The later minor version has protocol extensions made subsequently. The later minor version has
no dependencies on NFS version 4 minor version 0, and is considered a no dependencies on NFS version 4 minor version 0, and is considered a
separate protocol. separate protocol.
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 5, 2020. This Internet-Draft will expire on April 22, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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 7, line 51 skipping to change at page 7, line 51
1. Introduction 1. Introduction
1.1. Introduction to this Update 1.1. Introduction to this Update
The revised description of the NFS version 4 minor version 1 The revised description of the NFS version 4 minor version 1
(NFSv4.1) protocol presented in this update is necessary to enable (NFSv4.1) protocol presented in this update is necessary to enable
full use of trunking in connection with multi-server namespace full use of trunking in connection with multi-server namespace
features and to enable the use of transparent state migration in features and to enable the use of transparent state migration in
connection with NFSv4.1. This document is in the form of an updated connection with NFSv4.1. This document is in the form of an updated
description of the NFS 4.1 protocol previously defined in RFC5661 description of the NFS 4.1 protocol previously defined in RFC5661
[60]. RFC5661 is obsoleted by this document. However, the update [62]. RFC5661 is obsoleted by this document. However, the update
has a limited scope and is focused on enabling full use of trunking has a limited scope and is focused on enabling full use of trunking
and transparent state migration. The need for these changes is and transparent state migration. The need for these changes is
discussed in Appendix A. Appendix B describes the specific changes discussed in Appendix A. Appendix B describes the specific changes
made to arrive at the current text. made to arrive at the current text.
This limited scope update is applied to the main NFSv4.1 RFC with the This limited scope update is applied to the main NFSv4.1 RFC with the
intention of providing an authoritative complete specification, the intention of providing an authoritative complete specification, the
motivation for which is discussed in [I.D-roach-bis-documents], motivation for which is discussed in [I.D-roach-bis-documents],
addressing the issues within the scope of the update. However, it addressing the issues within the scope of the update. However, it
will not address issues that are known but outside of this limited will not address issues that are known but outside of this limited
scope as could expected by a full update of the protocol. Below are scope as could expected by a full update of the protocol. Below are
some areas which are known to need addressing in a future update of some areas which are known to need addressing in a future update of
the protocol. the protocol.
o Work would have to be done with regard to RFC8178 [61] which o Work would have to be done with regard to RFC8178 [63] which
establishes NFSv4-wide versioning rules. As RFC5661 is curretly establishes NFSv4-wide versioning rules. As RFC5661 is curretly
inconsistent with this document, changes are needed in order to inconsistent with this document, changes are needed in order to
arrive at a situation in which there would be no need for RFC8178 arrive at a situation in which there would be no need for RFC8178
to update the NFSv4.1 specfication. to update the NFSv4.1 specfication.
o Work would have to be done with regard to RFC8434 [64], which o Work would have to be done with regard to RFC8434 [66], which
establishes the requirements for pNFS layout types, which are not establishes the requirements for pNFS layout types, which are not
clearly defined in RFC5661. When that work is done and the clearly defined in RFC5661. When that work is done and the
resulting documents approved, the new NFSv4.1 specfication resulting documents approved, the new NFSv4.1 specfication
document will provide a clear set of requirements for layout types document will provide a clear set of requirements for layout types
and a description of the file layout type that conforms to those and a description of the file layout type that conforms to those
requirements. Other layout types will have their own specfication requirements. Other layout types will have their own specfication
documents that conforms to those requirements as well. documents that conforms to those requirements as well.
o Work would have to be done to address many erratas relevant to RFC o Work would have to be done to address many erratas relevant to RFC
5661, other than errata 2006 which is addressed in this document. 5661, other than errata 2006 [60], which is addressed in this
That errata was not deferrable because of the interaction of the document. That errata was not deferrable because of the
changes suggested in that errata and handling of state and session interaction of the changes suggested in that errata and handling
migration. The erratas that have been deferred include changes of state and session migration. The erratas that have been
originally suggested by a particular errata, which change deferred include changes originally suggested by a particular
consensus decisions made in RFC 5661, which need to be changed to errata, which change consensus decisions made in RFC 5661, which
ensure compatibility with existing implementations that do not need to be changed to ensure compatibility with existing
follow the handling delineated in RFC 5661. Note that it is implementations that do not follow the handling delineated in RFC
expected that such erratas will remain relevant to implementers 5661. Note that it is expected that such erratas will remain
and the authors of an eventual rfc5661bis, despite the fact that relevant to implementers and the authors of an eventual
this document, when approved, will obsolete RFC 5661. rfc5661bis, despite the fact that this document, when approved,
will obsolete RFC 5661.
o There is a need for a new approach to the description of o There is a need for a new approach to the description of
internationalization since the current internationalization internationalization since the current internationalization
section (Section 14) has never been implemented and does not meet section (Section 14) has never been implemented and does not meet
the needs of the NFSv4 protocol. Possible solutions are to create the needs of the NFSv4 protocol. Possible solutions are to create
a new internationalization section modeled on that in [62] or to a new internationalization section modeled on that in [64] or to
create a new document describing internationalization for all create a new document describing internationalization for all
NFSv4 minor versions and reference that document in the RFCs NFSv4 minor versions and reference that document in the RFCs
defining both NFSv4.0 and NFSv4.1. defining both NFSv4.0 and NFSv4.1.
o There is a need for a revised treatment of security in NFSv4.1. o There is a need for a revised treatment of security in NFSv4.1.
The issues with the existing treatment are discussed in The issues with the existing treatment are discussed in
Appendix C. Appendix C.
Until the above work is done, there will not be a consistent set of Until the above work is done, there will not be a consistent set of
documents providing a description of the NFSv4.1 protocol and any documents providing a description of the NFSv4.1 protocol and any
full description would involve documents updating other documents full description would involve documents updating other documents
within the specification, just as RFC 8434 [64] and RFC 8178 [61] do within the specification, just as RFC 8434 [66] and RFC 8178 [63] do
today. today.
1.2. The NFS Version 4 Minor Version 1 Protocol 1.2. The NFS Version 4 Minor Version 1 Protocol
The NFS version 4 minor version 1 (NFSv4.1) protocol is the second The NFS version 4 minor version 1 (NFSv4.1) protocol is the second
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 now described in RFC 7530 [62]. It generally version, NFSv4.0, is now described in RFC 7530 [64]. It generally
follows the guidelines for minor versioning that are listed in follows the guidelines for minor versioning that are listed in
Section 10 of RFC 3530. However, it diverges from guidelines 11 ("a Section 10 of RFC 3530. However, it diverges from guidelines 11 ("a
client and server that support minor version X must support minor client and server that support minor version X must support minor
versions 0 through X-1") and 12 ("no new features may be introduced versions 0 through X-1") and 12 ("no new features may be introduced
as mandatory in a minor version"). These divergences are due to the as mandatory in a minor version"). These divergences are due to the
introduction of the sessions model for managing non-idempotent introduction of the sessions model for managing non-idempotent
operations and the RECLAIM_COMPLETE operation. These two new operations and the RECLAIM_COMPLETE operation. These two new
features are infrastructural in nature and simplify implementation of features are infrastructural in nature and simplify implementation of
existing and other new features. Making them anything but REQUIRED existing and other new features. Making them anything but REQUIRED
would add undue complexity to protocol definition and implementation. would add undue complexity to protocol definition and implementation.
skipping to change at page 228, line 6 skipping to change at page 228, line 6
used together to access a single session. used together to access a single session.
o Trunking discovery is a process by which a client using one o Trunking discovery is a process by which a client using one
network address can obtain other addresses that are connected to network address can obtain other addresses that are connected to
the same server. Typically, it builds on a trunking detection the same server. Typically, it builds on a trunking detection
facility by providing one or more methods by which candidate facility by providing one or more methods by which candidate
addresses are made available to the client who can then use addresses are made available to the client who can then use
trunking detection to appropriately filter them. trunking detection to appropriately filter them.
Despite the support for trunking detection there was no Despite the support for trunking detection there was no
description of trunking discovery provided in RFC5661 [60], making description of trunking discovery provided in RFC5661 [62], making
it necessary to provide those means in this document. it necessary to provide those means in this document.
The combination of a server network address and a particular The combination of a server network address and a particular
connection type to be used by a connection is referred to as a connection type to be used by a connection is referred to as a
"server endpoint". Although using different connection types may "server endpoint". Although using different connection types may
result in different ports being used, the use of different ports by result in different ports being used, the use of different ports by
multiple connections to the same network address is not the essence multiple connections to the same network address is not the essence
of the distinction between the two endpoints used. of the distinction between the two endpoints used.
Two network addresses connected to the same server are said to be Two network addresses connected to the same server are said to be
skipping to change at page 230, line 19 skipping to change at page 230, line 19
able to use client ID trunking, but will only be able to use able to use client ID trunking, but will only be able to use
session trunking if the paths are also session-trunkable. session trunking if the paths are also session-trunkable.
o Two file system location elements are said to be session-trunkable o Two file system location elements are said to be session-trunkable
if they specify the same fs name and the location addresses are if they specify the same fs name and the location addresses are
such that the location addresses are session-trunkable. When the such that the location addresses are session-trunkable. When the
corresponding network paths are used, the client will be able to corresponding network paths are used, the client will be able to
able to use either client ID trunking or session trunking. able to use either client ID trunking or session trunking.
Discussion of the term "replica" is complicated by the fact that the Discussion of the term "replica" is complicated by the fact that the
term was used in RFC5661 [60], with a meaning different from that in term was used in RFC5661 [62], with a meaning different from that in
this document. In short, in [60] each replica is identified by a this document. In short, in [62] each replica is identified by a
single network access path while, in the current document a set of single network access path while, in the current document a set of
network access paths which have server-trunkable network addresses network access paths which have server-trunkable network addresses
and the same root-relative file system pathname is considered to be a and the same root-relative file system pathname is considered to be a
single replica with multiple network access paths. single replica with multiple network access paths.
Each set of server-trunkable location elements defines a set of Each set of server-trunkable location elements defines a set of
available network access paths to a particular file system. When available network access paths to a particular file system. When
there are multiple such file systems, each of which contains the same there are multiple such file systems, each of which contains the same
data, these file systems are considered replicas of one another. data, these file systems are considered replicas of one another.
Logically, such replication is symmetric, since the fs currently in Logically, such replication is symmetric, since the fs currently in
skipping to change at page 239, line 47 skipping to change at page 239, line 47
located on one server with a file system located on another server. located on one server with a file system located on another server.
When this includes the use of pure referrals, servers are provided a When this includes the use of pure referrals, servers are provided a
way of placing a file system in a location within the namespace way of placing a file system in a location within the namespace
essentially without respect to its physical location on a particular essentially without respect to its physical location on a particular
server. This allows a single server or a set of servers to present a server. This allows a single server or a set of servers to present a
multi-server namespace that encompasses file systems located on a multi-server namespace that encompasses file systems located on a
wider range of servers. Some likely uses of this facility include wider range of servers. Some likely uses of this facility include
establishment of site-wide or organization-wide namespaces, with the establishment of site-wide or organization-wide namespaces, with the
eventual possibility of combining such together into a truly global eventual possibility of combining such together into a truly global
namespace, such as the one provided by AFS (the Andrew File System) namespace, such as the one provided by AFS (the Andrew File System)
[TBD: appropriate reference needed] [61].
Referrals occur when a client determines, upon first referencing a Referrals occur when a client determines, upon first referencing a
position in the current namespace, that it is part of a new file position in the current namespace, that it is part of a new file
system and that the file system is absent. When this occurs, system and that the file system is absent. When this occurs,
typically upon receiving the error NFS4ERR_MOVED, the actual location typically upon receiving the error NFS4ERR_MOVED, the actual location
or locations of the file system can be determined by fetching a or locations of the file system can be determined by fetching a
locations attribute. locations attribute.
The file system location attribute may designate a single file system The file system location attribute may designate a single file system
location or multiple file system locations, to be selected based on location or multiple file system locations, to be selected based on
skipping to change at page 246, line 13 skipping to change at page 246, line 13
Section 11.12. Section 11.12.
o The servers' (source and destination) responsibilities in o The servers' (source and destination) responsibilities in
effecting Transparent Migration of locking and session state are effecting Transparent Migration of locking and session state are
discussed in Section 11.13. discussed in Section 11.13.
11.10.1. File System Transitions and Simultaneous Access 11.10.1. File System Transitions and Simultaneous Access
The fs_locations_info attribute (described in Section 11.16) may The fs_locations_info attribute (described in Section 11.16) may
indicate that two replicas may be used simultaneously, (see indicate that two replicas may be used simultaneously, (see
Section 11.7.2.1 of RFC5661 [60] for details). Although situations Section 11.7.2.1 of RFC5661 [62] for details). Although situations
in which multiple replicas may be accessed simultaneously are in which multiple replicas may be accessed simultaneously are
somewhat similar to those in which a single replica is accessed by somewhat similar to those in which a single replica is accessed by
multiple network addresses, there are important differences, since multiple network addresses, there are important differences, since
locking state is not shared among multiple replicas. locking state is not shared among multiple replicas.
Because of this difference in state handling, many clients will not Because of this difference in state handling, many clients will not
have the ability to take advantage of the fact that such replicas have the ability to take advantage of the fact that such replicas
represent the same data. Such clients will not be prepared to use represent the same data. Such clients will not be prepared to use
multiple replicas simultaneously but will access each file system multiple replicas simultaneously but will access each file system
using only a single replica, although the replica selected might make using only a single replica, although the replica selected might make
skipping to change at page 254, line 7 skipping to change at page 254, line 7
potentially conflicting non-reclaimed locks are granted. potentially conflicting non-reclaimed locks are granted.
11.11. Transferring State upon Migration 11.11. Transferring State upon Migration
When the transition is a result of a server-initiated decision to When the transition is a result of a server-initiated decision to
transition access and the source and destination servers have transition access and the source and destination servers have
implemented appropriate co-operation, it is possible to: implemented appropriate co-operation, it is possible to:
o Transfer locking state from the source to the destination server, o Transfer locking state from the source to the destination server,
in a fashion similar to that provided by Transparent State in a fashion similar to that provided by Transparent State
Migration in NFSv4.0, as described in [63]. Server Migration in NFSv4.0, as described in [65]. Server
responsibilities are described in Section 11.13.2. responsibilities are described in Section 11.13.2.
o Transfer session state from the source to the destination server. o Transfer session state from the source to the destination server.
Server responsibilities in effecting such a transfer are described Server responsibilities in effecting such a transfer are described
in Section 11.13.3. in Section 11.13.3.
The means by which the client determines which of these transfer The means by which the client determines which of these transfer
events has occurred are described in Section 11.12. events has occurred are described in Section 11.12.
11.11.1. Transparent State Migration and pNFS 11.11.1. Transparent State Migration and pNFS
skipping to change at page 267, line 32 skipping to change at page 267, line 32
granted until the client does a RECLAIM_COMPLETE, after reclaiming granted until the client does a RECLAIM_COMPLETE, after reclaiming
the locks it had, with the exception of reclaims denied because the locks it had, with the exception of reclaims denied because
they were attempts to reclaim locks that had been lost. they were attempts to reclaim locks that had been lost.
o Implement Transparent State Migration, except for the lock with o Implement Transparent State Migration, except for the lock with
the conflicting stateid. In this case, the client will be aware the conflicting stateid. In this case, the client will be aware
of a lost lock (through the SEQ4_STATUS flags) and be allowed to of a lost lock (through the SEQ4_STATUS flags) and be allowed to
reclaim it. reclaim it.
When transferring state between the source and destination, the When transferring state between the source and destination, the
issues discussed in Section 7.2 of [63] must still be attended to. issues discussed in Section 7.2 of [65] must still be attended to.
In this case, the use of NFS4ERR_DELAY may still necessary in In this case, the use of NFS4ERR_DELAY may still necessary in
NFSv4.1, as it was in NFSv4.0, to prevent locking state changing NFSv4.1, as it was in NFSv4.0, to prevent locking state changing
while it is being transferred. See Section 15.1.1.3 for information while it is being transferred. See Section 15.1.1.3 for information
about appropriate client retry approaches in the event that about appropriate client retry approaches in the event that
NFS4ERR_DELAY is returned. NFS4ERR_DELAY is returned.
There are a number of important differences in the NFS4.1 context: There are a number of important differences in the NFS4.1 context:
o The absence of RELEASE_LOCKOWNER means that the one case in which o The absence of RELEASE_LOCKOWNER means that the one case in which
an operation could not be deferred by use of NFS4ERR_DELAY no an operation could not be deferred by use of NFS4ERR_DELAY no
longer exists. longer exists.
o Sequencing of operations is no longer done using owner-based o Sequencing of operations is no longer done using owner-based
operation sequences numbers. Instead, sequencing is session- operation sequences numbers. Instead, sequencing is session-
based based
As a result, when sessions are not transferred, the techniques As a result, when sessions are not transferred, the techniques
discussed in Section 7.2 of [63] are adequate and will not be further discussed in Section 7.2 of [65] are adequate and will not be further
discussed. discussed.
11.13.3. Server Responsibilities in Effecting Session Transfer 11.13.3. Server Responsibilities in Effecting Session Transfer
The basic responsibility of the source server in effecting session The basic responsibility of the source server in effecting session
transfer is to make available to the destination server a description transfer is to make available to the destination server a description
of the current state of each slot with the session, including: of the current state of each slot with the session, including:
o The last sequence value received for that slot. o The last sequence value received for that slot.
skipping to change at page 285, line 31 skipping to change at page 285, line 31
representing the same data, are such that 8 bits provide a quite representing the same data, are such that 8 bits provide a quite
acceptable range of values. Even where there might be more than acceptable range of values. Even where there might be more than
256 such file system instances, having more than 256 distinct 256 such file system instances, having more than 256 distinct
classes or priorities is unlikely. classes or priorities is unlikely.
o Explicit definition of the various specific data items within XDR o Explicit definition of the various specific data items within XDR
would limit expandability in that any extension within would would limit expandability in that any extension within would
require yet another attribute, leading to specification and require yet another attribute, leading to specification and
implementation clumsiness. In the context of the NFSv4 extension implementation clumsiness. In the context of the NFSv4 extension
model in effect at the time fs_locations_info was designed (i.e. model in effect at the time fs_locations_info was designed (i.e.
that described in RFC5661 [60]), this would necessitate a new that described in RFC5661 [62]), this would necessitate a new
minor version to effect any Standards Track extension to the data minor version to effect any Standards Track extension to the data
in in fls_info. in in fls_info.
The set of fls_info data is subject to expansion in a future minor The set of fls_info data is subject to expansion in a future minor
version, or in a Standards Track RFC, within the context of a single version, or in a Standards Track RFC, within the context of a single
minor version. The server SHOULD NOT send and the client MUST NOT minor version. The server SHOULD NOT send and the client MUST NOT
use indices within the fls_info array or flag bits that are not use indices within the fls_info array or flag bits that are not
defined in Standards Track RFCs. defined in Standards Track RFCs.
In light of the new extension model defined in RFC8178 [61] and the In light of the new extension model defined in RFC8178 [63] and the
fact that the individual items within fls_info are not explicitly fact that the individual items within fls_info are not explicitly
referenced in the XDR, the following practices should be followed referenced in the XDR, the following practices should be followed
when extending or otherwise changing the structure of the data when extending or otherwise changing the structure of the data
returned in fls_info within the scope of a single minor version. returned in fls_info within the scope of a single minor version.
o All extensions need to be described by Standards Track documents. o All extensions need to be described by Standards Track documents.
There is no need for such documents to be marked as updating There is no need for such documents to be marked as updating
RFC5661 [60] or this document. RFC5661 [62] or this document.
o It needs to be made clear whether the information in any added o It needs to be made clear whether the information in any added
data items applies to the replica specified by the entry or to the data items applies to the replica specified by the entry or to the
specific network paths specified in the entry. specific network paths specified in the entry.
o There needs to be a reliable way defined to determine whether the o There needs to be a reliable way defined to determine whether the
server is aware of the extension. This may be based on the length server is aware of the extension. This may be based on the length
field of the fls_info array, but it is more flexible to provide field of the fls_info array, but it is more flexible to provide
fs-scope or server-scope attributes to indicate what extensions fs-scope or server-scope attributes to indicate what extensions
are provided. are provided.
skipping to change at page 596, line 47 skipping to change at page 596, line 47
These two may be done in any order as long as all necessary lock These two may be done in any order as long as all necessary lock
reclaims have been done before issuing either of them. reclaims have been done before issuing either of them.
Any locks not reclaimed at the point at which RECLAIM_COMPLETE is Any locks not reclaimed at the point at which RECLAIM_COMPLETE is
done become non-reclaimable. The client MUST NOT attempt to reclaim done become non-reclaimable. The client MUST NOT attempt to reclaim
them, either during the current server instance or in any subsequent them, either during the current server instance or in any subsequent
server instance, or on another server to which responsibility for server instance, or on another server to which responsibility for
that file system is transferred. If the client were to do so, it that file system is transferred. If the client were to do so, it
would be violating the protocol by representing itself as owning would be violating the protocol by representing itself as owning
locks that it does not own, and so has no right to reclaim. See locks that it does not own, and so has no right to reclaim. See
Section 8.4.3 of [60] for a discussion of edge conditions related to Section 8.4.3 of [62] for a discussion of edge conditions related to
lock reclaim. lock reclaim.
By sending a RECLAIM_COMPLETE, the client indicates readiness to By sending a RECLAIM_COMPLETE, the client indicates readiness to
proceed to do normal non-reclaim locking operations. The client proceed to do normal non-reclaim locking operations. The client
should be aware that such operations may temporarily result in should be aware that such operations may temporarily result in
NFS4ERR_GRACE errors until the server is ready to terminate its grace NFS4ERR_GRACE errors until the server is ready to terminate its grace
period. period.
18.51.4. IMPLEMENTATION 18.51.4. IMPLEMENTATION
skipping to change at page 647, line 9 skipping to change at page 647, line 9
Negotiation for WebNFS", RFC 2755, January 2000. Negotiation for WebNFS", RFC 2755, January 2000.
[58] Narten, T. and H. Alvestrand, "Guidelines for Writing an [58] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[59] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- [59] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, February Hashing for Message Authentication", RFC 2104, February
1997. 1997.
[60] Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed., [60] Eisler, M., "Errata 2006 for RFC 5661", January 2010,
<https://www.rfc-editor.org/errata_search.php?eid=2006>.
[61] Spasojevic, M. and M. Satayanarayanan, "An Empirical Study
of a Wide-Area Distributed File System", May 1996,
<https://www.cs.cmu.edu/~satya/docdir/spasojevic-tocs-afs-
measurement-1996.pdf>.
[62] Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed.,
"Network File System (NFS) Version 4 Minor Version 1 "Network File System (NFS) Version 4 Minor Version 1
Protocol", RFC 5661, DOI 10.17487/RFC5661, January 2010, Protocol", RFC 5661, DOI 10.17487/RFC5661, January 2010,
<https://www.rfc-editor.org/info/rfc5661>. <https://www.rfc-editor.org/info/rfc5661>.
[61] Noveck, D., "Rules for NFSv4 Extensions and Minor [63] Noveck, D., "Rules for NFSv4 Extensions and Minor
Versions", RFC 8178, DOI 10.17487/RFC8178, July 2017, Versions", RFC 8178, DOI 10.17487/RFC8178, July 2017,
<https://www.rfc-editor.org/info/rfc8178>. <https://www.rfc-editor.org/info/rfc8178>.
[62] Haynes, T., Ed. and D. Noveck, Ed., "Network File System [64] Haynes, T., Ed. and D. Noveck, Ed., "Network File System
(NFS) Version 4 Protocol", RFC 7530, DOI 10.17487/RFC7530, (NFS) Version 4 Protocol", RFC 7530, DOI 10.17487/RFC7530,
March 2015, <https://www.rfc-editor.org/info/rfc7530>. March 2015, <https://www.rfc-editor.org/info/rfc7530>.
[63] Noveck, D., Ed., Shivam, P., Lever, C., and B. Baker, [65] Noveck, D., Ed., Shivam, P., Lever, C., and B. Baker,
"NFSv4.0 Migration: Specification Update", RFC 7931, "NFSv4.0 Migration: Specification Update", RFC 7931,
DOI 10.17487/RFC7931, July 2016, DOI 10.17487/RFC7931, July 2016,
<https://www.rfc-editor.org/info/rfc7931>. <https://www.rfc-editor.org/info/rfc7931>.
[64] Haynes, T., "Requirements for Parallel NFS (pNFS) Layout [66] Haynes, T., "Requirements for Parallel NFS (pNFS) Layout
Types", RFC 8434, DOI 10.17487/RFC8434, August 2018, Types", RFC 8434, DOI 10.17487/RFC8434, August 2018,
<https://www.rfc-editor.org/info/rfc8434>. <https://www.rfc-editor.org/info/rfc8434>.
[65] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an [67] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
2014, <https://www.rfc-editor.org/info/rfc7258>. 2014, <https://www.rfc-editor.org/info/rfc7258>.
[66] Rescorla, E. and B. Korver, "Guidelines for Writing RFC [68] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552, Text on Security Considerations", BCP 72, RFC 3552,
DOI 10.17487/RFC3552, July 2003, DOI 10.17487/RFC3552, July 2003,
<https://www.rfc-editor.org/info/rfc3552>. <https://www.rfc-editor.org/info/rfc3552>.
Appendix A. Need for this Update Appendix A. Need for this Update
This document includes an explanation of how clients and servers are This document includes an explanation of how clients and servers are
to determine the particular network access paths to be used to access to determine the particular network access paths to be used to access
a file system. This includes describing how changes to the specific a file system. This includes describing how changes to the specific
replica to be used or to the set of addresses to be used to access it replica to be used or to the set of addresses to be used to access it
are to be dealt with, and how transfers of responsibility that need are to be dealt with, and how transfers of responsibility that need
to be made can be dealt with transparently. This includes cases in to be made can be dealt with transparently. This includes cases in
which there is a shift between one replica and another and those in which there is a shift between one replica and another and those in
which different network access paths are used to access the same which different network access paths are used to access the same
replica. replica.
As a result of the following problems in RFC5661 [60], it is As a result of the following problems in RFC5661 [62], it is
necessary to provide the specific updates which are made by this necessary to provide the specific updates which are made by this
document. These updates are described in Appendix B document. These updates are described in Appendix B
o RFC5661 [60], while it dealt with situations in which various o RFC5661 [62], while it dealt with situations in which various
forms of clustering allowed co-ordination of the state assigned by forms of clustering allowed co-ordination of the state assigned by
co-operating servers to be used, made no provisions for co-operating servers to be used, made no provisions for
Transparent State Migration. Within NFSv4.0, Transparent Transparent State Migration. Within NFSv4.0, Transparent
Migration was first explained cearly in RFC7530 [62] and corrected Migration was first explained cearly in RFC7530 [64] and corrected
and clarified by RFC7931 [63]. No correesponding explanation for and clarified by RFC7931 [65]. No correesponding explanation for
NFSv4.1 had been provided. NFSv4.1 had been provided.
o Although NFSv4.1 was defined with a clear definition of how o Although NFSv4.1 was defined with a clear definition of how
trunking detection was to be done, there was no clear trunking detection was to be done, there was no clear
specification of how trunking discovery was to be done, despite specification of how trunking discovery was to be done, despite
the fact that the specification clearly indicated that this the fact that the specification clearly indicated that this
information could be made available via the file system location information could be made available via the file system location
attributes. attributes.
o Because the existence of multiple network access paths to the same o Because the existence of multiple network access paths to the same
skipping to change at page 648, line 50 skipping to change at page 648, line 50
the addresses used to access a particular file system instance. the addresses used to access a particular file system instance.
As a result, in situations in which both migration and trunking As a result, in situations in which both migration and trunking
configuration changes were involved, neither of these could be configuration changes were involved, neither of these could be
clearly dealt with and the relationship between these two features clearly dealt with and the relationship between these two features
was not seriously addressed. was not seriously addressed.
o Because use of two network access paths to the same file system o Because use of two network access paths to the same file system
instance (i.e. trunking) was often treated as if two replicas were instance (i.e. trunking) was often treated as if two replicas were
involved, it was considered that two replicas were being used involved, it was considered that two replicas were being used
simultaneously. As a result, the treatment of replicas being used simultaneously. As a result, the treatment of replicas being used
simultaneously in RFC5661 [60] was not clear as it covered the two simultaneously in RFC5661 [62] was not clear as it covered the two
distinct cases of a single file system instance being accessed by distinct cases of a single file system instance being accessed by
two different network access paths and two replicas being accessed two different network access paths and two replicas being accessed
simultaneously, with the limitations of the latter case not being simultaneously, with the limitations of the latter case not being
clearly laid out. clearly laid out.
The majority of the consequences of these issues are dealt with by The majority of the consequences of these issues are dealt with by
presenting in Section 11 a replacement for Section 11 within RFC5661 presenting in Section 11 a replacement for Section 11 within RFC5661
[60]. This replacement modifies existing sub-sections within that [62]. This replacement modifies existing sub-sections within that
section and adds new ones, as described in Appendix B.1. Also, some section and adds new ones, as described in Appendix B.1. Also, some
existing sections are deleted. These changes were made in order to: existing sections are deleted. These changes were made in order to:
o Reorganize the description so that the case of two network access o Reorganize the description so that the case of two network access
paths to the same file system instance needs to be distinguished paths to the same file system instance needs to be distinguished
clearly from the case of two different replicas since, in the clearly from the case of two different replicas since, in the
former case, locking state is shared and there also can be sharing former case, locking state is shared and there also can be sharing
of session state. of session state.
o Provide a clear statement regarding the desirability of o Provide a clear statement regarding the desirability of
transparent transfer of state between replicas together with a transparent transfer of state between replicas together with a
recommendation that either that or a single-fs grace period be recommendation that either that or a single-fs grace period be
provided. provided.
o Specifically delineate how such transfers are to be dealt with by o Specifically delineate how such transfers are to be dealt with by
the client, taking into account the differences from the treatment the client, taking into account the differences from the treatment
in [63] made necessary by the major protocol changes made in in [65] made necessary by the major protocol changes made in
NFSv4.1. NFSv4.1.
o Provide discussion of the relationship between transparent state o Provide discussion of the relationship between transparent state
transfer and Parallel NFS (pNFS). transfer and Parallel NFS (pNFS).
o Provide clarification of the fs_locations_info attribute in order o Provide clarification of the fs_locations_info attribute in order
to specify which portions of the information provided apply to a to specify which portions of the information provided apply to a
specific network access path and which to the replica which that specific network access path and which to the replica which that
path is used to access. path is used to access.
In addition, there are also updates to other sections of RFC5661 In addition, there are also updates to other sections of RFC5661
[60], where the consequences of the incorrect assumptions underlying [62], where the consequences of the incorrect assumptions underlying
the current treatment of multi-server namespace issues also needed to the current treatment of multi-server namespace issues also needed to
be corrected. These are to be dealt with as described in Sections be corrected. These are to be dealt with as described in Sections
B.2 through B.4. B.2 through B.4.
o A revised introductory section regarding multi-server namespace o A revised introductory section regarding multi-server namespace
facilities is provided. facilities is provided.
o A more realistic treatment of server scope is provided, which o A more realistic treatment of server scope is provided, which
reflects the more limited co-ordination of locking state adopted reflects the more limited co-ordination of locking state adopted
by servers actually sharing a common server scope. by servers actually sharing a common server scope.
skipping to change at page 650, line 22 skipping to change at page 650, line 22
situations that would arise in dealing with transparent state situations that would arise in dealing with transparent state
migration, or because some types of reclaim issues were not migration, or because some types of reclaim issues were not
adequately dealt with in the context of fs-specific grace periods. adequately dealt with in the context of fs-specific grace periods.
For details, see Appendix B.2. For details, see Appendix B.2.
Appendix B. Changes in this Update Appendix B. Changes in this Update
B.1. Revisions Made to Section 11 of [RFC5661] B.1. Revisions Made to Section 11 of [RFC5661]
A number of areas needed to be revised or extended, in many case A number of areas needed to be revised or extended, in many case
replacing existing sub-sections within section 11 of RFC5661 [60]: replacing existing sub-sections within section 11 of RFC5661 [62]:
o New introductory material, including a terminology section, o New introductory material, including a terminology section,
replaces the existing material in RFC5661 [60] ranging from the replaces the existing material in RFC5661 [62] ranging from the
start of the existing Section 11 up to and including the existing start of the existing Section 11 up to and including the existing
Section 11.1. The new material starts at the beginning of Section 11.1. The new material starts at the beginning of
Section 11 and continues through 11.2 below. Section 11 and continues through 11.2 below.
o A significant reorganization of the material in the existing o A significant reorganization of the material in the existing
Sections 11.4 and 11.5 (of RFC5661 [60]) is necessary. The Sections 11.4 and 11.5 (of RFC5661 [62]) is necessary. The
reasons for the reorganization of these sections into a single reasons for the reorganization of these sections into a single
section with multiple subsections are discussed in Appendix B.1.1 section with multiple subsections are discussed in Appendix B.1.1
below. This replacement appears as Section 11.5 below. below. This replacement appears as Section 11.5 below.
New material relating to the handling of the file system location New material relating to the handling of the file system location
attributes is contained in Sections 11.5.1 and 11.5.7 below. attributes is contained in Sections 11.5.1 and 11.5.7 below.
o A new section describing requirements for user and group handling o A new section describing requirements for user and group handling
within a multi-server namespace has been added as Section 11.6 within a multi-server namespace has been added as Section 11.6
o A major replacement for the existing Section 11.7 of RFC5661 [60] o A major replacement for the existing Section 11.7 of RFC5661 [62]
entitled "Effecting File System Transitions", will appear as entitled "Effecting File System Transitions", will appear as
Sections 11.8 through 11.13. The reasons for the reorganization Sections 11.8 through 11.13. The reasons for the reorganization
of this section into multiple sections are discussed in of this section into multiple sections are discussed in
Appendix B.1.2. Appendix B.1.2.
o A replacement for the existing Section 11.10 of RFC5661 [60] o A replacement for the existing Section 11.10 of RFC5661 [62]
entitled "The Attribute fs_locations_info", will appear as entitled "The Attribute fs_locations_info", will appear as
Section 11.16, with Appendix B.1.3 describing the differences Section 11.16, with Appendix B.1.3 describing the differences
between the new section and the treatment within [60]. A revised between the new section and the treatment within [62]. A revised
treatment is necessary because the existing treatment did not make treatment is necessary because the existing treatment did not make
clear how the added attribute information relates to the case of clear how the added attribute information relates to the case of
trunked paths to the same replica. These issues were not trunked paths to the same replica. These issues were not
addressed in RFC5661 [60] where the concepts of a replica and a addressed in RFC5661 [62] where the concepts of a replica and a
network path used to access a replica were not clearly network path used to access a replica were not clearly
distinguished. distinguished.
B.1.1. Re-organization of Sections 11.4 and 11.5 of [RFC5661] B.1.1. Re-organization of Sections 11.4 and 11.5 of [RFC5661]
Previously, issues related to the fact that multiple location entries Previously, issues related to the fact that multiple location entries
directed the client to the same file system instance were dealt with directed the client to the same file system instance were dealt with
in a separate Section 11.5 of RFC5661 [60]. Because of the new in a separate Section 11.5 of RFC5661 [62]. Because of the new
treatment of trunking, these issues now belong within Section 11.5 treatment of trunking, these issues now belong within Section 11.5
below. below.
In this new section, trunking is dealt with in Section 11.5.2 In this new section, trunking is dealt with in Section 11.5.2
together with the other uses of file system location information together with the other uses of file system location information
described in Sections Section 11.5.3 through 11.5.6. described in Sections Section 11.5.3 through 11.5.6.
As a result, Section 11.5 which will replace Section 11.4 of RFC5661 As a result, Section 11.5 which will replace Section 11.4 of RFC5661
[60] is substantially different than the section it replaces in that [62] is substantially different than the section it replaces in that
some existing sections will be replaced by corresponding sections some existing sections will be replaced by corresponding sections
below while, at the same time, new sections will be added, resulting below while, at the same time, new sections will be added, resulting
in a replacement containing some renumbered sections, as follows: in a replacement containing some renumbered sections, as follows:
o The material in Section 11.5, exclusive of subsections, replaces o The material in Section 11.5, exclusive of subsections, replaces
the material in Section 11.4 of RFC5661 [60] exclusive of the material in Section 11.4 of RFC5661 [62] exclusive of
subsections. subsections.
o Section 11.5.1 is a new first subsection of the overall section. o Section 11.5.1 is a new first subsection of the overall section.
o Section 11.5.2 is a new second subsection of the overall section. o Section 11.5.2 is a new second subsection of the overall section.
o Each of the Sections 11.5.4, 11.5.5, and 11.5.6 replaces (in o Each of the Sections 11.5.4, 11.5.5, and 11.5.6 replaces (in
order) one of the corresponding Sections 11.4.1, 11.4.2, and order) one of the corresponding Sections 11.4.1, 11.4.2, and
11.4.3 of RFC5661 [60]. 11.4.4, and 11.4.5. 11.4.3 of RFC5661 [62]. 11.4.4, and 11.4.5.
o Section 11.5.7 is a new final subsection of the overall section. o Section 11.5.7 is a new final subsection of the overall section.
B.1.2. Re-organization of Material Dealing with File System Transitions B.1.2. Re-organization of Material Dealing with File System Transitions
The material relating to file system transition, previously contained The material relating to file system transition, previously contained
in Section 11.7 of RFC5661 [60] has been reorganized and augmented as in Section 11.7 of RFC5661 [62] has been reorganized and augmented as
described below: described below:
o Because there can be a shift of the network access paths used to o Because there can be a shift of the network access paths used to
access a file system instance without any shift between replicas, access a file system instance without any shift between replicas,
a new Section 11.8 distinguishes between those cases in which a new Section 11.8 distinguishes between those cases in which
there is a shift between distinct replicas and those involving a there is a shift between distinct replicas and those involving a
shift in network access paths with no shift between replicas. shift in network access paths with no shift between replicas.
As a result, a new Section 11.9 deals with network address As a result, a new Section 11.9 deals with network address
transitions while the bulk of the former Section 11.7 (in RFC5661 transitions while the bulk of the former Section 11.7 (in RFC5661
[60]) is extensively modified as reflected in Section 11.10 which [62]) is extensively modified as reflected in Section 11.10 which
is now limited to cases in which there is a shift between two is now limited to cases in which there is a shift between two
different sets of replicas. different sets of replicas.
o The additional Section 11.11 discusses the case in which a shift o The additional Section 11.11 discusses the case in which a shift
to a different replica is made and state is transferred to allow to a different replica is made and state is transferred to allow
the client the ability to have continued access to its accumulated the client the ability to have continued access to its accumulated
locking state on the new server. locking state on the new server.
o The additional Section 11.12 discusses the client's response to o The additional Section 11.12 discusses the client's response to
access transitions and how it determines whether migration has access transitions and how it determines whether migration has
occurred, and how it gets access to any transferred locking and occurred, and how it gets access to any transferred locking and
session state. session state.
o The additional Section 11.13 discusses the responsibilities of the o The additional Section 11.13 discusses the responsibilities of the
source and destination servers when transferring locking and source and destination servers when transferring locking and
session state. session state.
This re-organization has caused a renumbering of the sections within This re-organization has caused a renumbering of the sections within
Section 11 of [60] as described below: Section 11 of [62] as described below:
o The new Sections 11.8 and 11.9 have resulted in existing sections o The new Sections 11.8 and 11.9 have resulted in existing sections
wit these numbers to be renumbered. wit these numbers to be renumbered.
o Section 11.7 of [60] will be substantially modified and appear as o Section 11.7 of [62] will be substantially modified and appear as
Section 11.10. The necessary modifications reflect the fact that Section 11.10. The necessary modifications reflect the fact that
this section will only deal with transitions between replicas this section will only deal with transitions between replicas
while transitions between network addresses are dealt with in while transitions between network addresses are dealt with in
other sections. Details of the reorganization are described later other sections. Details of the reorganization are described later
in this section. in this section.
o The additional Sections 11.11, 11.12, and 11.13 have been added. o The additional Sections 11.11, 11.12, and 11.13 have been added.
o Consequently, Sections 11.8, 11.9, 11.10, and 11.11 in [60] now o Consequently, Sections 11.8, 11.9, 11.10, and 11.11 in [62] now
appear as Sections 11.13, 11.14, 11.15, and 11.16, respectively. appear as Sections 11.13, 11.14, 11.15, and 11.16, respectively.
As part of this general re-organization, Section 11.7 of RFC5661 [60] As part of this general re-organization, Section 11.7 of RFC5661 [62]
will be modified as described below: will be modified as described below:
o Sections 11.7 and 11.7.1 of RFC5661 [60] are to be replaced by o Sections 11.7 and 11.7.1 of RFC5661 [62] are to be replaced by
Sections 11.10 and 11.10.1, respectively. Sections 11.10 and 11.10.1, respectively.
o Section 11.7.2 (and included subsections) of RFC5661 [60] are to o Section 11.7.2 (and included subsections) of RFC5661 [62] are to
be deleted. be deleted.
o Sections 11.7.3, 11.7.4. 11.7.5, 11.7.5.1, and 11.7.6 of RFC5661 o Sections 11.7.3, 11.7.4. 11.7.5, 11.7.5.1, and 11.7.6 of RFC5661
[60] are to be replaced by Sections 11.10.2, 11.10.3, 11.10.4, [62] are to be replaced by Sections 11.10.2, 11.10.3, 11.10.4,
11.10.4.1, and 11.10.5 respectively in this document. 11.10.4.1, and 11.10.5 respectively in this document.
o Section 11.7.7 of RFC5661 [60] is to be replaced by o Section 11.7.7 of RFC5661 [62] is to be replaced by
Section 11.10.9 This sub-section has been moved to the end of the Section 11.10.9 This sub-section has been moved to the end of the
section dealing with file system transitions. section dealing with file system transitions.
o Sections 11.7.8, 11.7.9. and 11.7.10 of RFC5661 [60] are to be o Sections 11.7.8, 11.7.9. and 11.7.10 of RFC5661 [62] are to be
replaced by Sections 11.10.6, 11.10.7, and 11.10.8 respectively in replaced by Sections 11.10.6, 11.10.7, and 11.10.8 respectively in
this document. this document.
B.1.3. Updates to treatment of fs_locations_info B.1.3. Updates to treatment of fs_locations_info
Various elements of the fs_locations_info attribute contain Various elements of the fs_locations_info attribute contain
information that applies to either a specific file system replica or information that applies to either a specific file system replica or
to a network path or set of network paths used to access such a to a network path or set of network paths used to access such a
replica. The existing treatment of fs_locations info (in replica. The existing treatment of fs_locations info (in
Section 11.10 of RFC5661 [60]) does not clearly distinguish these Section 11.10 of RFC5661 [62]) does not clearly distinguish these
cases, in part because the document did not clearly distinguish cases, in part because the document did not clearly distinguish
replicas from the paths used to access them. replicas from the paths used to access them.
In addition, special clarification needed to be provided with regard In addition, special clarification needed to be provided with regard
to the following fields: to the following fields:
o With regard to the handling of FSLI4GF_GOING, it needs to be made o With regard to the handling of FSLI4GF_GOING, it needs to be made
clear that this only applies to the unavailability of a replica clear that this only applies to the unavailability of a replica
rather than to a path to access a replica. rather than to a path to access a replica.
o In describing the appropriate value for a server to use for o In describing the appropriate value for a server to use for
fli_valid_for, it needs to be made clear that there is no need for fli_valid_for, it needs to be made clear that there is no need for
the client to frequently fetch the fs_locations_info value to be the client to frequently fetch the fs_locations_info value to be
prepared for shifts in trunking patterns. prepared for shifts in trunking patterns.
o Clarification of the rules for extensions to the fls_info needs to o Clarification of the rules for extensions to the fls_info needs to
be provided. The existing treatment reflects the extension model be provided. The existing treatment reflects the extension model
in effect at the time RFC5661 [60] was written, and needed to be in effect at the time RFC5661 [62] was written, and needed to be
updated in accordance with the extension model described in updated in accordance with the extension model described in
RFC8178 [61]. RFC8178 [63].
B.2. Revisions Made to Operations in [RFC5661] B.2. Revisions Made to Operations in [RFC5661]
Revised descriptions were needed to address issues that arose in Revised descriptions were needed to address issues that arose in
effecting necessary changes to multi-server namespace features. effecting necessary changes to multi-server namespace features.
o The existing treatment of EXCHANGE_ID (in Section 18.35 of RFC5661 o The existing treatment of EXCHANGE_ID (in Section 18.35 of RFC5661
[60]) assumes that client IDs cannot be created/ confirmed other [62]) assumes that client IDs cannot be created/ confirmed other
than by the EXCHANGE_ID and CREATE_SESSION operations. Also, the than by the EXCHANGE_ID and CREATE_SESSION operations. Also, the
necessary use of EXCHANGE_ID in recovery from migration and necessary use of EXCHANGE_ID in recovery from migration and
related situations is not addressed clearly. A revised treatment related situations is not addressed clearly. A revised treatment
of EXCHANGE_ID is necessary and it appears in Section 18.35 while of EXCHANGE_ID is necessary and it appears in Section 18.35 while
the specific differences between it and the treatment within [60] the specific differences between it and the treatment within [62]
are explained in Appendix B.2.1 below. are explained in Appendix B.2.1 below.
o The existing treatment of RECLAIM_COMPLETE in section 18.51 of o The existing treatment of RECLAIM_COMPLETE in section 18.51 of
RFC5661 [60]) is not sufficiently clear about the purpose and use RFC5661 [62]) is not sufficiently clear about the purpose and use
of the rca_one_fs and how the server is to deal with inappropriate of the rca_one_fs and how the server is to deal with inappropriate
values of this argument. Because the resulting confusion raises values of this argument. Because the resulting confusion raises
interoperability issues, a new treatment of RECLAIM_COMPLETE is interoperability issues, a new treatment of RECLAIM_COMPLETE is
necessary and it appears in Section 18.51 below while the specific necessary and it appears in Section 18.51 below while the specific
differences between it and the treatment within RFC5661 [60] are differences between it and the treatment within RFC5661 [62] are
discussed in Appendix B.2.2 below. In addition, the definitions discussed in Appendix B.2.2 below. In addition, the definitions
of the reclaim-related errors receive an updated treatment in of the reclaim-related errors receive an updated treatment in
Section 15.1.9 to reflect the fact that there are multiple Section 15.1.9 to reflect the fact that there are multiple
contexts for lock reclaim operations. contexts for lock reclaim operations.
B.2.1. Revision to Treatment of EXCHANGE_ID B.2.1. Revision to Treatment of EXCHANGE_ID
There are a number of issues in the original treatment of EXCHANGE_ID There are a number of issues in the original treatment of EXCHANGE_ID
(in RFC5661 [60]) that cause problems for Transparent State Migration (in RFC5661 [62]) that cause problems for Transparent State Migration
and for the transfer of access between different network access paths and for the transfer of access between different network access paths
to the same file system instance. to the same file system instance.
These issues arise from the fact that this treatment was written, These issues arise from the fact that this treatment was written,
o Assuming that a client ID can only become known to a server by o Assuming that a client ID can only become known to a server by
having been created by executing an EXCHANGE_ID, with confirmation having been created by executing an EXCHANGE_ID, with confirmation
of the ID only possible by execution of a CREATE_SESSION. of the ID only possible by execution of a CREATE_SESSION.
o Considering the interactions between a client and a server only o Considering the interactions between a client and a server only
skipping to change at page 655, line 30 skipping to change at page 655, line 30
which it was done, so that it could be used by a subsequent which it was done, so that it could be used by a subsequent
CREATE_SESSSION, whose parameters do not include an explicit CREATE_SESSSION, whose parameters do not include an explicit
client ID. client ID.
The new treatment explicitly discusses the role of EXCHANGE_ID in The new treatment explicitly discusses the role of EXCHANGE_ID in
associating the client ID with the connection so it can be used by associating the client ID with the connection so it can be used by
CREATE_SESSION and in associating a connection with an existing CREATE_SESSION and in associating a connection with an existing
session. session.
The new treatment can be found in Section 18.35 below. It is The new treatment can be found in Section 18.35 below. It is
intended to supersede the treatment in Section 18.35 of RFC5661 [60]. intended to supersede the treatment in Section 18.35 of RFC5661 [62].
Publishing a complete replacement for Section 18.35 allows the Publishing a complete replacement for Section 18.35 allows the
corrected definition to be read as a whole, in place of the one in corrected definition to be read as a whole, in place of the one in
RFC5661 [60]. RFC5661 [62].
B.2.2. Revision to Treatment of RECLAIM_COMPLETE B.2.2. Revision to Treatment of RECLAIM_COMPLETE
The following changes were made to the treatment of RECLAIM_COMPLETE The following changes were made to the treatment of RECLAIM_COMPLETE
in RFC5661 [60] to arrive at the treatment in Section 18.51. in RFC5661 [62] to arrive at the treatment in Section 18.51.
o In a number of places the text is made more explicit about the o In a number of places the text is made more explicit about the
purpose of rca_one_fs and its connection to file system migration. purpose of rca_one_fs and its connection to file system migration.
o There is a discussion of situations in which particular forms of o There is a discussion of situations in which particular forms of
RECLAIM_COMPLETE would need to be done. RECLAIM_COMPLETE would need to be done.
o There is a discussion of interoperability issues that result from o There is a discussion of interoperability issues that result from
implementations that may have arisen due to the lack of clarity of implementations that may have arisen due to the lack of clarity of
the previous treatment of RECLAIM_COMPLETE. the previous treatment of RECLAIM_COMPLETE.
B.3. Revisions Made to Error Definitions in [RFC5661] B.3. Revisions Made to Error Definitions in [RFC5661]
The new handling of various situations required revisions of some The new handling of various situations required revisions of some
existing error definition: existing error definition:
o Because of the need to appropriately address trunking-related o Because of the need to appropriately address trunking-related
issues, some uses of the term "replica" in RFC5661 [60] have issues, some uses of the term "replica" in RFC5661 [62] have
become problematic since a shift in network access paths was become problematic since a shift in network access paths was
considered to be a shift to a different replica. As a result, the considered to be a shift to a different replica. As a result, the
existing definition of NFS4ERR_MOVED (in Section 15.1.2.4 of existing definition of NFS4ERR_MOVED (in Section 15.1.2.4 of
RFC5661 [60]) needs to be updated to reflect the different RFC5661 [62]) needs to be updated to reflect the different
handling of unavailability of a particular fs via a specific handling of unavailability of a particular fs via a specific
network address. network address.
Since such a situation is no longer considered to constitute Since such a situation is no longer considered to constitute
unavailability of a file system instance, the description needs to unavailability of a file system instance, the description needs to
change even though the set of circumstances in which it is to be change even though the set of circumstances in which it is to be
returned remain the same. The new paragraph explicitly recognizes returned remain the same. The new paragraph explicitly recognizes
that a different network address might be used, while the previous that a different network address might be used, while the previous
description, misleadingly, treated this as a shift between two description, misleadingly, treated this as a shift between two
replicas while only a single file system instance might be replicas while only a single file system instance might be
involved. The updated description appears in Section 15.1.2.4 involved. The updated description appears in Section 15.1.2.4
below. below.
o Because of the need to accommodate use of fs-specific grace o Because of the need to accommodate use of fs-specific grace
periods, it is necessary to clarify some of the error definitions periods, it is necessary to clarify some of the error definitions
of reclaim-related errors in Section 15 of RFC5661 [60], so the of reclaim-related errors in Section 15 of RFC5661 [62], so the
text applies properly to reclaims for all types of grace periods. text applies properly to reclaims for all types of grace periods.
The updated descriptions appear within Section 15.1.9 below. The updated descriptions appear within Section 15.1.9 below.
o Because of the need to provide the clarifications in errata 2006 o Because of the need to provide the clarifications in errata 2006
and to adapt these to properly explain the interaction of [60] and to adapt these to properly explain the interaction of
NFS4ERR_DELAY with the replay cache, a revised description of NFS4ERR_DELAY with the replay cache, a revised description of
NFS4ERR_DELAY appears in Section 15.1.1.3. This errata, unlike NFS4ERR_DELAY appears in Section 15.1.1.3. This errata, unlike
many other RFC5661 erratas, is addressed in this document because many other RFC5661 erratas, is addressed in this document because
of the extensive use of NFS4ERR_DELAY in connection with state of the extensive use of NFS4ERR_DELAY in connection with state
migration and session migration. migration and session migration.
B.4. Other Revisions Made to [RFC5661] B.4. Other Revisions Made to [RFC5661]
Beside the major reworking of Section 11 and the associated revisions Beside the major reworking of Section 11 and the associated revisions
to existing operations and errors, there are a number of related to existing operations and errors, there are a number of related
changes that are necessary: changes that are necessary:
o The summary that appeared in Section 1.7.3.3 of RFC5661 [60] was o The summary that appeared in Section 1.7.3.3 of RFC5661 [62] was
revised to reflect the changes made in the revised Section 11 revised to reflect the changes made in the revised Section 11
above. The updated summary appears as Section 1.8.3.3 above. above. The updated summary appears as Section 1.8.3.3 above.
o The discussion of server scope which appeared in Section 2.10.4 of o The discussion of server scope which appeared in Section 2.10.4 of
RFC5661 [60] needed to be replaced, since the previous text RFC5661 [62] needed to be replaced, since the previous text
appears to require a level of inter-server co-ordination appears to require a level of inter-server co-ordination
incompatible with its basic function of avoiding the need for a incompatible with its basic function of avoiding the need for a
globally uniform means of assigning server_owner values. A globally uniform means of assigning server_owner values. A
revised treatment appears in Section 2.10.4. revised treatment appears in Section 2.10.4.
o The discussion of trunking which appeared in Section 2.10.5 of o The discussion of trunking which appeared in Section 2.10.5 of
RFC5661 [60] needed to be revised, to more clearly explain the RFC5661 [62] needed to be revised, to more clearly explain the
multiple types of trunking supporting and how the client can be multiple types of trunking supporting and how the client can be
made aware of the existing trunking configuration. In addition made aware of the existing trunking configuration. In addition
the last paragraph (exclusive of sub-sections) of that section, the last paragraph (exclusive of sub-sections) of that section,
dealing with server_owner changes, is literally true, it has been dealing with server_owner changes, is literally true, it has been
a source of confusion. Since the existing paragraph can be read a source of confusion. Since the existing paragraph can be read
as suggesting that such changes be dealt with non-disruptively, as suggesting that such changes be dealt with non-disruptively,
the issue needs to be clarified in the revised section, which the issue needs to be clarified in the revised section, which
appears in Section 2.10.5 appears in Section 2.10.5
Appendix C. Security Issues that Need to be Addressed Appendix C. Security Issues that Need to be Addressed
The following issues in the treatment of security within the NFSv4.1 The following issues in the treatment of security within the NFSv4.1
specification need to be addressed: specification need to be addressed:
o The Security Considerations Section of RFC5661 [60] is not written o The Security Considerations Section of RFC5661 [62] is not written
in accord with RFC3552 [66] (also BCP72). Of particular concern in accord with RFC3552 [68] (also BCP72). Of particular concern
is the fact that the section does not contain a threat analysis. is the fact that the section does not contain a threat analysis.
o Initial analysis of the existing security issues with NFSv4.1 has o Initial analysis of the existing security issues with NFSv4.1 has
made it likely that a revised Security Considerations Section for made it likely that a revised Security Considerations Section for
the existing protocol (one containing a threat analysis) would be the existing protocol (one containing a threat analysis) would be
likely to conclude that NFSv4.1 does not meet the goal of secure likely to conclude that NFSv4.1 does not meet the goal of secure
use on the internet. use on the internet.
The Security Considerations Section of this document (in Section 21) The Security Considerations Section of this document (in Section 21)
has not been thoroughly revised to correct the difficulties mentioned has not been thoroughly revised to correct the difficulties mentioned
skipping to change at page 658, line 11 skipping to change at page 658, line 11
creates needs to be addressed. Addressing this issue must not be creates needs to be addressed. Addressing this issue must not be
limited to the questions of whether the designation of this as limited to the questions of whether the designation of this as
OPTIONAL was justified and whether it should be changed. OPTIONAL was justified and whether it should be changed.
In any event, it may not be possible, at this point, to correct In any event, it may not be possible, at this point, to correct
the security problems created by continued use of AUTH_SYS simply the security problems created by continued use of AUTH_SYS simply
by revising this designation. by revising this designation.
o The lack of attention within the protocol to the possibility of o The lack of attention within the protocol to the possibility of
pervasive monitoring attacks such as those described in RFC7258 pervasive monitoring attacks such as those described in RFC7258
[65] (also BCP188). [67] (also BCP188).
In that connection, the use of CREATE_SESSION without privacy In that connection, the use of CREATE_SESSION without privacy
protection needs to be addressed as it exposes the session ID to protection needs to be addressed as it exposes the session ID to
view by an attacker. This is worrisome as this is precisely the view by an attacker. This is worrisome as this is precisely the
type of protocol artifact alluded to in RFC7258, which can enable type of protocol artifact alluded to in RFC7258, which can enable
further mischief on the part of the attacker as it enables denial- further mischief on the part of the attacker as it enables denial-
of-service attacks which can be executed effectively with only a of-service attacks which can be executed effectively with only a
single, normally low-value, credential, even when RPCSEC_GSS single, normally low-value, credential, even when RPCSEC_GSS
authentication is in use. authentication is in use.
 End of changes. 77 change blocks. 
90 lines changed or deleted 99 lines changed or added

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