RE: iSCSI: Negotiation clarifications still needed

[pat_thaler@agilent.com]

I can't parse (on page 68):

A value is whatever follows the = that follows the key-name up to a
zero-byte delimiter that separates a key=value pair from the next or
up to the end of data (for the last key=value pair if the PDU C flag
bit is set to 0).

I think I know what he meant but I can't get the text to parse clearly.
It is trying to do too much in one sentence.
How about:
A value is whatever follows the = that follows the key-name up to a
zero-byte delimiter. The zero-byte delimiter separates a key=value 
pair from the next and follows the last key=value pair when the PDU C flag
bit is set to 0.

The text on the bottom of page 72 is sufficient to produce the behavior
we want but it doesn't make clear the reason for having the C bit. We
don't need the C bit to know that the last value was incomplete. We need
it to allow us to prepare a multi-PDU buffer of key-value pairs for 
transmission.
How about:
Key=value pairs may span PDU boundaries. 

The C flag bit allows an initiator or target to prepare a set of
key values larger than the PDU size for transmission and send the set in
multiple 
PDUs ensuring that it will not receive key-value pairs while those PDUs are 
being transmitted. An initiator or target wishing to do this indicates that
more
text follows by setting the C flag bit in the Text Request or Text
Response to 1. A target or initiator receiving a Text Request or 
Text Response, respectively, with the C flag bit set to 1 MUST answer with a
Text Response or Text Request with no data segment (DataSegmentLength
0). A Text Request or Text Response PDU having the C flag
bit set to 1 MUST NOT have the F bit set to 1.

In 4 the bit is called the C flag bit. In 9.10 and 9.11, it is called the C
bit.
It should be called the same thing everywhere. Otherwise it becomes hard to
search for. As noted earlier the bit also needs to be added to 9.12 and
9.13.

With that done, I am content with the text though much the same thing
could be accomplished by enlarging PDU size during negotiation. The C bit 
just builds a super-PDU with pacing by the partner.

Regards,
Pat

-----Original Message-----
From: John Hufferd [mailto:hufferd@us.ibm.com]
Sent: Wednesday, May 29, 2002 8:23 PM
To: pat_thaler@agilent.com
Cc: wrstuden@wasabisystems.com; pat_thaler@agilent.com; Julian Satran;
cbm@rose.hp.com; ips@ece.cmu.edu; mkrikis@yahoo.com
Subject: RE: iSCSI: Negotiation clarifications still needed



I take it that we are all happy with the current C bit stuff (if it also is
in Login).  I think that is the hand off token.

.
.
.
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: hufferd@us.ibm.com


pat_thaler@agilent.com@ece.cmu.edu on 05/29/2002 04:15:57 PM

Sent by:    owner-ips@ece.cmu.edu


To:    wrstuden@wasabisystems.com, pat_thaler@agilent.com
cc:    Julian Satran/Haifa/IBM@IBMIL, cbm@rose.hp.com, ips@ece.cmu.edu,
       mkrikis@yahoo.com
Subject:    RE: iSCSI: Negotiation clarifications still needed




From: Bill Studenmund
<snip>
What do we want to decide?

Bill,

As I mention in the response to John, I would like to see proposed text for
specifying the hand-off.

I think one could approach this by handing back and forth the right to make
negotiation offers and leave to the implementations whether they send empty
text negotiations or responses and declarations when they don't have the
right to make negotiation offers. I think the hand-off should be based on a
bit flag rather than based on whether the last PDU received ended in a
complete key-value pair.

Once people have had a chance to see the proposal, I would like to hear
opinions beyond those of the few people who have been active in this
discussion.

Regards,
Pat