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

From: "Julian Satran" <[email-masked]>
Date: Thu, 23 May 2002 18:04:59 +0300

Discovering capabilities is best left to discovery (SLP, iSNS etc.).
Reject, Irrelevant etc., should be marginal and IMHO are here to handle 
gracefully exceptions.
I would not complicate negotiation beyond a one time handshake - except 
perhaps for deep negotiation trees 
if they can be proven useful. And even then I would leave them for iSCSI-2 
 :-)

Julo

Luben Tuikov <[email-masked]>
Sent by: [email-masked]
05/23/2002 04:35 PM
Please respond to Luben Tuikov

        To:     iSCSI <[email-masked]>, Julian Satran/Haifa/IBM@IBMIL
        cc: 
        Subject:        [iSCSI]: Key negotiation procedure proposal

I'm proposing the following key negotiation procedure. It
preserves the no-renegotiation of keys rule and all the
rules of login request and response currently used in the
draft (12-91). It applies to any kind of value (list,
boolean, integer, etc.).

Simple implementations:

Simple implementations SHOULD close the connection right
after Reject has been communicated. This ensures that the
reason for closing has been communicated to the peer.

Regular implementations:

Core rule: A negotiation of a key=value pair is
complete/finished when both the Originator and Responder
have sent their values (non-reserved keywords).

The core rule implies the the following:

If a Responder replies with Reject, then the Originator
SHOULD NOT renegotiate the rejected key.

If a Responder replies with Reject, it SHOULD sent its value
of that key on the next reply to the Originator.

If an Originator finds the response to an offered key=value
pair to be unacceptable, it SHOULD send Reject and close the
connection.

Please note that the core rule above ensures that both the
Originator and Responder _know_ each other's values if the
connection is closed due to Reject. This will give the user
of each node more information to find out what went wrong.
That is, this kind of negotiation is exhaustive.

Let O: denote Originator and R: the Responder.

Example 1:
----------
O: v = x  -->
         <--   R: v = Reject

O: ""     -->
         <--   R: v = y

O: 1) v = y is OK, continue as normal,
   2) v = y is unacceptable,
 
   v = Reject -->
   close the connection (reason just given).

Example 2:
----------
O: v = x  --> 
         <--   R: v = y

O: 1) v = y is OK, continue, as normal,

   2) v = y is unacceptable,
 
   v = Reject -->

   close the connection (reason just given).

-- 
Luben

---

From: Luben Tuikov <[email-masked]>
Date: Thu, 23 May 2002 11:29:44 -0400

But Julian, I'm _not_ talking here about discovering capabilities.

This is just rules for Login/Text Operational Key Negotiation.

The proposal here just puts forward one core
rule plus 3 more implied by the core rule,
and those 4 dictate the negotiations.

If you take a look at it carefully you'll see that it
obsoletes section 4.2.1 and 4.2.2, and will leave you
with exactly  58 lines of text for chapter 4.2 (that is
_including_ the examples).

It also solves all the problems we've been having
with login negotiation, renegotiation, etc, for which
so many of us have posted their opinions here on
this mailing list.

This has nothing to do with capabilities!

Furthermore I don't think that this complicates negotiation,
If anything ,it makes it simpler. There is a rule for simple
implementations (Martins, your opinion?) and a rule
for fully developed implementations.

It's just login/text negotiation rules.

People, take a look at the rules and examples
and let me hear your opinion? (those of you
involved in login/text neg. discussions)

--
Luben

Julian Satran wrote:
> Reject, Irrelevant etc., should be marginal and IMHO are here to handle gracefully exceptions.
> I would not complicate negotiation beyond a one time handshake - except perhaps for deep
> negotiation trees
> if they can be proven useful. And even then I would leave them for iSCSI-2  :-)
> 
> Julo
> 
>   Sent by: [email-masked]            To:        iSCSI <[email-masked]>, Julian
>                                     Satran/Haifa/IBM@IBMIL
>   05/23/2002 04:35 PM                       cc:
>   Please respond to Luben Tuikov            Subject:        [iSCSI]: Key negotiation procedure
>                                     proposal
> 
> 
>

---

From: Paul Koning <[email-masked]>
Date: Thu, 23 May 2002 12:54:34 -0400

Excerpt of message (sent 23 May 2002) by Luben Tuikov:
> ...

I think it's unnecessarily complex.  The "simple implementation" alone
is plenty.

   paul

---

From: Luben Tuikov <[email-masked]>
Date: Thu, 23 May 2002 13:11:30 -0400

> I think it's unnecessarily complex.  The "simple implementation" alone

Certainly!

But if we want more than that, then mathematics tells me
that those are the rules. (I.e. those are the minimum
consistent set of rules which achieve the task at hand.
It also tells me that there is no ``in the middle''
implementation.)

Please also note that ``simple implementations''
can co-exist with ``complete impementations''.
It's just that complete ones will get the TCP FIN,
when rejecting a simple implementation's key=value
pair, or just TCP FIN if the simple implementation
rejected theirs.

Julian, most of the negotiation the way we have it
now, already observes most of those rules.

And as to your request ``if they can be proven
useful'' -- a few examples on your own will
convince even the most doubtful heart. :-)

-- 
Luben
P.S. I just don't want to end up writing a paper
about this (co-authors welcome) as it happened
for CRC32C.