[nfsv4] Eric Rescorla's Discuss on draft-ietf-nfsv4-flex-files-15: (with DISCUSS and COMMENT)

Eric Rescorla <ekr@rtfm.com> Wed, 24 January 2018 21:48 UTC

Return-Path: <ekr@rtfm.com>
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 E48E212D77D; Wed, 24 Jan 2018 13:48:21 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Eric Rescorla <ekr@rtfm.com>
To: "The IESG" <iesg@ietf.org>
Cc: draft-ietf-nfsv4-flex-files@ietf.org, Spencer Shepler <spencer.shepler@gmail.com>, nfsv4-chairs@ietf.org, spencer.shepler@gmail.com, nfsv4@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.70.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151683050192.22597.10931170494891133045.idtracker@ietfa.amsl.com>
Date: Wed, 24 Jan 2018 13:48:21 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/2SqUeNLxWrw0-qpo6vpMttSpEIg>
Subject: [nfsv4] Eric Rescorla's Discuss on draft-ietf-nfsv4-flex-files-15: (with DISCUSS and COMMENT)
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.22
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: Wed, 24 Jan 2018 21:48:22 -0000

Eric Rescorla has entered the following ballot position for
draft-ietf-nfsv4-flex-files-15: Discuss

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:


I concur with Kathleen's discuss. To put a finer point on it, I think the
security considerations section here needs to really clearly state what the
security properties of this design are and how they differ from existing NFS.
That's not true yes.


- I'm a bit confused on whether the client can tell which model the server is using. I see:

   An implementation can always be deployed as a loosely coupled model.
   There is however no way for a storage device to indicate over a NFS
   protocol that it can definitively participate in a tightly coupled

But then there is a flag that you use to indicate you are tightly coupled. So I'm confused.

- I note that some of your PDUs have /// in front and some do not. E.g., Section 5. Is that a bug.

- S 2.2.
" Note: it is recommended to implement common access control methods at"

Do you want RECOMMENDED.