Subject: iSCSI: ImmediateData negotiation

From: Dennis Young <[email-masked]>
Date: Wed, 8 May 2002 11:02:23 -0700

I have a question on how a target should respond to
"ImmediateData=Yes" from an initiator if the target
doesn't support ImmediateData.  Here are two scenarios:

Scenario 1:
/* The target here only considers the value offered by the
 * initiator, if the value is not acceptable, it simply 
 * rejects it rather than suggesting another value.
 */
I->T: ImmediateData=Yes
T->I: ImmediateData=Reject
I->T: ImmediateData=No  /* Should initiator offer No? */
T->I: ImmediateData=No

Scenario 2:
/* The target here simply returns a value it supports 
 * without rejecting the value offered by the initiator.
 */
I->T: ImmediateData=Yes
T->I: ImmediateData=No
I->T: ImmediateData=No  /* Should initiator reply No? */
T->I: ImmediateData=No

Based on section 4.2 of draft 12, I believe scenario 1 is correct, right?

In addition, does the Result function of a text parameter (AND or OR) make a
difference here?

Thanks,
Dennis

---

From: [email-masked]
Date: Wed, 8 May 2002 12:08:24 -0600

Actually, both are incorrect. It is illegal to negotiate a parameter more
than once during a login. The correct sequence is:

I->T: ImmediateData=Yes
T->I: ImmediateData=No

Both initiator and target must send ImmediateData=Yes for immediate data to
be used.

Kevin Lemay

-----Original Message-----
From: Dennis Young [mailto:[email-masked]]
Sent: Wednesday, May 08, 2002 11:02 AM
To: [email-masked]
Subject: iSCSI: ImmediateData negotiation

Scenario 1:

Scenario 2:

Thanks,
Dennis

---

From: [email-masked]
Date: Wed, 8 May 2002 12:56:47 -0600

Dennis,

That paragraph refers to "List" parameters and not boolean operators. Look
over to the next page....

"For Boolean negotiations (keys taking the values Yes or No), the responding
party MUST respond with the required key and the result of the negotiation
when the received value does not determine that result by itself. The last
value transmitted becomes the negotiation result. The rules for selecting
the value with which to respond are expressed as Boolean functions of the
value received and the value that the responding party would select in the
absence of knowledge of the received value."

Kevin Lemay

-----Original Message-----
From: Dennis Young [mailto:[email-masked]]
Sent: Wednesday, May 08, 2002 11:45 AM
To: [email-masked]'; [email-masked]
Subject: RE: iSCSI: ImmediateData negotiation

The following paragraphs in section 4.2 of draft 12
lead me to believe otherwise:
  ...
  The responding party answers with the first value that
  it supports and is allowed to use for the specfic originator
  selected from the originator list. 
  ...
  An offer of a value not admissible MAY be answered with
  the constant "Reject".

My interpretation of the two paragraphs is that the responding
party can only respond with value offered in the originator list,
and since "Yes" is not admissible, responding with "Reject"
seems correct.

Dennis

>From: [email-masked] [mailto:[email-masked]]
>Sent: Wednesday, May 08, 2002 11:08 AM
>To: [email-masked]; [email-masked]
>Subject: RE: iSCSI: ImmediateData negotiation
>
>

---

From: "John Hufferd" <[email-masked]>
Date: Wed, 8 May 2002 12:58:01 -0700

I think in the case mentioned, the Target will probably be the first sender
of the ImmediateData keyword and it will send No, because Yes is the
default.

.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136, Cell: (408) 499-9702
Internet address: [email-masked]

[email-masked]@ece.cmu.edu on 05/08/2002 11:56:47 AM

Sent by:    [email-masked]

To:    [email-masked], [email-masked]
cc:
Subject:    RE: iSCSI: ImmediateData negotiation

Dennis,

"For Boolean negotiations (keys taking the values Yes or No), the
responding

Kevin Lemay

-----Original Message-----
From: Dennis Young [mailto:[email-masked]]
Sent: Wednesday, May 08, 2002 11:45 AM
To: [email-masked]'; [email-masked]
Subject: RE: iSCSI: ImmediateData negotiation

Dennis