Subject: RE: [nfsv4] V4.0 support requirements

From: "Noveck, Dave" <[email-masked]>
Date: Sun, 16 Jul 2006 10:40:01 -0400

> However, we really can't be sure there will be a v4.1 so I think 
> we should address this now.

Should have proofread this better.  I meant we can't be sure there
will be a v4.2.  I am sure there will be a v4.1.

-----Original Message-----
From: Noveck, Dave 
Sent: Sunday, July 16, 2006 9:50 AM
To: [email-masked]
Subject: [nfsv4] V4.0 support requirements

I've just created issue 92 for this. Text for the issue description
follows:
 
Currently, inherited from RFC3530, we have the requirement that a
v4.1 server MUST support v4.0 and similarly that a v4.1 client MUST
support v4.0.

There are some good reasons to consider weakening these, to SHOULD
perhaps.  The basic reason is that we have eliminated a whole bunch of
complexity with regard to  management of sequence state for owners and
the associated replay protection.  With the implementation of sessions,
none of that complexity is required but a MUST would make it required,
so you would wind up having to implement both sessions and the old-style
replay protection.

A large part of the purpose of simplifying the protocol is to simplify
the task of impementation, but a requirement to implement both would
mean that it was more complicated.  Until v4.1 is ubiquitous, clients
and servers are going to have to support v4.0 anyway so the mandate has
no purpose at that point.  But once v4.1 is ubiquitous, why should we
force people to do this extra implementation?  The other thing

here is that we may force people to implement this but we can't force
them to implement it well.  If we are in the v4.1 world and everybody
has to say that they support v4.0 then they will, even if the testing is
quite sketchy.  It would be far better if people could distinguish
between those that really supported v4.0 and those that didn't and that
would be easier without the requirement.

I think this issue is tied to the fact that we have made sessions
mandatory.  If v4.1 simply consisted of optional additions then the MUST
for supporting previous versions would be quite viable.

I had considered afddressing this issue in v4.2 by which time
v4.1-ubiquity would be on the horizon.  However, we really can't be sure
there will be a v4.1 so I think we should address this now.

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

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

---

From: "Noveck, Dave" <[email-masked]>
Date: Tue, 25 Jul 2006 15:38:10 -0400

I haven't heard any disagreement with this change.  I'm going to
assume that we have consensus.  I'll be moving this issue to 
to need-text.

With regard to the issue of generalization, I agree that the new
text needs to address this.  We need to update the minor versioning
section to address all of the v4.1 changes. 

One thing that we need to be clear about when we do this is that
this spec will be definitive with regards to v4.1 but can only
present guidelines for v4.x x > 1, just as what RFC3530 
says about v4.1 isn't binding on us.

-----Original Message-----
From: Spencer Shepler [mailto:[email-masked]] 
Sent: Tuesday, July 25, 2006 5:29 AM
To: [email-masked]
Subject: Re: [nfsv4] V4.0 support requirements

This approach is fine with me.  I might suggest that the issue be
generalized to making changes in the minor versioning rules since we
have broken rule #12 with the sessions decision.  We should reflect that
and any other changes needed.

Spencer

> the associated replay protection.  With the implementation of 
> sessions, none of that complexity is required but a MUST would make it

> required, so you would wind up having to implement both sessions and 
> the old-style replay protection.
> 

> and servers are going to have to support v4.0 anyway so the mandate 
> has no purpose at that point.  But once v4.1 is ubiquitous, why should

> we force people to do this extra implementation?  The other thing
> 
> has to say that they support v4.0 then they will, even if the testing 
> is quite sketchy.  It would be far better if people could distinguish 
> between those that really supported v4.0 and those that didn't and 
> that would be easier without the requirement.
> 
> mandatory.  If v4.1 simply consisted of optional additions then the 
> MUST for supporting previous versions would be quite viable.
> 
> v4.1-ubiquity would be on the horizon.  However, we really can't be 
> sure there will be a v4.1 so I think we should address this now.
>