*** draft-ietf-nfsv4-minorversion1-PAv5.xml.new	2009-09-06 08:03:43.000000000 -0700
--- PAv6.d/draft-ietf-nfsv4-minorversion1-PAv6.xml	2009-10-28 16:42:01.000000000 -0700
***************
*** 57,65 ****
  <rfc
      category="std"
      ipr="trust200811"
!     docName="draft-ietf-nfsv4-minorversion1-PAv5.txt" >
  
! <!-- 	$Id: nfsv41_front.xml,v 1.25 2008/12/03 22:32:07 mre Exp $	 -->
  <!-- Copyright (C) The IETF Trust (2007) -->
  <!-- Copyright (C) The Internet Society (2006) -->
  
--- 57,65 ----
  <rfc
      category="std"
      ipr="trust200811"
!     docName="draft-ietf-nfsv4-minorversion1-PAv6.txt" >
  
! <!-- 	$Id: nfsv41_front.xml,v 1.26 2009/10/28 23:33:05 shepler.mre Exp $	 -->
  <!-- Copyright (C) The IETF Trust (2007) -->
  <!-- Copyright (C) The Internet Society (2006) -->
  
***************
*** 110,116 ****
                  <street>1601 Trapelo Road, Suite 16</street>
                  <city>Waltham</city>
                  <region>MA</region>
!                 <code>02454</code>
                  <country>USA</country>
              </postal>
              <phone>+1-781-768-5347</phone>
--- 110,116 ----
                  <street>1601 Trapelo Road, Suite 16</street>
                  <city>Waltham</city>
                  <region>MA</region>
!                 <code>02451</code>
                  <country>USA</country>
              </postal>
              <phone>+1-781-768-5347</phone>
***************
*** 119,125 ****
      </author>
  
  
!     <date year="2009" month="September" day="06"/>
  
      <area>Transport</area>
      <workgroup>NFSv4</workgroup>
--- 119,125 ----
      </author>
  
  
!     <date year="2009" month="October" day="28"/>
  
      <area>Transport</area>
      <workgroup>NFSv4</workgroup>
***************
*** 847,853 ****
  
  
  
! <!--    $Id: nfsv41_middle_core_infrastructure.xml,v 1.117 2009/09/05 23:48:16 shepler.mre Exp $  -->
  <!-- Copyright (C) The IETF Trust (2007-2009) -->
  <!-- Copyright (C) The Internet Society (1996-2006)  -->
  
--- 847,853 ----
  
  
  
! <!--    $Id: nfsv41_middle_core_infrastructure.xml,v 1.118 2009/10/28 23:33:06 shepler.mre Exp $  -->
  <!-- Copyright (C) The IETF Trust (2007-2009) -->
  <!-- Copyright (C) The Internet Society (1996-2006)  -->
  
***************
*** 3476,3483 ****
--- 3476,3609 ----
  
         </t>
  
+        <t>
+         If the second operation is an illegal operation, or an
+         operation that was legal in a previous minor version of
+         NFSv4 and MUST NOT
+         be supported in current minor version (e.g. SETCLIENTID), the
+         replier MUST NOT ever return NFS4ERR_RETRY_UNCACHED_REP.
+         Instead the replier MUST return NFS4ERR_OP_ILLEGAL, or
+         NFS4ERR_BADXDR, or NFS4ERR_NOTSUPP as appropriate.
+        </t>
+ 
+        <t>
+         If the second operation can result in another error status,
+         the replier MAY return a status other than NFS4ERR_RETRY_UNCACHED_REP,
+         provided the operation is not executed in such a way that the state
+         of the replier is changed. Examples of such
+         an error status include: NFS4ERR_NOTSUPP returned for an
+         operation that is legal but not REQUIRED in the current 
+         minor versions, and thus not supported by the replier;
+         NFS4ERR_SEQUENCE_POS; and NFS4ERR_REQ_TOO_BIG.
+        </t>
+ 
         </list>
        </t>
+     
+       <t>
+ 	The discussion above assumes that the
+ 	retried request matches the original
+ 	one.  <xref target="false_retry"/>
+ 	discusses what the replier might do, and
+ 	MUST do when original and retried requests do not match.
+         Since the replier may
+ 	only cache a small amount of the
+ 	information that would be required to
+ 	determine whether this is a case of a
+ 	false retry, the replier may send to the
+ 	client, any of the following responses:
+ 
+ 	<list style='symbols'>
+ 
+ 	<t>
+          The cached reply to the original request (if the replier has cached
+          it in its entirety, and the users of the original request and retry match).
+         </t>
+ 
+ 	<t>
+           A reply that consists only of the Sequence operation with the error
+ 	  NFS4ERR_FALSE_RETRY.
+         </t>
+ 
+         <t>
+ 	A reply consisting of the response to Sequence  with the status
+ 	NFS4_OK, together with the second operation as it appeared in the retried
+ 	request with an error of NFS4ERR_RETRY_UNCACHED_REP or other error as
+ 	described above.
+         </t>
+ 
+ 	<t>
+           A reply that consists of the response to Sequence with the status
+ 	NFS4_OK, together with the second operation as it appeared in the original
+ 	request with an error of NFS4ERR_RETRY_UNCACHED_REP or other error as
+ 	described above.
+         </t>
+         </list>
+ 
+       </t>
+ 
+         <section anchor="false_retry" title="False Retry">
+           <t>
+ 	If a requester sent a Sequence operation
+ 	with a slot ID and sequence ID that are
+ 	in the reply cache, but the replier
+ 	detected that the retried request is not
+ 	the same as the original request,
+ 	including a retry that has different
+ 	operations or different arguments in the
+ 	operations from the original, and a retry
+ 	that uses a different principal in the
+ 	RPC request's credential field that
+ 	translates to a different user, then this
+ 	is a false retry. When the replier
+ 	detects a false retry, it is permitted to
+ 	(but not always obligated to) return
+ 	NFS4ERR_FALSE_RETRY in response to the
+ 	Sequence operation when it detects a
+ 	false retry.
+ 
+           </t>
+          
+           <t>
+ 	Translations of particularly privileged
+ 	user values to other users due to the
+ 	lack of appropriately secure credentials,
+ 	as configured on the replier, should be
+ 	applied before determining whether the
+ 	users are the same or different. If the
+ 	replier determines the users are
+ 	different between the original request
+ 	and a retry, then the replier MUST return
+ 	NFS4ERR_FALSE_RETRY.
+ 
+           </t>
+ 
+           <t>
+ 	If an operation of the retry is an
+ 	illegal operation, or an operation that
+ 	was legal in a previous minor version of
+ 	NFSv4 and MUST NOT be supported in
+ 	current minor version (e.g. SETCLIENTID),
+ 	the replier MAY return
+ 	NFS4ERR_FALSE_RETRY (and MUST do so if
+ 	the users of the original request and
+ 	retry differ). Otherwise, the replier MAY
+ 	NFS4ERR_OP_ILLEGAL, or NFS4ERR_BADXDR, or
+ 	NFS4ERR_NOTSUPP as appropriate.  Note
+ 	that the handling is in contrast for how
+ 	replier deals with retries requests with
+ 	no cached reply. The difference is due to
+ 	NFS4ERR_FALSE_RETRY being a valid error
+ 	for only Sequence operations, whereas
+ 	NFS4ERR_RETRY_UNCACHED_REP is a valid
+ 	error for all operations except illegal
+ 	operations and operations that MUST NOT be
+ 	supported in the current minor version of
+ 	NFSv4.
+ 
+           </t>
+         </section>
+         
       </section> <!-- Optional Reply Caching -->
      </section> <!-- Slot Identifiers and Server Reply Cache -->
  
***************
*** 17260,17266 ****
      </t>
    </section>
  </section>
! <!-- $Id: nfsv41_middle_pnfs.xml,v 1.94 2009/09/05 18:53:42 shepler.mre Exp $ -->
  <!-- Copyright (C) The IETF Trust (2007-2008) -->
  <!-- Copyright (C) The Internet Society (2006) -->
  <section title="Parallel NFS (pNFS)" anchor="pnfs">
--- 17386,17392 ----
      </t>
    </section>
  </section>
! <!-- $Id: nfsv41_middle_pnfs.xml,v 1.95 2009/10/28 23:33:11 shepler.mre Exp $ -->
  <!-- Copyright (C) The IETF Trust (2007-2008) -->
  <!-- Copyright (C) The Internet Society (2006) -->
  <section title="Parallel NFS (pNFS)" anchor="pnfs">
***************
*** 18446,18452 ****
  <list style="numbers">
  <t>
    The client sent the LAYOUTGET before processing the CB_LAYOUTRECALL.
!   The "seqid" in the layout stateid of LAYOUTGET is two less 
    than the "seqid" in CB_LAYOUTRECALL. The server returns
    NFS4ERR_RECALLCONFLICT to the client, which indicates to the client
    that there is a pending recall.
--- 18572,18578 ----
  <list style="numbers">
  <t>
    The client sent the LAYOUTGET before processing the CB_LAYOUTRECALL.
!   The "seqid" in the layout stateid of the arguments of LAYOUTGET is one less 
    than the "seqid" in CB_LAYOUTRECALL. The server returns
    NFS4ERR_RECALLCONFLICT to the client, which indicates to the client
    that there is a pending recall.
***************
*** 21157,21163 ****
  </t>
  </section>
  </section>
! <!-- 	$Id: nfsv41_middle_errors.xml,v 1.79 2009/09/05 23:48:16 shepler.mre Exp $	 -->
  <!-- Copyright (C) The IETF Trust (2007-2008) -->
  <!-- Copyright (C) The Internet Society (2006) -->
  
--- 21283,21289 ----
  </t>
  </section>
  </section>
! <!-- 	$Id: nfsv41_middle_errors.xml,v 1.80 2009/10/28 23:33:08 shepler.mre Exp $	 -->
  <!-- Copyright (C) The IETF Trust (2007-2008) -->
  <!-- Copyright (C) The Internet Society (2006) -->
  
***************
*** 21829,21835 ****
               anchor="err_NOT_ONLY_OP">
        <t>
          Certain operations, which are allowed to be executed outside
!         of a session, MUST be the only operation within a COMPOUND.
          This error results when that constraint is not met.
        </t>
      </section>
--- 21955,21962 ----
               anchor="err_NOT_ONLY_OP">
        <t>
          Certain operations, which are allowed to be executed outside
!         of a session, MUST be the only operation within a Compound when
!         ever the Compound does not start with a Sequence operation. 
          This error results when that constraint is not met.
        </t>
      </section>
***************
*** 22481,22495 ****
          The requester sent a Sequence operation with a
          slot ID and sequence ID that are in the reply cache, but
          the replier has detected that the retried request
!         is not the same as the original request, including a retry
!         that has different operations or different arguments in the operations
!         from the original, and a retry that uses a different principal
!         in the RPC request's credential field that translates to a different
!         user. In the latter case, translations of particularly 
!         privileged user values to other users due to the lack of
!         appropriately secure credentials, as configured on the
!         server, should be applied before determining whether 
!         the users are the same or different.
        </t>
      </section>
      <section title="NFS4ERR_SEQ_MISORDERED (Error Code 10063)" 
--- 22608,22615 ----
          The requester sent a Sequence operation with a
          slot ID and sequence ID that are in the reply cache, but
          the replier has detected that the retried request
!         is not the same as the original request. 
!         See <xref target="false_retry"/>.
        </t>
      </section>
      <section title="NFS4ERR_SEQ_MISORDERED (Error Code 10063)" 
***************
*** 23180,23186 ****
  
      <c>ILLEGAL</c>
      <c>
!       NFS4ERR_BADXDR
        NFS4ERR_OP_ILLEGAL
      </c>
  
--- 23300,23306 ----
  
      <c>ILLEGAL</c>
      <c>
!       NFS4ERR_BADXDR,
        NFS4ERR_OP_ILLEGAL
      </c>
  
***************
*** 34752,34758 ****
     </t>
    </section>
  </section>
! <!-- 	$Id: nfsv41_middle_op_destroy_session.xml,v 1.17 2008/09/04 23:00:15 mre Exp $	 -->
  <!-- Copyright (C) The IETF Trust (2007-2008) -->
  <!-- Copyright (C) The Internet Society (2006) -->
  <section anchor="OP_DESTROY_SESSION" title="Operation 44: DESTROY_SESSION - Destroy a Session" >
--- 34872,34878 ----
     </t>
    </section>
  </section>
! <!-- 	$Id: nfsv41_middle_op_destroy_session.xml,v 1.18 2009/10/28 23:33:10 shepler.mre Exp $	 -->
  <!-- Copyright (C) The IETF Trust (2007-2008) -->
  <!-- Copyright (C) The Internet Society (2006) -->
  <section anchor="OP_DESTROY_SESSION" title="Operation 44: DESTROY_SESSION - Destroy a Session" >
***************
*** 34821,34845 ****
  
        </t>
  
        </list>
      </t>
      <t>
!       DESTROY_SESSION MAY be the only
!       operation in a COMPOUND request.
      </t>
      <t>
!       Because the session is destroyed, a client that
!       retries the request may receive an error in
!       reply to the retry, even though the original request was
!       successful.
  
      </t>
      <t>
       If there is a backchannel on the session and the
       server has outstanding CB_COMPOUND operations for the
       session which have not been replied to, then the server
       MAY refuse to destroy the session and return an error.
!      In the event the backchannel is down, the server
       SHOULD return NFS4ERR_CB_PATH_DOWN to inform the
       client that the backchannel needs to repaired before
       the server will allow the session to be destroyed.
--- 34941,34980 ----
  
        </t>
  
+       <t>
+ 	Because the session and its reply cache are destroyed, a client that
+ 	retries the request may receive an error in
+ 	reply to the retry, even though the original request was
+ 	successful.
+ 
+       </t>
+ 
        </list>
      </t>
+ 
      <t>
!       If the COMPOUND request starts with SEQUENCE, and
!       if the sessionids specified in SEQUENCE and DESTROY_SESSION
!       are the different, then DESTROY_SESSION can appear in any position
!       of the COMPOUND request (except for the first position). The
!       two sessionids can belong to different client IDs. 
      </t>
+ 
      <t>
!       If the COMPOUND request does not start with
!       SEQUENCE, and if DESTROY_SESSION is not the
!       sole operation, then server MUST return
!       NFS4ERR_NOT_ONLY_OP.
  
      </t>
+ 
      <t>
       If there is a backchannel on the session and the
       server has outstanding CB_COMPOUND operations for the
       session which have not been replied to, then the server
       MAY refuse to destroy the session and return an error.
!      If so, then
!      in the event the backchannel is down, the server
       SHOULD return NFS4ERR_CB_PATH_DOWN to inform the
       client that the backchannel needs to repaired before
       the server will allow the session to be destroyed.
***************
*** 34902,34908 ****
    </section>
  </section>
  
! <!-- 	$Id: nfsv41_middle_op_get_dir_delegation.xml,v 1.13 2008/09/04 23:00:15 mre Exp $	 -->
  <!-- Copyright (C) The IETF Trust (2007-2008) -->
  <!-- Copyright (C) The Internet Society (2006) -->
  <section anchor="OP_GET_DIR_DELEGATION" title="Operation 46: GET_DIR_DELEGATION - Get a directory delegation" >
--- 35037,35043 ----
    </section>
  </section>
  
! <!-- 	$Id: nfsv41_middle_op_get_dir_delegation.xml,v 1.14 2009/10/28 23:33:10 shepler.mre Exp $	 -->
  <!-- Copyright (C) The IETF Trust (2007-2008) -->
  <!-- Copyright (C) The Internet Society (2006) -->
  <section anchor="OP_GET_DIR_DELEGATION" title="Operation 46: GET_DIR_DELEGATION - Get a directory delegation" >
***************
*** 35012,35017 ****
--- 35147,35172 ----
        delegation is immediately available, the server SHOULD return it with
        the response to the operation, rather than via a callback. 
      </t>
+ 
+     <t>
+       When a client makes a request for a
+       directory delegation while it already holds
+       a directory delegation for that directory
+       (including the case where it has been
+       recalled but not yet returned by the client
+       or revoked by the server), the server MUST
+       reply with the value of gddr_status set to
+       NFS4_OK, the value of gddrnf_status set to
+       GDD4_UNAVAIL, and the value of
+       gddrnf_will_signal_deleg_avail set to
+       FALSE.  The delegation the client held
+       before the request remains intact, and its
+       state is unchanged. The current stateid is
+       not changed (see <xref
+       target="current_stateid"/> for a description
+       of the current stateid).
+ 
+     </t>
    </section>
    <section toc="exclude" anchor="OP_GET_DIR_DELEGATION_IMPLEMENTATION" title="IMPLEMENTATION">
      <t>