From ips-bounces@ietf.org Tue Sep 05 18:50:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKjje-0006d0-2Q; Tue, 05 Sep 2006 18:49:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKjjc-0006cu-Na for ips@ietf.org; Tue, 05 Sep 2006 18:49:36 -0400 Received: from alnrmhc14.comcast.net ([204.127.225.94] helo=alnrmhc11.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKjjb-000189-GJ for ips@ietf.org; Tue, 05 Sep 2006 18:49:36 -0400 Received: from ivvtdkv0981 (c-66-177-51-34.hsd1.fl.comcast.net[66.177.51.34]) by comcast.net (alnrmhc14) with SMTP id <20060905224934b14001p30me>; Tue, 5 Sep 2006 22:49:35 +0000 Message-ID: <000601c6d13d$8eff3ce0$04031eac@ivivity.com> From: "Eddy Quicksall" To: Date: Tue, 5 Sep 2006 18:49:34 -0400 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Subject: [Ips] iSER use of ITT in Data_Completion_Notify X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1593719853==" Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============1593719853== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01C6D11C.077B2C00" This is a multi-part message in MIME format. ------=_NextPart_000_0003_01C6D11C.077B2C00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Data_Completion_Notify is used at the target to notify the completion of = Data-in or Data-out. The ITT is given as one of the Input Qualifiers. = But the ITT is not understood by the target. It would seem that the TTT = is what should be given instead since that is understood by the target. What am I missing? Eddy ------=_NextPart_000_0003_01C6D11C.077B2C00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Data_Completion_Notify is used at the target to = notify the=20 completion of Data-in or Data-out. The ITT is given as one of the Input=20 Qualifiers. But the ITT is not understood by the target. It would = seem that=20 the TTT is what should be given instead since that is understood by the=20 target.
 
What am I missing?
 
Eddy
------=_NextPart_000_0003_01C6D11C.077B2C00-- --===============1593719853== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============1593719853==-- From ips-bounces@ietf.org Tue Sep 05 19:44:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKkat-0003wF-Om; Tue, 05 Sep 2006 19:44:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKkas-0003w9-V7 for ips@ietf.org; Tue, 05 Sep 2006 19:44:38 -0400 Received: from e4.ny.us.ibm.com ([32.97.182.144]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKkaq-0005Qb-10 for ips@ietf.org; Tue, 05 Sep 2006 19:44:38 -0400 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e4.ny.us.ibm.com (8.13.8/8.12.11) with ESMTP id k85NiZ3S015315 for ; Tue, 5 Sep 2006 19:44:35 -0400 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay02.pok.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id k85NiZ6Y284782 for ; Tue, 5 Sep 2006 19:44:35 -0400 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id k85NiZhd006202 for ; Tue, 5 Sep 2006 19:44:35 -0400 Received: from d01ml604.pok.ibm.com (d01ml604.pok.ibm.com [9.56.227.90]) by d01av03.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k85NiZFA006197 for ; Tue, 5 Sep 2006 19:44:35 -0400 In-Reply-To: <000601c6d13d$8eff3ce0$04031eac@ivivity.com> Subject: Re: [Ips] iSER use of ITT in Data_Completion_Notify To: "Eddy Quicksall" X-Mailer: Lotus Notes Release 7.0 HF242 April 21, 2006 Message-ID: From: Mike Ko Date: Tue, 5 Sep 2006 16:44:34 -0700 X-MIMETrack: Serialize by Router on D01ML604/01/M/IBM(Release 7.0.1HF269 | June 22, 2006) at 09/05/2006 19:44:35 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org ITT is used to identify a task during its execution by both the initiator and the target. See RFC3720. It is for this reason that it is used as an input qualifier in Data_Completion_Notify. Mike "Eddy Quicksall" cc 09/05/2006 03:49 PM Subject [Ips] iSER use of ITT in Data_Completion_Notify Data_Completion_Notify is used at the target to notify the completion of Data-in or Data-out. The ITT is given as one of the Input Qualifiers. But the ITT is not understood by the target. It would seem that the TTT is what should be given instead since that is understood by the target. What am I missing? Eddy_______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Tue Sep 05 21:37:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKmLX-0005AN-6x; Tue, 05 Sep 2006 21:36:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKmLV-0005AI-SE for ips@ietf.org; Tue, 05 Sep 2006 21:36:53 -0400 Received: from alnrmhc13.comcast.net ([206.18.177.53] helo=alnrmhc11.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKmLU-0001GG-Je for ips@ietf.org; Tue, 05 Sep 2006 21:36:53 -0400 Received: from ivvtdkv0981 (c-66-177-51-34.hsd1.fl.comcast.net[66.177.51.34]) by comcast.net (alnrmhc13) with SMTP id <20060906013641b13003qjd2e>; Wed, 6 Sep 2006 01:36:52 +0000 Message-ID: <000c01c6d154$eda6fdc0$04031eac@ivivity.com> From: "Eddy Quicksall" To: "Mike Ko" References: Subject: Re: [Ips] iSER use of ITT in Data_Completion_Notify Date: Tue, 5 Sep 2006 21:36:41 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org That is true but it would be better if the TTT were supplied for the target to identify the structure used for the data. That way the target does not need to catalog the ITT. The TTT could just be an index or a pointer that can be resolved quite easily. Eddy ----- Original Message ----- From: "Mike Ko" To: "Eddy Quicksall" Cc: Sent: Tuesday, September 05, 2006 7:44 PM Subject: Re: [Ips] iSER use of ITT in Data_Completion_Notify > ITT is used to identify a task during its execution by both the initiator > and the target. See RFC3720. It is for this reason that it is used as an > input qualifier in Data_Completion_Notify. > > Mike > > > > "Eddy Quicksall" > Vivity_iSCSI@Comc To > ast.net> > cc > 09/05/2006 03:49 > PM Subject > [Ips] iSER use of ITT in > Data_Completion_Notify > > > > > > > > > > > Data_Completion_Notify is used at the target to notify the completion of > Data-in or Data-out. The ITT is given as one of the Input Qualifiers. But > the ITT is not understood by the target. It would seem that the TTT is > what > should be given instead since that is understood by the target. > > What am I missing? > > Eddy_______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips > > > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Wed Sep 06 00:13:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKon2-0001GF-Rm; Wed, 06 Sep 2006 00:13:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKon1-0001Fv-Q9 for ips@ietf.org; Wed, 06 Sep 2006 00:13:27 -0400 Received: from e1.ny.us.ibm.com ([32.97.182.141]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKon0-0001Ee-9l for ips@ietf.org; Wed, 06 Sep 2006 00:13:27 -0400 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e1.ny.us.ibm.com (8.13.8/8.12.11) with ESMTP id k864DPqX027265 for ; Wed, 6 Sep 2006 00:13:25 -0400 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay04.pok.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id k864DPYQ272578 for ; Wed, 6 Sep 2006 00:13:25 -0400 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id k864DPJv016130 for ; Wed, 6 Sep 2006 00:13:25 -0400 Received: from d01ml604.pok.ibm.com (d01ml604.pok.ibm.com [9.56.227.90]) by d01av03.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k864DPQi016119; Wed, 6 Sep 2006 00:13:25 -0400 In-Reply-To: <000c01c6d154$eda6fdc0$04031eac@ivivity.com> Subject: Re: [Ips] iSER use of ITT in Data_Completion_Notify To: "Eddy Quicksall" X-Mailer: Lotus Notes Release 7.0 HF242 April 21, 2006 Message-ID: From: Mike Ko Date: Tue, 5 Sep 2006 21:13:24 -0700 X-MIMETrack: Serialize by Router on D01ML604/01/M/IBM(Release 7.0.1HF269 | June 22, 2006) at 09/06/2006 00:13:25 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org I don't know what you mean by "the target does not need to catalog the ITT". Both the R2T and the SCSI Data-in PDU generated by the iSCSI layer contained the ITT. Mike "Eddy Quicksall" "Mike Ko" cc 09/05/2006 06:36 PM Subject Re: [Ips] iSER use of ITT in Data_Completion_Notify That is true but it would be better if the TTT were supplied for the target to identify the structure used for the data. That way the target does not need to catalog the ITT. The TTT could just be an index or a pointer that can be resolved quite easily. Eddy ----- Original Message ----- From: "Mike Ko" To: "Eddy Quicksall" Cc: Sent: Tuesday, September 05, 2006 7:44 PM Subject: Re: [Ips] iSER use of ITT in Data_Completion_Notify > ITT is used to identify a task during its execution by both the initiator > and the target. See RFC3720. It is for this reason that it is used as an > input qualifier in Data_Completion_Notify. > > Mike > > > > "Eddy Quicksall" > Vivity_iSCSI@Comc To > ast.net> > cc > 09/05/2006 03:49 > PM Subject > [Ips] iSER use of ITT in > Data_Completion_Notify > > > > > > > > > > > Data_Completion_Notify is used at the target to notify the completion of > Data-in or Data-out. The ITT is given as one of the Input Qualifiers. But > the ITT is not understood by the target. It would seem that the TTT is > what > should be given instead since that is understood by the target. > > What am I missing? > > Eddy_______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips > > > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Wed Sep 06 16:08:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GL3gH-0002BH-RF; Wed, 06 Sep 2006 16:07:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GL3gG-0002BC-9U for ips@ietf.org; Wed, 06 Sep 2006 16:07:28 -0400 Received: from sccrmhc15.comcast.net ([204.127.200.85]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GL3gF-0003v0-0b for ips@ietf.org; Wed, 06 Sep 2006 16:07:28 -0400 Received: from ivvtdkv0981 (c-66-177-51-34.hsd1.fl.comcast.net[66.177.51.34]) by comcast.net (sccrmhc15) with SMTP id <2006090620072101500oko1ne>; Wed, 6 Sep 2006 20:07:26 +0000 Message-ID: <000f01c6d1f0$13222980$04031eac@ivivity.com> From: "Eddy Quicksall" To: "Mike Ko" References: Subject: Re: [Ips] iSER use of ITT in Data_Completion_Notify Date: Wed, 6 Sep 2006 16:07:21 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org To answer your question, since the target does not understand the ITT it must catalog it so that when it is received again in the absence of the TTT, the target must use some algorithm (which often includes some sort of search) to find the task. You are correct in what you say but what I'm trying to point out is a more efficient method that is available with the TTT. The TTT is also supplied in both the R2T. the SCSI Data-in and Data-out PDU. Eddy ----- Original Message ----- From: "Mike Ko" To: "Eddy Quicksall" Cc: Sent: Wednesday, September 06, 2006 12:13 AM Subject: Re: [Ips] iSER use of ITT in Data_Completion_Notify >I don't know what you mean by "the target does not need to catalog the > ITT". Both the R2T and the SCSI Data-in PDU generated by the iSCSI layer > contained the ITT. > > Mike > > > > "Eddy Quicksall" > Vivity_iSCSI@comc To > ast.net> "Mike Ko" > cc > 09/05/2006 06:36 > PM Subject > Re: [Ips] iSER use of ITT in > Data_Completion_Notify > > > > > > > > > > > That is true but it would be better if the TTT were supplied for the > target > > to identify the structure used for the data. That way the target does not > need to catalog the ITT. The TTT could just be an index or a pointer that > can be resolved quite easily. > > > Eddy > > ----- Original Message ----- > From: "Mike Ko" > To: "Eddy Quicksall" > Cc: > Sent: Tuesday, September 05, 2006 7:44 PM > Subject: Re: [Ips] iSER use of ITT in Data_Completion_Notify > > >> ITT is used to identify a task during its execution by both the initiator >> and the target. See RFC3720. It is for this reason that it is used as > an >> input qualifier in Data_Completion_Notify. >> >> Mike >> >> >> >> "Eddy Quicksall" >> > Vivity_iSCSI@Comc To >> ast.net> >> cc >> 09/05/2006 03:49 >> PM Subject >> [Ips] iSER use of ITT in >> Data_Completion_Notify >> >> >> >> >> >> >> >> >> >> >> Data_Completion_Notify is used at the target to notify the completion of >> Data-in or Data-out. The ITT is given as one of the Input Qualifiers. But >> the ITT is not understood by the target. It would seem that the TTT is >> what >> should be given instead since that is understood by the target. >> >> What am I missing? >> >> Eddy_______________________________________________ >> Ips mailing list >> Ips@ietf.org >> https://www1.ietf.org/mailman/listinfo/ips >> >> >> >> _______________________________________________ >> Ips mailing list >> Ips@ietf.org >> https://www1.ietf.org/mailman/listinfo/ips >> > > > > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Wed Sep 06 17:28:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GL4wD-0005GI-Tn; Wed, 06 Sep 2006 17:28:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GL4wC-0005GA-KC for ips@ietf.org; Wed, 06 Sep 2006 17:28:00 -0400 Received: from sccrmhc14.comcast.net ([63.240.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GL4wB-0007GF-Do for ips@ietf.org; Wed, 06 Sep 2006 17:28:00 -0400 Received: from ivvtdkv0981 (c-66-177-51-34.hsd1.fl.comcast.net[66.177.51.34]) by comcast.net (sccrmhc14) with SMTP id <20060906212753014008lpp2e>; Wed, 6 Sep 2006 21:27:59 +0000 Message-ID: <000901c6d1fb$535c1d20$04031eac@ivivity.com> From: "Eddy Quicksall" To: Date: Wed, 6 Sep 2006 17:27:53 -0400 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Subject: [Ips] clearification on iSER Completion_Notify X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1421002559==" Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============1421002559== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C6D1D9.C8C2DD00" This is a multi-part message in MIME format. ------=_NextPart_000_0006_01C6D1D9.C8C2DD00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Am I correct that only the target gets a Completion_Notify? Am I correct that the method used by the initiator to determine that = SCSI Read data has arrived is the completion of the SCSI Read command? Can the target issue multiple outstanding R2T's and if enabled, receive = a Completion_Notify for each completed sequence? Eddy ------=_NextPart_000_0006_01C6D1D9.C8C2DD00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Am I correct that only the target gets a=20 Completion_Notify?
 
Am I correct that the method used by the initiator = to=20 determine that SCSI Read data has arrived is the completion of the SCSI = Read=20 command?
 
Can the target issue multiple outstanding R2T's = and if=20 enabled, receive a Completion_Notify for each completed = sequence?
 
Eddy
------=_NextPart_000_0006_01C6D1D9.C8C2DD00-- --===============1421002559== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============1421002559==-- From ips-bounces@ietf.org Thu Sep 07 16:43:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLQi2-0003kW-GY; Thu, 07 Sep 2006 16:42:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLQi1-0003kI-P3 for ips@ietf.org; Thu, 07 Sep 2006 16:42:49 -0400 Received: from alnrmhc11.comcast.net ([206.18.177.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLQi0-0007uX-I1 for ips@ietf.org; Thu, 07 Sep 2006 16:42:49 -0400 Received: from ivvtdkv0981 (c-66-177-51-34.hsd1.fl.comcast.net[66.177.51.34]) by comcast.net (alnrmhc11) with SMTP id <20060907204247b11001oov2e>; Thu, 7 Sep 2006 20:42:48 +0000 Message-ID: <000d01c6d2be$250d84e0$04031eac@ivivity.com> From: "Eddy Quicksall" To: Date: Thu, 7 Sep 2006 16:42:30 -0400 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Subject: [Ips] iSER TMF question X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2147049716==" Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============2147049716== Content-Type: multipart/alternative; boundary="----=_NextPart_000_000A_01C6D29C.9C35A3D0" This is a multi-part message in MIME format. ------=_NextPart_000_000A_01C6D29C.9C35A3D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The spec talks about TMF Requests but has little to say about the TMF = Response. Am I correct that the TMF Response's Write STag and Read STag = should be 0 and the WSV and RSV fields should be 0? Should the TMF Response use SendInvSE? Eddy ------=_NextPart_000_000A_01C6D29C.9C35A3D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
The spec talks about TMF Requests but has little to = say about=20 the TMF Response. Am I correct that the TMF Response's Write STag and = Read STag=20 should be 0 and the WSV and RSV fields should be 0?
 
Should the TMF Response use SendInvSE?
 
Eddy
------=_NextPart_000_000A_01C6D29C.9C35A3D0-- --===============2147049716== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============2147049716==-- From ips-bounces@ietf.org Thu Sep 07 17:46:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLRh5-0002kf-E4; Thu, 07 Sep 2006 17:45:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLRh4-0002jB-1e for ips@ietf.org; Thu, 07 Sep 2006 17:45:54 -0400 Received: from e2.ny.us.ibm.com ([32.97.182.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLRh2-0006TF-Pe for ips@ietf.org; Thu, 07 Sep 2006 17:45:54 -0400 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e2.ny.us.ibm.com (8.13.8/8.12.11) with ESMTP id k87LjnLF013742 for ; Thu, 7 Sep 2006 17:45:49 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id k87LjoVe279568 for ; Thu, 7 Sep 2006 17:45:50 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id k87LjnWD016572 for ; Thu, 7 Sep 2006 17:45:49 -0400 Received: from d01ml604.pok.ibm.com (d01ml604.pok.ibm.com [9.56.227.90]) by d01av02.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k87Ljnt1016567 for ; Thu, 7 Sep 2006 17:45:49 -0400 In-Reply-To: <000d01c6d2be$250d84e0$04031eac@ivivity.com> Subject: Re: [Ips] iSER TMF question To: "Eddy Quicksall" X-Mailer: Lotus Notes Release 7.0 HF242 April 21, 2006 Message-ID: From: Mike Ko Date: Thu, 7 Sep 2006 14:45:49 -0700 X-MIMETrack: Serialize by Router on D01ML604/01/M/IBM(Release 7.0.1HF269 | June 22, 2006) at 09/07/2006 17:45:49 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org That is correct. In general, the RSV and the WSV flags and the STag fields in the iSER header are used by the initiator to advertise the initiator's buffer to the target. See section 9.2. Mike "Eddy Quicksall" cc 09/07/2006 01:42 PM Subject [Ips] iSER TMF question The spec talks about TMF Requests but has little to say about the TMF Response. Am I correct that the TMF Response's Write STag and Read STag should be 0 and the WSV and RSV fields should be 0? Should the TMF Response use SendInvSE? Eddy_______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Thu Sep 07 18:12:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLS65-00040a-5d; Thu, 07 Sep 2006 18:11:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLS64-0003x6-0a for ips@ietf.org; Thu, 07 Sep 2006 18:11:44 -0400 Received: from e2.ny.us.ibm.com ([32.97.182.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLRvp-00079z-9k for ips@ietf.org; Thu, 07 Sep 2006 18:01:10 -0400 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e2.ny.us.ibm.com (8.13.8/8.12.11) with ESMTP id k87M181W003363 for ; Thu, 7 Sep 2006 18:01:08 -0400 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay02.pok.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id k87M19cm239856 for ; Thu, 7 Sep 2006 18:01:09 -0400 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id k87M18QL026585 for ; Thu, 7 Sep 2006 18:01:08 -0400 Received: from d01ml604.pok.ibm.com (d01ml604.pok.ibm.com [9.56.227.90]) by d01av04.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k87M18p8026577 for ; Thu, 7 Sep 2006 18:01:08 -0400 In-Reply-To: <000901c6d1fb$535c1d20$04031eac@ivivity.com> Subject: Re: [Ips] clearification on iSER Completion_Notify To: "Eddy Quicksall" X-Mailer: Lotus Notes Release 7.0 HF242 April 21, 2006 Message-ID: From: Mike Ko Date: Thu, 7 Sep 2006 15:01:08 -0700 X-MIMETrack: Serialize by Router on D01ML604/01/M/IBM(Release 7.0.1HF269 | June 22, 2006) at 09/07/2006 18:01:08 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org That is correct. Mike "Eddy Quicksall" cc 09/06/2006 02:27 PM Subject [Ips] clearification on iSER Completion_Notify Am I correct that only the target gets a Completion_Notify? Am I correct that the method used by the initiator to determine that SCSI Read data has arrived is the completion of the SCSI Read command? Can the target issue multiple outstanding R2T's and if enabled, receive a Completion_Notify for each completed sequence? Eddy_______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Fri Sep 08 00:55:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLYOI-0007j3-Eb; Fri, 08 Sep 2006 00:54:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLYOH-0007iG-0O for ips@ietf.org; Fri, 08 Sep 2006 00:54:57 -0400 Received: from web36806.mail.mud.yahoo.com ([209.191.85.57]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GLYOF-00032R-AF for ips@ietf.org; Fri, 08 Sep 2006 00:54:56 -0400 Received: (qmail 29305 invoked by uid 60001); 8 Sep 2006 04:54:54 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=IEb/YtfJBku468/6S22LofLb3OW0kaIEvvoK8CgiXsHnAVXDEdxq3Ac0fBQ4mAqNgRHG7/dXtPdNP/3MP2d8F8VD5KiqkY5s7mqLODkcfW03Hh0JbMUpu5jpz+og29kdKvZJPAP2lqRLoyrdM9BKnKf1XNBUe2h46MeWBlSc4bI= ; Message-ID: <20060908045454.29303.qmail@web36806.mail.mud.yahoo.com> Received: from [69.134.212.78] by web36806.mail.mud.yahoo.com via HTTP; Thu, 07 Sep 2006 21:54:54 PDT Date: Thu, 7 Sep 2006 21:54:54 -0700 (PDT) From: Dave Wyso To: internet-drafts@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-894355274-1157691294=:28371" Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 28adfdfeb3b69a8c1fb469b1c327fd44 Cc: ips@ietf.org, Black_David@emc.com Subject: [Ips] draft-ietf-ips-iscsi-nodearch-key-01.txt X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: wysochanski@pobox.com List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org --0-894355274-1157691294=:28371 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Id: Content-Disposition: inline --0-894355274-1157691294=:28371 Content-Type: text/plain; name="draft-ietf-ips-iscsi-nodearch-key-01.txt" Content-Description: 3836641885-draft-ietf-ips-iscsi-nodearch-key-01.txt Content-Disposition: inline; filename="draft-ietf-ips-iscsi-nodearch-key-01.txt" IP Storage Working Group D. Wysochanski Internet-Draft September 7, 2006 Intended status: Informational Expires: March 11, 2007 Declarative Public Extension Key for iSCSI Node Architecture draft-ietf-ips-iscsi-nodearch-key-01.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on March 11, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Wysochanski Expires March 11, 2007 [Page 1] Internet-Draft iSCSI Node Architecture September 2006 Abstract The iSCSI protocol, described in RFC 3720 [2], allows for extension items to the protocol in the form of Private or Public Extension Keys. This Internet-Draft describes a Public Extension Key for the purpose of enhancing iSCSI supportability. The key accomplishes this objective by allowing iSCSI nodes to communicate architecture details during the iSCSI login sequence. The receiving node can then use this information for enhanced logging and support. Wysochanski Expires March 11, 2007 [Page 2] Internet-Draft iSCSI Node Architecture September 2006 1. Introduction 1.1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1]. 1.2. Overview This Internet-Draft describes a declarative Public Extension Key as defined by section 12.22 of RFC 3720 [2] that may be used to communicate additional iSCSI node information to the opposite node in a session. The information carried in the described key has been found to be valuable in real iSCSI customer environments as initiator and target vendors collaborate to resolve technical issues and better understand the evolving iSCSI market. The key has been modeled after the "Server" and "User-Agent" header fields as specified in sections 14.38 and 14.43 of RFC 2616 [3], with the text-value(s) of the key roughly equivalent to Product Tokens in section 3.8 of RFC 2616 [3]. Note however that the text-value(s) in the keys list-of-values MUST conform to the Text Format as specified in section 5.1 of RFC 3720 [2]. The key is sent during operational parameter negotiation of an iSCSI session's login phase. The intended use of this key is to provide enhanced logging and support capabilities, and to enable collection of iSCSI implementation and usage information. Functional behavior of the iSCSI node (this includes the iSCSI protocol logic -- the SCSI, iSCSI, and TCP/IP protocols) MUST NOT depend on the presence, absence, or content of the key. The key MUST NOT be used by iSCSI nodes for interoperability, or exclusion or deception of other nodes. To ensure proper use, key values SHOULD be set by the node itself, and there SHOULD NOT be provisions for the key values to contain user-defined text. Wysochanski Expires March 11, 2007 [Page 3] Internet-Draft iSCSI Node Architecture September 2006 2. Definition The definition of the key is as follows, conforming to sections 11 and 12 of RFC 3720 [2], with example list-of-values conforming to section 5.1 of RFC 3720 [2]. The key is defined with a Use of "LO", making it a Leading Only key, and does not amend sections 11 or 12 of RFC 3720 [2]. Thus, the key MUST only be sent on the leading connection, MUST NOT be changed after the leading connection login, and MUST only be sent after the security negotiation login stage has completed (during operational negotiation login stage). The key may be sent during normal or discovery sessions. 2.1. X#NodeArchitecture Use: LO, Declarative Senders: Initiator and Target Scope: SW X#NodeArchitecture= Examples: X#NodeArchitecture=ExampleOS/v1234,ExampleInc_SW_Initiator/1.05a X#NodeArchitecture=ExampleInc_HW_Initiator/4010,Firmware/2.0.0.5 X#NodeArchitecture=ExampleInc_SW_Initiator/2.1,CPU_Arch/i686 The initiator or target declares the details of its iSCSI node architecture to the remote endpoint. These details may include, but are not limited to, iSCSI vendor software, firmware, or hardware versions, the OS version, or hardware architecture. The length of the key value (total length of the list-of-values) MUST NOT be greater than 255 bytes. X#NodeArchitecture MUST NOT be redeclared. Wysochanski Expires March 11, 2007 [Page 4] Internet-Draft iSCSI Node Architecture September 2006 3. Implementation Nodes implementing this key may choose to only transmit the key, only log the key values received from other nodes, or both transmit and log the key values. Each node choosing to implement transmission of the key values MUST be prepared to handle the response of RFC 3720 [2] compliant nodes that do not understand the key (RFC 3720 [2] states that compliant nodes MUST respond with X#NodeArchitecture=NotUnderstood). Nodes that implement transmission and/or logging of the key values may also implement switches which disable and/or change the logging and key transmission detail (see Security Considerations). Thus, a valid implementation of this key may be that a node is completely silent (the node does not transmit any key value, and simply discards any key values it receives). Wysochanski Expires March 11, 2007 [Page 5] Internet-Draft iSCSI Node Architecture September 2006 4. Security Considerations This extension key transmits specific implementation details about the node that sends it; such details may be considered sensitive in some environments. For example, if a certain software or firmware version is known to contain security weaknesses, announcing the presence of that version via this key may not be desirable. The countermeasures for this security concern are: o sending less detailed information in the key values, or o not sending the extension key, or o using IPsec to provide confidentiality for the iSCSI connection on which the key is sent (see RFC 3720 [2] and RFC 3723 [4]). To support the first and second countermeasures, all implementations of this extension key MUST provide an administrative mechanism to disable sending the key. In addition, all implementations SHOULD provide an administrative mechanism to configure a verbosity level of the key value, thereby controlling the amount of information sent. For example, a lower verbosity might enable transmission of node architecture component names only, but no version numbers. The choice of which countermeasure is most appropriate depends on the environment. However, the first countermeasure may be acceptable in many environments, since it provides a compromise between sending too much information and the other more complete countermeasures of not sending the key at all or using IPsec. In addition to security considerations involving transmission of the key contents, any logging method(s) used for the key values MUST keep the information secure from intruders. For all implementations, the requirements to address this security concern are: o display of the log MUST only be possible with administrative rights to the node o options to disable logging to disk and to keep logs for a fixed duration SHOULD be provided Finally, it is important to note that different nodes may have different levels of risk, and these differences may affect the implementation. The components of risk include assets, threats, and vulnerabilities. Consider the following example iSCSI nodes, which demonstrate differences in assets and vulnerabilities of the nodes, and as a result, differences in implementation: Wysochanski Expires March 11, 2007 [Page 6] Internet-Draft iSCSI Node Architecture September 2006 o One iSCSI target based on a special-purpose operating system. Since the iSCSI target controls access to the data storage containing company assets, the asset level is seen as very high. Also, because of the special-purpose operating system, in which vulnerabilities are less well-known, the vulnerability level is viewed as low. o Multiple iSCSI initiators in a blade farm, each running a general- purpose operating system. The asset level of each node is viewed as low, since blades are replaceable and low cost. However, the vulnerability level is viewed as high, since there are many well- known vulnerabilities to the general-purpose operating system. For the above target, an appropriate implementation might be logging of received key values, but no transmission of the key. For the initiators, an appropriate implementation might be transmission of the key, but no logging of received key values. Wysochanski Expires March 11, 2007 [Page 7] Internet-Draft iSCSI Node Architecture September 2006 5. IANA Considerations This document defines the iSCSI Extension Key NodeArchitecture to be registered in the IANA iSCSI extended key registry. Wysochanski Expires March 11, 2007 [Page 8] Internet-Draft iSCSI Node Architecture September 2006 6. References 6.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka, M., and E. Zeidner, "Internet Small Computer Systems Interface (iSCSI)", RFC 3720, April 2004. 6.2. Informative References [3] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [4] Aboba, B., Tseng, J., Walker, J., Rangan, V., and F. Travostino, "Securing Block Storage Protocols over IP", RFC 3723, April 2004. Wysochanski Expires March 11, 2007 [Page 9] Internet-Draft iSCSI Node Architecture September 2006 Appendix A. Acknowledgements The IP Storage (ips) Working Group in the Transport Area of IETF has been responsible for defining the iSCSI protocol (apart from a host of other relevant IP Storage protocols). The editor acknowledges the contributions of the entire working group. The following individuals directly contributed to identifying issues and/or suggesting resolutions to the issues found in this document: David Black, Mallikarjun Chadalapaka, Paul Koning, Julian Satran, John Hufferd, Claire Kraft, Ranga Sankar, Joseph Pittman, Greg Berg, John Forte, Jim Yuill, and William Studenmund. This document benefited from all these contributions. Finally, the author recognizes Network Appliance, Inc. for sponsorship and support during the development of this work. Wysochanski Expires March 11, 2007 [Page 10] Internet-Draft iSCSI Node Architecture September 2006 Author's Address Dave Wysochanski 8311 Brier Creek Parkway Suite 105-296 Raleigh, NC 27617 US Phone: +1 919 696 8130 Email: wysochanski@pobox.com Wysochanski Expires March 11, 2007 [Page 11] Internet-Draft iSCSI Node Architecture September 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Wysochanski Expires March 11, 2007 [Page 12] --0-894355274-1157691294=:28371 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --0-894355274-1157691294=:28371-- From gdkaelbk9@a-net.ne.jp Sat Sep 09 01:18:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLvEX-0004pG-7J for IPS-ARCHIVE@LISTS.IETF.ORG; Sat, 09 Sep 2006 01:18:25 -0400 Received: from [221.210.39.204] (helo=a-net.ne.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLvAm-0006KJ-5l for IPS-ARCHIVE@LISTS.IETF.ORG; Sat, 09 Sep 2006 01:14:47 -0400 Received: from xplema1 (unknown [85.188.5.183]) by smtp57 (Coremail) with SMTP id N6U3jSRmxSq9bit5.1 for ; Sat, 09 Sep 2006 13:14:31 +0800 (CST) X-Originating-IP: [85.188.5.183] Subject: =?iso-2022-jp?B?GyRCIVoiKDliM1s8fUZ+JE4kKkNOJGkkOyIoIVsbKEI=?= From: =?gb2312?B?aW5mb3JtYXRpb24=?= To: X-Mailer: Microsoft Outlook Express MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C6C402.3AF65A40" X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.7 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 This is a multi-part message in MIME format. ------=_NextPart_000_0006_01C6C402.3AF65A40 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: base64 GyRCOiMhIjkrJEdPQ0JqJE4hVjVVMWc9dThyOl0hVxsoQg0KGyRCJCIkSiQ/JE8kNEI4Q04kRyQ5 JCshKRsoQg0KDQobJEIkKjZiJEskKjokJGokTkp9ISI9Yz9oJEslKCVDJUEkLCQ3JD8kJEp9RXkh IiRJJEokP01NJEckYjRKQzEkSkVQTz8kRzojRnwkKyRpNVUxZz11JWklJCVVJCw0Lkc9JEckLSRe JDkhIxsoQg0KaHR0cDovL3ZpZm4uY29tLz9oYXJ1MjEyDQoNChskQiF+PXdALSROJF8hIkcvPH0h Ij8mNkghIiQ9JE5CPiEiRXY8UjUsRGokTj8zOjokciQ1JDskRkQ6JCQkRiQqJGokXiQ5JE4kRyQ0 Tjs+NSQvJEAkNSQkISMbKEINChskQiIoJTUlXSE8JUg2YjNbJE84RD9NJE48K00zJEgkNyRGJCQk XiQ5ISMbKEINChskQiIoJVclaSUkJVAlNyE8Sl04biRPRTBEbDRJTX0kciQ3JEYkJCReJDkhIxso Qg0KGyRCISE9Oz1qISI7YUw+ISJFRU9DSFY5ZkV5JE41LTpcOWBMXCRPMGxAWiQiJGokXiQ7JHMh IxsoQg0KGyRCMnEwd0VQTz8kSyRPNEpDMSRKJSIlSSVsJTkzTkcnJE4kXyRHJDkkTiRHMEI/NCQ3 JEYkNE14TVEyPCQ1JCQhIxsoQg0KDQobJEIiKEVQTz9OQSEmRy8ycUhxJE80MEE0TDVOQSEqGyhC DQobJEI0SkMxRVBPPxsoQlVSTBskQiJNISEbKEJodHRwOi8vdmlmbi5jb20vP2hhcnUyMTINCg0K DQoNCg0KGyRCR1s/LklUTVclYSE8JWslIiVJJWwlOSIqISEbKEJtaWRhcmFfbWFzdGVyQHlhaG9v LmNvLmpwDQoNClVzZWxlc3NuZXNzIHRvIHNlcnZlGyRCIiohIRsoQm1pZGFyYV9tYXN0ZXJAeWFo b28uY28uanA= ------=_NextPart_000_0006_01C6C402.3AF65A40 Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWlzby0yMDIyLWpwIj4NCjxNRVRBIGNvbnRlbnQ9Ik1TSFRN TCA2LjAwLjI5MDAuMjE4MCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVB RD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgZmFjZT0iTVMgVUkgR290aGlj Ij4bJEI6IyEiOSskR09DQmokTiFWNVUxZz11OHI6XSFXGyhCPEJSPhskQiQiJEokPyRPJDRCOENO JEckOSQrISkbKEI8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9Ik1TIFVJIEdvdGhpYyIg c2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgDQpmYWNlPSJNUyBVSSBHb3Ro aWMiPhskQiQqNmIkSyQqOiQkaiROSn0hIj1jP2gkSyUoJUMlQSQsJDckPyQkSn1FeSEiJEkkSiQ/ TU0kRyRiNEpDMSRKRVBPPyRHOiNGfCQrJGk1VTFnPXUlaSUkJVUkLDQuRz0kRyQtJF4kOSEjGyhC PEJSPjxBIA0KaHJlZj0iaHR0cDovL3ZpZm4uY29tLz9oYXJ1MjEyIj5odHRwOi8vdmlmbi5jb20v P2hhcnUyMTI8L0E+PC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQg DQpmYWNlPSJNUyBVSSBHb3RoaWMiPhskQiF+PXdALSROJF8hIkcvPH0hIj8mNkghIiQ9JE5CPiEi RXY8UjUsRGokTj8zOjokciQ1JDskRkQ6JCQkRiQqJGokXiQ5JE4kRyQ0Tjs+NSQvJEAkNSQkISMb KEI8QlI+GyRCIiglNSVdITwlSDZiM1skTzhEP00kTjwrTTMkSCQ3JEYkJCReJDkhIxsoQjxCUj4b JEIiKCVXJWklJCVQJTchPEpdOG4kT0UwRGw0SU19JHIkNyRGJCQkXiQ5ISMbKEI8QlI+GyRCISE9 Oz1qISI7YUw+ISJFRU9DSFY5ZkV5JE41LTpcOWBMXCRPMGxAWiQiJGokXiQ7JHMhIxsoQjxCUj4b JEIycTB3RVBPPyRLJE80SkMxJEolIiVJJWwlOTNORyckTiRfJEckOSROJEcwQj80JDckRiQ0TXhN UTI8JDUkJCEjGyhCPC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQg ZmFjZT0iTVMgVUkgR290aGljIj4bJEIiKEVQTz9OQSEmRy8ycUhxJE80MEE0TDVOQSEqGyhCPEJS PhskQjRKQzFFUE8/GyhCVVJMGyRCIk0hIRsoQjxBIA0KaHJlZj0iaHR0cDovL3ZpZm4uY29tLz9o YXJ1MjEyIj5odHRwOi8vdmlmbi5jb20vP2hhcnUyMTI8L0E+PC9GT05UPjwvRElWPg0KPERJVj4m bmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0iTVMgVUkgR290aGljIiBzaXplPTI+PC9GT05U PiZuYnNwOzwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj48Rk9OVCBmYWNlPSJNUyBVSSBHb3RoaWMi IHNpemU9Mj4NCjxESVY+PEJSPhskQkdbPy5JVE1XJWEhPCVrJSIlSSVsJTkiKiEhGyhCPEEgDQpo cmVmPSJtYWlsdG86bWlkYXJhX21hc3RlckB5YWhvby5jby5qcCI+bWlkYXJhX21hc3RlckB5YWhv by5jby5qcDwvQT48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPlVzZWxlc3NuZXNzIHRv IHNlcnZlGyRCIiohIRsoQjxBIA0KaHJlZj0ibWFpbHRvOm1pZGFyYV9tYXN0ZXJAeWFob28uY28u anAiPm1pZGFyYV9tYXN0ZXJAeWFob28uY28uanA8L0E+PC9GT05UPjwvRElWPjwvQk9EWT48L0hU TUw+DQo= ------=_NextPart_000_0006_01C6C402.3AF65A40-- From ourhyrqy4@a-net.ne.jp Sun Sep 10 00:59:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMHPS-0006DU-Lp for IPS-ARCHIVE@LISTS.IETF.ORG; Sun, 10 Sep 2006 00:59:10 -0400 Received: from [221.210.37.135] (helo=a-net.ne.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GMHPQ-00047o-7B for IPS-ARCHIVE@LISTS.IETF.ORG; Sun, 10 Sep 2006 00:59:10 -0400 Received: from wbxy2 (unknown [30.145.244.120]) by smtp62 (Coremail) with SMTP id e2Q90tOnOT3U6n8Y.1 for ; Sun, 10 Sep 2006 12:59:07 +0800 (CST) X-Originating-IP: [30.145.244.120] Subject: =?iso-2022-jp?B?GyRCIiEkNE14TVEbKEIuGyRCRVBPP00tJGpGcSQmJDQkNhsoQg==?= From: =?shift-jis?B?aW5mb3JtYXRpb24=?= To: X-Mailer: Microsoft Outlook Express MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C6C53A.5B672820" X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 2.6 (++) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 This is a multi-part message in MIME format. ------=_NextPart_000_0006_01C6C53A.5B672820 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: base64 GyRCISEiLkV2JTUlJCVIJCskaSROJCpDTiRpJDskRyQ5Ii4bKEINCmh0dHA6Ly92aWZuLmNvbS8/ aGFydTIxMg0KDQoNChskQiEhISEiIyQ0TXhNUTBGRmIiIxsoQg0KGyRCISZFUE8/JE80MEE0TDVO QSFKGyhCMjQbJEI7fjRWISFFUE8/PHUkMUlVJDFDZiEqIUsbKEINChskQiEmGyhCRnJlZRskQiUi JUklbCU5JEckNE14TVEkJCQ/JEAkMSReJDkbKEINChskQiEmN0hCUyEiJVElPSUzJXMkSSRBJGkk SyRiQlAxfiEqGyhCDQobJEIhISFKQlQkQTlnJG8kOyROO34kS0pYTXgkSjRKQzEkKkNOJGkkOzUh Rz1JVSQtJEckOSFLGyhCDQobJEIhJkxCT0clYSE8JWtLSTtfNSFHPUlVJEcwQj80JEckORsoQg0K GyRCISEiKEt8JCwwbCEiJCo1Uk1NJEclSCVpJVYlayQsQDgkOCQ/Pmw5ZyRPJTUlJCVIJEskKkxk JCQ5ZyRvJDsyPCQ1JCQhIxsoQg0KGyRCISEiKCMyIzQ7fjRWQlAxfiQ3JEYkKiRqJF4kOSEjGyhC DQobJEIhWiQqTGQkJDlnJG8kOyFbIk0hIRsoQmh0dHA6Ly92aWZuLmNvbS8/aGFydTIxMg0KDQoN ChskQiF5IXkheT13QC0kTjxMJWEkTzgrSnxCaiEqRUVPQ0hWOWYhIkQ+JSIlSSROOHI0OSRPNDBB NDwrTTMheSF5IXkbKEINChskQiEhISFAJ0hzJDMkTjUhMnEkS0FHRSgkSj1QMnEkJCRyOCskRCQx JEYkTyRJJCYkRyQ3JGckJiQrISkbKEINCg0KGyRCISEiIyU1JSQlSBsoQlVSTBskQiEnISEbKEJo dHRwOi8vdmlmbi5jb20vP2hhcnUyMTINCg0KDQoNChskQiF5IXkoLCgsKCwoLCgsKCwoLCgsKCwo LCgsKCwoLCgsKCwoLCgsKCwoLCgsKCwoLCgsKCwoLCgsKCwoLBsoQg0KDQobJEJHWz8uSVRNVyRP JDMkQSRpJF4kRyIqISEbKEJvZmZpY2VfbmV3c19oaW1pdHN1QHlhaG9vLmNvLmpwDQoNChskQiEh GyhCcmVmdXNlIGFuIGVtYWlsGyRCIiohIRsoQm9mZmljZV9uZXdzX2hpbWl0c3VAeWFob28uY28u anA= ------=_NextPart_000_0006_01C6C53A.5B672820 Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWlzby0yMDIyLWpwIj4NCjxNRVRBIGNvbnRlbnQ9Ik1TSFRN TCA2LjAwLjI5MDAuMjE4MCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVB RD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZiBiYWNrZ3JvdW5kPSIiPjxGT05UIGZhY2U9Ik1TIFVJ IEdvdGhpYyIgc2l6ZT0yPg0KPERJVj48Rk9OVCBzaXplPTQ+GyRCISEbKEI8Rk9OVCBjb2xvcj0j ZmYwMDAwPhskQiIuGyhCPC9GT05UPhskQkV2JTUlJCVIJCskaSROJCpDTiRpJDskRyQ5GyhCPC9G T05UPjxGT05UIA0Kc2l6ZT00PjxGT05UIGNvbG9yPSNmZjAwMDA+GyRCIi4bKEI8L0ZPTlQ+PEJS PjwvRk9OVD48Rk9OVCBmYWNlPRskQkFXQk4bKEI+PEEgDQpocmVmPSJodHRwOi8vdmlmbi5jb20v P2hhcnUyMTIiPmh0dHA6Ly92aWZuLmNvbS8/aGFydTIxMjwvQT48L0ZPTlQ+PEZPTlQgDQpzaXpl PTM+PC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEJSPjxGT05UIA0Kc2l6 ZT0zPhskQiEhISEiIyQ0TXhNUTBGRmIiIxsoQjxCUj4bJEIhJkVQTz8kTzQwQTRMNU5BIUobKEIy NBskQjt+NFYhIUVQTz88dSQxSVUkMUNmISohSxsoQjxCUj4bJEIhJhsoQkZyZWUbJEIlIiVJJWwl OSRHJDRNeE1RJCQkPyRAJDEkXiQ5GyhCPEJSPhskQiEmN0hCUyEiJVElPSUzJXMkSSRBJGkkSyRi QlAxfiEqGyhCPEJSPhskQiEhIUpCVCRBOWckbyQ7JE47fiRLSlhNeCRKNEpDMSQqQ04kaSQ7NSFH PUlVJC0kRyQ5IUsbKEI8QlI+GyRCISZMQk9HJWEhPCVrS0k7XzUhRz1JVSRHMEI/NCRHJDkbKEI8 QlI+GyRCISEiKEt8JCwwbCEiJCo1Uk1NJEclSCVpJVYlayQsQDgkOCQ/Pmw5ZyRPJTUlJCVIJEsk KkxkJCQ5ZyRvJDsyPCQ1JCQhIxsoQjxCUj4bJEIhISIoIzIjNDt+NFZCUDF+JDckRiQqJGokXiQ5 ISMbKEI8QlI+PC9GT05UPjxGT05UIA0Kc2l6ZT0yPhskQiFaGyhCPEZPTlQgY29sb3I9I2ZmMDAw MD4bJEIkKkxkJCQ5ZyRvJDsbKEI8L0ZPTlQ+GyRCIVsiTSEhGyhCPEEgDQpocmVmPSJodHRwOi8v dmlmbi5jb20vP2hhcnUyMTIiPmh0dHA6Ly92aWZuLmNvbS8/aGFydTIxMjwvQT48L0ZPTlQ+PC9E SVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48QlI+PEZPTlQgDQpzaXplPTM+GyRCIXkheSF5 PXdALSROPEwlYSRPOCtKfEJqISpFRU9DSFY5ZiEiRD4lIiVJJE44cjQ5JE80MEE0PCtNMyF5IXkh eRsoQjxCUj4bJEIhISEhQCdIcyQzJE41ITJxJEtBR0UoJEo9UDJxJCQkcjgrJEQkMSRGJE8kSSQm JEckNyRnJCYkKyEpGyhCPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTM+PC9GT05UPiZu YnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTM+GyRCISEiIyU1JSQlSBsoQlVSTBskQiEnISEb KEI8QSANCmhyZWY9Imh0dHA6Ly92aWZuLmNvbS8/aGFydTIxMiI+aHR0cDovL3ZpZm4uY29tLz9o YXJ1MjEyPC9BPjwvRk9OVD48Rk9OVCANCnNpemU9Mz48L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNw OzwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05U IHNpemU9Mz4bJEIheSF5KCwoLCgsKCwoLCgsKCwoLCgsKCwoLCgsKCwoLCgsKCwoLCgsKCwoLCgs KCwoLCgsKCwoLCgsKCwbKEI8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mz48L0ZPTlQ+ Jm5ic3A7PC9ESVY+DQo8RElWPhskQkdbPy5JVE1XJE8kMyRBJGkkXiRHIiohIRsoQjxBIA0KaHJl Zj0ibWFpbHRvOm9mZmljZV9uZXdzX2hpbWl0c3VAeWFob28uY28uanAiPm9mZmljZV9uZXdzX2hp bWl0c3VAeWFob28uY28uanA8L0E+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4bJEIh IRsoQnJlZnVzZSBhbiBlbWFpbBskQiIqISEbKEI8QSANCmhyZWY9Im1haWx0bzpvZmZpY2VfbmV3 c19oaW1pdHN1QHlhaG9vLmNvLmpwIj5vZmZpY2VfbmV3c19oaW1pdHN1QHlhaG9vLmNvLmpwPC9B PjwvRk9OVD48L0RJVj48L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_0006_01C6C53A.5B672820-- From ips-bounces@ietf.org Sun Sep 10 15:51:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMVKV-0005Xu-EI; Sun, 10 Sep 2006 15:50:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMVKA-0004d6-Ks; Sun, 10 Sep 2006 15:50:38 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GMVKA-0000iz-Hi; Sun, 10 Sep 2006 15:50:38 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GMVK4-0007ZJ-Rk; Sun, 10 Sep 2006 15:50:38 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 87720175EA; Sun, 10 Sep 2006 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GMVJa-00062z-3q; Sun, 10 Sep 2006 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Sun, 10 Sep 2006 15:50:02 -0400 X-Spam-Score: -5.9 (-----) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: ips@ietf.org Subject: [Ips] I-D ACTION:draft-ietf-ips-iscsi-nodearch-key-01.txt X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org --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 : Declarative Public Extension Key for iSCSI Node Architecture Author(s) : D. Wysochanski Filename : draft-ietf-ips-iscsi-nodearch-key-01.txt Pages : 12 Date : 2006-9-10 The iSCSI protocol, described in RFC 3720 [2], allows for extension items to the protocol in the form of Private or Public Extension Keys. This Internet-Draft describes a Public Extension Key for the purpose of enhancing iSCSI supportability. The key accomplishes this objective by allowing iSCSI nodes to communicate architecture details during the iSCSI login sequence. The receiving node can then use this information for enhanced logging and support. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-nodearch-key-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-iscsi-nodearch-key-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-iscsi-nodearch-key-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: <2006-9-10110147.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-iscsi-nodearch-key-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-iscsi-nodearch-key-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-9-10110147.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --NextPart-- From ips-bounces@ietf.org Sun Sep 10 20:11:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMZNr-0008Vw-7I; Sun, 10 Sep 2006 20:10:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMZNp-0008Vq-VA for ips@ietf.org; Sun, 10 Sep 2006 20:10:41 -0400 Received: from bay0-omc1-s26.bay0.hotmail.com ([65.54.246.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GMZNo-0006QO-ME for ips@ietf.org; Sun, 10 Sep 2006 20:10:41 -0400 Received: from hotmail.com ([65.54.250.41]) by bay0-omc1-s26.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 10 Sep 2006 17:10:40 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 10 Sep 2006 17:10:39 -0700 Message-ID: Received: from 65.54.250.200 by by115fd.bay115.hotmail.msn.com with HTTP; Mon, 11 Sep 2006 00:10:38 GMT X-Originating-IP: [70.244.122.4] X-Originating-Email: [sma78759@hotmail.com] X-Sender: sma78759@hotmail.com From: "Steve Ma" To: ips@ietf.org Bcc: Date: Mon, 11 Sep 2006 00:10:38 +0000 Mime-Version: 1.0 X-OriginalArrivalTime: 11 Sep 2006 00:10:39.0813 (UTC) FILETIME=[B6C7B750:01C6D536] X-Spam-Score: 4.0 (++++) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 Subject: [Ips] (no subject) X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1919177756==" Errors-To: ips-bounces@ietf.org --===============1919177756== Content-Type: text/html; format=flowed
Unsubscribe
--===============1919177756== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============1919177756==-- From ips-bounces@ietf.org Wed Sep 13 11:35:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNWlI-0000LR-51; Wed, 13 Sep 2006 11:34:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNWlH-0000IN-Hc for ips@ietf.org; Wed, 13 Sep 2006 11:34:51 -0400 Received: from mexforward.lss.emc.com ([128.222.32.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNWlG-00068G-9o for ips@ietf.org; Wed, 13 Sep 2006 11:34:51 -0400 Received: from mailhub.lss.emc.com (sesha.lss.emc.com [10.254.144.12]) by mexforward.lss.emc.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k8DFYno6000463 for ; Wed, 13 Sep 2006 11:34:49 -0400 (EDT) Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k8DFYNrs028289 for ; Wed, 13 Sep 2006 11:34:47 -0400 (EDT) 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.0); Wed, 13 Sep 2006 11:34:18 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 13 Sep 2006 11:34:17 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ips Working Group Last Call - Node Architecture Key draft Thread-Index: AcbXShM9ETCFt5gpTvi/YpkFk1H9dw== X-Priority: 1 Priority: Urgent Importance: high To: X-OriginalArrivalTime: 13 Sep 2006 15:34:18.0506 (UTC) FILETIME=[13B8AEA0:01C6D74A] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.9.13.81443 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -2, PRIORITY_NO_NAME 0.716, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CTE 0, __CTYPE_CHARSET_QUOTED 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_PRIORITY 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.3 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: [Ips] ips Working Group Last Call - Node Architecture Key draft X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org This is to announce an ips WG Last Call on the following draft: Declarative Public Extension Key for iSCSI Node Architecture draft-ietf-ips-iscsi-nodearch-key-01.txt =20 This WG Last Call will run through 12 midnight Eastern Time on Sunday, October 1, 2006 (your WG chair hopes to deal with the Last Call results during the week of October 2nd). Technical comments *must* be sent to the ips mailing list. Editorial comments may be sent directly to the draft editor (but please cc: me): Dave Wysochanski Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Fri Sep 15 15:51:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOJi2-0008AR-BV; Fri, 15 Sep 2006 15:50:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOJhr-0007qo-VO; Fri, 15 Sep 2006 15:50:35 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOJhr-00011A-Sc; Fri, 15 Sep 2006 15:50:35 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GOJhp-0003wh-0A; Fri, 15 Sep 2006 15:50:35 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id B187A175D1; Fri, 15 Sep 2006 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GOJhK-0007Or-9F; Fri, 15 Sep 2006 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 15 Sep 2006 15:50:02 -0400 X-Spam-Score: -5.9 (-----) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: ips@ietf.org Subject: [Ips] I-D ACTION:draft-ietf-ips-iscsi-impl-guide-03.txt X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org --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 : iSCSI Implementer's Guide Author(s) : M. Chadalapaka Filename : draft-ietf-ips-iscsi-impl-guide-03.txt,.pdf Pages : 32 Date : 2006-9-15 iSCSI is a SCSI transport protocol and maps the SCSI family of application protocols onto TCP/IP. RFC 3720 defines the iSCSI protocol. This document compiles the clarifications to the original protocol definition in RFC 3720 to serve as a companion document for the iSCSI implementers. This document updates RFC 3720 and the text in this document supersedes the text in RFC 3720 when the two differ. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-impl-guide-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-iscsi-impl-guide-03.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-iscsi-impl-guide-03.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: <2006-9-15125349.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-iscsi-impl-guide-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-iscsi-impl-guide-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-9-15125349.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --NextPart-- From ips-bounces@ietf.org Tue Sep 19 12:14:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPiDI-00010J-O3; Tue, 19 Sep 2006 12:12:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPiDH-0000zr-Gv for ips@ietf.org; Tue, 19 Sep 2006 12:12:47 -0400 Received: from ausc60ps301.us.dell.com ([143.166.148.206]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPiDE-0006ev-5e for ips@ietf.org; Tue, 19 Sep 2006 12:12:47 -0400 DomainKey-Signature: s=smtpout; d=dell.com; c=nofws; q=dns; b=QB+nrLpUXaKz9Fq2+uc6jY2vKw1OCR2LkMql0olyzNVuNtDov/iAtXdmay4q5KzhzKnQehVu/Ala1a34VgyJE/J55KGkQWJ7A+M+1jTF/NLJYJKmzzJuAaXjrowDMbvK; Received: from ausx3bpc101.aus.amer.dell.com ([10.30.101.51]) by ausc60ps301.us.dell.com with ESMTP; 19 Sep 2006 11:12:41 -0500 X-IronPort-AV: i="4.09,186,1157346000"; d="scan'208"; a="82943594:sNHT50160195" X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 19 Sep 2006 11:12:41 -0500 Message-ID: <389040536173ED4AADA5EFEA96333586016788F5@ausx3mpc106.aus.amer.dell.com> In-Reply-To: <17484.54828.106000.849356@gargle.gargle.HOWL> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Initiator Task Tag Thread-Index: AcZnpS7v/yoMPHbtQZGg2KmemOBGjB0YDkPw From: To: X-OriginalArrivalTime: 19 Sep 2006 16:12:41.0629 (UTC) FILETIME=[6EF7DCD0:01C6DC06] X-Spam-Score: 0.2 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Subject: [Ips] Initiator Task Tag X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org Should the Initiator task tag be unique for an I_T nexus or for an I_T_L nexus? Section 3.2.1 says: Initiator identifying elements, such as the Initiator Task Tag, are global across the session regardless of the connection on which they are sent or received. and=20 Sections 10.2.1.8 says: While a task exists, this tag MUST uniquely identify the task session-wide. SCSI may also use the initiator task tag as part of the SCSI task identifier when the timespan during which an iSCSI initiator task tag must be unique extends over the timespan during which a SCSI task tag must be unique. (which seems to imply I_T nexus wide uniqueness) Section 3.5.1.1 says: IN arguments such as task attributes, Expected Data Transfer Length for one or both transfer directions (the latter for bidirectional commands), and Task Tag (as part of the I_T_L_x nexus). (which seems to follow the broadest definition allowed by SAM) What was the intention of the designers? Thanks, Jacob=20 _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Tue Sep 19 17:02:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPmjW-00078u-B2; Tue, 19 Sep 2006 17:02:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPmjV-00078p-2l for ips@ietf.org; Tue, 19 Sep 2006 17:02:21 -0400 Received: from mexforward.lss.emc.com ([128.222.32.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPmjS-0008Qr-Nh for ips@ietf.org; Tue, 19 Sep 2006 17:02:21 -0400 Received: from mailhub.lss.emc.com (sesha.lss.emc.com [10.254.144.12]) by mexforward.lss.emc.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k8JL2DpL007556; Tue, 19 Sep 2006 17:02:13 -0400 (EDT) Received: from corpussmtp2.corp.emc.com (corpussmtp2.corp.emc.com [128.221.14.146]) by mailhub.lss.emc.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k8JL25jG003021; Tue, 19 Sep 2006 17:02:10 -0400 (EDT) From: Black_David@emc.com Received: from CORPUSMX20A.corp.emc.com ([128.221.62.13]) by corpussmtp2.corp.emc.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 19 Sep 2006 17:01:59 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ips] Initiator Task Tag Date: Tue, 19 Sep 2006 17:01:59 -0400 Message-ID: In-Reply-To: <389040536173ED4AADA5EFEA96333586016788F5@ausx3mpc106.aus.amer.dell.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ips] Initiator Task Tag Thread-Index: AcZnpS7v/yoMPHbtQZGg2KmemOBGjB0YDkPwAAok/qA= To: , X-OriginalArrivalTime: 19 Sep 2006 21:01:59.0653 (UTC) FILETIME=[D9282150:01C6DC2E] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.9.19.133442 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -2, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CTE 0, __CTYPE_CHARSET_QUOTED 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.2 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org Jacob, An iSCSI session is an I_T nexus - see the definitions of session and I_T nexus in section 2.1 of RFC 3720. Hence initiator task tags have to be unique across an I_T nexus. The language in Section 3.5.1.1 says that to identify a specific SCSI command (I_T_L_x nexus), one needs the Task Tag to identify the command. In other words, session (I_T nexus) + ITT identifies a specific command (I_T_L_x nexus). If you need to know the LUN (L), the command will contain that information. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- > -----Original Message----- > From: Jacob_Cherian@Dell.com [mailto:Jacob_Cherian@Dell.com]=20 > Sent: Tuesday, September 19, 2006 12:13 PM > To: ips@ietf.org > Subject: [Ips] Initiator Task Tag >=20 > Should the Initiator task tag be unique for an I_T nexus or for an I_T_L > nexus? >=20 > Section 3.2.1 says: > Initiator identifying elements, such as the Initiator Task Tag, are > global across the session regardless of the connection on which they are > sent or received. >=20 > and=20 >=20 > Sections 10.2.1.8 says: > While a task exists, this tag MUST uniquely identify the task session-wide. > SCSI may also use the initiator task tag as part of the SCSI task > identifier when the timespan during which an iSCSI initiator task tag > must be unique extends over the timespan during which a SCSI task tag > must be unique. >=20 > (which seems to imply I_T nexus wide uniqueness) >=20 >=20 >=20 > Section 3.5.1.1 says: > IN arguments such as task attributes, Expected Data Transfer Length for > one or both transfer directions (the latter for bidirectional commands), > and Task Tag (as part of the I_T_L_x nexus). >=20 > (which seems to follow the broadest definition allowed by SAM) >=20 >=20 > What was the intention of the designers? >=20 >=20 > Thanks, > Jacob=20 >=20 > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips >=20 _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Tue Sep 19 17:08:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPmon-0001WZ-5t; Tue, 19 Sep 2006 17:07:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPmol-0001WS-UO for ips@ietf.org; Tue, 19 Sep 2006 17:07:47 -0400 Received: from mononoke.wasabisystems.com ([66.173.145.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPmoj-0000qK-Lo for ips@ietf.org; Tue, 19 Sep 2006 17:07:47 -0400 Received: from [10.0.0.10] (h-66-166-188-91.sndacagl.covad.net [66.166.188.91]) by mononoke.wasabisystems.com (Postfix) with ESMTP id D5DF687193; Tue, 19 Sep 2006 17:07:42 -0400 (EDT) In-Reply-To: <389040536173ED4AADA5EFEA96333586016788F5@ausx3mpc106.aus.amer.dell.com> References: <389040536173ED4AADA5EFEA96333586016788F5@ausx3mpc106.aus.amer.dell.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <499B39E9-98A4-4D34-9563-DC225562DD37@wasabisystems.com> Content-Transfer-Encoding: 7bit From: William Studenmund Subject: Re: [Ips] Initiator Task Tag Date: Tue, 19 Sep 2006 14:07:38 -0700 To: X-Pgp-Agent: GPGMail 1.1.2 (Tiger) X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sep 19, 2006, at 9:12 AM, wrote: > Should the Initiator task tag be unique for an I_T nexus or for an > I_T_L > nexus? They are session-unique. The difference is that they have meaning for iSCSI operations in addition to SCSI ones. > Section 3.2.1 says: > Initiator identifying elements, such as the Initiator Task Tag, are > global across the session regardless of the connection on which > they are > sent or received. > > and > > Sections 10.2.1.8 says: > While a task exists, this tag MUST uniquely identify the task > session-wide. > SCSI may also use the initiator task tag as part of the SCSI task > identifier when the timespan during which an iSCSI initiator task tag > must be unique extends over the timespan during which a SCSI task tag > must be unique. > > (which seems to imply I_T nexus wide uniqueness) That definition is good-enough. :-) > Section 3.5.1.1 says: > IN arguments such as task attributes, Expected Data Transfer Length > for > one or both transfer directions (the latter for bidirectional > commands), > and Task Tag (as part of the I_T_L_x nexus). I don't see how this disagrees. The I_T_L_x nexus is the task. The specific value of the ITT is an attribute of the task. That it (the ITT) is an attribute of the task doesn't mean that it is only scoped to the I_T_L level. Take care, Bill -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFFEFwfDJT2Egh26K0RAuKdAKCcbJt6Otbgemjyf6K2nHf9bcZD0wCgk/pN z9vUHQImWhti0ldTtq2VIk4= =tfDc -----END PGP SIGNATURE----- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Wed Sep 20 08:33:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ1GZ-000304-Mp; Wed, 20 Sep 2006 08:33:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ1GX-0002zy-Vk for ips@ietf.org; Wed, 20 Sep 2006 08:33:25 -0400 Received: from mtagate5.de.ibm.com ([195.212.29.154]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQ1GW-0007ow-Dl for ips@ietf.org; Wed, 20 Sep 2006 08:33:25 -0400 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 k8KCXNUj074882 for ; Wed, 20 Sep 2006 12:33:23 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id k8KCcAgc3068034 for ; Wed, 20 Sep 2006 14:38:10 +0200 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id k8KCXNU2028453 for ; Wed, 20 Sep 2006 14:33:23 +0200 Received: from d12mc102.megacenter.de.ibm.com (d12mc102.megacenter.de.ibm.com [9.149.167.114]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k8KCXMeU028447; Wed, 20 Sep 2006 14:33:23 +0200 In-Reply-To: <389040536173ED4AADA5EFEA96333586016788F5@ausx3mpc106.aus.amer.dell.com> To: MIME-Version: 1.0 Subject: Re: [Ips] Initiator Task Tag X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 From: Julian Satran Message-ID: Date: Wed, 20 Sep 2006 15:38:08 +0300 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 7.0.1HF269 | June 22, 2006) at 20/09/2006 15:38:09, Serialize complete at 20/09/2006 15:38:09 X-Spam-Score: 0.1 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0513177331==" Errors-To: ips-bounces@ietf.org This is a multipart message in MIME format. --===============0513177331== Content-Type: multipart/alternative; boundary="=_alternative 0044F732C22571EF_=" This is a multipart message in MIME format. --=_alternative 0044F732C22571EF_= Content-Type: text/plain; charset="US-ASCII" ITT has to be I_T unique. TTT has to be just I_T_L unique (TTT is mostly a "target convenience" artifact). Julo 19/09/06 19:12 To cc Subject [Ips] Initiator Task Tag Should the Initiator task tag be unique for an I_T nexus or for an I_T_L nexus? Section 3.2.1 says: Initiator identifying elements, such as the Initiator Task Tag, are global across the session regardless of the connection on which they are sent or received. and Sections 10.2.1.8 says: While a task exists, this tag MUST uniquely identify the task session-wide. SCSI may also use the initiator task tag as part of the SCSI task identifier when the timespan during which an iSCSI initiator task tag must be unique extends over the timespan during which a SCSI task tag must be unique. (which seems to imply I_T nexus wide uniqueness) Section 3.5.1.1 says: IN arguments such as task attributes, Expected Data Transfer Length for one or both transfer directions (the latter for bidirectional commands), and Task Tag (as part of the I_T_L_x nexus). (which seems to follow the broadest definition allowed by SAM) What was the intention of the designers? Thanks, Jacob _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --=_alternative 0044F732C22571EF_= Content-Type: text/html; charset="US-ASCII"
ITT has to be  I_T unique. TTT has to be just I_T_L unique (TTT is mostly a "target convenience" artifact). Julo


<Jacob_Cherian@Dell.com>

19/09/06 19:12

To
<ips@ietf.org>
cc
Subject
[Ips] Initiator Task Tag





Should the Initiator task tag be unique for an I_T nexus or for an I_T_L
nexus?

Section 3.2.1 says:
Initiator identifying elements, such as the Initiator Task Tag, are
global across the session regardless of the connection on which they are
sent or received.

and

Sections 10.2.1.8 says:
While a task exists, this tag MUST uniquely identify the task
session-wide.
SCSI may also use the initiator task tag as part of the SCSI task
identifier when the timespan during which an iSCSI initiator task tag
must be unique extends over the timespan during which a SCSI task tag
must be unique.

(which seems to imply I_T nexus wide uniqueness)



Section 3.5.1.1 says:
IN arguments such as task attributes, Expected Data Transfer Length for
one or both transfer directions (the latter for bidirectional commands),
and Task Tag (as part of the I_T_L_x nexus).

(which seems to follow the broadest definition allowed by SAM)


What was the intention of the designers?


Thanks,
Jacob

_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips
--=_alternative 0044F732C22571EF_=-- --===============0513177331== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0513177331==-- From ips-bounces@ietf.org Tue Sep 26 05:12:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GS8yZ-0005q5-4I; Tue, 26 Sep 2006 05:11:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GS8yY-0005pz-8X for ips@ietf.org; Tue, 26 Sep 2006 05:11:38 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GS8yX-0006rK-Bp for ips@ietf.org; Tue, 26 Sep 2006 05:11:38 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 26 Sep 2006 02:11:36 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8Q9Bahq016666; Tue, 26 Sep 2006 02:11:36 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k8Q9BaQV018283; Tue, 26 Sep 2006 02:11:36 -0700 (PDT) Received: from xmb-sjc-228.amer.cisco.com ([128.107.191.125]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Sep 2006 02:11:36 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ips] Re-sending a command Date: Tue, 26 Sep 2006 02:11:34 -0700 Message-ID: <35B3FBF7A0B5A14BA6E092D25B35298602D06A62@xmb-sjc-228.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ips] Re-sending a command Thread-Index: Aca8bAaw03aGph8aQ+qfOTKzK1msZAk3VeQg From: "Ashish Shah \(ashishs\)" To: "Eddy Quicksall" , "Julian Satran" X-OriginalArrivalTime: 26 Sep 2006 09:11:36.0012 (UTC) FILETIME=[C460E8C0:01C6E14B] DKIM-Signature: a=rsa-sha1; q=dns; l=22302; t=1159261896; x=1160125896; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ashishs@cisco.com; z=From:=22Ashish=20Shah=20\(ashishs\)=22=20 |Subject:RE=3A=20[Ips]=20Re-sending=20a=20command; X=v=3Dcisco.com=3B=20h=3Ddw3Llw6UuyWmptkRZZ3ZOyq9CiQ=3D; b=XReG7ZiwFew4ri4OLdrY2ebG8PShRast0RmlOf0yHb2YywpjynfcZd2qcI9hu0SLUkyWbdos /r71cwl4Fyz6pGK5bktTvhRh77+Ruh20y4JQ+ZUFLCpHPpRINyNaFxwE; Authentication-Results: sj-dkim-2.cisco.com; header.From=ashishs@cisco.com; dkim=pass ( 59 extraneous bytes; sig from cisco.com verified; ); X-Spam-Score: 0.2 (/) X-Scan-Signature: d424907374faffed8e9e11e94f671eb2 Cc: ips@ietf.org, Amit Kumar , "Arpakorn Boonkongchuen \(aboonkon\)" X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1241810966==" Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============1241810966== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6E14B.C4278FF6" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6E14B.C4278FF6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 I have a question that is a slight variation to this example.=20 =20 I->T: CmdSN=3D25 ITT=3D1 SCSI1 I->T: CmdSN=3D26 ITT=3D2 SCSI1