[nfsv4] AD Evaluation of draft-ietf-nfsv4-layout-types-08

Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> Mon, 05 February 2018 21:52 UTC

Return-Path: <spencerdawkins.ietf@gmail.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 A4A09127011; Mon, 5 Feb 2018 13:52:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 QyNlsy0EoAXr; Mon, 5 Feb 2018 13:52:21 -0800 (PST)
Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3469C12DA08; Mon, 5 Feb 2018 13:52:21 -0800 (PST)
Received: by mail-yw0-x236.google.com with SMTP id t201so19510552ywf.1; Mon, 05 Feb 2018 13:52:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=pUhZH9jYMriVy8eXFlozU4SiiyWp3o3oEfFD9gSwmAQ=; b=lDxiOATzdbJKk6hTzZlADXfYc9M3G1bNxHTvdVNOiofNBQHfHROS+stk5k7YSrAY5N BiJXFmGVIVGaRfRdqSzObbIc7G7i0aTMIBUa0ykYki+8yLK5oGyCH7VE6fJpO+k+AFe3 /gmvxR3faQ9hGzel1y06uqnQOVl/RrDKySOSD4tjNFXjkCrV22+at8PeCscj3gPsrgwX QzmQdnO/7ur9p/CAXe2SsDIiUhteNf8p2ARR2oi9p6lzW9m8GzcdoGj0hNPVuSNbPNJ/ /KJ2afr0Ng9pFQobivVUskR4mWQGX5ZVRtoo9hsTzC6kQy4CI27tO+ghov1e0078RawG HICw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=pUhZH9jYMriVy8eXFlozU4SiiyWp3o3oEfFD9gSwmAQ=; b=bVT5UZmJkkI6+EQhQDvtJXiNVK0EOEFJkgmLSNRK6neqrWEbChl7hmRiI8zG8DGLFr BYVZEb9SYMCqffN/UHvSe7OpcCXqo46C6MX+/RSqwcCUiG+nOjuIj1I0dWnZZFEksdJi 7XG1Qkeph68DPjsevyMlZTXaxoJhDohzZ+DFCR+YySELim9zNXKP2EqTI6LtkQOp5DPW 2JOPh/aWJu9zNHyOcXBGj39Z6KpspBUPfaStf5wvNRSTsJ5zRlU0rA6bBoynd/3HDkh9 7bhWw6VLhakOWu/ZSu1v1xjnFDF3M0H7VKh4L6eI9Mtk3IwiLszZWzRjDNT5ABm6QleE 2s+g==
X-Gm-Message-State: APf1xPDBj+Usy7Iz/EpI7Oj/1NTU62fD1GAX/shtbdwpPUpxwmi0tAPE +aeAZZws3YDtRG7Lztl/EehwVQJN+OXrenaaZs2l7A==
X-Google-Smtp-Source: AH8x224D3yTABbNIaLslKI+GzcgO9QYY8QCtQS07K7o7x46H33Jhjn6iScJ6Z+AwFf9YS7du2+ETmXib85Rg+IYjfl8=
X-Received: by 10.37.50.18 with SMTP id y18mr155550yby.417.1517867540137; Mon, 05 Feb 2018 13:52:20 -0800 (PST)
MIME-Version: 1.0
Received: by 10.37.21.201 with HTTP; Mon, 5 Feb 2018 13:52:19 -0800 (PST)
From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Date: Mon, 5 Feb 2018 15:52:19 -0600
Message-ID: <CAKKJt-epFo2_iiOfH1hoXzzdDeEcxk8-U4-_bpSgUAP0CvYRTw@mail.gmail.com>
To: draft-ietf-nfsv4-layout-types@ietf.org
Cc: nfsv4-chairs@ietf.org, NFSv4 <nfsv4@ietf.org>
Content-Type: multipart/alternative; boundary="001a1146dff88bcb1105647e13ea"
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/7JIHhmCVfeAkiZFGxPZe9X-PHpE>
Subject: [nfsv4] AD Evaluation of draft-ietf-nfsv4-layout-types-08
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: Mon, 05 Feb 2018 21:52:24 -0000

Dear Authors,

This draft looks quite clean. NFSv4 drafts usually do.

I did make some notes during AD Evaluation, and would like to resolve them
before requesting IETF Last Call.

Please let me know what you think.

Spencer

In this text from the 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.

I'd suggest dropping "effectively" in the last sentence.

In this text,

  The concept of layout type has a central role in the definition and
   implementation of Parallel Network File System (pNFS).  Clients and
   servers implementing different layout types behave differently in
   many ways while conforming to the overall pNFS framework defined in
   [RFC5661] and this document.

I'd suggest adding the reference to [RFC5661] at the end of the first
sentence, since that's where pNFS is defined (right?). The existing
reference to [RFC5661] in the final sentence is fine.

In this text,

  As a consequence, new internet drafts (see [FlexFiles] and [Lustre])
   may struggle to meet the requirements to be a pNFS layout type.

I'd suggest "authors of new specifications" ... "may struggle".

I understand that the Terminology section is in alphabetical order, but
could you consider whether a different organization might be helpful?
"loose coupling" and "tight coupling" seem useful to read together, for
instance, but they don't appear on the same page. If you tell me that doing
that doesn't seem helpful, I believe you …

In this text,

  layout stateid:  is a 128-bit quantity returned by a server that
      uniquely defines the layout state provided by the server for a
      specific layout that describes a layout type and file (see
      Section 12.5.2 of [RFC5661]).

I found myself wondering "unique within what scope?"

In this text,

3.  The Control Protocol

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

could you give an example of a mechanism that wouldn't be described as a
protocol? I can guess, but I'm guessing. The SCSI layout given as an
example a bit further down this section is the kind of example I'm thinking
about here.

The security considerations section deflects the reader to the security
considerations that appear in layout type specifications, but doesn't
provide any specific references to guide the user in finding such
specifications. Would it be possible to provide pointers to layout type
definition documents, even if there are only one or two that would make
sense?