Re: [iSCSI]: Key negotiation procedure proposal

[Martins Krikis <mkrikis@yahoo.com>]

Luben,

I'm not sure whether what you are proposing is or
is not an improvement to the current situation,
but unless it is perfect, we have no chance of
changing anything. So here are my comments.

> In other words you'd use ``simple implementation''
> rule. That is fine.

No. I'm not that kind of guy. I'd make an
implementation that could behave either as the
simple one or as the complex one, depending on
how it's configured to behave. :-)

> > First of all what you propose looks like
> > renegotion to me.
> 
> It is NOT, since the Originator is NOT allowed
> to send the same key twice, see implied rule 1.
> (If a Responder replies with Reject, then the
> Originator
> SHOULD NOT renegotiate the rejected key.)

But the Responder may, yes I know, I understand.
All I was trying to say is that after a key
has traveled in both direction seeing it travel
again _looks_ like a renegotiation. Period.
That's true even for my (later and not too serious)
key=? reinstantement proposal. I understand
that you could define what a renegotiation is
and exempt this case because it hasn't yet
traveled in that direction together with an
unreserved value. But then we need more state
than now. So, I understand that you don't call
this a renegotiation, but I don't consider it
beautiful either. Sorry.

> > However, just like Bill I don't like having to
> > send the key again in the next sequence.
> 
> This has already been finalized -- see the
> mailing list.

Mails crossed over the wires. I can't help the lag.

> > 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?
> 
> You could put it right after: e.g.
> [BHS+[opt]]key=Reject\000key=reponder_value\000...

Of course I would put it right after. Why would I
wait? But that does not guarantee that it will fit.
So what now? Adjusting the state, of course.

> > 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.
>
> Please note when this happens, there's no
> choice but to close the connection!
> I.e. both sides rejected each other's
> values -- this is the core rule, and the result
> of rejection on both sides == non-operability.

I know! But I should just close the connection
now and log that I have met an incompatible Originator

instead of sending 
X-vendor-blah-login-reject-reason=duplicate_key
and then close it. Subtle nuanses maybe, but my
admin may like to know.

> Yes, you do need state at the originator.

A super-nice implementation needs it on both sides. 
And more than currently. That's the reason I'm not
yet crazy about this proposal. Once the protocol
can work with as much or less state, I'll be more
agreeable.

> I think that the negotiation schematic is pretty
> simple, easiliy transferable into if () {} else {}
> etc.

I think it is more complicated than the current
situation, where I've got already plenty of all
kinds of flags. I'm reluctant to introduce more.

> I think that all here in this mailing list know
> what the requrements are -- interoperability.

If we're speaking mathematics, we will need to
get more precise.

> > 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,
> 
> There is no other choice Martins -- is it?
> (Interoperability...)

Other choice than closing? Yes---we can keep it
open and consider it negotiated for commit
purposes, yet the value won't change. Other
choice than interoperability? No, I guess
there isn't. But interoperability can be easier
achieved with sides not sending junk to the
other side, than requiring rejecting sides
to show what they would have liked...

> > > > 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?
> 
> Say, its a mininum of some values and the Originator
> found y to be too small.

It shouldn't find it too small. I don't think that's
allowed. For those kind of things we have ranges.
If using a range in negotiation is not allowed, 
then a compliant implementation should be happy
with any number that can be obtained by applying
the selection rule (min or max, so far) to the
number it supplied and to any number in the acceptable
range.

Alright, so here we have a chance to get more words
in the draft (whichever way it is).

> > 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.
> 
> Currently it looks like ``simple implementations''
> with the added bonus of loops.

Your example of loops (unless there have been more)
was based on the possibility of renegotiation.
The way I understand it (confirmed by a private
email from Julian) renegotiation is now disallowed.
Yes, even for Rejects, Irrelevants and NotUnderstoods.
The phrase that Pat suggested got added in 12-92,
except the last sentence. I have asked Julian why.

Plus, loops aren't as tragic as is complicating
the protocol. I don't mind having a configurable
counter that puts an upper bound on the number
of negotiation rounds. That's one variable per
all keys, instead of additional if/else cases
to be done for each key. 

But the way I see it, we cannot have loops anymore.
So what we have is like your "simple version",
except that closing the connection is not mandated. 
And simplicity is good. If we
mandate closure, I'm fine with that too. In fact,
I think it is the best, but not by an amount
worth fighting for.

> First, Originator shouldn't ``guess'' and keep
> sending
> same_key=value pairs indefinitely.

He no longer can. That would be a renegotiation.

> Second, in 4.2.2, 12-92, third change-bar from top
> has a inconsistenly problem (contradiction)
> as has been shown in this mailing list many times
> before.
> Depending on MAY 1) Reject, 2) send admissible value
> plus the next sentence ``not admissible by the
> selection rules...'' we get to a contradicion
> of negotiation...

Yes, true, not the clearest text. However, I
actually object to the whole idea of cutting any
slack to non-conforming Originators by not Reject-ing
their keys and sending a "good value" instead.
I don't think it is good. So I'm for the removal of
this possibility first, and only if somebody
convinces me about the value of it, then for
making the text more precise.
Take care,

  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