Subject: Re: [iSCSI]: Key negotiation procedure proposal Rephrased

From: "John Hufferd" <[email-masked]>
Date: Thu, 23 May 2002 18:29:10 -0700

I am rephrasing the last note:

There are two things, to do when the key=value comes in wrong...
(That is after you respond with a Reject).

1. terminate the connection
OR
2. continue but do not accept that key again.(If attempted, terminate the
connection)
     a. What ever the defaults are, they stand.
     b. If there is no default, and the value is needed, terminate the
connection.

As for 1,  it is simple and not an interoperability problem -- FIX the
Problem.
As for 2:
* I do not think you need to be to formal here.  Either defaults work, or
they don't.  If they don't, then terminate and Fix the problem.
* I do not think this brings up interoperability problems. If it doesn't
work, terminate and fix the problem.

This is good enough.  Pick 1 or 2 and lets stop polishing the error case.

.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136, Cell: (408) 499-9702
Internet address: [email-masked]

Luben Tuikov <[email-masked]>@ns.splentec.com on 05/23/2002 05:23:14 PM

Sent by:    [email-masked]

To:    John Hufferd/San Jose/IBM@IBMUS
cc:    Martins Krikis <[email-masked]>, [email-masked]
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