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

[Mike Kupfer <[e-mail]>]

David Noveck <[e-mail]> writes:

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

Well, there won't be a check at the RPC layer.  But presumably the NFS
layer would return something like NFS4ERR_INVAL if it's given a value it
doesn't know about.

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

I'm okay with narrowing the scope of what an extension can do.  But if
we require a minor version bump to change the set of allowed values for
an enum, we should do the same for the general case of flag words.  (New
attributes could still be added via an extension.)

mike