RE: iSCSI: keys/parameter dependence

["THALER,PAT (A-Roseville,ex1)" <pat_thaler@agilent.com>]

My comments are inserted with my initials. Pat

-----Original Message-----
From: Robert D. Russell [mailto:rdr@io.iol.unh.edu]
Sent: Sunday, June 02, 2002 12:10 PM
To: ips@ece.cmu.edu
Subject: Re: iSCSI: keys/parameter dependence

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

<PAT> This is an excellent example of why it is necessary 
to state explicitly where (if anywhere) one is required
to send parameters in a specific order. Requiring that
x not exceed y is equivalent to requiring y to be greater
than or equal to x. It doesn't imply the order. In any case, 
as long as each side independently ensures that the maximum 
value it will accept for FirstBurstSize does not exceed
the maximum value it will accept for MaxBurstSize, it doesn't
matter which is negotiated first. The relationship between
these two values does not imply an order and if we want to
force an order it will need to be done explicitly.

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

<PAT> Then the sentence: "If they are sent within the same command, a
response for a parameter might imply responses for others." should
be altered. "A response for a parameter might imply responses for
others" appears to some readers to say that those responses may 
be omitted since they are already implied though to other readers
it just means that the earlier response limits the response to
the later key.


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

<PAT> If the first sentence of the paragaph is to stay, then 
one needs to explicitly list the parameter ordering requirements
because dependency order is not clear. The second sentence
should be deleted as it doesn't say anything useful. It is 
clear that the response to earlier parameters limits the range
of responses to later parameters regardless of whether they 
are in the same PDU or not.

Regards,
Pat