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

[[e-mail] (J. Bruce Fields)]

On Thu, Oct 27, 2016 at 06:01:22AM -0400, David Noveck wrote:
> 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.

It may not be caught at xdr decoding time, but in most cases some other
part of the code will have to catch it.  E.g. 5661 18.16.4 requires
implementations to return INVAL on unknown share_access values.

(IO_ADVISE is an interesting case--the server's required to ignore
unsupported values.  That might not extend to undefined values.  But as
it's only a hint, clients could probably deal with either behavior
easily enough.)

The important principal here that we preserve interoperability with
existing implementations.  Applying that principal to specific protocol
exentensions is going to be more useful than trying to enumerate general
rules about extending different kinds of protocol elements.

--b.

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