Message-ID: <200309151829.OAA17092@ietf.org> From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org To: Cc: dhcwg@ietf.org, ips@ece.cmu.edu Subject: I-D ACTION:draft-ietf-dhc-isnsoption-09.txt,.pdf Date: Mon, 15 Sep 2003 14:29:26 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01C37D23.0965A6D0" A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : The IPv4 DHCP Options for the Internet Storage Name Service Author(s) : C. Monia, J. Tseng, K. Gibbons Filename : draft-ietf-dhc-isnsoption-09.txt,.pdf Pages : 14 Date : 2003-9-15 This document describes the DHCP option to allow Internet Storage Name Service (iSNS) clients to automatically discover the location of the iSNS server through the use of DHCP for IPv4. iSNS provides discovery and management capabilities for Internet SCSI (iSCSI) and Internet Fibre Channel Protocol (iFCP) storage devices in an enterprise-scale IP storage network. iSNS provides intelligent storage management services comparable to those found in Fibre Channel networks, allowing a commodity IP network to function in a similar capacity as a storage area network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-isnsoption-09.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-isnsoption-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-isnsoption-09.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. To: Subject: Date: Wed, 17 Sep 2003 09:53:15 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_004_01C37D23.0965A6D0" ATT23090 Message-ID: From: Black_David@emc.com To: Julian_Satran@il.ibm.com Cc: ips@ece.cmu.edu Subject: RE: ASC/ASCQ for implicit termination (was iSCSI - Errata - to 2 0) Date: Mon, 15 Sep 2003 09:50:49 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Provide the name and values for the ASC/ASCQ code, and refer to SPC3 as the authority where it is defined. As I said earlier, we can be reasonably confident that the values will be stable. Thanks, --David -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Thursday, September 11, 2003 1:03 AM To: Black_David@emc.com Cc: ips@ece.cmu.edu Subject: Re: ASC/ASCQ for implicit termination (was iSCSI - Errata - to 20) So mentioning that the codes exists and referring the reader to SPC3 is acceptable? If yes I can put that statement in and we are done. Julo Black_David@emc.com 11/09/2003 01:36 To Julian Satran/Haifa/IBM@IBMIL cc ips@ece.cmu.edu Subject ASC/ASCQ for implicit termination (was iSCSI - Errata - to 20) Julian, > > > -the UA related text for abort (in both relevant places) > > > > Once WG Last Call closes on the command ordering draft (assuming it closes > > without objection to this point) a sentence saying which ASC/ASCQ code T10 > > has defined for this case needs to be added in both places. > > > I think that the agreement reached at the time was that we won't give the codes > (other SCSI documents do the same - the argument being to minimize fixes needed > in case of change). The concern on the other side is that it's hard to make the connection between these iSCSI implicit termination cases and the specific ASC/ASCQ code that's been defined. I'm not suggesting a "MUST" requirement but rather a statement that this ASC/ASCQ exists and is appropriate for these cases. While T10 controls both the existence and appropriateness of this ASC/ASCQ, I think both are likely to be stable. 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 ---------------------------------------------------- Message-ID: <000701c37992$7f066ee0$0a899ba6@EGRodriguez> From: "Elizabeth G. Rodriguez" To: 'Charles Monia' , 'Ralph Droms' , "'Thomas Narten (E-mail)'" , 'Steven Bellovin' Cc: "'DHCP (E-mail)'" , "'Ips (E-mail)'" , "'David Black (E-mail)'" , "'Allison Mankin (E-mail)'" , 'Joshua Tseng' , 'Kevin Gibbons' Subject: RE: New revision of iSNS Option for DHCP (Rev 10) Date: Fri, 12 Sep 2003 21:00:45 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Forwarding to Steve Bellovin. Since it is his comment that we are trying to address, we need to get his input as well. Elizabeth -----Original Message----- From: Charles Monia [mailto:cmonia@NishanSystems.com] Sent: Friday, September 12, 2003 3:51 PM To: 'Ralph Droms'; 'Thomas Narten (E-mail)' Cc: 'DHCP (E-mail)'; 'Ips (E-mail)'; 'David Black (E-mail)'; 'Elizabeth Rodriguez (E-mail)'; 'Allison Mankin (E-mail)'; Charles Monia; Joshua Tseng; Kevin Gibbons Subject: New revision of iSNS Option for DHCP (Rev 10) Hi Ralph and Thomas: This new version of the iSNS option for DHCP contains a security section revised in response to comments from David Black, Elizabeth Rodriguez, Ralph Droms and Steve Bellovin. It also includes changes based on all other IESG review comments. If the new version is OK, I'd like to restart the approval process at the appropriate point. Please let me know if there are problems. Pending the announcement of document availability from the archive, revision 10 can be obtained from ftp://ftp.nishansystems.com/outgoing/draft-ietf-dhc-isnsoption-10.pdf or ftp://ftp.nishansystems.com/outgoing/draft-ietf-dhc-isnsoption-10.txt. Markups visible in the PDF version show the text that was added or deleted. -- Charles ----------------------------------------- Charles Monia Senior Technology Consultant Nishan Systems email: cmonia@nishansystems.com voice: (408) 519-3986 fax: (408) 435-8385 Message-ID: From: Charles Monia To: 'Ralph Droms' , "'Thomas Narten (E-mail)'" Cc: "'DHCP (E-mail)'" , "'Ips (E-mail)'" , "'David Black (E-mail)'" , "'Elizabeth Rodriguez (E-mail)'" , "'Allison Mankin (E-mail)'" , Charles Monia , Joshua Tseng , Kevin Gibbons Subject: New revision of iSNS Option for DHCP (Rev 10) Date: Fri, 12 Sep 2003 18:50:59 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Hi Ralph and Thomas: This new version of the iSNS option for DHCP contains a security section revised in response to comments from David Black, Elizabeth Rodriguez, Ralph Droms and Steve Bellovin. It also includes changes based on all other IESG review comments. If the new version is OK, I'd like to restart the approval process at the appropriate point. Please let me know if there are problems. Pending the announcement of document availability from the archive, revision 10 can be obtained from ftp://ftp.nishansystems.com/outgoing/draft-ietf-dhc-isnsoption-10.pdf or ftp://ftp.nishansystems.com/outgoing/draft-ietf-dhc-isnsoption-10.txt. Markups visible in the PDF version show the text that was added or deleted. -- Charles ----------------------------------------- Charles Monia Senior Technology Consultant Nishan Systems email: cmonia@nishansystems.com voice: (408) 519-3986 fax: (408) 435-8385 From exim@www1.ietf.org Wed Sep 17 10:12:55 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13327 for ; Wed, 17 Sep 2003 10:12:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zd2n-0008JP-K2 for ips-archive@odin.ietf.org; Wed, 17 Sep 2003 10:12:33 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8HECX95031945 for ips-archive@odin.ietf.org; Wed, 17 Sep 2003 10:12:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zd2n-0008JA-Et for ips-web-archive@optimus.ietf.org; Wed, 17 Sep 2003 10:12:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13296 for ; Wed, 17 Sep 2003 10:12:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zd2l-0006Wm-00 for ips-web-archive@ietf.org; Wed, 17 Sep 2003 10:12:31 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19zd2k-0006Wi-00 for ips-web-archive@ietf.org; Wed, 17 Sep 2003 10:12:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zd2I-0008Hr-Cs; Wed, 17 Sep 2003 10:12:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zd1v-0008HO-JD for ips@optimus.ietf.org; Wed, 17 Sep 2003 10:11:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13168 for ; Wed, 17 Sep 2003 10:11:30 -0400 (EDT) From: Black_David@emc.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zd1t-0006Uo-00 for ips@ietf.org; Wed, 17 Sep 2003 10:11:37 -0400 Received: from [168.159.2.31] (helo=mailhub.lss.emc.com) by ietf-mx with esmtp (Exim 4.12) id 19zd1s-0006Uj-00 for ips@ietf.org; Wed, 17 Sep 2003 10:11:36 -0400 Received: from mxic1.corp.emc.com (mxic1.isus.emc.com [168.159.129.100]) by mailhub.lss.emc.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h8HEBXW13447 for ; Wed, 17 Sep 2003 10:11:33 -0400 (EDT) Received: by mxic1.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Wed, 17 Sep 2003 10:11:33 -0400 Message-ID: To: ips@ietf.org Date: Wed, 17 Sep 2003 10:11:31 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Ips] Welcome to the new IETF WG list Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , Everyone, Congratulations - if you received this message, you have been successfully subscribed to the new IETF IP Storage WG mailing list, ips@ietf.org. This is the new location of the list, and replaces the CMU list. You do not need to do anything in order to continue receiving WG email. If you wish to remove yourself from the list, send email to ips-request@ietf.org. Posting to this list is restricted to list members only as an anti-spam measure - posts from non-members will be held for approval, but posts that are not spam will be approved. Also, this list has a message length limitation that will reject large messages - instead of sending attachments to the list, please post them to a web site and send a URL to the list. The new location of the email list archives is ftp://ftp.ietf.org/ietf-mail-archive/ips/ This contains all of the email from the CMU list. The web archives at ietf.org will initially contain only messages sent to the new list at ietf.org. Thanks, --David and Elizabeth (IPS WG co-chairs) ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Wed Sep 17 11:41:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18084 for ; Wed, 17 Sep 2003 11:41:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zeQd-0003m6-3W for ips-archive@odin.ietf.org; Wed, 17 Sep 2003 11:41:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8HFfE0s014501 for ips-archive@odin.ietf.org; Wed, 17 Sep 2003 11:41:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zeQc-0003lo-4s for ips-web-archive@optimus.ietf.org; Wed, 17 Sep 2003 11:41:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18063 for ; Wed, 17 Sep 2003 11:41:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zeQa-0000DT-00 for ips-web-archive@ietf.org; Wed, 17 Sep 2003 11:41:13 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19zeQa-0000DP-00 for ips-web-archive@ietf.org; Wed, 17 Sep 2003 11:41:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zeQQ-0003iZ-MB; Wed, 17 Sep 2003 11:41:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zePg-0003hM-HM for ips@optimus.ietf.org; Wed, 17 Sep 2003 11:40:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18019 for ; Wed, 17 Sep 2003 11:40:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zePf-0000CU-00 for ips@ietf.org; Wed, 17 Sep 2003 11:40:15 -0400 Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx with esmtp (Exim 4.12) id 19zePe-0000BY-00 for ips@ietf.org; Wed, 17 Sep 2003 11:40:15 -0400 Received: from mail5.microsoft.com ([157.54.6.156]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 17 Sep 2003 08:40:07 -0700 Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(6.0.3790.1039); Wed, 17 Sep 2003 08:39:44 -0700 Received: from 157.54.5.25 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 17 Sep 2003 08:39:21 -0700 Received: from RED-MSG-30.redmond.corp.microsoft.com ([157.54.47.230]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 17 Sep 2003 08:39:31 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ips] Welcome to the new IETF WG list Date: Wed, 17 Sep 2003 08:39:42 -0700 Message-ID: <417189D11A212D42B24FB2621155CB8301B34D05@RED-MSG-30.redmond.corp.microsoft.com> Thread-Topic: [Ips] Welcome to the new IETF WG list Thread-Index: AcN9JhKUMWdavk5VRQWiuF0ygRZqzQAC8ftQ From: "Setheni Kirschnick" To: X-OriginalArrivalTime: 17 Sep 2003 15:39:31.0484 (UTC) FILETIME=[E32E55C0:01C37D31] Content-Transfer-Encoding: quoted-printable Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Please remove me from the list at this time. Thank you,=20 -----Original Message----- From: ips-admin@ietf.org [mailto:ips-admin@ietf.org] On Behalf Of Black_David@emc.com Sent: Wednesday, September 17, 2003 7:12 AM To: ips@ietf.org Everyone, Congratulations - if you received this message, you have been successfully subscribed to the new IETF IP Storage WG mailing list, ips@ietf.org. This is the new location of the list, and replaces the CMU list. You do not need to do anything in order to continue receiving WG email. If you wish to remove yourself from the list, send email to ips-request@ietf.org. Posting to this list is restricted to list members only as an anti-spam measure - posts from non-members will be held for approval, but posts that are not spam will be approved. Also, this list has a message length limitation that will reject large messages - instead of sending attachments to the list, please post them to a web site and send a URL to the list. The new location of the email list archives is ftp://ftp.ietf.org/ietf-mail-archive/ips/ This contains all of the email from the CMU list. The web archives at ietf.org will initially contain only messages sent to the new list at ietf.org. Thanks, --David and Elizabeth (IPS WG co-chairs) ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Sat Sep 20 12:13:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14771 for ; Sat, 20 Sep 2003 12:13:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0kM5-00043f-Ns for ips-archive@odin.ietf.org; Sat, 20 Sep 2003 12:13:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8KGD5NR015589 for ips-archive@odin.ietf.org; Sat, 20 Sep 2003 12:13:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0kM5-000435-Bd for ips-web-archive@optimus.ietf.org; Sat, 20 Sep 2003 12:13:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14744 for ; Sat, 20 Sep 2003 12:12:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0kM3-00065h-00 for ips-web-archive@ietf.org; Sat, 20 Sep 2003 12:13:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A0kLy-00065W-00 for ips-web-archive@ietf.org; Sat, 20 Sep 2003 12:12:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0kL3-0003sS-HU; Sat, 20 Sep 2003 12:12:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0k35-0002At-Dw for ips@optimus.ietf.org; Sat, 20 Sep 2003 11:53:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20303 for ; Fri, 19 Sep 2003 16:05:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0RVX-0000oN-00 for ips@ietf.org; Fri, 19 Sep 2003 16:05:35 -0400 Received: from [64.238.111.99] (helo=mail.ivivity.com) by ietf-mx with esmtp (Exim 4.12) id 1A0RVN-0000oB-00 for ips@ietf.org; Fri, 19 Sep 2003 16:05:25 -0400 Received: by atlops.ivivity.com with Internet Mail Service (5.5.2653.19) id ; Fri, 19 Sep 2003 16:05:04 -0400 Message-ID: From: Eddy Quicksall To: ips@ietf.org Date: Fri, 19 Sep 2003 16:04:54 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C37EE9.4ABF5A00" Subject: [Ips] NOP during Discovery Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , 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_01C37EE9.4ABF5A00 Content-Type: text/plain I have found that at least one initiator is doing a NOP-out during discovery phase. But the spec says that isn't allowed. Am I misunderstanding something? 3.3 iSCSI Session Types iSCSI defines two types of sessions: a) Normal operational session - an unrestricted session. b) Discovery-session - a session only opened for target discovery. The target MUST ONLY accept text requests with the SendTargets key and a logout request with reason "close the session". All other requests MUST be rejected. The session type is defined during login with key=value parameter in the login command. Eddy ------_=_NextPart_001_01C37EE9.4ABF5A00 Content-Type: text/html Content-Transfer-Encoding: quoted-printable

I have found that at least one initiator is doing a = NOP-out during discovery phase. But the spec says that isn't allowed. Am I misunderstanding something?

 

3.3 iSCSI Session = Types

  = iSCSI defines two types of = sessions:

  = a) Normal operational session - an unrestricted = session.

  = b) Discovery-session - a session only opened for = target

     discovery. The target MUST ONLY accept text = requests with the

     SendTargets key and a logout request with reason "close = the

     session". All other requests MUST be = rejected.

     The session type is defined during login with key=3Dvalue parameter = in

     the login command.

 

 

Eddy

 

------_=_NextPart_001_01C37EE9.4ABF5A00-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Sat Sep 20 13:55:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17547 for ; Sat, 20 Sep 2003 13:55:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0lww-0003Nc-Pl for ips-archive@odin.ietf.org; Sat, 20 Sep 2003 13:55:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8KHtEJ8012986 for ips-archive@odin.ietf.org; Sat, 20 Sep 2003 13:55:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0lww-0003NN-Ks for ips-web-archive@optimus.ietf.org; Sat, 20 Sep 2003 13:55:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17544 for ; Sat, 20 Sep 2003 13:55:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0lwu-00079j-00 for ips-web-archive@ietf.org; Sat, 20 Sep 2003 13:55:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A0lwp-00079g-00 for ips-web-archive@ietf.org; Sat, 20 Sep 2003 13:55:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0lwk-0003KK-MC; Sat, 20 Sep 2003 13:55:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0lvs-0003Gx-OY for ips@optimus.ietf.org; Sat, 20 Sep 2003 13:54:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17508; Sat, 20 Sep 2003 13:53:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0lvl-00079C-00; Sat, 20 Sep 2003 13:54:01 -0400 Received: from d12lmsgate.de.ibm.com ([194.196.100.234]) by ietf-mx with esmtp (Exim 4.12) id 1A0lvL-00077c-00; Sat, 20 Sep 2003 13:53:35 -0400 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196]) by d12lmsgate.de.ibm.com (8.12.9/8.12.8) with ESMTP id h8KHqOMD092806; Sat, 20 Sep 2003 19:52:24 +0200 Received: from d10ml001.telaviv.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12relay02.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h8KHqNlw257194; Sat, 20 Sep 2003 19:52:23 +0200 In-Reply-To: To: Eddy Quicksall Cc: ips@ietf.org, ips-admin@ietf.org Subject: Re: [Ips] NOP during Discovery MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF2 July 23, 2003 From: "Julian Satran" Message-ID: Date: Sat, 20 Sep 2003 13:52:16 -0400 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 20/09/2003 20:52:23, Serialize complete at 20/09/2003 20:52:23 Content-Type: multipart/alternative; boundary="=_alternative 006226AC85256DA7_=" Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , This is a multipart message in MIME format. --=_alternative 006226AC85256DA7_= Content-Type: text/plain; charset="US-ASCII" It is not allowed in discovery - There was a long discussion with one party insisting on having NOP as a way of keeping the discovery session alive. Discovery being only a lightweight location mechanism it was decided that it is not worth having it as a permanent alternative for a management interface. Regards, Julo Eddy Quicksall Sent by: ips-admin@ietf.org 19/09/2003 16:04 To ips@ietf.org cc Subject [Ips] NOP during Discovery I have found that at least one initiator is doing a NOP-out during discovery phase. But the spec says that isn't allowed. Am I misunderstanding something? 3.3 iSCSI Session Types iSCSI defines two types of sessions: a) Normal operational session - an unrestricted session. b) Discovery-session - a session only opened for target discovery. The target MUST ONLY accept text requests with the SendTargets key and a logout request with reason "close the session". All other requests MUST be rejected. The session type is defined during login with key=value parameter in the login command. Eddy --=_alternative 006226AC85256DA7_= Content-Type: text/html; charset="US-ASCII"
It is not allowed in discovery - There was a long discussion with one party insisting on having NOP as a way of keeping the discovery session alive.
Discovery being only a lightweight location mechanism it was decided that it is  not worth having it as a permanent alternative for a management interface.

Regards,
Julo


Eddy Quicksall <eddy_quicksall@ivivity.com>
Sent by: ips-admin@ietf.org

19/09/2003 16:04

To
ips@ietf.org
cc
Subject
[Ips] NOP during Discovery





I have found that at least one initiator is doing a NOP-out during discovery phase. But the spec says that isn't allowed. Am I misunderstanding something?

 

3.3 iSCSI Session Types

  iSCSI defines two types of sessions:

  a) Normal operational session - an unrestricted session.

  b) Discovery-session - a session only opened for target

     discovery. The target MUST ONLY accept text requests with the

     SendTargets key and a logout request with reason "close the

     session". All other requests MUST be rejected.

     The session type is defined during login with key=value parameter in

     the login command.

 

 

Eddy

 

--=_alternative 006226AC85256DA7_=-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Sat Sep 20 14:13:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18068 for ; Sat, 20 Sep 2003 14:13:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0mEH-0004vc-Jq for ips-archive@odin.ietf.org; Sat, 20 Sep 2003 14:13:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8KID9Br018938 for ips-archive@odin.ietf.org; Sat, 20 Sep 2003 14:13:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0mEG-0004vN-Om for ips-web-archive@optimus.ietf.org; Sat, 20 Sep 2003 14:13:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18044 for ; Sat, 20 Sep 2003 14:13:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0mEE-0007MT-00 for ips-web-archive@ietf.org; Sat, 20 Sep 2003 14:13:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A0mE8-0007MQ-00 for ips-web-archive@ietf.org; Sat, 20 Sep 2003 14:13:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0mE9-0004tE-7s; Sat, 20 Sep 2003 14:13:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0mDv-0004sm-3o for ips@optimus.ietf.org; Sat, 20 Sep 2003 14:12:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18038; Sat, 20 Sep 2003 14:12:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0mDo-0007Lg-00; Sat, 20 Sep 2003 14:12:40 -0400 Received: from [64.238.111.99] (helo=mail.ivivity.com) by ietf-mx with esmtp (Exim 4.12) id 1A0mDd-0007LH-00; Sat, 20 Sep 2003 14:12:30 -0400 Received: by atlops.ivivity.com with Internet Mail Service (5.5.2653.19) id ; Sat, 20 Sep 2003 14:12:16 -0400 Message-ID: From: Eddy Quicksall To: Julian Satran Cc: ips@ietf.org, ips-admin@ietf.org Subject: RE: [Ips] NOP during Discovery Date: Sat, 20 Sep 2003 14:12:15 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C37FA2.B89444A0" Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , 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_01C37FA2.B89444A0 Content-Type: text/plain Thanks Would it work to just use SendTargets= instead of NOP? If there is a target for the discovery session, it would respond with just the target name. If there are no targets for the discovery session, the target would still respond but with 0 for the DataSegmentLength. If so, can you talk that person into that? Eddy -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Saturday, September 20, 2003 1:52 PM To: Eddy Quicksall Cc: ips@ietf.org; ips-admin@ietf.org Subject: Re: [Ips] NOP during Discovery It is not allowed in discovery - There was a long discussion with one party insisting on having NOP as a way of keeping the discovery session alive. Discovery being only a lightweight location mechanism it was decided that it is not worth having it as a permanent alternative for a management interface. Regards, Julo Eddy Quicksall Sent by: ips-admin@ietf.org 19/09/2003 16:04 To ips@ietf.org cc Subject [Ips] NOP during Discovery I have found that at least one initiator is doing a NOP-out during discovery phase. But the spec says that isn't allowed. Am I misunderstanding something? 3.3 iSCSI Session Types iSCSI defines two types of sessions: a) Normal operational session - an unrestricted session. b) Discovery-session - a session only opened for target discovery. The target MUST ONLY accept text requests with the SendTargets key and a logout request with reason "close the session". All other requests MUST be rejected. The session type is defined during login with key=value parameter in the login command. Eddy ------_=_NextPart_001_01C37FA2.B89444A0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable

Thanks

=

 

=

Would it work to just use SendTargets=3D<nothing> instead of NOP? If = there is a target for the discovery session, it would respond with just the target = name. If there are no targets for the discovery session, the target would = still respond but with 0 for the DataSegmentLength.

 

=

If so, can you = talk that person into that?

 

=

Eddy

 

=

-----Original = Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: = Saturday, September 20, = 2003 1:52 PM
To: Eddy Quicksall
Cc: ips@ietf.org; ips-admin@ietf.org
Subject: Re: [Ips] NOP = during Discovery

 


It is not allowed in discovery - There was a = long discussion with one party insisting on having NOP as a way of keeping = the discovery session alive.
Discovery being only a lightweight location mechanism it was decided that it is =  not worth having it as a permanent alternative for a management = interface.

Regards,=
Julo

Eddy Quicksall <eddy_quicksall@ivivity.com>
Sent by: ips-admin@ietf.org

19/09/2003 16:04

To

ips@ietf.org =

cc

 

Subject

[Ips] NOP during = Discovery

 

 

 




I have found that at least one initiator is doing a NOP-out = during discovery phase. But the spec says that isn't allowed. Am I = misunderstanding something?

 

3.3 iSCSI Session Types =

  iSCSI defines two types of = sessions:

  a) Normal operational session - an unrestricted session.

  b) Discovery-session - a session = only opened for target

     discovery. The target = MUST ONLY accept text requests with the

     SendTargets key and a = logout request with reason "close the

     session". All = other requests MUST be rejected.

     The session type is = defined during login with key=3Dvalue parameter in =

     the login = command.

 

 

Eddy

 

------_=_NextPart_001_01C37FA2.B89444A0-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Sat Sep 20 16:54:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22490 for ; Sat, 20 Sep 2003 16:54:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0okC-0006pW-Ip for ips-archive@odin.ietf.org; Sat, 20 Sep 2003 16:54:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8KKsGDl026251 for ips-archive@odin.ietf.org; Sat, 20 Sep 2003 16:54:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0okC-0006pK-Bs for ips-web-archive@optimus.ietf.org; Sat, 20 Sep 2003 16:54:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22475 for ; Sat, 20 Sep 2003 16:54:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0okA-0001B2-00 for ips-web-archive@ietf.org; Sat, 20 Sep 2003 16:54:14 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A0ok5-0001Az-00 for ips-web-archive@ietf.org; Sat, 20 Sep 2003 16:54:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0ojx-0006oJ-RQ; Sat, 20 Sep 2003 16:54:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0ojJ-0006nl-DN for ips@optimus.ietf.org; Sat, 20 Sep 2003 16:53:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22439; Sat, 20 Sep 2003 16:53:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0ojH-00019N-00; Sat, 20 Sep 2003 16:53:19 -0400 Received: from d12lmsgate-4.de.ibm.com ([194.196.100.237] helo=d12lmsgate.de.ibm.com) by ietf-mx with esmtp (Exim 4.12) id 1A0oiq-00017U-00; Sat, 20 Sep 2003 16:52:53 -0400 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by d12lmsgate.de.ibm.com (8.12.9/8.12.8) with ESMTP id h8KKpkoU061708; Sat, 20 Sep 2003 22:51:46 +0200 Received: from d10ml001.telaviv.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h8KKpixZ214666; Sat, 20 Sep 2003 22:51:45 +0200 In-Reply-To: To: Eddy Quicksall Cc: ips@ietf.org, ips-admin@ietf.org Subject: RE: [Ips] NOP during Discovery MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF2 July 23, 2003 From: "Julian Satran" Message-ID: Date: Sat, 20 Sep 2003 16:51:40 -0400 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 20/09/2003 23:51:45, Serialize complete at 20/09/2003 23:51:45 Content-Type: multipart/alternative; boundary="=_alternative 0072936C85256DA7_=" Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , This is a multipart message in MIME format. --=_alternative 0072936C85256DA7_= Content-Type: text/plain; charset="US-ASCII" Eddy, I think that they realized that already and are content. NOP is somewhat richer in that in a "storage router" NOP might reach the end-point while SendTargets will probably not. In any case the text is unequivocal about NOP. Julo Eddy Quicksall 20/09/2003 14:12 To Julian Satran/Haifa/IBM@IBMIL cc ips@ietf.org, ips-admin@ietf.org Subject RE: [Ips] NOP during Discovery Thanks Would it work to just use SendTargets= instead of NOP? If there is a target for the discovery session, it would respond with just the target name. If there are no targets for the discovery session, the target would still respond but with 0 for the DataSegmentLength. If so, can you talk that person into that? Eddy -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Saturday, September 20, 2003 1:52 PM To: Eddy Quicksall Cc: ips@ietf.org; ips-admin@ietf.org Subject: Re: [Ips] NOP during Discovery It is not allowed in discovery - There was a long discussion with one party insisting on having NOP as a way of keeping the discovery session alive. Discovery being only a lightweight location mechanism it was decided that it is not worth having it as a permanent alternative for a management interface. Regards, Julo Eddy Quicksall Sent by: ips-admin@ietf.org 19/09/2003 16:04 To ips@ietf.org cc Subject [Ips] NOP during Discovery I have found that at least one initiator is doing a NOP-out during discovery phase. But the spec says that isn't allowed. Am I misunderstanding something? 3.3 iSCSI Session Types iSCSI defines two types of sessions: a) Normal operational session - an unrestricted session. b) Discovery-session - a session only opened for target discovery. The target MUST ONLY accept text requests with the SendTargets key and a logout request with reason "close the session". All other requests MUST be rejected. The session type is defined during login with key=value parameter in the login command. Eddy --=_alternative 0072936C85256DA7_= Content-Type: text/html; charset="US-ASCII"
Eddy,

I think that they realized that already and are content. NOP is somewhat richer in that in a "storage router" NOP might reach the end-point while SendTargets will probably not.  In any case the text is unequivocal about NOP.

Julo


Eddy Quicksall <eddy_quicksall@ivivity.com>

20/09/2003 14:12

To
Julian Satran/Haifa/IBM@IBMIL
cc
ips@ietf.org, ips-admin@ietf.org
Subject
RE: [Ips] NOP during Discovery





Thanks

 

Would it work to just use SendTargets=<nothing> instead of NOP? If there is a target for the discovery session, it would respond with just the target name. If there are no targets for the discovery session, the target would still respond but with 0 for the DataSegmentLength.

 

If so, can you talk that person into that?

 

Eddy

 

-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Saturday, September 20, 2003 1:52 PM
To: Eddy Quicksall
Cc: ips@ietf.org; ips-admin@ietf.org
Subject: Re: [Ips] NOP during Discovery

 


It is not allowed in discovery - There was a long discussion with one party insisting on having NOP as a way of keeping the discovery session alive.
Discovery being only a lightweight location mechanism it was decided that it is  not worth having it as a permanent alternative for a management interface.

Regards,
Julo

Eddy Quicksall <eddy_quicksall@ivivity.com>
Sent by: ips-admin@ietf.org

19/09/2003 16:04


To
ips@ietf.org
cc
 
Subject
[Ips] NOP during Discovery

 


   




I have found that at least one initiator is doing a NOP-out during discovery phase. But the spec says that isn't allowed. Am I misunderstanding something?

 

3.3 iSCSI Session Types

  iSCSI defines two types of sessions:

  a) Normal operational session - an unrestricted session.

  b) Discovery-session - a session only opened for target

     discovery. The target MUST ONLY accept text requests with the

     SendTargets key and a logout request with reason "close the

     session". All other requests MUST be rejected.

     The session type is defined during login with key=value parameter in

     the login command.

 

 

Eddy

 

--=_alternative 0072936C85256DA7_=-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Mon Sep 22 14:46:55 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00028 for ; Mon, 22 Sep 2003 14:46:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1Vhh-0006QR-Ih for ips-archive@odin.ietf.org; Mon, 22 Sep 2003 14:46:33 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8MIkXSE024697 for ips-archive@odin.ietf.org; Mon, 22 Sep 2003 14:46:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1Vhh-0006PE-8B for ips-web-archive@optimus.ietf.org; Mon, 22 Sep 2003 14:46:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29955 for ; Mon, 22 Sep 2003 14:46:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1Vhd-0005qN-00 for ips-web-archive@ietf.org; Mon, 22 Sep 2003 14:46:29 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A1VhX-0005po-00 for ips-web-archive@ietf.org; Mon, 22 Sep 2003 14:46:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1VhB-0006E1-Lm; Mon, 22 Sep 2003 14:46:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1Vgm-0006BN-5l for ips@optimus.ietf.org; Mon, 22 Sep 2003 14:45:37 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29808; Mon, 22 Sep 2003 14:45:26 -0400 (EDT) Message-Id: <200309221845.OAA29808@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ips@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 22 Sep 2003 14:45:26 -0400 Subject: [Ips] I-D ACTION:draft-ietf-ips-command-ordering-01.txt,.pdf Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Storage Working Group of the IETF. Title : SCSI Command Ordering Considerations with iSCSI Author(s) : M. Chadalapaka, R. Elliott Filename : draft-ietf-ips-command-ordering-01.txt,.pdf Pages : 20 Date : 2003-9-22 iSCSI is a SCSI transport protocol designed to run on top of TCP. The iSCSI session abstraction is equivalent to the SCSI I_T nexus, and the iSCSI session provides an ordered command delivery from the SCSI initiator to the SCSI target. This document goes into the design considerations that led to the iSCSI session model as it is defined today, relates the SCSI command ordering features defined in T10 specifications to the iSCSI concepts, and finally provides guidance to system designers on how true command ordering solutions can be built based on iSCSI. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-command-ordering-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ips-command-ordering-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ips-command-ordering-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-9-22132847.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-command-ordering-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-command-ordering-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-9-22132847.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Mon Sep 22 16:13:03 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07934 for ; Mon, 22 Sep 2003 16:13:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1X33-0007t8-03 for ips-archive@odin.ietf.org; Mon, 22 Sep 2003 16:12:41 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8MKCeOr030318 for ips-archive@odin.ietf.org; Mon, 22 Sep 2003 16:12:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1X32-0007sv-Sa for ips-web-archive@optimus.ietf.org; Mon, 22 Sep 2003 16:12:40 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07872 for ; Mon, 22 Sep 2003 16:12:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1X2P-0007mY-8B; Mon, 22 Sep 2003 16:12:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1X22-0007kK-DF for ips@optimus.ietf.org; Mon, 22 Sep 2003 16:11:38 -0400 Received: from osmtp2.electric.net (osmtp2.electric.net [216.129.90.29]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07698 for ; Mon, 22 Sep 2003 16:11:19 -0400 (EDT) Received: from root by osmtp2.electric.net with emc1-ok (Exim 4.10) id 1A1X0t-000KnC-0W for ips@ietf.org; Mon, 22 Sep 2003 13:10:27 -0700 Received: by emcmailer; Mon, Sep 22 2003 13:10:27 -0700 Received: from [166.155.154.179] (helo=EGRodriguez) by osmtp2.electric.net with asmtp (Exim 4.10) id 1A1X0r-000KlP-0W for ips@ietf.org; Mon, 22 Sep 2003 13:10:26 -0700 From: "Elizabeth G. Rodriguez" To: Date: Mon, 22 Sep 2003 13:10:14 -0700 Message-ID: <012001c38145$8c2cab10$b39a9ba6@EGRodriguez> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <200309221845.OAA29808@ietf.org> Importance: Normal Content-Transfer-Encoding: quoted-printable Subject: [Ips] Command Ordering Draft Completed WG last call Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable All, The Command Ordering Draft completed WG last call successfully. Mallikarjun has produced a new draft to address the editorial comments against the draft, announcement below. This draft will be forwarded this week to the ADs for further = processing. Thanks, Elizabeth Rodriguez & David Black IPS co-chairs -----Original Message----- From: ips-admin@ietf.org [mailto:ips-admin@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Monday, September 22, 2003 11:45 AM To: IETF-Announce: Cc: ips@ietf.org Subject: [Ips] I-D ACTION:draft-ietf-ips-command-ordering-01.txt,.pdf A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Storage Working Group of the IETF. Title : SCSI Command Ordering Considerations with iSCSI Author(s) : M. Chadalapaka, R. Elliott Filename : draft-ietf-ips-command-ordering-01.txt,.pdf Pages : 20 Date : 2003-9-22 =09 iSCSI is a SCSI transport protocol designed to run on top of=20 TCP. The iSCSI session abstraction is equivalent to the SCSI I_T=20 nexus, and the iSCSI session provides an ordered command=20 delivery from the SCSI initiator to the SCSI target. This=20 document goes into the design considerations that led to the=20 iSCSI session model as it is defined today, relates the SCSI=20 command ordering features defined in T10 specifications to the iSCSI concepts, and finally provides guidance to system=20 designers on how true command ordering solutions can be built=20 based on iSCSI. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-command-ordering-01.tx= t To remove yourself from the IETF Announcement list, send a message to=20 ietf-announce-request with the word unsubscribe in the body of the = message. Internet-Drafts are also available by anonymous FTP. Login with the = username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ips-command-ordering-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ips-command-ordering-01.txt". =09 NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. =09 =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Mon Sep 22 16:40:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09392 for ; Mon, 22 Sep 2003 16:40:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1XSr-0002O9-Gb for ips-archive@odin.ietf.org; Mon, 22 Sep 2003 16:39:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8MKdLsQ009175 for ips-archive@odin.ietf.org; Mon, 22 Sep 2003 16:39:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1XSr-0002Nu-Cw for ips-web-archive@optimus.ietf.org; Mon, 22 Sep 2003 16:39:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09293 for ; Mon, 22 Sep 2003 16:39:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1XSd-0006mA-00 for ips-web-archive@ietf.org; Mon, 22 Sep 2003 16:39:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A1XSY-0006m7-00 for ips-web-archive@ietf.org; Mon, 22 Sep 2003 16:39:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1XSX-0002Iy-3a; Mon, 22 Sep 2003 16:39:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1XRf-0002Cv-Hl for ips@optimus.ietf.org; Mon, 22 Sep 2003 16:38:07 -0400 Received: from MAHO3MSX2.corp.emc.com (maho3msx2.corp.emc.com [128.221.11.32]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09220 for ; Mon, 22 Sep 2003 16:37:53 -0400 (EDT) From: Black_David@emc.com Received: by maho3msx2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Mon, 22 Sep 2003 16:12:02 -0400 Message-ID: To: ips@ietf.org Date: Mon, 22 Sep 2003 16:12:00 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Ips] New IPS list administrivia Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , Sorry for the intrusion of administrivia; with luck this will be the only message I need to send on this topic ... As part of transferring the IPS mailing list to IETF, new mailing list passwords were assigned to everyone - your password is needed to unsubscribe from the list, and to change options (e.g., digests vs. individual messages). To get your password, go to: https://www1.ietf.org/mailman/listinfo/ips , enter your email address in the bottom box at the bottom of the page (in the Ips Subscribers section), click the "Edit Options" button and then click the "Email My Password To Me" button on the next page. The IETF email list manager will automatically send monthly reminders of list passwords to everyone, so if you don't have anything that needs to be done now, you don't need to do anything. There are about ten email addresses transferred from the CMU list that have bounced all messages sent to them. IF you have one of these addresses, AND you have found this message (e.g., in the list archive), AND your address is now accepting email, AND you'd like to receive IPS list email again, THEN follow the above instructions to get your password which will enable you to turn off the "Disable mail delivery" option (further down the same page as the "Email My Password To Me" button). At least one list member has a spam filter that demands a response from a human when email from an unknown address arrives. The postmaster for that member has been sent a note asking the postmaster to ask the member to update his/her whitelist to allow email through. While it's a courtesy to do so, those who post to this list should not feel obligated to respond to clueless spam filters. Speaking of clueless spam filters, at least one company has its email firewall configured to reject Internet-Draft announcements (the firewall appears to be configured to reject the MIME type used by those announcements). The postmaster for the company involved has been sent a note that their email firewall is being overly aggressive. If you're not getting Internet-Draft announcements (there was one sent to the IPS list this afternoon, just before 3pm Eastern time), you might want to check with your postmaster about this. 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 exim@www1.ietf.org Mon Sep 22 16:46:56 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09765 for ; Mon, 22 Sep 2003 16:46:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1XZq-0003iW-Eq for ips-archive@odin.ietf.org; Mon, 22 Sep 2003 16:46:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8MKkYuG014282 for ips-archive@odin.ietf.org; Mon, 22 Sep 2003 16:46:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1XZq-0003iH-AK for ips-web-archive@optimus.ietf.org; Mon, 22 Sep 2003 16:46:34 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09712 for ; Mon, 22 Sep 2003 16:46:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1XZK-0003T7-Rc; Mon, 22 Sep 2003 16:46:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1XZE-0003RN-KJ for ips@optimus.ietf.org; Mon, 22 Sep 2003 16:45:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09640 for ; Mon, 22 Sep 2003 16:45:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1XZC-0007Ju-00 for ips@ietf.org; Mon, 22 Sep 2003 16:45:54 -0400 Received: from gw.openss7.com ([142.179.199.224] ident=[9W1l5aPgSGOtEVjwnuqXz1ahs9CPWn2M]) by ietf-mx with esmtp (Exim 4.12) id 1A1XZC-0007C5-00 for ips@ietf.org; Mon, 22 Sep 2003 16:45:54 -0400 Received: from ns.pigworks.openss7.net (IDENT:ZNrYRTWIEyGHIUki1K7SS8OxcCsdKvRo@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h8MKiLa24859; Mon, 22 Sep 2003 14:44:21 -0600 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h8MKiKl28471; Mon, 22 Sep 2003 14:44:20 -0600 Date: Mon, 22 Sep 2003 14:44:20 -0600 From: "Brian F. G. Bidulock" To: Black_David@emc.com Cc: ips@ietf.org Subject: Re: [Ips] New IPS list administrivia Message-ID: <20030922144420.A28399@openss7.org> Reply-To: bidulock@openss7.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from Black_David@emc.com on Mon, Sep 22, 2003 at 04:12:00PM -0400 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by gw.openss7.com id h8MKiLa24859 Content-Transfer-Encoding: quoted-printable Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Black_David, Thank you for your diligence. --brian On Mon, 22 Sep 2003, Black_David@emc.com wrote: > Sorry for the intrusion of administrivia; with luck this will > be the only message I need to send on this topic ... >=20 > As part of transferring the IPS mailing list to IETF, new mailing > list passwords were assigned to everyone - your password is > needed to unsubscribe from the list, and to change options (e.g., > digests vs. individual messages). To get your password, go > to: https://www1.ietf.org/mailman/listinfo/ips , enter your > email address in the bottom box at the bottom of the page (in > the Ips Subscribers section), click the "Edit Options" button > and then click the "Email My Password To Me" button on the next > page. The IETF email list manager will automatically send monthly > reminders of list passwords to everyone, so if you don't have > anything that needs to be done now, you don't need to do anything. >=20 > There are about ten email addresses transferred from the CMU > list that have bounced all messages sent to them. IF you have > one of these addresses, AND you have found this message (e.g., > in the list archive), AND your address is now accepting email, > AND you'd like to receive IPS list email again, THEN follow the > above instructions to get your password which will enable > you to turn off the "Disable mail delivery" option (further > down the same page as the "Email My Password To Me" button). >=20 > At least one list member has a spam filter that demands a response > from a human when email from an unknown address arrives. The > postmaster for that member has been sent a note asking the postmaster > to ask the member to update his/her whitelist to allow email through. > While it's a courtesy to do so, those who post to this list > should not feel obligated to respond to clueless spam filters. >=20 > Speaking of clueless spam filters, at least one company has > its email firewall configured to reject Internet-Draft announcements > (the firewall appears to be configured to reject the MIME > type used by those announcements). The postmaster for the > company involved has been sent a note that their email firewall > is being overly aggressive. If you're not getting Internet-Draft > announcements (there was one sent to the IPS list this afternoon, > just before 3pm Eastern time), you might want to check with > your postmaster about this. >=20 > Thanks, > --David >=20 > ---------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 176 South St., Hopkinton, MA 01748 > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > black_david@emc.com Mobile: +1 (978) 394-7754 > ---------------------------------------------------- >=20 >=20 > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips --=20 Brian F. G. Bidulock =A6 The reasonable man adapts himself to the =A6 bidulock@openss7.org =A6 world; the unreasonable one persists in =A6 http://www.openss7.org/ =A6 trying to adapt the world to himself. =A6 =A6 Therefore all progress depends on the =A6 =A6 unreasonable man. -- George Bernard Shaw =A6 _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Tue Sep 23 12:19:42 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22464 for ; Tue, 23 Sep 2003 12:19:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1psm-0005Gs-AX for ips-archive@odin.ietf.org; Tue, 23 Sep 2003 12:19:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8NGJKeV020256 for ips-archive@odin.ietf.org; Tue, 23 Sep 2003 12:19:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1psm-0005Gd-3C for ips-web-archive@optimus.ietf.org; Tue, 23 Sep 2003 12:19:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22448 for ; Tue, 23 Sep 2003 12:19:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1psk-0002V3-00 for ips-web-archive@ietf.org; Tue, 23 Sep 2003 12:19:18 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A1psk-0002Uz-00 for ips-web-archive@ietf.org; Tue, 23 Sep 2003 12:19:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1psT-0005DR-Qk; Tue, 23 Sep 2003 12:19:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1prV-00059q-JJ for ips@optimus.ietf.org; Tue, 23 Sep 2003 12:18:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22377 for ; Tue, 23 Sep 2003 12:17:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1prU-0002TW-00 for ips@ietf.org; Tue, 23 Sep 2003 12:18:00 -0400 Received: from d12lmsgate-3.de.ibm.com ([194.196.100.236] helo=d12lmsgate.de.ibm.com) by ietf-mx with esmtp (Exim 4.12) id 1A1prT-0002S9-00 for ips@ietf.org; Tue, 23 Sep 2003 12:17:59 -0400 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by d12lmsgate.de.ibm.com (8.12.10/8.12.8) with ESMTP id h8NGHRXZ057058 for ; Tue, 23 Sep 2003 18:17:27 +0200 Received: from d10ml001.telaviv.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h8NGHQhP240398 for ; Tue, 23 Sep 2003 18:17:26 +0200 To: ips@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF2 July 23, 2003 From: "Julian Satran" Message-ID: Date: Tue, 23 Sep 2003 19:17:25 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 23/09/2003 19:17:25, Serialize complete at 23/09/2003 19:17:25 Content-Type: multipart/alternative; boundary="=_alternative 00595CF1C2256DAA_=" Subject: [Ips] test Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , This is a multipart message in MIME format. --=_alternative 00595CF1C2256DAA_= Content-Type: text/plain; charset="US-ASCII" please ignore --=_alternative 00595CF1C2256DAA_= Content-Type: text/html; charset="US-ASCII"
please ignore --=_alternative 00595CF1C2256DAA_=-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Sun Sep 28 14:53:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26515 for ; Sun, 28 Sep 2003 14:53:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3gfO-0000dy-9r for ips-archive@odin.ietf.org; Sun, 28 Sep 2003 14:53:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8SIrACn002468 for ips-archive@odin.ietf.org; Sun, 28 Sep 2003 14:53:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3gfO-0000dj-3p for ips-web-archive@optimus.ietf.org; Sun, 28 Sep 2003 14:53:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26508 for ; Sun, 28 Sep 2003 14:53:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A3gfL-0003oJ-00 for ips-web-archive@ietf.org; Sun, 28 Sep 2003 14:53:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A3gfK-0003oF-00 for ips-web-archive@ietf.org; Sun, 28 Sep 2003 14:53:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3gfF-0000d5-In; Sun, 28 Sep 2003 14:53:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3geS-0000ca-4S for ips@optimus.ietf.org; Sun, 28 Sep 2003 14:52:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26495; Sun, 28 Sep 2003 14:51:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A3geI-0003o6-00; Sun, 28 Sep 2003 14:52:02 -0400 Received: from [63.91.96.5] (helo=newex.sbs-mio.com) by ietf-mx with esmtp (Exim 4.12) id 1A3geH-0003nv-00; Sun, 28 Sep 2003 14:52:02 -0400 Received: by NEWEX with Internet Mail Service (5.5.2655.55) id ; Sun, 28 Sep 2003 11:51:30 -0700 Message-ID: <4DCF75ED419BD411821A0050DAB499CD01DE3FC0@NEWEX> From: Vysyaraju Daliraju To: "'Julian Satran'" , Eddy Quicksall Cc: ips@ietf.org, ips-admin@ietf.org Date: Sun, 28 Sep 2003 11:51:30 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C385F1.87671C40" Subject: [Ips] iscsi RDMA standard Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , 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_01C385F1.87671C40 Content-Type: text/plain; charset="iso-8859-1" Hi I am new to RDMA ISCSI. Is there any standars exist for iscsi RDMA. Vysyaraju Dali Raju __________________________________________ Vysyaraju Daliraju, / Sr Systems Software Engineer SBS Technologies, 8371C Central Ave. / Newark, CA 94560 Phone: 510-742-2570 / Fax: -2501 / EMail: VDaliraju@sbs.com -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Saturday, September 20, 2003 1:52 PM To: Eddy Quicksall Cc: ips@ietf.org; ips-admin@ietf.org Subject: RE: [Ips] NOP during Discovery Eddy, I think that they realized that already and are content. NOP is somewhat richer in that in a "storage router" NOP might reach the end-point while SendTargets will probably not. In any case the text is unequivocal about NOP. Julo Eddy Quicksall 20/09/2003 14:12 To Julian Satran/Haifa/IBM@IBMIL cc ips@ietf.org, ips-admin@ietf.org Subject RE: [Ips] NOP during Discovery Thanks Would it work to just use SendTargets= instead of NOP? If there is a target for the discovery session, it would respond with just the target name. If there are no targets for the discovery session, the target would still respond but with 0 for the DataSegmentLength. If so, can you talk that person into that? Eddy -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Saturday, September 20, 2003 1:52 PM To: Eddy Quicksall Cc: ips@ietf.org; ips-admin@ietf.org Subject: Re: [Ips] NOP during Discovery It is not allowed in discovery - There was a long discussion with one party insisting on having NOP as a way of keeping the discovery session alive. Discovery being only a lightweight location mechanism it was decided that it is not worth having it as a permanent alternative for a management interface. Regards, Julo Eddy Quicksall Sent by: ips-admin@ietf.org 19/09/2003 16:04 To ips@ietf.org cc Subject [Ips] NOP during Discovery I have found that at least one initiator is doing a NOP-out during discovery phase. But the spec says that isn't allowed. Am I misunderstanding something? 3.3 iSCSI Session Types iSCSI defines two types of sessions: a) Normal operational session - an unrestricted session. b) Discovery-session - a session only opened for target discovery. The target MUST ONLY accept text requests with the SendTargets key and a logout request with reason "close the session". All other requests MUST be rejected. The session type is defined during login with key=value parameter in the login command. Eddy ***This message has been scanned for virus, spam, and undesirable content.*** ***For further information, contact your mail administrator.*** ------_=_NextPart_001_01C385F1.87671C40 Content-Type: text/html; charset="iso-8859-1"

Hi
 
I am new to RDMA ISCSI. Is there any standars exist for iscsi RDMA.
 

Vysyaraju Dali Raju

__________________________________________

Vysyaraju Daliraju, / Sr Systems Software Engineer

SBS Technologies, 8371C Central Ave. / Newark, CA 94560

Phone: 510-742-2570 / Fax: -2501 / EMail: VDaliraju@sbs.com <mailto:VDaliraju@sbs.com>

 
 
 
 
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Saturday, September 20, 2003 1:52 PM
To: Eddy Quicksall
Cc: ips@ietf.org; ips-admin@ietf.org
Subject: RE: [Ips] NOP during Discovery


Eddy,

I think that they realized that already and are content. NOP is somewhat richer in that in a "storage router" NOP might reach the end-point while SendTargets will probably not.  In any case the text is unequivocal about NOP.

Julo


Eddy Quicksall <eddy_quicksall@ivivity.com>

20/09/2003 14:12

To
Julian Satran/Haifa/IBM@IBMIL
cc
ips@ietf.org, ips-admin@ietf.org
Subject
RE: [Ips] NOP during Discovery





Thanks

 

Would it work to just use SendTargets=<nothing> instead of NOP? If there is a target for the discovery session, it would respond with just the target name. If there are no targets for the discovery session, the target would still respond but with 0 for the DataSegmentLength.

 

If so, can you talk that person into that?

 

Eddy

 

-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Saturday, September 20, 2003 1:52 PM
To: Eddy Quicksall
Cc: ips@ietf.org; ips-admin@ietf.org
Subject: Re: [Ips] NOP during Discovery

 


It is not allowed in discovery - There was a long discussion with one party insisting on having NOP as a way of keeping the discovery session alive.
Discovery being only a lightweight location mechanism it was decided that it is  not worth having it as a permanent alternative for a management interface.

Regards,
Julo

Eddy Quicksall <eddy_quicksall@ivivity.com>
Sent by: ips-admin@ietf.org

19/09/2003 16:04


To
ips@ietf.org
cc
 
Subject
[Ips] NOP during Discovery

 


   




I have found that at least one initiator is doing a NOP-out during discovery phase. But the spec says that isn't allowed. Am I misunderstanding something?

 

3.3 iSCSI Session Types

  iSCSI defines two types of sessions:

  a) Normal operational session - an unrestricted session.

  b) Discovery-session - a session only opened for target

     discovery. The target MUST ONLY accept text requests with the

     SendTargets key and a logout request with reason "close the

     session". All other requests MUST be rejected.

     The session type is defined during login with key=value parameter in

     the login command.

 

 

Eddy

 


***This message has been scanned for virus, spam, and undesirable content.***
***For further information, contact your mail administrator.***

------_=_NextPart_001_01C385F1.87671C40-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Mon Sep 29 01:06:02 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13038 for ; Mon, 29 Sep 2003 01:06:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3qE6-0003I8-Db for ips-archive@odin.ietf.org; Mon, 29 Sep 2003 01:05:39 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8T55cXl012648 for ips-archive@odin.ietf.org; Mon, 29 Sep 2003 01:05:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3qE6-0003Hv-9L for ips-web-archive@optimus.ietf.org; Mon, 29 Sep 2003 01:05:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13034 for ; Mon, 29 Sep 2003 01:05:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A3qE3-0000oG-00 for ips-web-archive@ietf.org; Mon, 29 Sep 2003 01:05:35 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A3qE3-0000oD-00 for ips-web-archive@ietf.org; Mon, 29 Sep 2003 01:05:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3qDW-0003Gm-Az; Mon, 29 Sep 2003 01:05:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3qDC-0003G4-Gf for ips@optimus.ietf.org; Mon, 29 Sep 2003 01:04:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13025; Mon, 29 Sep 2003 01:04:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A3qD9-0000o7-00; Mon, 29 Sep 2003 01:04:39 -0400 Received: from d12lmsgate-3.de.ibm.com ([194.196.100.236] helo=d12lmsgate.de.ibm.com) by ietf-mx with esmtp (Exim 4.12) id 1A3qD7-0000nh-00; Mon, 29 Sep 2003 01:04:38 -0400 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by d12lmsgate.de.ibm.com (8.12.10/8.12.8) with ESMTP id h8T547XZ039190; Mon, 29 Sep 2003 07:04:07 +0200 Received: from d10ml001.telaviv.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h8T546Wo261890; Mon, 29 Sep 2003 07:04:06 +0200 In-Reply-To: <4DCF75ED419BD411821A0050DAB499CD01DE3FC0@NEWEX> To: Vysyaraju Daliraju Cc: Eddy Quicksall , ips@ietf.org, ips-admin@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF2 July 23, 2003 From: "Julian Satran" Message-ID: Date: Mon, 29 Sep 2003 08:04:03 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 29/09/2003 08:04:06, Serialize complete at 29/09/2003 08:04:06 Content-Type: multipart/alternative; boundary="=_alternative 001BD273C2256DB0_=" Subject: [Ips] Re: iscsi RDMA standard Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , This is a multipart message in MIME format. --=_alternative 001BD273C2256DB0_= Content-Type: text/plain; charset="US-ASCII" There is an extension to iSCSI called ISER - being worked on by a consortium of companies. Julo Vysyaraju Daliraju 28/09/2003 21:51 To Julian Satran/Haifa/IBM@IBMIL, Eddy Quicksall cc ips@ietf.org, ips-admin@ietf.org Subject iscsi RDMA standard Hi I am new to RDMA ISCSI. Is there any standars exist for iscsi RDMA. Vysyaraju Dali Raju __________________________________________ Vysyaraju Daliraju, / Sr Systems Software Engineer SBS Technologies, 8371C Central Ave. / Newark, CA 94560 Phone: 510-742-2570 / Fax: -2501 / EMail: VDaliraju@sbs.com < mailto:VDaliraju@sbs.com> -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Saturday, September 20, 2003 1:52 PM To: Eddy Quicksall Cc: ips@ietf.org; ips-admin@ietf.org Subject: RE: [Ips] NOP during Discovery Eddy, I think that they realized that already and are content. NOP is somewhat richer in that in a "storage router" NOP might reach the end-point while SendTargets will probably not. In any case the text is unequivocal about NOP. Julo Eddy Quicksall 20/09/2003 14:12 To Julian Satran/Haifa/IBM@IBMIL cc ips@ietf.org, ips-admin@ietf.org Subject RE: [Ips] NOP during Discovery Thanks Would it work to just use SendTargets= instead of NOP? If there is a target for the discovery session, it would respond with just the target name. If there are no targets for the discovery session, the target would still respond but with 0 for the DataSegmentLength. If so, can you talk that person into that? Eddy -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Saturday, September 20, 2003 1:52 PM To: Eddy Quicksall Cc: ips@ietf.org; ips-admin@ietf.org Subject: Re: [Ips] NOP during Discovery It is not allowed in discovery - There was a long discussion with one party insisting on having NOP as a way of keeping the discovery session alive. Discovery being only a lightweight location mechanism it was decided that it is not worth having it as a permanent alternative for a management interface. Regards, Julo Eddy Quicksall Sent by: ips-admin@ietf.org 19/09/2003 16:04 To ips@ietf.org cc Subject [Ips] NOP during Discovery I have found that at least one initiator is doing a NOP-out during discovery phase. But the spec says that isn't allowed. Am I misunderstanding something? 3.3 iSCSI Session Types iSCSI defines two types of sessions: a) Normal operational session - an unrestricted session. b) Discovery-session - a session only opened for target discovery. The target MUST ONLY accept text requests with the SendTargets key and a logout request with reason "close the session". All other requests MUST be rejected. The session type is defined during login with key=value parameter in the login command. Eddy ***This message has been scanned for virus, spam, and undesirable content.*** ***For further information, contact your mail administrator.*** --=_alternative 001BD273C2256DB0_= Content-Type: text/html; charset="US-ASCII"
There is an extension to iSCSI called ISER - being worked on by a consortium of companies. Julo


Vysyaraju Daliraju <VDaliraju@sbs.com>

28/09/2003 21:51

To
Julian Satran/Haifa/IBM@IBMIL, Eddy Quicksall <eddy_quicksall@ivivity.com>
cc
ips@ietf.org, ips-admin@ietf.org
Subject
iscsi RDMA standard





Hi
 
I am new to RDMA ISCSI. Is there any standars exist for iscsi RDMA.
 

Vysyaraju Dali Raju

__________________________________________

Vysyaraju Daliraju, / Sr Systems Software Engineer

SBS Technologies, 8371C Central Ave. / Newark, CA 94560

Phone: 510-742-2570 / Fax: -2501 / EMail: VDaliraju@sbs.com <mailto:VDaliraju@sbs.com>

 
 
 
 
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Saturday, September 20, 2003 1:52 PM
To: Eddy Quicksall
Cc: ips@ietf.org; ips-admin@ietf.org
Subject: RE: [Ips] NOP during Discovery

Eddy,

I think that they realized that already and are content. NOP is somewhat richer in that in a "storage router" NOP might reach the end-point while SendTargets will probably not.  In any case the text is unequivocal about NOP.

Julo

Eddy Quicksall <eddy_quicksall@ivivity.com>

20/09/2003 14:12


To
Julian Satran/Haifa/IBM@IBMIL
cc
ips@ietf.org, ips-admin@ietf.org
Subject
RE: [Ips] NOP during Discovery







Thanks

 

Would it work to just use SendTargets=<nothing> instead of NOP? If there is a target for the discovery session, it would respond with just the target name. If there are no targets for the discovery session, the target would still respond but with 0 for the DataSegmentLength.

 

If so, can you talk that person into that?

 

Eddy

 

-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Saturday, September 20, 2003 1:52 PM
To: Eddy Quicksall
Cc: ips@ietf.org; ips-admin@ietf.org
Subject: Re: [Ips] NOP during Discovery

 


It is not allowed in discovery - There was a long discussion with one party insisting on having NOP as a way of keeping the discovery session alive.
Discovery being only a lightweight location mechanism it was decided that it is  not worth having it as a permanent alternative for a management interface.

Regards,
Julo

Eddy Quicksall <eddy_quicksall@ivivity.com>
Sent by: ips-admin@ietf.org

19/09/2003 16:04


To
ips@ietf.org
cc
 
Subject
[Ips] NOP during Discovery

 


   




I have found that at least one initiator is doing a NOP-out during discovery phase. But the spec says that isn't allowed. Am I misunderstanding something?

 

3.3 iSCSI Session Types

  iSCSI defines two types of sessions:

  a) Normal operational session - an unrestricted session.

  b) Discovery-session - a session only opened for target

     discovery. The target MUST ONLY accept text requests with the

     SendTargets key and a logout request with reason "close the

     session". All other requests MUST be rejected.

     The session type is defined during login with key=value parameter in

     the login command.

 

 

Eddy

 


***This message has been scanned for virus, spam, and undesirable content.***
***For further information, contact your mail administrator.***

--=_alternative 001BD273C2256DB0_=-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Mon Sep 29 01:57:40 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14242 for ; Mon, 29 Sep 2003 01:57:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3r24-0005gY-3n for ips-archive@odin.ietf.org; Mon, 29 Sep 2003 01:57:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8T5vGHm021848 for ips-archive@odin.ietf.org; Mon, 29 Sep 2003 01:57:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3r24-0005gJ-02 for ips-web-archive@optimus.ietf.org; Mon, 29 Sep 2003 01:57:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14211 for ; Mon, 29 Sep 2003 01:57:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A3r20-0001Cd-00 for ips-web-archive@ietf.org; Mon, 29 Sep 2003 01:57:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A3r20-0001Ca-00 for ips-web-archive@ietf.org; Mon, 29 Sep 2003 01:57:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3r1q-0005aa-0Y; Mon, 29 Sep 2003 01:57:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3r0r-0005Si-Ev for ips@optimus.ietf.org; Mon, 29 Sep 2003 01:56:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14158 for ; Mon, 29 Sep 2003 01:55:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A3r0o-0001BV-00 for ips@ietf.org; Mon, 29 Sep 2003 01:55:58 -0400 Received: from web20711.mail.yahoo.com ([66.163.169.152]) by ietf-mx with smtp (Exim 4.12) id 1A3r0n-0001BS-00 for ips@ietf.org; Mon, 29 Sep 2003 01:55:57 -0400 Message-ID: <20030929055558.33042.qmail@web20711.mail.yahoo.com> Received: from [67.120.99.130] by web20711.mail.yahoo.com via HTTP; Sun, 28 Sep 2003 22:55:58 PDT Date: Sun, 28 Sep 2003 22:55:58 -0700 (PDT) From: dan yo To: ips@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1502348857-1064814958=:28888" Subject: [Ips] iSNS: question on exporting FC Zone DB to iSNS DB Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , --0-1502348857-1064814958=:28888 Content-Type: text/plain; charset=us-ascii Hi, I would like to get some opinions and thoughts on mapping FC Zone Server DB to iSNS DB in a single or multiple fabrics, mixed protocol SAN switches environment. Based on my understanding of the FC-GS, FC-SW, and the iSNS draft, FC zone objects are mapped to iSNS objects as follow: FC zone maps to iSNS DD (Discovery Domain). FC zone set maps to iSNS DD Set. FC fabric maps to iSNS Network Entity. Assume we have a multi-fabric SAN with mixed FC and iSCSI switches, and FC/iSCSI gateways. We want to create a central iSNS database to store all the devices, where some of the devices are exported from the FC zone DBs, and some are registered from the iSNS capable clients (most likely iSCSI devices). With the central iSNS server, iSNS capable management stations now have a full view of the whole multi-fabric SAN. My questions are: 1. Would iSNS serve well for the above application? 2. When FC Zone DBs are merged or segmented, how the FC Zone DBs are synchronized with the iSNS DB is an implementation issue, but has anybody written any guideline or paper on this? If not, would this subject be a good ietf draft/rfc candidate? 3. Is there any such product on the market from the major SAN switch manufacturers (that exports and maps FC Zone DB to iSNS server)? Thanks, Dan --------------------------------- Do you Yahoo!? The New Yahoo! Shopping - with improved product search --0-1502348857-1064814958=:28888 Content-Type: text/html; charset=us-ascii

Hi,
 
I would like to get some opinions and thoughts on mapping FC Zone Server DB
to iSNS DB in a single or multiple fabrics, mixed protocol SAN switches
environment.
 
Based on my understanding of the FC-GS, FC-SW, and the iSNS draft, FC zone
objects are mapped to iSNS objects as follow:
 
  FC zone maps to iSNS DD (Discovery Domain).
  FC zone set maps to iSNS DD Set.
  FC fabric maps to iSNS Network Entity.
 
Assume we have a multi-fabric SAN with mixed FC and iSCSI switches,
and FC/iSCSI gateways.
We want to create a central iSNS database to store all the devices,
where some of the devices are exported from the FC zone DBs, and some
are registered from the iSNS capable clients (most likely iSCSI devices). 
With the central iSNS server, iSNS capable management stations now
have a full view of the whole multi-fabric SAN. 
 
My questions are:
 
1. Would iSNS serve well for the above application?
2. When FC Zone DBs are merged or segmented, how the FC Zone DBs
    are synchronized with the iSNS DB is an implementation issue, but 
    has anybody written any guideline or paper on this?
    If not, would this subject be a good ietf draft/rfc candidate?
3. Is there any such product on the market from the major SAN switch
    manufacturers (that exports and maps FC Zone DB to iSNS server)?
 
Thanks,
Dan
 

Do you Yahoo!?
The New Yahoo! Shopping - with improved product search --0-1502348857-1064814958=:28888-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Mon Sep 29 09:47:46 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14731 for ; Mon, 29 Sep 2003 09:47:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3yMz-00038K-PU for ips-archive@odin.ietf.org; Mon, 29 Sep 2003 09:47:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8TDlLIo012038 for ips-archive@odin.ietf.org; Mon, 29 Sep 2003 09:47:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3yMz-000385-8R for ips-web-archive@optimus.ietf.org; Mon, 29 Sep 2003 09:47:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14712 for ; Mon, 29 Sep 2003 09:47:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A3yMx-0005z4-00 for ips-web-archive@ietf.org; Mon, 29 Sep 2003 09:47:19 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A3yMw-0005z1-00 for ips-web-archive@ietf.org; Mon, 29 Sep 2003 09:47:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3yMf-00035P-84; Mon, 29 Sep 2003 09:47:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3sPy-0002u3-FZ for ips@optimus.ietf.org; Mon, 29 Sep 2003 03:26:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29039 for ; Mon, 29 Sep 2003 03:25:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A3sPw-00023a-00 for ips@ietf.org; Mon, 29 Sep 2003 03:26:00 -0400 Received: from mcjekyll.mcdata.com ([144.49.6.25] helo=380GATE01out.mcdata.com) by ietf-mx with esmtp (Exim 4.12) id 1A3sPv-00023N-00 for ips@ietf.org; Mon, 29 Sep 2003 03:25:59 -0400 Received: from 380GATE01.mcdata.com ([172.18.1.72]) by 380GATE01out.mcdata.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 29 Sep 2003 01:25:30 -0600 Received: from ariel.nishansystems.com ([192.100.100.16]) by 380GATE01 with InterScan Messaging Security Suite; Mon, 29 Sep 2003 01:25:29 -0600 Received: by ariel.nishansystems.com with Internet Mail Service (5.5.2653.19) id ; Mon, 29 Sep 2003 00:25:28 -0700 Message-ID: From: Joshua Tseng To: "'dan yo'" , ips@ietf.org Subject: RE: [Ips] iSNS: question on exporting FC Zone DB to iSNS DB Date: Mon, 29 Sep 2003 00:25:27 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3865A.DAB1F460" X-OriginalArrivalTime: 29 Sep 2003 07:25:30.0486 (UTC) FILETIME=[DCB9F960:01C3865A] Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , 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_01C3865A.DAB1F460 Content-Type: text/plain Dan, Here are my responses: 1) Yes, as alluded to in the iSNS draft. You understood it well. 2) You are welcome to write a paper or RFC if you desire. I am willing to help you out. 3) Yes. Regards, Josh -----Original Message----- From: dan yo [mailto:ipsandude@yahoo.com] Sent: Sunday, September 28, 2003 10:56 PM To: ips@ietf.org Subject: [Ips] iSNS: question on exporting FC Zone DB to iSNS DB Hi, I would like to get some opinions and thoughts on mapping FC Zone Server DB to iSNS DB in a single or multiple fabrics, mixed protocol SAN switches environment. Based on my understanding of the FC-GS, FC-SW, and the iSNS draft, FC zone objects are mapped to iSNS objects as follow: FC zone maps to iSNS DD (Discovery Domain). FC zone set maps to iSNS DD Set. FC fabric maps to iSNS Network Entity. Assume we have a multi-fabric SAN with mixed FC and iSCSI switches, and FC/iSCSI gateways. We want to create a central iSNS database to store all the devices, where some of the devices are exported from the FC zone DBs, and some are registered from the iSNS capable clients (most likely iSCSI devices). With the central iSNS server, iSNS capable management stations now have a full view of the whole multi-fabric SAN. My questions are: 1. Would iSNS serve well for the above application? 2. When FC Zone DBs are merged or segmented, how the FC Zone DBs are synchronized with the iSNS DB is an implementation issue, but has anybody written any guideline or paper on this? If not, would this subject be a good ietf draft/rfc candidate? 3. Is there any such product on the market from the major SAN switch manufacturers (that exports and maps FC Zone DB to iSNS server)? Thanks, Dan _____ Do you Yahoo!? The New Yahoo! Shopping - with improved product search SPECIAL NOTICE All information transmitted hereby is intended only for the use of the addressee(s) named above and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of confidential and privileged information is prohibited. If the reader of this message is not the intended recipient(s) or the employee or agent responsible for delivering the message to the intended recipient, you are herby notified that you must not read this transmission and that disclosure, copying, printing, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. Anyone who receives confidential and privileged information in error should notify us immediately by telephone and mail the original message to us at the above address and destroy all copies. To the extent any portion of this communication contains public information, no such restrictions apply to that information. (gate01) ------_=_NextPart_001_01C3865A.DAB1F460 Content-Type: text/html

Dan,

 

Here are my responses:

 

1)       Yes, as alluded to in the iSNS draft.  You understood it well.

2)       You are welcome to write a paper or RFC if you desire.  I am willing to help you out.

3)       Yes.

 

Regards,

Josh

 

 

 

-----Original Message-----
From: dan yo [mailto:ipsandude@yahoo.com]
Sent: Sunday, September 28, 2003 10:56 PM
To: ips@ietf.org
Subject: [Ips] iSNS: question on exporting FC Zone DB to iSNS DB

 

Hi,

 

I would like to get some opinions and thoughts on mapping FC Zone Server DB

to iSNS DB in a single or multiple fabrics, mixed protocol SAN switches

environment.

 

Based on my understanding of the FC-GS, FC-SW, and the iSNS draft, FC zone

objects are mapped to iSNS objects as follow:

 

  FC zone maps to iSNS DD (Discovery Domain).

  FC zone set maps to iSNS DD Set.

  FC fabric maps to iSNS Network Entity.

 

Assume we have a multi-fabric SAN with mixed FC and iSCSI switches,

and FC/iSCSI gateways.

We want to create a central iSNS database to store all the devices,

where some of the devices are exported from the FC zone DBs, and some

are registered from the iSNS capable clients (most likely iSCSI devices). 

With the central iSNS server, iSNS capable management stations now

have a full view of the whole multi-fabric SAN. 

 

My questions are:

 

1. Would iSNS serve well for the above application?

2. When FC Zone DBs are merged or segmented, how the FC Zone DBs

    are synchronized with the iSNS DB is an implementation issue, but 

    has anybody written any guideline or paper on this?

    If not, would this subject be a good ietf draft/rfc candidate?

3. Is there any such product on the market from the major SAN switch

    manufacturers (that exports and maps FC Zone DB to iSNS server)?

 

Thanks,

Dan

 

Do you Yahoo!?
The New Yahoo! Shopping - with improved product search

SPECIAL NOTICE 

All information transmitted hereby is intended only for the use of the
addressee(s) named above and may contain confidential and privileged
information. Any unauthorized review, use, disclosure or distribution
of confidential and privileged information is prohibited. If the reader
of this message is not the intended recipient(s) or the employee or agent
responsible for delivering the message to the intended recipient, you are
herby notified that you must not read this transmission and that disclosure,
copying, printing, distribution or use of any of the information contained
in or attached to this transmission is STRICTLY PROHIBITED.

Anyone who receives confidential and privileged information in error should
notify us immediately by telephone and mail the original message to us at
the above address and destroy all copies.  To the extent any portion of this
communication contains public information, no such restrictions apply to that
information. (gate01)
------_=_NextPart_001_01C3865A.DAB1F460-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Mon Sep 29 10:52:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18857 for ; Mon, 29 Sep 2003 10:52:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3zNm-0006Za-KT for ips-archive@odin.ietf.org; Mon, 29 Sep 2003 10:52:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8TEqEsd025263 for ips-archive@odin.ietf.org; Mon, 29 Sep 2003 10:52:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3zNm-0006ZO-81 for ips-web-archive@optimus.ietf.org; Mon, 29 Sep 2003 10:52:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18843 for ; Mon, 29 Sep 2003 10:52:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A3zNi-0006r3-00 for ips-web-archive@ietf.org; Mon, 29 Sep 2003 10:52:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A3zNh-0006r0-00 for ips-web-archive@ietf.org; Mon, 29 Sep 2003 10:52:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3zNZ-0006YM-4K; Mon, 29 Sep 2003 10:52:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3zMk-0006XS-O6 for ips@optimus.ietf.org; Mon, 29 Sep 2003 10:51:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18821; Mon, 29 Sep 2003 10:51:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A3zMh-0006qq-00; Mon, 29 Sep 2003 10:51:07 -0400 Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx with esmtp (Exim 4.12) id 1A3zMh-0006qa-00; Mon, 29 Sep 2003 10:51:07 -0400 Received: from mail5.microsoft.com ([157.54.6.156]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 29 Sep 2003 07:50:35 -0700 Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(6.0.3790.1039); Mon, 29 Sep 2003 07:50:36 -0700 Received: from 157.54.8.109 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 29 Sep 2003 07:50:35 -0700 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 29 Sep 2003 07:50:35 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 29 Sep 2003 07:50:41 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Mon, 29 Sep 2003 07:50:34 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Subject: RE: [Ips] Re: iscsi RDMA standard Date: Mon, 29 Sep 2003 07:50:32 -0700 Message-ID: Thread-Topic: [Ips] Re: iscsi RDMA standard thread-index: AcOGR1bsNr+0EgWvSGqqEvY+vRtMmQAUQ+SA From: "Jim Pinkerton" To: "Julian Satran" , "Vysyaraju Daliraju" Cc: "Eddy Quicksall" , , X-OriginalArrivalTime: 29 Sep 2003 14:50:34.0602 (UTC) FILETIME=[099EB4A0:01C38699] Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C38699.078C5F60" ------_=_NextPart_001_01C38699.078C5F60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 The consortium (www.rdmaconsortium.org ) has submitted iSER to the IETF IPS working group as a potential work item.=20 =20 The initial wire protocol Internet Draft is at http://www.ietf.org/internet-drafts/draft-ko-iwarp-iser-00.txt The initial data mover architecture Internet Draft is at http://www.ietf.org/internet-drafts/draft-chadalapaka-iwarp-da-00.txt =20 =20 =20 Jim =20 =20 =20 =20 =20 =20 ________________________________ From: ips-admin@ietf.org [mailto:ips-admin@ietf.org] On Behalf Of Julian Satran Sent: Sunday, September 28, 2003 10:04 PM To: Vysyaraju Daliraju Cc: Eddy Quicksall; ips@ietf.org; ips-admin@ietf.org Subject: [Ips] Re: iscsi RDMA standard =20 There is an extension to iSCSI called ISER - being worked on by a consortium of companies. Julo=20 Vysyaraju Daliraju =20 28/09/2003 21:51=20 To Julian Satran/Haifa/IBM@IBMIL, Eddy Quicksall =20 cc ips@ietf.org, ips-admin@ietf.org=20 Subject iscsi RDMA standard =20 =20 =20 Hi=20 =20 I am new to RDMA ISCSI. Is there any standars exist for iscsi RDMA.=20 =20 Vysyaraju Dali Raju=20 __________________________________________=20 Vysyaraju Daliraju, / Sr Systems Software Engineer=20 SBS Technologies, 8371C Central Ave. / Newark, CA 94560=20 Phone: 510-742-2570 / Fax: -2501 / EMail: VDaliraju@sbs.com =20 =20 =20 =20 =20 -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Saturday, September 20, 2003 1:52 PM To: Eddy Quicksall Cc: ips@ietf.org; ips-admin@ietf.org Subject: RE: [Ips] NOP during Discovery Eddy,=20 I think that they realized that already and are content. NOP is somewhat richer in that in a "storage router" NOP might reach the end-point while SendTargets will probably not. In any case the text is unequivocal about NOP.=20 Julo=20 Eddy Quicksall =20 20/09/2003 14:12=20 =20 To Julian Satran/Haifa/IBM@IBMIL=20 cc ips@ietf.org, ips-admin@ietf.org=20 Subject RE: [Ips] NOP during Discovery =20 =20 =20 Thanks=20 =20 Would it work to just use SendTargets=3D instead of NOP? If = there is a target for the discovery session, it would respond with just the target name. If there are no targets for the discovery session, the target would still respond but with 0 for the DataSegmentLength.=20 =20 If so, can you talk that person into that?=20 =20 Eddy=20 =20 -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com]=20 Sent: Saturday, September 20, 2003 1:52 PM To: Eddy Quicksall Cc: ips@ietf.org; ips-admin@ietf.org Subject: Re: [Ips] NOP during Discovery=20 =20 It is not allowed in discovery - There was a long discussion with one party insisting on having NOP as a way of keeping the discovery session alive.=20 Discovery being only a lightweight location mechanism it was decided that it is not worth having it as a permanent alternative for a management interface.=20 Regards,=20 Julo=20 Eddy Quicksall =20 Sent by: ips-admin@ietf.org=20 19/09/2003 16:04=20 =20 To ips@ietf.org=20 cc =20 Subject [Ips] NOP during Discovery =20 =20 =20 =20 I have found that at least one initiator is doing a NOP-out during discovery phase. But the spec says that isn't allowed. Am I misunderstanding something?=20 =20 3.3 iSCSI Session Types=20 iSCSI defines two types of sessions:=20 a) Normal operational session - an unrestricted session.=20 b) Discovery-session - a session only opened for target=20 discovery. The target MUST ONLY accept text requests with the=20 SendTargets key and a logout request with reason "close the=20 session". All other requests MUST be rejected.=20 The session type is defined during login with key=3Dvalue parameter in=20 the login command.=20 =20 =20 Eddy=20 =20 ***This message has been scanned for virus, spam, and undesirable content.*** ***For further information, contact your mail administrator.***=20 ------_=_NextPart_001_01C38699.078C5F60 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

The consortium (www.rdmaconsortium.org) has = submitted iSER to the IETF IPS working group as a potential work item. =

 

The initial wire = protocol Internet Draft is at h= ttp://www.ietf.org/internet-drafts/draft-ko-iwarp-iser-00.txt<= /font>

The initial data = mover architecture Internet Draft is at http://www.ietf.org/internet-drafts/draft-chadalapaka-iwarp-da-00.t= xt

 

 

 

Jim

 

 

 

 

 

 

From: ips-admin@ietf.org [mailto:ips-admin@ietf.org] On Behalf Of Julian Satran
Sent: Sunday, September = 28, 2003 10:04 PM
To: Vysyaraju = Daliraju
Cc: Eddy Quicksall; = ips@ietf.org; ips-admin@ietf.org
Subject: [Ips] Re: iscsi = RDMA standard

 


There is an extension to iSCSI called ISER - = being worked on by a consortium of companies. Julo

Vysyaraju Daliraju <VDaliraju@sbs.com>

28/09/2003 21:51

To

Julian Satran/Haifa/IBM@IBMIL, Eddy = Quicksall <eddy_quicksall@ivivity.com>

cc

ips@ietf.org, = ips-admin@ietf.org

Subject

iscsi RDMA standard

 

 

 




Hi
 
I am new to RDMA ISCSI. Is there any standars exist = for iscsi RDMA.
 

Vysyaraju Dali Raju

__________________________________________

Vysyaraju Daliraju, / Sr Systems Software = Engineer

SBS Technologies, 8371C Central Ave. / Newark, CA = 94560

Phone: 510-742-2570 / Fax: -2501 / EMail: = VDaliraju@sbs.com <mailto:VDaliraju@sbs.com>

 
 
 
 
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Saturday, September 20, 2003 1:52 PM
To: Eddy Quicksall
Cc: ips@ietf.org; ips-admin@ietf.org
Subject: RE: [Ips] NOP during Discovery


Eddy,

I think that they realized that already and are content. NOP is somewhat = richer in that in a "storage router" NOP might reach the end-point = while SendTargets will probably not.  In any case the text is unequivocal = about NOP.

Julo

Eddy Quicksall = <eddy_quicksall@ivivity.com>

20/09/2003 14:12

 

To

Julian = Satran/Haifa/IBM@IBMIL

cc

ips@ietf.org, = ips-admin@ietf.org

Subject

RE: [Ips] NOP during = Discovery

 

 

 





Thanks

 

Would it work to just use = SendTargets=3D<nothing> instead of NOP? If there is a target for the discovery session, it would respond = with just the target name. If there are no targets for the discovery session, = the target would still respond but with 0 for the = DataSegmentLength.

 

If so, can you talk that person into = that?

 

Eddy

 

-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com] =
Sent: Saturday, September 20, 2003 1:52 PM
To: Eddy Quicksall
Cc: ips@ietf.org; ips-admin@ietf.org
Subject: Re: [Ips] NOP during Discovery

 


It is not allowed in discovery - There was a long discussion with one = party insisting on having NOP as a way of keeping the discovery session = alive.
Discovery being only a lightweight location mechanism it was decided = that it is  not worth having it as a permanent alternative for a management interface.

Regards,
Julo

Eddy Quicksall <eddy_quicksall@ivivity.com>
Sent by: ips-admin@ietf.org

19/09/2003 16:04

 

To

ips@ietf.org

cc

 

Subject

[Ips] NOP during = Discovery

 

 

 

 




I have found that at least one initiator is doing a NOP-out during = discovery phase. But the spec says that isn't allowed. Am I misunderstanding = something?

 

3.3 iSCSI Session Types

  iSCSI defines two types of sessions:

  a) Normal operational session - an unrestricted session. =

  b) Discovery-session - a session only opened for target =

     discovery. The target MUST ONLY accept text requests with = the

     SendTargets key and a logout request with reason = "close the

     session". All other requests MUST be = rejected.

     The session type is defined during login with key=3Dvalue = parameter in

     the login command.

 

 

Eddy

 


***This message has been scanned for virus, spam, and undesirable = content.***
***For further information, contact your mail administrator.*** =

------_=_NextPart_001_01C38699.078C5F60-- --------------InterScan_NT_MIME_Boundary-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Mon Sep 29 12:38:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27684 for ; Mon, 29 Sep 2003 12:38:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A412N-0003jd-Gy for ips-archive@odin.ietf.org; Mon, 29 Sep 2003 12:38:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8TGcFFY014351 for ips-archive@odin.ietf.org; Mon, 29 Sep 2003 12:38:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A412N-0003jO-Ag for ips-web-archive@optimus.ietf.org; Mon, 29 Sep 2003 12:38:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27669 for ; Mon, 29 Sep 2003 12:38:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A412L-0001WJ-00 for ips-web-archive@ietf.org; Mon, 29 Sep 2003 12:38:13 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A412L-0001WG-00 for ips-web-archive@ietf.org; Mon, 29 Sep 2003 12:38:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A412A-0003gh-GI; Mon, 29 Sep 2003 12:38:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A411G-0003Jj-Eb for ips@optimus.ietf.org; Mon, 29 Sep 2003 12:37:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27604 for ; Mon, 29 Sep 2003 12:36:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A411E-0001Uy-00 for ips@ietf.org; Mon, 29 Sep 2003 12:37:04 -0400 Received: from web20702.mail.yahoo.com ([216.136.226.175]) by ietf-mx with smtp (Exim 4.12) id 1A411D-0001Uv-00 for ips@ietf.org; Mon, 29 Sep 2003 12:37:04 -0400 Message-ID: <20030929163703.26346.qmail@web20702.mail.yahoo.com> Received: from [63.121.140.220] by web20702.mail.yahoo.com via HTTP; Mon, 29 Sep 2003 09:37:03 PDT Date: Mon, 29 Sep 2003 09:37:03 -0700 (PDT) From: dan yo Subject: RE: [Ips] iSNS: question on exporting FC Zone DB to iSNS DB To: Joshua Tseng , ips@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-460142765-1064853423=:25102" Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , --0-460142765-1064853423=:25102 Content-Type: text/plain; charset=us-ascii Joshua, Thanks. Regardinig #2, I would be interested in writing a paper after I have explored more on the interoperability issues in bridging FC zones to iSNS, will definitely need more of your help. I don't believe this qualifies for IETF draft or RFC, but having a more well defined rules in mapping FC zones to iSNS will simplify the job of managing a mixed FC/iSCSI SAN. On a related question, is there a way to specify a IP subnet as an iSCSI Initiator node in a Discovery Domain -- the intent is to allow all the hosts on a subnet to access the targets in the corresponding DD. Regards, Dan Joshua Tseng wrote: Dan, Here are my responses: 1) Yes, as alluded to in the iSNS draft. You understood it well. 2) You are welcome to write a paper or RFC if you desire. I am willing to help you out. 3) Yes. Regards, Josh -----Original Message----- From: dan yo [mailto:ipsandude@yahoo.com] Sent: Sunday, September 28, 2003 10:56 PM To: ips@ietf.org Subject: [Ips] iSNS: question on exporting FC Zone DB to iSNS DB Hi, I would like to get some opinions and thoughts on mapping FC Zone Server DB to iSNS DB in a single or multiple fabrics, mixed protocol SAN switches environment. Based on my understanding of the FC-GS, FC-SW, and the iSNS draft, FC zone objects are mapped to iSNS objects as follow: FC zone maps to iSNS DD (Discovery Domain). FC zone set maps to iSNS DD Set. FC fabric maps to iSNS Network Entity. Assume we have a multi-fabric SAN with mixed FC and iSCSI switches, and FC/iSCSI gateways. We want to create a central iSNS database to store all the devices, where some of the devices are exported from the FC zone DBs, and some are registered from the iSNS capable clients (most likely iSCSI devices). With the central iSNS server, iSNS capable management stations now have a full view of the whole multi-fabric SAN. My questions are: 1. Would iSNS serve well for the above application? 2. When FC Zone DBs are merged or segmented, how the FC Zone DBs are synchronized with the iSNS DB is an implementation issue, but has anybody written any guideline or paper on this? If not, would this subject be a good ietf draft/rfc candidate? 3. Is there any such product on the market from the major SAN switch manufacturers (that exports and maps FC Zone DB to iSNS server)? Thanks, Dan --------------------------------- Do you Yahoo!? The New Yahoo! Shopping - with improved product search SPECIAL NOTICE All information transmitted hereby is intended only for the use of theaddressee(s) named above and may contain confidential and privilegedinformation. Any unauthorized review, use, disclosure or distributionof confidential and privileged information is prohibited. If the readerof this message is not the intended recipient(s) or the employee or agentresponsible for delivering the message to the intended recipient, you areherby notified that you must not read this transmission and that disclosure,copying, printing, distribution or use of any of the information containedin or attached to this transmission is STRICTLY PROHIBITED.Anyone who receives confidential and privileged information in error shouldnotify us immediately by telephone and mail the original message to us atthe above address and destroy all copies. To the extent any portion of thiscommunication contains public information, no such restrictions apply to thatinformation. (gate01) --------------------------------- Do you Yahoo!? The New Yahoo! Shopping - with improved product search --0-460142765-1064853423=:25102 Content-Type: text/html; charset=us-ascii
Joshua,
 
Thanks. 
 
Regardinig #2, I would be interested in writing a paper after I have explored 
more on the interoperability issues in bridging FC zones to iSNS, will
definitely need more of your help.  I don't believe this qualifies for IETF draft
or RFC, but having a more well defined rules in mapping FC zones to iSNS 
will simplify the job of managing a mixed FC/iSCSI SAN.
On a related question, is there a way to specify a IP subnet as an iSCSI
Initiator node in a Discovery Domain -- the intent is to allow all the hosts
on a subnet to access the targets in the corresponding DD.
 
Regards,
Dan

Joshua Tseng <Joshua.Tseng@mcdata.com> wrote:

Dan,

 

Here are my responses:

 

1)       Yes, as alluded to in the iSNS draft.  You understood it well.

2)       You are welcome to write a paper or RFC if you desire.  I am willing to help you out.

3)       Yes.

 

Regards,

Josh

 

 

 

-----Original Message-----
From: dan yo [mailto:ipsandude@yahoo.com]
Sent: Sunday, September 28, 2003 10:56 PM
To: ips@ietf.org
Subject: [Ips] iSNS: question on exporting FC Zone DB to iSNS DB

 

Hi,

 

I would like to get some opinions and thoughts on mapping FC Zone Server DB

to iSNS DB in a single or multiple fabrics, mixed protocol SAN switches

environment.

 

Based on my understanding of the FC-GS, FC-SW, and the iSNS draft, FC zone

objects are mapped to iSNS objects as follow:

 

  FC zone maps to iSNS DD (Discovery Domain).

  FC zone set maps to iSNS DD Set.

  FC fabric maps to iSNS Network Entity.

 

Assume we have a multi-fabric SAN with mixed FC and iSCSI switches,

and FC/iSCSI gateways.

We want to create a central iSNS database to store all the devices,

where some of the devices are exported from the FC zone DBs, and some

are registered from the iSNS capable clients (most likely iSCSI devices). 

With the central iSNS server, iSNS capable management stations now

have a full view of the whole multi-fabric SAN. 

 

My questions are:

 

1. Would iSNS serve well for the above application?

2. When FC Zone DBs are merged or segmented, how the FC Zone DBs

    are synchronized with the iSNS DB is an implementation issue, but 

    has anybody written any guideline or paper on this?

    If not, would this subject be a good ietf draft/rfc candidate?

3. Is there any such product on the market from the major SAN switch

    manufacturers (that exports and maps FC Zone DB to iSNS server)?

 

Thanks,

Dan

 

Do you Yahoo!?
The New Yahoo! Shopping - with improved product search

SPECIAL NOTICE 

All information transmitted hereby is intended only for the use of the
addressee(s) named above and may contain confidential and privileged
information. Any unauthorized review, use, disclosure or distribution
of confidential and privileged information is prohibited. If the reader
of this message is not the intended recipient(s) or the employee or agent
responsible for delivering the message to the intended recipient, you are
herby notified that you must not read this transmission and that disclosure,
copying, printing, distribution or use of any of the information contained
in or attached to this transmission is STRICTLY PROHIBITED.

Anyone who receives confidential and privileged information in error should
notify us immediately by telephone and mail the original message to us at
the above address and destroy all copies.  To the extent any portion of this
communication contains public information, no such restrictions apply to that
information. (gate01)

Do you Yahoo!?
The New Yahoo! Shopping - with improved product search --0-460142765-1064853423=:25102-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Mon Sep 29 12:44:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27988 for ; Mon, 29 Sep 2003 12:44:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4186-0004H9-6v for ips-archive@odin.ietf.org; Mon, 29 Sep 2003 12:44:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8TGiA7P016429 for ips-archive@odin.ietf.org; Mon, 29 Sep 2003 12:44:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4185-0004Gq-K4 for ips-web-archive@optimus.ietf.org; Mon, 29 Sep 2003 12:44:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27962 for ; Mon, 29 Sep 2003 12:44:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4183-0001cJ-00 for ips-web-archive@ietf.org; Mon, 29 Sep 2003 12:44:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4183-0001cG-00 for ips-web-archive@ietf.org; Mon, 29 Sep 2003 12:44:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A417x-0004A1-Vl; Mon, 29 Sep 2003 12:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A410H-0003Gt-Kp for ips@optimus.ietf.org; Mon, 29 Sep 2003 12:36:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27558 for ; Mon, 29 Sep 2003 12:35:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A410G-0001Tn-00 for ips@ietf.org; Mon, 29 Sep 2003 12:36:04 -0400 Received: from magic-mail.adaptec.com ([216.52.22.10] helo=magic.adaptec.com) by ietf-mx with esmtp (Exim 4.12) id 1A410F-0001TH-00 for ips@ietf.org; Mon, 29 Sep 2003 12:36:03 -0400 Received: from redfish.adaptec.com (redfish.adaptec.com [162.62.50.11]) by magic.adaptec.com (8.11.6/8.11.6) with ESMTP id h8TGZVR07346; Mon, 29 Sep 2003 09:35:31 -0700 Received: from aime2k02.adaptec.com (aime2k02.adaptec.com [10.25.8.42]) by redfish.adaptec.com (8.8.8p2+Sun/8.8.8) with ESMTP id JAA01756; Mon, 29 Sep 2003 09:35:31 -0700 (PDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: [Ips] Re: iscsi RDMA standard Date: Mon, 29 Sep 2003 09:35:31 -0700 Message-ID: <59C7D667A0EADB45866C62DD1B55A0FD4EC3D8@aime2k02.adaptec.com> Thread-Topic: [Ips] Re: iscsi RDMA standard Thread-Index: AcOGR2kezzDJ/aaqSUqzYx8QKD969gAX1kJQ From: "Carrier, John" To: "Vysyaraju Daliraju" Cc: Content-Transfer-Encoding: quoted-printable Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable The specs for iSCSI Extensions for RDMA (iSER) and the underlying = Datamover Architecture (DA) were submitted to the IETF in July. The = URLs for the Internet-Drafts are=20 http://www.ietf.org/internet-drafts/draft-chadalapaka-iwarp-da-00.txt http://www.ietf.org/internet-drafts/draft-ko-iwarp-iser-00.txt -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Sunday, September 28, 2003 10:04 PM To: Vysyaraju Daliraju Cc: Eddy Quicksall; ips@ietf.org; ips-admin@ietf.org Subject: [Ips] Re: iscsi RDMA standard There is an extension to iSCSI called ISER - being worked on by a = consortium of companies. Julo=20 Vysyaraju Daliraju =20 28/09/2003 21:51 ToJulian Satran/Haifa/IBM@IBMIL, Eddy Quicksall = =20 ccips@ietf.org, ips-admin@ietf.org=20 Subjectiscsi RDMA standard Hi=20 =20 I am new to RDMA ISCSI. Is there any standars exist for iscsi RDMA.=20 =20 Vysyaraju Dali Raju=20 __________________________________________=20 Vysyaraju Daliraju, / Sr Systems Software Engineer=20 SBS Technologies, 8371C Central Ave. / Newark, CA 94560=20 Phone: 510-742-2570 / Fax: -2501 / EMail: VDaliraju@sbs.com = =20 =20 =20 =20 =20 -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Saturday, September 20, 2003 1:52 PM To: Eddy Quicksall Cc: ips@ietf.org; ips-admin@ietf.org Subject: RE: [Ips] NOP during Discovery Eddy,=20 I think that they realized that already and are content. NOP is somewhat = richer in that in a "storage router" NOP might reach the end-point while = SendTargets will probably not. In any case the text is unequivocal = about NOP.=20 Julo=20 Eddy Quicksall =20 20/09/2003 14:12=20 ToJulian Satran/Haifa/IBM@IBMIL=20 ccips@ietf.org, ips-admin@ietf.org=20 SubjectRE: [Ips] NOP during Discovery Thanks=20 =20 Would it work to just use SendTargets=3D instead of NOP? If = there is a target for the discovery session, it would respond with just = the target name. If there are no targets for the discovery session, the = target would still respond but with 0 for the DataSegmentLength.=20 =20 If so, can you talk that person into that?=20 =20 Eddy=20 =20 -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com]=20 Sent: Saturday, September 20, 2003 1:52 PM To: Eddy Quicksall Cc: ips@ietf.org; ips-admin@ietf.org Subject: Re: [Ips] NOP during Discovery=20 =20 It is not allowed in discovery - There was a long discussion with one = party insisting on having NOP as a way of keeping the discovery session = alive.=20 Discovery being only a lightweight location mechanism it was decided = that it is not worth having it as a permanent alternative for a = management interface.=20 Regards,=20 Julo=20 Eddy Quicksall =20 Sent by: ips-admin@ietf.org=20 19/09/2003 16:04=20 Toips@ietf.org=20 cc =20 Subject[Ips] NOP during Discovery =20 =20 I have found that at least one initiator is doing a NOP-out during = discovery phase. But the spec says that isn't allowed. Am I = misunderstanding something?=20 =20 3.3 iSCSI Session Types=20 iSCSI defines two types of sessions:=20 a) Normal operational session - an unrestricted session.=20 b) Discovery-session - a session only opened for target=20 discovery. The target MUST ONLY accept text requests with the=20 SendTargets key and a logout request with reason "close the=20 session". All other requests MUST be rejected.=20 The session type is defined during login with key=3Dvalue parameter = in=20 the login command.=20 =20 =20 Eddy=20 =20 ***This message has been scanned for virus, spam, and undesirable = content.*** ***For further information, contact your mail administrator.***=20 _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Mon Sep 29 13:16:42 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29382 for ; Mon, 29 Sep 2003 13:16:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A41dB-0006IT-AR for ips-archive@odin.ietf.org; Mon, 29 Sep 2003 13:16:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8THGHit024205 for ips-archive@odin.ietf.org; Mon, 29 Sep 2003 13:16:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A41dB-0006IK-4s for ips-web-archive@optimus.ietf.org; Mon, 29 Sep 2003 13:16:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29360 for ; Mon, 29 Sep 2003 13:16:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A41d9-00023b-00 for ips-web-archive@ietf.org; Mon, 29 Sep 2003 13:16:15 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A41d9-00023Y-00 for ips-web-archive@ietf.org; Mon, 29 Sep 2003 13:16:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A41cw-0006Ec-8u; Mon, 29 Sep 2003 13:16:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A41cL-0006Dq-Do for ips@optimus.ietf.org; Mon, 29 Sep 2003 13:15:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29325; Mon, 29 Sep 2003 13:15:16 -0400 (EDT) From: pat_thaler@agilent.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A41cJ-000231-00; Mon, 29 Sep 2003 13:15:23 -0400 Received: from msgbas1x.cos.agilent.com ([192.25.240.36]) by ietf-mx with esmtp (Exim 4.12) id 1A41cI-00022y-00; Mon, 29 Sep 2003 13:15:22 -0400 Received: from relcos1.cos.agilent.com (relcos1.cos.agilent.com [130.29.152.239]) by msgbas1x.cos.agilent.com (Postfix) with ESMTP id A31B127D19; Mon, 29 Sep 2003 11:15:22 -0600 (MDT) Received: from axcsbh3.cos.agilent.com (axcsbh3.cos.agilent.com [130.29.152.190]) by relcos1.cos.agilent.com (Postfix) with SMTP id 7B9CD33; Mon, 29 Sep 2003 11:15:22 -0600 (MDT) Received: from 130.29.152.190 by axcsbh3.cos.agilent.com (InterScan E-Mail VirusWall NT); Mon, 29 Sep 2003 11:15:21 -0600 Received: by axcsbh3.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Mon, 29 Sep 2003 11:15:21 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A0132E0533@axcs04.cos.agilent.com> To: Julian_Satran@il.ibm.com, VDaliraju@sbs.com Cc: eddy_quicksall@ivivity.com, ips@ietf.org, ips-admin@ietf.org Subject: RE: [Ips] Re: iscsi RDMA standard Date: Mon, 29 Sep 2003 11:15:19 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-c5a3936e-e62f-4a48-9ecf-ee85337054f5" Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , 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. ------=_NextPartTM-000-c5a3936e-e62f-4a48-9ecf-ee85337054f5 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C386AD.4204F070" ------_=_NextPart_001_01C386AD.4204F070 Content-Type: text/plain; charset="ISO-8859-1" The consortium has finished the work Julian mentioned. The results of the work have been submitted as internet drafts: http://www.ietf.org/internet-drafts/draft-ko-iwarp-iser-00.txt and http://www.ietf.org/internet-drafts/draft-chadalapaka-iwarp-da-00.txt The first is the spec for iSCSI over iSER and the second is the architecture document. Pat -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Sunday, September 28, 2003 10:04 PM To: Vysyaraju Daliraju Cc: Eddy Quicksall; ips@ietf.org; ips-admin@ietf.org Subject: [Ips] Re: iscsi RDMA standard There is an extension to iSCSI called ISER - being worked on by a consortium of companies. Julo Vysyaraju Daliraju 28/09/2003 21:51 To Julian Satran/Haifa/IBM@IBMIL, Eddy Quicksall cc ips@ietf.org, ips-admin@ietf.org Subject iscsi RDMA standard Hi I am new to RDMA ISCSI. Is there any standars exist for iscsi RDMA. Vysyaraju Dali Raju __________________________________________ Vysyaraju Daliraju, / Sr Systems Software Engineer SBS Technologies, 8371C Central Ave. / Newark, CA 94560 Phone: 510-742-2570 / Fax: -2501 / EMail: VDaliraju@sbs.com -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Saturday, September 20, 2003 1:52 PM To: Eddy Quicksall Cc: ips@ietf.org; ips-admin@ietf.org Subject: RE: [Ips] NOP during Discovery Eddy, I think that they realized that already and are content. NOP is somewhat richer in that in a "storage router" NOP might reach the end-point while SendTargets will probably not. In any case the text is unequivocal about NOP. Julo Eddy Quicksall 20/09/2003 14:12 To Julian Satran/Haifa/IBM@IBMIL cc ips@ietf.org, ips-admin@ietf.org Subject RE: [Ips] NOP during Discovery Thanks Would it work to just use SendTargets= instead of NOP? If there is a target for the discovery session, it would respond with just the target name. If there are no targets for the discovery session, the target would still respond but with 0 for the DataSegmentLength. If so, can you talk that person into that? Eddy -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Saturday, September 20, 2003 1:52 PM To: Eddy Quicksall Cc: ips@ietf.org; ips-admin@ietf.org Subject: Re: [Ips] NOP during Discovery It is not allowed in discovery - There was a long discussion with one party insisting on having NOP as a way of keeping the discovery session alive. Discovery being only a lightweight location mechanism it was decided that it is not worth having it as a permanent alternative for a management interface. Regards, Julo Eddy Quicksall Sent by: ips-admin@ietf.org 19/09/2003 16:04 To ips@ietf.org cc Subject [Ips] NOP during Discovery I have found that at least one initiator is doing a NOP-out during discovery phase. But the spec says that isn't allowed. Am I misunderstanding something? 3.3 iSCSI Session Types iSCSI defines two types of sessions: a) Normal operational session - an unrestricted session. b) Discovery-session - a session only opened for target discovery. The target MUST ONLY accept text requests with the SendTargets key and a logout request with reason "close the session". All other requests MUST be rejected. The session type is defined during login with key=value parameter in the login command. Eddy ***This message has been scanned for virus, spam, and undesirable content.*** ***For further information, contact your mail administrator.*** ------_=_NextPart_001_01C386AD.4204F070 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
The = consortium has=20 finished the work Julian mentioned. The results of the work have been = submitted=20 as internet drafts:
 
= http://www.ietf.org/internet-drafts/draft-ko-iwarp-iser-00.txt
 
and
 
http://www.ietf.org/internet-drafts/draft-chadalapaka-iwarp-da-00= .txt
 
The = first is the=20 spec for iSCSI over iSER and the second is the architecture document.=20
 
Pat
-----Original Message-----
From: Julian Satran=20 [mailto:Julian_Satran@il.ibm.com]
Sent: Sunday, September = 28, 2003=20 10:04 PM
To: Vysyaraju Daliraju
Cc: Eddy = Quicksall;=20 ips@ietf.org; ips-admin@ietf.org
Subject: [Ips] Re: iscsi = RDMA=20 standard


There is an=20 extension to iSCSI called ISER - being worked on by a consortium of = companies.=20 Julo


Vysyaraju = Daliraju=20 <VDaliraju@sbs.com>

28/09/2003 21:51 =

To
Julian=20 Satran/Haifa/IBM@IBMIL, Eddy Quicksall=20 <eddy_quicksall@ivivity.com>=20
cc
ips@ietf.org,=20 ips-admin@ietf.org=20
Subject
iscsi = RDMA=20 standard

=




Hi
  =
I am new to RDMA ISCSI. Is there = any standars=20 exist for iscsi RDMA.
 =20

Vysyaraju Dali Raju =

__________________________________________=20

Vysyaraju Daliraju, / Sr = Systems=20 Software Engineer=20

SBS Technologies, 8371C = Central Ave. /=20 Newark, CA 94560=20

Phone: 510-742-2570 / = Fax: -2501 /=20 EMail: VDaliraju@sbs.com <mailto:VDaliraju@sbs.com>=20


 =20
 
  =
-----Original Message-----
From: = Julian Satran=20 [mailto:Julian_Satran@il.ibm.com]
Sent: Saturday, September = 20, 2003=20 1:52 PM
To: Eddy Quicksall
Cc: ips@ietf.org;=20 ips-admin@ietf.org
Subject: RE: [Ips] NOP during=20 Discovery


Eddy,

I think = that they realized=20 that already and are content. NOP is somewhat richer in that in a = "storage=20 router" NOP might reach the end-point while SendTargets will probably = not.=20  In any case the text is unequivocal about NOP.=20

Julo=20

Eddy = Quicksall=20 <eddy_quicksall@ivivity.com>

20/09/2003 = 14:12=20


To
Julian=20 Satran/Haifa/IBM@IBMIL
cc
ips@ietf.org,=20 ips-admin@ietf.org
Subject
RE: [Ips] = NOP during=20 Discovery







Thanks

 

Would it work to just = use=20 SendTargets=3D<nothing> instead of NOP? If there is a target = for the=20 discovery session, it would respond with just the target name. If = there are no=20 targets for the discovery session, the target would still respond but = with 0=20 for the DataSegmentLength.

 

If so, can you talk = that person into=20 that?

 

Eddy

 

-----Original = Message-----
From: Julian=20 Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Saturday, = September=20 20, 2003 1:52 PM
To: Eddy Quicksall
Cc: = ips@ietf.org;=20 ips-admin@ietf.org
Subject: Re: [Ips] NOP during=20 Discovery

 


It is not allowed in = discovery - There was=20 a long discussion with one party insisting on having NOP as a way of = keeping=20 the discovery session alive.=20
Discovery being only a = lightweight=20 location mechanism it was decided that it is  not worth having = it as a=20 permanent alternative for a management interface.

Regards,=20
Julo

Eddy = Quicksall=20 <eddy_quicksall@ivivity.com>
Sent by:=20 ips-admin@ietf.org

19/09/2003 = 16:04


To
ips@ietf.org=20
cc
 
Subject
[Ips] NOP = during=20 Discovery

 =20


   

=




I have found that at least one initiator is doing a = NOP-out=20 during discovery phase. But the spec says that isn't allowed. Am I=20 misunderstanding something?

 =20

3.3 iSCSI Session Types

  iSCSI defines two types of=20 sessions:

  a) Normal operational session = - an=20 unrestricted session. =

  b) Discovery-session - a = session only=20 opened for target =

     discovery. The = target MUST=20 ONLY accept text requests with the=20

     SendTargets key = and a logout=20 request with reason "close the=20

     session". All = other requests=20 MUST be rejected. =

     The session type = is defined=20 during login with key=3Dvalue parameter in

     the login=20 command.

 =20

 =20

Eddy=20

 =20


***This message has been scanned for virus, = spam, and=20 undesirable content.***
***For further information, contact your = mail=20 administrator.***=20

------_=_NextPart_001_01C386AD.4204F070-- ------=_NextPartTM-000-c5a3936e-e62f-4a48-9ecf-ee85337054f5-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Mon Sep 29 16:47:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11265 for ; Mon, 29 Sep 2003 16:47:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A44vF-0002AC-24 for ips-archive@odin.ietf.org; Mon, 29 Sep 2003 16:47:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8TKl9kS008316 for ips-archive@odin.ietf.org; Mon, 29 Sep 2003 16:47:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A44vE-0002A3-Uz for ips-web-archive@optimus.ietf.org; Mon, 29 Sep 2003 16:47:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11232 for ; Mon, 29 Sep 2003 16:47:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A44vC-0004xZ-00 for ips-web-archive@ietf.org; Mon, 29 Sep 2003 16:47:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A44vC-0004xV-00 for ips-web-archive@ietf.org; Mon, 29 Sep 2003 16:47:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A44v7-00028G-L3; Mon, 29 Sep 2003 16:47:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A44uQ-00022C-Uk for ips@optimus.ietf.org; Mon, 29 Sep 2003 16:46:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11191 for ; Mon, 29 Sep 2003 16:46:10 -0400 (EDT) From: Black_David@emc.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A44uP-0004we-00 for ips@ietf.org; Mon, 29 Sep 2003 16:46:17 -0400 Received: from [168.159.2.31] (helo=mailhub.lss.emc.com) by ietf-mx with esmtp (Exim 4.12) id 1A44uO-0004wa-00 for ips@ietf.org; Mon, 29 Sep 2003 16:46:16 -0400 Received: from mxic1.corp.emc.com (mxic1.corp.emc.com [168.159.129.100]) by mailhub.lss.emc.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id h8TKkEY20429 for ; Mon, 29 Sep 2003 16:46:15 -0400 (EDT) Received: by mxic1.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Mon, 29 Sep 2003 16:46:14 -0400 Message-ID: To: ips@ietf.org Subject: RE: [Ips] Re: iscsi RDMA standard Date: Mon, 29 Sep 2003 16:46:13 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , I just want to make it clear that while iSER has been submitted as internet drafts, no decision has been made on whether to work on standardization in the IETF. Anyone can submit an Internet-Draft to the IETF on almost any relevant topic, and these drafts currently have that "individual submission" status. Thanks, --David (IPS WG co-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: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com] Sent: Monday, September 29, 2003 1:15 PM To: Julian_Satran@il.ibm.com; VDaliraju@sbs.com Cc: eddy_quicksall@ivivity.com; ips@ietf.org; ips-admin@ietf.org Subject: RE: [Ips] Re: iscsi RDMA standard The consortium has finished the work Julian mentioned. The results of the work have been submitted as internet drafts: http://www.ietf.org/internet-drafts/draft-ko-iwarp-iser-00.txt and http://www.ietf.org/internet-drafts/draft-chadalapaka-iwarp-da-00.txt The first is the spec for iSCSI over iSER and the second is the architecture document. Pat -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Sunday, September 28, 2003 10:04 PM To: Vysyaraju Daliraju Cc: Eddy Quicksall; ips@ietf.org; ips-admin@ietf.org Subject: [Ips] Re: iscsi RDMA standard There is an extension to iSCSI called ISER - being worked on by a consortium of companies. Julo Vysyaraju Daliraju 28/09/2003 21:51 ToJulian Satran/Haifa/IBM@IBMIL, Eddy Quicksall ccips@ietf.org, ips-admin@ietf.org Subjectiscsi RDMA standard Hi I am new to RDMA ISCSI. Is there any standars exist for iscsi RDMA. Vysyaraju Dali Raju __________________________________________ Vysyaraju Daliraju, / Sr Systems Software Engineer SBS Technologies, 8371C Central Ave. / Newark, CA 94560 Phone: 510-742-2570 / Fax: -2501 / EMail: VDaliraju@sbs.com -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Saturday, September 20, 2003 1:52 PM To: Eddy Quicksall Cc: ips@ietf.org; ips-admin@ietf.org Subject: RE: [Ips] NOP during Discovery Eddy, I think that they realized that already and are content. NOP is somewhat richer in that in a "storage router" NOP might reach the end-point while SendTargets will probably not. In any case the text is unequivocal about NOP. Julo Eddy Quicksall 20/09/2003 14:12 ToJulian Satran/Haifa/IBM@IBMIL ccips@ietf.org, ips-admin@ietf.org SubjectRE: [Ips] NOP during Discovery Thanks Would it work to just use SendTargets= instead of NOP? If there is a target for the discovery session, it would respond with just the target name. If there are no targets for the discovery session, the target would still respond but with 0 for the DataSegmentLength. If so, can you talk that person into that? Eddy -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Saturday, September 20, 2003 1:52 PM To: Eddy Quicksall Cc: ips@ietf.org; ips-admin@ietf.org Subject: Re: [Ips] NOP during Discovery It is not allowed in discovery - There was a long discussion with one party insisting on having NOP as a way of keeping the discovery session alive. Discovery being only a lightweight location mechanism it was decided that it is not worth having it as a permanent alternative for a management interface. Regards, Julo Eddy Quicksall Sent by: ips-admin@ietf.org 19/09/2003 16:04 Toips@ietf.org cc Subject[Ips] NOP during Discovery I have found that at least one initiator is doing a NOP-out during discovery phase. But the spec says that isn't allowed. Am I misunderstanding something? 3.3 iSCSI Session Types iSCSI defines two types of sessions: a) Normal operational session - an unrestricted session. b) Discovery-session - a session only opened for target discovery. The target MUST ONLY accept text requests with the SendTargets key and a logout request with reason "close the session". All other requests MUST be rejected. The session type is defined during login with key=value parameter in the login command. Eddy ***This message has been scanned for virus, spam, and undesirable content.*** ***For further information, contact your mail administrator.*** _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Mon Sep 29 19:32:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17421 for ; Mon, 29 Sep 2003 19:32:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A47V0-0001aF-Hi for ips-archive@odin.ietf.org; Mon, 29 Sep 2003 19:32:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8TNWEuP006087 for ips-archive@odin.ietf.org; Mon, 29 Sep 2003 19:32:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A47V0-0001a6-By for ips-web-archive@optimus.ietf.org; Mon, 29 Sep 2003 19:32:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17408 for ; Mon, 29 Sep 2003 19:32:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A47Uy-0006df-00 for ips-web-archive@ietf.org; Mon, 29 Sep 2003 19:32:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A47Uy-0006dc-00 for ips-web-archive@ietf.org; Mon, 29 Sep 2003 19:32:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A47Un-0001XE-An; Mon, 29 Sep 2003 19:32:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A47UH-0001We-Dx for ips@optimus.ietf.org; Mon, 29 Sep 2003 19:31:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17397 for ; Mon, 29 Sep 2003 19:31:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A47UF-0006dJ-00 for ips@ietf.org; Mon, 29 Sep 2003 19:31:27 -0400 Received: from mcjekyll.mcdata.com ([144.49.6.25] helo=380GATE01out.mcdata.com) by ietf-mx with esmtp (Exim 4.12) id 1A47UE-0006d8-00 for ips@ietf.org; Mon, 29 Sep 2003 19:31:27 -0400 Received: from 380GATE01.mcdata.com ([172.18.1.72]) by 380GATE01out.mcdata.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 29 Sep 2003 17:30:57 -0600 Received: from ariel.nishansystems.com ([192.100.100.16]) by 380GATE01 with InterScan Messaging Security Suite; Mon, 29 Sep 2003 17:30:57 -0600 Received: by ariel.nishansystems.com with Internet Mail Service (5.5.2653.19) id ; Mon, 29 Sep 2003 16:30:56 -0700 Message-ID: From: Joshua Tseng To: "'dan yo'" , ips@ietf.org Subject: RE: [Ips] iSNS: question on exporting FC Zone DB to iSNS DB Date: Mon, 29 Sep 2003 16:30:54 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C386E1.BA40AC30" X-OriginalArrivalTime: 29 Sep 2003 23:30:57.0736 (UTC) FILETIME=[BC0EDC80:01C386E1] Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , 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_01C386E1.BA40AC30 Content-Type: text/plain Dan, Contact me offline if you want help writing a draft. Regarding your question, in iSNS connectivity between iSCSI devices is established by DD membership. DD membership for an iSCSI device can only be established by iSCSI Name. Portal membership in a DD only indicates the preferred interface for iSCSI sessions, and by itself does not indicate DD membership for any iSCSI device. So the answer is 'no', you cannot establish DD membership by IP subnet. Josh -----Original Message----- From: dan yo [mailto:ipsandude@yahoo.com] Sent: Monday, September 29, 2003 9:37 AM To: Joshua Tseng; ips@ietf.org Subject: RE: [Ips] iSNS: question on exporting FC Zone DB to iSNS DB Joshua, Thanks. Regardinig #2, I would be interested in writing a paper after I have explored more on the interoperability issues in bridging FC zones to iSNS, will definitely need more of your help. I don't believe this qualifies for IETF draft or RFC, but having a more well defined rules in mapping FC zones to iSNS will simplify the job of managing a mixed FC/iSCSI SAN. On a related question, is there a way to specify a IP subnet as an iSCSI Initiator node in a Discovery Domain -- the intent is to allow all the hosts on a subnet to access the targets in the corresponding DD. Regards, Dan Joshua Tseng wrote: Dan, Here are my responses: 1) Yes, as alluded to in the iSNS draft. You understood it well. 2) You are welcome to write a paper or RFC if you desire. I am willing to help you out. 3) Yes. Regards, Josh -----Original Message----- From: dan yo [mailto:ipsandude@yahoo.com] Sent: Sunday, September 28, 2003 10:56 PM To: ips@ietf.org Subject: [Ips] iSNS: question on exporting FC Zone DB to iSNS DB Hi, I would like to get some opinions and thoughts on mapping FC Zone Server DB to iSNS DB in a single or multiple fabrics, mixed protocol SAN switches environment. Based on my understanding of the FC-GS, FC-SW, and the iSNS draft, FC zone objects are mapped to iSNS objects as follow: FC zone maps to iSNS DD (Discovery Domain). FC zone set maps to iSNS DD Set. FC fabric maps to iSNS Network Entity. Assume we have a multi-fabric SAN with mixed FC and iSCSI switches, and FC/iSCSI gateways. We want to create a central iSNS database to store all the devices, where some of the devices are exported from the FC zone DBs, and some are registered from the iSNS capable clients (most likely iSCSI devices). With the central iSNS server, iSNS capable management stations now have a full view of the whole multi-fabric SAN. My questions are: 1. Would iSNS serve well for the above application? 2. When FC Zone DBs are merged or segmented, how the FC Zone DBs are synchronized with the iSNS DB is an implementation issue, but has anybody written any guideline or paper on this? If not, would this subject be a good ietf draft/rfc candidate? 3. Is there any such product on the market from the major SAN switch manufacturers (that exports and maps FC Zone DB to iSNS server)? Thanks, Dan _____ Do you Yahoo!? The New Yahoo! Shopping - with improved product search SPECIAL NOTICE All information transmitted hereby is intended only for the use of the addressee(s) named above and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of confidential and privileged information is prohibited. If the reader of this message is not the intended recipient(s) or the employee or agent responsible for delivering the message to the intended recipient, you are herby notified that you must not read this transmission and that disclosure, copying, printing, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. Anyone who receives confidential and privileged information in error should notify us immediately by telephone and mail the original message to us at the above address and destroy all copies. To the extent any portion of this communication contains public information, no such restrictions apply to that information. (gate01) _____ Do you Yahoo!? The New Yahoo! Shopping - with improved product search ------_=_NextPart_001_01C386E1.BA40AC30 Content-Type: text/html Content-Transfer-Encoding: quoted-printable

Dan,

 

Contact me offline if you want = help writing a = draft.           =             =             =             =   

 

Regarding your question, in iSNS connectivity between iSCSI devices is established by DD = membership.  DD membership for an iSCSI device can only be established by iSCSI = Name.  Portal membership in a DD only indicates the preferred interface for = iSCSI sessions, and by itself does not indicate DD membership for any iSCSI = device.  So the answer is 'no', you cannot establish DD membership by IP subnet.

 

Josh

 

-----Original = Message-----
From: dan yo [mailto:ipsandude@yahoo.com]
Sent: Monday, September = 29, 2003 9:37 AM
To: Joshua Tseng; = ips@ietf.org
Subject: RE: [Ips] iSNS: = question on exporting FC Zone DB to iSNS DB

 

Joshua,

 

Thanks.  =

 

Regardinig = #2, I would be interested in writing a paper after I have explored 

more = on the interoperability issues in bridging FC zones to iSNS, = will

definitely = need more of your help.  I don't believe this qualifies for IETF draft =

or RFC, = but having a more well defined rules in mapping FC zones to = iSNS 

will simplify = the job of managing a mixed FC/iSCSI SAN.

On a related question, is there a way to specify a IP subnet as an iSCSI =

Initiator = node in a Discovery Domain -- the intent is to allow all the hosts =

on a = subnet to access the targets in the corresponding DD.

 

Regards,

Dan


Joshua Tseng <Joshua.Tseng@mcdata.com> wrote:

Dan,

 

Here are my responses:

 

1)       = Yes, as alluded to in the iSNS draft.  You understood = it well.

2)       = You are welcome to write a paper or RFC if you = desire.  I am willing to help you out.

3)       = Yes.

 

Regards,<= /font>

Josh

 

 

 

-----Original = Message-----
From: dan yo [mailto:ipsandude@yahoo.com]
Sent: Sunday, September = 28, 2003 10:56 PM
To: ips@ietf.org
Subject: [Ips] iSNS: = question on exporting FC Zone DB to iSNS DB

 

Hi,

 

I would like = to get some opinions and thoughts on mapping FC Zone = Server DB

to iSNS = DB in a single or multiple fabrics, mixed protocol SAN switches =

environment.

 

Based on my = understanding of the FC-GS, FC-SW, and the iSNS draft, FC zone =

objects are = mapped to iSNS objects as follow:

 

  FC = zone maps to iSNS DD (Discovery Domain).

  FC = zone set maps to iSNS DD Set.

  FC = fabric maps to iSNS Network Entity.

 

Assume we = have a multi-fabric SAN with mixed FC and = iSCSI switches,

and FC/iSCSI = gateways.

We want to = create a central iSNS database to store all the devices,

where some of = the devices are exported from the FC zone DBs, and some =

are = registered from the iSNS capable clients (most likely iSCSI devices).  =

With the = central iSNS server, iSNS capable management stations now

have a full = view of the whole multi-fabric SAN. 

 

My questions = are:

 

1. Would = iSNS serve well for the above application?

2. When FC = Zone DBs are merged or segmented, how the FC Zone DBs

    are synchronized with the iSNS DB is an implementation issue, = but 

    has anybody written any guideline or paper = on this?

    If not, would this subject be a good ietf draft/rfc = candidate?

3. Is there = any such product on the market from the major SAN switch

    manufacturers (that exports and maps FC Zone DB to iSNS = server)?

 

Thanks,

Dan

 

Do you = Yahoo!?
The New Yahoo! Shopping - with improved product = search

SPECIAL NOTICE 
 
All information transmitted hereby is intended only for =
the use of the
addressee(s) named above and may contain confidential =
and privileged
information. Any unauthorized review, use, disclosure or =
distribution
of confidential and privileged information is =
prohibited. If the reader
of this message is not the intended recipient(s) or the =
employee or agent
responsible for delivering the message to the intended =
recipient, you are
herby notified that you must not read this transmission =
and that disclosure,
copying, printing, distribution or use of any of the =
information contained
in or attached to this transmission is STRICTLY =
PROHIBITED.
 
Anyone who receives confidential =
and privileged information in error =
should
notify us immediately by telephone and mail the original =
message to us at
the above address and destroy all copies.  To the =
extent any portion of this
communication contains public information, no such =
restrictions apply to that
information. (gate01)

Do you = Yahoo!?
The New Yahoo! Shopping - with improved product = search

------_=_NextPart_001_01C386E1.BA40AC30-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Tue Sep 30 12:43:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01215 for ; Tue, 30 Sep 2003 12:43:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4Nai-0002Ay-4K for ips-archive@odin.ietf.org; Tue, 30 Sep 2003 12:43:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8UGhCBj008361 for ips-archive@odin.ietf.org; Tue, 30 Sep 2003 12:43:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4Nah-0002Am-Ur for ips-web-archive@optimus.ietf.org; Tue, 30 Sep 2003 12:43:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01204 for ; Tue, 30 Sep 2003 12:43:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4Nag-0001U3-00 for ips-web-archive@ietf.org; Tue, 30 Sep 2003 12:43:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4Naf-0001U0-00 for ips-web-archive@ietf.org; Tue, 30 Sep 2003 12:43:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4NaX-00029b-T1; Tue, 30 Sep 2003 12:43:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4NaS-00029B-EZ for ips@optimus.ietf.org; Tue, 30 Sep 2003 12:42:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01197 for ; Tue, 30 Sep 2003 12:42:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4NaQ-0001Tv-00 for ips@ietf.org; Tue, 30 Sep 2003 12:42:54 -0400 Received: from web20701.mail.yahoo.com ([216.136.226.174]) by ietf-mx with smtp (Exim 4.12) id 1A4NaP-0001Tn-00 for ips@ietf.org; Tue, 30 Sep 2003 12:42:53 -0400 Message-ID: <20030930163831.21130.qmail@web20701.mail.yahoo.com> Received: from [63.121.140.220] by web20701.mail.yahoo.com via HTTP; Tue, 30 Sep 2003 09:38:31 PDT Date: Tue, 30 Sep 2003 09:38:31 -0700 (PDT) From: dan yo Subject: RE: [Ips] iSNS: question on exporting FC Zone DB to iSNS DB To: Joshua Tseng , ips@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-858064149-1064939911=:20851" Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , --0-858064149-1064939911=:20851 Content-Type: text/plain; charset=us-ascii Josh, Base on the same reasoning that iSNS doesn't support the use of IP subnet as an initiator node in a DD, it doesn't support the (Domain_ID,Port_Number) construct in a FC zone, correct? Thanks, Dan Joshua Tseng wrote: Dan, Contact me offline if you want help writing a draft. Regarding your question, in iSNS connectivity between iSCSI devices is established by DD membership. DD membership for an iSCSI device can only be established by iSCSI Name. Portal membership in a DD only indicates the preferred interface for iSCSI sessions, and by itself does not indicate DD membership for any iSCSI device. So the answer is 'no', you cannot establish DD membership by IP subnet. Josh -----Original Message----- From: dan yo [mailto:ipsandude@yahoo.com] Sent: Monday, September 29, 2003 9:37 AM To: Joshua Tseng; ips@ietf.org Subject: RE: [Ips] iSNS: question on exporting FC Zone DB to iSNS DB Joshua, Thanks. Regardinig #2, I would be interested in writing a paper after I have explored more on the interoperability issues in bridging FC zones to iSNS, will definitely need more of your help. I don't believe this qualifies for IETF draft or RFC, but having a more well defined rules in mapping FC zones to iSNS will simplify the job of managing a mixed FC/iSCSI SAN. On a related question, is there a way to specify a IP subnet as an iSCSI Initiator node in a Discovery Domain -- the intent is to allow all the hosts on a subnet to access the targets in the corresponding DD. Regards, Dan Joshua Tseng wrote: Dan, Here are my responses: 1) Yes, as alluded to in the iSNS draft. You understood it well. 2) You are welcome to write a paper or RFC if you desire. I am willing to help you out. 3) Yes. Regards, Josh -----Original Message----- From: dan yo [mailto:ipsandude@yahoo.com] Sent: Sunday, September 28, 2003 10:56 PM To: ips@ietf.org Subject: [Ips] iSNS: question on exporting FC Zone DB to iSNS DB Hi, I would like to get some opinions and thoughts on mapping FC Zone Server DB to iSNS DB in a single or multiple fabrics, mixed protocol SAN switches environment. Based on my understanding of the FC-GS, FC-SW, and the iSNS draft, FC zone objects are mapped to iSNS objects as follow: FC zone maps to iSNS DD (Discovery Domain). FC zone set maps to iSNS DD Set. FC fabric maps to iSNS Network Entity. Assume we have a multi-fabric SAN with mixed FC and iSCSI switches, and FC/iSCSI gateways. We want to create a central iSNS database to store all the devices, where some of the devices are exported from the FC zone DBs, and some are registered from the iSNS capable clients (most likely iSCSI devices). With the central iSNS server, iSNS capable management stations now have a full view of the whole multi-fabric SAN. My questions are: 1. Would iSNS serve well for the above application? 2. When FC Zone DBs are merged or segmented, how the FC Zone DBs are synchronized with the iSNS DB is an implementation issue, but has anybody written any guideline or paper on this? If not, would this subject be a good ietf draft/rfc candidate? 3. Is there any such product on the market from the major SAN switch manufacturers (that exports and maps FC Zone DB to iSNS server)? Thanks, Dan --------------------------------- Do you Yahoo!? The New Yahoo! Shopping - with improved product search SPECIAL NOTICE All information transmitted hereby is intended only for the use of the addressee(s) named above and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of confidential and privileged information is prohibited. If the reader of this message is not the intended recipient(s) or the employee or agent responsible for delivering the message to the intended recipient, you are herby notified that you must not read this transmission and that disclosure, copying, printing, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. Anyone who receives confidential and privileged information in error should notify us immediately by telephone and mail the original message to us at the above address and destroy all copies. To the extent any portion of this communication contains public information, no such restrictions apply to that information. (gate01) --------------------------------- Do you Yahoo!? The New Yahoo! Shopping - with improved product search --------------------------------- Do you Yahoo!? The New Yahoo! Shopping - with improved product search --0-858064149-1064939911=:20851 Content-Type: text/html; charset=us-ascii
Josh,
 
Base on the same reasoning that iSNS doesn't support the use of IP subnet
as an initiator node in a DD, it doesn't support the (Domain_ID,Port_Number)
construct in a FC zone, correct? 
 
Thanks,
Dan

Joshua Tseng <Joshua.Tseng@mcdata.com> wrote:

Dan,

 

Contact me offline if you want help writing a draft.                                                 

 

Regarding your question, in iSNS connectivity between iSCSI devices is established by DD membership.  DD membership for an iSCSI device can only be established by iSCSI Name.  Portal membership in a DD only indicates the preferred interface for iSCSI sessions, and by itself does not indicate DD membership for any iSCSI device.  So the answer is 'no', you cannot establish DD membership by IP subnet.

 

Josh

 

-----Original Message-----
From: dan yo [mailto:ipsandude@yahoo.com]
Sent: Monday, September 29, 2003 9:37 AM
To: Joshua Tseng; ips@ietf.org
Subject: RE: [Ips] iSNS: question on exporting FC Zone DB to iSNS DB

 

Joshua,

 

Thanks. 

 

Regardinig #2, I would be interested in writing a paper after I have explored 

more on the interoperability issues in bridging FC zones to iSNS, will

definitely need more of your help.  I don't believe this qualifies for IETF draft

or RFC, but having a more well defined rules in mapping FC zones to iSNS 

will simplify the job of managing a mixed FC/iSCSI SAN.

On a related question, is there a way to specify a IP subnet as an iSCSI

Initiator node in a Discovery Domain -- the intent is to allow all the hosts

on a subnet to access the targets in the corresponding DD.

 

Regards,

Dan


Joshua Tseng <Joshua.Tseng@mcdata.com> wrote:

Dan,

 

Here are my responses:

 

1)       Yes, as alluded to in the iSNS draft.  You understood it well.

2)       You are welcome to write a paper or RFC if you desire.  I am willing to help you out.

3)       Yes.

 

Regards,

Josh

 

 

 

-----Original Message-----
From: dan yo [mailto:ipsandude@yahoo.com]
Sent: Sunday, September 28, 2003 10:56 PM
To: ips@ietf.org
Subject: [Ips] iSNS: question on exporting FC Zone DB to iSNS DB

 

Hi,

 

I would like to get some opinions and thoughts on mapping FC Zone Server DB

to iSNS DB in a single or multiple fabrics, mixed protocol SAN switches

environment.

 

Based on my understanding of the FC-GS, FC-SW, and the iSNS draft, FC zone

objects are mapped to iSNS objects as follow:

 

  FC zone maps to iSNS DD (Discovery Domain).

  FC zone set maps to iSNS DD Set.

  FC fabric maps to iSNS Network Entity.

 

Assume we have a multi-fabric SAN with mixed FC and iSCSI switches,

and FC/iSCSI gateways.

We want to create a central iSNS database to store all the devices,

where some of the devices are exported from the FC zone DBs, and some

are registered from the iSNS capable clients (most likely iSCSI devices). 

With the central iSNS server, iSNS capable management stations now

have a full view of the whole multi-fabric SAN. 

 

My questions are:

 

1. Would iSNS serve well for the above application?

2. When FC Zone DBs are merged or segmented, how the FC Zone DBs

    are synchronized with the iSNS DB is an implementation issue, but 

    has anybody written any guideline or paper on this?

    If not, would this subject be a good ietf draft/rfc candidate?

3. Is there any such product on the market from the major SAN switch

    manufacturers (that exports and maps FC Zone DB to iSNS server)?

 

Thanks,

Dan

 

Do you Yahoo!?
The New Yahoo! Shopping - with improved product search

SPECIAL NOTICE 
 
All information transmitted hereby is intended only for the use of the
addressee(s) named above and may contain confidential and privileged
information. Any unauthorized review, use, disclosure or distribution
of confidential and privileged information is prohibited. If the reader
of this message is not the intended recipient(s) or the employee or agent
responsible for delivering the message to the intended recipient, you are
herby notified that you must not read this transmission and that disclosure,
copying, printing, distribution or use of any of the information contained
in or attached to !
 this
 transmission is STRICTLY PROHIBITED.
 
Anyone who receives confidential and privileged information in error should
notify us immediately by telephone and mail the original message to us at
the above address and destroy all copies.  To the extent any portion of this
communication contains public information, no such restrictions apply to that
information. (gate01)

Do you Yahoo!?
The New Yahoo! Shopping - with improved product search

Do you Yahoo!?
The New Yahoo! Shopping - with improved product search --0-858064149-1064939911=:20851-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Tue Sep 30 14:43:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06736 for ; Tue, 30 Sep 2003 14:43:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4PSm-0001rD-Fs for ips-archive@odin.ietf.org; Tue, 30 Sep 2003 14:43:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8UIh8r8007133 for ips-archive@odin.ietf.org; Tue, 30 Sep 2003 14:43:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4PSm-0001qp-AD for ips-web-archive@optimus.ietf.org; Tue, 30 Sep 2003 14:43:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06724 for ; Tue, 30 Sep 2003 14:42:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4PSj-0002wY-00 for ips-web-archive@ietf.org; Tue, 30 Sep 2003 14:43:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4PSj-0002wS-00 for ips-web-archive@ietf.org; Tue, 30 Sep 2003 14:43:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4PSg-0001o7-JA; Tue, 30 Sep 2003 14:43:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4PSd-0001mr-R2 for ips@optimus.ietf.org; Tue, 30 Sep 2003 14:42:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06714 for ; Tue, 30 Sep 2003 14:42:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4PSb-0002wJ-00 for ips@ietf.org; Tue, 30 Sep 2003 14:42:57 -0400 Received: from mxic2.corp.emc.com ([128.221.31.40]) by ietf-mx with esmtp (Exim 4.12) id 1A4PSa-0002vU-00 for ips@ietf.org; Tue, 30 Sep 2003 14:42:56 -0400 Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Tue, 30 Sep 2003 14:42:09 -0400 Message-ID: From: "Black, David" To: "'ips@ietf.org'" Date: Tue, 30 Sep 2003 14:42:14 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C38782.90F046F0" Subject: [Ips] FW: SendTargets Response Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , 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_01C38782.90F046F0 Content-Type: text/plain The official IPS WG mailing list has moved to ietf.org. The IPS WG chairs are trying to get the CMU list shut down, but please DO NOT USE IT! Thanks, --David -----Original Message----- From: Jacob_Cherian@Dell.com [mailto:Jacob_Cherian@Dell.com] Sent: Tuesday, September 30, 2003 2:07 PM To: ips@ece.cmu.edu Subject: SendTargets Response What is the valid response for SendTargets if the network entity has no targets to send. I -> T "SendTargets=ALL" T->I "TargetName=" Is this valid ?? Thanks, Jacob Cherian PowerVault NAS Engineering Dell Inc. Ph: (512) 723 3247 ------_=_NextPart_001_01C38782.90F046F0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Message
The official=20 IPS WG mailing list has moved to ietf.org.  The=20 IPS
WG=20 chairs are trying to get the CMU list shut down, = but please=20 DO
NOT USE=20 IT!
 
Thanks,
--David
 
-----Original Message-----
From: = Jacob_Cherian@Dell.com=20 [mailto:Jacob_Cherian@Dell.com]
Sent: Tuesday, September 30, = 2003=20 2:07 PM
To: ips@ece.cmu.edu
Subject: SendTargets=20 Response

What=20 is the valid response for SendTargets if the network entity has no = targets to=20 send.
 
I=20 -> T        =20 "SendTargets=3DALL"
T->I         &n= bsp; "TargetName=3D"        = ;       =20 Is this valid ??=20

Thanks, =

Jacob=20 Cherian
PowerVault NAS Engineering =
Dell=20 Inc.
Ph: (512) 723 3247=20

 
 
------_=_NextPart_001_01C38782.90F046F0-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Tue Sep 30 14:43:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06742 for ; Tue, 30 Sep 2003 14:43:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4PSm-0001qi-5g for ips-archive@odin.ietf.org; Tue, 30 Sep 2003 14:43:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8UIh8jE007101 for ips-archive@odin.ietf.org; Tue, 30 Sep 2003 14:43:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4PSl-0001qS-VS for ips-web-archive@optimus.ietf.org; Tue, 30 Sep 2003 14:43:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06718 for ; Tue, 30 Sep 2003 14:42:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4PSj-0002wR-00 for ips-web-archive@ietf.org; Tue, 30 Sep 2003 14:43:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4PSi-0002wN-00 for ips-web-archive@ietf.org; Tue, 30 Sep 2003 14:43:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4PSf-0001n4-0C; Tue, 30 Sep 2003 14:43:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4PRh-0001lN-9l for ips@optimus.ietf.org; Tue, 30 Sep 2003 14:42:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06677 for ; Tue, 30 Sep 2003 14:41:52 -0400 (EDT) From: Jacob_Cherian@Dell.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4PRe-0002v6-00 for ips@ietf.org; Tue, 30 Sep 2003 14:41:58 -0400 Received: from ausadmmsrr501.aus.amer.dell.com ([143.166.83.88]) by ietf-mx with smtp (Exim 4.12) id 1A4PRe-0002uo-00 for ips@ietf.org; Tue, 30 Sep 2003 14:41:58 -0400 Received: from 143.166.3.50 by AUSADMMSRR501.aus.amer.dell.com with ESMTP (Tumbleweed MMS SMTP Relay (MMS v4.7);); Tue, 30 Sep 2003 13:41: 15 -0500 X-Server-Uuid: ff595059-9672-488a-bf38-b4dee96ef25b Received: by AUSXICPS307.aus.amer.dell.com with Internet Mail Service ( 5.5.2653.19) id ; Tue, 30 Sep 2003 13:41:15 -0500 Message-ID: To: ips@ietf.org Date: Tue, 30 Sep 2003 13:41:05 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 136711C1757703-01-01 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C38782.41A5267E" Subject: [Ips] RE: SendTargets Response Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , 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_01C38782.41A5267E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit What is the valid response for SendTargets if the network entity has no targets to send. I -> T "SendTargets=ALL" T -> I "TargetName=" // Is this valid ?? Thanks, Jacob Cherian Dell Inc. Ph: (512) 723 3247 ------_=_NextPart_001_01C38782.41A5267E Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message
What=20 is the valid response for SendTargets if the network entity has no = targets to=20 send.
 
I  =20  ->  =20  T        =20 "SendTargets=3DALL"
T  =  -> =20 =  I         &nbs= p; "TargetName=3D"        &= nbsp;        //  Is this valid ??

Thanks,

Jacob Cherian
Dell Inc. =
Ph: = (512) 723=20 3247

 
 
------_=_NextPart_001_01C38782.41A5267E-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Tue Sep 30 14:47:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07123 for ; Tue, 30 Sep 2003 14:47:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4PWj-0002lD-V7 for ips-archive@odin.ietf.org; Tue, 30 Sep 2003 14:47:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8UIlDXT010605 for ips-archive@odin.ietf.org; Tue, 30 Sep 2003 14:47:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4PWj-0002hm-CV for ips-web-archive@optimus.ietf.org; Tue, 30 Sep 2003 14:47:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07053 for ; Tue, 30 Sep 2003 14:47:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4PWg-00032C-00 for ips-web-archive@ietf.org; Tue, 30 Sep 2003 14:47:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4PWg-000329-00 for ips-web-archive@ietf.org; Tue, 30 Sep 2003 14:47:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4PWW-0002b9-HW; Tue, 30 Sep 2003 14:47:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4PW3-0002ZB-AP for ips@optimus.ietf.org; Tue, 30 Sep 2003 14:46:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07017 for ; Tue, 30 Sep 2003 14:46:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4PW0-00031E-00 for ips@ietf.org; Tue, 30 Sep 2003 14:46:28 -0400 Received: from dmz1.silverbacksystems.com ([65.172.158.82]) by ietf-mx with esmtp (Exim 4.12) id 1A4PVv-00030f-00 for ips@ietf.org; Tue, 30 Sep 2003 14:46:23 -0400 Received: from ns.silverbacksystems.com (gate-camp-hme0.silverbacksystems.com [65.172.158.93]) by dmz1.silverbacksystems.com (Postfix on SuSE Linux 7.3 (i386)) with ESMTP id 4AC8DF688; Tue, 30 Sep 2003 11:45:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ns.silverbacksystems.com (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 80E96A580; Tue, 30 Sep 2003 11:46:23 -0700 (PDT) Received: from ns.silverbacksystems.com (localhost [127.0.0.1]) by localhost (AvMailGate-2.0.1.6) id 03780-2DD4306D; Tue, 30 Sep 2003 11:46:23 -0700 Received: from carlos.silverbacksystems.com (carlos.corp.silverbacksystems.com [10.0.16.197]) by ns.silverbacksystems.com (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id D9D04A580; Tue, 30 Sep 2003 11:46:22 -0700 (PDT) Message-Id: <6.0.0.22.2.20030930114002.026da020@pop.silverbacksystems.com> X-Sender: crimola@pop.silverbacksystems.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Tue, 30 Sep 2003 11:45:38 -0700 To: ips@ietf.org From: Carlos Rimola Cc: Jacob_Cherian@Dell.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiVirus: checked by AntiVir MailGate (version: 2.0.1.6; AVE: 6.21.0.1; VDF: 6.21.0.56; host: ns.silverbacksystems.com) Subject: [Ips] Re: SendTargets Response Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , For the benefit of others - I got 2 pieces of feedback on my response: 1) the new list address to use for iSCSI is ips@ietf.org - ips@ece.cmu.edu has been discontinued (Marjorie Krueger @ HP) 2) do not use HTML but plain text in your replies (MIchael Brown @ EMC) Having said that, here is the original message and reply: ----- begin included message ----- My understanding is that the proper response is an empty PDU payload - in other words, the DataSegmentLength field in the response header is 0. This is the way we operate and how I have seen other targets operate. Carlos Rimola Silverback Systems At 11:07 AM 9/30/2003, Jacob_Cherian@Dell.com wrote: >What is the valid response for SendTargets if the network entity has no >targets to send. > >I -> T "SendTargets=ALL" >T->I "TargetName=" Is this valid ?? > >Thanks, > >Jacob Cherian >PowerVault NAS Engineering >Dell Inc. >Ph: (512) 723 3247 > > ----- end included message ----- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Tue Sep 30 14:58:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07882 for ; Tue, 30 Sep 2003 14:58:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4PhF-0003oU-0n for ips-archive@odin.ietf.org; Tue, 30 Sep 2003 14:58:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8UIw4kT014652 for ips-archive@odin.ietf.org; Tue, 30 Sep 2003 14:58:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4PhE-0003oF-T6 for ips-web-archive@optimus.ietf.org; Tue, 30 Sep 2003 14:58:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07849 for ; Tue, 30 Sep 2003 14:57:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4PhC-0003H0-00 for ips-web-archive@ietf.org; Tue, 30 Sep 2003 14:58:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4PhB-0003Gx-00 for ips-web-archive@ietf.org; Tue, 30 Sep 2003 14:58:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4PhB-0003nH-Hd; Tue, 30 Sep 2003 14:58:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4PgD-0003mu-If for ips@optimus.ietf.org; Tue, 30 Sep 2003 14:57:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07711 for ; Tue, 30 Sep 2003 14:56:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4PgA-0003EI-00 for ips@ietf.org; Tue, 30 Sep 2003 14:56:58 -0400 Received: from d12lmsgate-2.de.ibm.com ([194.196.100.235] helo=d12lmsgate.de.ibm.com) by ietf-mx with esmtp (Exim 4.12) id 1A4Pg9-0003D6-00 for ips@ietf.org; Tue, 30 Sep 2003 14:56:57 -0400 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196]) by d12lmsgate.de.ibm.com (8.12.10/8.12.8) with ESMTP id h8UIuLoS182492 for ; Tue, 30 Sep 2003 20:56:21 +0200 Received: from d10ml001.telaviv.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12relay02.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h8UIuKhU250820 for ; Tue, 30 Sep 2003 20:56:20 +0200 To: ips@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF2 July 23, 2003 From: "Julian Satran" Message-ID: Date: Tue, 30 Sep 2003 21:56:17 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 30/09/2003 21:56:21, Serialize complete at 30/09/2003 21:56:21 Content-Type: multipart/alternative; boundary="=_alternative 0068D687C2256DB1_=" Subject: [Ips] [iscsi} Send Target Response Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , This is a multipart message in MIME format. --=_alternative 0068D687C2256DB1_= Content-Type: text/plain; charset="US-ASCII" Jacob, David has the right answer (and you the wrong one). See page 216 fifth paragraph. Julo ----- Forwarded by Julian Satran/Haifa/IBM on 30/09/2003 22:02 ----- Black_David@emc.com Sent by: ips-admin@ietf.org 30/09/2003 21:42 To ips@ietf.org cc Subject [Ips] FW: SendTargets Response -----Original Message----- From: Carlos Rimola [mailto:crimola@silverbacksystems.com] Sent: Tuesday, September 30, 2003 2:22 PM To: Jacob_Cherian@Dell.com; ips@ece.cmu.edu Subject: Re: SendTargets Response My understanding is that the proper response is an empty PDU payload - in other words, the DataSegmentLength field in the response header is 0. This is the way we operate and how I have seen other targets operate. Carlos Rimola Silverback Systems At 11:07 AM 9/30/2003, Jacob_Cherian@Dell.com wrote: What is the valid response for SendTargets if the network entity has no targets to send. I -> T "SendTargets=ALL" T->I "TargetName=" Is this valid ?? Thanks, Jacob Cherian PowerVault NAS Engineering Dell Inc. Ph: (512) 723 3247 ----- Forwarded by Julian Satran/Haifa/IBM on 30/09/2003 22:02 ----- Jacob_Cherian@Dell.com Sent by: ips-admin@ietf.org 30/09/2003 21:41 To ips@ietf.org cc Subject [Ips] RE: SendTargets Response What is the valid response for SendTargets if the network entity has no targets to send. I -> T "SendTargets=ALL" T -> I "TargetName=" // Is this valid ?? Thanks, Jacob Cherian Dell Inc. Ph: (512) 723 3247 --=_alternative 0068D687C2256DB1_= Content-Type: text/html; charset="US-ASCII"
Jacob,

David has the right answer (and you the wrong one). See page 216 fifth paragraph.


Julo
----- Forwarded by Julian Satran/Haifa/IBM on 30/09/2003 22:02 -----
Black_David@emc.com
Sent by: ips-admin@ietf.org

30/09/2003 21:42

To
ips@ietf.org
cc
Subject
[Ips] FW: SendTargets Response





 
-----Original Message-----
From: Carlos Rimola [mailto:crimola@silverbacksystems.com]
Sent: Tuesday, September 30, 2003 2:22 PM
To: Jacob_Cherian@Dell.com; ips@ece.cmu.edu
Subject: Re: SendTargets Response
My understanding is that the proper response is an empty PDU payload - in other words, the DataSegmentLength field in the response header is 0.  This is the way we operate and how I have seen other targets operate.

Carlos Rimola
Silverback Systems

At 11:07 AM 9/30/2003, Jacob_Cherian@Dell.com wrote:
What is the valid response for SendTargets if the network entity has no targets to send.

I -> T         "SendTargets=ALL"
T->I           "TargetName="                Is this valid ??

Thanks,

Jacob Cherian
PowerVault NAS Engineering
Dell Inc.
Ph: (512) 723 3247



----- Forwarded by Julian Satran/Haifa/IBM on 30/09/2003 22:02 -----
Jacob_Cherian@Dell.com
Sent by: ips-admin@ietf.org

30/09/2003 21:41

To
ips@ietf.org
cc
Subject
[Ips] RE: SendTargets Response





What is the valid response for SendTargets if the network entity has no targets to send.
 
I    ->    T         "SendTargets=ALL"
T   ->   I           "TargetName="                 //  Is this valid ??

Thanks,

Jacob Cherian
Dell Inc.
Ph: (512) 723 3247

 
  --=_alternative 0068D687C2256DB1_=-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Tue Sep 30 15:09:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09077 for ; Tue, 30 Sep 2003 15:09:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4Prt-0005Lw-T2 for ips-archive@odin.ietf.org; Tue, 30 Sep 2003 15:09:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8UJ95jD020570 for ips-archive@odin.ietf.org; Tue, 30 Sep 2003 15:09:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4Prt-0005Lh-NL for ips-web-archive@optimus.ietf.org; Tue, 30 Sep 2003 15:09:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09011 for ; Tue, 30 Sep 2003 15:08:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4Prq-0003Sn-00 for ips-web-archive@ietf.org; Tue, 30 Sep 2003 15:09:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4Prq-0003Sk-00 for ips-web-archive@ietf.org; Tue, 30 Sep 2003 15:09:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4Prp-0005IM-P4; Tue, 30 Sep 2003 15:09:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4PrQ-0005FS-Sc for ips@optimus.ietf.org; Tue, 30 Sep 2003 15:08:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08941 for ; Tue, 30 Sep 2003 15:08:27 -0400 (EDT) From: Black_David@emc.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4PrN-0003SW-00 for ips@ietf.org; Tue, 30 Sep 2003 15:08:33 -0400 Received: from [168.159.2.31] (helo=mailhub.lss.emc.com) by ietf-mx with esmtp (Exim 4.12) id 1A4PrN-0003ST-00 for ips@ietf.org; Tue, 30 Sep 2003 15:08:33 -0400 Received: from mxic1.corp.emc.com (mxic1.corp.emc.com [168.159.129.100]) by mailhub.lss.emc.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id h8UJ8Vu23300 for ; Tue, 30 Sep 2003 15:08:31 -0400 (EDT) Received: by mxic1.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Tue, 30 Sep 2003 15:08:31 -0400 Message-ID: To: ips@ietf.org Date: Tue, 30 Sep 2003 15:08:30 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Ips] HTML email Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , Regarding the following request: > 2) do not use HTML but plain text in your replies (MIchael Brown @ EMC) I guess people can make that request, as not every mail reader copes well with HTML, but I don't think it's appropriate to ban it from this list - it's been used without major issue here for a while. It would be a courtesy for people to set their mailers to default to plain text (e.g., mine is set that way, hence this message), but I see no cause to ban or actively discourage it on this list. OTOH, don't even think about sending Rich Text Format email to this list. Thanks, --David (IPS WG co-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 ---------------------------------------------------- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Tue Sep 30 15:31:53 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06737 for ; Tue, 30 Sep 2003 14:43:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4PSm-0001qy-Bk for ips-archive@odin.ietf.org; Tue, 30 Sep 2003 14:43:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8UIh8tO007117 for ips-archive@odin.ietf.org; Tue, 30 Sep 2003 14:43:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4PSm-0001qZ-5C for ips-web-archive@optimus.ietf.org; Tue, 30 Sep 2003 14:43:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06720 for ; Tue, 30 Sep 2003 14:42:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4PSj-0002wV-00 for ips-web-archive@ietf.org; Tue, 30 Sep 2003 14:43:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4PSi-0002wO-00 for ips-web-archive@ietf.org; Tue, 30 Sep 2003 14:43:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4PSf-0001nE-Om; Tue, 30 Sep 2003 14:43:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4PSB-0001lk-C3 for ips@optimus.ietf.org; Tue, 30 Sep 2003 14:42:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06695 for ; Tue, 30 Sep 2003 14:42:22 -0400 (EDT) From: Black_David@emc.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4PS8-0002vY-00 for ips@ietf.org; Tue, 30 Sep 2003 14:42:28 -0400 Received: from [168.159.2.31] (helo=mailhub.lss.emc.com) by ietf-mx with esmtp (Exim 4.12) id 1A4PS8-0002vV-00 for ips@ietf.org; Tue, 30 Sep 2003 14:42:28 -0400 Received: from mxic1.corp.emc.com (mxic1.corp.emc.com [168.159.129.100]) by mailhub.lss.emc.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id h8UIgQu22941 for ; Tue, 30 Sep 2003 14:42:26 -0400 (EDT) Received: by mxic1.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Tue, 30 Sep 2003 14:42:25 -0400 Message-ID: To: ips@ietf.org Date: Tue, 30 Sep 2003 14:42:22 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C38782.960D2D10" Subject: [Ips] FW: SendTargets Response Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , 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_01C38782.960D2D10 Content-Type: text/plain -----Original Message----- From: Carlos Rimola [mailto:crimola@silverbacksystems.com] Sent: Tuesday, September 30, 2003 2:22 PM To: Jacob_Cherian@Dell.com; ips@ece.cmu.edu Subject: Re: SendTargets Response My understanding is that the proper response is an empty PDU payload - in other words, the DataSegmentLength field in the response header is 0. This is the way we operate and how I have seen other targets operate. Carlos Rimola Silverback Systems At 11:07 AM 9/30/2003, Jacob_Cherian@Dell.com wrote: What is the valid response for SendTargets if the network entity has no targets to send. I -> T "SendTargets=ALL" T->I "TargetName=" Is this valid ?? Thanks, Jacob Cherian PowerVault NAS Engineering Dell Inc. Ph: (512) 723 3247 ------_=_NextPart_001_01C38782.960D2D10 Content-Type: text/html Message

 
-----Original Message-----
From: Carlos Rimola [mailto:crimola@silverbacksystems.com]
Sent: Tuesday, September 30, 2003 2:22 PM
To: Jacob_Cherian@Dell.com; ips@ece.cmu.edu
Subject: Re: SendTargets Response

My understanding is that the proper response is an empty PDU payload - in other words, the DataSegmentLength field in the response header is 0.  This is the way we operate and how I have seen other targets operate.

Carlos Rimola
Silverback Systems

At 11:07 AM 9/30/2003, Jacob_Cherian@Dell.com wrote:
What is the valid response for SendTargets if the network entity has no targets to send.
 
I -> T         "SendTargets=ALL"
T->I           "TargetName="                Is this valid ??

Thanks,

Jacob Cherian
PowerVault NAS Engineering
Dell Inc.
Ph: (512) 723 3247
 
 

------_=_NextPart_001_01C38782.960D2D10-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Tue Sep 30 15:46:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11800 for ; Tue, 30 Sep 2003 15:46:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4QRp-00014I-IH for ips-archive@odin.ietf.org; Tue, 30 Sep 2003 15:46:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8UJkDxi004105 for ips-archive@odin.ietf.org; Tue, 30 Sep 2003 15:46:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4QRp-000148-Df for ips-web-archive@optimus.ietf.org; Tue, 30 Sep 2003 15:46:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11751 for ; Tue, 30 Sep 2003 15:46:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4QRn-0003z7-00 for ips-web-archive@ietf.org; Tue, 30 Sep 2003 15:46:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4QRn-0003z4-00 for ips-web-archive@ietf.org; Tue, 30 Sep 2003 15:46:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4QRe-00011F-UR; Tue, 30 Sep 2003 15:46:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4QRJ-000104-Dn for ips@optimus.ietf.org; Tue, 30 Sep 2003 15:45:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11724 for ; Tue, 30 Sep 2003 15:45:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4QRH-0003yL-00 for ips@ietf.org; Tue, 30 Sep 2003 15:45:40 -0400 Received: from [66.155.203.134] (helo=sadr.equallogic.com) by ietf-mx with smtp (Exim 4.12) id 1A4QRH-0003xp-00 for ips@ietf.org; Tue, 30 Sep 2003 15:45:39 -0400 Received: from sadr.equallogic.com (localhost.localdomain [127.0.0.1]) by sadr.equallogic.com (8.12.8/8.12.8) with ESMTP id h8UJj54h011301 for ; Tue, 30 Sep 2003 15:45:05 -0400 Received: from deneb.dev.equallogic.com (deneb [172.16.1.99]) by sadr.equallogic.com (8.12.8/8.12.8) with ESMTP id h8UJj4ZA011296; Tue, 30 Sep 2003 15:45:04 -0400 Received: from localhost.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.6) with ESMTP id h8UJj4A20089; Tue, 30 Sep 2003 15:45:04 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16249.56640.64196.991072@gargle.gargle.HOWL> Date: Tue, 30 Sep 2003 15:45:04 -0400 From: Paul Koning To: Black_David@emc.com Cc: ips@ietf.org Subject: Re: [Ips] HTML email References: X-Mailer: VM 7.07 under 21.4 (patch 8) "Honest Recruiter" XEmacs Lucid Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit >>>>> "Black" == Black David writes: Black> Regarding the following request: >> 2) do not use HTML but plain text in your replies (MIchael Brown @ >> EMC) Black> I guess people can make that request, as not every mail reader Black> copes well with HTML, but I don't think it's appropriate to Black> ban it from this list - it's been used without major issue Black> here for a while. It would be a courtesy for people to set Black> their mailers to default to plain text (e.g., mine is set that Black> way, hence this message), but I see no cause to ban or Black> actively discourage it on this list. I feel differently. At one time I had HTML enabled in my mail reader. I changed it so that it refuses to interpret "HTML". I ran into too many mail messages created by certain mailers from certain vendors that produce grossly proprietary weird syntax and pretend it is HTML. Such messages produce ugly garbage, consume excessive CPU time in the mail reader, or otherwise create a nuisance. So for this reason my mail reader now always uses the plaintext flavor of the message if it is available. If a mail message ONLY offers an HTML form, it is usually spam. On the rare occasions when it isn't, I may try to look at it but I would really prefer not to. As far as I can see, there is NO reason for sending HTML to lists such as this one, and many reasons (including, for example, effective operation of the archiver system) to avoid it. paul _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips