From ips-bounces@ietf.org Fri Jul 01 14:44:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoQUb-0003VZ-J8; Fri, 01 Jul 2005 14:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoQUZ-0003VP-Qg for ips@megatron.ietf.org; Fri, 01 Jul 2005 14:43:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27587 for ; Fri, 1 Jul 2005 14:43:55 -0400 (EDT) Received: from sccrmhc12.comcast.net ([204.127.202.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DoQuZ-0004EX-QU for ips@ietf.org; Fri, 01 Jul 2005 15:10:53 -0400 Received: from ivvt2dxrc11 (c-66-177-46-174.hsd1.fl.comcast.net[66.177.46.174]) by comcast.net (sccrmhc12) with SMTP id <2005070118434901200hdpo7e>; Fri, 1 Jul 2005 18:43:49 +0000 Message-ID: <000601c57e6c$d1c9fad0$03031eac@ivivity.com> From: "Eddy Quicksall" To: Date: Fri, 1 Jul 2005 14:43:48 -0400 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.6 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Subject: [Ips] target/initiator device 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="===============1639978358==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============1639978358== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01C57E4B.4A14EEE0" This is a multi-part message in MIME format. ------=_NextPart_000_0003_01C57E4B.4A14EEE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable How does iSCSI work as a target/initiator device? i.e., iSCSI has = different types of names for the initiator and target names but = paragraph 4.7.3 in SAM 3 appears to need a common name between the two. Eddy ------=_NextPart_000_0003_01C57E4B.4A14EEE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

How does iSCSI work as a target/initiator = device?=20 i.e., iSCSI has different types of names for the initiator and target = names but=20 paragraph 4.7.3 in SAM 3 appears to need a common name between the=20 two.

Eddy

------=_NextPart_000_0003_01C57E4B.4A14EEE0-- --===============1639978358== 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 --===============1639978358==-- From ips-bounces@ietf.org Sat Jul 02 03:26:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DocOs-0002Fq-Pu; Sat, 02 Jul 2005 03:26:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DocOq-0002Fg-8a for ips@megatron.ietf.org; Sat, 02 Jul 2005 03:26:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14719 for ; Sat, 2 Jul 2005 03:26:49 -0400 (EDT) Received: from mtagate2.de.ibm.com ([195.212.29.151]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Docow-0000Ee-Bt for ips@ietf.org; Sat, 02 Jul 2005 03:53:51 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id j627QUew173324 for ; Sat, 2 Jul 2005 07:26:30 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j627QT2M137624 for ; Sat, 2 Jul 2005 09:26:29 +0200 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id j627QTaC007285 for ; Sat, 2 Jul 2005 09:26:29 +0200 Received: from d12ml102.megacenter.de.ibm.com (d12ml102.megacenter.de.ibm.com [9.149.166.138]) by d12av02.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j627QTKk007282; Sat, 2 Jul 2005 09:26:29 +0200 In-Reply-To: <000601c57e6c$d1c9fad0$03031eac@ivivity.com> To: "Eddy Quicksall" Subject: Re: [Ips] target/initiator device MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_06152005NP June 15, 2005 From: Julian Satran Message-ID: Date: Sat, 2 Jul 2005 10:26:26 +0300 X-MIMETrack: Serialize by Router on D12ML102/12/M/IBM(Release 6.5.1| March 5, 2004) at 02/07/2005 10:26:28, Serialize complete at 02/07/2005 10:26:28 X-Spam-Score: 2.0 (++) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c 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="===============1482555314==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org --===============1482555314== Content-Type: text/html; charset="US-ASCII"
Eddy,

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

Julo

"Eddy Quicksall" <eddy_quicksall_iVivity_iSCSI@comcast.net>
Sent by: ips-bounces@ietf.org

01/07/2005 21:43

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

How does iSCSI work as a target/initiator device? i.e., iSCSI has different types of names for the initiator and target names but paragraph 4.7.3 in SAM 3 appears to need a common name between the two.

Eddy_______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips
--===============1482555314== 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 --===============1482555314==-- From ips-bounces@ietf.org Tue Jul 12 10:50:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsM5Q-0003IK-P9; Tue, 12 Jul 2005 10:50:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsM5C-00037Z-W8; Tue, 12 Jul 2005 10:50:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29711; Tue, 12 Jul 2005 10:50:00 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsMXQ-0007oV-AZ; Tue, 12 Jul 2005 11:19:12 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1DsM5B-0006oH-K3; Tue, 12 Jul 2005 10:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 12 Jul 2005 10:50:01 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: ips@ietf.org Subject: [Ips] I-D ACTION:draft-ietf-ips-iscsi-impl-guide-00.txt X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Storage Working Group of the IETF. Title : iSCSI Implementer's Guide Author(s) : M. Chadalapaka Filename : draft-ietf-ips-iscsi-impl-guide-00.txt,.pdf Pages : 19 Date : 2005-7-12 iSCSI is a SCSI transport protocol and maps the SCSI family of application protocols onto TCP/IP. RFC 3720 defines the iSCSI protocol. This document compiles the clarifications to the original protocol definition in RFC 3720 to serve as a companion document for the iSCSI implementers. This document updates RFC 3720 and the text in this document supersedes the text in RFC 3720 when the two differ. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-impl-guide-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ips-iscsi-impl-guide-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ips-iscsi-impl-guide-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-7-12101205.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-iscsi-impl-guide-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-iscsi-impl-guide-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-7-12101205.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --NextPart-- From ips-bounces@ietf.org Tue Jul 12 23:58:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsYNl-0003XP-PE; Tue, 12 Jul 2005 23:58:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsYNj-0003Ur-Pr for ips@megatron.ietf.org; Tue, 12 Jul 2005 23:57:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23267 for ; Tue, 12 Jul 2005 23:57:57 -0400 (EDT) Received: from mononoke.wasabisystems.com ([66.173.145.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsYq3-0003kR-2Q for ips@ietf.org; Wed, 13 Jul 2005 00:27:16 -0400 Received: from [172.20.100.149] (unknown [12.105.77.226]) by mononoke.wasabisystems.com (Postfix) with ESMTP id D206687061 for ; Tue, 12 Jul 2005 23:57:47 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v622) In-Reply-To: References: Message-Id: From: William Studenmund Date: Tue, 12 Jul 2005 23:57:41 -0400 To: IPS X-Pgp-Agent: GPGMail 1.0 (v30, 10.3) X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Subject: [Ips] Residuals, Re: draft-ietf-ips-iscsi-impl-guide-00.txt X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1097449214==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org --===============1097449214== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-4--961542791" Content-Transfer-Encoding: 7bit --Apple-Mail-4--961542791 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mallikarjun, Thank you for working on this draft. I think it will help clarify a number of points. I think section 3, however, could use some modification. I have two main concerns with it. First, it focuses a lot on the REPORT LUNS command. However that command is not the only command that behaves this way. Any command that uses an "Allocation Length" parameter is in this class, such as INQUIRY and MODE SENSE. I think we should generalize this discussion so it is clear that it applies to all of them. Second, I think it would be good to add a SCSI Expected Data Transfer Length (SEDTL) term and concept. This concept is present in the text, but unnamed. I think naming it will add a lot of clarity to the discussion. For a REPORT LUNS command, an INQUIRY command, a MODE SENSE command, or other comparable commands, the SEDTL is given by the ALLOCATION LENGTH in the CDB. For SCSI READ or WRITE commands to a disk, the SEDTL is given by the block size multiplied by the number of blocks to transfer. I'm not 100% sure what the SEDTL is for a tape drive in face of varying block sizes. (O) and (U) bits then depend only on the difference between the EDTL and the SEDTL (assuming I understand the concept right :-) . Then the second paragraph of 3.1 becomes something like: iSCSI uses the (O) bit (bit 5) in the Flags field of the SCSI Response and SCSI Data-Out PDUs for READ-type commands (or the (o) bit, bit 3, for bidirectional commands) to indicate that an iSCSI target was unable to transfer to the initiator all of the SCSI data for a command because the SEDTL exceeded the EDTL. I also am concerned with the use of "at least" in the fourth paragraph. While correct, my concern is that if the EDTL is greater than the SEDTL (ALLOCATION LENGTH), we in fact need to set the (U) bit and note an under run, :-) To make sure I understand it: For a write phase: If SEDTL is greater than EDTL, we wanted more data than we got. After the command completes, we will report an under run of SEDTL - EDTL. If SEDTL is less than EDTL, we got more data than we wanted. After the command completes, we will report an overrun of EDTL - SEDTL. For a read phase: If SEDTL is greater than EDTL, we got more data than we wanted. After the command completes, we will report an overrun of SEDTL - EDTL. If SEDTL is less than EDTL, we wanted more data than we got. After the command completes, we will report an under run of EDTL - SEDTL. Did I get that right? Also, what do we do in case of an error? In addition to CHECK CONDITION and ASC/ASCQ, do we try to flag either an under run or overrun to indicate how far we got into the transaction before the error happened? Take care, Bill --Apple-Mail-4--961542791 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFC1JE6DJT2Egh26K0RAibQAJ900owwm6QytLWfWn6QS8aKE+8qEwCfQJMh v52SnpFaXfwIJL57A8J2EH8= =1VSS -----END PGP SIGNATURE----- --Apple-Mail-4--961542791-- --===============1097449214== 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 --===============1097449214==-- From ips-bounces@ietf.org Thu Jul 14 16:17:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtA2d-0006uv-5q; Thu, 14 Jul 2005 16:10:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtA2b-0006ul-Gl for ips@megatron.ietf.org; Thu, 14 Jul 2005 16:10:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19108 for ; Thu, 14 Jul 2005 16:10:39 -0400 (EDT) Received: from palrel13.hp.com ([156.153.255.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtAVF-000265-LQ for ips@ietf.org; Thu, 14 Jul 2005 16:40:19 -0400 Received: from rosemail.rose.hp.com (rosemail.rose.hp.com [15.43.209.160]) by palrel13.hp.com (Postfix) with ESMTP id A027D1C045CE for ; Sat, 16 Jul 2005 18:00:57 -0700 (PDT) Received: from [127.0.0.1] (sindhu.americas.hpqcorp.net [16.93.44.53]) by rosemail.rose.hp.com (Postfix) with ESMTP id A34C982C4 for ; Thu, 14 Jul 2005 13:03:03 -0700 (PDT) Message-ID: <42D6C6BC.5090406@rose.hp.com> Date: Thu, 14 Jul 2005 13:10:36 -0700 From: "Mallikarjun C." User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IPS Subject: Re: [Ips] Residuals, Re: draft-ietf-ips-iscsi-impl-guide-00.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Content-Transfer-Encoding: 7bit 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: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org Bill, >I think we should generalize this discussion so it is clear that > it applies to all of them. I think that's a good suggestion. > Second, I think it would be good to add a SCSI Expected Data Transfer > Length (SEDTL) term and concept. We have to be careful not to assume that all SCSI-level *expected* data is transacted through the iSCSI layer. E.g., target SCSI device server may not have *presented* enough bytes to iSCSI layer for the Data-in buffer, say, due to bad blocks. I think the iSCSI layer should not flag an Overflow if its EDTL matched with what was presented to it, regardless of the SEDTL value. I would suggest the notion of "SCSI-Presented Data Transfer Length" (SPDTL) to denote the aggregate data length that the SCSI layer presents to iSCSI layer for a Data-in/out transfer in the context of a SCSI task. If you agree, it would then be: SPDTL > EDTL --> iSCSI Overflow Residual Count = SPDTL - EDTL SPDTL < EDTL --> iSCSI Underflow Residual Count = EDTL - SPDTL Similar approach applies to bidirectional operations. > I also am concerned with the use of "at least" in the fourth paragraph. > While correct, my concern is that if the EDTL is greater than the SEDTL > (ALLOCATION LENGTH), we in fact need to set the (U) bit and note an > under run, :-) You are correct, although the text as written is accurate. I agree it would be good to note the underflow scenario. I'll do it in the next rev. > Did I get that right? I think you got the write under/overflows backwards. IOW, I do not see how the underflow/overflow result changes between read & write for given SPTDL & EDTL values (RFC 3720, 10.4.1 doesn't qualify the definitions based on read & write) ..... >In addition to CHECK CONDITION > and ASC/ASCQ, do we try to flag either an under run or overrun to > indicate how far we got into the transaction before the error happened? iSCSI should be technically ignorant of SCSI error specifics. I suggest the only factor for setting the U & O bits (and their lower-case friends) at the iSCSI layer be SPDTL. In short, "it depends". Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture StorageWorks Division Hewlett-Packard MS 5668 Roseville CA 95747 cbm [at] rose.hp.com William Studenmund wrote: > Mallikarjun, > > Thank you for working on this draft. I think it will help clarify a > number of points. > > I think section 3, however, could use some modification. I have two main > concerns with it. > > First, it focuses a lot on the REPORT LUNS command. However that command > is not the only command that behaves this way. Any command that uses an > "Allocation Length" parameter is in this class, such as INQUIRY and MODE > SENSE. I think we should generalize this discussion so it is clear that > it applies to all of them. > > Second, I think it would be good to add a SCSI Expected Data Transfer > Length (SEDTL) term and concept. This concept is present in the text, > but unnamed. I think naming it will add a lot of clarity to the discussion. > > For a REPORT LUNS command, an INQUIRY command, a MODE SENSE command, or > other comparable commands, the SEDTL is given by the ALLOCATION LENGTH > in the CDB. For SCSI READ or WRITE commands to a disk, the SEDTL is > given by the block size multiplied by the number of blocks to transfer. > I'm not 100% sure what the SEDTL is for a tape drive in face of varying > block sizes. > > (O) and (U) bits then depend only on the difference between the EDTL and > the SEDTL (assuming I understand the concept right :-) . > > Then the second paragraph of 3.1 becomes something like: > > iSCSI uses the (O) bit (bit 5) in the Flags field of the SCSI Response > and SCSI Data-Out PDUs for READ-type commands (or the (o) bit, bit 3, > for bidirectional commands) to indicate that an iSCSI target was unable > to transfer to the initiator all of the SCSI data for a command because > the SEDTL exceeded the EDTL. > > I also am concerned with the use of "at least" in the fourth paragraph. > While correct, my concern is that if the EDTL is greater than the SEDTL > (ALLOCATION LENGTH), we in fact need to set the (U) bit and note an > under run, :-) > > To make sure I understand it: > > For a write phase: > > If SEDTL is greater than EDTL, we wanted more data than we got. After > the command completes, we will report an under run of SEDTL - EDTL. > > If SEDTL is less than EDTL, we got more data than we wanted. After the > command completes, we will report an overrun of EDTL - SEDTL. > > For a read phase: > > If SEDTL is greater than EDTL, we got more data than we wanted. After > the command completes, we will report an overrun of SEDTL - EDTL. > > If SEDTL is less than EDTL, we wanted more data than we got. After the > command completes, we will report an under run of EDTL - SEDTL. > > > Did I get that right? > > Also, what do we do in case of an error? In addition to CHECK CONDITION > and ASC/ASCQ, do we try to flag either an under run or overrun to > indicate how far we got into the transaction before the error happened? > > Take care, > > Bill > > > ------------------------------------------------------------------------ > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Fri Jul 15 01:44:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtIzo-0003Hb-UG; Fri, 15 Jul 2005 01:44:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtIzj-000366-Ty for ips@megatron.ietf.org; Fri, 15 Jul 2005 01:44:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11901 for ; Fri, 15 Jul 2005 01:44:15 -0400 (EDT) Received: from mononoke.wasabisystems.com ([66.173.145.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtJSQ-0000jB-1n for ips@ietf.org; Fri, 15 Jul 2005 02:14:00 -0400 Received: from [10.0.0.10] (h-66-166-188-91.sndacagl.covad.net [66.166.188.91]) by mononoke.wasabisystems.com (Postfix) with ESMTP id 7C07E87090; Fri, 15 Jul 2005 01:44:05 -0400 (EDT) In-Reply-To: <42D6C6BC.5090406@rose.hp.com> References: <42D6C6BC.5090406@rose.hp.com> Mime-Version: 1.0 (Apple Message framework v622) Message-Id: From: William Studenmund Subject: Re: [Ips] Residuals, Re: draft-ietf-ips-iscsi-impl-guide-00.txt Date: Thu, 14 Jul 2005 22:43:57 -0700 To: "Mallikarjun C." X-Pgp-Agent: GPGMail 1.0 (v30, 10.3) X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: IPS 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="===============0056488170==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org --===============0056488170== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-2--782366731" Content-Transfer-Encoding: 7bit --Apple-Mail-2--782366731 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Jul 14, 2005, at 1:10 PM, Mallikarjun C. wrote: > Bill, > > >I think we should generalize this discussion so it is clear that > > it applies to all of them. > > I think that's a good suggestion. > > > Second, I think it would be good to add a SCSI Expected Data Transfer > > Length (SEDTL) term and concept. > > We have to be careful not to assume that all SCSI-level *expected* > data is transacted through the iSCSI layer. E.g., target SCSI device > server may not have *presented* enough bytes to iSCSI layer for the > Data-in buffer, say, due to bad blocks. I think the iSCSI layer > should not flag an Overflow if its EDTL matched with what was > presented to it, regardless of the SEDTL value. Ok, another term will be good. I was 1) focusing on non-error cases, and 2) trying to differentiate between how much REPORT LUNS/MODE SENSE/etc. data are there and how much SCSI expects to transfer. i.e. the whole REPORT LUNS discussion gets clearer when there were two different SCSI lengths involved. We can then say that only one of them matters for O&I. I agree that in an error case, we should not use the "expected" amount but something more reflective of reality. > I would suggest the notion of "SCSI-Presented Data Transfer Length" > (SPDTL) to denote the aggregate data length that the SCSI layer > presents to iSCSI layer for a Data-in/out transfer in the context of a > SCSI task. > > If you agree, it would then be: > > SPDTL > EDTL --> iSCSI Overflow Residual Count = SPDTL - EDTL > SPDTL < EDTL --> iSCSI Underflow Residual Count = EDTL - SPDTL > > Similar approach applies to bidirectional operations. > > > I also am concerned with the use of "at least" in the fourth > paragraph. > > While correct, my concern is that if the EDTL is greater than the > SEDTL > > (ALLOCATION LENGTH), we in fact need to set the (U) bit and note an > > under run, :-) > > You are correct, although the text as written is accurate. I agree it > would be good to note the underflow scenario. I'll do it in the next > rev. > > > Did I get that right? > > I think you got the write under/overflows backwards. IOW, I do not > see how the underflow/overflow result changes between read & write for > given SPTDL & EDTL values (RFC 3720, 10.4.1 doesn't qualify the > definitions based on read & write) ..... Then we definitely need to document this! I always understood overflow to mean you had more data than wanted and underflow to mean you got less than wanted. That's probably as I started out with serial ports where bit and byte timings could generate these issues. The flipping was deliberate, and reflected the fact that in write cases, iSCSI is presenting data to SCSI (that then doesn't know what to do with it) and in read cases, SCSI presents data to iSCSI which can't do anything with it. Looking at 10.4.1, you are right that it has no reflection. While I find this definition counter-intuitive, it has a bit of symmetry; it's always the iSCSI # relative to the SCSI #. > >In addition to CHECK CONDITION > > and ASC/ASCQ, do we try to flag either an under run or overrun to > > indicate how far we got into the transaction before the error > happened? > > iSCSI should be technically ignorant of SCSI error specifics. I > suggest the only factor for setting the U & O bits (and their > lower-case friends) at the iSCSI layer be SPDTL. In short, "it > depends". I think we're agreeing. I agree iSCSI shouldn't care about the error code, I was just trying to figure out what a target does in addition to setting them. Admittedly I'm coming from an integrated SCSI/iSCSI target scenario. :-) Take care, Bill --Apple-Mail-2--782366731 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFC100jDJT2Egh26K0RAgMLAJ0azNVJ43GhfhSh+obJ0XcycLSsfwCfbZft cNbB+fV8+3rnwsfF0ZdLFW8= =cEt7 -----END PGP SIGNATURE----- --Apple-Mail-2--782366731-- --===============0056488170== 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 --===============0056488170==-- From ips-bounces@ietf.org Fri Jul 15 09:29:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtQFj-0004Yq-Ko; Fri, 15 Jul 2005 09:29:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtQFd-0004Ya-8X; Fri, 15 Jul 2005 09:29:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05045; Fri, 15 Jul 2005 09:29:11 -0400 (EDT) Received: from mtagate4.de.ibm.com ([195.212.29.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtQiR-0000Rw-SH; Fri, 15 Jul 2005 09:59:00 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id j6FDT2YR165594; Fri, 15 Jul 2005 13:29:02 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j6FDT2rv180406; Fri, 15 Jul 2005 15:29:02 +0200 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id j6FDT2bP004369; Fri, 15 Jul 2005 15:29:02 +0200 Received: from d12ml102.megacenter.de.ibm.com (d12ml102.megacenter.de.ibm.com [9.149.166.138]) by d12av04.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j6FDT2FS004366; Fri, 15 Jul 2005 15:29:02 +0200 In-Reply-To: To: William Studenmund Subject: Re: [Ips] Residuals, Re: draft-ietf-ips-iscsi-impl-guide-00.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_M6_06302005 Beta 4NP June 30, 2005 From: Julian Satran Message-ID: Date: Fri, 15 Jul 2005 16:29:00 +0300 X-MIMETrack: Serialize by Router on D12ML102/12/M/IBM(Release 6.5.1| March 5, 2004) at 15/07/2005 16:29:01 Content-Type: multipart/mixed; boundary="=_mixed 004603CF8525703F_=" X-Spam-Score: 2.3 (++) X-Scan-Signature: ccfb4541e989aa743998098cd315d0fd Cc: IPS , ips-bounces@ietf.org, "Mallikarjun C." 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: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org --=_mixed 004603CF8525703F_= Content-Type: text/html; charset="US-ASCII"
You may want to consider that in any decent implementation the overrun/underrun values (counts not flags) will probably originate from SCSI. This may make you want to change SPDTL into P(otential)SPDTL - :-)

On a more philosophical plan underflow/overflow is basically a SCSI issue that originates by SCSI using two potentially different length related parameters.
Some are classics (blocks/buffer) and some are new (allocated vs. expected). The origin of the mess is the parallel SCSI where length (EDTL) was not conveyed to target.
- and it is still with us.

Julo

William Studenmund <wrstuden@wasabisystems.com>
Sent by: ips-bounces@ietf.org

15/07/2005 01:43

To	"Mallikarjun C." <cbm@rose.hp.com>
cc	IPS <ips@ietf.org>
Subject	Re: [Ips] Residuals, Re: draft-ietf-ips-iscsi-impl-guide-00.txt

On Jul 14, 2005, at 1:10 PM, Mallikarjun C. wrote: > Bill, > > >I think we should generalize this discussion so it is clear that > > it applies to all of them. > > I think that's a good suggestion. > > > Second, I think it would be good to add a SCSI Expected Data Transfer > > Length (SEDTL) term and concept. > > We have to be careful not to assume that all SCSI-level *expected* > data is transacted through the iSCSI layer. E.g., target SCSI device > server may not have *presented* enough bytes to iSCSI layer for the > Data-in buffer, say, due to bad blocks. I think the iSCSI layer > should not flag an Overflow if its EDTL matched with what was > presented to it, regardless of the SEDTL value. Ok, another term will be good. I was 1) focusing on non-error cases, and 2) trying to differentiate between how much REPORT LUNS/MODE SENSE/etc. data are there and how much SCSI expects to transfer. i.e. the whole REPORT LUNS discussion gets clearer when there were two different SCSI lengths involved. We can then say that only one of them matters for O&I. I agree that in an error case, we should not use the "expected" amount but something more reflective of reality. > I would suggest the notion of "SCSI-Presented Data Transfer Length" > (SPDTL) to denote the aggregate data length that the SCSI layer > presents to iSCSI layer for a Data-in/out transfer in the context of a > SCSI task. > > If you agree, it would then be: > > SPDTL > EDTL --> iSCSI Overflow Residual Count = SPDTL - EDTL > SPDTL < EDTL --> iSCSI Underflow Residual Count = EDTL - SPDTL > > Similar approach applies to bidirectional operations. > > > I also am concerned with the use of "at least" in the fourth > paragraph. > > While correct, my concern is that if the EDTL is greater than the > SEDTL > > (ALLOCATION LENGTH), we in fact need to set the (U) bit and note an > > under run, :-) > > You are correct, although the text as written is accurate. I agree it > would be good to note the underflow scenario. I'll do it in the next > rev. > > > Did I get that right? > > I think you got the write under/overflows backwards. IOW, I do not > see how the underflow/overflow result changes between read & write for > given SPTDL & EDTL values (RFC 3720, 10.4.1 doesn't qualify the > definitions based on read & write) ..... Then we definitely need to document this! I always understood overflow to mean you had more data than wanted and underflow to mean you got less than wanted. That's probably as I started out with serial ports where bit and byte timings could generate these issues. The flipping was deliberate, and reflected the fact that in write cases, iSCSI is presenting data to SCSI (that then doesn't know what to do with it) and in read cases, SCSI presents data to iSCSI which can't do anything with it. Looking at 10.4.1, you are right that it has no reflection. While I find this definition counter-intuitive, it has a bit of symmetry; it's always the iSCSI # relative to the SCSI #. > >In addition to CHECK CONDITION > > and ASC/ASCQ, do we try to flag either an under run or overrun to > > indicate how far we got into the transaction before the error > happened? > > iSCSI should be technically ignorant of SCSI error specifics. I > suggest the only factor for setting the U & O bits (and their > lower-case friends) at the iSCSI layer be SPDTL. In short, "it > depends". I think we're agreeing. I agree iSCSI shouldn't care about the error code, I was just trying to figure out what a target does in addition to setting them. Admittedly I'm coming from an integrated SCSI/iSCSI target scenario. :-) Take care, Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips
--=_mixed 004603CF8525703F_= Content-Type: application/octet-stream; name="PGP.sig" Content-Disposition: attachment; filename="PGP.sig" Content-Transfer-Encoding: base64 LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0NClZlcnNpb246IEdudVBHIHYxLjIuMyAoRGFy d2luKQ0KDQppRDhEQlFGQzEwMGpESlQyRWdoMjZLMFJBZ01MQUowYXpOVko0M0doZmhTaCtvYkow WGN5Y0xTc2Z3Q2ZiWmZ0DQpjTmJCK2ZWOCszcm53c2ZGMFpkTEZXOD0NCj1jRXQ3DQotLS0tLUVO RCBQR1AgU0lHTkFUVVJFLS0tLS0NCg== --=_mixed 004603CF8525703F_= 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 --=_mixed 004603CF8525703F_=-- From ips-bounces@ietf.org Fri Jul 15 14:44:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtVAZ-00063f-EL; Fri, 15 Jul 2005 14:44:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtVAX-00063Y-CE for ips@megatron.ietf.org; Fri, 15 Jul 2005 14:44:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04987 for ; Fri, 15 Jul 2005 14:44:15 -0400 (EDT) Received: from atlrel6.hp.com ([156.153.255.205]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtVdO-0005Rq-Ui for ips@ietf.org; Fri, 15 Jul 2005 15:14:07 -0400 Received: from rosemail.rose.hp.com (rosemail.rose.hp.com [15.43.209.160]) by atlrel6.hp.com (Postfix) with ESMTP id ADC8ABD9D for ; Fri, 15 Jul 2005 14:44:15 -0400 (EDT) Received: from [127.0.0.1] (sindhu.americas.hpqcorp.net [16.93.44.53]) by rosemail.rose.hp.com (Postfix) with ESMTP id 3A9A78000 for ; Fri, 15 Jul 2005 11:36:49 -0700 (PDT) Message-ID: <42D80408.1060108@rose.hp.com> Date: Fri, 15 Jul 2005 11:44:24 -0700 From: "Mallikarjun C." User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IPS Subject: Re: [Ips] Residuals, Re: draft-ietf-ips-iscsi-impl-guide-00.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba Content-Transfer-Encoding: 7bit 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: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org > You may want to consider that in any decent implementation the > overrun/underrun values (counts not flags) will probably originate from > SCSI. This may make you want to change SPDTL into P(otential)SPDTL - :-) That is a good observation, I'll add a sentence to the draft to include this idea. I'd though leave the SPDTL unchanged because the "presenting" really is logical (and I'll note it as such). As Bill requested, I'll also document the fact that underflow/overflow & residual count setting are agnostic about reads & writes. The only exception is when read and write are *both* in progress (bidirectional operation), in which case, the residuals and flags for bidi reads are to be captured separately in other header fields (the over/underflow logic is still the same even here, results merely encoded in different fields). Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture StorageWorks Division Hewlett-Packard MS 5668 Roseville CA 95747 cbm [at] rose.hp.com Julian Satran wrote: > > You may want to consider that in any decent implementation the > overrun/underrun values (counts not flags) will probably originate from > SCSI. This may make you want to change SPDTL into P(otential)SPDTL - :-) > > On a more philosophical plan underflow/overflow is basically a SCSI > issue that originates by SCSI using two potentially different length > related parameters. > Some are classics (blocks/buffer) and some are new (allocated vs. > expected). The origin of the mess is the parallel SCSI where length > (EDTL) was not conveyed to target. > - and it is still with us. > > Julo > > > *William Studenmund * > Sent by: ips-bounces@ietf.org > > 15/07/2005 01:43 > > > To > "Mallikarjun C." > cc > IPS > Subject > Re: [Ips] Residuals, Re: draft-ietf-ips-iscsi-impl-guide-00.txt > > > > > > > > > On Jul 14, 2005, at 1:10 PM, Mallikarjun C. wrote: > > > Bill, > > > > >I think we should generalize this discussion so it is clear that > > > it applies to all of them. > > > > I think that's a good suggestion. > > > > > Second, I think it would be good to add a SCSI Expected Data Transfer > > > Length (SEDTL) term and concept. > > > > We have to be careful not to assume that all SCSI-level *expected* > > data is transacted through the iSCSI layer. E.g., target SCSI device > > server may not have *presented* enough bytes to iSCSI layer for the > > Data-in buffer, say, due to bad blocks. I think the iSCSI layer > > should not flag an Overflow if its EDTL matched with what was > > presented to it, regardless of the SEDTL value. > > Ok, another term will be good. I was 1) focusing on non-error cases, > and 2) trying to differentiate between how much REPORT LUNS/MODE > SENSE/etc. data are there and how much SCSI expects to transfer. i.e. > the whole REPORT LUNS discussion gets clearer when there were two > different SCSI lengths involved. We can then say that only one of them > matters for O&I. > > I agree that in an error case, we should not use the "expected" amount > but something more reflective of reality. > > > I would suggest the notion of "SCSI-Presented Data Transfer Length" > > (SPDTL) to denote the aggregate data length that the SCSI layer > > presents to iSCSI layer for a Data-in/out transfer in the context of a > > SCSI task. > > > > If you agree, it would then be: > > > > SPDTL > EDTL --> iSCSI Overflow Residual Count = SPDTL - EDTL > > SPDTL < EDTL --> iSCSI Underflow Residual Count = EDTL - SPDTL > > > > Similar approach applies to bidirectional operations. > > > > > I also am concerned with the use of "at least" in the fourth > > paragraph. > > > While correct, my concern is that if the EDTL is greater than the > > SEDTL > > > (ALLOCATION LENGTH), we in fact need to set the (U) bit and note an > > > under run, :-) > > > > You are correct, although the text as written is accurate. I agree it > > would be good to note the underflow scenario. I'll do it in the next > > rev. > > > > > Did I get that right? > > > > I think you got the write under/overflows backwards. IOW, I do not > > see how the underflow/overflow result changes between read & write for > > given SPTDL & EDTL values (RFC 3720, 10.4.1 doesn't qualify the > > definitions based on read & write) ..... > > Then we definitely need to document this! > > I always understood overflow to mean you had more data than wanted and > underflow to mean you got less than wanted. That's probably as I > started out with serial ports where bit and byte timings could generate > these issues. > > The flipping was deliberate, and reflected the fact that in write > cases, iSCSI is presenting data to SCSI (that then doesn't know what to > do with it) and in read cases, SCSI presents data to iSCSI which can't > do anything with it. Looking at 10.4.1, you are right that it has no > reflection. While I find this definition counter-intuitive, it has a > bit of symmetry; it's always the iSCSI # relative to the SCSI #. > > > >In addition to CHECK CONDITION > > > and ASC/ASCQ, do we try to flag either an under run or overrun to > > > indicate how far we got into the transaction before the error > > happened? > > > > iSCSI should be technically ignorant of SCSI error specifics. I > > suggest the only factor for setting the U & O bits (and their > > lower-case friends) at the iSCSI layer be SPDTL. In short, "it > > depends". > > I think we're agreeing. I agree iSCSI shouldn't care about the error > code, I was just trying to figure out what a target does in addition to > setting them. Admittedly I'm coming from an integrated SCSI/iSCSI > target scenario. :-) > > Take care, > > Bill > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Mon Jul 18 11:34:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuXd6-00022L-GJ; Mon, 18 Jul 2005 11:34:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtbYf-0008Lj-FC for ips@megatron.ietf.org; Fri, 15 Jul 2005 21:33:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12405 for ; Fri, 15 Jul 2005 21:33:34 -0400 (EDT) Received: from dmz1.silverbacksystems.com ([65.172.158.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dtc1X-00060t-Or for ips@ietf.org; Fri, 15 Jul 2005 22:03:30 -0400 Received: from ns.silverbacksystems.com (gate-camp-hme0.silverbacksystems.com [65.172.158.93]) by dmz1.silverbacksystems.com (Postfix on SuSE Linux 7.3 (i386)) with ESMTP id 865CE120EC; Fri, 15 Jul 2005 17:28:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ns.silverbacksystems.com (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 6032B754B0; Fri, 15 Jul 2005 18:32:23 -0700 (PDT) Received: from ns.silverbacksystems.com (localhost [127.0.0.1]) by localhost (AvMailGate-2.0.1.6) id 07111-59BD543C; Fri, 15 Jul 2005 18:32:23 -0700 Received: from someshlap (somesh-lap.corp.silverbacksystems.com [10.0.16.116]) by ns.silverbacksystems.com (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 10FEF753B1; Fri, 15 Jul 2005 18:32:23 -0700 (PDT) From: "Somesh Gupta" To: "'Mallikarjun C.'" , "'IPS'" Date: Fri, 15 Jul 2005 18:32:15 -0700 Organization: Silverback Systems, Inc Message-ID: <003c01c589a6$3572ce60$7410000a@corp.silverbacksystems.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: <42D80408.1060108@rose.hp.com> x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal X-AntiVirus: checked by AntiVir MailGate (version: 2.0.1.6; AVE: 6.24.0.7; VDF: 6.24.0.88; host: ns.silverbacksystems.com) X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 18 Jul 2005 11:34:02 -0400 Cc: Subject: [Ips] Re: draft-ietf-ips-iscsi-impl-guide-00.txt X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org Mallikarjun, Thanks for starting this activity. I have some confusion on Section 4.1.2 under the heading "The Target" which describes the steps the target should perform. Is the Target term as used here, the "Service Delivery System" or the "Task Manager"? The reason I have the confusion is that a. The determination of the affected tasks can be performed only by the "Task Manager" which knows the scope of the Task Management Function based on various Control Mode Page settings b. Don't know whether target SCSI layer in step d means the "Device Server" or the "Task Manager" c. The step (e) is transport specific and at least there is no abstract "transport protocol service" interface defined to make sure the acknowledgements have been received by the initiator (i.e. there is no way to force NOP-Ins at specific points). ----- Another item that would be useful to discuss in the implementors guide is the behavior when UA conditions are generated (including transport specific conditions), but I will generate another email on that. Thanks, Somesh _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Mon Jul 18 15:50:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DubdL-0008AM-E6; Mon, 18 Jul 2005 15:50:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dubcr-0007uV-Jw; Mon, 18 Jul 2005 15:50:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10359; Mon, 18 Jul 2005 15:50:03 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Duc6I-0006X1-Vt; Mon, 18 Jul 2005 16:20:32 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1Dubcn-0002Gx-QX; Mon, 18 Jul 2005 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 18 Jul 2005 15:50:01 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: ips@ietf.org Subject: [Ips] I-D ACTION:draft-ietf-ips-isns-mib-07.txt X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Storage Working Group of the IETF. Title : Definitions of Managed Objects for iSNS (Internet Storage Name Service) Author(s) : K. Gibbons, et al. Filename : draft-ietf-ips-isns-mib-07.txt Pages : 85 Date : 2005-7-18 The iSNS protocol provides storage name service functionality on an IP network that is being used for iSCSI or iFCP storage. This draft provides a mechanism to monitor and control multiple iSNS Client and Servers, including information about registered objects in an iSNS Server. This memo is a product of the IP Storage (IPS) working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at ips@ece.cmu.edu and/or the authors. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-isns-mib-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ips-isns-mib-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ips-isns-mib-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-7-18145933.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-isns-mib-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-isns-mib-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-7-18145933.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --NextPart-- From ips-bounces@ietf.org Mon Jul 18 19:12:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Duems-0003NC-O1; Mon, 18 Jul 2005 19:12:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Duemg-0003M1-UL for ips@megatron.ietf.org; Mon, 18 Jul 2005 19:12:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13372 for ; Mon, 18 Jul 2005 19:12:23 -0400 (EDT) Received: from palrel13.hp.com ([156.153.255.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DufGC-0003Py-PS for ips@ietf.org; Mon, 18 Jul 2005 19:42:57 -0400 Received: from rosemail.rose.hp.com (rosemail.rose.hp.com [15.43.209.160]) by palrel13.hp.com (Postfix) with ESMTP id 38A0C1C07B54 for ; Fri, 22 Jul 2005 22:17:34 -0700 (PDT) Received: from [127.0.0.1] (sindhu.americas.hpqcorp.net [16.93.44.53]) by rosemail.rose.hp.com (Postfix) with ESMTP id 4B9198251 for ; Mon, 18 Jul 2005 16:04:45 -0700 (PDT) Message-ID: <42DC3763.5040909@rose.hp.com> Date: Mon, 18 Jul 2005 16:12:35 -0700 From: "Mallikarjun C." User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'IPS'" References: <003c01c589a6$3572ce60$7410000a@corp.silverbacksystems.com> In-Reply-To: <003c01c589a6$3572ce60$7410000a@corp.silverbacksystems.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Content-Transfer-Encoding: 7bit Subject: [Ips] Re: draft-ietf-ips-iscsi-impl-guide-00.txt X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org Somesh, > Is the Target term as used here, the "Service Delivery System" > or the "Task Manager"? Neither... It is used in the same sense RFC 3720 used the term: "SCSI is a client-server architecture. Clients of a SCSI interface are called "initiators". Initiators issue SCSI "commands" to request services from components, logical units, of a server known as a "target"." In short, it is the network entity composed of an iSCSI node and a corresponding SCSI device. BTW, SAM-2 makes a clear distinction between "service delivery subsystem" and a "task manager". > a. The determination of the affected tasks > can be performed only by the "Task > Manager" which knows the scope of the Task Management > Function based on various Control Mode Page settings AFAIK, control mode page settings are needed only for Clear Task Set. At any rate, the current text defines the chronological sequence of actions in the iSCSI layer relative to the Task management SCSI transport protocol service indication & response (step d). Its intent is not to define what happens in the SCSI layer. > b. Don't know whether target SCSI layer in step d means > the "Device Server" or the "Task Manager" It actually refers to the iSCSI layer ("..receives the response from the target SCSI layer."). > c. The step (e) is transport specific and at least Not sure what you mean, the entire list is specific to iSCSI. > there is no abstract "transport protocol service" interface > defined to make sure the acknowledgements have been > received by the initiator Not sure again - why would SCSI want to know about StatSN acks? Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture StorageWorks Division Hewlett-Packard MS 5668 Roseville CA 95747 cbm [at] rose.hp.com Somesh Gupta wrote: > Mallikarjun, > > Thanks for starting this activity. > > I have some confusion on Section 4.1.2 under the > heading "The Target" which describes the steps the > target should perform. > > Is the Target term as used here, the "Service Delivery System" > or the "Task Manager"? The reason I have the confusion is > that > > a. The determination of the affected tasks > can be performed only by the "Task > Manager" which knows the scope of the Task Management > Function based on various Control Mode Page settings > > b. Don't know whether target SCSI layer in step d means > the "Device Server" or the "Task Manager" > > c. The step (e) is transport specific and at least > there is no abstract "transport protocol service" interface > defined to make sure the acknowledgements have been > received by the initiator (i.e. there is no way to force > NOP-Ins at specific points). > > ----- > > Another item that would be useful to discuss in the > implementors guide is the behavior when UA conditions > are generated (including transport specific conditions), > but I will generate another email on that. > > Thanks, > Somesh > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Tue Jul 19 07:49:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuqbW-00031m-0M; Tue, 19 Jul 2005 07:49:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuqbT-0002zj-IX; Tue, 19 Jul 2005 07:49:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04948; Tue, 19 Jul 2005 07:49:38 -0400 (EDT) Received: from [12.16.56.39] (helo=afir) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dur2z-0002gx-My; Tue, 19 Jul 2005 08:18:06 -0400 Received: from mail pickup service by afir with Microsoft SMTPSVC; Tue, 19 Jul 2005 07:47:54 -0400 Received: from mail64.messagelabs.com ([216.82.255.51]) by afir with Microsoft SMTPSVC(5.0.2195.6713); Mon, 18 Jul 2005 15:57:20 -0400 X-VirusChecked: Checked X-Env-Sender: i-d-announce-bounces@ietf.org X-Msg-Ref: server-8.tower-64.messagelabs.com!1121716559!53609795!1 X-StarScan-Version: 5.4.15; banners=-,-,anspach.com X-Originating-IP: [132.151.6.71] X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG, MIME_BOUND_NEXTPART,NO_REAL_NAME Received: (qmail 32000 invoked from network); 18 Jul 2005 19:55:59 -0000 Received: from megatron.ietf.org (132.151.6.71) by server-8.tower-64.messagelabs.com with SMTP; 18 Jul 2005 19:55:59 -0000 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DubdK-000866-1w; Mon, 18 Jul 2005 15:50:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dubcr-0007uV-Jw; Mon, 18 Jul 2005 15:50:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10359; Mon, 18 Jul 2005 15:50:03 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Duc6I-0006X1-Vt; Mon, 18 Jul 2005 16:20:32 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1Dubcn-0002Gx-QX; Mon, 18 Jul 2005 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 18 Jul 2005 15:50:01 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-OriginalArrivalTime: 18 Jul 2005 19:57:20.0703 (UTC) FILETIME=[E85254F0:01C58BD2] X-Spam-Score: 0.4 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: ips@ietf.org Subject: [Ips] I-D ACTION:draft-ietf-ips-isns-mib-07.txt X-BeenThere: ips@ietf.org Reply-To: internet-drafts@ietf.org List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Storage Working Group of the IETF. Title : Definitions of Managed Objects for iSNS (Internet Storage Name Service) Author(s) : K. Gibbons, et al. Filename : draft-ietf-ips-isns-mib-07.txt Pages : 85 Date : 2005-7-18 The iSNS protocol provides storage name service functionality on an IP network that is being used for iSCSI or iFCP storage. This draft provides a mechanism to monitor and control multiple iSNS Client and Servers, including information about registered objects in an iSNS Server. This memo is a product of the IP Storage (IPS) working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at ips@ece.cmu.edu and/or the authors. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-isns-mib-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ips-isns-mib-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ips-isns-mib-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ______________________________________________________________________ This e-mail has been scanned by MCI Managed Email Content Service, using Skeptic(tm) technology powered by MessageLabs. For more information on MCI's Managed Email Content Service, visit http://www.mci.com. ______________________________________________________________________ --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-7-18145933.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-isns-mib-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-isns-mib-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-7-18145933.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --NextPart-- From ips-bounces@ietf.org Tue Jul 19 15:33:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Duxq0-0004qd-Sz; Tue, 19 Jul 2005 15:33:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Duxpw-0004qC-Qh for ips@megatron.ietf.org; Tue, 19 Jul 2005 15:33:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26502 for ; Tue, 19 Jul 2005 15:33:02 -0400 (EDT) Received: from io.iol.unh.edu ([132.177.123.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DuyJc-0000u4-EI for ips@ietf.org; Tue, 19 Jul 2005 16:03:45 -0400 Received: from io.iol.unh.edu (localhost.localdomain [127.0.0.1]) by io.iol.unh.edu (8.13.4/8.13.4) with ESMTP id j6JJWg0W025002; Tue, 19 Jul 2005 15:32:42 -0400 Received: from localhost (rdr@localhost) by io.iol.unh.edu (8.13.4/8.13.4/Submit) with ESMTP id j6JJWg7P024997; Tue, 19 Jul 2005 15:32:42 -0400 Date: Tue, 19 Jul 2005 15:32:42 -0400 (EDT) From: "Robert D. Russell" To: "Mallikarjun C." In-Reply-To: <42D80408.1060108@rose.hp.com> Message-ID: References: <42D80408.1060108@rose.hp.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-UNH-IOL-MailScanner-Information: Please contact systems@iol.unh.edu for more information X-UNH-IOL-MailScanner: Found to be clean X-UNH-IOL-MailScanner-From: rdr@io.iol.unh.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: IPS Subject: [Ips] ISID and Discovery Re: draft-ietf-ips-iscsi-impl-guide-00.txt X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org Mallikarjun: Last August (2004) there was a long discussion on the reflector about how the ISID rule applied to discovery sessions. A satisfactory resolution was arrived at, but given that your new implementer's guide is intended to clarify 3720, would you consider adding that resolution of the ISID/discovery problem to your new guide as a clarification? Thanks, Bob Russell InterOperability Lab University of New Hampshire rdr@iol.unh.edu 603-862-3774 _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Tue Jul 19 19:53:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dv1tk-0006u1-CB; Tue, 19 Jul 2005 19:53:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dv1ti-0006nJ-Rk for ips@megatron.ietf.org; Tue, 19 Jul 2005 19:53:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14741 for ; Tue, 19 Jul 2005 19:53:09 -0400 (EDT) Received: from atlrel8.hp.com ([156.153.255.206]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dv2NO-0005Ix-Nq for ips@ietf.org; Tue, 19 Jul 2005 20:23:55 -0400 Received: from rosemail.rose.hp.com (rosemail.rose.hp.com [15.43.209.160]) by atlrel8.hp.com (Postfix) with ESMTP id 50B7639F1; Tue, 19 Jul 2005 19:53:08 -0400 (EDT) Received: from [127.0.0.1] (sindhu.americas.hpqcorp.net [16.93.44.53]) by rosemail.rose.hp.com (Postfix) with ESMTP id 778018295; Tue, 19 Jul 2005 16:45:23 -0700 (PDT) Message-ID: <42DD9271.4010706@rose.hp.com> Date: Tue, 19 Jul 2005 16:53:21 -0700 From: "Mallikarjun C." User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Robert D. Russell" References: <42D80408.1060108@rose.hp.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Cc: IPS Subject: [Ips] Re: ISID and Discovery Re: draft-ietf-ips-iscsi-impl-guide-00.txt X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org Bob, Yes, I will certainly consider. Please send me a URL to a decent summary email in that thread. Or please do me a favor by writing up one if a summary doesn't exist. Thanks. Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture StorageWorks Division Hewlett-Packard MS 5668 Roseville CA 95747 cbm [at] rose.hp.com Robert D. Russell wrote: > Mallikarjun: > > Last August (2004) there was a long discussion on the reflector about > how the ISID rule applied to discovery sessions. A satisfactory > resolution was arrived at, but given that your new implementer's guide > is intended to clarify 3720, would you consider adding that resolution > of the ISID/discovery problem to your new guide as a clarification? > > Thanks, > > Bob Russell > InterOperability Lab > University of New Hampshire > rdr@iol.unh.edu > 603-862-3774 _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Wed Jul 20 00:04:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dv5oh-00066j-8R; Wed, 20 Jul 2005 00:04:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dv5od-00066Y-Sf for ips@megatron.ietf.org; Wed, 20 Jul 2005 00:04:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15045 for ; Wed, 20 Jul 2005 00:04:13 -0400 (EDT) Received: from sccrmhc12.comcast.net ([204.127.202.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dv6IO-0001Qt-9x for ips@ietf.org; Wed, 20 Jul 2005 00:35:01 -0400 Received: from [67.188.98.5] (c-67-188-98-5.hsd1.ca.comcast.net[67.188.98.5]) by comcast.net (sccrmhc12) with SMTP id <2005072004040501200igk9je>; Wed, 20 Jul 2005 04:04:05 +0000 Mime-Version: 1.0 (Apple Message framework v622) In-Reply-To: <003c01c589a6$3572ce60$7410000a@corp.silverbacksystems.com> References: <003c01c589a6$3572ce60$7410000a@corp.silverbacksystems.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <03567e817e8705a7401e7496bd4fb616@ieee.org> Content-Transfer-Encoding: 7bit From: Pat LaVarre Subject: Re: [Ips] Re: draft-ietf-ips-iscsi-impl-guide-00.txt Date: Tue, 19 Jul 2005 21:03:59 -0700 To: "'IPS'" X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Content-Transfer-Encoding: 7bit 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: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org > Another item that would be useful to discuss in the > implementors guide is the behavior when UA conditions > are generated (including transport specific conditions), > but I will generate another email on that. SK ASC = x 6 28 for each gone ready of a media insertion, x 6 29 for each reset or plug in to promise x 6 28 later, end of story ... no? _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Mon Jul 25 12:09:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx5WX-0005IO-DS; Mon, 25 Jul 2005 12:09:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx5WT-0005GH-9c for ips@megatron.ietf.org; Mon, 25 Jul 2005 12:09:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03643 for ; Mon, 25 Jul 2005 12:09:43 -0400 (EDT) Received: from mailgate.mcdata.com ([208.47.132.224] helo=mc4gate01out.mcdata.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dx61L-0008B8-0M for ips@ietf.org; Mon, 25 Jul 2005 12:41:40 -0400 Received: from mc4gate01.mcdata.com ([172.16.11.205]) by mc4gate01out.mcdata.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Jul 2005 10:09:25 -0600 Received: from MC4EXCH02.mcdata.com ([172.16.11.132]) by mc4gate01.mcdata.com with InterScan Messaging Security Suite; Mon, 25 Jul 2005 10:09:24 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Mon, 25 Jul 2005 10:09:23 -0600 Message-ID: <3CCE3490660DD14ABB8BCD7D0B09925C3F6821@MC4EXCH02.mcdata.com> Thread-Topic: iSNS MIB Changes Thread-Index: AcWRM0OpUGJdRI/KTk6fIKUyQ8v09Q== From: "Scott Kipp" To: X-imss-version: 2.029 X-imss-result: Passed X-imss-approveListMatch: *@mcdata.com X-OriginalArrivalTime: 25 Jul 2005 16:09:25.0200 (UTC) FILETIME=[39FA6D00:01C59133] X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: quoted-printable Subject: [Ips] iSNS MIB Changes 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: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org iSNS MIB Reviewers, I would like to announce the miraculous recovery of the iSNS MIB. After= revision 6 of the iSNS MIB expired, G D Ramkumar and I were tasked to= complete revision 7 of the iSNS MIB with the help of Kevin Gibbons. Kevin= has been assigned other duties within McDATA and was unable to champion= this effort with his busy schedule. You have probably seen that the new= revision has been posted and I would like to discuss the changes that were= made on the reflector and in the meeting next week. Here are the changes that were made to the draft: =0D 1. Added clarification to DESCRIPTION of isnsClntCfgSrvrTable specifying= that the role of the server is not covered by this table.=0D "The active/backup role of the configured server=0D is not within the scope of this MIB and hence not included in this= table."=0D =0D 2. Added above clarification to DESCRIPTION of isnsClntDscvrdSrvrTable as= well. " The active/backup role of the discovered server is not within the scope of this MIB and hence not included in this= table." =0D 3. Removed these fields from the isnsClntInstTable, from isnsClntInstEntry isnsClntInstAddressType InetAddressType, isnsClntInstAddress InetAddress, isnsClntInstTcpPort Integer32=0D isnsClntInstUdpPort Integer32 These were removed because these fields are not required to describe= the client and they unnecessarily restrict the client to a single IP= address and port.=0D Removed these fields also from the corresponding conformance table,= isnsClientAttributesGroup 4. Removed one of duplicate "the" in the description of= "isnsClntCfgSrvrEntry" 5. Remove isnsClntDscvrdSrvrIndex from the isnsClntRegEntityEntry table.=0D Add isnsClntRegEntityAddrType InetAddressType, isnsClntRegEntityAddr InetAddress, isnsClntRegEntityTcpPort Integer32, isnsClntRegEntityUdpPort Integer32 This change is to decouple the isnsClntRegEntity table from the= isnsClntDscvrdSrvr table so that it can more accurately reflect the= entities that are being reported to the servers.=0D These fields are also added to the conformance table= isnsClientAttributesGroup Au Revoir, Scott SPECIAL NOTICE=0D All information transmitted hereby is intended only for the use of the addressee(s) named above and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of confidential and privileged information is prohibited. If the reader of this message is not the intended recipient(s) or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that you must not read this transmission and that= disclosure, copying, printing, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. Anyone who receives confidential and privileged information in error should notify us immediately by telephone and mail the original message to us at the above address and destroy all copies. To the extent any portion of= this communication contains public information, no such restrictions apply to= that information. (gate01) _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Mon Jul 25 12:27:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx5o2-0002FX-W6; Mon, 25 Jul 2005 12:27:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx5nz-0002EP-Gb for ips@megatron.ietf.org; Mon, 25 Jul 2005 12:27:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04873 for ; Mon, 25 Jul 2005 12:27:49 -0400 (EDT) Received: from io.iol.unh.edu ([132.177.123.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dx6Ip-0000If-CV for ips@ietf.org; Mon, 25 Jul 2005 12:59:46 -0400 Received: from io.iol.unh.edu (localhost.localdomain [127.0.0.1]) by io.iol.unh.edu (8.13.4/8.13.4) with ESMTP id j6PGRLOO022031; Mon, 25 Jul 2005 12:27:21 -0400 Received: from localhost (rdr@localhost) by io.iol.unh.edu (8.13.4/8.13.4/Submit) with ESMTP id j6PGRK2m022028; Mon, 25 Jul 2005 12:27:21 -0400 Date: Mon, 25 Jul 2005 12:27:20 -0400 (EDT) From: "Robert D. Russell" To: "Mallikarjun C." In-Reply-To: <42DD9271.4010706@rose.hp.com> Message-ID: References: <42D80408.1060108@rose.hp.com> <42DD9271.4010706@rose.hp.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-UNH-IOL-MailScanner-Information: Please contact systems@iol.unh.edu for more information X-UNH-IOL-MailScanner: Found to be clean X-UNH-IOL-MailScanner-From: rdr@io.iol.unh.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: IPS Subject: [Ips] Re: ISID and Discovery Re: draft-ietf-ips-iscsi-impl-guide-00.txt X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org Mallikarjun: > Yes, I will certainly consider. Please send me a URL to a decent summary > email in that thread. Or please do me a favor by writing up one if a summary > doesn't exist. > Attached below is my draft of a proposed clarification based on two long threads that appeared on the reflector in August, 2004, both having to do with the uniqueness of iscsi sessions and I_T nexus identifiers. The first thread appeared under the heading: "ISCSI Name and Multi-Port Targets", starting with http://www.spinics.net/lists/iscsi/msg10052.html The second thread appeared under two headings: "final resolution of ISID rule as it applies to discovery sessions", starting with http://www.spinics.net/lists/iscsi/msg10129.html and (note the missing space) "final resolution of ISID rule as it applies to discoverysessions", starting with http://www.spinics.net/lists/iscsi/msg10142.html In writing this summary I realized that the "final resolution of the ISID rule for discovery sessions" thread never mentioned what to do about the Portal Group Tag in the I_T nexus identifier when the Target Name was omitted during the first login request of a discovery session. It seems to me that without the Target Name no Portal Group Tag can be uniquely determined, even based on the IP address and port number used by the initiator to connect to the target (since that IP address and port number can belong to different portal groups under different Target Names used by the same target network entity). I therefore wrote in the summary that the Portal Group Tag component of the I_T nexus identifier was also NULL or "" in this case. Comments? Thanks, Bob Russell InterOperability Lab University of New Hampshire rdr@iol.unh.edu 603-862-3774 --------------------------------------------------------------------------- Uniqueness of iSCSI sessions ---------------------------- According to Section 3.4.2 c) of RFC 3720, the SCSI "I_T nexus" defined in SAM2 is equivalent to the iSCSI session defined in RFC 3720. This section also defines the "I_T nexus identifier" to be the tuple: (iSCSI Initiator Name + 'i' + ISID, iSCSI Target Name + 't' + Portal Group Tag) where both the iSCSI Initiator Name and iSCSI Target Name are intended to be world-wide unique names. Therefore, two such tuples with a difference in any one of the four components will identify two different I_T nexi and therefore two different iSCSI sessions. This has several implications: 1) An initiator may use the same iSCSI Initiator Name and ISID when establishing different (i.e., unique) sessions with different targets and/or different portal groups. This behavior is discussed in section 9.1.1 and is, in fact, encouraged as conservative reuse of ISIDs. 2) According to section 9.1.2, there is intended to be just one iSCSI Initiator Name per operating system image on a machine. Therefore, when multiple initiators are running on the same operating system image on the same machine, they should all share the same iSCSI Initiator Name and manage the ISID name space between them to avoid conflicts (e.g., by appropriate partitioning). 3) The I_T nexus identifier applies to all session types (normal and discovery). When an initiator supplies a Target Name on the first login request of a discovery session, there is a Portal Group Tag associated with that Target Name and formation of the I_T nexus identifier is straight-forward. However, according to section 3.2.6.1, the initiator MAY omit supplying the iSCSI Target Name on the first login request of a discovery session, in which case the I_T nexus identifier is constructed by supplying an empty value (e.g., NULL or "") for both the iSCSI Target Name and the Portal Group Tag components. The consequences of this are: a) The I_T nexus identifier of a discovery session established WITH a Target Name MAY match the I_T nexus identifier of a normal session, in which case such a discovery session will force reinstatement of an existing normal session (and vice versa) as defined in section 5.3.1. b) The I_T nexus identifier of a discovery session established WITHOUT a Target Name NEVER matches the I_T nexus identifier of a normal session, so that such a discovery session NEVER forces reinstatement of an existing normal session (and vice versa) as defined in section 5.3.1. c) At any time, a single target should have at most one discovery session with the I_T nexus identifier: (iSCSI Initiator Name + 'i' + ISID + "" + 't' + "") _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Tue Jul 26 17:50:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxXJp-000791-Mm; Tue, 26 Jul 2005 17:50:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxXJo-00078w-AO for ips@megatron.ietf.org; Tue, 26 Jul 2005 17:50:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26938 for ; Tue, 26 Jul 2005 17:50:29 -0400 (EDT) Received: from pat.qlogic.com ([198.70.193.2] helo=avexch01.qlogic.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxXov-0003Tv-6u for ips@ietf.org; Tue, 26 Jul 2005 18:22:42 -0400 Received: from avexch02.qlogic.com ([10.1.4.82]) by avexch01.qlogic.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 26 Jul 2005 14:50:15 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6556.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C5922C.0128E74A" Date: Tue, 26 Jul 2005 14:50:14 -0700 Message-ID: X-MS-TNEF-Correlator: Thread-Topic: Ips Digest, Vol 15, Issue 9 Thread-Index: AcWR/HwqENGopLb3TZ+Rkp6nbvyGOQAL3A// From: "Prashanth Nednoor" To: X-OriginalArrivalTime: 26 Jul 2005 21:50:15.0020 (UTC) FILETIME=[016F12C0:01C5922C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7cb76adb986247703cbb5582da68b5fc Subject: [Ips] RE: Ips Digest, Vol 15, Issue 9 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: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C5922C.0128E74A Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Smh5bGluZywNCiANCndhaHRzIGlzIHRoZSBhcmd1bWVudCB0byBydW4gNDAyMiBpbiBkaWFnIG1v ZGUsIA0KIA0KaSBoYXZlIHRoZSBsb2dpYyBpbiB0aGUgY29kZS4uLi4NCiANCnRoYW5rcw0KcHJh c2hhbnRoDQoNCgktLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLSANCglGcm9tOiBpcHMtYm91bmNl c0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgaXBzLXJlcXVlc3RAaWV0Zi5vcmcgDQoJU2VudDogVHVl IDcvMjYvMjAwNSA5OjA5IEFNIA0KCVRvOiBpcHNAaWV0Zi5vcmcgDQoJQ2M6IA0KCVN1YmplY3Q6 IElwcyBEaWdlc3QsIFZvbCAxNSwgSXNzdWUgOQ0KCQ0KCQ0KDQoJU2VuZCBJcHMgbWFpbGluZyBs aXN0IHN1Ym1pc3Npb25zIHRvDQoJICAgICAgICBpcHNAaWV0Zi5vcmcNCgkNCglUbyBzdWJzY3Jp YmUgb3IgdW5zdWJzY3JpYmUgdmlhIHRoZSBXb3JsZCBXaWRlIFdlYiwgdmlzaXQNCgkgICAgICAg IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwcw0KCW9yLCB2aWEgZW1h aWwsIHNlbmQgYSBtZXNzYWdlIHdpdGggc3ViamVjdCBvciBib2R5ICdoZWxwJyB0bw0KCSAgICAg ICAgaXBzLXJlcXVlc3RAaWV0Zi5vcmcNCgkNCglZb3UgY2FuIHJlYWNoIHRoZSBwZXJzb24gbWFu YWdpbmcgdGhlIGxpc3QgYXQNCgkgICAgICAgIGlwcy1vd25lckBpZXRmLm9yZw0KCQ0KCVdoZW4g cmVwbHlpbmcsIHBsZWFzZSBlZGl0IHlvdXIgU3ViamVjdCBsaW5lIHNvIGl0IGlzIG1vcmUgc3Bl Y2lmaWMNCgl0aGFuICJSZTogQ29udGVudHMgb2YgSXBzIGRpZ2VzdC4uLiINCgkNCgkNCglUb2Rh eSdzIFRvcGljczoNCgkNCgkgICAxLiBpU05TIE1JQiBDaGFuZ2VzIChTY290dCBLaXBwKQ0KCSAg IDIuIFJlOiBJU0lEIGFuZCBEaXNjb3ZlcnkgUmU6DQoJICAgICAgZHJhZnQtaWV0Zi1pcHMtaXNj c2ktaW1wbC1ndWlkZS0wMC50eHQgKFJvYmVydCBELiBSdXNzZWxsKQ0KCQ0KCQ0KCS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NCgkNCglNZXNzYWdlOiAxDQoJRGF0ZTogTW9uLCAyNSBKdWwgMjAwNSAxMDowOToyMyAt MDYwMA0KCUZyb206ICJTY290dCBLaXBwIiA8c2NvdHQua2lwcEBtY2RhdGEuY29tPg0KCVN1Ympl Y3Q6IFtJcHNdIGlTTlMgTUlCIENoYW5nZXMNCglUbzogPGlwc0BpZXRmLm9yZz4NCglNZXNzYWdl LUlEOg0KCSAgICAgICAgPDNDQ0UzNDkwNjYwREQxNEFCQjhCQ0Q3RDBCMDk5MjVDM0Y2ODIxQE1D NEVYQ0gwMi5tY2RhdGEuY29tPg0KCUNvbnRlbnQtVHlwZTogdGV4dC9wbGFpbjsgICAgICAgY2hh cnNldD1pc28tODg1OS0xDQoJDQoJDQoJaVNOUyBNSUIgUmV2aWV3ZXJzLA0KCQ0KCUkgd291bGQg bGlrZSB0byBhbm5vdW5jZSB0aGUgbWlyYWN1bG91cyByZWNvdmVyeSBvZiB0aGUgaVNOUyBNSUIu ICBBZnRlciByZXZpc2lvbiA2IG9mIHRoZSBpU05TIE1JQiBleHBpcmVkLCBHIEQgUmFta3VtYXIg YW5kIEkgd2VyZSB0YXNrZWQgdG8gY29tcGxldGUgcmV2aXNpb24gNyBvZiB0aGUgaVNOUyBNSUIg d2l0aCB0aGUgaGVscCBvZiBLZXZpbiBHaWJib25zLiAgS2V2aW4gaGFzIGJlZW4gYXNzaWduZWQg b3RoZXIgZHV0aWVzIHdpdGhpbiBNY0RBVEEgYW5kIHdhcyB1bmFibGUgdG8gY2hhbXBpb24gdGhp cyBlZmZvcnQgd2l0aCBoaXMgYnVzeSBzY2hlZHVsZS4gIFlvdSBoYXZlIHByb2JhYmx5IHNlZW4g dGhhdCB0aGUgbmV3IHJldmlzaW9uIGhhcyBiZWVuIHBvc3RlZCBhbmQgSSB3b3VsZCBsaWtlIHRv IGRpc2N1c3MgdGhlIGNoYW5nZXMgdGhhdCB3ZXJlIG1hZGUgb24gdGhlIHJlZmxlY3RvciBhbmQg aW4gdGhlIG1lZXRpbmcgbmV4dCB3ZWVrLg0KCQ0KCUhlcmUgYXJlIHRoZSBjaGFuZ2VzIHRoYXQg d2VyZSBtYWRlIHRvIHRoZSBkcmFmdDogDQoJDQoJDQoJICAgICAgICAxLiAgICAgIEFkZGVkIGNs YXJpZmljYXRpb24gdG8gREVTQ1JJUFRJT04gb2YgaXNuc0NsbnRDZmdTcnZyVGFibGUgc3BlY2lm eWluZyB0aGF0IHRoZSByb2xlIG9mIHRoZSBzZXJ2ZXIgaXMgbm90IGNvdmVyZWQgYnkgdGhpcyB0 YWJsZS4NCgkgICAgICAgICAgICAgICAgICAgICAgICAiVGhlIGFjdGl2ZS9iYWNrdXAgcm9sZSBv ZiB0aGUgY29uZmlndXJlZCBzZXJ2ZXINCgkgICAgICAgICBpcyBub3Qgd2l0aGluIHRoZSBzY29w ZSBvZiB0aGlzIE1JQiBhbmQgaGVuY2Ugbm90IGluY2x1ZGVkIGluIHRoaXMgdGFibGUuIg0KCSAg ICAgICANCgkNCgkgICAgICAgIDIuICAgICAgQWRkZWQgYWJvdmUgY2xhcmlmaWNhdGlvbiB0byBE RVNDUklQVElPTiBvZiBpc25zQ2xudERzY3ZyZFNydnJUYWJsZSBhcyB3ZWxsLg0KCSAgICAgICAg ICAgICAgICAgICAgICAgICIgVGhlIGFjdGl2ZS9iYWNrdXAgcm9sZSBvZiB0aGUgZGlzY292ZXJl ZA0KCSAgICAgICAgIHNlcnZlciBpcyBub3Qgd2l0aGluIHRoZSBzY29wZSBvZiB0aGlzIE1JQiBh bmQgaGVuY2Ugbm90IGluY2x1ZGVkIGluIHRoaXMgdGFibGUuIg0KCQ0KCQ0KCSAgICAgICAgMy4g ICAgICBSZW1vdmVkIHRoZXNlIGZpZWxkcyBmcm9tIHRoZSBpc25zQ2xudEluc3RUYWJsZSwgZnJv bSBpc25zQ2xudEluc3RFbnRyeQ0KCSAgICAgICAgICAgICAgIGlzbnNDbG50SW5zdEFkZHJlc3NU eXBlICAgICBJbmV0QWRkcmVzc1R5cGUsDQoJICAgICAgICAgICAgICAgaXNuc0NsbnRJbnN0QWRk cmVzcyAgICAgICAgICAgICBJbmV0QWRkcmVzcywNCgkgICAgICAgICAgICAgICBpc25zQ2xudElu c3RUY3BQb3J0ICAgICAgICAgICAgIEludGVnZXIzMg0KCSAgICAgICAgICAgICAgIGlzbnNDbG50 SW5zdFVkcFBvcnQgICAgICAgICAgICAgSW50ZWdlcjMyDQoJDQoJICAgICAgICAgICAgICBUaGVz ZSB3ZXJlIHJlbW92ZWQgYmVjYXVzZSB0aGVzZSBmaWVsZHMgYXJlIG5vdCByZXF1aXJlZCB0byBk ZXNjcmliZSB0aGUgY2xpZW50IGFuZCB0aGV5IHVubmVjZXNzYXJpbHkgcmVzdHJpY3QgdGhlIGNs aWVudCB0byBhIHNpbmdsZSBJUCBhZGRyZXNzIGFuZCBwb3J0Lg0KCQ0KCSAgICAgICAgICAgICAg IFJlbW92ZWQgdGhlc2UgZmllbGRzIGFsc28gZnJvbSB0aGUgY29ycmVzcG9uZGluZyBjb25mb3Jt YW5jZSB0YWJsZSwgaXNuc0NsaWVudEF0dHJpYnV0ZXNHcm91cA0KCQ0KCSAgICAgICAgNC4gICAg ICBSZW1vdmVkIG9uZSBvZiBkdXBsaWNhdGUgInRoZSIgaW4gdGhlIGRlc2NyaXB0aW9uIG9mICJp c25zQ2xudENmZ1NydnJFbnRyeSINCgkNCgkgICAgICAgIDUuICAgICAgUmVtb3ZlIGlzbnNDbG50 RHNjdnJkU3J2ckluZGV4IGZyb20gdGhlIGlzbnNDbG50UmVnRW50aXR5RW50cnkgdGFibGUuDQoJ ICAgICAgICAgICAgICAgIEFkZCAgICAgaXNuc0NsbnRSZWdFbnRpdHlBZGRyVHlwZSAgICAgICBJ bmV0QWRkcmVzc1R5cGUsDQoJICAgICAgICAgICAgICAgICAgICAgICAgICAgIGlzbnNDbG50UmVn RW50aXR5QWRkciAgICAgICAgICAgICAgIEluZXRBZGRyZXNzLA0KCSAgICAgICAgICAgICAgICAg ICAgICAgICAgICBpc25zQ2xudFJlZ0VudGl0eVRjcFBvcnQgICAgICAgICAgIEludGVnZXIzMiwN CgkgICAgICAgICAgICAgICAgICAgICAgICAgICAgaXNuc0NsbnRSZWdFbnRpdHlVZHBQb3J0ICAg ICAgICAgICBJbnRlZ2VyMzINCgkNCgkgICAgICAgICAgICAgICAgVGhpcyBjaGFuZ2UgaXMgdG8g ZGVjb3VwbGUgdGhlIGlzbnNDbG50UmVnRW50aXR5IHRhYmxlIGZyb20gdGhlIGlzbnNDbG50RHNj dnJkU3J2ciB0YWJsZSBzbyB0aGF0IGl0IGNhbiBtb3JlIGFjY3VyYXRlbHkgcmVmbGVjdCB0aGUg ZW50aXRpZXMgdGhhdCBhcmUgYmVpbmcgcmVwb3J0ZWQgdG8gdGhlIHNlcnZlcnMuDQoJDQoJICAg ICAgICAgICAgICAgIFRoZXNlIGZpZWxkcyBhcmUgYWxzbyBhZGRlZCB0byB0aGUgY29uZm9ybWFu Y2UgdGFibGUgaXNuc0NsaWVudEF0dHJpYnV0ZXNHcm91cA0KCQ0KCUF1IFJldm9pciwNCglTY290 dA0KCQ0KCQ0KCVNQRUNJQUwgTk9USUNFDQoJDQoJQWxsIGluZm9ybWF0aW9uIHRyYW5zbWl0dGVk IGhlcmVieSBpcyBpbnRlbmRlZCBvbmx5IGZvciB0aGUgdXNlIG9mIHRoZQ0KCWFkZHJlc3NlZShz KSBuYW1lZCBhYm92ZSBhbmQgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFuZCBwcml2aWxlZ2Vk DQoJaW5mb3JtYXRpb24uIEFueSB1bmF1dGhvcml6ZWQgcmV2aWV3LCB1c2UsIGRpc2Nsb3N1cmUg b3IgZGlzdHJpYnV0aW9uDQoJb2YgY29uZmlkZW50aWFsIGFuZCBwcml2aWxlZ2VkIGluZm9ybWF0 aW9uIGlzIHByb2hpYml0ZWQuIElmIHRoZSByZWFkZXINCglvZiB0aGlzIG1lc3NhZ2UgaXMgbm90 IHRoZSBpbnRlbmRlZCByZWNpcGllbnQocykgb3IgdGhlIGVtcGxveWVlIG9yIGFnZW50DQoJcmVz cG9uc2libGUgZm9yIGRlbGl2ZXJpbmcgdGhlIG1lc3NhZ2UgdG8gdGhlIGludGVuZGVkIHJlY2lw aWVudCwgeW91IGFyZQ0KCWhlcmVieSBub3RpZmllZCB0aGF0IHlvdSBtdXN0IG5vdCByZWFkIHRo aXMgdHJhbnNtaXNzaW9uIGFuZCB0aGF0IGRpc2Nsb3N1cmUsDQoJY29weWluZywgcHJpbnRpbmcs IGRpc3RyaWJ1dGlvbiBvciB1c2Ugb2YgYW55IG9mIHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQN CglpbiBvciBhdHRhY2hlZCB0byB0aGlzIHRyYW5zbWlzc2lvbiBpcyBTVFJJQ1RMWSBQUk9ISUJJ VEVELg0KCQ0KCUFueW9uZSB3aG8gcmVjZWl2ZXMgY29uZmlkZW50aWFsIGFuZCBwcml2aWxlZ2Vk IGluZm9ybWF0aW9uIGluIGVycm9yIHNob3VsZA0KCW5vdGlmeSB1cyBpbW1lZGlhdGVseSBieSB0 ZWxlcGhvbmUgYW5kIG1haWwgdGhlIG9yaWdpbmFsIG1lc3NhZ2UgdG8gdXMgYXQNCgl0aGUgYWJv dmUgYWRkcmVzcyBhbmQgZGVzdHJveSBhbGwgY29waWVzLiAgVG8gdGhlIGV4dGVudCBhbnkgcG9y dGlvbiBvZiB0aGlzDQoJY29tbXVuaWNhdGlvbiBjb250YWlucyBwdWJsaWMgaW5mb3JtYXRpb24s IG5vIHN1Y2ggcmVzdHJpY3Rpb25zIGFwcGx5IHRvIHRoYXQNCglpbmZvcm1hdGlvbi4gKGdhdGUw MSkNCgkNCgkNCgkNCgktLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCgkNCglNZXNzYWdl OiAyDQoJRGF0ZTogTW9uLCAyNSBKdWwgMjAwNSAxMjoyNzoyMCAtMDQwMCAoRURUKQ0KCUZyb206 ICJSb2JlcnQgRC4gUnVzc2VsbCIgPHJkckBpby5pb2wudW5oLmVkdT4NCglTdWJqZWN0OiBbSXBz XSBSZTogSVNJRCBhbmQgRGlzY292ZXJ5IFJlOg0KCSAgICAgICAgZHJhZnQtaWV0Zi1pcHMtaXNj c2ktaW1wbC1ndWlkZS0wMC50eHQNCglUbzogIk1hbGxpa2FyanVuIEMuIiA8Y2JtQHJvc2UuaHAu Y29tPg0KCUNjOiBJUFMgPGlwc0BpZXRmLm9yZz4NCglNZXNzYWdlLUlEOiA8UGluZS5MTlguNC42 My4wNTA3MjUxMjI0MzcwLjE2MjY2QGlvLmlvbC51bmguZWR1Pg0KCUNvbnRlbnQtVHlwZTogVEVY VC9QTEFJTjsgY2hhcnNldD1VUy1BU0NJSTsgZm9ybWF0PWZsb3dlZA0KCQ0KCU1hbGxpa2FyanVu Og0KCQ0KCT4gWWVzLCBJIHdpbGwgY2VydGFpbmx5IGNvbnNpZGVyLiAgUGxlYXNlIHNlbmQgbWUg YSBVUkwgdG8gYSBkZWNlbnQgc3VtbWFyeQ0KCT4gZW1haWwgaW4gdGhhdCB0aHJlYWQuICBPciBw bGVhc2UgZG8gbWUgYSBmYXZvciBieSB3cml0aW5nIHVwIG9uZSBpZiBhIHN1bW1hcnkNCgk+IGRv ZXNuJ3QgZXhpc3QuDQoJPg0KCQ0KCUF0dGFjaGVkIGJlbG93IGlzIG15IGRyYWZ0IG9mIGEgcHJv cG9zZWQgY2xhcmlmaWNhdGlvbg0KCWJhc2VkIG9uIHR3byBsb25nIHRocmVhZHMgdGhhdCBhcHBl YXJlZCBvbiB0aGUgcmVmbGVjdG9yIGluDQoJQXVndXN0LCAyMDA0LCBib3RoIGhhdmluZyB0byBk byB3aXRoIHRoZSB1bmlxdWVuZXNzIG9mIGlzY3NpDQoJc2Vzc2lvbnMgYW5kIElfVCBuZXh1cyBp ZGVudGlmaWVycy4NCgkNCglUaGUgZmlyc3QgdGhyZWFkIGFwcGVhcmVkIHVuZGVyIHRoZSBoZWFk aW5nOg0KCSJJU0NTSSBOYW1lIGFuZCBNdWx0aS1Qb3J0IFRhcmdldHMiLCBzdGFydGluZyB3aXRo DQoJaHR0cDovL3d3dy5zcGluaWNzLm5ldC9saXN0cy9pc2NzaS9tc2cxMDA1Mi5odG1sDQoJDQoJ VGhlIHNlY29uZCB0aHJlYWQgYXBwZWFyZWQgdW5kZXIgdHdvIGhlYWRpbmdzOg0KCSJmaW5hbCBy ZXNvbHV0aW9uIG9mIElTSUQgcnVsZSBhcyBpdCBhcHBsaWVzIHRvIGRpc2NvdmVyeSBzZXNzaW9u cyIsDQoJc3RhcnRpbmcgd2l0aCBodHRwOi8vd3d3LnNwaW5pY3MubmV0L2xpc3RzL2lzY3NpL21z ZzEwMTI5Lmh0bWwNCglhbmQgKG5vdGUgdGhlIG1pc3Npbmcgc3BhY2UpDQoJImZpbmFsIHJlc29s dXRpb24gb2YgSVNJRCBydWxlIGFzIGl0IGFwcGxpZXMgdG8gZGlzY292ZXJ5c2Vzc2lvbnMiLA0K CXN0YXJ0aW5nIHdpdGggaHR0cDovL3d3dy5zcGluaWNzLm5ldC9saXN0cy9pc2NzaS9tc2cxMDE0 Mi5odG1sDQoJDQoJSW4gd3JpdGluZyB0aGlzIHN1bW1hcnkgSSByZWFsaXplZCB0aGF0IHRoZSAi ZmluYWwgcmVzb2x1dGlvbiBvZiB0aGUNCglJU0lEIHJ1bGUgZm9yIGRpc2NvdmVyeSBzZXNzaW9u cyIgdGhyZWFkIG5ldmVyIG1lbnRpb25lZCB3aGF0IHRvIGRvDQoJYWJvdXQgdGhlIFBvcnRhbCBH cm91cCBUYWcgaW4gdGhlIElfVCBuZXh1cyBpZGVudGlmaWVyIHdoZW4gdGhlDQoJVGFyZ2V0IE5h bWUgd2FzIG9taXR0ZWQgZHVyaW5nIHRoZSBmaXJzdCBsb2dpbiByZXF1ZXN0IG9mIGENCglkaXNj b3Zlcnkgc2Vzc2lvbi4gIEl0IHNlZW1zIHRvIG1lIHRoYXQgd2l0aG91dCB0aGUgVGFyZ2V0IE5h bWUNCglubyBQb3J0YWwgR3JvdXAgVGFnIGNhbiBiZSB1bmlxdWVseSBkZXRlcm1pbmVkLCBldmVu IGJhc2VkIG9uIHRoZQ0KCUlQIGFkZHJlc3MgYW5kIHBvcnQgbnVtYmVyIHVzZWQgYnkgdGhlIGlu aXRpYXRvciB0byBjb25uZWN0IHRvIHRoZQ0KCXRhcmdldCAoc2luY2UgdGhhdCBJUCBhZGRyZXNz IGFuZCBwb3J0IG51bWJlciBjYW4gYmVsb25nIHRvIGRpZmZlcmVudA0KCXBvcnRhbCBncm91cHMg dW5kZXIgZGlmZmVyZW50IFRhcmdldCBOYW1lcyB1c2VkIGJ5IHRoZSBzYW1lIHRhcmdldA0KCW5l dHdvcmsgZW50aXR5KS4gIEkgdGhlcmVmb3JlIHdyb3RlIGluIHRoZSBzdW1tYXJ5IHRoYXQgdGhl IFBvcnRhbA0KCUdyb3VwIFRhZyBjb21wb25lbnQgb2YgdGhlIElfVCBuZXh1cyBpZGVudGlmaWVy IHdhcyBhbHNvIE5VTEwgb3IgIiINCglpbiB0aGlzIGNhc2UuDQoJDQoJQ29tbWVudHM/DQoJDQoJ VGhhbmtzLA0KCQ0KCUJvYiBSdXNzZWxsDQoJSW50ZXJPcGVyYWJpbGl0eSBMYWINCglVbml2ZXJz aXR5IG9mIE5ldyBIYW1wc2hpcmUNCglyZHJAaW9sLnVuaC5lZHUNCgk2MDMtODYyLTM3NzQNCgkN CgktLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCgkNCglVbmlxdWVuZXNzIG9mIGlTQ1NJIHNlc3Npb25zDQoJ LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KCQ0KCUFjY29yZGluZyB0byBTZWN0aW9uIDMu NC4yIGMpIG9mIFJGQyAzNzIwLCB0aGUgU0NTSSAiSV9UIG5leHVzIiBkZWZpbmVkDQoJaW4gU0FN MiBpcyBlcXVpdmFsZW50IHRvIHRoZSBpU0NTSSBzZXNzaW9uIGRlZmluZWQgaW4gUkZDIDM3MjAu DQoJVGhpcyBzZWN0aW9uIGFsc28gZGVmaW5lcyB0aGUgIklfVCBuZXh1cyBpZGVudGlmaWVyIiB0 byBiZSB0aGUgdHVwbGU6DQoJDQoJICAgIChpU0NTSSBJbml0aWF0b3IgTmFtZSArICdpJyArIElT SUQsDQoJICAgICBpU0NTSSBUYXJnZXQgTmFtZSArICd0JyArIFBvcnRhbCBHcm91cCBUYWcpDQoJ DQoJd2hlcmUgYm90aCB0aGUgaVNDU0kgSW5pdGlhdG9yIE5hbWUgYW5kIGlTQ1NJIFRhcmdldCBO YW1lIGFyZQ0KCWludGVuZGVkIHRvIGJlIHdvcmxkLXdpZGUgdW5pcXVlIG5hbWVzLg0KCQ0KCVRo ZXJlZm9yZSwgdHdvIHN1Y2ggdHVwbGVzIHdpdGggYSBkaWZmZXJlbmNlIGluIGFueSBvbmUgb2Yg dGhlIGZvdXINCgljb21wb25lbnRzIHdpbGwgaWRlbnRpZnkgdHdvIGRpZmZlcmVudCBJX1QgbmV4 aSBhbmQgdGhlcmVmb3JlIHR3bw0KCWRpZmZlcmVudCBpU0NTSSBzZXNzaW9ucy4gIFRoaXMgaGFz IHNldmVyYWwgaW1wbGljYXRpb25zOg0KCQ0KCQ0KCTEpIEFuIGluaXRpYXRvciBtYXkgdXNlIHRo ZSBzYW1lIGlTQ1NJIEluaXRpYXRvciBOYW1lIGFuZCBJU0lEIHdoZW4NCgkgICAgZXN0YWJsaXNo aW5nIGRpZmZlcmVudCAoaS5lLiwgdW5pcXVlKSBzZXNzaW9ucyB3aXRoIGRpZmZlcmVudCB0YXJn ZXRzDQoJICAgIGFuZC9vciBkaWZmZXJlbnQgcG9ydGFsIGdyb3Vwcy4gIFRoaXMgYmVoYXZpb3Ig aXMgZGlzY3Vzc2VkIGluIHNlY3Rpb24NCgkgICAgOS4xLjEgYW5kIGlzLCBpbiBmYWN0LCBlbmNv dXJhZ2VkIGFzIGNvbnNlcnZhdGl2ZSByZXVzZSBvZiBJU0lEcy4NCgkNCgkNCgkyKSBBY2NvcmRp bmcgdG8gc2VjdGlvbiA5LjEuMiwgdGhlcmUgaXMgaW50ZW5kZWQgdG8gYmUganVzdCBvbmUgaVND U0kNCgkgICAgSW5pdGlhdG9yIE5hbWUgcGVyIG9wZXJhdGluZyBzeXN0ZW0gaW1hZ2Ugb24gYSBt YWNoaW5lLiAgVGhlcmVmb3JlLA0KCSAgICB3aGVuIG11bHRpcGxlIGluaXRpYXRvcnMgYXJlIHJ1 bm5pbmcgb24gdGhlIHNhbWUgb3BlcmF0aW5nIHN5c3RlbQ0KCSAgICBpbWFnZSBvbiB0aGUgc2Ft ZSBtYWNoaW5lLCB0aGV5IHNob3VsZCBhbGwgc2hhcmUgdGhlIHNhbWUNCgkgICAgaVNDU0kgSW5p dGlhdG9yIE5hbWUgYW5kIG1hbmFnZSB0aGUgSVNJRCBuYW1lIHNwYWNlIGJldHdlZW4gdGhlbQ0K CSAgICB0byBhdm9pZCBjb25mbGljdHMgKGUuZy4sIGJ5IGFwcHJvcHJpYXRlIHBhcnRpdGlvbmlu ZykuDQoJDQoJDQoJMykgVGhlIElfVCBuZXh1cyBpZGVudGlmaWVyIGFwcGxpZXMgdG8gYWxsIHNl c3Npb24gdHlwZXMgKG5vcm1hbCBhbmQNCgkgICAgZGlzY292ZXJ5KS4gIFdoZW4gYW4gaW5pdGlh dG9yIHN1cHBsaWVzIGEgVGFyZ2V0IE5hbWUgb24gdGhlIGZpcnN0DQoJICAgIGxvZ2luIHJlcXVl c3Qgb2YgYSBkaXNjb3Zlcnkgc2Vzc2lvbiwgdGhlcmUgaXMgYSBQb3J0YWwgR3JvdXAgVGFnDQoJ ICAgIGFzc29jaWF0ZWQgd2l0aCB0aGF0IFRhcmdldCBOYW1lIGFuZCBmb3JtYXRpb24gb2YgdGhl IElfVCBuZXh1cw0KCSAgICBpZGVudGlmaWVyIGlzIHN0cmFpZ2h0LWZvcndhcmQuICBIb3dldmVy LCBhY2NvcmRpbmcgdG8gc2VjdGlvbg0KCSAgICAzLjIuNi4xLCB0aGUgaW5pdGlhdG9yIE1BWSBv bWl0IHN1cHBseWluZyB0aGUgaVNDU0kgVGFyZ2V0IE5hbWUgb24NCgkgICAgdGhlIGZpcnN0IGxv Z2luIHJlcXVlc3Qgb2YgYSBkaXNjb3Zlcnkgc2Vzc2lvbiwgaW4gd2hpY2ggY2FzZSB0aGUNCgkg ICAgSV9UIG5leHVzIGlkZW50aWZpZXIgaXMgY29uc3RydWN0ZWQgYnkgc3VwcGx5aW5nIGFuIGVt cHR5IHZhbHVlDQoJICAgIChlLmcuLCBOVUxMIG9yICIiKSBmb3IgYm90aCB0aGUgaVNDU0kgVGFy Z2V0IE5hbWUgYW5kIHRoZSBQb3J0YWwNCgkgICAgR3JvdXAgVGFnIGNvbXBvbmVudHMuICBUaGUg Y29uc2VxdWVuY2VzIG9mIHRoaXMgYXJlOg0KCQ0KCSAgICBhKSBUaGUgSV9UIG5leHVzIGlkZW50 aWZpZXIgb2YgYSBkaXNjb3Zlcnkgc2Vzc2lvbiBlc3RhYmxpc2hlZCBXSVRIIGENCgkgICAgICAg VGFyZ2V0IE5hbWUgTUFZIG1hdGNoIHRoZSBJX1QgbmV4dXMgaWRlbnRpZmllciBvZiBhIG5vcm1h bCBzZXNzaW9uLA0KCSAgICAgICBpbiB3aGljaCBjYXNlIHN1Y2ggYSBkaXNjb3Zlcnkgc2Vzc2lv biB3aWxsIGZvcmNlIHJlaW5zdGF0ZW1lbnQgb2YNCgkgICAgICAgYW4gZXhpc3Rpbmcgbm9ybWFs IHNlc3Npb24gKGFuZCB2aWNlIHZlcnNhKSBhcyBkZWZpbmVkIGluIHNlY3Rpb24NCgkgICAgICAg NS4zLjEuDQoJDQoJICAgIGIpIFRoZSBJX1QgbmV4dXMgaWRlbnRpZmllciBvZiBhIGRpc2NvdmVy eSBzZXNzaW9uIGVzdGFibGlzaGVkIFdJVEhPVVQNCgkgICAgICAgYSBUYXJnZXQgTmFtZSBORVZF UiBtYXRjaGVzIHRoZSBJX1QgbmV4dXMgaWRlbnRpZmllciBvZiBhIG5vcm1hbA0KCSAgICAgICBz ZXNzaW9uLCBzbyB0aGF0IHN1Y2ggYSBkaXNjb3Zlcnkgc2Vzc2lvbiBORVZFUiBmb3JjZXMgcmVp bnN0YXRlbWVudA0KCSAgICAgICBvZiBhbiBleGlzdGluZyBub3JtYWwgc2Vzc2lvbiAoYW5kIHZp Y2UgdmVyc2EpIGFzIGRlZmluZWQgaW4gc2VjdGlvbg0KCSAgICAgICA1LjMuMS4NCgkNCgkgICAg YykgQXQgYW55IHRpbWUsIGEgc2luZ2xlIHRhcmdldCBzaG91bGQgaGF2ZSBhdCBtb3N0IG9uZSBk aXNjb3ZlcnkNCgkgICAgICAgc2Vzc2lvbiB3aXRoIHRoZSBJX1QgbmV4dXMgaWRlbnRpZmllcjoN CgkgICAgICAgKGlTQ1NJIEluaXRpYXRvciBOYW1lICsgJ2knICsgSVNJRCArICIiICsgJ3QnICsg IiIpDQoJDQoJDQoJDQoJDQoJLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoJDQoJX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCglJcHMgbWFpbGlu ZyBsaXN0DQoJSXBzQGlldGYub3JnDQoJaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vaXBzDQoJDQoJDQoJRW5kIG9mIElwcyBEaWdlc3QsIFZvbCAxNSwgSXNzdWUgOQ0KCSoq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCgkNCg0K ------_=_NextPart_001_01C5922C.0128E74A Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 eJ8+Ig8VAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAENgAQAAgAAAAIAAgABBYAD AA4AAADVBwcAGgAOADIADgACAE0BASCAAwAOAAAA1QcHABoADgAyAA4AAgBNAQEJgAEAIQAAAEQw MzFDRTA0MTM2OEI3NDZCMkI0MEIzQkMzODc2QTFDABoHAQOQBgCcOwAAOAAAAB8AGgABAAAAEgAA AEkAUABNAC4ATgBvAHQAZQAAAAAAAwA2AAAAAAAfADcAAQAAAEAAAABSAEUAOgAgAEkAcABzACAA RABpAGcAZQBzAHQALAAgAFYAbwBsACAAMQA1ACwAIABJAHMAcwB1AGUAIAA5AAAAQAA5AErnKAEs ksUBHwA9AAEAAAAKAAAAUgBFADoAIAAAAAAAAgFHAAEAAAAvAAAAYz1VUzthPSA7cD1RTG9naWM7 bD1BVkVYQ0gwMi0wNTA3MjYyMTUwMTRaLTY2OAAAHwBJAAEAAAA4AAAASQBwAHMAIABEAGkAZwBl AHMAdAAsACAAVgBvAGwAIAAxADUALAAgAEkAcwBzAHUAZQAgADkAAABAAE4AALWOdfyRxQEfAFoA AQAAACoAAABpAHAAcwAtAGIAbwB1AG4AYwBlAHMAQABpAGUAdABmAC4AbwByAGcAAAAAAAIBWwAB AAAARwAAAAAAAACBKx+kvqMQGZ1uAN0BD1QCAAAAAGlwcy1ib3VuY2VzQGlldGYub3JnAFNNVFAA aXBzLWJvdW5jZXNAaWV0Zi5vcmcAAAIBXAABAAAAGgAAAFNNVFA6SVBTLUJPVU5DRVNASUVURi5P UkcAAAAfAF0AAQAAACoAAABpAHAAcwAtAHIAZQBxAHUAZQBzAHQAQABpAGUAdABmAC4AbwByAGcA AAAAAAIBXgABAAAARwAAAAAAAACBKx+kvqMQGZ1uAN0BD1QCAAAAAGlwcy1yZXF1ZXN0QGlldGYu b3JnAFNNVFAAaXBzLXJlcXVlc3RAaWV0Zi5vcmcAAAIBXwABAAAAGgAAAFNNVFA6SVBTLVJFUVVF U1RASUVURi5PUkcAAAAfAGYAAQAAAAoAAABTAE0AVABQAAAAAAAfAGcAAQAAACoAAABpAHAAcwAt AGIAbwB1AG4AYwBlAHMAQABpAGUAdABmAC4AbwByAGcAAAAAAB8AaAABAAAACgAAAFMATQBUAFAA AAAAAB8AaQABAAAAKgAAAGkAcABzAC0AcgBlAHEAdQBlAHMAdABAAGkAZQB0AGYALgBvAHIAZwAA AAAAHwBwAAEAAAA4AAAASQBwAHMAIABEAGkAZwBlAHMAdAAsACAAVgBvAGwAIAAxADUALAAgAEkA cwBzAHUAZQAgADkAAAACAXEAAQAAABsAAAABxZH8fCoQ0aiktvdNn5GSnqdu/IY5AAvcD/8AHwB0 AAEAAAAaAAAAaQBwAHMAQABpAGUAdABmAC4AbwByAGcAAAAAAB8AGgwBAAAAJAAAAFAAcgBhAHMA aABhAG4AdABoACAATgBlAGQAbgBvAG8AcgAAAB8AHQ4BAAAAOAAAAEkAcABzACAARABpAGcAZQBz AHQALAAgAFYAbwBsACAAMQA1ACwAIABJAHMAcwB1AGUAIAA5AAAAAgEJEAEAAADyMgAA7jIAALnx AABMWkZ1vC39JgMACgByY3BnMTI1gjIDQ2h0bWwxAzA/AQMB9wqAAqQD4wIAY2jBCsBzZXQwIAcT AoD/EAMAUARWCFUHshHVDlEDAd0Q1zIGAAbDEdUzBEYQ2W8S6xHjCO8J9zsYzw4wNTsR0gxgYwBQ CwkBZDM2kxFgC6U0IBACKlwOsr0BkGcU8AqjEeMd6DQU8AA8IURPQ1RZUABFIEhUTUwgUABVQkxJ QyAiLSAvL1czQyGARFQiRCCUMy4yIYBFTpwiPh7tHo8jwTE4H/BvIKIjDyQfJpAzHYAlcEV8QUQl zQ7xJu8pbyT0NkEO8DxNRVRBB7BBMSxgPSJHCfAEkGF0RQWwIhLQT05UItBUEyzwBeFFeBDxbmdl PQZSdhMxL0EAkAIgIDbwLjAuNhsQMAEi/irPCSUDNzcf8FRJVExKRSXONA7wSXAEIESCaS7gc3Qs IFYG8GggMTU1YEkEEApQIOo5JG41H/AvM08xfyZFXzSRN5AoTyafO2Q1EWA8AEJPRFkgZGly+j07 gHI60DtDACEDMD3hnGRvAOA94QqxXHEYsP894RDwAzA+RRFgOvsc8Tv/iGc5Nh/wRElWPhlnAABA VzsZNjRDj0CiSshoeWwLgGcsOxkBwN8+JwqiPicKcSR8MCgRIeD/Q1tJGEDfQe9C/0QPRR9PuwU6 +zgdgCZuYnNw8wKAPjgnYQFAT/9H/0kP/0ofSy9ST01PTl9Rj1B/XX84IHdhDrAEIAQAIHTmaC7w CsBndQeAAjBhMBBvIHJ1A6A0MDLvFPALgD2RO6AgBGI1YFWP/1afV69Yv1nPWt9b71z/Xg//Xx9o T1MvVD9VT2SPZZ9mr39nv2jPad9q72v/bQ96C2neIBEAL0BhMxhgZw3gYsL3YUIFoAEALn6xcc9y 33Pv/3T/dg93H3gveT96T3tfg4//b29wf3GPf8+A34Hvgv+ED3+FH4Yvhz+IT5VLYUAAcGv+c40P jh+PL5A/kU+SX5Nvr5R/lY+Wn50ncC1Qcy6x/2FAmJ+Zr5q/m8+c353vnv+FPUBMIDBLUVVPLfAt PZYgNUBHEGUuMUFSgEdJTi1SSUcgoOA6IDBweCLxPjgKsf8QAj9FP+M/oUA/qd8fGxFgf7Owqr+g D6Efoi+w1z7AaWsc0iR8NCVRRi3RrPBpunqtQDK1OwvisLktvLJ2TwUQfcBuB0AF0AeQc707oGW8 s7kdLBA9MVI+G30LgGUKgbDfiqY9QLU7YrWwuUYDYTqz/B/hL8J6f6jJHZwdgLJfitOzwQUgc9Yt BuBiUGMHkEAIkAAwei4FsGeKL4s/jEov0WLKZREAbD6gb2bKz8vf94xKyYIY0HEKUDVAyjfG///I D8kVvm+/f8CPwZ/Cr9e0XwZgAjDEX8VvxndUNjE3SC8yNt4AMDA3cDnoOjA5EXBNvl/WH9cv59g/ 2U/hpVRv2w/cH8Z3/8mB0f/TD9Qf3y/gP+FP4l/z42/tk0Nj5O/l/8Z/62+P7H/tj+6f2d51YmoF kP/a//G/8sg0zzXX6G/pf8kk/jnzb/R/9Y8AnwGvAr8k1v8wYDeBukL6z4y/pR+mL6c/vwgPsU/+ z7NvtvUf8FCun3+4GbePuJ+5r7q/u83awWT9/CNtHDBHIn2QYRBh8DYg/GJtYRAvsmDw/d8Pb8kk /y1wA28EfwWPzp/PryAvIT//Ik8jXyRvJX8mjyefKK8pv/8qzyvfLO8t/y8PMB+MO+eL/x2/Hs8f 3zXfNu83+eTAGw/nHB/JFRpRc2O9EM3QzZC3rOBiUD5YdmMQYTNXypAybBkgV2ljcEBQZWK/Y5A7 3zzv6oQ/4BqwdDiv/zm/N88yLzM/Rq9Hv0jPSd//Su9L/00PTh9PL1A/UU9SX79Tb1R/VY9WnzQM 9m9BQkS1EKBo0YBmrVBZ8HT8QJA6Ly93XeAxLjUmZi8ZghmAbi8aAmLQZvxvL8mBrooX4TUgQJAP wg5mQJBi0Pywe0hZUMhFUkytsEsgXV9eb5lfeH19F+FAkHJzEDDAXGNmMVx1sKpir79jv1+GDR8T ig2v+fpBRXD/RD9FT0ZcypBBT0JfQ2hAALZlGYL80HMZAkAAbb2k9CB3RBBoGkL5Qj7iycAQZHkg J35AbHAn/3DPcd8dL24fby9r71kvWj//fE99X35vf3+Aj4Gfgq+Dv/+Ez4Xfhu+H/4kPih+LL4w/ /1sPd2/IztGOeV96b3t/lH9LlY+WmVnJ0CBjpBAgzdGAYbBgQBNwZWXAzaH/ZEEPABnCQCIaA5CP kZ/qhP5hRC+YT5Zfjb+Oz6H/ow//pB+lL6Y/p0+oX6lvqn+rj/+sn62vrr+vz7Dfse+Pn50f054v yUZvd6GwcpO/oB/foS+zf7sfvC8OIVdAMJqi+HBseRnB/NDA0JrQdAD3c4BhkBowecnQPwD5FRnx /7yAFsA7sMHhts+338klGWGnypDDEZtgY2lg4GO9bw++f7yMQCCakSJSZTr78IDNoHTa0RlgzkD8 I2GQ9fySLswQIscfyC+8j8yPH82fzq/Pv9DP5EhkYXneJxr/xI+4xuTAcMbwZ2D/0l/Tb9F/2P/a D9sftD+1Tz/eb99/4I8QoGfQNNBTTuBTIE1JQvCAyiH8kSAgKFNjb2cwIEv5uUBwKdvP3N/d7+Hf 4u+/6Q/qH+svtn/Wn7iZMuSg4cpySVNJRHRAGRH8cPk+gG92ubB2IMpx5p/nr//ov+yv7b/2L/c/ +E/5X/pv//t//I/9n/6v/78Az+7/8A/DuHtlsGFmdC254gfwL7lR8vEasAfwbcDQLWcCdUDRLTAw LnR48RowKFJvPsAD8PLQ5KBnBS8GP9f0UnUaoGEAbP/mj/S/9c8N7w7/EA8RHxIvvRM3LRbPF98Y 7xn/LRPP3xTfEu8bXxxvHXlNdITKkHcKzwvf8YQxHi8fPx1MRBufcMqBTZugwTAyNSAaSmZRMgmg KAAxMDogMDk6MjMWsDA2DwmgJE8lXx1MRnJvbfXKkCLl6CIhryK/8XUCPzsuUAOJPB2I8wFnMC5r seZRQG1j1XAqMC7l8OptME9nMWo+HY8qDysf1zZFwmXKkFvLcV3kvza//zfP1H4hny6/L88w3zHt uUF/ud80rzW/O788zyBfdLEt//Jw869ITx0/Al8Db01fTm//T39Qj1GfUq9Tv1TPVd9W7/9X/1kP Wh9bL1w/XU8EPz8PD0FPQS9CPzIpM0NDRRgzNDkpUClgREQxADRBQkI4QkNEMDdEMEIo4G0QNUMA M0Y2ODIxQE2AQzRFWENIMPHgfzOPRS9GP0r/TA9NHMq1LbxUeZtgPs9jH3i3ZQng6i/A0GFNADtq 72BPXn//dN9173b/eA95H3ovez98T/99X35vf3+Aj4GfYd9yH/E5J5rwhuDBkHQ9nLBvLeA4ODU5 LSQ/bn9ND/+Jn4qvi7+Mz43fQ2jk1spw6nZEMHebcSyPf5CPjp9Hk9+U75X5SSB3wiBs6/LAlaBr wxB0w0CF34bvyZ8Vbm7CIG5jmlHAcPXGMGkHsGMoMMIgxiDAsO/zFctBnbLkxi6C74P/hQt+QQfQ ubDAoZMgCMAnsCB/l5DLQZqvm79zdZ95wbB4a9hwwLBkwTBH8tDyAGHwbWt1baVx8qKZobmw/5pR wYCaQPLAmnFqscFRyuC9o3g3pC+lP6ZP5PR3w2CmaJ2jwHBscMsyS5MRocCQR2liYiewc6Av/6E/ hPywNMogxiAKQMCBwYD9CMBnlcDywKvfrO/xhC0g48BwwkBkdXREMMYgryKBsGFNY0RBVEHyk+Z3 tHGdYGFiwWCqI8ogjwkAo9K48cYgZWZmRIC/w3CvI7tytY+2n/GEYg1Q//NgCKC4ILhgwWCxD7If hPxOWZ5gtFHzMCBwLKBif7pRv2G0ssoRCfCdspXAd5+jeLRnvL+9z/GEcG/L8P+qAakVmdvLsAig DVGdo4hR/+WDxHOpc6jQCXCv8LtCqtL+ZqqgOgBEgMZfx2+ct/LA/7BhnbO0sLiAO2DE8Qnhk1D8 ZWvADJd/mI+Wn9Mv1D3+SKmCzuCdlMtfzGSaf86//63LB6NK7MDvge/VP9ZP1F//4N/h7+L/5A/l H+Yv3l/fb//pf+qP65/sr+2/7s/v3/Dv//H/8w/0H/Uv9j/3T/hf+W//hW/bPyNswA/73/oPAK8B v/8CzwPfBO8F/wcPCB8JLwo/LaJ6ZMyQqTBjdDByaThmaWNqcLsj2nBERQBTQ1JJUFRJTz5Oq5/+ n8+4yqCw4ENsAXCQQ2ZnU3J2ct5UulMNEJ6wD3B50ULEd/8soLpxnzWIkBRwuDG7gZ1A9y1AnsOq AWKfEBE/Ek+t9v+7gecwumHSH+ef6K8MDw0f/x4vHz8gTyFfIm8jfySPJZ//Jq8nvyjPKd8q7yv/ LQ8uH//83xi/Gc9kbzDfLw81jzaf/zevOL85zzrfO+88/z4PPx//QC9BP0JPQ19Eb0V/Mr8zz/80 30cvSD9Gb0zvTf9PD1Af/1EvUj9TT1RfVW9Wf1ePWJ/PWa9av1vPSQgiVJ3BniDruICe4C/DwGOo sK/gFkqfSa9Kv4f1sNAPgGd1GCL/FwQbzxzfHe9dn16vaE9pX/9qb2t/bI9tn26vb79wz3Hf/3Lv c/91D3Yfdy94P3lPel//e29JFxd1Yk9jX8/0uNUWw/+qYBUQnyS7gZLCqRK4IJ1y9xeiZ+APMHUO 8tCTvI+BP/vciBtzImXfZu9n/30vfj//i/+ND44fjy+QP5FPkl+Tb/+Uf5WPlp+Xr5i/mc+a35vv /5z/ic+K36APoR+iL6M/nm//n3+mj6efqK+pv6rPq9+s7/+t/68PsB+xL7I/s0+0X7Vv77Z/ST+H P8+LMgBfuO+3H/+9v77Pv9/A78H/ww/EH8Uv/8Y/x08OLxtwF/EPLxA/uu9bu/8Ta0SDgBSAZBRo YfOGcNnAbGwbv6Svpb/JH//KL9WP1p/Xr9i/2c/a39vv/9z/3g/fH+Av4T/iT+Nf5G//5X+5787P z99L7+g/5m/s7//t/+8P8B/xL/I/80/0X/Vv//Z/94/4n/mv+r/7z/zf6h//6y/sP/6P/5/9zwRP BV8Gb/8HfwiPCZ8Krwu/DM8N3w7v3w//EQ8SHxMvX7kgYG9hf/cBTwJfGuBkhmBkwGWhzBD/0y/U P9VPFP8WDx9PIF8hb/8ifyOPJJ8lrya/J88o3ynv/yr/LA8tHy4vLz8wTzFfMm//AHdldH/fGk+B /4MPhB+FL/+GPzh/iF+Jbx3PHt9BD0If/0MvRD9FT0ZfNG81f0mvSr//S89M303vTv9QD1EfUi9T P/9UT1VfVm9Xf1iPWZ8Abz5//WPOM71vXD9ab2EPYh9jL/9kP2VPZl9nb2h/aY9qn115eFJlbcxh PDAZcTbgIKvM8NLgZD3gZhjwbRlvV17v0H/RgEnRQHTSQyxPcHRxH3Ivcz90RdGAcv55Rv9ID0kf bH9tj3sffC//fT9+T39fgG+Bf4KPg5+Er/+Fv4bPh9+I74n/iw9dT3VP/3ZfA1+Nz4v/kn+Tj5Sf la//lr+Xz5jfme+a/5wPnR+eL3+fP49fkG92v3PHy+EcoHP4c1R5OyCgv6HPn/+n7/+o/6oPqx+s L60/rk+iv6PP16TfG/J0EGWm2ix4r3m//3rPsG+xf7kfui+7P7xPvV//vm+/f8CPwZ/Cr8O/xM/F 3//G78f/yQ+yT7NftG+SL8vP/8n/0H/Rj9Kf06/Uv9XP1t//1+/Y/9oP2x/cL90/zV/Ob/+lT6Ze 3r/fz93/5a/mv+fP/+jf6e/q/+wP7R/uL+8/8E//8V/yb/N/9I/1n/av97/4z//53/rv+//9D/4f /y8APwFP/wJfA2/hH+IvtL+1x7aft6//uL8FHwYvDY8Onw+vEL8Rz/8S3xPvFP8WDxcfGC8ZPxpP /xtfHG8dfwb/CA8JH9AfID//Hm8k7yX/Jw8oHykvKj8rT/8sXy1vLn8vjzCfMa8hzyLfw+M/c7lj cFBvNPAzP/80TzJ/Oi87PzxPPV8+bz9//0CPQZ9Cr0O/RM9F30bvR///SQ9KH0svTD9NT05fT29Q f/9Rj1KfU69Uv1XPVt9X7zWfAzavCX90ZWdlcjP+MgsvDD8NT1mvWr9h72L//2QPZR9mL2c/aE9p X2pva3//bI9tn26vb79wz3HfW49cn/9drySvdJ9yz3lPel97b3x//32Pfp9/r4C/gc+C34PvhP+f hg92L3c/N8+mV1VkOY//iE+JX44vjz+QT5Ffkm+Tf/+Uj5Wflq+Xv5jPmd+a75v//50Pnh+fL6A/ oU+iX6NvpH//pY+mn6evqL+pz6rfq++Jn/+Kr4u/Xr9fz2DfrT+0T7Vf/7Zvrn+vj7m/us+737zv vf//vw/AH8Evwj/DT8RfxW/Gf//Hj8ifya+wX7FveG/LX8xv/8qf0R/SL9M/1E/VX9Zv139P2I/Z n9qvzaNUaOUgZRwgd7OA3yDlEG1vdgBlZCBiZWNhdQXfEXTe82ZpZWxkjHMgzwDfIG5vdM3vx87/ jIUK0HF1aQrQ3/AQdG8gZArgY3Jp0+AQ4IIgY7jAZTkA4VCGbuTR3vB5IHVuuOBmYwrh4vBpbObQ CtF0/eVgY+HA5bnk8eHv4v+MlEhhIHO40Gds3yBJflDhUAq05lPpT+pfjJRw/Y3xLrbPt9+47/BP 8V/yb//cX91v9b/2z/ff+O/5//sP//wf/S/+P/9PAF8BbwJ/A4//BJ8Fr81P7a/uvwdfCG8Gn/8N Hw4vDz8QTxFfEm8TfxSPvxWfFq8XvxjPGd8J81LfpQngnGxz5QBmcm9t7+WjCk8LX4yUY43w59Hv wK/mcOvx5eAjMGaN8G3mYNPnMOCAYWLsICwgPyFPk4yL5hJBdOgBYnWzUORzRx/AdXDzH/Qv9T// KR8qLys/G48cny6PL58wr/8xvzLPM9807zX/Nw84Hzkv/zo/O088Xz1vPn8JnyU/Jk/+NPAMQP8/ L0XPRt9H70j//0oPSx9ML00/Tk9PXx0/38PrIzDfIG9QMGQowC3g4DDJs1AgIuCRIiAt8B//x0Pf JqnlJHB0aSMwVNIXVo9Xn4yUIoz2Q2ZnIFNydnJFjVByef4iK+8s/y4PXg9fH2AvUZ//Uq9jf2SP ZZ9mr2e/aM9p3/9q72v/bQ9uH28vcD9xT3Jf73NvQm9aX1tvNUWvdh90T/9673v/fQ9+H38vgD+B T4Jf34NvhH9Tf1YAjQVE5UBdUO5kXTKNcOUgeB+veH8mX4tclR4QZ11xaXR5XXP/JFTwD2HfYu+G T4dfkk+TX/+Ub5V/lo+Xn5ivmb+az5vf/5zvnf+fD6AfoS+iP3cfi7//jM8Mj6T/oy+pr6q/q8+s 3/+t767/sA+xH7Ivsz+0T7Vf37Zvt3+4j7mfptJB7JC63/+777ofvk+/X8BvwX/Cj8Off8Svpi+n P6l/jd+O4r3BcvhUeXCSEca/x8/F/84P/88f0C/RP9JP01/Ub9V/1o//15/Yr9m/2s/JX8pv7zeK oO5lJ+DslM1SLI/vkP+SD//cL90/5N/l7+b/6A/pH+ov/+s/7E/tX+5v73/wj/Gf8q//87/0z94P 3x/gL6lv94/1v//8P/1P/l//bwB/AY8CnwOv/wS/Bc8G3wfvCP8KDwsfDC//+W/6f/uPDd8O7w0f E58Ur/8VvxbPF98Y7xn/Gw8cHx0v/x4/H08gXyFvIn8jjySfJa//Jr8nzyjfKe8q/ywPLR8uL/8P 7xD/y0/MXi+PMJ8uzzaf/zevOL85zzrfO+88/z4PPx//QC9BP0JPQ19Eb0V/Ro9Hn/9Ir0m/Ss9L 30zvTf9PD1Af/1EvUj9TT1RfVW9Wf1ePWJ//Wa8xfzKPM5/hHuJf42/kf/9bz1zfZD9lT2ZfZ29o f2mP/2qfa69sv23Pbt9v73D/cg//cx90L12vXr9fzxKPdu91H/97n3yvfb9+z3/fgO+B/4MP/4Qf hS+GP4dPiF+Jb4p/i4//eM9533rvjT+OT4x/kv+UD/+VH5Yvlz+YT5lfmm+bf5yP/52fnq+fv6DP od+i76P/pQ//ph+nL6g/qU+qX6tvrH+tjw+PT5BfNC81O1RjcFD+b7Cwrv+wD64/tj+3T7hf/7lv un+7j7yfva++v7/PwN//we/C/8QPxR/GL8c/yE/JX//Kb8t/zI/Nn86vsc+y32CYwnQ1gGVyMzJh z2Lf/2Pvz+/Q/9g/2U/aX9tv3H//3Y/en9+v4L/hz+Lf4+/k///mD+cf6C/Rz9Lf0++R/+rv/+kf 75/wr/G/8s/z3/Tv9f//9w/4H/kv+j/7T/xf/W/+f///j+zP7d/u7wE/Ak8Afwb//wgPCR8KLws/ DE8NXw5vD3//EI8RnxKvE78UzxXfFu8X//8ZDxofGy8cPx1PHl8fbyB/nyGPA08EX7OfNTtVZLWf /yO/JM8p7yr/LA8tHy4vLz//ME8xXzJvM380jzWfNq83v/84zznfOu87/z0PPh8/L0A//0FPQl8l fyaP1G/Vc9Xf1u//1/9J/0sPTB9EL0U/T29Qf/9Rj1KfU69Uv1XPVt9X71j//1oPWx9cL10/Xk9f X0YPRx//SC9hD2IfYE9mz2ffaO9p//9rD2wfbS9uP29PcF9xb3J/T3OPdJ91r2LvVGgoYCBQY2hh btVwIHrBdABvIGRlY291cPJse0B0aHtAY/9lDygPE7UUe4BhYnwhZnJvBm18Q38WRHNjdnLYZFNy gdCAJXN7oHxQLGF0e1CDEGN7ECBtDymwfH99j36WYWNjdbJygwBlbIAQg8BmfCCWY4MQfFJltSJp ZXtxp4LyhQB7QGJlTtBnhxHycCmxZWR7gnxfhM9+eMpz1YB21YBzLkzPTd//Tu+Nn46vj794H3kv kw+UH/+VL5Y/l0+YX5lvmn+bj5yf/52vnr+fz6Dfoe+i/2NPis//i9+kr6W/o++qb6t/rI+tn/+u r6+/sM+x37Lvs/+1D7Yf/7cvuD+5T6aPeqCIQIBxiDBMbGR60IjCYWyCsWE+ZHvAid+oH34te+Bu ZvUpsG17EGN8MYBDfxSIMAEowEF0dHJpYnX51VBzR4CgfACQb5F/ko/nxd/G78f5QXXAb8F/fqXh KOB2b2ly1c/Jr8e9/lN74MTAzs/P38fP0k/TXw/Ub9V/1o/RR1BFQ0kAQUwgTk9USUN+Rdgf2S/X P9wv3T/K+mz+bHtQwxQpMMMAe4CGsCiA/m0pQImyy9/M7360wECDwN5igBB6wd4AhtBuv8LDANeG 8cMhwCN1vnFvulDAMV/e/+AP3hy/oYPAc4zgZYAocykgbmFtv9G9gEBvjRCIsOcQg5BhgBB/47/k z8KX6XDeAHrgwwFpL3vAKSG/UO1TcMTgdml7fCBJcGTo3+nv3hziOS61y5BugBB17KDFEGgpsBxp er/Rg8DyIGV3LF/t3+7vfqXoMffQZH8QY/hsb3OGoOhR+RD6wcTU/+Kx8p/zr94c6HHw7/H44iuv 9//5D3628eFverBiKUD7v9D2QEnog4cRv6CNIPxv//1//o/AMHrB7MDsIAcAe0P+btHggNTm5gIf Ay9+tIPAOGNpcMRy7GLnxWVt+XwQb3nsQPtiChEowAZf/wdv3hzsAYmAKIDE8IBi+3L/huDyEI0g iSLAPwxvfngJ1u/ABebXDhf30Hl78IiyEG/vEX/eHOY1CoFpvqG/4YLy/RoCbegwgxAVXxZvfrQK gv8F8gl04vXsIOKy7WKC4/rIz86/G3/eDXvgcHmJIffQ//Hxh/EoEh9fIG9+tPuq+2L/6DV7EIAQ 6HTiK/Bl8n8lv//0nywjgwAvgHrwv9Qo/yoPR360Im97UlNUUtvAVABMWSBQUk9ISeBCSVRFRI1f L+/eD784PzlPyuv2cMMAe0B39vD/GUKJEI0QetAzDzQfwpj/378A7zaBg4CNIICgQHBz9vD+db7Q Ox88Lzo8HeP2gT8/+0BPfpdt7MFCYIbT5nGG0X+JcPbwPlHtZPIwFQP3AWf/OiBCcRfZSLGDAEVP Rl86PP8VEu0ESO9J/4YV6+TtU3vA//vBD5C/QeIQJ8GIMTgMvC/lvT9UwBRleObxiKH2cf+JgiwD ulBS/1QPNShPX1BvdybuS3D2oGmDYC4KBKF1v4BQYkDiKijQCoCCoHV68N8TUsTRh3Disb7xcHwQ 7c//XR81B4LEXu9f//S/9chmTxNnX360KGeGwTAxKf9pP2pPOj9wP3FPcl9zb3R/73WPdp93r3iz LXwPfNp5D196H3gvfh9/L4A5TQnkOnds/24PF2UygO+B/4AMRAtLwYRQTWRSMjUgShNFEIqgMDCK wDEyOkwyN4uQe+EwNIswILooN+BUb/+ID3/9RkSgwm2EUCJSb2LmQB8wuTfwIFLoML5w4gAihG/f hX+pr1gFkeBYuTwSyevwSkDisC7isGwu9qBoqi4uwHWT32eU+j6AT6+NL44/0VZjYGoOIHSEUGBb SXBzXZCwhEFJaFNJRO1TRPrRUrFy92Yvkk/N2DqaH5svgA9Xn/9Yr6Sfpa+mv6fPqN+p76r//6wP rR+uL68/sE+xX7Jvs38/tI9ZfJ9/oI8rFSLAZnT+LVcguDC8IJ3AvCD64BPAY7wgD2EtZ3VCEYwA MPwudFrQoi+jP6RMWlCP8VJNVrFpa7pgavagIHxDLpE/uk+TX5RvlX1jGGJtQESgLIAuaHD+LmHh xQ+Yn7X/vt+/78rS5ENjniFQU7Zfxg9rt9edwJaQvEEuW4Bnzp/Jn+/Kr8u/zM+DqS2eYIRfw38X xI/PL5V9UKQxLkxOgFguNC42My6LQAwwN4qwi3AyNDM3473g1VAyNjaWn9IP0x8/1C/VP9ZPzfHw cUIxLVQ8eXCET9kfF0c30FhUgC9QTEFJTjth0AVpAHIsgHQ9VVMtYEFTQ0lJ6dABdD36ZvsAdy7P 48+kL+v/7Q//1qzBmKIf7+/t//LP89/079/gn+GvuS/nnxdHWT8gKND+ST5wQyBW0ZBRLpFL8S5R XxPABiFXX7dvWXxQQzBhDyyBLIBNAkzRIFVSTP8YQgOQC1A+4FsB+0/8Xxd09yRwS3AFwHn1r/a/ 98/43//571oDD1BNQkRRHnMVECISd/+vAL9ZfE8F0GYAAsNkYz6gA2NmYXYsQR2xd58rsCiSBK8F vxdldXAyAP8+UR4QA4EHPwhPCV8Kbwt/5/qKEiA/IG4nBJBawCuB/zgPGG8ZfxqPG58gnx6vH79/ I18kbz0fMlaQQOuRNpJt/59fFK+7W1viA5BC4FcAx+H5QsBjbCvQSHBiRSZ/J4+dJZxiAtFCwDZx dHc+oP/rkBOBDiQ1sQ3iZeECwA5A/0LAKs8r3wbUMrJSYQ5A64C/nVFEsSWAL18wbz09db1wd2Uw ipGLMDRkcFKgUlAg/2kAQxAzQgQAEiH+MDyBUlL5YiFxdQMgVbJb/zW/Stj/vNI4jzmfJZwC4JDg ZZRNAfhJX1RkgFrASLH/YWLg/y7BkFBXTUKfQ68mb0f/wE7/UmEu0OogDgY0Pz9vFT8DMP+QUFpz WpAOYBNx8p9K/0kNiiKeQEOeUCBOYQNizQMxTYrwE2AtUFuBWkDjT6DXwHRzImRwZTBPoD8TYz2C Uj9TT0kfQHs8QUdPdNqADjFmPSIQEHSgcDovL3ddwC4PwM9aYGOQRtBacHQvWlBlMMRzL7zDL21z WRCLMXYyyBAQISJZmVhwRpFsHmRYcjfgUeFlMHtIWexQRQPA6bBLwWBdX15veV99fX1hEWFg6iBP IFzwY2YxXIrxWrhi/2QPP198EAcP91swat9bLjky+VlQL0FZkFhfWW9af27f/2/vTE1On0+vBtUE UC8wA0DvTZ5RFTLxUbVzUi9yr1ROrS7QbsGQN7Fz36B1LxL7PrKeQ3KK8HTPdd8GtgLQ/xaQNCNw oP3QPROe50TGV1D/eg97H0PtV5pbT1xfZ+9o//tfg96AOWAPYR9iL4nviv//jAlmD2cfj5+Qr4wX bB9r7/9xT24PhD+FT5k1RVJ+/4APuQbUKG48cDegUXJtHaDPQaATgQ/AKaBlKZr/nA//fC99P35J gX+eP59PLOWClv+DL6Kvo7+GX4dviH+Jj5Uf/ZFHNF//jV+Ob7H/sw+0Gv+SX5Nvt7+4z7Q3mG+Y P5lPf5pfrF+tb8Ffw7/Ez8XSSf8NsKg/qU8G1BM2UXAqYRb19/4BDkHFEHoygQ3VN6ClP/8+slFx xh/HL8g9fm/JzwZN/+sRgn+roXfGxTCC0QNRRmH7FmEDQHcN4z0yz9/Q750d/zxgpfBRY1aSzpHT f9SPBtT+Ry4AFjFW4BOQDaM3oEWf/0ah2NEDIM+f2l/bb1bVVZT6d6chb6FQKYBOb95/LLjedS6w M0NNFiogZw2hDkD/PkFNYS2i4v/kD8U81j8Oj/sPnwHMSQSQAuANQIIzA2H/53/ojwbUDdM9gtym 5fnsL//tP8U8oMDdFuAYLvANsCoA/z4F/vH0L/U/LOW9gO+AoVD/2KFXYNfx/MEyZ+Lf+V/R3/pQ RUBkLUA+gkVSLiBWsf5uFwAqAP7ARgAp0hMQUXL//a/+v0EVvSATYC8AEtGCUf93gcUwOBCCQgHP At8D71eR/eYiKKGBogAz5AT/BggHb58If/ZE/KQzJIJiZmbvgL/h4QufDK/FPAXi3WFn4CL/M9BR FBTX5eoZIQa1EX8Sj/v2Rjegc1WyDpQVbxZ/+o0zvYAy8HJrANDh8XR5/inwP/FP8l1RYjfBVqDm kf8uAKDh4LXMlhufHK/2Sdzo/x8PIB/FPPwJ5vAF4MUwGhH/z3ThH+IkpyHdYKXAJ/8pD2H2NU5V TEw+sDMgIv4iK38sj8U84LPMYfygd2C/Ru82L8UvOR86Lzs6Q+bw+dhCcz87/z0POx8/v0DP83P7 VfBrc6vfQ49Bn0Yf40cvSDpCb2Ix/zMP9jX2UhsQd2BsK29J/8gvAEFqT3hgctyAaUfwIsAg3kzc gE8vUD9IHFW9IILRx2TwUwF+IU5ld0wvTT/99jVIHmAZEMxQzTBTb1R/lUgcchAQQNcQbC540HRo LudAdVqfW69IHDYAMDMtODYyLTP4Nzc0Xo9fn0gfYn9jj/1kmS1oT2lfam9rf2vkZU//Zl9kb20v bj9VvOuBbxAQQY9Xj1if9kR+IWlTQ9Lg/4MXb/9xD2dvel9sf3fPeN/Pb698v33PwaBBYwqwXZD7 zAPZQFMK8aYSc690v/ZEkDMuNC7CoGMppkKQUkZDIGIAMjAAwPuhEnZjIjAn11Dh0M5h50DHfv+A DzdPU0FNwqDMYf/rcVaA3WAaAqgPhC8di3Zb/4hm4KKGhjjvie9En8xigtX/MbOIdKfhziIwIo1/ jo/2RN8wbtdR2UD84aESdPww00D+OpJfk29+H5xfnW+efyNvfyR/oc+i36PvpP+mD/JcKH92VMkQ CgaXj5ifNCUeYivwICdpJ66h0tJF76Av/6E/qA+pH7Hvsv+0D7Ufti9/tz+4T7lfJSuq5OX6rrF0 367yq++s//ZE+54pr4+wn/+xr8N/xI/FmeJxJoHckB4Q/yczqu7mYxByvhu/v8DPrgn/zaBaj8dP iv8m4BlR51CbJPEiMWxkLfbw4dD9BSHw/xrCkk/Qn8Vf1S/WP0TMJjX3hwEiMCdxY8nQzJ/Nr/ZF /5vS86D28hBgFMcPQScREHD/VvHXIC+mJmDqANgP2R/XLP8vF98STwCaVifv3T/2J9vB+xmoMCVp EGMmGCIh4b/iz//XLBmodlwi/7wvvTzmT+dfv/ZElVMqkJWCVpH70WkvMPfXAPyggvJznB/sT9cf 909f+F/5b/p/+4/8lzGGMEH/AaAJ6Cew5iAbESc0HmLyz7/z3wmFyk/LVa8yyTJu/S///j/8T/AP 8R8JTwpfC28Mf+8Nj/G/c2AHcGII0FpBgmG/Aj8DT4+UGaiq0F5ALocA/9Q0hjB2tt8kGagepHcv B9//CO8PvxDPG78czx3fHu8f/98hDxNPFF+PheoxL6ux7kj7L0DCU2fCsu+/Iw+9LZVTe9NQRZB2 XdAmIDhx36Bz/mNOwpFzJQ8mH4+UlaUZX/8abxt/Ka8qvzOvNL81zzbf4zfvK185LjE88Mt0RdD5 i9JmYYLghwDgAeGBMeD/kWH1oS5PL1+PlIIQdxCa4O+M0ILwVpBdgGUBYlcRrzL/1O8yLzM/Q49E n0WvRr9Hz71I2DIAMYIKlaY84jKHA7/JcT8/QE8EVZpB0qxqmjD/vsDgwqrjSX9Kj0ifOi87P39V v1bPV99Y71n/O98FHXB/muBOv0/PdbZf4faxgmFz8nkSkGVt9kE+seCx33H/ASDcEFVRKW9dDyuO 2yZTT/9UX1VvZR9mL2rva/9tD24ff28vZs9gL2E/j5QGkgEQdf10sGmb4QB45UDPYUJw1DD/q1CC YYMRAadiqHQvdT8wZf9jU2h/aY9qn3Fvcn9/r4C//4HPgt+D73MfY7cBp2RlTkP/5iAS8MLA07CW EcKAEvB4Mv96X3tvj5gB4n0/fk9/X4Yv/4c/kW+Sf5OPlJ+Vr4ffBL//y0YBINSgY+HhMgZD1KKL 77+M/zBWnoDgIdNQ27BldsH/TmF9L4//kQ+X35jvo4+kn7+lr6a/p8+o31HyLOBv5bBZ5KFuZvaB 5TEoFqBnnRaxYuYvnn8nB3BwwrB/sUDK0V/Br7BNoE2iTQEp/0Nvoi+jP7Lvs/+1D7Yfty99uDcz F0DbAemWQqDlpmn/X/GxIbfA3wHTIa6vr78nJbeLYhd0TlB5X+Ct4W4ooP8BICjg6jG4z7nft++q H6svf8T/xg/HH8gvyT+rzy1yb9318XmyrcwfzS9XdrLqMH++L78/BEabF9vwvZXfgFTfGPMFpIlF vTB4AHTCj8Of/8Svzx/QL9of2y/cP91P3l/x0M9sb2cuH9M/jecWIP8XEVKC4kBkQM43F1ZORi1B 9WRAUCikRykS46/kv/TW/9hQ16/Yv9nP4J/hr+7f7+8f8P/yD/Mf4k8/AHNvY/+xki3wF/NOYAVg 1hsGAmgh/wEgTaNC4em/6s+OGLw37G//7X/uj/Vf9m8A/wIPAx8ELz8FP/cPvNktQRKQPqBpZ9UI wC1oIXf8QGTO3whPz3NP+2/8f8CBSG+gkOdR/05AoCBMzzEv/48AnwxPDV//Fc8W3xfvGP8aDxsf u7BOIBwuNj0QTkN3eCBNQW5ZDw8QH2I2bZsg1WR5/00DH7Kas9YsE28UfxWPHF//HW8oLyk/Kk8r XyxvHg/XF//jTyFv5W/mf+eJPcF2oK2w/fjwYz8AnIMlvybPJ98ur/8vvzpvO388jz2fPq8wX/3y fzJvM3+OFLx/UUGtYQsRdb9NkFHRrnEjmNIhY4BwwXD3Q99E744FdsCwNRA3/zkP/zofQO9B/08P UB9RL1I/U0/DQp+uBU5VTExkAErg3CIiu9BoIaBQb/jjJF//nV9Kr8Ao+jGOcujkTJ9Nr/9Ov1WP Vp9hP2JPY19kb2V/f1c/6VTsMa1RSXCtcLzxc/8MH2iPmcy78ltvXH+OFEei/TTybqAwvLA1Yegw 6JI04P46Xs9f32Dvcz90T3VfbC//bT94r3m/es9733zv9z273n9u/3AP1HW86DVvwRQ1IWEOYngA i5D4kVdJVEj/gr+Dz8BGdg93H3gvfv+AD/+Nf46Pj5+Qr5G/ks+T35Tv/5X/lw+YH5kvmj+bT26R 1jn/IIL6kTdB/buIb4l/hN+F5P/B5eemiw+MH40vnJ+dr6h//6mPqp+rr6y/rc+u36/vsP//sg+z H7QvtT+2TwoRMk+ij/9LxjcZ1XA3QYYvwUH4wMDB+/phcgAgNOCoEIdxSCBbMO9G8Lp/u48i1mam D6cfqC//t5+4r8Xvxv/ID8kfyi/LP//MT81fzm/Pf9CP0Z/Sr9O/+4GRSUF4CuD6sEkBpRxYMH/6 IsDfwe9L5b0gWiAR0XP3gbE3gL4QZUcgxZBeALpR/xL/xB/FL9Sf1a/T3+Fv4n//44/kn+Wv5r/n z+jf6e/q/z/sD+0f7i8Oj9pP/M01Lv0fEDFrvN8v4D91//aP95//79/w7/rv+//9D/4f/y8AP/9Z oIHOhU81x/Kv879L5Ibv8Yf1T1VU+I/5n/qvAX//Ao8Njw6fD68QvxHPEt8T7/8U/xYPFx8YLxk/ Gk8bX4GRHyTGBu8H/0vkJUNORVb8RVKgRHIRoLwFTh//IQ//RgXYkwsfDC8NPxyvHb8q3/8r7yz/ Lg8vHzAvMT8yTzNf/zRvNX82jzefOK9dsKWGvaD+b3JhwFC9piWPJp9L5L4v/yK1v5Ohfz8vS8a/ +yhvKX//Ko85/zsPSG9Jf0qPS59Mr/9Nv07PT99Q71H/Uw9UH1Uv/1Y/XbCF8tffQp9Drwj92XP/ 3E/dV1uvXL8JBt4PRr9Hz/9XP1hPVn9mv2fPaN9p72r//2wPbR9uL28/cE9xX3Jvc3//8j9hP/Rf 9W9kf2WPes973/9873Uvdj+AP4FPgl+Db4R/9bleYwRAQR/QWnAGwCTA35/gPSA+EAmQ2FBsv9B+ UOMfowpQb3VsCoA9gF9Az3fPeN/b1T2RbW8J8KSw/3/Qvhh9v37Pf9+Gr4e/km//k3+Uj5Wflq+X v5jPmd+a7/+b/50Pnh+fL6A/PJe/MT1wvyOTjC+NP9vkI+8k8TqP//+RD5IfoY+in6ufrK+tv67P /6/fsO+x/7MPtB+1L7Y/t08HuF+5b0CAKGlTQ1PqSSPQbqTQacBQv6ClT4OmXyIKKyAnaSfBQUpJ vbBEwUEiIsFCdN/Bkr6Pv5/b5MJAKakvqj//q0/F38bvx//JD8ofyy/MP9/NT85fz2/Qf9eQLdSv 1Xq/0a/Sv9DP1r/Xz9jZX9yPn92f3mrZj9qf2KxJcEKP98PvCOYjIGnYgVsQCjFF77Pgf+GPc0Ak 8LxQLkJAnmfl/+cP2K8nCzxB45RFQIBoRSBmPSK8AHTh4oA6Ly937zB6kOk25i/lMiMgbi/lsuvA QjD0L2nigCLq+enQJOGLoA3p0maLoEVCe0hZUOEi8ExJTkvCMO6/78958Nd9ffIRi6BfYONAXPBj ZjFci5DrkOwn8/9/9Q/w1rv3u+cEAPsf2V458jLqsC9B6vDpv+rP69+//x8ALwE/Ak8DXwRmRV7B n+K/488npCUx4nJEaYsgk0VgPSBWb1uAMTU9ILpJpGB1pT8JHyeGOQTv+wX/BAwqEg8THg8PEB8E DwUUWTUVES9GT05U/xVp+6+8UA1iGUgWaA1TFm9VDMY3/nJQ/s4w7ZEvAEJMT0NLUVVP7FRFGJ8c v2f8MQ1/Ik+JDPM1OB9ST0RZ/s0X/nAjzyZRN/6BSFRNCkwVYH0ogAAAHwA1EAEAAAB+AAAAPABG AEUANQA2ADEAMABCAEYANABGADQANwBDAEEANAA5AEIAQQA0ADYANAA0ADAANwBBADQARAAzAEUA QwBEADYAMAAxAEUAMAAzADEAMwBBAEAAQQBWAEUAWABDAEgAMAAyAC4AcQBsAG8AZwBpAGMALgBv AHIAZwA+AAAAAAAfAEcQAQAAAB4AAABtAGUAcwBzAGEAZwBlAC8AcgBmAGMAOAAyADIAAAAAAAsA 8hABAAAAHwDzEAEAAABMAAAAUgBFACUAMwBBACAASQBwAHMAIABEAGkAZwBlAHMAdAAsACAAVgBv AGwAIAAxADUALAAgAEkAcwBzAHUAZQAgADkALgBFAE0ATAAAAAsA9hAAAAAAQAAHMHYIZOwrksUB QAAIMCDTNAEsksUBAwDeP+n9AAADAPE/CQQAAB8A+D8BAAAAJAAAAFAAcgBhAHMAaABhAG4AdABo ACAATgBlAGQAbgBvAG8AcgAAAAIB+T8BAAAAUwAAAAAAAADcp0DIwEIQGrS5CAArL+GCAQAAAAAA AAAvTz1RTE9HSUMvT1U9UUxDTlREL0NOPVJFQ0lQSUVOVFMvQ049UFJBU0hBTlRILk5FRE5PT1IA AB8A+j8BAAAAKgAAAFMAeQBzAHQAZQBtACAAQQBkAG0AaQBuAGkAcwB0AHIAYQB0AG8AcgAAAAAA AgH7PwEAAAAeAAAAAAAAANynQMjAQhAatLkIACsv4YIBAAAAAAAAAC4AAAADAP0/5AQAAAMAGUAA AAAAAwAaQAAAAAADAB1AAAAAAAMAHkAAAAAAHwAwQAEAAAAkAAAAUABSAEEAUwBIAEEATgBUAEgA LgBOAEUARABOAE8ATwBSAAAAHwAxQAEAAAAkAAAAUABSAEEAUwBIAEEATgBUAEgALgBOAEUARABO AE8ATwBSAAAAHwAyQAEAAAAqAAAAaQBwAHMALQBiAG8AdQBuAGMAZQBzAEAAaQBlAHQAZgAuAG8A cgBnAAAAAAAfADNAAQAAACoAAABpAHAAcwAtAHIAZQBxAHUAZQBzAHQAQABpAGUAdABmAC4AbwBy AGcAAAAAAB8AOEABAAAAJAAAAFAAUgBBAFMASABBAE4AVABIAC4ATgBFAEQATgBPAE8AUgAAAB8A OUABAAAABAAAAC4AAAALACkAAAAAAAsAIwAAAAAAAwAGEOvSLwgDAAcQIR4AAAMAEBAAAAAAAwAR EAAAAAAeAAgQAQAAAGUAAABKSFlMSU5HLFdBSFRTSVNUSEVBUkdVTUVOVFRPUlVONDAyMklORElB R01PREUsSUhBVkVUSEVMT0dJQ0lOVEhFQ09ERVRIQU5LU1BSQVNIQU5USC0tLS0tT1JJR0lOQUxN RVNTAAAAAAIBfwABAAAAPwAAADxGRTU2MTBCRjRGNDdDQTQ5QkE0NjQ0MDdBNEQzRUNENjAxRTAz MTNBQEFWRVhDSDAyLnFsb2dpYy5vcmc+AACcYQ== ------_=_NextPart_001_01C5922C.0128E74A Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips ------_=_NextPart_001_01C5922C.0128E74A-- From ips-bounces@ietf.org Tue Jul 26 21:07:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxaNw-0000ky-Hh; Tue, 26 Jul 2005 21:07:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxaNu-0000kR-Lb for ips@megatron.ietf.org; Tue, 26 Jul 2005 21:06:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09610 for ; Tue, 26 Jul 2005 21:06:56 -0400 (EDT) Received: from palrel11.hp.com ([156.153.255.246]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dxat4-0000HG-CB for ips@ietf.org; Tue, 26 Jul 2005 21:39:10 -0400 Received: from rosemail.rose.hp.com (rosemail.rose.hp.com [15.43.209.160]) by palrel11.hp.com (Postfix) with ESMTP id 352BF808C for ; Tue, 26 Jul 2005 18:06:49 -0700 (PDT) Received: from [127.0.0.1] (sindhu.americas.hpqcorp.net [16.93.44.53]) by rosemail.rose.hp.com (Postfix) with ESMTP id 7541681D2 for ; Tue, 26 Jul 2005 14:17:25 -0700 (PDT) Message-ID: <42E6DE24.3020602@rose.hp.com> Date: Tue, 26 Jul 2005 18:06:44 -0700 From: "Mallikarjun C." User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IPS References: <42D80408.1060108@rose.hp.com> <42DD9271.4010706@rose.hp.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Content-Transfer-Encoding: 7bit Subject: [Ips] Re: ISID and Discovery Re: draft-ietf-ips-iscsi-impl-guide-00.txt X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org Bob, Many thanks for the URLs to old threads and the summary. I reviewed them all. Your summary looks OK to me, I will incorporate this issue into the next revision with some editorial changes. >I therefore wrote in the summary that the Portal > Group Tag component of the I_T nexus identifier was also NULL or "" > in this case. I agree. That's why I was commenting in the past email thread that it's really a session to the Network Entity - with no node and no TPG affiliation. > c) At any time, a single target should have at most one discovery > session with the I_T nexus identifier: > (iSCSI Initiator Name + 'i' + ISID + "" + 't' + "") The implication of this, to be explicit, is that a discovery session reinstates another discovery session if both implied - by omitting - the NULL target name with the same Initiator Name & ISID. Thanks! Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture StorageWorks Division Hewlett-Packard MS 5668 Roseville CA 95747 cbm [at] rose.hp.com Robert D. Russell wrote: > Mallikarjun: > >> Yes, I will certainly consider. Please send me a URL to a decent >> summary email in that thread. Or please do me a favor by writing up >> one if a summary doesn't exist. >> > > Attached below is my draft of a proposed clarification > based on two long threads that appeared on the reflector in > August, 2004, both having to do with the uniqueness of iscsi > sessions and I_T nexus identifiers. > > The first thread appeared under the heading: > "ISCSI Name and Multi-Port Targets", starting with > http://www.spinics.net/lists/iscsi/msg10052.html > > The second thread appeared under two headings: > "final resolution of ISID rule as it applies to discovery sessions", > starting with http://www.spinics.net/lists/iscsi/msg10129.html > and (note the missing space) > "final resolution of ISID rule as it applies to discoverysessions", > starting with http://www.spinics.net/lists/iscsi/msg10142.html > > In writing this summary I realized that the "final resolution of the > ISID rule for discovery sessions" thread never mentioned what to do > about the Portal Group Tag in the I_T nexus identifier when the > Target Name was omitted during the first login request of a > discovery session. It seems to me that without the Target Name > no Portal Group Tag can be uniquely determined, even based on the > IP address and port number used by the initiator to connect to the > target (since that IP address and port number can belong to different > portal groups under different Target Names used by the same target > network entity). I therefore wrote in the summary that the Portal > Group Tag component of the I_T nexus identifier was also NULL or "" > in this case. > > Comments? > > Thanks, > > Bob Russell > InterOperability Lab > University of New Hampshire > rdr@iol.unh.edu > 603-862-3774 > > --------------------------------------------------------------------------- > > Uniqueness of iSCSI sessions > ---------------------------- > > According to Section 3.4.2 c) of RFC 3720, the SCSI "I_T nexus" defined > in SAM2 is equivalent to the iSCSI session defined in RFC 3720. > This section also defines the "I_T nexus identifier" to be the tuple: > > (iSCSI Initiator Name + 'i' + ISID, > iSCSI Target Name + 't' + Portal Group Tag) > > where both the iSCSI Initiator Name and iSCSI Target Name are > intended to be world-wide unique names. > > Therefore, two such tuples with a difference in any one of the four > components will identify two different I_T nexi and therefore two > different iSCSI sessions. This has several implications: > > > 1) An initiator may use the same iSCSI Initiator Name and ISID when > establishing different (i.e., unique) sessions with different targets > and/or different portal groups. This behavior is discussed in section > 9.1.1 and is, in fact, encouraged as conservative reuse of ISIDs. > > > 2) According to section 9.1.2, there is intended to be just one iSCSI > Initiator Name per operating system image on a machine. Therefore, > when multiple initiators are running on the same operating system > image on the same machine, they should all share the same > iSCSI Initiator Name and manage the ISID name space between them > to avoid conflicts (e.g., by appropriate partitioning). > > > 3) The I_T nexus identifier applies to all session types (normal and > discovery). When an initiator supplies a Target Name on the first > login request of a discovery session, there is a Portal Group Tag > associated with that Target Name and formation of the I_T nexus > identifier is straight-forward. However, according to section > 3.2.6.1, the initiator MAY omit supplying the iSCSI Target Name on > the first login request of a discovery session, in which case the > I_T nexus identifier is constructed by supplying an empty value > (e.g., NULL or "") for both the iSCSI Target Name and the Portal > Group Tag components. The consequences of this are: > > a) The I_T nexus identifier of a discovery session established WITH a > Target Name MAY match the I_T nexus identifier of a normal session, > in which case such a discovery session will force reinstatement of > an existing normal session (and vice versa) as defined in section > 5.3.1. > > b) The I_T nexus identifier of a discovery session established WITHOUT > a Target Name NEVER matches the I_T nexus identifier of a normal > session, so that such a discovery session NEVER forces reinstatement > of an existing normal session (and vice versa) as defined in section > 5.3.1. > > c) At any time, a single target should have at most one discovery > session with the I_T nexus identifier: > (iSCSI Initiator Name + 'i' + ISID + "" + 't' + "") _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Tue Jul 26 21:38:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxasI-0001YF-83; Tue, 26 Jul 2005 21:38:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxasG-0001VX-9T for ips@megatron.ietf.org; Tue, 26 Jul 2005 21:38:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10918 for ; Tue, 26 Jul 2005 21:38:18 -0400 (EDT) Received: from mononoke.wasabisystems.com ([66.173.145.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxbNP-000131-J0 for ips@ietf.org; Tue, 26 Jul 2005 22:10:32 -0400 Received: from [10.0.0.10] (h-66-166-188-91.sndacagl.covad.net [66.166.188.91]) by mononoke.wasabisystems.com (Postfix) with ESMTP id 0E7EE870B8; Tue, 26 Jul 2005 21:38:05 -0400 (EDT) In-Reply-To: References: <42D80408.1060108@rose.hp.com> <42DD9271.4010706@rose.hp.com> Mime-Version: 1.0 (Apple Message framework v622) Message-Id: <9a00dc707c09c8d4e58ac7f8a9f980fb@wasabisystems.com> From: William Studenmund Subject: Re: [Ips] Re: ISID and Discovery Re: draft-ietf-ips-iscsi-impl-guide-00.txt Date: Tue, 26 Jul 2005 18:37:55 -0700 To: "Robert D. Russell" X-Pgp-Agent: GPGMail 1.0 (v30, 10.3) X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: IPS , "Mallikarjun C." 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="===============0736396466==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org --===============0736396466== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-7-239671314" Content-Transfer-Encoding: 7bit --Apple-Mail-7-239671314 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Jul 25, 2005, at 9:27 AM, Robert D. Russell wrote: > Mallikarjun: > >> Yes, I will certainly consider. Please send me a URL to a decent >> summary email in that thread. Or please do me a favor by writing up >> one if a summary doesn't exist. >> > > Attached below is my draft of a proposed clarification > based on two long threads that appeared on the reflector in > August, 2004, both having to do with the uniqueness of iscsi > sessions and I_T nexus identifiers. Thank you for this. > The first thread appeared under the heading: > "ISCSI Name and Multi-Port Targets", starting with > http://www.spinics.net/lists/iscsi/msg10052.html > > The second thread appeared under two headings: > "final resolution of ISID rule as it applies to discovery sessions", > starting with http://www.spinics.net/lists/iscsi/msg10129.html > and (note the missing space) > "final resolution of ISID rule as it applies to discoverysessions", > starting with http://www.spinics.net/lists/iscsi/msg10142.html > > In writing this summary I realized that the "final resolution of the > ISID rule for discovery sessions" thread never mentioned what to do > about the Portal Group Tag in the I_T nexus identifier when the > Target Name was omitted during the first login request of a > discovery session. It seems to me that without the Target Name > no Portal Group Tag can be uniquely determined, even based on the > IP address and port number used by the initiator to connect to the > target (since that IP address and port number can belong to different > portal groups under different Target Names used by the same target > network entity). I therefore wrote in the summary that the Portal > Group Tag component of the I_T nexus identifier was also NULL or "" > in this case. > > Comments? My one thought would be to leave the handling of TPGT to the implementation. While I do not think your suggestion is unreasonable, I think it would also be reasonable for the target implementation to be able to associate a unique TPGT to the session, based on the IP address and port number used to connect to the target network entity. If that is the case, I would like us to permit such a target to handle the session uniqueness rules using the given TPGT. I believe that it is reasonable that a target MUST always use the same TPGT for discovery sessions for an initiator connecting to a given portal (IP addr and TCP port), for a given configuration. Thus a target has a choice of ""/NULL or some valid TPGT value, but regardless of what it does it must keep doing the same, until its configuration changes. That way session reinstatement will work correctly. Also, will implementations deal with an omitted TPGT value ("key=\000")? Perhaps a better solution is to use the value 0 (zero) for the case where we do not have a valid TPGT value. According to SAM2, the TPGT is a non-zero two-byte integer, so 0 is outside the valid value space. Take care, Bill --Apple-Mail-7-239671314 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFC5uV5DJT2Egh26K0RAgZKAJsF289S2GR3ti2EJb7kNsyah0c7SgCfTL/W CTM2ifdO+lTGuQiq4PF2M1E= =z4S8 -----END PGP SIGNATURE----- --Apple-Mail-7-239671314-- --===============0736396466== 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 --===============0736396466==-- From ips-bounces@ietf.org Wed Jul 27 03:32:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxgPC-00040e-Js; Wed, 27 Jul 2005 03:32:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxgPA-0003zK-Kh for ips@megatron.ietf.org; Wed, 27 Jul 2005 03:32:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03862 for ; Wed, 27 Jul 2005 03:32:36 -0400 (EDT) Received: from volter-fw.ser.netvision.net.il ([212.143.107.30] helo=taurus.voltaire.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxguK-0001aT-KD for ips@ietf.org; Wed, 27 Jul 2005 04:04:54 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="x-user-defined" Content-Transfer-Encoding: quoted-printable Date: Wed, 27 Jul 2005 10:32:26 +0300 Message-ID: Thread-Topic: CHAP_N not necessary for authentication? Thread-Index: AcWSfVY37Ucm22tcTF62JJxbNyVyNA== From: "Dan Bar Dov" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Content-Transfer-Encoding: quoted-printable Subject: [Ips] CHAP_N not necessary for authentication? 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: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org The spec does not specify whether CHAP_N need to match.=20 Should and initiator with the proper CHAP_R response be allowed to = proceed even if CHAP_N is incorrect? Dan Bar Dov =20 _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Wed Jul 27 09:03:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxlZE-00089m-GV; Wed, 27 Jul 2005 09:03:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxlZC-00088F-BV for ips@megatron.ietf.org; Wed, 27 Jul 2005 09:03:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25210 for ; Wed, 27 Jul 2005 09:03:20 -0400 (EDT) Received: from sadr.equallogic.com ([66.155.203.134]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dxm4R-0004FX-QT for ips@ietf.org; Wed, 27 Jul 2005 09:35:41 -0400 Received: from sadr.equallogic.com (localhost.localdomain [127.0.0.1]) by sadr.equallogic.com (8.12.8/8.12.8) with ESMTP id j6RD33ZZ016007 for ; Wed, 27 Jul 2005 09:03:03 -0400 Received: from M31.equallogic.com (M31.equallogic.com [172.16.1.31]) by sadr.equallogic.com (8.12.8/8.12.8) with SMTP id j6RD32Nd016002; Wed, 27 Jul 2005 09:03:02 -0400 Received: from PKONING.equallogic.com ([172.16.1.186]) by M31.equallogic.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 27 Jul 2005 09:03:02 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17127.34308.691000.938289@gargle.gargle.HOWL> Date: Wed, 27 Jul 2005 09:03:00 -0400 From: Paul Koning To: danb@voltaire.com Subject: Re: [Ips] CHAP_N not necessary for authentication? References: X-Mailer: VM 7.07 under 21.4 (patch 10) "Military Intelligence (Windows)" XEmacs Lucid X-OriginalArrivalTime: 27 Jul 2005 13:03:02.0540 (UTC) FILETIME=[856B6CC0:01C592AB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit 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: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org >>>>> "Dan" == Dan Bar Dov writes: Dan> The spec does not specify whether CHAP_N need to match. Match what? Dan> Should and initiator with the proper CHAP_R response be allowed Dan> to proceed even if CHAP_N is incorrect? I'm not sure what you mean. CHAP authenticates a CHAP user name -- which is CHAP_N. The response proves that the sender knows the secret associated with that name. That name has no relationship to the initiator name. So if you're doing access control with CHAP authentication, you'd put CHAP names into your access control entries. paul _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Wed Jul 27 11:08:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxnVo-0003rO-SI; Wed, 27 Jul 2005 11:08:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxnVl-0003rG-Fa for ips@megatron.ietf.org; Wed, 27 Jul 2005 11:07:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05623 for ; Wed, 27 Jul 2005 11:07:54 -0400 (EDT) Received: from io.iol.unh.edu ([132.177.123.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dxo11-0008OS-N6 for ips@ietf.org; Wed, 27 Jul 2005 11:40:17 -0400 Received: from io.iol.unh.edu (localhost.localdomain [127.0.0.1]) by io.iol.unh.edu (8.13.4/8.13.4) with ESMTP id j6RF7ZpO000950; Wed, 27 Jul 2005 11:07:36 -0400 Received: from localhost (rdr@localhost) by io.iol.unh.edu (8.13.4/8.13.4/Submit) with ESMTP id j6RF7Wm6000944; Wed, 27 Jul 2005 11:07:33 -0400 Date: Wed, 27 Jul 2005 11:07:32 -0400 (EDT) From: "Robert D. Russell" To: William Studenmund Subject: Re: [Ips] Re: ISID and Discovery Re: draft-ietf-ips-iscsi-impl-guide-00.txt In-Reply-To: <9a00dc707c09c8d4e58ac7f8a9f980fb@wasabisystems.com> Message-ID: References: <42D80408.1060108@rose.hp.com> <42DD9271.4010706@rose.hp.com> <9a00dc707c09c8d4e58ac7f8a9f980fb@wasabisystems.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-UNH-IOL-MailScanner-Information: Please contact systems@iol.unh.edu for more information X-UNH-IOL-MailScanner: Found to be clean X-UNH-IOL-MailScanner-From: rdr@io.iol.unh.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: IPS , "Mallikarjun C." 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: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org Bill: A couple of comments on your idea to leave it up to the target to set the TPGT on a discovery session when no TargetName is given. 1. You mentioned that the TPGT comes from SAM2 -- I thought the TPGT was invented by iSCSI as a means of allowing the target to specify the grouping of (IP-address, port-number) pairs (i.e., of Network Portals), and had no visibility in SCSI (SAM2). 2. You mentioned that a TPGT of 0 was somehow a special case. According to RFC3720, section 12.9, the value is a 16-bit-binary-value, with 0 not given any special meaning. Also in section 3.4.1 e) it says "Portal Groups are identified within an iSCSI Node by a portal group tag, a simple unsigned-integer between 0 and 65535." This also implies that a value of 0 is nothing special, and in particular does not indicate "no portal group". 3. If the target is allowed to assign a TPGT to a discovery session when there is no TargetName given, then it would be possible for there to be several simultaneously active "unnamed" discovery sessions to the same initiator (InitiatorName + ISID) -- one for each possible portal group. This seems to be contrary to the idea expressed by Mallikarjun that an "unnamed" discovery session is intended to be to the "Network Entity", and therefore there can/should be only one of them (i.e., a second unnamed discovery session to the same Network Entity would log out the first unnamed discovery session that that Network Entity). Comments? Thanks, Bob Russell InterOperability Lab University of New Hampshire rdr@iol.unh.edu 603-862-3774 > On Jul 25, 2005, at 9:27 AM, Robert D. Russell wrote: > >> Mallikarjun: >> >>> Yes, I will certainly consider. Please send me a URL to a decent summary >>> email in that thread. Or please do me a favor by writing up one if a >>> summary doesn't exist. >>> >> >> Attached below is my draft of a proposed clarification >> based on two long threads that appeared on the reflector in >> August, 2004, both having to do with the uniqueness of iscsi >> sessions and I_T nexus identifiers. > > Thank you for this. > >> The first thread appeared under the heading: >> "ISCSI Name and Multi-Port Targets", starting with >> http://www.spinics.net/lists/iscsi/msg10052.html >> >> The second thread appeared under two headings: >> "final resolution of ISID rule as it applies to discovery sessions", >> starting with http://www.spinics.net/lists/iscsi/msg10129.html >> and (note the missing space) >> "final resolution of ISID rule as it applies to discoverysessions", >> starting with http://www.spinics.net/lists/iscsi/msg10142.html >> >> In writing this summary I realized that the "final resolution of the >> ISID rule for discovery sessions" thread never mentioned what to do >> about the Portal Group Tag in the I_T nexus identifier when the >> Target Name was omitted during the first login request of a >> discovery session. It seems to me that without the Target Name >> no Portal Group Tag can be uniquely determined, even based on the >> IP address and port number used by the initiator to connect to the >> target (since that IP address and port number can belong to different >> portal groups under different Target Names used by the same target >> network entity). I therefore wrote in the summary that the Portal >> Group Tag component of the I_T nexus identifier was also NULL or "" >> in this case. >> >> Comments? > > My one thought would be to leave the handling of TPGT to the implementation. > While I do not think your suggestion is unreasonable, I think it would also > be reasonable for the target implementation to be able to associate a unique > TPGT to the session, based on the IP address and port number used to connect > to the target network entity. If that is the case, I would like us to permit > such a target to handle the session uniqueness rules using the given TPGT. > > I believe that it is reasonable that a target MUST always use the same TPGT > for discovery sessions for an initiator connecting to a given portal (IP addr > and TCP port), for a given configuration. Thus a target has a choice of > ""/NULL or some valid TPGT value, but regardless of what it does it must keep > doing the same, until its configuration changes. That way session > reinstatement will work correctly. > > Also, will implementations deal with an omitted TPGT value ("key=\000")? > Perhaps a better solution is to use the value 0 (zero) for the case where we > do not have a valid TPGT value. According to SAM2, the TPGT is a non-zero > two-byte integer, so 0 is outside the valid value space. > > Take care, > > Bill > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Wed Jul 27 13:26:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxpfZ-0007So-BL; Wed, 27 Jul 2005 13:26:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxpfW-0007Sg-3z for ips@megatron.ietf.org; Wed, 27 Jul 2005 13:26:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15506 for ; Wed, 27 Jul 2005 13:26:06 -0400 (EDT) Received: from mononoke.wasabisystems.com ([66.173.145.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxqAo-0004VT-1J for ips@ietf.org; Wed, 27 Jul 2005 13:58:30 -0400 Received: from [10.0.0.10] (h-66-166-188-91.sndacagl.covad.net [66.166.188.91]) by mononoke.wasabisystems.com (Postfix) with ESMTP id BF2748709D; Wed, 27 Jul 2005 13:25:54 -0400 (EDT) In-Reply-To: References: <42D80408.1060108@rose.hp.com> <42DD9271.4010706@rose.hp.com> <9a00dc707c09c8d4e58ac7f8a9f980fb@wasabisystems.com> Mime-Version: 1.0 (Apple Message framework v622) Message-Id: <5bed23bfdf7ace05d6e538adb57c0381@wasabisystems.com> From: William Studenmund Subject: Re: [Ips] Re: ISID and Discovery Re: draft-ietf-ips-iscsi-impl-guide-00.txt Date: Wed, 27 Jul 2005 10:25:45 -0700 To: "Robert D. Russell" X-Pgp-Agent: GPGMail 1.0 (v30, 10.3) X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Cc: IPS , "Mallikarjun C." 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="===============1460630573==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org --===============1460630573== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-10-296540969" Content-Transfer-Encoding: 7bit --Apple-Mail-10-296540969 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Jul 27, 2005, at 8:07 AM, Robert D. Russell wrote: > Bill: > A couple of comments on your idea to leave it up to the target > to set the TPGT on a discovery session when no TargetName is > given. > > 1. You mentioned that the TPGT comes from SAM2 -- I thought the TPGT > was invented by iSCSI as a means of allowing the target to specify > the grouping of (IP-address, port-number) pairs (i.e., of Network > Portals), and had no visibility in SCSI (SAM2). We are both right. TPGT is an iSCSI concept. However it is an implementation of a target port identifier, which is a SCSI concept. TPGT is visible to SCSI, in the parts that need to know about transport-specific information. Or at least that's what I understood TPGT to be. A target device has to have a port identifier, which is part of the I_T nexus rule. For iSCSI, we use TPGT for that, thus TPGT == Target port identifier. > 2. You mentioned that a TPGT of 0 was somehow a special case. > According to RFC3720, section 12.9, the value is a > 16-bit-binary-value, with 0 not given any special meaning. > Also in section 3.4.1 e) it says "Portal Groups are identified > within an iSCSI Node by a portal group tag, a simple > unsigned-integer > between 0 and 65535." This also implies that a value of 0 is > nothing special, and in particular does not indicate "no portal > group". You are correct. However please see SAM 2 or SAM 3. For SAM 2r23, Table A.4 on page 117 and Table A.6 on page 118 both mention, in foot notes, that the TPGT is a non-zero two-byte integer. SAM 3 (rev 13a) is a bit more verbose. In Table A.3 (page 121) and Table A.5 (page 123), the Target Portal Group Tag is described as a UTF-8 encode hexadecimal representation of a non-zero two-byte integer. Note: this is how it is expressed while naming SCSI entities, not how it is expressed during iSCSI negotiation. So while the RFC permits zero, SAM does not. We should probably address this issue in its own right in this draft. :-) As Target Portal IDs have been non-zero for longer than iSCSI has been around, we should probably disallow 0. However we still have the question which inspired me to suggest 0. RFC 3720 states that the key "TargetPortalGroupTag" has a value which is an integer. Do we know how existing implementations will react if we don't give a valid value? I actually think we'd do better to skip the TPGT rather than send an ill-formed one. > 3. If the target is allowed to assign a TPGT to a discovery session > when > there is no TargetName given, then it would be possible for there to > be several simultaneously active "unnamed" discovery sessions to the > same initiator (InitiatorName + ISID) -- one for each possible > portal > group. This seems to be contrary to the idea expressed by > Mallikarjun > that an "unnamed" discovery session is intended to be to the > "Network Entity", and therefore there can/should be only one of them > (i.e., a second unnamed discovery session to the same Network Entity > would log out the first unnamed discovery session that that Network > Entity). Well, what does it hurt to permit multiple ones? Put another way, why do we NEED to prevent multiple ones? As an example where it helps to be flexible, consider a system where iSCSI processing is handled by PCI add-in cards, and the host system only handles SCSI-level issues. If we permit implementations, at their discretion, to retain the TPGT behavior, then each add-in card just has its own TPGT and all is well. All iSCSI processing happens only in a card, and the host does SCSI. Now if we require there be only one discovery session per network entity, that means that these iSCSI offload cards have to be able to communicate the existence of a discovery session to the host, and the host has to coordinate it between them. Thus when a discovery session happens on one card, it has to ensure that any discovery sessions on other cards get logged out. That sounds like a lot of hassle. So while I don't disagree with the idea that we only intend there to be one discovery session per network entity, to actively enforce that can be a lot of pain to an implementation (or implementations, as in my example the iSCSI offload may come from multiple vendors who are not the vendor of the underlying system). Since I don't see a need for this pain, I think it would be easier to permit a target to retain the TPGT behavior (send a valid value) if it wishes. As before, I believe that a target should stick with whichever behavior it chooses. Regardless of the TPGT value sent, the session ID rules will still be in effect. If two different portals (IP addr/TCP port) return the same TPGT value to an initiator, logging into one of them with a new discovery session will of course log out the other one. If two different portals return the "not really a TPGT" TPGT value, a new session to one of them will trigger session reinstatement on the other. Take care, Bill --Apple-Mail-10-296540969 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFC58OfDJT2Egh26K0RAnbmAJ9FdWWBAsr33SkbdUrt2JE+52p23gCfYYWp DR/8M3JuuwnIMubMxC+IfSo= =LTy6 -----END PGP SIGNATURE----- --Apple-Mail-10-296540969-- --===============1460630573== 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 --===============1460630573==-- From ips-bounces@ietf.org Wed Jul 27 19:45:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxvb2-0006nF-JH; Wed, 27 Jul 2005 19:45:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxvb0-0006n2-DZ for ips@megatron.ietf.org; Wed, 27 Jul 2005 19:45:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17985 for ; Wed, 27 Jul 2005 19:45:48 -0400 (EDT) Received: from palrel10.hp.com ([156.153.255.245]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dxw6J-0007n2-K2 for ips@ietf.org; Wed, 27 Jul 2005 20:18:16 -0400 Received: from rosemail.rose.hp.com (rosemail.rose.hp.com [15.43.209.160]) by palrel10.hp.com (Postfix) with ESMTP id 734605415 for ; Wed, 27 Jul 2005 16:45:01 -0700 (PDT) Received: from [127.0.0.1] (sindhu.americas.hpqcorp.net [16.93.44.53]) by rosemail.rose.hp.com (Postfix) with ESMTP id 926757FF2 for ; Wed, 27 Jul 2005 12:55:33 -0700 (PDT) Message-ID: <42E81C7E.5020907@rose.hp.com> Date: Wed, 27 Jul 2005 16:45:02 -0700 From: "Mallikarjun C." User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IPS Subject: Re: [Ips] Re: ISID and Discovery Re: draft-ietf-ips-iscsi-impl-guide-00.txt References: <42D80408.1060108@rose.hp.com> <42DD9271.4010706@rose.hp.com> <9a00dc707c09c8d4e58ac7f8a9f980fb@wasabisystems.com> <5bed23bfdf7ace05d6e538adb57c0381@wasabisystems.com> In-Reply-To: <5bed23bfdf7ace05d6e538adb57c0381@wasabisystems.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b8f3559805f7873076212d6f63ee803e Content-Transfer-Encoding: 7bit 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: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org Bill, > TPGT is visible to SCSI, Only as a substring in a longer string. > So while the RFC permits zero, SAM does not. Thanks for pointing this out. Rob Elliott though noted the following offline on my prompt: a) That is just an informative annex in SAM-nn, not normative, so other documents can override it, and b) The existing SAM-nn text is historical (until iSCSI rev13 or so, we required it to be between 1-65535). Rob also volunteered to move a T10 proposal to sync up the SAM-4 wording to RFC 3720 (thanks Rob!). > We should probably address this issue in its own right in this draft. I agree. Per above comments, I will note in the next revision of Implementer's guide that zero-value is expressly allowed. >I actually think we'd do better to skip the TPGT > rather than send an ill-formed one. Are you referring to the case when TargetName is not given by the initiator? If so, I agree. TPGT is not required to be returned per RFC 3720. When TargetName is specified in the Login Request though, there's no choice wrt returning TPGT. > Now if we require there be only one discovery session per network > entity,... Only for a given InitiatorName-ISID combination. >I think it would be easier to permit a target to retain the TPGT > behavior (send a valid value) if it wishes Unfortunately though, by definition, it will be invalid in the absence of a TargetName context. Section 3.4.1 in RFC 3720 says the following: "A Portal Group defines a set of Network Portals within an iSCSI Node...." and "Portal Groups are identified within an iSCSI Node by a portal group tag,...." When a TargetName is not specified for a discovery session, there isn't an iSCSI Node context, a TPGT thus is not meaningful and cannot be inferred. While TPGT is not required to be returned per RFC 3720, I therefore propose that it must not be returned in this case. So a "workaround" we have been implying in our discussions so far is that there be a No-Name (aka NULL aka "") TPGT that identifies this invalid "thing" (that isn't really a portal group). Since one cannot distinguish by definition between multiple No-Name "things", an application of the ISID RULE argues for a discovery session reinstatement once the InitiatorName-ISID tuple matches. I personally think it is easier to implement since the same ISID RULE is used to manage discovery and normal sessions alike (you can map your implmentation's TPGT for the "No-Name thing" to index 0, and start your valid TPGTs from index 1 - AFAICT, that's legal). >If we permit implementations, at their > discretion, to retain the TPGT behavior, then each add-in card just has > its own TPGT and all is well. All iSCSI processing happens only in a > card, and the host does SCSI. I am not sure such a functionality partition can satisfy the following in Appendix D of RFC 3720: "In a discovery session, a target MUST return all path information (target name and IP address-port pairs and portal group tags) for the targets on the target network entity which the requesting initiator is authorized to access." Thanks. Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture StorageWorks Division Hewlett-Packard MS 5668 Roseville CA 95747 cbm [at] rose.hp.com William Studenmund wrote: > On Jul 27, 2005, at 8:07 AM, Robert D. Russell wrote: > >> Bill: >> A couple of comments on your idea to leave it up to the target >> to set the TPGT on a discovery session when no TargetName is >> given. >> >> 1. You mentioned that the TPGT comes from SAM2 -- I thought the TPGT >> was invented by iSCSI as a means of allowing the target to specify >> the grouping of (IP-address, port-number) pairs (i.e., of Network >> Portals), and had no visibility in SCSI (SAM2). > > > We are both right. TPGT is an iSCSI concept. However it is an > implementation of a target port identifier, which is a SCSI concept. > TPGT is visible to SCSI, in the parts that need to know about > transport-specific information. > > Or at least that's what I understood TPGT to be. A target device has to > have a port identifier, which is part of the I_T nexus rule. For iSCSI, > we use TPGT for that, thus TPGT == Target port identifier. > >> 2. You mentioned that a TPGT of 0 was somehow a special case. >> According to RFC3720, section 12.9, the value is a >> 16-bit-binary-value, with 0 not given any special meaning. >> Also in section 3.4.1 e) it says "Portal Groups are identified >> within an iSCSI Node by a portal group tag, a simple unsigned-integer >> between 0 and 65535." This also implies that a value of 0 is >> nothing special, and in particular does not indicate "no portal >> group". > > > You are correct. However please see SAM 2 or SAM 3. For SAM 2r23, Table > A.4 on page 117 and Table A.6 on page 118 both mention, in foot notes, > that the TPGT is a non-zero two-byte integer. SAM 3 (rev 13a) is a bit > more verbose. In Table A.3 (page 121) and Table A.5 (page 123), the > Target Portal Group Tag is described as a UTF-8 encode hexadecimal > representation of a non-zero two-byte integer. Note: this is how it is > expressed while naming SCSI entities, not how it is expressed during > iSCSI negotiation. > > So while the RFC permits zero, SAM does not. > > We should probably address this issue in its own right in this draft. > :-) As Target Portal IDs have been non-zero for longer than iSCSI has > been around, we should probably disallow 0. > > > However we still have the question which inspired me to suggest 0. RFC > 3720 states that the key "TargetPortalGroupTag" has a value which is an > integer. Do we know how existing implementations will react if we don't > give a valid value? I actually think we'd do better to skip the TPGT > rather than send an ill-formed one. > >> 3. If the target is allowed to assign a TPGT to a discovery session when >> there is no TargetName given, then it would be possible for there to >> be several simultaneously active "unnamed" discovery sessions to the >> same initiator (InitiatorName + ISID) -- one for each possible portal >> group. This seems to be contrary to the idea expressed by Mallikarjun >> that an "unnamed" discovery session is intended to be to the >> "Network Entity", and therefore there can/should be only one of them >> (i.e., a second unnamed discovery session to the same Network Entity >> would log out the first unnamed discovery session that that Network >> Entity). > > > Well, what does it hurt to permit multiple ones? Put another way, why do > we NEED to prevent multiple ones? > > As an example where it helps to be flexible, consider a system where > iSCSI processing is handled by PCI add-in cards, and the host system > only handles SCSI-level issues. If we permit implementations, at their > discretion, to retain the TPGT behavior, then each add-in card just has > its own TPGT and all is well. All iSCSI processing happens only in a > card, and the host does SCSI. > > Now if we require there be only one discovery session per network > entity, that means that these iSCSI offload cards have to be able to > communicate the existence of a discovery session to the host, and the > host has to coordinate it between them. Thus when a discovery session > happens on one card, it has to ensure that any discovery sessions on > other cards get logged out. > > That sounds like a lot of hassle. > > > So while I don't disagree with the idea that we only intend there to be > one discovery session per network entity, to actively enforce that can > be a lot of pain to an implementation (or implementations, as in my > example the iSCSI offload may come from multiple vendors who are not the > vendor of the underlying system). Since I don't see a need for this > pain, I think it would be easier to permit a target to retain the TPGT > behavior (send a valid value) if it wishes. > > As before, I believe that a target should stick with whichever behavior > it chooses. > > Regardless of the TPGT value sent, the session ID rules will still be in > effect. If two different portals (IP addr/TCP port) return the same TPGT > value to an initiator, logging into one of them with a new discovery > session will of course log out the other one. If two different portals > return the "not really a TPGT" TPGT value, a new session to one of them > will trigger session reinstatement on the other. > > Take care, > > Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Wed Jul 27 21:24:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxx8m-0000Ys-MY; Wed, 27 Jul 2005 21:24:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxx8l-0000Yn-K4 for ips@megatron.ietf.org; Wed, 27 Jul 2005 21:24:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23698 for ; Wed, 27 Jul 2005 21:24:48 -0400 (EDT) Received: from mononoke.wasabisystems.com ([66.173.145.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dxxe8-0001vw-5Y for ips@ietf.org; Wed, 27 Jul 2005 21:57:16 -0400 Received: from [10.0.0.10] (h-66-166-188-91.sndacagl.covad.net [66.166.188.91]) by mononoke.wasabisystems.com (Postfix) with ESMTP id E83FE870BD; Wed, 27 Jul 2005 21:24:39 -0400 (EDT) In-Reply-To: <42E81C7E.5020907@rose.hp.com> References: <42D80408.1060108@rose.hp.com> <42DD9271.4010706@rose.hp.com> <9a00dc707c09c8d4e58ac7f8a9f980fb@wasabisystems.com> <5bed23bfdf7ace05d6e538adb57c0381@wasabisystems.com> <42E81C7E.5020907@rose.hp.com> Mime-Version: 1.0 (Apple Message framework v622) Message-Id: <9e8ad9858bd06593b8d2ecde86f96440@wasabisystems.com> From: William Studenmund Subject: Re: [Ips] Re: ISID and Discovery Re: draft-ietf-ips-iscsi-impl-guide-00.txt Date: Wed, 27 Jul 2005 18:24:32 -0700 To: "Mallikarjun C." X-Pgp-Agent: GPGMail 1.0 (v30, 10.3) X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Cc: IPS 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="===============1329512125==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org --===============1329512125== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-18-325268599" Content-Transfer-Encoding: 7bit --Apple-Mail-18-325268599 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Jul 27, 2005, at 4:45 PM, Mallikarjun C. wrote: > Bill, > > > TPGT is visible to SCSI, > > Only as a substring in a longer string. > > > So while the RFC permits zero, SAM does not. > > Thanks for pointing this out. Rob Elliott though noted the following > offline on my prompt: a) That is just an informative annex in SAM-nn, > not normative, so other documents can override it, and b) The existing > SAM-nn text is historical (until iSCSI rev13 or so, we required it to > be between 1-65535). Rob also volunteered to move a T10 proposal to > sync up the SAM-4 wording to RFC 3720 (thanks Rob!). > > > We should probably address this issue in its own right in this draft. > > I agree. Per above comments, I will note in the next revision of > Implementer's guide that zero-value is expressly allowed. Ok. > >I actually think we'd do better to skip the TPGT > > rather than send an ill-formed one. > > Are you referring to the case when TargetName is not given by the > initiator? If so, I agree. TPGT is not required to be returned per > RFC 3720. > > When TargetName is specified in the Login Request though, there's no > choice wrt returning TPGT. I agree on both counts. > > Now if we require there be only one discovery session per network > > entity,... > > Only for a given InitiatorName-ISID combination. Yes... > >I think it would be easier to permit a target to retain the TPGT > > behavior (send a valid value) if it wishes > > Unfortunately though, by definition, it will be invalid in the absence > of a TargetName context. > > Section 3.4.1 in RFC 3720 says the following: "A Portal Group defines > a set of Network Portals within an iSCSI Node...." and "Portal Groups > are identified within an iSCSI Node by a portal group tag,...." > > When a TargetName is not specified for a discovery session, there > isn't an iSCSI Node context, a TPGT thus is not meaningful and cannot > be inferred. While TPGT is not required to be returned per RFC 3720, > I therefore propose that it must not be returned in this case. Actually I disagree with the above. I think it depends on how the target handles its internal configuration. If the target assigns the same TPGT to all nodes accessible via a portal, then the TPGT can be considered an attribute of the portal, not the node-portal link. I am specifically thinking of the case in draft-ietf-ips-iscsi-mib-10.txt where iscsiTgtPortalNodeIndexOrZero would be zero (Or I think I am, the MIB document has changed since I last studied it). So in that case, the target can always have a TPGT available. And it would be easier to let it just return it, rather than making its return depend on session type. I also like this idea as I have things coded this way and I'd rather not change it if I don't have to. :-) > So a "workaround" we have been implying in our discussions so far is > that there be a No-Name (aka NULL aka "") TPGT that identifies this > invalid "thing" (that isn't really a portal group). Since one cannot > distinguish by definition between multiple No-Name "things", an > application of the ISID RULE argues for a discovery session > reinstatement once the InitiatorName-ISID tuple matches. Yes. While I would rather the target not HAVE to use No-Name, I agree that if it does, then any new discovery session to a "No-Name" portal triggers reinstatement once the InitiatorName-ISID tuple matches. > I personally think it is easier to implement since the same ISID RULE > is used to manage discovery and normal sessions alike (you can map > your implmentation's TPGT for the "No-Name thing" to index 0, and > start your valid TPGTs from index 1 - AFAICT, that's legal). I'm sorry if I was confusing. I have always wanted the same ISID rule to apply. :-) > >If we permit implementations, at their > > discretion, to retain the TPGT behavior, then each add-in card just > has > > its own TPGT and all is well. All iSCSI processing happens only in a > > card, and the host does SCSI. > > I am not sure such a functionality partition can satisfy the following > in Appendix D of RFC 3720: > > "In a discovery > session, a target MUST return all path information (target name and > IP address-port pairs and portal group tags) for the targets on the > target network entity which the requesting initiator is authorized to > access." True. I guess my thought was that this can be handled by either special-casing SendTargets processing, or uploading a config to each card. Said config would include both nodes served by the card and nodes served by other cards. Either way, there is no need for card-coordination during the middle of login processing. Take care, Bill --Apple-Mail-18-325268599 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFC6DPXDJT2Egh26K0RAqDjAKCVKOPLQSwvNdHSNHAT4KRqOc+TFQCfQ/6y OSWSlXnMemhctt2B+SfCjpg= =NcQU -----END PGP SIGNATURE----- --Apple-Mail-18-325268599-- --===============1329512125== 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 --===============1329512125==-- From ips-bounces@ietf.org Thu Jul 28 11:37:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyAS0-0007xR-1I; Thu, 28 Jul 2005 11:37:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyARy-0007xM-W2 for ips@megatron.ietf.org; Thu, 28 Jul 2005 11:37:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06028 for ; Thu, 28 Jul 2005 11:37:32 -0400 (EDT) Received: from wproxy.gmail.com ([64.233.184.207]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DyAxS-0000ih-HB for ips@ietf.org; Thu, 28 Jul 2005 12:10:07 -0400 Received: by wproxy.gmail.com with SMTP id i30so419765wra for ; Thu, 28 Jul 2005 08:37:22 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=nrUjETW/01MYQsyfWOrEMtohFAycKtPcviVx9JMCCX5xqc1uOCK8gBomYlpr80BLAq6d11Q8o8lnEX1D+WNr+Tr4HE5LeUhXRG7fgFoTBvrpgABKt20Xwm6jNnc6PatJSMwdMZxKQb3OJp+eB5Q9pHOSd4fcZdcldJ9txJaXfZY= Received: by 10.54.99.7 with SMTP id w7mr842345wrb; Thu, 28 Jul 2005 08:37:22 -0700 (PDT) Received: by 10.54.15.44 with HTTP; Thu, 28 Jul 2005 08:37:22 -0700 (PDT) Message-ID: <8320074d05072808373c22c5c2@mail.gmail.com> Date: Thu, 28 Jul 2005 21:07:22 +0530 From: Rohan Sen To: ips@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: quoted-printable Subject: [Ips] Few queries related to RFC3720 X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Rohan Sen List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org Hello, To what value should the Initiator Task Tag (ITT) field of aTask Management Response PDU be set ? Should it be the Ref Task Tag of the Task Management Request or the ITT of the Task Management Request ? ---------------------------------------------------------------------------= ------------------------------------------------------------ What should we expect from a Target as Reject Reason if it receives a Logout Request with non zero length. Should the reason be Protocol Error or should it be Invalid PDU Field ? ---------------------------------------------------------------------------= ------------------------------------------------------------ Is there any other resource on ISCSI where I can get a simpler description related to connection reinstatement ? I am finding it quite difficult to understand it from the RFC. Any help on these above topic would be highly appreciated. --=20 thanks, Rohan Sen _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Fri Jul 29 21:01:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dyfjg-0002wZ-Gq; Fri, 29 Jul 2005 21:01:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dyfjd-0002wU-Mq for ips@megatron.ietf.org; Fri, 29 Jul 2005 21:01:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21613 for ; Fri, 29 Jul 2005 21:01:51 -0400 (EDT) Received: from palrel11.hp.com ([156.153.255.246]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DygFP-0004c4-Hg for ips@ietf.org; Fri, 29 Jul 2005 21:34:43 -0400 Received: from rosemail.rose.hp.com (rosemail.rose.hp.com [15.43.209.160]) by palrel11.hp.com (Postfix) with ESMTP id ECC084AB2 for ; Fri, 29 Jul 2005 18:01:51 -0700 (PDT) Received: from [127.0.0.1] (sindhu.americas.hpqcorp.net [16.93.44.53]) by rosemail.rose.hp.com (Postfix) with ESMTP id 22248825D for ; Fri, 29 Jul 2005 14:12:15 -0700 (PDT) Message-ID: <42EAD17E.5040703@rose.hp.com> Date: Fri, 29 Jul 2005 18:01:50 -0700 From: "Mallikarjun C." User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IPS Subject: Re: [Ips] Re: ISID and Discovery Re: draft-ietf-ips-iscsi-impl-guide-00.txt References: <42D80408.1060108@rose.hp.com> <42DD9271.4010706@rose.hp.com> <9a00dc707c09c8d4e58ac7f8a9f980fb@wasabisystems.com> <5bed23bfdf7ace05d6e538adb57c0381@wasabisystems.com> <42E81C7E.5020907@rose.hp.com> <9e8ad9858bd06593b8d2ecde86f96440@wasabisystems.com> In-Reply-To: <9e8ad9858bd06593b8d2ecde86f96440@wasabisystems.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: 7bit 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: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org OK, I see two options in dealing with TPGTs. I sketched out the options and respective implications below as I see them. Since I plan to mandate one of the two based on the list feedback in the Implementer's guide, please review carefully - your initiator, target or NIC *may be* affected. I personally am leaning towards Option A because I see it's closest to RFC 3720 semantics and would require no new conceptual additions. Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture StorageWorks Division Hewlett-Packard MS 5668 Roseville CA 95747 cbm [at] rose.hp.com Options: A. TPGTs are always Node-scoped. If Node name isn't specified in the discovery Login Request PDU, TPGT is meaningless and can't be inferred (or inferred to be invalid). B. TPGTs are always Node-scoped. If Node name isn't specified in the discovery Login Request PDU, a special "No-Name" iSCSI Node is implied. This No-Name iSCSI Node has its own TPGT numbering space - one tag for each physically possible portal group - and thus the TPGT can be inferred. Implications - Option A: 1. There can only be one no-named discovery session to a Network Entity with a given InitiatorName-ISID combination. A new no-named discovery session reinstates the first. If this is your current behavior, speak up. 2. An initiator doing parallel discovery probing of multiple IP addresses using a generic InitiatorName-ISID tuple may see all but one of its probe attempts fail in each set of IP addresses hosted by one Network Entity (if you're doing SLP/iSNS-based discovery, this may be a no-op). 3. To realize the session reinstatement of a no-named discovery session on matching InitiatorName-ISID, target CPU software may have to be involved in Login processing for no-named discovery sessions. Depending on your implementation, it may not all be offloaded to hardware. Option B: 1. There can be multiple no-named discovery sessions to a Network Entity with a given InitiatorName-ISID combination - one for each TPGT of the No-Name Node. A new no-named discovery session reinstates an existing discovery session only if the TPGT matches. If this is your current behavior, speak up. 2. An initiator doing parallel discovery probing of multiple IP addresses using a generic InitiatorName-ISID tuple may have all successful probes, but all such probes of each set of IP addresses hosted by one Network Entity return duplicate discovery data (if you're doing SLP/iSNS-based discovery, this may be a no-op). 3. For some implementations, it is technically feasible to offload the login processing for a no-named discovery session. Target CPU software is not required to be involved (although your code may have other reasons to get involved). 4. Introduces a new notion of a "No-Name" iSCSI Node that must host all physically possible portal groups. No-Name Node is however not a full-fledged Node because TargetPortalGroupTag must not be returned - though it can be inferred - on no-named discovery sessions per RFC 3720, and is limited to hosting only the no-named discovery sessions. _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Fri Jul 29 23:11:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyhlM-0003ZK-H2; Fri, 29 Jul 2005 23:11:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyhlK-0003ZE-KN for ips@megatron.ietf.org; Fri, 29 Jul 2005 23:11:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26400 for ; Fri, 29 Jul 2005 23:11:43 -0400 (EDT) Received: from relay2.mail.twtelecom.net ([216.54.204.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DyiH5-00004z-Bw for ips@ietf.org; Fri, 29 Jul 2005 23:44:37 -0400 Received: from saturn.p3corpnet.pivot3.com (207-114-252-60.gen.twtelecom.net [207.114.252.60]) by relay2.mail.twtelecom.net (Postfix) with ESMTP id 07FA2C1B6 for ; Fri, 29 Jul 2005 22:11:36 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ips] Re: ISID and Discovery Re:draft-ietf-ips-iscsi-impl-guide-00.txt Date: Fri, 29 Jul 2005 22:11:25 -0500 Message-ID: Thread-Topic: [Ips] Re: ISID and Discovery Re:draft-ietf-ips-iscsi-impl-guide-00.txt Thread-Index: AcWUooU+krRdxb+VSxuWJtGV74I7pAADfuEA From: "Galloway, Bill" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Content-Transfer-Encoding: quoted-printable 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: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org Mallikarjun, If I understand you options correctly I would like to see Option B. We have a product that has multiple hot-plug scsi ports. For normal session logins, these separate ports have nothing to coordinate since each is its own portal group. I have no idea how to reinstate a discovery session on one hot-plug port when the same initiator tries to do a discovery login on the other hot-plug port (with a different CPU). One other minor problem with option A is that TPGTs could not be Node-scoped since multiple nodes can live behind a single Network Portal. Bill Galloway > -----Original Message----- > From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On=20 > Behalf Of Mallikarjun C. > Sent: Friday, July 29, 2005 8:02 PM > To: IPS > Subject: Re: [Ips] Re: ISID and Discovery=20 > Re:draft-ietf-ips-iscsi-impl-guide-00.txt >=20 > OK, I see two options in dealing with TPGTs. I sketched out=20 > the options=20 > and respective implications below as I see them. Since I plan to=20 > mandate one of the two based on the list feedback in the=20 > Implementer's=20 > guide, please review carefully - your initiator, target or=20 > NIC *may be*=20 > affected. >=20 > I personally am leaning towards Option A because I see it's=20 > closest to=20 > RFC 3720 semantics and would require no new conceptual additions. >=20 > Mallikarjun >=20 > Mallikarjun Chadalapaka > Networked Storage Architecture > StorageWorks Division > Hewlett-Packard MS 5668 > Roseville CA 95747 > cbm [at] rose.hp.com >=20 >=20 > Options: >=20 > A. TPGTs are always Node-scoped. If Node name isn't specified in the=20 > discovery Login Request PDU, TPGT is meaningless and can't be=20 > inferred=20 > (or inferred to be invalid). >=20 > B. TPGTs are always Node-scoped. If Node name isn't specified in the=20 > discovery Login Request PDU, a special "No-Name" iSCSI Node=20 > is implied.=20 > This No-Name iSCSI Node has its own TPGT numbering space -=20 > one tag for=20 > each physically possible portal group - and thus the TPGT can=20 > be inferred. >=20 > Implications - >=20 > Option A: >=20 > 1. There can only be one no-named discovery session to a=20 > Network Entity=20 > with a given InitiatorName-ISID combination. A new no-named discovery=20 > session reinstates the first. If this is your current=20 > behavior, speak up. >=20 > 2. An initiator doing parallel discovery probing of multiple IP=20 > addresses using a generic InitiatorName-ISID tuple may see=20 > all but one=20 > of its probe attempts fail in each set of IP addresses hosted by one=20 > Network Entity (if you're doing SLP/iSNS-based discovery,=20 > this may be a=20 > no-op). >=20 > 3. To realize the session reinstatement of a no-named=20 > discovery session=20 > on matching InitiatorName-ISID, target CPU software may have to be=20 > involved in Login processing for no-named discovery sessions.=20 > Depending=20 > on your implementation, it may not all be offloaded to hardware. >=20 > Option B: > 1. There can be multiple no-named discovery sessions to a=20 > Network Entity=20 > with a given InitiatorName-ISID combination - one for each=20 > TPGT of the=20 > No-Name Node. A new no-named discovery session reinstates an existing=20 > discovery session only if the TPGT matches. If this is your current=20 > behavior, speak up. >=20 > 2. An initiator doing parallel discovery probing of multiple IP=20 > addresses using a generic InitiatorName-ISID tuple may have all=20 > successful probes, but all such probes of each set of IP addresses=20 > hosted by one Network Entity return duplicate discovery data=20 > (if you're=20 > doing SLP/iSNS-based discovery, this may be a no-op). >=20 > 3. For some implementations, it is technically feasible to=20 > offload the=20 > login processing for a no-named discovery session. Target=20 > CPU software=20 > is not required to be involved (although your code may have other=20 > reasons to get involved). >=20 > 4. Introduces a new notion of a "No-Name" iSCSI Node that=20 > must host all=20 > physically possible portal groups. No-Name Node is however not a=20 > full-fledged Node because TargetPortalGroupTag must not be returned -=20 > though it can be inferred - on no-named discovery sessions=20 > per RFC 3720,=20 > and is limited to hosting only the no-named discovery sessions. >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips >=20 _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Sun Jul 31 14:26:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzIW4-0005Ua-8Z; Sun, 31 Jul 2005 14:26:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzIW3-0005UV-6d for ips@megatron.ietf.org; Sun, 31 Jul 2005 14:26:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11423 for ; Sun, 31 Jul 2005 14:26:25 -0400 (EDT) From: Black_David@emc.com Received: from mailhub.lss.emc.com ([168.159.2.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzJ29-0000Y7-1T for ips@ietf.org; Sun, 31 Jul 2005 14:59:39 -0400 Received: from mxic2.corp.emc.com (mxic2.corp.emc.com [128.221.12.9]) by mailhub.lss.emc.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id j6VIQAbb003114; Sun, 31 Jul 2005 14:26:11 -0400 (EDT) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Sun, 31 Jul 2005 14:26:10 -0400 Message-ID: To: senrohan@gmail.com, ips@ietf.org Subject: RE: [Ips] Few queries related to RFC3720 Date: Sun, 31 Jul 2005 14:26:05 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.0.3.2, Antispam-Data: 2005.7.31.19 X-PerlMx-Spam: Gauge=, SPAM=0%, Reasons='EMC_BODY_1+ -5, EMC_FROM_00+ 0, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __IMS_MSGID 0, __IMS_MUA 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0' X-Spam-Score: 0.3 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 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: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org > To what value should the Initiator Task Tag (ITT) field of aTask > Management Response PDU be set ? Should it be the Ref Task Tag of the > Task Management Request or the ITT of the Task Management Request ? The latter. The ITT is used by the initiator to match tasks sent to the target with target responses, and hence needs to be set to the ITT of the Task Management Request. If the Task Management Request does something to the referenced task (not always the case), the results of that will be visible via other means (e.g., that task sends a Response with unsuccessful status). > What should we expect from a Target as Reject Reason if it receives a > Logout Request with non zero length. Should the reason be Protocol > Error or should it be Invalid PDU Field ? I presume this asks about an initiator not abiding by this text from RFC 3720: 10.14.2. TotalAHSLength and DataSegmentLength For this PDU TotalAHSLength and DataSegmentLength MUST be 0 The MUST makes this a Protocol Error. Invalid PDU Field is for doing something that is allowed by the protocol but using a bad value as indicated in Note 2 in section 10.17.1 . I think there's some possibility for overlap between Protocol Error and Invalid PDU field, but don't think that should be a major issue, as either reason code in a Reject should be enough to tell the Initiator that it has fouled up, and nothing useful happened as a result. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Sun Jul 31 14:30:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzIa8-00069A-K8; Sun, 31 Jul 2005 14:30:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzIa4-00068y-UY; Sun, 31 Jul 2005 14:30:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11549; Sun, 31 Jul 2005 14:30:35 -0400 (EDT) Received: from mtagate2.de.ibm.com ([195.212.29.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzJ6B-0000iI-95; Sun, 31 Jul 2005 15:03:49 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id j6VIUKeA127228; Sun, 31 Jul 2005 18:30:20 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j6VIUKhG021094; Sun, 31 Jul 2005 20:30:20 +0200 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id j6VIUJi2025833; Sun, 31 Jul 2005 20:30:20 +0200 Received: from d12ml102.megacenter.de.ibm.com (d12ml102.megacenter.de.ibm.com [9.149.166.138]) by d12av04.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j6VIUJXt025830; Sun, 31 Jul 2005 20:30:19 +0200 In-Reply-To: <42EAD17E.5040703@rose.hp.com> To: "Mallikarjun C." Subject: Re: [Ips] Re: ISID and Discovery Re: draft-ietf-ips-iscsi-impl-guide-00.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_M6_06302005 Beta 4NP June 30, 2005 From: Julian Satran Message-ID: Date: Sun, 31 Jul 2005 21:30:19 +0300 X-MIMETrack: Serialize by Router on D12ML102/12/M/IBM(Release 6.5.1| March 5, 2004) at 31/07/2005 21:30:19, Serialize complete at 31/07/2005 21:30:19 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8d89ee9312a95de8ee48d1c94511f1bb Cc: IPS , ips-bounces@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="===============2032132218==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org This is a multipart message in MIME format. --===============2032132218== Content-Type: multipart/alternative; boundary="=_alternative 00649D49C225704F_=" This is a multipart message in MIME format. --=_alternative 00649D49C225704F_= Content-Type: text/plain; charset="US-ASCII" Mallikarjun, Option A was the one considered when iSCSI was written. Bill is talking about an implementation in which TPGT is an entity by its own used by several targets. His parallel with the target port-id illustrates this point. TPGT however was not intended to be a target port-id by itself. Regards, Julo "Mallikarjun C." Sent by: ips-bounces@ietf.org 30-07-05 04:01 To IPS cc Subject Re: [Ips] Re: ISID and Discovery Re: draft-ietf-ips-iscsi-impl-guide-00.txt OK, I see two options in dealing with TPGTs. I sketched out the options and respective implications below as I see them. Since I plan to mandate one of the two based on the list feedback in the Implementer's guide, please review carefully - your initiator, target or NIC *may be* affected. I personally am leaning towards Option A because I see it's closest to RFC 3720 semantics and would require no new conceptual additions. Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture StorageWorks Division Hewlett-Packard MS 5668 Roseville CA 95747 cbm [at] rose.hp.com Options: A. TPGTs are always Node-scoped. If Node name isn't specified in the discovery Login Request PDU, TPGT is meaningless and can't be inferred (or inferred to be invalid). B. TPGTs are always Node-scoped. If Node name isn't specified in the discovery Login Request PDU, a special "No-Name" iSCSI Node is implied. This No-Name iSCSI Node has its own TPGT numbering space - one tag for each physically possible portal group - and thus the TPGT can be inferred. Implications - Option A: 1. There can only be one no-named discovery session to a Network Entity with a given InitiatorName-ISID combination. A new no-named discovery session reinstates the first. If this is your current behavior, speak up. 2. An initiator doing parallel discovery probing of multiple IP addresses using a generic InitiatorName-ISID tuple may see all but one of its probe attempts fail in each set of IP addresses hosted by one Network Entity (if you're doing SLP/iSNS-based discovery, this may be a no-op). 3. To realize the session reinstatement of a no-named discovery session on matching InitiatorName-ISID, target CPU software may have to be involved in Login processing for no-named discovery sessions. Depending on your implementation, it may not all be offloaded to hardware. Option B: 1. There can be multiple no-named discovery sessions to a Network Entity with a given InitiatorName-ISID combination - one for each TPGT of the No-Name Node. A new no-named discovery session reinstates an existing discovery session only if the TPGT matches. If this is your current behavior, speak up. 2. An initiator doing parallel discovery probing of multiple IP addresses using a generic InitiatorName-ISID tuple may have all successful probes, but all such probes of each set of IP addresses hosted by one Network Entity return duplicate discovery data (if you're doing SLP/iSNS-based discovery, this may be a no-op). 3. For some implementations, it is technically feasible to offload the login processing for a no-named discovery session. Target CPU software is not required to be involved (although your code may have other reasons to get involved). 4. Introduces a new notion of a "No-Name" iSCSI Node that must host all physically possible portal groups. No-Name Node is however not a full-fledged Node because TargetPortalGroupTag must not be returned - though it can be inferred - on no-named discovery sessions per RFC 3720, and is limited to hosting only the no-named discovery sessions. _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --=_alternative 00649D49C225704F_= Content-Type: text/html; charset="US-ASCII"
Mallikarjun,

Option A was the one considered when iSCSI was written. Bill is talking about an implementation in which TPGT is an entity by its own used by several targets.
His parallel with the target port-id illustrates this point. TPGT however was not intended to be a target port-id by itself.

Regards,
Julo

OK, I see two options in dealing with TPGTs. I sketched out the options and respective implications below as I see them. Since I plan to mandate one of the two based on the list feedback in the Implementer's guide, please review carefully - your initiator, target or NIC *may be* affected. I personally am leaning towards Option A because I see it's closest to RFC 3720 semantics and would require no new conceptual additions. Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture StorageWorks Division Hewlett-Packard MS 5668 Roseville CA 95747 cbm [at] rose.hp.com Options: A. TPGTs are always Node-scoped. If Node name isn't specified in the discovery Login Request PDU, TPGT is meaningless and can't be inferred (or inferred to be invalid). B. TPGTs are always Node-scoped. If Node name isn't specified in the discovery Login Request PDU, a special "No-Name" iSCSI Node is implied. This No-Name iSCSI Node has its own TPGT numbering space - one tag for each physically possible portal group - and thus the TPGT can be inferred. Implications - Option A: 1. There can only be one no-named discovery session to a Network Entity with a given InitiatorName-ISID combination. A new no-named discovery session reinstates the first. If this is your current behavior, speak up. 2. An initiator doing parallel discovery probing of multiple IP addresses using a generic InitiatorName-ISID tuple may see all but one of its probe attempts fail in each set of IP addresses hosted by one Network Entity (if you're doing SLP/iSNS-based discovery, this may be a no-op). 3. To realize the session reinstatement of a no-named discovery session on matching InitiatorName-ISID, target CPU software may have to be involved in Login processing for no-named discovery sessions. Depending on your implementation, it may not all be offloaded to hardware. Option B: 1. There can be multiple no-named discovery sessions to a Network Entity with a given InitiatorName-ISID combination - one for each TPGT of the No-Name Node. A new no-named discovery session reinstates an existing discovery session only if the TPGT matches. If this is your current behavior, speak up. 2. An initiator doing parallel discovery probing of multiple IP addresses using a generic InitiatorName-ISID tuple may have all successful probes, but all such probes of each set of IP addresses hosted by one Network Entity return duplicate discovery data (if you're doing SLP/iSNS-based discovery, this may be a no-op). 3. For some implementations, it is technically feasible to offload the login processing for a no-named discovery session. Target CPU software is not required to be involved (although your code may have other reasons to get involved). 4. Introduces a new notion of a "No-Name" iSCSI Node that must host all physically possible portal groups. No-Name Node is however not a full-fledged Node because TargetPortalGroupTag must not be returned - though it can be inferred - on no-named discovery sessions per RFC 3720, and is limited to hosting only the no-named discovery sessions. _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips
--=_alternative 00649D49C225704F_=-- --===============2032132218== 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 --===============2032132218==-- From ips-bounces@ietf.org Sun Jul 31 14:46:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzIph-0000mc-CS; Sun, 31 Jul 2005 14:46:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzIpg-0000mX-Df for ips@megatron.ietf.org; Sun, 31 Jul 2005 14:46:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12305 for ; Sun, 31 Jul 2005 14:46:42 -0400 (EDT) From: Black_David@emc.com Received: from mailhub.lss.emc.com ([168.159.2.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzJLm-0001Vp-Ew for ips@ietf.org; Sun, 31 Jul 2005 15:19:56 -0400 Received: from mxic2.corp.emc.com (mxic2.corp.emc.com [128.221.12.9]) by mailhub.lss.emc.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id j6VIkd3F010649 for ; Sun, 31 Jul 2005 14:46:40 -0400 (EDT) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id