RE: iSCSI: login issue - partial consensus call

[Michael Schoberg <michael_schoberg@cnt.com>]

Sorry this isn't a consensus message, but I just feel like the proposals
aren't getting us to the simplest solution.

Why put a square peg through a round hole?  A lot of things in this spec let
the client (initiator) dictate too much to the server (target).  Why?  If we
can't assume all initiators are aware of each other, why put things in the
protocol that can allow them to step on each other?  The target knows all
CID's, ISID's, TSID's, and everything else associated with the initiators
it's linked to, let it do the work of setting ID's.


CID - unique ID for this connection within the session.

The initiator doesn't need to specify this.  It only needs to set a flag
saying it wants to form a new connection for this session-ID.  Let the
target decide what the CID should be and send it back up to the initiator.
Letting the initiator decide this simply adds more checks to the target to
ensure that the initiator isn't trying to establish a connection-ID that
already exists.  Keep it simple.


ISID - initiator-defined session-identifier

Since initiators don't know about other initiators connected to this target,
this has the potential of causing problems.  Eliminate it.  The initiator
should simply state it's intentions of establishing a new session or adding
a connection to an existing session (via binary flags).  Recovery can be a
special case of the latter.  When the session or connection is established,
the target can return the ID's that make it unique the IC_T Nexus.  Those
ID's can be used to form new connections or recover from dropped
connections.