RE: iSCSI: keys/parameter dependence

["Julian Satran" <Julian_Satran@il.ibm.com>]

There was never a requirement to respond immediately.

Julo

"THALER,PAT (A-Roseville,ex1)" <pat_thaler@agilent.com> Sent by: owner-ips@ece.cmu.edu 06/05/2002 03:23 AM Please respond to "THALER,PAT (A-Roseville,ex1)"

To:        "Robert D. Russell" <rdr@io.iol.unh.edu>, Robert Snively <rsnively@Brocade.COM>         cc:        ips@ece.cmu.edu         Subject:        RE: iSCSI: keys/parameter dependence

Bob,

I agree. There is no requirement to respond to the keys received in the
last batch in your next batch. 

Pat

-----Original Message-----
From: Robert D. Russell [mailto:rdr@io.iol.unh.edu]
Sent: Monday, June 03, 2002 11:45 PM
To: Robert Snively
Cc: ips@ece.cmu.edu
Subject: RE: iSCSI: keys/parameter dependence


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
> have to send them one at a time without the C bit set.

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


> 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.