Re: iscsi : iscsi parameter default values

[Santosh Rao <santoshr@cup.hp.com>]

Paul,

My comments inline.

Thanks,
Santosh

Paul Koning wrote:
> 
> Excerpt of message (sent 1 October 2001) by Santosh Rao:
> > All,
> >
> > As the one who started this thread, please allow me to raise one
> > important consideration to this discussion.
> > ...
> > The reason for applying the above criteria is that it provides the
> > benefit of completing login negotiation in a single handshake and in
> > most cases, where initiator goes with the defaults, allows no
> > negotiation to be required whatsoever. [in the case where no security is
> > being negotiated.]. This has the significant benefit of boosting iscsi
> > interoperability, since it has been seen that login is one of the most
> > painful areas of iscsi.
> >
> > With the above in mind, let us consider the 2 cases, Immediate data
> > default to "yes" & "no" (assuming neither side is interested in
> > security) :
> >
> > In the first case (default immediate data="yes') :
> > --------------------------------------------------
> > - Initiator wishes to use immediate data. Target does not support it.
> >
> > I -> T : (no key is sent. default assumed for immediate data).
> >        (CSG=Operational, NSG=FullFeaturePhase). T=1
> >
> > T -> I : ImmediateData="no" (tgt does not support imm data.)
> >        (CSG=Operational,NSG=Operational). T=0
> >
> > I -> T : (CSG=Operational, NSG=FullFeaturePhase). T=1
> >          (no keys to negotiate.
> >           negotiation completed at initiator.
> >           only phase change taking place.)
> >
> > T -> I : (CSG=Operational, NSG=FullFeaturePhase). T=1
> >          (target completes phase change.
> >           both sides move to FFP.)
> >
> >
> > Thus, in the above model, there's an extra dummy login handshake, when
> > the default ImmediateData is "yes" but targets don't support it for the
> > sole purpose of completing the login phase change.
> 
> If I understand this right, what you're saying is that a message with
> a login parameter omitted has different semantics than a message with
> that same parameter supplied and set equal to its default value. 

That's correct. 

The difference in semantics is due to the following text in Section 5.1
of the Rev 08 draft :

"An initiator that can operate without security and with all the
operational parameters taking the default values issues the Login with
the T bit set to 1, the CSG set to LoginOperationalNegotiation and NSG
set to FullFeaturePhase. If the target is also ready to forego security
and LoginOperationalNegotiation the Login response is empty and has T
bit set to 1, the CSG set to LoginOperationalNegotiation and NSG set to
FullFeaturePhase in the next stage."

The conclusion from the above is that if the initiator sent in all
defaults and some of these defaults are not acceptable to the target, it
must respond with T bit set to 0 & NSG set to Operational. 

(Target is unable to accept defaults and needs to explicitly originate
keys to notify the initiator that its defaults are unacceptable. Thus,
target could not forego operational negotiation due to its inability to
comply with the defaults and needs to respond with T=0.)


>  The
> difference is that in the latter case the target can respond with a
> different value for the parameter, whereas it cannot do so if the
> parameter is omitted.


Now, I'm not sure if we're saying the same thing :-} The target IS
allowed to respond with a different value even when the initiator used
defaults. However, since it did not forego operational negotiation,
based on the above quoted text, one has to conclude that it is not
allowed to change phase to FFP and must set T=0.


> 
> I do not find this rule in the discussion of the login request and
> response messages in the 0.8 spec.
> 
> In any case, it seems strange and counterproductive to have such a
> rule.  The conventional meaning of "default" is that you can omit
> stating the value of a parameter if its value is the default value,
> but the effect is the same whether you supplied it or not.
> 
> So I think the entire discussion can be cleared up with a simple
> repair: allow the target to ask for a different value for a parameter
> whether the parameter was omitted or not.
> 
> (An alternative repair is to do away with the notion of default values
> entirely, and require all parameters to be stated.)
> 
> In any case, though, the spec needs to change, either to express the
> rule Santosh referred to, or to express one of the repairs I
> suggested.

I think this login blob is all setup for inter-operability problems and
needs to be REALLY simplified and clarified. For example, the above
redundancy seems un-necessary and could be gotten rid of. The spec needs
to explicitly clarify WHEN the target & initiator can explicitly change
phases. 



-- 
##################################
Santosh Rao
Software Design Engineer,
HP-UX iSCSI Driver Team,
Hewlett Packard, Cupertino.
email : santoshr@cup.hp.com
Phone : 408-447-3751
##################################