--- 1/draft-ietf-nfsv4-flex-files-18.txt 2018-05-03 18:13:10.886286778 -0700 +++ 2/draft-ietf-nfsv4-flex-files-19.txt 2018-05-03 18:13:10.966288707 -0700 @@ -1,19 +1,19 @@ NFSv4 B. Halevy Internet-Draft Intended status: Standards Track T. Haynes -Expires: October 27, 2018 Hammerspace - April 25, 2018 +Expires: November 4, 2018 Hammerspace + May 03, 2018 Parallel NFS (pNFS) Flexible File Layout - draft-ietf-nfsv4-flex-files-18.txt + draft-ietf-nfsv4-flex-files-19.txt Abstract The Parallel Network File System (pNFS) allows a separation between the metadata (onto a metadata server) and data (onto a storage 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 devices in a fashion such that they require only a quite limited degree of interaction with the metadata server, using already existing protocols. Client-side mirroring is also added to provide @@ -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 October 27, 2018. + This Internet-Draft will expire on November 4, 2018. Copyright Notice Copyright (c) 2018 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 @@ -1707,36 +1707,36 @@ In cases where clients are uncommunicative and their lease has expired or when clients fail to return recalled layouts within a lease period, the server MAY revoke client layouts and reassign these resources to other clients (see Section 12.5.5 in [RFC5661]). To avoid data corruption, the metadata server MUST fence off the revoked clients from the respective data files as described in Section 2.2. 15. Security Considerations - The pNFS feature partitions the NFSv4.1+ file system protocol into - two parts, the control path and the data path (storage protocol). - The control path contains all the new operations described by this - feature; all existing NFSv4 security mechanisms and features apply to - the control path (see Sections 1.7.1 and 2.2.1 of [RFC5661]). The - combination of components in a pNFS system is required to preserve - the security properties of NFSv4.1+ with respect to an entity - accessing data via a client, including security countermeasures to - defend against threats that NFSv4.1+ provides defenses for in - environments where these threats are considered significant. - - The metadata server is primarily responsible for securing the data - path. It has to authenticate the client access and provide - appropriate credentials to the client to access data files on the - storage device. Finally, it is responsible for revoking access for a - client to the storage device. + The combination of components in a pNFS system is required to + preserve the security properties of NFSv4.1+ with respect to an + entity accessing data via a client. The pNFS feature partitions the + NFSv4.1+ file system protocol into two parts, the control protocol + and the data protocol. As the control protocol in this document is + NFS, the security properties are equivalent to that version of NFS. + The Flexible File Layout further divides the data protocol into + metadata and data paths. The security properties of the metadata + path are equivalent to those of NFSv4.1x (see Sections 1.7.1 and + 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 + storage device, with the provision that the metadata server is + responsible for authenticating client access to the data file. The + metadata server provides appropriate credentials to the client to + access data files on the storage device. It is also responsible for + revoking access for a client to the storage device. The metadata server enforces the file access-control policy at LAYOUTGET time. The client should use RPC authorization credentials for getting the layout for the requested iomode (READ or RW) and the server verifies the permissions and ACL for these credentials, possibly returning NFS4ERR_ACCESS if the client is not allowed the requested iomode. If the LAYOUTGET operation succeeds the client receives, as part of the layout, a set of credentials allowing it I/O access to the specified data files corresponding to the requested iomode. When the client acts on I/O operations on behalf of its