Message-ID: <3EAD5489.6060600@netapp.com>
Date: Mon, 28 Apr 2003 12:19:21 -0400
From: dave wysochanski <davidw@netapp.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020918
MIME-Version: 1.0
To: ips@ece.cmu.edu
CC: jpittman@netapp.com, Julian_Satran@il.ibm.com, cbm@rose.hp.com,
   csapuntz@cisco.com, meth@il.ibm.com
Subject: Re: iSCSI: ISID RULE and Discovery sessions
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

So let me see if I understand this correctly.

What we're saying here is that technically we have two distinct,
ISID enforcement spaces:
1) Discovery sessions with no target name defined in the login sequence
2) All other sessions with a target name defined in the login sequence

A target should not implicitly logout a session with the same
InitiatorName/ISID in the first space, if a session with the same
InitiatorName/ISID exists in the second space (and vice versa).
These sessions should be allowed to exist concurrently, with
no ISID rule violation.  But sessions with the same InitiatorName/ISID
within the same space should not be allowed to exist.

One thing that's confusing here is the use of "session" and
"I_T" nexus interchangeably in the spec.  Clearly though, the
case of a discovery session with no target name seems to be
a special case, which I'm not even sure it's fair to call it an
"I_T" nexus.  If it is to be considered an "I_T" nexus, the
"T" portion of the nexus is undefined.   I guess for those that
know the history and/or read between the lines this is all clear.
But it may merit a specific mentioning of this this special
case and how the ISID rule applies in a future revision.

Thanks.