[pnfs] Fwd: October Bakeathon: Draft 13 and NFSv4.1 OPEN clientid and other seqid/clientid questions.

[William A. (Andy) Adamson]

---------- Forwarded message ----------
From: William A. (Andy) Adamson <andros at citi.umich.edu>
Date: Sep 18, 2007 10:15 AM
Subject: Re: October Bakeathon: Draft 13 and NFSv4.1 OPEN clientid and other
seqid/clientid questions.
To: lisa.week at sun.com

oops! my mistake! please see below.

On 9/18/07, William A. (Andy) Adamson <andros at citi.umich.edu> wrote:
>
> Hi
>
> In the interest of interoperabilty in the face of a bit of confusion in
> draft 13, here is what I propose that the Linux server will do WRT NFSv4.0sequence IDs and client IDs for
> NFSv4.1.
>
> CLOSE, LOCK(old lockowner) , LOCKU, OPEN_DOWNGRADE
> - ignore sequence ID
>
> LOCK (new lockowner)
> - ignore OPEN client ID and sequence ID
>
> OPEN
> - ignore client ID
> - ignore sequence ID
>
> OPEN is the really confusing one  - I belive the intention in draft 13 is
> to ignore all client ID and sequence ID for NFSv4.1, and instead derive
> the client ID from the Session ID, and use the Session sequence ID.



and that is what it says....

draft 13 OPEN (section 18.16.4) says
>
> The client ID associated with the owner is
>    not derived from the client field of the owner parameter but is
>    instead the client ID associated with the session on which the
>    request is issued.  If the client ID field of the owner parameter is
>    not zero, the server MUST return an NFS4ERR_INVAL error.
>
> but I don't believe it !!


^^^^^^^^^^^^^^^^^
sorry - the above paragraph is fine - my mistake.

I would still like to know what the other implementations are doing...

-->Andy

What are other implementations doing?
>
> Regards
>
> -->Andy
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://linux-nfs.org/pipermail/pnfs/attachments/20070918/23929782/attachment.htm