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

David Noveck <davenoveck@gmail.com> Mon, 27 February 2017 16:38 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 7A151129462 for <nfsv4@ietfa.amsl.com>; Mon, 27 Feb 2017 08:38:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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, 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 A58LnKh2uzWG for <nfsv4@ietfa.amsl.com>; Mon, 27 Feb 2017 08:38:13 -0800 (PST)
Received: from mail-ot0-x22f.google.com (mail-ot0-x22f.google.com [IPv6:2607:f8b0:4003:c0f::22f]) (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 AE8D0129974 for <nfsv4@ietf.org>; Mon, 27 Feb 2017 08:38:13 -0800 (PST)
Received: by mail-ot0-x22f.google.com with SMTP id w44so55323575otw.2 for <nfsv4@ietf.org>; Mon, 27 Feb 2017 08:38:13 -0800 (PST)
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=5VLjyXbtbjJWdN02R8Xo1UrUaNITfH3TFXfOznvNM0E=; b=np9WQuP0lwpZyArpPbUKKtILFUjV3Z583/ntxhNDWJd8g/IM0uCmCoNGhewr+EVi9G BczImd13Borcruq0UjcNBGHxQSnsWmLIjm6/biP3gR9X4VhjocPv4fVmdgAOl+UieqjJ 6llfvXH89EJrEOBeDV3hGkPHnkW+k0ImTbJ32FpZppN/SxdahfT/IibH5uLNsMXL8Rkc X9yVbreEQ7MHm3QQ2FrgMHOkW6dL5FlbvdgbdwXbG0wsrEgID/19xh4ZD91rfo12QOmL l21Hr/1/UOtOExASNGG9buXggal7gqCNAUTJosRNR/gIpozwThWx9xOrWTJUfDr23yb+ EkSA==
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=5VLjyXbtbjJWdN02R8Xo1UrUaNITfH3TFXfOznvNM0E=; b=VWXAZ0uX6GBjzjLtBp9aBQmCzov+TXqC5lFc3fRVsmRumiedhgWy6uehpoAdiv6u6k DLlIJbVuRrN00y1ZsYhEsRddLX27kzvbrTrMoCEFjIyi31Fio1VmxOVVQtMA3mcmQPsl 7LTmW8fpHVoKee/T6tVCD0W0CXcrO1mTGuJQn40dvJ/04CyCfkig5qD5MACS4oCLRYvS KV3yF63MCflh0lr8WllhZi09O7jZYaTVE9G6geCjjM6pii8Py8e5w93oLfA/0sVXoaA3 HmUoGnh4NCi55wGkB+uq8yIPOLFYcQXKHjKpJ/ZpbHLrJn6e+nXqNRAln1n4cnot9RcP 6wTw==
X-Gm-Message-State: AMke39nmrqg88c2Yh6ugk3kVVTpUtltWF1I38ZhYeGw+3IYya00Fxeq5h0QjfJYLpI/GeBpnEvgEqMUJcNmH1A==
X-Received: by 10.157.60.237 with SMTP id t42mr10170335otf.224.1488213492925; Mon, 27 Feb 2017 08:38:12 -0800 (PST)
MIME-Version: 1.0
Received: by 10.182.137.200 with HTTP; Mon, 27 Feb 2017 08:38:12 -0800 (PST)
In-Reply-To: <de109940-7de1-1a09-51f3-d3be44d98c60@talpey.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> <de109940-7de1-1a09-51f3-d3be44d98c60@talpey.com>
From: David Noveck <davenoveck@gmail.com>
Date: Mon, 27 Feb 2017 11:38:12 -0500
Message-ID: <CADaq8jf5zU0y=v4gaUxVd4scQQwyAEcgWtp11Ddcn=U4jB17pA@mail.gmail.com>
To: Tom Talpey <tom@talpey.com>
Content-Type: multipart/alternative; boundary="94eb2c1902c6988ae6054985b4d7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/6Gw0zEN3-m5K9odf4jl5Ka3rHrE>
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:38:15 -0000

One of the issues that Chuck has to deal with is the need
to make new implementations interoperable with existing
implementation.  That has been the source of some new
MUSTs.

Regarding the use of MUSTs, I think these terms are overused
in general and that RFC2119's suggestion that these be used
sparingly (which ironically uses a "MUST") is too often ignored,
including by  the IESG.

Regarding your suggestion that 5667bis is using "MUST" too
much, a comparison with RFC5667 is instructive.  Including
"MUST NOT"s, the RFC2119 term "MUST" Is  used:

   - 22 times in RFC5667, a 10-page spec.
   - 14 times in rf5667bis-06, an 18-page spec.

Part of Chuck's advantage here is that he deleted a lot of the
duplication in which RFC5667 ether repeated what was in
RFC5666 specialized to NFS (useless) or contradicted it (which
really had to go).


On Mon, Feb 27, 2017 at 8:16 AM, Tom Talpey <tom@talpey.com> wrote:

> On 2/26/2017 3:29 PM, Chuck Lever wrote:
>
>> On Feb 25, 2017, at 3:54 PM, David Noveck <davenoveck@gmail.com> wrote:
>>>
>>> RFC 5667 Section 4 says:
>>>>
>>>
>>> Similarly, a single RDMA Read list entry MAY be posted by the client
>>>>> to supply the opaque file data for a WRITE request or the pathname
>>>>> for a SYMLINK request.
>>>>>
>>>>
>>> Part of the problem here is that, as you discuss later, this statement is
>>> ambiguous, as the meaning of "read list entry" is not clear.
>>>
>>> The server MUST ignore any Read list for
>>>>> other NFS procedures,
>>>>>
>>>>
>>> As I understand it, this statement cannot apply to PZRCs, and rfc5666bis
>>> has already dealt with that issue.  So, if one tried to maintain this
>>> paragraph,
>>> in something like the RFC5667-form, some modification would have been
>>> necessary to avoid essentially preventing any use of PZRCs
>>>
>>> as well as additional Read list entries beyond
>>>>> the first in the list.
>>>>>
>>>>
>>> I take "Read list entry" to mean Read chunk, composed of
>>>> multiple list entries that share the same XDR position.
>>>> This comports with similar language describing Write
>>>> chunks where a single list entry is indeed allowed to
>>>> have multiple segments.
>>>>
>>>
>>> Makes sense to me.
>>>
>>> However, the original intent might have been "single
>>>> Read segment".
>>>>
>>>
>>> It might have been but there is no way to be sure.
>>>
>>
>> We can ask Tom Talpey. If he does not recall, then
>> we have no way to be sure.
>>
>
> I agree the paragraph in question could have been more clear. I'll
> hazard a guess that it should have been written as "Read list" instead
> of "Read list entry", meaning, an entire scatter list is provided.
> This woud certainly match the semantic for the result of an ordinary
> NFS Read.
>
> I will also observe that the statement is a MAY. That is, it prescribes
> no behavior, and offers a choice to the implementer. It does not rule
> out the option of posting a list.
>
> I think you guys need to stop worrying about writing these "rules"
> down so literally. The only goal of RFC5667 was to isolate the tidbits
> of NFS behaviors separate from the core rpcrdma transport. The
> document makes relatively few MUST requirements.
>
> Tom.
>
> _______________________________________________
> nfsv4 mailing list
> nfsv4@ietf.org
> https://www.ietf.org/mailman/listinfo/nfsv4
>