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

[Eddy Quicksall <Eddy_Quicksall@ivivity.com>]

Regarding "support for both outcomes is required". I don't agree. Targets
can have all sorts of reasons not to support both.

It may be useful to have a value like "Reject" apply for cases like this.
Then, the initiator or target would the option to disconnect or try to keep
going depending on the key.


Eddy

-----Original Message-----
From: Martin, Nick [mailto:Nick.Martin@COMPAQ.com]
Sent: Friday, February 08, 2002 4:30 PM
To: Julian Satran; Eddy Quicksall
Cc: ips@ece.cmu.edu; Lakshmi Ramasubramanian
Subject: RE: iSCSI: Boolean value (yes, no) negotiation

Julian, Eddy, and Lakshmi,

OK, since I had it wrong last time.  Let me try to explain it again.

The default for ImmediateData is yes.  The result function is AND.

I->T ImmediateData=no

Presuming the target wanted "yes", the result ("yes" AND "no") is "no".

The target has one option

T->I ImmediateData=no          

If this response is omitted, the result is the same.  Login proceeds
presuming ImmediateData=no.

I have been corrected that ImmediateData=Reject is not valid.
A response of ImmediateData=yes is also not valid.
I do not see a login response code meaning option not supported by
target.

From this in infer that support for both ImmediateData=yes and
ImmediateData=no is required.  One is not supposed to build a target nor
an initiator which does not support both possible values for each
boolean.  For either possible result of the negotiation, both parties
should be able to proceed.

Is this correct?  If so, I think it is worth stating that support for
both outcomes is required.

Thanks,
Nick

> -----Original Message-----
> From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> Sent: Wednesday, February 06, 2002 10:41 PM
> To: Eddy Quicksall
> Cc: ips@ece.cmu.edu; julian_satran@il. ibm. com (E-mail);
> Martin, Nick;
> Lakshmi Ramasubramanian
> Subject: RE: iSCSI: Boolean value (yes, no) negotiation
>
>
> Eddy is right - reject is not intended/valid for booleans.
>
> Julo
>
>
>                                                              
>                                   
>                     Eddy Quicksall                           
>                                   
>                     <Eddy_Quicksall@iv       To:     "Martin,
> Nick" <Nick.Martin@compaq.com>,   
>                     ivity.com>                Lakshmi
> Ramasubramanian                           
>                                              
> <nramas@windows.microsoft.com>, ips@ece.cmu.edu   
>                     06-02-02 23:55           cc:     Julian
> Satran/Haifa/IBM@IBMIL              
>                                              Subject:     RE:
> iSCSI: Boolean value (yes, no)    
>                                               negotiation    
>                                   
>                                                              
>                                   
>                                                              
>                                   
>                                                              
>                                   
>
>
>
> 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
> >
>
>
>
>
>