Subject: More spec changes

From: "Noveck, Dave" <[email-masked]>
Date: Sat, 3 Aug 2002 05:20:18 -0700

Here's my input on the spec changes for 50, 57, 61, 72, that you 
asked me to handle.  When added to the migration/delegation issues, 
this takes care of about half of the high-priority list from my 
issue triage.  I now feel confident that, assuming high-quality 
pizza (spec fuel), we can finish the spec issues at the bakeoff.  
If Beepy were so cruel as to institute a pizza-but-no-whiskey-
until-the-spec-is-done rule, we could probably finish Monday 
night or very early Tuesday morning.

Issue 51: Value of initial sequence id needs to be described and clarified so 
that unnecessary restrictions are placed upon the value by server implementations. 

     Assume that should be "no unnecessary restrictions" in which case this
     should be done.  I believe the answer is that the initial sequence id
     is unconstrained.  Right?

>>> Discussion:

On second thought, why should it be unconstrained?  If you know it is a new 
lockowner (have determined that it can't be recycle requiring confirmation),
then starting at zero seems right.  If you have an open-confirm situation,
then yes, the initial value can be anything, because it isn't really an
initial value.

>>> Resolution: 

** After the last sentence of the first paragraph of section 8.1.5, add the
   following:

The first request issued for any given lock owner is issued with a sequence 
number of zero.

** After the penultimate sentence of the last paragraph of 8;.1.7 (which has 
   become the first paragraph of 8.1.8), insert the following sentences:

Since the OPEN_CONFIRM sequence connects a new lockowner on the server with
an existing lockowner on a client, the sequence number may have any value.
The OPEN_CONFIRM step assures the server that the value it received is the
correct one.

-------------------------------------------------------------------------

Issue 57: OPEN upgrade and share conflicts. Need to specify how the server 
is to apply share checks on an OPEN_UPGRADE. Suggestion is to have the share 
checks done first before applying OPEN_UPGRADE and will a conflicting share
mode fail an OPEN_UPGRADE? 

     I don't understand the suggestion.  I would resolve this by stating that
     an OPEN is to check for any conflicting opens, with the exclusion of the
     one being upgraded (i.e. the one for the same file and lockowner) which the
     client can check locally.

     I can come up with a detailed proposal for spec changes.

>>> Discussion:

What I wrote above is wrong.  First, there is no OPEN_UPGRADE operation,
although there is an OPEN_DOWNGRADE.  What you are doing is an OPEN,
pure and simple, and the mode bits should be checked against all existing 
opens which is what the spec already implies.  The spec doesn't say that
explicitly, but we can add that.

The V4 logic of open-merge is to reflect multiple independent opens
done on the client.  The merge is simply an artifact to deal with the
inability of some VFS's to allow open file information to be handled
properly.  Semantically, each OPEN stands on its own, and I believe that
all of the systems that implement share reservation semantics do so
without any special exception excusing reservations held by the same
process (i.e. lockowner), so that's what we'll do too.

>>> Resolution:

** Add to the end of the penultimate paragraph of the DESCRIPTION
   section of 14.2.16 (OPEN).

When such an OPEN is done, checking of share reservations for the 
new OPEN proceeds normally, with no exception for the existing OPEN
held by the same lockowner.

-----------------------------------------------------------------

Issue 61: Retransmission of CLOSE (how long to hold state) 

     I'll come up with something based on my comments in the issue and the
     fact that the reply cache will help here.

>>> Discussion:

I still think these comments are valid:

      I think the spec should say that a server SHOULD maintain that
      information until the earliest of:
      
      	    Another validly sequenced request for the same lockowner,
      	    that is not a retransmission.
      
      	    The time that a lockowner is freed by the server due to 
      	    period with no activity.
      
      	    All locks for the client are freed as a result of a 
      	    SETCLIENTID.
      
      It's a not a MUST so simple servers could just return no error
      if it gets a close request and it doesn't recognize the stateid
      (as long as it determines it is not a STALE_STATEID situation).

Not much else to say.

>>> Resolution:

** Add a new section after the current 8.9

8.9.1 Close and Retention of State Information

Since a CLOSE operation requests deallocation of a stateid, 
dealing retransmission of the CLOSE, may pose special difficulties,
since the state information, which normally would be used to 
determine the state of the open file being designated, might be
deallocated, resulting in an NFS4ERR_BAD_STATEID error.

Servers may deal with this problem in a number of ways.  To 
provide the greatest degree assurance that the protocol is being
used properly, a server should, rather than deallocate the stateid,
mark is as close-pending, and retain the stateid with this status,
until later deallocation.  In this way, a retransmitted CLOSE
can be recognized since the stateid points to state information with
this distinctive status, so that it can be handled without error.

When adopting this strategy, a server should retain the state 
information until the earliest of:

o     Another validly sequenced request for the same lockowner,
      that is not a retransmission.
      
o     The time that a lockowner is freed by the server due to 
      period with no activity.
      
o     All locks for the client are freed as a result of a 
      SETCLIENTID.

Servers may avoid this complexity, at the cost of less complete
protocol error checking, by simply responding NFS4ERR_OK in the
event of a CLOSE for a deallocated stateid, on the assumption that
this case must be caused by a retranmitted close.  When adopting
this approach, it is desirable to at least log an error when 
returning a no-error indication in this situation.  If the server
maintains a reply-cache mechanism, it can verify the CLOSE is 
indeed a retransmission and avoid error logging in most cases.

----------------------------------------------------------------

Issue 72: OPEN needs clarification of permission/ACLs be checked against 
the requested access. ACCESS also needs to be referenced.

     I guess this should be done.

>>> Discussion:

Well if you insist :-)

>>> Resolution:

** Add a new paragraph after the current penultimate paragraph of the
   IMPLEMENTATION section of 14.2.16 (OPEN): 

Based on the access value (READ, WRITE, or BOTH) the client should check
that the issuer has the proper access rights to perform the specified
operation.  This would generally be the results of applying the ACL access
rules to the file for the current requestor.  However, just as with the
ACCESS procedure, the client should not attempt to second-guess the server's
decisions, as access rights may change and may be subject to server
administrative controls outside the ACL framework.  If the requestor is
not authorized to READ or WRITE (depending on the access value), the server
must return NFS4ERR_ACCESS.  Note that since the NFS-v4 protocol does not
impose any requirement that READ's and WRITE's issued for an open file have
the same credentials as the OPEN itself, the server still must do appropriate
access checking on the READ's and WRITE's themselves.