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

[Trond Myklebust <[e-mail]>]

> On Oct 31, 2016, at 13:25, David Noveck <[e-mail]> wrote:
> 
> > So, that rules out adding attributes?  
> 
> No it doesn't.
> 
> > (Since you'd have to return new bits in the supported_attribute attribute).
> 
> I said adding "bit flags" and I think that means a new definition of a previously unknown flag bit.
> 
> Each bit in the bit mask of supported attribute already has a definition and when I write the text, I'll make sure that it is clear that expanding supported_attrs is not going to change that  For example bit 128 means the server supports attribute 128.  The further information regarding what attribute that is would be provided by the extension that defines attribute 128, the effect of which is already clear.  The point is that the client who does not know about attribute 128 is not going to puzzle over this new bit.  He knows it indicates that the server supports some attribute he doesn't know about.

One thing to note is that we’ve had issues before where both clients and servers have been known to assume things about the maximum size of the bitmaps being returned.


> 
> On Sun, Oct 30, 2016 at 10:04 PM, J. Bruce Fields <[e-mail] <mailto:[e-mail]>> wrote:
> 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 <[e-mail] <mailto:[e-mail]>> wrote:
> >
> > > David Noveck <[e-mail] <mailto:[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
> > >
> 
> > _______________________________________________
> > nfsv4 mailing list
> > [e-mail] <mailto:[e-mail]>
> > https://www.ietf.org/mailman/listinfo/nfsv4 <https://www.ietf.org/mailman/listinfo/nfsv4>
> 
> 
> _______________________________________________
> nfsv4 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nfsv4