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

[David Noveck <[e-mail]>]

> That's a subtle distinction.

Not really.

> I'm not sure I completely understand the rationale.

I'll try to clarify below.

> So adding a new attribute flag is OK,

There isn't a new attribute flag.  There is a new attribute, which means
that suppattr would be longer. It is true that there are clients with bugs
that would be exposed by adding attributes, but the idea of adding
attributes in extensions has not been considered troubling in the years the
working group has been considering a new versioning approach.  I don't see
why issues regarding newly defined flags in responses should change that.

In fact there are two documents that propose this very thing now nearing
working group last call: draft-ietf-nfsv4-umask-03
and draft-ietf-nfsv4-xattrs-03.

> but e.g. a new open result flag is out?

Yes.  That is a new flag which the extension would have to assign a meaning
to.

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

No.  There has been no consideration of what buggy
clients might do.

The reason is that when the responder sends a response, it needs to know
that the requester understands it.  With new request flags, the responder
can tell the requester "Huh?"  using NFS4ERR_INVAL. as we have been
discussing and the  client and server can adopt a protocol variant they
both understand.
There is no way the requester can tell the responder that it doesn't
understand something in a response so we have to avoid that situation.

If you want a new open response flag, an extension could define an OPEN2 op
that has a more extensive response. The responder knows that if you use
OPEN2, you are prepared for the more extensive response.

Regarding issues with buggy clients, I didn't deal with them in the
extension document.  However, they should be discussed when we consider and
review individual extensions.

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

With regard to proposed extensions to v4.2, I don't see this as being
worrisome.  Extensions to v4.2, including new attributes have been under
discussion for some time.  Implementers should be aware of the fact that
suppattr is defined as variable-length item.

If you feel this is a serious concern in the v4.2 context, then the issue
can be discussed when extensions containing new attributes are reviewed.

> I wasn't too worried about this kind of thing when I thought
> we were just talking about allowing new minorversions
> to be extensible,

I think that is what we are talking about.

> or maybe opening up 4.2 in retrospect,

I consider 4.2 a new minor version.  I will do so until at least a few
months after it is published as a Proposed Standard.

> but extending 4.0 this way makes me nervous.

draft-ietf-nfsv4-versioning-7 does allow this, but the decision to actually
do it for an existing minor version is something that the working group has
to decide to do.  In doing so, it will be considering compatibility issues
such as the ones your concerned about.

While I have speculated about possibly backporting umask to v4.0, nobody,
including me, has actually proposed doing it.    When someone submits an
I-D proposing that, the working group will review the document and you and
others can state their concerns, including issues with buggy clients.
Similarly, when it is proposed to make that a working group document, and
when it is proposed to move it forward to the IESG.  This would all be done
by consensus.   I don't see the working group rushing ahead in this way
without considering fully the sort of  issues you are concerned about.






On Mon, Oct 31, 2016 at 5:08 PM, Fields Bruce James <[e-mail]>
wrote:

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