RE: [iSCSI]: Key negotiation procedure proposal

[pat_thaler@agilent.com]

I think it also makes sense to close the connection. Why try to 
interoperate when something is broken and for the existing parameters,
there is no reason for a Reject when an appropriate type value was offerred?
But if one really wants to give it a try there is a reasonable value to
use. All parameters that have a default can use that as the commit value if
an attempt to negotiate at login experiences a Reject. During full feature
they can use the old value.


Regards,
Pat

-----Original Message-----
From: Luben Tuikov [mailto:luben@splentec.com]
Sent: Thursday, May 23, 2002 5:23 PM
To: John Hufferd
Cc: Martins Krikis; ips@ece.cmu.edu
Subject: Re: [iSCSI]: Key negotiation procedure proposal


John Hufferd wrote:
> 
> Martins said:
> "...However, I actually object to the whole idea of cutting any slack to
> non-conforming Originators by not Rejecting their keys and sending a "good
> value" instead.  I don't think it is good. So I'm for the removal of this
> possibility...."
> 
> I agree with this.
> 
> I do not know if we have to end the connection after the Reject, but if the
> Originator sends it again, then shut down.  I see no value in going on and
> on (like this thread).  lets move to closure here.

Ok, ``simple implementation'' handles this.

But, John, what else can we do after sending key=Reject
_and_ inter-operate?!

We have to have some stringent rules, in order to
achieve inter-operability _and_ negotiation convergence.

If you have a constructive suggestion (a rule, ruleset, etc.),
please post it.
 
-- 
Luben