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

[Mike Kupfer <[e-mail]>]

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