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

David Noveck <davenoveck@gmail.com> Fri, 12 May 2017 14:55 UTC

Return-Path: <davenoveck@gmail.com>
X-Original-To: nfsv4@ietfa.amsl.com
Delivered-To: nfsv4@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E65F12EBE9; Fri, 12 May 2017 07:55:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vvabzs5sWtE6; Fri, 12 May 2017 07:55:04 -0700 (PDT)
Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31C4E131456; Fri, 12 May 2017 07:49:22 -0700 (PDT)
Received: by mail-it0-x22d.google.com with SMTP id e65so38450305ita.1; Fri, 12 May 2017 07:49:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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; d=1e100.net; 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 10.36.175.5 with SMTP id t5mr3747918ite.80.1494600561257; Fri, 12 May 2017 07:49:21 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.17.18 with HTTP; Fri, 12 May 2017 07:49:20 -0700 (PDT)
In-Reply-To: <149459980428.13464.2287524739238339362.idtracker@ietfa.amsl.com>
References: <149459980428.13464.2287524739238339362.idtracker@ietfa.amsl.com>
From: David Noveck <davenoveck@gmail.com>
Date: Fri, 12 May 2017 10:49:20 -0400
Message-ID: <CADaq8jcRVBO2m+mTin7bEoq3We-D6K2=qgYJ+L4HdRK6btgzWQ@mail.gmail.com>
To: Spencer Dawkins <spencerdawkins.ietf@gmail.com>
Cc: The IESG <iesg@ietf.org>, draft-ietf-nfsv4-versioning@ietf.org, Spencer Shepler <spencer.shepler@gmail.com>, "nfsv4-chairs@ietf.org" <nfsv4-chairs@ietf.org>, "nfsv4@ietf.org" <nfsv4@ietf.org>
Content-Type: multipart/alternative; boundary="f403045dc12a88f3e3054f54cf63"
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/xNhw-wtCdwtbfQ3YUNkFG5gXvwM>
Subject: Re: [nfsv4] Spencer Dawkins' Yes on draft-ietf-nfsv4-versioning-09: (with COMMENT)
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
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: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 <
spencerdawkins.ietf@gmail.com> 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 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-versioning/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> 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.
>
>
>