Re: [nfsv4] Changes in versioning-08

Mike Kupfer <> Wed, 07 December 2016 01:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8AD7E129628 for <>; Tue, 6 Dec 2016 17:20:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.098
X-Spam-Status: No, score=-7.098 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=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5KJImjEtpqbT for <>; Tue, 6 Dec 2016 17:20:08 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3DDCF1293EE for <>; Tue, 6 Dec 2016 17:20:07 -0800 (PST)
Received: from ( []) by (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id uB71K51v012852 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for <>; Wed, 7 Dec 2016 01:20:06 GMT
Received: from ( []) by (8.14.4/8.14.4) with ESMTP id uB71K5r7001207 for <>; Wed, 7 Dec 2016 01:20:05 GMT
Received: from (localhost []) by (8.15.2+Sun/8.15.2) with ESMTP id uB717h3U011783; Tue, 6 Dec 2016 17:07:43 -0800 (PST)
From: Mike Kupfer <>
To: David Noveck <>
In-reply-to: <>
References: <>
Comments: In-reply-to David Noveck <> message dated "Sat, 03 Dec 2016 08:03:25 -0500."
X-Mailer: MH-E 8.6+mdk01; nmh 1.2; GNU Emacs 24.5.1
Date: Tue, 06 Dec 2016 17:07:42 -0800
Message-ID: <>
X-Source-IP: []
Archived-At: <>
Cc: "" <>
Subject: Re: [nfsv4] Changes in versioning-08
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NFSv4 Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 07 Dec 2016 01:20:09 -0000

David Noveck wrote:

> If you have an issue that I've missed or feel that your issue was not
> satisfactorily addressed, please let me know.

One of my comments from -07 didn't get addressed, but that's due to
ambiguity in the way I submitted it.  More on that below.  I also
noticed a few new editorial issues (mostly nits) while diffing against

> > * Page 5, last bullet item: change "subsequently" to "up to that time"
> Not sure what you mean by "that time" in "up to that time". By
> "subsequently" I meant after the minor version was defined an the new text
> makes that clear.

Sorry, I wasn't clear enough about which bullet item.  I meant the one
after the bullet item that you changed.  (I'm fine with the change that
you did make.)

   o  At any given time, the term "current minor version" denotes the
      minor version variant including all extensions of and corrections
      to the minor version made by standard-track documents published

I like "up to that time" because it goes with "At any given time".
Obviously we can't know the future, so I suppose there's no harm in
"subsequently", but I'd prefer "up to that time".

Here are the new issues:

* First page, third line ("Updates: ....").  Should "(if approved)" go

* Section 4.3, first paragraph: change "in received in" to "that are
  received in".

* Section 4.4.1, page 12:

    For many minor versions, all existing protocol elements, are required
    to be known by both the client and the server, and so requesters do

  Delete the comma after "elements".

* Section 6:

    o  Additions to the set of callback requests and extensions to the
       XDR for existing callback operations can only be made if the
       server can determine, based on the client's actions, that client

  "that client" -> "that the client"

* Section 6: should this section say something about how the server
  needs to "forget" what extensions the client knows about if the client
  submits a new clientid?  This is sort of covered already by text near
  the end of Section 4.4.3 ("A determination of the knowledge..."), but
  reiterating it here in Section 6 seems like it would be helpful.

* Section 9.1:

    o  When a correction is made to a REQUIRED feature, the situation
       becomes one in which the old version of the feature remains 
       different variants of the same minor version may not support both
       support the corrected version.  See Section 9.3 for details.

  I wasn't completely sure how the penultimate sentence is supposed to
  read.  I suggest replacing "support both support" with "both support".

* Section 9.3, first sentence: I suggest adding "in this case" after
  "Interoperability issues".