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

Thomas Haynes <> Tue, 29 August 2017 22:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7DBC8132A87 for <>; Tue, 29 Aug 2017 15:25:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Y3KhELOiLBF8 for <>; Tue, 29 Aug 2017 15:25:19 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9FA01126DD9 for <>; Tue, 29 Aug 2017 15:25:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=mimecast20170802; t=1504045518; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references; bh=B/vkNfxPpzge0KHNussrjIYQKReS+qmwDc+SkXgyUgY=; b=Q6LQe8DOIS0/Xsf2/ixzTUfnygxmJe6Yu7QzBi5Yj2H1ebPGcudXigOP5Gi/fUTck6tW4mZ+hiuwf3c3FCfgZcurEDhnpPQIH2gno9pd7WoXjh+VCI8yVGK6ZGT8gH8Z2V1nRiQFhXLpA396Wuvze96+7PSA9WQQavXBfN2hSUg=
Received: from ( []) (Using TLS) by with ESMTP id us-mta-135-svXAqzufOFWFuWT0YjQhSw-1; Tue, 29 Aug 2017 18:25:08 -0400
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1385.9; Tue, 29 Aug 2017 22:25:04 +0000
Received: from ([]) by ([]) with mapi id 15.01.1385.014; Tue, 29 Aug 2017 22:25:04 +0000
From: Thomas Haynes <>
To: "Black, David" <>
CC: "" <>
Thread-Topic: [nfsv4] I-D Action: draft-ietf-nfsv4-layout-types-07.txt
Thread-Index: AQHTIQoOAxgUa3TpG0Kx1WmFKsuq4aKb3WuAgAAL0oA=
Date: Tue, 29 Aug 2017 22:25:04 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BY2PR1101MB1127; 20:gXymDfIJoYicC8kTekNjdCKieDjLD0haLVKLAbg+oWuEEy8FwJ0eeUpGwqaGP7wQRI5v6rABSBMmdII37nWgOGMDkcUqKgdE53Tu9sgdkX9W4gfO0i2hcg0ib4FTiqEyszSkGotW3jmgukFPF5MeBFw2b6jkznvZu4AceL0gTZI=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 4f97c28a-3559-4a0f-cd45-08d4ef2ccbe6
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(2017082002075)(300000503095)(300135400095)(2017052603199)(201703131423075)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BY2PR1101MB1127;
x-ms-traffictypediagnostic: BY2PR1101MB1127:
x-exchange-antispam-report-test: UriScan:(158342451672863)(120809045254105)(56004941905204);
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(10201501046)(3002001)(93006095)(93001095)(6041248)(20161123560025)(20161123564025)(20161123562025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(2016111802025)(6043046)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BY2PR1101MB1127; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BY2PR1101MB1127;
x-forefront-prvs: 0414DF926F
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39830400002)(51914003)(189002)(24454002)(199003)(377424004)(13464003)(377454003)(8936002)(66066001)(81156014)(6916009)(81166006)(82746002)(14454004)(36756003)(229853002)(101416001)(97736004)(230783001)(53546010)(2900100001)(2950100002)(966005)(83716003)(8676002)(2906002)(5660300001)(54356999)(6506006)(6436002)(33656002)(76176999)(50986999)(189998001)(102836003)(6306002)(86362001)(6512007)(99286003)(8666007)(305945005)(7736002)(6116002)(6246003)(3660700001)(68736007)(6486002)(110136004)(3280700002)(53936002)(77096006)(106356001)(25786009)(478600001)(105586002)(3846002)(4326008)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR1101MB1127;; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-ID: <>
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Aug 2017 22:25:04.3488 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 03193ed6-8726-4bb3-a832-18ab0d28adb7
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR1101MB1127
X-MC-Unique: svXAqzufOFWFuWT0YjQhSw-1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: base64
Archived-At: <>
Subject: Re: [nfsv4] I-D Action: draft-ietf-nfsv4-layout-types-07.txt
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NFSv4 Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 29 Aug 2017 22:25:22 -0000

Hi David,

Thanks for the review - only one contention and one major change in my replies.

> On Aug 29, 2017, at 2:42 PM, Black, David <> wrote:
> 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.

I *thought* I eradicated all of those?

Ah, I got rid of data storage protocol.


> -- 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).


          The metadata
          server typically would revoke a layout whenever a client fails
          to respond to a recall or a client's lease is expired due to

Is it too subtle?

And remember we did define both revoking and recalling a layout in Section 2.

> -- 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.

I agree with your analysis.

>  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.

Going with the format in the third item, how about this:

   (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.

        For the block and SCSI layout, as the storage device is not able
        to reject the I/O operation, the client is responsible for
        enforcing this requirement.

> 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.

This has already flipped once per review.

Argh, Section 3.3 is not consistent.

I’m going to go with we haven’t been consistent outside of titles (and evidently within) and I find it to read better in lowercase.

Changes made.

> Also in Section 3.2:
>   (1)  The metadata server MIGHT use fencing operations to the storage
>        devices to enforce layout revocation against the client.


> -- 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 [] On Behalf Of internet-
>> Sent: Tuesday, August 29, 2017 5:02 PM
>> To:
>> Cc:
>> 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:
>> There are also htmlized versions available at:
>> A diff from the previous version is available at:
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at
>> Internet-Drafts are also available by anonymous FTP at:
>> _______________________________________________
>> nfsv4 mailing list
> _______________________________________________
> nfsv4 mailing list