RE: iSCSI: Boolean value (yes, no) negotiation

[Eddy Quicksall <Eddy_Quicksall@ivivity.com>]

It looks to me like "reject" is intended for list negotiations (notice "all
of the offered options" ... I think that is referring to list options):

If a responder does not support or is not allowed to use all of the
offered options with a specific originator, it may use the constant
"Reject".

Julian, correct me if I am wrong.

Eddy

-----Original Message-----
From: Martin, Nick [mailto:Nick.Martin@compaq.com]
Sent: Wednesday, February 06, 2002 2:18 PM
To: Lakshmi Ramasubramanian; ips@ece.cmu.edu
Subject: RE: iSCSI: Boolean value (yes, no) negotiation

Lakshmi,

It is my understanding, that if either initiator or target begins
negotiation for a boolean by sending a key=value pair, the responder
applies the specified boolean function (to the requested value and the
current value) to obtain the result.  The result is then included in a
reply (unless the rules say it may be omitted).  This negotiation is
concluded.

I believe it should not be permitted for the responder, desiring a
different outcome, to later initiate negotiation for a different value
of the same parameter.  If both initiator and target were permitted to
do this, it can cause an endless loop.  However I do not find where this
is documented.

I have found an option for the target other than rejecting the login.
It can reject this parameter value with key=Reject.  The initiator in
this case can then accept the value previously in effect, negotiate for
another value, or close the connection.  I believe sending key=Reject
does not require that the entire login should fail.  The current value
for key should be unchanged by a negotiation ending in key=Reject, just
as if it never happened.

It is not always clear to me whether such negotiations are intended only
to allow selection of preferred modes of operation, or to enable
implementations which do not support certain features to operate with
other implementations which do not require those features.

For example, it is not stated whether a target or an initiator SHOULD or
MUST implement/accept both ImmediateData=yes and ImmediateData=no.

If these are for preferences, and the initiator and target are
configured for different preferences, what should be the result?  Either
result may allow operation.  In fact neither may be optimal for both
parties at the same time.  Is the result predictable?  Should we
negotiate differently for preferences versus requirements?  For example
should an initiator only negotiate preferences after the target has had
a chance to negotiate requirements?  Should we expect that key=Reject
could be the response to almost any key negotiation?

The suggestion by Rahul to use key=? is not permitted.  key=? is only
permitted in text commands, during full feature phase.  It returns the
current value, not the list of support values.  Requesting the list of
supported values is not a current capability.

Thanks,
Nick

> -----Original Message-----
> From: Lakshmi Ramasubramanian [mailto:nramas@windows.microsoft.com]
> Sent: Wednesday, February 06, 2002 11:26 AM
> To: ips@ece.cmu.edu
> Subject: iSCSI: Boolean value (yes, no) negotiation
>
>
> Could someone please clarify Boolean key=value usage
> (such as "ImmediateData=yes", etc)?
>
> For example, the initiator sends to target "ImmediateData=no".
> But the target wants ImmediateData. So, it sends back
> "ImmediateData=yes".
> The initiator, being able to handle it, sends back "ImmediateData=no".
> Now, they use immediate data in the PDUs.
>
> Is this valid? Or, in the above case if the target can't handle
> non-immediate data it has to reject the login ?
>
> thanks!
>  -lakshmi
>