[nfsv4] Mirja Kühlewind's No Objection on draft-ietf-nfsv4-scsi-layout-08: (with COMMENT)

"Mirja Kuehlewind" <ietf@kuehlewind.net> Thu, 01 September 2016 13:28 UTC

Return-Path: <ietf@kuehlewind.net>
X-Original-To: nfsv4@ietf.org
Delivered-To: nfsv4@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AB93D12DB76; Thu, 1 Sep 2016 06:28:44 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Mirja Kuehlewind <ietf@kuehlewind.net>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.31.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <147273652465.10237.7261711668591428605.idtracker@ietfa.amsl.com>
Date: Thu, 01 Sep 2016 06:28:44 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/CYDqoWGqRrR_quNUhGaYUrdzSsU>
Cc: nfsv4-chairs@ietf.org, nfsv4@ietf.org, draft-ietf-nfsv4-scsi-layout@ietf.org
Subject: [nfsv4] Mirja Kühlewind's No Objection on draft-ietf-nfsv4-scsi-layout-08: (with COMMENT)
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.17
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: Thu, 01 Sep 2016 13:28:45 -0000

Mirja Kühlewind has entered the following ballot position for
draft-ietf-nfsv4-scsi-layout-08: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-nfsv4-scsi-layout/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Nits:

1) Maybe spell out what RFC5663 is about...?
OLD:
"[RFC6688] is unnecessary in the context of the SCSI layout type because
the new
   layout type provides mandatory disk access protection as part of the
   layout type definition."
NEW
"pNFS Block Disk Protection [RFC6688] is unnecessary in the context 
   of the SCSI layout type because the new layout type provides mandatory

   disk access protection as part of the layout type definition."

2) Why is this not a MUST?
"Since SCSI storage devices are generally not capable of enforcing
   such file-based security, in environments where pNFS clients cannot
   be trusted to enforce such policies, pNFS SCSI layouts SHOULD NOT be
   used."

3) "Storage devices such as storage arrays can have multiple physical
   network ports that need not be connected to a common network"
Should this be network interfaces instead on network ports?

4) "The client SHOULD track the number of
   retries, and if forward progress is not made, the client should
   abandon the attempt to get a layout and perform READ and WRITE
   operations by sending them to the server"
Should the second 'should' also be upper case?
I believe there are actually more cases (at least in this section) where
upper case SHOULDs and MAYs could be used. Please check!