Subject: [nfsv4] October Bakeathon and Vestigial Locking Infrastructure From V4.0

From: "William A. (Andy) Adamson" <[email-masked]>
Date: Thu, 13 Sep 2007 16:08:30 -0400

Just a note that draft-ietf-nfsv4-minorversion1-13.txt has not changed the
draft-ietf-nfsv4-minorversion10.txt language concerning the requriement to
zero sequence id's and client id's in existing operations related to locking
(OPEN, LOCK, LOCKU, etc).

Since the October Bakeathon uses draft-ietf-nfsv4-minorversion1-13.txt, we
expect this behaviour. Maybe I missed something - but I thought that at the
Austin bakeathon it was decided that the server could ignore vestigial
locking sequence id and client ids....

-->Andy

>From draft-ietf-nfsv4-minorversion1-13.txt,
8.8.  Vestigial Locking Infrastructure From V4.0

          .......................

   Also, there are a number of fields, present in existing operations

Shepler, et al.          Expires January 2, 2008              [Page 160]
^L
Internet-Draft            NFSv4 Minor Version 1                July 2007

   related to locking that have no use in minor version one.  They were
   used in minor version zero to perform functions now provided in a
   different fashion.

   o  Sequence ids used to sequence requests for a given state-owner and
      to provide retry protection, now provided via sessions.

   o  Client IDs used to identify the client associated with a given
      request.  Client identification is now available using the client
      ID associated with the current session, without needing an
      explicit client ID field.

   Such vestigial fields in existing operations should be set by the
   client to zero.  When they are not, the server MUST return an
   NFS4ERR_INVAL error.
_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: "William A. (Andy) Adamson" <[email-masked]>
Date: Fri, 14 Sep 2007 10:34:44 -0400

Hi Mike

This is a bit of a long email where I look at each 4.0 operation related to
locking to see what draft 13 says about the operations seqid and clientid
WRT to 4.1, and compare it to what draft 13 says at the bottom of section
8.8.

The result: draft 13 is inconsistent to say the least!

At the end of the day, I agree that the draft 13 intent is to ignore seqid
and clientid for 4.1 for these operations, and to not ignore them for 4.0.

I believe this is what other implementations will bring to the bakeathon,
and so after checking, I will apply your changes.....

Hopefully, draft 14 will address this confusion.

Regards

-->Andy

On 9/13/07, Sager, Mike <[email-masked]> wrote:
>
>  Hi Andy,
>
> Section 18.10.4 of Draft 13 has this: "The client field of the lock owner,
> and all seqid values in the arguments MAY be any value and MUST be ignored
> by the server"  which is different from that of Draft 10.
>

Yes, but I believe this is supposed to be for 4.1 only, yet the draft does
not say so.
Also, the above section disagrees with 8.8.

For the case described in 8.8 below, the patched code distinguishes between
> 4.0 and 4.1, so I think both cases are covered.
>

Hmmm. Section 8.8 says that in 4.1, the sequenceid and clientid in the
"existing operations related to locking (e.g. OPEN, OPEN_DOWNGRADE, LOCK,
LOCKU, CLOSE)  MUST be set to zero else the server returns NFS4ERR_INVAL.
This directly contradicts section 18.10.4.

The draft is very confusing on how 4.1 deals with 4.0 sequence numbers and
client id's in these operations. Lets look:

The description of OPEN section in 18.16.4 agrees with section 8.8, but the
client ID description (below) does not mention this is for 4.1, not
4.0while the seqid description does mention
4.1 only.

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.

    The seqid value is not used in NFSv4.1, but it MAY be any value and
   the server MUST ignore it.

The description of OPEN_DOWNGRADE in section 18.18.4 disagrees with 8.8

  The seqid argument is not used in NFSv4.1, MAY be any value, and MUST
   be ignored by the server.

The description of LOCK in section 18.10.4 disagrees with 8.8, but the
section (below) does not stipulate that it is describing what 4.1 does, not
4.0

The client field of the lock owner, and all seqid values in the
   arguments MAY be any value and MUST be ignored by the server.  The
    client ID with which all owners and stateids are associated is the
   client ID associated with the session on which the request was
   issued.  The client ID appearing in a LOCK4denied structure is the
   actual client associated with the conflicting lock, whether this is
   the client ID associated with the current session, or a different
   one.

The description of CLOSE in section 18.2.4 disagrees with section 8.8, but
the section (below) does not stipulate that it is describing what 4.1 does,
not 4.0

   The argument seqid MAY have any value and the server MUST ignore
    seqid.

the description of LOCKU in section 18.12.4 disagrees with section 8.8, but
the section (below) does not stipulate that it is describing what 4.1 does,
not 4.0

  The seqid parameter MAY be any value and the server MUST ignore it.

Mike
>
>  -----Original Message-----
> *From:* William A. (Andy) Adamson [mailto:[email-masked]]
> *Sent:* Thursday, September 13, 2007 1:09 PM
> *To:* NFSv4
> *Cc:* [email-masked]
> *Subject:* [pnfs] October Bakeathon and Vestigial Locking Infrastructure
> FromV4.0
>

---

From: Spencer Shepler <[email-masked]>
Date: Fri, 14 Sep 2007 12:40:21 -0500

On Sep 14, 2007, at 9:34 AM, William A. (Andy) Adamson wrote:

> Hi Mike
>
> This is a bit of a long email where I look at each 4.0 operation  
> related to locking to see what draft 13 says about the operations  
> seqid and clientid WRT to 4.1, and compare it to what draft 13 says  
> at the bottom of section 8.8.
>
> At the end of the day, I agree that the draft 13 intent is to  
> ignore seqid and clientid for 4.1 for these operations, and to not  
> ignore them for 4.0 .
>
> I believe this is what other implementations will bring to the  
> bakeathon, and so after checking, I will apply your changes.....
>

I will see what I can get cleaned up.

Spencer

> Regards
>
> -->Andy
>
> On 9/13/07, Sager, Mike <[email-masked] > wrote:
> Hi Andy,
>
> Section 18.10.4 of Draft 13 has this: "The client field of the lock  
> owner, and all seqid values in the arguments MAY be any value and  
> MUST be ignored by the server"  which is different from that of  
> Draft 10.
>
>
> Yes, but I believe this is supposed to be for 4.1 only, yet the  
> draft does not say so.
> For the case described in 8.8 below, the patched code distinguishes  
> between 4.0 and 4.1, so I think both cases are covered.
>
> Hmmm. Section 8.8 says that in 4.1, the sequenceid and clientid in  
> the "existing operations related to locking (e.g. OPEN,  
> OPEN_DOWNGRADE, LOCK, LOCKU, CLOSE)  MUST be set to zero else the  
> server returns NFS4ERR_INVAL. This directly contradicts section  
> 18.10.4.
>
> The draft is very confusing on how 4.1 deals with 4.0 sequence  
> numbers and client id's in these operations. Lets look:
>
> The description of OPEN section in 18.16.4 agrees with section 8.8,  
> but the client ID description (below) does not mention this is for  
> 4.1, not 4.0 while the seqid description does mention 4.1 only.
>
> be ignored by the server. The description of LOCK in section  
> 18.10.4 disagrees with 8.8, but the section (below) does not  
> stipulate that it is describing what 4.1 does, not 4.0
>
> The description of CLOSE in section 18.2.4 disagrees with section  
> 8.8, but the section (below) does not stipulate that it is  
> describing what 4.1 does, not 4.0
>
> seqid.the description of LOCKU in section 18.12.4 disagrees with  
> section 8.8, but the section (below) does not stipulate that it is  
> describing what 4.1 does, not 4.0
> From: William A. (Andy) Adamson [mailto:[email-masked]]
> Sent: Thursday, September 13, 2007 1:09 PM
> To: NFSv4
> Cc: [email-masked]
> Subject: [pnfs] October Bakeathon and Vestigial Locking  
> Infrastructure FromV4.0
>
> Just a note that draft-ietf-nfsv4-minorversion1-13.txt has not  
> changed the draft-ietf-nfsv4-minorversion10.txt language concerning  
> the requriement to zero sequence id's and client id's in existing  
> operations related to locking (OPEN, LOCK, LOCKU, etc).
>
> Since the October Bakeathon uses draft-ietf-nfsv4- 
> minorversion1-13.txt, we expect this behaviour. Maybe I missed  
> something - but I thought that at the Austin bakeathon it was  
> decided that the server could ignore vestigial locking sequence id  
> and client ids....
>
> -->Andy
>
> pNFS mailing list
> [email-masked]
> http://linux-nfs.org/cgi-bin/mailman/listinfo/pnfs

---

From: "Iyer, Rahul" <[email-masked]>
Date: Fri, 14 Sep 2007 11:09:47 -0700

I think it might be wise to bring this up on the IETF list. That way we
can get it to their attention early enough so this can make the draft 14
boat.
-Rahul

> Sent: Friday, September 14, 2007 7:35 AM
> To: Sager, Mike
> Cc: [email-masked]; NFSv4
> Subject: [nfsv4] Re: [pnfs] October Bakeathon and Vestigial 
> LockingInfrastructure FromV4.0
> 
> Hi Mike
> 
> This is a bit of a long email where I look at each 4.0 
> operation related to locking to see what draft 13 says about 
> the operations seqid and clientid WRT to 4.1, and compare it 
> to what draft 13 says at the bottom of section 8.8.
> 
> ignore seqid and clientid for 4.1 for these operations, and 
> to not ignore them for 4.0 .
> 
> I believe this is what other implementations will bring to 
> the bakeathon, and so after checking, I will apply your changes.....
> 
> 	Section 18.10.4 of Draft 13 has this: "The client field 
> of the lock owner, and all seqid values in the arguments MAY 
> be any value and MUST be ignored by the server"  which is 
> different from that of Draft 10.  
> 
> 
> 
> Yes, but I believe this is supposed to be for 4.1 only, yet 
> the draft does not say so.
> 	For the case described in 8.8 below, the patched code 
> distinguishes between 4.0 and 4.1, so I think both cases are covered.
> 
> 
> Hmmm. Section 8.8 says that in 4.1, the sequenceid and 
> clientid in the "existing operations related to locking (e.g. 
> OPEN, OPEN_DOWNGRADE, LOCK, LOCKU, CLOSE)  MUST be set to 
> zero else the server returns NFS4ERR_INVAL. This directly 
> contradicts section 18.10.4.
> 
> The draft is very confusing on how 4.1 deals with 4.0 
> sequence numbers and client id's in these operations. Lets look:
> 
> The description of OPEN section in 18.16.4 agrees with 
> section 8.8, but the client ID description (below) does not 
> mention this is for 4.1, not 4.0 while the seqid description 
> does mention 4.1 only.
> 
> 
> The description of LOCK in section 18.10.4 disagrees with 
> The description of CLOSE in section 18.2.4 disagrees with 
> section 8.8, but the section (below) does not stipulate that 
> it is describing what 4.1 does, not 4.0
> 
> 
> the description of LOCKU in section 18.12.4 disagrees with 
> section 8.8, but the section (below) does not stipulate that 
> it is describing what 4.1 does, not 4.0
> 
> 		Subject: [pnfs] October Bakeathon and Vestigial 
> Locking Infrastructure FromV4.0
> 		
> 		
> 		Just a note that 
> draft-ietf-nfsv4-minorversion1-13.txt has not changed the 
> draft-ietf-nfsv4-minorversion10.txt language concerning the 
> requriement to zero sequence id's and client id's in existing 
> 		Since the October Bakeathon uses 
> draft-ietf-nfsv4-minorversion1-13.txt, we expect this 
> behaviour. Maybe I missed something - but I thought that at 
> the Austin bakeathon it was decided that the server could 
> ignore vestigial locking sequence id and client ids....
> 		
> 		-->Andy 
>

---

From: Spencer Shepler <[email-masked]>
Date: Fri, 14 Sep 2007 13:16:41 -0500

Heh, he did; [email-masked] is cc'd.

Spencer