Re: [nfsv4] Changes in versioning-08

[David Noveck <[e-mail]>]

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 <[e-mail]> 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
>