iSNS DevGetNext question

From krs0@att.com Mon Mar 3 04:20:52 2008 Return-Path: X-Original-To: ietfarch-ips-archive@core3.amsl.com Delivered-To: ietfarch-ips-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C33928C57A for ; Mon, 3 Mar 2008 04:20:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -39.547 X-Spam-Level: X-Spam-Status: No, score=-39.547 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DOS_OE_TO_MX=2.75, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, GB_ROLEX=5, HTML_MESSAGE=1, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eun+K28TKKtp for ; Mon, 3 Mar 2008 04:20:40 -0800 (PST) Received: from host-88-155-220-24.midco.net (host-88-155-220-24.midco.net [24.220.155.88]) by core3.amsl.com (Postfix) with ESMTP id 0744B28C56D for ; Mon, 3 Mar 2008 04:20:39 -0800 (PST) Message-ID: <000a01c87d28$076049d8$7fc6a883@mvripw> From: "ephrem haley" To: Subject: Breitling Date: Mon, 03 Mar 2008 10:33:01 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C87D28.075B6BE9" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C87D28.075B6BE9 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Prestige replicas Most popular watches Rolex Datejusts=95Rolex Sports Models=95Cartier=95Hublot=95Panerai = =95Chanel=95Jacob & Co=95Patek=95Philippe Alain = Silberstein=95Chopard=95Jaeger=95LeCoutrePorsche=95Design =20 Most popular TIFFANY & CO. JEWERLY Tiffany & CO Bracelets=95Tiffany & CO = Necklace=95Tiffany & CO Earings Most popular PENS Mont Blanc Ballpoint=95Louis Vuitton Rollerball=95St Dupont = Fountain=95Mont Blanc Rollerball=95Gucci Roller=95St Dupont = Ballpoint=95Louis Vuitton Ballpoint=95St Dupont Roller Click here =20 ------=_NextPart_000_0007_01C87D28.075B6BE9 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Prestige
replicas

Most popular=20 watches

Rolex Datejusts=95Rolex Sports = Models=95Cartier=95Hublot=95Panerai =95Chanel=95Jacob &=20 Co=95Patek=95Philippe Alain = Silberstein=95Chopard=95Jaeger=95LeCoutrePorsche=95Design=20

Most popular = TIFFANY & CO.=20 JEWERLY

Tiffany & CO=20 Bracelets=95Tiffany & CO Necklace=95Tiffany & CO = Earings

Most popular = PENS

Mont Blanc=20 Ballpoint=95Louis Vuitton Rollerball=95St Dupont Fountain=95Mont = Blanc=20 Rollerball=95Gucci Roller=95St Dupont Ballpoint=95Louis Vuitton = Ballpoint=95St=20 Dupont Roller

Click here=20

------=_NextPart_000_0007_01C87D28.075B6BE9-- From ips-bounces@ietf.org Wed Mar 5 15:54:01 2008 Return-Path: X-Original-To: ietfarch-ips-archive@core3.amsl.com Delivered-To: ietfarch-ips-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B708E28C709; Wed, 5 Mar 2008 15:54:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.462 X-Spam-Level: X-Spam-Status: No, score=-101.462 tagged_above=-999 required=5 tests=[AWL=-1.025, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z4-BnEZoYoJB; Wed, 5 Mar 2008 15:53:59 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32B1528C2F0; Wed, 5 Mar 2008 15:53:30 -0800 (PST) X-Original-To: ips@core3.amsl.com Delivered-To: ips@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8932228C2F0 for ; Wed, 5 Mar 2008 15:53:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nL3X7qizGiku for ; Wed, 5 Mar 2008 15:53:27 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id 99BCC28C27F for ; Wed, 5 Mar 2008 15:53:27 -0800 (PST) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id m25NrFvP009564; Wed, 5 Mar 2008 18:53:15 -0500 (EST) Received: from mailhub.lss.emc.com (nirah.lss.emc.com [10.254.144.13]) by hop04-l1d11-si02.isus.emc.com (Tablus Interceptor); Wed, 5 Mar 2008 18:53:15 -0500 Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id m25NqZh1014048; Wed, 5 Mar 2008 18:53:13 -0500 (EST) From: Black_David@emc.com Received: from CORPUSMX20A.corp.emc.com ([128.221.62.13]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Mar 2008 18:53:08 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 5 Mar 2008 18:53:07 -0500 Message-ID: <8CC6CEAB44F131478D3A7B429ECACD9192386F@CORPUSMX20A.corp.emc.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ips] Recovery and ERL=0 Thread-Index: AchuaqY+a5tGTFu2R7ubRCaOT4mEegQrkGGQ References: To: , X-OriginalArrivalTime: 05 Mar 2008 23:53:08.0854 (UTC) FILETIME=[10409960:01C87F1C] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.8.30.51425 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -3, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Tablus-Inspected: yes X-Tablus-Classifications: M and A Terms X-Tablus-Action: allow Subject: Re: [Ips] Recovery and ERL=0 X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org Prafulla, This discussion is about data digest errors only, as with a header digest error, the PDU type may have been affected by the corruption. Section 6.7 applies regardless of the error recovery level, but some of the options are not available at error recovery level 0. I believe that what you describe is acceptable at error recovery level 0, but note that the following additional text (from Section 6.7) applies to data digest errors at the target: If the target chooses to implement this option, it MUST wait to receive all the data (signaled by a Data PDU with the final bit set for all outstanding R2Ts) before sending the response PDU. A task management command (such as an abort task) from the initiator during this wait may also conclude the task. For the initiator, aborting the task affected by a data digest error may involve sending a task management function to the target. Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- ________________________________ From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On Behalf Of Deuskar, Prafulla Sent: Wednesday, February 13, 2008 1:03 PM To: ips@ietf.org Subject: [Ips] Recovery and ERL=0 With ERL=0 and Multiple Connections/Session what options does an Initiator have for error recovery? Session recovery seems very heavy weight with MCS - Does section 6.7 in RFC only apply to within-a-command' or 'within-a-connection' data recovery classes? For ex: In case of digest error can I do the following and still be considered compliant with RFC with ERL=0 If it is an iSCSI data PDU with digest error - abort the task and terminate the command with an error If it is an iSCSI response PDU with digest error - logout the connection (abort all commands associated with the connection) Thanks, Prafulla _______________________________________________ Ips mailing list Ips@ietf.org https://www.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Wed Mar 5 23:04:33 2008 Return-Path: X-Original-To: ietfarch-ips-archive@core3.amsl.com Delivered-To: ietfarch-ips-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9AA03A6941; Wed, 5 Mar 2008 23:04:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.978 X-Spam-Level: X-Spam-Status: No, score=-100.978 tagged_above=-999 required=5 tests=[AWL=-1.540, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kMnBorVYlYae; Wed, 5 Mar 2008 23:04:32 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA53F28C806; Wed, 5 Mar 2008 23:04:32 -0800 (PST) X-Original-To: ips@core3.amsl.com Delivered-To: ips@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D30F3A68EF for ; Wed, 5 Mar 2008 23:04:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XfY5JSngreBy for ; Wed, 5 Mar 2008 23:04:29 -0800 (PST) Received: from mtagate5.de.ibm.com (mtagate5.de.ibm.com [195.212.29.154]) by core3.amsl.com (Postfix) with ESMTP id ACBFC28C820 for ; Wed, 5 Mar 2008 23:03:59 -0800 (PST) Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate5.de.ibm.com (8.13.8/8.13.8) with ESMTP id m2673jg3215128 for ; Thu, 6 Mar 2008 07:03:45 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v8.7) with ESMTP id m2673jfB2044124 for ; Thu, 6 Mar 2008 08:03:45 +0100 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m2673jgr025043 for ; Thu, 6 Mar 2008 08:03:45 +0100 Received: from d12mc102.megacenter.de.ibm.com (d12mc102.megacenter.de.ibm.com [9.149.167.114]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m2673j1o025040; Thu, 6 Mar 2008 08:03:45 +0100 In-Reply-To: <8CC6CEAB44F131478D3A7B429ECACD9192386F@CORPUSMX20A.corp.emc.com> References: <8CC6CEAB44F131478D3A7B429ECACD9192386F@CORPUSMX20A.corp.emc.com> To: Black_David@emc.com MIME-Version: 1.0 X-KeepSent: 8823CB26:DAF7A37F-C2257404:00258303; type=4; name=$KeepSent X-Mailer: Lotus Notes Build VMac_Beta85_20080115_MM2 January 15, 2008 From: Julian Satran Message-ID: Date: Thu, 6 Mar 2008 09:03:43 +0200 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 8.0|August 02, 2007) at 06/03/2008 09:03:44, Serialize complete at 06/03/2008 09:03:44 Cc: ips@ietf.org Subject: Re: [Ips] Recovery and ERL=0 X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2069460926==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org This is a multipart message in MIME format. --===============2069460926== Content-Type: multipart/alternative; boundary="=_alternative 0026CA2BC2257404_=" This is a multipart message in MIME format. --=_alternative 0026CA2BC2257404_= Content-Type: text/plain; charset="US-ASCII" Prafulla, As David said - in your first case you may either wait for the response or issue an abort immediately. In both cases you may have to handle some additional recovery at the SCSI level as you have "dropped" a command that may be part of a sequence. For the response digest error logging out is an option but not technically mandatory (gray area) - but again you may have to handle (regardless of how you do it) some additional recovery at SCSI level. Please note that higher recovery levels would allow you to avoid (in most cases) the need for recovery at SCSI level. Julo From: Black_David@emc.com To: , Date: 03/06/08 01:54 AM Subject: Re: [Ips] Recovery and ERL=0 Prafulla, This discussion is about data digest errors only, as with a header digest error, the PDU type may have been affected by the corruption. Section 6.7 applies regardless of the error recovery level, but some of the options are not available at error recovery level 0. I believe that what you describe is acceptable at error recovery level 0, but note that the following additional text (from Section 6.7) applies to data digest errors at the target: If the target chooses to implement this option, it MUST wait to receive all the data (signaled by a Data PDU with the final bit set for all outstanding R2Ts) before sending the response PDU. A task management command (such as an abort task) from the initiator during this wait may also conclude the task. For the initiator, aborting the task affected by a data digest error may involve sending a task management function to the target. Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- ________________________________ From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On Behalf Of Deuskar, Prafulla Sent: Wednesday, February 13, 2008 1:03 PM To: ips@ietf.org Subject: [Ips] Recovery and ERL=0 With ERL=0 and Multiple Connections/Session what options does an Initiator have for error recovery? Session recovery seems very heavy weight with MCS - Does section 6.7 in RFC only apply to within-a-command' or 'within-a-connection' data recovery classes? For ex: In case of digest error can I do the following and still be considered compliant with RFC with ERL=0 If it is an iSCSI data PDU with digest error - abort the task and terminate the command with an error If it is an iSCSI response PDU with digest error - logout the connection (abort all commands associated with the connection) Thanks, Prafulla _______________________________________________ Ips mailing list Ips@ietf.org https://www.ietf.org/mailman/listinfo/ips --=_alternative 0026CA2BC2257404_= Content-Type: text/html; charset="US-ASCII"
Prafulla,

As David said - in your first case you may either wait for the response or issue an abort immediately.
In both cases you may have to handle some additional recovery at the SCSI level as you have "dropped" a command that may be part of a sequence.
For the response digest error logging out is an option but not technically mandatory (gray area) - but again you may have to handle (regardless of how you do it) some additional recovery at SCSI level.
Please note that higher recovery levels would allow you to avoid (in most cases) the need for recovery at SCSI level.

Julo

From:	Black_David@emc.com
To:	<prafulla.deuskar@intel.com>, <ips@ietf.org>
Date:	03/06/08 01:54 AM
Subject:	Re: [Ips] Recovery and ERL=0

Prafulla, This discussion is about data digest errors only, as with a header digest error, the PDU type may have been affected by the corruption. Section 6.7 applies regardless of the error recovery level, but some of the options are not available at error recovery level 0. I believe that what you describe is acceptable at error recovery level 0, but note that the following additional text (from Section 6.7) applies to data digest errors at the target: If the target chooses to implement this option, it MUST wait to receive all the data (signaled by a Data PDU with the final bit set for all outstanding R2Ts) before sending the response PDU. A task management command (such as an abort task) from the initiator during this wait may also conclude the task. For the initiator, aborting the task affected by a data digest error may involve sending a task management function to the target. Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- ________________________________ From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On Behalf Of Deuskar, Prafulla Sent: Wednesday, February 13, 2008 1:03 PM To: ips@ietf.org Subject: [Ips] Recovery and ERL=0 With ERL=0 and Multiple Connections/Session what options does an Initiator have for error recovery? Session recovery seems very heavy weight with MCS - Does section 6.7 in RFC only apply to within-a-command' or 'within-a-connection' data recovery classes? For ex: In case of digest error can I do the following and still be considered compliant with RFC with ERL=0 If it is an iSCSI data PDU with digest error - abort the task and terminate the command with an error If it is an iSCSI response PDU with digest error - logout the connection (abort all commands associated with the connection) Thanks, Prafulla _______________________________________________ Ips mailing list Ips@ietf.orghttps://www.ietf.org/mailman/listinfo/ips
--=_alternative 0026CA2BC2257404_=-- --===============2069460926== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www.ietf.org/mailman/listinfo/ips --===============2069460926==-- From ips-bounces@ietf.org Tue Mar 25 13:33:00 2008 Return-Path: X-Original-To: ietfarch-ips-archive@core3.amsl.com Delivered-To: ietfarch-ips-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97A3628C202; Tue, 25 Mar 2008 13:33:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.492 X-Spam-Level: X-Spam-Status: No, score=-100.492 tagged_above=-999 required=5 tests=[AWL=-0.056, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cTGSWfaSOlCo; Tue, 25 Mar 2008 13:32:59 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3AFDF3A6D45; Tue, 25 Mar 2008 13:32:59 -0700 (PDT) X-Original-To: ips@core3.amsl.com Delivered-To: ips@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DB2D3A6830 for ; Tue, 25 Mar 2008 13:32:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M8c918mpwp7s for ; Tue, 25 Mar 2008 13:32:57 -0700 (PDT) Received: from mail3.pillardata.com (mail3.pillardata.com [209.120.231.20]) by core3.amsl.com (Postfix) with ESMTP id 6FB2B3A6D45 for ; Tue, 25 Mar 2008 13:32:57 -0700 (PDT) Received: from coex02.trans.corp ([172.18.24.19]) by mail3.pillardata.com with ESMTP; 25 Mar 2008 13:30:28 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 25 Mar 2008 14:30:27 -0600 Message-ID: <16236EEEF4D4264DA31C2E35E3607CFE03DA7528@coex02.trans.corp> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: iSNS DevGetNext question Thread-Index: AciOtw/tumz29QCZRxO0hHS4zYDTvA== From: "Paul Hughes" To: "IP Storage Mailing List (E-mail)" Subject: [Ips] iSNS DevGetNext question X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1054442134==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============1054442134== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C88EB7.10005590" This is a multi-part message in MIME format. ------_=_NextPart_001_01C88EB7.10005590 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Is it possible for an iSNS client (an iSCSI target) to use the iSNS = DevGetNext request message to obtain a list of both registered and = un-registered members of the Discovery Domain by specifying a = zero-length operating attribute with DD Member iSCSI Device Name (tag = 2068) as the tag or is querying for un-registered DD members only = possible using a DevAttrQry request? I've tried sending a DevGetNext request with iSCSI Name (tag 32) as the = message key attribute, and operating attributes of iSCSI Node Type (tag = 33 with an "initiator" value) and DD Member iSCSI Name (tag 2068 with = zero-length) but the DevGetNextRsp is returned with Message Format Error = status. I tried this with Microsoft iSNS Server v3.0. Section 5.6.5.2 (Device Attribute Query Request) of RFC 4171 mentions = the following: DD membership can be discovered through the DevAttrQry message by = including either DD member attributes (i.e., DD Member iSCSI Index, DD = Member iSCSI Node [sic], DD Member iFCP Node, DD Member Portal Index, DD = Member Portal IP Addr, and DD Member Portal TCP/UDP) or the object key = of the Storage Node or Portal (i.e., iSCSI Name, iSCSI Index, Portal IP = Addr, Portal TCP/UDP Port, and Portal Index) in the Operating = Attributes. Using DD member attributes SHALL return both registered and = unregistered member Storage Nodes and/or Portals of a DD. DevAttrQry = messages using the Storage Node and/or Portal object key SHALL return = only member Storage Nodes or Portals that are currently registered in = the iSNS database. Section 5.6.5.3 (Device Get Next Request) does not mention DD member = attributes, so it is unclear whether DD member attributes can be used as = operating attributes of a DevGetNext request. Thanks, Paul ------_=_NextPart_001_01C88EB7.10005590 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable iSNS DevGetNext question

Is it possible for an iSNS client (an = iSCSI target) to use the iSNS DevGetNext request message to obtain a = list of both registered and un-registered members of the Discovery = Domain by specifying a zero-length operating attribute with DD Member = iSCSI Device Name (tag 2068) as the tag or is querying for un-registered = DD members only possible using a DevAttrQry request?

I've tried sending a DevGetNext request = with iSCSI Name (tag 32) as the message key attribute, and operating = attributes of iSCSI Node Type (tag 33 with an "initiator" = value) and DD Member iSCSI Name (tag 2068 with zero-length) but the = DevGetNextRsp is returned with Message Format Error status. I = tried this with Microsoft iSNS Server v3.0.

Section 5.6.5.2 (Device Attribute Query = Request) of RFC 4171 mentions the following:

DD membership can be discovered through = the DevAttrQry message by including either DD member attributes (i.e., = DD Member iSCSI Index, DD Member iSCSI Node [sic], DD Member iFCP Node, = DD Member Portal Index, DD Member Portal IP Addr, and DD Member Portal = TCP/UDP) or the object key of the Storage Node or Portal (i.e., iSCSI = Name, iSCSI Index, Portal IP Addr, Portal TCP/UDP Port, and Portal = Index) in the Operating Attributes. Using DD member attributes = SHALL return both registered and unregistered member Storage Nodes = and/or Portals of a DD. DevAttrQry messages using the Storage Node = and/or Portal object key SHALL return only member Storage Nodes or = Portals that are currently registered in the iSNS database.

Section 5.6.5.3 (Device Get Next = Request) does not mention DD member attributes, so it is unclear whether = DD member attributes can be used as operating attributes of a DevGetNext = request.

Thanks,
Paul

------_=_NextPart_001_01C88EB7.10005590-- --===============1054442134== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www.ietf.org/mailman/listinfo/ips --===============1054442134==--