Subject: iSCSI: Login Request error

From: Mike Donohoe <[email-masked]>
Date: Fri, 17 May 2002 09:14:41 -0700

1. What error case was the Status: 020B "Invalid during login" intended to
cover?  I can't find any other occurence in the spec of a "Request Type", to
say what an invalid one would be.

2.  If a target receives something like "ImmediateData=Ye" what would be a
proper status to return?

Thanks.

---

From: Bill Studenmund <[email-masked]>
Date: Fri, 17 May 2002 14:20:29 -0700 (PDT)

> say what an invalid one would be.

I believe any command other than login (or logout?) is invalid before you
hit full-feature phase. Thus any other such command would count as 020b.

> 2.  If a target receives something like "ImmediateData=Ye" what would be a

Either Reject or NotUnderstood come to mind.

Take care,

Bill

---

From: "Carlos Rimola" <[email-masked]>
Date: Fri, 17 May 2002 17:16:48 -0700

My understanding:

For question 1 - only Login request/responses are allowed before full
feature phase (no Logout since you are not logged in).

For question 2 - the correct response would either be Reject or Yes/No
(is ok to reply with an admissible value to an invalid/unrecognized
offer).  NotUnderstood should only be used when the key itself is not
recognized (e.g. ImmediateData misspelled like ImediateData).  The spec
explicitly states that NotUnderstood MUST NOT be used for known keys
(those defined in chapter 11).

Carlos Rimola
Silverback Systems 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Bill Studenmund
Sent: Friday, May 17, 2002 2:20 PM
To: Mike Donohoe
Cc: [email-masked]'
Subject: Re: iSCSI: Login Request error

> say what an invalid one would be.

I believe any command other than login (or logout?) is invalid before
you
hit full-feature phase. Thus any other such command would count as 020b.

Take care,

Bill

---

From: Parthi <[email-masked]>
Date: Sat, 18 May 2002 12:30:23 +0530

> 2.  If a target receives something like "ImmediateData=Ye" what would be a

 Responder should say  "Reject" in Text param negotiation.

       ex.       Originator->  ImmediateData=Ye
                    Responder ->  ImmediateData=Reject

 The status value would be  020b  "Invalid during login".

--
Parthiban M,
iSCSI Driver Team,
HCL Technologies Ltd.,          Tel : (+91)-44-3741939 to 42, Extn. 2332
http://san.hcltech.com

---

From: Bill Studenmund <[email-masked]>
Date: Mon, 20 May 2002 15:02:30 -0700 (PDT)

>  The status value would be  020b  "Invalid during login".

Would 020b be the correct error for that? I would have thought 0200
"Miscellaneous iSCSI initiator errors" would have been better; I thought
020b was exclusively for an attempt to do something that should only be
done in FFP, before you've gotten to FFP.

Take care,

Bill

---

From: Parthi <[email-masked]>
Date: Tue, 21 May 2002 10:44:43 +0530

> done in FFP, before you've gotten to FFP.

Hi :

  Draft says "Initiator Error(not a format error) -- This indicates request
for a resource for which the initiator
does not have permission. The request should not be tried again".

---

From: Luben Tuikov <[email-masked]>
Date: Tue, 21 May 2002 09:46:39 -0400

Parthi wrote:
>   Draft says "Initiator Error(not a format error) -- This indicates request for a resource for
> which the initiator

The status value should be 0 (Success). Note that
since we are talking about status codes, we imply
that the _Target_ replies.

That is, the Target should reply with (as already noted)
ImmediateData=Reject and status of 0. This would tell the
Initiator that login is proceeding ok, but ImmediateData
needs renegotiation/reconsideration.

Note that the Target may reply with other keys' responses,
along with the rejected ones.

Then the initiator will reconsider all rejected keys.

Note that a status code of anything but 0, implies
closing the connection.

Please see this message:
http://www.pdl.cmu.edu/mailinglists/ips/mail/msg09771.html

My reply is a bit messy, in that I should've been clearer,
that the originator of the key being rejected by the
responder, SHOULD, if available, offer another set of values,
or close the connection.

Currently, the draft says (pg 69, 12-90):

	If a responder does support, understand or is allowed
to use none of the offered options with a specific originator,
it MAY use the constant "Reject" or it MAY respond with an
admissible value. The selection of a value not offered is
considered a negotiation failure and is handled as a protocol
error.

Which is inconsistent with itself. (I.e. self-contradictory
to negotiation.)

Proof: By the first clause:
Assume that the responder cannot use any of the
offered options to a key (keyword ``none'' in the
first sentence). Then the responder 
   1) MAY Reject,
   2) MAY offer an admissible value.
Take 2) and proceed.

Then the originator receives an (admissible) value
which was NOT in what it offered and closes the
connection by the second clause.
Clearly, this is a negotiation failure.

If, on the other hand, we had chosen 1),
i.e. send Reject, the originator, may reconsider
it's options and send a different set of values,
and should one of them be acceptable to the
responder, we arrive at negotiation success.
QED.

This has already been communicated to Julian. Julian?

Nevertheless, a Reject response is required by
the responder to ``close the loop''.

If the originator doesn't close the connection
after that, the responder MAY choose to send
it's own values for the same (Rejected) key.
I.e. the responder to the Reject will now become
the originator of the Reject-ed variable.

-- 
Luben

---

From: Parthi <[email-masked]>
Date: Thu, 23 May 2002 12:50:49 +0530

> Initiator that login is proceeding ok, but ImmediateData

the draft says  (pg 99) : 6.8 Negotiation Failure
During Login, any failure in negotiation MUST be considered a
login process failure and the login phase must be terminated,
and with it the connection. If the target detects the failure,
it must terminate the login with the appropriate login
response code.

---

From: Luben Tuikov <[email-masked]>
Date: Thu, 23 May 2002 06:53:54 -0400

> it must terminate the login with the appropriate login

Wrong!

``Reject'' is a legitimate response. Pg 69, Sec 4.2.1.

Thus, replying with ``Reject'' doesn't necessarily
close the connection.

For your statement to be correct you have to define
``Negotiation Failure''.

-- 
Luben