IETF Logo Mail Archive

Re: [nfsv4] Review of draft-ietf-nfsv4-rfc5667bis-09

Chuck Lever <chuck.lever@oracle.com> Mon, 24 April 2017 14:46 UTC

Return-Path: <chuck.lever@oracle.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 0854E1315AB for <nfsv4@ietfa.amsl.com>; Mon, 24 Apr 2017 07:46:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
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 NvpLsR-T5-Si for <nfsv4@ietfa.amsl.com>; Mon, 24 Apr 2017 07:46:29 -0700 (PDT)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E73B01315AE for <nfsv4@ietf.org>; Mon, 24 Apr 2017 07:46:05 -0700 (PDT)
Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v3OEk54x029082 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <nfsv4@ietf.org>; Mon, 24 Apr 2017 14:46:05 GMT
Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0021.oracle.com (8.13.8/8.14.4) with ESMTP id v3OEk5Of009584 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <nfsv4@ietf.org>; Mon, 24 Apr 2017 14:46:05 GMT
Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v3OEk4H4015561 for <nfsv4@ietf.org>; Mon, 24 Apr 2017 14:46:05 GMT
Received: from anon-dhcp-171.1015granger.net (/68.46.169.226) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 24 Apr 2017 07:46:04 -0700
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Chuck Lever <chuck.lever@oracle.com>
In-Reply-To: <413d4364-6652-d571-7377-fc2d7a266838@oracle.com>
Date: Mon, 24 Apr 2017 10:46:04 -0400
Content-Transfer-Encoding: 7bit
Message-Id: <7ACCDB13-E13B-4241-A1D9-C71DB187671E@oracle.com>
References: <CADaq8jdkGgL+H-yoO-+bTNbSYiE_1us9cN5SXY8QV0gfYfK0Ng@mail.gmail.com> <ce42960d-d1e9-8fa6-e98e-3e9b1a2af7d6@oracle.com> <f66e8e66-ba54-ff57-945a-7951eab2f8b1@talpey.com> <BB65A737-BDBD-4A23-9CEE-2EA153293842@oracle.com> <33468014-6695-a2da-1af8-f1f355fbe986@talpey.com> <CADaq8jcJJQ3TiVX6fFURg22YgNg=Cd7ezNQewjt6fgNK4LrPVg@mail.gmail.com> <F417EA11-D49F-420D-A64F-AE6A382B920C@oracle.com> <7213a956-6157-d0a6-432d-1da8d555d8e9@talpey.com> <413d4364-6652-d571-7377-fc2d7a266838@oracle.com>
To: NFSv4 <nfsv4@ietf.org>
X-Mailer: Apple Mail (2.3124)
X-Source-IP: aserv0021.oracle.com [141.146.126.233]
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/T-255jren_1MzLInMWLcj_ypJSA>
Subject: Re: [nfsv4] Review of draft-ietf-nfsv4-rfc5667bis-09
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: Mon, 24 Apr 2017 14:46:31 -0000

> On Apr 24, 2017, at 10:36 AM, karen deitke <karen.deitke@oracle.com> wrote:
> 
> 
> 
> On 4/24/2017 5:56 AM, Tom Talpey wrote:
>> On 4/21/2017 10:43 AM, Chuck Lever wrote:
>>> I agree that SHOULD/MAY makes things cloudier, and does not
>>> seem to align with well-defined RFC2119 usage.
>>> 
>>> Another way we've dealt with similar disagreements between
>>> specification and implementation is to decide that one of
>>> the implementations is incorrect.
>>> 
>>> Can we agree that:
>>> 
>>> - GARBAGE_ARGS is a bit of a layering violation, though it's
>>> understandable why it might be returned
>>> 
>>> - RPC clients are already prepared for GARBAGE_ARGS
>> 
>> Are you certain of this? And out of curiosity, what is returned
>> to the consumer for GARBAGE_ARGS versus ERR_CHUNK?
> Consumer will see EIO for both.

On Solaris.

On Linux, EIO for ERR_CHUNK, and EACCES for GARBAGE_ARGS
(historical behavior).


--
Chuck Lever

v2.23.0 | Report a Bug | By Email