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

From: "Martin, Nick" <[email-masked]>
Date: Fri, 8 Feb 2002 15:30:21 -0600

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:[email-masked]]
> Sent: Wednesday, February 06, 2002 10:41 PM
> To: Eddy Quicksall
> Cc: [email-masked]; 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" <[email-masked]>,    
>                     ivity.com>                Lakshmi 
> Ramasubramanian                            
>                                               
> <[email-masked]>, [email-masked]    
>                     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:[email-masked]]
> Sent: Wednesday, February 06, 2002 2:18 PM
> To: Lakshmi Ramasubramanian; [email-masked]
> 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:[email-masked]]
> > Sent: Wednesday, February 06, 2002 11:26 AM
> > To: [email-masked]
> > 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
> >
> 
> 
> 
> 
>

---

From: Paul Koning <[email-masked]>
Date: Mon, 11 Feb 2002 10:17:04 -0500 (EST)

>>>>> "Martin," == Martin, Nick <[email-masked]> writes:

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

I don't agree, and it doesn't follow from the analysis.

If the rule is AND, then either end can force the outcome "no" by
proposing "no" (as initiator) or replying with "no" (as target).

If the rule is OR, then either end can force outcome "yes" by similar
reasoning. 

So the negotiation rules imply that you must support the outcome that
the other end can force.  The rules imply nothing about the other
outcome (e.g., "yes" for ImmediateData).  That could be optional to
support as far as the mechanism goes.  The spec can make it mandatory
if it is agreed to do so, but the mechanism doesn't affect such a
decision. 

    paul