Subject: [nfsv4] Changes in versioning-08

From: David Noveck <[email-masked]>
Date: Sat, 3 Dec 2016 08:03:25 -0500

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

Done.

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

Done.

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

Done.

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

Done.

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

Done.

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

Done.

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

Done.

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

Done.

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

Done.

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

Done.

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

Done.

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

Done.

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

Done.

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

Done.

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

Done.

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

---

From: Mike Kupfer <[email-masked]>
Date: Tue, 06 Dec 2016 17:07:42 -0800

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

> "subsequently" I meant after the minor version was defined an the new text

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

---

From: David Noveck <[email-masked]>
Date: Wed, 7 Dec 2016 06:40:44 -0500

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

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.

---

From: Mike Kupfer <[email-masked]>
Date: Wed, 07 Dec 2016 11:10:45 -0800

> It will eventually but normally this happens when the RFC is published.

Ah, okay.  Thanks for explaining about xml2rfc.

> is made before sending those new or extended callbacks.

I think that should be sufficient.

thanks,
mike