OP_LOCK4: question about open_to_lock_owner4::lock_seqid

[DENIEL Philippe]

Hi to all,

I need precisions about the way the lock_seqid field should be used in 
OP_LOCK4 in the case of a new lock owner.
The RFC3540 says:

      The locker argument specifies the lock_owner that is associated with
       the LOCK request.  The locker4 structure is a switched union that
       indicates whether the lock_owner is known to the server or if the
       lock_owner is new to the server.  In the case that the lock_owner is
       known to the server and has an established lock_seqid, the argument
       is just the lock_owner and lock_seqid.  *In the case that the
       lock_owner is not known to the server, the argument contains not only
       the lock_owner and lock_seqid but also the open_stateid and
       open_seqid.  *The new lock_owner case covers the very first lock done
       by the lock_owner and offers a method to use the established state of
       the open_stateid to transition to the use of the lock_owner.

It seems to me that a new lock owner will create a new state if lock is 
successful with a brand new stateid. This stateid will contain a seqid of 0.
the open_to_lock_owner4::lock_seqid field is the "desired" seqid for the 
client, and since the lock owner is new, it can't be something else than 
0. So both client and server knowns this value is to be 0.
So far, I am wondering about the use of this field in the case of a new 
lock owner (if LOCK4arg::.locker.new_lock_owner == TRUE). Should I 
ignore it ? Should I check it is 0 and return an error if
the value is not 0 ? The test LOCK8c from newpynfs seems to take this 
position: if LOCK4arg::.locker.new_lock_owner == TRUE and lock_seqid != 
0, NFS4ERR_BAD_SEQID should be returned.
Is this the things to be implemented in my server ?

  Thanks in advance for your time and help

       Philippe