Subject: RE: [nfsv4] Minor Versioning.

From: "wurzl, mario" <[email-masked]>
Date: Tue, 1 Feb 2005 14:30:28 -0500

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Trond Myklebust
> Sent: Tuesday, February 01, 2005 1:47 PM
> To: Robert Gordon
> Cc: [email-masked]
> Subject: Re: [nfsv4] Minor Versioning.
> 
> må den 31.01.2005 Klokka 19:25 (-0600) skreiv Robert Gordon:
> 
> > > Why is the existing NFS4ERR_NOTSUPP insufficient for 
> these purposes?
> > 
> > The proposal allows for a succinct up-front mechanism to ascertain
> > the operations supported by the server in one round-trip. One could
> > also figure out the minor versions supported by the server if the
> > supported operations in the reply was zero.
> >
> > I don't see how one could achieve the same with NFS4ERR_NOTSUPP,
> > maybe i'm missing something..
> 
> The minor version is always known to the client, since it 
> supplies it as
> an argument to COMPOUND. The server will return
> NFS4ERR_MINOR_VERS_MISMATCH if it does not support that minor version.
> 
> Beyond that, NFS4ERR_NOTSUPP is sufficient to ascertain which ops
> actually have been implemented. In practice it makes little 
> sense for a
> server to advertise a minor version if it does not actually implement
> any of the features of that minor version, so we should be able to
> assume that the number of unimplemented recommended features 
> will always
> be small.
> 
> Cheers,
>   Trond
> -- 
> Trond Myklebust <[email-masked]>

Robert's proposal would allow a server to choose not to implement all the
features of a minor release.

Mario

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: Trond Myklebust <[email-masked]>
Date: Tue, 01 Feb 2005 12:28:07 -0800

> features of a minor release.

They can do that anyway: a recommended feature is by definition not
mandatory to implement, and mechanisms already exist to allow clients to
probe for it (minor number + NFS4ERR_NOTSUPP).

Having an operation that allows for batch querying of supported
operations only makes sense if we expect large numbers of features to be
optional to implement (as opposed to just one or two operations).
My impression was that minor versions add recommended features which are
by and large supposed to be "on probation". In other words, they are
expected to be strong candidates for "mandatory to implement" in newer
versions of the protocol, else they will be dropped and/or replaced.

A protocol with large numbers of optional features doesn't make sense
from an interoperability perspective.

Cheers,
  Trond

---

From: Robert Gordon <[email-masked]>
Date: Tue, 01 Feb 2005 16:00:05 -0600

> probe for it (minor number + NFS4ERR_NOTSUPP).

And a client can continue to use that method if they so choose.

> optional to implement (as opposed to just one or two operations).

It seems to make sense to me that with the result of one operation
the client can choose to craft the appropriate compound(s) to suite
the capabilities of the server.

> versions of the protocol, else they will be dropped and/or replaced.

One thing i wanted to point out was Daves VERSION_INFO use of 'features'
as opposed to my use of 'operations'. I had read the RFC use of feature
and operation to mean the same thing (silly,i know).. Presumably a 
feature
would be something in the order of "pNFS", and claiming support for the
pNFS feature would imply that all operations required for that feature
are supported by the server.

Robert..