[nfsv4] Benjamin Kaduk's Discuss on draft-ietf-nfsv4-layout-types-10: (with DISCUSS and COMMENT)
Benjamin Kaduk <kaduk@mit.edu> Tue, 17 April 2018 22:38 UTC
Return-Path: <kaduk@mit.edu>
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 AD029124BFA; Tue, 17 Apr 2018 15:38:58 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk <kaduk@mit.edu>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-nfsv4-layout-types@ietf.org, nfsv4-chairs@ietf.org, spencer.shepler@gmail.com, nfsv4@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.78.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <152400473870.31889.11598697956073886295.idtracker@ietfa.amsl.com>
Date: Tue, 17 Apr 2018 15:38:58 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/FWI_rggmdSISYlBwAcfy-v0xgiQ>
Subject: [nfsv4] Benjamin Kaduk's Discuss on draft-ietf-nfsv4-layout-types-10: (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: Tue, 17 Apr 2018 22:38:59 -0000
Benjamin Kaduk has entered the following ballot position for draft-ietf-nfsv4-layout-types-10: 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: https://datatracker.ietf.org/doc/draft-ietf-nfsv4-layout-types/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks for writing this up; it's good to have better clarity about the requirements placed on various actors in pNFS. I will change to Yes once this issue is resolved: Section 4 leaves me confused about what exactly from RFC 5661 is being updated. That is, the subsections look to be some discussion about how the "real requirements" (i.e., this document) apply to the given layout types, and we are told that these sections do not update the specification for those specific layout types. So it's hard to get a clear picture about which specific requirements are being changed/added; this leads me to wonder if the top-level Section 4 should not say "This section updates Section 12 of [RFC5661]" and leave the "discussed here only to illuminate the updates made to Section 12 of [RFC5661]". ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 1 Such matters are defined in a standards-track layout type specification. This could be read as saying that there is a single document, which happens to be a layout-type specification and standards-track, that gives guidance on how layout types differ. Maybe: Each layout type will define the needed details for its usage in the specifciation for that layout type; layout type specifications are always standards-track RFCs. Section 3.3 [..] If the document does not impose implementation requirements sufficient to ensure that these semantic requirements are met, it is not appropriate for the working group to allow the document to move forward. Maybe "it is not appropriate for publication as an IETF-stream RFC"? o If the metadata server does not have a means to invalidate a stateid issued to the storage device to keep a particular client from accessing a specific file, then the layout type specification has to document how the metadata server is going to fence the client from access to the file on that storage device. Is the stateid issued to the storage device or to the client? Section 4 leaves me confused about what exactly from RFC 5661 is being updated. That is, the subsections look to be some discussion about how the "real requirements" (i.e., this document) apply to the given layout types, we are told that these sections do not update the specification for those specific layout types. So it's hard to get a clear picture about which specific things are being updated; this leads me to wonder if the top-level Section 4 should not say "This section updates Section 12 of [RFC5661]" and leave the "discussed here only to illuminate the updates made to Section 12 of [RFC5661[". Section 6 [...] In the latter case, I/O access writes are reflected in layouts [...] s/writes/rights/
- [nfsv4] Benjamin Kaduk's Discuss on draft-ietf-nf… Benjamin Kaduk
- Re: [nfsv4] Benjamin Kaduk's Discuss on draft-iet… Spencer Dawkins at IETF
- Re: [nfsv4] Benjamin Kaduk's Discuss on draft-iet… Tom Haynes
- Re: [nfsv4] Benjamin Kaduk's Discuss on draft-iet… Benjamin Kaduk