draft-ietf-nfsv4-layout-types-06.txt		draft-ietf-nfsv4-layout-types-07.txt
	NFSv4 T. Haynes		NFSv4 T. Haynes
	Internet-Draft Primary Data		Internet-Draft Primary Data
	Updates: 5661 (if approved) August 16, 2017		Updates: 5661 (if approved) August 29, 2017
	Intended status: Standards Track		Intended status: Standards Track
	Expires: February 17, 2018		Expires: March 2, 2018
	Requirements for pNFS Layout Types		Requirements for pNFS Layout Types
	draft-ietf-nfsv4-layout-types-06.txt		draft-ietf-nfsv4-layout-types-07.txt
	Abstract		Abstract
	This document defines the requirements which individual pNFS layout		This document defines the requirements which individual pNFS layout
	types need to meet in order to work within the parallel NFS (pNFS)		types need to meet in order to work within the parallel NFS (pNFS)
	framework as defined in RFC5661. In so doing, it aims to clearly		framework as defined in RFC5661. In so doing, it aims to clearly
	distinguish between requirements for pNFS as a whole and those		distinguish between requirements for pNFS as a whole and those
	specifically directed to the pNFS File Layout. The lack of a clear		specifically directed to the pNFS File Layout. The lack of a clear
	separation between the two set of requirements has been troublesome		separation between the two set of requirements has been troublesome
	for those specifying and evaluating new Layout Types. In this		for those specifying and evaluating new Layout Types. In this
	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 February 17, 2018.		This Internet-Draft will expire on March 2, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2017 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 6, line 39 ¶		skipping to change at page 6, line 39 ¶
	(2) any particular requirement applies to those defining layout		(2) any particular requirement applies to those defining layout
	types.		types.
	(3) the requirement is a general requirement which implementations		(3) the requirement is a general requirement which implementations
	need to conform to, with the specific means left to layout type		need to conform to, with the specific means left to layout type
	definitions type to specify.		definitions type to specify.
	3. The Control Protocol		3. The Control Protocol
	One of the key requirements of a layout type is the need for a		A layout type has to meet the requirements that apply to the
	mechanism to be used to meet the requirements that apply to the
	interaction between the metadata server and the storage device such		interaction between the metadata server and the storage device such
	that they present a consistent interface to the client		that they present to the client a consistent view of stored data and
	(Section 12.2.6 of [RFC5661]). Particular implementations may		lock state (Section 12.2.6 of [RFC5661]). Particular implementations
	satisfy this requirement in any manner they choose and the mechanism		may satisfy these requirements in any manner they choose and the
	chosen may not be described as a protocol. Specifications defining		mechanism chosen need not be described as a protocol. Specifications
	layout types need to clearly show how implementations can meet the		defining layout types need to clearly show how implementations can
	requirements discussed below, especially with respect to those that		meet the requirements discussed below, especially with respect to
	have security implications. In addition, such specifications may		those that have security implications. In addition, such
	find it necessary to impose requirements on implementations of the		specifications may find it necessary to impose requirements on
	layout type to ensure appropriate interoperability.		implementations of the layout type to ensure appropriate
			interoperability.
	In some cases, there may be no control protocol other than the		In some cases, there may be no control protocol other than the
	storage protocol. This is often described as using a "loose		storage protocol. This is often described as using a "loose
	coupling" model. In such cases, the assumption is that the metadata		coupling" model. In such cases, the assumption is that the metadata
	server, storage devices, and client may be changed independently and		server, storage devices, and client may be changed independently and
	that the implementation requirements in the layout type specification		that the implementation requirements in the layout type specification
	need to ensure this degree of interoperability. This model is used		need to ensure this degree of interoperability. This model is used
	in the block and object layout type specification.		in the block and object layout type specification.
	In other cases, it is assumed that there will be a purpose-built		In other cases, it is assumed that there will be a purpose-built
	skipping to change at page 11, line 11 ¶		skipping to change at page 11, line 11 ¶
	from accessing a specific file, then the layout type specification		from accessing a specific file, then the layout type specification
	has to document how the metadata server is going to fence the		has to document how the metadata server is going to fence the
	client from access to the file on that storage device.		client from access to the file on that storage device.
	o If the metadata server implements mandatory byte-range locking		o If the metadata server implements mandatory byte-range locking
	when accessed directly by the client, it must do so when data is		when accessed directly by the client, it must do so when data is
	read or written using the designated storage protocol.		read or written using the designated storage protocol.
	4. Specifications of Original Layout Types		4. Specifications of Original Layout Types
	This section is not normative with regards to each of the presented		This section updates Section 12 of [RFC5661], which enumerates the
	types. This document does not update the specification of either the		requirements of pNFS layout type specifications. It is not normative
	block layout type (see [RFC5663]) or the object layout type (see		with regards to the file layout type presented in Section 13 of
	[RFC5664]). Nor does it update Section 13 of [RFC5661], but rather		[RFC5661], the block layout type [RFC5663], and the object layout
	Section 12 of that document. In other words, it is the pNFS		type [RFC5664]. These are discussed here only to illuminate the
	requirements being updated rather than the specification of the file		updates made to Section 12 of [RFC5661].
	layout type.
	4.1. File Layout Type		4.1. File Layout Type
	Because the storage protocol is a subset of NFSv4.1, the semantics of		Because the storage protocol is a subset of NFSv4.1, the semantics of
	the file layout type comes closest to the semantics of NFSv4.1 in the		the file layout type comes closest to the semantics of NFSv4.1 in the
	absence of pNFS. In particular, the stateid and principal used for I		absence of pNFS. In particular, the stateid and principal used for I
	/O MUST have the same effect and be subject to the same validation on		/O MUST have the same effect and be subject to the same validation on
	a data server as it would have if the I/O were being performed on the		a data server as it would have if the I/O were being performed on the
	metadata server itself. The same set of validations are applied		metadata server itself. The same set of validations are applied
	whether pNFS is in effect or not.		whether pNFS is in effect or not.
End of changes. 7 change blocks.
	22 lines changed or deleted		21 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/