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

[David Noveck <[e-mail]>]

I think we are close to agreement regarding how to address the issues in
section 9.

Regarding strings/enums, I don't think we want to try to expand the scope
of what can be done in an extension.  The -05 draft allowed knowledge of an
additional XDR element as part of an extension to signal whether a field
use change such as one to the set of valid values of a string was present.
However, the working group found that too complicated and in -06 I focused
 on the simplest extension model, in which each of the kinds of changes
allowed by the original minor versioning approach was allowed in an
extension and other things required a minor version.  That might not be the
most flexible approach but it is way better than where we are now, with
every change requiring a minor version.

Regarding extending enums, it is true that -07 seems to allow this without
saying how to mange it in general.  It  only discusses expanding switches
and provides specific rules regarding error codes, operation codes, and
attribute numbers.

The real problem with allowing general enum extensions is that XDR
implementations do not check that the values in the fields are valid.  As a
result, you cannot test that the responder knows about the new values by
issuing a request containing the new value, as you can with extensions to
switches.

As a result, enum fields are essentially ints, and the restriction to the
values listed in the XDR file is much like an in-spec-text restriction
regarding the contents of that particular field. I think the spec should
make clear it that changing the set of allowed values requires a new minor
version.

> But then I'm not into country music[1]. :-)

Neither am I.

On Wed, Oct 26, 2016 at 6:34 PM, Mike Kupfer <[e-mail]> wrote:

> David Noveck <[e-mail]> writes:
>
> >> but I think we should be able to extend a list of known literal
> >> strings in an extension.
> [...]
> > 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.
>
> Hmm.  I was thinking that adding a new string would be similar to adding
> a new value to an enum.  But I now see that although Section 4.2 says
> that an extension can add values to enums, the document doesn't say how
> that would be managed.
>
> > 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.
>
> Yes, the server would need to know that the client supports a particular
> extension before returning values that are defined by that extension.
>
> Adding a new attribute or operation that knows about the extended type
> sounds reasonable to me.  That approach could be used for both new
> strings and new values in an enum.
>
> So it sounds like this is just an editorial issue, to clarify how new
> enum values or string literals could be added by an extension.
>
> Here's a suggestion for text to add at the end of Section 4.2:
>
>   If an enum may be contained in an RPC response, an extension that adds
>   one or more new values to the enum must additionally provide a way for
>   the responder to determine that the requester knows about the
>   extension.  For example, an extension that defines a new file type
>   could define new operations to use instead of GETATTR and SETATTR.
>   The GETATTR and SETATTR operations would continue to support just the
>   original set of file types.  The new operations would support the
>   original file types as well as the new one.
>
> I'd still like to see the ability to extend a list of well-known strings
> without changing the minor version.  I think that adding the following
> text to the first bullet item in Section 5.1 would cover it:
>
>   In some cases, an extension may add new string literals to a set of
>   well-known strings, similar to the way that new values may be added to
>   an enum.  Consideration must be given to whether the string might
>   already be in use.  And as with enums, there are additional
>   requirements if the string could be included in an RPC response (see
>   Section 4.2 for details).
>
> >> 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.
>
> Right.  I meant that *if* the server supports the corrected version, it
> must still support the uncorrected 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.
>
> And if the uncorrected version is not supported, the client would fall
> back to 4.x.
>
> > 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.
>
> Yeah.  So I think we'd want to discourage that last choice.
>
> > With regard to WGLC, we have two options:
> [...]
> I have no opinion on WGLC for any of the I-Ds.  But then I'm not into
> country music[1]. :-)
>
> cheers,
> mike
>
> [1] http://www.wglc.net
>