Re: [nfsv4] Review of draft-ietf-nfsv4-rfc5667bis-06
Chuck Lever <chuck.lever@oracle.com> Mon, 27 February 2017 16:33 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 161AA129965 for <nfsv4@ietfa.amsl.com>; Mon, 27 Feb 2017 08:33:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level:
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, 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 cRuMVyGJiSkt for <nfsv4@ietfa.amsl.com>; Mon, 27 Feb 2017 08:33:08 -0800 (PST)
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 E44C612A1F9 for <nfsv4@ietf.org>; Mon, 27 Feb 2017 08:33:07 -0800 (PST)
Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v1RGX5SE012334 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 27 Feb 2017 16:33:06 GMT
Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v1RGX5KJ001629 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 27 Feb 2017 16:33:05 GMT
Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id v1RGX3Rj029620; Mon, 27 Feb 2017 16:33:04 GMT
Received: from dhcp184.cthon.org (/70.213.12.227) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 27 Feb 2017 08:33:02 -0800
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: <CADaq8jeX4LiFeeq7ruPKQgwBhBHze6=bfvUOzRMcriLm-Zrn+Q@mail.gmail.com>
Date: Mon, 27 Feb 2017 08:33:00 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <CCB7ED5F-5CC8-4B37-99F3-0BBBB85DACD0@oracle.com>
References: <CADaq8je8zfRN5R11LxJw=0st-u-XOoKosGbZDBajOTiChzpS5Q@mail.gmail.com> <93F476D6-57F8-44AB-94C9-545608396F51@oracle.com> <CADaq8jcJ3WkpmPJVVec5aJc0ekKgdHPUok=S5_ofGVJnbqrrjA@mail.gmail.com> <5538FD5E-A71B-4F91-AC3A-CBD2F54AF9E3@oracle.com> <CADaq8jeX4LiFeeq7ruPKQgwBhBHze6=bfvUOzRMcriLm-Zrn+Q@mail.gmail.com>
To: David Noveck <davenoveck@gmail.com>
X-Mailer: Apple Mail (2.3124)
X-Source-IP: userv0022.oracle.com [156.151.31.74]
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/gAWFvSCPQYondNhy0BUWzg3Hs8A>
Cc: "nfsv4@ietf.org" <nfsv4@ietf.org>
Subject: Re: [nfsv4] Review of draft-ietf-nfsv4-rfc5667bis-06
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.17
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, 27 Feb 2017 16:33:09 -0000
> On Feb 26, 2017, at 4:54 PM, David Noveck <davenoveck@gmail.com> wrote: > > > As far as I know the extant implementations do > > not support this construction, and we have to > > preserve interoperation with them. > > I can see that the relevant factor is the need > to preserve interoperability, which is just as well, > since, whenever we try to interpret what RFC5667 > really meant, my head starts to hurt. > > If the reason for forbidding something is driven by > interoperability concerns, it would make the spec > more clear if this were said explicitly > > > That reasoning could also apply in the NFSv4 > > case, where it is almost a certainty that typical > > NFSv4 WRITE requests can be larger than the > > inline threshold. > > Perhaps so but note that section 5.4.1 of -06 says: > Therefore, an NFS version 4 client MAY send a reduced Payload stream in a Long Call. An NFS version 4 client MAY enable an NFS version 4 server to send a reduced Payload stream in a Long Reply. > This wasn't in -05. It doesn't seem to be needed, but if it is wrong, > simply deleting it would not be enough. You might have to put in > something forbidding it, as is done in the legacy case. Earlier I had believed we had some historical reasons for matching the intent of RFC 5667. But if we are interested only in documenting the behavior of existing implementations, note that: - None of them have support for more than one chunk in a Read or Write list - None of them support PZRC plus a non-zero Read chunk - None of them support multiple Write chunks - None of them support multiple NFS READ or WRITE requests per COMPOUND This could be an argument to, in addition, remove a large piece of text that discusses multiple Write chunks. However, it might be interesting to some to leave some flexibility for future use. I would like to hear opinions about this. -- Chuck Lever
- [nfsv4] Review of draft-ietf-nfsv4-rfc5667bis-06 David Noveck
- Re: [nfsv4] Review of draft-ietf-nfsv4-rfc5667bis… Chuck Lever
- Re: [nfsv4] Review of draft-ietf-nfsv4-rfc5667bis… David Noveck
- Re: [nfsv4] Review of draft-ietf-nfsv4-rfc5667bis… Chuck Lever
- Re: [nfsv4] Review of draft-ietf-nfsv4-rfc5667bis… David Noveck
- Re: [nfsv4] Review of draft-ietf-nfsv4-rfc5667bis… Tom Talpey
- Re: [nfsv4] Review of draft-ietf-nfsv4-rfc5667bis… Chuck Lever
- Re: [nfsv4] Review of draft-ietf-nfsv4-rfc5667bis… David Noveck
- Re: [nfsv4] Review of draft-ietf-nfsv4-rfc5667bis… David Noveck
- Re: [nfsv4] Review of draft-ietf-nfsv4-rfc5667bis… Chuck Lever
- Re: [nfsv4] Review of draft-ietf-nfsv4-rfc5667bis… David Noveck
- Re: [nfsv4] Review of draft-ietf-nfsv4-rfc5667bis… Chuck Lever
- Re: [nfsv4] Review of draft-ietf-nfsv4-rfc5667bis… David Noveck
- Re: [nfsv4] Review of draft-ietf-nfsv4-rfc5667bis… Chuck Lever
- Re: [nfsv4] Review of draft-ietf-nfsv4-rfc5667bis… Chuck Lever
- Re: [nfsv4] Review of draft-ietf-nfsv4-rfc5667bis… David Noveck
- Re: [nfsv4] Review of draft-ietf-nfsv4-rfc5667bis… karen deitke