[Ips] session re-instatement

"Paul Hughes" <phughes@pillardata.com> Mon, 26 February 2007 16:23 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLicx-0004wZ-1M; Mon, 26 Feb 2007 11:23:03 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLicv-0004qa-PN for ips@ietf.org; Mon, 26 Feb 2007 11:23:01 -0500
Received: from mail3.pillardata.com ([209.120.231.20]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HLicq-00031B-98 for ips@ietf.org; Mon, 26 Feb 2007 11:22:57 -0500
Received: from coex02.trans.corp ([172.18.24.19]) by mail3.pillardata.com with ESMTP; 26 Feb 2007 08:22:49 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Mon, 26 Feb 2007 09:22:48 -0700
Message-ID: <16236EEEF4D4264DA31C2E35E3607CFE03DA6E25@coex02.trans.corp>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: session re-instatement
Thread-Index: AcdZwlsFNaGu4uqaSIqp1wvjQ+4J/A==
From: Paul Hughes <phughes@pillardata.com>
To: "IP Storage Mailing List (E-mail)" <ips@ietf.org>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793
Subject: [Ips] session re-instatement
X-BeenThere: ips@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Storage <ips.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ips>, <mailto:ips-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ips@ietf.org>
List-Help: <mailto:ips-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ips>, <mailto:ips-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1322799538=="
Errors-To: ips-bounces@ietf.org

Is there any text in RFC 3720 or the implementer's guide that prevents an initiator from simultaneously logging-in on two connections to the same target portal using the same InitiatorName, ISID, and TSIH=0?  If the logins were done sequentially, the second login would re-instate the session created by the first login, but I can see how a target might not do session re-instatement if the sessions are being created simultaneously.

Thanks,
Paul

_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips