Re: [iSCSI]: Key negotiation procedure proposal

["Julian Satran" <Julian_Satran@il.ibm.com>]

All this thread is based on the assumption that discovery of what other side capabilities are is a good thing to have in the protocol.
Except for one item the group has decided a long time ago against it.
The messages consume an inordinate amount of time from all of us - and we are looking for things to fix (big or small).
If you think that negotiations have to be done some other way that is essentially better - please discuss this between yourselves and  submit an ID.
If something is badl in what we do now please be as concrete and brief as possible in outlining what is wrong and all of us will certainly listen - as we did in the past.

Julo

Martins Krikis <mkrikis@yahoo.com> Sent by: owner-ips@ece.cmu.edu 05/24/2002 12:33 AM Please respond to Martins Krikis

To:        ips@ece.cmu.edu         cc:                 Subject:        Re: [iSCSI]: Key negotiation procedure proposal

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.