Re: iSCSI: keys/parameter dependence

["Robert D. Russell" <rdr@io.iol.unh.edu>]

Hi Martins:

Comments in text below:

> > 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, there ARE dependencies between operational
parameters that cannot be ignored, such as the one Mike mentioned
-- FirstBurstSize and MaxBurstSize are dependent because of the
requirement in section 11.15: "FirstBurstSize MUST NOT exceed
MaxBurstSize."  See my e-mail response to Mike for details
on that dependence.  I am also sending a following e-mail
that details 3 other dependencies.


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

I don't see this, and I agree with John Hufferd's response
to this that "previous" is obviously "previous", whether in
the previous PDUs (because the current PDU was delivered
after them) or in the same PDU (because key=value pairs
are naturally scanned from the beginning of a PDU's data segment,
and if nothing else, pairs had to be put into the data segment
in that order, and delivered on the wire in that order).
This is a non-issue.


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

> Therefore, the text about them being sent in
> "the same command" is likely irrelevant, too,
> since many implementation simply won't check that.

"command" should simply be replaced by "batch" or,
to be more consistent with the rest of the wording in the
standard, with "set of key=value pairs".
However, see my earlier e-mail to Julian stating my
concerns over the use of the C-bit for "batching".


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


Certainly not, and nowhere can I find anything in the standard
that implies responses can ever be omitted.  On the contrary,
there are several places where it says you MUST always respond.
For example, in section 4.2 on Text Mode Negotiation it says:
"A key not understood by the responder may be ignored by the
responder without affecting the basic function.  However, the
Text Response for a key not understood MUST be Key=NotUnderstood."
And in section 4.2.2 for simple-value negotiations it says
"For simple-value negotiations, the responding party MUST respond
with the same key."
The only time responses are optional are the 2 special-case
Boolean negotiations detailed at the end of section 4.2.
At no other time can responses be omitted.
This is also a non-issue.


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

I do not see how we can get rid of this paragraph.
However, perhaps it could be worded better to make it clearer
without changing its intent.

Best,

Bob Russell
InterOperability Lab
University of New Hampshire
rdr@iol.unh.edu
603-862-3774