Subject: [nfsv4] Slight problem in section 8.5

From: "Noveck, Dave" <[email-masked]>
Date: Tue, 6 Apr 2004 07:39:01 -0700

Just noticed the following researching the STATEID-error issues.

RFC3530 (section 8.5) says:
> The following events cause implicit renewal of all of the leases for
> a given client (i.e., all those sharing a given clientid).  Each of
> these is a positive indication that the client is still active and
> that the associated state held at the server, for the client, is
> still valid.
>
> o  An OPEN with a valid clientid.
>
> o  Any operation made with a valid stateid (CLOSE, DELEGPURGE,
>    DELEGRETURN, LOCK, LOCKU, OPEN, OPEN_CONFIRM, OPEN_DOWNGRADE,
>    READ, RENEW, SETATTR, WRITE).  This does not include the special
>    stateids of all bits 0 or all bits 1.

RENEW and DELEGPURGE can't be done with a valid stateid since they
take a client id.  I guess this text didn't get updated when RENEW's
parameters were changed but not sure how the DELEGPURGE thing happened.

I must have looked at this text a dozen times and without noticing the 
problem.

Given that section 14.2.28 says that RENEW renews the lease (and that
section 8.5 does not say "these events, and only these events") we are
OK on RENEW.

For DELEGPURGE, I guess the spec is telling the server not to renew the 
lease.  One thing to note, when we try to fix this up, is that if 
section 8.5 is fixed up in the obvious way, by saying that the lease 
is to be renwed when DELEGPURGE is done with a valid clientid, it would
imply that if a client did a DELEGPURGE with a valid clientid, the 
server should renew the lease, even when it returns NFS4ERR_NOTSUPP :-)

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