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

Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> Thu, 25 May 2017 16:13 UTC

Return-Path: <spencerdawkins.ietf@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 9A707127369; Thu, 25 May 2017 09:13:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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_NONE=-0.0001, SPF_PASS=-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 GuFMefS7ukHF; Thu, 25 May 2017 09:13:33 -0700 (PDT)
Received: from mail-yb0-x231.google.com (mail-yb0-x231.google.com [IPv6:2607:f8b0:4002:c09::231]) (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 3FD22124B0A; Thu, 25 May 2017 09:13:33 -0700 (PDT)
Received: by mail-yb0-x231.google.com with SMTP id 130so35491844ybl.3; Thu, 25 May 2017 09:13:33 -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=iLweGJ1TmauWohJL47yvQEIHe/QaYWUwywXVzzZLb6A=; b=t6nDE6BVg3hTIJ97zl1kmEdMx+Ov96qAsT0mw6RU2RjWLIIbGB9lDajTfkOv/Vz+UJ duNd3bygqDYLICkYG2h5HNfLCMtfuw03Pt8GrOhfP7Fz9QeILm6J86QPuY9K+9tPwAPR JoCH7FNMP8imI785gvL2CC4QV/O3xjrVEb36U8x9e77Qb6e47tqA1j0Qd4L8KkUuTeTI n/0lSpJGg9lUoAU5/v8Od/wyOVXfMIXwk/hHG0QDQ1bFF14ct/wNXJPkLLuHq78n7D8Z 8wpLR9mdYmR6bddzq+ZHND98BqFXOIblWjpT5EYM42FJHMDUYK33/gLilt0mE5/89or5 Y1Jw==
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=iLweGJ1TmauWohJL47yvQEIHe/QaYWUwywXVzzZLb6A=; b=mkAfC8M+y24cLUZVC1TRUhBU102HnAPSf1/z4s6kR+q2WqSTf1jBjAGs5Tk93LHqsb RtV59Fhf8P3EEcu/ztAzs8muY+X3VE4qek14M8OzXGeAqsfTLx1gEXRrqJ2mRYkHB9l7 vMjs1KiPtIylG6faZuYlIARfLFfJt+TTVnS+dLeUlszajORBO0q7No9CPcyPWc4nd6Bw p7v4yCgtWD45hxvVT/bVxTCCzaeYcMbjT9Wcx48u3Z7mxB/+PYaskeqzsMiKf0EjgvnL FMcSyIGZFiqJdAavdoDwfx4eHy0aIzYFYkyo6y0nlwt69HE6RAiAWpH3lcEfzhjRosEo A73A==
X-Gm-Message-State: AODbwcAb4QckMRsdk9xgnF3sjkAsOuvbqKvjFRGVXR6fnJjenxWobMlP 9cZryJFSEiCqvuqOhLbYLo5i+bpf5w==
X-Received: by 10.37.193.71 with SMTP id r68mr10737005ybf.51.1495728812465; Thu, 25 May 2017 09:13:32 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.195.195 with HTTP; Thu, 25 May 2017 09:13:31 -0700 (PDT)
In-Reply-To: <1494602246.10434.3.camel@gmail.com>
References: <149459980428.13464.2287524739238339362.idtracker@ietfa.amsl.com> <1494602246.10434.3.camel@gmail.com>
From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Date: Thu, 25 May 2017 12:13:31 -0400
Message-ID: <CAKKJt-c=K-V0OPX3gk1bFGG9qwKTYuULn-ANd=7=fy=sZ5r_mA@mail.gmail.com>
To: Trond Myklebust <trondmy@gmail.com>
Cc: The IESG <iesg@ietf.org>, nfsv4-chairs@ietf.org, NFSv4 <nfsv4@ietf.org>, draft-ietf-nfsv4-versioning@ietf.org
Content-Type: multipart/alternative; boundary="001a114ea9108c4a3805505b80a0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/1Jpr1fN5QgkrTtR-ZgMi_fliRA4>
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: Thu, 25 May 2017 16:13:35 -0000

Dear -versioning- folk,

On Fri, May 12, 2017 at 11:17 AM, Trond Myklebust <trondmy@gmail.com> wrote:

> On Fri, 2017-05-12 at 07:36 -0700, Spencer Dawkins wrote:
> >
> > 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.
> >
>
> It's an extra mechanism that could be a convenience, but is not
> something that a client can or should rely on. The only reliable
> mechanism for verifying that the feature is available is to try it, and
> handle the resulting NFS4ERR_NOTSUPP and/or NFS4ERR_OP_ILLEGAL error.
>
> This is how the Linux client handles all the other NFSv4.x optional
> features as well.


This draft was approved on today's telechat, but the secretariat is holding
off sending the approval announcement until I let them know that all the
comments have been addressed.

It looked like David had a plan for this specific comment on idioms for
detecting support, and Trond had a response, so if others have thoughts
that would affect the text that appears in the RFC, it would be great to
hear that, Real Soon Now.

Thanks!

Spencer (D)