Re: [iSCSI]: Key negotiation procedure proposal

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

Martins Krikis wrote:

> > Please note when this happens, there's no
> > choice but to close the connection!
> > I.e. both sides rejected each other's
> > values -- this is the core rule, and the result
> > of rejection on both sides == non-operability.
> 
> I know! But I should just close the connection
> now and log that I have met an incompatible Originator
> 
> instead of sending
> X-vendor-blah-login-reject-reason=duplicate_key
> and then close it. Subtle nuanses maybe, but my
> admin may like to know.


> 
> > > Do we have a requirement to let the other side
> > know
> > > what values we would have accepted? I'm saying,
> > let's
> > > just Reject what we don't like, close the
> > connection
> > > if we wish,
> >
> > There is no other choice Martins -- is it?
> > (Interoperability...)
> 
> Other choice than closing? Yes---we can keep it
> open and consider it negotiated for commit
> purposes, yet the value won't change. Other
> choice than interoperability? No, I guess
> there isn't. But interoperability can be easier
> achieved with sides not sending junk to the
> other side, than requiring rejecting sides
> to show what they would have liked...
 


>  However, I
> actually object to the whole idea of cutting any
> slack to non-conforming Originators by not Reject-ing
> their keys and sending a "good value" instead.
> I don't think it is good. So I'm for the removal of
> this possibility first, and only if somebody
> convinces me about the value of it, then for
> making the text more precise.
> Take care,
> 
>   Martins Krikis, Intel Corp.

I agree with all the points Martins Krikis makes above. I strongly
oppose the proposal made by Luben since it is too complex and it
complicates the base negotiation scheme in an attempt to accomodate
non-interoperable implementations.

In order to communicate to the other side as to what was the problem
with the login negotiation, there are several better/simpler ways to do
this than to have to send the key back with the value the target would
have supported. This does amount to re-negotiation and causes added
complexity on both sides.

If the target does not negotiate what the initiator requested, log an
error message, issue a reject response and close the connection. The
support personnel who diagnose the problem will be able to root cause
the problem from the error log. Alternatively, consider enhancing the
iscsi MIB statistics to provide better fault isolation data, so that the
MIB statistics can be used to determine the root cause of the problem.

There is no need to complicate the base login negotiation protocol in an
attempt to deal with such non-interoperable implementations.

This is not an issue of simple vs. complex implementations. Its a choice
that should be made regarding what is the simplest way to provide a
mechanism to fault isolate non-interoperable implementations.

Also, in such cases, the market will decide which implementations will
sell and those target implementations that cannot support what the
initiator is negotiating will not sell in that server/OS market. The
initiator is seldom going to change its negotiation options in an
attempt to be able to interoperate with that target.

Lastly, I think we ought to be freezing the spec and stop making changes
that are'nt bug fixes. If we don't do that, we are never going to make
it to RFC and ship some iscsi products. 

- Santosh


-- 
The world is so fast that there are days when the person who says 
it can't be done is interrupted by the person who is doing it.
	~ Anon