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

["Julian Satran" <Julian_Satran@il.ibm.com>]

Paul is correct. The AND rule was chosen in order to avoid having one party force ImmediateData when the other party does not want it.

Julo

Paul Koning <ni1d@arrl.net> Sent by: owner-ips@ece.cmu.edu 11-02-02 17:17

To:        Nick.Martin@compaq.com         cc:        ips@ece.cmu.edu         Subject:        RE: iSCSI: Boolean value (yes, no) negotiation

>>>>> "Martin," == Martin, Nick <Nick.Martin@compaq.com> 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