Re: [nfsv4] Changes in versioning-08

David Noveck <davenoveck@gmail.com> Wed, 07 December 2016 11:41 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 49483129DEA for <nfsv4@ietfa.amsl.com>; Wed, 7 Dec 2016 03:41:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04qBHCMQVcBG for <nfsv4@ietfa.amsl.com>; Wed, 7 Dec 2016 03:41:09 -0800 (PST)
Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (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 D469D129DFB for <nfsv4@ietf.org>; Wed, 7 Dec 2016 03:40:45 -0800 (PST)
Received: by mail-oi0-x22e.google.com with SMTP id v84so411575602oie.3 for <nfsv4@ietf.org>; Wed, 07 Dec 2016 03:40:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=eWMAaFfwXXu2sYIT9wvlOa+s6oG4kEBvlc1t7S1tNdE=; b=LmlRT6ziGoqq/wFp9WL+7cU1zEAFgszbVY/AHoiSR/snlfgwX15YOdJ7pK+xwAzPwX xss5BOlqMn6bvlyAJ3McsRv2ItdMKRRp1eSSSwaeVbofyscZHAeJ85VsDJkNs9jhR0AB uvkB4bEEp4/V+6tY1YYoo3IwyPkNiaZc68w4iXxkQM2OE6Mj5tAC2yDUXlZtew00vEn2 1GEB2ARV6qOOc+MyRkJ8LUu1ndQVNrYY3Hrb6OdYYoXVPfy80YQx5IrRCEs8A7Sq9CMU cUUt9hZclz/KykjwDV7LzV+qMbg/t5SriCvppIrwHEGQuluyDGmKYjhS3tn/5lEzgS2c jQnw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=eWMAaFfwXXu2sYIT9wvlOa+s6oG4kEBvlc1t7S1tNdE=; b=V9PTKo9ooDy68CemUCzPMR5ZwULhGP+WtmYg/n5OQCB9+NutCpIQsyQWDvyg0HOIMH G4SR47IKTpE7YxibwJRE09k/28Fsww23LBqo23dNPO658vQtdK92AIOZZnauonXhM2R0 6f8s+p7qbz/pGZieIFJQg5btj9ZSfTygBG20BQtDGPq+dcCcPwNybbyxGy36RUbVc4Ie qngzk9e8t8zuKk7aFvg54IMKREL1xWYBcEHXsNgtFJhEXqli3F5bKDIrp6GV3gmgTzu+ uat9eNCvU1D6srxeMzS2HnaUkHeSMD6NZJP+Lwp0ZTlEMG7feWhZLg7CA+JTGDz25t5+ ZGHQ==
X-Gm-Message-State: AKaTC03DoZHap4YDL5uYCQZP+0pvuwtIGoicqkeTtkY+lhlHaduduwtK06fHa+7FMLuC/ZbKeffFqkIpTnQLnQ==
X-Received: by 10.157.11.14 with SMTP id a14mr39347118ota.185.1481110845158; Wed, 07 Dec 2016 03:40:45 -0800 (PST)
MIME-Version: 1.0
Received: by 10.182.137.202 with HTTP; Wed, 7 Dec 2016 03:40:44 -0800 (PST)
In-Reply-To: <11782.1481072862@athyra-vm1.us.oracle.com>
References: <CADaq8jfv08xyfCxEfSJih0mGwMv=JSSv7XvdDeZoBc9g18-2eg@mail.gmail.com> <11782.1481072862@athyra-vm1.us.oracle.com>
From: David Noveck <davenoveck@gmail.com>
Date: Wed, 7 Dec 2016 06:40:44 -0500
Message-ID: <CADaq8jf77F4PbzuT1KKRc_2oz2G4-VA045dXWt8HwZkQeetVNQ@mail.gmail.com>
To: Mike Kupfer <mike.kupfer@oracle.com>
Content-Type: multipart/alternative; boundary=001a113db650cc7a2905430ffde6
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/TkzL25TSiz7Yz7kE5hlSfhO0QeA>
Cc: "nfsv4@ietf.org" <nfsv4@ietf.org>
Subject: Re: [nfsv4] Changes in versioning-08
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: Wed, 07 Dec 2016 11:41:14 -0000

Thanks.  I intend to include these changes in a -09 to be submitted on
12/9.  I'll only note below cases in which your suggested change will not
be made or in which you suggest that something be done without actually
specifying replacement text.  In most cases, I've simply made your
suggested change.

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

It will eventually but normally this happens when the RFC is published.
xml2rfc generates it.

> 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.

OK. The paragraph now reads:

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 that client is aware of the changes.
This determination, for any particular client (as defined by its clientid),
is made before sending those new or extended callbacks.






On Tue, Dec 6, 2016 at 8:07 PM, Mike Kupfer <mike.kupfer@oracle.com> wrote:

> 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
> -07.
>
> > > * 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
>       subsequently.
>
> 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
>   away?
>
> * 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".
>
> cheers,
> mike
>