From ips-bounces@ietf.org Sun Jul 02 06:48:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwzV8-0000Tx-24; Sun, 02 Jul 2006 06:48:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwzV7-0000Ts-8A for ips@ietf.org; Sun, 02 Jul 2006 06:48:29 -0400 Received: from taurus.voltaire.com ([193.47.165.240]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwzV4-0001Lf-Se for ips@ietf.org; Sun, 02 Jul 2006 06:48:29 -0400 Received: from [172.25.5.24] ([172.25.5.24]) by taurus.voltaire.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 2 Jul 2006 13:48:17 +0300 Message-ID: <44A7A470.4070404@voltaire.com> Date: Sun, 02 Jul 2006 13:48:16 +0300 From: Erez Zilber User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: ips@ietf.org X-OriginalArrivalTime: 02 Jul 2006 10:48:17.0251 (UTC) FILETIME=[06A93B30:01C69DC5] X-Spam-Score: 1.2 (+) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Subject: [Ips] Receiving a SCSI response after abort task was sent 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="===============1477084557==" Errors-To: ips-bounces@ietf.org --===============1477084557== Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi,

I have a question about aborting tasks: when an initiator sends "abort task" to the target, it is possible that the target will send a SCSI response for the same task before receiving the abort task (I guess that the target won't send a task management response for the abort task). What should the initiator do with the SCSI response? Is the host that issued the abort task willing to receive a SCSI response for that task? Is it willing to receive only a task management response for the abort task?

This message was also sent to linux-scsi mailing list.

Thanks
--
Main Signature Signature

____________________________________________________________

Erez Zilber   |  972-9-971-7689

Software Engineer, Storage Team

Voltaire – The Grid Backbone

 

 www.voltaire.com

 

--===============1477084557== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============1477084557==-- From ips-bounces@ietf.org Mon Jul 03 09:54:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxOsV-0004Ms-Rp; Mon, 03 Jul 2006 09:54:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxOsU-0004Mk-K5 for ips@ietf.org; Mon, 03 Jul 2006 09:54:18 -0400 Received: from mexforward.lss.emc.com ([128.222.32.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxOsS-0006JE-5p for ips@ietf.org; Mon, 03 Jul 2006 09:54:18 -0400 Received: from mailhub.lss.emc.com (nagas.lss.emc.com [10.254.144.11]) by mexforward.lss.emc.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k63DsFCk016818; Mon, 3 Jul 2006 09:54:15 -0400 (EDT) Received: from mxic2.corp.emc.com (mxic2.corp.emc.com [128.221.12.9]) by mailhub.lss.emc.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k63DsB3u020536; Mon, 3 Jul 2006 09:54:14 -0400 (EDT) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Mon, 3 Jul 2006 09:54:11 -0400 Message-ID: From: Black_David@emc.com To: erezz@voltaire.com, ips@ietf.org Subject: RE: [Ips] Receiving a SCSI response after abort task was sent Date: Mon, 3 Jul 2006 09:54:04 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.7.3.61432 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -2, HTML_70_90 0.1, NO_REAL_NAME 0, __C230066_P5 0, __CP_URI_IN_BODY 0, __CT 0, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0, __CTYPE_MULTIPART_ALT 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __HTML_FONT_BLUE 0, __IMS_MSGID 0, __IMS_MUA 0, __MIME_HTML 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0, __TAG_EXISTS_HTML 0' X-Spam-Score: 0.2 (/) X-Scan-Signature: 7f3fa64b9851a63d7f3174ef64114da7 Cc: X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1445562284==" Errors-To: ips-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1445562284== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C69EA7.D48DFF8C" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C69EA7.D48DFF8C Content-Type: text/plain Erez, > I have a question about aborting tasks: when an initiator sends "abort task" to the target, > it is possible that the target will send a SCSI response for the same task before receiving the > abort task (I guess that the target won't send a task management response for the abort task). Yes and (No) in that order. The "abort task" task management function is defined to succeed when the task does not exist - the response will indicate success in this situation. > What should the initiator do with the SCSI response? Process it normally, as it would any other SCSI Response. > Is the host that issued the abort task willing to receive a SCSI response for that task? > Is it willing to receive only a task management response for the abort task? Yes and No in that order, the SCSI response is possible and must be handled. There will always be a task management response, independent of whether the SCSI response is issued. One important rule is that the SCSI response cannot occur *after* the task management response. 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 ---------------------------------------------------- _____ From: Erez Zilber [mailto:erezz@voltaire.com] Sent: Sunday, July 02, 2006 6:48 AM To: ips@ietf.org Subject: [Ips] Receiving a SCSI response after abort task was sent Hi, I have a question about aborting tasks: when an initiator sends "abort task" to the target, it is possible that the target will send a SCSI response for the same task before receiving the abort task (I guess that the target won't send a task management response for the abort task). What should the initiator do with the SCSI response? Is the host that issued the abort task willing to receive a SCSI response for that task? Is it willing to receive only a task management response for the abort task? This message was also sent to linux-scsi mailing list. Thanks -- ____________________________________________________________ Erez Zilber | 972-9-971-7689 Software Engineer, Storage Team Voltaire - The Grid Backbone www.voltaire.com ------_=_NextPart_001_01C69EA7.D48DFF8C Content-Type: text/html Main Signature Signature
Erez,
 
> I have a question about aborting tasks: when an initiator sends "abort task" to the target,
> it is possible that the target will send a SCSI response for the same task before receiving the
> abort task (I guess that the target won't send a task management response for the abort task).
 
Yes and (No) in that order.  The "abort task" task management function
is defined to succeed when the task does not exist - the response will
indicate success in this situation.
 
> What should the initiator do with the SCSI response?
 
Process it normally, as it would any other SCSI Response.
 
> Is the host that issued the abort task willing to receive a SCSI response for that task?
> Is it willing to receive only a task management response for the abort task?
 
Yes and No in that order, the SCSI response is possible and must be
handled.  There will always be a task management response, independent
of whether the SCSI response is issued.  One important rule is that
the SCSI response cannot occur *after* the task management response.
 
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
----------------------------------------------------

From: Erez Zilber [mailto:erezz@voltaire.com]
Sent: Sunday, July 02, 2006 6:48 AM
To: ips@ietf.org
Subject: [Ips] Receiving a SCSI response after abort task was sent

Hi,

I have a question about aborting tasks: when an initiator sends "abort task" to the target, it is possible that the target will send a SCSI response for the same task before receiving the abort task (I guess that the target won't send a task management response for the abort task). What should the initiator do with the SCSI response? Is the host that issued the abort task willing to receive a SCSI response for that task? Is it willing to receive only a task management response for the abort task?

This message was also sent to linux-scsi mailing list.

Thanks
--

____________________________________________________________

Erez Zilber   |  972-9-971-7689

Software Engineer, Storage Team

Voltaire – The Grid Backbone

 www.voltaire.com

 

------_=_NextPart_001_01C69EA7.D48DFF8C-- --===============1445562284== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============1445562284==-- From ips-bounces@ietf.org Mon Jul 03 12:17:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxR6k-0001s4-Gg; Mon, 03 Jul 2006 12:17:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxR6j-0001rz-0C for ips@ietf.org; Mon, 03 Jul 2006 12:17:09 -0400 Received: from mtagate2.de.ibm.com ([195.212.29.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxR6h-0000tB-G9 for ips@ietf.org; Mon, 03 Jul 2006 12:17:08 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate2.de.ibm.com (8.13.6/8.13.6) with ESMTP id k63GH6xd160444 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 3 Jul 2006 16:17:06 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.13.6/NCO/VER7.0) with ESMTP id k63GJlBd145474 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 3 Jul 2006 18:19:47 +0200 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id k63GH6EQ032415 for ; Mon, 3 Jul 2006 18:17:06 +0200 Received: from d12mc102.megacenter.de.ibm.com (d12mc102.megacenter.de.ibm.com [9.149.167.114]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k63GH6E4032412; Mon, 3 Jul 2006 18:17:06 +0200 In-Reply-To: <44A7A470.4070404@voltaire.com> To: Erez Zilber Subject: Re: [Ips] Receiving a SCSI response after abort task was sent MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 From: Julian Satran Message-ID: Date: Mon, 3 Jul 2006 19:19:43 +0300 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 7.0.1HF123 | April 14, 2006) at 03/07/2006 19:19:46, Serialize complete at 03/07/2006 19:19:46 X-Spam-Score: 0.1 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 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="===============1848610488==" Errors-To: ips-bounces@ietf.org This is a multipart message in MIME format. --===============1848610488== Content-Type: multipart/alternative; boundary="=_alternative 0058F82CC22571A0_=" This is a multipart message in MIME format. --=_alternative 0058F82CC22571A0_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Erez Zilber wrote on 02/07/2006 13:48:16: > Hi, >=20 > I have a question about aborting tasks: when an initiator sends=20 > "abort task" to the target, it is possible that the target will send > a SCSI response for the same task before receiving the abort task (I > guess that the target won't send a task management response for the=20 > abort task).=20 That can happen - however the target has to send the response to task=20 management. > What should the initiator do with the SCSI response?=20 > Is the host that issued the abort task willing to receive a SCSI=20 > response for that task? Is it willing to receive only a task=20 > management response for the abort task? >=20 It has to be ready to get a SCSI response BEFORE the task abort report. It may react badly if it receives a SCSI response AFTER the task abort=20 response (that is forbidden by SCSI). > This message was also sent to linux-scsi mailing list. >=20 > Thanks > --=20 > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > Erez Zilber | 972-9-971-7689 > Software Engineer, Storage Team > Voltaire ? The Grid Backbone >=20 > www.voltaire.com > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips --=_alternative 0058F82CC22571A0_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable

Erez Zilber <erezz@voltaire.com> wrote on 02/0= 7/2006 13:48:16:

> Hi,
>
> I have a question about aborting tasks: when an initiator sends
> "abort task" to the target, it is possible that the target will send
> a SCSI response for the same task before receiving the abort task (I
> guess that the target won't send a task management response for the
> abort task).

That can happen - however the target has to send the response to task management.

> What should the initiator do with the SCSI resp= onse?
> Is the host that issued the abort task willing to receive a SCSI
> response for that task? Is it willing to receive only a task
> management response for the abort task?
>

It has to be ready to get a SCSI response BEFORE the task abort report.
It may react badly if it receives a SCSI response AFTER the task abort response (that is forbidden by SCSI).

> This message was also sent to linux-scsi mailing list.
>
> Thanks
> --
> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
> Erez Zilber   |  972-9-971-7689
> Software Engineer, Storage Team
> Voltaire – The Grid Backbone
>  
>  www.voltaire.com
>   =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F
> Ips mailing list
> Ips@ietf.org
> https://www1.ietf.org/mailman/listinfo/ips
 --=_alternative 0058F82CC22571A0_=-- --===============1848610488== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============1848610488==-- From ips-bounces@ietf.org Mon Jul 03 13:18:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxS4H-0002TU-TC; Mon, 03 Jul 2006 13:18:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxS4G-0002TP-Kp for ips@ietf.org; Mon, 03 Jul 2006 13:18:40 -0400 Received: from mail74.messagelabs.com ([216.82.244.99]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FxS4F-0003z6-5F for ips@ietf.org; Mon, 03 Jul 2006 13:18:40 -0400 X-VirusChecked: Checked X-Env-Sender: rsnively@Brocade.COM X-Msg-Ref: server-13.tower-74.messagelabs.com!1151947114!68275628!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [66.243.153.112] Received: (qmail 22184 invoked from network); 3 Jul 2006 17:18:34 -0000 Received: from f112.brocade.com (HELO scooby.brocade.com) (66.243.153.112) by server-13.tower-74.messagelabs.com with SMTP; 3 Jul 2006 17:18:34 -0000 Received: from hq-exch-1.corp.brocade.com (hq-exch-1.brocade.com [10.3.8.21]) by scooby.brocade.com (Postfix) with ESMTP id 5FFEE25801A; Mon, 3 Jul 2006 10:16:34 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ips] Receiving a SCSI response after abort task was sent Date: Mon, 3 Jul 2006 10:18:27 -0700 Message-ID: <6002A63FDB393D4F9ADB36DE70C484754F066C@hq-exch-1.corp.brocade.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ips] Receiving a SCSI response after abort task was sent Thread-Index: AcaeqEQinjvxktelQse5LEpFWRaPhwAG5JyQ From: "Robert Snively" To: , , X-Spam-Score: 0.0 (/) X-Scan-Signature: 7b8e6f6ef974ecda19a6b57d59caeb7d Cc: X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0898050161==" Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============0898050161== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C69EC4.B6B0C006" This is a multi-part message in MIME format. ------_=_NextPart_001_01C69EC4.B6B0C006 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable With one minor warning, I agree with David. =20 Warning below: ________________________________ From: Black_David@emc.com [mailto:Black_David@emc.com]=20 Sent: Monday, July 03, 2006 6:54 AM To: erezz@voltaire.com; ips@ietf.org Subject: RE: [Ips] Receiving a SCSI response after abort task was sent Erez, =20 > I have a question about aborting tasks: when an initiator sends "abort task" to the target, > it is possible that the target will send a SCSI response for the same task before receiving the > abort task (I guess that the target won't send a task management response for the abort task). =20 Yes and (No) in that order. The "abort task" task management function is defined to succeed when the task does not exist - the response will indicate success in this situation. =20 > What should the initiator do with the SCSI response? =20 Process it normally, as it would any other SCSI Response. =20 > Is the host that issued the abort task willing to receive a SCSI response for that task? > Is it willing to receive only a task management response for the abort task? =20 Yes and No in that order, the SCSI response is possible and must be handled. There will always be a task management response, independent of whether the SCSI response is issued. One important rule is that the SCSI response cannot occur *after* the task management response.=20 =20 In some technologies and under some conditions, it is hypothetically possible for a SCSI response to appear at an initiator after the task management response. In such environments, this will be detected as a SCSI response for which there is no SCSI request and it will be discarded.=20 Since TCP/IP forces in-order behavior on the SCSI stream, and since the abort task is normally sent through the same stream as the command, this normally may be ignored by iSCSI. =20 Thanks, --David ----------------------------------------------------=20 David L. Black, Senior Technologist=20 EMC Corporation, 176 South St., Hopkinton, MA 01748=20 +1 (508) 293-7953 FAX: +1 (508) 293-7786=20 black_david@emc.com Mobile: +1 (978) 394-7754=20 ----------------------------------------------------=20 ________________________________ From: Erez Zilber [mailto:erezz@voltaire.com]=20 Sent: Sunday, July 02, 2006 6:48 AM To: ips@ietf.org Subject: [Ips] Receiving a SCSI response after abort task was sent =09 =09 Hi, =09 I have a question about aborting tasks: when an initiator sends "abort task" to the target, it is possible that the target will send a SCSI response for the same task before receiving the abort task (I guess that the target won't send a task management response for the abort task). What should the initiator do with the SCSI response? Is the host that issued the abort task willing to receive a SCSI response for that task? Is it willing to receive only a task management response for the abort task? =09 This message was also sent to linux-scsi mailing list. =09 Thanks =09 --=20 =09 ____________________________________________________________ Erez Zilber | 972-9-971-7689 Software Engineer, Storage Team Voltaire - The Grid Backbone =09 www.voltaire.com =20 =09 =20 =09 ------_=_NextPart_001_01C69EC4.B6B0C006 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Main Signature Signature
With one minor warning, I agree with=20 David.
 
Warning below:

From: Black_David@emc.com=20 [mailto:Black_David@emc.com]
Sent: Monday, July 03, 2006 6:54 = AM
To: erezz@voltaire.com; ips@ietf.org
Subject: RE: = [Ips]=20 Receiving a SCSI response after abort task was sent

Erez,
 
> = I have a=20 question about aborting tasks: when an initiator sends "abort task" to = the=20 target,
> = it is=20 possible that the target will send a SCSI response for the same task = before=20 receiving the
> = abort task (I=20 guess that the target won't send a task management response for the = abort=20 task).
 
Yes and (No) in that order.  The "abort task" task = management=20 function
is defined to succeed when the task does not exist - the = response=20 will
indicate success in this = situation.
 
> = What should=20 the initiator do with the SCSI response?
 
Process it normally, as it would any other SCSI = Response.
 
> = Is the host=20 that issued the abort task willing to receive a SCSI response for that=20 task?
> = Is it willing=20 to receive only a task management response for the abort task?
 
Yes and No in that order, the SCSI response is possible and = must=20 be
handled.  There will always be a task management = response,=20 independent
of whether the SCSI response is issued.  One = important rule=20 is that
the SCSI response cannot occur *after* the task management=20 response. 
 
In some technologies and under some conditions, it is=20 hypothetically possible for a = SCSI
response to appear at an initiator after the task = management=20 response.  In such environments, this=20 will
be detected as a SCSI response for which there is no = SCSI request=20 and it will be discarded. 
Since = TCP/IP forces=20 in-order behavior on the SCSI stream, and since the abort task=20 is
normally = sent through=20 the same stream as the command, this normally may be=20 ignored
by=20 iSCSI.
 
Thanks,
--David
----------------------------------------------------=20
David L. = Black, Senior=20 Technologist
EMC Corporation, 176 South St., Hopkinton, MA  = 01748=20
+1 (508)=20 293-7953           = ; =20 FAX: +1 (508) 293-7786
black_david@emc.com        = Mobile: +1=20 (978) 394-7754
----------------------------------------------------=20

From: Erez Zilber = [mailto:erezz@voltaire.com]=20
Sent: Sunday, July 02, 2006 6:48 AM
To:=20 ips@ietf.org
Subject: [Ips] Receiving a SCSI response after = abort=20 task was sent

Hi,

I have a question about aborting tasks: when an=20 initiator sends "abort task" to the target, it is possible that the = target=20 will send a SCSI response for the same task before receiving the abort = task (I=20 guess that the target won't send a task management response for the = abort=20 task). What should the initiator do with the SCSI response? Is the = host that=20 issued the abort task willing to receive a SCSI response for that = task? Is it=20 willing to receive only a task management response for the abort=20 task?

This message was also sent to linux-scsi mailing=20 list.

Thanks
--

____________________________________________________________

Erez=20 Zilber   | =20 972-9-971-7689

Software=20 Engineer, Storage Team

Voltaire=20 – The Grid Backbone

 www.voltaire.com<= /P>

 

= ------_=_NextPart_001_01C69EC4.B6B0C006-- --===============0898050161== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0898050161==-- From ips-bounces@ietf.org Wed Jul 05 13:47:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyBTY-0000rp-5A; Wed, 05 Jul 2006 13:47:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyBTW-0000rk-7M for ips@ietf.org; Wed, 05 Jul 2006 13:47:46 -0400 Received: from mononoke.wasabisystems.com ([66.173.145.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyBTU-0006dq-P0 for ips@ietf.org; Wed, 05 Jul 2006 13:47:46 -0400 Received: from [10.0.0.10] (h-66-166-188-91.sndacagl.covad.net [66.166.188.91]) by mononoke.wasabisystems.com (Postfix) with ESMTP id C3192871D3; Wed, 5 Jul 2006 13:47:40 -0400 (EDT) In-Reply-To: <6002A63FDB393D4F9ADB36DE70C484754F066C@hq-exch-1.corp.brocade.com> References: <6002A63FDB393D4F9ADB36DE70C484754F066C@hq-exch-1.corp.brocade.com> Mime-Version: 1.0 (Apple Message framework v750) Message-Id: <1B4F171F-768B-4A0A-9F97-0CF1B77F044E@wasabisystems.com> From: William Studenmund Subject: Re: [Ips] Receiving a SCSI response after abort task was sent Date: Wed, 5 Jul 2006 10:47:34 -0700 To: Robert Snively X-Pgp-Agent: GPGMail 1.1.2 (Tiger) X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 Cc: ips@ietf.org, Black_David@emc.com X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0113240271==" Errors-To: ips-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0113240271== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-2--131721202" Content-Transfer-Encoding: 7bit This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-2--131721202 Content-Type: multipart/alternative; boundary=Apple-Mail-1--131721319 --Apple-Mail-1--131721319 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Jul 3, 2006, at 10:18 AM, Robert Snively wrote: > With one minor warning, I agree with David. > > Warning below: > > > Is the host that issued the abort task willing to receive a SCSI > response for that task? > > Is it willing to receive only a task management response for the > abort task? > > Yes and No in that order, the SCSI response is possible and must be > handled. There will always be a task management response, independent > of whether the SCSI response is issued. One important rule is that > the SCSI response cannot occur *after* the task management response. > > In some technologies and under some conditions, it is > hypothetically possible for a SCSI > response to appear at an initiator after the task management > response. In such environments, this will > be detected as a SCSI response for which there is no SCSI request > and it will be discarded. > Since TCP/IP forces in-order behavior on the SCSI stream, and since > the abort task is > normally sent through the same stream as the command, this normally > may be ignored > by iSCSI. I don't think this is a concern, because the ABORT TASK MUST be on the same connection (section 10.5.1, page 131 of RFC 3720) as the command in question. Thus StatSN numbering for the two is in the same number space. The SCSI response should have a lower StatSN than the TMF response as StatSN is the only real way to determine what is "before" or "after", and we are talking about the case where the task finished "before" the abort. So as the initiator processes StatSN responses, it will see the SCSI response "before" the TMF response. As long as any other iSCSI transport (other than TCP) retains StatSN, this will work right. Take care, Bill --Apple-Mail-1--131721319 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
On Jul 3, 2006, at = 10:18 AM, Robert Snively wrote:

With one minor warning, I = agree with David.
=A0
Warning below:

=
> Is the host that issued the = abort task willing to receive a SCSI response for that task?
> = Is it willing to receive only a task management response for the = abort task?
=A0
Yes = and No in that order, the SCSI response is possible and must = be
handled.=A0 There = will always be a task management response, = independent
of = whether the SCSI response is issued.=A0 One = important rule is that
the SCSI response cannot = occur *after* the task management response.=A0
=A0
In = some technologies and under some conditions, it is hypothetically = possible for a SCSI
response to appear at an initiator after the task = management response.=A0 In such environments, this = will
be detected as a SCSI response for = which there is no SCSI request and it will be = discarded.=A0
Since = TCP/IP forces in-order behavior on the SCSI stream, and since the abort = task is
normally sent through the same stream as = the command, this normally may be = ignored
by = iSCSI.

I = don't think this is a concern, because the ABORT TASK MUST be on the = same connection (section 10.5.1, page 131 of RFC 3720)=A0as the command = in question. Thus StatSN numbering for the two is in the same number = space. The SCSI response should have a lower StatSN than the TMF = response as StatSN is the only real way to determine what is "before" or = "after", and we are talking about the case where the task finished = "before" the abort.

So as the initiator = processes StatSN responses, it will see the SCSI response "before" the = TMF response.

As long as any other iSCSI = transport (other than TCP) retains StatSN, this will work = right.

Take = care,

Bill
= --Apple-Mail-1--131721319-- --Apple-Mail-2--131721202 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.4.1 (Darwin) iD8DBQFEq/s7DJT2Egh26K0RAo2jAJ9eEWbKhMIwAvQwt20BRbgf8swUxwCfVstW Lgln/Jl5CLpYii88AinBqCE= =AuGZ -----END PGP SIGNATURE----- --Apple-Mail-2--131721202-- --===============0113240271== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0113240271==-- From ips-bounces@ietf.org Fri Jul 07 14:55:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyvTk-0002Gf-Pu; Fri, 07 Jul 2006 14:55:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyvTj-0002Ga-60 for ips@ietf.org; Fri, 07 Jul 2006 14:55:03 -0400 Received: from mx2.netapp.com ([216.240.18.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyvTi-0001Sn-D7 for ips@ietf.org; Fri, 07 Jul 2006 14:55:03 -0400 Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2.netapp.com with ESMTP; 07 Jul 2006 11:55:02 -0700 X-IronPort-AV: i="4.06,218,1149490800"; d="txt'?scan'208"; a="391662912:sNHT92034912" Received: from [10.61.17.67] ([10.61.17.67]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id k67It0SF025707 for ; Fri, 7 Jul 2006 11:55:01 -0700 (PDT) Message-ID: <44AEAB1D.5020206@netapp.com> Date: Fri, 07 Jul 2006 14:42:37 -0400 From: David Wysochanski User-Agent: Thunderbird 1.5.0.2 (X11/20060420) MIME-Version: 1.0 To: ips@ietf.org Content-Type: multipart/mixed; boundary="------------080509070508050703040803" X-Spam-Score: 0.0 (/) X-Scan-Signature: 28dc73ba51024f450a593b05aa945739 Subject: [Ips] Updates to draft-ietf-ips-iscsi-nodearch-key-00.txt 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: , Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --------------080509070508050703040803 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Attached is an updated version of draft-ietf-ips-iscsi-nodearch-key which addresses all of the remaining items on my list. Comments welcome. Note that I will not be attending the Montreal meeting. However, my colleage, Tom Talpey should be in attendance. Significant changes are: 1. p. 2. Updated usage paragraph. This seemed a little vague, so I tried to make it more specific and focus on prevention of the previous problem with JavaScript. I also loosened the requirement for setting the key value automatically to a SHOULD instead of a MUST (based on another reviewer comment). 2. p. 4. Security updates related to logging and different levels of risk for nodes. These ideas came from a computer security reviewer, and I believe address important issues. List of all changes (verified via RFC diff tool below) draft-ietf-ips-iscsi-nodearch-key-00.txt draft-ietf-ips-iscsi-nodearch-key-01r1.txt - p. 2: Modified proper use paragraph - p. 3: fix typeo - p. 4: fix typeo - p. 4: added paragraphs 3-5 - p. 8: added another contributor http://www1.tools.ietf.org/tools/rfcdiff/rfcdiff.pyht --------------080509070508050703040803 Content-Type: text/plain; name="draft-ietf-ips-iscsi-nodearch-key-01r1.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="draft-ietf-ips-iscsi-nodearch-key-01r1.txt" INTERNET-DRAFT Dave Wysochanski Expires: November 4, 2006 Network Appliance, Inc May 4, 2006 Declarative Public Extension Key for iSCSI Node Architecture draft-ietf-ips-iscsi-nodearch-key-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on November 4, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract The iSCSI protocol, described in [RFC3720], allows for extension items to the protocol in the form of Private or Public Extension Keys. This Internet-Draft describes a Public Extension Key for the purpose of enhancing iSCSI supportability. The key accomplishes this objective by allowing iSCSI nodes to communicate architecture details during the iSCSI login sequence. The receiving node can then use this information for enhanced logging and support. Wysochanski Expires November 4, 2006 [Page 1] Internet-Draft iSCSI Node Architecture July 2006 1. Introduction 1.1 Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 1.2 Overview This Internet-Draft describes a declarative Public Extension Key as defined by section 12.22 of [RFC3720] that may be used to communicate additional iSCSI node information to the opposite node in a session. The information carried in the described 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 key has been modeled after the "Server" and "User-Agent" header fields as specified in sections 14.38 and 14.43 of [RFC2616], with the text-value(s) of the key roughly equivalent to Product Tokens in section 3.8 of [RFC2616]. Note however that the text-value(s) in the keys list-of-values MUST conform to the Text Format as specified in section 5.1 of [RFC3720]. The key is sent during the login phase of an iSCSI normal session. The intended use of this key is to provide enhanced logging and support capabilities, and to enable collection of iSCSI implementation and usage information. The protocol logic of the iSCSI stack (SCSI, iSCSI, and TCP/IP protocols) MUST NOT depend on the presence, absence, or content of the key. The key MUST NOT be used by iSCSI nodes for interoperability, or exclusion or deception of other nodes. To ensure proper use, key values SHOULD be set by the node itself, and there SHOULD NOT be provisions for the key values to be modified by end users or system administrators. Wysochanski Expires November 4, 2006 [Page 2] Internet-Draft iSCSI Node Architecture July 2006 2. Definition The definition of the key is as follows, with example list-of-values conforming to section 5.1 of [RFC3720]. X#NodeArchitecture Use: LO, Declarative Senders: Initiator and Target Scope: SW X#NodeArchitecture= Examples: X#NodeArchitecture="Microsoft Software Initiator/1.05a, Microsoft Windows/2003Build1489, Microsoft Cluster Services/2.0, CPU Architecture/x86_64" X#NodeArchitecture="Qlogic iSCSI 4010 Hardware Initiator/rev1, Qlogic Firmware/2.0.0.5, Qlogic Driver/2.0.0.1" X#NodeArchitecture="Linux iSCSI Software Initiator/4:0.1.11-3, Red Hat Enterprise Linux/4u3, Linux Kernel/2.6.9-34.26.ELsmp, CPU Architecture/i686, CPU Speed/3.06GHz, Memory Size/4059364kB" X#NodeArchitecture="NetApp Software Target/7.1, Data ONTAP/7.1, NetApp FAS/270c" 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, iSCSI vendor software, firmware, or hardware versions, the OS version, or hardware architecture. X#NodeArchitecture MUST NOT be redeclared. Wysochanski Expires November 4, 2006 [Page 3] Internet-Draft iSCSI Node Architecture July 2006 3. Security Considerations This extension key transmits specific implementation details about the node that sends it; such details may be considered sensitive in some environments. For example, if a certain software or firmware version is known to contain security weaknesses, announcing the presence of that version via this key may not be desirable. The countermeasures for this security concern are: - sending less detailed information in the key values, or - not sending the extension key, or - using IPsec to provide confidentiality for the iSCSI connection on which the key is sent (see [RFC3720] and [RFC3723]). To support the first and second countermeasures, all implementations of this extension key SHOULD provide an administrative mechanism to configure different levels of detail in the extension key values and MUST provide an administrative mechanism to disable sending the key. The choice of which countermeasure is most appropriate depends on the environment. However, the first countermeasure may be acceptable in many environments, since it provides a compromise between sending too much information and the other more complete countermeasures of not sending the key at all or using IPsec. In addition to security considerations involving transmission of the key contents, any logging method(s) used for the key values MUST keep the information secure from intruders. For all implementations, the requirements to address this security concern are: - display of the log MUST only be possible with administrative rights to the node - options to disable logging to disk and to keep logs for a fixed duration SHOULD be provided Finally, it is important to note that different nodes may have different levels of risk, and these differences may affect the implementation. The components of risk include assets, threats, and vulnerabilities. Consider the following example iSCSI nodes, which demonstrate differences in assets and vulnerabilities of the nodes, and as a result, differences in implementation: - One iSCSI target based on a special-purpose operating system. Since the iSCSI target controls access to the data storage containing company assets, the asset level is seen as very high. Also, because of the special-purpose operating system, in which vulnerabilities are less well-known, the vulnerability level is viewed as low. - Multiple iSCSI initiators in a blade farm, each running a general-purpose operating system. The asset level of each node is viewed as low, since blades are replaceable and low cost. However, the vulnerability level is viewed as high, since there are many well-known vulnerabilities to the general-purpose operating system. For the above target, an appropriate implementation might be logging of received key values, but no transmission of the key. For the initiators, an appropriate implementation might be transmission of the key, but no logging of received key values. Wysochanski Expires November 4, 2006 [Page 4] Internet-Draft iSCSI Node Architecture July 2006 4. IANA Considerations This document defines the iSCSI Extension Key NodeArchitecture to be registered in the IANA iSCSI extended key registry. Wysochanski Expires November 4, 2006 [Page 5] Internet-Draft iSCSI Node Architecture July 2006 5. References 5.1 Normative References [RFC2119] Bradner, S. "Key Words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3720] Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka, M., and E. Zeidner, "Internet Small Computer Systems Interface (iSCSI)", RFC 3720, April 2004. 5.2 Informative References [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [RFC3723] Adoba, B., Tseng, J., Walker, J., Rangan, V., and Travostino, F., "Securing Block Storage Protocols over IP", RFC 3723, April 2004. Wysochanski Expires November 4, 2006 [Page 6] Internet-Draft iSCSI Node Architecture July 2006 6. Author's Address Dave Wysochanski Network Appliance, Inc. 7301 Kit Creek Road P. O. Box 13917 Research Triangle, NC 27709 Phone: +1-919-476-5628 E-mail: davidw@netapp.com Wysochanski Expires November 4, 2006 [Page 7] Internet-Draft iSCSI Node Architecture July 2006 7. Acknowledgements The IP Storage (ips) Working Group in the Transport Area of IETF has been responsible for defining the iSCSI protocol (apart from a host of other relevant IP Storage protocols). The editor acknowledges the contributions of the entire working group. The following individuals directly contributed to identifying issues and/or suggesting resolutions to the issues found in this document: David Black, Mallikarjun Chadalapaka, Paul Koning, Julian Satran, John Hufferd, Claire Kraft, Ranga Sankar, Joseph Pittman, Greg Berg, John Forte, and Jim Yuill. This document benefited from all these contributions. Wysochanski Expires November 4, 2006 [Page 8] Internet-Draft iSCSI Node Architecture July 2006 8. Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Wysochanski Expires November 4, 2006 [Page 9] Internet-Draft iSCSI Node Architecture July 2006 9. Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Wysochanski Expires November 4, 2006 [Page 10] --------------080509070508050703040803 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --------------080509070508050703040803-- From ips-bounces@ietf.org Sun Jul 09 13:35:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzdC5-0008MA-V7; Sun, 09 Jul 2006 13:35:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzdC5-0008M5-Gf for ips@ietf.org; Sun, 09 Jul 2006 13:35:45 -0400 Received: from rwcrmhc13.comcast.net ([204.127.192.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzdC5-00084r-01 for ips@ietf.org; Sun, 09 Jul 2006 13:35:45 -0400 Received: from ivvtdkv0981 (mail.ivivity.com?[64.238.111.98]) by comcast.net (rwcrmhc13) with SMTP id <20060709173542m1300rl135e>; Sun, 9 Jul 2006 17:35:43 +0000 Message-ID: <003601c6a37e$1b133c10$3b01a8c0@ivivity.com> From: "Eddy Quicksall" To: "William Studenmund" , "Robert Snively" References: <6002A63FDB393D4F9ADB36DE70C484754F066C@hq-exch-1.corp.brocade.com> <1B4F171F-768B-4A0A-9F97-0CF1B77F044E@wasabisystems.com> Subject: Re: [Ips] Receiving a SCSI response after abort task was sent Date: Sun, 9 Jul 2006 13:35:42 -0400 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: f60fbf3dbcaca652b6d10036f0630412 Cc: ips@ietf.org, Black_David@emc.com X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1074621757==" Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============1074621757== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0033_01C6A35C.930C66A0" This is a multi-part message in MIME format. ------=_NextPart_000_0033_01C6A35C.930C66A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Wasn't Bob talking about technologies other than iSCSI? =20 Bob, are you sure? Do you have an example of such a technology?=20 I would think it would be dangerous for a technology to allow a SCSI = response to be received after the TMF response has been received for the = same command. My reasoning is that once the initiator has received the = TMF response it can reuse the ITT. In that case if the SCSI response for = the aborted command comes after the TMF response for the same command = but a new command has already used the same ITT, then there would be no = way to determine that the response should be discarded. Eddy ----- Original Message -----=20 From: William Studenmund=20 To: Robert Snively=20 Cc: ips@ietf.org ; Black_David@emc.com=20 Sent: Wednesday, July 05, 2006 1:47 PM Subject: Re: [Ips] Receiving a SCSI response after abort task was sent On Jul 3, 2006, at 10:18 AM, Robert Snively wrote: With one minor warning, I agree with David. Warning below: > Is the host that issued the abort task willing to receive a SCSI = response for that task? > Is it willing to receive only a task management response for the = abort task? Yes and No in that order, the SCSI response is possible and must be handled. There will always be a task management response, = independent of whether the SCSI response is issued. One important rule is that the SCSI response cannot occur *after* the task management response. = In some technologies and under some conditions, it is hypothetically = possible for a SCSI response to appear at an initiator after the task management = response. In such environments, this will be detected as a SCSI response for which there is no SCSI request = and it will be discarded.=20 Since TCP/IP forces in-order behavior on the SCSI stream, and since = the abort task is normally sent through the same stream as the command, this normally = may be ignored by iSCSI. I don't think this is a concern, because the ABORT TASK MUST be on the = same connection (section 10.5.1, page 131 of RFC 3720) as the command in = question. Thus StatSN numbering for the two is in the same number space. = The SCSI response should have a lower StatSN than the TMF response as = StatSN is the only real way to determine what is "before" or "after", = and we are talking about the case where the task finished "before" the = abort. So as the initiator processes StatSN responses, it will see the SCSI = response "before" the TMF response. As long as any other iSCSI transport (other than TCP) retains StatSN, = this will work right. Take care, Bill -------------------------------------------------------------------------= ----- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips ------=_NextPart_000_0033_01C6A35C.930C66A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Wasn't Bob talking about technologies other than=20 iSCSI?
 
Bob, are you sure? Do you have an example of such a=20 technology?
 
I would think it would be dangerous for a technology = to allow a SCSI response to be received after the TMF = response=20 has been received for the same command. My reasoning is that once the = initiator=20 has received the TMF response it can reuse the ITT. In that case if the = SCSI=20 response for the aborted command comes after the TMF response for the = same=20 command but a new command has already used the same ITT, then = there=20 would be no way to determine that the response should be = discarded.
 
Eddy
----- Original Message -----
From:=20 William Studenmund =
Sent: Wednesday, July 05, 2006 = 1:47=20 PM
Subject: Re: [Ips] Receiving a = SCSI=20 response after abort task was sent

On Jul 3, 2006, at 10:18 AM, Robert Snively wrote:
With one minor warning, I agree with=20 David.
 
Warning below:

> = Is the=20 host that issued the abort task willing to receive a SCSI response = for that=20 task?
> = Is it=20 willing to receive only a task management response for the abort = task?
 
Yes and No in that order, the SCSI = response is=20 possible and must be
handled.  There = will always=20 be a task management response, independent
of whether the = SCSI response=20 is issued.  One important rule is that
the SCSI response = cannot occur=20 *after* the task management response. 
 
In some technologies and under some conditions, it = is=20 hypothetically possible for a = SCSI
response to appear at an initiator after the task = management=20 response.  In such environments, this=20 will
be detected as a SCSI response for which there is no = SCSI=20 request and it will be=20 discarded. 
Since = TCP/IP forces=20 in-order behavior on the SCSI stream, and since the abort task=20 is
normally sent=20 through the same stream as the command, this normally may be=20 ignored
by=20 iSCSI.

I don't think this is a concern, because the ABORT TASK MUST be = on the=20 same connection (section 10.5.1, page 131 of RFC 3720) as the = command in=20 question. Thus StatSN numbering for the two is in the same number = space. The=20 SCSI response should have a lower StatSN than the TMF response as = StatSN is=20 the only real way to determine what is "before" or "after", and we are = talking=20 about the case where the task finished "before" the abort.

So as the initiator processes StatSN responses, it will see the = SCSI=20 response "before" the TMF response.

As long as any other iSCSI transport (other than TCP) retains = StatSN,=20 this will work right.

Take care,

Bill

_______________________________________________
Ips mailing=20 = list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips
------=_NextPart_000_0033_01C6A35C.930C66A0-- --===============1074621757== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============1074621757==-- From ips-bounces@ietf.org Sun Jul 09 14:15:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fzdol-0007V3-9Q; Sun, 09 Jul 2006 14:15:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fzdoj-0007Px-UO for ips@ietf.org; Sun, 09 Jul 2006 14:15:41 -0400 Received: from [216.148.227.155] (helo=rwcrmhc15.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fzdoi-0004qT-Go for ips@ietf.org; Sun, 09 Jul 2006 14:15:41 -0400 Received: from ivvtdkv0981 (mail.ivivity.com?[64.238.111.98]) by comcast.net (rwcrmhc15) with SMTP id <20060709181534m15003qeste>; Sun, 9 Jul 2006 18:15:39 +0000 Message-ID: <004701c6a383$aee58b00$3b01a8c0@ivivity.com> From: "Eddy Quicksall" To: "Julian Satran" References: Subject: Re: [Ips] target/initiator device Date: Sun, 9 Jul 2006 14:15:33 -0400 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.3 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd 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="===============1621358566==" Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============1621358566== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0044_01C6A362.24072B90" This is a multi-part message in MIME format. ------=_NextPart_000_0044_01C6A362.24072B90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks, my error. I re-read it and it does not require the target and = initiator ports to have identical names. ----- Original Message -----=20 From: Julian Satran=20 To: Eddy Quicksall=20 Cc: ips@ietf.org=20 Sent: Saturday, July 02, 2005 3:26 AM Subject: Re: [Ips] target/initiator device Eddy,=20 Bassically iSCSI is using SAM2 as reference. However the name types = for iSCSI initiator and target are not different.=20 And since SAM3 has separate initiator port and target port in a = combined device the same iSCSI name CAN be used for naming both ports = using the iSCSI naming conventions for ports.=20 Julo=20 "Eddy Quicksall" =20 Sent by: ips-bounces@ietf.org=20 01/07/2005 21:43=20 To =20 cc =20 Subject [Ips] target/initiator device=20 =20 =20 How does iSCSI work as a target/initiator device? i.e., iSCSI has = different types of names for the initiator and target names but = paragraph 4.7.3 in SAM 3 appears to need a common name between the two.=20 =20 Eddy_______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips ------=_NextPart_000_0044_01C6A362.24072B90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Thanks, my error. I re-read it and it does not = require the=20 target and initiator ports to have identical names.
----- Original Message -----
From:=20 Julian Satran
To: Eddy = Quicksall=20
Sent: Saturday, July 02, 2005 = 3:26=20 AM
Subject: Re: [Ips] = target/initiator=20 device


Eddy, =

Bassically iSCSI is using SAM2 as = reference. However=20 the name types for iSCSI initiator and target are not = different.=20
And since SAM3 has separate = initiator port=20 and target port in a combined device the same iSCSI name CAN be used = for=20 naming both ports using the iSCSI naming conventions for ports. =

Julo


"Eddy = Quicksall" <eddy_quicksall_i= Vivity_iSCSI@comcast.net>=20
Sent by: ips-bounces@ietf.org=20

01/07/2005 21:43

To
<ips@ietf.org>=20
cc
Subject
[Ips] target/initiator=20 device

=




How=20 does iSCSI work as a target/initiator device? i.e., iSCSI has = different types=20 of names for the initiator and target names but paragraph 4.7.3 in SAM = 3=20 appears to need a common name between the two.
 
Eddy_______________________________________________
Ips = mailing=20 = list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips

------=_NextPart_000_0044_01C6A362.24072B90-- --===============1621358566== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============1621358566==-- From ips-bounces@ietf.org Mon Jul 10 12:16:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzyQz-00062d-MT; Mon, 10 Jul 2006 12:16:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzyQy-00062Y-V4 for ips@ietf.org; Mon, 10 Jul 2006 12:16:32 -0400 Received: from mtagate1.de.ibm.com ([195.212.29.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzyQw-0001Wk-5l for ips@ietf.org; Mon, 10 Jul 2006 12:16:32 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate1.de.ibm.com (8.13.6/8.13.6) with ESMTP id k6AGGTBM047506 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 10 Jul 2006 16:16:29 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.13.6/NCO/VER7.0) with ESMTP id k6AGJKRf138324 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 10 Jul 2006 18:19:21 +0200 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id k6AGGS1p031026 for ; Mon, 10 Jul 2006 18:16:28 +0200 Received: from d12mc102.megacenter.de.ibm.com (d12mc102.megacenter.de.ibm.com [9.149.167.114]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k6AGGSck031018; Mon, 10 Jul 2006 18:16:28 +0200 In-Reply-To: <003601c6a37e$1b133c10$3b01a8c0@ivivity.com> To: "Eddy Quicksall" Subject: Re: [Ips] Receiving a SCSI response after abort task was sent MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 From: Julian Satran Message-ID: Date: Mon, 10 Jul 2006 12:19:18 -0400 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 7.0.1HF123 | April 14, 2006) at 10/07/2006 19:19:20, Serialize complete at 10/07/2006 19:19:20 X-Spam-Score: 0.1 (/) X-Scan-Signature: 2b2ad76aced9b1d558e34a970a85c027 Cc: ips@ietf.org, William Studenmund , Black_David@emc.com, Robert Snively 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="===============1140979572==" Errors-To: ips-bounces@ietf.org This is a multipart message in MIME format. --===============1140979572== Content-Type: multipart/alternative; boundary="=_alternative 005962F2852571A7_=" This is a multipart message in MIME format. --=_alternative 005962F2852571A7_= Content-Type: text/plain; charset="US-ASCII" Eddy, I don't think was talking about iSCSI (where it should not happen). But SCSI was defined for a variety of technologies some which do not have ordered and reliable transport. If you take technologies that have a "link-by-link" error recovery (such as PCI express) and include some switches in the "pot" this may definitely happen. So it is wise to be prepared for it. Regards, Julo "Eddy Quicksall" 09/07/06 13:35 To "William Studenmund" , "Robert Snively" cc ips@ietf.org, Black_David@emc.com Subject Re: [Ips] Receiving a SCSI response after abort task was sent Wasn't Bob talking about technologies other than iSCSI? Bob, are you sure? Do you have an example of such a technology? I would think it would be dangerous for a technology to allow a SCSI response to be received after the TMF response has been received for the same command. My reasoning is that once the initiator has received the TMF response it can reuse the ITT. In that case if the SCSI response for the aborted command comes after the TMF response for the same command but a new command has already used the same ITT, then there would be no way to determine that the response should be discarded. Eddy ----- Original Message ----- From: William Studenmund To: Robert Snively Cc: ips@ietf.org ; Black_David@emc.com Sent: Wednesday, July 05, 2006 1:47 PM Subject: Re: [Ips] Receiving a SCSI response after abort task was sent On Jul 3, 2006, at 10:18 AM, Robert Snively wrote: With one minor warning, I agree with David. Warning below: > Is the host that issued the abort task willing to receive a SCSI response for that task? > Is it willing to receive only a task management response for the abort task? Yes and No in that order, the SCSI response is possible and must be handled. There will always be a task management response, independent of whether the SCSI response is issued. One important rule is that the SCSI response cannot occur *after* the task management response. In some technologies and under some conditions, it is hypothetically possible for a SCSI response to appear at an initiator after the task management response. In such environments, this will be detected as a SCSI response for which there is no SCSI request and it will be discarded. Since TCP/IP forces in-order behavior on the SCSI stream, and since the abort task is normally sent through the same stream as the command, this normally may be ignored by iSCSI. I don't think this is a concern, because the ABORT TASK MUST be on the same connection (section 10.5.1, page 131 of RFC 3720) as the command in question. Thus StatSN numbering for the two is in the same number space. The SCSI response should have a lower StatSN than the TMF response as StatSN is the only real way to determine what is "before" or "after", and we are talking about the case where the task finished "before" the abort. So as the initiator processes StatSN responses, it will see the SCSI response "before" the TMF response. As long as any other iSCSI transport (other than TCP) retains StatSN, this will work right. Take care, Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --=_alternative 005962F2852571A7_= Content-Type: text/html; charset="US-ASCII"
Eddy,

I don't think was talking about iSCSI (where it should not happen). But SCSI was defined for a variety of technologies some which do not have ordered and reliable transport. If you take technologies that have a "link-by-link" error recovery (such as PCI express) and include some switches in the "pot" this may definitely happen. So it is wise to be prepared for it.

Regards,
Julo


"Eddy Quicksall" <eddy_quicksall_iVivity_iSCSI@Comcast.net>

09/07/06 13:35

To
"William Studenmund" <wrstuden@wasabisystems.com>, "Robert Snively" <rsnively@Brocade.COM>
cc
ips@ietf.org, Black_David@emc.com
Subject
Re: [Ips] Receiving a SCSI response after abort task was sent





Wasn't Bob talking about technologies other than iSCSI?
 
Bob, are you sure? Do you have an example of such a technology?
 
I would think it would be dangerous for a technology to allow a SCSI response to be received after the TMF response has been received for the same command. My reasoning is that once the initiator has received the TMF response it can reuse the ITT. In that case if the SCSI response for the aborted command comes after the TMF response for the same command but a new command has already used the same ITT, then there would be no way to determine that the response should be discarded.
 
Eddy
----- Original Message -----
From: William Studenmund
To: Robert Snively
Cc: ips@ietf.org ; Black_David@emc.com
Sent: Wednesday, July 05, 2006 1:47 PM
Subject: Re: [Ips] Receiving a SCSI response after abort task was sent

On Jul 3, 2006, at 10:18 AM, Robert Snively wrote:

With one minor warning, I agree with David.
 
Warning below:

> Is the host that issued the abort task willing to receive a SCSI response for that task?
> Is it willing to receive only a task management response for the abort task?
 
Yes and No in that order, the SCSI response is possible and must be
handled.  There will always be a task management response, independent
of whether the SCSI response is issued.  One important rule is that
the SCSI response cannot occur *after* the task management response.
 
In some technologies and under some conditions, it is hypothetically possible for a SCSI
response to appear at an initiator after the task management response.  In such environments, this will
be detected as a SCSI response for which there is no SCSI request and it will be discarded.
Since TCP/IP forces in-order behavior on the SCSI stream, and since the abort task is
normally sent through the same stream as the command, this normally may be ignored
by iSCSI.

I don't think this is a concern, because the ABORT TASK MUST be on the same connection (section 10.5.1, page 131 of RFC 3720) as the command in question. Thus StatSN numbering for the two is in the same number space. The SCSI response should have a lower StatSN than the TMF response as StatSN is the only real way to determine what is "before" or "after", and we are talking about the case where the task finished "before" the abort.

So as the initiator processes StatSN responses, it will see the SCSI response "before" the TMF response.

As long as any other iSCSI transport (other than TCP) retains StatSN, this will work right.

Take care,

Bill

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

--=_alternative 005962F2852571A7_=-- --===============1140979572== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============1140979572==-- From ips-bounces@ietf.org Mon Jul 10 13:54:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzzxH-00022w-VP; Mon, 10 Jul 2006 13:53:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzzxG-00022n-Re for ips@ietf.org; Mon, 10 Jul 2006 13:53:58 -0400 Received: from mail97.messagelabs.com ([216.82.244.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FzzxG-0000q9-9p for ips@ietf.org; Mon, 10 Jul 2006 13:53:58 -0400 X-VirusChecked: Checked X-Env-Sender: rsnively@Brocade.COM X-Msg-Ref: server-15.tower-97.messagelabs.com!1152554036!71087630!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [66.243.153.112] Received: (qmail 3887 invoked from network); 10 Jul 2006 17:53:56 -0000 Received: from f112.brocade.com (HELO scooby.brocade.com) (66.243.153.112) by server-15.tower-97.messagelabs.com with SMTP; 10 Jul 2006 17:53:56 -0000 Received: from hq-exch-1.corp.brocade.com (hq-exch-1.brocade.com [10.3.8.21]) by scooby.brocade.com (Postfix) with ESMTP id D694A25801A; Mon, 10 Jul 2006 10:51:41 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ips] Receiving a SCSI response after abort task was sent Date: Mon, 10 Jul 2006 10:53:55 -0700 Message-ID: <6002A63FDB393D4F9ADB36DE70C484754F0AC2@hq-exch-1.corp.brocade.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ips] Receiving a SCSI response after abort task was sent Thread-Index: AcakPDnFe9NBc1x+TgiyLdHp6K7YaAADF8sw From: "Robert Snively" To: "Julian Satran" , "Eddy Quicksall" X-Spam-Score: 0.3 (/) X-Scan-Signature: 6379955759c38e2371a49573a0932fc7 Cc: ips@ietf.org, Black_David@emc.com X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0949202045==" Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============0949202045== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6A449.D03F074E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6A449.D03F074E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Eddy, =20 Julian has shown you one example. =20 A second example is in some Fibre Channel environments, where in-order delivery is optional. In those cases, the rules say that you shall not re-use the fully qualified exchange identifier until a timeout has passed that guarantees that all possible responses have either been discarded in the network or received (and discarded) by the initiator. =20 Of course, any technology may have a target failure that generates a response for a command that either no longer exists or has never existed. That should not confuse anyone and certainly should not bring down an initiator. Be forgiving, and accept the unexpected response and discard it. You may choose to post a notice to some upper programming level, but the system should not crash or create operational problems for other targets. =20 Bob ________________________________ From: Julian Satran [mailto:Julian_Satran@il.ibm.com]=20 Sent: Monday, July 10, 2006 9:19 AM To: Eddy Quicksall Cc: Black_David@emc.com; ips@ietf.org; Robert Snively; William Studenmund Subject: Re: [Ips] Receiving a SCSI response after abort task was sent Eddy,=20 I don't think was talking about iSCSI (where it should not happen). But SCSI was defined for a variety of technologies some which do not have ordered and reliable transport. If you take technologies that have a "link-by-link" error recovery (such as PCI express) and include some switches in the "pot" this may definitely happen. So it is wise to be prepared for it.=20 Regards,=20 Julo=20 "Eddy Quicksall" =20 09/07/06 13:35=20 To "William Studenmund" , "Robert Snively" =20 cc ips@ietf.org, Black_David@emc.com=20 Subject Re: [Ips] Receiving a SCSI response after abort task was sent =09 Wasn't Bob talking about technologies other than iSCSI?=20 =20 Bob, are you sure? Do you have an example of such a technology?=20 =20 I would think it would be dangerous for a technology to allow a SCSI response to be received after the TMF response has been received for the same command. My reasoning is that once the initiator has received the TMF response it can reuse the ITT. In that case if the SCSI response for the aborted command comes after the TMF response for the same command but a new command has already used the same ITT, then there would be no way to determine that the response should be discarded.=20 =20 Eddy=20 ----- Original Message -----=20 From: William Studenmund =20 To: Robert Snively =20 Cc: ips@ietf.org ; Black_David@emc.com =20 Sent: Wednesday, July 05, 2006 1:47 PM=20 Subject: Re: [Ips] Receiving a SCSI response after abort task was sent=20 On Jul 3, 2006, at 10:18 AM, Robert Snively wrote:=20 With one minor warning, I agree with David.=20 =20 Warning below:=20 > Is the host that issued the abort task willing to receive a SCSI response for that task?=20 > Is it willing to receive only a task management response for the abort task?=20 =20 Yes and No in that order, the SCSI response is possible and must be=20 handled. There will always be a task management response, independent=20 of whether the SCSI response is issued. One important rule is that=20 the SCSI response cannot occur *after* the task management response.=20 =20 In some technologies and under some conditions, it is hypothetically possible for a SCSI=20 response to appear at an initiator after the task management response. In such environments, this will=20 be detected as a SCSI response for which there is no SCSI request and it will be discarded.=20 Since TCP/IP forces in-order behavior on the SCSI stream, and since the abort task is=20 normally sent through the same stream as the command, this normally may be ignored=20 by iSCSI.=20 I don't think this is a concern, because the ABORT TASK MUST be on the same connection (section 10.5.1, page 131 of RFC 3720) as the command in question. Thus StatSN numbering for the two is in the same number space. The SCSI response should have a lower StatSN than the TMF response as StatSN is the only real way to determine what is "before" or "after", and we are talking about the case where the task finished "before" the abort.=20 So as the initiator processes StatSN responses, it will see the SCSI response "before" the TMF response.=20 As long as any other iSCSI transport (other than TCP) retains StatSN, this will work right.=20 Take care,=20 Bill=20 ________________________________ _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips______________________________ _________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips ------_=_NextPart_001_01C6A449.D03F074E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Eddy,
 
Julian has shown you one = example.
 
A second example is in some Fibre Channel = environments,=20 where in-order
delivery is optional.  In those cases, the = rules say=20 that you shall not re-use
the fully qualified exchange identifier until a = timeout has=20 passed that guarantees
that all possible responses have either been = discarded in=20 the network or
received (and discarded) by the=20 initiator.
 
Of course, any technology may have a target = failure that=20 generates a
response for a command that either no longer = exists or has=20 never existed.
That should not confuse anyone and certainly = should not=20 bring down an
initiator.  Be forgiving, and accept the = unexpected=20 response and discard it.
You may choose to post a notice to some upper = programming=20 level, but
the system should not crash or create = operational problems=20 for other
targets.
 
Bob

From: Julian Satran=20 [mailto:Julian_Satran@il.ibm.com]
Sent: Monday, July 10, 2006 = 9:19=20 AM
To: Eddy Quicksall
Cc: Black_David@emc.com; = ips@ietf.org;=20 Robert Snively; William Studenmund
Subject: Re: [Ips] = Receiving a SCSI=20 response after abort task was sent


Eddy, =

I don't think was talking about iSCSI (where = it should=20 not happen). But SCSI was defined for a variety of technologies some = which do=20 not have ordered and reliable transport. If you take technologies that = have a=20 "link-by-link" error recovery (such as PCI express) and include some = switches in=20 the "pot" this may definitely happen. So it is wise to be prepared for=20 it.

Regards, =
Julo


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

09/07/06 13:35

To
"William Studenmund"=20 <wrstuden@wasabisystems.com>, "Robert Snively"=20 <rsnively@Brocade.COM>=20
cc
ips@ietf.org,=20 Black_David@emc.com=20
Subject
Re: [Ips] Receiving a = SCSI response=20 after abort task was sent

=




Wasn't Bob talking about technologies other than iSCSI? =
 
Bob, are you sure? Do you have = an example=20 of such a technology?
 
I=20 would think it would be dangerous for a technology to allow a SCSI = response to=20 be received after the TMF response has been received for the same = command. My=20 reasoning is that once the initiator has received the TMF response it = can reuse=20 the ITT. In that case if the SCSI response for the aborted command comes = after=20 the TMF response for the same command but a new command has already used = the=20 same ITT, then there would be no way to determine that the response = should be=20 discarded.
 
Eddy=20
----- Original Message -----
From: William Studenmund=20
To: Robert=20 Snively
Cc: ips@ietf.org ; Black_David@emc.com =
Sent: Wednesday, July 05, 2006 1:47 PM
Subject: Re: [Ips] Receiving a SCSI response after abort = task was=20 sent

On Jul 3, 2006, at 10:18 AM, Robert = Snively=20 wrote:

With one = minor warning,=20 I agree with David.
 
Warning below:

> = Is the host=20 that issued the abort task willing to receive a SCSI response for that=20 task?
> Is it willing to receive only a = task=20 management response for the abort task?
 =20
Yes and No in that order, the = SCSI response=20 is possible and must be
handled.=20  There will always be a task management response, = independent=20
of whether the SCSI response is = issued.=20  One important rule is that
the=20 SCSI response cannot occur *after* the task management = response.
 
In some technologies and under some = conditions, it=20 is hypothetically possible for a SCSI
response to appear at an initiator after the task management = response.=20  In such environments, this will
be detected as a SCSI response for which there is no SCSI = request and it=20 will be discarded. =
Since TCP/IP forces in-order behavior = on the SCSI=20 stream, and since the abort task is
normally sent through the same stream as the command, this = normally may=20 be ignored
by = iSCSI.=20

I don't think this is a concern, because the = ABORT TASK=20 MUST be on the same connection (section 10.5.1, page 131 of RFC 3720) as = the=20 command in question. Thus StatSN numbering for the two is in the same = number=20 space. The SCSI response should have a lower StatSN than the TMF = response as=20 StatSN is the only real way to determine what is "before" or "after", = and we are=20 talking about the case where the task finished "before" the = abort.=20

So as the initiator processes StatSN responses, = it will see=20 the SCSI response "before" the TMF response.

As long=20 as any other iSCSI transport (other than TCP) retains StatSN, this will = work=20 right.

Take care,

Bill=20

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

------_=_NextPart_001_01C6A449.D03F074E-- --===============0949202045== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0949202045==-- From ips-bounces@ietf.org Tue Jul 11 15:56:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0OLO-0000q7-6X; Tue, 11 Jul 2006 15:56:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0OLN-0000px-B1 for ips@ietf.org; Tue, 11 Jul 2006 15:56:29 -0400 Received: from roadrunner-base.egenera.com ([63.160.166.46]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0OLL-0004ZK-2U for ips@ietf.org; Tue, 11 Jul 2006 15:56:29 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by roadrunner.egenera.com (Postfix) with ESMTP id 7859DA0532 for ; Tue, 11 Jul 2006 15:56:26 -0400 (EDT) Received: from roadrunner-base.egenera.com ([127.0.0.1]) by localhost (roadrunner.egenera.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09457-03 for ; Tue, 11 Jul 2006 15:56:23 -0400 (EDT) Received: from webaccess.egenera.com (webaccess.egenera.com [63.160.165.24]) by roadrunner.egenera.com (Postfix) with ESMTP id AFBA6A051B for ; Tue, 11 Jul 2006 15:56:23 -0400 (EDT) Received: from thror.egenera.com ([63.160.166.4]) by webaccess.egenera.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Jul 2006 15:56:23 -0400 Received: from thror.egenera.com (thror.egenera.com [127.0.0.1]) by thror.egenera.com (8.13.6/8.13.6) with ESMTP id k6BJuJSd029459 for ; Tue, 11 Jul 2006 15:56:23 -0400 From: David Allan To: ips@ietf.org Content-Type: text/plain Date: Tue, 11 Jul 2006 15:56:19 -0400 Message-Id: <1152647779.27112.36.camel@thror.egenera.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 (2.6.2-1.fc5.5) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Jul 2006 19:56:23.0302 (UTC) FILETIME=[15FE2260:01C6A524] X-Virus-Scanned: amavisd-new at egenera.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: [Ips] Implementing an iSNS server 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: , Errors-To: ips-bounces@ietf.org I am in the planning stage of implementing an iSNS server compliant with RFC4171. I've looked over the code at http://sourceforge.net/projects/linuxisns/ which looks like it's based on v5 of the draft spec. I've compared the v5 spec with RFC4171, and there appear to be some fairly significant differences, but I have not been involved from the beginning of the RFC process, so I'd like opinions from people who have more of the history. What are people's thoughts on how much value the sourceforge code would be in implementing the RFC? TIA, Dave _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From 6kbg5Dk8Xn@mail.ru Wed Jul 12 09:53:12 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0f9M-0002IZ-87; Wed, 12 Jul 2006 09:53:12 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0f9M-0005ro-6N; Wed, 12 Jul 2006 09:53:12 -0400 Received: from bb121-6-126-251.singnet.com.sg ([121.6.126.251]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G0f9J-0004xp-MR; Wed, 12 Jul 2006 09:53:12 -0400 Date: Wed, 12 Jul 2006 13:53:11 -0480 From: "Deirdre Ziegler" X-Mailer: The Bat! (v3.01 RC8) Educational Reply-To: "Deirdre Ziegler" X-Priority: 3 (Normal) Message-ID: <08071250.20060712135311@mail.ru> To: ipo-archive@lists.ietf.org Subject: RYX MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 4.2 (++++) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 "Well, if you can't, you can't. I understand you, Red, and I can't pass miles an hour in the entry! You have to be smooth! Firm but smooth, He wants to go up. And what if something gets you at twenty yards? "We're free to go where we wish and to be what we are," Jonathan From ips-bounces@ietf.org Wed Jul 12 10:28:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0fhL-0007DA-Ku; Wed, 12 Jul 2006 10:28:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0fhK-0007D5-AE for ips@ietf.org; Wed, 12 Jul 2006 10:28:18 -0400 Received: from mexforward.lss.emc.com ([128.222.32.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0fhI-0007nP-W5 for ips@ietf.org; Wed, 12 Jul 2006 10:28:18 -0400 Received: from mailhub.lss.emc.com (nirah.lss.emc.com [10.254.144.13]) by mexforward.lss.emc.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k6CESEYe017997; Wed, 12 Jul 2006 10:28:14 -0400 (EDT) Received: from corpussmtp4.corp.emc.com (corpussmtp4.corp.emc.com [10.254.64.54]) by mailhub.lss.emc.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k6CES7is008954; Wed, 12 Jul 2006 10:28:12 -0400 (EDT) From: Black_David@emc.com Received: from corpussmtp3.corp.emc.com ([10.254.64.53]) by corpussmtp4.corp.emc.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 12 Jul 2006 10:27:35 -0400 Received: from CORPUSMX20A.corp.emc.com ([128.221.62.13]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 12 Jul 2006 10:19:04 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ips] Updates to draft-ietf-ips-iscsi-nodearch-key-00.txt Date: Wed, 12 Jul 2006 10:19:03 -0400 Message-ID: In-Reply-To: <44AEAB1D.5020206@netapp.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ips] Updates to draft-ietf-ips-iscsi-nodearch-key-00.txt Thread-Index: Acah9vwdOO2eEC/RSGCUiuEivfUgjwDxWi6A To: , X-OriginalArrivalTime: 12 Jul 2006 14:19:04.0598 (UTC) FILETIME=[2132BB60:01C6A5BE] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.7.12.71433 X-PerlMx-Spam: Gauge=, SPAM=2%, Reason='EMC_FROM_0+ -2, NO_REAL_NAME 0, __CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CTYPE_CHARSET_QUOTED 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __PHISH_PHRASE11 0, __SANE_MSGID 0' X-Spam-Score: 0.2 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org Quick note: -00 is what's currently on the Internet-Draft servers, so the final form of this -01 is headed for submission after the Montreal meetings. In the meeting, I intend to project at least what I consider the crucial paragraphs for detailed editing/wordsmithing: - Last paragraph of Section 1.2, forbidding behavioral dependencies - First paragraph of the security section on what to do if there's a need to keep implementation details secret. Dave W took the latter paragraph directly from an email I sent, so blame me rather than him for any problems with that text. The -01 version of this draft is probably headed for WG Last Call within the next few weeks. Thanks, --David > -----Original Message----- > From: David Wysochanski [mailto:davidw@netapp.com]=20 > Sent: Friday, July 07, 2006 2:43 PM > To: ips@ietf.org > Subject: [Ips] Updates to draft-ietf-ips-iscsi-nodearch-key-00.txt >=20 > Attached is an updated version of=20 > draft-ietf-ips-iscsi-nodearch-key which > addresses all of the remaining items on my list. Comments welcome. > Note that I will not be attending the Montreal meeting. However, my > colleage, Tom Talpey should be in attendance. >=20 > Significant changes are: >=20 > 1. p. 2. Updated usage paragraph. This seemed a little=20 > vague, so I tried > to make it more specific and focus on prevention of the=20 > previous problem > with JavaScript. I also loosened the requirement for setting the key > value automatically to a SHOULD instead of a MUST (based on=20 > another reviewer > comment). >=20 > 2. p. 4. Security updates related to logging and different levels of > risk for nodes. These ideas came from a computer security reviewer, > and I believe address important issues. >=20 > List of all changes (verified via RFC diff tool below) > draft-ietf-ips-iscsi-nodearch-key-00.txt > draft-ietf-ips-iscsi-nodearch-key-01r1.txt > - p. 2: Modified proper use paragraph > - p. 3: fix typeo > - p. 4: fix typeo > - p. 4: added paragraphs 3-5 > - p. 8: added another contributor >=20 > http://www1.tools.ietf.org/tools/rfcdiff/rfcdiff.pyht >=20 >=20 >=20 _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Wed Jul 12 12:10:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0hI0-0006EN-Jk; Wed, 12 Jul 2006 12:10:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0hHz-000655-II for ips@ietf.org; Wed, 12 Jul 2006 12:10:15 -0400 Received: from mx2.netapp.com ([216.240.18.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0hHx-0004A5-8G for ips@ietf.org; Wed, 12 Jul 2006 12:10:15 -0400 Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2.netapp.com with ESMTP; 12 Jul 2006 09:10:13 -0700 X-IronPort-AV: i="4.06,236,1149490800"; d="scan'208"; a="392571696:sNHT46829172" Received: from [10.61.17.67] ([10.61.17.67]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id k6CGABSt007686; Wed, 12 Jul 2006 09:10:12 -0700 (PDT) Message-ID: <44B51BCF.9030802@netapp.com> Date: Wed, 12 Jul 2006 11:57:03 -0400 From: David Wysochanski User-Agent: Thunderbird 1.5.0.2 (X11/20060420) MIME-Version: 1.0 To: Black_David@emc.com Subject: Re: [Ips] Updates to draft-ietf-ips-iscsi-nodearch-key-00.txt References: In-Reply-To: Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe 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: , Errors-To: ips-bounces@ietf.org Thanks. I will await the outcome of the meeting and be ready to respond to any edits in a timely manner. Black_David@emc.com wrote: > > Quick note: -00 is what's currently on the Internet-Draft servers, so > the final form of this -01 is headed for submission after the Montreal > meetings. In the meeting, I intend to project at least what I consider > the crucial paragraphs for detailed editing/wordsmithing: > - Last paragraph of Section 1.2, forbidding behavioral dependencies > - First paragraph of the security section on what to do if there's > a need to keep implementation details secret. > Dave W took the latter paragraph directly from an email I sent, so > blame me rather than him for any problems with that text. > > The -01 version of this draft is probably headed for WG Last Call > within the next few weeks. > > Thanks, > --David > > > -----Original Message----- > > From: David Wysochanski [mailto:davidw@netapp.com] > > Sent: Friday, July 07, 2006 2:43 PM > > To: ips@ietf.org > > Subject: [Ips] Updates to draft-ietf-ips-iscsi-nodearch-key-00.txt > > > > Attached is an updated version of > > draft-ietf-ips-iscsi-nodearch-key which > > addresses all of the remaining items on my list. Comments welcome. > > Note that I will not be attending the Montreal meeting. However, my > > colleage, Tom Talpey should be in attendance. > > > > Significant changes are: > > > > 1. p. 2. Updated usage paragraph. This seemed a little > > vague, so I tried > > to make it more specific and focus on prevention of the > > previous problem > > with JavaScript. I also loosened the requirement for setting the key > > value automatically to a SHOULD instead of a MUST (based on > > another reviewer > > comment). > > > > 2. p. 4. Security updates related to logging and different levels of > > risk for nodes. These ideas came from a computer security reviewer, > > and I believe address important issues. > > > > List of all changes (verified via RFC diff tool below) > > draft-ietf-ips-iscsi-nodearch-key-00.txt > > draft-ietf-ips-iscsi-nodearch-key-01r1.txt > > - p. 2: Modified proper use paragraph > > - p. 3: fix typeo > > - p. 4: fix typeo > > - p. 4: added paragraphs 3-5 > > - p. 8: added another contributor > > > > http://www1.tools.ietf.org/tools/rfcdiff/rfcdiff.pyht > > > > > > > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Wed Jul 12 19:52:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0oV5-0003ul-D5; Wed, 12 Jul 2006 19:52:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0oV3-0003ud-Qm for ips@ietf.org; Wed, 12 Jul 2006 19:52:13 -0400 Received: from mexforward.lss.emc.com ([128.222.32.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0oV3-0001qP-Fv for ips@ietf.org; Wed, 12 Jul 2006 19:52:13 -0400 Received: from mailhub.lss.emc.com (sesha.lss.emc.com [10.254.144.12]) by mexforward.lss.emc.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k6CNqC1h005374 for ; Wed, 12 Jul 2006 19:52:13 -0400 (EDT) Received: from mxic2.corp.emc.com (mxic2.corp.emc.com [128.221.12.9]) by mailhub.lss.emc.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k6CNq4Nn014344 for ; Wed, 12 Jul 2006 19:52:10 -0400 (EDT) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Wed, 12 Jul 2006 19:52:02 -0400 Message-ID: From: Black_David@emc.com To: ips@ietf.org Date: Wed, 12 Jul 2006 19:51:58 -0400 Importance: high X-Priority: 1 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.7.12.154933 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -2, NO_REAL_NAME 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __HAS_X_PRIORITY 0, __IMS_MSGID 0, __IMS_MUA 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0' X-Spam-Score: 0.3 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Cc: Black_David@emc.com Subject: [Ips] DRAFT Montreal minutes 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: , Errors-To: ips-bounces@ietf.org We actually managed to use the entire hour, and (IMHO) had very productive discussions. Please send any corrections to the DRAFT minutes below to me (and cc: the list if you want to). IMPORTANT: The sense of the room in Montreal was that adding SASL to iSCSI is a good way to: - Obtain an authentication method or methods based on SHA-256 - Address issues with the current Kerberos and SPKM methods. There is no current intent to make any SASL method mandatory or remove the mandatory-to-implement status of iSCSI CHAP. Anyone who disagrees with the above sense-of-the-room conclusions should post that disagreement to the list promptly along with an explanation of why - *please* change the subject line of the email when doing so. Absent such posts, this "SASL is a good thing to add" direction will become the rough consensus of the IPS WG. Thanks, --David (ips WG chair) IP Storage (ips) WG Meeting Minutes - DRAFT Wednesday, July 12, 2006 - 1510-1610 Montreal, Quebec, Canada ----------------------------------- Administrivia, agenda bashing, draft status review, etc. - 15 min David L. Black, EMC (chair) Blue sheets Note Well Draft status - projected from I-D tracker - Lots of published RFCs - iSER and DA drafts are paused waiting for the RDDP drafts that they depend on. The RDDP drafts are starting to move. - iSNS MIB has received MIB Doctor review, and a revised draft is in preparation (significant work is involved) - Implementers Guide is in WG, but not much activity. Likely to be WG Last Called before next IETF. Most important material in that draft involves task management operations that may affect more than one task (e.g., ABORT TASK SET, CLEAR TASK SET, LOGICAL UNIT RESET, TARGET RESET) - please review this material. Not on today's agenda - Node Architecture draft. Will be worked on today. Milestones - Dec 2006 for Node Architecture Draft - Jan 2007 for Implementers Guide Draft - Both appear reasonable. WG chair will be pushing ISER, DA, and iSNS MIB drafts through the process. iSCSI X#NodeArchitecture Key: Dave Wysochanski, Network Appliance - 30 min (draft-ietf-ips-iscsi-nodearch-key.txt) WG Discussion: - Key should be allowed only after Authentication. Revise draft to impose this restriction - Make sure it's a regular-size text key (not a big one, like the one used for the large numbers involved in some authentication methods). - "protocol logic": crucial point is that **behavior** is the same independent of presence, absence, or content of the key. Add or revise text to make this point. - Document behavior of RFC 3720-compliant implementation that receives this new key and does not understand it, and how the other side deals with the resulting response. - "configure different levels" text needs to be rephrased to be specific that the amount of detail is what changes across levels. - Align ability to configure amount of details with "SHOULD NOT" in Section 1.2 about administrative setting of key value. (the prior "SHOULD NOT" appears to conflict with this "SHOULD"). - Double-check there is a 3720-format definition of the key, including description clearly in the draft. - Make the examples phony (no real company names), and remove the double quotes ("), as they don't appear on the wire. - Spaces are forbidden in text strings. See RFC 3720, Section 5.1, and feel free to ask on the list for options on how to deal with this. iSCSI Security Mechanisms: WG Members - time remaining (if any) The IETF Security Area has requested that IETF Working Groups plan to transition away from usage of MD5. iSCSI CHAP currently uses MD5 in a fashion not directly threatened by the hash collision results known for MD5. If time is available in the meeting, it will be used to discuss what to do instead, as using a different hash with CHAP is not the only option. Above description is copied verbatim from Dallas agenda. There are two other related concerns: a) The Kerberos support in iSCSI is frowned upon by Kerberos experts. iSCSI Kerberos is not GSSAPI-based, and hence can't be used with GSSAPI-only Kerberos implementations. b) The SPKM-1 and SPKM-2 methods are arguably obsolete. SASL is a potential means of addressing all of these problems: - SASL has and/or will have methods based on SHA-256, the next hash of choice (according to the IETF Security Area) - SASL has GSSAPI-based Kerberos support that has been designed by Kerberos experts - SASL has an SPKM-3 method. The approach would be to add SASL methods to iSCSI by doing mapping the SASL tokens into iSCSI and providing authentication mechanism names (e.g., the SASL mechanism is negotiated by iSCSI as the SASL- mechanism). These would be additions - the current must-implement CHAP mechanism is not broken, and would not be removed. There may be a draft forthcoming that will add SASL to iSCSI - the sense of the room is that this would be a good thing to do, although it is not of immediate urgency. Open Mike - Roger Cummings noted that RFC 3720 is based on SAM-2; SAM-3 has appeared resulting in SCSI work in T10 that requires SAM-3. One example is encrypting tape drive work in T10 that relies upon a new well-known logical unit definition that is only in SAM-3. This is a reason to work on updating iSCSI to SAM-3. The WG chair commented that such an update would be backwards compatible, and would require the active involvement of a SCSI guru to ensure that the interactions with the SAM-3 specification are correct. _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Thu Jul 13 11:20:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G12ol-0004vX-Vo; Thu, 13 Jul 2006 11:09:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G12oc-0004Qk-EM for ips@ietf.org; Thu, 13 Jul 2006 11:09:22 -0400 Received: from mx2.netapp.com ([216.240.18.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G12gR-00089u-Jq for ips@ietf.org; Thu, 13 Jul 2006 11:00:56 -0400 Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2.netapp.com with ESMTP; 13 Jul 2006 07:58:06 -0700 X-IronPort-AV: i="4.06,238,1149490800"; d="scan'208"; a="392782126:sNHT208034552" Received: from [10.61.17.67] ([10.61.17.67]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id k6DEw3FM007066; Thu, 13 Jul 2006 07:58:04 -0700 (PDT) Message-ID: <44B65C5F.1060007@netapp.com> Date: Thu, 13 Jul 2006 10:44:47 -0400 From: David Wysochanski User-Agent: Thunderbird 1.5.0.2 (X11/20060420) MIME-Version: 1.0 To: Black_David@emc.com Subject: Re: [Ips] DRAFT Montreal minutes - X#NodeArchitecture comments References: In-Reply-To: Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 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: , Errors-To: ips-bounces@ietf.org A couple comments a points for clarification, while this is fresh on everyone's minds below. > iSCSI X#NodeArchitecture Key: Dave Wysochanski, Network Appliance - 30 > min > (draft-ietf-ips-iscsi-nodearch-key.txt) > > WG Discussion: > - Key should be allowed only after Authentication. Revise draft > to impose this restriction > This is actually already in there if you read the fine print of the "Use" portion of the declaration and note that "Any-Stage" is not there (see Section 12 in 3720). Since it has come up repeatedly though from various people, I will add some text to point this out explicitly and refer to Sections 11 and 12 of 3720. > - Make sure it's a regular-size text key (not a big one, like the > one used for the large numbers involved in some > authentication > methods). > Was the comment to limit the value size to 255 bytes, i.e. a single "text-value" (or "simple-value"), as defined by 3720, or something else? I liked the comma separated values and list-of-values seemed to fit well. But if there are concerns about key length I suppose we can add an explicit max length of the list-of-values. Another reviewer raised the question about the maximum length early on so perhaps an explicit limit is the way to go here. > - "protocol logic": crucial point is that **behavior** is the > same > independent of presence, absence, or content of the key. > Add > or revise text to make this point. > Was the consensus that the original term, "functional behavior", was clear enough, and I just muddied the water by trying to make it more crisp? > - Document behavior of RFC 3720-compliant implementation that > receives this new key and does not understand it, and how > the other side deals with the resulting response. > Ok. > - "configure different levels" text needs to be rephrased to be > specific that the amount of detail is what changes across > levels. > I'm not sure about this comment because I thought the existing text does just that. Here's what the text says today: all implementations of this extension key SHOULD provide an administrative mechanism to configure different levels of detail in the extension key values and MUST provide an administrative mechanism to disable sending the key. > - Align ability to configure amount of details with "SHOULD NOT" > in Section 1.2 about administrative setting of key value. > (the prior "SHOULD NOT" appears to conflict with this > "SHOULD"). > Point taken - will work on it. > - Double-check there is a 3720-format definition of the key, > including description clearly in the draft. > Was the comment that the existing declaration in section 2 conforms to section 12 of 3720, and specifically, section 12.22? > - Make the examples phony (no real company names), and remove > the double quotes ("), as they don't appear on the wire. > Ok. Main intent in providing company names was to show valid examples for implementers but I will remove them. Note that RFC 2616 does have valid examples Examples: User-Agent: CERN-LineMode/2.15 libwww/2.17b3 Server: Apache/0.8.4 > - Spaces are forbidden in text strings. See RFC 3720, Section > 5.1, > and feel free to ask on the list for options on how to > deal > with this. > Good catch - looks like I got carried away in my intent to provide clear examples. _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Thu Jul 13 11:35:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G13EI-0002ag-CL; Thu, 13 Jul 2006 11:35:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G13EH-0002Zv-0s for ips@ietf.org; Thu, 13 Jul 2006 11:35:53 -0400 Received: from mexforward.lss.emc.com ([128.222.32.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G13Cf-0002ER-7y for ips@ietf.org; Thu, 13 Jul 2006 11:34:13 -0400 Received: from mailhub.lss.emc.com (sesha.lss.emc.com [10.254.144.12]) by mexforward.lss.emc.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k6DFYCHq027249; Thu, 13 Jul 2006 11:34:12 -0400 (EDT) Received: from mxic2.corp.emc.com (mxic2.corp.emc.com [128.221.12.9]) by mailhub.lss.emc.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k6DFY4kb028905; Thu, 13 Jul 2006 11:34:10 -0400 (EDT) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Thu, 13 Jul 2006 11:34:03 -0400 Message-ID: From: Black_David@emc.com To: davidw@netapp.com Subject: RE: [Ips] DRAFT Montreal minutes - X#NodeArchitecture comments Date: Thu, 13 Jul 2006 11:33:51 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.7.13.81432 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -2, 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_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0' X-Spam-Score: 0.2 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab 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: , Errors-To: ips-bounces@ietf.org Dave, > A couple comments a points for clarification, while this is fresh on > everyone's minds below. > > > iSCSI X#NodeArchitecture Key: Dave Wysochanski, Network Appliance - 30 min > > (draft-ietf-ips-iscsi-nodearch-key.txt) > > > > WG Discussion: > > - Key should be allowed only after Authentication. Revise draft > > to impose this restriction > > > This is actually already in there if you read the fine print of the "Use" portion of > the declaration and note that "Any-Stage" is not there (see Section 12 in 3720). > Since it has come up repeatedly though from various people, I will add some > text to point this out explicitly and refer to Sections 11 and 12 of 3720. Yes, please do that. > > - Make sure it's a regular-size text key (not a big one, like the > > one used for the large numbers involved in some authentication > > methods). > > > Was the comment to limit the value size to 255 bytes, i.e. a single > "text-value" (or "simple-value"), as defined by 3720, or something else? Limiting the value size to 255 bytes was the intention. > I liked the comma separated values and list-of-values seemed to > fit well. But if there are concerns about key length I suppose we > can add an explicit max length of the list-of-values. Another reviewer > raised the question about the maximum length early on so perhaps > an explicit limit is the way to go here. An explicit limit is probably a good idea, as an implementation that receives this key and doesn't recognize it may only log the first 255 bytes, so imposing that as a max limit may encourage more useful behavior from implementations that aren't expecting the key. > > - "protocol logic": crucial point is that **behavior** is the same > > independent of presence, absence, or content of the key. Add > > or revise text to make this point. > > > Was the consensus that the original term, "functional behavior", > was clear enough, and I just muddied the water by trying to > make it more crisp? The "protocol logic" wording is not inherently a problem, but it is important that the on-the-wire "behavior" is unchanged, and "behavior" is an important word. > > - Document behavior of RFC 3720-compliant implementation that > > receives this new key and does not understand it, and how > > the other side deals with the resulting response. > > > Ok. > > > - "configure different levels" text needs to be rephrased to be > > specific that the amount of detail is what changes across levels. > > > I'm not sure about this comment because I thought the existing text > does just that. Here's what the text says today: > > all > implementations of this extension key SHOULD provide an > administrative mechanism to configure different levels of > detail in the extension key values and MUST provide an > administrative mechanism to disable sending the key. "levels of detail" seems to be less than perfectly clear. Talking about being able to set "amount of information" provided to one of several levels, and perhaps "verbosity" or "verbosity level" of the key could be clearer. > > - Align ability to configure amount of details with "SHOULD NOT" > > in Section 1.2 about administrative setting of key value. > > (the prior "SHOULD NOT" appears to conflict with this "SHOULD"). > > > Point taken - will work on it. > > > - Double-check there is a 3720-format definition of the key, > > including description clearly in the draft. > > > Was the comment that the existing declaration in section 2 > conforms to section 12 of 3720, and specifically, section > 12.22? If it does, I think you're done. We weren't 100% sure in the meeting. > > - Make the examples phony (no real company names), and remove > > the double quotes ("), as they don't appear on the wire. > > > Ok. Main intent in providing company names was to show valid > examples for implementers but I will remove them. Note that > RFC 2616 does have valid examples > > Examples: > > User-Agent: CERN-LineMode/2.15 libwww/2.17b3 > Server: Apache/0.8.4 The big concern was use of company names. Example, Inc. is definitely ok, and non-offensive parodies of the company names used are probably fair game (Dave Noveck may already be thinking up some of the latter). > > - Spaces are forbidden in text strings. See RFC 3720, Section 5.1, > > and feel free to ask on the list for options on how to deal > > with this. > > > Good catch - looks like I got carried away in my intent to provide > clear examples. 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 Thu Jul 13 15:46:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G179A-0004f0-CO; Thu, 13 Jul 2006 15:46:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1798-0004ev-Gv for ips@ietf.org; Thu, 13 Jul 2006 15:46:50 -0400 Received: from mononoke.wasabisystems.com ([66.173.145.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1796-0003Zx-6H for ips@ietf.org; Thu, 13 Jul 2006 15:46:50 -0400 Received: from [132.219.30.152] (unknown [132.219.30.152]) by mononoke.wasabisystems.com (Postfix) with ESMTP id 9D43A87187; Thu, 13 Jul 2006 15:46:47 -0400 (EDT) In-Reply-To: <44B65C5F.1060007@netapp.com> References: <44B65C5F.1060007@netapp.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <84C75C94-25F2-466C-93D5-5F754C842516@wasabisystems.com> Content-Transfer-Encoding: 7bit From: William Studenmund Subject: Re: [Ips] DRAFT Montreal minutes - X#NodeArchitecture comments Date: Thu, 13 Jul 2006 15:46:39 -0400 To: David Wysochanski X-Pgp-Agent: GPGMail 1.1.2 (Tiger) X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: ips@ietf.org, Black_David@emc.com X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Jul 13, 2006, at 10:44 AM, David Wysochanski wrote: > A couple comments a points for clarification, while this is fresh on > everyone's minds below. > >> iSCSI X#NodeArchitecture Key: Dave Wysochanski, Network Appliance >> - 30 min >> (draft-ietf-ips-iscsi-nodearch-key.txt) >> >> WG Discussion: >> - Key should be allowed only after Authentication. Revise >> draft >> to impose this restriction >> > This is actually already in there if you read the fine print of the > "Use" portion of > the declaration and note that "Any-Stage" is not there (see Section > 12 in 3720). > Since it has come up repeatedly though from various people, I will > add some > text to point this out explicitly and refer to Sections 11 and 12 > of 3720. It could also be that we just kinda forgot the exact wordings. Now that I look at it, it seems ok. So perhaps just mentioning Operational Negotiation Only somewhere in the text is ok. >> - Make sure it's a regular-size text key (not a big one, >> like the >> one used for the large numbers involved in some >> authentication >> methods). >> > Was the comment to limit the value size to 255 bytes, i.e. a single > "text-value" (or "simple-value"), as defined by 3720, or something > else? Yes, 255. The long keys are rarely used, so we wanted to keep this a short one. > I liked the comma separated values and list-of-values seemed to > fit well. But if there are concerns about key length I suppose we > can add an explicit max length of the list-of-values. Another > reviewer > raised the question about the maximum length early on so perhaps > an explicit limit is the way to go here. Well, we can get a lot in 255 bytes. :-) >> - Document behavior of RFC 3720-compliant implementation that >> receives this new key and does not understand it, >> and how >> the other side deals with the resulting response. >> > Ok. I think that you'll get back a "NotUnderstood" response, but we should check into this. :-) >> - Double-check there is a 3720-format definition of the key, >> including description clearly in the draft. > Was the comment that the existing declaration in section 2 > conforms to section 12 of 3720, and specifically, section > 12.22? I think the initial thought was something more along the lines of making sure there is a 12.whatever (less than 22) style block. And I think there is. >> - Make the examples phony (no real company names), and remove >> the double quotes ("), as they don't appear on the >> wire. >> > Ok. Main intent in providing company names was to show valid > examples for implementers but I will remove them. Note that > RFC 2616 does have valid examples > > Examples: > > User-Agent: CERN-LineMode/2.15 libwww/2.17b3 > Server: Apache/0.8.4 > > >> - Spaces are forbidden in text strings. See RFC 3720, >> Section 5.1, >> and feel free to ask on the list for options on >> how to deal >> with this. >> > Good catch - looks like I got carried away in my intent to provide > clear examples. No. I think spaces could be quite useful. My idea is to suggest that we make this key use "iSCSI-name-value" format. That would let us have a 255 byte UTF-8 string, which can encode a lot of stuff. I think it's ok for commas to be in there. The difference between having commas in an "iSCSI-name-value" and a "list-of-values" is that the latter is a list of things that make sense to iSCSI negotiation. Like Auth methods or CHAP hashes. But this key isn't supposed to be processed by login negotiation (it's passed around as an opaque string), so just happening to have commas in it is fine. They merely only have meaning for humans looking at the logs. Take care, Bill -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFEtqMlDJT2Egh26K0RAlsiAJoCI92ub7cwPfV2uycCrnGZnWK5KACfYaau 0jQ/KXw1Iz251NLeqqzOFwo= =LO0p -----END PGP SIGNATURE----- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Thu Jul 13 18:34:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G19l5-0000Iq-W1; Thu, 13 Jul 2006 18:34:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G19l4-0000Ik-Jv for ips@ietf.org; Thu, 13 Jul 2006 18:34:10 -0400 Received: from mx2.netapp.com ([216.240.18.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G19l3-0000I2-Lj for ips@ietf.org; Thu, 13 Jul 2006 18:34:10 -0400 Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2.netapp.com with ESMTP; 13 Jul 2006 15:34:09 -0700 X-IronPort-AV: i="4.06,238,1149490800"; d="txt'?scan'208"; a="392863919:sNHT24435272" Received: from [10.61.17.67] ([10.61.17.67]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id k6DMY3bw022941; Thu, 13 Jul 2006 15:34:04 -0700 (PDT) Message-ID: <44B6CA5B.6090709@netapp.com> Date: Thu, 13 Jul 2006 18:34:03 -0400 From: David Wysochanski User-Agent: Thunderbird 1.5.0.2 (X11/20060420) MIME-Version: 1.0 To: Black_David@emc.com Subject: Re: [Ips] DRAFT Montreal minutes - X#NodeArchitecture comments References: In-Reply-To: Content-Type: multipart/mixed; boundary="------------090101080006000709010506" X-Spam-Score: 0.0 (/) X-Scan-Signature: dd055ca905b7a8538e016a7989511901 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: , Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --------------090101080006000709010506 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit I think the attached addresses all of the comments below (or is pretty close). I know the format is wrong in some cases (pages too long, etc) but I'll fix that later. Diffing should be simpler. Some remaining points still for discussion: 1) Still not sure about proper use / behavioral text 2) Now explicitly states the key may be sent in either normal or discovery sessions. Specific comments / explanations below. Black_David@emc.com wrote: > Dave, > > > A couple comments a points for clarification, while this is fresh on > > everyone's minds below. > > > > > iSCSI X#NodeArchitecture Key: Dave Wysochanski, Network Appliance - 30 > min > > > (draft-ietf-ips-iscsi-nodearch-key.txt) > > > > > > WG Discussion: > > > - Key should be allowed only after Authentication. Revise > draft > > > to impose this restriction > > > > > This is actually already in there if you read the fine print of the > "Use" > portion of > > the declaration and note that "Any-Stage" is not there (see Section > 12 in > 3720). > > Since it has come up repeatedly though from various people, I will add > some > > text to point this out explicitly and refer to Sections 11 and 12 of > 3720. > > Yes, please do that. > This has been fixed with a small change to the first sentence of paragraph 3, section 1.2 and added a second paragraph in section 2. > > > - Make sure it's a regular-size text key (not a big one, like > the > > > one used for the large numbers involved in some > authentication > > > methods). > > > > > Was the comment to limit the value size to 255 bytes, i.e. a single > > "text-value" (or "simple-value"), as defined by 3720, or something else? > > Limiting the value size to 255 bytes was the intention. > > > I liked the comma separated values and list-of-values seemed to > > fit well. But if there are concerns about key length I suppose we > > can add an explicit max length of the list-of-values. Another reviewer > > raised the question about the maximum length early on so perhaps > > an explicit limit is the way to go here. > > An explicit limit is probably a good idea, as an implementation that > receives this key and doesn't recognize it may only log the first > 255 bytes, so imposing that as a max limit may encourage more useful > behavior from implementations that aren't expecting the key. > Addressed in Section 2. > > > - "protocol logic": crucial point is that **behavior** is the > same > > > independent of presence, absence, or content of the > key. > Add > > > or revise text to make this point. > > > > > Was the consensus that the original term, "functional behavior", > > was clear enough, and I just muddied the water by trying to > > make it more crisp? > > The "protocol logic" wording is not inherently a problem, but it is > important > that the on-the-wire "behavior" is unchanged, and "behavior" is an > important > word. > I put back the "functional behavior" term and made my added "protocol logic" sentence parenthetical. Please let me know if this hits the mark. > > > - Document behavior of RFC 3720-compliant implementation that > > > receives this new key and does not understand it, and > how > > > the other side deals with the resulting response. > > > > > Ok. > > Adddressed with last paragraph added in 1.2. The paragraph starts with a short discussion about possible valid implementations, which complements part of the latter security section. > > > - "configure different levels" text needs to be rephrased > to be > > > specific that the amount of detail is what changes > across levels. > > > > > I'm not sure about this comment because I thought the existing text > > does just that. Here's what the text says today: > > > > all > > implementations of this extension key SHOULD provide an > > administrative mechanism to configure different levels of > > detail in the extension key values and MUST provide an > > administrative mechanism to disable sending the key. > > "levels of detail" seems to be less than perfectly clear. Talking > about being able to set "amount of information" provided to one of > several levels, and perhaps "verbosity" or "verbosity level" of > the key could be clearer. > I think this is clearer now. Please see paragraph 2, section 3. > > > - Align ability to configure amount of details with "SHOULD > NOT" > > > in Section 1.2 about administrative setting of key > value. > > > (the prior "SHOULD NOT" appears to conflict with this > "SHOULD"). > > > > > Point taken - will work on it. > > Also, I think addressed with slight modification to 3rd paragraph of section 1.2 > > > - Double-check there is a 3720-format definition of the key, > > > including description clearly in the draft. > > > > > Was the comment that the existing declaration in section 2 > > conforms to section 12 of 3720, and specifically, section > > 12.22? > > If it does, I think you're done. We weren't 100% sure in the meeting. > I double checked this and I think for the most part it is there. However, upon examination and more thinking, I do not see or remember a reason to preclude use in discovery sessions (again, logging may be useful), and 3270 does not seem to forbid declarative keys in discovery sessions (are declarative keys "requests"?). Thus, I've clarified some text to make this clear. Please let me know if there are objections to this. If so, I will add "Irrelevant when: SessionType=Discovery" to the key declaration and remove the references to discovery sessions. > > > - Make the examples phony (no real company names), and remove > > > the double quotes ("), as they don't appear on the > wire. > > > > > Ok. Main intent in providing company names was to show valid > > examples for implementers but I will remove them. Note that > > RFC 2616 does have valid examples > > > > Examples: > > > > User-Agent: CERN-LineMode/2.15 libwww/2.17b3 > > Server: Apache/0.8.4 > > The big concern was use of company names. Example, Inc. is definitely > ok, and non-offensive parodies of the company names used are probably > fair game (Dave Noveck may already be thinking up some of the latter). > Done. > > > - Spaces are forbidden in text strings. See RFC 3720, Section > 5.1, > > > and feel free to ask on the list for options on how to > deal > > > with this. > > > > > Good catch - looks like I got carried away in my intent to provide > > clear examples. > Replaced all spaces with underscores. --------------090101080006000709010506 Content-Type: text/plain; name="draft-ietf-ips-iscsi-nodearch-key-01r2.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="draft-ietf-ips-iscsi-nodearch-key-01r2.txt" INTERNET-DRAFT Dave Wysochanski Expires: November 4, 2006 Network Appliance, Inc May 4, 2006 Declarative Public Extension Key for iSCSI Node Architecture draft-ietf-ips-iscsi-nodearch-key-01r2.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on November 4, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract The iSCSI protocol, described in [RFC3720], allows for extension items to the protocol in the form of Private or Public Extension Keys. This Internet-Draft describes a Public Extension Key for the purpose of enhancing iSCSI supportability. The key accomplishes this objective by allowing iSCSI nodes to communicate architecture details during the iSCSI login sequence. The receiving node can then use this information for enhanced logging and support. Wysochanski Expires November 4, 2006 [Page 1] Internet-Draft iSCSI Node Architecture July 2006 1. Introduction 1.1 Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 1.2 Overview This Internet-Draft describes a declarative Public Extension Key as defined by section 12.22 of [RFC3720] that may be used to communicate additional iSCSI node information to the opposite node in a session. The information carried in the described 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 key has been modeled after the "Server" and "User-Agent" header fields as specified in sections 14.38 and 14.43 of [RFC2616], with the text-value(s) of the key roughly equivalent to Product Tokens in section 3.8 of [RFC2616]. Note however that the text-value(s) in the keys list-of-values MUST conform to the Text Format as specified in section 5.1 of [RFC3720]. The key is sent during operational parameter negotiation of an iSCSI session's login phase. The intended use of this key is to provide enhanced logging and support capabilities, and to enable collection of iSCSI implementation and usage information. Functional behavior of the iSCSI node (this includes the iSCSI protocol logic -- the SCSI, iSCSI, and TCP/IP protocols) MUST NOT depend on the presence, absence, or content of the key. The key MUST NOT be used by iSCSI nodes for interoperability, or exclusion or deception of other nodes. To ensure proper use, key values SHOULD be set by the node itself, and there SHOULD NOT be provisions for the key values to contain user-defined text. Nodes implementing this key may choose to only transmit the key, only log the key values received from other nodes, or both transmit and log the key values. Each node choosing to implement transmission of the key values MUST be prepared to handle the response of [RFC3720] compliant nodes that do not understand the key ([RFC3720] states that compliant nodes MUST respond with X#NodeArchitecture=NotUnderstood). Wysochanski Expires November 4, 2006 [Page 2] Internet-Draft iSCSI Node Architecture July 2006 2. Definition The definition of the key is as follows, conforming to sections 11 and 12 of [RFC3720], with example list-of-values conforming to section 5.1 of [RFC3720]. The key is defined with a Use of "LO", making it a Leading Only key, and does not amend sections 11 or 12 of [RFC3720]. Thus, the key MUST only be sent on the leading connection, MUST NOT be changed after the leading connection login, and MUST only be sent after the security negotiation login stage has completed (during operational negotiation login stage). The key may be sent during normal or discovery sessions. X#NodeArchitecture Use: LO, Declarative Senders: Initiator and Target Scope: SW X#NodeArchitecture= Examples: X#NodeArchitecture=ExampleInc_Software_Initiator/1.05a, ExampleInc_OperatingSystem/2003Build1489, ExampleInc_Cluster_Services/2.0, CPU_Architecture/x86_64 X#NodeArchitecture=ExampleInc_iSCSI_4010_Hardware_Initiator/rev1, ExampleInc_Firmware/2.0.0.5, ExampleInc_Driver/2.0.0.1 X#NodeArchitecture=Linux_iSCSI_Software_Initiator/4:0.1.11-3, ExampleInc_Enterprise_Linux/4u3, Linux_Kernel/2.6.9-34.26.ELsmp, CPU_Architecture/i686, CPU_Speed/3.06GHz, Memory_Size/4059364kB X#NodeArchitecture=ExampleInc_Software_Target/7.1, ExampleInc_Firmware/7.1, ExampleInc_Model/270c 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, iSCSI vendor software, firmware, or hardware versions, the OS version, or hardware architecture. The length of the key value (total length of the list-of-values) MUST NOT be greater than 255 bytes. X#NodeArchitecture MUST NOT be redeclared. Wysochanski Expires November 4, 2006 [Page 3] Internet-Draft iSCSI Node Architecture July 2006 3. Security Considerations This extension key transmits specific implementation details about the node that sends it; such details may be considered sensitive in some environments. For example, if a certain software or firmware version is known to contain security weaknesses, announcing the presence of that version via this key may not be desirable. The countermeasures for this security concern are: - sending less detailed information in the key values, or - not sending the extension key, or - using IPsec to provide confidentiality for the iSCSI connection on which the key is sent (see [RFC3720] and [RFC3723]). To support the first and second countermeasures, all implementations of this extension key MUST provide an administrative mechanism to disable sending the key. In addition, all implementations SHOULD provide an administrative mechanism to configure a verbosity level of the key value, thereby controlling the amount of information sent. For example, a lower verbosity might enable transmission of node architecture component names only, but no version numbers. The choice of which countermeasure is most appropriate depends on the environment. However, the first countermeasure may be acceptable in many environments, since it provides a compromise between sending too much information and the other more complete countermeasures of not sending the key at all or using IPsec. In addition to security considerations involving transmission of the key contents, any logging method(s) used for the key values MUST keep the information secure from intruders. For all implementations, the requirements to address this security concern are: - display of the log MUST only be possible with administrative rights to the node - options to disable logging to disk and to keep logs for a fixed duration SHOULD be provided Finally, it is important to note that different nodes may have different levels of risk, and these differences may affect the implementation. The components of risk include assets, threats, and vulnerabilities. Consider the following example iSCSI nodes, which demonstrate differences in assets and vulnerabilities of the nodes, and as a result, differences in implementation: - One iSCSI target based on a special-purpose operating system. Since the iSCSI target controls access to the data storage containing company assets, the asset level is seen as very high. Also, because of the special-purpose operating system, in which vulnerabilities are less well-known, the vulnerability level is viewed as low. - Multiple iSCSI initiators in a blade farm, each running a general-purpose operating system. The asset level of each node is viewed as low, since blades are replaceable and low cost. However, the vulnerability level is viewed as high, since there are many well-known vulnerabilities to the general-purpose operating system. For the above target, an appropriate implementation might be logging of received key values, but no transmission of the key. For the initiators, an appropriate implementation might be transmission of the key, but no logging of received key values. Wysochanski Expires November 4, 2006 [Page 4] Internet-Draft iSCSI Node Architecture July 2006 4. IANA Considerations This document defines the iSCSI Extension Key NodeArchitecture to be registered in the IANA iSCSI extended key registry. Wysochanski Expires November 4, 2006 [Page 5] Internet-Draft iSCSI Node Architecture July 2006 5. References 5.1 Normative References [RFC2119] Bradner, S. "Key Words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3720] Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka, M., and E. Zeidner, "Internet Small Computer Systems Interface (iSCSI)", RFC 3720, April 2004. 5.2 Informative References [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [RFC3723] Adoba, B., Tseng, J., Walker, J., Rangan, V., and Travostino, F., "Securing Block Storage Protocols over IP", RFC 3723, April 2004. Wysochanski Expires November 4, 2006 [Page 6] Internet-Draft iSCSI Node Architecture July 2006 6. Author's Address Dave Wysochanski Network Appliance, Inc. 7301 Kit Creek Road P. O. Box 13917 Research Triangle, NC 27709 Phone: +1-919-476-5628 E-mail: davidw@netapp.com Wysochanski Expires November 4, 2006 [Page 7] Internet-Draft iSCSI Node Architecture July 2006 7. Acknowledgements The IP Storage (ips) Working Group in the Transport Area of IETF has been responsible for defining the iSCSI protocol (apart from a host of other relevant IP Storage protocols). The editor acknowledges the contributions of the entire working group. The following individuals directly contributed to identifying issues and/or suggesting resolutions to the issues found in this document: David Black, Mallikarjun Chadalapaka, Paul Koning, Julian Satran, John Hufferd, Claire Kraft, Ranga Sankar, Joseph Pittman, Greg Berg, John Forte, and Jim Yuill. This document benefited from all these contributions. Wysochanski Expires November 4, 2006 [Page 8] Internet-Draft iSCSI Node Architecture July 2006 8. Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Wysochanski Expires November 4, 2006 [Page 9] Internet-Draft iSCSI Node Architecture July 2006 9. Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Wysochanski Expires November 4, 2006 [Page 10] --------------090101080006000709010506 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --------------090101080006000709010506-- From ips-bounces@ietf.org Thu Jul 13 18:39:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G19qP-0000kB-9y; Thu, 13 Jul 2006 18:39:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G19qO-0000k6-AH for ips@ietf.org; Thu, 13 Jul 2006 18:39:40 -0400 Received: from mx2.netapp.com ([216.240.18.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G19qO-0000p9-0R for ips@ietf.org; Thu, 13 Jul 2006 18:39:40 -0400 Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2.netapp.com with ESMTP; 13 Jul 2006 15:39:40 -0700 X-IronPort-AV: i="4.06,238,1149490800"; d="scan'208"; a="392865577:sNHT47715040" Received: from [10.61.17.67] ([10.61.17.67]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id k6DMda5x025166; Thu, 13 Jul 2006 15:39:38 -0700 (PDT) Message-ID: <44B6CBA8.1010509@netapp.com> Date: Thu, 13 Jul 2006 18:39:36 -0400 From: David Wysochanski User-Agent: Thunderbird 1.5.0.2 (X11/20060420) MIME-Version: 1.0 To: William Studenmund Subject: Re: [Ips] DRAFT Montreal minutes - X#NodeArchitecture comments References: <44B65C5F.1060007@netapp.com> <84C75C94-25F2-466C-93D5-5F754C842516@wasabisystems.com> In-Reply-To: <84C75C94-25F2-466C-93D5-5F754C842516@wasabisystems.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: ips@ietf.org, Black_David@emc.com X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org William Studenmund wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Jul 13, 2006, at 10:44 AM, David Wysochanski wrote: > > > A couple comments a points for clarification, while this is fresh on > > everyone's minds below. > > > >> iSCSI X#NodeArchitecture Key: Dave Wysochanski, Network Appliance > >> - 30 min > >> (draft-ietf-ips-iscsi-nodearch-key.txt) > >> > >> WG Discussion: > >> - Key should be allowed only after Authentication. Revise > >> draft > >> to impose this restriction > >> > > This is actually already in there if you read the fine print of the > > "Use" portion of > > the declaration and note that "Any-Stage" is not there (see Section > > 12 in 3720). > > Since it has come up repeatedly though from various people, I will > > add some > > text to point this out explicitly and refer to Sections 11 and 12 > > of 3720. > > It could also be that we just kinda forgot the exact wordings. Now > that I look at it, it seems ok. So perhaps just mentioning > Operational Negotiation Only somewhere in the text is ok. > > >> - Make sure it's a regular-size text key (not a big one, > >> like the > >> one used for the large numbers involved in some > >> authentication > >> methods). > >> > > Was the comment to limit the value size to 255 bytes, i.e. a single > > "text-value" (or "simple-value"), as defined by 3720, or something > > else? > > Yes, 255. The long keys are rarely used, so we wanted to keep this a > short one. > > > I liked the comma separated values and list-of-values seemed to > > fit well. But if there are concerns about key length I suppose we > > can add an explicit max length of the list-of-values. Another > > reviewer > > raised the question about the maximum length early on so perhaps > > an explicit limit is the way to go here. > > Well, we can get a lot in 255 bytes. :-) > > >> - Document behavior of RFC 3720-compliant implementation that > >> receives this new key and does not understand it, > >> and how > >> the other side deals with the resulting response. > >> > > Ok. > > I think that you'll get back a "NotUnderstood" response, but we > should check into this. :-) > > >> - Double-check there is a 3720-format definition of the key, > >> including description clearly in the draft. > > Was the comment that the existing declaration in section 2 > > conforms to section 12 of 3720, and specifically, section > > 12.22? > > I think the initial thought was something more along the lines of > making sure there is a 12.whatever (less than 22) style block. And I > think there is. > > >> - Make the examples phony (no real company names), and remove > >> the double quotes ("), as they don't appear on the > >> wire. > >> > > Ok. Main intent in providing company names was to show valid > > examples for implementers but I will remove them. Note that > > RFC 2616 does have valid examples > > > > Examples: > > > > User-Agent: CERN-LineMode/2.15 libwww/2.17b3 > > Server: Apache/0.8.4 > > > > > >> - Spaces are forbidden in text strings. See RFC 3720, > >> Section 5.1, > >> and feel free to ask on the list for options on > >> how to deal > >> with this. > >> > > Good catch - looks like I got carried away in my intent to provide > > clear examples. > > No. I think spaces could be quite useful. My idea is to suggest that > we make this key use "iSCSI-name-value" format. That would let us > have a 255 byte UTF-8 string, which can encode a lot of stuff. > > I think it's ok for commas to be in there. The difference between > having commas in an "iSCSI-name-value" and a "list-of-values" is that > the latter is a list of things that make sense to iSCSI negotiation. > Like Auth methods or CHAP hashes. But this key isn't supposed to be > processed by login negotiation (it's passed around as an opaque > string), so just happening to have commas in it is fine. They merely > only have meaning for humans looking at the logs. > Ok, may have to revisit this one. I think all the other comments are the same as David's and/or have been addressed. Thanks for the feedback. _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Fri Jul 21 17:02:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4294-0004SG-Ry; Fri, 21 Jul 2006 17:02:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G416l-0001we-TC for ips@ietf.org; Fri, 21 Jul 2006 15:56:23 -0400 Received: from mexforward.lss.emc.com ([128.222.32.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G40w3-0001JN-Nw for ips@ietf.org; Fri, 21 Jul 2006 15:45:20 -0400 Received: from mailhub.lss.emc.com (uraeus.lss.emc.com [10.254.144.14]) by mexforward.lss.emc.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k6LJjFxt015435 for ; Fri, 21 Jul 2006 15:45:19 -0400 (EDT) Received: from mxic2.corp.emc.com (mxic2.corp.emc.com [128.221.12.9]) by mailhub.lss.emc.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k6LJjC3l012772 for ; Fri, 21 Jul 2006 15:45:13 -0400 (EDT) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Fri, 21 Jul 2006 15:45:12 -0400 Message-ID: From: Black_David@emc.com To: ips@ietf.org Date: Fri, 21 Jul 2006 15:45:07 -0400 Importance: high X-Priority: 1 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.7.21.121432 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -2, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __HAS_X_PRIORITY 0, __IMS_MSGID 0, __IMS_MUA 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0' X-Spam-Score: 0.3 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 Subject: [Ips] FINAL Montreal minutes 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: , Errors-To: ips-bounces@ietf.org Having seen no comments on the list, these are now the final Montreal minutes, and the "IMPORTANT:" note about the merits of adding SASL to iSCSI is now the rough consensus of the IP Storage WG. As the minutes say: There may be a draft forthcoming that will add SASL to iSCSI - the sense of the room is that this would be a good thing to do, although it is not of immediate urgency. Thanks, --David (ips WG chair) ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- -----Original Message----- From: Black, David Sent: Wednesday, July 12, 2006 7:52 PM To: ips@ietf.org Cc: Black, David Subject: DRAFT Montreal minutes Importance: High We actually managed to use the entire hour, and (IMHO) had very productive discussions. Please send any corrections to the DRAFT minutes below to me (and cc: the list if you want to). IMPORTANT: The sense of the room in Montreal was that adding SASL to iSCSI is a good way to: - Obtain an authentication method or methods based on SHA-256 - Address issues with the current Kerberos and SPKM methods. There is no current intent to make any SASL method mandatory or remove the mandatory-to-implement status of iSCSI CHAP. Anyone who disagrees with the above sense-of-the-room conclusions should post that disagreement to the list promptly along with an explanation of why - *please* change the subject line of the email when doing so. Absent such posts, this "SASL is a good thing to add" direction will become the rough consensus of the IPS WG. Thanks, --David (ips WG chair) IP Storage (ips) WG Meeting Minutes - DRAFT Wednesday, July 12, 2006 - 1510-1610 Montreal, Quebec, Canada ----------------------------------- Administrivia, agenda bashing, draft status review, etc. - 15 min David L. Black, EMC (chair) Blue sheets Note Well Draft status - projected from I-D tracker - Lots of published RFCs - iSER and DA drafts are paused waiting for the RDDP drafts that they depend on. The RDDP drafts are starting to move. - iSNS MIB has received MIB Doctor review, and a revised draft is in preparation (significant work is involved) - Implementers Guide is in WG, but not much activity. Likely to be WG Last Called before next IETF. Most important material in that draft involves task management operations that may affect more than one task (e.g., ABORT TASK SET, CLEAR TASK SET, LOGICAL UNIT RESET, TARGET RESET) - please review this material. Not on today's agenda - Node Architecture draft. Will be worked on today. Milestones - Dec 2006 for Node Architecture Draft - Jan 2007 for Implementers Guide Draft - Both appear reasonable. WG chair will be pushing ISER, DA, and iSNS MIB drafts through the process. iSCSI X#NodeArchitecture Key: Dave Wysochanski, Network Appliance - 30 min (draft-ietf-ips-iscsi-nodearch-key.txt) WG Discussion: - Key should be allowed only after Authentication. Revise draft to impose this restriction - Make sure it's a regular-size text key (not a big one, like the one used for the large numbers involved in some authentication methods). - "protocol logic": crucial point is that **behavior** is the same independent of presence, absence, or content of the key. Add or revise text to make this point. - Document behavior of RFC 3720-compliant implementation that receives this new key and does not understand it, and how the other side deals with the resulting response. - "configure different levels" text needs to be rephrased to be specific that the amount of detail is what changes across levels. - Align ability to configure amount of details with "SHOULD NOT" in Section 1.2 about administrative setting of key value. (the prior "SHOULD NOT" appears to conflict with this "SHOULD"). - Double-check there is a 3720-format definition of the key, including description clearly in the draft. - Make the examples phony (no real company names), and remove the double quotes ("), as they don't appear on the wire. - Spaces are forbidden in text strings. See RFC 3720, Section 5.1, and feel free to ask on the list for options on how to deal with this. iSCSI Security Mechanisms: WG Members - time remaining (if any) The IETF Security Area has requested that IETF Working Groups plan to transition away from usage of MD5. iSCSI CHAP currently uses MD5 in a fashion not directly threatened by the hash collision results known for MD5. If time is available in the meeting, it will be used to discuss what to do instead, as using a different hash with CHAP is not the only option. Above description is copied verbatim from Dallas agenda. There are two other related concerns: a) The Kerberos support in iSCSI is frowned upon by Kerberos experts. iSCSI Kerberos is not GSSAPI-based, and hence can't be used with GSSAPI-only Kerberos implementations. b) The SPKM-1 and SPKM-2 methods are arguably obsolete. SASL is a potential means of addressing all of these problems: - SASL has and/or will have methods based on SHA-256, the next hash of choice (according to the IETF Security Area) - SASL has GSSAPI-based Kerberos support that has been designed by Kerberos experts - SASL has an SPKM-3 method. The approach would be to add SASL methods to iSCSI by doing mapping the SASL tokens into iSCSI and providing authentication mechanism names (e.g., the SASL mechanism is negotiated by iSCSI as the SASL- mechanism). These would be additions - the current must-implement CHAP mechanism is not broken, and would not be removed. There may be a draft forthcoming that will add SASL to iSCSI - the sense of the room is that this would be a good thing to do, although it is not of immediate urgency. Open Mike - Roger Cummings noted that RFC 3720 is based on SAM-2; SAM-3 has appeared resulting in SCSI work in T10 that requires SAM-3. One example is encrypting tape drive work in T10 that relies upon a new well-known logical unit definition that is only in SAM-3. This is a reason to work on updating iSCSI to SAM-3. The WG chair commented that such an update would be backwards compatible, and would require the active involvement of a SCSI guru to ensure that the interactions with the SAM-3 specification are correct. _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Wed Jul 26 08:11:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5iE9-0007Bm-FH; Wed, 26 Jul 2006 08:11:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5iE8-0007BQ-PY for ips@ietf.org; Wed, 26 Jul 2006 08:11:00 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5gHk-0008VY-M2 for ips@ietf.org; Wed, 26 Jul 2006 06:06:36 -0400 Received: from sineb-mail-2.sun.com ([192.18.19.7]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G5g5n-0003Ww-CQ for ips@ietf.org; Wed, 26 Jul 2006 05:54:18 -0400 Received: from fe-apac-04.sun.com (fe-apac-04.sun.com [192.18.19.175] (may be forged)) by sineb-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k6Q9s4HK026547 for ; Wed, 26 Jul 2006 17:54:10 +0800 (SGT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0J3000A018TXKK00@mail-apac.sun.com> (original mail from Victor.Li@Sun.COM) for ips@ietf.org; Wed, 26 Jul 2006 17:54:04 +0800 (SGT) Received: from [129.158.144.125] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0J3000D688U2VHT0@mail-apac.sun.com> for ips@ietf.org; Wed, 26 Jul 2006 17:54:03 +0800 (SGT) Date: Wed, 26 Jul 2006 17:56:26 +0800 From: Victor Li To: ips@ietf.org Message-id: <44C73C4A.3080704@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: zh-cn User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; zh-CN; rv:1.7) Gecko/20060221 X-Spam-Score: -2.6 (--) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Subject: [Ips] iSNS: authentication of Control Node 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: , Errors-To: ips-bounces@ietf.org I have a qeustion on the authentication of control nodes. As it is described in RFC 4171 section 2.3.5, a Management Station can be a control node. Is the authorization for a control node by comparing the node names only? then anybody can use this name to make a fake control node if administrative settings on the server are readable to anybody. Are there any other ways to solve the security issue? Thanks, Victor _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From abbcd@0451.com Thu Jul 27 12:40:02 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G68u2-0007vn-5N; Thu, 27 Jul 2006 12:40:02 -0400 Received: from static-213-182-106-63.teleos-web.de ([213.182.106.63]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G68tx-0006r5-Jf; Thu, 27 Jul 2006 12:40:02 -0400 Date: Thu, 27 Jul 2006 16:40:25 -0060 From: "Elisa Fox" X-Mailer: The Bat! (v2.00) Personal Reply-To: "Elisa Fox" X-Priority: 3 (Normal) Message-ID: <403527804.20060727164025@0451.com> To: iporpr-archive@lists.ietf.org Subject: Your cash, passing strake MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 4.2 (++++) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Even if you have no erectin problems SOFT CIAYLIS would help you to make BETTER SEWX MORE OFTEN! and to bring unimagnable plesure to her. Just disolve half a pil under your tongue and get ready for action in 15 minutes. The tests showed that the majority of men after taking this medic ation were able to have PERFECT ERJECTION during 36 hours! VISIT US, AND GET OUR SPECIAL 70% DISC1OUNT OFER! http://wfwrcl.bigbacks.info/?99865114 ========== Outcast. "Family?" "... for his reckless irresponsibility " the solemn voice intoned, "There is a steady leak of materials from the Visitation Zones into the was very nearly Fletcher's top speed. twenty feet away and it's completely rusted out, but they look like they've inventiveness marvelous to behold. "At ease, sergeant," said. "I'm pleased." From ips-bounces@ietf.org Mon Jul 31 17:36:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7fRB-0006XT-O7; Mon, 31 Jul 2006 17:36:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7fRA-0006XN-FD for ips@ietf.org; Mon, 31 Jul 2006 17:36:32 -0400 Received: from mx2.netapp.com ([216.240.18.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7fR9-00077w-FM for ips@ietf.org; Mon, 31 Jul 2006 17:36:32 -0400 Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2.netapp.com with ESMTP; 31 Jul 2006 14:36:31 -0700 X-IronPort-AV: i="4.07,199,1151910000"; d="scan'208"; a="397140916:sNHT86483752" Received: from [10.61.17.67] ([10.61.17.67]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id k6VLaRJS013672; Mon, 31 Jul 2006 14:36:29 -0700 (PDT) Message-ID: <44CE77DA.0@netapp.com> Date: Mon, 31 Jul 2006 17:36:26 -0400 From: David Wysochanski User-Agent: Thunderbird 1.5.0.2 (X11/20060420) MIME-Version: 1.0 To: William Studenmund , Black_David@emc.com Subject: Re: [Ips] DRAFT Montreal minutes - X#NodeArchitecture comments References: <44B6CA5B.6090709@netapp.com> In-Reply-To: <44B6CA5B.6090709@netapp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: c25c25eef92c03b403abac6c7c688517 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: , Errors-To: ips-bounces@ietf.org Ping on the 2 items below - any comments? Also adding a 3rd item: 3) Change key value format from list-of-values to "iSCSI-name-value" (see 7/13/06 post). For this one, I'd rather leave it as list-of-values, since this is simple, underscores are just about as readable as spaces, and iSCSI-name-value seems a little strange to me in this context. Wysochanski, David wrote: > I think the attached addresses all of the comments > below (or is pretty close). I know the format > is wrong in some cases (pages too long, etc) but I'll > fix that later. Diffing should be simpler. > > Some remaining points still for discussion: > 1) Still not sure about proper use / behavioral text > 2) Now explicitly states the key may be sent in either > normal or discovery sessions. > > Specific comments / explanations below. > > > Black_David@emc.com wrote: > > Dave, > > > > > A couple comments a points for clarification, while this is fresh on > > > everyone's minds below. > > > > > > > iSCSI X#NodeArchitecture Key: Dave Wysochanski, Network > Appliance - 30 > > min > > > > (draft-ietf-ips-iscsi-nodearch-key.txt) > > > > > > > > WG Discussion: > > > > - Key should be allowed only after Authentication. Revise > > draft > > > > to impose this restriction > > > > > > > This is actually already in there if you read the fine print of the > > "Use" > > portion of > > > the declaration and note that "Any-Stage" is not there (see Section > > 12 in > > 3720). > > > Since it has come up repeatedly though from various people, I will > add > > some > > > text to point this out explicitly and refer to Sections 11 and 12 of > > 3720. > > > > Yes, please do that. > > > > This has been fixed with a small change to the first > sentence of paragraph 3, section 1.2 and added a > second paragraph in section 2. > > > > > > - Make sure it's a regular-size text key (not a big one, > like > > the > > > > one used for the large numbers involved in some > > authentication > > > > methods). > > > > > > > Was the comment to limit the value size to 255 bytes, i.e. a single > > > "text-value" (or "simple-value"), as defined by 3720, or something > else? > > > > Limiting the value size to 255 bytes was the intention. > > > > > I liked the comma separated values and list-of-values seemed to > > > fit well. But if there are concerns about key length I suppose we > > > can add an explicit max length of the list-of-values. Another > reviewer > > > raised the question about the maximum length early on so perhaps > > > an explicit limit is the way to go here. > > > > An explicit limit is probably a good idea, as an implementation that > > receives this key and doesn't recognize it may only log the first > > 255 bytes, so imposing that as a max limit may encourage more useful > > behavior from implementations that aren't expecting the key. > > > > Addressed in Section 2. > > > > > > - "protocol logic": crucial point is that **behavior** > is the > > same > > > > independent of presence, absence, or content of the > > key. > > Add > > > > or revise text to make this point. > > > > > > > Was the consensus that the original term, "functional behavior", > > > was clear enough, and I just muddied the water by trying to > > > make it more crisp? > > > > The "protocol logic" wording is not inherently a problem, but it is > > important > > that the on-the-wire "behavior" is unchanged, and "behavior" is an > > important > > word. > > > > I put back the "functional behavior" term and made > my added "protocol logic" sentence parenthetical. > Please let me know if this hits the mark. > > > > > > - Document behavior of RFC 3720-compliant implementation > that > > > > receives this new key and does not understand > it, and > > how > > > > the other side deals with the resulting response. > > > > > > > Ok. > > > > > Adddressed with last paragraph added in 1.2. > The paragraph starts with a short discussion about > possible valid implementations, which complements > part of the latter security section. > > > > > > - "configure different levels" text needs to be rephrased > > to be > > > > specific that the amount of detail is what changes > > across levels. > > > > > > > I'm not sure about this comment because I thought the existing text > > > does just that. Here's what the text says today: > > > > > > all > > > implementations of this extension key SHOULD provide an > > > administrative mechanism to configure different levels of > > > detail in the extension key values and MUST provide an > > > administrative mechanism to disable sending the key. > > > > "levels of detail" seems to be less than perfectly clear. Talking > > about being able to set "amount of information" provided to one of > > several levels, and perhaps "verbosity" or "verbosity level" of > > the key could be clearer. > > > > I think this is clearer now. Please see paragraph > 2, section 3. > > > > > > - Align ability to configure amount of details with "SHOULD > > NOT" > > > > in Section 1.2 about administrative setting of key > > value. > > > > (the prior "SHOULD NOT" appears to conflict with > this > > "SHOULD"). > > > > > > > Point taken - will work on it. > > > > > Also, I think addressed with slight modification to > 3rd paragraph of section 1.2 > > > > > > - Double-check there is a 3720-format definition of the > key, > > > > including description clearly in the draft. > > > > > > > Was the comment that the existing declaration in section 2 > > > conforms to section 12 of 3720, and specifically, section > > > 12.22? > > > > If it does, I think you're done. We weren't 100% sure in the meeting. > > > > I double checked this and I think for the most part it > is there. However, upon examination and more thinking, > I do not see or remember a reason to preclude use in > discovery sessions (again, logging may be useful), and > 3270 does not seem to forbid declarative keys in discovery > sessions (are declarative keys "requests"?). Thus, I've > clarified some text to make this clear. Please let me > know if there are objections to this. If so, I will add > "Irrelevant when: SessionType=Discovery" to the key > declaration and remove the references to discovery sessions. > > > > > > - Make the examples phony (no real company names), and > remove > > > > the double quotes ("), as they don't appear on the > > wire. > > > > > > > Ok. Main intent in providing company names was to show valid > > > examples for implementers but I will remove them. Note that > > > RFC 2616 does have valid examples > > > > > > Examples: > > > > > > User-Agent: CERN-LineMode/2.15 libwww/2.17b3 > > > Server: Apache/0.8.4 > > > > The big concern was use of company names. Example, Inc. is definitely > > ok, and non-offensive parodies of the company names used are probably > > fair game (Dave Noveck may already be thinking up some of the latter). > > > > Done. > > > > > > - Spaces are forbidden in text strings. See RFC 3720, > Section > > 5.1, > > > > and feel free to ask on the list for options on > how to > > deal > > > > with this. > > > > > > > Good catch - looks like I got carried away in my intent to provide > > > clear examples. > > > > Replaced all spaces with underscores. > > > > ------------------------------------------------------------------------ > > INTERNET-DRAFT Dave Wysochanski > Expires: November 4, 2006 Network Appliance, Inc > May 4, 2006 > > > > Declarative Public Extension Key for iSCSI Node Architecture > draft-ietf-ips-iscsi-nodearch-key-01r2.txt > > > Status of this Memo > > By submitting this Internet-Draft, each author represents > that any applicable patent or other IPR claims of which he or > she is aware have been or will be disclosed, and any of which > he or she becomes aware will be disclosed, in accordance with > Section 6 of BCP 79. > > Internet-Drafts are working documents of the Internet > Engineering Task Force (IETF), its areas, and its working > groups. Note that other groups may also distribute working > documents as Internet-Drafts. > > Internet-Drafts are draft documents valid for a maximum of > six months and may be updated, replaced, or obsoleted by > other documents at any time. It is inappropriate to use > Internet-Drafts as reference material or to cite them other > than as "work in progress." > > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/1id-abstracts.html > > The list of Internet-Draft Shadow Directories can be accessed > at http://www.ietf.org/shadow.html. > > This Internet-Draft will expire on November 4, 2006. > > Copyright Notice > > Copyright (C) The Internet Society (2006). > > Abstract > > The iSCSI protocol, described in [RFC3720], allows for extension > items to the protocol in the form of Private or Public Extension > Keys. This Internet-Draft describes a Public Extension Key for > the purpose of enhancing iSCSI supportability. The key > accomplishes this objective by allowing iSCSI nodes to > communicate architecture details during the iSCSI login > sequence. The receiving node can then use this information > for enhanced logging and support. > > > Wysochanski Expires November 4, 2006 [Page 1] > > > > Internet-Draft iSCSI Node Architecture July 2006 > > 1. Introduction > > 1.1 Terminology > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in > this document are to be interpreted as described in [RFC2119]. > > 1.2 Overview > > This Internet-Draft describes a declarative Public Extension > Key as defined by section 12.22 of [RFC3720] that may be used to > communicate additional iSCSI node information to the opposite > node in a session. The information carried in the described > 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 key has been modeled after the "Server" and "User-Agent" > header fields as specified in sections 14.38 and 14.43 of > [RFC2616], with the text-value(s) of the key roughly equivalent > to Product Tokens in section 3.8 of [RFC2616]. Note however > that the text-value(s) in the keys list-of-values MUST conform > to the Text Format as specified in section 5.1 of [RFC3720]. > > The key is sent during operational parameter negotiation of an > iSCSI session's login phase. The intended use of this key is > to provide enhanced logging and support capabilities, and to > enable collection of iSCSI implementation and usage information. > Functional behavior of the iSCSI node (this includes the iSCSI > protocol logic -- the SCSI, iSCSI, and TCP/IP protocols) MUST NOT > depend on the presence, absence, or content of the key. The key > MUST NOT be used by iSCSI nodes for interoperability, or exclusion > or deception of other nodes. To ensure proper use, key values > SHOULD be set by the node itself, and there SHOULD NOT be > provisions for the key values to contain user-defined text. > > Nodes implementing this key may choose to only transmit the > key, only log the key values received from other nodes, or both > transmit and log the key values. Each node choosing to implement > transmission of the key values MUST be prepared to handle the > response of [RFC3720] compliant nodes that do not understand the > key ([RFC3720] states that compliant nodes MUST respond with > X#NodeArchitecture=NotUnderstood). > > > Wysochanski Expires November 4, 2006 [Page 2] > > > > Internet-Draft iSCSI Node Architecture July 2006 > > 2. Definition > > The definition of the key is as follows, conforming to sections 11 > and 12 of [RFC3720], with example list-of-values conforming to > section 5.1 of [RFC3720]. > > The key is defined with a Use of "LO", making it a Leading Only > key, and does not amend sections 11 or 12 of [RFC3720]. Thus, the > key MUST only be sent on the leading connection, MUST NOT be > changed after the leading connection login, and MUST only be sent > after the security negotiation login stage has completed (during > operational negotiation login stage). The key may be sent during > normal or discovery sessions. > > > X#NodeArchitecture > > Use: LO, Declarative > Senders: Initiator and Target > Scope: SW > > X#NodeArchitecture= > > Examples: > > X#NodeArchitecture=ExampleInc_Software_Initiator/1.05a, > ExampleInc_OperatingSystem/2003Build1489, > ExampleInc_Cluster_Services/2.0, > CPU_Architecture/x86_64 > X#NodeArchitecture=ExampleInc_iSCSI_4010_Hardware_Initiator/rev1, > ExampleInc_Firmware/2.0.0.5, > ExampleInc_Driver/2.0.0.1 > X#NodeArchitecture=Linux_iSCSI_Software_Initiator/4:0.1.11-3, > ExampleInc_Enterprise_Linux/4u3, > Linux_Kernel/2.6.9-34.26.ELsmp, > CPU_Architecture/i686, > CPU_Speed/3.06GHz, > Memory_Size/4059364kB > X#NodeArchitecture=ExampleInc_Software_Target/7.1, > ExampleInc_Firmware/7.1, > ExampleInc_Model/270c > > 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, iSCSI vendor software, firmware, or > hardware versions, the OS version, or hardware architecture. > > The length of the key value (total length of the list-of-values) > MUST NOT be greater than 255 bytes. > > X#NodeArchitecture MUST NOT be redeclared. > > > > Wysochanski Expires November 4, 2006 [Page 3] > > > > Internet-Draft iSCSI Node Architecture July 2006 > > 3. Security Considerations > > This extension key transmits specific implementation details > about the node that sends it; such details may be considered > sensitive in some environments. For example, if a certain > software or firmware version is known to contain security > weaknesses, announcing the presence of that version via this > key may not be desirable. The countermeasures for this > security concern are: > - sending less detailed information in the key values, or > - not sending the extension key, or > - using IPsec to provide confidentiality for the iSCSI > connection on which the key is sent (see [RFC3720] > and [RFC3723]). > To support the first and second countermeasures, all > implementations of this extension key MUST provide an > administrative mechanism to disable sending the key. In addition, > all implementations SHOULD provide an administrative mechanism to > configure a verbosity level of the key value, thereby controlling > the amount of information sent. For example, a lower verbosity > might enable transmission of node architecture component names > only, but no version numbers. > > The choice of which countermeasure is most appropriate depends > on the environment. However, the first countermeasure may be > acceptable in many environments, since it provides a compromise > between sending too much information and the other more > complete countermeasures of not sending the key at all or using > IPsec. > > In addition to security considerations involving transmission of > the key contents, any logging method(s) used for the key values > MUST keep the information secure from intruders. For all > implementations, the requirements to address this security > concern are: > - display of the log MUST only be possible with administrative > rights to the node > - options to disable logging to disk and to keep logs for a > fixed duration SHOULD be provided > > Finally, it is important to note that different nodes may have > different levels of risk, and these differences may affect the > implementation. The components of risk include assets, threats, > and vulnerabilities. Consider the following example iSCSI nodes, > which demonstrate differences in assets and vulnerabilities of > the nodes, and as a result, differences in implementation: > - One iSCSI target based on a special-purpose operating > system. Since the iSCSI target controls access to the data > storage containing company assets, the asset level is seen > as very high. Also, because of the special-purpose > operating system, in which vulnerabilities are less > well-known, the vulnerability level is viewed as low. > - Multiple iSCSI initiators in a blade farm, each running > a general-purpose operating system. The asset level of > each node is viewed as low, since blades are replaceable > and low cost. However, the vulnerability level is viewed > as high, since there are many well-known vulnerabilities > to the general-purpose operating system. > > For the above target, an appropriate implementation might be > logging of received key values, but no transmission of the key. > For the initiators, an appropriate implementation might be > transmission of the key, but no logging of received key values. > > > Wysochanski Expires November 4, 2006 [Page 4] > > > > Internet-Draft iSCSI Node Architecture July 2006 > > 4. IANA Considerations > > This document defines the iSCSI Extension Key NodeArchitecture > to be registered in the IANA iSCSI extended key registry. > > > > > > > > > > Wysochanski Expires November 4, 2006 [Page 5] > > > > Internet-Draft iSCSI Node Architecture July 2006 > > 5. References > > 5.1 Normative References > > [RFC2119] Bradner, S. "Key Words for use in RFCs to Indicate > Requirement Levels", BCP 14, RFC 2119, March 1997. > > [RFC3720] Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka, > M., and E. Zeidner, "Internet Small Computer Systems > Interface (iSCSI)", RFC 3720, April 2004. > > > > 5.2 Informative References > > [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., > Masinter, L., Leach, P., and T. Berners-Lee, > "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, > June 1999. > > [RFC3723] Adoba, B., Tseng, J., Walker, J., Rangan, V., and > Travostino, F., "Securing Block Storage Protocols > over IP", RFC 3723, April 2004. > > > > > > > > > > > Wysochanski Expires November 4, 2006 [Page 6] > > > > Internet-Draft iSCSI Node Architecture July 2006 > > 6. Author's Address > > Dave Wysochanski > Network Appliance, Inc. > 7301 Kit Creek Road > P. O. Box 13917 > Research Triangle, NC 27709 > Phone: +1-919-476-5628 > E-mail: davidw@netapp.com > > > > > > > > > > Wysochanski Expires November 4, 2006 [Page 7] > > > > Internet-Draft iSCSI Node Architecture July 2006 > > 7. Acknowledgements > > The IP Storage (ips) Working Group in the Transport Area of > IETF has been responsible for defining the iSCSI protocol > (apart from a host of other relevant IP Storage protocols). > The editor acknowledges the contributions of the entire > working group. > > The following individuals directly contributed to identifying > issues and/or suggesting resolutions to the issues found in this > document: David Black, Mallikarjun Chadalapaka, Paul Koning, > Julian Satran, John Hufferd, Claire Kraft, Ranga Sankar, > Joseph Pittman, Greg Berg, John Forte, and Jim Yuill. This > document benefited from all these contributions. > > > > > > > > > > Wysochanski Expires November 4, 2006 [Page 8] > > > > Internet-Draft iSCSI Node Architecture July 2006 > > 8. Full Copyright Statement > > Copyright (C) The Internet Society (2006). This document is > subject to the rights, licenses and restrictions contained in > BCP 78, and except as set forth therein, the authors retain > all their rights. > > This document and the information contained herein are > provided on an "AS IS" basis and THE CONTRIBUTOR, THE > ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), > THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE > DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT > NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION > HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES > OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. > > > > > > > > Wysochanski Expires November 4, 2006 [Page 9] > > > > Internet-Draft iSCSI Node Architecture July 2006 > > 9. Intellectual Property Statement > > The IETF takes no position regarding the validity or scope of > any Intellectual Property Rights or other rights that might > be claimed to pertain to the implementation or use of the > technology described in this document or the extent to which > any license under such rights might or might not be > available; nor does it represent that it has made any > independent effort to identify any such rights. Information > on the procedures with respect to rights in RFC documents can > be found in BCP 78 and BCP 79. > > Copies of IPR disclosures made to the IETF Secretariat and > any assurances of licenses to be made available, or the > result of an attempt made to obtain a general license or > permission for the use of such proprietary rights by > implementers or users of this specification can be obtained > from the IETF on-line IPR repository at http://www.ietf.org/ipr. > > The IETF invites any interested party to bring to its > attention any copyrights, patents or patent applications, > or other proprietary rights that may cover technology that > may be required to implement this standard. Please address > the information to the IETF at ietf-ipr@ietf.org. > > > > > > > > > > Wysochanski Expires November 4, 2006 [Page 10] > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Mon Jul 31 18:26:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7gDU-0004TY-Ow; Mon, 31 Jul 2006 18:26:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7gDT-0004TT-6Y for ips@ietf.org; Mon, 31 Jul 2006 18:26:27 -0400 Received: from mononoke.wasabisystems.com ([66.173.145.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7gDQ-0003aF-VT for ips@ietf.org; Mon, 31 Jul 2006 18:26:27 -0400 Received: from [10.0.0.10] (h-66-166-188-91.sndacagl.covad.net [66.166.188.91]) by mononoke.wasabisystems.com (Postfix) with ESMTP id 1CC4E871C0; Mon, 31 Jul 2006 18:26:24 -0400 (EDT) In-Reply-To: <44CE77DA.0@netapp.com> References: <44B6CA5B.6090709@netapp.com> <44CE77DA.0@netapp.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <061162F7-EE64-4D66-A34C-C206EC5A3555@wasabisystems.com> Content-Transfer-Encoding: 7bit From: William Studenmund Subject: Re: [Ips] DRAFT Montreal minutes - X#NodeArchitecture comments Date: Mon, 31 Jul 2006 15:26:17 -0700 To: David Wysochanski X-Pgp-Agent: GPGMail 1.1.2 (Tiger) X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: ips@ietf.org, Black_David@emc.com X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Jul 31, 2006, at 2:36 PM, David Wysochanski wrote: > Ping on the 2 items below - any comments? > > Also adding a 3rd item: > 3) Change key value format from list-of-values to > "iSCSI-name-value" (see 7/13/06 post). > > For this one, I'd rather leave it as list-of-values, since > this is simple, underscores are just about as readable as > spaces, and iSCSI-name-value seems a little strange > to me in this context. Actually, how about "iSCSI-local-name-value". The thing I don't like about list-of-values is that it implies, to me at least, list negotiations. Which we don't want here. :-) Also, list- of-values just vies us "text-value" plus comma. Among other things, we don't have spaces, nor do we have CR. Take care, Bill -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFEzoOODJT2Egh26K0RArpzAKCKFUPehEY27NdYkTrH/vPxfJi1vwCeLTJp VNN373IE6PKWVWC7aYzfLNY= =WDqV -----END PGP SIGNATURE----- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips