Re: [nfsv4] Changes in versioning-08

[Mike Kupfer <[e-mail]>]

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