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

[David Noveck <[e-mail]>]

> Potential technical issues:

I don't think of either of these as difficult to resolve.

I'll discuss each one and then we can consider the possible effect on WGLC,
given
the onrushing 10/31 (!) document submission witching hour.

> but I think we should be able to extend a list of known literal
> strings in an extension.

I can see why you might want that, but it is difficult to provide for.
When you are testing for support or knowledge of an XDR protocol element,
the draft  already has a description of how to do the testing, the errors
that might result, etc.

If you are going to allow those that do or do not support a extension with
regard to the strings accepted, you have to provide analogous means to find
out what is supported.  I fear that changing the document at this point to
provide for that would be difficult to do, especially in a case where
strings are added to attribute values.  In that case you need to know
whether the client will accept them on GETATTR as well as whether the
server will accept them on SETATTR.

If you want to have variant/extended handling of the set of strings, you
could define a new attribute that allowed the new strings together with
retaining  an older one that accepted only the old strings.  I think this
would give you what you need, leaving the extension framework as it is.

> At this point the client could ask about a correction to feature
> FOO, but it doesn't know about any such correction.

Good point.  The difference from the rest of the extension model is that
the old client, having been written before the correction was identified,
has no knowledge of the potential non-support and thus cannot test for it
in advance.

>It seems like the server must support both the uncorrected and
> corrected versions of the feature.

Lets call the version subject to correction 4.x.

4.x requires the uncorrected version and and cannot require the corrected
version.

I think it can allow (not require) the corrected version.

>It can only drop support for the uncorrected version with the
> next minor version.

The working group would have a number of options in 4.x+1:

Making the corrected version REQUIRED and the uncorrected version mandatory
to not implement.  This would force older clients to use and servers to
support the corrected version. befire adopting 4.x+1

Making the corrected version REQUIRED and the uncorrected version OPTIONAL
 This would force server to support the corrected version but 4.x clients
could have a reprieve and could simply send the 4.x request as 4.x+1, with
no guarantee of support.  However, it would test for support of the
uncorrected version as an OPTIONAL feature.

Making both the corrected and uncorrected version OPTIONAL with the
constraint that at least one has to be supported.  This would allow both
uncorrected clients and servers to be easily converted to 4.x+1,  However,
there would be no guarantee of interoperability for servers or clents only
prepared to deal with the corrected or corrected variant.

With regard to WGLC, we have two options:

Consider your comments an early contribution to the about-to-be-announced
WGLC of -07

Wait until the submission hiatus to submit a -08 and make that the subject
of WGLC.  That document could respond to the technical issues and address
the editorial issues you raised in your mail

I'm OK with either of the above but feel that the WGLC for umask-02 and
xattrs-03 should go forward now in any case.






On Tue, Oct 25, 2016 at 4:54 PM, Mike Kupfer <[e-mail]> wrote:

> 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
>
> _______________________________________________
> nfsv4 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nfsv4
>