From ips-bounces@ietf.org Tue Mar 1 09:39:23 2005 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 JAA29855 for ; Tue, 1 Mar 2005 09:39:23 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D68Xx-0004nW-72 for ips-web-archive@ietf.org; Tue, 01 Mar 2005 09:40:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D68Vf-0005y4-U0; Tue, 01 Mar 2005 09:38:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D68Vf-0005xz-5b for ips@megatron.ietf.org; Tue, 01 Mar 2005 09:38:03 -0500 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 JAA29769 for ; Tue, 1 Mar 2005 09:38:01 -0500 (EST) Received: from rwcrmhc12.comcast.net ([216.148.227.85]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D68Wc-0004lX-6M for ips@ietf.org; Tue, 01 Mar 2005 09:39:03 -0500 Received: from ivvt2dxrc11 (c-66-177-46-174.se.client2.attbi.com[66.177.46.174]) by comcast.net (rwcrmhc12) with SMTP id <2005030114375201400hllsne>; Tue, 1 Mar 2005 14:37:52 +0000 Message-ID: <000901c51e6c$3fd349c0$0303a8c0@ivivity.com> From: "Eddy Quicksall" To: Date: Tue, 1 Mar 2005 09:37:51 -0500 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.2 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Subject: [Ips] iSCSI: accepting redirection 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="===============1059749278==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 This is a multi-part message in MIME format. --===============1059749278== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C51E42.563FBE20" This is a multi-part message in MIME format. ------=_NextPart_000_0006_01C51E42.563FBE20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 10.13.5. A redirection SHOULD be accepted by an initiator even without having the target complete a security negotiation if any security negotiation is required, and MUST be accepted by the initiator after the completion of the security negotiation if any security negotiation is required. If a security negotiation is required, isn't it dangerous to accept a = redirection before security negotiation is complete? Eddy ------=_NextPart_000_0006_01C51E42.563FBE20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

10.13.5.

A redirection SHOULD be

accepted by an initiator even without having the=20 target

complete a security negotiation if any security = negotiation=20 is

required, and MUST be accepted by the initiator = after=20 the

completion of the security negotiation if any=20 security

negotiation is required.

If a security negotiation is required, isn't it dangerous to = accept a=20 redirection before security negotiation is complete?

Eddy

------=_NextPart_000_0006_01C51E42.563FBE20-- --===============1059749278== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============1059749278==-- From ips-bounces@ietf.org Wed Mar 2 10:29:20 2005 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 KAA22662 for ; Wed, 2 Mar 2005 10:29:19 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6Vo2-00038O-Kt for ips-web-archive@ietf.org; Wed, 02 Mar 2005 10:30:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6Vjr-0008Rv-Cw; Wed, 02 Mar 2005 10:26:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6Vjp-0008Rp-Oe for ips@megatron.ietf.org; Wed, 02 Mar 2005 10:26:13 -0500 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 KAA22329 for ; Wed, 2 Mar 2005 10:26:11 -0500 (EST) Received: from rwcrmhc13.comcast.net ([204.127.198.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6Vl0-000315-0n for ips@ietf.org; Wed, 02 Mar 2005 10:27:27 -0500 Received: from ivvt2dxrc11 (c-66-177-46-174.se.client2.attbi.com[66.177.46.174]) by comcast.net (rwcrmhc13) with SMTP id <2005030215255501500l03d5e>; Wed, 2 Mar 2005 15:25:55 +0000 Message-ID: <000c01c51f3c$207b56a0$0303a8c0@ivivity.com> From: "Eddy Quicksall" To: Date: Wed, 2 Mar 2005 10:25:53 -0500 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.2 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Subject: [Ips] iSCSI: redirection of 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="===============1077303725==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b This is a multi-part message in MIME format. --===============1077303725== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C51F12.36C798D0" This is a multi-part message in MIME format. ------=_NextPart_000_0009_01C51F12.36C798D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 1 - Redirection - indicates that the initiator must take further action to complete the request. This is usually due to the target moving to a different address. All of the redirection status class responses MUST return one or more text key parameters of the type "TargetAddress", which indicates the target's new address.=20 Does this mean that a discovery session can't be redirected? Eddy ------=_NextPart_000_0009_01C51F12.36C798D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

1 - = Redirection=20 - indicates that the initiator must take further

=20 action to complete the request. =20 This is usually due to the

=20 target moving to a different address. All of the=20 redirection

=20 status class responses MUST return one or more text=20 key

=20 parameters of the type "TargetAddress", which indicates=20 the

=20 target's new address.

Does=20 this mean that a discovery session can't be = redirected?

Eddy

------=_NextPart_000_0009_01C51F12.36C798D0-- --===============1077303725== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============1077303725==-- From ips-bounces@ietf.org Wed Mar 2 17:13:12 2005 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 RAA03970 for ; Wed, 2 Mar 2005 17:13:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6c6x-0004nX-NY for ips-web-archive@ietf.org; Wed, 02 Mar 2005 17:14:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6c2O-0008Ps-JM; Wed, 02 Mar 2005 17:09:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6c2M-0008Pk-U4 for ips@megatron.ietf.org; Wed, 02 Mar 2005 17:09:46 -0500 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 RAA03622 for ; Wed, 2 Mar 2005 17:09:44 -0500 (EST) 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 1D6c3a-0004h4-OO for ips@ietf.org; Wed, 02 Mar 2005 17:11:03 -0500 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 j22M6r3b015751 for ; Wed, 2 Mar 2005 17:06:53 -0500 (EST) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Wed, 2 Mar 2005 17:06:49 -0500 Message-ID: To: ips@ietf.org Date: Wed, 2 Mar 2005 17:06:49 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain 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: ea4ac80f790299f943f0a53be7e1a21a Subject: [Ips] IPS WG meeting agenda 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 X-Spam-Score: 0.3 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 I seem to be a bit tardy in getting to this. As the WG co-chair who will be running next week's meeting, I currently know of the following drafts that will need time in the IPS WG meeting: DA: draft-ietf-ips-iwarp-da-01.txt Update. iSER: draft-ietf-ips-iser-01.txt Update, some minor technical issues iSER for SCTP, InfiniBand, etc.: draft-hufferd-ips-iser-sctp-ib-00.pdf Significant time required to determine what to do with/about this draft. If there is any other draft that wants/needs meeting time next week, please let me know ASAP. 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 Wed Mar 2 18:43:53 2005 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 SAA12882 for ; Wed, 2 Mar 2005 18:43:53 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6dWk-0006gV-Ug for ips-web-archive@ietf.org; Wed, 02 Mar 2005 18:45:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6dTw-0000ep-9N; Wed, 02 Mar 2005 18:42:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6dTv-0000ef-Kx for ips@megatron.ietf.org; Wed, 02 Mar 2005 18:42:19 -0500 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 SAA12799 for ; Wed, 2 Mar 2005 18:42:15 -0500 (EST) Received: from mx2.netapp.com ([216.240.18.37]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6dV9-0006dt-LL for ips@ietf.org; Wed, 02 Mar 2005 18:43:37 -0500 Received: from smtp2.corp.netapp.com (10.57.159.114) by mx2.netapp.com with ESMTP; 02 Mar 2005 15:42:08 -0800 X-IronPort-AV: i="3.90,131,1107763200"; d="scan'208"; a="172646896:sNHT15498296" Received: from [10.58.52.99] ([10.58.52.99]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id j22Ng81U026371; Wed, 2 Mar 2005 15:42:08 -0800 (PST) Message-ID: <42264F4F.40809@netapp.com> Date: Wed, 02 Mar 2005 15:42:07 -0800 From: Dave Wysochanski User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ips@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Cc: iana@iana.org Subject: [Ips] RFC 3720 Public Extension Keys questions 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit Can someone point me at the current list of IANA registered strings for the X# keys as described in section 12.22 of the iSCSI RFC? Is the list under the "iSCSI extended key" heading here (in which case there are none defined): http://www.iana.org/assignments/iscsi-parameters I'd also like to know what the procedure is for registering a new string for a currently undefined Public Extension Key. Do I use the "General Request for Assignments": http://www.iana.org/cgi-bin/assignments.pl Thanks. http://www.faqs.org/rfcs/rfc3720.html 12.22. The Private or Public Extension Key Format Use: ALL Senders: Initiator and Target Scope: specific key dependent X-reversed.vendor.dns_name.do_something= or X<#>= Keys with this format are used for public or private extension purposes. These keys always start with X- if unregistered with IANA (private) or X# if registered with IANA (public). For unregistered keys, to identify the vendor, we suggest you use the reversed DNS-name as a prefix to the key-proper. The part of key-name following X- and X# MUST conform to the format for key-name specified in Section 5.1 Text Format. For IANA registered keys the string following X# must be registered with IANA and the use of the key MUST be described by an informational RFC. _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Wed Mar 2 19:14:14 2005 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 TAA15313 for ; Wed, 2 Mar 2005 19:14:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6e06-0007MF-KW for ips-web-archive@ietf.org; Wed, 02 Mar 2005 19:15:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6dtK-0006Ij-Up; Wed, 02 Mar 2005 19:08:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6dtK-0006Ie-7M for ips@megatron.ietf.org; Wed, 02 Mar 2005 19:08:34 -0500 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 TAA14822 for ; Wed, 2 Mar 2005 19:08:30 -0500 (EST) 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 1D6duX-0007D8-01 for ips@ietf.org; Wed, 02 Mar 2005 19:09:52 -0500 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 j2308QUh026312; Wed, 2 Mar 2005 19:08:26 -0500 (EST) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Wed, 2 Mar 2005 19:08:22 -0500 Message-ID: To: davidw@netapp.com, ips@ietf.org Subject: RE: [Ips] RFC 3720 Public Extension Keys questions Date: Wed, 2 Mar 2005 19:08:22 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain 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: 8abaac9e10c826e8252866cbe6766464 Cc: iana@iana.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 X-Spam-Score: 0.3 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Dave, > Can someone point me at the current list of IANA registered strings > for the X# keys as described in section 12.22 of the iSCSI RFC? > Is the list under the "iSCSI extended key" heading here (in which case > there are none defined): > http://www.iana.org/assignments/iscsi-parameters Yes; it's currently empty. > I'd also like to know what the procedure is for registering a new string > for a currently undefined Public Extension Key. Do I use the "General > Request for Assignments": > http://www.iana.org/cgi-bin/assignments.pl That should work, or send email to IANA, but an RFC is a necessary prerequisite: "For IANA registered keys the string following X# must be registered with IANA and the use of the key MUST be described by an informational RFC." I strongly suggest that any draft intended to become such an RFC be brought to the attention of the IPS WG prior to any request for publication as an RFC. 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 Sat Mar 5 11:54:21 2005 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 LAA29168 for ; Sat, 5 Mar 2005 11:54:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7cZc-0006sC-FU for ips-web-archive@ietf.org; Sat, 05 Mar 2005 11:56:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7cUn-0007Cq-3Q; Sat, 05 Mar 2005 11:51:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7cUk-0007Cc-T2 for ips@megatron.ietf.org; Sat, 05 Mar 2005 11:51:15 -0500 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 LAA28979 for ; Sat, 5 Mar 2005 11:51:12 -0500 (EST) Received: from leviathan.ele.uri.edu ([131.128.51.64]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7cWY-0006oS-5j for ips@ietf.org; Sat, 05 Mar 2005 11:53:07 -0500 Received: from [127.0.0.1] (leviathan [131.128.51.64]) by leviathan.ele.uri.edu (8.12.9/8.12.9) with ESMTP id j25Gp7Cu004345 for ; Sat, 5 Mar 2005 11:51:07 -0500 (EST) From: Ming Zhang To: ips@ietf.org Content-Type: text/plain Message-Id: <1110041467.2937.24.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Sat, 05 Mar 2005 11:51:07 -0500 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Subject: [Ips] LUN or reserved in R2T? X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mingz@ele.uri.edu List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit In R2T, shall the LUN field have actual LUN value or can be reserved? I knew this is asked before. but the archival i can find is http://www.pdl.cmu.edu/mailinglists/ips/mail/msg09192.html, which is in 2002, pretty old. And there is no formal description on this field in 10.8. Thanks. Ming _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Sat Mar 5 18:53:28 2005 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 SAA28979 for ; Sat, 5 Mar 2005 18:53:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7j7H-0007Jh-DI for ips-web-archive@ietf.org; Sat, 05 Mar 2005 18:55:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7j2v-00067W-Ms; Sat, 05 Mar 2005 18:50:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7j2u-00067O-BO for ips@megatron.ietf.org; Sat, 05 Mar 2005 18:50:56 -0500 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 SAA28850 for ; Sat, 5 Mar 2005 18:50:53 -0500 (EST) Received: from rwcrmhc13.comcast.net ([204.127.198.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7j4l-0007GA-Al for ips@ietf.org; Sat, 05 Mar 2005 18:52:52 -0500 Received: from ivvt2dxrc11 (c-66-177-46-174.se.client2.attbi.com[66.177.46.174]) by comcast.net (rwcrmhc13) with SMTP id <200503052350450150040f4de>; Sat, 5 Mar 2005 23:50:45 +0000 Message-ID: <000301c521de$2649bc30$0303a8c0@ivivity.com> From: "Eddy Quicksall" To: , References: <1110041467.2937.24.camel@localhost.localdomain> Subject: Re: [Ips] LUN or reserved in R2T? Date: Sat, 5 Mar 2005 18:50:44 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; 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: b19722fc8d3865b147c75ae2495625f2 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 X-Spam-Score: 0.1 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit It is up to the target: The Target Transfer Tag and LUN are copied in the outgoing data PDUs and are only used by the target. Eddy ----- Original Message ----- From: "Ming Zhang" To: Sent: Saturday, March 05, 2005 11:51 AM Subject: [Ips] LUN or reserved in R2T? > In R2T, shall the LUN field have actual LUN value or can be reserved? > > I knew this is asked before. but the archival i can find is > http://www.pdl.cmu.edu/mailinglists/ips/mail/msg09192.html, which is in > 2002, pretty old. And there is no formal description on this field in > 10.8. > > Thanks. > > Ming > > > > _______________________________________________ > 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 Mar 5 19:12:30 2005 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 TAA29915 for ; Sat, 5 Mar 2005 19:12:30 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7jPf-0007fl-4f for ips-web-archive@ietf.org; Sat, 05 Mar 2005 19:14:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7jMn-0008Ht-Fl; Sat, 05 Mar 2005 19:11:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7jMl-0008GT-Rf for ips@megatron.ietf.org; Sat, 05 Mar 2005 19:11:28 -0500 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 TAA29867 for ; Sat, 5 Mar 2005 19:11:24 -0500 (EST) Received: from rwcrmhc12.comcast.net ([216.148.227.85]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7jOc-0007eg-OZ for ips@ietf.org; Sat, 05 Mar 2005 19:13:24 -0500 Received: from ivvt2dxrc11 (c-66-177-46-174.se.client2.attbi.com[66.177.46.174]) by comcast.net (rwcrmhc12) with SMTP id <2005030600111601400jibf1e>; Sun, 6 Mar 2005 00:11:17 +0000 Message-ID: <000701c521e1$0426d860$0303a8c0@ivivity.com> From: "Eddy Quicksall" To: , References: <1110041467.2937.24.camel@localhost.localdomain> Subject: Re: [Ips] LUN or reserved in R2T? Date: Sat, 5 Mar 2005 19:11:15 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; 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: 8abaac9e10c826e8252866cbe6766464 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 X-Spam-Score: 0.1 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit I see the confusion because the LUN in the R2T is only used by the target so that says the initiator must only copy it and not use it. But the data out which was solicited by the R2T must have a valid LUN. So, the best thing is to make sure the LUN is valid when you send the R2T. Eddy ----- Original Message ----- From: "Ming Zhang" To: Sent: Saturday, March 05, 2005 11:51 AM Subject: [Ips] LUN or reserved in R2T? > In R2T, shall the LUN field have actual LUN value or can be reserved? > > I knew this is asked before. but the archival i can find is > http://www.pdl.cmu.edu/mailinglists/ips/mail/msg09192.html, which is in > 2002, pretty old. And there is no formal description on this field in > 10.8. > > Thanks. > > Ming > > > > _______________________________________________ > 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 Mar 5 19:20:58 2005 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 TAA00635 for ; Sat, 5 Mar 2005 19:20:58 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7jXu-0007sz-8V for ips-web-archive@ietf.org; Sat, 05 Mar 2005 19:22:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7jTq-0000pZ-55; Sat, 05 Mar 2005 19:18:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7jTo-0000pU-B8 for ips@megatron.ietf.org; Sat, 05 Mar 2005 19:18:44 -0500 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 TAA00396 for ; Sat, 5 Mar 2005 19:18:41 -0500 (EST) Received: from rwcrmhc11.comcast.net ([204.127.198.35]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7jVf-0007p7-G4 for ips@ietf.org; Sat, 05 Mar 2005 19:20:40 -0500 Received: from ivvt2dxrc11 (unknown[66.177.46.174]) by comcast.net (rwcrmhc11) with SMTP id <2005030600183301300ofvp3e>; Sun, 6 Mar 2005 00:18:33 +0000 Message-ID: <001f01c521e2$08757c90$0303a8c0@ivivity.com> From: "Eddy Quicksall" To: "Julian Satran" , Subject: Fw: [Ips] iSCSI: redirection of a discovery session Date: Sat, 5 Mar 2005 19:16:05 -0500 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.1 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a 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="===============0337547463==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 This is a multi-part message in MIME format. --===============0337547463== Content-Type: multipart/alternative; boundary="----=_NextPart_000_001C_01C521B7.C7461D80" This is a multi-part message in MIME format. ------=_NextPart_000_001C_01C521B7.C7461D80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I think this is true, but can you please confirm my understanding? Eddy ----- Original Message -----=20 From: Eddy Quicksall=20 To: ips@ietf.org=20 Sent: Wednesday, March 02, 2005 10:25 AM Subject: [Ips] iSCSI: redirection of a discovery session 1 - Redirection - indicates that the initiator must take further action to complete the request. This is usually due to the target moving to a different address. All of the redirection status class responses MUST return one or more text key parameters of the type "TargetAddress", which indicates the target's new address.=20 Does this mean that a discovery session can't be redirected? Eddy -------------------------------------------------------------------------= ------- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips ------=_NextPart_000_001C_01C521B7.C7461D80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I think this is true, but can you please = confirm my=20 understanding?

Eddy

----- Original Message -----=20

From: Eddy = Quicksall

To: ips@ietf.org

Sent: Wednesday, March 02, 2005 10:25 AM

Subject: [Ips] iSCSI: redirection of a discovery = session

1 - = Redirection=20 - indicates that the initiator must take further

=20 action to complete the request. =20 This is usually due to the

=20 target moving to a different address. All of the=20 redirection

=20 status class responses MUST return one or more text=20 key

=20 parameters of the type "TargetAddress", which indicates=20 the

=20 target's new address.

Does=20 this mean that a discovery session can't be = redirected?

Eddy

_______________________________________________
Ips mailing=20 list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips
------=_NextPart_000_001C_01C521B7.C7461D80-- --===============0337547463== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0337547463==-- From ips-bounces@ietf.org Sat Mar 5 22:37:03 2005 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 WAA11306 for ; Sat, 5 Mar 2005 22:37:02 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7mbe-00034w-Bb for ips-web-archive@ietf.org; Sat, 05 Mar 2005 22:39:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7mWU-0001GG-Ei; Sat, 05 Mar 2005 22:33:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7mWT-0001GB-OL for ips@megatron.ietf.org; Sat, 05 Mar 2005 22:33:41 -0500 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 WAA11126 for ; Sat, 5 Mar 2005 22:33:39 -0500 (EST) Received: from leviathan.ele.uri.edu ([131.128.51.64]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7mYM-00030N-PG for ips@ietf.org; Sat, 05 Mar 2005 22:35:40 -0500 Received: from [127.0.0.1] (leviathan [131.128.51.64]) by leviathan.ele.uri.edu (8.12.9/8.12.9) with ESMTP id j263XaCu019492; Sat, 5 Mar 2005 22:33:36 -0500 (EST) Subject: Re: [Ips] LUN or reserved in R2T? From: Ming Zhang To: Eddy Quicksall In-Reply-To: <000701c521e1$0426d860$0303a8c0@ivivity.com> References: <1110041467.2937.24.camel@localhost.localdomain> <000701c521e1$0426d860$0303a8c0@ivivity.com> Content-Type: text/plain Message-Id: <1110080015.2937.54.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Sat, 05 Mar 2005 22:33:35 -0500 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mingz@ele.uri.edu List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit On Sat, 2005-03-05 at 19:11, Eddy Quicksall wrote: > I see the confusion because the LUN in the R2T is only used by the target so > that says the initiator must only copy it and not use it. But the data out > which was solicited by the R2T must have a valid LUN. > > So, the best thing is to make sure the LUN is valid when you send the R2T. yes, this is the best thing. but can we safely say this? 1) initiator should not check the validity of LUN field and should simply copy it to data out packet 2) if target wants to check the validity of lun field in data out packet, then target should supply a valid lun field in r2t packet? ming > > Eddy > ----- Original Message ----- > From: "Ming Zhang" > To: > Sent: Saturday, March 05, 2005 11:51 AM > Subject: [Ips] LUN or reserved in R2T? > > > > In R2T, shall the LUN field have actual LUN value or can be reserved? > > > > I knew this is asked before. but the archival i can find is > > http://www.pdl.cmu.edu/mailinglists/ips/mail/msg09192.html, which is in > > 2002, pretty old. And there is no formal description on this field in > > 10.8. > > > > Thanks. > > > > Ming > > > > > > > > _______________________________________________ > > 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 Mar 5 22:38:29 2005 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 WAA11404 for ; Sat, 5 Mar 2005 22:38:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7md2-00037W-Dj for ips-web-archive@ietf.org; Sat, 05 Mar 2005 22:40:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7mYR-0001S9-AI; Sat, 05 Mar 2005 22:35:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7mYL-0001Ov-ES for ips@megatron.ietf.org; Sat, 05 Mar 2005 22:35:41 -0500 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 WAA11219 for ; Sat, 5 Mar 2005 22:35:35 -0500 (EST) Received: from leviathan.ele.uri.edu ([131.128.51.64]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7maF-00033E-Gq for ips@ietf.org; Sat, 05 Mar 2005 22:37:35 -0500 Received: from [127.0.0.1] (leviathan [131.128.51.64]) by leviathan.ele.uri.edu (8.12.9/8.12.9) with ESMTP id j263ZWCu019535; Sat, 5 Mar 2005 22:35:33 -0500 (EST) Subject: Re: [Ips] LUN or reserved in R2T? From: Ming Zhang To: Eddy Quicksall In-Reply-To: <000301c521de$2649bc30$0303a8c0@ivivity.com> References: <1110041467.2937.24.camel@localhost.localdomain> <000301c521de$2649bc30$0303a8c0@ivivity.com> Content-Type: text/plain Message-Id: <1110080132.2937.57.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Sat, 05 Mar 2005 22:35:32 -0500 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mingz@ele.uri.edu List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit On Sat, 2005-03-05 at 18:50, Eddy Quicksall wrote: > It is up to the target: > > The Target Transfer Tag and LUN are copied in > > the outgoing data PDUs and are only used by the target. see my another email, if this is only used by the target, then initiator should never check this? ming > > > > Eddy > ----- Original Message ----- > From: "Ming Zhang" > To: > Sent: Saturday, March 05, 2005 11:51 AM > Subject: [Ips] LUN or reserved in R2T? > > > > In R2T, shall the LUN field have actual LUN value or can be reserved? > > > > I knew this is asked before. but the archival i can find is > > http://www.pdl.cmu.edu/mailinglists/ips/mail/msg09192.html, which is in > > 2002, pretty old. And there is no formal description on this field in > > 10.8. > > > > Thanks. > > > > Ming > > > > > > > > _______________________________________________ > > 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 Sun Mar 6 03:16:10 2005 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 DAA17743 for ; Sun, 6 Mar 2005 03:16:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7qxo-0008Lz-S7 for ips-web-archive@ietf.org; Sun, 06 Mar 2005 03:18:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7quV-0006do-4C; Sun, 06 Mar 2005 03:14:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7quL-0006cI-KA for ips@megatron.ietf.org; Sun, 06 Mar 2005 03:14:38 -0500 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 DAA17637 for ; Sun, 6 Mar 2005 03:14:35 -0500 (EST) Received: from smtp818.mail.sc5.yahoo.com ([66.163.170.4]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D7qwH-0008KO-4S for ips@ietf.org; Sun, 06 Mar 2005 03:16:37 -0500 Received: from unknown (HELO ?192.168.0.102?) (nicholas?bellinger@sbcglobal.net@64.172.181.156 with plain) by smtp818.mail.sc5.yahoo.com with SMTP; 6 Mar 2005 08:14:30 -0000 Subject: Re: [Ips] LUN or reserved in R2T? From: "Nicholas A. Bellinger" To: mingz@ele.uri.edu In-Reply-To: <1110080132.2937.57.camel@localhost.localdomain> References: <1110041467.2937.24.camel@localhost.localdomain> <000301c521de$2649bc30$0303a8c0@ivivity.com> <1110080132.2937.57.camel@localhost.localdomain> Content-Type: text/plain Date: Sun, 06 Mar 2005 00:09:48 -0800 Message-Id: <1110096588.21190.108.camel@haakon> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: 7bit 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 X-Spam-Score: 0.1 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Content-Transfer-Encoding: 7bit Hi Ming!! On Sat, 2005-03-05 at 22:35 -0500, Ming Zhang wrote: > On Sat, 2005-03-05 at 18:50, Eddy Quicksall wrote: > > It is up to the target: > > > > The Target Transfer Tag and LUN are copied in > > > > the outgoing data PDUs and are only used by the target. > see my another email, if this is only used by the target, then initiator > should never check this? > I have used to rule in the iscsi-initiator-core.org initiator stack implementation that the Initiator uses the OS'es SCSI Task LUN inside of the LUN field for DataOUT PDUs in the solicited DataOUT case. This ensures that the LUN from the original PDU containing the SCSI CDB and all DataOUT PDUs contain the same value. Please see iscsi_initiator.c:iscsi_build_data_out() for further details. On the target side, I have observed in the past that certain initiators may not include the correct LUN inside of solicited DataOUT PDUs, and hence cause interopt problems. In the PyX Technologies Target Stack we leave the check against DataOUT PDU's LUN vs. the original ISCSI_INIT_SCSI_CMND pdu's LUN stubbed out in order to ensure interopt with these initiator implementations. Take care, -- Nicholas A. Bellinger Chief Architect, PyX Technologies, Inc. > ming > > > > > > > > > Eddy > > ----- Original Message ----- > > From: "Ming Zhang" > > To: > > Sent: Saturday, March 05, 2005 11:51 AM > > Subject: [Ips] LUN or reserved in R2T? > > > > > > > In R2T, shall the LUN field have actual LUN value or can be reserved? > > > > > > I knew this is asked before. but the archival i can find is > > > http://www.pdl.cmu.edu/mailinglists/ips/mail/msg09192.html, which is in > > > 2002, pretty old. And there is no formal description on this field in > > > 10.8. > > > > > > Thanks. > > > > > > Ming > > > > > > > > > > > > _______________________________________________ > > > 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 -- Nicholas A. Bellinger _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Sun Mar 6 06:14:45 2005 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 GAA27784 for ; Sun, 6 Mar 2005 06:14:45 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7tkg-0007lB-At for ips-web-archive@ietf.org; Sun, 06 Mar 2005 06:16:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7tgZ-0007Ih-Uz; Sun, 06 Mar 2005 06:12:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7tgY-0007IZ-4P for ips@megatron.ietf.org; Sun, 06 Mar 2005 06:12:34 -0500 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 GAA27657 for ; Sun, 6 Mar 2005 06:12:31 -0500 (EST) Received: from mtagate4.de.ibm.com ([195.212.29.153]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7tiV-0007i3-9O for ips@ietf.org; Sun, 06 Mar 2005 06:14:36 -0500 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 j26BCMWM084918 for ; Sun, 6 Mar 2005 11:12:22 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j26BCMje158478 for ; Sun, 6 Mar 2005 12:12:22 +0100 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j26BCMdS009115 for ; Sun, 6 Mar 2005 12:12:22 +0100 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 j26BCMVF009112 for ; Sun, 6 Mar 2005 12:12:22 +0100 To: ips@ietf.org Subject: Re: [Ips] LUN or reserved in R2T? MIME-Version: 1.0 X-Mailer: IBM Lotus Notes Build V70_02012005 February 01, 2005 From: Julian Satran Message-ID: Date: Sun, 6 Mar 2005 06:12:21 -0500 X-MIMETrack: Serialize by Router on D12ML102/12/M/IBM(Release 6.5.1| March 5, 2004) at 06/03/2005 13:12:21, Serialize complete at 06/03/2005 13:12:21 X-Spam-Score: 0.5 (/) X-Scan-Signature: 9361ae25efd9cff62e36f70ef966350e 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="===============0988696777==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: e9051aca6d23a9cf6df09e1ef4738712 This is a multipart message in MIME format. --===============0988696777== Content-Type: multipart/alternative; boundary="=_alternative 003B6EA585256FBC_=" This is a multipart message in MIME format. --=_alternative 003B6EA585256FBC_= Content-Type: text/plain; charset="US-ASCII" LUN should always be correct. Whether an initiator or a target checks them is left to the implementer. The reason the LUN is there in REQ and DataOUT is that the TTT is required to be unique only for a given LU. An implementer using an incorrect LUN invites trouble - especially in case when the target is "composed target" (on which the LUN will be used for routing. Julo ----- Forwarded by Julian Satran/Haifa/IBM on 06/03/2005 05:42 ----- Ming Zhang Sent by: ips-bounces@ietf.org 05/03/2005 22:35 Please respond to mingz@ele.uri.edu To Eddy Quicksall cc ips@ietf.org Subject Re: [Ips] LUN or reserved in R2T? On Sat, 2005-03-05 at 18:50, Eddy Quicksall wrote: > It is up to the target: > > The Target Transfer Tag and LUN are copied in > > the outgoing data PDUs and are only used by the target. see my another email, if this is only used by the target, then initiator should never check this? ming > > > > Eddy > ----- Original Message ----- > From: "Ming Zhang" > To: > Sent: Saturday, March 05, 2005 11:51 AM > Subject: [Ips] LUN or reserved in R2T? > > > > In R2T, shall the LUN field have actual LUN value or can be reserved? > > > > I knew this is asked before. but the archival i can find is > > http://www.pdl.cmu.edu/mailinglists/ips/mail/msg09192.html, which is in > > 2002, pretty old. And there is no formal description on this field in > > 10.8. > > > > Thanks. > > > > Ming > > > > > > > > _______________________________________________ > > 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 ----- Forwarded by Julian Satran/Haifa/IBM on 06/03/2005 05:42 ----- Ming Zhang Sent by: ips-bounces@ietf.org 05/03/2005 22:33 Please respond to mingz@ele.uri.edu To Eddy Quicksall cc ips@ietf.org Subject Re: [Ips] LUN or reserved in R2T? On Sat, 2005-03-05 at 19:11, Eddy Quicksall wrote: > I see the confusion because the LUN in the R2T is only used by the target so > that says the initiator must only copy it and not use it. But the data out > which was solicited by the R2T must have a valid LUN. > > So, the best thing is to make sure the LUN is valid when you send the R2T. yes, this is the best thing. but can we safely say this? 1) initiator should not check the validity of LUN field and should simply copy it to data out packet 2) if target wants to check the validity of lun field in data out packet, then target should supply a valid lun field in r2t packet? ming > > Eddy > ----- Original Message ----- > From: "Ming Zhang" > To: > Sent: Saturday, March 05, 2005 11:51 AM > Subject: [Ips] LUN or reserved in R2T? > > > > In R2T, shall the LUN field have actual LUN value or can be reserved? > > > > I knew this is asked before. but the archival i can find is > > http://www.pdl.cmu.edu/mailinglists/ips/mail/msg09192.html, which is in > > 2002, pretty old. And there is no formal description on this field in > > 10.8. > > > > Thanks. > > > > Ming > > > > > > > > _______________________________________________ > > 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 ----- Forwarded by Julian Satran/Haifa/IBM on 06/03/2005 05:42 ----- "Nicholas A. Bellinger" Sent by: ips-bounces@ietf.org 06/03/2005 03:09 To mingz@ele.uri.edu cc ips@ietf.org, Eddy Quicksall Subject Re: [Ips] LUN or reserved in R2T? Hi Ming!! On Sat, 2005-03-05 at 22:35 -0500, Ming Zhang wrote: > On Sat, 2005-03-05 at 18:50, Eddy Quicksall wrote: > > It is up to the target: > > > > The Target Transfer Tag and LUN are copied in > > > > the outgoing data PDUs and are only used by the target. > see my another email, if this is only used by the target, then initiator > should never check this? > I have used to rule in the iscsi-initiator-core.org initiator stack implementation that the Initiator uses the OS'es SCSI Task LUN inside of the LUN field for DataOUT PDUs in the solicited DataOUT case. This ensures that the LUN from the original PDU containing the SCSI CDB and all DataOUT PDUs contain the same value. Please see iscsi_initiator.c:iscsi_build_data_out() for further details. On the target side, I have observed in the past that certain initiators may not include the correct LUN inside of solicited DataOUT PDUs, and hence cause interopt problems. In the PyX Technologies Target Stack we leave the check against DataOUT PDU's LUN vs. the original ISCSI_INIT_SCSI_CMND pdu's LUN stubbed out in order to ensure interopt with these initiator implementations. Take care, -- Nicholas A. Bellinger Chief Architect, PyX Technologies, Inc. > ming > > > > > > > > > Eddy > > ----- Original Message ----- > > From: "Ming Zhang" > > To: > > Sent: Saturday, March 05, 2005 11:51 AM > > Subject: [Ips] LUN or reserved in R2T? > > > > > > > In R2T, shall the LUN field have actual LUN value or can be reserved? > > > > > > I knew this is asked before. but the archival i can find is > > > http://www.pdl.cmu.edu/mailinglists/ips/mail/msg09192.html, which is in > > > 2002, pretty old. And there is no formal description on this field in > > > 10.8. > > > > > > Thanks. > > > > > > Ming > > > > > > > > > > > > _______________________________________________ > > > 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 -- Nicholas A. Bellinger _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --=_alternative 003B6EA585256FBC_= Content-Type: text/html; charset="US-ASCII"
LUN should always be correct. Whether an initiator or a target checks them is left to the implementer.
The reason the LUN is there in REQ and DataOUT is that the TTT is required to be unique only for a given LU.
An implementer using an incorrect LUN invites trouble - especially in case when the target is "composed target" (on which the LUN will be used for routing.

Julo

----- Forwarded by Julian Satran/Haifa/IBM on 06/03/2005 05:42 -----

Ming Zhang <mingz@ele.uri.edu>
Sent by: ips-bounces@ietf.org

05/03/2005 22:35

Please respond to
mingz@ele.uri.edu

To	Eddy Quicksall <eddy_quicksall_iVivity_iSCSI@comcast.net>
cc	ips@ietf.org
Subject	Re: [Ips] LUN or reserved in R2T?

On Sat, 2005-03-05 at 18:50, Eddy Quicksall wrote: > It is up to the target: > > The Target Transfer Tag and LUN are copied in > > the outgoing data PDUs and are only used by the target. see my another email, if this is only used by the target, then initiator should never check this? ming > > > > Eddy > ----- Original Message ----- > From: "Ming Zhang" <mingz@ele.uri.edu> > To: <ips@ietf.org> > Sent: Saturday, March 05, 2005 11:51 AM > Subject: [Ips] LUN or reserved in R2T? > > > > In R2T, shall the LUN field have actual LUN value or can be reserved? > > > > I knew this is asked before. but the archival i can find is > > http://www.pdl.cmu.edu/mailinglists/ips/mail/msg09192.html, which is in > > 2002, pretty old. And there is no formal description on this field in > > 10.8. > > > > Thanks. > > > > Ming > > > > > > > > _______________________________________________ > > 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
----- Forwarded by Julian Satran/Haifa/IBM on 06/03/2005 05:42 -----

Ming Zhang <mingz@ele.uri.edu>
Sent by: ips-bounces@ietf.org

05/03/2005 22:33

Please respond to
mingz@ele.uri.edu

To	Eddy Quicksall <eddy_quicksall_iVivity_iSCSI@comcast.net>
cc	ips@ietf.org
Subject	Re: [Ips] LUN or reserved in R2T?

On Sat, 2005-03-05 at 19:11, Eddy Quicksall wrote: > I see the confusion because the LUN in the R2T is only used by the target so > that says the initiator must only copy it and not use it. But the data out > which was solicited by the R2T must have a valid LUN. > > So, the best thing is to make sure the LUN is valid when you send the R2T. yes, this is the best thing. but can we safely say this? 1) initiator should not check the validity of LUN field and should simply copy it to data out packet 2) if target wants to check the validity of lun field in data out packet, then target should supply a valid lun field in r2t packet? ming > > Eddy > ----- Original Message ----- > From: "Ming Zhang" <mingz@ele.uri.edu> > To: <ips@ietf.org> > Sent: Saturday, March 05, 2005 11:51 AM > Subject: [Ips] LUN or reserved in R2T? > > > > In R2T, shall the LUN field have actual LUN value or can be reserved? > > > > I knew this is asked before. but the archival i can find is > > http://www.pdl.cmu.edu/mailinglists/ips/mail/msg09192.html, which is in > > 2002, pretty old. And there is no formal description on this field in > > 10.8. > > > > Thanks. > > > > Ming > > > > > > > > _______________________________________________ > > 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
----- Forwarded by Julian Satran/Haifa/IBM on 06/03/2005 05:42 -----

"Nicholas A. Bellinger" <nick@pyxtechnologies.com>
Sent by: ips-bounces@ietf.org

06/03/2005 03:09

To	mingz@ele.uri.edu
cc	ips@ietf.org, Eddy Quicksall <eddy_quicksall_iVivity_iSCSI@comcast.net>
Subject	Re: [Ips] LUN or reserved in R2T?

Hi Ming!! On Sat, 2005-03-05 at 22:35 -0500, Ming Zhang wrote: > On Sat, 2005-03-05 at 18:50, Eddy Quicksall wrote: > > It is up to the target: > > > > The Target Transfer Tag and LUN are copied in > > > > the outgoing data PDUs and are only used by the target. > see my another email, if this is only used by the target, then initiator > should never check this? > I have used to rule in the iscsi-initiator-core.org initiator stack implementation that the Initiator uses the OS'es SCSI Task LUN inside of the LUN field for DataOUT PDUs in the solicited DataOUT case. This ensures that the LUN from the original PDU containing the SCSI CDB and all DataOUT PDUs contain the same value. Please see iscsi_initiator.c:iscsi_build_data_out() for further details. On the target side, I have observed in the past that certain initiators may not include the correct LUN inside of solicited DataOUT PDUs, and hence cause interopt problems. In the PyX Technologies Target Stack we leave the check against DataOUT PDU's LUN vs. the original ISCSI_INIT_SCSI_CMND pdu's LUN stubbed out in order to ensure interopt with these initiator implementations. Take care, -- Nicholas A. Bellinger <nick@pyxtechnologies.com> Chief Architect, PyX Technologies, Inc. > ming > > > > > > > > > Eddy > > ----- Original Message ----- > > From: "Ming Zhang" <mingz@ele.uri.edu> > > To: <ips@ietf.org> > > Sent: Saturday, March 05, 2005 11:51 AM > > Subject: [Ips] LUN or reserved in R2T? > > > > > > > In R2T, shall the LUN field have actual LUN value or can be reserved? > > > > > > I knew this is asked before. but the archival i can find is > > > http://www.pdl.cmu.edu/mailinglists/ips/mail/msg09192.html, which is in > > > 2002, pretty old. And there is no formal description on this field in > > > 10.8. > > > > > > Thanks. > > > > > > Ming > > > > > > > > > > > > _______________________________________________ > > > 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 -- Nicholas A. Bellinger <nick@pyxtechnologies.com> _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --=_alternative 003B6EA585256FBC_=-- --===============0988696777== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0988696777==-- From ips-bounces@ietf.org Sun Mar 6 11:15:50 2005 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 LAA22645 for ; Sun, 6 Mar 2005 11:15:50 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7yS5-0006Ff-Ez for ips-web-archive@ietf.org; Sun, 06 Mar 2005 11:17:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7yOQ-0004tQ-J2; Sun, 06 Mar 2005 11:14:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7yOP-0004tL-46 for ips@megatron.ietf.org; Sun, 06 Mar 2005 11:14:09 -0500 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 LAA22532 for ; Sun, 6 Mar 2005 11:14:06 -0500 (EST) Received: from leviathan.ele.uri.edu ([131.128.51.64]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7yQP-0006Dy-RI for ips@ietf.org; Sun, 06 Mar 2005 11:16:14 -0500 Received: from [127.0.0.1] (leviathan [131.128.51.64]) by leviathan.ele.uri.edu (8.12.9/8.12.9) with ESMTP id j26GE2Cu003854; Sun, 6 Mar 2005 11:14:05 -0500 (EST) Subject: Re: [Ips] LUN or reserved in R2T? From: Ming Zhang To: "Nicholas A. Bellinger" In-Reply-To: <1110096588.21190.108.camel@haakon> References: <1110041467.2937.24.camel@localhost.localdomain> <000301c521de$2649bc30$0303a8c0@ivivity.com> <1110080132.2937.57.camel@localhost.localdomain> <1110096588.21190.108.camel@haakon> Content-Type: text/plain Message-Id: <1110125641.2941.6.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Sun, 06 Mar 2005 11:14:02 -0500 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Content-Transfer-Encoding: 7bit Cc: ips@ietf.org, Eddy Quicksall X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mingz@ele.uri.edu List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Content-Transfer-Encoding: 7bit On Sun, 2005-03-06 at 03:09, Nicholas A. Bellinger wrote: > Hi Ming!! > > On Sat, 2005-03-05 at 22:35 -0500, Ming Zhang wrote: > > On Sat, 2005-03-05 at 18:50, Eddy Quicksall wrote: > > > It is up to the target: > > > > > > The Target Transfer Tag and LUN are copied in > > > > > > the outgoing data PDUs and are only used by the target. > > see my another email, if this is only used by the target, then initiator > > should never check this? > > Thank you, Nicholas, > > I have used to rule in the iscsi-initiator-core.org initiator stack > implementation that the Initiator uses the OS'es SCSI Task LUN inside of > the LUN field for DataOUT PDUs in the solicited DataOUT case. This > ensures that the LUN from the original PDU containing the SCSI CDB and > all DataOUT PDUs contain the same value. Please see > iscsi_initiator.c:iscsi_build_data_out() for further details. > This is to say that you are a good guy. :) But does your initiator check the target R2T packet Lun field? > On the target side, I have observed in the past that certain initiators > may not include the correct LUN inside of solicited DataOUT PDUs, and > hence cause interopt problems. In the PyX Technologies Target Stack we > leave the check against DataOUT PDU's LUN vs. the original > ISCSI_INIT_SCSI_CMND pdu's LUN stubbed out in order to ensure interopt > with these initiator implementations. > This is to say that you allow other guys to do something not so good. :) But the question is, what does the rfc say? and which one strictly follows the standard? I put question completely on the table, we (http://iscsitarget.sourceforge.net/) leave that field reserved in R2T, while open-iscsi(http://www.open-iscsi.org/) checks this field to make sure it is LUN. so... ming > Take care, > > -- > Nicholas A. Bellinger > Chief Architect, PyX Technologies, Inc. > > > ming > > > > > > > > > > > > > > Eddy > > > ----- Original Message ----- > > > From: "Ming Zhang" > > > To: > > > Sent: Saturday, March 05, 2005 11:51 AM > > > Subject: [Ips] LUN or reserved in R2T? > > > > > > > > > > In R2T, shall the LUN field have actual LUN value or can be reserved? > > > > > > > > I knew this is asked before. but the archival i can find is > > > > http://www.pdl.cmu.edu/mailinglists/ips/mail/msg09192.html, which is in > > > > 2002, pretty old. And there is no formal description on this field in > > > > 10.8. > > > > > > > > Thanks. > > > > > > > > Ming > > > > > > > > > > > > > > > > _______________________________________________ > > > > 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 Sun Mar 6 12:34:11 2005 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 MAA01060 for ; Sun, 6 Mar 2005 12:34:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7zfw-0008Lz-5R for ips-web-archive@ietf.org; Sun, 06 Mar 2005 12:36:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7zbc-0005Rr-SD; Sun, 06 Mar 2005 12:31:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7zbY-0005Rm-Ob for ips@megatron.ietf.org; Sun, 06 Mar 2005 12:31:51 -0500 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 MAA00363 for ; Sun, 6 Mar 2005 12:31:45 -0500 (EST) Received: from leviathan.ele.uri.edu ([131.128.51.64]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7zdZ-0008Eu-Ut for ips@ietf.org; Sun, 06 Mar 2005 12:33:54 -0500 Received: from [127.0.0.1] (leviathan [131.128.51.64]) by leviathan.ele.uri.edu (8.12.9/8.12.9) with ESMTP id j26HViCu006835; Sun, 6 Mar 2005 12:31:44 -0500 (EST) Subject: Re: [Ips] LUN or reserved in R2T? From: Ming Zhang To: Julian Satran In-Reply-To: References: Content-Type: text/plain Message-Id: <1110130303.2941.32.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Sun, 06 Mar 2005 12:31:44 -0500 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8cb9b411340046bf4080a729180a0672 Content-Transfer-Encoding: 7bit Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mingz@ele.uri.edu List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d2fdecab7a7fa796e06e001d026c91 Content-Transfer-Encoding: 7bit Thanks. On Sun, 2005-03-06 at 06:12, Julian Satran wrote: > LUN should always be correct. Whether an initiator or a target checks > them is left to the implementer. > The reason the LUN is there in REQ and DataOUT is that the TTT is > required to be unique only for a given LU. > An implementer using an incorrect LUN invites trouble - especially in > case when the target is "composed target" (on which the LUN will be > used for routing. > so my understanding is that this is left to target. As long as a target can handle this, it should be able to do what it wants to do. ming > > Julo > > > ----- Forwarded by Julian Satran/Haifa/IBM on 06/03/2005 05:42 ----- > Ming Zhang > Sent by: ips-bounces@ietf.org > > 05/03/2005 22:35 > Please respond to > mingz@ele.uri.edu > To > Eddy Quicksall > > cc > ips@ietf.org > Subject > Re: [Ips] LUN or > reserved in R2T? > > > > > On Sat, 2005-03-05 at 18:50, Eddy Quicksall wrote: > > It is up to the target: > > > > The Target Transfer Tag and LUN are copied in > > > > the outgoing data PDUs and are only used by the target. > see my another email, if this is only used by the target, then > initiator > should never check this? > > ming > > > > > > > > > Eddy > > ----- Original Message ----- > > From: "Ming Zhang" > > To: > > Sent: Saturday, March 05, 2005 11:51 AM > > Subject: [Ips] LUN or reserved in R2T? > > > > > > > In R2T, shall the LUN field have actual LUN value or can be > reserved? > > > > > > I knew this is asked before. but the archival i can find is > > > http://www.pdl.cmu.edu/mailinglists/ips/mail/msg09192.html, which > is in > > > 2002, pretty old. And there is no formal description on this field > in > > > 10.8. > > > > > > Thanks. > > > > > > Ming > > > > > > > > > > > > _______________________________________________ > > > 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 > > ----- Forwarded by Julian Satran/Haifa/IBM on 06/03/2005 05:42 ----- > Ming Zhang > Sent by: ips-bounces@ietf.org > > 05/03/2005 22:33 > Please respond to > mingz@ele.uri.edu > To > Eddy Quicksall > > cc > ips@ietf.org > Subject > Re: [Ips] LUN or > reserved in R2T? > > > > > On Sat, 2005-03-05 at 19:11, Eddy Quicksall wrote: > > I see the confusion because the LUN in the R2T is only used by the > target so > > that says the initiator must only copy it and not use it. But the > data out > > which was solicited by the R2T must have a valid LUN. > > > > So, the best thing is to make sure the LUN is valid when you send > the R2T. > yes, this is the best thing. > > but can we safely say this? > > 1) initiator should not check the validity of LUN field and should > simply copy it to data out packet > 2) if target wants to check the validity of lun field in data out > packet, then target should supply a valid lun field in r2t packet? > > ming > > > > > > Eddy > > ----- Original Message ----- > > From: "Ming Zhang" > > To: > > Sent: Saturday, March 05, 2005 11:51 AM > > Subject: [Ips] LUN or reserved in R2T? > > > > > > > In R2T, shall the LUN field have actual LUN value or can be > reserved? > > > > > > I knew this is asked before. but the archival i can find is > > > http://www.pdl.cmu.edu/mailinglists/ips/mail/msg09192.html, which > is in > > > 2002, pretty old. And there is no formal description on this field > in > > > 10.8. > > > > > > Thanks. > > > > > > Ming > > > > > > > > > > > > _______________________________________________ > > > 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 > > ----- Forwarded by Julian Satran/Haifa/IBM on 06/03/2005 05:42 ----- > "Nicholas A. Bellinger" > > Sent by: ips-bounces@ietf.org > > 06/03/2005 03:09 > To > mingz@ele.uri.edu > cc > ips@ietf.org, > Eddy Quicksall > > Subject > Re: [Ips] LUN or > reserved in R2T? > > > > > Hi Ming!! > > On Sat, 2005-03-05 at 22:35 -0500, Ming Zhang wrote: > > On Sat, 2005-03-05 at 18:50, Eddy Quicksall wrote: > > > It is up to the target: > > > > > > The Target Transfer Tag and LUN are copied in > > > > > > the outgoing data PDUs and are only used by the target. > > see my another email, if this is only used by the target, then > initiator > > should never check this? > > > > I have used to rule in the iscsi-initiator-core.org initiator stack > implementation that the Initiator uses the OS'es SCSI Task LUN inside > of > the LUN field for DataOUT PDUs in the solicited DataOUT case. This > ensures that the LUN from the original PDU containing the SCSI CDB and > all DataOUT PDUs contain the same value. Please see > iscsi_initiator.c:iscsi_build_data_out() for further details. > > On the target side, I have observed in the past that certain > initiators > may not include the correct LUN inside of solicited DataOUT PDUs, and > hence cause interopt problems. In the PyX Technologies Target Stack > we > leave the check against DataOUT PDU's LUN vs. the original > ISCSI_INIT_SCSI_CMND pdu's LUN stubbed out in order to ensure interopt > with these initiator implementations. > > Take care, > > -- > Nicholas A. Bellinger > Chief Architect, PyX Technologies, Inc. > > > ming > > > > > > > > > > > > > > Eddy > > > ----- Original Message ----- > > > From: "Ming Zhang" > > > To: > > > Sent: Saturday, March 05, 2005 11:51 AM > > > Subject: [Ips] LUN or reserved in R2T? > > > > > > > > > > In R2T, shall the LUN field have actual LUN value or can be > reserved? > > > > > > > > I knew this is asked before. but the archival i can find is > > > > http://www.pdl.cmu.edu/mailinglists/ips/mail/msg09192.html, > which is in > > > > 2002, pretty old. And there is no formal description on this > field in > > > > 10.8. > > > > > > > > Thanks. > > > > > > > > Ming > > > > > > > > > > > > > > > > _______________________________________________ > > > > 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 > -- > Nicholas A. Bellinger > > > _______________________________________________ > 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 Sun Mar 6 15:40:40 2005 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 PAA23714 for ; Sun, 6 Mar 2005 15:40:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D82aN-00050F-P1 for ips-web-archive@ietf.org; Sun, 06 Mar 2005 15:42:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D82XA-0000Yz-Hj; Sun, 06 Mar 2005 15:39:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D82X6-0000Yu-Cn for ips@megatron.ietf.org; Sun, 06 Mar 2005 15:39:26 -0500 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 PAA23627 for ; Sun, 6 Mar 2005 15:39:21 -0500 (EST) Received: from smtp814.mail.sc5.yahoo.com ([66.163.170.84]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D82Z8-0004y6-9g for ips@ietf.org; Sun, 06 Mar 2005 15:41:31 -0500 Received: from unknown (HELO ?192.168.0.101?) (nicholas?bellinger@sbcglobal.net@64.172.181.156 with plain) by smtp814.mail.sc5.yahoo.com with SMTP; 6 Mar 2005 20:39:21 -0000 Subject: Re: [Ips] LUN or reserved in R2T? From: "Nicholas A. Bellinger" To: Ming Zhang In-Reply-To: <1110125641.2941.6.camel@localhost.localdomain> References: <1110041467.2937.24.camel@localhost.localdomain> <000301c521de$2649bc30$0303a8c0@ivivity.com> <1110080132.2937.57.camel@localhost.localdomain> <1110096588.21190.108.camel@haakon> <1110125641.2941.6.camel@localhost.localdomain> Content-Type: text/plain Date: Sun, 06 Mar 2005 12:34:32 -0800 Message-Id: <1110141272.1786.153.camel@haakon> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Content-Transfer-Encoding: 7bit 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 X-Spam-Score: 0.1 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Content-Transfer-Encoding: 7bit On Sun, 2005-03-06 at 11:14 -0500, Ming Zhang wrote: > > > > I have used to rule in the iscsi-initiator-core.org initiator stack > > implementation that the Initiator uses the OS'es SCSI Task LUN inside of > > the LUN field for DataOUT PDUs in the solicited DataOUT case. This > > ensures that the LUN from the original PDU containing the SCSI CDB and > > all DataOUT PDUs contain the same value. Please see > > iscsi_initiator.c:iscsi_build_data_out() for further details. > > > This is to say that you are a good guy. :) > > But does your initiator check the target R2T packet Lun field? No, and here is the reasoning from 10.7.4: The Target Transfer Tag values are not specified by this protocol except that the value 0xffffffff is reserved and means that the Target Transfer Tag is not supplied. If the Target Transfer Tag is provided, then the LUN field MUST hold a valid value and be consistent with whatever was specified with the command; otherwise, the LUN field is reserved. 'Consistent' here meaning the DataOUT should be using the LUN from the original SCSI command PDU, and not what the target may or may not be echoing back in an R2T. All good targets MUST include the original LUN from the SCSI command PDU when they are soliciting DataOUT with R2Ts as specified in 3.2.4.3: As the Initiator Task Tag is used to identify a task during its execution the iSCSI initiator and target MUST verify that all other fields used in task related PDUs have values that are consistent with the values used at the task instantiation based on Initiator Task Tag (e.g., the LUN used in an R2T PDU MUST be the same as the one used in the SCSI command PDU used to instantiate the task). Using inconsistent field values is considered a protocol error. Aside from these two points, it can be argued there is no MUST requirement that the Initiator actually _check_ the LUN in the R2T against what it originally sent in the SCSI command, only that the LUN in solicitied DataOUT PDUs be consistant with the LUN from the original SCSI command PDU. > > > On the target side, I have observed in the past that certain initiators > > may not include the correct LUN inside of solicited DataOUT PDUs, and > > hence cause interopt problems. In the PyX Technologies Target Stack we > > leave the check against DataOUT PDU's LUN vs. the original > > ISCSI_INIT_SCSI_CMND pdu's LUN stubbed out in order to ensure interopt > > with these initiator implementations. > > > This is to say that you allow other guys to do something not so good. :) > Not really. The initiator knows what LUN its DataOUT is destined for, after all, it was the initiator that selected what LUN the original SCSI command PDU was directed towards in the first place. I believe this example Jonathan B. Postel's famous observation on network protocol design: "Be liberal in what you accept, and conservative in what you send". > But the question is, what does the rfc say? and which one strictly > follows the standard? > Along with the quoted sections from above, here is my interpretation of what RFC 3720 says for the WRITE case: Initiator: The LUN field in ISCSI_INIT_SCSI_CMND and ISCSI_INIT_SCSI_DATA_OUT PDUs should be from the same data source (ie: the SCSI Task from the Host OS). Since the initiator has the initial choice of what LUN the SCSI Command is destined towards, I believe its up to the implementor to determine if the LUN from the R2T should be checked against the original SCSI Command's LUN. ie: The initiator is telling the target what LUN the SCSI Command is destined for, and not the target telling the initiator. Target: The LUNs in the original SCSI command MUST be copied into all R2Ts. There is no strict requirement that the Target check the LUN in subsequent DataOUT PDUs fullfilling the R2T. -- Nicholas A. Bellinger Chief Architect, PyX Technologies, Inc. _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Sun Mar 6 22:09:31 2005 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 WAA28312 for ; Sun, 6 Mar 2005 22:09:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D88el-0005qw-Fr for ips-web-archive@ietf.org; Sun, 06 Mar 2005 22:11:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D88bK-0006Jj-EB; Sun, 06 Mar 2005 22:08:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D88bJ-0006Jb-Gw for ips@megatron.ietf.org; Sun, 06 Mar 2005 22:08:09 -0500 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 WAA28228 for ; Sun, 6 Mar 2005 22:08:06 -0500 (EST) Received: from leviathan.ele.uri.edu ([131.128.51.64]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D88dP-0005pi-Mu for ips@ietf.org; Sun, 06 Mar 2005 22:10:20 -0500 Received: from [127.0.0.1] (leviathan [131.128.51.64]) by leviathan.ele.uri.edu (8.12.9/8.12.9) with ESMTP id j27380Cu023516; Sun, 6 Mar 2005 22:08:03 -0500 (EST) Subject: Re: [Ips] LUN or reserved in R2T? From: Ming Zhang To: "Nicholas A. Bellinger" In-Reply-To: <1110141272.1786.153.camel@haakon> References: <1110041467.2937.24.camel@localhost.localdomain> <000301c521de$2649bc30$0303a8c0@ivivity.com> <1110080132.2937.57.camel@localhost.localdomain> <1110096588.21190.108.camel@haakon> <1110125641.2941.6.camel@localhost.localdomain> <1110141272.1786.153.camel@haakon> Content-Type: text/plain Message-Id: <1110164879.5718.18.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Sun, 06 Mar 2005 22:08:00 -0500 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Content-Transfer-Encoding: 7bit Cc: ips@ietf.org, open-iscsi , Eddy Quicksall X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mingz@ele.uri.edu List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Content-Transfer-Encoding: 7bit On Sun, 2005-03-06 at 15:34, Nicholas A. Bellinger wrote: > On Sun, 2005-03-06 at 11:14 -0500, Ming Zhang wrote: > > > > > > I have used to rule in the iscsi-initiator-core.org initiator stack > > > implementation that the Initiator uses the OS'es SCSI Task LUN inside of > > > the LUN field for DataOUT PDUs in the solicited DataOUT case. This > > > ensures that the LUN from the original PDU containing the SCSI CDB and > > > all DataOUT PDUs contain the same value. Please see > > > iscsi_initiator.c:iscsi_build_data_out() for further details. > > > > > This is to say that you are a good guy. :) > > > > But does your initiator check the target R2T packet Lun field? > > No, and here is the reasoning from 10.7.4: > > The Target Transfer Tag values are not specified by this protocol > except that the value 0xffffffff is reserved and means that the > Target Transfer Tag is not supplied. If the Target Transfer Tag is > provided, then the LUN field MUST hold a valid value and be > consistent with whatever was specified with the command; otherwise, > the LUN field is reserved. > > 'Consistent' here meaning the DataOUT should be using the LUN from the > original SCSI command PDU, and not what the target may or may not be > echoing back in an R2T. as 10.7.4 On incoming data, the Target Transfer Tag and LUN MUST be provided by the target if the A bit is set to 1; otherwise they are reserved. The Target Transfer Tag and LUN are copied by the initiator into the SNACK of type DataACK that it issues as a result of receiving a SCSI Data-In PDU with the A bit set to 1. so this A bit should be check first, before checking the validity of LUN if initiator want to check it. > > All good targets MUST include the original LUN from the SCSI command PDU > when they are soliciting DataOUT with R2Ts as specified in 3.2.4.3: > > As the Initiator Task Tag is used to identify a task during its > execution the iSCSI initiator and target MUST verify that all other > fields used in task related PDUs have values that are consistent > with the values used at the task instantiation based on Initiator > Task Tag (e.g., the LUN used in an R2T PDU MUST be the same as the > one used in the SCSI command PDU used to instantiate the task). > Using inconsistent field values is considered a protocol error. > > Aside from these two points, it can be argued there is no MUST > requirement that the Initiator actually _check_ the LUN in the R2T > against what it originally sent in the SCSI command, only that the LUN > in solicitied DataOUT PDUs be consistant with the LUN from the original > SCSI command PDU. > > > > > > On the target side, I have observed in the past that certain initiators > > > may not include the correct LUN inside of solicited DataOUT PDUs, and > > > hence cause interopt problems. In the PyX Technologies Target Stack we > > > leave the check against DataOUT PDU's LUN vs. the original > > > ISCSI_INIT_SCSI_CMND pdu's LUN stubbed out in order to ensure interopt > > > with these initiator implementations. > > > > > This is to say that you allow other guys to do something not so good. :) > > > > Not really. The initiator knows what LUN its DataOUT is destined for, > after all, it was the initiator that selected what LUN the original SCSI > command PDU was directed towards in the first place. I believe this > example Jonathan B. Postel's famous observation on network protocol > design: > > "Be liberal in what you accept, and conservative in what you send". > > > But the question is, what does the rfc say? and which one strictly > > follows the standard? > > > > Along with the quoted sections from above, here is my interpretation of > what RFC 3720 says for the WRITE case: > > Initiator: The LUN field in ISCSI_INIT_SCSI_CMND and > ISCSI_INIT_SCSI_DATA_OUT PDUs should be from the same data source (ie: > the SCSI Task from the Host OS). Since the initiator has the initial > choice of what LUN the SCSI Command is destined towards, I believe its > up to the implementor to determine if the LUN from the R2T should be > checked against the original SCSI Command's LUN. ie: The initiator is > telling the target what LUN the SCSI Command is destined for, and not > the target telling the initiator. > > Target: The LUNs in the original SCSI command MUST be copied into all > R2Ts. There is no strict requirement that the Target check the LUN in > subsequent DataOUT PDUs fullfilling the R2T. i admit that this is really conservative. :P thanks. ming _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Sun Mar 6 23:28:40 2005 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 XAA04682 for ; Sun, 6 Mar 2005 23:28:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D89tO-0007ZB-Fs for ips-web-archive@ietf.org; Sun, 06 Mar 2005 23:30:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D89pc-00051F-UK; Sun, 06 Mar 2005 23:27:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D89oW-0004wJ-SB for ips@megatron.ietf.org; Sun, 06 Mar 2005 23:25:54 -0500 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 XAA04406 for ; Sun, 6 Mar 2005 23:25:48 -0500 (EST) Received: from mtagate1.de.ibm.com ([195.212.29.150]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D89qa-0007V2-Tj for ips@ietf.org; Sun, 06 Mar 2005 23:28:03 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id j274Pd0Q169494 for ; Mon, 7 Mar 2005 04:25:39 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 j274Pcje185556 for ; Mon, 7 Mar 2005 05:25:38 +0100 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j274Pcha003591 for ; Mon, 7 Mar 2005 05:25:38 +0100 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 j274PcJ6003582; Mon, 7 Mar 2005 05:25:38 +0100 In-Reply-To: <1110130303.2941.32.camel@localhost.localdomain> To: mingz@ele.uri.edu Subject: Re: [Ips] LUN or reserved in R2T? MIME-Version: 1.0 X-Mailer: IBM Lotus Notes Build V70_02012005 February 01, 2005 From: Julian Satran Message-ID: Date: Sun, 6 Mar 2005 22:25:36 -0600 X-MIMETrack: Serialize by Router on D12ML102/12/M/IBM(Release 6.5.1| March 5, 2004) at 07/03/2005 06:25:38, Serialize complete at 07/03/2005 06:25:38 X-Spam-Score: 0.0 (/) X-Scan-Signature: c343632e7d969f32683dd165d9d1aa55 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="===============0960163063==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a6ea8837e8866a83aa68ed7cf9155ec9 This is a multipart message in MIME format. --===============0960163063== Content-Type: multipart/alternative; boundary="=_alternative 006DA6C285256FBC_=" This is a multipart message in MIME format. --=_alternative 006DA6C285256FBC_= Content-Type: text/plain; charset="US-ASCII" Ming Zhang, That is left to both!. If a traget issues invalid LUN it risks encountering an overzelous initiator that will not like an LU that is not matching the one one it has marked as addressing when issuing the oringinal command (the ITT). That is why for interoperability you will want to always use a correct LUN. So a target should use correct LUN and an initiator should not replace them with other values. Any implementation using incorrect LUN may be marked by testing labs as "not-compliant". Julo Ming Zhang 06/03/2005 12:31 Please respond to mingz@ele.uri.edu To Julian Satran/Haifa/IBM@IBMIL cc ips@ietf.org Subject Re: [Ips] LUN or reserved in R2T? Thanks. On Sun, 2005-03-06 at 06:12, Julian Satran wrote: > LUN should always be correct. Whether an initiator or a target checks > them is left to the implementer. > The reason the LUN is there in REQ and DataOUT is that the TTT is > required to be unique only for a given LU. > An implementer using an incorrect LUN invites trouble - especially in > case when the target is "composed target" (on which the LUN will be > used for routing. > so my understanding is that this is left to target. As long as a target can handle this, it should be able to do what it wants to do. ming > > Julo > > > ----- Forwarded by Julian Satran/Haifa/IBM on 06/03/2005 05:42 ----- > Ming Zhang > Sent by: ips-bounces@ietf.org > > 05/03/2005 22:35 > Please respond to > mingz@ele.uri.edu > To > Eddy Quicksall > > cc > ips@ietf.org > Subject > Re: [Ips] LUN or > reserved in R2T? > > > > > On Sat, 2005-03-05 at 18:50, Eddy Quicksall wrote: > > It is up to the target: > > > > The Target Transfer Tag and LUN are copied in > > > > the outgoing data PDUs and are only used by the target. > see my another email, if this is only used by the target, then > initiator > should never check this? > > ming > > > > > > > > > Eddy > > ----- Original Message ----- > > From: "Ming Zhang" > > To: > > Sent: Saturday, March 05, 2005 11:51 AM > > Subject: [Ips] LUN or reserved in R2T? > > > > > > > In R2T, shall the LUN field have actual LUN value or can be > reserved? > > > > > > I knew this is asked before. but the archival i can find is > > > http://www.pdl.cmu.edu/mailinglists/ips/mail/msg09192.html, which > is in > > > 2002, pretty old. And there is no formal description on this field > in > > > 10.8. > > > > > > Thanks. > > > > > > Ming > > > > > > > > > > > > _______________________________________________ > > > 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 > > ----- Forwarded by Julian Satran/Haifa/IBM on 06/03/2005 05:42 ----- > Ming Zhang > Sent by: ips-bounces@ietf.org > > 05/03/2005 22:33 > Please respond to > mingz@ele.uri.edu > To > Eddy Quicksall > > cc > ips@ietf.org > Subject > Re: [Ips] LUN or > reserved in R2T? > > > > > On Sat, 2005-03-05 at 19:11, Eddy Quicksall wrote: > > I see the confusion because the LUN in the R2T is only used by the > target so > > that says the initiator must only copy it and not use it. But the > data out > > which was solicited by the R2T must have a valid LUN. > > > > So, the best thing is to make sure the LUN is valid when you send > the R2T. > yes, this is the best thing. > > but can we safely say this? > > 1) initiator should not check the validity of LUN field and should > simply copy it to data out packet > 2) if target wants to check the validity of lun field in data out > packet, then target should supply a valid lun field in r2t packet? > > ming > > > > > > Eddy > > ----- Original Message ----- > > From: "Ming Zhang" > > To: > > Sent: Saturday, March 05, 2005 11:51 AM > > Subject: [Ips] LUN or reserved in R2T? > > > > > > > In R2T, shall the LUN field have actual LUN value or can be > reserved? > > > > > > I knew this is asked before. but the archival i can find is > > > http://www.pdl.cmu.edu/mailinglists/ips/mail/msg09192.html, which > is in > > > 2002, pretty old. And there is no formal description on this field > in > > > 10.8. > > > > > > Thanks. > > > > > > Ming > > > > > > > > > > > > _______________________________________________ > > > 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 > > ----- Forwarded by Julian Satran/Haifa/IBM on 06/03/2005 05:42 ----- > "Nicholas A. Bellinger" > > Sent by: ips-bounces@ietf.org > > 06/03/2005 03:09 > To > mingz@ele.uri.edu > cc > ips@ietf.org, > Eddy Quicksall > > Subject > Re: [Ips] LUN or > reserved in R2T? > > > > > Hi Ming!! > > On Sat, 2005-03-05 at 22:35 -0500, Ming Zhang wrote: > > On Sat, 2005-03-05 at 18:50, Eddy Quicksall wrote: > > > It is up to the target: > > > > > > The Target Transfer Tag and LUN are copied in > > > > > > the outgoing data PDUs and are only used by the target. > > see my another email, if this is only used by the target, then > initiator > > should never check this? > > > > I have used to rule in the iscsi-initiator-core.org initiator stack > implementation that the Initiator uses the OS'es SCSI Task LUN inside > of > the LUN field for DataOUT PDUs in the solicited DataOUT case. This > ensures that the LUN from the original PDU containing the SCSI CDB and > all DataOUT PDUs contain the same value. Please see > iscsi_initiator.c:iscsi_build_data_out() for further details. > > On the target side, I have observed in the past that certain > initiators > may not include the correct LUN inside of solicited DataOUT PDUs, and > hence cause interopt problems. In the PyX Technologies Target Stack > we > leave the check against DataOUT PDU's LUN vs. the original > ISCSI_INIT_SCSI_CMND pdu's LUN stubbed out in order to ensure interopt > with these initiator implementations. > > Take care, > > -- > Nicholas A. Bellinger > Chief Architect, PyX Technologies, Inc. > > > ming > > > > > > > > > > > > > > Eddy > > > ----- Original Message ----- > > > From: "Ming Zhang" > > > To: > > > Sent: Saturday, March 05, 2005 11:51 AM > > > Subject: [Ips] LUN or reserved in R2T? > > > > > > > > > > In R2T, shall the LUN field have actual LUN value or can be > reserved? > > > > > > > > I knew this is asked before. but the archival i can find is > > > > http://www.pdl.cmu.edu/mailinglists/ips/mail/msg09192.html, > which is in > > > > 2002, pretty old. And there is no formal description on this > field in > > > > 10.8. > > > > > > > > Thanks. > > > > > > > > Ming > > > > > > > > > > > > > > > > _______________________________________________ > > > > 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 > -- > Nicholas A. Bellinger > > > _______________________________________________ > 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 --=_alternative 006DA6C285256FBC_= Content-Type: text/html; charset="US-ASCII"
Ming Zhang,

That is left to both!. If a traget issues invalid LUN it risks encountering an overzelous initiator that will not like an LU that is not matching the one one it has marked as addressing when issuing the oringinal command (the ITT). That is why for interoperability you will want to always use a correct LUN. So a target should use correct LUN and an initiator should not replace them with other values. Any implementation using incorrect LUN may be marked by testing labs as "not-compliant".

Julo

Ming Zhang <mingz@ele.uri.edu>

06/03/2005 12:31

Please respond to
mingz@ele.uri.edu

To	Julian Satran/Haifa/IBM@IBMIL
cc	ips@ietf.org
Subject	Re: [Ips] LUN or reserved in R2T?

Thanks. On Sun, 2005-03-06 at 06:12, Julian Satran wrote: > LUN should always be correct. Whether an initiator or a target checks > them is left to the implementer. > The reason the LUN is there in REQ and DataOUT is that the TTT is > required to be unique only for a given LU. > An implementer using an incorrect LUN invites trouble - especially in > case when the target is "composed target" (on which the LUN will be > used for routing. > so my understanding is that this is left to target. As long as a target can handle this, it should be able to do what it wants to do. ming > > Julo > > > ----- Forwarded by Julian Satran/Haifa/IBM on 06/03/2005 05:42 ----- > Ming Zhang <mingz@ele.uri.edu> > Sent by: ips-bounces@ietf.org > > 05/03/2005 22:35 > Please respond to > mingz@ele.uri.edu > To > Eddy Quicksall > <eddy_quicksall_iVivity_iSCSI@comcast.net> > cc > ips@ietf.org > Subject > Re: [Ips] LUN or > reserved in R2T? > > > > > On Sat, 2005-03-05 at 18:50, Eddy Quicksall wrote: > > It is up to the target: > > > > The Target Transfer Tag and LUN are copied in > > > > the outgoing data PDUs and are only used by the target. > see my another email, if this is only used by the target, then > initiator > should never check this? > > ming > > > > > > > > > Eddy > > ----- Original Message ----- > > From: "Ming Zhang" <mingz@ele.uri.edu> > > To: <ips@ietf.org> > > Sent: Saturday, March 05, 2005 11:51 AM > > Subject: [Ips] LUN or reserved in R2T? > > > > > > > In R2T, shall the LUN field have actual LUN value or can be > reserved? > > > > > > I knew this is asked before. but the archival i can find is > > > http://www.pdl.cmu.edu/mailinglists/ips/mail/msg09192.html, which > is in > > > 2002, pretty old. And there is no formal description on this field > in > > > 10.8. > > > > > > Thanks. > > > > > > Ming > > > > > > > > > > > > _______________________________________________ > > > 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 > > ----- Forwarded by Julian Satran/Haifa/IBM on 06/03/2005 05:42 ----- > Ming Zhang <mingz@ele.uri.edu> > Sent by: ips-bounces@ietf.org > > 05/03/2005 22:33 > Please respond to > mingz@ele.uri.edu > To > Eddy Quicksall > <eddy_quicksall_iVivity_iSCSI@comcast.net> > cc > ips@ietf.org > Subject > Re: [Ips] LUN or > reserved in R2T? > > > > > On Sat, 2005-03-05 at 19:11, Eddy Quicksall wrote: > > I see the confusion because the LUN in the R2T is only used by the > target so > > that says the initiator must only copy it and not use it. But the > data out > > which was solicited by the R2T must have a valid LUN. > > > > So, the best thing is to make sure the LUN is valid when you send > the R2T. > yes, this is the best thing. > > but can we safely say this? > > 1) initiator should not check the validity of LUN field and should > simply copy it to data out packet > 2) if target wants to check the validity of lun field in data out > packet, then target should supply a valid lun field in r2t packet? > > ming > > > > > > Eddy > > ----- Original Message ----- > > From: "Ming Zhang" <mingz@ele.uri.edu> > > To: <ips@ietf.org> > > Sent: Saturday, March 05, 2005 11:51 AM > > Subject: [Ips] LUN or reserved in R2T? > > > > > > > In R2T, shall the LUN field have actual LUN value or can be > reserved? > > > > > > I knew this is asked before. but the archival i can find is > > > http://www.pdl.cmu.edu/mailinglists/ips/mail/msg09192.html, which > is in > > > 2002, pretty old. And there is no formal description on this field > in > > > 10.8. > > > > > > Thanks. > > > > > > Ming > > > > > > > > > > > > _______________________________________________ > > > 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 > > ----- Forwarded by Julian Satran/Haifa/IBM on 06/03/2005 05:42 ----- > "Nicholas A. Bellinger" > <nick@pyxtechnologies.com> > Sent by: ips-bounces@ietf.org > > 06/03/2005 03:09 > To > mingz@ele.uri.edu > cc > ips@ietf.org, > Eddy Quicksall > <eddy_quicksall_iVivity_iSCSI@comcast.net> > Subject > Re: [Ips] LUN or > reserved in R2T? > > > > > Hi Ming!! > > On Sat, 2005-03-05 at 22:35 -0500, Ming Zhang wrote: > > On Sat, 2005-03-05 at 18:50, Eddy Quicksall wrote: > > > It is up to the target: > > > > > > The Target Transfer Tag and LUN are copied in > > > > > > the outgoing data PDUs and are only used by the target. > > see my another email, if this is only used by the target, then > initiator > > should never check this? > > > > I have used to rule in the iscsi-initiator-core.org initiator stack > implementation that the Initiator uses the OS'es SCSI Task LUN inside > of > the LUN field for DataOUT PDUs in the solicited DataOUT case. This > ensures that the LUN from the original PDU containing the SCSI CDB and > all DataOUT PDUs contain the same value. Please see > iscsi_initiator.c:iscsi_build_data_out() for further details. > > On the target side, I have observed in the past that certain > initiators > may not include the correct LUN inside of solicited DataOUT PDUs, and > hence cause interopt problems. In the PyX Technologies Target Stack > we > leave the check against DataOUT PDU's LUN vs. the original > ISCSI_INIT_SCSI_CMND pdu's LUN stubbed out in order to ensure interopt > with these initiator implementations. > > Take care, > > -- > Nicholas A. Bellinger <nick@pyxtechnologies.com> > Chief Architect, PyX Technologies, Inc. > > > ming > > > > > > > > > > > > > > Eddy > > > ----- Original Message ----- > > > From: "Ming Zhang" <mingz@ele.uri.edu> > > > To: <ips@ietf.org> > > > Sent: Saturday, March 05, 2005 11:51 AM > > > Subject: [Ips] LUN or reserved in R2T? > > > > > > > > > > In R2T, shall the LUN field have actual LUN value or can be > reserved? > > > > > > > > I knew this is asked before. but the archival i can find is > > > > http://www.pdl.cmu.edu/mailinglists/ips/mail/msg09192.html, > which is in > > > > 2002, pretty old. And there is no formal description on this > field in > > > > 10.8. > > > > > > > > Thanks. > > > > > > > > Ming > > > > > > > > > > > > > > > > _______________________________________________ > > > > 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 > -- > Nicholas A. Bellinger <nick@pyxtechnologies.com> > > > _______________________________________________ > 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
--=_alternative 006DA6C285256FBC_=-- --===============0960163063== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0960163063==-- From ips-bounces@ietf.org Sun Mar 6 23:56:42 2005 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 XAA08351 for ; Sun, 6 Mar 2005 23:56:42 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8AKW-0008K1-Tg for ips-web-archive@ietf.org; Sun, 06 Mar 2005 23:58:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8AGC-0007Zp-5g; Sun, 06 Mar 2005 23:54:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8AG8-0007Zf-Ac for ips@megatron.ietf.org; Sun, 06 Mar 2005 23:54:25 -0500 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 XAA08019 for ; Sun, 6 Mar 2005 23:54:21 -0500 (EST) Received: from mtagate3.de.ibm.com ([195.212.29.152]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8AIE-0008DV-Pi for ips@ietf.org; Sun, 06 Mar 2005 23:56:36 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate3.de.ibm.com (8.12.10/8.12.10) with ESMTP id j274sEFa112848 for ; Mon, 7 Mar 2005 04:54:14 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j274sDje173652 for ; Mon, 7 Mar 2005 05:54:13 +0100 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j274sDIs022417 for ; Mon, 7 Mar 2005 05:54:13 +0100 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 j274sDj2022412; Mon, 7 Mar 2005 05:54:13 +0100 In-Reply-To: <1110164879.5718.18.camel@localhost.localdomain> To: mingz@ele.uri.edu Subject: Re: [Ips] LUN or reserved in R2T? MIME-Version: 1.0 X-Mailer: IBM Lotus Notes Build V70_02012005 February 01, 2005 From: Julian Satran Message-ID: Date: Sun, 6 Mar 2005 22:54:11 -0600 X-MIMETrack: Serialize by Router on D12ML102/12/M/IBM(Release 6.5.1| March 5, 2004) at 07/03/2005 06:54:13, Serialize complete at 07/03/2005 06:54:13 X-Spam-Score: 0.0 (/) X-Scan-Signature: df1883a27a831c1ea5e8cfe5eb3ad38e Cc: ips@ietf.org, open-iscsi , 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="===============2053100480==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 06d29b9b22258f4f07fe89b4d4a05a86 This is a multipart message in MIME format. --===============2053100480== Content-Type: multipart/alternative; boundary="=_alternative 001A571686256FBD_=" This is a multipart message in MIME format. --=_alternative 001A571686256FBD_= Content-Type: text/plain; charset="US-ASCII" The answers given up to know should have clarified the issue. The A bit is mentioned only because the positive SACK needs the same two fields (TTT & LUN). THe reason all outgoing solicited PDUs have those fields are: TTT a convenience label to help the target identify an internal control structure related to the incoming PDU LUN to enable the target to define TTT per LU (in case the work is done by different control entities at the target) Obviously those value have to be consistent with those used by the initiator - and referred to by ITT. ITT is the primary "identifier" of a task. As I indicated earlier - you should do it correctly to ensure interoperability but you are not mandated to check what others do (ass long as you can live with it). Certain compliance test suites will certainly indicate that you are not compliant if you do not set consistent values in those fields. Julo Ming Zhang Sent by: ips-bounces@ietf.org 06/03/2005 21:08 Please respond to mingz@ele.uri.edu To "Nicholas A. Bellinger" cc ips@ietf.org, open-iscsi , Eddy Quicksall Subject Re: [Ips] LUN or reserved in R2T? On Sun, 2005-03-06 at 15:34, Nicholas A. Bellinger wrote: > On Sun, 2005-03-06 at 11:14 -0500, Ming Zhang wrote: > > > > > > I have used to rule in the iscsi-initiator-core.org initiator stack > > > implementation that the Initiator uses the OS'es SCSI Task LUN inside of > > > the LUN field for DataOUT PDUs in the solicited DataOUT case. This > > > ensures that the LUN from the original PDU containing the SCSI CDB and > > > all DataOUT PDUs contain the same value. Please see > > > iscsi_initiator.c:iscsi_build_data_out() for further details. > > > > > This is to say that you are a good guy. :) > > > > But does your initiator check the target R2T packet Lun field? > > No, and here is the reasoning from 10.7.4: > > The Target Transfer Tag values are not specified by this protocol > except that the value 0xffffffff is reserved and means that the > Target Transfer Tag is not supplied. If the Target Transfer Tag is > provided, then the LUN field MUST hold a valid value and be > consistent with whatever was specified with the command; otherwise, > the LUN field is reserved. > > 'Consistent' here meaning the DataOUT should be using the LUN from the > original SCSI command PDU, and not what the target may or may not be > echoing back in an R2T. as 10.7.4 On incoming data, the Target Transfer Tag and LUN MUST be provided by the target if the A bit is set to 1; otherwise they are reserved. The Target Transfer Tag and LUN are copied by the initiator into the SNACK of type DataACK that it issues as a result of receiving a SCSI Data-In PDU with the A bit set to 1. so this A bit should be check first, before checking the validity of LUN if initiator want to check it. > > All good targets MUST include the original LUN from the SCSI command PDU > when they are soliciting DataOUT with R2Ts as specified in 3.2.4.3: > > As the Initiator Task Tag is used to identify a task during its > execution the iSCSI initiator and target MUST verify that all other > fields used in task related PDUs have values that are consistent > with the values used at the task instantiation based on Initiator > Task Tag (e.g., the LUN used in an R2T PDU MUST be the same as the > one used in the SCSI command PDU used to instantiate the task). > Using inconsistent field values is considered a protocol error. > > Aside from these two points, it can be argued there is no MUST > requirement that the Initiator actually _check_ the LUN in the R2T > against what it originally sent in the SCSI command, only that the LUN > in solicitied DataOUT PDUs be consistant with the LUN from the original > SCSI command PDU. > > > > > > On the target side, I have observed in the past that certain initiators > > > may not include the correct LUN inside of solicited DataOUT PDUs, and > > > hence cause interopt problems. In the PyX Technologies Target Stack we > > > leave the check against DataOUT PDU's LUN vs. the original > > > ISCSI_INIT_SCSI_CMND pdu's LUN stubbed out in order to ensure interopt > > > with these initiator implementations. > > > > > This is to say that you allow other guys to do something not so good. :) > > > > Not really. The initiator knows what LUN its DataOUT is destined for, > after all, it was the initiator that selected what LUN the original SCSI > command PDU was directed towards in the first place. I believe this > example Jonathan B. Postel's famous observation on network protocol > design: > > "Be liberal in what you accept, and conservative in what you send". > > > But the question is, what does the rfc say? and which one strictly > > follows the standard? > > > > Along with the quoted sections from above, here is my interpretation of > what RFC 3720 says for the WRITE case: > > Initiator: The LUN field in ISCSI_INIT_SCSI_CMND and > ISCSI_INIT_SCSI_DATA_OUT PDUs should be from the same data source (ie: > the SCSI Task from the Host OS). Since the initiator has the initial > choice of what LUN the SCSI Command is destined towards, I believe its > up to the implementor to determine if the LUN from the R2T should be > checked against the original SCSI Command's LUN. ie: The initiator is > telling the target what LUN the SCSI Command is destined for, and not > the target telling the initiator. > > Target: The LUNs in the original SCSI command MUST be copied into all > R2Ts. There is no strict requirement that the Target check the LUN in > subsequent DataOUT PDUs fullfilling the R2T. i admit that this is really conservative. :P thanks. ming _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --=_alternative 001A571686256FBD_= Content-Type: text/html; charset="US-ASCII"
The answers given up to know should have clarified the issue. The A bit is mentioned only because the positive SACK needs the same two fields (TTT & LUN).
THe reason all outgoing solicited PDUs have those fields are:

TTT a convenience label to help the target identify an internal control structure related to the incoming PDU
LUN to enable the target to define TTT per LU (in case the work is done by different control entities at the target)

Obviously those value have to be consistent with those used by the initiator - and referred to by ITT.
ITT is the primary "identifier" of a task.

As I indicated earlier - you should do it correctly to ensure interoperability but you are not mandated to check what others do (ass long as you can live with it).

Certain compliance test suites will certainly indicate that you are not compliant if you do not set consistent values in those fields.

Julo

Ming Zhang <mingz@ele.uri.edu>
Sent by: ips-bounces@ietf.org

06/03/2005 21:08

Please respond to
mingz@ele.uri.edu

To	"Nicholas A. Bellinger" <nick@pyxtechnologies.com>
cc	ips@ietf.org, open-iscsi <open-iscsi@googlegroups.com>, Eddy Quicksall <eddy_quicksall_iVivity_iSCSI@comcast.net>
Subject	Re: [Ips] LUN or reserved in R2T?

On Sun, 2005-03-06 at 15:34, Nicholas A. Bellinger wrote: > On Sun, 2005-03-06 at 11:14 -0500, Ming Zhang wrote: > > > > > > I have used to rule in the iscsi-initiator-core.org initiator stack > > > implementation that the Initiator uses the OS'es SCSI Task LUN inside of > > > the LUN field for DataOUT PDUs in the solicited DataOUT case. This > > > ensures that the LUN from the original PDU containing the SCSI CDB and > > > all DataOUT PDUs contain the same value. Please see > > > iscsi_initiator.c:iscsi_build_data_out() for further details. > > > > > This is to say that you are a good guy. :) > > > > But does your initiator check the target R2T packet Lun field? > > No, and here is the reasoning from 10.7.4: > > The Target Transfer Tag values are not specified by this protocol > except that the value 0xffffffff is reserved and means that the > Target Transfer Tag is not supplied. If the Target Transfer Tag is > provided, then the LUN field MUST hold a valid value and be > consistent with whatever was specified with the command; otherwise, > the LUN field is reserved. > > 'Consistent' here meaning the DataOUT should be using the LUN from the > original SCSI command PDU, and not what the target may or may not be > echoing back in an R2T. as 10.7.4 On incoming data, the Target Transfer Tag and LUN MUST be provided by the target if the A bit is set to 1; otherwise they are reserved. The Target Transfer Tag and LUN are copied by the initiator into the SNACK of type DataACK that it issues as a result of receiving a SCSI Data-In PDU with the A bit set to 1. so this A bit should be check first, before checking the validity of LUN if initiator want to check it. > > All good targets MUST include the original LUN from the SCSI command PDU > when they are soliciting DataOUT with R2Ts as specified in 3.2.4.3: > > As the Initiator Task Tag is used to identify a task during its > execution the iSCSI initiator and target MUST verify that all other > fields used in task related PDUs have values that are consistent > with the values used at the task instantiation based on Initiator > Task Tag (e.g., the LUN used in an R2T PDU MUST be the same as the > one used in the SCSI command PDU used to instantiate the task). > Using inconsistent field values is considered a protocol error. > > Aside from these two points, it can be argued there is no MUST > requirement that the Initiator actually _check_ the LUN in the R2T > against what it originally sent in the SCSI command, only that the LUN > in solicitied DataOUT PDUs be consistant with the LUN from the original > SCSI command PDU. > > > > > > On the target side, I have observed in the past that certain initiators > > > may not include the correct LUN inside of solicited DataOUT PDUs, and > > > hence cause interopt problems. In the PyX Technologies Target Stack we > > > leave the check against DataOUT PDU's LUN vs. the original > > > ISCSI_INIT_SCSI_CMND pdu's LUN stubbed out in order to ensure interopt > > > with these initiator implementations. > > > > > This is to say that you allow other guys to do something not so good. :) > > > > Not really. The initiator knows what LUN its DataOUT is destined for, > after all, it was the initiator that selected what LUN the original SCSI > command PDU was directed towards in the first place. I believe this > example Jonathan B. Postel's famous observation on network protocol > design: > > "Be liberal in what you accept, and conservative in what you send". > > > But the question is, what does the rfc say? and which one strictly > > follows the standard? > > > > Along with the quoted sections from above, here is my interpretation of > what RFC 3720 says for the WRITE case: > > Initiator: The LUN field in ISCSI_INIT_SCSI_CMND and > ISCSI_INIT_SCSI_DATA_OUT PDUs should be from the same data source (ie: > the SCSI Task from the Host OS). Since the initiator has the initial > choice of what LUN the SCSI Command is destined towards, I believe its > up to the implementor to determine if the LUN from the R2T should be > checked against the original SCSI Command's LUN. ie: The initiator is > telling the target what LUN the SCSI Command is destined for, and not > the target telling the initiator. > > Target: The LUNs in the original SCSI command MUST be copied into all > R2Ts. There is no strict requirement that the Target check the LUN in > subsequent DataOUT PDUs fullfilling the R2T. i admit that this is really conservative. :P thanks. ming _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips
--=_alternative 001A571686256FBD_=-- --===============2053100480== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============2053100480==-- From ips-bounces@ietf.org Sun Mar 6 23:56:48 2005 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 XAA08374 for ; Sun, 6 Mar 2005 23:56:48 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8AKd-0008KA-2e for ips-web-archive@ietf.org; Sun, 06 Mar 2005 23:59:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8AG6-0007ZS-Ff; Sun, 06 Mar 2005 23:54:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8AG4-0007ZI-Bk for ips@megatron.ietf.org; Sun, 06 Mar 2005 23:54:20 -0500 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 XAA08000 for ; Sun, 6 Mar 2005 23:54:17 -0500 (EST) Received: from mtagate2.de.ibm.com ([195.212.29.151]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8AIA-0008DM-Vb for ips@ietf.org; Sun, 06 Mar 2005 23:56:32 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id j274sA96131362 for ; Mon, 7 Mar 2005 04:54:10 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j274s9je147812 for ; Mon, 7 Mar 2005 05:54:09 +0100 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j274s9hG022394 for ; Mon, 7 Mar 2005 05:54:09 +0100 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 j274s9D4022386; Mon, 7 Mar 2005 05:54:09 +0100 In-Reply-To: <1110141272.1786.153.camel@haakon> To: "Nicholas A. Bellinger" Subject: Re: [Ips] LUN or reserved in R2T? MIME-Version: 1.0 X-Mailer: IBM Lotus Notes Build V70_02012005 February 01, 2005 From: Julian Satran Message-ID: Date: Sun, 6 Mar 2005 22:54:07 -0600 X-MIMETrack: Serialize by Router on D12ML102/12/M/IBM(Release 6.5.1| March 5, 2004) at 07/03/2005 06:54:09, Serialize complete at 07/03/2005 06:54:09 X-Spam-Score: 0.0 (/) X-Scan-Signature: 515708a075ffdf0a79d1c83b601e2afd Cc: Ming Zhang , 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="===============1424855030==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f8ee348dcc4be4a59bc395f7cd6343ad This is a multipart message in MIME format. --===============1424855030== Content-Type: multipart/alternative; boundary="=_alternative 0019504386256FBD_=" This is a multipart message in MIME format. --=_alternative 0019504386256FBD_= Content-Type: text/plain; charset="US-ASCII" "Nicholas A. Bellinger" Sent by: ips-bounces@ietf.org 06/03/2005 14:34 To Ming Zhang cc ips@ietf.org, Eddy Quicksall Subject Re: [Ips] LUN or reserved in R2T? On Sun, 2005-03-06 at 11:14 -0500, Ming Zhang wrote: > > > > I have used to rule in the iscsi-initiator-core.org initiator stack > > implementation that the Initiator uses the OS'es SCSI Task LUN inside of > > the LUN field for DataOUT PDUs in the solicited DataOUT case. This > > ensures that the LUN from the original PDU containing the SCSI CDB and > > all DataOUT PDUs contain the same value. Please see > > iscsi_initiator.c:iscsi_build_data_out() for further details. > > > This is to say that you are a good guy. :) > > But does your initiator check the target R2T packet Lun field? No, and here is the reasoning from 10.7.4: The Target Transfer Tag values are not specified by this protocol except that the value 0xffffffff is reserved and means that the Target Transfer Tag is not supplied. If the Target Transfer Tag is provided, then the LUN field MUST hold a valid value and be consistent with whatever was specified with the command; otherwise, the LUN field is reserved. 'Consistent' here meaning the DataOUT should be using the LUN from the original SCSI command PDU, and not what the target may or may not be echoing back in an R2T. All good targets MUST include the original LUN from the SCSI command PDU when they are soliciting DataOUT with R2Ts as specified in 3.2.4.3: As the Initiator Task Tag is used to identify a task during its execution the iSCSI initiator and target MUST verify that all other fields used in task related PDUs have values that are consistent with the values used at the task instantiation based on Initiator Task Tag (e.g., the LUN used in an R2T PDU MUST be the same as the one used in the SCSI command PDU used to instantiate the task). Using inconsistent field values is considered a protocol error. Aside from these two points, it can be argued there is no MUST requirement that the Initiator actually _check_ the LUN in the R2T against what it originally sent in the SCSI command, only that the LUN in solicitied DataOUT PDUs be consistant with the LUN from the original SCSI command PDU. > > > On the target side, I have observed in the past that certain initiators > > may not include the correct LUN inside of solicited DataOUT PDUs, and > > hence cause interopt problems. In the PyX Technologies Target Stack we > > leave the check against DataOUT PDU's LUN vs. the original > > ISCSI_INIT_SCSI_CMND pdu's LUN stubbed out in order to ensure interopt > > with these initiator implementations. > > > This is to say that you allow other guys to do something not so good. :) > Not really. The initiator knows what LUN its DataOUT is destined for, after all, it was the initiator that selected what LUN the original SCSI command PDU was directed towards in the first place. I believe this example Jonathan B. Postel's famous observation on network protocol design: "Be liberal in what you accept, and conservative in what you send". > But the question is, what does the rfc say? and which one strictly > follows the standard? > Along with the quoted sections from above, here is my interpretation of what RFC 3720 says for the WRITE case: Initiator: The LUN field in ISCSI_INIT_SCSI_CMND and ISCSI_INIT_SCSI_DATA_OUT PDUs should be from the same data source (ie: the SCSI Task from the Host OS). Since the initiator has the initial choice of what LUN the SCSI Command is destined towards, I believe its up to the implementor to determine if the LUN from the R2T should be checked against the original SCSI Command's LUN. ie: The initiator is telling the target what LUN the SCSI Command is destined for, and not the target telling the initiator. Target: The LUNs in the original SCSI command MUST be copied into all R2Ts. There is no strict requirement that the Target check the LUN in subsequent DataOUT PDUs fullfilling the R2T. -- Nicholas A. Bellinger Chief Architect, PyX Technologies, Inc. _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --=_alternative 0019504386256FBD_= Content-Type: text/html; charset="US-ASCII"

"Nicholas A. Bellinger" <nick@pyxtechnologies.com>
Sent by: ips-bounces@ietf.org

06/03/2005 14:34

To	Ming Zhang <mingz@ele.uri.edu>
cc	ips@ietf.org, Eddy Quicksall <eddy_quicksall_iVivity_iSCSI@comcast.net>
Subject	Re: [Ips] LUN or reserved in R2T?

On Sun, 2005-03-06 at 11:14 -0500, Ming Zhang wrote: > > > > I have used to rule in the iscsi-initiator-core.org initiator stack > > implementation that the Initiator uses the OS'es SCSI Task LUN inside of > > the LUN field for DataOUT PDUs in the solicited DataOUT case. This > > ensures that the LUN from the original PDU containing the SCSI CDB and > > all DataOUT PDUs contain the same value. Please see > > iscsi_initiator.c:iscsi_build_data_out() for further details. > > > This is to say that you are a good guy. :) > > But does your initiator check the target R2T packet Lun field? No, and here is the reasoning from 10.7.4: The Target Transfer Tag values are not specified by this protocol except that the value 0xffffffff is reserved and means that the Target Transfer Tag is not supplied. If the Target Transfer Tag is provided, then the LUN field MUST hold a valid value and be consistent with whatever was specified with the command; otherwise, the LUN field is reserved. 'Consistent' here meaning the DataOUT should be using the LUN from the original SCSI command PDU, and not what the target may or may not be echoing back in an R2T. All good targets MUST include the original LUN from the SCSI command PDU when they are soliciting DataOUT with R2Ts as specified in 3.2.4.3: As the Initiator Task Tag is used to identify a task during its execution the iSCSI initiator and target MUST verify that all other fields used in task related PDUs have values that are consistent with the values used at the task instantiation based on Initiator Task Tag (e.g., the LUN used in an R2T PDU MUST be the same as the one used in the SCSI command PDU used to instantiate the task). Using inconsistent field values is considered a protocol error. Aside from these two points, it can be argued there is no MUST requirement that the Initiator actually _check_ the LUN in the R2T against what it originally sent in the SCSI command, only that the LUN in solicitied DataOUT PDUs be consistant with the LUN from the original SCSI command PDU. > > > On the target side, I have observed in the past that certain initiators > > may not include the correct LUN inside of solicited DataOUT PDUs, and > > hence cause interopt problems. In the PyX Technologies Target Stack we > > leave the check against DataOUT PDU's LUN vs. the original > > ISCSI_INIT_SCSI_CMND pdu's LUN stubbed out in order to ensure interopt > > with these initiator implementations. > > > This is to say that you allow other guys to do something not so good. :) > Not really. The initiator knows what LUN its DataOUT is destined for, after all, it was the initiator that selected what LUN the original SCSI command PDU was directed towards in the first place. I believe this example Jonathan B. Postel's famous observation on network protocol design: "Be liberal in what you accept, and conservative in what you send". > But the question is, what does the rfc say? and which one strictly > follows the standard? > Along with the quoted sections from above, here is my interpretation of what RFC 3720 says for the WRITE case: Initiator: The LUN field in ISCSI_INIT_SCSI_CMND and ISCSI_INIT_SCSI_DATA_OUT PDUs should be from the same data source (ie: the SCSI Task from the Host OS). Since the initiator has the initial choice of what LUN the SCSI Command is destined towards, I believe its up to the implementor to determine if the LUN from the R2T should be checked against the original SCSI Command's LUN. ie: The initiator is telling the target what LUN the SCSI Command is destined for, and not the target telling the initiator. Target: The LUNs in the original SCSI command MUST be copied into all R2Ts. There is no strict requirement that the Target check the LUN in subsequent DataOUT PDUs fullfilling the R2T. -- Nicholas A. Bellinger <nick@pyxtechnologies.com> Chief Architect, PyX Technologies, Inc. _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips
--=_alternative 0019504386256FBD_=-- --===============1424855030== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============1424855030==-- From ips-bounces@ietf.org Mon Mar 7 00:01:32 2005 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 AAA08867 for ; Mon, 7 Mar 2005 00:01:32 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8APC-0000Ak-79 for ips-web-archive@ietf.org; Mon, 07 Mar 2005 00:03:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8ALw-0008W6-Lh; Mon, 07 Mar 2005 00:00:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8ALt-0008W0-Mj for ips@megatron.ietf.org; Mon, 07 Mar 2005 00:00:21 -0500 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 AAA08682; Mon, 7 Mar 2005 00:00:18 -0500 (EST) 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 1D8AO0-00006V-4B; Mon, 07 Mar 2005 00:02:33 -0500 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 j2750DCu018424; Mon, 7 Mar 2005 00:00:13 -0500 (EST) Received: by maho3msx2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Mon, 7 Mar 2005 00:00:07 -0500 Message-ID: To: agenda@ietf.org, ips@ietf.org Date: Mon, 7 Mar 2005 00:00:06 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-PerlMx-Spam: Gauge=, SPAM=0%, Reasons='EMC_BODY_1+ -5, 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: 7655788c23eb79e336f5f8ba8bce7906 Subject: [Ips] IP Storage (ips) WG Minneapolis meeting agenda 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 X-Spam-Score: 0.3 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 The IP Storage (ips) WG meets 0900-1130 on Tuesday, March 8 at the IETF meetings in Minneapolis, MN. AGENDA ------ Administrivia, agenda bashing, draft status review, etc.: 15 min David L. Black, EMC (co-chair) Blue sheets Note Well Milestones Draft status iSER and DA: 45min Mike Ko, IBM (draft-ietf-ips-iser-01.txt) (draft-ietf-ips-iwarp-da-01.txt) iSER = iSCSI Extensions for RDMA DA = Datamover Architecture for iSCSI iSER over InfiniBand: up to 1 hour 30min John Hufferd, IBM draft-hufferd-ips-iser-sctp-ib-00.{txt,pdf} Proposal to generalize iSER to non-TCP transports. _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Mon Mar 7 09:47:57 2005 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 JAA23050 for ; Mon, 7 Mar 2005 09:47:57 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8JYl-0005CE-QO for ips-web-archive@ietf.org; Mon, 07 Mar 2005 09:50:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8JSN-00038r-RS; Mon, 07 Mar 2005 09:43:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8JS9-0002zO-Nk for ips@megatron.ietf.org; Mon, 07 Mar 2005 09:43:26 -0500 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 JAA22311 for ; Mon, 7 Mar 2005 09:43:23 -0500 (EST) Received: from leviathan.ele.uri.edu ([131.128.51.64]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8JUM-00050N-92 for ips@ietf.org; Mon, 07 Mar 2005 09:45:42 -0500 Received: from [127.0.0.1] (leviathan [131.128.51.64]) by leviathan.ele.uri.edu (8.12.9/8.12.9) with ESMTP id j27EhHCu009181; Mon, 7 Mar 2005 09:43:17 -0500 (EST) Subject: Re: [Ips] LUN or reserved in R2T? From: Ming Zhang To: Julian Satran In-Reply-To: References: Content-Type: text/plain Message-Id: <1110206596.2892.4.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Mon, 07 Mar 2005 09:43:16 -0500 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 86f85b2f88b0d50615aed44a7f9e33c7 Content-Transfer-Encoding: 7bit Cc: ips@ietf.org, open-iscsi , Eddy Quicksall X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mingz@ele.uri.edu List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f2984bf50fb52a9e56055f779793d783 Content-Transfer-Encoding: 7bit On Sun, 2005-03-06 at 23:54, Julian Satran wrote: > The answers given up to know should have clarified the issue. The A > bit is mentioned only because the positive SACK needs the same two > fields (TTT & LUN). > THe reason all outgoing solicited PDUs have those fields are: > * TTT a convenience label to help the target identify an > internal control structure related to the incoming PDU > * LUN to enable the target to define TTT per LU (in case the > work is done by different control entities at the target) > > > Obviously those value have to be consistent with those used by the > initiator - and referred to by ITT. > ITT is the primary "identifier" of a task. > > As I indicated earlier - you should do it correctly to ensure > interoperability but you are not mandated to check what others do (ass > long as you can live with it). thanks. i think this is a very good summary on this question. we will modify (in fact, we are modifying) base on this. thanks again. > > Certain compliance test suites will certainly indicate that you are > not compliant if you do not set consistent values in those fields. > > Julo > > > Ming Zhang > Sent by: ips-bounces@ietf.org > > 06/03/2005 21:08 > Please respond to > mingz@ele.uri.edu > To > "Nicholas A. > Bellinger" > > cc > ips@ietf.org, > open-iscsi > , Eddy Quicksall > Subject > Re: [Ips] LUN or > reserved in R2T? > > > > > On Sun, 2005-03-06 at 15:34, Nicholas A. Bellinger wrote: > > On Sun, 2005-03-06 at 11:14 -0500, Ming Zhang wrote: > > > > > > > > I have used to rule in the iscsi-initiator-core.org initiator > stack > > > > implementation that the Initiator uses the OS'es SCSI Task LUN > inside of > > > > the LUN field for DataOUT PDUs in the solicited DataOUT case. > This > > > > ensures that the LUN from the original PDU containing the SCSI > CDB and > > > > all DataOUT PDUs contain the same value. Please see > > > > iscsi_initiator.c:iscsi_build_data_out() for further details. > > > > > > > This is to say that you are a good guy. :) > > > > > > But does your initiator check the target R2T packet Lun field? > > > > No, and here is the reasoning from 10.7.4: > > > > The Target Transfer Tag values are not specified by this protocol > > except that the value 0xffffffff is reserved and means that the > > Target Transfer Tag is not supplied. If the Target Transfer Tag > is > > provided, then the LUN field MUST hold a valid value and be > > consistent with whatever was specified with the command; > otherwise, > > the LUN field is reserved. > > > > 'Consistent' here meaning the DataOUT should be using the LUN from > the > > original SCSI command PDU, and not what the target may or may not be > > echoing back in an R2T. > as 10.7.4 > > On incoming data, the Target Transfer Tag and LUN MUST be provided > by > the target if the A bit is set to 1; otherwise they are reserved. > The Target Transfer Tag and LUN are copied by the initiator into the > SNACK of type DataACK that it issues as a result of receiving a > SCSI > Data-In PDU with the A bit set to 1. > > so this A bit should be check first, before checking the validity of > LUN > if initiator want to check it. > > > > > All good targets MUST include the original LUN from the SCSI command > PDU > > when they are soliciting DataOUT with R2Ts as specified in 3.2.4.3: > > > > As the Initiator Task Tag is used to identify a task during its > > execution the iSCSI initiator and target MUST verify that all > other > > fields used in task related PDUs have values that are consistent > > with the values used at the task instantiation based on Initiator > > Task Tag (e.g., the LUN used in an R2T PDU MUST be the same as > the > > one used in the SCSI command PDU used to instantiate the task). > > Using inconsistent field values is considered a protocol error. > > > > Aside from these two points, it can be argued there is no MUST > > requirement that the Initiator actually _check_ the LUN in the R2T > > against what it originally sent in the SCSI command, only that the > LUN > > in solicitied DataOUT PDUs be consistant with the LUN from the > original > > SCSI command PDU. > > > > > > > > > On the target side, I have observed in the past that certain > initiators > > > > may not include the correct LUN inside of solicited DataOUT > PDUs, and > > > > hence cause interopt problems. In the PyX Technologies Target > Stack we > > > > leave the check against DataOUT PDU's LUN vs. the original > > > > ISCSI_INIT_SCSI_CMND pdu's LUN stubbed out in order to ensure > interopt > > > > with these initiator implementations. > > > > > > > This is to say that you allow other guys to do something not so > good. :) > > > > > > > Not really. The initiator knows what LUN its DataOUT is destined > for, > > after all, it was the initiator that selected what LUN the original > SCSI > > command PDU was directed towards in the first place. I believe this > > example Jonathan B. Postel's famous observation on network protocol > > design: > > > > "Be liberal in what you accept, and conservative in what you send". > > > > > But the question is, what does the rfc say? and which one strictly > > > follows the standard? > > > > > > > Along with the quoted sections from above, here is my interpretation > of > > what RFC 3720 says for the WRITE case: > > > > Initiator: The LUN field in ISCSI_INIT_SCSI_CMND and > > ISCSI_INIT_SCSI_DATA_OUT PDUs should be from the same data source > (ie: > > the SCSI Task from the Host OS). Since the initiator has the > initial > > choice of what LUN the SCSI Command is destined towards, I believe > its > > up to the implementor to determine if the LUN from the R2T should be > > checked against the original SCSI Command's LUN. ie: The initiator > is > > telling the target what LUN the SCSI Command is destined for, and > not > > the target telling the initiator. > > > > Target: The LUNs in the original SCSI command MUST be copied into > all > > R2Ts. There is no strict requirement that the Target check the LUN > in > > subsequent DataOUT PDUs fullfilling the R2T. > i admit that this is really conservative. :P > > thanks. > > ming > > > > _______________________________________________ > 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 Mar 9 11:13:47 2005 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 LAA20158 for ; Wed, 9 Mar 2005 11:13:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D93rL-0003UJ-MU for ips-web-archive@ietf.org; Wed, 09 Mar 2005 11:16:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D93l6-0003pI-Br; Wed, 09 Mar 2005 11:10:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D93l5-0003og-9J for ips@megatron.ietf.org; Wed, 09 Mar 2005 11:10:03 -0500 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 LAA19740 for ; Wed, 9 Mar 2005 11:10:00 -0500 (EST) Received: from smtp018.mail.yahoo.com ([216.136.174.115]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D93ng-0003Q0-Px for ips@ietf.org; Wed, 09 Mar 2005 11:12:46 -0500 Received: from unknown (HELO 172.10.7.7) (dmitry?yus@24.7.114.77 with plain) by smtp018.mail.yahoo.com with SMTP; 9 Mar 2005 16:09:59 -0000 From: Dmitry Yusupov To: ips@ietf.org Content-Type: text/plain Date: Wed, 09 Mar 2005 08:09:46 -0800 Message-Id: <1110384587.4451.59.camel@mylaptop> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) Content-Transfer-Encoding: 7bit X-Spam-Score: 3.4 (+++) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Content-Transfer-Encoding: 7bit Subject: [Ips] Open-iSCSI High-Performance Initiator for Linux/Unix 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 X-Spam-Score: 3.4 (+++) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Content-Transfer-Encoding: 7bit This is to announce Open-iSCSI project: High-Performance iSCSI Initiator for Linux. Though OpenSolaris port is a work in progress. MOTIVATION ========== Our initial motivations for the project were: (1) implement the right user/kernel split, and (2) design iSCSI data path for performance. Recently we added (3): get accepted into the mainline kernel. As far as user/kernel, the existing iSCSI initiators bloat the kernel with ever-growing control plane code, including but not limited to: iSCSI discovery, Login (Authentication and Operational), session and connection management, connection-level error processing, iSCSI Text, Nop-Out/In, Async Message, iSNS, SLP, Radius... Open-iSCSI puts the entire control plane in the user space. This control plane talks to the data plane via well defined interface over the netlink transport. (Side note: prior to closing on the netlink we considered: sysfs, ioctl, and syscall. Because the entire control plane logic resides in the user space, we needed a real bi-directional transport that could support asynchronous API to transfer iSCSI control PDUs: Login, Logout, Nop-in, Nop-Out, Text, Async Message. Performance. This is the major goal and motivation for this project. As it happens, iSCSI has to compete with Fibre Channel, which is a more entrenched technology in the storage space. In addition, the "soft" iSCSI implementation have to show good results in presence of specialized hardware offloads. Our today's performance numbers are: - 450MB/sec Read on a single connection (2-way 2.4Ghz Opteron, 64KB block size); - 320MB/sec Write on a single connection (2-way 2.4Ghz Opteron, 64KB block size); - 50,000 Read IOPS on a single connection (2-way 2.4Ghz Opteron, 4KB block size). Prior to starting from-scratch the data path code we did evaluate the sfnet Initiator. And eventually decided against patching it. Instead, we reused its Discovery, Login, etc. control plane code. Technically, it was the shortest way to achieve the (1) and (2) goals stated above. We believe that it remains the easiest and the most practical thing on the larger scale of: iSCSI for Linux. STATUS ====== There's a 100% working code that interoperates with all (count=5) iSCSI targets we could get our hands on. The software was tested on AMD Opteron (TM) and Intel Xeon (TM). Code is available online via either Subversion source control database or the latest development release (i.e., the tarball containing Open- iSCSI sources, including user space, that will build and run on kernels starting 2.6.10). http://www.open-iscsi.org Features: - highly optimized and small-footprint data path; - multiple outstanding R2Ts; - thread-less receive; - sendpage() based transmit; - zero-copy header processing on receive; - no data path memory allocations at runtime; - persistent configuration database; - SendTargets discovery; - CHAP; - DataSequenceInOrder=No; - PDU header Digest; - multiple sessions; - MC/S (note: disabled in the patch); - SCSI-level recovery via Abort Task and session re-open. TODO ==== The near term plan is: test, test, and test. We need to stabilize the existing code, after 5 months of development this seems to be the right thing to do. Other short-term plans include: a) process community feedback, implement comments and apply patches; b) cleanup user side of the iSCSI open interface; use API calls (instead of directly constructing events); c) eliminate runtime control path memory allocations (for Nop-In, Nop- Out, etc.); d) implement Write path optimizations (delayed because of the self- imposed submission deadline); e) oProfile the data path, use the reports for further optimization; f) complete the readme. Comments, code reviews, patches - are greatly appreciated! THANKS ====== Special thanks to our first reviewers: Christoph Hellwig and Mike Christie. Special thanks to Ming Zhang for help in testing and for insightful questions. Regards, Alex Aizman & Dmitry Yusupov _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Thu Mar 10 21:57:43 2005 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 VAA07514 for ; Thu, 10 Mar 2005 21:57:43 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9aON-0007g6-87 for ips-web-archive@ietf.org; Thu, 10 Mar 2005 22:00:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9aFM-00053A-Jj; Thu, 10 Mar 2005 21:51:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9aFL-000530-4Q for ips@megatron.ietf.org; Thu, 10 Mar 2005 21:51:27 -0500 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 VAA06738 for ; Thu, 10 Mar 2005 21:51:24 -0500 (EST) Received: from mx1.netapp.com ([216.240.18.38]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9aIF-0007Ki-De for ips@ietf.org; Thu, 10 Mar 2005 21:54:28 -0500 Received: from smtp2.corp.netapp.com (10.57.159.114) by mx1.netapp.com with ESMTP; 10 Mar 2005 18:51:16 -0800 X-IronPort-AV: i="3.90,155,1107763200"; d="scan'208"; a="121256197:sNHT15848592" Received: from netapp.com ([10.58.53.228]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id j2B2pFaZ006861 for ; Thu, 10 Mar 2005 18:51:16 -0800 (PST) Message-ID: <423107A2.40600@netapp.com> Date: Thu, 10 Mar 2005 21:51:14 -0500 From: Dave Wysochanski User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040114 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ips@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Subject: [Ips] "proposed access type specification" 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit I would like to propose a public extension key to the group, however, I'm a little unsure of the format for the proposal. Reading through RFC 3720, it seems I need a "proposed access type specification". I've looked around but I'm still not sure what this lingo means. Can someone point me in the right direction? Thanks. 13.5.1. Present the iSCSI extension item to the Community Send a proposed access type specification to the IPS WG mailing list, or if the IPS WG is disbanded at the registration time, to a mailing list designated by the IETF Transport Area Director for a review period of a month. The intent of the public posting is to solicit comments and feedback on the iSCSI extension item specification and a review of any security considerations. _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Fri Mar 11 15:27:19 2005 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 PAA04939 for ; Fri, 11 Mar 2005 15:27:18 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9qmE-0000Hr-Vu for ips-web-archive@ietf.org; Fri, 11 Mar 2005 15:30:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9qiO-0004xw-PI; Fri, 11 Mar 2005 15:26:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9qiM-0004xi-JM for ips@megatron.ietf.org; Fri, 11 Mar 2005 15:26:30 -0500 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 PAA04901 for ; Fri, 11 Mar 2005 15:26:29 -0500 (EST) Received: from mononoke.wasabisystems.com ([66.173.145.228]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9qlP-0000Bj-TI for ips@ietf.org; Fri, 11 Mar 2005 15:29:41 -0500 Received: from [10.0.0.10] (h-66-166-188-62.sndacagl.covad.net [66.166.188.62]) by mononoke.wasabisystems.com (Postfix) with ESMTP id F1883870A4; Fri, 11 Mar 2005 15:26:25 -0500 (EST) In-Reply-To: <423107A2.40600@netapp.com> References: <423107A2.40600@netapp.com> Mime-Version: 1.0 (Apple Message framework v619.2) Message-Id: <28e94592bb3feec7ebee6bf123a37205@wasabisystems.com> From: William Studenmund Subject: Re: [Ips] "proposed access type specification" Date: Fri, 11 Mar 2005 12:26:18 -0800 To: Dave Wysochanski X-Pgp-Agent: GPGMail 1.0 (v30, 10.3) X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 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="===============1751345538==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 --===============1751345538== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-3--878407502" --Apple-Mail-3--878407502 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Mar 10, 2005, at 6:51 PM, Dave Wysochanski wrote: > I would like to propose a public extension key to the group, however, > I'm a little unsure of the format for the proposal. Reading through > RFC 3720, it seems I need a "proposed access type specification". > I've looked around but I'm still not sure what this lingo means. Can > someone point me in the right direction? I think the first step is an informal proposal. What exactly do you want to add? :-) Take care, Bill --Apple-Mail-3--878407502 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) iD8DBQFCMf7wDJT2Egh26K0RApgfAKCD2KqnvSJLzHDlzgpgxgXY/sewAwCfaxQ5 92EkEt2KRovD0PuqRgF6s7U= =PSk5 -----END PGP SIGNATURE----- --Apple-Mail-3--878407502-- --===============1751345538== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============1751345538==-- From ips-bounces@ietf.org Fri Mar 11 16:00:23 2005 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 QAA07016 for ; Fri, 11 Mar 2005 16:00:23 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9rIE-0001tq-Rc for ips-web-archive@ietf.org; Fri, 11 Mar 2005 16:03:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9rE0-0002Qo-Bf; Fri, 11 Mar 2005 15:59:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9rDz-0002Qc-K8 for ips@megatron.ietf.org; Fri, 11 Mar 2005 15:59:11 -0500 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 PAA06944 for ; Fri, 11 Mar 2005 15:59:10 -0500 (EST) Received: from mx2.netapp.com ([216.240.18.37]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9rH3-0001nN-8Y for ips@ietf.org; Fri, 11 Mar 2005 16:02:22 -0500 Received: from smtp2.corp.netapp.com (10.57.159.114) by mx2.netapp.com with ESMTP; 11 Mar 2005 12:58:59 -0800 X-IronPort-AV: i="3.90,157,1107763200"; d="txt'?scan'208"; a="181353506:sNHT21176740" Received: from netapp.com (davidw-suse.hq.netapp.com [10.60.8.108]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id j2BKwwv2018126 for ; Fri, 11 Mar 2005 12:58:58 -0800 (PST) Message-ID: <42320691.7090703@netapp.com> Date: Fri, 11 Mar 2005 15:58:57 -0500 From: David Wysochanski User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030821 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ips@ietf.org X-Enigmail-Version: 0.76.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/mixed; boundary="------------000604050903000206050605" X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Subject: [Ips] Proposed Declarative Public Extension Key - X#NodeArchitecture 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d This is a multi-part message in MIME format. --------------000604050903000206050605 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit --------------000604050903000206050605 Content-Type: text/plain; name="X-keys-for-enhanced-iscsi-supportability-ietf-v0.4.txt" Content-Disposition: inline; filename="X-keys-for-enhanced-iscsi-supportability-ietf-v0.4.txt" Content-Transfer-Encoding: 7bit Declarative Public Extension Key to Enhance iSCSI Supportability This proposal identifies a declarative Public Extension Key as defined by section 12.22 of RFC 3720 that may be used to communicate additional iSCSI node information to the opposite node in a session. The information carried in the proposed key has been found to be valuable in real iSCSI customer environments as initiator and target vendors collaborate to resolve technical issues and better understand the evolving iSCSI market. The following proposed Public Extension Key is sent during the login phase of an iSCSI normal session. It is important to note that the intent of providing this key is for better understanding of customer environments. The key MUST NOT be used by iSCSI nodes for things such as interoperability, performance, exclusion or deception of other nodes, or other uses not defined by this proposal. To enforce proper use, iSCSI nodes MUST NOT allow user modification of the key value(s), but MUST set the value automatically based on standard internal interfaces. In certain environments where security is a primary concern, the use of this key MAY NOT be appropriate as it reveals specific details about an iSCSI node. For these environments, nodes implementing this public extension key MUST provide a method to disable sending the key. The definition of the proposed key is as follows, with example text-values conforming to section 5.1 of RFC 3720. X#NodeArchitecture Use: LO, Declarative Senders: Initiator and Target Scope: SW X#NodeArchitecture= Examples: X#NodeArchitecture="os-v1.2.3.4,iscsi-vendor-software-v1.2.3.4" X#NodeArchitecture="os-v1.2.3.4,cpu-type-x,cpu-speed-2.0ghz, iscsi-vendor-hardware-v1.2.3.4, iscsi-vendor-firmware-v1.2.3.4" The initiator or target declares the details of its iSCSI node architecture to the remote endpoint. These details may include, but are not limited to, the OS version, CPU or hardware architecture, iSCSI vendor software and/or firmware version, iSCSI vendor hardware revision, and so on. NodeArchitecture MUST NOT be redeclared. --------------000604050903000206050605 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --------------000604050903000206050605-- From ips-bounces@ietf.org Fri Mar 11 16:01:15 2005 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 QAA07111 for ; Fri, 11 Mar 2005 16:01:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9rJ4-0001vP-U1 for ips-web-archive@ietf.org; Fri, 11 Mar 2005 16:04:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9rCP-0002KY-SY; Fri, 11 Mar 2005 15:57:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9rCN-0002KT-To for ips@megatron.ietf.org; Fri, 11 Mar 2005 15:57:31 -0500 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 PAA06800 for ; Fri, 11 Mar 2005 15:57:30 -0500 (EST) Received: from mx1.netapp.com ([216.240.18.38]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9rFR-0001d0-Se for ips@ietf.org; Fri, 11 Mar 2005 16:00:43 -0500 Received: from smtp2.corp.netapp.com (10.57.159.114) by mx1.netapp.com with ESMTP; 11 Mar 2005 12:57:21 -0800 X-IronPort-AV: i="3.90,157,1107763200"; d="scan'208"; a="123312553:sNHT16079032" Received: from netapp.com (davidw-suse.hq.netapp.com [10.60.8.108]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id j2BKvKdQ017887; Fri, 11 Mar 2005 12:57:20 -0800 (PST) Message-ID: <42320630.6060905@netapp.com> Date: Fri, 11 Mar 2005 15:57:20 -0500 From: David Wysochanski User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030821 X-Accept-Language: en-us, en MIME-Version: 1.0 To: William Studenmund , William Studenmund Subject: Re: [Ips] "proposed access type specification" References: <423107A2.40600@netapp.com> <28e94592bb3feec7ebee6bf123a37205@wasabisystems.com> In-Reply-To: <28e94592bb3feec7ebee6bf123a37205@wasabisystems.com> X-Enigmail-Version: 0.76.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit William Studenmund wrote: > > On Mar 10, 2005, at 6:51 PM, Dave Wysochanski wrote: > >> I would like to propose a public extension key to the group, however, >> I'm a little unsure of the format for the proposal. Reading through >> RFC 3720, it seems I need a "proposed access type specification". >> I've looked around but I'm still not sure what this lingo means. Can >> someone point me in the right direction? > > > I think the first step is an informal proposal. What exactly do you want > to add? :-) > > Take care, > > Bill Ok, I'll just post what I have. _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Fri Mar 11 17:28:42 2005 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 RAA13770 for