draft-ietf-nfsv4-mv0-trunking-update-01.txt   draft-ietf-nfsv4-mv0-trunking-update-02.txt 
Network File System Version 4 C. Lever, Ed. Network File System Version 4 C. Lever, Ed.
Internet-Draft Oracle Internet-Draft Oracle
Updates: 7530 (if approved) D. Noveck Updates: 7530 (if approved) D. Noveck
Intended status: Standards Track NetApp Intended status: Standards Track NetApp
Expires: January 17, 2019 July 16, 2018 Expires: May 9, 2019 November 5, 2018
NFS version 4.0 Trunking Update NFS version 4.0 Trunking Update
draft-ietf-nfsv4-mv0-trunking-update-01 draft-ietf-nfsv4-mv0-trunking-update-02
Abstract Abstract
The location-related attribute in NFS version 4.0, fs_locations, The file system location-related attribute in NFS version 4.0,
informs clients about alternate locations of file systems. An NFS fs_locations, informs clients about alternate locations of file
version 4.0 client can use this information to handle migration and systems. An NFS version 4.0 client can use this information to
replication of server filesystems. This document describes how an handle migration and replication of server filesystems. This
NFS version 4.0 client can additionally use this information to document describes how an NFS version 4.0 client can additionally use
discover an NFS version 4.0 server's trunking capabilities. This this information to discover an NFS version 4.0 server's trunking
document updates RFC 7530. capabilities. This document updates RFC 7530.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at 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 January 17, 2019. This Internet-Draft will expire on May 9, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
3. Preliminaries . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 4. Document Organization . . . . . . . . . . . . . . . . . . . . 6
3.2. Document Organization . . . . . . . . . . . . . . . . . . 5 5. Changes Within Section 8 of [RFC7530] . . . . . . . . . . . . 7
3.3. Document Goals . . . . . . . . . . . . . . . . . . . . . 6 5.1. Updated Section 8.1 of [RFC7530], entitled
4. Overview of changes in RFC7530 Section 8 . . . . . . . . . . 6 "Location Attributes" . . . . . . . . . . . . . . . . . . 7
5. Location Attributes (as updated) . . . . . . . . . . . . . . 7 5.2. Updates to Section 8.4 of [RFC7530], entitled
6. Updates to RFC7530 Section 8.4 (Uses of Location Information) 8 "Uses of Location Information" . . . . . . . . . . . . . 9
6.1. Introduction to uses of Location Information (as updated) 8 5.2.1. Updated Introduction to Section 8.4 of [RFC7530],
6.2. Trunking Discovery and Detection (to be added) . . . . . 10 entitled "Uses of Location Information" . . . . . . . 9
6.3. Location Attributes and Connection Type Selection (to be 5.2.2. New Sub-section of Section 8.4 of [RFC7530],
added) . . . . . . . . . . . . . . . . . . . . . . . . . 11 to be entitled "Trunking Discovery and Detection" . . 10
6.4. File System Replication and Trunking (as updated) . . . . 11 5.2.3. New Sub-section of Section 8.4 of [RFC7530],
6.5. File System Migration (as updated) . . . . . . . . . . . 11 to be entitled "Location Attributes and Connection
6.6. Interaction of Trunking, Migration, and Replication (to Type Selection" . . . . . . . . . . . . . . . . . . . 11
be added) . . . . . . . . . . . . . . . . . . . . . . . . 12 5.2.4. Updated Section 8.4.1 of [RFC7530], entitled
7. Location Entries and Server Identity Update (as updated) . . 13 "File System Replication and Trunking" . . . . . . . 11
8. Updates to RFC7530 Outside Section Eight . . . . . . . . . . 14 5.2.5. Updated Section 8.4.2 of [RFC7530], entitled
9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 "File System Migration" . . . . . . . . . . . . . . . 12
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 5.2.6. New Sub-section of Section 8.4 of [RFC7530],
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 to be entitled "Interaction of Trunking, Migration,
11.1. Normative References . . . . . . . . . . . . . . . . . . 16 and Replication" . . . . . . . . . . . . . . . . . . 12
11.2. Informative References . . . . . . . . . . . . . . . . . 17 5.3. Updated Section 8.5 of [RFC7530], entitled
Appendix A. Section Classification . . . . . . . . . . . . . . . 17 "Location Entries and Server Identity Update" . . . . . . 14
6. Updates to [RFC7530] Outside Section Eight . . . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.1. Normative References . . . . . . . . . . . . . . . . . . 17
9.2. Informative References . . . . . . . . . . . . . . . . . 17
Appendix A. Section Classification . . . . . . . . . . . . . . . 18
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 18 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
The NFS version 4.0 specification [RFC7530] defines a migration The NFS version 4.0 specification [RFC7530] defines a migration
feature which enables the transfer of a file system from one server feature which enables the transfer of a file system from one server
to another without disruption of client activity. There were a to another without disruption of client activity. There were a
number of issues with the original definition of this feature, now number of issues with the original definition of this feature, now
resolved with the publication of [RFC7931]. resolved with the publication of [RFC7931].
After a migration event, a client must determine whether state After a migration event, a client must determine whether state
recovery is necessary. To do this, it needs to determine whether the recovery is necessary. To do this, it needs to determine whether the
source and destination server addresses represent the same server source and destination server addresses represent the same server
instance, if the client has already established a lease on the instance, if the client has already established a lease on the
destination server for other file systems, and if the destination destination server for other file systems, and if the destination
server instance has lock state for the migrated file system. server instance has lock state for the migrated file system.
As part of addressing this need, [RFC7931] introduces into NFS As part of addressing this need, [RFC7931] introduces trunking into
version 4.0 a trunking detection mechanism to enable a client to NFS version 4.0 along with a trunking detection mechanism. This
determine whether two distinct network addresses are connected to the enables a client to determine whether two distinct network addresses
same NFS version 4.0 server instance. Despite this addition, the NFS are connected to the same NFS version 4.0 server instance.
version 4.0 specification remains without a complete discussion of Nevertheless, the use of the concept of server-trunkability is the
trunking. same in both protocol versions.
File system migration, replication, and referrals are distinct File system migration, replication, and referrals are distinct
protocol features. However, it is not appropriate to treat each of protocol features. However, it is not appropriate to treat each of
these features in isolation. For example, client migration recovery these features in isolation. For example, client migration recovery
processing needs to deal with the possibility of multiple server processing needs to deal with the possibility of multiple server
addresses in a returned fs_locations attribute. In addition, the addresses in a returned fs_locations attribute. In addition, the
contents of the fs_locations attribute, which provides both trunking- contents of the fs_locations attribute, which provides both trunking-
related and replication information, may change over repeated related and replication information, may change over repeated
retrievals, requiring an integrated description of how clients are to retrievals, requiring an integrated description of how clients are to
deal with such changes. The issues discussed in the current document deal with such changes. The issues discussed in the current document
relate to the interpretation of the fs_locations attribute and to the relate to the interpretation of the fs_locations attribute and to the
proper client and server handling of changes in fs_locations proper client and server handling of changes in fs_locations
attribute values. attribute values.
Therefore the goals of this document are:
o To provide NFS version 4.0 with a means of trunking discovery,
compatible with the means of trunking detection introduced by
[RFC7931].
o To describe how NFS version 4.0 clients are to handle the presence
of multiple network addresses associated to the same server, when
recovering from a replication and migration event.
o To describe how NFS version 4.0 clients are to handle changes in
the contents of returned fs_locations attributes, including those
that indicate changes in the responding NFS version 4.0 server's
trunking configuration.
The current document pursues these goals by presenting a set of
updates to [RFC7530] as summarized in Sections 5 and 6 below.
2. Requirements Language 2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14 [RFC2119] document are to be interpreted as described in BCP 14 [RFC2119]
[RFC8174] when, and only when, they appear in all capitals, as shown [RFC8174] when, and only when, they appear in all capitals, as shown
here. here.
3. Preliminaries 3. Terminology
3.1. Terminology
Most of the terms related to handling the fs_locations attribute are Most of the terms related to handling the fs_locations attribute are
appropriately defined in Section 5 below. However, there are a few appropriately defined in Section 5.1 below. However, there are a few
terms used outside that context that are explained in this section. terms used outside that context that are explained in this section.
Regarding network addresses and the handling of trunking we use the Trunking refers to a situation in which a client uses multiple
following terminology: network addresses communicate with the same server. Trunking was
first introduced to NFSv4.0 by [RFC7931]. Regarding network
addresses and the handling of trunking we use the following
terminology:
o Each NFSv4 server is assumed to have a set of IP addresses to o Each NFSv4 server is assumed to have a set of IP addresses to
which NFSv4 requests may be sent by clients. These are referred which NFSv4 requests may be sent by clients. These are referred
to as the server's network addresses. Access to a specific server to as the server's network addresses. Access to a specific server
network address might involve the use of multiple network ports, network address might involve the use of multiple network ports,
since the ports to be used for particular types of connections since the ports to be used for particular types of connections
might be required to be different. might be required to be different.
o Clients may establish connections to NFSv4 servers via one of o Clients may establish connections to NFSv4 servers via one of
several connection types, supporting the NFSv4 protocol layered on several connection types, supporting the NFSv4 protocol layered on
top of an RPC stream transport, as described in [RFC5531], or on top of an RPC stream transport, as described in [RFC5531], or on
top of RPC-over-RDMA, as described in [RFC8166]. top of RPC-over-RDMA, as described in [RFC8166]. The combination
of a server network address and a particular connection type is
o The combination of a server network address and a particular referred to as a "server endpoint".
connection type is referred to as a "server endpoint". Using
different connection types typically results in the use of
different ports. However, the use of different ports by multiple
connections to the same network address is not the essence of the
distinction between the two endpoints used.
o Each network address, when combined with a pathname providing the o Each network address, when combined with a pathname providing the
location of a file system root directory relative to the location of a file system root directory relative to the
associated server root file handle, defines a file system network associated server root file handle, defines a file system network
access path. access path.
o Two network addresses connected to the same server are said to be o Two network addresses connected to the same server are said to be
server-trunkable. server-trunkable. Unlike the case of NFSv4.1 (which introduced
the concept of trunking to NFS version 4), NFSv4.0 only recgnizes
a single type of trunking relationship between addresses. NFSv4.1
distinguishes two (see [RFC5661]). Despite this difference, two
addresses connected to the same NFSv4.0 server would normally be
connected to the same server if NFSv4.1 were used.
Particularly important is the distinction between trunking detection Particularly important is the distinction between trunking detection
and trunking discovery. The definitions we present are applicable to and trunking discovery. The definitions we present are applicable to
all minor versions of NFSv4, but we put particular emphasis on how all minor versions of NFSv4, but we put particular emphasis on how
these terms apply to NFS version 4.0. these terms apply to NFS version 4.0.
o Trunking detection refers to ways of confirming that two unique o Trunking detection refers to ways of confirming that two unique
network addresses are associated with the same NFSv4 server network addresses are associated with the same NFSv4 server
instance. The means available to make this determination depends instance. The means available to make this determination depends
on the protocol version and, in some cases, on the client on the protocol version and, in some cases, on the client
skipping to change at page 5, line 6 skipping to change at page 5, line 37
filter them. filter them.
Trunking discovery is not discussed in [RFC7530] and no Trunking discovery is not discussed in [RFC7530] and no
description of it is provided in [RFC7931]. description of it is provided in [RFC7931].
Discussion of the term "replica" is complicated for a number of Discussion of the term "replica" is complicated for a number of
reasons. Even though the term is used in explaining the issues in reasons. Even though the term is used in explaining the issues in
[RFC7530] that need to be addressed in this document, a full [RFC7530] that need to be addressed in this document, a full
explanation of this term requires explanation of related terms explanation of this term requires explanation of related terms
connected to the fs_locations attribute, which is provided in connected to the fs_locations attribute, which is provided in
Section 5 of the current document. Section 5.1 of the current document.
The term is also used in previous documents about NFSv4.0 (i.e., The term is also used in previous documents about NFSv4.0 (i.e.,
[RFC7530] and [RFC7931]) with a meaning different from that in the [RFC7530] and [RFC7931]) with a meaning different from that in the
current document. In these documents each replica is identified by a current document. In these documents each replica is identified by a
single network access path. However, in the current document a set single network access path. However, in the current document a set
of network access paths which have server-trunkable network addresses of network access paths which have server-trunkable network addresses
and the same root-relative file system pathname are considered to be and the same root-relative file system pathname are considered to be
a single replica with multiple network access paths. Although a single replica with multiple network access paths. Although
[RFC7931] enables an NFSv4.0 client to determine whether two network [RFC7931] enables an NFSv4.0 client to determine whether two network
addresses were server-trunkable, it never described these as addresses were server-trunkable, it never described these as
connected to a single replica, leaving in effect the approach connected to a single replica, leaving in effect the approach
established in [RFC7530]. established in [RFC7530].
3.2. Document Organization 4. Document Organization
The sections of the current document are divided into four types The sections of the current document are divided into four types
based on how they relate to the eventual updating of the NFS verion based on how they relate to the eventual updating of the NFS verion
4.0 specification. Once this update is published, NFS version 4.0 4.0 specification. Once this update is published, NFS version 4.0
will be specified by multiple documents that need to be read will be specified by multiple documents that need to be read
together, until such time as a consolidated replacement specification together, until such time as a consolidated replacement specification
is produced. is produced.
o The base specification [RFC7530]. o The base specification [RFC7530].
o The migration-related update [RFC7931]. o The migration-related update [RFC7931].
o An eventual RFC based on the current document. o This document [RFC-TBD].
The section types are as follows. See Appendix A for a The section types are as follows. See Appendix A for a
classification of each section of the current document. classification of each section of the current document.
o An explanatory section does not contain any material that is meant o An explanatory section does not contain any material that is meant
to update the specification of NFS version 4.0. Such sections may to update the specification of NFS version 4.0. Such sections may
contain explanation about why and how changes are to be done, but contain explanation about why and how changes are to be done, but
do not include any text that is to update [RFC7530] or appear in do not include any text that is to update [RFC7530] or appear in
an eventual consolidated document. an eventual consolidated document.
o A replacement section contains text that is to replace and thus o A replacement section contains text that is to replace and thus
supersede text within [RFC7530] and then appear in an eventual supersede text within [RFC7530] and then appear in an eventual
consolidated document. consolidated document. The titles of replacement sections
indicate what section of [RFC7530] is to be replaced.
o An additional section contains text which, although not replacing o An additional section contains text which, although not replacing
anything in [RFC7530], will be part of the specification of NFS anything in [RFC7530], will be part of the specification of NFS
version 4.0 and will be expected to be part of an eventual version 4.0 and will be expected to be part of an eventual
consolidated document. consolidated document. The titles of additional sections provide
an indication of where in an updated [RFC7530], the new section
would appear.
o An editing section contains some text that replaces text within o An editing section contains some text that replaces text within
[RFC7530], although the entire section will not consist of such [RFC7530], although the entire section will not consist of such
text and will include other text as well. Such sections make text and will include other text as well. Such sections make
relatively minor adjustments in the existing NFS version 4.0 relatively minor adjustments in the existing NFS version 4.0
specification which are expected to be reflected in an eventual specification which are expected to be reflected in an eventual
consolidated document. Generally such replacement text appears as consolidated document. Generally such replacement text appears as
a quotation, possibly taking the form of an indented set of a quotation, possibly taking the form of an indented set of
paragraphs. paragraphs.
3.3. Document Goals 5. Changes Within Section 8 of [RFC7530]
The goals of this document are as follows:
o To provide NFS version 4.0 with a means of trunking discovery,
compatible with the means of trunking detection introduced by
[RFC7931].
o To describe how NFS version 4.0 clients are to handle the presence
of multiple network addresses associated to the same server, when
recovering from a replication and migration event.
o To describe how NFS version 4.0 clients are to handle changes in
the contents of returned fs_locations attributes, including those
that indicate changes in the responding NFS version 4.0 server's
trunking configuration.
The current document pursues these goals by presenting a set of
updates to [RFC7530] as summarized in Sections 4 and 8 below.
4. Overview of changes in RFC7530 Section 8
With a few small exceptions (see below), all of the updates to Most of the updates to [RFC7530] to provide support for trunking
[RFC7530] to provide support for trunking using the fs_locations using the fs_locations attribute apply to Section 8 of that document,
attribute apply to Section 8 of that document, entitled "Multi-Server entitled "Multi-Server Namespace".
Namespace".
o Section 5 replaces Section 8.1 of [RFC7530], entitled "Location o Section 5.1 replaces Section 8.1 of [RFC7530], entitled "Location
Attributes". This section has been reorganized and extended to Attributes". This section has been reorganized and extended to
explicitly allow the use of fs_locations to provide trunking- explicitly allow the use of fs_locations to provide trunking-
related information that appropriately interacts with the related information that appropriately interacts with the
migration, replication and referral features of fs_locations. migration, replication and referral features of fs_locations.
Terminology used to describe the interactions is added. Terminology used to describe the interactions is added.
o Section 6 updates Section 8.4 of [RFC7530], entitled "Uses of o Section 5.2 updates Section 8.4 of [RFC7530], entitled "Uses of
Location Information". This section comprises the bulk of the Location Information". This section comprises the bulk of the
updates. Each paragraph of Section 8.4 and its sub-sections has updates. Each paragraph of Section 8.4 and its sub-sections has
been reviewed to clarify the provision of trunking-related been reviewed to clarify the provision of trunking-related
information using the fs_locations attribute. information using the fs_locations attribute.
* Section 6.1 replaces the introductory material within * Section 5.2.1 replaces the introductory material within
Section 8.4 of [RFC7530]. Section 8.4 of [RFC7530].
* Section 6.2 is to be added after the introductory material * Section 5.2.2 is to be added as a new sub-section of
within Section 8.4 of [RFC7530]. Section 8.4 before the updated Section 8.4.1 of [RFC7530].
* Section 6.4 replaces Section 8.4.1 of [RFC7530], entitled "File * Section 5.2.3 is to be added as a new sub-section of
System Replication". Section 8.4 before the updated Section 8.4.1 of [RFC7530].
* Section 6.5 replaces Section 8.4.2 of [RFC7530], entitled "File * Section 5.2.4 replaces Section 8.4.1 of [RFC7530], entitled
System Migration". "File System Replication".
* Section 6.6 is to be added after the updated Section 8.4.2 of * Section 5.2.5 replaces Section 8.4.2 of [RFC7530], entitled
[RFC7530]. "File System Migration".
o Section 7 replaces Section 8.5 of [RFC7530], entitled "Location * Section 5.2.6 is to be added as a new sub-section of
Section 8.4 before Section 8.4.3 of [RFC7530].
o Section 5.3 replaces Section 8.5 of [RFC7530], entitled "Location
Entries and Server Identity". The last paragraph of the existing Entries and Server Identity". The last paragraph of the existing
section has been removed. section has been removed.
o A small set of updates outside Section 8 of [RFC7530] are 5.1. Updated Section 8.1 of [RFC7530], entitled "Location Attributes"
presented in Section 8.
o Section 9 introduces additional security considerations that are
to be added to those within Section 19 of [RFC7530], entitled
"Security Considerations".
5. Location Attributes (as updated)
The fs_locations attribute (described as "RECOMMENDED" in [RFC7530]) The fs_locations attribute (described as "RECOMMENDED" in [RFC7530])
allows specification of file system locations where the data allows specification of file system locations where the data
corresponding to a given file system may be accessed. This attribute corresponding to a given file system may be accessed. This attribute
represents such file system instances as a server address target (as represents such file system instances as a server address target (as
either a DNS host name representing one or more network addresses, or either a DNS host name representing one or more network addresses, or
a single literal network address) together with the path of that file a single literal network address) together with the path of that file
system within the associated single-server namespace. Individual system within the associated single-server namespace. Individual
fs_locations entries can express trunkable addresses, locations of fs_locations entries can express trunkable addresses, locations of
file system replicas on other servers, migration targets, or pure file system replicas on other servers, migration targets, or pure
skipping to change at page 8, line 18 skipping to change at page 8, line 32
Regarding terminology relating to GETATTR attributes used in trunking Regarding terminology relating to GETATTR attributes used in trunking
discovery and other multi-server namespace features: discovery and other multi-server namespace features:
o Location attributes include only the fs_locations GETATTR o Location attributes include only the fs_locations GETATTR
attribute. attribute.
o Location entries (fs_location4, defined in [RFC7530] o Location entries (fs_location4, defined in [RFC7530]
Section 2.2.6) are the individual file system locations in the Section 2.2.6) are the individual file system locations in the
fs_locations attribute (defined in [RFC7530] Section 2.2.7). A fs_locations attribute (defined in [RFC7530] Section 2.2.7). A
location entry designates a set of network addresses to which file system location entry designates a set of network addresses
clients may establish connections. The entry may designate to which clients may establish connections. The entry may
multiple such addresses because the server host name may map to designate multiple such addresses because the server host name may
multiple network addresses, and because multiple connection types map to multiple network addresses, and because multiple connection
may be used to communicate with each specified network address. types may be used to communicate with each specified network
All such addresses MUST provide a way of connecting to a single address. All such addresses MUST provide a way of connecting to a
server. single server.
o Location elements are derived from location entries. If a o File system location elements are derived from file system
location entry specifies a network address there is only a single location entries. If a file system location entry specifies a
corresponding location element. When a location entry contains a network address, there is only a single corresponding location
host name, the host name is resolved by the client, producing one element. When a file system location entry contains a host name,
the host name is resolved by the client, producing one file system
location element for each of the resulting network addresses. location element for each of the resulting network addresses.
o All location elements consist of a location address, which is the o All file system location elements consist of a file system
network address of an interface to a server, and an fs_name, which location address, which is the network address of an interface to
is the location of the file system within the server's pseudo-fs. a server, and an fs_name, which is the location of the file system
within the server's pseudo-fs.
o If the server has no pseudo-fs and only a single exported file o If the server has no pseudo-fs and only a single exported file
system at the root filehandle, the fs_name may be empty. system at the root filehandle, the fs_name may be empty.
6. Updates to RFC7530 Section 8.4 (Uses of Location Information) 5.2. Updates to Section 8.4 of [RFC7530], entitled "Uses of Location
Information"
The subsections below provide replacement sections for existing The subsections below provide replacement sections for existing
sections within Section 8.4 of [RFC7530] or new sub-sections to be sections within Section 8.4 of [RFC7530] or new sub-sections to be
added to that section. added to that section.
6.1. Introduction to uses of Location Information (as updated) 5.2.1. Updated Introduction to Section 8.4 of [RFC7530], entitled "Uses
of Location Information"
Together with the possibility of absent file systems, the location- Together with the possibility of absent file systems, the file system
bearing attribute fs_locations provides a number of important location-bearing attribute fs_locations provides a number of
facilities that enable reliable, manageable, and scalable data important facilities that enable reliable, manageable, and scalable
access. data access.
When a file system is present on the queried server, this attribute When a file system is present on the queried server, this attribute
can provide a set of locations that clients may use to access the can provide a set of locations that clients may use to access the
file system. In the event that server failure, communications file system. In the event that server failure, communications
problems, or other difficulties make continued access to the file problems, or other difficulties make continued access to the file
system impossible or otherwise impractical, the returned information system impossible or otherwise impractical, the returned information
provides alternate locations that enable continued access to the file provides alternate locations that enable continued access to the file
system. Provision of such alternative locations is referred to as system. Provision of such alternative file system locations is
"replication". referred to as "replication".
When alternative locations are provided, they may represent distinct When alternative file system locations are provided, they may
physical copies of the same file system data or separate NFS server represent distinct physical copies of the same file system data or
instances that provide access to the same physical file system. separate NFS server instances that provide access to the same
Another possible use of the provision of multiple location entries is physical file system. Another possible use of the provision of
trunking, wherein the location entries do not in fact represent multiple file system location entries is trunking, wherein the file
different servers but rather are distinct network paths to the same system location entries do not in fact represent different servers
server. but rather are distinct network paths to the same server.
A client may use location elements simultaneously to provide higher- A client may use file system location elements simultaneously to
performance access to the target file system. The client utilizes provide higher-performance access to the target file system. The
trunking detection and/or discovery, further described in Section 6.2 client utilizes trunking detection and/or discovery, further
of the current document, to determine a set of network paths that are described in Section 5.2.2 of the current document, to determine a
server-trunkable with the one currently being used to access the file set of network paths that are server-trunkable with the one currently
system. being used to access the file system.
When a file system is present and subsequently becomes absent, When a file system is present and subsequently becomes absent,
clients can be given the opportunity to have continued access to clients can be given the opportunity to have continued access to
their data at an alternative location. Transfer of the file system their data at an alternative file system location. Transfer of the
contents to the new location is referred to as "migration". The file system contents to the new file system location is referred to
client's responsibilities in dealing with this transition depend on as "migration". The client's responsibilities in dealing with this
the specific nature of the new access path as well as how and whether transition depend on the specific nature of the new access path as
data was in fact migrated. See Sections 6.5 and 6.6 of the current well as how and whether data was in fact migrated. See Sections
document for details. 5.2.5 and 5.2.6 of the current document for details.
The fs_locations attribute can designate one or more remote locations The fs_locations attribute can designate one or more remote file
in place of an absent file system. This is known as a "referral". A system locations in place of an absent file system. This is known as
particularly important case is that of a "pure referral", in which a "referral". A particularly important case is that of a "pure
the absent file system has never been present on the NFS server. referral", in which the absent file system has never been present on
Such a referral is a means by which a file system located on one the NFS server. Such a referral is a means by which a file system
server can redirect clients to file systems located on other servers, located on one server can redirect clients to file systems located on
thus enabling the creation of a multi-server namespace. other servers, thus enabling the creation of a multi-server
namespace.
Because client support for the fs_locations attribute is OPTIONAL, a Because client support for the fs_locations attribute is OPTIONAL, a
server may (but is not required to) take action to hide migration and server may (but is not required to) take action to hide migration and
referral events from such clients by acting as a proxy, for example. referral events from such clients by acting as a proxy, for example.
6.2. Trunking Discovery and Detection (to be added) 5.2.2. New Sub-section of Section 8.4 of [RFC7530], to be entitled
"Trunking Discovery and Detection"
Trunking is a situation in which multiple distinct network addresses Trunking is a situation in which multiple distinct network addresses
are associated with the same NFS server instance. As a matter of are associated with the same NFS server instance. As a matter of
convenience, we say that two network addresses connected to the same convenience, we say that two network addresses connected to the same
NFS server instance are server-trunkable. Section 5.4 of [RFC7931] NFS server instance are server-trunkable. Section 5.4 of [RFC7931]
explains why NFSv4 clients need to be aware of NFS server identity to explains why NFSv4 clients need to be aware of NFS server identity to
manage lease and lock state effectively when multiple connections to manage lease and lock state effectively when multiple connections to
the same server exist. the same server exist.
Trunking detection refers to a way for an NFSv4 client to confirm Trunking detection refers to a way for an NFSv4 client to confirm
skipping to change at page 10, line 38 skipping to change at page 11, line 6
so, it will be unable to perform trunking detection. so, it will be unable to perform trunking detection.
Trunking discovery is the process by which an NFSv4 client using a Trunking discovery is the process by which an NFSv4 client using a
host name or one of an NFSv4 server's network addresses can obtain host name or one of an NFSv4 server's network addresses can obtain
other candidate network addresses that are trunkable with it; i.e., a other candidate network addresses that are trunkable with it; i.e., a
set of addresses that might be connected to the same NFSv4 server set of addresses that might be connected to the same NFSv4 server
instance. An NFSv4.0 client can discover server-trunkable network instance. An NFSv4.0 client can discover server-trunkable network
addresses in a number of ways: addresses in a number of ways:
o An NFS server's host name is provided either at mount time or in a o An NFS server's host name is provided either at mount time or in a
returned location entry. A DNS query of this host name can return returned file system location entry. A DNS query of this host
more than one network address. The returned network addresses are name can return more than one network address. The returned
candidates for trunking. network addresses are candidates for trunking.
o Location entries returned in an fs_locations attribute can specify o Location entries returned in an fs_locations attribute can specify
network addresses. These network addresses are candidates for network addresses. These network addresses are candidates for
trunking. trunking.
When there is a means of trunking detection available, an NFSv4.0 When there is a means of trunking detection available, an NFSv4.0
client can confirm that a set of network addresses correspond to the client can confirm that a set of network addresses correspond to the
same NFSv4.0 server instance and thus any of them can be used to same NFSv4.0 server instance and thus any of them can be used to
access that server. access that server.
6.3. Location Attributes and Connection Type Selection (to be added) 5.2.3. New Sub-section of Section 8.4 of [RFC7530], to be entitled
"Location Attributes and Connection Type Selection"
Because of the need to support multiple connections, clients face the Because of the need to support multiple connections, clients face the
issue of determining the proper connection type to use when issue of determining the proper connection type to use when
establishing a connection to a server network address. The establishing a connection to a server network address. The
fs_locations attribute provides no information to support connection fs_locations attribute provides no information to support connection
type selection. As a result, clients supporting multiple connection type selection. As a result, clients supporting multiple connection
types need to attempt to establish a connection on various connection types need to attempt to establish a connection on various connection
types until the one preferred by the client is successfully types until the one preferred by the client is successfully
established. established.
6.4. File System Replication and Trunking (as updated) 5.2.4. Updated Section 8.4.1 of [RFC7530], entitled "File System
Replication and Trunking"
On first access to a file system, the client should obtain the value On first access to a file system, the client should obtain the value
of the set of alternative locations by interrogating the fs_locations of the set of alternative file system locations by interrogating the
attribute. Trunking discovery and/or detection can then be applied fs_locations attribute. Trunking discovery and/or detection can then
to the location entries to separate the candidate server-trunkable be applied to the file system location entries to separate the
addresses from the replica addresses that provide alternative candidate server-trunkable addresses from the replica addresses that
locations of the file system. Server-trunkable addresses may be used provide alternative locations of the file system. Server-trunkable
simultaneously to provide higher performance through the exploitation addresses may be used simultaneously to provide higher performance
of multiple paths between client and target file system. through the exploitation of multiple paths between client and target
file system.
In the event that server failures, communications problems, or other In the event that server failures, communications problems, or other
difficulties make continued access to the current file system difficulties make continued access to the current file system
impossible or otherwise impractical, the client can use the impossible or otherwise impractical, the client can use the
alternative locations as a way to maintain continued access to the alternative file system locations as a way to maintain continued
file system. See Section 6.6 of the current document for more access to the file system. See Section 5.2.6 of the current document
detail. for more detail.
6.5. File System Migration (as updated) 5.2.5. Updated Section 8.4.2 of [RFC7530], entitled "File System
Migration"
When a file system is present and becomes absent, clients can be When a file system is present and becomes absent, clients can be
given the opportunity to have continued access to their data at an given the opportunity to have continued access to their data at an
alternative location specified by the fs_locations attribute. alternative file system location specified by the fs_locations
Typically, a client will be accessing the file system in question, attribute. Typically, a client will be accessing the file system in
get an NFS4ERR_MOVED error, and then use the fs_locations attribute question, get an NFS4ERR_MOVED error, and then use the fs_locations
to determine the new location of the data. See Section 6.6 of the attribute to determine the new location of the data. See
current document for more detail. Section 5.2.6 of the current document for more detail.
Such migration can help provide load balancing or general resource Such migration can help provide load balancing or general resource
reallocation. The protocol does not specify how the file system will reallocation. The protocol does not specify how the file system will
be moved between servers. It is anticipated that a number of be moved between servers. It is anticipated that a number of
different server-to-server transfer mechanisms might be used, with different server-to-server transfer mechanisms might be used, with
the choice left to the server implementer. The NFSv4 protocol the choice left to the server implementer. The NFSv4 protocol
specifies the method used to communicate the migration event between specifies the method used to communicate the migration event between
client and server. client and server.
When an alternative location is designated as the target for When an alternative file system location is designated as the target
migration, it must designate the same data. Where file systems are for migration, it must designate the same data. Where file systems
writable, a change made on the original file system must be visible are writable, a change made on the original file system must be
on all migration targets. Where a file system is not writable but visible on all migration targets. Where a file system is not
represents a read-only copy (possibly periodically updated) of a writable but represents a read-only copy (possibly periodically
writable file system, similar requirements apply to the propagation updated) of a writable file system, similar requirements apply to the
of updates. Any change visible in the original file system must propagation of updates. Any change visible in the original file
already be effected on all migration targets, to avoid any system must already be effected on all migration targets, to avoid
possibility that a client, in effecting a transition to the migration any possibility that a client, in effecting a transition to the
target, will see any reversion in file system state. migration target, will see any reversion in file system state.
6.6. Interaction of Trunking, Migration, and Replication (to be added) 5.2.6. New Sub-section of Section 8.4 of [RFC7530], to be entitled
"Interaction of Trunking, Migration, and Replication"
When the set of network addresses designated by a location attribute When the set of network addresses designated by a file system
changes, NFS4ERR_MOVED might or might not result. In some of the location attribute changes, NFS4ERR_MOVED might or might not result.
cases in which NFS4ERR_MOVED is returned migration has occurred, In some of the cases in which NFS4ERR_MOVED is returned migration has
while in others there is a shift in the network addresses used to occurred, while in others there is a shift in the network addresses
access a particular file system with no migration. used to access a particular file system with no migration.
1. When the list of network addresses is a superset of that 1. When the list of network addresses is a superset of that
previously in effect, there is no need for migration or any other previously in effect, there is no need for migration or any other
sort of client adjustment. Nevertheless, the client is free to sort of client adjustment. Nevertheless, the client is free to
use an additional address in the replacement list if that address use an additional address in the replacement list if that address
provides another path to the same server. Or, the client may provides another path to the same server. Or, the client may
treat that address as it does a replica, to be used if current treat that address as it does a replica, to be used if current
server addresses become unavailable. server addresses become unavailable.
2. When the list of network addresses is a subset of that previously 2. When the list of network addresses is a subset of that previously
skipping to change at page 13, line 25 skipping to change at page 13, line 47
Although significant harm cannot arise from this misapprehension, it Although significant harm cannot arise from this misapprehension, it
can give rise to disconcerting situations. For example, if a lock can give rise to disconcerting situations. For example, if a lock
has been revoked during the address shift, it will appear to the has been revoked during the address shift, it will appear to the
client as if the lock has been lost during migration, normally client as if the lock has been lost during migration, normally
calling for it to be recoverable via an fs-specific grace period calling for it to be recoverable via an fs-specific grace period
associated with the migration event. associated with the migration event.
With regard to the destination server, it is desirable for the client With regard to the destination server, it is desirable for the client
to be aware of all valid network addresses that can be used to access to be aware of all valid network addresses that can be used to access
the destination server. However, there is no need for this to be the destination server. However, there is no need for this to be
done immediately. Implementations can process the additional done immediately. Implementations can process the additional file
location elements in parallel with normal use of the first valid system location elements in parallel with normal use of the first
location entry found to access the destination. valid file system location entry found to access the destination.
Because a location attribute may include entries relating to the Because a file system location attribute may include entries relating
current server, the migration destination, and possible replicas to to the current server, the migration destination, and possible
use, scanning for available network addresses could potentially be a replicas to use, scanning for available network addresses could
long process. To keep this process as short as possible, Servers are potentially be a long process. To keep this process as short as
REQUIRED to place location entries that represent addresses usable possible, Servers are REQUIRED to place file system location entries
with the current server or a migration target before those associated that represent addresses usable with the current server or a
with replicas. A client can then cease scanning for trunkable migration target before those associated with replicas. A client can
location entries once it encounters a location element whose fs_name then cease scanning for trunkable file system location entries once
differs from the current fs_name, or whose address is not server- it encounters a file system location element whose fs_name differs
trunkable with the one it is currently using. from the current fs_name, or whose address is not server-trunkable
with the one it is currently using.
7. Location Entries and Server Identity Update (as updated) 5.3. Updated Section 8.5 of [RFC7530], entitled "Location Entries and
Server Identity Update"
As mentioned above, a single location entry may have a server address As mentioned above, a single file system location entry may have a
target in the form of a DNS host name that resolves to multiple server address target in the form of a DNS host name that resolves to
network addresses, while multiple location entries may have their own multiple network addresses, while multiple file system location
server address targets that reference the same server. entries may have their own server address targets that reference the
same server.
When server-trunkable addresses for a server exist, the client may When server-trunkable addresses for a server exist, the client may
assume that for each file system in the namespace of a given server assume that for each file system in the namespace of a given server
network address, there exist file systems at corresponding namespace network address, there exist file systems at corresponding namespace
locations for each of the other server network addresses. It may do locations for each of the other server network addresses. It may do
this even in the absence of explicit listing in fs_locations. Such this even in the absence of explicit listing in fs_locations. Such
corresponding file system locations can be used as alternative corresponding file system locations can be used as alternative
locations, just as those explicitly specified via the fs_locations locations, just as those explicitly specified via the fs_locations
attribute. attribute.
8. Updates to RFC7530 Outside Section Eight 6. Updates to [RFC7530] Outside Section Eight
Since the existing description of NFS4ERR_MOVED in Section 13.1.2.4 Since the existing description of NFS4ERR_MOVED in Section 13.1.2.4
of [RFC7530] does not take proper account of trunking, it needs to be of [RFC7530] does not take proper account of trunking, it needs to be
modified by replacing the first two sentences of the description with modified by replacing the first two sentences of the description with
the following material: the following material:
The file system that contains the current filehandle object cannot The file system that contains the current filehandle object cannot
be accessed using the current network address. It may be be accessed using the current network address. It may be
accessible using other network addresses connected to the same accessible using other network addresses connected to the same
server, it may have been relocated to another server, or it may server, it may have been relocated to another server, or it may
never have been present. never have been present.
9. Security Considerations 7. Security Considerations
The Security Considerations section of [RFC7530] needs the additions The Security Considerations section of [RFC7530] needs the additions
below to properly address some aspects of trunking discovery, below to properly address some aspects of trunking discovery,
referral, migration, and replication. referral, migration, and replication.
The possibility that requests to determine the set of network The possibility that requests to determine the set of network
addresses corresponding to a given server might be interfered with addresses corresponding to a given server might be interfered with
or have their responses corrupted needs to be taken into account. or have their responses corrupted needs to be taken into account.
o When DNS is used to convert NFS server host names to network o When DNS is used to convert NFS server host names to network
addresses and DNSSEC [RFC4033] is not available, the validity addresses and DNSSEC [RFC4033] is not available, the validity
of the network addresses returned cannot be relied upon. of the network addresses returned cannot be relied upon.
However, when the client uses RPCSEC_GSS [RFC7861] to access However, when the client uses RPCSEC_GSS [RFC7861] to access
NFS servers, it is possible for mutual authentication to detect NFS servers, it is possible for mutual authentication to detect
invalid server addresses. Other forms of transport layer invalid server addresses. Other forms of transport layer
security (e.g., [RFC5246]) can also offer strong authentication security (e.g., [RFC8446]) can also offer strong authentication
of NFS servers. of NFS servers.
o Fetching location information SHOULD be performed using o Fetching file system location information SHOULD be performed
RPCSEC_GSS with integrity protection, as previously explained using RPCSEC_GSS with integrity protection, as previously
in the Security Considerations section of [RFC7530]. Making a explained in the Security Considerations section of [RFC7530].
request of this sort without using strong integrity protection Making a request of this sort without using strong integrity
permits corruption during transit of returned location protection permits corruption during transit of returned file
information. The client implementer needs to recognize that system location information. The client implementer needs to
using such information to access an NFS server without use of recognize that using such information to access an NFS server
RPCSEC_GSS (e.g., by using AUTH_SYS as defined in [RFC5531]) without use of RPCSEC_GSS (e.g., by using AUTH_SYS as defined
can result in the client interacting with an unverified network in [RFC5531]) can result in the client interacting with an
address that is posing as an NFSv4 server. unverified network address that is posing as an NFSv4 server.
o Despite the fact that it is a REQUIREMENT of [RFC7530] that o Despite the fact that it is a REQUIREMENT of [RFC7530] that
"implementations" provide "support" for the use of RPCSEC_GSS, "implementations" provide "support" for the use of RPCSEC_GSS,
it cannot be assumed that use of RPCSEC_GSS is always possible it cannot be assumed that use of RPCSEC_GSS is always possible
between any particular client-server pair. between any particular client-server pair.
o Returning only network addresses to a client that has no o Returning only network addresses to a client that has no
trusted DNS resolution service can hamper its ability to use trusted DNS resolution service can hamper its ability to use
RPCSEC_GSS. RPCSEC_GSS.
Therefore an NFSv4 server SHOULD present location entries that Therefore an NFSv4 server SHOULD present file system location
correspond to file systems on other servers using only host names. entries that correspond to file systems on other servers using
This enables the client to interrogate the fs_locations on the only host names. This enables the client to interrogate the
destination server to obtain trunking information (as well as fs_locations on the destination server to obtain trunking
replica information) using RPCSEC_GSS with integrity, validating information (as well as replica information) using RPCSEC_GSS with
the host name provided while assuring that the response has not integrity, validating the host name provided while assuring that
been corrupted. the response has not been corrupted.
When RPCSEC_GSS is not available on an NFS server, returned When RPCSEC_GSS is not available on an NFS server, returned file
location information is subject to corruption during transit and system location information is subject to corruption during
cannot be relied upon. In the case of a client being directed to transit and cannot be relied upon. In the case of a client being
another server after NFS4ERR_MOVED, this could vitiate the directed to another server after NFS4ERR_MOVED, this could vitiate
authentication provided by the use of RPCSEC_GSS on the the authentication provided by the use of RPCSEC_GSS on the
destination. Even when RPCSEC_GSS authentication is available on destination. Even when RPCSEC_GSS authentication is available on
the destination, this server might validly represent itself as the the destination, this server might validly represent itself as the
server to which the client was erroneously directed. Without a server to which the client was erroneously directed. Without a
way to decide wether the server is a valid one, the client can way to decide wether the server is a valid one, the client can
only determine, using RPCSEC_GSS, that the server corresponds to only determine, using RPCSEC_GSS, that the server corresponds to
the host name provided, with no basis for trusting that server. the host name provided, with no basis for trusting that server.
The client should not use such unverified location entries as a The client should not use such unverified file system location
basis for migration, even though RPCSEC_GSS might be available on entries as a basis for migration, even though RPCSEC_GSS might be
the destination server. available on the destination server.
When a location attribute is fetched upon connecting with an NFSv4 When a file system location attribute is fetched upon connecting
server, it SHOULD, as stated above, be done using RPCSEC_GSS with with an NFSv4 server, it SHOULD, as stated above, be done using
integrity protection. RPCSEC_GSS with integrity protection.
When location information cannot be protected in transit, the When file system location information cannot be protected in
client can subject it to additional filtering to prevent the transit, the client can subject it to additional filtering to
client from being inappropriately directed. For example, if a prevent the client from being inappropriately directed. For
range of network addresses can be determined that assure that the example, if a range of network addresses can be determined that
servers and clients using AUTH_SYS are subject to appropriate assure that the servers and clients using AUTH_SYS are subject to
constraints (such as physical network isolation and the use of appropriate constraints (such as physical network isolation and
administrative controls within the operating systems), then the use of administrative controls within the operating systems),
network adresses in this range can be used with others discarded then network adresses in this range can be used with others
or restricted in their use of AUTH_SYS. discarded or restricted in their use of AUTH_SYS.
When neither integrity protection nor filtering is possible, it is When neither integrity protection nor filtering is possible, it is
best for the client to ignore trunking and replica information or best for the client to ignore trunking and replica information or
simply not fetch the location information for these purposes. simply not fetch the file system location information for these
purposes.
To summarize considerations regarding the use of RPCSEC_GSS in To summarize considerations regarding the use of RPCSEC_GSS in
fetching location information, consider the following fetching file system location information, consider the following
possibilities for requests to interrogate location information, possibilities for requests to interrogate location information,
with interrogation approaches on the referring and destination with interrogation approaches on the referring and destination
servers arrived at separately: servers arrived at separately:
o The use of RPCSEC_GSS with integrity protection is RECOMMENDED o The use of RPCSEC_GSS with integrity protection is RECOMMENDED
in all cases, since the absence of integrity protection exposes in all cases, since the absence of integrity protection exposes
the client to the possibility of the results being modified in the client to the possibility of the results being modified in
transit. transit.
o The use of requests issued without RPCSEC_GSS (e.g., using o The use of requests issued without RPCSEC_GSS (e.g., using
AUTH_SYS), while undesirable, might be unavoidable in some AUTH_SYS), while undesirable, might be unavoidable in some
cases. Where the use of returned location information cannot cases. Where the use of returned file system location
be avoided, it should be subject to filtering to eliminate information cannot be avoided, it should be subject to
untrusted network addresses. The specifics will vary depending filtering to eliminate untrusted network addresses. The
on the degree of network isolation and whether the request is specifics will vary depending on the degree of network
to the referring or destination servers. isolation and whether the request is to the referring or
destination servers.
10. IANA Considerations 8. IANA Considerations
This document does not require actions by IANA. This document does not require actions by IANA.
11. References 9. References
11.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC5531] Thurlow, R., "RPC: Remote Procedure Call Protocol [RFC5531] Thurlow, R., "RPC: Remote Procedure Call Protocol
Specification Version 2", RFC 5531, DOI 10.17487/RFC5531, Specification Version 2", RFC 5531, DOI 10.17487/RFC5531,
May 2009, <https://www.rfc-editor.org/info/rfc5531>. May 2009, <https://www.rfc-editor.org/info/rfc5531>.
skipping to change at page 17, line 14 skipping to change at page 17, line 40
[RFC8166] Lever, C., Ed., Simpson, W., and T. Talpey, "Remote Direct [RFC8166] Lever, C., Ed., Simpson, W., and T. Talpey, "Remote Direct
Memory Access Transport for Remote Procedure Call Version Memory Access Transport for Remote Procedure Call Version
1", RFC 8166, DOI 10.17487/RFC8166, June 2017, 1", RFC 8166, DOI 10.17487/RFC8166, June 2017,
<https://www.rfc-editor.org/info/rfc8166>. <https://www.rfc-editor.org/info/rfc8166>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
11.2. Informative References 9.2. Informative References
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", Rose, "DNS Security Introduction and Requirements",
RFC 4033, DOI 10.17487/RFC4033, March 2005, RFC 4033, DOI 10.17487/RFC4033, March 2005,
<https://www.rfc-editor.org/info/rfc4033>. <https://www.rfc-editor.org/info/rfc4033>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008,
<https://www.rfc-editor.org/info/rfc5246>.
[RFC5661] Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed., [RFC5661] 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>.
[RFC7861] Adamson, A. and N. Williams, "Remote Procedure Call (RPC) [RFC7861] Adamson, A. and N. Williams, "Remote Procedure Call (RPC)
Security Version 3", RFC 7861, DOI 10.17487/RFC7861, Security Version 3", RFC 7861, DOI 10.17487/RFC7861,
November 2016, <https://www.rfc-editor.org/info/rfc7861>. November 2016, <https://www.rfc-editor.org/info/rfc7861>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
Appendix A. Section Classification Appendix A. Section Classification
All sections of this document are considered explanatory with the All sections of this document are considered explanatory with the
following exceptions. following exceptions.
o Sections 5 and 6.1 are replacement sections. o Sections 5.1 and 5.2.1 are replacement sections.
o Section 6.2 is an additional section. o Section 5.2.2 is an additional section.
o Sections 6.4 and 6.5 are replacement sections. o Sections 5.2.4 and 5.2.5 are replacement sections.
o Section 6.6 is an additional section. o Section 5.2.6 is an additional section.
o Section 7 is a replacement section. o Section 5.3 is a replacement section.
o Section 8 is an editing section. o Section 6 is an editing section.
o Section 9 is an additional section. o Section 7 is an additional section.
Acknowledgments Acknowledgments
The authors wish to thank Andy Adamson, who wrote the original The authors wish to thank Andy Adamson, who wrote the original
version of this document. All the innovation in this document is the version of this document. All the innovation in this document is the
result of Andy's work, while mistakes are best ascribed to the result of Andy's work, while mistakes are best ascribed to the
current authors. current authors.
The editor wishes to thank Greg Marsden of Oracle for his support of The editor wishes to thank Greg Marsden for his support of this work,
this work, and Rob Thurlow of Oracle for review and suggestions. and Robert Thurlow for review and suggestions.
Special thanks go to Transport Area Director Spencer Dawkins, NFSV4 Special thanks go to Transport Area Director Spencer Dawkins, NFSV4
Working Group Chairs Spencer Shepler and Brian Pawlowski, and NFSV4 Working Group Chairs Spencer Shepler and Brian Pawlowski, and NFSV4
Working Group Secretary Thomas Haynes for their support. Working Group Secretary Thomas Haynes for their ongoing support.
Authors' Addresses Authors' Addresses
Charles Lever (editor) Charles Lever (editor)
Oracle Corporation Oracle Corporation
1015 Granger Avenue 1015 Granger Avenue
Ann Arbor, MI 48104 Ann Arbor, MI 48104
United States of America United States of America
Phone: +1 248 816 6463 Phone: +1 248 816 6463
Email: chuck.lever@oracle.com Email: chuck.lever@oracle.com
David Noveck David Noveck
 End of changes. 82 change blocks. 
276 lines changed or deleted 294 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/