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

From: "Mirja Kuehlewind" <[email-masked]>
Date: Thu, 01 Sep 2016 06:28:44 -0700

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!

---

From: Christoph Hellwig <[email-masked]>
Date: Sun, 4 Sep 2016 15:21:56 +0200

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

Sounds fine.

>    be trusted to enforce such policies, pNFS SCSI layouts SHOULD NOT be

I can change this.

> Should this be network interfaces instead on network ports?

That might be the better terminology, I can change that.

> upper case SHOULDs and MAYs could be used. Please check!

I will audit the usage.  This section has been taken almost 1:1 from
RFC5663 and passed there, but updating them will improve the document.