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

["Buck Landry" <blandry@crossroads.com>]

Not that sixty other people won't answer this, but draft v10 states pretty clearly in section 1.2.4 that:

-> The value "?" MUST be used ONLY in Full Feature Phase.

IMHO if the initiator is willing to work with *or* without ImmediateData it should send ImmediateData=yes and let the target decide.

If the initiator can't use ImmediateData, it should send ImmediateData=no.  If the target supports only ImmediateData (now *that* would be interesting), the login session might as well terminate because the two implementations clearly aren't compatible.

I suppose if the initiator can only handle ImmediateData=yes, it should send that and terminate the session if the target sends back ImmediateData=no.  "Bad initiator! *whack*"

To respond directly to lakshmi,

> So that means, if the target needs to use ONLY immediate data,
> it has to fail the login because the initiator said NO to ImmediateData?

(again, IMHO) yup.

--buck


-----Original Message-----
From: Rahul Bhagwat [mailto:rahulb@veritas.com]
Sent: Wednesday, February 06, 2002 12:44 PM
To: Lakshmi Ramasubramanian; ips@ece.cmu.edu
Subject: Re: iSCSI: Boolean value (yes, no) negotiation


In this particular case, the default value for the key is "Yes". Initiator
should
be able to express it's preference that it wants to do away with immediate
date if the target is willing to do so (without forcing it through the AND
function),
else the initiator is okay to work with immedidate data. Looks like this is
not
possible with the boolean  negotiation. Can we use ImmediateData=? to get
the
supported value from the target. If the target responds with yes, the
initiator can
either use immediate data (by responding Yes) or not use it (by responding
No).
If the target response no, the initiator does not use immediate data. In
this case,
the Login need not terminate. Does this give the solution ? Is this a valid
thing ?

Regards,
Rahul
----- Original Message -----
From: "Lakshmi Ramasubramanian" <nramas@windows.microsoft.com>
To: "Rahul Bhagwat" <rahulb@veritas.com>; <ips@ece.cmu.edu>
Sent: Wednesday, February 06, 2002 11:40 PM
Subject: RE: iSCSI: Boolean value (yes, no) negotiation


> So that means, if the target needs to use ONLY immediate data,
> it has to fail the login because the initiator said NO to ImmediateData?
>
> thanks!
>  -lakshmi
>
> -----Original Message-----
> From: Rahul Bhagwat [mailto:rahulb@veritas.com]
> Sent: Wednesday, February 06, 2002 10:07 AM
> To: Lakshmi Ramasubramanian; ips@ece.cmu.edu
> Subject: Re: iSCSI: Boolean value (yes, no) negotiation
>
>
> I believe a key is not negotiated thrice as you have pointed out. That
> is a sender offers a value, receiver offers it's own and that's it. (I
> think specs has a mention that a key cannot be negotiated twice. This
> example falls into that category.) The result of the negotiation is key
> dependent. For example, in this particular key, when initiator sends
> ImmediateData=no, the negotiation is over as this is an
> AND function. However it is not an error to send back a response. In any
> case, the outcome of the result was decided for the initiator when it
> sent the key first and for the target when it received the key.
>
> Regards,
> Rahul
> ----- Original Message -----
> From: "Lakshmi Ramasubramanian" <nramas@windows.microsoft.com>
> To: <ips@ece.cmu.edu>
> Sent: Wednesday, February 06, 2002 10:56 PM
> 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
> >
>