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

Trond Myklebust <> Fri, 12 May 2017 15:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C5FC312940F; Fri, 12 May 2017 08:22:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 3DsY3wF0Z6jM; Fri, 12 May 2017 08:22:44 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EF2F2129A99; Fri, 12 May 2017 08:17:28 -0700 (PDT)
Received: by with SMTP id o12so42085280iod.3; Fri, 12 May 2017 08:17:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=message-id:subject:from:to:cc:date:in-reply-to:references :mime-version:content-transfer-encoding; bh=ok/DMbFSz0iUuPHO/U23juZWW//kG4AujX96JrIYuqI=; b=lvtSOcu9Jn2gxATP+nZyMUpjJzMDKw9KQDLlzTBVNV/ciqelWRxZVaSfMyLp2ApwZY cqieAd4zDyF0cKRJsyMbiQK0kvNNe/Z8OmIlHoayN4SAc/TH6RSphCQ9u+YeH9uHhuRJ fNVQ2lH5kDWIljtXpQrVSPfpNuReIi1j7gaRbqD/DK/Kp6oeOL+EULBVdMbecQ6tKxPu EFUboMo4Q6MJG4t9ismRkr/uK1br7n4BMo4Qgv/31NQ71tWoRp4/UzB1u2TDf/GS9Z1g dG+AtRAL/KaxlgRWu52fs2bLgwrc5LHLeys0YLTBhZUOq3hrJ3JqJTBMsyveuldaNpmH hVtA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:mime-version:content-transfer-encoding; bh=ok/DMbFSz0iUuPHO/U23juZWW//kG4AujX96JrIYuqI=; b=PMF4Q7b7F7wNtN0m7DSIoAh87HfrCYYGdGsuZlnZymwu56qG99mfV5MuddBpVmZwdt bfw5TliOvgOGI54xAobNl71M3I0A5RbSOhcnnLA8coxFflZS8QycEHKs1apMmo8H8RDW mzkzgJ5aPwDogACgO46n4qWzQZJ+tINFshqDfW7dkuPnsvWBZT5GDcASkzBn6ug5sXUG HB/SGzDOscmhshRLuYUe8vupHfP99HK+6DJmwpN+5gMiABdNHr/GrkzDQUcAE4NXsdjK tVKMqq6D5y9cBWAKwQCNVKXpxyuMLkQKwrTv6KtKOl4KaXUMDIfl6xShj6YSTLd1h239 2H3Q==
X-Gm-Message-State: AODbwcBTfEky0eBGKdJCupvIazhzkAjUzgl4k6YcLEUdG+RHE97AHli0 V+sK1MZLchBAgA==
X-Received: by with SMTP id b12mr4097625iof.50.1494602248264; Fri, 12 May 2017 08:17:28 -0700 (PDT)
Received: from leira ( []) by with ESMTPSA id e21sm1542077ioj.15.2017. (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 12 May 2017 08:17:27 -0700 (PDT)
Message-ID: <>
From: Trond Myklebust <>
To: Spencer Dawkins <>, The IESG <>
Date: Fri, 12 May 2017 11:17:26 -0400
In-Reply-To: <>
References: <>
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.22.6 (3.22.6-2.fc25)
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
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 15:22:46 -0000

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.