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

David Noveck <> Fri, 12 May 2017 14:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9E65F12EBE9; Fri, 12 May 2017 07:55:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Vvabzs5sWtE6; Fri, 12 May 2017 07:55:04 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c0b::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 31C4E131456; Fri, 12 May 2017 07:49:22 -0700 (PDT)
Received: by with SMTP id e65so38450305ita.1; Fri, 12 May 2017 07:49:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=O+x5+Lh7FZYhKsDHqs8mq6My6S2YlyE0ezKMHJ4HGA0=; b=MT0RkdDhyvtXTnbNa3AUxFCUF62aFx8rfgZgG1EK8wmA4pdhb7GR/rraEyoKrbTugP O6Jn1pIGVJ1h0AzkVTkhynWjQZ766CKaDwNvLj9YJGhmRH6ZDpadkQRsU1/mnWKBgWQ3 2LXdDngpZ0OeyjbxwnUAmtUGZnQpQqILqVtwxzTt+806+0o6JNyNkStIWaMGNDITw7W5 mziYRJoiNdC7lzu9rVy5Z1bp9TZ/lD8r7rDou+6rDwsQK8VCBFB0F7cpnoZ5Ps3HOFIc /p1GPSWeylH/y2KFAPmvofVoLGHKaCCiuPm3d1pp6MPLZ+egwV5q88KRmP990y2yn0ZQ DtqA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=O+x5+Lh7FZYhKsDHqs8mq6My6S2YlyE0ezKMHJ4HGA0=; b=f0nJ2cAM5lNAI6oY/05YpdnFzYsVvrLBY+hbffXoGkVJaaOmKNf1D7EAI11DfEeABr U6GZbOkk0bxkYmXDv9uHfUwVETtDP8n735NmmNR6Au1gS3W6AbAI1iacXFWB3w60d1Vk hhTKb4tfuCVBLi9PwZIvgUA32oz4oq4O6kqCISVQZdh7IRqzk0E6GCqrEUVdYTYIZw0b Nol2JSmoK9IPn06HIYpe5p3bXcwqJfcLwrViJOCjwBWJGF1BUwymwgnYXXhUgZN6KCr4 q+s7Gfv3XmSfFdFNLem9EXBZQ2wCxjZf2r5+agLzHTOKCCESSqMUN/BvD5gA4+wyRPZD XPZg==
X-Gm-Message-State: AODbwcB/bL4fHFfXWUKqC6J4i3DXUiRNXs/Ip/y1OUvOG8YQdpox+n4a 3CZeKIhaCVBTUzCHQMoMINnCXnqifA==
X-Received: by with SMTP id t5mr3747918ite.80.1494600561257; Fri, 12 May 2017 07:49:21 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Fri, 12 May 2017 07:49:20 -0700 (PDT)
In-Reply-To: <>
References: <>
From: David Noveck <>
Date: Fri, 12 May 2017 10:49:20 -0400
Message-ID: <>
To: Spencer Dawkins <>
Cc: The IESG <>,, Spencer Shepler <>, "" <>, "" <>
Content-Type: multipart/alternative; boundary="f403045dc12a88f3e3054f54cf63"
Archived-At: <>
Subject: Re: [nfsv4] Spencer Dawkins' Yes on draft-ietf-nfsv4-versioning-09: (with COMMENT)
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NFSv4 Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 12 May 2017 14:55:06 -0000

I think this is a good idea.  I'll work on an additional paragraph for
section 6, explaining why and when an extension-supported attribute would
be helpful.

On Fri, May 12, 2017 at 10:36 AM, Spencer Dawkins <> wrote:

> 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
> 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
> attribute.
> 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.