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

[Fields Bruce James <[e-mail]>]

On Mon, Oct 31, 2016 at 01:57:40PM -0400, Trond Myklebust wrote:
> 
> > 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.

That's a subtle distinction.  I'm not sure I completely understand the
rationale.  So adding a new attribute flag is OK, but e.g. a new open
result flag is out?  Are you judging that a client is more likely to
give up and throw an EIO on an unknown open result flag than on an
unknown attribute flag?

Personally I'd put my money on the attribute case being more likely, if
only because it's variable-length and, as Trond says, we've actually
seen bugs here before in practice.

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

I wasn't too worried about this kind of thing when I thought we were
just talking about allowing new minorversions to be extensible, or maybe
opening up 4.2 in retrospect, but extending 4.0 this way makes me
nervous.

Bugs happen, and we fix them, but the older the protocol the more likely
there's old implementations out there that aren't getting much
maintenance.  I don't know.

--b.