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

On Fri, Oct 28, 2016 at 08:29:26AM -0400, David Noveck wrote:
> 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.

So, that rules out adding attributes?  (Since you'd have to return new
bits in the supported_attribute attribute).

--b.

>    - 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 <mike.kupfer@oracle.com> wrote:
> 
> > David Noveck <davenoveck@gmail.com> 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
> >

> _______________________________________________
> nfsv4 mailing list
> nfsv4@ietf.org
> https://www.ietf.org/mailman/listinfo/nfsv4