Re: [iSCSI]: Key negotiation procedure proposal

[Martins Krikis <mkrikis@yahoo.com>]

Luben,

I'm afraid I'm agreeing with Bill or Paul more here
than with you. 

The simple version looks perfectly acceptable.
I would not mandate closing the connection, since
I am also perfectly happy considering (on both
sides) the Reject-ed key to be "negotiated to
the current value" (i.e., negotiated, but the
value doesn't change on commit). But even
if closing is mandated, that's fine with me.
In fact, it is simpler so should be preferable.

If we go into the more complex version, where
you propose to let the originator know what
values would have made the responder happy... hmm...
First of all what you propose looks like
renegotion to me. It's now originating from the other
side, so it is kind-of justifyable and explainable.
However, just like Bill I don't like having to
send the key again in the next sequence. It does
require some new values for the state of the key.
Something like "received and rejected, but not yet
sent". Every new possibility for a state means
more checks upon reception and possibly even when
sending each key. Repeating the same key in the same
PDU sounds better, since then no new state is
necessary (sent+received) suffices. Or does it?
What if there is no space to send the key again
in the same PDU and it has to be left for the 
next time? Then it does need this extra state
again. Also, if it does get Reject-ed by the
other side (original Originator, now Responder),
we don't want to treat it as a no-renegotiation
violation, (unless we'll be closing the connection),
so we may need state.

To put it briefly, I think it still is too
complicated. The less state we can get away
with, the better. 

Speaking of mathematics, we have to express clearly
what the requirements are, then we can start proving
minimal sets of rules to satisfy those requirements.
Do we have a requirement to let the other side know
what values we would have accepted? I'm saying, let's
just Reject what we don't like, close the connection
if we wish, and if the other side doesn't like it,
its admin can give our admin a call and find what
values we like.

> > Example 2:
> > ----------
> > O: v = x  -->
> >          <--   R: v = y
> >
> > O: 1) v = y is OK, continue, as normal,
> >
> >    2) v = y is unacceptable,
> >
> >    v = Reject -->
> >
> >    close the connection (reason just given).

I don't quite get this one. How can y be unacceptable?
Did it violate the selection rules? If so, it's a
protocol error. We can just close the connection
or send the Reject PDU (not a key=Reject thing),
or send a Login Response with bad status, then close
the connection, it all depends of who we are.

In summary, I think I'm happy with what's currently
in 12-92, i.e., a key used twice by the same side
is a no-renegotiation violation.

  Martins Krikis, Intel Corp.

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








__________________________________________________
Do You Yahoo!?
LAUNCH - Your Yahoo! Music Experience
http://launch.yahoo.com