Re: [nfsv4] I-D Action: draft-ietf-nfsv4-layout-types-07.txt

"Black, David" <David.Black@dell.com> Tue, 29 August 2017 21:43 UTC

Return-Path: <David.Black@dell.com>
X-Original-To: nfsv4@ietfa.amsl.com
Delivered-To: nfsv4@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CA571321B8 for <nfsv4@ietfa.amsl.com>; Tue, 29 Aug 2017 14:43:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.5
X-Spam-Level:
X-Spam-Status: No, score=-5.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dell.com header.b=SzZVq5xo; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=qJ7qi24x
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q6WUIIMU3jE8 for <nfsv4@ietfa.amsl.com>; Tue, 29 Aug 2017 14:43:00 -0700 (PDT)
Received: from esa2.dell-outbound.iphmx.com (esa2.dell-outbound.iphmx.com [68.232.149.220]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37A821321B6 for <nfsv4@ietf.org>; Tue, 29 Aug 2017 14:43:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1504042980; x=1535578980; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=uM6etuhWsLzGXYz5HmlldQpFLU2766foX1gp9I2bf5o=; b=SzZVq5xoQYRqSx4KEpqW5g7+PnUNuqFlPuTE/mRpX2BnrehAH1ow9rCa pHBx0lY/82yVlSaL/yYhAej3ITQv0bjIooT0euUrGizuxQU7iOUmfFSA+ 5c7yYTDKd/Jbx/mkuykd8hmeHArnvwZZ/gRcLiH++Fpp4jCiz+lEB35Ew 0=;
Received: from esa3.dell-outbound2.iphmx.com ([68.232.154.63]) by esa2.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Aug 2017 16:42:59 -0500
From: "Black, David" <David.Black@dell.com>
Received: from mailuogwhop.emc.com ([168.159.213.141]) by esa3.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Aug 2017 03:36:58 +0600
Received: from maildlpprd04.lss.emc.com (maildlpprd04.lss.emc.com [10.253.24.36]) by mailuogwprd04.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v7TLgvOA006341 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for <nfsv4@ietf.org>; Tue, 29 Aug 2017 17:42:57 -0400
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com v7TLgvOA006341
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1504042978; bh=F6nWGYhY76FGyA08MLilxzKqcuY=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=qJ7qi24xe5iR7vomnXlhRkFiTCk9cXq/BHtGbuSj+JH2JK/0yAJylILBC8iVaPm9r 0Nz++xy27q/PmZYdtO2tRk60KNsOkzJACQhtrtrCh96/luahv9OyLXsZpOME7oxW8d ibvgCZglskli0qM6HnUF5/vZJIkCcobPN7XJnLz0=
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com v7TLgvOA006341
Received: from mailusrhubprd01.lss.emc.com (mailusrhubprd01.lss.emc.com [10.253.24.19]) by maildlpprd04.lss.emc.com (RSA Interceptor) for <nfsv4@ietf.org>; Tue, 29 Aug 2017 17:41:46 -0400
Received: from MXHUB314.corp.emc.com (MXHUB314.corp.emc.com [10.146.3.92]) by mailusrhubprd01.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v7TLgkcq010201 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL) for <nfsv4@ietf.org>; Tue, 29 Aug 2017 17:42:46 -0400
Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB314.corp.emc.com ([10.146.3.92]) with mapi id 14.03.0352.000; Tue, 29 Aug 2017 17:42:46 -0400
To: "nfsv4@ietf.org" <nfsv4@ietf.org>
Thread-Topic: [nfsv4] I-D Action: draft-ietf-nfsv4-layout-types-07.txt
Thread-Index: AQHTIQoN3kSxKg3AvUiv46S2y9a/2qKb1OAA
Date: Tue, 29 Aug 2017 21:42:45 +0000
Message-ID: <CE03DB3D7B45C245BCA0D243277949362FC270CD@MX307CL04.corp.emc.com>
References: <150404051071.32268.12603067292136611968@ietfa.amsl.com>
In-Reply-To: <150404051071.32268.12603067292136611968@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.238.44.126]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Sentrion-Hostname: mailusrhubprd01.lss.emc.com
X-RSA-Classifications: public
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/3EPZ5b25KOLeNGWGv13ThIr0mXo>
Subject: Re: [nfsv4] I-D Action: draft-ietf-nfsv4-layout-types-07.txt
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nfsv4/>
List-Post: <mailto:nfsv4@ietf.org>
List-Help: <mailto:nfsv4-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Aug 2017 21:43:02 -0000

Reading this late in the process, I noticed a few small things:

-- Section 2.  Definitions

   control protocol:  is the particular mechanism that an implementation
      of a layout type would use to meet the control communication
      requirement for that layout type.  This need not be a protocol as
      normally understood.  In some cases the same protocol may be used
      as a control protocol and data access protocol.

"data access protocol" -> "storage protocol"  as that's the term used elsewhere in this document.

-- Section 3.1 item (2)

It might be helpful to add a sentence or two to state that these layout revocation requirements do not apply to layout recall, where the client's cooperative participation is expected (with layout revocation available as a fallback if the client does not cooperate).

-- Section 3.1 item (4).

   (4)  Interactions between locking and I/O operations MUST obey
        existing semantic restrictions.  In particular, if an I/O
        operation would be invalid when directed at the metadata server,
        it is not to be allowed when performed on the storage device.

This is easy to misread as placing responsibility for not allowing the I/O operation on the storage device.  In some layouts, the client is responsible for enforcing that.  Suggested rephrasing of the last line:

        then the I/O operation MUST also be invalid between the
        client and storage device.   Client rejection of the invalid I/O
        operation is a valid means of enforcing this requirements.
             
             
The rest of this concern is then covered by the last two paragraphs in Section 3.1 that allow different layouts to place/divide responsibility for meeting the requirements in different ways.

-- Use of ALL CAPS

This ought to be limited to RFC 2119 keywords, e.g., "REQUIREMENTS" ought to be lower case "requirements" in the titles of Sections 3.1 and 3.2, plus one instance in Section 3.2.

Also in Section 3.2:

   (1)  The metadata server MIGHT use fencing operations to the storage
        devices to enforce layout revocation against the client.

MIGHT -> MAY

-- End of Section 3.3

   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.

Referent of "it" in the second line is wrong: "it must do so" -> "then the layout type specification must require that this also be done"

Thanks, --David


> -----Original Message-----
> From: nfsv4 [mailto:nfsv4-bounces@ietf.org] On Behalf Of internet-
> drafts@ietf.org
> Sent: Tuesday, August 29, 2017 5:02 PM
> To: i-d-announce@ietf.org
> Cc: nfsv4@ietf.org
> Subject: [nfsv4] I-D Action: draft-ietf-nfsv4-layout-types-07.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Network File System Version 4 WG of the
> IETF.
> 
>         Title           : Requirements for pNFS Layout Types
>         Author          : Thomas Haynes
> 	Filename        : draft-ietf-nfsv4-layout-types-07.txt
> 	Pages           : 16
> 	Date            : 2017-08-29
> 
> 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
>    regard, this document effectively updates RFC5661.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-nfsv4-layout-types/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-nfsv4-layout-types-07
> https://datatracker.ietf.org/doc/html/draft-ietf-nfsv4-layout-types-07
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-nfsv4-layout-types-07
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> nfsv4 mailing list
> nfsv4@ietf.org
> https://www.ietf.org/mailman/listinfo/nfsv4