From ips-bounces@ietf.org Wed Jan 02 13:27:44 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JA8Ja-0002bo-GW; Wed, 02 Jan 2008 13:27:42 -0500 Received: from ips by megatron.ietf.org with local (Exim 4.43) id 1JA8JZ-0002bj-LH for ips-confirm+ok@megatron.ietf.org; Wed, 02 Jan 2008 13:27:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JA8JZ-0002bb-BD for ips@ietf.org; Wed, 02 Jan 2008 13:27:41 -0500 Received: from mexforward.lss.emc.com ([128.222.32.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JA8JY-00079w-DG for ips@ietf.org; Wed, 02 Jan 2008 13:27:41 -0500 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 m02IRdhY017633 for ; Wed, 2 Jan 2008 13:27:39 -0500 (EST) Received: from mailhub.lss.emc.com (uraeus.lss.emc.com [10.254.144.14]) by hop04-l1d11-si02.isus.emc.com (Tablus Interceptor) for ; Wed, 2 Jan 2008 13:27:39 -0500 Received: from corpussmtp4.corp.emc.com (corpussmtp4.corp.emc.com [10.254.64.54]) by mailhub.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id m02IRZDP026830 for ; Wed, 2 Jan 2008 13:27:37 -0500 (EST) From: Sears_Bill@emc.com Received: from CORPUSMX40A.corp.emc.com ([10.254.64.48]) by corpussmtp4.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 2 Jan 2008 13:27:37 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 2 Jan 2008 13:27:31 -0500 Message-ID: <83FD3BD6BD6165418CE12A050B5E3B761B0A92@CORPUSMX40A.corp.emc.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: LUN field in R2T thread-index: AchNbSMPJWDKKt1wSSiZ1D9qXLiETw== To: X-OriginalArrivalTime: 02 Jan 2008 18:27:37.0214 (UTC) FILETIME=[267699E0:01C84D6D] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.8.30.51425 X-PerlMx-Spam: Gauge=, SPAM=1%, Reason='EMC_FROM_0+ -3, HTML_70_90 0.1, NO_REAL_NAME 0, __CT 0, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0, __CTYPE_MULTIPART_ALT 0, __HAS_MSGID 0, __HTML_FONT_BLUE 0, __HTML_MSWORD 0, __IMS_MSGID 0, __MIME_HTML 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_PHRASE_25 0, __TAG_EXISTS_HTML 0' X-Tablus-Inspected: yes X-Tablus-Classifications: public X-Tablus-Action: allow X-Spam-Score: -4.0 (----) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Subject: [Ips] LUN field in R2T 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="===============0100136770==" Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============0100136770== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C84D6D.22EEE7BB" This is a multi-part message in MIME format. ------_=_NextPart_001_01C84D6D.22EEE7BB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Just a quick clarification: =20 10.8.5. Target Transfer Tag [...]The Target Transfer Tag and LUN are copied in the outgoing data PDUs and are only used by the target. =20 Does this mean that the LUN field in the R2T does not need to contain the actual LUN number specified by the SCSI write? Since the field is "only used by the target" I assume this text means that the target may place anything it wants in the LUN field of the R2T and have it echoed back by the initiator. =20 ------_=_NextPart_001_01C84D6D.22EEE7BB Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Just a quick = clarification:

 

10.8.5.  Target Transfer = Tag

[...]The Target Transfer Tag and LUN are copied in = the outgoing data PDUs and are only used by the = target.

 

Does this mean that the LUN field in the R2T does not = need to contain the actual LUN number specified by the SCSI = write?   Since the field is “only used by the target” I assume this text = means that the target may place anything it wants in the LUN field of the R2T = and have it echoed back by the initiator.

 

------_=_NextPart_001_01C84D6D.22EEE7BB-- --===============0100136770== 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 --===============0100136770==-- From ips-bounces@ietf.org Wed Jan 02 17:19:44 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JABw5-0004m8-Vg; Wed, 02 Jan 2008 17:19:41 -0500 Received: from ips by megatron.ietf.org with local (Exim 4.43) id 1JABw3-0004ls-UC for ips-confirm+ok@megatron.ietf.org; Wed, 02 Jan 2008 17:19:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JABw3-0004lk-KU for ips@ietf.org; Wed, 02 Jan 2008 17:19:39 -0500 Received: from noteserv1.attotech.com ([208.69.85.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JABw1-0003mn-8T for ips@ietf.org; Wed, 02 Jan 2008 17:19:39 -0500 In-Reply-To: <83FD3BD6BD6165418CE12A050B5E3B761B0A92@CORPUSMX40A.corp.emc.com> To: Sears_Bill@emc.com Subject: Re: [Ips] LUN field in R2T MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.2 September 26, 2006 Message-ID: From: dcuddihy@attotech.com Date: Wed, 2 Jan 2008 17:19:36 -0500 X-MIMETrack: Serialize by Router on NOTESERV1/SERV/ATTO(Release 7.0.2FP1|January 10, 2007) at 01/02/2008 05:19:37 PM, Serialize complete at 01/02/2008 05:19:37 PM X-Spam-Score: 0.0 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 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="===============1825667025==" Errors-To: ips-bounces@ietf.org This is a multipart message in MIME format. --===============1825667025== Content-Type: multipart/alternative; boundary="=_alternative 007AA4C1852573C4_=" This is a multipart message in MIME format. --=_alternative 007AA4C1852573C4_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Hi Bill, I know from experience that some initiators will fill in the LUN field in=20 the data out with the actual LUN specified in the SCSI write.=20 While that may not be compliant with 10.8.5, you may see interop problems=20 if you're depending on the initiator to echo that LUN back to you. regards, david Java: The elegant simplicity of C++=20 and the blazing speed of smalltalk. David J Cuddihy Principal Engineer ATTO Technology, Inc. (716) 691-1999 x157=20 www.attotech.com Power Behind the Storage Sears=5FBill@emc.com=20 01/02/2008 01:28 PM To cc Subject [Ips] LUN field in R2T Just a quick clarification: =20 10.8.5. Target Transfer Tag [...]The Target Transfer Tag and LUN are copied in the outgoing data PDUs=20 and are only used by the target. =20 Does this mean that the LUN field in the R2T does not need to contain the=20 actual LUN number specified by the SCSI write? Since the field is ?only=20 used by the target? I assume this text means that the target may place=20 anything it wants in the LUN field of the R2T and have it echoed back by=20 the initiator. =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --=_alternative 007AA4C1852573C4_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Bill,

I know from experience that some ini= tiators will fill in the LUN field in the data out with the actual LUN specified in the SCSI write.  

While that may not be compliant with 10.8.5, you may see interop problems if you're depending on the initiator to echo that LUN back to you.


regards,

david


Java: The elegant simplicity of C++
and the blazing speed of smalltalk.

David J Cuddihy
Principal Engineer
ATTO Technology, Inc.
(716) 691-1999 x157

www.attotech.com
Power Behind the Storage


Sears=5FBill@emc.com<= /b>

01/02/2008 01:28 PM

To
<ips@ietf.org>
cc
Subject
[Ips] LUN field in R2T





Just a quick clarification:
 
10.8.5.  Target Transfer Tag
[...]The Target Transfer Tag and LUN are copied in the outgoing data PDUs and are only used by the target.
 
Does this mean that the LUN field in the R2T does not need to contain the actual LUN number specified by the SCSI write?   Since the field is “only used by the target” I as= sume this text means that the target may place anything it wants in the LUN field of the R2T and have it echoed back by the initiator.
 =5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips
--=_alternative 007AA4C1852573C4_=-- --===============1825667025== 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 --===============1825667025==-- From ips-bounces@ietf.org Thu Jan 03 04:11:48 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAM76-0004AB-16; Thu, 03 Jan 2008 04:11:44 -0500 Received: from ips by megatron.ietf.org with local (Exim 4.43) id 1JAM75-00044F-82 for ips-confirm+ok@megatron.ietf.org; Thu, 03 Jan 2008 04:11:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAM74-000446-Tu for ips@ietf.org; Thu, 03 Jan 2008 04:11:42 -0500 Received: from mtagate1.de.ibm.com ([195.212.29.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JAM71-0003gX-2G for ips@ietf.org; Thu, 03 Jan 2008 04:11:42 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate1.de.ibm.com (8.13.8/8.13.8) with ESMTP id m039BYlm139754 for ; Thu, 3 Jan 2008 09:11:34 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 m039BY1i2588818 for ; Thu, 3 Jan 2008 10:11:34 +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 m039BX63010490 for ; Thu, 3 Jan 2008 10:11:34 +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 m039BX0p010487; Thu, 3 Jan 2008 10:11:33 +0100 In-Reply-To: <83FD3BD6BD6165418CE12A050B5E3B761B0A92@CORPUSMX40A.corp.emc.com> To: Sears_Bill@emc.com Subject: Re: [Ips] LUN field in R2T MIME-Version: 1.0 X-KeepSent: 8D1DE537:DC30EE1A-652573C5:0031D1BD; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 7.0.3 September 26, 2007 From: Julian Satran Message-ID: Date: Thu, 3 Jan 2008 14:41:32 +0530 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 8.0|August 02, 2007) at 03/01/2008 11:11:33, Serialize complete at 03/01/2008 11:11:33 X-Spam-Score: -4.0 (----) X-Scan-Signature: 2086112c730e13d5955355df27e3074b 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="===============1049931109==" Errors-To: ips-bounces@ietf.org This is a multipart message in MIME format. --===============1049931109== Content-Type: multipart/alternative; boundary="=_alternative 00327BE4652573C5_=" This is a multipart message in MIME format. --=_alternative 00327BE4652573C5_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Your interpretation is more liberal than the text says. The reason for=20 requiring a LUN field in the first place was to remove the requirement for = a target-wide unique TTT and enable distributed targets that do not=20 require coordination. The reason LUN was chosen to tag the R2T is that it = may simplify routing of the data to the appropriate destination. But since it is called LUN some zealous initiator may check (although it=20 is not mandated) the LUN validity versus a list obtained otherwise - so I=20 would not go for a very liberal interpretation. Julo Sears=5FBill@emc.com=20 01/02/08 11:57 PM To cc Subject [Ips] LUN field in R2T Just a quick clarification: =20 10.8.5. Target Transfer Tag [...]The Target Transfer Tag and LUN are copied in the outgoing data PDUs=20 and are only used by the target. =20 Does this mean that the LUN field in the R2T does not need to contain the=20 actual LUN number specified by the SCSI write? Since the field is ?only=20 used by the target? I assume this text means that the target may place=20 anything it wants in the LUN field of the R2T and have it echoed back by=20 the initiator. =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --=_alternative 00327BE4652573C5_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
Your interpretation is more liberal than the text says. The reason for requiring a LUN field in the first place was to remove the requirement for a  target-wide unique TTT and enable distributed targets that do not require coordination.  The reason LUN was chosen to tag the R2T is that it may simplify routing of the data to the appropriate destination.
But since it is called LUN some zeal= ous initiator may check (although it is not mandated) the LUN validity versus a list obtained otherwise - so I would not go for a very liberal interpreta= tion.

Julo


Sears=5FBill@emc.com<= /b>

01/02/08 11:57 PM

To
<ips@ietf.org>
cc
Subject
[Ips] LUN field in R2T





Just a quick clarification:
 
10.8.5.  Target Transfer Tag
[...]The Target Transfer Tag and LUN are copied in the outgoing data PDUs and are only used by the target.
 
Does this mean that the LUN field in the R2T does not need to contain the actual LUN number specified by the SCSI write?   Since the field is “only used by the target” I as= sume this text means that the target may place anything it wants in the LUN field of the R2T and have it echoed back by the initiator.
 =5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips
--=_alternative 00327BE4652573C5_=-- --===============1049931109== 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 --===============1049931109==-- From ips-bounces@ietf.org Thu Jan 03 16:06:43 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAXGz-0002BB-SC; Thu, 03 Jan 2008 16:06:41 -0500 Received: from ips by megatron.ietf.org with local (Exim 4.43) id 1JAXGz-0002B1-2m for ips-confirm+ok@megatron.ietf.org; Thu, 03 Jan 2008 16:06:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAXGy-0002As-Gc for ips@ietf.org; Thu, 03 Jan 2008 16:06:40 -0500 Received: from mexforward.lss.emc.com ([128.222.32.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JAXGu-0008MR-0q for ips@ietf.org; Thu, 03 Jan 2008 16:06:40 -0500 Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id m03L6ZAZ019462; Thu, 3 Jan 2008 16:06:35 -0500 (EST) Received: from mailhub.lss.emc.com (sesha.lss.emc.com [10.254.144.12]) by hop04-l1d11-si01.isus.emc.com (Tablus Interceptor); Thu, 3 Jan 2008 16:06:34 -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 m03L6QWA009060; Thu, 3 Jan 2008 16:06:32 -0500 (EST) From: Sears_Bill@emc.com Received: from CORPUSMX40A.corp.emc.com ([10.254.64.48]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 3 Jan 2008 16:06:03 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ips] LUN field in R2T Date: Thu, 3 Jan 2008 16:06:03 -0500 Message-ID: <83FD3BD6BD6165418CE12A050B5E3B761B0A9A@CORPUSMX40A.corp.emc.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ips] LUN field in R2T thread-index: AchN6PfpLZTwN8puSAOyqibNTUueSwAWbM/g To: X-OriginalArrivalTime: 03 Jan 2008 21:06:03.0971 (UTC) FILETIME=[73585930:01C84E4C] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.8.30.53115 X-PerlMx-Spam: Gauge=, SPAM=1%, Reason='EMC_FROM_0+ -3, HTML_70_90 0.1, NO_REAL_NAME 0, __CT 0, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0, __CTYPE_MULTIPART_ALT 0, __HAS_MSGID 0, __HTML_BOLD 0, __HTML_FONT_BLUE 0, __HTML_MSWORD 0, __IMS_MSGID 0, __MIME_HTML 0, __MIME_VERSION 0, __RATWARE_SIGNATURE_3_N1 0, __SANE_MSGID 0, __STOCK_PHRASE_25 0, __TAG_EXISTS_HTML 0' X-Tablus-Inspected: yes X-Tablus-Classifications: public X-Tablus-Action: allow X-Spam-Score: -4.0 (----) X-Scan-Signature: 3cb75504e283d08ef0543f38ba481a75 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="===============0129736160==" Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============0129736160== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C84E4C.72E1678B" This is a multi-part message in MIME format. ------_=_NextPart_001_01C84E4C.72E1678B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks for getting back on this. I think I still need a little clarification. =20 In a nutshell all I want to know is this: Is it legal for an initiator to set the LUN field in the Data-Out PDU based on what it knows the LUN to be, or MUST the initiator copy the contents of the LUN field from the received R2T into the Data Out.=20 =20 Example: An initiator negotiates for MaxOutstandingR2T=3D=3D4. The initiator sends a write command to a target. The initiator receives an R2T and starts sending multiple Data-Out PDUs. The initiator receives 3 more R2Ts but cannot start sending Data-Out PDUs immediately due to outbound resource limitations. The initiator must now store off each R2T request so that it can honor them when resources become available - otherwise the initiator will need to halt receive processing on the connection. The initiator will probably need to store the Target Transfer Tag, Buffer Offset, and Desired Data Transfer Length for each R2T. Does the initiator need to store the LUN from each R2T as well? Or can it just fill in the LUN in the Data Out PDUs based on knowing what LUN the command was sent to in the first place?=20 =20 Thanks, =20 =20 Bill =20 =20 =20 ________________________________ From: Julian Satran [mailto:Julian_Satran@il.ibm.com]=20 Sent: Thursday, January 03, 2008 4:12 AM To: Sears, Bill Cc: ips@ietf.org Subject: Re: [Ips] LUN field in R2T =20 Your interpretation is more liberal than the text says. The reason for requiring a LUN field in the first place was to remove the requirement for a target-wide unique TTT and enable distributed targets that do not require coordination. The reason LUN was chosen to tag the R2T is that it may simplify routing of the data to the appropriate destination.=20 But since it is called LUN some zealous initiator may check (although it is not mandated) the LUN validity versus a list obtained otherwise - so I would not go for a very liberal interpretation.=20 Julo=20 Sears_Bill@emc.com=20 01/02/08 11:57 PM=20 To =20 cc =20 Subject [Ips] LUN field in R2T =20 =20 =20 Just a quick clarification:=20 =20 10.8.5. Target Transfer Tag=20 [...]The Target Transfer Tag and LUN are copied in the outgoing data PDUs and are only used by the target.=20 =20 Does this mean that the LUN field in the R2T does not need to contain the actual LUN number specified by the SCSI write? Since the field is "only used by the target" I assume this text means that the target may place anything it wants in the LUN field of the R2T and have it echoed back by the initiator.=20 _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips =20 ------_=_NextPart_001_01C84E4C.72E1678B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks for getting back on this.   I think I still need a little = clarification.

 

In a nutshell all I want to know is = this:  Is it legal for an initiator to set the LUN field in the Data-Out PDU = based on what it knows the LUN to be, or MUST the initiator copy the contents of = the LUN field from the received R2T into the Data Out. =

 

Example:  An initiator = negotiates for MaxOutstandingR2T=3D=3D4.  The initiator sends a write command to a target.  The initiator receives an R2T and starts sending multiple Data-Out PDUs.   The initiator receives 3 more R2Ts but cannot = start sending Data-Out PDUs immediately due to outbound resource limitations.   The initiator must now store off each R2T = request so that it can honor them when resources become available – otherwise = the initiator will need to halt receive processing on the connection. =   The initiator will probably need to store the Target Transfer Tag, Buffer = Offset, and Desired Data Transfer Length for each R2T.   Does the = initiator need to store the LUN from each R2T as well?  Or can it just fill = in the LUN in the Data Out PDUs based on knowing what LUN the command was sent = to in the first place?

 

Thanks,

=

 

 

Bill

 

 

 

From: = Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Thursday, January = 03, 2008 4:12 AM
To: Sears, Bill
Cc: ips@ietf.org
Subject: Re: [Ips] LUN = field in R2T

 


Your interpretation is more liberal than the = text says. The reason for requiring a LUN field in the first place was to remove = the requirement for a  target-wide unique TTT and enable distributed = targets that do not require coordination.  The reason LUN was chosen to tag = the R2T is that it may simplify routing of the data to the appropriate = destination.
But since it is called LUN some zealous initiator may check (although it is = not mandated) the LUN validity versus a list obtained otherwise - so I would = not go for a very liberal interpretation.

Julo

Sears_Bill@emc.com<= /font> =

01/02/08 11:57 PM

To

<ips@ietf.org> =

cc

 

Subject

[Ips] LUN field in = R2T

 

 

 




Just a quick clarification:
 
10.8.5.  Target Transfer Tag
[...]The Target Transfer Tag and LUN are copied in the outgoing data PDUs and are = only used by the target.
 
Does this mean that the LUN field in the R2T does not need to contain the = actual LUN number specified by the SCSI write?   Since the field is = “only used by the target” I assume this text means that the target may place anything it wants in the LUN field of the R2T and have it echoed back by = the initiator.
 ______________________________________________= _
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips

------_=_NextPart_001_01C84E4C.72E1678B-- --===============0129736160== 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 --===============0129736160==-- From ips-bounces@ietf.org Fri Jan 04 07:54:05 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAm3l-00039Z-2k; Fri, 04 Jan 2008 07:54:01 -0500 Received: from ips by megatron.ietf.org with local (Exim 4.43) id 1JAm3j-00031s-A1 for ips-confirm+ok@megatron.ietf.org; Fri, 04 Jan 2008 07:53:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAm3i-000314-VN for ips@ietf.org; Fri, 04 Jan 2008 07:53:58 -0500 Received: from mtagate7.de.ibm.com ([195.212.29.156]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JAm3d-0001a5-NQ for ips@ietf.org; Fri, 04 Jan 2008 07:53:58 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate7.de.ibm.com (8.13.8/8.13.8) with ESMTP id m04Crn4S029932 for ; Fri, 4 Jan 2008 12:53:49 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 m04Crnsk2846824 for ; Fri, 4 Jan 2008 13:53:49 +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 m04Crnip024094 for ; Fri, 4 Jan 2008 13:53:49 +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 m04CrnqP024091; Fri, 4 Jan 2008 13:53:49 +0100 In-Reply-To: <83FD3BD6BD6165418CE12A050B5E3B761B0A9A@CORPUSMX40A.corp.emc.com> To: Sears_Bill@emc.com Subject: RE: [Ips] LUN field in R2T MIME-Version: 1.0 X-KeepSent: B2769B9D:544FEA84-652573C6:001BA7D8; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 7.0.3 September 26, 2007 From: Julian Satran Message-ID: Date: Fri, 4 Jan 2008 18:23:47 +0530 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 8.0|August 02, 2007) at 04/01/2008 14:53:48, Serialize complete at 04/01/2008 14:53:48 X-Spam-Score: -4.0 (----) X-Scan-Signature: 2b2ad76aced9b1d558e34a970a85c027 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="===============0391638296==" Errors-To: ips-bounces@ietf.org This is a multipart message in MIME format. --===============0391638296== Content-Type: multipart/alternative; boundary="=_alternative 001C13DD652573C6_=" This is a multipart message in MIME format. --=_alternative 001C13DD652573C6_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Bill, This is left to the implementer. I would argue that a "liberal" initiator=20 should store the LUN-TTT fields as they come and not fill them up. Julo Sears=5FBill@emc.com wrote on 01/04/2008 02:36:03 AM: > Thanks for getting back on this. I think I still need a little=20 clarification. >=20 > In a nutshell all I want to know is this: Is it legal for an=20 > initiator to set the LUN field in the Data-Out PDU based on what it=20 > knows the LUN to be, or MUST the initiator copy the contents of the=20 > LUN field from the received R2T into the Data Out.=20 >=20 > Example: An initiator negotiates for MaxOutstandingR2T=3D=3D4. The=20 > initiator sends a write command to a target. The initiator receives=20 > an R2T and starts sending multiple Data-Out PDUs. The initiator=20 > receives 3 more R2Ts but cannot start sending Data-Out PDUs=20 > immediately due to outbound resource limitations. The initiator must > now store off each R2T request so that it can honor them when=20 > resources become available ? otherwise the initiator will need to halt > receive processing on the connection. The initiator will probably=20 > need to store the Target Transfer Tag, Buffer Offset, and Desired Data > Transfer Length for each R2T. Does the initiator need to store the=20 > LUN from each R2T as well? Or can it just fill in the LUN in the Data > Out PDUs based on knowing what LUN the command was sent to in the first=20 place?=20 >=20 > Thanks, >=20 >=20 > Bill >=20 >=20 >=20 >=20 > From: Julian Satran [mailto:Julian=5FSatran@il.ibm.com]=20 > Sent: Thursday, January 03, 2008 4:12 AM > To: Sears, Bill > Cc: ips@ietf.org > Subject: Re: [Ips] LUN field in R2T >=20 >=20 > Your interpretation is more liberal than the text says. The reason for > requiring a LUN field in the first place was to remove the requirement > for a target-wide unique TTT and enable distributed targets that do=20 > not require coordination. The reason LUN was chosen to tag the R2T is > that it may simplify routing of the data to the appropriate destination. = > But since it is called LUN some zealous initiator may check (although=20 > it is not mandated) the LUN validity versus a list obtained otherwise=20 > - so I would not go for a very liberal interpretation.=20 >=20 > Julo=20 >=20 > Sears=5FBill@emc.com=20 > 01/02/08 11:57 PM=20 >=20 > To >=20 > =20 >=20 > cc >=20 >=20 >=20 > Subject >=20 > [Ips] LUN field in R2T >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Just a quick clarification:=20 >=20 > 10.8.5. Target Transfer Tag=20 > [...]The Target Transfer Tag and LUN are copied in the outgoing data=20 > PDUs and are only used by the target.=20 >=20 > Does this mean that the LUN field in the R2T does not need to contain=20 > the actual LUN number specified by the SCSI write? Since the field=20 > is ?only used by the target? I assume this text means that the target=20 > may place anything it wants in the LUN field of the R2T and have it=20 > echoed back by the initiator.=20 > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips --=_alternative 001C13DD652573C6_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
Bill,

This is left to the implementer. I w= ould argue that a "liberal" initiator should store the LUN-TTT fields as they come and not fill them up.

Julo


Sears=5FBill@emc.com wrote on 01/04/2008 02:36:03 AM= :

> Thanks for getting back on this.   I think I still need a little clarification.
>  
> In a nutshell all I want to know is this:  = ;Is it legal for an
> initiator to set the LUN field in the Data-Out PDU based on what it
> knows the LUN to be, or MUST the initiator copy the contents of the
> LUN field from the received R2T into the Data Out.
>  
> Example:  An initiator negotiates for MaxO= utstandingR2T=3D=3D4.  The
> initiator sends a write command to a target.  The initiator recei= ves
> an R2T and starts sending multiple Data-Out PDUs.   The initiator
> receives 3 more R2Ts but cannot start sending Data-Out PDUs
> immediately due to outbound resource limitations.   The initiator must
> now store off each R2T request so that it can honor them when
> resources become available – otherwise the initiator will need to halt
> receive processing on the connection.   The initiator will probab= ly
> need to store the Target Transfer Tag, Buffer Offset, and Desired Data
> Transfer Length for each R2T.   Does the initiator need to store the
> LUN from each R2T as well?  Or can it just fill in the LUN in the Data
> Out PDUs based on knowing what LUN the command was sent to in the first place?
>  
> Thanks,
>  
>  
> Bill
>  
>  
>  
>
> From: Julian Satran [mailto:Julian=5FSatran@il.ibm.com]
> Sent: Thursday, January 03, 2008 4:12 AM
> To: Sears, Bill
> Cc: ips@ietf.org
> Subject: Re: [Ips] LUN field in R2T
>  
>
> Your interpretation is more liberal than the text says. The reason for
> requiring a LUN field in the first place was to remove the requirement=
> for a  target-wide unique TTT and enable distributed targets that do
> not require coordination.  The reason LUN was chosen to tag the R2T is
> that it may simplify routing of the data to the appropriate destinatio= n.
> But since it is called LUN some zealous initiator may check (although
> it is not mandated) the LUN validity versus a list obtained otherwise
> - so I would not go for a very liberal interpretation.
>
> Julo

>
> Sears=5FBill@emc.com
> 01/02/08 11:57 PM
>
> To
>
> <ips@ietf.org>
>
> cc
>
>  
>
> Subject
>
> [Ips] LUN field in R2T
>
>  
>
>  
>
>  
>
>
>
>
> Just a quick clarification:
>  
> 10.8.5.  Target Transfer Tag
> [...]The Target Transfer Tag and LUN are copied in the outgoing data
> PDUs and are only used by the target.
>  
> Does this mean that the LUN field in the R2T does not need to contain
> the actual LUN number specified by the SCSI write?   Since the field
> is “only used by the target” I assume this text means that= the target
> may place anything it wants in the LUN field of the R2T and have it
> echoed back by the initiator.
>  =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F
> Ips mailing list
> Ips@ietf.org
> <= font size=3D2>https://www1.ietf.org/mailman/listinfo/ips --=_alternative 001C13DD652573C6_=-- --===============0391638296== 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 --===============0391638296==-- From ips-bounces@ietf.org Fri Jan 04 09:58:57 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAo0d-0004TH-Nh; Fri, 04 Jan 2008 09:58:55 -0500 Received: from ips by megatron.ietf.org with local (Exim 4.43) id 1JAo0d-0004TC-CP for ips-confirm+ok@megatron.ietf.org; Fri, 04 Jan 2008 09:58:55 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAo0d-0004T4-1X for ips@ietf.org; Fri, 04 Jan 2008 09:58:55 -0500 Received: from exprod8og107.obsmtp.com ([64.18.3.94]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JAo0c-0008KI-Cl for ips@ietf.org; Fri, 04 Jan 2008 09:58:54 -0500 Received: from source ([12.110.134.31]) by exprod8ob107.postini.com ([64.18.7.12]) with SMTP; Fri, 04 Jan 2008 06:58:31 PST Received: from pkoning-laptop.equallogic.com.equallogic.com ([172.25.202.31]) by M31.equallogic.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 Jan 2008 09:54:00 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18302.18567.101356.273717@pkoning-laptop.equallogic.com> Date: Fri, 4 Jan 2008 09:53:59 -0500 From: Paul Koning To: Julian_Satran@il.ibm.com Subject: RE: [Ips] LUN field in R2T References: <83FD3BD6BD6165418CE12A050B5E3B761B0A9A@CORPUSMX40A.corp.emc.com> X-Mailer: VM 7.17 under 21.4 (patch 19) "Constant Variable" XEmacs Lucid X-OriginalArrivalTime: 04 Jan 2008 14:54:00.0280 (UTC) FILETIME=[A3CD2D80:01C84EE1] X-Spam-Score: -4.0 (----) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: Sears_Bill@emc.com, 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 >>>>> "Julian" == Julian Satran writes: Julian> Bill, This is left to the implementer. I would argue that a Julian> "liberal" initiator should store the LUN-TTT fields as they Julian> come and not fill them up. That doesn't sound right to me. Something can only be left to the implementer if any of the allowed choices interoperate. And that is not the case here. If the target treats the LUN field as an additional identifier along with the TTT, NOT necessarily the same as the LUN number used in the original I/O request -- which is what section 10.8.5 clearly permits -- then the only interoperable initiator behavior is to copy the TTT AND LUN from the R2T to the Data Out message. If it uses the original request's LUN instead, it won't interoperate with a target that picks its own value for the R2T. So there are two possible answers: 1. A target can put anything it wants in the R2T LUN field, and the initiator must use that value from the R2T in its Data Out, or 2. A target must use the original request LUN in the R2T, and the initiator can either copy the LUN field from the R2T, or use the LUN it used in the request (since they are the same) when building its Data Out. It seems pretty clear to me that the current spec answer is #1. And the underlying problem is that the field was called "LUN" rather than "64 bit cookie" or something like that. >> In a nutshell all I want to know is this: Is it legal for an >> initiator to set the LUN field in the Data-Out PDU based on what >> it knows the LUN to be, or MUST the initiator copy the contents of >> the LUN field from the received R2T into the Data Out. >> >> Example: An initiator negotiates for MaxOutstandingR2T==4. The >> initiator sends a write command to a target. The initiator >> receives an R2T and starts sending multiple Data-Out PDUs. The >> initiator receives 3 more R2Ts but cannot start sending Data-Out >> PDUs immediately due to outbound resource limitations. The >> initiator must now store off each R2T request so that it can honor >> them when resources become available ? otherwise the initiator >> will need to halt receive processing on the connection. The >> initiator will probably need to store the Target Transfer Tag, >> Buffer Offset, and Desired Data Transfer Length for each R2T. >> Does the initiator need to store the LUN from each R2T as well? >> Or can it just fill in the LUN in the Data Out PDUs based on >> knowing what LUN the command was sent to in the first >> place? _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Fri Jan 04 10:21:33 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAoMU-0000BA-HQ; Fri, 04 Jan 2008 10:21:30 -0500 Received: from ips by megatron.ietf.org with local (Exim 4.43) id 1JAoMT-0000Az-RS for ips-confirm+ok@megatron.ietf.org; Fri, 04 Jan 2008 10:21:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAoMT-0000Aq-HZ for ips@ietf.org; Fri, 04 Jan 2008 10:21:29 -0500 Received: from noteserv1.attotech.com ([208.69.85.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JAoMS-0005Y3-Ey for ips@ietf.org; Fri, 04 Jan 2008 10:21:29 -0500 In-Reply-To: <18302.18567.101356.273717@pkoning-laptop.equallogic.com> To: Paul Koning Subject: RE: [Ips] LUN field in R2T MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.2 September 26, 2006 Message-ID: From: dcuddihy@attotech.com Date: Fri, 4 Jan 2008 10:21:26 -0500 X-MIMETrack: Serialize by Router on NOTESERV1/SERV/ATTO(Release 7.0.2FP1|January 10, 2007) at 01/04/2008 10:21:28 AM, Serialize complete at 01/04/2008 10:21:28 AM X-Spam-Score: 0.0 (/) X-Scan-Signature: bcd240e64c427d3d3617cfc704e7fd7f Cc: ips@ietf.org, Sears_Bill@emc.com, Julian_Satran@il.ibm.com X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1415459026==" Errors-To: ips-bounces@ietf.org This is a multipart message in MIME format. --===============1415459026== Content-Type: multipart/alternative; boundary="=_alternative 00545CC3852573C6_=" This is a multipart message in MIME format. --=_alternative 00545CC3852573C6_= Content-Type: text/plain; charset="US-ASCII" Paul, Your comments make sense to me. The initiator *should* copy the lun over from the R2T. From a practical standpoint I don't think that a target should rely on the initiator copying that data, since the field is, in fact, called "LUN" in the data out message. Further, I'm not sure that 10.7.4 is clear on this point: "If the Target Transfer Tag is provided, then the LUN field MUST hold a valid value and be consistent with whatever was specified with the command;" One could argue that 'command' is generally used in the context of a SCSI command, not an R2T. To reiterate - It's reasonable to say that an initiator should copy the data, but I don't think that a target can depend on that behavior. regards, david David J Cuddihy Principal Engineer ATTO Technology, Inc. www.attotech.com Power Behind the Storage Paul Koning wrote on 01/04/2008 09:53:59 AM: > >>>>> "Julian" == Julian Satran writes: > > Julian> Bill, This is left to the implementer. I would argue that a > Julian> "liberal" initiator should store the LUN-TTT fields as they > Julian> come and not fill them up. > > That doesn't sound right to me. > > Something can only be left to the implementer if any of the allowed > choices interoperate. And that is not the case here. > > If the target treats the LUN field as an additional identifier along > with the TTT, NOT necessarily the same as the LUN number used in the > original I/O request -- which is what section 10.8.5 clearly permits > -- then the only interoperable initiator behavior is to copy the TTT > AND LUN from the R2T to the Data Out message. If it uses the original > request's LUN instead, it won't interoperate with a target that picks > its own value for the R2T. > > So there are two possible answers: > > 1. A target can put anything it wants in the R2T LUN field, and the > initiator must use that value from the R2T in its Data Out, or > > 2. A target must use the original request LUN in the R2T, and the > initiator can either copy the LUN field from the R2T, or use the > LUN it used in the request (since they are the same) when building > its Data Out. > > It seems pretty clear to me that the current spec answer is #1. And > the underlying problem is that the field was called "LUN" rather than > "64 bit cookie" or something like that. > > >> In a nutshell all I want to know is this: Is it legal for an > >> initiator to set the LUN field in the Data-Out PDU based on what > >> it knows the LUN to be, or MUST the initiator copy the contents of > >> the LUN field from the received R2T into the Data Out. > >> > >> Example: An initiator negotiates for MaxOutstandingR2T==4. The > >> initiator sends a write command to a target. The initiator > >> receives an R2T and starts sending multiple Data-Out PDUs. The > >> initiator receives 3 more R2Ts but cannot start sending Data-Out > >> PDUs immediately due to outbound resource limitations. The > >> initiator must now store off each R2T request so that it can honor > >> them when resources become available ? otherwise the initiator > >> will need to halt receive processing on the connection. The > >> initiator will probably need to store the Target Transfer Tag, > >> Buffer Offset, and Desired Data Transfer Length for each R2T. > >> Does the initiator need to store the LUN from each R2T as well? > >> Or can it just fill in the LUN in the Data Out PDUs based on > >> knowing what LUN the command was sent to in the first > >> place? > > > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips --=_alternative 00545CC3852573C6_= Content-Type: text/html; charset="US-ASCII"
Paul,

Your comments make sense to me.   The initiator  *should* copy the lun over from the R2T.    From a practical standpoint I don't think that  a target should rely on the initiator copying that data, since the field is, in fact, called "LUN" in the data out message.

Further, I'm not sure that 10.7.4 is clear on this point:  

"If the Target Transfer Tag is
  provided, then the LUN field MUST hold a valid value and be
  consistent with whatever was specified with the command;"

One could argue that 'command' is generally used in the context of a SCSI command, not an R2T.  To reiterate - It's reasonable to say that an initiator should copy the data, but I don't think that a target can depend on that behavior.

regards,

david



David J Cuddihy
Principal Engineer
ATTO Technology, Inc.


www.attotech.com
Power Behind the Storage



Paul Koning <pkoning@equallogic.com> wrote on 01/04/2008 09:53:59 AM:

> >>>>> "Julian" == Julian Satran <Julian_Satran@il.ibm.com> writes:
>
>  Julian> Bill, This is left to the implementer. I would argue that a
>  Julian> "liberal" initiator should store the LUN-TTT fields as they
>  Julian> come and not fill them up.
>
> That doesn't sound right to me.
>
> Something can only be left to the implementer if any of the allowed
> choices interoperate.  And that is not the case here.
>
> If the target treats the LUN field as an additional identifier along
> with the TTT, NOT necessarily the same as the LUN number used in the
> original I/O request -- which is what section 10.8.5 clearly permits
> -- then the only interoperable initiator behavior is to copy the TTT
> AND LUN from the R2T to the Data Out message.  If it uses the original
> request's LUN instead, it won't interoperate with a target that picks
> its own value for the R2T.
>
> So there are two possible answers:
>
> 1. A target can put anything it wants in the R2T LUN field, and the
>    initiator must use that value from the R2T in its Data Out, or
>
> 2. A target must use the original request LUN in the R2T, and the
>    initiator can either copy the LUN field from the R2T, or use the
>    LUN it used in the request (since they are the same) when building
>    its Data Out.
>
> It seems pretty clear to me that the current spec answer is #1.  And
> the underlying problem is that the field was called "LUN" rather than
> "64 bit cookie" or something like that.
>
>  >>  In a nutshell all I want to know is this: Is it legal for an
>  >> initiator to set the LUN field in the Data-Out PDU based on what
>  >> it knows the LUN to be, or MUST the initiator copy the contents of
>  >> the LUN field from the received R2T into the Data Out.
>  >>
>  >> Example: An initiator negotiates for MaxOutstandingR2T==4.  The
>  >> initiator sends a write command to a target.  The initiator
>  >> receives an R2T and starts sending multiple Data-Out PDUs.  The
>  >> initiator receives 3 more R2Ts but cannot start sending Data-Out
>  >> PDUs immediately due to outbound resource limitations.  The
>  >> initiator must now store off each R2T request so that it can honor
>  >> them when resources become available ? otherwise the initiator
>  >> will need to halt receive processing on the connection.  The
>  >> initiator will probably need to store the Target Transfer Tag,
>  >> Buffer Offset, and Desired Data Transfer Length for each R2T.
>  >> Does the initiator need to store the LUN from each R2T as well?
>  >> Or can it just fill in the LUN in the Data Out PDUs based on
>  >> knowing what LUN the command was sent to in the first
>  >> place?
>
>
>
> _______________________________________________
> Ips mailing list
> Ips@ietf.org
> https://www1.ietf.org/mailman/listinfo/ips
 --=_alternative 00545CC3852573C6_=-- --===============1415459026== 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 --===============1415459026==-- From ips-bounces@ietf.org Fri Jan 04 12:44:33 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAqas-0002UT-Dz; Fri, 04 Jan 2008 12:44:30 -0500 Received: from ips by megatron.ietf.org with local (Exim 4.43) id 1JAqar-0002Qc-8x for ips-confirm+ok@megatron.ietf.org; Fri, 04 Jan 2008 12:44:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAqaq-0002Ng-UQ for ips@ietf.org; Fri, 04 Jan 2008 12:44:28 -0500 Received: from mexforward.lss.emc.com ([128.222.32.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JAqam-0000Bz-RB for ips@ietf.org; Fri, 04 Jan 2008 12:44:28 -0500 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 m04HiONL002093 for ; Fri, 4 Jan 2008 12:44:24 -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) for ; Fri, 4 Jan 2008 12:44:24 -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 m04HhkKn009135 for ; Fri, 4 Jan 2008 12:44:20 -0500 (EST) From: Sears_Bill@emc.com Received: from CORPUSMX40A.corp.emc.com ([10.254.64.48]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 Jan 2008 12:44:11 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ips] LUN field in R2T Date: Fri, 4 Jan 2008 12:44:10 -0500 Message-ID: <83FD3BD6BD6165418CE12A050B5E3B761B0AA0@CORPUSMX40A.corp.emc.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ips] LUN field in R2T thread-index: AchO5X75f/7Dp1qqT26qEN52LVB01AAEpTaA To: X-OriginalArrivalTime: 04 Jan 2008 17:44:11.0218 (UTC) FILETIME=[69FEAB20:01C84EF9] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.8.30.51425 X-PerlMx-Spam: Gauge=, SPAM=1%, Reason='EMC_FROM_0+ -3, HTML_50_70 0.1, NO_REAL_NAME 0, __CP_URI_IN_BODY 0, __CT 0, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0, __CTYPE_MULTIPART_ALT 0, __HAS_MSGID 0, __HTML_BOLD 0, __HTML_FONT_BLUE 0, __HTML_MSWORD 0, __IMS_MSGID 0, __MIME_HTML 0, __MIME_VERSION 0, __RATWARE_SIGNATURE_3_N1 0, __SANE_MSGID 0, __TAG_EXISTS_HTML 0' X-Tablus-Inspected: yes X-Tablus-Classifications: public X-Tablus-Action: allow X-Spam-Score: -4.0 (----) X-Scan-Signature: d6c15d82a53e26283536b4a751453103 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="===============0176292103==" Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============0176292103== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C84EF9.69897591" This is a multi-part message in MIME format. ------_=_NextPart_001_01C84EF9.69897591 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sounds like whatever the intent of the field was that the spec might be somewhat ambiguous. I'll err on the side of caution and make sure the LUN field is copied from the R2T into the Data-Outs. Personally in neither our initiator or target implementations do I even look at that LUN field in the R2T or Data-Out since the ITT and TTT are sufficient for tracking the IO. However I can conceed that some target implementations may benefit from having the LUN field in the Data-Out. =20 Bill =20 ________________________________ From: dcuddihy@attotech.com [mailto:dcuddihy@attotech.com]=20 Sent: Friday, January 04, 2008 10:21 AM To: Paul Koning Cc: ips@ietf.org; Julian_Satran@il.ibm.com; Sears, Bill Subject: RE: [Ips] LUN field in R2T =20 Paul,=20 Your comments make sense to me. The initiator *should* copy the lun over from the R2T. From a practical standpoint I don't think that a target should rely on the initiator copying that data, since the field is, in fact, called "LUN" in the data out message.=20 Further, I'm not sure that 10.7.4 is clear on this point: =20 "If the Target Transfer Tag is provided, then the LUN field MUST hold a valid value and be consistent with whatever was specified with the command;"=20 One could argue that 'command' is generally used in the context of a SCSI command, not an R2T. To reiterate - It's reasonable to say that an initiator should copy the data, but I don't think that a target can depend on that behavior.=20 regards,=20 david=20 say that the David J Cuddihy Principal Engineer ATTO Technology, Inc. www.attotech.com =20 Power Behind the Storage=20 Paul Koning wrote on 01/04/2008 09:53:59 AM: > >>>>> "Julian" =3D=3D Julian Satran writes: >=20 > Julian> Bill, This is left to the implementer. I would argue that a > Julian> "liberal" initiator should store the LUN-TTT fields as they > Julian> come and not fill them up. >=20 > That doesn't sound right to me. >=20 > Something can only be left to the implementer if any of the allowed > choices interoperate. And that is not the case here. >=20 > If the target treats the LUN field as an additional identifier along > with the TTT, NOT necessarily the same as the LUN number used in the > original I/O request -- which is what section 10.8.5 clearly permits > -- then the only interoperable initiator behavior is to copy the TTT > AND LUN from the R2T to the Data Out message. If it uses the original > request's LUN instead, it won't interoperate with a target that picks > its own value for the R2T. >=20 > So there are two possible answers: >=20 > 1. A target can put anything it wants in the R2T LUN field, and the > initiator must use that value from the R2T in its Data Out, or >=20 > 2. A target must use the original request LUN in the R2T, and the > initiator can either copy the LUN field from the R2T, or use the > LUN it used in the request (since they are the same) when building > its Data Out. >=20 > It seems pretty clear to me that the current spec answer is #1. And > the underlying problem is that the field was called "LUN" rather than > "64 bit cookie" or something like that. >=20 > >> In a nutshell all I want to know is this: Is it legal for an > >> initiator to set the LUN field in the Data-Out PDU based on what > >> it knows the LUN to be, or MUST the initiator copy the contents of > >> the LUN field from the received R2T into the Data Out. > >>=20 > >> Example: An initiator negotiates for MaxOutstandingR2T=3D=3D4. = The > >> initiator sends a write command to a target. The initiator > >> receives an R2T and starts sending multiple Data-Out PDUs. The > >> initiator receives 3 more R2Ts but cannot start sending Data-Out > >> PDUs immediately due to outbound resource limitations. The > >> initiator must now store off each R2T request so that it can honor > >> them when resources become available ? otherwise the initiator > >> will need to halt receive processing on the connection. The > >> initiator will probably need to store the Target Transfer Tag, > >> Buffer Offset, and Desired Data Transfer Length for each R2T. > >> Does the initiator need to store the LUN from each R2T as well? > >> Or can it just fill in the LUN in the Data Out PDUs based on > >> knowing what LUN the command was sent to in the first > >> place? >=20 >=20 >=20 > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips ------_=_NextPart_001_01C84EF9.69897591 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Sounds like whatever the intent of = the field was that the spec might be somewhat ambiguous.  =  I’ll err on the side of caution and make sure the LUN field is copied from the = R2T into the Data-Outs.   Personally in neither our initiator or target implementations do I even look at that LUN field in the R2T or Data-Out = since the ITT and TTT are sufficient for tracking the IO.  However I can = conceed that some target implementations may benefit from having the LUN field = in the Data-Out.

 

Bill

 

From: = dcuddihy@attotech.com [mailto:dcuddihy@attotech.com]
Sent: Friday, January 04, = 2008 10:21 AM
To: Paul Koning
Cc: ips@ietf.org; Julian_Satran@il.ibm.com; Sears, Bill
Subject: RE: [Ips] LUN = field in R2T

 


Paul,

Your comments make sense to me.   The initiator  *should* copy the = lun over from the R2T.    From a practical standpoint I don't = think that  a target should rely on the initiator copying that data, since the field = is, in fact, called "LUN" in the data out message.

Further, I'm not sure that 10.7.4 is clear on this point:  

"If the Target Transfer Tag is
  provided, then the LUN field MUST = hold a valid value and be
  consistent with whatever was = specified with the command;"

One could argue that 'command' is generally used in the context of a SCSI = command, not an R2T.  To reiterate - It's reasonable to say that an = initiator should copy the data, but I don't think that a target can depend on that behavior.

regards,

david

say that = the

David J Cuddihy
Principal Engineer
ATTO Technology, Inc.


www.attotech.com
Power Behind the Storage



Paul Koning <pkoning@equallogic.com> wrote on 01/04/2008 09:53:59 = AM:

> >>>>> = "Julian" =3D=3D Julian Satran <Julian_Satran@il.ibm.com> writes:
>
>  Julian> Bill, This is left = to the implementer. I would argue that a
>  Julian> "liberal" initiator should store the LUN-TTT fields as they
>  Julian> come and not fill = them up.
>
> That doesn't sound right to = me.
>
> Something can only be left to the = implementer if any of the allowed
> choices interoperate.  And that = is not the case here.
>
> If the target treats the LUN field = as an additional identifier along
> with the TTT, NOT necessarily the = same as the LUN number used in the
> original I/O request -- which is = what section 10.8.5 clearly permits
> -- then the only interoperable = initiator behavior is to copy the TTT
> AND LUN from the R2T to the Data Out = message.  If it uses the original
> request's LUN instead, it won't = interoperate with a target that picks
> its own value for the = R2T.
>
> So there are two possible = answers:
>
> 1. A target can put anything it = wants in the R2T LUN field, and the
>    initiator must use that = value from the R2T in its Data Out, or
>
> 2. A target must use the original = request LUN in the R2T, and the
>    initiator can either = copy the LUN field from the R2T, or use the
>    LUN it used in the = request (since they are the same) when building
>    its Data = Out.
>
> It seems pretty clear to me that the = current spec answer is #1.  And
> the underlying problem is that the = field was called "LUN" rather than
> "64 bit cookie" or = something like that.
>
>  >>  In a nutshell = all I want to know is this: Is it legal for an
>  >> initiator to set the = LUN field in the Data-Out PDU based on what
>  >> it knows the LUN to = be, or MUST the initiator copy the contents of
>  >> the LUN field from = the received R2T into the Data Out.
>  >>
>  >> Example: An initiator negotiates for MaxOutstandingR2T=3D=3D4.  The
>  >> initiator sends a = write command to a target.  The initiator
>  >> receives an R2T and = starts sending multiple Data-Out PDUs.  The
>  >> initiator receives 3 = more R2Ts but cannot start sending Data-Out
>  >> PDUs immediately due = to outbound resource limitations.  The
>  >> initiator must now = store off each R2T request so that it can honor
>  >> them when resources = become available ? otherwise the initiator
>  >> will need to halt = receive processing on the connection.  The
>  >> initiator will = probably need to store the Target Transfer Tag,
>  >> Buffer Offset, and = Desired Data Transfer Length for each R2T.
>  >> Does the initiator = need to store the LUN from each R2T as well?
>  >> Or can it just fill = in the LUN in the Data Out PDUs based on
>  >> knowing what LUN the = command was sent to in the first
>  >> = place?
>
>
>
> _______________________________________________
> Ips mailing list
> Ips@ietf.org
> = https://www1.ietf.org/mailman/listinfo/ips=

------_=_NextPart_001_01C84EF9.69897591-- --===============0176292103== 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 --===============0176292103==-- From ips-bounces@ietf.org Fri Jan 04 12:51:52 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAqi0-0003W6-0M; Fri, 04 Jan 2008 12:51:52 -0500 Received: from ips by megatron.ietf.org with local (Exim 4.43) id 1JAqhy-0003W1-Qs for ips-confirm+ok@megatron.ietf.org; Fri, 04 Jan 2008 12:51:50 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAqhy-0003Vt-Gc for ips@ietf.org; Fri, 04 Jan 2008 12:51:50 -0500 Received: from exprod8og101.obsmtp.com ([64.18.3.82]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JAqhy-0004gM-0D for ips@ietf.org; Fri, 04 Jan 2008 12:51:50 -0500 Received: from source ([12.110.134.31]) by exprod8ob101.postini.com ([64.18.7.12]) with SMTP; Fri, 04 Jan 2008 09:51:42 PST Received: from pkoning-laptop.equallogic.com.equallogic.com ([172.25.202.31]) by M31.equallogic.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 Jan 2008 12:48:22 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18302.29025.7297.986571@pkoning-laptop.equallogic.com> Date: Fri, 4 Jan 2008 12:48:17 -0500 From: Paul Koning To: Sears_Bill@emc.com Subject: RE: [Ips] LUN field in R2T References: <83FD3BD6BD6165418CE12A050B5E3B761B0AA0@CORPUSMX40A.corp.emc.com> X-Mailer: VM 7.17 under 21.4 (patch 19) "Constant Variable" XEmacs Lucid X-OriginalArrivalTime: 04 Jan 2008 17:48:22.0772 (UTC) FILETIME=[FFEEC340:01C84EF9] X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 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 >>>>> "Sears" == Sears Bill writes: Sears> Sounds like whatever the intent of the field was that the spec Sears> might be somewhat ambiguous. I'll err on the side of caution Sears> and make sure the LUN field is copied from the R2T into the Sears> Data-Outs. Personally in neither our initiator or target Sears> implementations do I even look at that LUN field in the R2T or Sears> Data-Out since the ITT and TTT are sufficient for tracking the Sears> IO. However I can conceed that some target implementations Sears> may benefit from having the LUN field in the Data-Out. >> Further, I'm not sure that 10.7.4 is clear on this point: >> "If the Target Transfer Tag is provided, then the LUN field >> MUST hold a valid value and be consistent with whatever was >> specified with the command;" >> One could argue that 'command' is generally used in the >> context of a SCSI command, not an R2T. To reiterate - It's >> reasonable to say that an initiator should copy the data, but >> I don't think that a target can depend on that behavior. It sure looks like the spec is contradictory. So the safe implementation approach would be: 1. In the initiator, copy LUN from R2T to Data Out, without looking at it. 2. In the target, copy LUN from the request to R2T (don't make up your own value). paul _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Sat Jan 05 11:50:35 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBCE7-0007FN-SU; Sat, 05 Jan 2008 11:50:27 -0500 Received: from ips by megatron.ietf.org with local (Exim 4.43) id 1JBCE5-0007FG-TK for ips-confirm+ok@megatron.ietf.org; Sat, 05 Jan 2008 11:50:25 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBCE5-0007C0-HY for ips@ietf.org; Sat, 05 Jan 2008 11:50:25 -0500 Received: from mtagate4.de.ibm.com ([195.212.29.153]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JBCE1-000880-Uy for ips@ietf.org; Sat, 05 Jan 2008 11:50:22 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate4.de.ibm.com (8.13.8/8.13.8) with ESMTP id m05GoIYY113594 for ; Sat, 5 Jan 2008 16:50:18 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.8/8.13.8/NCO v8.7) with ESMTP id m05GoIeZ2871518 for ; Sat, 5 Jan 2008 17:50:18 +0100 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 m05GoHOO028800 for ; Sat, 5 Jan 2008 17:50:18 +0100 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 m05GoHfQ028797; Sat, 5 Jan 2008 17:50:17 +0100 In-Reply-To: <18302.18567.101356.273717@pkoning-laptop.equallogic.com> To: Paul Koning Subject: RE: [Ips] LUN field in R2T MIME-Version: 1.0 X-KeepSent: E769FA22:3A41AFD9-652573C7:003CC647; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 7.0.3 September 26, 2007 From: Julian Satran Message-ID: Date: Sat, 5 Jan 2008 22:20:16 +0530 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 8.0|August 02, 2007) at 05/01/2008 18:50:17, Serialize complete at 05/01/2008 18:50:17 X-Spam-Score: 0.0 (/) X-Scan-Signature: ec7c6dab5a62df223002ae71b5179d41 Cc: ips@ietf.org, Sears_Bill@emc.com X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0801876181==" Errors-To: ips-bounces@ietf.org This is a multipart message in MIME format. --===============0801876181== Content-Type: multipart/alternative; boundary="=_alternative 003D3D59652573C7_=" This is a multipart message in MIME format. --=_alternative 003D3D59652573C7_= Content-Type: text/plain; charset="US-ASCII" Paul, You are right that the current spec "favors" 1. However it does not forbid a "zealous" initiator to check the validity of the LUN. If we would have gone as far as naming it a cookie we would have had to face an interminable discussion about what where the "legal" cookie values. LUN seemed a good enough option fora target that segregates resources based on LU. Julo Paul Koning 01/04/08 08:23 PM To Julian Satran/Haifa/IBM@IBMIL cc Sears_Bill@emc.com, ips@ietf.org Subject RE: [Ips] LUN field in R2T >>>>> "Julian" == Julian Satran writes: Julian> Bill, This is left to the implementer. I would argue that a Julian> "liberal" initiator should store the LUN-TTT fields as they Julian> come and not fill them up. That doesn't sound right to me. Something can only be left to the implementer if any of the allowed choices interoperate. And that is not the case here. If the target treats the LUN field as an additional identifier along with the TTT, NOT necessarily the same as the LUN number used in the original I/O request -- which is what section 10.8.5 clearly permits -- then the only interoperable initiator behavior is to copy the TTT AND LUN from the R2T to the Data Out message. If it uses the original request's LUN instead, it won't interoperate with a target that picks its own value for the R2T. So there are two possible answers: 1. A target can put anything it wants in the R2T LUN field, and the initiator must use that value from the R2T in its Data Out, or 2. A target must use the original request LUN in the R2T, and the initiator can either copy the LUN field from the R2T, or use the LUN it used in the request (since they are the same) when building its Data Out. It seems pretty clear to me that the current spec answer is #1. And the underlying problem is that the field was called "LUN" rather than "64 bit cookie" or something like that. >> In a nutshell all I want to know is this: Is it legal for an >> initiator to set the LUN field in the Data-Out PDU based on what >> it knows the LUN to be, or MUST the initiator copy the contents of >> the LUN field from the received R2T into the Data Out. >> >> Example: An initiator negotiates for MaxOutstandingR2T==4. The >> initiator sends a write command to a target. The initiator >> receives an R2T and starts sending multiple Data-Out PDUs. The >> initiator receives 3 more R2Ts but cannot start sending Data-Out >> PDUs immediately due to outbound resource limitations. The >> initiator must now store off each R2T request so that it can honor >> them when resources become available ? otherwise the initiator >> will need to halt receive processing on the connection. The >> initiator will probably need to store the Target Transfer Tag, >> Buffer Offset, and Desired Data Transfer Length for each R2T. >> Does the initiator need to store the LUN from each R2T as well? >> Or can it just fill in the LUN in the Data Out PDUs based on >> knowing what LUN the command was sent to in the first >> place? --=_alternative 003D3D59652573C7_= Content-Type: text/html; charset="US-ASCII"
Paul,

You are right that the current spec "favors" 1. However it does not forbid a "zealous" initiator to check the validity of the LUN.
If we would have gone as far as naming it a cookie we would have had to face an interminable discussion about what where the "legal" cookie values.
LUN seemed a good enough option fora target that segregates resources based on LU.

Julo


Paul Koning <pkoning@equallogic.com>

01/04/08 08:23 PM

To
Julian Satran/Haifa/IBM@IBMIL
cc
Sears_Bill@emc.com, ips@ietf.org
Subject
RE: [Ips] LUN field in R2T





>>>>> "Julian" == Julian Satran <Julian_Satran@il.ibm.com> writes:

Julian> Bill, This is left to the implementer. I would argue that a
Julian> "liberal" initiator should store the LUN-TTT fields as they
Julian> come and not fill them up.

That doesn't sound right to me.

Something can only be left to the implementer if any of the allowed
choices interoperate.  And that is not the case here.

If the target treats the LUN field as an additional identifier along
with the TTT, NOT necessarily the same as the LUN number used in the
original I/O request -- which is what section 10.8.5 clearly permits
-- then the only interoperable initiator behavior is to copy the TTT
AND LUN from the R2T to the Data Out message.  If it uses the original
request's LUN instead, it won't interoperate with a target that picks
its own value for the R2T.

So there are two possible answers:

1. A target can put anything it wants in the R2T LUN field, and the
  initiator must use that value from the R2T in its Data Out, or

2. A target must use the original request LUN in the R2T, and the
  initiator can either copy the LUN field from the R2T, or use the
  LUN it used in the request (since they are the same) when building
  its Data Out.

It seems pretty clear to me that the current spec answer is #1.  And
the underlying problem is that the field was called "LUN" rather than
"64 bit cookie" or something like that.

>>  In a nutshell all I want to know is this: Is it legal for an
>> initiator to set the LUN field in the Data-Out PDU based on what
>> it knows the LUN to be, or MUST the initiator copy the contents of
>> the LUN field from the received R2T into the Data Out.
>>
>> Example: An initiator negotiates for MaxOutstandingR2T==4.  The
>> initiator sends a write command to a target.  The initiator
>> receives an R2T and starts sending multiple Data-Out PDUs.  The
>> initiator receives 3 more R2Ts but cannot start sending Data-Out
>> PDUs immediately due to outbound resource limitations.  The
>> initiator must now store off each R2T request so that it can honor
>> them when resources become available ? otherwise the initiator
>> will need to halt receive processing on the connection.  The
>> initiator will probably need to store the Target Transfer Tag,
>> Buffer Offset, and Desired Data Transfer Length for each R2T.
>> Does the initiator need to store the LUN from each R2T as well?
>> Or can it just fill in the LUN in the Data Out PDUs based on
>> knowing what LUN the command was sent to in the first
>> place?
--=_alternative 003D3D59652573C7_=-- --===============0801876181== 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 --===============0801876181==-- From ips-bounces@ietf.org Mon Jan 07 13:06:31 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBwMn-0002LS-Je; Mon, 07 Jan 2008 13:06:29 -0500 Received: from ips by megatron.ietf.org with local (Exim 4.43) id 1JBwMm-0002Iv-Fi for ips-confirm+ok@megatron.ietf.org; Mon, 07 Jan 2008 13:06:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBwMm-0002IQ-4f for ips@ietf.org; Mon, 07 Jan 2008 13:06:28 -0500 Received: from web51704.mail.re2.yahoo.com ([206.190.38.222]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1JBwMj-0004SF-Pm for ips@ietf.org; Mon, 07 Jan 2008 13:06:28 -0500 Received: (qmail 67053 invoked by uid 60001); 7 Jan 2008 18:06:25 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=Nv/YrRJ7gnN3OGpu/HNdqseiMqRW9HNsVUva/FdKJvtySop3HtYvX19kAfE0t7vFmixgISfrjGxY/fNx3mLYqBVNW6hmcs52fXsUrv8RLkV7nI6GQAJRmAOdsmjZ7Xl9Xrk3EsbAbLsvVIOU1LvDlnCoHIqKFo2szDh1VMN7K9Y=; X-YMail-OSG: CAD_CWMVM1m0nIEb_fy_AMjbJve8LHeJKmDEGLVjF2.4CVNIDxhVFnQTwF8fyw0mDQ-- Received: from [15.235.153.106] by web51704.mail.re2.yahoo.com via HTTP; Mon, 07 Jan 2008 10:06:24 PST X-Mailer: YahooMailRC/818.31 YahooMailWebService/0.7.158.1 Date: Mon, 7 Jan 2008 10:06:24 -0800 (PST) From: "Mallikarjun C." Subject: Re: [Ips] LUN field in R2T To: ips@ietf.org MIME-Version: 1.0 Message-ID: <27885.65355.qm@web51704.mail.re2.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 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="===============0581629332==" Errors-To: ips-bounces@ietf.org --===============0581629332== Content-Type: multipart/alternative; boundary="0-785340272-1199729184=:65355" --0-785340272-1199729184=:65355 Content-Type: text/plain; charset=us-ascii So there are two possible answers: 1. A target can put anything it wants in the R2T LUN field, and the initiator must use that value from the R2T in its Data Out, or I tend to think that the original intent of the spec was Paul's #1. However, in hindsight, the spec should have used the "must" in Paul's description which it unfortunately it did not. To Bill who originally asked the question, the safe approach thus would be storing more state on the initiator end for queueing R2Ts to be serviced. Mallikarjun ----- Original Message ---- From: Julian Satran To: Paul Koning Cc: ips@ietf.org; Sears_Bill@emc.com Sent: Saturday, January 5, 2008 8:50:16 AM Subject: RE: [Ips] LUN field in R2T Paul, You are right that the current spec "favors" 1. However it does not forbid a "zealous" initiator to check the validity of the LUN. If we would have gone as far as naming it a cookie we would have had to face an interminable discussion about what where the "legal" cookie values. LUN seemed a good enough option fora target that segregates resources based on LU. Julo Paul Koning 01/04/08 08:23 PM ToJulian Satran/Haifa/IBM@IBMIL ccSears_Bill@emc.com, ips@ietf.org SubjectRE: [Ips] LUN field in R2T >>>>> "Julian" == Julian Satran writes: Julian> Bill, This is left to the implementer. I would argue that a Julian> "liberal" initiator should store the LUN-TTT fields as they Julian> come and not fill them up. That doesn't sound right to me. Something can only be left to the implementer if any of the allowed choices interoperate. And that is not the case here. If the target treats the LUN field as an additional identifier along with the TTT, NOT necessarily the same as the LUN number used in the original I/O request -- which is what section 10.8.5 clearly permits -- then the only interoperable initiator behavior is to copy the TTT AND LUN from the R2T to the Data Out message. If it uses the original request's LUN instead, it won't interoperate with a target that picks its own value for the R2T. So there are two possible answers: 1. A target can put anything it wants in the R2T LUN field, and the initiator must use that value from the R2T in its Data Out, or 2. A target must use the original request LUN in the R2T, and the initiator can either copy the LUN field from the R2T, or use the LUN it used in the request (since they are the same) when building its Data Out. It seems pretty clear to me that the current spec answer is #1. And the underlying problem is that the field was called "LUN" rather than "64 bit cookie" or something like that. >> In a nutshell all I want to know is this: Is it legal for an >> initiator to set the LUN field in the Data-Out PDU based on what >> it knows the LUN to be, or MUST the initiator copy the contents of >> the LUN field from the received R2T into the Data Out. >> >> Example: An initiator negotiates for MaxOutstandingR2T==4. The >> initiator sends a write command to a target. The initiator >> receives an R2T and starts sending multiple Data-Out PDUs. The >> initiator receives 3 more R2Ts but cannot start sending Data-Out >> PDUs immediately due to outbound resource limitations. The >> initiator must now store off each R2T request so that it can honor >> them when resources become available ? otherwise the initiator >> will need to halt receive processing on the connection. The >> initiator will probably need to store the Target Transfer Tag, >> Buffer Offset, and Desired Data Transfer Length for each R2T. >> Does the initiator need to store the LUN from each R2T as well? >> Or can it just fill in the LUN in the Data Out PDUs based on >> knowing what LUN the command was sent to in the first >> place? ____________________________________________________________________________________ Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping --0-785340272-1199729184=:65355 Content-Type: text/html; charset=us-ascii
So there are two possible answers:

1. A target can put anything it wants in the R2T LUN field, and the
  initiator must use that value from the R2T in its Data Out, or

  

 

I tend to think that the original intent of the spec was Paul's #1.  However, in hindsight, the spec should have used the "must" in Paul's description which it unfortunately it did not.  To Bill who originally asked the question, the safe approach thus would be storing more state on the initiator end for queueing R2Ts to be serviced.
 
Mallikarjun

----- Original Message ----
From: Julian Satran <Julian_Satran@il.ibm.com>
To: Paul Koning <pkoning@equallogic.com>
Cc: ips@ietf.org; Sears_Bill@emc.com
Sent: Saturday, January 5, 2008 8:50:16 AM
Subject: RE: [Ips] LUN field in R2T


Paul,

You are right that the current spec "favors" 1. However it does not forbid a "zealous" initiator to check the validity of the LUN.
If we would have gone as far as naming it a cookie we would have had to face an interminable discussion about what where the "legal" cookie values.
LUN seemed a good enough option fora target that segregates resources based on LU.

Julo


Paul Koning <pkoning@equallogic.com>

01/04/08 08:23 PM

To
Julian Satran/Haifa/IBM@IBMIL
cc
Sears_Bill@emc.com, ips@ietf.org
Subject
RE: [Ips] LUN field in R2T





>>>>> "Julian" == Julian Satran <Julian_Satran@il.ibm.com> writes:

Julian> Bill, This is left to the implementer. I would argue that a
Julian> "liberal" initiator should store the LUN-TTT fields as they
Julian> come and not fill them up.

That doesn't sound right to me.

Something can only be left to the implementer if any of the allowed
choices interoperate.  And that is not the case here.

If the target treats the LUN field as an additional identifier along
with the TTT, NOT necessarily the same as the LUN number used in the
original I/O request -- which is what section 10.8.5 clearly permits
-- then the only interoperable initiator behavior is to copy the TTT
AND LUN from the R2T to the Data Out message.  If it uses the original
request's LUN instead, it won't interoperate with a target that picks
its own value for the R2T.

So there are two possible answers:

1. A target can put anything it wants in the R2T LUN field, and the
  initiator must use that value from the R2T in its Data Out, or

2. A target must use the original request LUN in the R2T, and the
  initiator can either copy the LUN field from the R2T, or use the
  LUN it used in the request (since they are the same) when building
  its Data Out.

It seems pretty clear to me that the current spec answer is #1.  And
the underlying problem is that the field was called "LUN" rather than
"64 bit cookie" or something like that.

>>  In a nutshell all I want to know is this: Is it legal for an
>> initiator to set the LUN field in the Data-Out PDU based on what
>> it knows the LUN to be, or MUST the initiator copy the contents of
>> the LUN field from the received R2T into the Data Out.
>>
>> Example: An initiator negotiates for MaxOutstandingR2T==4.  The
>> initiator sends a write command to a target.  The initiator
>> receives an R2T and starts sending multiple Data-Out PDUs.  The
>> initiator receives 3 more R2Ts but cannot start sending Data-Out
>> PDUs immediately due to outbound resource limitations.  The
>> initiator must now store off each R2T request so that it can honor
>> them when resources become available ? otherwise the initiator
>> will need to halt receive processing on the connection.  The
>> initiator will probably need to store the Target Transfer Tag,
>> Buffer Offset, and Desired Data Transfer Length for each R2T.
>> Does the initiator need to store the LUN from each R2T as well?
>> Or can it just fill in the LUN in the Data Out PDUs based on
>> knowing what LUN the command was sent to in the first
>> place?




Looking for last minute shopping deals? Find them fast with Yahoo! Search. --0-785340272-1199729184=:65355-- --===============0581629332== 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 --===============0581629332==-- From ips-bounces@ietf.org Fri Jan 11 07:16:34 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDIoK-000694-D4; Fri, 11 Jan 2008 07:16:32 -0500 Received: from ips by megatron.ietf.org with local (Exim 4.43) id 1JDIoI-00068z-Vs for ips-confirm+ok@megatron.ietf.org; Fri, 11 Jan 2008 07:16:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDIoI-000687-M2 for ips@ietf.org; Fri, 11 Jan 2008 07:16:30 -0500 Received: from smtp.nokia.com ([192.100.122.233] helo=mgw-mx06.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JDIoG-0003uF-SO for ips@ietf.org; Fri, 11 Jan 2008 07:16:30 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m0BCGDaW013200; Fri, 11 Jan 2008 14:16:25 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Jan 2008 14:16:24 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Jan 2008 14:16:23 +0200 Received: from esdhcp03947.research.nokia.com ([172.21.39.47]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Jan 2008 14:16:24 +0200 Message-Id: From: Lars Eggert To: ips@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Date: Fri, 11 Jan 2008 14:16:21 +0200 X-Mailer: Apple Mail (2.915) X-OriginalArrivalTime: 11 Jan 2008 12:16:24.0088 (UTC) FILETIME=[C85D0980:01C8544B] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: Subject: [Ips] Errata reported for RFC4171 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 Hi, the following errata has been reported for an RFC that originated with this WG [*]. The transport ADs are soliciting comments on (1) classifying and (2) verifying the errata below. (1) The errata below should have a classification suggested by the submitter, which will either be "technical" or editorial. We're interested to hear comments on whether the current classification is accurate. (2) We're interested to hear comments on whether the errata addresses a valid technical or editorial issue with the published RFC, i.e., whether the errata should be rejected or accepted as verified. Thanks, Lars [*] For WGs that have concluded but whose mailing list is still active, I'm assuming that some of the relevant experts will hopefully still be subscribed RFC4171, "Internet Storage Name Service (iSNS)", September 2005 Status: Reported Type: Editorial Reported By: Hannes Reinecke Date Reported: 2006-06-23 Report Text: Section 4.1.1 refers to 'iSCSI Node Certificate', which is never defined in the document. _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Fri Jan 11 07:19:37 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDIrH-0007NW-SI; Fri, 11 Jan 2008 07:19:35 -0500 Received: from ips by megatron.ietf.org with local (Exim 4.43) id 1JDIrG-0007Ml-G5 for ips-confirm+ok@megatron.ietf.org; Fri, 11 Jan 2008 07:19:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDIrG-0007Md-6G for ips@ietf.org; Fri, 11 Jan 2008 07:19:34 -0500 Received: from smtp.nokia.com ([192.100.122.233] helo=mgw-mx06.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JDIrF-0003wb-NO for ips@ietf.org; Fri, 11 Jan 2008 07:19:34 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m0BCIdHF015428; Fri, 11 Jan 2008 14:19:30 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Jan 2008 14:19:28 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Jan 2008 14:19:27 +0200 Received: from esdhcp03947.research.nokia.com ([172.21.39.47]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Jan 2008 14:19:27 +0200 Message-Id: <8D1089D3-EB48-40D1-B1D2-EB4ACE66DD70@nokia.com> From: Lars Eggert To: ips@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Date: Fri, 11 Jan 2008 14:19:24 +0200 X-Mailer: Apple Mail (2.915) X-OriginalArrivalTime: 11 Jan 2008 12:19:27.0229 (UTC) FILETIME=[358622D0:01C8544C] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: Subject: [Ips] Errata reported for RFC4173 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 Hi, the following errata has been reported for an RFC that originated with this WG [*]. The transport ADs are soliciting comments on (1) classifying and (2) verifying the errata below. (1) The errata below should have a classification suggested by the submitter, which will either be "technical" or editorial. We're interested to hear comments on whether the current classification is accurate. (2) We're interested to hear comments on whether the errata addresses a valid technical or editorial issue with the published RFC, i.e., whether the errata should be rejected or accepted as verified. Thanks, Lars [*] For WGs that have concluded but whose mailing list is still active, I'm assuming that some of the relevant experts will hopefully still be subscribed RFC4173, "Bootstrapping Clients using the Internet Small Computer System Interface (iSCSI) Protocol", September 2005 Status: Reported Type: Editorial Reported By: Alfred Hoenes Date Reported: 2005-10-17 Report Text: Two normative references have been obsoleted: RFC 2396 ( Ref. "[Lee98]" ) and RFC 2732 ( Ref. "[Hinden99]" ) have both been obsoleted by RFC 3986 == STD 66 (published in January 2005) ! Affected pieces of RFC 4173: - Both Ref's appear once (and together) near the bottom of page 4 (in the 6th-to-last line). - Normative References section, bottom of page 9 + top of page 10 _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Mon Jan 28 12:54:20 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJYBS-0007tg-PD; Mon, 28 Jan 2008 12:54:14 -0500 Received: from ips by megatron.ietf.org with local (Exim 4.43) id 1JJYBR-0007tb-Id for ips-confirm+ok@megatron.ietf.org; Mon, 28 Jan 2008 12:54:13 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJYBQ-0007tT-Td for ips@ietf.org; Mon, 28 Jan 2008 12:54:12 -0500 Received: from mexforward.lss.emc.com ([128.222.32.20]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JJYBQ-0003nu-F1 for ips@ietf.org; Mon, 28 Jan 2008 12:54:12 -0500 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 m0SHsBJG016744; Mon, 28 Jan 2008 12:54:12 -0500 (EST) Received: from mailhub.lss.emc.com (sesha.lss.emc.com [10.254.144.12]) by hop04-l1d11-si02.isus.emc.com (Tablus Interceptor); Mon, 28 Jan 2008 12:54:11 -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 m0SHs0F6028320; Mon, 28 Jan 2008 12:54:09 -0500 (EST) From: Black_David@emc.com Received: from CORPUSMX20A.corp.emc.com ([128.221.62.11]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 28 Jan 2008 12:54:06 -0500 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] Errata reported for RFC4171 Date: Mon, 28 Jan 2008 12:54:06 -0500 Message-ID: <8CC6CEAB44F131478D3A7B429ECACD919236CE@CORPUSMX20A.corp.emc.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ips] Errata reported for RFC4171 Thread-Index: AchUTBxqzMauKqawRDCHxozFL1U3LwNildUQ References: To: , X-OriginalArrivalTime: 28 Jan 2008 17:54:06.0804 (UTC) FILETIME=[C6E7E140:01C861D6] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.8.30.53115 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: public X-Tablus-Action: allow X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 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 Lars, The comment appears to be correct, and the actual Errata should be to remove the following line from Section 4.1.1 of RFC 4171 (iSNS) because it is not supported by the iSNS protocol: iSCSI Node Certificate 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 ---------------------------------------------------- > -----Original Message----- > From: Lars Eggert [mailto:lars.eggert@nokia.com]=20 > Sent: Friday, January 11, 2008 7:16 AM > To: ips@ietf.org > Subject: [Ips] Errata reported for RFC4171 >=20 > Hi, >=20 > the following errata has been reported for an RFC that=20 > originated with =20 > this WG [*]. The transport ADs are soliciting comments on (1) =20 > classifying and (2) verifying the errata below. >=20 > (1) The errata below should have a classification suggested by the =20 > submitter, which will either be "technical" or editorial. We're =20 > interested to hear comments on whether the current classification is =20 > accurate. >=20 > (2) We're interested to hear comments on whether the errata=20 > addresses =20 > a valid technical or editorial issue with the published RFC, i.e., =20 > whether the errata should be rejected or accepted as verified. >=20 > Thanks, > Lars >=20 > [*] For WGs that have concluded but whose mailing list is still =20 > active, I'm assuming that some of the relevant experts will=20 > hopefully =20 > still be subscribed >=20 >=20 >=20 > RFC4171, "Internet Storage Name Service (iSNS)", September 2005 >=20 > Status: Reported > Type: Editorial >=20 > Reported By: Hannes Reinecke > Date Reported: 2006-06-23 > Report Text: >=20 > Section 4.1.1 refers to 'iSCSI Node Certificate', which=20 > is never =20 > defined in the document.=20 >=20 >=20 > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips >=20 >=20 _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Mon Jan 28 13:06:41 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJYNU-0005oy-32; Mon, 28 Jan 2008 13:06:40 -0500 Received: from ips by megatron.ietf.org with local (Exim 4.43) id 1JJYNT-0005oo-CR for ips-confirm+ok@megatron.ietf.org; Mon, 28 Jan 2008 13:06:39 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJYNT-0005oe-02 for ips@ietf.org; Mon, 28 Jan 2008 13:06:39 -0500 Received: from mexforward.lss.emc.com ([128.222.32.20]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JJYNS-00047s-EF for ips@ietf.org; Mon, 28 Jan 2008 13:06:38 -0500 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 m0SI6bqr000150; Mon, 28 Jan 2008 13:06:38 -0500 (EST) Received: from mailhub.lss.emc.com (nagas.lss.emc.com [10.254.144.11]) by hop04-l1d11-si02.isus.emc.com (Tablus Interceptor); Mon, 28 Jan 2008 13:06:37 -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 m0SI6aQg017468; Mon, 28 Jan 2008 13:06:36 -0500 (EST) From: Black_David@emc.com Received: from CORPUSMX20A.corp.emc.com ([128.221.62.11]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 28 Jan 2008 12:58:17 -0500 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] Errata reported for RFC4173 Date: Mon, 28 Jan 2008 12:58:15 -0500 Message-ID: <8CC6CEAB44F131478D3A7B429ECACD919236CF@CORPUSMX20A.corp.emc.com> In-Reply-To: <8D1089D3-EB48-40D1-B1D2-EB4ACE66DD70@nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ips] Errata reported for RFC4173 Thread-Index: AchUTF3RAlKxFA/jSU+reTSZYmJg/gNiqU4Q References: <8D1089D3-EB48-40D1-B1D2-EB4ACE66DD70@nokia.com> To: , X-OriginalArrivalTime: 28 Jan 2008 17:58:17.0665 (UTC) FILETIME=[5C6E3B10:01C861D7] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.8.30.53115 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 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 Lars, Independent of the publication date, the work on the draft that became this RFC significantly predates publication of RFC 3986. The references to those two RFCs are correct, and the obsoleted status of the RFCs can be readily determined from the RFC Editor's database. I do not believe it is an appropriate use of Errata to record the fact that referenced RFCs have been obsoleted. 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 ---------------------------------------------------- > -----Original Message----- > From: Lars Eggert [mailto:lars.eggert@nokia.com]=20 > Sent: Friday, January 11, 2008 7:19 AM > To: ips@ietf.org > Subject: [Ips] Errata reported for RFC4173 >=20 > Hi, >=20 > the following errata has been reported for an RFC that=20 > originated with =20 > this WG [*]. The transport ADs are soliciting comments on (1) =20 > classifying and (2) verifying the errata below. >=20 > (1) The errata below should have a classification suggested by the =20 > submitter, which will either be "technical" or editorial. We're =20 > interested to hear comments on whether the current classification is =20 > accurate. >=20 > (2) We're interested to hear comments on whether the errata=20 > addresses =20 > a valid technical or editorial issue with the published RFC, i.e., =20 > whether the errata should be rejected or accepted as verified. >=20 > Thanks, > Lars >=20 > [*] For WGs that have concluded but whose mailing list is still =20 > active, I'm assuming that some of the relevant experts will=20 > hopefully =20 > still be subscribed >=20 >=20 >=20 > RFC4173, "Bootstrapping Clients using the Internet Small Computer =20 > System Interface (iSCSI) Protocol", September 2005 >=20 > Status: Reported > Type: Editorial >=20 > Reported By: Alfred Hoenes > Date Reported: 2005-10-17 > Report Text: >=20 > Two normative references have been obsoleted: > RFC 2396 ( Ref. "[Lee98]" ) > and > RFC 2732 ( Ref. "[Hinden99]" ) > have both been obsoleted by RFC 3986 =3D=3D STD 66 (published in = January =20 > 2005) ! >=20 > Affected pieces of RFC 4173: > - Both Ref's appear once (and together) near the bottom of=20 > page 4 (in =20 > the 6th-to-last line). > - Normative References section, bottom of page 9 + top of page 10=20 >=20 >=20 > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips >=20 >=20 _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From bestbargins@stevenson.mb.ca Thu Jan 31 22:59:05 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 7ADDF3A680F for ; Thu, 31 Jan 2008 22:59:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: YES X-Spam-Score: 28.782 X-Spam-Level: **************************** X-Spam-Status: Yes, score=28.782 tagged_above=-999 required=5 tests=[BAYES_80=2, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BLUEYON=1.4, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, NORMAL_HTTP_TO_IP=0.001, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931] X-Spam-Report: * 1.4 HELO_EQ_BLUEYON HELO_EQ_BLUEYON * 1.4 HOST_EQ_MODEMCABLE HOST_EQ_MODEMCABLE * 0.8 FH_HOST_EQ_D_D_D_D Host starts with d-d-d-d * 0.8 HELO_EQ_MODEMCABLE HELO_EQ_MODEMCABLE * 0.9 FH_HOST_EQ_D_D_D_DB Host is d-d-d-d * 4.3 HELO_DYNAMIC_HCC Relay HELO'd using suspicious hostname (HCC) * 4.4 HELO_DYNAMIC_IPADDR2 Relay HELO'd using suspicious hostname (IP addr * 2) * 1.6 FH_HELO_EQ_D_D_D_D Helo is d-d-d-d * 1.9 TVD_RCVD_IP TVD_RCVD_IP * 0.0 NORMAL_HTTP_TO_IP URI: Uses a dotted-decimal IP address in URL * 2.0 BAYES_80 BODY: Bayesian spam probability is 80 to 95% * [score: 0.8407] * 0.5 RAZOR2_CHECK Listed in Razor2 (http://razor.sf.net/) * 2.0 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net * [Blocked - see ] * 0.9 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP address * [62.30.175.198 listed in dnsbl.sorbs.net] * 0.9 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL * [62.30.175.198 listed in zen.spamhaus.org] * 3.0 RCVD_IN_XBL RBL: Received via a relay in Spamhaus XBL * 2.0 FM_DDDD_TIMES_2 Dual helo + host eq d_d_d_d * 0.1 RDNS_DYNAMIC Delivered to trusted network by host with * dynamic-looking rDNS Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1FNLDxC0RHDa for ; Thu, 31 Jan 2008 22:59:04 -0800 (PST) Received: from 62-30-175-198.cable.ubr06.dund.blueyonder.co.uk (62-30-175-198.cable.ubr06.dund.blueyonder.co.uk [62.30.175.198]) by core3.amsl.com (Postfix) with SMTP id 1D9BF3A680A for ; Thu, 31 Jan 2008 22:59:03 -0800 (PST) Received: from wdirf ([181.63.168.189]) by 62-30-175-198.cable.ubr06.dund.blueyonder.co.uk (8.13.3/8.13.3) with SMTP id m117578I032459; Fri, 1 Feb 2008 07:05:07 +0000 Message-ID: <47A2C398.1030402@stevenson.mb.ca> Date: Fri, 1 Feb 2008 07:00:40 +0000 From: User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: ips-archive@lists.ietf.org Subject: ***SPAM*** 28.782 (5) Happy I'll Be Your Bride Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Eternity of Your Love http://221.124.246.42/