Re: iSCSI: keys/parameter dependence

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

Hi Pat:

Comments in text below.

> The part that might cause interoperability problems is different
> interpretations of which parameters action or acceptance is dependent on
> others.

I agree -- see below.


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

See my responses to Mike Donahoe and Martins Krikis.  In particular,
an offered key ALWAYs requires a response (unless this happens during
login, in which case the responder can also just close the connection).
The response can be Reject or NotUnderstood or Irrelevant in certain
defined circumstances, but there must always be a response.


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

I believe the sentence should be left in and its intent remain unchanged.
However, clarification would certainly be desirable, and would probably
remove a lot of the current uncertainty.


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

There are dependencies, so such a statement cannot be added to section 11.

The existence of a dependency between FirstBurstSize and
MaxBurstSize is already clear from the statement in section 11.15:
"FirstBurstSize MUST NOT exceed MaxBurstSize."  My earlier e-mail to Mike
Donahoe details this dependency.

The existence of a dependency between OFMarker and OFMarkInt, and between
IFMarker and IFMarkInt, is implied by the statements in section A.3.2:
"When the interval is unacceptable the responder answers with
"Reject".  Reject is resetting the marker function in the spcified
direction (Output or Input) to No."
This last sentence should probably be reworded to say:
"A response value of "Reject" to an OFMarkInt (IFMarkInt) key resets the
corresponding OFMarker (IFMarker) key value to "No"."


Besides these two dependencies just mentioned,
I am aware of two other dependencies, and it would certainly would not
hurt to have all these made explicit in the appropriate sections of the
standard.  If anyone else has other dependencies to add, we should
all know about these now! :)

1. The table in section 11.12 describes the action taken on the four
combinations of InitialR2T = Yes/No and ImmediateData = Yes/No.
The combination InitialR2T=Yes and ImmediateData=No means "Unsolicited
data disallowed".  Therefore, FirstBurstSize becomes "Irrelevant" for
this combination.  This means that if FirstBurstSize is offered after
an offer of ImmediateData=No which is accepted, and either an explicit
offer of InitialR2T=Yes which is accepted or no explicit offer of
InitialR2T (in which case the applicable default value is Yes),
then a reply of FirstBurstSize=Irrelevant MAY be returned
(alternatively, a valid value can also be given in the reply).

2. Since the default value of OFMarker (IFMarker) is No, an offer
of OFMarkInt (IFMarkInt) without a previous explicit offer of
OFMarker=Yes (IFMarker=Yes) MAY generate the reply
OFMarkInt=Irrelevant (IFMarkInt=Irrelevant) -- it can, of course,
also reply with a valid value or with "Reject", as specified in
section A.3.2.
A similar reply of OFMarkInt=Irrelevant (IFMarkInt=Irrelevant) MAY
also be generated if the previous explicit offer of OFMarker=Yes
(IFMarker=YES) was refused by a reply of OFMarker=No (IFMarker=NO).

Best,

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