[nfsv4] Review of draft-ietf-nfsv4-rfc5667bis-03 (part three of three)

David Noveck <davenoveck@gmail.com> Mon, 19 December 2016 22:57 UTC

Return-Path: <davenoveck@gmail.com>
X-Original-To: nfsv4@ietfa.amsl.com
Delivered-To: nfsv4@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 02CEF12950F for <nfsv4@ietfa.amsl.com>; Mon, 19 Dec 2016 14:57:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 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_LOW=-0.7, 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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id zZoh0LRxEFgr for <nfsv4@ietfa.amsl.com>; Mon, 19 Dec 2016 14:57:38 -0800 (PST)
Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::22c]) (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 D23221293F5 for <nfsv4@ietf.org>; Mon, 19 Dec 2016 14:57:37 -0800 (PST)
Received: by mail-oi0-x22c.google.com with SMTP id y198so161015016oia.1 for <nfsv4@ietf.org>; Mon, 19 Dec 2016 14:57:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=8JgDQg1vd+SDqaTFsP7flMXVd+mv2KVGHVHuQJW01ZU=; b=uex+6DlqR6+ESwvB6jLGCyUgB3gHkmZYvlzCiWRVc4Fy1u1UjT3tTAQC5pbBLTOqFU 2WjcIPqkoQub/Xtn7pceGgIO6gYVoMvR5SuEFKcZ6GdM+1Z0uZk0oJ+XJwKW0Bw6kYGO cYgA9uXwX5Gkhv8eB3aptKkCqf8prRlRLkYNkeGCytlcn88yV/Z3NLsM3Jsqt/N2rFYz kbaTCe9Gm+0F3Cr3cWxi1GuMhvnu87bkel/VnvLf+KcjxdoMqc7MlP2L36KalvmVlupA 5Om9LWoHXWvqWwdOEq33fInR5YHSzgpSw18ITIyqDssZCzjvi7E7ZVU0nbOUgM/QnXjb zGpA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=8JgDQg1vd+SDqaTFsP7flMXVd+mv2KVGHVHuQJW01ZU=; b=C/HM6mdK2xN9/bLYXJmUR52jyPhk6K1ZHhkQUwdb1fCRZ+/XyB7RaFFcaAtMeHK4H8 Z6HPhNQRDjNFqcn2ctdg1NtId8F3tKxHDpu67fpC/1KvWyVUUoM7R3a/wPKjypjOzpbR ZBRzg3KlQYkJIkRFbiroj++rN+JW2TzNGK0dxxZfM1QRWZAcX+0XDrivmwllEfWGPKkc yDNST+ZEO55W19DIL8+bhd42FaOEWg+dLn+RANNwKeDCj4zjJ7Ogqv5yQaPORH5qSFRj 2LUe4Dpk5WDClfxNlrkK+vK88se9ddRCPy4+zDdneMmHE2UTMzon5aE+xtO3ksM6BeDO mOIg==
X-Gm-Message-State: AIkVDXKPV5BREFJvGlRZoDar14TmneMv2Qx4FzLkbeBrU/8X7i2LWkCPgUBTwO6q54oZN7w4rhG22fyWqJOM2Q==
X-Received: by with SMTP id u198mr9633388oia.165.1482188257151; Mon, 19 Dec 2016 14:57:37 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Mon, 19 Dec 2016 14:57:36 -0800 (PST)
From: David Noveck <davenoveck@gmail.com>
Date: Mon, 19 Dec 2016 17:57:36 -0500
Message-ID: <CADaq8jcQCUn6SuadH2w_2m=b+dRqm_moFXTtvkqGa44o7PK0uA@mail.gmail.com>
To: Chuck Lever <chuck.lever@oracle.com>
Content-Type: multipart/alternative; boundary="001a113e574e8ed03b05440ad845"
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/p4YZbphznxKrP1L5im47VsvTBf4>
Cc: "nfsv4@ietf.org" <nfsv4@ietf.org>
Subject: [nfsv4] Review of draft-ietf-nfsv4-rfc5667bis-03 (part three of three)
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, 19 Dec 2016 22:57:40 -0000

*Review Structure*

This is the final part of a multi-part review.  It is split into multiple
emails to avoid running into mailing list size limits.

This part has per-section comments starting at Section 4.2 and going
through to the end of the document.

Note that all general comments are in the first email.

*Comments by Section (from Section 4.2)*

*4.2.  Reply Size Estimation*

This section is likely to wind up numbered 4.3.

I don't see he point of the second sentence of the first paragraph:

   - TCP clients do not need to prepare buffers to accommodate replies.
   - There is no real significance in dealing with most operations
successfully as long as there are some you do not successfully deal

I have a number of issues with the bulleted list that appears in this section:

   - Regarding the introductory phrase, "These include but are not
limited to", that makes things too vague.  If there are other cases,
we have to know about them.  For now I'm going to assume that this is
the complete list.
   - I'm unclear of the significance of the reputed opacity of these
items, which are not truly opaque anyway.

*4.x.y.  Reply Size Estimation for NFSv4.0*

Propose ddeleting the lat paragraph of the current Section 4.2 andd
replacing it with tis new section, as follows:

With regard to NFS version 4.0, the items discussed in Section  4.2
[numbering may change] make it impossible to determine an a priori
limit on the reply size of GEATTR operations interrogating certain
attributes.  While it is possible for client implementations to rely
on their own architectural limits to bound the reply size, such limits
are not guaranteed to be reliable.   Because of this, the techniques
discussed in Section 2.x to make sure that a GETATTR  with an
appropriately sized reply chunk can be done, when an anomalously large
reply is encountered.

As a result, the reply size for most operations is determinable using
the XDR for the specific operations within the COMPOUND issued.  In
the case of operations such as READ and READDIR, it can be assume that
variable length items in the reply will be no larger than the size
limit presented in the request.  In the case of a response to GETATTR,
where only attributes of fixed size are requested, it may be assume
that the response size is no larger than then size of the set of
attributes requested.

This leaves the following operations as those for which no a priori
size limits can be determined:

   - GETATTR where the set of attributes requested include acl, owner,
group, fs_locations.

Compound requests that include any of the operations for which reply size
limits cannot be determined are to be treated as iscussed in Section 2.x.

   - For COMPOUNDs including such operations, a reply size limit of at
   least 4K SHOULD be initially used. When the inline buffer size is smaller
   than this size, a reply chunk MUST be provided.

   - When a transport error indicates that this reply size was inadequate,
   the COMPOUND MUST be retried with a larger reply chunk. This larger reply
   chunk SHOULD be at least twice the size previously used.

   - If a retry is needed, the requester SHOULD issue future requests for
   such COMPOUNDs, providing a reply chunk at least as large as the largest
   one already used.

Since the presence of COMPOUNDs that contain non-idempotent operations
(.g. RENAME, REMOVE, CREATE) interferes with the ability to retry, it
is best to avoids COMPOUNDs that contain such operations together with
operations for which reply limits are uncertain. Clients SHOULD avoid
such COMPOUNDs by issuing multiple COMPOUNDs to replace COMPOUNDs
containing this combination.  In this connection, it is important to
note that many operation currently thought of as non-idempotent (e.g.
SETATTR, WRITE) are in fact idempotent and are not affected by this

*4.2.1.  Managing READ_PLUS Replies*

I don't see this section as related to *Reply Size Estimation*, so it
should probably wind up numbered 4.4

*4.3.  NFS Version 4 COMPOUND Requests*

I think this section will wind up numbered 4.5.

In the last sentence of the first paragraph, suggest replacing "as
long as it observes the restrictions in Section 4.1" by "as long as
chunks are only used to represent DDP-eligible data items, as
described in section 4.1."

With regard to the third paragraph, it is unclear what is being
refereed to by the phrase "with some additional restrictions.".  If
such restrictions exist, they need to be called out explicitly.

*4.4.1.  NFS Version 4.0 Callback*

I don't see the point of not providing a ULB, given that one would be
so trivial (i.e. No DDP-eligible items, smalll messages).  I think the
text seems to be focused on the fact that there is no big demand for
this as yet, but it seems to be that given that this is so easy to do,
you might as well just indicate how it would be done and not force a
new document to be written when and if this is needed.

*4.4.2.  NFS Version 4.1 Callback*

In the first sentence of the third paragraph, suggest deleting "or Reply".

Suggest replacing the third sentence of the third paragraph by the following:

When the NFS version 4 client reports a backchannel ca_maxrequestsize
that is larger than the connection's inline threshold, the NFS version
4.1 client can support Long Call messages (by using a Position-zero
Read Chunk). Otherwise an NFS version 4.1 server MUST use Short
messages to convey backchannel operations.

* 5.  Extending NFS Upper Layer Bindings*

Suggest rewriting the last sentence as follows:

This includes extensions to a given NFSv4 minor version whose
definition is published separately, as described in [nfsv4-vers].

*8.1.  Normative References*

This needs the following updates:

   - *I-D.ietf-nfsv4-minorversion2* needs to be updated to point to RFC7862
   - *I-D.ietf-nfsv4-rfc5666bis* needs to be updated to -08.

*8.2.  Informative References*

Suggest you add a reference to *draft-ietf-nfsv4-versioning-09*.