RE: iSCSI: login issue - partial consensus call

["KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>]

One clarification..

> This is also Venkat's concern - unintentional reuse of an ISID
> by the same Initiator:
> 
> > 2. There is some value in protecting an accidental use of an
> > existing ISID by a second client (ISID=<existing>, TSID=0).
> > This can be done with a Reject of the login attempt,
> 
> In contrast to some of the responses to Venkat, I interpret
> "client" to mean another iSCSI port on the same Initiator, and
> then his concern matches Julian's. 

"Another port on the same initiator" by definition has a different ISID and
thus this problem is not possible.  Maybe you mean another iSCSI driver?


> Venkat seems to think that
> there's a useful distinction between boot scenarios in t which
> teardown of existing sessions is needed and boot scenarios
> in which it's not needed

I haven't seen any examples where teardown of the dup session would not be
the desired behavior (or would be harmful).  That's the rationale I'd like
to hear.  If there isn't any conceivable use of the login reject
information, then perhaps it would satisfy Julian and others if we could
maintain the behavior of option A, but inform the initiator (via some sort
of reponse code) that an existing session had been aborted as a result of
this login?

Marj