[nfsv4] Changes in versioning-08

David Noveck <davenoveck@gmail.com> Sat, 03 December 2016 13:03 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 74FDE1297A5 for <nfsv4@ietfa.amsl.com>; Sat, 3 Dec 2016 05:03:29 -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 BbnPrb8qEVGK for <nfsv4@ietfa.amsl.com>; Sat, 3 Dec 2016 05:03:27 -0800 (PST)
Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (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 2EFA412973D for <nfsv4@ietf.org>; Sat, 3 Dec 2016 05:03:27 -0800 (PST)
Received: by mail-oi0-x235.google.com with SMTP id y198so295559204oia.1 for <nfsv4@ietf.org>; Sat, 03 Dec 2016 05:03:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=gipzFyuOQ4TXwRJ6N+RjPigJtisLCYpZ8VAwxGLtqjY=; b=wtDK0vjxYH4+EDS/TvsIMxRQErBOZTvfbjC+N3Y9O8YNGPyhnF8fzZYJv4Vi+rYkAz n3r9KDurMXSo/NKMFkjI9FPtnGhZ2Bl+Mc9GIEgZN7/FaNJBIkyuSrb/LcBmngJ6catc YlbGcTUP1xDY3sL8+BXodnvkJvSm/Fn8XSHpXS92b3cV2g7Sb3SLGMkGn/NdJBCQkj4h cy7tydx/dBwianoVfhLhH8Fh57rvBNrkvxKSs59GDvrI0eZJfQNdvwPoF1Y1Sf7WhaKx umWLK/x7PCXJCY56gyN3f3PUVFWKMCT7htB7cL78yp8FsKDGjTs4/p5XCZ7atpYgnqdc AWVw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=gipzFyuOQ4TXwRJ6N+RjPigJtisLCYpZ8VAwxGLtqjY=; b=HGYiswFb9KHB4j7+qn5rbP4Q2+vfPenuDHJRy+Q71AMP9FJckEc1ttci0ddJEnKmbx /EbKRCnCH9nS/iTsmg83cuYMW47p+xIUgZv31exS5B5I37kj0NZPK+ke7sYXwm256WVz 81YiUG/fpSDU5dn3ddMS4S4hhHaKmINGvOHN/1CySVg9n3rmaLgHi9rJoMqV7z5KF0O2 sn4lo8IaEs3z6PT8PM9vsJb173c2LzoHHWHr+8NPzPEbj6THp78z/AMcj7a6NYG86chG mhnQa9vsKlE8M2xxqi6LT8HiQsNz19SHItpEinj8kA0Z0rMCvTYNOh4fpNRA8cgn0ZZd RWEw==
X-Gm-Message-State: AKaTC02wfNiKgyEc/7nblLdxIS9jGjMIfXDkB6ClbjD65CqgctIBuLYW0e384hIUUcCIvMsuMW43SZ+bVSwmzQ==
X-Received: by with SMTP id g184mr25428305oib.23.1480770206208; Sat, 03 Dec 2016 05:03:26 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Sat, 3 Dec 2016 05:03:25 -0800 (PST)
From: David Noveck <davenoveck@gmail.com>
Date: Sat, 3 Dec 2016 08:03:25 -0500
Message-ID: <CADaq8jfv08xyfCxEfSJih0mGwMv=JSSv7XvdDeZoBc9g18-2eg@mail.gmail.com>
To: "nfsv4@ietf.org" <nfsv4@ietf.org>
Content-Type: multipart/alternative; boundary=001a113b06022296f40542c0ae71
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/EBbZQpV-7Tt91ioMJ19-qkTEELU>
Subject: [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: Sat, 03 Dec 2016 13:03:29 -0000

I think versioning-08 addresses all the comments I have received about
versioning-07, whether those comments were made as part of the WGLC or not.

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

versioning-08 changes include:

   - Adaptation to the publication of RFC7862, including deletion of
   Appendix B.
   - The document title has now been made aperiodic :-), as requested by
   Marcel Telka.
   - A revision of Section 9 to address the issues that Mike raised about
   correction to REQUIRED features.
   - Changes addressing Mike's list of editorial issues.  See the details
   - My response to the issues, raised by Bruce and Mike about additions to
   sets of strings, bit fields, enums.  The summary is that changes to strings
   still require a minor version and that new bit fields and enums values can
   appear in requests, but that a new minor version is required for changes in
   responses, unless there is a protocol element that  can be used to
   determine that the client is aware of the extension. I know that this may
   not give people all the flexibility they want, but note that I tried a more
   complicated and flexible model in -05 and am reluctant to go back there
   unless there is a pressing need. Until a new versioning document is
   published as an RFC, ALL changes require a minor version and think we want
   to focus on changing that unsatisfactory situation.

Here are my responses to Mike's editorial issues:

> Minor editorial stuff:

> * Section 1, penultimate paragraph: the current wording seems to imply
>  that the XDR extensions approach will be able to handle all protocol
>  corrections.  I would change "to make other sorts of changes" to "when
>  needed".


> * Section 1, last paragraph: change "is provide" to "is to provide"


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

> * Page 6, lines 4-5: change "it is the set is" to "it is"


> * Page 6, last paragraph of Section 2.3: the last sentence of that
>  paragraph bothers me, as it just echoes the first sentence of the
>  previous paragraph.  Maybe replace the first sentence of the previous
>  paragraph with
>    Each client and server which implements a specific minor version
>    will implement some particular variant of that minor version.  Each
>    variant is a subset of the current minor version and a superset of
>    the base minor version.
>  and drop the last paragraph completely?

Done.  Thanks.

> * Page 7, third bullet item, sentence starting with "In particular": add
>  a comma after "all previously specified minor versions".


> * Page 9, second bullet item: change "operation codes" to "procedures".


> * Page 9, third bullet item: change "RPC operations" to "RPC procedures,
>  operation codes".

Done.  Now RPC procedures, operations codes, ...

> * Section 4.3, penultimate paragraph: remove the comma after "protocol
>  elements".


> * Page 11, second bullet item: change "subsequent minor version" to
>  "subsequent minor versions" (add "s")


> * Page 11, paragraph starting with "For many minor versions": change the
>  first sentence to
>    For many minor versions, all existing protocol elements are required
>    to be known by both the client and the server, and so requesters do
>    not have to test for the presence or absence of knowledge regarding
>    optional protocol elements.

Addressed.  I took your sentence but dropped the word "optional" since it
is ambiguous.  Normally it means optional to implement but in this case it
would mean optional to know about.

> * Page 13, bullet item at the top of the page, sentence starting with
>  "The client can determine which of the extensions": change to
>    The client can use the approach described in Section 4.4.3 to
>    determine which of the extensions it knows about are also known by
>    the server.


> * Section 4.5, first paragraph: change "fields." to "fields that are"


> * Section 5, first paragraph: add a period at the end of the paragraph.


> * Page 16, last bullet item: change "indicated non-support a flag bit"
>   to "indicating non-support of a flag bit".


> * Page 17, last paragraph: "OPTONAL" -> "OPTIONAL"


> * Section 9, first paragraph: add a comma after "acceptance of that


> * Section 9, 2nd paragraph, first sentence:
>    Such corrections are best done in a document obsoleting or updating
>    the RFC defining the relevant feature definition document or minor
>   version specification.
>  I think there are too many words here.  We could refer to "the RFC
>  defining the relevant feature or minor version".  Or we could refer to
>   the "relevant feature definition document or minor version
>   specification".

Done.  I picked the former.

>* Section 9.1, 2nd bullet item: change "appropriate" to "appropriate way"


> * Page 20, 2nd bullet item: change "feature, be considered obsolescent"
>  to "feature be considered obsolescent"


> * Page 20, paragraph starting with "By doing things this way": I would
>  drop the bullet list that follows this paragraph and replace the
>  paragraph with

The original is now gone as part of the reoganization of section 9.

> * Section 9.2 title: should "required" be all uppercase?

Yes. Because of the reorganization of section 9, this is now section 9.3.