Subject: RE: iSCSI: keys/parameter dependence

From: Robert Snively <[email-masked]>
Date: Mon, 3 Jun 2002 07:56:43 -0700

Picking up on this in the middle of a thread, I
find the following reply from Bob Russell
interesting:

> > It's
> > probably irrelevant, since due to the introduction
> > of the C-bit, parameters can be accumulated and
> > processed one "batch" at a time, without any
> > specific order within the "batch" and they will
> > quite likely not be processed PDU by PDU.
> 
> I don't see this either.  Nowhere does the newly added text
> describing the C-bit say anything about doing away with the
> specific order of the key=value pairs within the "batch".
> Why should it -- even if you don't process PDU by PDU you still
> have to process batch by batch, a batch still has to be scanned
> to find key=value pairs, and the natural way to scan is from the
> beginning of the batch, since the next key starts after the
> delimiter of the previous key in the batch.
> This is also a non-issue.

Skimming over rev 12, I have not found the word "order"
applied in the context of processing a string of 
key=value pairs.  While they
must clearly be parsed linearly, it is perfectly reasonable
to process the parsed values in any order, or even in 
a vendor-specific order than makes sense to a particular
target.  That is why key=value pairs are used in the
first place, so that one does not have to worry about 
ordering.  In this context, batching would be normal behavior
and out of order processing within a batch would also be
normal behavior.  If you want to order processing, you would
have to send them one at a time without the C bit set.

---

From: "Robert D. Russell" <[email-masked]>
Date: Tue, 4 Jun 2002 02:45:28 -0400 (EDT)

Robert:

You are, of course, absolutely correct.  There is no mention
in the current drafts of "order" applied to the processing of keys
-- there used to be such an "order" requirement, but that went out
when draft 8 came in, and is now ancient history.

My apologies to the entire list for mistakenly bringing it back.

I do, however, have a question about one small point in what you said:

> If you want to order processing, you would

Is this true?  When the C bit is not set, there appears to be
no requirement in the standard that the receiver is forced to
reply to the keys it has received at that time -- it MUST reply
to every key eventually, but just having the C bit = 0 does
not seem to require it to reply then -- it could send an empty
reply PDU, or could offer new keys of its own at that time
and delay responding to anything until "everything is on the
table".  Comments/corrections please.

Thanks
Bob Russell