From ips-bounces@ietf.org Mon May 02 14:18:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSfUl-0002XJ-Cy; Mon, 02 May 2005 14:18:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSfUj-0002Wy-Rb; Mon, 02 May 2005 14:18:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11547; Mon, 2 May 2005 14:18:12 -0400 (EDT) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DSfiS-0001Cs-Ql; Mon, 02 May 2005 14:32:25 -0400 Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j42IH9603396; Mon, 2 May 2005 11:17:09 -0700 (PDT) Message-Id: <200505021817.j42IH9603396@boreas.isi.edu> To: ietf-announce@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Mon, 02 May 2005 11:17:09 -0700 X-ISI-4-39-6-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu X-Spam-Score: -14.6 (--------------) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: ips@ietf.org, rfc-editor@rfc-editor.org Subject: [Ips] RFC 4018 on Finding Internet Small Computer Systems Interface (iSCSI) Targets and Name Servers by Using Service Location Protocol version 2 (SLPv2) X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org --NextPart A new Request for Comments is now available in online RFC libraries. RFC 4018 Title: Finding Internet Small Computer Systems Interface (iSCSI) Targets and Name Servers by Using Service Location Protocol version 2 (SLPv2) Author(s): M. Bakke, J. Hufferd, K. Voruganti, M. Krueger, T. Sperry Status: Standards Track Date: April 2005 Mailbox: mbakke@cisco.com, jlhufferd@comcast.net, kaladhar@us.ibm.com, marjorie_krueger@hp.com, todd_sperry@adaptec.com Pages: 23 Characters: 48498 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ips-iscsi-slp-09.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc4018.txt The iSCSI protocol provides a way for hosts to access SCSI devices over an IP network. This document defines the use of the Service Location Protocol (SLP) by iSCSI hosts, devices, and management services, along with the SLP service type templates that describe the services they provide. This document is a product of the IP Storage Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <050502111544.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc4018 --OtherAccess Content-Type: Message/External-body; name="rfc4018.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <050502111544.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --NextPart-- From ips-bounces@ietf.org Mon May 02 14:52:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSg2M-0005OP-6B; Mon, 02 May 2005 14:52:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSg2J-0005Ll-W2 for ips@megatron.ietf.org; Mon, 02 May 2005 14:52:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18116 for ; Mon, 2 May 2005 14:52:54 -0400 (EDT) Received: from rwcrmhc12.comcast.net ([216.148.227.85]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DSgG2-00036D-CY for ips@ietf.org; Mon, 02 May 2005 15:07:07 -0400 Received: from ivvt2dxrc11 (c-66-177-46-174.hsd1.fl.comcast.net[66.177.46.174]) by comcast.net (rwcrmhc12) with SMTP id <2005050218524401400kq6iae>; Mon, 2 May 2005 18:52:44 +0000 Message-ID: <001701c54f48$205f6710$0303a8c0@ivivity.com> From: "Eddy Quicksall" To: Date: Mon, 2 May 2005 14:52:43 -0400 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.9 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Subject: [Ips] ABORT TASK vs ABORT TASK SET X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1736285019==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============1736285019== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0014_01C54F26.9894D750" This is a multi-part message in MIME format. ------=_NextPart_000_0014_01C54F26.9894D750 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable For ABORT TASK SET, the target must wait for all outstanding tags to be = responded to. 10.6.2: b) Waits for all target transfer tags to be responded to and for all affected tasks in the task set to be received. But that is not mentioned for ABORT TASK. I'm wondering what the = rational was for ABORT TASK SET but not ABORT TASK. If the rational is = to cover possible race conditions at the initiator (e.g., still = transmitting/receiving data but also getting a TMF Complete) then it = would seem that the same race should be with ABORT TASK. Eddy ------=_NextPart_000_0014_01C54F26.9894D750 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
For ABORT TASK SET, the target must wait for all = outstanding=20 tags to be responded to.
 
10.6.2:
         b) = Waits for=20 all target transfer tags to be responded to=20 and
           = for=20 all affected tasks in the task set to be received.
 
But that is not mentioned for ABORT TASK. I'm = wondering what=20 the rational was for ABORT TASK SET but not ABORT TASK. If the rational = is to=20 cover possible race conditions at the initiator (e.g., still=20 transmitting/receiving data but also getting a TMF Complete) then it = would seem=20 that the same race should be with ABORT TASK.
 
Eddy
------=_NextPart_000_0014_01C54F26.9894D750-- --===============1736285019== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============1736285019==-- From ips-bounces@ietf.org Mon May 02 18:49:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSjjb-0000gM-83; Mon, 02 May 2005 18:49:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSjjZ-0000e1-Dw for ips@megatron.ietf.org; Mon, 02 May 2005 18:49:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26189 for ; Mon, 2 May 2005 18:49:46 -0400 (EDT) Received: from mononoke.wasabisystems.com ([66.173.145.228]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DSjxJ-0004pe-PG for ips@ietf.org; Mon, 02 May 2005 19:04:03 -0400 Received: from [10.0.0.10] (h-66-166-188-91.sndacagl.covad.net [66.166.188.91]) by mononoke.wasabisystems.com (Postfix) with ESMTP id 0383287062; Mon, 2 May 2005 18:49:42 -0400 (EDT) In-Reply-To: <001701c54f48$205f6710$0303a8c0@ivivity.com> References: <001701c54f48$205f6710$0303a8c0@ivivity.com> Mime-Version: 1.0 (Apple Message framework v622) Message-Id: <9df4ce8d768c0fe01a41ca8f04caf64f@wasabisystems.com> From: William Studenmund Subject: Re: [Ips] ABORT TASK vs ABORT TASK SET Date: Mon, 2 May 2005 15:49:36 -0700 To: "Eddy Quicksall" X-Pgp-Agent: GPGMail 1.0 (v30, 10.3) X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0429762901==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org --===============0429762901== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-7--671977259" Content-Transfer-Encoding: 7bit --Apple-Mail-7--671977259 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On May 2, 2005, at 11:52 AM, Eddy Quicksall wrote: > For ABORT TASK SET, the target must wait for all outstanding tags to=20= > be responded to. > =A0 > 10.6.2: > =A0=A0=A0=A0=A0=A0=A0=A0 b) Waits for all target transfer tags to be = responded to and > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 for all affected tasks in the task = set to be received. > =A0 > But that is not mentioned for ABORT TASK. I'm wondering what the=20 > rational was for ABORT TASK SET but not ABORT TASK. If the rational is=20= > to cover possible race conditions at the initiator (e.g., still=20 > transmitting/receiving data but also getting a TMF Complete) then it=20= > would seem that the same race should be with ABORT TASK. My take on this was that you send an ABORT TASK when you know you want=20= to kill a task. Chances are you know a lot about what's going on with=20 it, so you will be able to clearly deal with internal state issues. My take on ABORT TASK SET is that while you may use it when you know a=20= lot about what's going on, you may also use it when you detect an=20 internal consistency error. Think of it as a panic button. You press it=20= when you're in trouble. Take care, Bill= --Apple-Mail-7--671977259 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFCdq6FDJT2Egh26K0RAn9yAJkB5V5vUdco+noPn8TTwaVc2KbinwCeN16/ ptoOzBFxwMVZwAu9Ky2LriE= =nwIq -----END PGP SIGNATURE----- --Apple-Mail-7--671977259-- --===============0429762901== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0429762901==-- From ips-bounces@ietf.org Tue May 03 18:15:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DT5fb-0002VC-3Q; Tue, 03 May 2005 18:15:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DT5fY-0002TF-S7; Tue, 03 May 2005 18:15:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17627; Tue, 3 May 2005 18:15:06 -0400 (EDT) Received: from mtagate4.de.ibm.com ([195.212.29.153]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DT5tV-0001Gs-Fa; Tue, 03 May 2005 18:29:35 -0400 Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id j43MEuqF074184; Tue, 3 May 2005 22:14:56 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1507.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j43MEuvi257062; Wed, 4 May 2005 00:14:56 +0200 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id j43MEtwP028686; Wed, 4 May 2005 00:14:56 +0200 Received: from d12ml102.megacenter.de.ibm.com (d12ml102.megacenter.de.ibm.com [9.149.166.138]) by d12av02.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j43MEtEv028683; Wed, 4 May 2005 00:14:55 +0200 In-Reply-To: <9df4ce8d768c0fe01a41ca8f04caf64f@wasabisystems.com> To: William Studenmund Subject: Re: [Ips] ABORT TASK vs ABORT TASK SET MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_04212005NP April 21, 2005 From: Julian Satran Message-ID: Date: Wed, 4 May 2005 01:14:54 +0300 X-MIMETrack: Serialize by Router on D12ML102/12/M/IBM(Release 6.5.1| March 5, 2004) at 04/05/2005 01:14:54 Content-Type: multipart/mixed; boundary="=_mixed 0079646586256FF6_=" X-Spam-Score: 2.6 (++) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: ips@ietf.org, Eddy Quicksall , ips-bounces@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org --=_mixed 0079646586256FF6_= Content-Type: text/html; charset="US-ASCII"
The rational is that Abort task has to be sent on the connection on which the task was issued and then it is easy to assure serialization.
That is not the case with task set.

Regards,
Julo


William Studenmund <wrstuden@wasabisystems.com>
Sent by: ips-bounces@ietf.org

02/05/2005 17:49

To
"Eddy Quicksall" <eddy_quicksall_iVivity_iSCSI@comcast.net>
cc
ips@ietf.org
Subject
Re: [Ips] ABORT TASK vs ABORT TASK SET





On May 2, 2005, at 11:52 AM, Eddy Quicksall wrote:

> For ABORT TASK SET, the target must wait for all outstanding tags to
> be responded to.
>  
> 10.6.2:
>          b) Waits for all target transfer tags to be responded to and
>             for all affected tasks in the task set to be received.
>  
> But that is not mentioned for ABORT TASK. I'm wondering what the
> rational was for ABORT TASK SET but not ABORT TASK. If the rational is
> to cover possible race conditions at the initiator (e.g., still
> transmitting/receiving data but also getting a TMF Complete) then it
> would seem that the same race should be with ABORT TASK.

My take on this was that you send an ABORT TASK when you know you want
to kill a task. Chances are you know a lot about what's going on with
it, so you will be able to clearly deal with internal state issues.

My take on ABORT TASK SET is that while you may use it when you know a
lot about what's going on, you may also use it when you detect an
internal consistency error. Think of it as a panic button. You press it
when you're in trouble.

Take care,

Bill_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips
--=_mixed 0079646586256FF6_= Content-Type: application/octet-stream; name="PGP.sig" Content-Disposition: attachment; filename="PGP.sig" Content-Transfer-Encoding: base64 LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0NClZlcnNpb246IEdudVBHIHYxLjIuMyAoRGFy d2luKQ0KDQppRDhEQlFGQ2RxNkZESlQyRWdoMjZLMFJBbjl5QUprQjVWNXZVZGNvK25vUG44VFR3 YVZjMktiaW53Q2VOMTYvDQpwdG9PekJGeHdNVlp3QXU5S3kyTHJpRT0NCj1ud0lxDQotLS0tLUVO RCBQR1AgU0lHTkFUVVJFLS0tLS0NCg== --=_mixed 0079646586256FF6_= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --=_mixed 0079646586256FF6_=-- From ips-bounces@ietf.org Wed May 04 04:29:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTFFd-000058-Gz; Wed, 04 May 2005 04:29:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTFFc-0008W1-69 for ips@megatron.ietf.org; Wed, 04 May 2005 04:29:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05281 for ; Wed, 4 May 2005 04:28:57 -0400 (EDT) Received: from dmz1.silverbacksystems.com ([65.172.158.82]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTFTf-0006PJ-5j for ips@ietf.org; Wed, 04 May 2005 04:43:31 -0400 Received: from ns.silverbacksystems.com (gate-camp-hme0.silverbacksystems.com [65.172.158.93]) by dmz1.silverbacksystems.com (Postfix on SuSE Linux 7.3 (i386)) with ESMTP id 30F6C1202C; Wed, 4 May 2005 01:28:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ns.silverbacksystems.com (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 6E1173B34; Wed, 4 May 2005 01:28:06 -0700 (PDT) Received: from ns.silverbacksystems.com (localhost [127.0.0.1]) by localhost (AvMailGate-2.0.1.6) id 06104-00798076; Wed, 04 May 2005 01:28:06 -0700 Received: from gwendallap (vpn-162.corp.silverbacksystems.com [10.0.16.162]) by ns.silverbacksystems.com (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id B37A03B34; Wed, 4 May 2005 01:28:05 -0700 (PDT) From: "gwendal grignou" To: "'Julian Satran'" Subject: RE: [Ips] ABORT TASK vs ABORT TASK SET Date: Wed, 4 May 2005 01:28:06 -0700 Message-ID: <000801c55083$32f43450$6601a8c0@corp.silverbacksystems.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal In-Reply-To: X-AntiVirus: checked by AntiVir MailGate (version: 2.0.1.6; AVE: 6.24.0.7; VDF: 6.24.0.88; host: ns.silverbacksystems.com) X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Content-Transfer-Encoding: quoted-printable Cc: ips@ietf.org, 'Eddy Quicksall' X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org Julian, You have a valid point for Abort Task, but what about LUN RESET? It can impact tasks on all connections of the session where the TASK Management Request has been sent [I am not talking about other = sessions], but according to the iSCSI RFC, the initiator that issued the LUN RESET = is not bound to send an answer for all outstanding tags. It just says: "For the LOGICAL UNIT RESET function, the target MUST behave as dictated by the Logical Unit Reset function in [SAM2]." Couldn't we have a race condition? Depending on the timing, the target = may or may not received DataOut PDUs with F bit or DataACK for outstanding = tags impacted by the LUN RESET in same the session where the LUN RESET has = been issued, but issued on different connections... Do you expect the target to send a NOP In on all other connections to "collect" all remaining SNACK and DataOUT PDUs? Regards, Gwendal -----Original Message----- From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On Behalf Of = Julian Satran Sent: Tuesday, May 03, 2005 3:15 PM To: William Studenmund Cc: ips@ietf.org; Eddy Quicksall; ips-bounces@ietf.org Subject: Re: [Ips] ABORT TASK vs ABORT TASK SET The rational is that Abort task has to be sent on the connection on = which the task was issued and then it is easy to assure serialization.=20 That is not the case with task set.=20 Regards,=20 Julo=20 William Studenmund =20 Sent by: ips-bounces@ietf.org=20 02/05/2005 17:49=20 To "Eddy Quicksall" =20 cc ips@ietf.org=20 Subject Re: [Ips] ABORT TASK vs ABORT TASK SET On May 2, 2005, at 11:52 AM, Eddy Quicksall wrote: > For ABORT TASK SET, the target must wait for all outstanding tags to=20 > be responded to. > =A0 > 10.6.2: > =A0=A0=A0=A0=A0=A0=A0=A0 b) Waits for all target transfer tags to be = responded to and > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 for all affected tasks in the task = set to be received. > =A0 > But that is not mentioned for ABORT TASK. I'm wondering what the=20 > rational was for ABORT TASK SET but not ABORT TASK. If the rational is = > to cover possible race conditions at the initiator (e.g., still=20 > transmitting/receiving data but also getting a TMF Complete) then it=20 > would seem that the same race should be with ABORT TASK. My take on this was that you send an ABORT TASK when you know you want=20 to kill a task. Chances are you know a lot about what's going on with=20 it, so you will be able to clearly deal with internal state issues. My take on ABORT TASK SET is that while you may use it when you know a=20 lot about what's going on, you may also use it when you detect an=20 internal consistency error. Think of it as a panic button. You press it=20 when you're in trouble. Take care, Bill_______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Wed May 04 12:59:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTNDT-0004X2-TR; Wed, 04 May 2005 12:59:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTNDS-0004Ws-86 for ips@megatron.ietf.org; Wed, 04 May 2005 12:59:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00093 for ; Wed, 4 May 2005 12:59:15 -0400 (EDT) Received: from sccrmhc12.comcast.net ([204.127.202.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTNRZ-0004NG-1w for ips@ietf.org; Wed, 04 May 2005 13:13:54 -0400 Received: from ivvt2dxrc11 (c-66-177-46-174.hsd1.fl.comcast.net[66.177.46.174]) by comcast.net (sccrmhc12) with SMTP id <2005050416590601200desuje>; Wed, 4 May 2005 16:59:07 +0000 Message-ID: <000601c550ca$959d0a40$0303a8c0@ivivity.com> From: "Eddy Quicksall" To: Date: Wed, 4 May 2005 12:59:06 -0400 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.9 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Subject: [Ips] negotiating more than once X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1964679555==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============1964679555== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01C550A9.0DBEA460" This is a multi-part message in MIME format. ------=_NextPart_000_0003_01C550A9.0DBEA460 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The top of page 55 says this: Reject or Irrelevant are legitimate negotiation options where allowed but their excessive use is discouraged. A negotiation is considered complete when the acceptor has sent the key value pair even if the value is "Reject", "Irrelevant", or "NotUnderstood. Sending the key again would be a re-negotiation and is forbidden for many keys. Take this case: The initiator says ImmediateData=3DOK. The target says = ImmediateData=3DReject. The negotiation is now finished. Since ImmediateData defaults to YES and = if the target can't take immediate data then what is the target to do? = The only thing would be to close the connection. Does anyone disagree? How about "does anyone agree"? Eddy ------=_NextPart_000_0003_01C550A9.0DBEA460 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
The top of page 55 says this:
 
   Reject or Irrelevant are legitimate = negotiation=20 options where allowed
   but their excessive use is=20 discouraged.  A negotiation is considered
   complete = when the=20 acceptor has sent the key value pair even if the
   value = is=20 "Reject", "Irrelevant", or "NotUnderstood.  Sending the = key
  =20 again would be a re-negotiation and is forbidden for many = keys.
Take this case:
 
  The initiator says ImmediateData=3DOK. The = target says=20 ImmediateData=3DReject.
 
The negotiation is now finished. Since ImmediateData = defaults=20 to YES and if the target can't take immediate data then what is the = target to=20 do? The only thing would be to close the connection.
 
Does anyone disagree? How about "does anyone=20 agree"?
 
Eddy
------=_NextPart_000_0003_01C550A9.0DBEA460-- --===============1964679555== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============1964679555==-- From ips-bounces@ietf.org Wed May 04 13:03:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTNHR-00057M-DV; Wed, 04 May 2005 13:03:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTNHQ-000570-Ao for ips@megatron.ietf.org; Wed, 04 May 2005 13:03:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00576 for ; Wed, 4 May 2005 13:03:21 -0400 (EDT) Received: from sccrmhc14.comcast.net ([204.127.202.59]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTNVX-0004Uu-8P for ips@ietf.org; Wed, 04 May 2005 13:18:00 -0400 Received: from ivvt2dxrc11 (c-66-177-46-174.hsd1.fl.comcast.net[66.177.46.174]) by comcast.net (sccrmhc14) with SMTP id <20050504170313014009sffqe>; Wed, 4 May 2005 17:03:13 +0000 Message-ID: <001e01c550cb$286c8170$0303a8c0@ivivity.com> From: "Eddy Quicksall" To: "Julian Satran" , References: Subject: Re: [Ips] ABORT TASK vs ABORT TASK SET Date: Wed, 4 May 2005 13:03:12 -0400 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 1.0 (+) X-Scan-Signature: dd7e0c3fd18d19cffdd4de99a114001d Cc: X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1559527167==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============1559527167== Content-Type: multipart/alternative; boundary="----=_NextPart_000_001B_01C550A9.A0E08150" This is a multi-part message in MIME format. ------=_NextPart_000_001B_01C550A9.A0E08150 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Julian, I may have missed this but I can't find anything in the spec that says = it must be synchronized ... i.e., that the initiator must not continue = to send data PDU's for the task after issueing the ABORT TASK. Did I miss something? Eddy ----- Original Message -----=20 From: Julian Satran=20 To: William Studenmund=20 Cc: ips@ietf.org ; Eddy Quicksall ; ips-bounces@ietf.org=20 Sent: Tuesday, May 03, 2005 6:14 PM Subject: Re: [Ips] ABORT TASK vs ABORT TASK SET The rational is that Abort task has to be sent on the connection on = which the task was issued and then it is easy to assure serialization.=20 That is not the case with task set.=20 Regards,=20 Julo=20 William Studenmund =20 Sent by: ips-bounces@ietf.org=20 02/05/2005 17:49=20 To "Eddy Quicksall" =20 cc ips@ietf.org =20 Subject Re: [Ips] ABORT TASK vs ABORT TASK SET=20 =20 =20 On May 2, 2005, at 11:52 AM, Eddy Quicksall wrote: > For ABORT TASK SET, the target must wait for all outstanding tags to = > be responded to. > =20 > 10.6.2: > b) Waits for all target transfer tags to be responded to = and > for all affected tasks in the task set to be received. > =20 > But that is not mentioned for ABORT TASK. I'm wondering what the=20 > rational was for ABORT TASK SET but not ABORT TASK. If the rational = is=20 > to cover possible race conditions at the initiator (e.g., still=20 > transmitting/receiving data but also getting a TMF Complete) then it = > would seem that the same race should be with ABORT TASK. My take on this was that you send an ABORT TASK when you know you want = to kill a task. Chances are you know a lot about what's going on with=20 it, so you will be able to clearly deal with internal state issues. My take on ABORT TASK SET is that while you may use it when you know a = lot about what's going on, you may also use it when you detect an=20 internal consistency error. Think of it as a panic button. You press = it=20 when you're in trouble. Take care, Bill_______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips -------------------------------------------------------------------------= ----- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips ------=_NextPart_000_001B_01C550A9.A0E08150 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Julian,
 
I may have missed this but I can't find anything in = the spec=20 that says it must be synchronized ... i.e., that the initiator = must=20 not continue to send data PDU's for the task after issueing the = ABORT=20 TASK.
 
Did I miss something?
 
Eddy
----- Original Message -----
From:=20 Julian Satran
Cc: ips@ietf.org ; Eddy = Quicksall ; ips-bounces@ietf.org
Sent: Tuesday, May 03, 2005 = 6:14 PM
Subject: Re: [Ips] ABORT TASK = vs ABORT=20 TASK SET


The rational is = that Abort=20 task has to be sent on the connection on which the task was issued and = then it=20 is easy to assure serialization.
That=20 is not the case with task set.

Regards,
Julo=20


William = Studenmund=20 <wrstuden@wasabisystems.com= >=20
Sent by: ips-bounces@ietf.org=20

02/05/2005 17:49

To
"Eddy Quicksall" <eddy_quicksall_i= Vivity_iSCSI@comcast.net>=20
cc
ips@ietf.org=20
Subject
Re: [Ips] ABORT TASK vs = ABORT=20 TASK SET

=




On May 2, 2005, at 11:52 AM, Eddy Quicksall = wrote:

> For=20 ABORT TASK SET, the target must wait for all outstanding tags to =
> be=20 responded to.
>  
> 10.6.2:
>=20          b) Waits for all = target=20 transfer tags to be responded to and
>=20             for = all=20 affected tasks in the task set to be received.
>  
> = But that=20 is not mentioned for ABORT TASK. I'm wondering what the
> = rational was=20 for ABORT TASK SET but not ABORT TASK. If the rational is
> to = cover=20 possible race conditions at the initiator (e.g., still
>=20 transmitting/receiving data but also getting a TMF Complete) then it =
>=20 would seem that the same race should be with ABORT TASK.

My = take on=20 this was that you send an ABORT TASK when you know you want
to = kill a=20 task. Chances are you know a lot about what's going on with
it, so = you=20 will be able to clearly deal with internal state issues.

My = take on=20 ABORT TASK SET is that while you may use it when you know a
lot = about=20 what's going on, you may also use it when you detect an
internal=20 consistency error. Think of it as a panic button. You press it =
when you're=20 in trouble.

Take=20 = care,

Bill_______________________________________________
Ips=20 mailing=20 = list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips

_______________________________________________
Ips mailing=20 = list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips
------=_NextPart_000_001B_01C550A9.A0E08150-- --===============1559527167== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============1559527167==-- From ips-bounces@ietf.org Wed May 04 13:31:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTNj5-0005tm-3F; Wed, 04 May 2005 13:31:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTNj3-0005th-7g for ips@megatron.ietf.org; Wed, 04 May 2005 13:31:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03789 for ; Wed, 4 May 2005 13:31:54 -0400 (EDT) Received: from mtagate4.de.ibm.com ([195.212.29.153]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTNxA-0005QQ-1I for ips@ietf.org; Wed, 04 May 2005 13:46:33 -0400 Received: from d12nrmr1707.megacenter.de.ibm.com (d12nrmr1707.megacenter.de.ibm.com [9.149.167.81]) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id j44HVkqF126914 for ; Wed, 4 May 2005 17:31:46 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1707.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j44HVj17281772 for ; Wed, 4 May 2005 19:31:45 +0200 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id j44HVjkN028834 for ; Wed, 4 May 2005 19:31:45 +0200 Received: from d12ml102.megacenter.de.ibm.com (d12ml102.megacenter.de.ibm.com [9.149.166.138]) by d12av04.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j44HVjKX028831; Wed, 4 May 2005 19:31:45 +0200 In-Reply-To: <001e01c550cb$286c8170$0303a8c0@ivivity.com> To: "Eddy Quicksall" Subject: Re: [Ips] ABORT TASK vs ABORT TASK SET MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_04212005NP April 21, 2005 From: Julian Satran Message-ID: Date: Wed, 4 May 2005 12:31:44 -0500 X-MIMETrack: Serialize by Router on D12ML102/12/M/IBM(Release 6.5.1| March 5, 2004) at 04/05/2005 20:31:45, Serialize complete at 04/05/2005 20:31:45 X-Spam-Score: 2.1 (++) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1823769100==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org --===============1823769100== Content-Type: text/html; charset="US-ASCII"
The initiator can be in one of two states:
  • abort is finished - the using the ITT for data packets is no legal (by initiator)
  • initiator has not yet sensed the abort as being ended - then the target will discard the data if it has already executed the abort or process them if not.


In any case  there is no race neither at initiator nor at target due to the synchronization of abort after the task.

Julo


"Eddy Quicksall" <eddy_quicksall_iVivity_iSCSI@comcast.net>

04/05/2005 12:03

To
Julian Satran/Haifa/IBM@IBMIL, <ips@ietf.org>
cc
Subject
Re: [Ips] ABORT TASK vs ABORT TASK SET





Julian,
 
I may have missed this but I can't find anything in the spec that says it must be synchronized ... i.e., that the initiator must not continue to send data PDU's for the task after issueing the ABORT TASK.
 
Did I miss something?
 
Eddy
----- Original Message -----
From: Julian Satran
To: William Studenmund
Cc: ips@ietf.org ; Eddy Quicksall ; ips-bounces@ietf.org
Sent: Tuesday, May 03, 2005 6:14 PM
Subject: Re: [Ips] ABORT TASK vs ABORT TASK SET


The rational is that Abort task has to be sent on the connection on which the task was issued and then it is easy to assure serialization.
That is not the case with task set.

Regards,
Julo

William Studenmund <wrstuden@wasabisystems.com>
Sent by: ips-bounces@ietf.org

02/05/2005 17:49


To
"Eddy Quicksall" <eddy_quicksall_iVivity_iSCSI@comcast.net>
cc
ips@ietf.org
Subject
Re: [Ips] ABORT TASK vs ABORT TASK SET







On May 2, 2005, at 11:52 AM, Eddy Quicksall wrote:

> For ABORT TASK SET, the target must wait for all outstanding tags to
> be responded to.
>  
> 10.6.2:
>          b) Waits for all target transfer tags to be responded to and
>             for all affected tasks in the task set to be received.
>  
> But that is not mentioned for ABORT TASK. I'm wondering what the
> rational was for ABORT TASK SET but not ABORT TASK. If the rational is
> to cover possible race conditions at the initiator (e.g., still
> transmitting/receiving data but also getting a TMF Complete) then it
> would seem that the same race should be with ABORT TASK.

My take on this was that you send an ABORT TASK when you know you want
to kill a task. Chances are you know a lot about what's going on with
it, so you will be able to clearly deal with internal state issues.

My take on ABORT TASK SET is that while you may use it when you know a
lot about what's going on, you may also use it when you detect an
internal consistency error. Think of it as a panic button. You press it
when you're in trouble.

Take care,

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

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

--===============1823769100== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============1823769100==-- From ips-bounces@ietf.org Wed May 04 13:47:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTNyG-0002c8-6p; Wed, 04 May 2005 13:47:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTNyE-0002bv-Rl; Wed, 04 May 2005 13:47:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06675; Wed, 4 May 2005 13:47:37 -0400 (EDT) Received: from sccrmhc11.comcast.net ([204.127.202.55]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTOCN-0006JX-0G; Wed, 04 May 2005 14:02:15 -0400 Received: from ivvt2dxrc11 (c-66-177-46-174.hsd1.fl.comcast.net[66.177.46.174]) by comcast.net (sccrmhc11) with SMTP id <2005050417472801100ihe19e>; Wed, 4 May 2005 17:47:28 +0000 Message-ID: <001501c550d1$572756b0$0303a8c0@ivivity.com> From: "Eddy Quicksall" To: "William Studenmund" , "Julian Satran" References: Subject: Re: [Ips] ABORT TASK vs ABORT TASK SET Date: Wed, 4 May 2005 13:47:28 -0400 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 1.0 (+) X-Scan-Signature: f8184d7d4d1b986353eb58ea3e887935 Cc: ips@ietf.org, ips-bounces@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1054322555==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============1054322555== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0012_01C550AF.CF849A40" This is a multi-part message in MIME format. ------=_NextPart_000_0012_01C550AF.CF849A40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable For ABORT TASK SET the target must wait for all commands effected by the = TMF to be received. But what if the very reason for the TMF was because = a bad connection is preventing a command from reaching the target? Even = if the immediate bit is set on the TMF, the target must wait. This would = lead to a dead lock for the session. Does the following apply to a bad connection (not just to a data digest = error) too? That would overcome the dead lock. But then how long does = the target wait? If it is too long, the target may get a WARM/COLD = RESET. If it is too short, the command may still arrive later. In case all or part of the response sequence is not received (due to digest errors) for a valid TTT ... [the target] may = drop the connection ... Eddy ----- Original Message -----=20 From: Julian Satran=20 To: William Studenmund=20 Cc: ips@ietf.org ; Eddy Quicksall ; ips-bounces@ietf.org=20 Sent: Tuesday, May 03, 2005 6:14 PM Subject: Re: [Ips] ABORT TASK vs ABORT TASK SET The rational is that Abort task has to be sent on the connection on = which the task was issued and then it is easy to assure serialization.=20 That is not the case with task set.=20 Regards,=20 Julo=20 William Studenmund =20 Sent by: ips-bounces@ietf.org=20 02/05/2005 17:49=20 To "Eddy Quicksall" =20 cc ips@ietf.org =20 Subject Re: [Ips] ABORT TASK vs ABORT TASK SET=20 =20 =20 On May 2, 2005, at 11:52 AM, Eddy Quicksall wrote: > For ABORT TASK SET, the target must wait for all outstanding tags to = > be responded to. > =20 > 10.6.2: > b) Waits for all target transfer tags to be responded to = and > for all affected tasks in the task set to be received. > =20 > But that is not mentioned for ABORT TASK. I'm wondering what the=20 > rational was for ABORT TASK SET but not ABORT TASK. If the rational = is=20 > to cover possible race conditions at the initiator (e.g., still=20 > transmitting/receiving data but also getting a TMF Complete) then it = > would seem that the same race should be with ABORT TASK. My take on this was that you send an ABORT TASK when you know you want = to kill a task. Chances are you know a lot about what's going on with=20 it, so you will be able to clearly deal with internal state issues. My take on ABORT TASK SET is that while you may use it when you know a = lot about what's going on, you may also use it when you detect an=20 internal consistency error. Think of it as a panic button. You press = it=20 when you're in trouble. Take care, Bill_______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips -------------------------------------------------------------------------= ----- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips ------=_NextPart_000_0012_01C550AF.CF849A40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

 
For ABORT TASK SET the target must wait for all = commands=20 effected by the TMF to be received. But what if the very reason for the = TMF was=20 because a bad connection is preventing a command from reaching the = target? Even=20 if the immediate bit is set on the TMF, the target must wait. This would = lead to=20 a dead lock for the session.
 
Does the following apply to a bad connection = (not just to=20 a data digest error) too? That would overcome the dead lock. But then = how long=20 does the target wait? If it is too long, the target may get a=20 WARM/COLD RESET. If it is too short, the command may still arrive=20 later.
  In case all or part of the response sequence = is=20 not
  received (due to digest errors) for a valid TTT = ... [the=20 target] may drop the connection ...
 
 
Eddy
----- Original Message -----
From:=20 Julian Satran
Cc: ips@ietf.org ; Eddy = Quicksall ; ips-bounces@ietf.org
Sent: Tuesday, May 03, 2005 = 6:14 PM
Subject: Re: [Ips] ABORT TASK = vs ABORT=20 TASK SET


The rational is = that Abort=20 task has to be sent on the connection on which the task was issued and = then it=20 is easy to assure serialization.
That=20 is not the case with task set.

Regards,
Julo=20


William = Studenmund=20 <wrstuden@wasabisystems.com= >=20
Sent by: ips-bounces@ietf.org=20

02/05/2005 17:49

To
"Eddy Quicksall" <eddy_quicksall_i= Vivity_iSCSI@comcast.net>=20
cc
ips@ietf.org=20
Subject
Re: [Ips] ABORT TASK vs = ABORT=20 TASK SET

=




On May 2, 2005, at 11:52 AM, Eddy Quicksall = wrote:

> For=20 ABORT TASK SET, the target must wait for all outstanding tags to =
> be=20 responded to.
>  
> 10.6.2:
>=20          b) Waits for all = target=20 transfer tags to be responded to and
>=20             for = all=20 affected tasks in the task set to be received.
>  
> = But that=20 is not mentioned for ABORT TASK. I'm wondering what the
> = rational was=20 for ABORT TASK SET but not ABORT TASK. If the rational is
> to = cover=20 possible race conditions at the initiator (e.g., still
>=20 transmitting/receiving data but also getting a TMF Complete) then it =
>=20 would seem that the same race should be with ABORT TASK.

My = take on=20 this was that you send an ABORT TASK when you know you want
to = kill a=20 task. Chances are you know a lot about what's going on with
it, so = you=20 will be able to clearly deal with internal state issues.

My = take on=20 ABORT TASK SET is that while you may use it when you know a
lot = about=20 what's going on, you may also use it when you detect an
internal=20 consistency error. Think of it as a panic button. You press it =
when you're=20 in trouble.

Take=20 = care,

Bill_______________________________________________
Ips=20 mailing=20 = list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips

_______________________________________________
Ips mailing=20 = list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips
------=_NextPart_000_0012_01C550AF.CF849A40-- --===============1054322555== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============1054322555==-- From ips-bounces@ietf.org Wed May 04 13:57:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTO7P-00004z-D8; Wed, 04 May 2005 13:57:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTO7M-0008WH-HS for ips@megatron.ietf.org; Wed, 04 May 2005 13:57:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07731 for ; Wed, 4 May 2005 13:57:03 -0400 (EDT) Received: from sccrmhc11.comcast.net ([204.127.202.55]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTOLU-0006dX-Pn for ips@ietf.org; Wed, 04 May 2005 14:11:41 -0400 Received: from ivvt2dxrc11 (c-66-177-46-174.hsd1.fl.comcast.net[66.177.46.174]) by comcast.net (sccrmhc11) with SMTP id <2005050417565401100ih646e>; Wed, 4 May 2005 17:56:54 +0000 Message-ID: <002301c550d2$a8835260$0303a8c0@ivivity.com> From: "Eddy Quicksall" To: "Julian Satran" References: Subject: Re: [Ips] ABORT TASK vs ABORT TASK SET Date: Wed, 4 May 2005 13:56:54 -0400 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 1.1 (+) X-Scan-Signature: 6379955759c38e2371a49573a0932fc7 Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2120682462==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============2120682462== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0020_01C550B1.20F5F2B0" This is a multi-part message in MIME format. ------=_NextPart_000_0020_01C550B1.20F5F2B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable For the first bullet, I agree this is common sense. But I don't see it = in the RFC. For the second bullet, it looks like a race as to if the target is in = the process of sending the response (so the initiator has not sensed it = as ended) but the target perceives it as ended. Is it understood that = the target does not see it as ended until it gets an ExpStatSN = indicating the initiator now sees it as ended? Eddy ----- Original Message -----=20 From: Julian Satran=20 To: Eddy Quicksall=20 Cc: ips@ietf.org=20 Sent: Wednesday, May 04, 2005 1:31 PM Subject: Re: [Ips] ABORT TASK vs ABORT TASK SET The initiator can be in one of two states:=20 a.. abort is finished - the using the ITT for data packets is no = legal (by initiator)=20 b.. initiator has not yet sensed the abort as being ended - then the = target will discard the data if it has already executed the abort or = process them if not. In any case there is no race neither at initiator nor at target due = to the synchronization of abort after the task.=20 Julo=20 "Eddy Quicksall" =20 04/05/2005 12:03=20 To Julian Satran/Haifa/IBM@IBMIL, =20 cc =20 Subject Re: [Ips] ABORT TASK vs ABORT TASK SET=20 =20 =20 Julian,=20 =20 I may have missed this but I can't find anything in the spec that says = it must be synchronized ... i.e., that the initiator must not continue = to send data PDU's for the task after issueing the ABORT TASK.=20 =20 Did I miss something?=20 =20 Eddy=20 ----- Original Message -----=20 From: Julian Satran=20 To: William Studenmund=20 Cc: ips@ietf.org ; Eddy Quicksall ; ips-bounces@ietf.org=20 Sent: Tuesday, May 03, 2005 6:14 PM=20 Subject: Re: [Ips] ABORT TASK vs ABORT TASK SET=20 The rational is that Abort task has to be sent on the connection on = which the task was issued and then it is easy to assure serialization.=20 That is not the case with task set.=20 Regards,=20 Julo=20 William Studenmund =20 Sent by: ips-bounces@ietf.org=20 02/05/2005 17:49=20 =20 To "Eddy Quicksall" = =20 cc ips@ietf.org =20 Subject Re: [Ips] ABORT TASK vs ABORT TASK SET=20 =20 =20 On May 2, 2005, at 11:52 AM, Eddy Quicksall wrote: > For ABORT TASK SET, the target must wait for all outstanding tags to = > be responded to. > =20 > 10.6.2: > b) Waits for all target transfer tags to be responded to = and > for all affected tasks in the task set to be received. > =20 > But that is not mentioned for ABORT TASK. I'm wondering what the=20 > rational was for ABORT TASK SET but not ABORT TASK. If the rational = is=20 > to cover possible race conditions at the initiator (e.g., still=20 > transmitting/receiving data but also getting a TMF Complete) then it = > would seem that the same race should be with ABORT TASK. My take on this was that you send an ABORT TASK when you know you want = to kill a task. Chances are you know a lot about what's going on with=20 it, so you will be able to clearly deal with internal state issues. My take on ABORT TASK SET is that while you may use it when you know a = lot about what's going on, you may also use it when you detect an=20 internal consistency error. Think of it as a panic button. You press = it=20 when you're in trouble. Take care, Bill_______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips -------------------------------------------------------------------------= ----- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips=20 -------------------------------------------------------------------------= ----- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips ------=_NextPart_000_0020_01C550B1.20F5F2B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
For the first bullet, I agree this is common sense. = But I=20 don't see it in the RFC.
 
For the second bullet, it looks like a race as to if = the=20 target is in the process of sending the response (so the initiator has = not=20 sensed it as ended) but the target perceives it as ended. Is it = understood that=20 the target does not see it as ended until it gets an ExpStatSN = indicating the=20 initiator now sees it as ended?
 
Eddy
----- Original Message -----
From:=20 Julian Satran
To: Eddy = Quicksall=20
Sent: Wednesday, May 04, 2005 = 1:31=20 PM
Subject: Re: [Ips] ABORT TASK = vs ABORT=20 TASK SET


The initiator can = be in one of=20 two states:
  • abort is finished - the using = the ITT for=20 data packets is no legal (by initiator)=20
  • initiator has not yet sensed = the abort as=20 being ended - then the target will discard the data if it has = already=20 executed the abort or process them if = not.


In any case  there is no race neither = at initiator=20 nor at target due to the synchronization of abort after the = task.=20

Julo


"Eddy = Quicksall" <eddy_quicksall_i= Vivity_iSCSI@comcast.net>=20

04/05/2005 12:03

To
Julian = Satran/Haifa/IBM@IBMIL,=20 <ips@ietf.org>=20
cc
Subject
Re: [Ips] ABORT TASK vs = ABORT=20 TASK SET

=




Julian,
 
I may=20 have missed this but I can't find anything in the spec that says it = must be=20 synchronized ... i.e., that the initiator must not continue to send = data PDU's=20 for the task after issueing the ABORT TASK.
 
Did I miss something? =
 
Eddy
-----=20 Original Message -----
From: = Julian=20 Satran
To:=20 William Studenmund =
Cc: ips@ietf.org ; Eddy Quicksall ; ips-bounces@ietf.org =
Sent: Tuesday, May 03, 2005 6:14 PM
Subject: Re: [Ips] ABORT TASK vs ABORT TASK SET =


The rational is that = Abort task has=20 to be sent on the connection on which the task was issued and then it = is easy=20 to assure serialization.
That is not the case with task set. =

Regards,=20
Julo =

William = Studenmund=20 <wrstuden@wasabisystems.com>
Sent by: ips-bounces@ietf.org =

02/05/2005 17:49=20


To
"Eddy = Quicksall"=20 <eddy_quicksall_iVivity_iSCSI@comcast.net> =
cc
ips@ietf.org =
Subject
Re: [Ips] ABORT TASK vs = ABORT=20 TASK SET







On May 2, 2005, at = 11:52 AM, Eddy=20 Quicksall wrote:

> For ABORT TASK SET, the target must wait = for all=20 outstanding tags to
> be responded to.
>  
>=20 10.6.2:
>          b) Waits for all = target=20 transfer tags to be responded to and
>       =  =20     for all affected tasks in the task set to be = received.
>=20  
> But that is not mentioned for ABORT TASK. I'm wondering = what=20 the
> rational was for ABORT TASK SET but not ABORT TASK. If = the=20 rational is
> to cover possible race conditions at the = initiator (e.g.,=20 still
> transmitting/receiving data but also getting a TMF = Complete)=20 then it
> would seem that the same race should be with ABORT=20 TASK.

My take on this was that you send an ABORT TASK when you = know you=20 want
to kill a task. Chances are you know a lot about what's going = on with=20
it, so you will be able to clearly deal with internal state=20 issues.

My take on ABORT TASK SET is that while you may use it = when you=20 know a
lot about what's going on, you may also use it when you = detect an=20
internal consistency error. Think of it as a panic button. You = press it=20
when you're in trouble.

Take=20 = care,

Bill_______________________________________________
Ips=20 mailing=20 = list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips=

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

_______________________________________________
Ips mailing=20 = list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips
------=_NextPart_000_0020_01C550B1.20F5F2B0-- --===============2120682462== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============2120682462==-- From ips-bounces@ietf.org Wed May 04 16:42:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTQha-0003aB-1j; Wed, 04 May 2005 16:42:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTQhX-0003XL-Sp for ips@megatron.ietf.org; Wed, 04 May 2005 16:42:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03047 for ; Wed, 4 May 2005 16:42:33 -0400 (EDT) Received: from sccrmhc14.comcast.net ([204.127.202.59]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTQvg-0005a8-AN for ips@ietf.org; Wed, 04 May 2005 16:57:14 -0400 Received: from ivvt2dxrc11 (c-66-177-46-174.hsd1.fl.comcast.net[66.177.46.174]) by comcast.net (sccrmhc14) with SMTP id <2005050420421301400eabe9e>; Wed, 4 May 2005 20:42:13 +0000 Message-ID: <003d01c550e9$c088f3d0$0303a8c0@ivivity.com> From: "Eddy Quicksall" To: "Julian Satran" References: <002301c550d2$a8835260$0303a8c0@ivivity.com> Subject: Re: [Ips] ABORT TASK vs ABORT TASK SET Date: Wed, 4 May 2005 16:42:12 -0400 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 1.1 (+) X-Scan-Signature: 4de5d7f989d6c039c8b887f1940f36ab Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0097558448==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============0097558448== Content-Type: multipart/alternative; boundary="----=_NextPart_000_003A_01C550C8.390000F0" This is a multi-part message in MIME format. ------=_NextPart_000_003A_01C550C8.390000F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Actually, SAM-2 basically says this under section 5.6. Sorry about the = confusion. Eddy ----- Original Message -----=20 From: Eddy Quicksall=20 To: Julian Satran=20 Cc: ips@ietf.org=20 Sent: Wednesday, May 04, 2005 1:56 PM Subject: Re: [Ips] ABORT TASK vs ABORT TASK SET For the first bullet, I agree this is common sense. But I don't see it = in the RFC. For the second bullet, it looks like a race as to if the target is in = the process of sending the response (so the initiator has not sensed it = as ended) but the target perceives it as ended. Is it understood that = the target does not see it as ended until it gets an ExpStatSN = indicating the initiator now sees it as ended? Eddy ----- Original Message -----=20 From: Julian Satran=20 To: Eddy Quicksall=20 Cc: ips@ietf.org=20 Sent: Wednesday, May 04, 2005 1:31 PM Subject: Re: [Ips] ABORT TASK vs ABORT TASK SET The initiator can be in one of two states:=20 a.. abort is finished - the using the ITT for data packets is no = legal (by initiator)=20 b.. initiator has not yet sensed the abort as being ended - then = the target will discard the data if it has already executed the abort or = process them if not. In any case there is no race neither at initiator nor at target due = to the synchronization of abort after the task.=20 Julo=20 "Eddy Quicksall" =20 04/05/2005 12:03=20 To Julian Satran/Haifa/IBM@IBMIL, =20 cc =20 Subject Re: [Ips] ABORT TASK vs ABORT TASK SET=20 =20 =20 Julian,=20 =20 I may have missed this but I can't find anything in the spec that = says it must be synchronized ... i.e., that the initiator must not = continue to send data PDU's for the task after issueing the ABORT TASK.=20 =20 Did I miss something?=20 =20 Eddy=20 ----- Original Message -----=20 From: Julian Satran=20 To: William Studenmund=20 Cc: ips@ietf.org ; Eddy Quicksall ; ips-bounces@ietf.org=20 Sent: Tuesday, May 03, 2005 6:14 PM=20 Subject: Re: [Ips] ABORT TASK vs ABORT TASK SET=20 The rational is that Abort task has to be sent on the connection on = which the task was issued and then it is easy to assure serialization.=20 That is not the case with task set.=20 Regards,=20 Julo=20 William Studenmund =20 Sent by: ips-bounces@ietf.org=20 02/05/2005 17:49=20 =20 To "Eddy Quicksall" = =20 cc ips@ietf.org =20 Subject Re: [Ips] ABORT TASK vs ABORT TASK SET=20 =20 =20 On May 2, 2005, at 11:52 AM, Eddy Quicksall wrote: > For ABORT TASK SET, the target must wait for all outstanding tags = to=20 > be responded to. > =20 > 10.6.2: > b) Waits for all target transfer tags to be responded to = and > for all affected tasks in the task set to be received. > =20 > But that is not mentioned for ABORT TASK. I'm wondering what the=20 > rational was for ABORT TASK SET but not ABORT TASK. If the = rational is=20 > to cover possible race conditions at the initiator (e.g., still=20 > transmitting/receiving data but also getting a TMF Complete) then = it=20 > would seem that the same race should be with ABORT TASK. My take on this was that you send an ABORT TASK when you know you = want=20 to kill a task. Chances are you know a lot about what's going on = with=20 it, so you will be able to clearly deal with internal state issues. My take on ABORT TASK SET is that while you may use it when you know = a=20 lot about what's going on, you may also use it when you detect an=20 internal consistency error. Think of it as a panic button. You press = it=20 when you're in trouble. Take care, Bill_______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips -------------------------------------------------------------------------= --- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips=20 -------------------------------------------------------------------------= --- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips -------------------------------------------------------------------------= ----- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips ------=_NextPart_000_003A_01C550C8.390000F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Actually, SAM-2 basically says this under section = 5.6. Sorry=20 about the confusion.
 
Eddy
----- Original Message -----
From:=20 Eddy = Quicksall=20
Sent: Wednesday, May 04, 2005 = 1:56=20 PM
Subject: Re: [Ips] ABORT TASK = vs ABORT=20 TASK SET

For the first bullet, I agree this is common = sense. But I=20 don't see it in the RFC.
 
For the second bullet, it looks like a race as to = if the=20 target is in the process of sending the response (so the initiator has = not=20 sensed it as ended) but the target perceives it as ended. Is it = understood=20 that the target does not see it as ended until it gets an ExpStatSN = indicating=20 the initiator now sees it as ended?
 
Eddy
----- Original Message -----
From:=20 Julian Satran
To: Eddy = Quicksall=20
Sent: Wednesday, May 04, 2005 = 1:31=20 PM
Subject: Re: [Ips] ABORT TASK = vs ABORT=20 TASK SET


The initiator = can be in one=20 of two states:
  • abort is finished - the using = the ITT for=20 data packets is no legal (by initiator)=20
  • initiator has not yet sensed = the abort as=20 being ended - then the target will discard the data if it has = already=20 executed the abort or process them if = not.


In any case  there is no race = neither at=20 initiator nor at target due to the synchronization of abort after = the=20 task.

Julo =


"Eddy = Quicksall"=20 <eddy_quicksall_i= Vivity_iSCSI@comcast.net>=20

04/05/2005 12:03 =

To
Julian = Satran/Haifa/IBM@IBMIL,=20 <ips@ietf.org>=20
cc
Subject
Re: [Ips] ABORT TASK = vs ABORT=20 TASK SET

=




<= FONT=20 size=3D2>Julian,
 
I may=20 have missed this but I can't find anything in the spec that says it = must be=20 synchronized ... i.e., that the initiator must not continue to send = data=20 PDU's for the task after issueing the ABORT TASK.
 
Did I miss = something?
 
Eddy
-----=20 Original Message -----
From: = Julian=20 Satran
To:=20 William Studenmund =
Cc: ips@ietf.org ; Eddy Quicksall ; ips-bounces@ietf.org =
Sent: Tuesday, May 03, 2005 6:14 PM
Subject: Re: [Ips] ABORT TASK vs ABORT TASK = SET=20


The rational is that = Abort task has=20 to be sent on the connection on which the task was issued and then = it is=20 easy to assure serialization.
That is not the case with task = set.

Regards,
Julo=20

William = Studenmund=20 <wrstuden@wasabisystems.com>
Sent by: ips-bounces@ietf.org =

02/05/2005 = 17:49=20


To
"Eddy = Quicksall"=20 <eddy_quicksall_iVivity_iSCSI@comcast.net> =
cc
ips@ietf.org=20
Subject
Re: [Ips] ABORT TASK = vs ABORT=20 TASK SET






On May 2, 2005, at = 11:52 AM, Eddy=20 Quicksall wrote:

> For ABORT TASK SET, the target must = wait for=20 all outstanding tags to
> be responded to.
> =  
>=20 10.6.2:
>          b) Waits for all = target=20 transfer tags to be responded to and
>       =  =20     for all affected tasks in the task set to be = received.
>=20  
> But that is not mentioned for ABORT TASK. I'm = wondering what=20 the
> rational was for ABORT TASK SET but not ABORT TASK. If = the=20 rational is
> to cover possible race conditions at the = initiator=20 (e.g., still
> transmitting/receiving data but also getting a = TMF=20 Complete) then it
> would seem that the same race should be = with=20 ABORT TASK.

My take on this was that you send an ABORT TASK = when you=20 know you want
to kill a task. Chances are you know a lot about = what's=20 going on with
it, so you will be able to clearly deal with = internal=20 state issues.

My take on ABORT TASK SET is that while you may = use it=20 when you know a
lot about what's going on, you may also use it = when you=20 detect an
internal consistency error. Think of it as a panic = button. You=20 press it
when you're in trouble.

Take=20 = care,

Bill_______________________________________________
Ips=20 mailing=20 = list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips=

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

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

_______________________________________________
Ips mailing=20 = list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips
------=_NextPart_000_003A_01C550C8.390000F0-- --===============0097558448== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0097558448==-- From ips-bounces@ietf.org Wed May 04 16:59:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTQxt-0008Ul-BT; Wed, 04 May 2005 16:59:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTQxm-0008QX-9l for ips@megatron.ietf.org; Wed, 04 May 2005 16:59:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05016 for ; Wed, 4 May 2005 16:59:19 -0400 (EDT) Received: from mtagate3.de.ibm.com ([195.212.29.152]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTRBv-0006Ck-Nj for ips@ietf.org; Wed, 04 May 2005 17:14:00 -0400 Received: from d12nrmr1707.megacenter.de.ibm.com (d12nrmr1707.megacenter.de.ibm.com [9.149.167.81]) by mtagate3.de.ibm.com (8.12.10/8.12.10) with ESMTP id j44KxAJl139242 for ; Wed, 4 May 2005 20:59:10 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1707.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j44KxA17287774 for ; Wed, 4 May 2005 22:59:10 +0200 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id j44KxAVl016525 for ; Wed, 4 May 2005 22:59:10 +0200 Received: from d12ml102.megacenter.de.ibm.com (d12ml102.megacenter.de.ibm.com [9.149.166.138]) by d12av04.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j44KxAHm016520; Wed, 4 May 2005 22:59:10 +0200 In-Reply-To: <002301c550d2$a8835260$0303a8c0@ivivity.com> To: "Eddy Quicksall" Subject: Re: [Ips] ABORT TASK vs ABORT TASK SET MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_04212005NP April 21, 2005 From: Julian Satran Message-ID: Date: Wed, 4 May 2005 15:59:09 -0500 X-MIMETrack: Serialize by Router on D12ML102/12/M/IBM(Release 6.5.1| March 5, 2004) at 04/05/2005 23:59:09, Serialize complete at 04/05/2005 23:59:09 X-Spam-Score: 2.1 (++) X-Scan-Signature: 0bb031f3a6fb29f760794ac9bf1997ae Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1801213748==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org --===============1801213748== Content-Type: text/html; charset="US-ASCII"
What would you want to see in the RFC - you are not supposed to use an ITT that you report as aborted.
The only thing needed for the second is for the target to ignore any data it receives after reporting the end of abort (and that is what I would consider obvious).

Julo


"Eddy Quicksall" <eddy_quicksall_iVivity_iSCSI@comcast.net>

04/05/2005 12:56

To
Julian Satran/Haifa/IBM@IBMIL
cc
<ips@ietf.org>
Subject
Re: [Ips] ABORT TASK vs ABORT TASK SET





For the first bullet, I agree this is common sense. But I don't see it in the RFC.
 
For the second bullet, it looks like a race as to if the target is in the process of sending the response (so the initiator has not sensed it as ended) but the target perceives it as ended. Is it understood that the target does not see it as ended until it gets an ExpStatSN indicating the initiator now sees it as ended?
 
Eddy
----- Original Message -----
From: Julian Satran
To: Eddy Quicksall
Cc: ips@ietf.org
Sent: Wednesday, May 04, 2005 1:31 PM
Subject: Re: [Ips] ABORT TASK vs ABORT TASK SET


The initiator can be in one of two states:
  • abort is finished - the using the ITT for data packets is no legal (by initiator)
  • initiator has not yet sensed the abort as being ended - then the target will discard the data if it has already executed the abort or process them if not.


In any case  there is no race neither at initiator nor at target due to the synchronization of abort after the task.

Julo

"Eddy Quicksall" <eddy_quicksall_iVivity_iSCSI@comcast.net>

04/05/2005 12:03


To
Julian Satran/Haifa/IBM@IBMIL, <ips@ietf.org>
cc
Subject
Re: [Ips] ABORT TASK vs ABORT TASK SET







Julian,
 
I may have missed this but I can't find anything in the spec that says it must be synchronized ... i.e., that the initiator must not continue to send data PDU's for the task after issueing the ABORT TASK.
 
Did I miss something?
 
Eddy
----- Original Message -----
From: Julian Satran
To: William Studenmund
Cc: ips@ietf.org ; Eddy Quicksall ; ips-bounces@ietf.org
Sent: Tuesday, May 03, 2005 6:14 PM
Subject: Re: [Ips] ABORT TASK vs ABORT TASK SET


The rational is that Abort task has to be sent on the connection on which the task was issued and then it is easy to assure serialization.
That is not the case with task set.

Regards,
Julo
William Studenmund <wrstuden@wasabisystems.com>
Sent by: ips-bounces@ietf.org

02/05/2005 17:49


To
"Eddy Quicksall" <eddy_quicksall_iVivity_iSCSI@comcast.net>
cc
ips@ietf.org
Subject
Re: [Ips] ABORT TASK vs ABORT TASK SET






On May 2, 2005, at 11:52 AM, Eddy Quicksall wrote:

> For ABORT TASK SET, the target must wait for all outstanding tags to
> be responded to.
>  
> 10.6.2:
>          b) Waits for all target transfer tags to be responded to and
>             for all affected tasks in the task set to be received.
>  
> But that is not mentioned for ABORT TASK. I'm wondering what the
> rational was for ABORT TASK SET but not ABORT TASK. If the rational is
> to cover possible race conditions at the initiator (e.g., still
> transmitting/receiving data but also getting a TMF Complete) then it
> would seem that the same race should be with ABORT TASK.

My take on this was that you send an ABORT TASK when you know you want
to kill a task. Chances are you know a lot about what's going on with
it, so you will be able to clearly deal with internal state issues.

My take on ABORT TASK SET is that while you may use it when you know a
lot about what's going on, you may also use it when you detect an
internal consistency error. Think of it as a panic button. You press it
when you're in trouble.

Take care,

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

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

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

--===============1801213748== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============1801213748==-- From ips-bounces@ietf.org Wed May 04 16:59:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTQxt-0008VD-Vg; Wed, 04 May 2005 16:59:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTQxn-0008QY-8b; Wed, 04 May 2005 16:59:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05019; Wed, 4 May 2005 16:59:20 -0400 (EDT) Received: from mtagate4.de.ibm.com ([195.212.29.153]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTRBv-0006Cm-Nx; Wed, 04 May 2005 17:14:01 -0400 Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id j44KxBqF182418; Wed, 4 May 2005 20:59:12 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1507.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j44KxBgY278524; Wed, 4 May 2005 22:59:11 +0200 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id j44KxBYc016536; Wed, 4 May 2005 22:59:11 +0200 Received: from d12ml102.megacenter.de.ibm.com (d12ml102.megacenter.de.ibm.com [9.149.166.138]) by d12av04.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j44KxBel016532; Wed, 4 May 2005 22:59:11 +0200 In-Reply-To: <001501c550d1$572756b0$0303a8c0@ivivity.com> To: "Eddy Quicksall" Subject: Re: [Ips] ABORT TASK vs ABORT TASK SET MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_04212005NP April 21, 2005 From: Julian Satran Message-ID: Date: Wed, 4 May 2005 15:59:09 -0500 X-MIMETrack: Serialize by Router on D12ML102/12/M/IBM(Release 6.5.1| March 5, 2004) at 04/05/2005 23:59:10, Serialize complete at 04/05/2005 23:59:10 X-Spam-Score: 2.1 (++) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Cc: ips@ietf.org, William Studenmund , ips-bounces@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2040265026==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org --===============2040265026== Content-Type: text/html; charset="US-ASCII"
Yes - that would be a decent implementation choice. Julo


"Eddy Quicksall" <eddy_quicksall_iVivity_iSCSI@comcast.net>

04/05/2005 12:47

To
"William Studenmund" <wrstuden@wasabisystems.com>, Julian Satran/Haifa/IBM@IBMIL
cc
<ips@ietf.org>, <ips-bounces@ietf.org>
Subject
Re: [Ips] ABORT TASK vs ABORT TASK SET





 
For ABORT TASK SET the target must wait for all commands effected by the TMF to be received. But what if the very reason for the TMF was because a bad connection is preventing a command from reaching the target? Even if the immediate bit is set on the TMF, the target must wait. This would lead to a dead lock for the session.
 
Does the following apply to a bad connection (not just to a data digest error) too? That would overcome the dead lock. But then how long does the target wait? If it is too long, the target may get a WARM/COLD RESET. If it is too short, the command may still arrive later.
  In case all or part of the response sequence is not
 received (due to digest errors) for a valid TTT ... [the target] may drop the connection ...
 
 
Eddy
----- Original Message -----
From: Julian Satran
To: William Studenmund
Cc: ips@ietf.org ; Eddy Quicksall ; ips-bounces@ietf.org
Sent: Tuesday, May 03, 2005 6:14 PM
Subject: Re: [Ips] ABORT TASK vs ABORT TASK SET


The rational is that Abort task has to be sent on the connection on which the task was issued and then it is easy to assure serialization.
That is not the case with task set.

Regards,
Julo

William Studenmund <wrstuden@wasabisystems.com>
Sent by: ips-bounces@ietf.org

02/05/2005 17:49


To
"Eddy Quicksall" <eddy_quicksall_iVivity_iSCSI@comcast.net>
cc
ips@ietf.org
Subject
Re: [Ips] ABORT TASK vs ABORT TASK SET







On May 2, 2005, at 11:52 AM, Eddy Quicksall wrote:

> For ABORT TASK SET, the target must wait for all outstanding tags to
> be responded to.
>  
> 10.6.2:
>          b) Waits for all target transfer tags to be responded to and
>             for all affected tasks in the task set to be received.
>  
> But that is not mentioned for ABORT TASK. I'm wondering what the
> rational was for ABORT TASK SET but not ABORT TASK. If the rational is
> to cover possible race conditions at the initiator (e.g., still
> transmitting/receiving data but also getting a TMF Complete) then it
> would seem that the same race should be with ABORT TASK.

My take on this was that you send an ABORT TASK when you know you want
to kill a task. Chances are you know a lot about what's going on with
it, so you will be able to clearly deal with internal state issues.

My take on ABORT TASK SET is that while you may use it when you know a
lot about what's going on, you may also use it when you detect an
internal consistency error. Think of it as a panic button. You press it
when you're in trouble.

Take care,

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

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

--===============2040265026== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============2040265026==-- From ips-bounces@ietf.org Wed May 04 17:01:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTQzd-0000TH-SU; Wed, 04 May 2005 17:01:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTQzb-0000T9-D6 for ips@megatron.ietf.org; Wed, 04 May 2005 17:01:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05317 for ; Wed, 4 May 2005 17:01:12 -0400 (EDT) Received: from email.crossroads.com ([65.68.235.6]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DTRDk-0006IT-GT for ips@ietf.org; Wed, 04 May 2005 17:15:53 -0400 Received: from mailnode1.COMMSTOR.Crossroads.com ([192.168.1.249]) by email.crossroads.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 4 May 2005 16:01:04 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ips] negotiating more than once Date: Wed, 4 May 2005 16:01:03 -0500 Message-ID: <43F5E8AE07F17C47BC16F7A159E9E700332DC0@mailnode1.commstor.crossroads.com> Thread-Topic: [Ips] negotiating more than once Thread-Index: AcVQy3xPeo9W35jVShqvCy8lDrs1bgAIGfRw From: "Buck Landry" To: "Eddy Quicksall" , X-OriginalArrivalTime: 04 May 2005 21:01:04.0229 (UTC) FILETIME=[6256D950:01C550EC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org Well, rfc3720 5.2.2 says "Proposing a value not admissible (e.g., not within the specified bounds) MAY be answered with the constant "Reject" or the acceptor MAY select an admissible value." So, the target doesn't have to respond with Reject -- it could just = respond w/"No". --buck -----Original Message----- From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org]On Behalf Of = Eddy Quicksall Sent: Wednesday, May 04, 2005 11:59 AM To: ips@ietf.org Subject: [Ips] negotiating more than once The top of page 55 says this: Reject or Irrelevant are legitimate negotiation options where allowed but their excessive use is discouraged. A negotiation is considered complete when the acceptor has sent the key value pair even if the value is "Reject", "Irrelevant", or "NotUnderstood. Sending the key again would be a re-negotiation and is forbidden for many keys. Take this case: The initiator says ImmediateData=3DOK. The target says = ImmediateData=3DReject. The negotiation is now finished. Since ImmediateData defaults to YES and = if the target can't take immediate data then what is the target to do? = The only thing would be to close the connection. Does anyone disagree? How about "does anyone agree"? Eddy _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Wed May 04 17:05:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTR3u-0001Wl-55; Wed, 04 May 2005 17:05:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTR3s-0001Wa-KT for ips@megatron.ietf.org; Wed, 04 May 2005 17:05:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05945 for ; Wed, 4 May 2005 17:05:38 -0400 (EDT) Received: from sccrmhc11.comcast.net ([204.127.202.55]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTRI1-0006U1-Ps for ips@ietf.org; Wed, 04 May 2005 17:20:19 -0400 Received: from ivvt2dxrc11 (c-66-177-46-174.hsd1.fl.comcast.net[66.177.46.174]) by comcast.net (sccrmhc11) with SMTP id <2005050421051801100ind9fe>; Wed, 4 May 2005 21:05:18 +0000 Message-ID: <005b01c550ec$f9e0a440$0303a8c0@ivivity.com> From: "Eddy Quicksall" To: "Buck Landry" , References: <43F5E8AE07F17C47BC16F7A159E9E700332DC0@mailnode1.commstor.crossroads.com> Subject: Re: [Ips] negotiating more than once Date: Wed, 4 May 2005 17:05:17 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org Ahh... Thanks, I didn't notice that. Eddy ----- Original Message ----- From: "Buck Landry" To: "Eddy Quicksall" ; Sent: Wednesday, May 04, 2005 5:01 PM Subject: RE: [Ips] negotiating more than once Well, rfc3720 5.2.2 says "Proposing a value not admissible (e.g., not within the specified bounds) MAY be answered with the constant "Reject" or the acceptor MAY select an admissible value." So, the target doesn't have to respond with Reject -- it could just respond w/"No". --buck -----Original Message----- From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org]On Behalf Of Eddy Quicksall Sent: Wednesday, May 04, 2005 11:59 AM To: ips@ietf.org Subject: [Ips] negotiating more than once The top of page 55 says this: Reject or Irrelevant are legitimate negotiation options where allowed but their excessive use is discouraged. A negotiation is considered complete when the acceptor has sent the key value pair even if the value is "Reject", "Irrelevant", or "NotUnderstood. Sending the key again would be a re-negotiation and is forbidden for many keys. Take this case: The initiator says ImmediateData=OK. The target says ImmediateData=Reject. The negotiation is now finished. Since ImmediateData defaults to YES and if the target can't take immediate data then what is the target to do? The only thing would be to close the connection. Does anyone disagree? How about "does anyone agree"? Eddy _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Thu May 05 09:41:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTgbu-00077N-62; Thu, 05 May 2005 09:41:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTgbs-00077F-5t for ips@megatron.ietf.org; Thu, 05 May 2005 09:41:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27329 for ; Thu, 5 May 2005 09:41:45 -0400 (EDT) Received: from sccrmhc14.comcast.net ([204.127.202.59]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTgq6-0002lo-T3 for ips@ietf.org; Thu, 05 May 2005 09:56:35 -0400 Received: from [67.188.98.5] (c-67-188-98-5.hsd1.ca.comcast.net[67.188.98.5]) by comcast.net (sccrmhc14) with SMTP id <2005050513413001400g5fg5e>; Thu, 5 May 2005 13:41:30 +0000 Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Pat LaVarre Date: Thu, 5 May 2005 06:41:27 -0700 To: "ips at ietf.org" X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: quoted-printable Subject: [Ips] association reasonably limited, not yet everywhere X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org Hello IP Storage folk, > RFC 4018 > Title: Finding Internet Small Computer Systems Interface > (iSCSI) Targets and Name Servers by Using Service > Location Protocol version 2 (SLPv2) How does my iSCSI host defend me against the indiscriminate=20 connectivity nightmare of politely listing for me every iSCSI drive=20 that my employer owns worldwide, to ask me to which I want to connect,=20= like I see some broken printer networks do? Are there relevant iSCSI FAQ=92s that I should have already reviewed? Is =93association=94 the correct jargon for this well-known design issue = in=20 the iSCSI context? Thanks in advance, Pat LaVarre P.S. Relevant background includes: /// http://www.google.com/search?q=3Dwireless+association+host+device =93One of the sought-after characteristics of mobile and ubiquitous=20 computing environments is for devices to become spontaneously=20 associated and interoperate over wireless networks. However,unlike the=20= cable that connects two devices in a wired association, a wireless=20 network does not provide a physical indication of which device is on=20 the other end of the association. Further, the messages sent over a=20 wireless network are readily accessible to other devices on the same=20 network. Hence, a spontaneous wireless association is subject to=20 various spoofing and replay attacks =85 Network-discovery systems such=20= as Jini ... and the Service Location Protocol =85 two-button protocol =85=20= Diffie-Hellman[-Merkle] key exchange =85=94 T. Kindberg & K. Zhang, 2002 /// http://www.google.com/search?q=3DiSCSI+FAQ [no prominent relevant hits yet] /// http://www.google.com/search?q=3DiSCSI+connect+too+well [no prominent relevant hits yet]= _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Thu May 05 14:36:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTlD1-0002fk-Fk; Thu, 05 May 2005 14:36:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTlCy-0002eA-4P for ips@megatron.ietf.org; Thu, 05 May 2005 14:36:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28089 for ; Thu, 5 May 2005 14:36:22 -0400 (EDT) Received: from mononoke.wasabisystems.com ([66.173.145.228]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTlRI-0000Ty-L7 for ips@ietf.org; Thu, 05 May 2005 14:51:13 -0400 Received: from [10.0.0.10] (h-66-166-188-91.sndacagl.covad.net [66.166.188.91]) by mononoke.wasabisystems.com (Postfix) with ESMTP id 12AFC870A7; Thu, 5 May 2005 14:36:10 -0400 (EDT) In-Reply-To: <000601c550ca$959d0a40$0303a8c0@ivivity.com> References: <000601c550ca$959d0a40$0303a8c0@ivivity.com> Mime-Version: 1.0 (Apple Message framework v622) Message-Id: <66ccb35e112265658e860edd4fc2f1dc@wasabisystems.com> From: William Studenmund Subject: Re: [Ips] negotiating more than once Date: Thu, 5 May 2005 11:36:03 -0700 To: "Eddy Quicksall" X-Pgp-Agent: GPGMail 1.0 (v30, 10.3) X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0216629618==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org --===============0216629618== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-1--427990051" Content-Transfer-Encoding: 7bit --Apple-Mail-1--427990051 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On May 4, 2005, at 9:59 AM, Eddy Quicksall wrote: > The top of page 55 says this: > =A0 > =A0=A0 Reject or Irrelevant are legitimate negotiation options where=20= > allowed > =A0=A0 but their excessive use is discouraged.=A0 A negotiation is = considered > =A0=A0 complete when the acceptor has sent the key value pair even if = the > =A0=A0 value is "Reject", "Irrelevant", or "NotUnderstood.=A0 Sending = the key > =A0=A0 again would be a re-negotiation and is forbidden for many keys. > Take this case: > =A0 > =A0 The initiator says ImmediateData=3DOK. The target says=20 > ImmediateData=3DReject. > =A0 > The negotiation is now finished. Since ImmediateData defaults to YES=20= > and if the target can't take immediate data then what is the target to=20= > do? The only thing would be to close the connection. Close the connection. Why is the initiator proposing something other than "YES" or "NO"? With=20= that Reject, you don't know if the target can or can't support=20 ImmediateData, you just know that it doesn't like "OK" as a boolean=20 value. While Buck is correct that the acceptor can send "an admissible value",=20= I'd favor the Reject response. It's not that hard to make sure your=20 offers are within the spec, so if you get something way out of the spec=20= (Like "OK" for a boolean), something somewhere is confused. Take care, Bill --Apple-Mail-1--427990051 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFCemeZDJT2Egh26K0RAiuNAKCK/r/DgKi7VFQEvZ/+iL0NoTu9sgCghpAx TocNsdF0Sj91s9iAlNwf56A= =m32G -----END PGP SIGNATURE----- --Apple-Mail-1--427990051-- --===============0216629618== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0216629618==-- From ips-bounces@ietf.org Thu May 05 18:55:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTpFM-00084p-GF; Thu, 05 May 2005 18:55:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTpFL-00082H-4f for ips@megatron.ietf.org; Thu, 05 May 2005 18:55:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03387 for ; Thu, 5 May 2005 18:54:58 -0400 (EDT) Received: from rwcrmhc12.comcast.net ([216.148.227.85]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTpLh-0006wI-1X for ips@ietf.org; Thu, 05 May 2005 19:01:43 -0400 Received: from ivvt2dxrc11 (c-66-177-46-174.hsd1.fl.comcast.net[66.177.46.174]) by comcast.net (rwcrmhc12) with SMTP id <2005050522463901400g1t5qe>; Thu, 5 May 2005 22:46:39 +0000 Message-ID: <000601c551c4$4d0e2660$0303a8c0@ivivity.com> From: "Eddy Quicksall" To: Date: Thu, 5 May 2005 18:46:34 -0400 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.9 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Subject: [Ips] First Burst Length vs disconnect-reconnect mode page's FIRST BURST SIZE X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0753430923==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============0753430923== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01C551A2.C2EB00A0" This is a multi-part message in MIME format. ------=_NextPart_000_0003_01C551A2.C2EB00A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The disconnect-reconnect mode page says: The FIRST BURST SIZE field specifies the maximum amount of data that may = be transferred to the target port for a command along with the command. What I'm wondering is ... does "along with the command" in iSCSI terms = mean the area covered by all unsolicited data (FirstBurstLength) or does = it mean just the immediate data? Eddy ------=_NextPart_000_0003_01C551A2.C2EB00A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

The disconnect-reconnect mode page = says:

The FIRST BURST = SIZE=20 field specifies the maximum = amount of data=20 that may be transferred to the target port for a command along with the=20 command.

What = I'm wondering is=20 ... does "along with the command" in iSCSI terms mean the area covered = by all=20 unsolicited data (FirstBurstLength) or does it mean just the immediate=20 data?

Eddy

------=_NextPart_000_0003_01C551A2.C2EB00A0-- --===============0753430923== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0753430923==-- From ips-bounces@ietf.org Thu May 05 18:55:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTpFP-000868-42; Thu, 05 May 2005 18:55:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTpFL-00084W-CB for ips@megatron.ietf.org; Thu, 05 May 2005 18:55:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03438 for ; Thu, 5 May 2005 18:55:03 -0400 (EDT) Received: from rwcrmhc13.comcast.net ([204.127.198.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTpHi-0006Yw-LV for ips@ietf.org; Thu, 05 May 2005 18:57:35 -0400 Received: from ivvt2dxrc11 (c-66-177-46-174.hsd1.fl.comcast.net[66.177.46.174]) by comcast.net (rwcrmhc13) with SMTP id <20050505224232015006v2qce>; Thu, 5 May 2005 22:42:32 +0000 Message-ID: <004301c551c3$b9d5b430$0303a8c0@ivivity.com> From: "Eddy Quicksall" To: "Julian Satran" References: Subject: Re: [Ips] ABORT TASK vs ABORT TASK SET Date: Thu, 5 May 2005 18:42:31 -0400 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 1.1 (+) X-Scan-Signature: 559439f19b20fd64c5cd872aef84c6f3 Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1976673266==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============1976673266== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0040_01C551A2.31EE2690" This is a multi-part message in MIME format. ------=_NextPart_000_0040_01C551A2.31EE2690 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I guess this deserves an answer. The RFC is explicit in so many places = that people take the absence of a fact as the presence of the opposite = (not well said but I think you know what I mean). So, I figured the RFC could say something like "The initiator MUST NOT = transfer any data after it has seen the response to the TMF and the = target MUST NOT and can free its resources after it has seen the = completion of the TMF by virtue of ExpStatSN" (but a bit more elegant = wording). Eddy ----- Original Message -----=20 From: Julian Satran=20 To: Eddy Quicksall=20 Cc: ips@ietf.org=20 Sent: Wednesday, May 04, 2005 4:59 PM Subject: Re: [Ips] ABORT TASK vs ABORT TASK SET What would you want to see in the RFC - you are not supposed to use an = ITT that you report as aborted.=20 The only thing needed for the second is for the target to ignore any = data it receives after reporting the end of abort (and that is what I = would consider obvious).=20 Julo=20 "Eddy Quicksall" =20 04/05/2005 12:56=20 To Julian Satran/Haifa/IBM@IBMIL =20 cc =20 Subject Re: [Ips] ABORT TASK vs ABORT TASK SET=20 =20 =20 For the first bullet, I agree this is common sense. But I don't see it = in the RFC.=20 =20 For the second bullet, it looks like a race as to if the target is in = the process of sending the response (so the initiator has not sensed it = as ended) but the target perceives it as ended. Is it understood that = the target does not see it as ended until it gets an ExpStatSN = indicating the initiator now sees it as ended?=20 =20 Eddy=20 ----- Original Message -----=20 From: Julian Satran=20 To: Eddy Quicksall=20 Cc: ips@ietf.org=20 Sent: Wednesday, May 04, 2005 1:31 PM=20 Subject: Re: [Ips] ABORT TASK vs ABORT TASK SET=20 The initiator can be in one of two states:=20 a.. abort is finished - the using the ITT for data packets is no = legal (by initiator)=20 b.. initiator has not yet sensed the abort as being ended - then the = target will discard the data if it has already executed the abort or = process them if not. In any case there is no race neither at initiator nor at target due = to the synchronization of abort after the task.=20 Julo=20 "Eddy Quicksall" =20 04/05/2005 12:03=20 =20 To Julian Satran/Haifa/IBM@IBMIL, =20 cc =20 Subject Re: [Ips] ABORT TASK vs ABORT TASK SET=20 =20 =20 Julian,=20 =20 I may have missed this but I can't find anything in the spec that says = it must be synchronized ... i.e., that the initiator must not continue = to send data PDU's for the task after issueing the ABORT TASK.=20 =20 Did I miss something?=20 =20 Eddy=20 ----- Original Message -----=20 From: Julian Satran=20 To: William Studenmund=20 Cc: ips@ietf.org ; Eddy Quicksall ; ips-bounces@ietf.org=20 Sent: Tuesday, May 03, 2005 6:14 PM=20 Subject: Re: [Ips] ABORT TASK vs ABORT TASK SET=20 The rational is that Abort task has to be sent on the connection on = which the task was issued and then it is easy to assure serialization.=20 That is not the case with task set.=20 Regards,=20 Julo=20 William Studenmund =20 Sent by: ips-bounces@ietf.org=20 02/05/2005 17:49=20 =20 To "Eddy Quicksall" = =20 cc ips@ietf.org =20 Subject Re: [Ips] ABORT TASK vs ABORT TASK SET=20 =20 =20 On May 2, 2005, at 11:52 AM, Eddy Quicksall wrote: > For ABORT TASK SET, the target must wait for all outstanding tags to = > be responded to. > =20 > 10.6.2: > b) Waits for all target transfer tags to be responded to = and > for all affected tasks in the task set to be received. > =20 > But that is not mentioned for ABORT TASK. I'm wondering what the=20 > rational was for ABORT TASK SET but not ABORT TASK. If the rational = is=20 > to cover possible race conditions at the initiator (e.g., still=20 > transmitting/receiving data but also getting a TMF Complete) then it = > would seem that the same race should be with ABORT TASK. My take on this was that you send an ABORT TASK when you know you want = to kill a task. Chances are you know a lot about what's going on with=20 it, so you will be able to clearly deal with internal state issues. My take on ABORT TASK SET is that while you may use it when you know a = lot about what's going on, you may also use it when you detect an=20 internal consistency error. Think of it as a panic button. You press = it=20 when you're in trouble. Take care, Bill_______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips=20 -------------------------------------------------------------------------= ----- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips=20 -------------------------------------------------------------------------= ----- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips=20 -------------------------------------------------------------------------= ----- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips ------=_NextPart_000_0040_01C551A2.31EE2690 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I guess this deserves an answer. The RFC is explicit = in so=20 many places that people take the absence of a fact as the presence of = the=20 opposite (not well said but I think you know what I mean).
 
So, I figured the RFC could say something like "The = initiator=20 MUST NOT transfer any data after it has seen the response to = the TMF=20 and the target MUST NOT and can free its resources after it has seen the = completion of the TMF by virtue of ExpStatSN" (but a bit more elegant=20 wording).
 
Eddy
----- Original Message -----
From:=20 Julian Satran
To: Eddy = Quicksall=20
Sent: Wednesday, May 04, 2005 = 4:59=20 PM
Subject: Re: [Ips] ABORT TASK = vs ABORT=20 TASK SET


What would you = want to see in=20 the RFC - you are not supposed to use an ITT that you report as=20 aborted.
The only thing = needed for the=20 second is for the target to ignore any data it receives after = reporting the=20 end of abort (and that is what I would consider obvious). =

Julo


"Eddy = Quicksall" <eddy_quicksall_i= Vivity_iSCSI@comcast.net>=20

04/05/2005 12:56

To
Julian Satran/Haifa/IBM@IBMIL =
cc
<ips@ietf.org>=20
Subject
Re: [Ips] ABORT TASK vs = ABORT=20 TASK SET

=




For=20 the first bullet, I agree this is common sense. But I don't see it in = the=20 RFC.
 
For = the second=20 bullet, it looks like a race as to if the target is in the process of = sending=20 the response (so the initiator has not sensed it as ended) but the = target=20 perceives it as ended. Is it understood that the target does not see = it as=20 ended until it gets an ExpStatSN indicating the initiator now sees it = as=20 ended?
 
Eddy=20
----- Original Message -----
From: Julian Satran=20
To: Eddy Quicksall =
Cc: ips@ietf.org =
Sent: Wednesday, May 04, 2005 1:31 PM
Subject: Re: [Ips] ABORT TASK vs ABORT TASK SET =


The initiator can be in = one of two=20 states:
  • abort is finished - the using = the ITT for=20 data packets is no legal (by initiator) =
  • initiator has not yet sensed = the abort as=20 being ended - then the target will discard the data if it has = already=20 executed the abort or process them if not.


In any case =  there is=20 no race neither at initiator nor at target due to the synchronization = of abort=20 after the task.

Julo

"Eddy = Quicksall"=20 <eddy_quicksall_iVivity_iSCSI@comcast.net>

04/05/2005 12:03=20


To
Julian=20 Satran/Haifa/IBM@IBMIL, <ips@ietf.org>=20
cc
Subject
Re: [Ips] ABORT TASK vs = ABORT=20 TASK SET







Julian,=20
 
I may have missed this but I can't = find=20 anything in the spec that says it must be synchronized ... i.e., that = the=20 initiator must not continue to send data PDU's for the task after = issueing the=20 ABORT TASK.
 
Did I miss=20 something?
 
Eddy
----- Original Message = -----=20
From: Julian Satran =
To:=20 William Studenmund =
Cc:=20 ips@ietf.org ; Eddy Quicksall ; ips-bounces@ietf.org =
Sent:=20 Tuesday, May 03, 2005 6:14 PM
Subject: Re: [Ips] ABORT TASK = vs=20 ABORT TASK SET


The = rational is=20 that Abort task has to be sent on the connection on which the task was = issued=20 and then it is easy to assure serialization. =
That is not the case with task = set.

Regards,
Julo=20
William = Studenmund=20 <wrstuden@wasabisystems.com>
Sent by: ips-bounces@ietf.org =

02/05/2005 17:49=20


To
"Eddy = Quicksall"=20 <eddy_quicksall_iVivity_iSCSI@comcast.net> =
cc
ips@ietf.org =
Subject
Re: [Ips] ABORT TASK vs = ABORT=20 TASK SET









On May 2, 2005, at = 11:52 AM,=20 Eddy Quicksall wrote:

> For ABORT TASK SET, the target must = wait for=20 all outstanding tags to
> be responded to.
> =  
>=20 10.6.2:
>          b) Waits for all = target=20 transfer tags to be responded to and
>       =  =20     for all affected tasks in the task set to be = received.
>=20  
> But that is not mentioned for ABORT TASK. I'm wondering = what=20 the
> rational was for ABORT TASK SET but not ABORT TASK. If = the=20 rational is
> to cover possible race conditions at the = initiator (e.g.,=20 still
> transmitting/receiving data but also getting a TMF = Complete)=20 then it
> would seem that the same race should be with ABORT=20 TASK.

My take on this was that you send an ABORT TASK when you = know you=20 want
to kill a task. Chances are you know a lot about what's going = on with=20
it, so you will be able to clearly deal with internal state=20 issues.

My take on ABORT TASK SET is that while you may use it = when you=20 know a
lot about what's going on, you may also use it when you = detect an=20
internal consistency error. Think of it as a panic button. You = press it=20
when you're in trouble.

Take=20 = care,

Bill_______________________________________________
Ips=20 mailing=20 = list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips= =20

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

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

_______________________________________________
Ips mailing=20 = list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips
------=_NextPart_000_0040_01C551A2.31EE2690-- --===============1976673266== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============1976673266==-- From ips-bounces@ietf.org Thu May 05 22:38:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTsjr-0001cD-Ht; Thu, 05 May 2005 22:38:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTsjo-0001bz-AJ for ips@megatron.ietf.org; Thu, 05 May 2005 22:38:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23771 for ; Thu, 5 May 2005 22:38:45 -0400 (EDT) Received: from mtagate2.de.ibm.com ([195.212.29.151]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTsyD-00054P-BC for ips@ietf.org; Thu, 05 May 2005 22:53:42 -0400 Received: from d12nrmr1707.megacenter.de.ibm.com (d12nrmr1707.megacenter.de.ibm.com [9.149.167.81]) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id j462cXSp106450 for ; Fri, 6 May 2005 02:38:33 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1707.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j462cX9A285202 for ; Fri, 6 May 2005 04:38:33 +0200 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id j462cW5S009976 for ; Fri, 6 May 2005 04:38:32 +0200 Received: from d12ml102.megacenter.de.ibm.com (d12ml102.megacenter.de.ibm.com [9.149.166.138]) by d12av02.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j462cW1U009970; Fri, 6 May 2005 04:38:32 +0200 In-Reply-To: <004301c551c3$b9d5b430$0303a8c0@ivivity.com> To: "Eddy Quicksall" Subject: Re: [Ips] ABORT TASK vs ABORT TASK SET MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_04212005NP April 21, 2005 From: Julian Satran Message-ID: Date: Thu, 5 May 2005 21:38:29 -0500 X-MIMETrack: Serialize by Router on D12ML102/12/M/IBM(Release 6.5.1| March 5, 2004) at 06/05/2005 05:38:31, Serialize complete at 06/05/2005 05:38:32, Serialize by Router on D12ML102/12/M/IBM(Release 6.5.1| March 5, 2004) at 06/05/2005 05:38:32 X-Spam-Score: 2.1 (++) X-Scan-Signature: 24d000849df6f171c5ec1cca2ea21b82 Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0705292063==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org --===============0705292063== Content-Type: text/html; charset="US-ASCII"
I ahve a hard time understanding why this is necessary. ITT is the primary indicator of a task existence (that is specified). It is also obvious (and specified) that ITT must be a valid value in output packets. All the rest follows.

Julo


"Eddy Quicksall" <eddy_quicksall_iVivity_iSCSI@comcast.net>

05/05/2005 17:42

To
Julian Satran/Haifa/IBM@IBMIL
cc
<ips@ietf.org>
Subject
Re: [Ips] ABORT TASK vs ABORT TASK SET





I guess this deserves an answer. The RFC is explicit in so many places that people take the absence of a fact as the presence of the opposite (not well said but I think you know what I mean).
 
So, I figured the RFC could say something like "The initiator MUST NOT transfer any data after it has seen the response to the TMF and the target MUST NOT and can free its resources after it has seen the completion of the TMF by virtue of ExpStatSN" (but a bit more elegant wording).
 
Eddy
----- Original Message -----
From: Julian Satran
To: Eddy Quicksall
Cc: ips@ietf.org
Sent: Wednesday, May 04, 2005 4:59 PM
Subject: Re: [Ips] ABORT TASK vs ABORT TASK SET


What would you want to see in the RFC - you are not supposed to use an ITT that you report as aborted.
The only thing needed for the second is for the target to ignore any data it receives after reporting the end of abort (and that is what I would consider obvious).

Julo

"Eddy Quicksall" <eddy_quicksall_iVivity_iSCSI@comcast.net>

04/05/2005 12:56


To
Julian Satran/Haifa/IBM@IBMIL
cc
<ips@ietf.org>
Subject
Re: [Ips] ABORT TASK vs ABORT TASK SET







For the first bullet, I agree this is common sense. But I don't see it in the RFC.
 
For the second bullet, it looks like a race as to if the target is in the process of sending the response (so the initiator has not sensed it as ended) but the target perceives it as ended. Is it understood that the target does not see it as ended until it gets an ExpStatSN indicating the initiator now sees it as ended?
 
Eddy
----- Original Message -----
From: Julian Satran
To: Eddy Quicksall
Cc: ips@ietf.org
Sent: Wednesday, May 04, 2005 1:31 PM
Subject: Re: [Ips] ABORT TASK vs ABORT TASK SET


The initiator can be in one of two states:
  • abort is finished - the using the ITT for data packets is no legal (by initiator)
  • initiator has not yet sensed the abort as being ended - then the target will discard the data if it has already executed the abort or process them if not.


In any case  there is no race neither at initiator nor at target due to the synchronization of abort after the task.

Julo
"Eddy Quicksall" <eddy_quicksall_iVivity_iSCSI@comcast.net>

04/05/2005 12:03


To
Julian Satran/Haifa/IBM@IBMIL, <ips@ietf.org>
cc
Subject
Re: [Ips] ABORT TASK vs ABORT TASK SET






Julian,

I may have missed this but I can't find anything in the spec that says it must be synchronized ... i.e., that the initiator must not continue to send data PDU's for the task after issueing the ABORT TASK.

Did I miss something?

Eddy
----- Original Message -----
From: Julian Satran
To: William Studenmund
Cc: ips@ietf.org ; Eddy Quicksall ; ips-bounces@ietf.org
Sent: Tuesday, May 03, 2005 6:14 PM
Subject: Re: [Ips] ABORT TASK vs ABORT TASK SET


The rational is that Abort task has to be sent on the connection on which the task was issued and then it is easy to assure serialization.
That is not the case with task set.

Regards,
Julo
William Studenmund <wrstuden@wasabisystems.com>
Sent by: ips-bounces@ietf.org

02/05/2005 17:49


To
"Eddy Quicksall" <eddy_quicksall_iVivity_iSCSI@comcast.net>
cc
ips@ietf.org
Subject
Re: [Ips] ABORT TASK vs ABORT TASK SET







On May 2, 2005, at 11:52 AM, Eddy Quicksall wrote:

> For ABORT TASK SET, the target must wait for all outstanding tags to
> be responded to.
>  
> 10.6.2:
>          b) Waits for all target transfer tags to be responded to and
>             for all affected tasks in the task set to be received.
>  
> But that is not mentioned for ABORT TASK. I'm wondering what the
> rational was for ABORT TASK SET but not ABORT TASK. If the rational is
> to cover possible race conditions at the initiator (e.g., still
> transmitting/receiving data but also getting a TMF Complete) then it
> would seem that the same race should be with ABORT TASK.

My take on this was that you send an ABORT TASK when you know you want
to kill a task. Chances are you know a lot about what's going on with
it, so you will be able to clearly deal with internal state issues.

My take on ABORT TASK SET is that while you may use it when you know a
lot about what's going on, you may also use it when you detect an
internal consistency error. Think of it as a panic button. You press it
when you're in trouble.

Take care,

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

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

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

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

--===============0705292063== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0705292063==-- From ips-bounces@ietf.org Thu May 05 22:38:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTsjs-0001cf-1R; Thu, 05 May 2005 22:38:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTsjp-0001c4-AQ; Thu, 05 May 2005 22:38:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23774; Thu, 5 May 2005 22:38:46 -0400 (EDT) Received: from mtagate1.de.ibm.com ([195.212.29.150]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTsyD-00054Q-K3; Thu, 05 May 2005 22:53:43 -0400 Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id j462cXkn124320; Fri, 6 May 2005 02:38:33 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1507.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j462cWVt274898; Fri, 6 May 2005 04:38:33 +0200 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id j462cWH8009977; Fri, 6 May 2005 04:38:32 +0200 Received: from d12ml102.megacenter.de.ibm.com (d12ml102.megacenter.de.ibm.com [9.149.166.138]) by d12av02.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j462cWbG009971; Fri, 6 May 2005 04:38:32 +0200 In-Reply-To: <000601c551c4$4d0e2660$0303a8c0@ivivity.com> To: "Eddy Quicksall" Subject: Re: [Ips] First Burst Length vs disconnect-reconnect mode page's FIRST BURST SIZE MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_04212005NP April 21, 2005 From: Julian Satran Message-ID: Date: Thu, 5 May 2005 21:38:30 -0500 X-MIMETrack: Serialize by Router on D12ML102/12/M/IBM(Release 6.5.1| March 5, 2004) at 06/05/2005 05:38:32, Serialize complete at 06/05/2005 05:38:32 X-Spam-Score: 2.0 (++) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: ips@ietf.org, ips-bounces@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0227217277==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org --===============0227217277== Content-Type: text/html; charset="US-ASCII"
All unsolicited data - Julo


"Eddy Quicksall" <eddy_quicksall_iVivity_iSCSI@comcast.net>
Sent by: ips-bounces@ietf.org

05/05/2005 17:46

To
<ips@ietf.org>
cc
Subject
[Ips] First Burst Length vs disconnect-reconnect mode page's FIRST        BURST SIZE





The disconnect-reconnect mode page says:

The FIRST BURST SIZE field specifies the maximum amount of data that may be transferred to the target port for a command along with the command.

What I'm wondering is ... does "along with the command" in iSCSI terms mean the area covered by all unsolicited data (FirstBurstLength) or does it mean just the immediate data?

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

--===============0227217277== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0227217277==-- From ips-bounces@ietf.org Fri May 06 08:29:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DU1x4-0004kz-Ji; Fri, 06 May 2005 08:29:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DU1x2-0004ku-Kf for ips@megatron.ietf.org; Fri, 06 May 2005 08:29:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07093 for ; Fri, 6 May 2005 08:29:02 -0400 (EDT) Received: from ind-iport-1.cisco.com ([64.104.129.195]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DU2BV-0000Ze-Un for ips@ietf.org; Fri, 06 May 2005 08:44:03 -0400 Received: from india-core-1.cisco.com (64.104.129.221) by ind-iport-1.cisco.com with ESMTP; 06 May 2005 18:10:48 +0530 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.92,160,1112553000"; d="scan'208"; a="33224165:sNHT20228808" Received: from ind-mira-01.cisco.com (IDENT:mirapoint@ind-mira-01.cisco.com [64.104.129.12]) by india-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j46HvNKh009188; Fri, 6 May 2005 17:57:24 GMT Received: from smithanw2k (dhcp-10-77-7-111.cisco.com [10.77.7.111]) by ind-mira-01.cisco.com (MOS 3.4.6-GR) with ESMTP id ALB15773; Fri, 6 May 2005 17:54:02 +0530 (IST) Message-Id: <200505061224.ALB15773@ind-mira-01.cisco.com> From: "Smitha Narayanaswamy \(smithan\)" To: , "'linux-iscsi-devel'" Date: Fri, 6 May 2005 17:58:34 +0530 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcVSNxDkAy57nKQXRvmJRXMhnXjbpw== X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: "'Bindu Thota \(bthota\)'" , "'Arpakorn Boonkongchuen \(aboonkon\)'" Subject: [Ips] Authentication X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: smithan@cisco.com List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org Hi, Is the authentication phase mandatory as per the RFC? Also, can you have only target authentication with no initiator authentication? The RFC seemed contradictory when we have: " 3.2.3. iSCSI Login <...> As part of the login process, the initiator and target SHOULD authenticate each other and MAY set a security association protocol for the session. This can occur in many different ways and is subject to negotiation. " and " 5.3. Login Phase <...> In some environments, a target or an initiator is not interested in authenticating its counterpart. It is possible to bypass authentication through the Login Request and Response. " and " 8.2. In-band Initiator-Target Authentication During login, the target MAY authenticate the initiator and the initiator MAY authenticate the target. The authentication is performed on every new iSCSI connection by an exchange of iSCSI Login PDUs using a negotiated authentication method. " Thanks, Smitha _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Fri May 06 10:18:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DU3eb-0004zs-7q; Fri, 06 May 2005 10:18:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DU3eZ-0004zn-Jg for ips@megatron.ietf.org; Fri, 06 May 2005 10:18:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19507 for ; Fri, 6 May 2005 10:18:05 -0400 (EDT) From: Black_David@emc.com Received: from mailhub.lss.emc.com ([168.159.2.31]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DU3t3-0007aA-FF for ips@ietf.org; Fri, 06 May 2005 10:33:07 -0400 Received: from MAHO3MSX2.corp.emc.com (maho3msx2.corp.emc.com [128.221.11.32]) by mailhub.lss.emc.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id j46EHtE0010495; Fri, 6 May 2005 10:17:59 -0400 (EDT) Received: by maho3msx2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Fri, 6 May 2005 10:17:49 -0400 Message-ID: To: smithan@cisco.com, ips@ietf.org Subject: RE: [Ips] Authentication Date: Fri, 6 May 2005 10:17:46 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.0.3.0, Antispam-Data: 2005.5.6.12 X-PerlMx-Spam: Gauge=, SPAM=0%, Reasons='EMC_BODY_1+ -5, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __IMS_MSGID 0, __IMS_MUA 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.3 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org > Is the authentication phase mandatory as per the RFC? It is not mandatory to use (the word "MUST" was not applied), but it is strongly recommended (SHOULD). Support for CHAP MUST be implemented. See RFC 2119 for what these words mean. > Also, can you have only target authentication with no initiator > authentication? No. If one is concerned about whether the holder of the data is actually whom she claims to be (target authentication), one should probably be concerned about whether the client accessing the data is whom she claims to be (initiator authentication). Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- > -----Original Message----- > From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On > Behalf Of Smitha Narayanaswamy (smithan) > Sent: Friday, May 06, 2005 8:29 AM > To: ips@ietf.org; 'linux-iscsi-devel' > Cc: 'Bindu Thota (bthota)'; 'Arpakorn Boonkongchuen (aboonkon)' > Subject: [Ips] Authentication > > Hi, > > Is the authentication phase mandatory as per the RFC? > Also, can you have only target authentication with no initiator > authentication? > > The RFC seemed contradictory when we have: > " > 3.2.3. iSCSI Login > <...> > As part of the login process, the initiator and target SHOULD > authenticate each other and MAY set a security association protocol > for the session. This can occur in many different ways and is > subject to negotiation. > " > and > " > 5.3. Login Phase > <...> > In some environments, a target or an initiator is not interested in > authenticating its counterpart. It is possible to bypass > authentication through the Login Request and Response. > " > and > " > 8.2. In-band Initiator-Target Authentication > > During login, the target MAY authenticate the initiator and the > initiator MAY authenticate the target. The authentication is > performed on every new iSCSI connection by an exchange of iSCSI > Login > PDUs using a negotiated authentication method. > " > > Thanks, > Smitha > > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Fri May 06 20:28:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DUDBF-0007Iz-Mg; Fri, 06 May 2005 20:28:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DUDBE-0007Is-2l for ips@megatron.ietf.org; Fri, 06 May 2005 20:28:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26390 for ; Fri, 6 May 2005 20:28:25 -0400 (EDT) Received: from atlrel7.hp.com ([156.153.255.213]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DUDPo-0003qX-UL for ips@ietf.org; Fri, 06 May 2005 20:43:33 -0400 Received: from rosemail.rose.hp.com (rosemail.rose.hp.com [15.43.209.160]) by atlrel7.hp.com (Postfix) with ESMTP id F1091AA38 for ; Fri, 6 May 2005 20:28:25 -0400 (EDT) Received: from [127.0.0.1] (sindhu.americas.hpqcorp.net [16.93.46.24]) by rosemail.rose.hp.com (Postfix) with ESMTP id 9D68B82E0 for ; Fri, 6 May 2005 17:26:00 -0700 (PDT) Message-ID: <427C0BAB.3080006@rose.hp.com> Date: Fri, 06 May 2005 17:28:27 -0700 From: "Mallikarjun C." User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ips@ietf.org Subject: Re: [Ips] ABORT TASK vs ABORT TASK SET References: <000801c55083$32f43450$6601a8c0@corp.silverbacksystems.com> In-Reply-To: <000801c55083$32f43450$6601a8c0@corp.silverbacksystems.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Content-Transfer-Encoding: 7bit X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org Gwendal, You raise an interesting question. > Do you expect the target to send a NOP In on all other connections to > "collect" all remaining SNACK and DataOUT PDUs? We required the TTT drainage in the spec because it makes target implementations simpler and it generally minimizes the chances for bugs. It turns out that the drainage behavior is beneficial for iSCSI/iSER as well. I do not believe however that it is strictly required for correctness (assuming a correct target implementation). But..... The other two elements of the approach (receiving all commands before acting, and confirming all StatSN acks before sending the final response) are required for correctness depending on the scope of the TMF request. Your question made me realize that the spec doesn't state this explicitly in regards to LU Reset, and Target Resets. This is concerning to me. I do not like the possibility of a naive (but technically compliant) multi-connection target implementation allowing the LU Reset TMF response to pass the "success" task responses of the same I_T_L nexus on other connections. As an aside, I also noticed in reading bullet (b) of target behavior ("Waits for all target transfer tags to be responded to and...") that it is probably more than what's strictly needed. I believe waiting for all TTTs for the I_T_L nexus in question should suffice for task set TMFs. I think it'd be a good idea to elaborate on LU Reset, and the two flavors of Target Reset in a formal IETF doc. Thanks! Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture StorageWorks Division Hewlett-Packard MS 5668 Roseville CA 95747 cbm [at] rose.hp.com gwendal grignou wrote: > Julian, > > You have a valid point for Abort Task, but what about LUN RESET? > > It can impact tasks on all connections of the session where the TASK > Management Request has been sent [I am not talking about other sessions], > but according to the iSCSI RFC, the initiator that issued the LUN RESET is > not bound to send an answer for all outstanding tags. It just says: > > "For the LOGICAL UNIT RESET function, the target MUST behave as > dictated by the Logical Unit Reset function in [SAM2]." > > Couldn't we have a race condition? Depending on the timing, the target may > or may not received DataOut PDUs with F bit or DataACK for outstanding tags > impacted by the LUN RESET in same the session where the LUN RESET has been > issued, but issued on different connections... > > Do you expect the target to send a NOP In on all other connections to > "collect" all remaining SNACK and DataOUT PDUs? > > Regards, > Gwendal > > -----Original Message----- > From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On Behalf Of Julian > Satran > Sent: Tuesday, May 03, 2005 3:15 PM > To: William Studenmund > Cc: ips@ietf.org; Eddy Quicksall; ips-bounces@ietf.org > Subject: Re: [Ips] ABORT TASK vs ABORT TASK SET > > > The rational is that Abort task has to be sent on the connection on which > the task was issued and then it is easy to assure serialization. > That is not the case with task set. > > Regards, > Julo > > William Studenmund > Sent by: ips-bounces@ietf.org > 02/05/2005 17:49 > To > "Eddy Quicksall" > cc > ips@ietf.org > Subject > Re: [Ips] ABORT TASK vs ABORT TASK SET > > > > > > > > On May 2, 2005, at 11:52 AM, Eddy Quicksall wrote: > > >>For ABORT TASK SET, the target must wait for all outstanding tags to >>be responded to. >> >>10.6.2: >> b) Waits for all target transfer tags to be responded to and >> for all affected tasks in the task set to be received. >> >>But that is not mentioned for ABORT TASK. I'm wondering what the >>rational was for ABORT TASK SET but not ABORT TASK. If the rational is >>to cover possible race conditions at the initiator (e.g., still >>transmitting/receiving data but also getting a TMF Complete) then it >>would seem that the same race should be with ABORT TASK. > > > My take on this was that you send an ABORT TASK when you know you want > to kill a task. Chances are you know a lot about what's going on with > it, so you will be able to clearly deal with internal state issues. > > My take on ABORT TASK SET is that while you may use it when you know a > lot about what's going on, you may also use it when you detect an > internal consistency error. Think of it as a panic button. You press it > when you're in trouble. > > Take care, > > Bill_______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips > > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Tue May 10 17:52:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVcem-00024f-Eg; Tue, 10 May 2005 17:52:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVcek-00024a-QX for ips@megatron.ietf.org; Tue, 10 May 2005 17:52:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25055 for ; Tue, 10 May 2005 17:52:44 -0400 (EDT) From: Black_David@emc.com Received: from mailhub.lss.emc.com ([168.159.2.31]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVcu8-0002C6-5P for ips@ietf.org; Tue, 10 May 2005 18:08:41 -0400 Received: from MAHO3MSX2.corp.emc.com (maho3msx2.corp.emc.com [128.221.11.32]) by mailhub.lss.emc.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id j4ALqPtf018012; Tue, 10 May 2005 17:52:26 -0400 (EDT) Received: by maho3msx2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Tue, 10 May 2005 17:52:19 -0400 Message-ID: To: p.lavarre@ieee.org, ips@ietf.org Subject: RE: [Ips] association reasonably limited, not yet everywhere Date: Tue, 10 May 2005 17:52:16 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.0.3.0, Antispam-Data: 2005.5.10.28 X-PerlMx-Spam: Gauge=, SPAM=0%, Reasons='EMC_BODY_1+ -5, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __IMS_MSGID 0, __IMS_MUA 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.3 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org Pat, > How does my iSCSI host defend me against the indiscriminate > connectivity nightmare of politely listing for me every iSCSI drive > that my employer owns worldwide, to ask me to which I want to > connect, like I see some broken printer networks do? RTFR, starting with Section 4.1.1 of RFC 4018, followed by RFC 2608 and RFC 2609 on SLPv2 (e.g., use of scopes, although scopes are analogous to what gets misconfigured in "some broken printer networks"). Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- > -----Original Message----- > From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On > Behalf Of Pat LaVarre > Sent: Thursday, May 05, 2005 9:41 AM > To: ips at ietf.org > Subject: [Ips] association reasonably limited, not yet everywhere > > Hello IP Storage folk, > > > RFC 4018 > > Title: Finding Internet Small Computer Systems Interface > > (iSCSI) Targets and Name Servers by Using Service > > Location Protocol version 2 (SLPv2) > > How does my iSCSI host defend me against the indiscriminate > connectivity nightmare of politely listing for me every iSCSI drive > that my employer owns worldwide, to ask me to which I want to > connect, > like I see some broken printer networks do? > > Are there relevant iSCSI FAQ's that I should have already reviewed? > > Is "association" the correct jargon for this well-known > design issue in > the iSCSI context? > > Thanks in advance, Pat LaVarre > > P.S. Relevant background includes: > > /// http://www.google.com/search?q=wireless+association+host+device > > "One of the sought-after characteristics of mobile and ubiquitous > computing environments is for devices to become spontaneously > associated and interoperate over wireless networks. > However,unlike the > cable that connects two devices in a wired association, a wireless > network does not provide a physical indication of which device is on > the other end of the association. Further, the messages sent over a > wireless network are readily accessible to other devices on the same > network. Hence, a spontaneous wireless association is subject to > various spoofing and replay attacks ... Network-discovery systems such > as Jini ... and the Service Location Protocol ... two-button protocol ... > Diffie-Hellman[-Merkle] key exchange ..." T. Kindberg & K. Zhang, 2002 > > /// http://www.google.com/search?q=iSCSI+FAQ > > [no prominent relevant hits yet] > > /// http://www.google.com/search?q=iSCSI+connect+too+well > > [no prominent relevant hits yet] > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Tue May 10 18:09:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVcuU-0000Pz-9t; Tue, 10 May 2005 18:09:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVcuS-0000Pu-61 for ips@megatron.ietf.org; Tue, 10 May 2005 18:09:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27199 for ; Tue, 10 May 2005 18:08:57 -0400 (EDT) From: Black_David@emc.com Received: from mailhub.lss.emc.com ([168.159.2.31]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVd9p-0003A8-PZ for ips@ietf.org; Tue, 10 May 2005 18:24:55 -0400 Received: from mxic2.corp.emc.com (mxic2.corp.emc.com [128.221.12.9]) by mailhub.lss.emc.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id j4AM8ujH022028 for ; Tue, 10 May 2005 18:08:56 -0400 (EDT) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Tue, 10 May 2005 18:08:55 -0400 Message-ID: To: ips@ietf.org Date: Tue, 10 May 2005 18:07:59 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.0.3.2, Antispam-Data: 2005.5.10.27 X-PerlMx-Spam: Gauge=, SPAM=0%, Reasons='EMC_BODY_1+ -5, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __IMS_MSGID 0, __IMS_MUA 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.3 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [Ips] iSER/DA WG Last Call timing X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org I realize that people have been waiting for this, and I apologize for getting diverted by my day job. In looking at this, I just realized that I need to clear up the status of MPA - whether that draft will be a standards track vs. informational RFC - in order to determine whether iSER will be standards track vs. informational. In order to avoid delaying things any further, I'm going to start the WG Last Call on iSER and DA (separate message coming shortly) and work on MPA's status in parallel, with the goal of getting it (and hence iSER's status) resolved before the conclusion of the WG Last Call. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Tue May 10 18:17:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVd2v-00036O-HH; Tue, 10 May 2005 18:17:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVd2t-00033N-1e for ips@megatron.ietf.org; Tue, 10 May 2005 18:17:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28485 for ; Tue, 10 May 2005 18:17:40 -0400 (EDT) From: Black_David@emc.com Received: from mailhub.lss.emc.com ([168.159.2.31]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVdIH-0003gO-PK for ips@ietf.org; Tue, 10 May 2005 18:33:38 -0400 Received: from MAHO3MSX2.corp.emc.com (maho3msx2.corp.emc.com [128.221.11.32]) by mailhub.lss.emc.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id j4AMHYS3001597 for ; Tue, 10 May 2005 18:17:35 -0400 (EDT) Received: by maho3msx2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Tue, 10 May 2005 18:17:23 -0400 Message-ID: To: ips@ietf.org Date: Tue, 10 May 2005 18:17:22 -0400 Importance: high X-Priority: 1 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.0.3.0, Antispam-Data: 2005.5.10.28 X-PerlMx-Spam: Gauge=, SPAM=0%, Reasons='EMC_BODY_1+ -5, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __HAS_X_PRIORITY 0, __IMS_MSGID 0, __IMS_MUA 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.8 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Subject: [Ips] WG Last Call: iSER and DA X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org It is my pleasure to announce the IPS Working Group Last Call on the following two drafts: iSCSI Extensions for RDMA Specification [aka iSER] (draft-ietf-ips-iser-03.txt) Datamover Architecture for iSCSI (DA) (draft-ietf-ips-iwarp-da-02.txt) iSER will become a Proposed Standard vs. Informational RFC depending on whether the RDDP MPA draft becomes a Proposed Standard vs. Informational RFC; I have to go work on the latter - stay tuned. DA will become an Informational RFC. This WG Last Call will run until 11:59pm Eastern Time (US) on Friday, June 3rd. That should give anyone who puts off reviewing these drafts until after Memorial Day in the US a few days to get their review done. Technical comments need to be posted to this mailing list. Editorial comments may be sent directly to the primary draft authors: - iSER: Mike Ko - DA: Mallikarjun Chadalapaka Please copy me (as WG co-chair - David Black ) on any editorial comments, just in case something initially thought to be editorial turns out to have technical content. These drafts depend on RDDP WG drafts (all of which have completed WG Last Call) linked to the RDDP WG's web page: http://www.ietf.org/html.charters/rddp-charter.html Many thanks, --David (for David & Elizabeth IPS WG co-chairs) ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Thu May 12 14:15:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWIDr-0006WY-UO; Thu, 12 May 2005 14:15:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWIDq-0006WQ-7E; Thu, 12 May 2005 14:15:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17518; Thu, 12 May 2005 14:15:44 -0400 (EDT) From: Black_David@emc.com Received: from mailhub.lss.emc.com ([168.159.2.31]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWITb-00009R-1G; Thu, 12 May 2005 14:32:04 -0400 Received: from MAHO3MSX2.corp.emc.com (maho3msx2.corp.emc.com [128.221.11.32]) by mailhub.lss.emc.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id j4CIFenM027992; Thu, 12 May 2005 14:15:41 -0400 (EDT) Received: by maho3msx2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Thu, 12 May 2005 14:15:40 -0400 Message-ID: To: rddp@ietf.org, ips@ietf.org Date: Thu, 12 May 2005 14:15:18 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.0.3.0, Antispam-Data: 2005.5.12.20 X-PerlMx-Spam: Gauge=, SPAM=0%, Reasons='EMC_BODY_1+ -5, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __IMS_MSGID 0, __IMS_MUA 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.3 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: Subject: [Ips] MPA and iSER: Standards Track X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org I've corresponded with the Transport Area Director for the RDDP WG (Jon Peterson), and the resulting agreement is that the RFC standards track is appropriate for MPA and hence also iSER, so the initial status that will be requested for both will be Proposed Standard RFC. Many thanks for everyone's patience with the necessity of deferring this decision until after MPA's WG Last Call. As for status/schedule of the RDDP drafts - they've all passed WG Last Call, and so authors should be making sure that the latest versions respond to all Last Call comments and satisfy everything in the ID Checklist: http://www.ietf.org/ID-Checklist.html Courtesy of my day job's bad habit of interfering with IETF work, I expect to be getting to double-checking this and submitting the RDDP drafts to our AD (Jon) and the IESG towards the end of this month. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Fri May 13 08:19:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWZ8E-00089L-9H; Fri, 13 May 2005 08:19:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWTnf-0008Oy-47; Fri, 13 May 2005 02:37:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13228; Fri, 13 May 2005 02:37:29 -0400 (EDT) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWU3W-00009t-CM; Fri, 13 May 2005 02:53:55 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 May 2005 23:37:19 -0700 Received: from red-hub-01.redmond.corp.microsoft.com ([157.54.7.71]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 May 2005 23:37:19 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 May 2005 23:37:18 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 May 2005 23:37:18 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7548.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ips] MPA and iSER: Standards Track Date: Thu, 12 May 2005 23:37:17 -0700 Message-ID: Thread-Topic: [Ips] MPA and iSER: Standards Track Thread-Index: AcVXH1WqVPNix9i8TryxNuhf5273xwAZtd/A From: "Jim Pinkerton" To: , , X-OriginalArrivalTime: 13 May 2005 06:37:18.0462 (UTC) FILETIME=[357E21E0:01C55786] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 13 May 2005 08:19:04 -0400 Cc: X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org Yow!!!! Jim =20 > -----Original Message----- > From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On=20 > Behalf Of Black_David@emc.com > Sent: Thursday, May 12, 2005 11:15 AM > To: rddp@ietf.org; ips@ietf.org > Subject: [Ips] MPA and iSER: Standards Track >=20 > I've corresponded with the Transport Area Director for the=20 > RDDP WG (Jon Peterson), and the resulting agreement is that=20 > the RFC standards track is appropriate for MPA and hence also=20 > iSER, so the initial status that will be requested for both=20 > will be Proposed Standard RFC. > Many thanks for everyone's patience with the necessity of=20 > deferring this decision until after MPA's WG Last Call. >=20 > As for status/schedule of the RDDP drafts - they've all=20 > passed WG Last Call, and so authors should be making sure=20 > that the latest versions respond to all Last Call comments=20 > and satisfy everything in the ID Checklist: >=20 > http://www.ietf.org/ID-Checklist.html >=20 > Courtesy of my day job's bad habit of interfering with IETF=20 > work, I expect to be getting to double-checking this and=20 > submitting the RDDP drafts to our AD (Jon) and the IESG=20 > towards the end of this month. >=20 > Thanks, > --David > ---------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 176 South St., Hopkinton, MA 01748 > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > black_david@emc.com Mobile: +1 (978) 394-7754 > ---------------------------------------------------- >=20 > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips >=20 _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Mon May 16 17:31:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXnBY-0004gr-EN; Mon, 16 May 2005 17:31:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXnBW-0004e0-3T; Mon, 16 May 2005 17:31:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22851; Mon, 16 May 2005 17:31:31 -0400 (EDT) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DXnS5-00039O-7b; Mon, 16 May 2005 17:48:44 -0400 Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j4GLRn322227; Mon, 16 May 2005 14:27:49 -0700 (PDT) Message-Id: <200505162127.j4GLRn322227@boreas.isi.edu> To: ietf-announce@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Mon, 16 May 2005 14:27:49 -0700 X-ISI-4-39-6-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu X-Spam-Score: -14.6 (--------------) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: ips@ietf.org, rfc-editor@rfc-editor.org Subject: [Ips] RFC 4044 on the Fibre Channel Management MIB X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org --NextPart A new Request for Comments is now available in online RFC libraries. RFC 4044 Title: Fibre Channel Management MIB Author(s): K. McCloghrie Status: Standards Track Date: May 2005 Mailbox: kzm@cisco.com Pages: 69 Characters: 127148 Obsoletes: 2837 I-D Tag: draft-ietf-ips-fcmgmt-mib-06.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc4044.txt This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for information related to the Fibre Channel. This document is a product of the IP Storage Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <050516142602.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc4044 --OtherAccess Content-Type: Message/External-body; name="rfc4044.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <050516142602.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --NextPart-- From ips-bounces@ietf.org Wed May 18 16:41:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYVME-0006NP-5K; Wed, 18 May 2005 16:41:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYVMB-0006NJ-O5 for ips@megatron.ietf.org; Wed, 18 May 2005 16:41:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18266 for ; Wed, 18 May 2005 16:41:29 -0400 (EDT) From: Yackey_Steve@emc.com Received: from mailhub.lss.emc.com ([168.159.2.31]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYVdD-0007Jk-0F for ips@ietf.org; Wed, 18 May 2005 16:59:07 -0400 Received: from corpusic3.corp.emc.com (corpusic3.corp.emc.com [10.254.64.109]) by mailhub.lss.emc.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id j4IKfRSi022272 for ; Wed, 18 May 2005 16:41:28 -0400 (EDT) Received: by corpusic3.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Wed, 18 May 2005 16:41:27 -0400 Message-ID: To: ips@ietf.org Date: Wed, 18 May 2005 16:41:26 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.0.3.2, Antispam-Data: 2005.5.18.24 X-PerlMx-Spam: Gauge=, SPAM=7%, Reasons='NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0, __CTYPE_MULTIPART_ALT 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __IMS_MSGID 0, __IMS_MUA 0, __MIME_HTML 0, __MIME_VERSION 0, __SANE_MSGID 0, __TAG_EXISTS_HTML 0' X-Spam-Score: 0.9 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Subject: [Ips] iSNS and iSCSI config X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1524072399==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1524072399== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C55BE9.F6300D65" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C55BE9.F6300D65 Content-Type: text/plain I have a couple of question regarding usage of iSNS for iSCSI configuration. In the IPSec area: 1) Is there provision for storing a pre-shared key ? 2) Is there provision for storing the tunnel gateway for esp tunnel mode ? I looked thru 'draft-ietf-ips-isns-22.txt' and did not see this info. Thanks in advance, Steve Steve Yackey EMC2 Corporation 1401 Main Street, Suite 350 Columbia, SC 29201 803-231-2632 ------_=_NextPart_001_01C55BE9.F6300D65 Content-Type: text/html iSNS and iSCSI config

I have a couple of question regarding usage of iSNS for iSCSI configuration.

In the IPSec area:

1) Is there provision for storing a pre-shared key ?
2) Is there provision for storing the tunnel gateway for esp tunnel mode ?

I looked thru 'draft-ietf-ips-isns-22.txt' and did not see this info.

Thanks in advance,
Steve


Steve Yackey
EMC2 Corporation
1401 Main Street, Suite 350
Columbia, SC 29201
803-231-2632


------_=_NextPart_001_01C55BE9.F6300D65-- --===============1524072399== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============1524072399==-- From ips-bounces@ietf.org Wed May 18 18:15:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYWmE-0004Tp-9F; Wed, 18 May 2005 18:12:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYWmC-0004Rm-9n for ips@megatron.ietf.org; Wed, 18 May 2005 18:12:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27849 for ; Wed, 18 May 2005 18:12:25 -0400 (EDT) Received: from mononoke.wasabisystems.com ([66.173.145.228]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYX3D-00032W-E9 for ips@ietf.org; Wed, 18 May 2005 18:30:04 -0400 Received: from [10.0.0.10] (h-66-166-188-91.sndacagl.covad.net [66.166.188.91]) by mononoke.wasabisystems.com (Postfix) with ESMTP id 480DC87062; Wed, 18 May 2005 18:12:20 -0400 (EDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v622) Message-Id: <612053ff9d078eda1787e9d917d41338@wasabisystems.com> From: William Studenmund Subject: Re: [Ips] iSNS and iSCSI config Date: Wed, 18 May 2005 15:12:07 -0700 To: Yackey_Steve@emc.com X-Pgp-Agent: GPGMail 1.0 (v30, 10.3) X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0766492236==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org --===============0766492236== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-1-708174036" Content-Transfer-Encoding: 7bit --Apple-Mail-1-708174036 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On May 18, 2005, at 1:41 PM, Yackey_Steve@emc.com wrote: > I have a couple of question regarding usage of iSNS for iSCSI > configuration. > > In the IPSec area: > > 1) Is there provision for storing a pre-shared key ? > 2) Is there provision for storing the tunnel gateway for esp tunnel > mode ? I think it would be a bad idea for iSNS to be used to distribute security configuration parameters. While I realize it will make life more difficult for a system with a lot of targets and/or initiators, I think any sort of security configuration distribution system should be designed as-such from the ground up. I am not aware that iSNS was designed as such, and so I think it would be a very inappropriate tool for distributing security configuration information. Take care, Bill --Apple-Mail-1-708174036 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD4DBQFCi73CDJT2Egh26K0RAkFcAJdM2sJlgSEMgVJ9J1SwSV6/6EXVAJ9Qkoeb 9ksBb1mKYQv9o+tYGFHeeA== =ks2z -----END PGP SIGNATURE----- --Apple-Mail-1-708174036-- --===============0766492236== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0766492236==-- From ips-bounces@ietf.org Wed May 18 23:24:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYbe6-0001bC-QN; Wed, 18 May 2005 23:24:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYbe4-0001b7-RR for ips@megatron.ietf.org; Wed, 18 May 2005 23:24:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22826 for ; Wed, 18 May 2005 23:24:22 -0400 (EDT) Received: from web52201.mail.yahoo.com ([206.190.39.83]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DYbv8-00030i-9D for ips@ietf.org; Wed, 18 May 2005 23:42:04 -0400 Received: (qmail 99430 invoked by uid 60001); 19 May 2005 03:24:13 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=AqTZg1/exjWfZ7+CkYhk3lKMQXRgaG26ynaflkwIAVmJCAL3m37kZfvuGugRF5/hfBCrW+Ymxo0YRv7Bb1XCs30v1S0Od1BYG/a1w+UPcQJNe8Q2LuV3QKpPa+kpcJuHkW4tWdeA01c5E6jqT/zd+crq9AMOryEQVBDPWrOOxpY= ; Message-ID: <20050519032413.99428.qmail@web52201.mail.yahoo.com> Received: from [68.120.139.233] by web52201.mail.yahoo.com via HTTP; Wed, 18 May 2005 20:24:13 PDT Date: Wed, 18 May 2005 20:24:13 -0700 (PDT) From: Josh Tseng Subject: Re: [Ips] iSNS and iSCSI config To: Yackey_Steve@emc.com, ips@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 1.3 (+) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org The answer to both of these questions is 'no' if you are restricted to the existing IANA-defined attributes. However, nothing prevents you from creating your own private attributes to do either, although you should consider the security implications of doing so. Josh --- Yackey_Steve@emc.com wrote: > > I have a couple of question regarding usage of iSNS > for iSCSI configuration. > > In the IPSec area: > > 1) Is there provision for storing a pre-shared key ? > 2) Is there provision for storing the tunnel gateway > for esp tunnel mode ? > > I looked thru 'draft-ietf-ips-isns-22.txt' and did > not see this info. > > Thanks in advance, > Steve > > > Steve Yackey > EMC2 Corporation > 1401 Main Street, Suite 350 > Columbia, SC 29201 > 803-231-2632 > > > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips > __________________________________ Do you Yahoo!? Take Yahoo! Mail with you! Get it on your mobile phone. http://mobile.yahoo.com/maildemo _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Wed May 18 23:39:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYbsD-0005Cj-Va; Wed, 18 May 2005 23:39:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYbsC-0005AQ-0C for ips@megatron.ietf.org; Wed, 18 May 2005 23:39:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24003 for ; Wed, 18 May 2005 23:38:57 -0400 (EDT) Received: from web52207.mail.yahoo.com ([206.190.39.89]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DYc9G-0003Lm-4X for ips@ietf.org; Wed, 18 May 2005 23:56:39 -0400 Received: (qmail 34742 invoked by uid 60001); 19 May 2005 03:38:49 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=jP1B9umR3DmH3Om4TTD8Xo2DODeddhfSvPRlgV+/8T7IiOYBsi0vNjNlhb+kjviKMbx2oQdiQfXta/+53l33BzIeJortfwneuc6onyavSgqBBn8t519yZn1LQwWB4KjOWZh4RaGF8dfbQzx7t8xA/5/WSxts3nMi6aqyJe6KuSg= ; Message-ID: <20050519033849.34740.qmail@web52207.mail.yahoo.com> Received: from [68.120.139.233] by web52207.mail.yahoo.com via HTTP; Wed, 18 May 2005 20:38:49 PDT Date: Wed, 18 May 2005 20:38:49 -0700 (PDT) From: Josh Tseng Subject: Re: [Ips] iSNS and iSCSI config To: William Studenmund , Yackey_Steve@emc.com In-Reply-To: <612053ff9d078eda1787e9d917d41338@wasabisystems.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 1.3 (+) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org > > I think it would be a bad idea for iSNS to be used > to distribute > security configuration parameters. While I realize > it will make life > more difficult for a system with a lot of targets > and/or initiators, I > think any sort of security configuration > distribution system should be > designed as-such from the ground up. I am not aware > that iSNS was > designed as such, and so I think it would be a very > inappropriate tool > for distributing security configuration information. > Hi Bill, iSNS is a specification; whether a specific iSNS server is secure enough to be used for communicating security policies really is an implementation question. But if the iSNS server is implemented in a secure manner, I don't see why security policies couldn't be communicated through iSNS. It can cut down on unnecessary IKE handshakes and thus improve response time for new iSCSI devices connecting into the network. Josh > Take care, > > Bill > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips > Discover Yahoo! Find restaurants, movies, travel and more fun for the weekend. Check it out! http://discover.yahoo.com/weekend.html _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Thu May 19 07:57:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYjeG-0003nA-AU; Thu, 19 May 2005 07:57:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYjeF-0003n5-Ip for ips@megatron.ietf.org; Thu, 19 May 2005 07:57:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25932 for ; Thu, 19 May 2005 07:57:06 -0400 (EDT) Received: from [202.54.64.17] (helo=hclnpd.hclt-ntl.co.in) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYjvO-0007Nu-Td for ips@ietf.org; Thu, 19 May 2005 08:14:51 -0400 Received: from npd-disclaim.hclt-ntl.co.in (10.105.1.115 [10.105.1.115]) by hclnpd.hclt-ntl.co.in with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id K826TVKB; Thu, 19 May 2005 17:26:53 +0530 thread-index: AcVcada0uYQ/afVoReWT6iF4Un0fNw== X-MessageTextProcessor: DisclaimIt (2.50.252) [HCL Technologies Ltd., Chennai, India] Received: from npd-mail.hclt-ntl.co.in ([10.105.1.104]) by npd-disclaim.hclt-ntl.co.in with Microsoft SMTPSVC(6.0.2600.2180); Thu, 19 May 2005 17:26:49 +0530 Received: from npd.hcltech.com (ssenthil-pc.hclt-ntl.co.in [10.105.2.131]) by npd-mail.hclt-ntl.co.in with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id J69ZPSZY; Thu, 19 May 2005 17:26:48 +0530 Message-ID: <428C7F00.B88FD881@npd.hcltech.com> Date: Thu, 19 May 2005 17:26:48 +0530 From: "sundara senthil" X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Subject: [Ips]Invalid key References: <20050519033849.34740.qmail@web52207.mail.yahoo.com> Content-Type: text/plain; charset="us-ascii" Content-Class: urn:content-classes:message Content-Transfer-Encoding: quoted-printable Importance: normal Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 19 May 2005 11:56:49.0295 (UTC) FILETIME=[D6AD99F0:01C55C69] X-Spam-Score: 0.3 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: quoted-printable X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org Hi All, According to the iscsi RFC 3720, mentioned in the section 5.2 "Any key not understood by the acceptor may be ignored by the acceptor without affecting the basic function. However, the answer for a key not understood MUST be key=3DNotUnderstood." I would like to know that if initiator sends any invalid key name and a = value pair to the iscsi target, should the target ignore the key pair without responding or target should respond as invalid = key=3DNotUnderstood. Thanks sundar Disclaimer: This message and any attachment(s) contained here are information that = is confidential, proprietary to HCL Technologies and its customers, = privileged or otherwise protected by law. The information is solely = intended for the individual or the entity it is addressed to. If you are = not the intended recipient of this message, you are not authorized to = read, forward, print, retain, copy or disseminate this message or any = part of it. If you have received this e-mail in error, please notify the = sender immediately by return e-mail and delete it from your computer. _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Thu May 19 08:14:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYjql-0007w1-Ux; Thu, 19 May 2005 08:10:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYjqk-0007u7-CE for ips@megatron.ietf.org; Thu, 19 May 2005 08:10:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27641 for ; Thu, 19 May 2005 08:10:01 -0400 (EDT) From: Yackey_Steve@emc.com Received: from mailhub.lss.emc.com ([168.159.2.31]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYk7s-0007vW-Rx for ips@ietf.org; Thu, 19 May 2005 08:27:46 -0400 Received: from corpusic1.corp.emc.com (corpusic1.corp.emc.com [168.159.129.100]) by mailhub.lss.emc.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id j4JC9qYv009408; Thu, 19 May 2005 08:09:53 -0400 (EDT) Received: by corpusic1.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Thu, 19 May 2005 08:09:52 -0400 Message-ID: To: joshtseng@yahoo.com, wrstuden@wasabisystems.com Subject: RE: [Ips] iSNS and iSCSI config Date: Thu, 19 May 2005 08:09:51 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.0.3.2, Antispam-Data: 2005.5.19.9 X-PerlMx-Spam: Gauge=, SPAM=7%, Reasons='NO_REAL_NAME 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __IMS_MSGID 0, __IMS_MUA 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.3 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org Bill, Additionally, the IPSec info available via iSNS fills in the 'gaps' left by rfc3723. Meaning two endpoints won't successfully talk if they don't agree on pfs, ike mode, etc. The iSNS traffic itself can be protected with ipsec. So I think that iSNS is an excellent solution, IMO. Thanks, Steve -----Original Message----- From: Josh Tseng [mailto:joshtseng@yahoo.com] Sent: Wednesday, May 18, 2005 11:39 PM To: William Studenmund; Yackey_Steve@emc.com Cc: ips@ietf.org Subject: Re: [Ips] iSNS and iSCSI config > > I think it would be a bad idea for iSNS to be used to distribute > security configuration parameters. While I realize it will make life > more difficult for a system with a lot of targets and/or initiators, I > think any sort of security configuration distribution system should be > designed as-such from the ground up. I am not aware that iSNS was > designed as such, and so I think it would be a very inappropriate tool > for distributing security configuration information. > Hi Bill, iSNS is a specification; whether a specific iSNS server is secure enough to be used for communicating security policies really is an implementation question. But if the iSNS server is implemented in a secure manner, I don't see why security policies couldn't be communicated through iSNS. It can cut down on unnecessary IKE handshakes and thus improve response time for new iSCSI devices connecting into the network. Josh > Take care, > > Bill > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips > Discover Yahoo! Find restaurants, movies, travel and more fun for the weekend. Check it out! http://discover.yahoo.com/weekend.html _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Thu May 19 12:39:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYo3u-0007yl-PE; Thu, 19 May 2005 12:39:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYo3t-0007ye-D5 for ips@megatron.ietf.org; Thu, 19 May 2005 12:39:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23074 for ; Thu, 19 May 2005 12:39:48 -0400 (EDT) Received: from mononoke.wasabisystems.com ([66.173.145.228]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYoL2-0007O0-Au for ips@ietf.org; Thu, 19 May 2005 12:57:37 -0400 Received: from [10.0.0.10] (h-66-166-188-91.sndacagl.covad.net [66.166.188.91]) by mononoke.wasabisystems.com (Postfix) with ESMTP id 8116A87087; Thu, 19 May 2005 12:39:27 -0400 (EDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v622) Message-Id: From: William Studenmund Subject: Re: [Ips] iSNS and iSCSI config Date: Thu, 19 May 2005 09:39:16 -0700 To: Yackey_Steve@emc.com X-Pgp-Agent: GPGMail 1.0 (v30, 10.3) X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0296733327==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org --===============0296733327== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-1-774603320" Content-Transfer-Encoding: 7bit --Apple-Mail-1-774603320 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On May 18, 2005, at 1:41 PM, Yackey_Steve@emc.com wrote: > I have a couple of question regarding usage of iSNS for iSCSI > configuration. > > In the IPSec area: > > 1) Is there provision for storing a pre-shared key ? > 2) Is there provision for storing the tunnel gateway for esp tunnel > mode ? Actually, in re-reading this more, I don't think there is any way storing a tunnel address would work; if iSNS indicates preferring tunnel mode, you should be establishing tunnel mode to the portal; the portal address already is the "gateway" address. To try to have iSNS include any sort of other esp tunnel gateway would require either a lot of knowledge about the intervening network, and would need it in the iSNS server. iSNS doesn't convey enough information to tell the server what is between the initiator and target, so some sort of magic would have to happen. While I can envision topologies where it would work out, I don't think they are the common case intended for iSNS. Take care, Bill --Apple-Mail-1-774603320 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFCjME5DJT2Egh26K0RAudKAJ4iCnABqALfOUMdQc6Mbz6AjSoF1wCfUknV 3Ea1gpAl+pbSeYdGyKAQnXs= =v6Yt -----END PGP SIGNATURE----- --Apple-Mail-1-774603320-- --===============0296733327== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0296733327==-- From ips-bounces@ietf.org Thu May 19 12:44:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYo8Q-0000JB-NW; Thu, 19 May 2005 12:44:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYo8P-0000Iv-3x for ips@megatron.ietf.org; Thu, 19 May 2005 12:44:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23458 for ; Thu, 19 May 2005 12:44:30 -0400 (EDT) Received: from mononoke.wasabisystems.com ([66.173.145.228]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYoPa-0007Wr-SY for ips@ietf.org; Thu, 19 May 2005 13:02:19 -0400 Received: from [10.0.0.10] (h-66-166-188-91.sndacagl.covad.net [66.166.188.91]) by mononoke.wasabisystems.com (Postfix) with ESMTP id 23CF5870AA; Thu, 19 May 2005 12:44:28 -0400 (EDT) In-Reply-To: <20050519033849.34740.qmail@web52207.mail.yahoo.com> References: <20050519033849.34740.qmail@web52207.mail.yahoo.com> Mime-Version: 1.0 (Apple Message framework v622) Message-Id: From: William Studenmund Subject: Re: [Ips] iSNS and iSCSI config Date: Thu, 19 May 2005 09:44:19 -0700 To: Josh Tseng X-Pgp-Agent: GPGMail 1.0 (v30, 10.3) X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: ips@ietf.org, Yackey_Steve@emc.com X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2120186371==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org --===============2120186371== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-2-774906279" Content-Transfer-Encoding: 7bit --Apple-Mail-2-774906279 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On May 18, 2005, at 8:38 PM, Josh Tseng wrote: >> >> I think it would be a bad idea for iSNS to be used >> to distribute >> security configuration parameters. While I realize >> it will make life >> more difficult for a system with a lot of targets >> and/or initiators, I >> think any sort of security configuration >> distribution system should be >> designed as-such from the ground up. I am not aware >> that iSNS was >> designed as such, and so I think it would be a very >> inappropriate tool >> for distributing security configuration information. >> > > Hi Bill, > > iSNS is a specification; whether a specific iSNS > server is secure enough to be used for communicating > security policies really is an implementation > question. But if the iSNS server is implemented in a > secure manner, I don't see why security policies > couldn't be communicated through iSNS. It can cut > down on unnecessary IKE handshakes and thus improve > response time for new iSCSI devices connecting into > the network. If we're just talking publicly-available info, then you're right. And the stuff in iSNS now is fine. However the initial question, to which I was overly-broadly replying above, was asking about distributing pre-shared keys. iSNS is not a pre-shared key distribution protocol. :-) Take care, Bill --Apple-Mail-2-774906279 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFCjMJpDJT2Egh26K0RAoGyAJ9TEsrXAEOjvZ+O2zTL6p4mF45vmACcD0Qt 1thfJFurFm4DgY0ADCEDRpw= =RU13 -----END PGP SIGNATURE----- --Apple-Mail-2-774906279-- --===============2120186371== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============2120186371==-- From ips-bounces@ietf.org Thu May 19 16:28:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYrcm-00021P-D2; Thu, 19 May 2005 16:28:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYrck-00020j-ES for ips@megatron.ietf.org; Thu, 19 May 2005 16:28:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27596 for ; Thu, 19 May 2005 16:28:03 -0400 (EDT) Received: from sccrmhc11.comcast.net ([204.127.202.55]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYrtx-0001I3-8d for ips@ietf.org; Thu, 19 May 2005 16:45:54 -0400 Received: from ivvt2dxrc11 (c-66-177-46-174.hsd1.fl.comcast.net[66.177.46.174]) by comcast.net (sccrmhc11) with SMTP id <2005051920275301100iu6g9e>; Thu, 19 May 2005 20:27:53 +0000 Message-ID: <000601c55cb1$374d0b50$03031eac@ivivity.com> From: "Eddy Quicksall" To: , "Julian Satran" Date: Thu, 19 May 2005 16:27:44 -0400 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.9 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: Subject: [Ips] Authentication in a discovery session X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2029342731==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============2029342731== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01C55C8F.AF9FA080" This is a multi-part message in MIME format. ------=_NextPart_000_0003_01C55C8F.AF9FA080 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Is Authentication allowed in a discovery session? I figure it is a good = idea but I want to ask what the authors intended. I may have missed something but in every case where I see Authentication = mentioned with regards to an object, it always mentions an initiator = and/or a target. I can't find an implication that a discovery session, = which does not have a target, should support authentication. Also, all of the examples show a TargetName supplied during AuthMethod. = Could there be some authentication methods that require a target name? Since discovery does not have a target, then is it intended that = authentication during discovery is not expected or even allowed? Eddy ------=_NextPart_000_0003_01C55C8F.AF9FA080 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Is Authentication allowed in a discovery session? I = figure it=20 is a good idea but I want to ask what the authors intended.
 
I may have missed something but in every case where = I see=20 Authentication mentioned with regards to an object, it always = mentions an=20 initiator and/or a target. I can't find an implication that a discovery = session,=20 which does not have a target, should support = authentication.
 
Also, all of the examples show a TargetName supplied = during=20 AuthMethod. Could there be some authentication methods that require a = target=20 name?
 
Since discovery does not have a target, then is it = intended=20 that authentication during discovery is not expected or even=20 allowed?
 
Eddy
 
 
 
 
------=_NextPart_000_0003_01C55C8F.AF9FA080-- --===============2029342731== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============2029342731==-- From ips-bounces@ietf.org Thu May 19 18:55:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYtvW-0006pz-93; Thu, 19 May 2005 18:55:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYtvU-0006pu-R0 for ips@megatron.ietf.org; Thu, 19 May 2005 18:55:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12526 for ; Thu, 19 May 2005 18:55:33 -0400 (EDT) Received: from mononoke.wasabisystems.com ([66.173.145.228]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYuCe-0005XY-4K for ips@ietf.org; Thu, 19 May 2005 19:13:23 -0400 Received: from [10.0.0.10] (h-66-166-188-91.sndacagl.covad.net [66.166.188.91]) by mononoke.wasabisystems.com (Postfix) with ESMTP id 1842E87084; Thu, 19 May 2005 18:55:25 -0400 (EDT) In-Reply-To: <428C7F00.B88FD881@npd.hcltech.com> References: <20050519033849.34740.qmail@web52207.mail.yahoo.com> <428C7F00.B88FD881@npd.hcltech.com> Mime-Version: 1.0 (Apple Message framework v622) Message-Id: <3832c56c7917ecb539a32934989d25df@wasabisystems.com> From: William Studenmund Subject: Re: [Ips]Invalid key Date: Thu, 19 May 2005 15:55:15 -0700 To: "sundara senthil" X-Pgp-Agent: GPGMail 1.0 (v30, 10.3) X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1971218213==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org --===============1971218213== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-1-797162301" Content-Transfer-Encoding: 7bit --Apple-Mail-1-797162301 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On May 19, 2005, at 4:56 AM, sundara senthil wrote: > Hi All, > > According to the iscsi RFC 3720, mentioned in the section 5.2 > > "Any key not understood by the acceptor may be ignored by the > acceptor without affecting the basic function. However, the answer > for a key not understood MUST be key=NotUnderstood." > > I would like to know that if initiator sends any invalid key name and > a value > pair to the iscsi target, should the target ignore the key pair > without responding or target should respond as invalid > key=NotUnderstood. The acceptor (the target could have made the initial offer, after all) must reply "invalid_key-NotUnderstood". Note however that we are assuming the unknown key came with some sort of conceivably reasonable initial offer. If the initial offer were something like "Reject", "Irrelevant", or "NotUnderstood", then there is a protocol error. I'd recommend closing the connection. Take care, Bill --Apple-Mail-1-797162301 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFCjRlZDJT2Egh26K0RAiYmAJ9d1PbdQU0Im3oSxK9OMHHOD7lHiwCdG/1N IL8aKFrgKw0Z2hPcjPLadak= =I/e2 -----END PGP SIGNATURE----- --Apple-Mail-1-797162301-- --===============1971218213== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============1971218213==-- From ips-bounces@ietf.org Thu May 19 19:12:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYuC2-0004T1-CY; Thu, 19 May 2005 19:12:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYuC0-0004Sw-51 for ips@megatron.ietf.org; Thu, 19 May 2005 19:12:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14083 for ; Thu, 19 May 2005 19:12:36 -0400 (EDT) Received: from mononoke.wasabisystems.com ([66.173.145.228]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYuT1-00064A-DG for ips@ietf.org; Thu, 19 May 2005 19:30:17 -0400 Received: from [10.0.0.10] (h-66-166-188-91.sndacagl.covad.net [66.166.188.91]) by mononoke.wasabisystems.com (Postfix) with ESMTP id 36F8E87097; Thu, 19 May 2005 19:12:24 -0400 (EDT) In-Reply-To: <000601c55cb1$374d0b50$03031eac@ivivity.com> References: <000601c55cb1$374d0b50$03031eac@ivivity.com> Mime-Version: 1.0 (Apple Message framework v622) Message-Id: <61e9b830e0d5a0b4fa84c28cca2c4e48@wasabisystems.com> From: William Studenmund Subject: Re: [Ips] Authentication in a discovery session Date: Thu, 19 May 2005 16:12:16 -0700 To: "Eddy Quicksall" X-Pgp-Agent: GPGMail 1.0 (v30, 10.3) X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: ips@ietf.org, Julian Satran X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0900728216==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org --===============0900728216== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-2-798183448" Content-Transfer-Encoding: 7bit --Apple-Mail-2-798183448 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On May 19, 2005, at 1:27 PM, Eddy Quicksall wrote: > Is Authentication allowed in a discovery session? I figure it is a=20 > good idea but I want to ask what the authors intended. The Wasabi target supports authentication during discovery sessions.=20 What it does not support is mutual CHAP during unnamed discovery=20 sessions. > I may have missed something but in every case where I see=20 > Authentication mentioned=A0with regards to an object, it always = mentions=20 > an initiator and/or a target. I can't find an implication that a=20 > discovery session, which does not have a target, should support=20 > authentication. My take on this is that in an unnamed discovery session, we do have an=20= initiator object. If that initiator object can be authenticated, by=20 matching the CHAP name to a CHAP secret for any node available via a=20 given portal, the it's allowed in for discovery and can discover all=20 nodes available (as per the spec). Even nodes for which it hadn't=20 authenticated in the discovery session. Worded another way, say there are nodes A, B, and C available via a=20 portal. An initiator logs in for a discovery session without a=20 TargetName. In replying to the CHAP challenge, it supplies a CHAP name=20= and a CHAP response. We find the first node that has an auth entry with=20= that CHAP name. If the CHAP response is correct for the CHAP name, then=20= the initiator is allowed in to see what's around. It could be that the=20= name and password are that for node C. Nodes A and B are still=20 mentioned in the discovery info. > Also, all of the examples show a TargetName supplied during=20 > AuthMethod. Could there be some authentication methods that require a=20= > target name? I personally feel that mutual CHAP requires a TargetName, so you know=20 what target should authenticate itself to the initiator. :-) > Since discovery does not have a target, then is it intended that=20 > authentication during discovery is not expected or even allowed? I believe it can be very useful to support authentication during=20 discovery. Connections and sessions are limited resources. If you don't=20= have authenticated discovery, then you open yourself up to potential=20 DoS attacks. However I do believe that if an initiator is able to log into a target=20= without authentication, it is reasonable to permit it to discover said=20= target without authentication. So don't use "None" on boxes on the=20 public internet. :-) Take care, Bill --Apple-Mail-2-798183448 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFCjR1VDJT2Egh26K0RAtnjAKCZw8SOMb/Usl/rl8kL5f9AlKaNiQCgmAzK YCa1Y63CwYNT6g2/rGOCE8g= =ffgi -----END PGP SIGNATURE----- --Apple-Mail-2-798183448-- --===============0900728216== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0900728216==-- From ips-bounces@ietf.org Fri May 20 01:49:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZ0OD-0007jN-1F; Fri, 20 May 2005 01:49:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZ0OB-0007jF-84 for ips@megatron.ietf.org; Fri, 20 May 2005 01:49:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17129 for ; Fri, 20 May 2005 01:49:38 -0400 (EDT) Received: from bay106-f29.bay106.hotmail.com ([65.54.161.39] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZ0fT-0007Ir-0x for ips@ietf.org; Fri, 20 May 2005 02:07:32 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 19 May 2005 22:49:28 -0700 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Fri, 20 May 2005 05:49:27 GMT X-Originating-IP: [65.54.161.200] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: <20050519033849.34740.qmail@web52207.mail.yahoo.com> From: "Bernard Aboba" To: ips@ietf.org Subject: Re: [Ips] iSNS and iSCSI config Date: Thu, 19 May 2005 22:49:27 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 20 May 2005 05:49:28.0053 (UTC) FILETIME=[AF7CBA50:01C55CFF] X-Spam-Score: 0.8 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org >I think any sort of security configuration distribution system should be >designed as-such from the >ground up. I am not aware that iSNS was designed >as such, and so I think it would be a very >inappropriate tool for >distributing security configuration information. Ironically existing "security configuration distribution systems" designed "from the ground up" are inferior to iSNS in terms of ease of use, reliability, interoperability, and in the end, security. They are inferior in terms of ease of use because they have to provide for a wide array of configuration options and usage scenarios, most of which are not allowable in IP storage security. One of the explicit goals of RFC 3723 was to dramatically simplify security configuration by reducing the range of potential configurations. Existing mechanisms are often unreliable because they don't support transaction semantics and can therefore replicate incomplete configurations. They are non-interoperable because there are no standard protocols designed to solve the general security configuration problem. And they are ultimately insecure, because they have not been subjected to security review, and are difficult to configure correctly. >iSNS is a specification; whether a specific iSNS >server is secure enough to be used for communicating >security policies really is an implementation >question. But if the iSNS server is implemented in a >secure manner, I don't see why security policies >couldn't be communicated through iSNS. It can cut >down on unnecessary IKE handshakes and thus improve >response time for new iSCSI devices connecting into >the network. Indeed. iSNS was designed to provide secure "plug and play" configuration for storage systems. In general, it provides configuration at the appropriate level of detail, utilizes standardized security mechanisms, provides reliable configuration, and can operate at scale. As a result, I think one can argue that iSNS is a better match to the security configuration problems of IP storage than any general purpose security policy configuration mechanism that exists today. _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Fri May 20 08:45:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZ6sW-0001HK-IU; Fri, 20 May 2005 08:45:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZ6sU-0001HF-UU for ips@megatron.ietf.org; Fri, 20 May 2005 08:45:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09667 for ; Fri, 20 May 2005 08:45:21 -0400 (EDT) From: Black_David@emc.com Received: from mailhub.lss.emc.com ([168.159.2.31]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZ79o-0000bT-8j for ips@ietf.org; Fri, 20 May 2005 09:03:19 -0400 Received: from mxic2.corp.emc.com (mxic2.corp.emc.com [128.221.12.9]) by mailhub.lss.emc.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id j4KCjDF1020019; Fri, 20 May 2005 08:45:14 -0400 (EDT) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Fri, 20 May 2005 08:45:13 -0400 Message-ID: To: senthilsn@npd.hcltech.com, ips@ietf.org Subject: RE: [Ips]Invalid key Date: Fri, 20 May 2005 08:45:12 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.0.3.2, Antispam-Data: 2005.5.20.10 X-PerlMx-Spam: Gauge=, SPAM=0%, Reasons='EMC_BODY_1+ -5, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __IMS_MSGID 0, __IMS_MUA 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.3 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org First of all ... > Disclaimer: > > This message and any attachment(s) contained here are > information that is confidential, proprietary to HCL > Technologies and its customers, privileged or otherwise > protected by law. [... remainder snipped ...] Disclaimers like that do not work when email is sent to a public IETF mailing list including this one - please remove them from all emails, as they are completely inappropriate for this list, as the only thing they will accomplish is to annoy people. Send any followups on this issue *directly* to me, and *not* to the list. > According to the iscsi RFC 3720, mentioned in the section 5.2 > > "Any key not understood by the acceptor may be ignored by the > acceptor without affecting the basic function. However, the answer > for a key not understood MUST be key=NotUnderstood." > > I would like to know that if initiator sends any invalid key > name and a value > pair to the iscsi target, should the target ignore the key pair > without responding or target should respond as invalid > key=NotUnderstood. The NotUnderstood response is REQUIRED (so that the initiator knows that something it tried didn't work). Beyond, that, the target can do what it likes with that key, including nothing else. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Fri May 20 10:12:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZ8FF-0003gm-8j; Fri, 20 May 2005 10:12:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZ8FC-0003gh-V0 for ips@megatron.ietf.org; Fri, 20 May 2005 10:12:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20283 for ; Fri, 20 May 2005 10:12:52 -0400 (EDT) From: Yackey_Steve@emc.com Received: from mailhub.lss.emc.com ([168.159.2.31]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZ8Wa-0002y7-4Q for ips@ietf.org; Fri, 20 May 2005 10:30:52 -0400 Received: from corpusic1.corp.emc.com (corpusic1.corp.emc.com [168.159.129.100]) by mailhub.lss.emc.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id j4KECnH5001228 for ; Fri, 20 May 2005 10:12:49 -0400 (EDT) Received: by corpusic1.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Fri, 20 May 2005 10:12:51 -0400 Message-ID: To: ips@ietf.org Subject: RE: [Ips] iSNS and iSCSI config Date: Fri, 20 May 2005 10:12:50 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.0.3.2, Antispam-Data: 2005.5.20.12 X-PerlMx-Spam: Gauge=, SPAM=7%, Reasons='NO_REAL_NAME 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __IMS_MSGID 0, __IMS_MUA 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.3 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org Just as a final note, rfc3723 informs that (2.6.2), "Once communication between iSNS clients and the iSNS server are secured through use of IPsec, iSNS clients have the capability to discover the security settings required for communication via the iSCSI and/or iFCP protocols. Use of iSNS for distribution of security policies offers the potential to reduce the burden of manual device configuration, and decrease the probability of communications failures due to incompatible security policies. ... " So I think iSNS has a real, practical application here. -----Original Message----- From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On Behalf Of Bernard Aboba Sent: Friday, May 20, 2005 1:49 AM To: ips@ietf.org Subject: Re: [Ips] iSNS and iSCSI config >I think any sort of security configuration distribution system should >be designed as-such from the >ground up. I am not aware that iSNS was >designed as such, and so I think it would be a very >inappropriate tool >for distributing security configuration information. Ironically existing "security configuration distribution systems" designed "from the ground up" are inferior to iSNS in terms of ease of use, reliability, interoperability, and in the end, security. They are inferior in terms of ease of use because they have to provide for a wide array of configuration options and usage scenarios, most of which are not allowable in IP storage security. One of the explicit goals of RFC 3723 was to dramatically simplify security configuration by reducing the range of potential configurations. Existing mechanisms are often unreliable because they don't support transaction semantics and can therefore replicate incomplete configurations. They are non-interoperable because there are no standard protocols designed to solve the general security configuration problem. And they are ultimately insecure, because they have not been subjected to security review, and are difficult to configure correctly. >iSNS is a specification; whether a specific iSNS server is secure >enough to be used for communicating security policies really is an >implementation question. But if the iSNS server is implemented in a >secure manner, I don't see why security policies couldn't be >communicated through iSNS. It can cut down on unnecessary IKE >handshakes and thus improve response time for new iSCSI devices >connecting into the network. Indeed. iSNS was designed to provide secure "plug and play" configuration for storage systems. In general, it provides configuration at the appropriate level of detail, utilizes standardized security mechanisms, provides reliable configuration, and can operate at scale. As a result, I think one can argue that iSNS is a better match to the security configuration problems of IP storage than any general purpose security policy configuration mechanism that exists today. _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Fri May 20 13:00:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZArK-0002n9-0b; Fri, 20 May 2005 13:00:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZArI-0002mH-CI for ips@megatron.ietf.org; Fri, 20 May 2005 13:00:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07497 for ; Fri, 20 May 2005 13:00:20 -0400 (EDT) Received: from e6.ny.us.ibm.com ([32.97.182.146]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZB8f-0007fg-Qr for ips@ietf.org; Fri, 20 May 2005 13:18:23 -0400 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e6.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j4KH08fD008500 for ; Fri, 20 May 2005 13:00:08 -0400 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4KH08YV099362 for ; Fri, 20 May 2005 13:00:08 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j4KH07Xv000774 for ; Fri, 20 May 2005 13:00:07 -0400 Received: from d01ml604.pok.ibm.com (d01ml604.pok.ibm.com [9.56.227.90]) by d01av01.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j4KH07Mb000714; Fri, 20 May 2005 13:00:07 -0400 Importance: Normal MIME-Version: 1.0 To: William Studenmund Subject: Re: [Ips]Invalid key X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 Message-ID: From: Mike Ko Date: Fri, 20 May 2005 09:57:52 -0700 X-MIMETrack: Serialize by Router on D01ML604/01/M/IBM(Build V70_04122005|April 12, 2005) at 05/20/2005 13:00:06, Serialize complete at 05/20/2005 13:00:06 Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: ips@ietf.org, sundara senthil X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org I wouldn't jump to the conclusion that if a key is NotUnderstood, that the recommended course of action is to close the connection. In iSER (iSCSI Extensions for RDMA), the initiator (or target) offers the key RDMAExtensions to determine if the target (or initiator) can operate in iSER mode. If the response is NotUnderstood, then the connection remains in iSCSI mode. This is not a protocol error and closing the connection in this case would be inappropriate. Mike Sent by: ips-bounces@ietf.org To: "sundara senthil" cc: ips@ietf.org Subject: Re: [Ips]Invalid key On May 19, 2005, at 4:56 AM, sundara senthil wrote: > Hi All, > > According to the iscsi RFC 3720, mentioned in the section 5.2 > > "Any key not understood by the acceptor may be ignored by the > acceptor without affecting the basic function. However, the answer > for a key not understood MUST be key=NotUnderstood." > > I would like to know that if initiator sends any invalid key name and > a value > pair to the iscsi target, should the target ignore the key pair > without responding or target should respond as invalid > key=NotUnderstood. The acceptor (the target could have made the initial offer, after all) must reply "invalid_key-NotUnderstood". Note however that we are assuming the unknown key came with some sort of conceivably reasonable initial offer. If the initial offer were something like "Reject", "Irrelevant", or "NotUnderstood", then there is a protocol error. I'd recommend closing the connection. Take care, Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Fri May 20 17:00:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZEbb-0000PB-PW; Fri, 20 May 2005 17:00:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZEbZ-0000Oy-7A for ips@megatron.ietf.org; Fri, 20 May 2005 17:00:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13822 for ; Fri, 20 May 2005 17:00:22 -0400 (EDT) Received: from mononoke.wasabisystems.com ([66.173.145.228]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZEsz-0000tJ-1w for ips@ietf.org; Fri, 20 May 2005 17:18:26 -0400 Received: from [10.0.0.10] (h-66-166-188-91.sndacagl.covad.net [66.166.188.91]) by mononoke.wasabisystems.com (Postfix) with ESMTP id 4ED4687090; Fri, 20 May 2005 17:00:15 -0400 (EDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v622) Message-Id: <3721339f1a2b37f6691008cea9f50ce8@wasabisystems.com> From: William Studenmund Subject: Re: [Ips]Invalid key Date: Fri, 20 May 2005 14:00:07 -0700 To: sundara senthil , Mike Ko X-Pgp-Agent: GPGMail 1.0 (v30, 10.3) X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: IPS X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1740666928==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org --===============1740666928== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-1-876654222" Content-Transfer-Encoding: 7bit --Apple-Mail-1-876654222 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On May 20, 2005, at 9:57 AM, Mike Ko wrote: > I wouldn't jump to the conclusion that if a key is NotUnderstood, that > the > recommended course of action is to close the connection. In iSER > (iSCSI > Extensions for RDMA), the initiator (or target) offers the key > RDMAExtensions to determine if the target (or initiator) can operate in > iSER mode. If the response is NotUnderstood, then the connection > remains > in iSCSI mode. This is not a protocol error and closing the > connection in > this case would be inappropriate. I'm sorry, I wasn't clear. If you get a key you don't understand AND what should be an initial offer is instead "Reject", "NotUnderstood" or "Irrelevant" (a response to an offer that you didn't make as you don't understand the key), THEN you should consider it a protocol error and close the connection. As an RDMA-aware initiator or target (the one that made the offer) will understand the key, it will not fall into the case above. It will merely find one of its offers was not understood. This latter behavior is the point of "NotUnderstood" and I agree we should NOT close the connection at that point. The whole point here is that if a key somehow gets in the negotiation stream that is not understood by either side, then the connection should close. This scenario came up once when an initiator was creating malformed offers, and both sides kept responding, "NotUnderstood", to each other. So to reply to the original question, if you get a key you don't understand, you should look at the value passed with the key. If the value is "Reject", "Irrelevant", or "NotUnderstood", then something bad happened. If the value is ANYTHING else, then you MUST reply "NotUnderstood" and otherwise ignore the occurrence. That means that if everything else looks fine in the negotiations, you transition along as normal. Take care, Bill --Apple-Mail-1-876654222 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFCjk/cDJT2Egh26K0RAjyQAJ9LjGtDDid/Qs5A24+k4sJvgR1TywCgnXFr 2lZOMo+UOc1uY+jF3VljIEo= =IBRE -----END PGP SIGNATURE----- --Apple-Mail-1-876654222-- --===============1740666928== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============1740666928==-- From ips-bounces@ietf.org Sat May 21 09:07:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZTh8-0004NG-2q; Sat, 21 May 2005 09:07:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZTh6-0004NB-9t for ips@megatron.ietf.org; Sat, 21 May 2005 09:07:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18775 for ; Sat, 21 May 2005 09:07:06 -0400 (EDT) Received: from rwcrmhc14.comcast.net ([216.148.227.89]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZTye-00051M-Tc for ips@ietf.org; Sat, 21 May 2005 09:25:18 -0400 Received: from ivvt2dxrc11 (c-66-177-46-174.hsd1.fl.comcast.net[66.177.46.174]) by comcast.net (rwcrmhc14) with SMTP id <2005052113065601400928cae>; Sat, 21 May 2005 13:06:57 +0000 Message-ID: <004e01c55e05$f16a4c50$03031eac@ivivity.com> From: "Eddy Quicksall" To: "William Studenmund" References: <000601c55cb1$374d0b50$03031eac@ivivity.com> <61e9b830e0d5a0b4fa84c28cca2c4e48@wasabisystems.com> Subject: Re: [Ips] Authentication in a discovery session Date: Sat, 21 May 2005 09:06:35 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Cc: ips@ietf.org, Julian Satran X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org >As an RDMA-aware initiator or target (the one that made the offer) will >understand the key, it will not fall into the case above. It will >merely find one of its offers was not understood. This latter behavior >is the point of "NotUnderstood" and I agree we should NOT close the >connection at that point. Does the NotUnderstood reasoning only apply to login? Or does it also apply to FFP too? Eddy ----- Original Message ----- From: "William Studenmund" To: "Eddy Quicksall" Cc: ; "Julian Satran" Sent: Thursday, May 19, 2005 7:12 PM Subject: Re: [Ips] Authentication in a discovery session > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Sat May 21 18:35:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZcZA-0001oT-Eo; Sat, 21 May 2005 18:35:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZcZ7-0001oL-Qe for ips@megatron.ietf.org; Sat, 21 May 2005 18:35:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04839 for ; Sat, 21 May 2005 18:35:24 -0400 (EDT) Received: from mtagate4.de.ibm.com ([195.212.29.153]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZcqk-0003hb-1x for ips@ietf.org; Sat, 21 May 2005 18:53:42 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id j4LMZEqF191922 for ; Sat, 21 May 2005 22:35:14 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4LMZEXm062446 for ; Sun, 22 May 2005 00:35:14 +0200 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id j4LMZEQp011600 for ; Sun, 22 May 2005 00:35:14 +0200 Received: from d12ml102.megacenter.de.ibm.com (d12ml102.megacenter.de.ibm.com [9.149.166.138]) by d12av02.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j4LMZDrr011597; Sun, 22 May 2005 00:35:14 +0200 In-Reply-To: <61e9b830e0d5a0b4fa84c28cca2c4e48@wasabisystems.com> To: William Studenmund Subject: Re: [Ips] Authentication in a discovery session MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_04212005NP April 21, 2005 From: Julian Satran Message-ID: Date: Sat, 21 May 2005 18:35:13 -0400 X-MIMETrack: Serialize by Router on D12ML102/12/M/IBM(Release 6.5.1| March 5, 2004) at 22/05/2005 01:35:13, Serialize complete at 22/05/2005 01:35:13 X-Spam-Score: 1.8 (+) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: ips@ietf.org, Eddy Quicksall X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0353550752==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org --===============0353550752== Content-Type: text/html; charset="US-ASCII"
I think that this answer summarizes the options available pretty well.
I wonder however if it not be wise for the target portal to hide some of the targets behind it based on the supplied initiator name (similar of the target ability to hide LUs  based on the initiator name during a normal session).

Julo
William Studenmund <wrstuden@wasabisystems.com> wrote on 19/05/2005 19:12:16:

> On May 19, 2005, at 1:27 PM, Eddy Quicksall wrote:
>
> > Is Authentication allowed in a discovery session? I figure it is a
> > good idea but I want to ask what the authors intended.
>
> The Wasabi target supports authentication during discovery sessions.
> What it does not support is mutual CHAP during unnamed discovery
> sessions.
>
> > I may have missed something but in every case where I see
> > Authentication mentioned with regards to an object, it always mentions
> > an initiator and/or a target. I can't find an implication that a
> > discovery session, which does not have a target, should support
> > authentication.
>
> My take on this is that in an unnamed discovery session, we do have an
> initiator object. If that initiator object can be authenticated, by
> matching the CHAP name to a CHAP secret for any node available via a
> given portal, the it's allowed in for discovery and can discover all
> nodes available (as per the spec). Even nodes for which it hadn't
> authenticated in the discovery session.
>
> Worded another way, say there are nodes A, B, and C available via a
> portal. An initiator logs in for a discovery session without a
> TargetName. In replying to the CHAP challenge, it supplies a CHAP name
> and a CHAP response. We find the first node that has an auth entry with
> that CHAP name. If the CHAP response is correct for the CHAP name, then
> the initiator is allowed in to see what's around. It could be that the
> name and password are that for node C. Nodes A and B are still
> mentioned in the discovery info.
>
> > Also, all of the examples show a TargetName supplied during
> > AuthMethod. Could there be some authentication methods that require a
> > target name?
>
> I personally feel that mutual CHAP requires a TargetName, so you know
> what target should authenticate itself to the initiator. :-)
>
> > Since discovery does not have a target, then is it intended that
> > authentication during discovery is not expected or even allowed?
>
> I believe it can be very useful to support authentication during
> discovery. Connections and sessions are limited resources. If you don't
> have authenticated discovery, then you open yourself up to potential
> DoS attacks.
>
> However I do believe that if an initiator is able to log into a target
> without authentication, it is reasonable to permit it to discover said
> target without authentication. So don't use "None" on boxes on the
> public internet. :-)
>
> Take care,
>
> Bill
> [attachment "PGP.sig" deleted by Julian Satran/Haifa/IBM] --===============0353550752== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0353550752==-- From ips-bounces@ietf.org Mon May 23 12:44:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaG2P-0002XL-MA; Mon, 23 May 2005 12:44:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaG2O-0002XG-Uy for ips@megatron.ietf.org; Mon, 23 May 2005 12:44:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12391 for ; Mon, 23 May 2005 12:44:18 -0400 (EDT) From: pat_thaler@agilent.com Received: from msgbas9x.lvld.agilent.com ([192.25.144.41]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaGKO-000303-Qd for ips@ietf.org; Mon, 23 May 2005 13:02:58 -0400 Received: from relcos1.cos.agilent.com (relcos1.cos.agilent.com [130.29.152.239]) by msgbas9x.lvld.agilent.com (Postfix) with ESMTP id C647429A5 for ; Mon, 23 May 2005 10:44:09 -0600 (MDT) Received: from wcosvs03.cos.agilent.com (wcosvs03.cos.agilent.com [130.29.152.233]) by relcos1.cos.agilent.com (Postfix) with ESMTP id 8FAFDA65 for ; Mon, 23 May 2005 10:44:09 -0600 (MDT) Received: from wcosbh02.cos.agilent.com ([130.29.152.126]) by wcosvs03.cos.agilent.com with InterScan Messaging Security Suite; Mon, 23 May 2005 10:44:08 -0600 Received: from wcosmb05.cos.agilent.com ([130.29.152.72]) by wcosbh02.cos.agilent.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 23 May 2005 10:44:08 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ips]Invalid key Date: Mon, 23 May 2005 10:44:08 -0600 Message-ID: <9418406DEC3B8A4BBDB1B87291D851AF014EBC6B@wcosmb05.cos.agilent.com> Thread-Topic: [Ips]Invalid key Thread-Index: AcVdXeU3uWnV97jaRkCtdArH5dPg8gAVSZ2Q To: , X-OriginalArrivalTime: 23 May 2005 16:44:08.0678 (UTC) FILETIME=[A3CDB060:01C55FB6] X-Spam-Score: 0.3 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: quoted-printable Cc: ips@ietf.org, senthilsn@npd.hcltech.com X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org I agree. A normal occurance of NotUnderstood would be an initiator or = target that offers a private or public extension key or a key from a = later standard that the other side doesn't understand. The offering = device often will be willing to continue to complete the connection = without the key. If the offering device isn't, then it can close the = connection. Pat -----Original Message----- From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org]On Behalf Of Mike Ko Sent: Friday, 20 May, 2005 9:58 AM To: William Studenmund Cc: ips@ietf.org; sundara senthil Subject: Re: [Ips]Invalid key I wouldn't jump to the conclusion that if a key is NotUnderstood, that = the=20 recommended course of action is to close the connection. In iSER (iSCSI = Extensions for RDMA), the initiator (or target) offers the key=20 RDMAExtensions to determine if the target (or initiator) can operate in=20 iSER mode. If the response is NotUnderstood, then the connection = remains=20 in iSCSI mode. This is not a protocol error and closing the connection = in=20 this case would be inappropriate. Mike Sent by: ips-bounces@ietf.org To: "sundara senthil" cc: ips@ietf.org=20 Subject: Re: [Ips]Invalid key On May 19, 2005, at 4:56 AM, sundara senthil wrote: > Hi All, > > According to the iscsi RFC 3720, mentioned in the section 5.2 > > "Any key not understood by the acceptor may be ignored by the > acceptor without affecting the basic function. However, the answer > for a key not understood MUST be key=3DNotUnderstood." > > I would like to know that if initiator sends any invalid key name and > a value > pair to the iscsi target, should the target ignore the key pair > without responding or target should respond as invalid > key=3DNotUnderstood. The acceptor (the target could have made the initial offer, after all) must reply "invalid_key-NotUnderstood". Note however that we are assuming the unknown key came with some sort of conceivably reasonable initial offer. If the initial offer were something like "Reject", "Irrelevant", or "NotUnderstood", then there is a protocol error. I'd recommend closing the connection. Take care, Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Mon May 23 18:46:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaLgY-0002HX-P7; Mon, 23 May 2005 18:46:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaLgX-0002HN-7G for ips@megatron.ietf.org; Mon, 23 May 2005 18:46:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08088 for ; Mon, 23 May 2005 18:46:06 -0400 (EDT) Received: from mononoke.wasabisystems.com ([66.173.145.228]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaLyZ-0007Ix-6m for ips@ietf.org; Mon, 23 May 2005 19:04:49 -0400 Received: from [10.0.0.10] (h-66-166-188-91.sndacagl.covad.net [66.166.188.91]) by mononoke.wasabisystems.com (Postfix) with ESMTP id 8378387087; Mon, 23 May 2005 18:45:51 -0400 (EDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v622) Message-Id: From: William Studenmund Subject: Re: [Ips] Authentication in a discovery session Date: Mon, 23 May 2005 15:45:41 -0700 To: Julian Satran X-Pgp-Agent: GPGMail 1.0 (v30, 10.3) X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: ips@ietf.org, Eddy Quicksall X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1195733998==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org --===============1195733998== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-1--1005295410" Content-Transfer-Encoding: 7bit --Apple-Mail-1--1005295410 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On May 21, 2005, at 3:35 PM, Julian Satran wrote: > I think that this answer summarizes the options available pretty well. > I wonder however if it not be wise for the target portal to hide some=20= > of the targets behind it based on the supplied initiator name (similar=20= > of the target ability to hide LUs =A0based on the initiator name = during=20 > a normal session). Oh, heh, I thought we were already supposed to do that. :-) We only announce a target over SendTargets discovery if it is=20 conceivable that an initiator can log into it. So say a portal exports=20= three nodes, A, B, and C. Further let there be a node D that isn't=20 exported via this portal (no node-portal linkage). Let an initiator J=20 be able to log into A using CHAP and NONE, and B using CHAP. Let it not=20= be authorized to log into C, and let it be authorized to log into D=20 (via a different portal as there is no node-portal linkage to this=20 port). If initiator J tries targetless discovery and either tries to skip=20 security or chooses AuthMethod=3DNONE, we will let it in. In its=20 SendTargets response (assuming All), we will tell it about nodes A, B,=20= and D, with appropriate TargetAddress responses. As initiator J can't=20 log into node C at all, we will not mention it. The initiator could=20 also have completed CHAP using the credential(s) valid for node A or=20 the one(s) for node B. Obviously when initiator J tries to log into node B, it will have to=20 perform CHAP using the right credential(s). Does this seem unreasonable to anyone? Take care, Bill= --Apple-Mail-1--1005295410 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFCkl0cDJT2Egh26K0RApfJAKCLlPsZ9XTtKzT0rPZGehh9ryY0pACZASPO xObnliSa7CLvjBAkbP9qBkE= =Cecf -----END PGP SIGNATURE----- --Apple-Mail-1--1005295410-- --===============1195733998== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============1195733998==-- From ips-bounces@ietf.org Tue May 24 14:57:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaeaT-0007Jp-9f; Tue, 24 May 2005 14:57:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaeaR-0007I2-1j for ips@megatron.ietf.org; Tue, 24 May 2005 14:57:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00987 for ; Tue, 24 May 2005 14:57:05 -0400 (EDT) Received: from rwcrmhc13.comcast.net ([204.127.198.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Daese-0008UF-QN for ips@ietf.org; Tue, 24 May 2005 15:15:58 -0400 Received: from ivvt2dxrc11 (c-66-177-46-174.hsd1.fl.comcast.net[66.177.46.174]) by comcast.net (rwcrmhc13) with SMTP id <2005052418565001500g0pr3e>; Tue, 24 May 2005 18:56:51 +0000 Message-ID: <001e01c56092$58bed400$03031eac@ivivity.com> From: "Eddy Quicksall" To: "William Studenmund" , "Julian Satran" References: Subject: Re: [Ips] Authentication in a discovery session Date: Tue, 24 May 2005 14:56:49 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7bit Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org Sounds like a good plan. Eddy ----- Original Message ----- From: "William Studenmund" To: "Julian Satran" Cc: ; "Eddy Quicksall" Sent: Monday, May 23, 2005 6:45 PM Subject: Re: [Ips] Authentication in a discovery session On May 21, 2005, at 3:35 PM, Julian Satran wrote: > I think that this answer summarizes the options available pretty well. > I wonder however if it not be wise for the target portal to hide some > of the targets behind it based on the supplied initiator name (similar > of the target ability to hide LUs based on the initiator name during > a normal session). Oh, heh, I thought we were already supposed to do that. :-) We only announce a target over SendTargets discovery if it is conceivable that an initiator can log into it. So say a portal exports three nodes, A, B, and C. Further let there be a node D that isn't exported via this portal (no node-portal linkage). Let an initiator J be able to log into A using CHAP and NONE, and B using CHAP. Let it not be authorized to log into C, and let it be authorized to log into D (via a different portal as there is no node-portal linkage to this port). If initiator J tries targetless discovery and either tries to skip security or chooses AuthMethod=NONE, we will let it in. In its SendTargets response (assuming All), we will tell it about nodes A, B, and D, with appropriate TargetAddress responses. As initiator J can't log into node C at all, we will not mention it. The initiator could also have completed CHAP using the credential(s) valid for node A or the one(s) for node B. Obviously when initiator J tries to log into node B, it will have to perform CHAP using the right credential(s). Does this seem unreasonable to anyone? Take care, Bill > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Mon May 30 04:13:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcfMj-0000F4-NC; Mon, 30 May 2005 04:11:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcfMh-0000Ew-EY for ips@megatron.ietf.org; Mon, 30 May 2005 04:11:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26503 for ; Mon, 30 May 2005 04:11:13 -0400 (EDT) Received: from calsoftinc.com ([64.62.215.98]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Dcfg3-0003FA-1W for ips@ietf.org; Mon, 30 May 2005 04:31:16 -0400 Received: from screech ([220.225.34.78]) by calsoftinc.com for ; Mon, 30 May 2005 01:11:02 -0700 Message-ID: <00be01c56425$e461f640$5f0010ac@screech> From: "Faraz Ahmed" To: , References: Date: Sun, 29 May 2005 01:10:28 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.0 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Cc: ips@ietf.org, linux-iscsi-devel@lists.sourceforge.net Subject: [Ips] Perfect Hashing for All 23 iSCSI Text Keys X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org Hi all; I dont know whether this should be discussed here. As part of implementing a iSCSI target, we often need to search for a particular Text key. Here i have discovered a hashing fucntion which perfectly hashes all the 23 iSCSI text key. The Bernsteins Hash Function wiht the MAGIC value of 34043539 hashes all the keys perfectly. #define FARAZ_HASH_VAL 34043539 #define PR_COL 0 #define IDX_COL 1 char __key_hash[MAX_KEYS][2]; /* * Berstein Hash Fucntion for strings. Hashes all the keys uniquely */ inline int __djb2_hash(char *str_orig) { unsigned long hash = FARAZ_HASH_VAL; char *str = str_orig; int c; while ((c=*str++)!='\0') hash = ((hash << 5) + hash) + c; /* hash * 33 + c */ iSCSIDEBUGINFO("__djb2_hash(%s)=%d",str_orig,(int)hash%MAX_KEYS); return hash%MAX_KEYS; } _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Tue May 31 19:24:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdG5m-00077j-0d; Tue, 31 May 2005 19:24:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdG5k-00077e-4B for ips@megatron.ietf.org; Tue, 31 May 2005 19:24:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09842 for ; Tue, 31 May 2005 19:24:07 -0400 (EDT) Received: from atlrel8.hp.com ([156.153.255.206]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdGP6-0004ZK-1L for ips@ietf.org; Tue, 31 May 2005 19:44:32 -0400 Received: from rosemail.rose.hp.com (rosemail.rose.hp.com [15.43.209.160]) by atlrel8.hp.com (Postfix) with ESMTP id AEB734830 for ; Tue, 31 May 2005 19:23:48 -0400 (EDT) Received: from [127.0.0.1] (unknown [16.93.44.11]) by rosemail.rose.hp.com (Postfix) with ESMTP id 4BB58808D for ; Tue, 31 May 2005 16:19:34 -0700 (PDT) Message-ID: <429CF206.8060001@rose.hp.com> Date: Tue, 31 May 2005 16:23:50 -0700 From: "Mallikarjun C." User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ips@ietf.org Subject: Re: [Ips] ABORT TASK vs ABORT TASK SET References: <000801c55083$32f43450$6601a8c0@corp.silverbacksystems.com> <427C0BAB.3080006@rose.hp.com> In-Reply-To: <427C0BAB.3080006@rose.hp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Content-Transfer-Encoding: 7bit X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org Responding to my own comment (since I seem to have done such a fine job of "aborting" this email thread)..... > I think it'd be a good idea to elaborate on LU Reset, and the two > flavors of Target Reset in a formal IETF doc. I am concerned that the current lack of detailed specification would allow targets that might even cause silent data corruptions to qualify as RFC 3720-compliant. Here are what I believe to be semantics applicable to all TMF requests that can potentially terminate multiple tasks. I do not know the IETF process well enough here, but I suggest that we consider this text replacing the existing section 10.6.2 in RFC 3720 - so the new text can cover all the TMFs that can impact multiple tasks. This is basically a superset of the current 10.6.2 semantics. Comments are welcome. Mallikarjun ----------------------------------------------------------------------- 10.6.2. Task Management Actions on Requests Affecting Multiple Tasks The execution of ABORT TASK SET, CLEAR TASK SET, LOGICAL UNIT RESET, TARGET WARM RESET, and TARGET COLD RESET Task Management function requests consists of the following sequence of actions in the specified order on each of the entities. The initiator: a) Issues ABORT TASK SET/CLEAR TASK SET/LOGICAL UNIT RESET/TARGET WARM RESET/TARGET COLD RESET request. b) Continues to respond to each target transfer tag received for the "affected" (*) tasks. c) Receives any responses that the target may provide for some tasks among the affected tasks (may process them as usual because they are guaranteed to be valid). d) Receives the task management response, thus concluding all the tasks in the set of affected tasks. The Target: a) Receives the ABORT TASK SET/CLEAR TASK SET/LOGICAL UNIT RESET/TARGET WARM RESET/TARGET COLD RESET request. b) Waits for all currently valid target transfer tags of the affected tasks to be responded. c) Based on the CmdSN ordering, waits (concurrent with the wait in step (b)) for all commands of the affected tasks to be received. In the case of target-scoped requests (i.e. TARGET WARM RESET and TARGET COLD RESET), all the commands that are not received, as at the end of step (b), in the command stream however can be considered to have been received with no command waiting period - i.e. the entire CmdSN space upto the CmdSN of the task management function can be "plugged" (refer section 6.9 on how aborting a specific task can implicitly plug the CmdSN of the task being aborted) at the end of step (b). d) Propagates the TMF request to and receives the response from the target SCSI layer. e) Takes note of last-sent StatSN on each of the connections in the iSCSI session(s) (one or more) sharing the affected tasks, and waits for acknowledgement of each StatSN (may solicit for acknowledgement by way of a NOP-In). If some tasks originate from non-iSCSI I_T_L nexi then the means by which the target insures that all affected tasks have returned their status to the initiator are defined by the specific non-iSCSI transport protocol(s). f) Sends the task set management response to the issuing initiator. [*] "affected" tasks: ABORT TASK SET: All outstanding tasks for the I_T_L nexus identified by the LUN field in the ABORT TASK SET task management function. CLEAR TASK SET: All outstanding tasks in the task set for the LU identified by the LUN field in the CLEAR TASK SET task management function. LOGICAL UNIT RESET: All outstanding tasks from all initiators for the LU identified by the LUN field in the LOGICAL UNIT RESET task management function. TARGET WARM RESET/TARGET COLD RESET: All outstanding tasks from all initiators across all LUs that the issuing session has access to on the SCSI target device hosting the iSCSI session. _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips