[iSCSI]: Key negotiation procedure proposal

[Luben Tuikov <luben@splentec.com>]

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