RE: iSCSI - negotiating against defaults/renegotiation the same key

[Robert Snively <rsnively@Brocade.COM>]

For two reasons, I would favor B)

   1)  If you consider case a, and the target may drop the
	login, what is the (consistent and interoperable) behavior
	if it chooses not to drop the login.

   2)  If you consider case c or d, when does the new
	and successful negotiation take place on one key
	if the first negotiation was successful and operation
	had started.

By the way, how are dependent keys handled, where successful
negotiation of one parameter leaves another parameter outside
the accepted negotiation?  Is there some kind of negotiation
order or hierarchy?

>  1-Multiple negotiations on one key - we may choose one of 
> the following
>  ways out:
> 
>    a)say that both initiator and target MAY drop the login if 
> that happens
>    (and close the connection)
>    b)say that both initiator and target MUST drop the login 
> if that happens
>    (and close the connection)
>    c)say that this is legitimate (a negotiated parameter 
> change due to a
>    later change not know when the negotiation started)
>    d)say that the whole sequence of Login request/responses 
> is a a "single
>    single virtual exchange" and the last value is the single one that
>    counts in every direction - this one is somewhat related 
> to the length
>    question but does not allow branching decisions
> 
>  I am would favor a)