Re: [iSCSI]: Key negotiation procedure proposal

[Martins Krikis <mkrikis@yahoo.com>]

Bill, Luben,

Sorry, my previous response was already somewhat dated. Hard to keep
up with you. :-)

> 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.

Does it mean it should not send or does it mean "should not send
with a non-reserved value"?

> 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.

There is the problem that it may not fit. If we leave it for the
next round, we have to remember that the state for this key is such.
In order to avoid this problem, we could use the key only once,
but use a list of values: first element "Reject", next elements
whatever was the value (or value list) that the Responder would
like. But, that's another big complication, so I am NOT proposing it.

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

But then the Responder (who both Reject-ed and responded to the key)
must remember that it not only sent the key but also rejected the
key, i.e., sent a value that does not necessarily fit in the selection
rules and which is not guaranteed to be liked by the Originator,
because if it is not liked, this Originator most likely will
send a Reject, which is not to be treated as a no-renegotionation
violation but just as a harmless little Reject. 

Thus, I think we need more state for this. But we gain the knowledge
of what values the other side likes. I like the latter feature
of course, but hate introducing more state. Plus I was getting
to feel happy about the current situation.

If the goal of this is to have a way to figure out what the other
side likes, perhaps it is simpler to reinstate the "key=?"
syntax, with the changed semantics, that the Responder must
send its acceptable values (not current). This would not count
as a start of a new negotiation, of course, so no extra state here.

I.e., 

O: k=u,v,w                   (I want (in order of preference) u, v or w)
R: k=Reject                  (But I hate all of those)
O: k=?                       (What do you like then?)
R: k=x,y,z                   (I like (in order of preference) x, y and z)

  Martins Krikis, Intel Corp.

Disclaimer: these opinions are mine and may not be those of my employer.