Re: iSCSI: keys/parameter dependence

["John Hufferd" <hufferd@us.ibm.com>]

I do not see a problem with the Text, the previous key=value pairs are ones
that were in previous PDUs or key=value pairs that were scanned previous to
the current pair being scanned.  It is not clear that we have to write any
thing else to help people understand the concept of previous.  I think we
are straining at a nat here, and it is not worth the effort.

I do not see the problem.

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


Martins Krikis <mkrikis@yahoo.com>@ece.cmu.edu on 05/31/2002 01:15:26 PM

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


To:    Mike Donohoe <Mike.Donohoe@quantum.com>, "'ips@ece.cmu.edu'"
       <ips@ece.cmu.edu>
cc:
Subject:    Re: iSCSI: keys/parameter dependence



--- Mike Donohoe <Mike.Donohoe@quantum.com> wrote:

> From 12-95 4.3.3 pg 80 (and also in 4.4 pg 83):
>
> Whenever parameter action or acceptance are
> dependent on other parameters,
> the dependent parameters MUST be sent after the
> parameters on
> which they depend. If they are sent within the same
> command, a
> response for a parameter might imply responses for
> others.

I've been ignoring this paraghaph having been
convinced that there are no dependencies among
the operational parameters (those allowed to be
used in the operational stage of login), and that
any dependencies for security parameters would
be naturally observed by security protocols (i.e.,
first send me this, I'll send you that, now
send this, etc.).

However, I think you raised some good questions.
I think this paragraph should be removed.
Here are the reasons:

"(sent) after" isn't defined. It is unclear
whether "in higher numbered bytes within the
same PDU" qualifies as "after" or whether only
"in a PDU sent at a later time" would. 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.
Therefore, the text about them being sent in
"the same command" is likely irrelevant, too,
since many implementation simply won't check that.

But what's really dangerous here is that an
implementation that perceives some parameters
as dependent may take the "might imply" text
as an endorsement for sending back less key=value
pairs than was received, which could make the
other side never commit due to missing responses.
We certainly don't want to allow for such a
non-interoperability in the specification.

So, could we please get rid of this whole
paragraph?

Thanks,

Martins Krikis, Intel Corp.

Disclaimer: these opinions are mine and may not
            be those of my employer.


__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com