RE: iSCSI: keys/parameter dependence

[Martins Krikis <mkrikis@yahoo.com>]

--- pat_thaler@agilent.com wrote:

> The part that might cause interoperability problems
> is different 
> interpretations of which parameters action or
> acceptance is dependent on
> others. For instance, does the sentence mean that
> InitialR2T should be sent
> before FirstBurstSize and that FirstBurstSize
> doesn't need a response when 
> the response to InitialR2T was Yes? 

This is exactly why I wrote that leaving this
paragraph in the draft is dangerous. I would
really hate to have to start checking the dependency
graphs of parameters in order to figure out whether
I may signal readiness to commit or whether I should
keep waiting for a response to some key. Please
let's not go down this road. Boolean omissions
are relatively easily to deal with compared to
what this would entail.

> If the sentence is left in, then it should be
> clarified by adding something 
> such as:
> "The definition of a key specifies whether the key
> is dependent on any other 
> keys."
> and if any of our current keys are dependent, add to
> those keys
> "This key is dependent on <key names>."
> If none are currently dependent, it would be
> reasonable to add to 11 "Currently,
> no Login/Text Operational keys are dependent."

I don't mind them being dependent much, but if
values of some may be omitted due to values given
to others, it makes the negotiation much more
complicated. Let's not do that. "Each key that
has been sent should be received" is a nice and
simple rule that I'm voting for (boolean omissions
are an exception that can be overcome w/o too much
effort). 

> -----Original Message-----
> From: John Hufferd [mailto: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.

You just tried to define it, but I don't think
that the original meaning of "after" in the draft
was anything close to this. Besides, you're talking
about "scanning" order. I know that I'll be doing
batch processing of keys, i.e., first accumulate
them from all the PDUs that have the C-bit set
plus the next one that doesn't. So, you're saying
that "after" is defined wrt my scanning order?
How is the other side supposed to know how I'm
planning to "scan" the key=value pairs? I may find
it easier to do it from the other end, or sort
first, then process, etc.

Furthermore, even before the C-bit, there has never
been a requirement to answer one key before the next,
so specifying that in the case when two dependent
keys are sent in one command (PDU?) a response to
one might mean something about the other looks
very suspicious because logically the same should
be true then regardless of how the keys were
received.

> It is not clear
> that we have to write any
> thing else to help people understand the concept of
> previous.

If previous can have two different interpretations,
then IMHO a little more precision is appropriate.
You just bundled both together and introduced
yet another undefined thing called "scan". That
isn't much help either. Plus I wasn't shooting
for clarification of "after" as much as for
getting rid of ordering requirements.

> I think we
> are straining at a nat here, and it is not worth the
> effort.

I'm not straining yet, the issue really isn't that
difficult here. The key reception order should be
irrelevant because there are no requirements on
processing order. It should also be irrelevant
because there are no dependencies currently for
the operational parameters, nor should they be
introduced, because they would signifficantly add
to complexity. Finally, the last sentence is
dangerous because it seems to imply that there
could be more legal response omissions than just
for booleans, and I doubt that anybody wants that.

Therefore I said that I would like the whole
paragraph removed. Removing is not much of an
effort, AFAIK.

> I do not see the problem.

I do and I'm getting scared if others don't.

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