Re: [iSCSI]: Key negotiation procedure proposal

[Luben Tuikov <luben@splentec.com>]

Martins Krikis wrote:
>
> > 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"?

It means that the Originator SHOULD NOT send any
more offers. (key=another-value(s))

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

Yes, Randy mentioned this already and gave an excellent
example.

Well, this is an open question. Anyone?

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

NO! it must only remember the value of the key it sent!
The Originator will 1) close the connection with Reject,
2) accept the value quetly. (I can know, implied rule 1,
but we have to STOP somewhere or we'll never get to 
FF phase :-))

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

key=Reject is never considered renegotiation, since there is no
valid value being offered!
 
> 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.

Oh, well, there is the ``simple implementation'' rule.

Please remember that there is always the ``simple implementation''
rule (compatible with ``regular implementation'').

If the people feel comfortable with the logic then, some
may implement ``simple'' others may implement ``regular'',
both will interoperate and will get the job done.
 
> 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)

This will never work since  ``k(R) Intersection k(O) = Empty''.
If it did, then O: cheated in its offer! (and should be banned
from operating ;-))

-- 
Luben