Subject: [nfsv4] DESTROY_SESSION Errors

From: Rick Mesta <[email-masked]>
Date: Fri, 9 Nov 2007 17:15:07 -0600

Hi folks...

	 While working on the server side DESTROY_SESSION implementation
	(draft-15), I notice the following as the only possible valid
	return codes for DESTROY_SESSION:

    DESTROY_SESSION             NFS4ERR_BACK_CHAN_BUSY, NFS4ERR_BADSESSION, 
                                NFS4ERR_DEADSESSION, NFS4ERR_STALE_CLIENTID

	However, section 18.37.4 does not specify which of the above
	should be used in case the cred of the DESTROY_SESSION request
	does not match the cred of the session being targetted for
	destruction (of course, depending on state prot flavor).

	Should there be an additional error here for such case (e.g.
	NFS4ERR_PERM) ?

	Thx,
		rick

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: Mike Eisler <[email-masked]>
Date: Fri, 9 Nov 2007 18:57:17 -0800 (PST)

I agree that NFS4ERR_PERM is the correct error for Rick's scenario.

---

From: Rick Mesta <[email-masked]>
Date: Tue, 13 Nov 2007 15:20:57 -0600

On Fri, Nov 09, 2007 at 06:57:17PM -0800, Mike Eisler wrote:
| I agree that NFS4ERR_PERM is the correct error for Rick's scenario.
| 
	Thx Mike !

	While on topic, now that draft-16 is out, I noticed the
	following text...

--8<-- draft-16: 18.37.3 --8<--

"If the COMPOUND request starts with SEQUENCE, and if the sessions
 referred to by SEQUENCE and DESTROY_SESSION are the same, then

   o  DESTROY_SESSION MUST be the final operation in the COMPOUND
      request.

   o  It is advisable to not place DESTROY_SESSION in a COMPOUND request
      with other state-modifying operations, because the DESTROY_SESSION
      will destroy reply cache.

 DESTROY_SESSION MAY be the only operation in a COMPOUND request."

--8<-- draft-16: 18.37.3 --8<--

	... which raised a couple of questions;

	Q1) What server behavior is expected if the COMPOUND does
	    _indeed_ start w/SEQUENCE but the sessionid specified
	    in SEQUENCE does NOT match the sessionid specified in
	    the DESTROY_SESSION's arguments ? NFS4ERR_BADSESSION ?

	Q2) What server behavior is expected if the DESTROY_SESSION
	    is NOT the final OP in the COMPOUND, whether prefixed by
	    SEQUENCE or not ? What error should be returned ? Same
	    error for both scenarios ?

	I simply couldn't discern a sensible answer from the current
	text in the spec. Are these scenarios covered in an upcoming
	draft update ? If not, your guidance is highly valued.

		rick

---

From: "Noveck, Dave" <[email-masked]>
Date: Tue, 13 Nov 2007 18:08:05 -0500

>	    the DESTROY_SESSION's arguments ? NFS4ERR_BADSESSION ? 

No.  That's the desirable situation.  You are using one session 
as a transport mechanism to send an op which destroys another.

No problem with that.

>	    error for both scenarios ?

If it is not prefixed with SEQUENCE, than the error is NOT_ONLY_OP.

>	draft update ? If not, your guidance is highly valued.

The discussions I've heard are that DESTROY_SESSION does not have 
to be the last thing, but the session destroyed has to be different
than the one that that the reqquest is issued on.  I believe INVAL
is the error if it is not.

My understanding was that that would be in an upcoming draft.

-----Original Message-----
From: Rick Mesta [mailto:[email-masked]] 
Sent: Tuesday, November 13, 2007 4:21 PM
To: [email-masked]
Cc: Mike Eisler; Rick Mesta
Subject: Re: [nfsv4] DESTROY_SESSION Errors (contd)

		rick

---

From: Mahesh Siddheshwar <[email-masked]>
Date: Tue, 13 Nov 2007 15:46:35 -0800

> as a transport mechanism to send an op which destroys another.
I guess you are implicitly suggesting in the above sentence that the two 
sessions
should be using a transport connection associated with both the 
sessions, correct?

Since DESTROY_SESSION MUST be invoked on a connection associated
with the session, if it is not, I  guess a valid error that is missing 
and should
be added is -- NFS4ERR_CONN_NOT_BOUND_TO_SESSION.

So either SEQUENCE or DESTROY_SESSION will error out with
NFS4ERR_CONN_NOT_BOUND_TO_SESSION, in such cases.

Mahesh

---

From: Robert Gordon <[email-masked]>
Date: Wed, 14 Nov 2007 00:18:52 -0600

On Nov 13, 2007, at 5:46 PM, Mahesh Siddheshwar wrote:

> with the session, if it is not, I  guess a valid error that is  
> missing and should

Yes, this is a missing error for DESTROY_SESSION.

-- 
Robert...
"Procrastination is the thief of time"

---

From: Rick Mesta <[email-masked]>
Date: Wed, 14 Nov 2007 10:04:20 -0600

On Tue, Nov 13, 2007 at 03:46:35PM -0800, Siddheshwar Mahesh wrote:
| Noveck, Dave wrote:
| >>	Q1) What server behavior is expected if the COMPOUND does
| >>	    _indeed_ start w/SEQUENCE but the sessionid specified
| >>	    in SEQUENCE does NOT match the sessionid specified in
| >>	    the DESTROY_SESSION's arguments ? NFS4ERR_BADSESSION ? 
| >>    
| >
| >No.  That's the desirable situation.  You are using one session 
| >as a transport mechanism to send an op which destroys another.
| >
| >No problem with that.
| >
| >  
| I guess you are implicitly suggesting in the above sentence that the two 
| sessions
| should be using a transport connection associated with both the 
| sessions, correct?
| 
| Since DESTROY_SESSION MUST be invoked on a connection associated
| with the session, if it is not, I  guess a valid error that is missing 
| and should
| be added is -- NFS4ERR_CONN_NOT_BOUND_TO_SESSION.
| 
| So either SEQUENCE or DESTROY_SESSION will error out with
| NFS4ERR_CONN_NOT_BOUND_TO_SESSION, in such cases.
| 
| Mahesh

	Hi Mahesh,

	I was thinking about Dave's answer when I logged off for the
	evening. It seems to me that we have either...

	a) (as you note) an implicit (though subtle) hint that both
	   sessions share the same connection in cases such as...

		[ SEQ sessid-a, DESTROY_SESSION sessid-b ]

				<<< OR >>>

	b) there is a contradiction in the spec's text, since (again,
	   as you note) the inbound DESTROY_SESSION op MUST be bound 
	   to the session being destroyed.

	If it's a) above, I'd suggest clearer text to make sure we
	differentiate between a clientid with two sessions (as in
	case a) above) and the clientid with only a single session
	(in which case I would assume a singleton COMPOUND with only
	DESTROY_SESSION suffices ?

| >>	Q2) What server behavior is expected if the DESTROY_SESSION
| >>	    is NOT the final OP in the COMPOUND, whether prefixed by
| >>	    SEQUENCE or not ? What error should be returned ? Same
| >>	    error for both scenarios ?
| >>    
| >
| >If it is not prefixed with SEQUENCE, than the error is NOT_ONLY_OP.

	I don't see such error in draft-16, so I'm assuming it'll be
	something like NFS4ERR_NOT_ONLY_OP ?

| >>	I simply couldn't discern a sensible answer from the current
| >>	text in the spec. Are these scenarios covered in an upcoming
| >>	draft update ? If not, your guidance is highly valued.
| >>    
| >
| >
| >The discussions I've heard are that DESTROY_SESSION does not have 
| >to be the last thing, but the session destroyed has to be different
| >than the one that that the reqquest is issued on.  I believe INVAL
| >is the error if it is not.
| >
| >My understanding was that that would be in an upcoming draft.

	Ack... thx for the quick response, Dave.

		rick

---

From: Robert Gordon <[email-masked]>
Date: Wed, 14 Nov 2007 11:33:19 -0600

> 	something like NFS4ERR_NOT_ONLY_OP ?

Indeed.

Robert.