Re: [iSCSI]: Key negotiation procedure proposal

[Luben Tuikov <luben@splentec.com>]

Bill Studenmund wrote:
> 
> That statement doesn't make sense.

I didn't see that you meant to send the 
Responder's offer along with the responder's Reject.
I see what you mean.
 
> I'm suggesting that we not wait for a future packet pair to send the value
> we would be happy with. As you so strongly pointed out, we can have
> multiple key=value tuples, why not repeat this key twice, once to indicate
> reject, and once to indicate our value. Thus the originator gets all the
> info it needs very quickly, we save a packet pair, and we don't need to
> add more state.

This certianly sounds reasonable. I'm happy with that.
So to make it more formal, the second implied rule should
read:

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

To recap:
---------------------
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 send its value
of that key in the same reply PDU to the Originator after the
key=Reject pair.

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

Well people, what do you think?

Bill, thanks for your analysis and support.

-- 
Luben