[nfsv4] feedback on draft-ietf-nfsv4-versioning-07

[Mike Kupfer <[e-mail]>]

Potential technical issues:

* Section 5.1, first bullet item: this bullet item seems to imply that
  any string-related changes must be done in a minor version, rather
  than an extension.  That's fine for the broad rules (e.g., i18n) that
  this bullet item seems to have in mind, but I think we should be able
  to extend a list of known literal strings in an extension.  We don't
  typically bake literal strings into the NFS specification, but we do
  use them occasionally (e.g., "nobody", as well as the special ACE
  identifiers like "OWNER@").

  (Sorry about just getting this out now--I missed it in previous
  reviews of my notes.)

* Section 9.2: after thinking about this some more, I'm still unsure on
  how things will work if the client implements only the uncorrected
  version and the server implements only the corrected version.  The
  client asks if the server supports minor version X and the server says
  yes.  At this point the client could ask about a correction to feature
  FOO, but it doesn't know about any such correction.  Since the client
  doesn't ask, the server might then be able to deduce that the client
  only supports the uncorrected version, but now it's too late--the
  server has already said it supports minor version X.  The first time
  the client will find out about the incompatibility is when it tries to
  use the uncorrected version of the feature and gets an error back from
  the server.

  It seems like the server must support both the uncorrected and
  corrected versions of the feature.  It can only drop support for the
  uncorrected version with the next minor version.

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"

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

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

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

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

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

* 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

    By doing things this way, a requester can determine whether the
    other host supports a particular version of the feature.  As a
    result, the protocol with the XDR modification can accommodate
    clients and servers that support either the corrected or the
    uncorrected version of the protocol, as well as clients and servers
    that support both alternatives.

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

Okay, that's everything I have flagged in my notes.

mike