--- 1/draft-ietf-nfsv4-layout-types-06.txt 2017-08-29 14:13:10.017669266 -0700 +++ 2/draft-ietf-nfsv4-layout-types-07.txt 2017-08-29 14:13:10.053670137 -0700 @@ -1,19 +1,19 @@ NFSv4 T. Haynes Internet-Draft Primary Data -Updates: 5661 (if approved) August 16, 2017 +Updates: 5661 (if approved) August 29, 2017 Intended status: Standards Track -Expires: February 17, 2018 +Expires: March 2, 2018 Requirements for pNFS Layout Types - draft-ietf-nfsv4-layout-types-06.txt + draft-ietf-nfsv4-layout-types-07.txt Abstract This document defines the requirements which individual pNFS layout 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 distinguish between requirements for pNFS as a whole and those specifically directed to the pNFS File Layout. The lack of a clear separation between the two set of requirements has been troublesome for those specifying and evaluating new Layout Types. In this @@ -27,21 +27,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -265,32 +265,32 @@ (2) any particular requirement applies to those defining layout types. (3) the requirement is a general requirement which implementations need to conform to, with the specific means left to layout type definitions type to specify. 3. The Control Protocol - One of the key requirements of a layout type is the need for a - mechanism to be used to meet the requirements that apply to the + A layout type has to meet the requirements that apply to the interaction between the metadata server and the storage device such - that they present a consistent interface to the client - (Section 12.2.6 of [RFC5661]). Particular implementations may - satisfy this requirement in any manner they choose and the mechanism - chosen may not be described as a protocol. Specifications defining - layout types need to clearly show how implementations can meet the - requirements discussed below, especially with respect to those that - have security implications. In addition, such specifications may - find it necessary to impose requirements on implementations of the - layout type to ensure appropriate interoperability. + that they present to the client a consistent view of stored data and + lock state (Section 12.2.6 of [RFC5661]). Particular implementations + may satisfy these requirements in any manner they choose and the + mechanism chosen need not be described as a protocol. Specifications + defining layout types need to clearly show how implementations can + meet the requirements discussed below, especially with respect to + those that have security implications. In addition, such + specifications may find it necessary to impose requirements on + implementations of the layout type to ensure appropriate + interoperability. In some cases, there may be no control protocol other than the storage protocol. This is often described as using a "loose coupling" model. In such cases, the assumption is that the metadata server, storage devices, and client may be changed independently and that the implementation requirements in the layout type specification need to ensure this degree of interoperability. This model is used in the block and object layout type specification. In other cases, it is assumed that there will be a purpose-built @@ -472,27 +472,26 @@ from accessing a specific file, then the layout type specification has to document how the metadata server is going to fence the client from access to the file on that storage device. o If the metadata server implements mandatory byte-range locking when accessed directly by the client, it must do so when data is read or written using the designated storage protocol. 4. Specifications of Original Layout Types - This section is not normative with regards to each of the presented - types. This document does not update the specification of either the - block layout type (see [RFC5663]) or the object layout type (see - [RFC5664]). Nor does it update Section 13 of [RFC5661], but rather - Section 12 of that document. In other words, it is the pNFS - requirements being updated rather than the specification of the file - layout type. + This section updates Section 12 of [RFC5661], which enumerates the + requirements of pNFS layout type specifications. It is not normative + with regards to the file layout type presented in Section 13 of + [RFC5661], the block layout type [RFC5663], and the object layout + type [RFC5664]. These are discussed here only to illuminate the + updates made to Section 12 of [RFC5661]. 4.1. File Layout Type 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 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 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 whether pNFS is in effect or not.