Subject: RE: iSCSI: keys/parameter dependence

From: [email-masked]
Date: Fri, 31 May 2002 18:02:40 -0600

John,

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? 

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

Pat

-----Original Message-----
From: John Hufferd [mailto:[email-masked]]
Sent: Friday, May 31, 2002 2:38 PM
To: Martins Krikis
Cc: Mike Donohoe; [email-masked]'
Subject: Re: iSCSI: keys/parameter dependence

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: [email-masked]

Martins Krikis <[email-masked]>@ece.cmu.edu on 05/31/2002 01:15:26 PM

Sent by:    [email-masked]

To:    Mike Donohoe <[email-masked]>, "[email-masked]'"
       <[email-masked]>
cc:
Subject:    Re: iSCSI: keys/parameter dependence

--- Mike Donohoe <[email-masked]> 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

---

From: Martins Krikis <[email-masked]>
Date: Fri, 31 May 2002 19:08:21 -0700 (PDT)

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

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

> 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

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.

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