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

[David Noveck <[e-mail]>]

l've looked at how bit flags are dealt with in -07 and believe that enum
extensions can be dealt with similarly.
They are both constructs where  the generated XDR code does not check for
validity and thus they raise similar issues.

In reviewing the treatment, I have found  few gap in the treatment of bit
flags.  Those need to be fixed and I expect that the handling of enum
extensions will be parallel:

   - There is no discussion of adding bit flags in existing responses.
   Instead, it should be made explicit that doing this would require a new
   minor version.
   - There is no explicit discussion of the fact that, for these additions,
   the interest cannot be distinguish between an unknown bit flag and one
   which is known but unsupported.  This can have implication for how the
   client and server decide on a common XDR variant.  I'd hope that this issue
   can treated in a way that allows a future minor version to better address
   the issue by  reorganizing error codes.  My preference would be for
   preservng NFS4ERR_INVAL as indicating an unknown bit/enum, while allowing
   future versions to address unsupported stuff in a way analogous that Tom
   did for switches in v4.2, i.e. by creating NFS4ERR_FLAGBIT_NOTSUPP and
   NFS4ERR_ENUMVAL_NOTSUPP.


On Thu, Oct 27, 2016 at 2:22 PM, Mike Kupfer <[e-mail]> wrote:

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