Re: iSCSI Parameter Negotiation

[Stephen Bailey <steph@cs.uchicago.edu>]

Bob,

Excellent question.  I agree that it's unclear too, and I'm not even
sure what's `right' independently of what the spec says.  I think the
problem goes deeper than a simple yes/no.

My reading of the spec is that it (the spec) is 90% convinced that the
target can not `talk out of turn' (once a channel guy....).  However,
you have pointed out one (MaxConnections) of several examples where
this assumption doesn't work right.  Another example is marker
parameters---the target might want to ask for them even if the
initiator's not into it.  Furthermore, even if the initiator does
enable markers with an FMarker parameter, the targer may respond with
FMarker AND MarkInts, even though the initiator is satisfied with the
default values, and so, did not send the parameters.

I have proposed that we precisely specify the exchange characteristics
for each parameter in the operational set (security parameters already
seem to be well specified by merit of the fact that security exchanges
are themselves precisely defined).

Beyond the exchange characteristics of the parameters themselves comes
how they should appear in PDUs.  If the parameter exchanges are very
free-formed, the implementation complexity increases massively for no
corresponding increase in capability.  I.e. who really cares if
parameters must be sent in a specification-defined order versus any
order you feel like?  Who cares if you the target can return responses
in a single PDU or multiple?

I have a well formed opinion about how to specify to cut the
implementation complexity, but I want to get the requirements on the
table first.

Steph