Re: iSCSI: Login Request error

[Luben Tuikov <luben@splentec.com>]

Parthi wrote:
> 
> > >  Responder should say  "Reject" in Text param negotiation.
> > >
> > >        ex.       Originator->  ImmediateData=Ye
> > >                     Responder ->  ImmediateData=Reject
> > >
> > >  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
> 
> 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".

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