[nfsv4] Spencer Dawkins' Yes on draft-ietf-nfsv4-versioning-09: (with COMMENT)

Spencer Dawkins <spencerdawkins.ietf@gmail.com> Fri, 12 May 2017 14:36 UTC

Return-Path: <spencerdawkins.ietf@gmail.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 54884129329; Fri, 12 May 2017 07:36:44 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Spencer Dawkins <spencerdawkins.ietf@gmail.com>
To: "The IESG" <iesg@ietf.org>
Cc: draft-ietf-nfsv4-versioning@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.50.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149459980428.13464.2287524739238339362.idtracker@ietfa.amsl.com>
Date: Fri, 12 May 2017 07:36:44 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/bXqfJ93rlL4ZommoWn9dnPMyNWI>
Subject: [nfsv4] Spencer Dawkins' Yes on draft-ietf-nfsv4-versioning-09: (with 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: Fri, 12 May 2017 14:36:44 -0000

Spencer Dawkins has entered the following ballot position for
draft-ietf-nfsv4-versioning-09: Yes

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:


Russ Housley has provided a Gen-ART review for -09 version of this
document, and the author is responding to those comments.

I did have one question that came up during AD Evaluation that I wanted
to mention.

The first two drafts that used this mechanism (umask and xattrs) used two
different idioms for discovering support. The xaddrs draft defines an
xaddr_support attribute, while umask does not.

In conversations with the working group, the reasoning was that xattrs
defines a number of operations, so discovering that the complete
mechanism is supported before you start trying to use the attributes
makes sense, while umask defines only one attribute, and for any
attribute, you can find out if it is supported within a given file system
by interrogating the appropriate bit position in the REQUIRED attribute
supported_attrs, so there is no advantage to adding a umask_support

That all made perfect sense to me, but the explanation was helpful enough
to me that I wonder if it's worth a sentence or two, pointing out that
some protocol designers may choose one idiom, while other protocol
designers choose the other, and saying that's not a problem.

If the answer is "that explanation isn't needed", that won't change my
ballot position from Yes, of course.