Subject: RE: [nfsv4] Question about v4 goals text

From: "Noveck, Dave" <[email-masked]>
Date: Tue, 11 Jul 2006 20:16:44 -0400

> Oh yes it _is_ a requirement that you must implement a v4.n server:
see section 10.
>    11. A client and server that support minor version X must support
>        minor versions 0 (zero) through X-1 as well. 

Not sure that is such a good idea in the long term, but for now it
only codifies what people are going to do anyway.  The issue can be
revisited later, I suppose, if there a number of additional minor 
versions.

> I've always interpreted the "backward compatibility" statement 
> to be the justification for why we don't allow minor versions 
> of NFSv4 to change existing operations or attributes (i.e. the 
> justification for points 3 to 7 in section 10). 

We don't allow them to change their form, but we do allow them
to be completely eliminated via the mandatory-to-not-implement
concept, so it is a strange form of "backward compatibility".

What those points guarantee I think is that the .x file for a
subsequent minor version can parse a previous one but that 
once that parsing is done, the particular minor version can
impose additional restrictions on what is valid and reject.
So the v4.1 .x file has XDR for both CREATE_CLIENTID and
SETCLIENTID with the former being rejected in v4.0 because 
the op had not not yet been defined in v4.0 while the latter 
is rejected in v4.1 because it has been made mandatory-to-
not-implement.

> > So is there some valid meaning to this statement?  Or should the 
> > statement be something else?

> Maybe, but AFAICS it is mainly advertising...
 
You've convinced me it is close enough to the truth to be
acceptable in an advertising context.

-----Original Message-----
From: Trond Myklebust [mailto:[email-masked]] 
Sent: Tuesday, July 11, 2006 7:55 PM
To: Noveck, Dave
Cc: [email-masked]
Subject: Re: [nfsv4] Question about v4 goals text

On Tue, 2006-07-11 at 18:55 -0400, Noveck, Dave wrote:
> Section 1.2 of RFC 3530 list the goals of NFS Version 4, one of which 
> is.
>  
> o  Designed for protocol extensions.
>  
>       The protocol is designed to accept standard extensions that do 
> not
>       compromise backward compatibility.
>  
> What is "backward compatibility" in this context?
>  
> The normal interpretation would be that v4.n client has to work with a
> v4.n+1 server and that isn't the goal.  Typically if you implement a
> v4.n+1 server, you will implement a v4.n sever but it isn't a 
> requirement.  It also isn't the case that a v4.n request is valid as a
> v4.n+1 request if you change the minor version, since ops can be made 
> mandatory-to-not-implement.

Oh yes it _is_ a requirement that you must implement a v4.n server: see
section 10.
    11. A client and server that support minor version X must support
        minor versions 0 (zero) through X-1 as well.

I've always interpreted the "backward compatibility" statement to be the
justification for why we don't allow minor versions of NFSv4 to change
existing operations or attributes (i.e. the justification for points 3
to 7 in section 10).

> So is there some valid meaning to this statement?  Or should the 
> statement be something else?

Maybe, but AFAICS it is mainly advertising...

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

---

From: Trond Myklebust <[email-masked]>
Date: Tue, 11 Jul 2006 20:32:27 -0400

> is rejected in v4.1 because it has been made mandatory-to-

Agreed. Basically it is ensuring that I can reuse my READDIR or LOOKUP
xdr code every time we release another of those 500-page documents
(unless we for some reason decide that we need to replace the entire
READDIR or LOOKUP operation).

Cheers,
  Trond