Re: iSCSI Parameter Negotiation

[Sandeep Joshi <sandeepj@research.bell-labs.com>]

Steph,

It seems that the target is allowed to propose parameter values.
See http://ips.pdl.cs.cmu.edu/mail/msg03273.html

It seems that the statement which was added to resolve this 
is in Sec 2.8.3
 "All these keys except the X- extension formatted MUST be 
  supported by iSCSI initiators and targets"

I agree that the legal permutations need to be more clearly stated.
  
And your efforts to cut any implementation complexity will undoubtedly 
earn much goodwill :-)

regards,
-Sandeep 

Stephen Bailey wrote:
> 
> 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