Re: [nfsv4] draft-haynes-nfsv4-versioning-01

["J. Bruce Fields" <[e-mail]>]

On Thu, Oct 23, 2014 at 09:18:26AM +0300, Benny Halevy wrote:
> On Thu, Oct 23, 2014 at 7:08 AM, Tom Haynes
> <[e-mail]> wrote:
> >
> > So this looks good to go with only two open items for me:
> >
> > 1) Are new operations assigned by IANA or by publishing a draft?
> >
> > Actually Christoph’s observation, but there seems to be controversy here. :-)
> >
> > 2) With respect to callbacks:
> >
> >    o  New callbacks will only be sent to clients that have used the new
> >       features associated with them, allowing existing clients to be
> >       unaware of their existence.
> >
> > What if the new feature is only implemented with callbacks?
> >
> > I.e., clients have to be able to respond with not supported as well.
> 
> Why wouldn't they be able to respond with "not supported"?
> Even today some callbacks are (feature) optional, e.g. CB_NOTIFY_DEVICEID

If they implemented only part of a minor version then they may not even
know the callback number is assigned in which case they'll return
NFS4ERR_OP_ILLEGAL.

Not necessarily a problem I guess as long as the server is prepared to
do the same fallback in the ILLEGAL case that it would in the NOTSUPP
case?

Ditto for forechannel operations.

And in the case of attributes INVAL might be returned in cases where we
might expect ATTRNOTSUPP (or just the relevant bits cleared from the
bitmap)?

We may need to go through the various ways of extending the protocol
listed in

	https://tools.ietf.org/html/draft-ietf-nfsv4-minorversion2-27#section-2

with an eye towards the case where the extension is something the client
or server doesn't even know the existance of or xdr for.

"adding cases to a switched union" needs some care: e.g. if we added
this to a server reply without some kind of client opt-in then the
client could be left unable to parse the result.  #4 makes it appear
this was intended only for arguments, not replies?

--b.