Re: [iSCSI]: Key negotiation procedure proposal

[Martins Krikis <mkrikis@yahoo.com>]

--- Luben Tuikov <luben@splentec.com> wrote:
> > I do not know if we have to end the connection
> after the Reject, but if the
> > Originator sends it again, then shut down.  I see
> no value in going on and
> > on (like this thread).  lets move to closure here.
> 
> Ok, ``simple implementation'' handles this.

And it's a good one. But it's a subset of what's
currently allowed. Yes we could fight for
restricting the current rules a little and thus
hit your "simple implementation" proposal exactly,
but, it's probably not worth doing it.

> But, John, what else can we do after sending
> key=Reject
> _and_ inter-operate?!

Live with former (possibly default values) or we
don't interoperate. Why should I try my best to
interoperate with somebody who is either incompatible
with me (in case of list-value rejection) or who
is sending me junk (simple-value rejection)?

> We have to have some stringent rules, in order to
> achieve inter-operability _and_ negotiation
> convergence.

If there is strict no-renegotiation (including
keys answered with reserved values), which I now
believe is the case, then there is little worry
about convergence. And you need a counter anyway,
to guard against never ending blank requests.
As to interoperability, I'm saying "play tough"
and soon everybody will be forced to play by
the rules.

> If you have a constructive suggestion (a rule,
> ruleset, etc.),
> please post it.

We can just leave it as it is, perhaps stressing
a little more that no key may ever travel twice
in the same direction (regardless of value).

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