RE: iscsi : target originated login negotiations.

["Eddy Quicksall" <EQuicksall@mediaone.net>]

I agree. i.e., "The value picked by the responder is sent back
to the originator." In fact, that is how I thought it worked ... I'll have
to read it again.

You are exactly right in saying "it is the more familiar negotiation
technique that is in use in most other mass storage protocols".

Eddy

-----Original Message-----
From: Santosh Rao [mailto:santoshr@cup.hp.com]
Sent: Friday, September 28, 2001 5:46 PM
To: 'IPS Reflector'
Subject: Re: iscsi : target originated login negotiations.


All,

The below ambiguities go to further prove that the current negotiation
model for login keys [and also, login stages] is open to
mis-interpretation and is susceptible to interop issues.

I suggest that the initiator be always considered as an originator of
the keys, even when it uses the defaults. This ensures that the login
negotiation always culminates at the initiator and does not cause any
redundant round trips of login pdu's.

In this context, I also request the group to consider the alternate,
simpler, more familiar & more debuggable negotiation technique that has
been proposed in a separate thread with the subject : "iscsi : numerical
negotiation ambiguous".

Thanks,
Santosh



Eddy Quicksall wrote:
>
> This is the way I see it ... since the spec has been changed to say:
>
>  For numerical (and binary) negotiations, the responding party MUST
>  respond with the required key.
>
> So, the initiator MUST respond. Therefore, after the target starts a
> negotiation, the default no longer has a meaning.
>
> I would also like to hear the answer to (a) and (b) below.
>
> Eddy
>
> -----Original Message-----
> From: Santosh Rao [mailto:santoshr@cup.hp.com]
> Sent: Thursday, September 27, 2001 8:30 PM
> To: IPS Reflector
> Subject: iscsi : target originated login negotiations.
>
> All,
>
> I have a question on how the target originated negotiation works. The
> draft describes this as :
>
> "The target may offer key=value pairs of its own. Target requests are
> not limited to matching key=value pairs as offered by the initiator.
> However, the initiator always controls the request-response initiation
> and termination."
>
> Here's my question, taking a specific scenario as an example :
>
> Assume ImmediateData defaults to "yes" [as is currently the case].
> Consider an initiator that wishes to use immediate data attempting to
> login with a target that does not support immediate data.
>
> I -> T : (does not explicitly send ImmediateData key, since the
default
> is its desired value).
>
> T -> I : ImmediateData="no" (No ImmediateData key is received. Hence,
> target needs to originate this key to indicate that it does not
> support).
>
> Is this considered the end of the negotiation, or does the initiator
> (who is the responding party in this case) need to respond to the
> offered key with a response indicating :
> I -> T : ImmediateData="no"
>
> Also :
>
> a)  how does the above work in the case of list negotiation ?
>
> b) What is meant by "the initiator always controls the
>    request-response initiation and termination." (?).
>    Could this be stated more clearly ?
>
> Thanks,
> Santosh
>
> --
> ##################################
> Santosh Rao
> Software Design Engineer,
> HP-UX iSCSI Driver Team,
> Hewlett Packard, Cupertino.
> email : santoshr@cup.hp.com
> Phone : 408-447-3751
> ##################################

--
##################################
Santosh Rao
Software Design Engineer,
HP-UX iSCSI Driver Team,
Hewlett Packard, Cupertino.
email : santoshr@cup.hp.com
Phone : 408-447-3751
##################################