draft-ietf-nfsv4-flex-files-18.txt		draft-ietf-nfsv4-flex-files-19.txt
	NFSv4 B. Halevy		NFSv4 B. Halevy
	Internet-Draft		Internet-Draft
	Intended status: Standards Track T. Haynes		Intended status: Standards Track T. Haynes
	Expires: October 27, 2018 Hammerspace		Expires: November 4, 2018 Hammerspace
	April 25, 2018		May 03, 2018
	Parallel NFS (pNFS) Flexible File Layout		Parallel NFS (pNFS) Flexible File Layout
	draft-ietf-nfsv4-flex-files-18.txt		draft-ietf-nfsv4-flex-files-19.txt
	Abstract		Abstract
	The Parallel Network File System (pNFS) allows a separation between		The Parallel Network File System (pNFS) allows a separation between
	the metadata (onto a metadata server) and data (onto a storage		the metadata (onto a metadata server) and data (onto a storage
	device) for a file. The flexible file layout type is defined in this		device) for a file. The flexible file layout type is defined in this
	document as an extension to pNFS which allows the use of storage		document as an extension to pNFS which allows the use of storage
	devices in a fashion such that they require only a quite limited		devices in a fashion such that they require only a quite limited
	degree of interaction with the metadata server, using already		degree of interaction with the metadata server, using already
	existing protocols. Client-side mirroring is also added to provide		existing protocols. Client-side mirroring is also added to provide
	skipping to change at page 1, line 38 ¶		skipping to change at page 1, line 38 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on October 27, 2018.		This Internet-Draft will expire on November 4, 2018.
	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
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 37, line 16 ¶		skipping to change at page 37, line 16 ¶
	In cases where clients are uncommunicative and their lease has		In cases where clients are uncommunicative and their lease has
	expired or when clients fail to return recalled layouts within a		expired or when clients fail to return recalled layouts within a
	lease period, the server MAY revoke client layouts and reassign these		lease period, the server MAY revoke client layouts and reassign these
	resources to other clients (see Section 12.5.5 in [RFC5661]). To		resources to other clients (see Section 12.5.5 in [RFC5661]). To
	avoid data corruption, the metadata server MUST fence off the revoked		avoid data corruption, the metadata server MUST fence off the revoked
	clients from the respective data files as described in Section 2.2.		clients from the respective data files as described in Section 2.2.
	15. Security Considerations		15. Security Considerations
	The pNFS feature partitions the NFSv4.1+ file system protocol into		The combination of components in a pNFS system is required to
	two parts, the control path and the data path (storage protocol).		preserve the security properties of NFSv4.1+ with respect to an
	The control path contains all the new operations described by this		entity accessing data via a client. The pNFS feature partitions the
	feature; all existing NFSv4 security mechanisms and features apply to		NFSv4.1+ file system protocol into two parts, the control protocol
	the control path (see Sections 1.7.1 and 2.2.1 of [RFC5661]). The		and the data protocol. As the control protocol in this document is
	combination of components in a pNFS system is required to preserve		NFS, the security properties are equivalent to that version of NFS.
	the security properties of NFSv4.1+ with respect to an entity		The Flexible File Layout further divides the data protocol into
	accessing data via a client, including security countermeasures to		metadata and data paths. The security properties of the metadata
	defend against threats that NFSv4.1+ provides defenses for in		path are equivalent to those of NFSv4.1x (see Sections 1.7.1 and
	environments where these threats are considered significant.		2.2.1 of [RFC5661]). And the security properties of the data path
			are equivalent to those of the version of NFS used to access the
	The metadata server is primarily responsible for securing the data		storage device, with the provision that the metadata server is
	path. It has to authenticate the client access and provide		responsible for authenticating client access to the data file. The
	appropriate credentials to the client to access data files on the		metadata server provides appropriate credentials to the client to
	storage device. Finally, it is responsible for revoking access for a		access data files on the storage device. It is also responsible for
	client to the storage device.		revoking access for a client to the storage device.
	The metadata server enforces the file access-control policy at		The metadata server enforces the file access-control policy at
	LAYOUTGET time. The client should use RPC authorization credentials		LAYOUTGET time. The client should use RPC authorization credentials
	for getting the layout for the requested iomode (READ or RW) and the		for getting the layout for the requested iomode (READ or RW) and the
	server verifies the permissions and ACL for these credentials,		server verifies the permissions and ACL for these credentials,
	possibly returning NFS4ERR_ACCESS if the client is not allowed the		possibly returning NFS4ERR_ACCESS if the client is not allowed the
	requested iomode. If the LAYOUTGET operation succeeds the client		requested iomode. If the LAYOUTGET operation succeeds the client
	receives, as part of the layout, a set of credentials allowing it I/O		receives, as part of the layout, a set of credentials allowing it I/O
	access to the specified data files corresponding to the requested		access to the specified data files corresponding to the requested
	iomode. When the client acts on I/O operations on behalf of its		iomode. When the client acts on I/O operations on behalf of its
End of changes. 4 change blocks.
	20 lines changed or deleted		20 lines changed or added
This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/