From ips-bounces@ietf.org Fri Dec 01 20:21:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqJZ3-0002UI-VJ; Fri, 01 Dec 2006 20:21:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqJZ2-0002U2-HT for ips@ietf.org; Fri, 01 Dec 2006 20:21:12 -0500 Received: from smtp.hsia.fairmont.com ([142.131.15.59] helo=torntsims03.hsia.fairmont.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GqJZ1-0007m6-58 for ips@ietf.org; Fri, 01 Dec 2006 20:21:12 -0500 Received: from [64.169.29.211] (unverified [64.169.29.211]) by torntsims03.hsia.fairmont.com (Vircom SMTPRS 4.2.425.4) with ESMTP id for ; Fri, 1 Dec 2006 19:57:41 -0500 X-Modus-BlackList: 64.169.29.211=OK;lars.eggert@netlab.nec.de=OK X-Modus-Trusted: 64.169.29.211=NO Received: from lars.local ([142.131.243.207]) by [64.169.29.211] (8.13.6/8.13.6) with ESMTP id kB21KnQk002980 for ; Fri, 1 Dec 2006 17:20:50 -0800 Received: from [127.0.0.1] (localhost [127.0.0.1]) by lars.local (Postfix) with ESMTP id 2ADC529C464 for ; Fri, 1 Dec 2006 16:58:01 -0800 (PST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) X-Priority: 1 Message-Id: From: Lars Eggert Subject: Re: [Ips] ips WG Last Call: iSCSI Implementer's Guide Date: Fri, 1 Dec 2006 16:57:59 -0800 To: ips@ietf.org X-Mailer: Apple Mail (2.752.2) X-Virus-Scanned: ClamAV version 0.88.4, clamav-milter version 0.88.4 on localhost X-Virus-Status: Clean X-Spam-Status: No, score=0.1 required=5.0 tests=AWL,X_PRIORITY_HIGH autolearn=disabled version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on sc1000 X-Spam-Score: 0.1 (/) X-Scan-Signature: e1924de3f9fb68e58c31920136007eb1 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="===============0713558806==" Errors-To: ips-bounces@ietf.org --===============0713558806== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-70--117197471; protocol="application/pkcs7-signature" --Apple-Mail-70--117197471 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Summary: Minor revision needed to address editorial issues. Note: I'm no iSCSI expert, so I cannot fully review the technical recommendations made in this document. I'd like to see at least one other review from someone who has the necessary background before this document moves forward - volunteers? Contains non-ASCII characters, boilerplate issues and other idnits. Please fix. Header should indicate that this document updates 3720 and potentially other IDs (abstract already partially does - good!) It would be good if this document would state for each item it discusses, whether this is a clarification to the original RFCs or a correction, i.e., whether it is merely the original text that can be misunderstood or if there is a technical error in the original text. (It already does in some cases.) INTRODUCTION, paragraph 1: > iSCSI Implementer's Guide Suggest to find a better title, because implementer's guides don't typically update the base specification in a normative way. (Maybe "iSCSI Corrections and Implementer's Guide" or something like that?) Section 2, paragraph 2: > iSCSI implementers are required to reference [RFC3722] and > [RFC3723] in addition to [RFC3720] for mandatory requirements. > In addition, [RFC3721] also contains useful information for > iSCSI implementers. The text in this document, however, updates > and supersedes the text in all the noted RFCs whenever there is > such a question. OK, so this document not only updates 3720, but also 3721, 3722 and 3723? That needs to be stated in the document header and abstract. (Also, 3721 needs to be normatively cited in this case.) Section 3.3, paragraph 0: > 3.3 SCSI Protocol Interface Model for Response Ordering The specification of the fence mechanisms should use RFC2119 terms, especially in Section 3.3.2. Section 3.3.3, paragraph 4: > 2. The TMF Response carrying the mult-task TMF Response on the > issuing session. Nit: s/mult/multi-/ Section 4.1.2, paragraph 4: > b. Should receive any responses that the target may provide > for some tasks among the affected tasks (may process them > as usual because they are guaranteed to have > chronologically originated prior to the TMF response). I'm not sure if "should receive" describes something that should be started in RFC2119 language or not. If that is the intent, a better phrasing should be found. (Also elsewhere in this document where the same phrasing is used.) Section 4.1.2, paragraph 8: > b. MUST wait (concurrent with the wait in Step.a) for all > commands of the affected tasks to be received based on the > CmdSN ordering. SHOULD NOT wait for new commands on > third-party affected sessions - only the instantiated tasks > have to be considered for the purpose of determining the > affected tasks. In the case of target-scoped requests > (i.e. TARGET WARM RESET and TARGET COLD RESET), all the > commands that are not yet received on the issuing session > in the command stream however can be considered to have > been received with no command waiting period - i.e. the > entire CmdSN space up to the CmdSN of the task management > function can be "plugged". Should the sentence starting with "SHOULD NOT" start a new item in this list? Section 4.1.3, paragraph 8: > a. MUST wait for all commands of the affected tasks to be > received based on the CmdSN ordering on the issuing > session. SHOULD NOT wait for new commands on third-party > affected sessions - only the instantiated tasks have to be > considered for the purpose of determining the affected > tasks. In the case of target-scoped requests (i.e. TARGET > WARM RESET and TARGET COLD RESET), all the commands that > are not yet received on the issuing session in the command > stream however can be considered to have been received with > no command waiting period - i.e. the entire CmdSN space up > to the CmdSN of the task management function can be > "plugged". Should the sentence starting with "SHOULD NOT" start a new item in this list? Section 11, paragraph 1: > This draft does not have any specific IANA considerations other than > those already noted in [RFC3720]. Remove text after "considerations" to not confuse IANA. May want to add a note to the RFC Editor to remove this section upon publication. Section 12.1, paragraph 1: > [RFC3720] Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka, > M., and E. Zeidner, "Internet Small Computer Systems > Interface (iSCSI)", RFC 3720, April 2004. Nit: Cited also as [RFC 3720], which confuses idnits. Remove the space in the other citations. Section 12.2, paragraph 1: > [RFC3721] Bakke, M., Hafner, J., Hufferd, J., Voruganti, K., > and M. Krueger, "Internet Small Computer Systems Interface > (iSCSI) Naming and Discovery", RFC 3721, April 2004. See above, if this ID updates 3721, it needs to normatively cite it. Section 12.2, paragraph 2: > [iSER] Ko, M., Chadalapaka, M., Elzur, U., Shah, H., Thaler, > P., J. Hufferd, "iSCSI Extensions for RDMA", IETF > Internet Draft draft-ietf-ips-iser-04.txt (work in > progress), June 2005. Not cited. Section 12.2, paragraph 3: > [RFC2119] Bradner, S. "Key Words for use in RFCs to Indicate > Requirement Levels", BCP 14, RFC 2119, March 1997. ID does not include the required 2119 boilerplate. Also, 2119 should be cited normatively. --Apple-Mail-70--117197471 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKZDCCAwEw ggJqoAMCAQICEBCR/semQl5bz/x3jtiU02YwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDgxNjA5MTU0NloXDTA3MDgxNjA5MTU0 NlowYDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEoMCYGCSqGSIb3DQEJARYZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5kZTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAL/+LXyqufw8ApYnCU24cnZ/H9S7ro4zZYeCqcyFqhwJpTcM8/yX 6Ms+16d2EtIceQS8Bas3GAUR+xfq0QI5dt8uIKM1Uy4trk8AAO0dh23+QTLw7toloArVngGIhUhC OTpVRR1bYfJTwPVpSAY43mbGhSGhwiu5035yKdYJezNWOXmuIO+lvXcD36hc5cU6AzRJkj0LYaFd WHjbfwzGmT7MO60p/7hT+aTv5xvTl/mcwslvm+KhKmJjoMYfSOF99xvuJE/rB7Ho3g6wDoeB2Tip 44Qq8CPmOHtCXzh/tF/bYo+OHStkPTzgPfOuNDMxa0/gAPEyELNL0Eh1/hC2TeMCAwEAAaM2MDQw JAYDVR0RBB0wG4EZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5kZTAMBgNVHRMBAf8EAjAAMA0GCSqG SIb3DQEBBQUAA4GBAHdaTI5TM5wV+LG2WW+CMEmxEyNhaRu3oca9T31HjbfHzvhVJe2fzKt1xBSo +hhCg0qKVFuE7yKxDH975Csq9jVvJJj3oL29RQjPnc3CgQqlMFJKHdJgterPQ+ZiCp05S9rbMhRl 1zxB/x+GvnDFHsXu19gA2dlynrdWN/G1BVWJMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUF ADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBU b3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSsw KQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAw MFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7s vc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV 84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGR MBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUu Y29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCk HjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oL LswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoL gnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHT HUb/XV9lTzCCBBgwggOBoAMCAQICAQAwDQYJKoZIhvcNAQEFBQAwgb8xCzAJBgNVBAYTAkRFMRww GgYDVQQIFBNCYWRlbi1Xw3VlcnR0ZW1iZXJnMRMwEQYDVQQHEwpIZWlkZWxiZXJnMRcwFQYDVQQK Ew5ORUMgRXVyb3BlIEx0ZDEdMBsGA1UECxMUTmV0d29yayBMYWJvcmF0b3JpZXMxGzAZBgNVBAMT EmtvYmUubmV0bGFiLm5lYy5kZTEoMCYGCSqGSIb3DQEJARYZbGFycy5lZ2dlcnRAbmV0bGFiLm5l Yy5kZTAeFw0wNDA2MTgxMTUzMDhaFw0wOTA2MTcxMTUzMDhaMIG/MQswCQYDVQQGEwJERTEcMBoG A1UECBQTQmFkZW4tV8N1ZXJ0dGVtYmVyZzETMBEGA1UEBxMKSGVpZGVsYmVyZzEXMBUGA1UEChMO TkVDIEV1cm9wZSBMdGQxHTAbBgNVBAsTFE5ldHdvcmsgTGFib3JhdG9yaWVzMRswGQYDVQQDExJr b2JlLm5ldGxhYi5uZWMuZGUxKDAmBgkqhkiG9w0BCQEWGWxhcnMuZWdnZXJ0QG5ldGxhYi5uZWMu ZGUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALQ5DCwTzpGu3RmzQY4KxiaQak/BwIW9Wk6K Mg+/V0aiWvlrz7uFdICBGVTKhyWr3F+GxRPCVTWqS9VEPf9A59DI9TFCS3FtraSx+w8ApQei8idb J0Lqu8tTz2O1gYR2dELID5wQH9dxIANt3bP39crgDZzGYxCJilcimFhADEgHAgMBAAGjggEgMIIB HDAdBgNVHQ4EFgQU6Hsv16oYecCFsl07g9gtjPEJo00wgewGA1UdIwSB5DCB4YAU6Hsv16oYecCF sl07g9gtjPEJo02hgcWkgcIwgb8xCzAJBgNVBAYTAkRFMRwwGgYDVQQIFBNCYWRlbi1Xw3VlcnR0 ZW1iZXJnMRMwEQYDVQQHEwpIZWlkZWxiZXJnMRcwFQYDVQQKEw5ORUMgRXVyb3BlIEx0ZDEdMBsG A1UECxMUTmV0d29yayBMYWJvcmF0b3JpZXMxGzAZBgNVBAMTEmtvYmUubmV0bGFiLm5lYy5kZTEo MCYGCSqGSIb3DQEJARYZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5kZYIBADAMBgNVHRMEBTADAQH/ MA0GCSqGSIb3DQEBBQUAA4GBAJfoil3cAX3cUPMFrDdlW9DPMK/+QY8EHPOsnefm77h5CmmY6J+G 5Ydl9vyHxL76Opyg8cZWOOU/k9oVv7AvQ1GmIFqVFyWKQPfEhj+EWjEnUAcI7QDN8XER+U7XRvj6 yYysFgm2Tl30QCGvmESCgYIztCKMG2cLBkEosj2kWBbXMYIDsjCCA64CAQEwdjBiMQswCQYDVQQG EwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEBCR/semQl5bz/x3jtiU02YwCQYFKw4D AhoFAKCCAhEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYxMjAy MDA1NzYwWjAjBgkqhkiG9w0BCQQxFgQUgA8pASIviNMawuEXgMiMuMrkPeowgdYGCSsGAQQBgjcQ BDGByDCBxTCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRlbWJlcmcxEzAR BgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYDVQQLExROZXR3 b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgwJgYJKoZIhvcN AQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMIHYBgsqhkiG9w0BCRACCzGByKCBxTCB vzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRlbWJlcmcxEzARBgNVBAcTCkhl aWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYDVQQLExROZXR3b3JrIExhYm9y YXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgwJgYJKoZIhvcNAQkBFhlsYXJz LmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMA0GCSqGSIb3DQEBAQUABIIBACIroQSCjz5nrERH7dc2 3hDex3mzNUieh4ZscG2dy/AFP533sGPC1MX7bEhE4m7V6mIIL3MYUwj6W/ySA6X28dKvPUV3KIst jLckMSZqtnVjaaJ/EUvh4Wia9ikCTzsBs5q+sHXPbzNl1087uwfOtoawdhqN6kkAITlu8Lo1HGNv GJgecchU6tSAsmA5lv2CpzYXYYhZg7mfL29N13RFwxoQWTlS0dfLq2TWi2c+Tg3v22bPwesazCav eEEfrC3PzOL3mjZE+HciZDygrPgJgnPnZL/bUNLTFCGMyfAZQ3bSQe/Dq0BpTWuf0La7FHc3GBDC ygaPOvWAZfwWmNjoi8kAAAAAAAA= --Apple-Mail-70--117197471-- --===============0713558806== 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 --===============0713558806==-- From ips-bounces@ietf.org Mon Dec 04 02:23:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gr89e-0000Mk-Vb; Mon, 04 Dec 2006 02:22:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gr89d-0000Md-Pf for ips@ietf.org; Mon, 04 Dec 2006 02:22:21 -0500 Received: from bay0-omc1-s1.bay0.hotmail.com ([65.54.246.73]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gr89c-0003DN-HB for ips@ietf.org; Mon, 04 Dec 2006 02:22:21 -0500 Received: from hotmail.com ([207.46.8.86]) by bay0-omc1-s1.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 3 Dec 2006 23:22:19 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 3 Dec 2006 23:22:19 -0800 Message-ID: Received: from 207.46.8.123 by by117fd.bay117.hotmail.msn.com with HTTP; Mon, 04 Dec 2006 07:22:18 GMT X-Originating-IP: [24.16.67.215] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: From: "Bernard Aboba" To: lars.eggert@netlab.nec.de, ips@ietf.org Bcc: Subject: Re: [Ips] ips WG Last Call: iSCSI Implementer's Guide Date: Sun, 03 Dec 2006 23:22:18 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 04 Dec 2006 07:22:19.0400 (UTC) FILETIME=[EED61080:01C71774] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Cc: X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org > OK, so this document not only updates 3720, but also 3721, 3722 and >3723? >From what I can see, the document does not update RFC 3723. _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From much@armaorlando.org Thu Dec 07 10:25:20 2006 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsL7g-00076S-Eg for ips-archive@lists.ietf.org; Thu, 07 Dec 2006 10:25:20 -0500 Received: from abordeaux-253-1-149-136.w86-213.abo.wanadoo.fr ([86.213.124.136]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GsL7Z-0000A6-8v for ips-archive@lists.ietf.org; Thu, 07 Dec 2006 10:25:20 -0500 Received: from ZSTZKB (unknown [118.150.141.129]) by armaorlando.org with ESMTP id 8534D920CBEC for ; Thu, 7 Dec 2006 16:25:45 +0100 (GMT) Message-ID: <000b01c71a13$e45fe8a0$00000000@fiori6o37gr6u8> From: "further" To: ips-archive@lists.ietf.org Subject: this morning Apparently Date: Thu, 7 Dec 2006 16:25:14 +0100 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0007_01C71A1C.462450A0" 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: 4.5 (++++) X-Scan-Signature: c119f9923e40f08a1d7f390ce651ea92 ------=_NextPart_000_0007_01C71A1C.462450A0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0008_01C71A1C.462450A0" ------=_NextPart_001_0008_01C71A1C.462450A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Skypes technology optimize, voice over ip! Ignore friend, xml branches = version gpl copy, copyright open! Office mac, drop deadapple rolling = gaming marketwho. Resolution, graphs ability show. Becoming dominant united states xcwith edonkeyxs. More people often less = moneyxd said edward. Fri mar st months ago updated sat, collects, = aspects. Data files shared million. One upped skype which uses own looks me that. Dec beta testers numbers. Each routing processing bandwidth, intensive tasks. Million worldwide able also connect friends family anywhere without. In = and space, wireless? To offer, voip phone service millions! Joe middot rate subscribe = releases! Provider through will, now available enabling customers make. Three decades rss, november october september august june april? Ceo = strategy inc written. Me that is download on not integrated into any. ------=_NextPart_001_0008_01C71A1C.462450A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
3D""
Skypes technology optimize, voice over = ip! Ignore=20 friend, xml branches version gpl copy, copyright open! Office mac, drop=20 deadapple rolling gaming marketwho. Resolution, graphs ability = show.
Becoming dominant united states xcwith = edonkeyxs.=20 More people often less moneyxd said edward. Fri mar st months ago = updated sat,=20 collects, aspects. Data files shared million.
One upped skype which uses own looks me = that.
Dec beta testers numbers.
Each routing processing bandwidth, = intensive tasks.
Million worldwide able also connect = friends family=20 anywhere without. In and space, wireless?
To offer, voip phone service millions! = Joe middot=20 rate subscribe releases! Provider through will, now available enabling = customers make.
Three decades rss, november october = september=20 august june april? Ceo strategy inc written.
Me that is download on not integrated = into=20 any.
------=_NextPart_001_0008_01C71A1C.462450A0-- ------=_NextPart_000_0007_01C71A1C.462450A0 Content-Type: image/gif; name="two.gif" Content-Transfer-Encoding: base64 Content-ID: <000601c71a13$e45fe8a0$00000000@fiori6o37gr6u8> R0lGODlhGAJgAocJAAAAB4cAAgB+A3uKAAAEdY4Ajg12gMrHwrfiuaHW/kkaAGkhAHQXC5cmAMMV DtIgAABKACIxADs4BmBMBHpMDJVCB7I9DOVAAAtXABhdADxYAGhiAIRdAJlWAL5YANJjDgCLACB3 AE2KC2yLAHWLAJOEAsJ3ANJ6BACtACynAkmnAGmgAHmoDK6YAL2pANeuAAK0ARvIAEG6AGTHAIfO BqvKALjFANPLCADsABXuDETfAFjmAHngAKDrC8rWAO7sAwwDOxoJQjUAPFkAQIwAR6kCS70KMuoA QQAgPSYmQzgmQWYqToUiTKAkQbUUS9ETQQtMTR0+SERMPGsxPXw0TqNKNs5NNNM1SgBhTS5rPkdk NVhrRophD5VdSspdMdFkPACFTil3SkSGMmN8Tn96N6mASsaHQdF/MgyoQyyWNTKnQmyWRXGfM6Sr RMeuQueaOADEMhLKTEe/NGLGS4fBP5O1Qc7NQNjLPADTTCXkNzPuMWPjP43kSJ/SRM7XNuHcOwMA jBwEeTsHi2gAhIAAcaAAhrUAjt4DdwArjScYh0QXclEfeHkdg6Ysd7EegNspcgBNgRQ0ek0xhmhF dXkxf61Ge7s0ethDfglaghxdeERfclpmcXxuf5ltd8hucd5afwBzeC2AdTV2h2B2h36DjJmHi8Z+ iu6Cgw6mfyalfzObjVGtdYOaiJqkicOmetibggDEgRa+gUHHelfChozHiqiyjby/fOOxfgDmdRvU djLVhGbefXbof6LWeb/XidbXhAAFvxQAxjMAwVcIwX4FvJ0AtcQJy94AswErsxwuzUwbxVMZwX0U sqAsycwWu9wVvQZOvxs9tUk9zmFNtn1AtZNOzctIy+5KuQ1ixS1asztqxV1avIJXwatru7ZjwuRb wgB2vxR6ujiDs1OGv3qLvZKNv8SGs+eMzACqvx2cuDuYs2SbuHepyaegu7iZxdWTzgC7sh/ExDaz yVOzunfEupXMuP/24pKtmXFxcv8AAQD4AfX0AA0A+/IA/wr///n//yH5BABct1oALAAAAAAYAmAC Bwj/AO0JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIBH+G0mypMmTKFOqXMmypcuX MGPKnEmzps2bOHPq3Mmzp8+fQIOmDEm0qNGjSJMqXcq0qdOnUKNKnUq1qtWrWLNq3cq1q9evYMOK 1Sq0rNmzaNOqXcu2rdu3cOPKnUu3rt27ePPq3cu3r9+/gAMLHrx3rOHDiBMrXsy4sePHkCNLXky4 suXLmDNr3sy5s+fPoENrnky6tOnTqFOrXs26tevXsGPLnk27tu3buHM7Fs27t+/fwOXqHk68uHGI wZMrX868Ocvj0KNLn069uvXr2LNr3859ovPv4MOL/x9Pvrz58+jTq1/Pvn1QiwLiF4wvwB79+/Tt y5+Pvz7C/vgN1B9DA/Lnn4D7CZQfgPkZxGCBCNb34IEHFdhghArepx+FGULYoYYETbghhRde2N2J ItlEn0krroiSiyW5CKNKM44kY3wr3SgAizjG2KONONbo0ow1tvjjkD0auaOPS/6j40kw3keSjk0K CWSUP1rp3pZ5FRnkkUxCmSWYYjZ5ZZgvHqmmlGg+KRORYCoJE5xOxjnmkkJ6ieedU5J5JZ9ncilo WfAl2OGG/xl66KIJmWgioyEqaqCiDVYqKYGGPrrgpRVyqmmClnKIqIGjlvpohKFiiOKqBt2kZ51m ov8pq5Z9mpmnn7TWqWubSfrJEpyxyolkrLXyWGWvxN66I5bHEnsmssUOKu1dEy77IKxlRkvjmsn6 il+2XgJZK4C/cssgrORmm+a1gSoLLrTj9oetsNhOa+9cr2rpbr05cqtuSt8WqyezMwFrLL/lOosw v27KKrC8DvPKsK/3VgxToRxuKiqkH57aKYmSeuwgqB6OSPLGCzlKqXwij4zypwemSiqpGs/scscx c8rqzhHBXKrNqj6ksqgtR+pfiStnqnOjSmfM8tJGJ+p0zkeHbPWiQ0uNKtU8d12RzyKfWvTHQIcN ctVcG322RFlHPXbUCP5s6n5iJ4010i+fDLXXfGP/OrXcQQfeUN1oM114hvxNCjdEbWP4NqqH+nw3 0XoHDaLZZ6fdd3eu2mntuaBTDDCuAW/L5sLhMpmu6RErufq6DbcrZegQa4suuvIC26zFvNO0+e/A By/88MTz3PvxyCefV/HMN4+d8tBHL31azldv/fXYZ6/9VtN37/334Icv/vjkl2/++einr/7427fv /vvwxy9/iuvXbz978+ev//789+///wAM4EDuR8AClkeACExgUQzIwAY68IEQjKAEJ0jB3yjwghjU SAU3yEG/ZPCDIAyhCEdIwhKaECMdTKEKV8jCFrrwhTCMoQxnSMAT2vCDNMyhDnfIwx768IdADKIQ /4c4khsa8YhITKISl8jE5xHxiSu0CD+m2BQqFsSKspkiPxqixYN0sYnNu4kWUzJGkpQRJ1M8SRrF c0aTlLGNZlyjWeAIRfRIEYtXxOMX72gQPMZmj3ncoj0AORBCgsSQYMwOIgepRz9OxJGOfM0iA+nF SHpkkomsjhY3KUhOevKThDQkJDtpxS920ZSlpCIqSSnIPnKSIJ4UyCoLuclApjKWsrwlLV/JyFpW Epe53OMnM0kbMb5xjW084yb/kUw5jsSZz+RHHKXJTGSm8ZjUHCM2o0lNN1ozm93U5ie5Wc1wWrOc 4EwnOctJzm2q0Z3iNGc365ieO7ZylrvMZzAXMv9KWLIyl7TcJyMD2kuA/pIhq8RnQUWJRXyesqGq tKQ/7xlRiv6TmNsRpi71WVCBJqSfuwRlSIcZTJH+MpS4TClEt8hQiwr0oS4FpitjulKPYlQ2xpTn OneqTGh6853ejKccOYlOeV5zmWT05DqxyVSi0rGn6mQnVLmJ1KBOs6hIpSM9jzdVdl6Vpz4tiU+h 6dSqlhWqR9VqUKXZVXR+1apw9eo220pVlExVrWrdqsW62kyd7tSu84zmO9Ma2GVWta6HXUk832rW sD51qN9sJ2QD69W4LhawlNXreOypT0Bq9KIeBSklbdrR0obWjzDdZ0JDOlGCorK0DtVlLRWa2pf/ QpS0N31NThmbVVDCsadAHexbwVrYycJVqVQ97FiJOs3ILtW5WE1nXyuLVmcyV7Pry2twxZpZ7Hq3 Ob4Nr3jHS97ymve86E2vetfL3vaO87vp0y53twvf+lomt/jNr373yxj7+hd9/A2wgAdM4AIb+MAI TrCCF0zC/zqYfAyOcHEeTOEKW/jCd5GwhjfM4dxi+MPI67CIYwPiEpv4xCiWyYhXzOIWgzDFMI6x jGdM4xrb+MZBdLGOS4PjHjNnx0COjI+HTOQitzDISG6MkZfM5CY7+ck0TrKUEwPlKlv5yg8OwEi0 bBIub7kmXs6LFMoyZpeU+SdnbkuacbJmM++k/80pgXP6LBIAgtR5IHdeyp3zjGeB1JnPDdnzQQAN ESkQxNADQfRDFI0RRgvE0QlBNKQpImmHTJrSjz7IpRey6UhH5NKThnSnjTLq6fD51E0RdEFQDRFV b4TRsP70qw1S6kxzpNINqbWlbZ0RXR9aI6GmNVR8nZqbeFnLx95yAJaNkmUz+x/I5rKzw0ySaVf7 y13+crKh7eyTTDva2+42TM48ZnKPRArohnO60X3udJ+k3Oxud7zXXRJ4k9vd5873P+i9b5KUmd/1 pje+941vgMv73wRHeL7XbW9/93vgDDdJww/ub4Mv/N/mTji7J27wiWv84giHeMET/m53W7zfDv8n OXmSzfKSUDvbz4a2y1cibWzPXOY1l/m1s83tnSN7525euMPTvGaio1zfFR96vZGedKGnPORLN7fR Jd7ulC/96HEmuNL1jfGna93pTP861sE+9q/Pm+zw9rrEMx51qUu97VZXe9iNznbx1DznYX75zPN+ 85Tg3dva1rngB49tvuO8JlBH+dTjXu6rMx7rCnf8w6+eeK4rXvKWj3vmVdJ4r2d86p1HO9U1P3nS s73ypd/846lO96i73vRML/rrz/PzwHPb2l22dt6/7W3c5/zm0XY573lueGnH/CWh7zzDZb/1uc/+ 8qMH+cgfHvHSL//dsT945ANucsofffuoD/3/2EEvcMx/3/PP3372NS7+9rPf/aNf/PoHzpmL/LnP rh60ne3BaoSwOv9+FoD3F4AKkX8ASGgKYWiKpoC8pmm/Fmu/lmj2AIGi9oAOOIEYKGy45mkZmGkU KGwS+IEL2ICVFmsQKIEhaIEoGIEdWIIqaGsVmIIy6IEvuIIdiIInSIIFQWxdgRO1d3iDR23H9oNB yHM9p3Mvd3eF13c+B3yC93vb1nzKh3n3BnnRl3rQJ3nwF35WJ3+ql3zq933wZ4Vk6H5VqIVimIbR 93lpCHrYJ4VmmH5k6H2aV4VsOBr2t2p25myDtmz894d76IcGwYeqRmiClmd7xod9+H9+JoiA//iI hOZosJZumoZuGbhuIAiDlJhok7iJE+iJuIaJNiiKtGaJOGiJCyiJqHiDI3hopgiDrPhoq+iKoDiL lBiDLaiJDHiCrxiLn7iLoshwnGiKOciJvxhqtviKPJgVWHYXcmYTz7gW0Yh4bwg9U5YVy8gQ2egR 25iAmXiNI9SNO+iJTUGKt/aN4JiON9SM7NiO7tge0yGORLGBSkGO3ogQ8ihr6IgU+ciBAHQT0xcX 00iNZZd1aKFwA4lmpIcSbRaGLZGQBnmFagGRNEGRDnQRrThsH0GP95gUHHkUPBiDy9iNwcYU/YiP AsRmFMd9FRdvH3dxVSdvJbdx9Dd/LtmSNP95b/NGf6e3ko53h+rncfz2eSN3kx/XeCJXkxGXlA0p cBh3dkoHcT45dE8JftSnk0b5kq2XldUHcEMpdi5Ud0gXh0/XdanXkOv3eGKpeGsZhj3phT0JfUX3 dlJohVk5lmI3hmXZfGVnlnYJd5YHl3VnhnTpfHyZdtWIhYTJQBhpgw0Yix/IawzIgcVogvdYjJfo gLuogzuIgZOZmTcImRE4mZaJkjQ4g6EJmqf5mKopmqjpgo6Zg5/pmTUoibWZmjpYmqt5QRlJi7KI icsnmadYkpU5mr2Ig8a5icG2mcd4nLT5maHYmSEojLTZnLMpndW5myL5gNQ5miyYneBZgt3/yZna 6ZqPqZvg+Z2zuZ64KUC9qYH7mIvnCYLFGZv0eZu4uZkf2ZnMCZq2iZoyiIuZyJ6YSY/XeZ+jaJ6Z 2WmyqaDsqZ4KCqHoeaAI9J65OKHCuZrbaZ+yKJ/eOYPEaJoemp8J2poOuoLoiZ0EaozSiaEtKqHG KILf6YsauqIdCqMdCmoxepv/6TwA6ZJGyZQ42YVlKWc5qW4bJ5MMeZNPqYY/yX1GunpBSXk8CaVh 96TkJ34tSaV3qXJDKpP2BqRTOXdJqZhgOpM6iYVrp3xCOn7v+KZwGqdyOqd0ihPqeKfcU6d6+h54 2qdNxKAW0Y8nqY/+eIEzKhGDKhuJGo/m/5hrqxGdhYqovcaa88hpFyiglIqggbqpVEGSmBafutGj xLGfjkmonLoUowao2KmP+SiOi3qqkjoRJXkcoFaLyuiZytioxzigwzmCxJiKIWqPHiqet+icCpir wWqbtkqswxiiu/qsx8qsvwmsxnqLv4iczQmfwiqMy1qJkgac34qs4aqjGaqr0eqB4zqt0Hqt06qs 4qquzfqsuDGr4Ymur9mRGVqvn3ijFXirLNiKofiet2qCyFiqx3qv6cmfvuqr+BmbAFueCmuwN6qv KKqJCRqZIsqwDjudJWqg+wqxLKqvxHmotEGdLmqjmcqa+smZGdmvh7qysEijuVmDEMqf+P9JofeK ofXZsSCLsB/as6npsQibqs9JnjPLsye6syJ7qSQ7r9b5tPVaoOZatL7Ysu0qszQInTE7n9MJnCJ6 iV47tEEbtuUZnEpbtUBLsdiKrubqr51YrMFoqcwZnDjargFLtmp7oiSKtbvBE1pakGRpmFeKlFmY hYVppqx3ll94hX8bpYf5l+iHhq3Hl2kpuHI5h48bf8+3EghpfurGEoTrkGppfoWbfXAph4BbuZ4B q1Hrnbp5nKloqL25gRq7r5g5opDKtWX7tdCJssGqoijbuhOru/7Zgi4rsXpbsa15sqWar0r7oDGr syF7tFv7s+2pqKSYvaBYtbPom7P6tsr/C7b9ubc0So6imq7tSYGrqL6kCa/WarLai6xj273Fe63H S6nmC6/j2In7S62umL6juK1xS4uTuK7DGZrsW8DjKK9C1hcWqT5oqTwPzLkyNsHoE8HIY8Gch2In 90AYzEAavKci7EJ+WsImfMI4JRghnBMrDBRICpEtHGddWpByEcMAKY0sLBM23D1rGXQ77MNX6rcV mZhA/GYPKWZuIbrjFhPRmJAP/MMMyTstrMRCQcVJTMRH7BMDCcVGrGZBzMRgvMFZvMRVrB5CWXDd p5U1yX5e6pVmh8FsuJR32cGIKaZECaQW55R4LKaTx5RNuZNBenZtSn0x+ZJrGnJ7zJVQ/3l5Owly XyrHkTeNydfGHUxxJ3fGXEnJgpzIW2rInxGotaua11mgE/ugv6q7Dwu2zWuw3xq9y8u3HhuZBwu0 GFux/mqc/Mq33OmzwgmwrYyryPvL2Um0sZu21quKvPyxURvKWnu9/QWNqHu4mLu4boiXiTvJhdvE 1QiU2TzN3VzNgeumcleHnmvNiJt1k2u5YPeW5dzNarrNpku648x8oie5cpjOCzke+BzJ41d9dCh9 i9yWfax2XsjGayh3WJmksPd+DM3IqCulS2qVBv2W/oyT4fzHdYmXWQqVbijJ8+zN/yzOAE3PZkp3 XcnHogGrpgygRBuhzqut8im0Jfqv2P/avqu6oSQLm7RsvfAptr2Mr8G7aTpttcyLtqk6wMa8tghM szedtJfJY9CcudJc0FZZzecHzwRNhU33pJk3hXD4hvscmLMXpCGt0WPNz/XchYFL1uZ81SXddBLt zbKXzosc0iStl5ArenTd1uKx0QHHloBspEzqk3F50GpN1QrN1Q7NdWUKx4PMhST3xz0ckIBtuEX6 woibxiy5eufnz5pdparrpllaukl3yV65xn5dhmVa2qAxYK86Frp2kq+9yoox209xYVxMGBRpw7kt z5nR23Naycqx2zoB3ByEwsid3MotGSPc3ObhxGKsktI4w85tR41RazhtqZratIv2tdr/DWzgvdzc gd3bja9KTWrdjRW2Ld5FYbUMHK/A/N5XK77UqopwC9/myK1u65zxvd/pGreomN+46r/0aazsCq32 iNTPGa7szY+2zN3xjbW1nLbCnN2niJwWesoLWtO7rNSznLfDvMAQK6AE6t4NzhAqSbggnbmW65Zy HdoOKdF/q9ioR82a+7hUTcN5TdphXdDVPRSbOrfjebVvC7sfyq0vy7IK7uG6KLs17bY0G8vcObUH frE87dS+eeINkeLWR8EsHsWRm9YfbdV2rc5uPaXffON6DboSGdZ9ec8R+eMn0Wjhu9Q5WrMoOtS9 u917vrcyqrLK28xS/rP0C70g2tQT/26ehX7eWn6OJCis9ovAkG6t4lvpyMi+xluKsszf7s3gkqmc pRjpCXypBt6r/0vAw5ie29voB6EZxi3nMrQY683q6qirtH7ruM5gsL7rvN7rN5HrwL4Qvj7sJhHs xt7qxJ7sx77sA5Tszv7svc7szA7tvi7t1n7t2J7t2r7td0rt3v7t4B7u4j7uUcbttE7u6J7uTWbu 7N7u6ajuIuzuWg7v9F7vNSbv+J7vLWbv/N7vJqbvAB/wEvYTejcTBW9zQHcWB08TC58WDb8SADAT Ed8WAFDxLDHxNIHx4aHxbMHxLuHxnvFtzPbwzSZuevd7Cd8TuIeEKkHyCE94Lu93L/9vhCMB8iYx 8TYP8WUB8jl/8zbh8T3v8zU/9CqB8UG/8yeB8xRP9B8PHIYXE3y38EkIFMWn8jRPeGBGcxLP9DBx 9DfB8y/h9Skh9mOf9DqvF2T/E2nP9XqREaimiPwH9302iHGPiAT4bX8oiNMmgI4o9wRI93lf93O/ 93Vv9/t3+IQv+Hnf94Xf+H8vEAAA+RVvEBVf+fZg+ZI/+ZSf+ZF/+Zff+ZWv+aE/EJg/+qRv+ab/ +aVf+p/P+aS/+ZGP+arv+rGf+p4/+qDP+rL/+rqf+6L/+p6v+r9f+50v/MXP+7l/+ppv/JDv+sIP /Hnqg8J3bU8/80fI8kCobVGIcy3/9/IFf3fhhvVOyITZn/3Bt4Tij/L/EPFGb/br3/4aD/Rmb/Fc z/4lYf9ED/brf//7TxL4DxD//gEYSFDgQYEGDSIkCGBhw4MKIyakOHHgxIUXHVqM+LAgR40WIYr8 SDFjxoQKJZ68SBIlwpYvYc6kWdPmTZw5bwZAyPMgT58CgwqlOdTn0X9Gk/ZkqnQozKc/iSpdGpXp 0p4BtG7FOhXqVaQzw2K8KZEsyIoMW6YNeVbtTLMm1bKUWfHlSLkwPcZ865HuW5B41/L123ew4Lsc ER/OWzOuTsiRIdujXNnyZcyWA2jmvHXr5c2YQ1MOXdre6NOpK3vWqpo06dagM6ve/4zaNGrYn12/ 7sz5dGzbvEez5l0ZAGWHxzErV47cXvLky5FDf265eXXoDqc3v258e/Trx7OLv5zdefnq3p9rP5+e ufX25L2HRz8fvnr52O/n16/+fnrszKOvP+uoA3A2BBNUcEHMJLOJKq8eLAqsCCvsSioMMyRqwqoo fIqqD7+C0MKwxsLqKZQSY6wut9piSzC42CJJr7liDExGFwfjy64X01qMJcByBBKvxYRkjEYfdTwS xiEddPJJmBhcMLjVdsPNSixpc601Kl8LbjjRfLtNzN22NM23Kr9Mk0wtYSvOOe6kO5C/7gjUbsD1 5gTwPTnp445OPadrzz5C3cMvPv8+CVS0Oz//2xO+P+GE1Lg645S0UPb42zNRKTv19FNQsxRON9F0 o/LMz2oDzVQxYyvV1TGrpM1ULt8sszRSac11tdpqLZM59pYL1r3o+rzzwPXkMzDZAutL9k9li2X0 WGQX3a7ZSMGjlNhMHX2W02cdBVbZQLV11tJlzR13XENDdTdUKOOVd15667VXwnvzrZdFffv1115+ /6UpYIEL1vddhBNWeGGGG7bVYYhDrTNiiitmeGKLEcQ4Y44jNvhjkEOm1yqR/YWuZJRTRqvkk1V2 +WWYY5Z5ZpprtvlmnHOeqWOee/b5Z6CDFnpooos2umedk1Z6aaabdvpppnneWOL/QaulOuiprfZv 66O79trZzColOmtKyf767Mz6VTFIBx9T8km3DQ5YprgJlgxIHAd20u6C+ZaXbhzXllsnv6GGWWo5 r2Z0YbMjznpqsRvGU2uwpWzc4svfhTxxrBnMHG3QKZu35ZhIT2kj0zvaiMe5Vi9o9YZcz86u5E5f CfbXVX8o9dchqp312WO33STX9W5MpeJtF34v3Xsf+Hfno285duRT/J36JPWqHXvgefc9eY1kh570 2bWHHfrhVyzJ8KZXYnvHvGe0fmXhGyOsrPXrNxJvGWXnkS7mhW9lillLkfrCPBXxL0YpQhLxZmQT /RGpgSmR35Fahxb//aVFDHzg/40AyD6ouY9+PYIg625EIw3+D38p3B/bOAg89XnwfYYxiwLhZ78O 8otJEyzS3JakpBfuyIAb5GEM7RfEutWoRSDUWfmGaEIgTq9/B9yeElVoPtRZMXwnUyASr3jE4M3Q LSMZj40YCDgL6m6HDAljB9X4Q8H90EgodGHruNjGKbrRiDli4r8QNiBA1Wdy5apaowplLUXpyZCX ElflAMlIRDZSY48CV5/QMzFOLe6QyIrceTqJSE1xcj+QFNsgF8m1QG2tkqcMZeiE9reOHC+BdaTg DY2YxTGKUDE/0iKRgihHX6axh3orTBqhGL/HvBCXGOxl4GKJNzSeUJfgeyILef9ZS2naSJZv62O+ Eqaua2FSPMUqD7XABchjoZNc4WLWOKWVLnKaq0DU8qQn01nObh0qbGBbFj45V052+nNd3yHot5o1 z0hijDqP5Fa1AqnKggZUnmWzFD6hlUhXvrKbMovjRgcXs8JBJqQeJWnOMnpSb1EOpZ072ucW5NKV xlSmnyrpyzpaU32N1GQ5xWlPDTdToAZVqEMlalGNelSkJlWpS2VqU536VKhGVapTpWpVjUrOmMLU qlvlqsJSVhedRias+xog3Iw3VrI6Rps+ZWtbk/Y1ra40rpOk69A2Nteu5lWvCxrd+MS3l+tt73q5 Sx/vQpLF8/2VeLv7K/V8JxL/9DUvehgRbGL8irvE3q56hAXiFiVLvpI01q2jJS3KJAjYAuYtgjqy YQQDeNpi4jC1sWWtYcyYvVg603+UrWD8BIjDIankiKUlbnERIjlRXvKfpExu1SKpSH5C91yXMuUo LUm5QT43kJXc5ykJGZ9U7lW8R+1rYBkLWQRyUYu9o6YwnYg7yqq3gSIsY5DiBr/ILkm+yhvm6Va4 3iYlqb7GJXCBxUpLN9awmb9coH3/u8TOXlGHtkVSHK1pTDmKsYUOTq1sDfzhnv5xW3FC16PalSfv Zveh0rWWd0384uae2LoVHVR+6MnidtFYuZtkKCWtO14gB7W8pTsv7U6CvR6a/xdwXbys8iQ72WUe GXxQNt5H8lu+3DFpsLvkLDGpuFncgpmbICZzmduK1puh2cxrZjPIgtwpvJ4tzm+mc53tDLQ5ey3P d+Zznz3VZkAHWtCDJnShDX1oRCda0YtmdKMd/WhIR5rRfqZ0pS196QZJWtOb5nSnPf1pUIda1KMm dalrgmlUp1rVq2Z1q1396tCZWtazpvVNYH1rXOda17vmda/tXGtgB1vWviZ2sY19bGQnW9nLZnaz ne0xYUdb2tOmdrWtfW1sZ1vbL3t2t739bXCHW9xV3Xa5zX1udKdb3ZEZd7vd/W54x1veHVt3ve3N xHnnW9/75ne//f1vgAdco//3JnjBDX5whCdc4QtneMMd/nCIR1zi/aLYsOy6Z6Hxgx8+0/hlOh7V j88m5JYZucBl+jcsT9m0aoaZxkPmcoTA3K0yjzk//kHzg+B84jP7Y6TyZDSLKyzoPUdQySszcqN7 quRJZyrTKZN0py8s6iaHV7yKhzqW9zWnWcfmTHQuEJp/PTI4F3tNy35zm3s97f86+85pQvQRQ2ta 8exnP8NmnoiOJzwGGk9EZ4P3vntc44PfuD0If3jED17wiyd54T/++I1D/umRd3zlRU74xive8IWf /NE173nIH77zIUf85D8veNGDnvOlp3rRhnUnYAlK9ij2eabuWvvYM0v2wbL//UGHPvveX371lvc8 6Dtf/MYzXvKbZ37zO758qA//+MxHOvFJb/nPP5/y09c+8lGP/OU3v/ULQ3lusc7G560vt11fv5WP rP4pn6/9Ktce+2t+f7TjP/85XztNyJ52lyO8/AvAwRtAmxPAr2u7/YM5Buw/AlS7+3vAsDvA/quJ Cdw/sAPACnQ7gRkwrPPA95IyLEO/Z3q/q2OswFKj/FJB++M//LvADNQ/CJTBxFu7GuQ/xLOJAoSJ HFxADcxBnbtACXTAH7wJIUy8GOTAydAccfo5YdmWspm9BHm9ccKWvQO+3HNCBeG9LMSM6ps+8fvC y2M800u9zWO9MzRD4fO+/+u7vswwui/sPjE0vTEsPqabuvGTmiYcOip8wt8DqLizQkGEQi70nCvU QjJ0Ps4Lw0V0uqVrxNAzvjOUxNMruu1jw+xbRO/bRDm8RDD8RDDsvjfUxDx0l/KDC+GiIMUSH2xS ucSqJfkrQdXpOlZExVlUPx4kwiTcRZmDQQzcRRf8RR/MRWAcxhjsRV/kRQ08Rl18QB+kwGA0xiRE xmJUQpuAO0A0qO94J6zCu7/zRnjyvcBjJ28UFnDEqlAcvtBLPDJ8RC8kPvDTxPDjPswrw9ODw3os w3SkPnXUPDWcxzasPjwsRYKUkoEUP1AsyICbOAUUxoa0RoictoeMSIqsSP+LvEiMzEhTU0iO7EhT rJcR6ReS8ReuEIt5Gcl8KUnJsAqV1MiCK5GCQUkMkcmd4BCaxImbNMkLwZcniYqcdElRUxgwKROI uZIEMUopMcozeRekTEoGacopCROPnEpZIY5cIRVZ2ZLcuA1YgZXf4BKs5BXgwEqr7EpX0YxU+Uqx 5Eov8Yys3Eo1ucqwdEu3TI2zpMpmO0mwCAqguIoM4csLAQrABMwT2RDDPEwTmcnB9MvDTArCbAoQ MUyfREzHlIqQLEzL/EmgdLSEOZXeeEsvscs3UZU1kY02sRXPlEo1AU3c6JLSrMrXZJPQjM0rWUrR xMtv08uZhEzPMMm+PAr/1ghModCK3XTM3mTMxNwQpwhOxhRO4yTOEOmKvtRJp2iK5sRMC9lMbYtM y8TJDknOkITJnfyK4iTP6uRJyjzP8pxO87TO7tQQ5XRP7Qy1zpTN23wYrRxNLBlKVEET/STK07zP WzHN2fyNARUV0xwO0izQuwzQBcVNgbONs8SVBi0OCR1LucxKsKzQugRQtazKsNzKLEnL1uQV/DQT VTkVX0GTuoRKCD22kbE2zZzPe1sYFz22G31RHWVKb8vRHe1IGg1SIR1SIgWxHz1SgpSXGa2JJQXJ GI3JxsyJnEzOlPRO9IxSyGjSIm0aLW1PkelS+ISSkaTSmtQJMrUXmWTJ/yjtUjDd0oJBGB9VkDh1 mDmdjToFFdt8Sqf0UIZxUaisTThFUqNSUuP8iZIUTL48TuAkzuecCkZFVENl1Of0yUMt1OFsyUuN 1ER91EslTPakVOi01EaNz1GF1E5d1E2VVE2tCkktkd4UzE511Mt0U5mB06HsDDDxzD810LakTQQN E690Ta1cTf8UDgYlUDd5mP78klz9zAI9UBM1VgHtlbek1v8UVK4S1mkdUT7dVmLdVgR5UHFF1v2U SjaJlWLV1mV1Vm9l1xL1z3X1VXk9UWxFKUJVTK5Qz8IE1VB9T1nN1+sMTn0F1fSkTkWNz8lEzlNF WIGVT1Z91eaMTlJlz/8O0dR+pUxarZlA9dVvRVf97FiiFFaQ1VaOBdZzfVbUdFdjBdSSRdZ3rdaV VVmXLdZ6nSpiXdH7BA5oxdlxvdmX5VkzIdCeNdlkXUqlnFkFjdmWNVCfJdfUXFCgndcArVmoUtEU bRXSpFAKtcsW7VCvxdncANe0XBUFNUtU8RWjtdOxHZWsZVvb3FqtFcuQXds2gdtbYRUNBU2q1TWW pao7zZi/NZrA3VtU61upGtyKQVyhUVzCBRr2SVjSalM0xVSmkdyMpbjGzVzN3VzODbLL/VzQDV3R HV3SLV3TPV3UTd2F61zWbV3XfV3YjV3XVV3arV3bvV3czd2akl3e7V3/3/1dntFd4S0w4C3eVhte 5E1e5V1e5m3enDBe6I1e6Z1e0XFe6+0m6s1e7d3ezr1e7/1e8A1f8R1f8i1f8z1f9E3fNeNe9hUv 9X1flGlf+Z1f+vXISMsHlckH/aUJ/H0Z/e3flAFgnBDgPuI6DhRgBJ4ZAs6XBa6XBj6IBxaIBY5g faFgkLFgCBYr+AIp35qgboomQkvgDJYZDI6XEnYSCk7hmThhemHhfzlhFw4gm+pgDTMcEB40AMbf HJbg/+XfHv4HHe7f/23gIZbgDB7iIObh/TXiJV5iIP5hII5iI4YJJI7iJv7hIi7iJ4ZiKSbgLObi Ke5iLEYIL+5hLU5i/zIe4TNOYzQ+YifWYiveYvyZLAfKn8vSrFtko8r6LPQBrC0LnMHKrAUSrdnq 48oSHOSJmnfJh8pgZEamDEe2jEeeDUee5Em2h0vGZEmGZE3mZEy25E3+ZEh+5EhuZE4G5VA+5Uw2 5U6+ZFL2ZE9e5VdmZVou5VNOZVZ2ZVHGDFDWZV9e5V3WZF0WZlTeJ+f6uW5RMSe0MWNBpVU6pBWT Dt7zlml+JB2rJ65ZJIyjmHkR4i4OYymuCR1O4xEu52/e4XBOZ28O43FWYyZeYTa2iXUW4XWe4gkG 53uu5zg2Z3uOZ3H+5iP2Z3gOaHcW4SqLJtqyrPWqsPe5LzJqphLiH/8vahIZhqKJfpqEseVSRmJZ HuJOHmWPlmQkpuVWFumQLuZKPulbvgxfZmmV/uSXHmZZhuWPNuVZXmmajuVNBuaVbmmbpuSdHmlh xuXpShwSA7yF2g8+rLFtPOZ1Yi6LopNyVCRwTCkZ0yR72mbQ0eiSRhCfzmmWzgyurmlgRumazuWz Jmu1Ruu07mqdDuu13mmatuW0vumhBmq7pmu6xuW9xum2Bi+j3iQcw2p9gmpMuurwGuwpnBRpRiXE liTHXiquzmu4FuVhzmmZ/mjKZmvNXutiTmX9jevQduuutmS7fmuw7uyfHmVenuu/huWvDm2e/uqS zuyivm1AyRbGdij/pq69v4Mon/OPG6suaGakw05s3T7ms2lhKiZjMFbifYbg597ies5hJ1ZidA5n IYbi7Kbi/W1n6Qbv7+bu8AZo76bufw5v6wbvcl5jeXbuN/7udCZneybvKgZnzkoeBEqfLNMvsLo6 /9qdtSKfZZpFLWsv9IoLAa8/w6qiLtMZXONpot5qoZHwjLHwqtLqYtu0EnbhAM5fl/HwnjJg+J1v +BZxlEFx5gZxMiPxEn9xGI9xGZ9x3cUzxAE4rdJwhOq1OdNxvcozhVIpqzbmXNM7Ia+ripOpIHel Hl+uojItgJnjnOAbF18zGxKpvtmoKo9yerkpfOu5ZOZCdCRHadE9/wF5D3fqbfAY84Uac3KclKDj u3hC5qPGwjAXJ9sTc4ryHEgRczTPp+YaKORe8zAvar5LKXi6qKwmqEOnuzwvJUFP86Z+80enqLlz JzzPpAAZmntZrS4qot1KxTqeo2S6LWYiovgrotCqoVT8ERmesISechLsrAxypuFqrR5J9Vuv4dNy CT36LT5iMg+K9Q/K9YYmIRniLY+6pjxKdhhaMNvCdWO6MLBS9f3usA1rdi/jMCnHMF6q9lKXdhai oz2CdQ/mo7dhdmRfd3Vvd4imsNpC9Zj5pqQubmre7RzbMcPexsghbuZacoh6sUQhMXwn7EnnRjeP Lvyodzi5K8RWZv8c2zFWMsc8j8JFR5SJ0pRxrDEBKfhvkWqG523k9ngf75iJ9/fenjF9ByXlLuwY y+3flqSKGvjiRvmR/5zJgXn7CHJNh3gXI5SJh+xCGvqHx3eVgvh/55xP6vd7r/miSm7jNvigPycW yyefb/qo1xrCpnls9jF7z+YRs3eHB+6wB/qYr3qmF+z/0GaspidmtpOuH+6XV/ikF5Sgz3pBwno7 aaWZ0hZ1ciiEZ+pr6XNH35SAAii7y7t7+sZKB+wTQ5cyd2ZubKi8Q/K/13mr2Ts976RDt/zCrxRz 0vOLt/vFz2pBp+bIX/RIt6go3EM3T3SMql+uKnkkl33bhxjaP/v/29995GKp6aVx4J8X3h9+4i/+ Z7Php9nysqqyGqbhdVtBnVpB5u90+mszBrubDkYzh5Z1LMcJtPKbG55+mNl+kuI6NBqpkLovKFF+ k9KcynGXzWEc+Iczjrmc415stMl9pTpul8J5xwEIewIHEixo8CDChAoXMlT47yHEiBIn/gMg0WJF ABohasRosSPHjBs7Yqw4kSTHjSdFlnzoUWVEkh8/xnRp0uZFkyBv3kRps+VLlTNLBm35E6ZPli53 Al1KdGfOpDihxmQqkqJPojqFZnT69GtIpVuNei2bEiRUqWWTsv151SvZrFQp0q1r9y7evHr35qzZ VCvSqVhx0qVJ/zgsWZ1ha3Y97JFn3MaKDwtuGlXrZMqB/9o17PYz5Z6DMReWbNSy4c2kM3t+/Hc1 T9ErTceOXPu26M2MF8vm6/s3cL4NE8rUaA8AQeTIkzM/LnB5weXQDypXKJ26c+LPm2/PXt3g9+7h m4+fvn36dfTRmas3v779+oHur4PPzrB8fPHe2XN3bn6+ff71FyB98cEnX30EKrjfgd0h+KB7w0k4 IYUVWpjfeeQZt2CBMjkoH0nPbWggdseNSF5/9I2HoHoCithRhhCG2KJyHqZo4ozg5SijdDaimCCM OsLYIoghOtggjkEGiSOL/D345H5Asucjj0PamJ6TH3J4IZddev/55X8LNgmhfmTeOGCUGAZY5ocq rhmjfgUymKWLcVpHp5ZIhhnhj2qGOWae2MmJn3Yo6omhnGbCiVCib84J6Jo0fjkppQ0Fp9ltgDH2 GGScLjYSb4KtBFtvnRKWWGaQfepaSqaihhtvnqXqaquahlpqSLA9Batjn3EWq6qYyTpsX6L29Wto nqbKKbG77obrpdFK61uXfxrJZJLQaVvjd/MZ12OE2xp4YnLkDnkko2Ki96147DLJ7YjgervktUae ++6LRYYL4rjhskukvuheGR298cb74qBCasvoifKWmGTAdvL4Zr2VWnwxxhTymTHHFW7cMcghi1zp xyObfHLJJ6v/vPJwKbMMsssvyzwzxjHTfLPGOOuMs807e9mzz0ELDeXQRVO3pNFJK7000007/TTU UWc8LdVVW3011llrvTXXXXv9Ndhhi7211GWbfTbaaau99ssxA12tmjl7fJ/Ob/tsN9Fs4533nVzu ffPY0qI6W7FXnwacsnsNfivVatW1uNaQ8yV5Z1UnHjjjk2v+2+WYez425bF5fTjnoeUleeibm074 59GmPpjhrT+LuOqbvy77RD8rSa+JIp7nMMLAY8ttk0hHTHzw721YI8LJF7x873UCCLF9wj9MsMHG U28vtsr7nuHyzxMKPI0HL3wj8v5ZSS6H7G/fPZW/f/9+u+wj/8/89jNmnx64NLte+EuWcpTSIIs1 tNlK5gYIGtGpBlg9sZUCQRMZZBGrNKyrYAIRmKwA5gZVssJNs/yCGFU9ayYjLBXpJFg53dxKKJdL Ta+qkqvVMAuCGiQh7kpXwlPl6nGZEuEOl7VCIGKqhw5UVgg3JboFsopXhQOWZTKIwU+NcHAffFUB P5ibC4LQWAwk4l2SmCwqRgWHXzRiDJH4wwzm8HQA5OECWdIsmTgljU6U4xqLyEQlZoqOpNOiECdT HB/WMYtPxGMUybjFqqDljUJETWBmlUfZFAUmabTkWUCFxiWSppKSkWMKAymq16DkNJhso15C6Skb GnJxFZziJP9hacgTFrCIgHwltCy4SVm+MZFwXGSvVLlHXzKLk2As5hKDGKpWzg6HISTVDhOJzDgm s5pgg9uZzlen6oXHXXAan5iOhB9xoS+bbVLQnxy1TW1KKkGL6mY6xRlOdElMnumEXoO82aGHeTNK CeOOPvPTT3i6c2HichPRDmWmQxHpbzSzF+8Ehj3vuKte0CNT/PI1vn5mK09I+2jzIsU3ijasXAc7 2u6yR7GUrrOgGJ0o+SoaUnzBb6TnamfvrmVSkqK0pTQF6MS6OVN9JUqnIKVfkfyHSrDdbqmpdCpU UdnUqFK1qlat6lSv2kytcjVrWe0qWMMqVqt9latlHStaV5f/1rWyta1ufStc4yrXuUaLbXa9K17z qte98rWvfv0rYAPLscCdlayg+58up1VYrH11sUylK2Rxt7KU8cmhbBrZ3xqFt+ndbW7qhJmFLCvY 0Q6EsJdabOe4VlYrBsc2S21qars2VcdGtrbUqpaS4KfTfNWvedwL37y+tb+kDpWeAhIfSi8av/RB tKTgG2718mbR4abPpPJibm7NVSXi6g+f1w2pNkkr3oMYloV6bCIl/dLJ2ZjXgMSkYnuFKUoB7tGY D9ylMx0JxgMekb6PTAwrSajGSI4RmrY9MHBIhs4BAWh6Ck3XgiE1z+OmyadQwlJC6aTZ6EIKSyua 8IoAtqUI/y/qPed0sIbRhOHxsthiHnowcXlav3vFuE8+Tan2qtOtFJtTxAr1Vjlf+uHiOA9RRq4w vDjqJCLXNFuEmvGKWyxlbL5zwooqE2fjljAffxZ8SJ6npLjcYS1Jj8c6ppg7twnmHyGJzGP6GELP VGU1T7nOEzpolrRbzzhbGMVjNiiaOExikX6PoEG+LJZ5LOhDc1TMif5z30jM5yfrM7yitTPUBAcq SGoxLXWslVUYWRhLFuUsmdQlDc1yEU0G5YxToQqp8SuWX64aKaxuZAthHWuxuJKRYAE1V0Td6lQj uNi/wTSyMX1pKie72c5+9l2X7TdoU7va1oaatC+U7WsXzf/Y3v42uMMt7nGTu9zmPje6063udbO7 3VbjNrzjLe9507ve9r43vvOt733zu9/+/jfAAy7wgRO84AY/OMKT5u6FM7zhDn84xCMu8YlTJOEW vzjGM67xjXO84x7/OMhDLvKRD4fiJj85ylOu8pWzvOVXIznMYy7zmdO85vZwOc5zrnPZ2bznPnfa zoMu9KFn7edGPzrSk650OxO96U5/ul6WLvWpU73qVm8a1LOu9axfvetep9DWwy72nX+97GZHyNjT rva1s73tbofs2eMe97fTve52vzve8441ufP963r/O+ADL/jBE77whj884hOv+MUzvvEU7zvkre74 yVO+8pb/v7znIq95qWO+856ny+ZDL/rRk97gnz896lOv+sqXvvUyXz3sYy/72dO+9ra/Pe5zP1fX 837kuv898IMv/OETv/gv7z3yPW785Ts9+c5/PvSjj1fmU1/o0r8+9rOv/aBVv/s5Z9omwk+h8G+i r+QX/0LI7yX1K4394Ee/hNyffPnbg/5dsn/9zw9//FuI/wPx/8X4n/sBYEMQIKWwnwEKRALqXwKm n/whoPg14P/BX0Lg3/kRxAJSoAQOHP1toAOWn0FAIAh6YAVS4EGQ4IUI4P6ZYIWgYAuiXwNmIAjm HwtOiP5N4AhGYA0qhAFa4AUq4A4WxAMGYcJ1IBGOXw0O/6AOzmBeqeAMuiAOskwMHiEQMiENcskN VmEIUqEQcmEJKqEVfqEW8lu0kJ9EmOFD6N8ZqiFEMOAmUAQa/oMZuuEbymH4peEd2uH5tWEe6mEf xiED4mEg1gUb+mEf8iEdFqIhEqIbRoQiDmIjIqIh5uEg6mFexKEkVqJdQCIl3uEcAuIeSqIggmId rmEoYuImdmIpTqIjViInamIhoiEq1hYqyqIn/mEp2mIdzqIlCqIf+iIr9qIuAqMq4mEmDiMc3mIu HqIpIuIuFiMv/qIwKiMxKuMbkiIwGmM1riIjcqMlhuIl3uI2fiMuXmM5auM0eiM5ZuNdIKMdiiIy nuMpQv+jKiqiVt1fIpYfGJ7gEkbhFj5hP44hA45hF+pjEh6kQQJkGF6hQAbhPmrhQxZkFO6j/T2k CIohQ37gP2ZkAfbjRQ4kQV7kRnLkRAZkRwKhGEYkBpqk+llkFgLdpdQiNWZjI2LjRMTjOQYjLM5k M47iJy6jOtpkNPYiUf6kKPYkOQJlMBZlMRKlTzZlOzJjUvKFLabjIh6lO0YiL1blUN6kPdZkTk6i OSqlUNqjbcnkWL6iL9qkKYIjW4KjWK6lVFrlVLIjVkKlVyqlXEYiUhrlNu5hWT7jKuKkOualYXal YeqkNQ5mThKmXf7lXNLFTgomU1JmXV6mLiImVOGjFbb/JEKWpELy40JG5A8WZA4mpGhmpGeG5kgy pBP64xXKIGjCZhWiZkOeJmyKpEZ2IUF2pELC4BKSJnDapmt+Zm0u5BcyIUWuIHGu5myGJBRKjRES 50qGpkrSZm4yJ3J+5GcuJ2tK5G1ipGqaJA8y53iGoXOG53n6o2xWZ28yBBgOJw3+oEs2p3y25kv6 pnKap3c+Z2yaZ20K1nRCZ3HKZ2m6J34CqHqKpIEOp31uJ0s6pILqpnEWqIX+J26qZ4Fm6HwmqIJi Z2/Sp0dyp3U66HuG6HWaJoKKaELa5gXWJ0ceqF8N6HH+Zmm6YWp6KHaC5HkCKB2uJ0LkJwD+KHTK aHba+Wh1iuCBxmeLsiiIzqeMVmSFdiiGBiiUriiOkiSKfig//uNLZumPCqeUSg25aWbTmam0oKnY qennsanQuelvwOmZWibuyanO2ele4OmbmqX39amf/imgBqqgDmrUbZ+h6huhJqqiLiqjNqqjPiqk RqqkTiqlVqqlXiqmZqqm5sWhduq9bSqohqqojiqplqqpniqqpurYeCqrtqqrvip5qaqsziqt1qqt 3iqu5qquXh6s9uqz7SqwSouvDiuxFivvBSuyJquydo2xNquzPuvZLau03gW0Vqu1XuvRTau2biu3 2gW2fiu4hqu4jmurdmu3kiu6Po25cmtAAAA7 ------=_NextPart_000_0007_01C71A1C.462450A0-- From kexrhmnlda@crengland.com Thu Dec 07 14:43:48 2006 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsP9o-0007aF-0M for ips-archive@lists.ietf.org; Thu, 07 Dec 2006 14:43:48 -0500 Received: from [131.109.225.35] (helo=[131.109.225.35]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GsP9k-0001GL-Hf for ips-archive@lists.ietf.org; Thu, 07 Dec 2006 14:43:45 -0500 From: "innocuous notes" To: ips-archive@lists.ietf.org Subject: Next Big market Winner! Date: Thu, 7 Dec 2006 14:46:32 +0500 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0001_01C71A0E.7C8C9200" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AccaDnyMAck1+gZ8TOGitg3mPaa2uA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Message-Id: <1A7C9BEDB754420.6E889D86C9@crengland.com> X-Spam-Score: 1.5 (+) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 ------=_NextPart_000_0001_01C71A0E.7C8C9200 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
VSUS Announces New MyOneScreen Application & New Market strategy. Price & Volume Going Through the Roof All Week!

VSUS technologies Inc. (VSUS) has developed a new application that allows you to surf the web, use email, shop online, and use office documents and spreadsheets, all from one secure application called MyOneScreen. This application is free to download and the campaign is now launching to the world market of internet users.

Company: VSUS Technologies Inc.
Sym: VSUS
Price: $0.03
Target: $0.07

Note: Price Up 33% This Week. Volume Up 600% This Week!

VSUS has also signed agreements with two of the largest Blog marketing companies on the net to incorporate their advertising solutions via Blogs into the software. Blog advertising, although in its infancy is fast becoming one of the worlds most effective means to reach the market. Companies like Intel, Banana Republic, and Coca Cola are now focusing large portions of their advertising dollar into Blog Advertising.

This company is in the right place at the right time and investors know it! Go read the recent news, look at the amazing new application and its capabilities, BUT most of all grab VSUS first thing Thursday morning, before this thing climbs any higher.
------=_NextPart_000_0001_01C71A0E.7C8C9200-- From aa17621i@arcor-ip.net Sun Dec 10 17:06:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtWox-00039S-PM for ips-archive@lists.ietf.org; Sun, 10 Dec 2006 17:06:55 -0500 Received: from dslb-084-058-029-016.pools.arcor-ip.net ([84.58.29.16] helo=arcor-ip.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GtWow-0007wZ-8U for ips-archive@lists.ietf.org; Sun, 10 Dec 2006 17:06:55 -0500 Message-ID: <203B9097.64DC219C@arcor-ip.net> Date: Mon, 11 Dec 2006 11:00:36 +1200 Reply-To: "jacob gordon" From: "jacob gordon" X-Accept-Language: en-us MIME-Version: 1.0 To: "Emmitt" Subject: Totally OutOfDebt Overnight Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 3.6 (+++) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Se1ect 1egal counse1 discovered a loophole inside the bank laws, With this discovery, we've been 5uccessful at eliminating people's creditcarddebt with 0ut them paying one more cent. WeGuarantee that we can help you with this. C0ntact us at 1---3 1 3--263--2706 See here, my good steed, broke in the Wizard, little Dorothy and I have been in many queer countries in our travels, and always escaped without harm. When, at last, he opened his eyes, he was puzzled to determine where he was From balanced@andrew--scott.com Mon Dec 11 04:46:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gthk5-0006gH-83 for ips-archive@lists.ietf.org; Mon, 11 Dec 2006 04:46:37 -0500 Received: from ai190.internetdsl.tpnet.pl ([80.53.166.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gthju-0004Hr-TE for ips-archive@lists.ietf.org; Mon, 11 Dec 2006 04:46:36 -0500 Received: from Yuuwjzk (unknown [194.143.12.40]) by andrew--scott.com with ESMTP id 4F9E581DF233 for ; Mon, 11 Dec 2006 10:46:46 +0100 Message-ID: <000c01c71d09$36e7a390$00000000@C10> From: "assumes" To: ips-archive@lists.ietf.org Subject: themselves parties Date: Mon, 11 Dec 2006 10:46:21 +0100 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0008_01C71D11.98AC0B90" 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: 1.2 (+) X-Scan-Signature: 5b943e80df8c8cad631fd60298783617 ------=_NextPart_000_0008_01C71D11.98AC0B90 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0009_01C71D11.98AC0B90" ------=_NextPart_001_0009_01C71D11.98AC0B90 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Take into account evidence some encourage upload share. Same actors = created, imbalanced, models our analog. November testimony, michael weiss. Net neutrality oped, jenny toomey. Feingolds concert disclosure public = right sound. Recordings names return fifth september page health. Links mashes day testifies, house, quotorphan worksquot. Letter to senate judiciary. Assumes do, want shared network under. = Hindered them spring worked with pew. Material being does take into = account evidence some. Emphasizes efficient licensing content! Negative beyond stated goals. Block andy sullivan home manifesto resources. Prevailing voices rules = determine parameters. Much stake outcome debates willing broader marketing promotion campaign. = The, united states dirksen office building, washington dc august. Band hearts album jupiters? Pearl jam donation proceeds appearance = donated artist. Act sends, committee the, united states, dirksen. ------=_NextPart_001_0009_01C71D11.98AC0B90 Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable
3D"using"
Take into account evidence some = encourage upload=20 share. Same actors created, imbalanced, models our analog.
November testimony, michael = weiss.
Net neutrality oped, jenny toomey. = Feingolds=20 concert disclosure public right sound.
Recordings names return fifth september = page health.
Links mashes day testifies, house, = quotorphan worksquot.
Letter to senate judiciary. Assumes do, = want shared=20 network under. Hindered them spring worked with pew. Material being does = take=20 into account evidence some.
Emphasizes efficient licensing content! = Negative=20 beyond stated goals.
Block andy sullivan home manifesto = resources.=20 Prevailing voices rules determine parameters.
Much stake outcome debates willing = broader=20 marketing promotion campaign. The, united states dirksen office = building,=20 washington dc august.
Band hearts album jupiters? Pearl jam = donation=20 proceeds appearance donated artist.
Act sends, committee the, united = states,=20 dirksen.
------=_NextPart_001_0009_01C71D11.98AC0B90-- ------=_NextPart_000_0008_01C71D11.98AC0B90 Content-Type: image/gif; name="worked with.gif" Content-Transfer-Encoding: base64 Content-ID: <000701c71d09$36e7a390$00000000@C10> R0lGODlhVAKUAofqAAkAAHUAAAd8AHOAAAEDd3sAgwt9ecS3y7Tcy5zH5TYaAFMiAH4kAKQrAMMh ANooAAAzABJEDUA0AFpJBoo3AJs4BLtMAuFFCQFkAx1iDDddDWNXAIRWAqRoALZXAOVuAACCBBxy ADaKAWR/AHp3AJRxAMWDANd5AgCiACaXCTWWDWegBoCoB6KWAMKuAOCdBgi8BSfKDTfLAFu9CnK8 AKvGAMzIANm1AQrVDRzhAzTmAF3RAITVB5rnA8fnDuXXCgACTCQNSEsAN2IORHMFRZEHTr4AOOIA QAIYORcYOz0qPlQgPHcYOK0tOMUhNNsoRQYySCM+TjFLP2tCQYs/RJE7RMg2TOM4Rg5cQh9qSDlZ TGVoTXxtAKVVTMNlSeZZRQB0SRiHSEd/OGyFO36APqOKNbx/Q9V9MQCZTBSrM0mjOGOlTYWiOpKt P8CnTeGkSgPOOxuzNUDKNWjBS4izNquxQr/EMui4TQDdMyfXPEXdTmrhRHTdQ6riSbHlNeTdSwsA eykFdkUDjGcAcnQMf5YAhMwHft8AhA0hfiYgdUsaiVQecocdf5kXd7sreuAadwk/eS01hz1Dg2g8 h3g/eJg+fctOh9Y6cQxZhRVdckZRjmVjhYdijK5Vc8xYhO1dcgCBihqFc0GGjVN1eIyIf5x4iMh+ dNuNigCnhhOqeUCdgGugiYukfJSXfruVdd2ifQG9iCrCeTuzgGTLio7FcZy6jrO9ct7Ghw3ufR7d dj3if2HhgIflg5zWf7LkjevjegYDyBEAyzkAu2sAu4oGwaMAurEAx+UAugAjvRYkzDgswGYqxHUd wJQqtLsgwNMoxQ1OtyZOv003y1NExog9tZY1wL89wN1FsgBdshlayjhVy1VVzXtVzpthxM1Uztxp vgZ7ziCFtUiHw1J8wHNxu6l6v8mLseaKxQeoziiouTGdzmmjt3quwaqbtc6nwdKlxwDNuSLEt0y0 tGWyxoOyyJO6xv//8JOhsHp/dv8ACgD6AP//AAAD/PgA9gn///L7/yH5BAAq9HIALAAAAABUApQC Bwj/AO0JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKtPevpMmTKFOqXMmypcuX MGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq06L+RSJMqXcq0qdOnUKNKnUr1odGrWLNq3cq1q9evYMOK HSuzqtmzaNOqXcu2rdu3cOPKnUu3rt27eC2S3cu3r9+/gAMLHky4sOHDiBMrXsy4cc68kCNLnky5 smWIjjNr3sy5s+fPoEOLHk26tOm+l1OrXs26tWukp2PLnk27NujXuHPr3s37su3fwIMLH861t/Hj yJMrb0q8ufPn0KNLn069unXSy7Nr3869e8Hr4MOL/x9Pvrz58+hve1/Pvr379/Djy59P32H6+/jz 6z9av7///wAGKOCABBaI2X4IJqjgggw26OCDgjE0wIQJTWjhAAddSOFAFhLUoUIfcqihhhWSKCKG HlI4IoolmnjiiileKNCKHcp4oj00hvhijDjm2COLIQbpYosF5bhhjCzOqOOISPJII5FNKrmhjga+ R+WNPxY55ZEf2gjikQZdGeaWQIKZZZdiSillmUmOiWKNZr7IppZt0smlinGqqWeWfKaJZYZ57hhl n3cKiaGhdfLJ455+VtmdmEsWuiicgSKZqKIIRfqmmZT+6eaffkaKqaWejmrnnKGSqaeoLQbaqIsm av+6Jqqc1kqljF426uh2V/aKZ52Uevllmq/G2amTkmaarKl70qmsjbdW+iOah1YabLWbXvqsq9LC iquxv1JrqqbgYrvoru75CuyvnzLZEJ7PDtuurYqmOmez5zoLaLX4FsvvmdbCyy6zJfYYb6vhDozs v8fmC6+b9KKbbrnzrouttAvvK6+z0ZpL8KpgGkmwyJ12LG/JPgJsMKLa3ghptwKbqy7AMlOsproR S8zezBxT7O5CDef7ac9tXosxjEKXqjTIo/qrJM3DJgxxy0Ev7fK3Hme8ssKgcq20rjonx7PWCwu7 7ctU+0xv1RXrO/Tb+v6Mb9wk+iv1wfuaPfekqs7/TC3bLOc5dti8vWRhSoejdHjiJy0+4T8XtsQ4 4yZRjvjjij9uueMDlGR55p1Djrnno4O+0uekhy765qVfrrqGq0seOeynt1756J+jfnvoiXPueuyp a2477sSrvvvvEEqHOuWTl9475pHX/vrwtpt+PPDHP1996sFfrxLznevePOvGI7+68OWDPj3xjW8/ vvnfV699+7wXj7712Oe+ffLTiQ996/PjXvfilzn4SU+ACAzg+Q44QN0tMHb+M170vBc/CfpOduuj HwIvV0D8VfCDAnzf7sJnv/Z1UIMe5F9zaES/5dFugxOkIPY2yJIRuW6C4JOf8zi3ohb+j4U5LJ8D /2c4uxyhcIbn2x/5UshEIr7Qieh7IhKX2EQVWvGKWMwihAjHxS560S5aDKMYx1iUL5rxjGg0CxnX yMY2uvGNcIyjHOdIxzra8Y54zKMe98hH8ATgjyr5oyADUBJBnsSQKRmkSRRZyEEScpGAPCQgHRlJ llCykpdcCSUl+chGEvKShsxkSxjpSU4ispSo/McpT9nHVgqGlagMZSRJmUhM2vKRq6xkKRFJS5Tk EpezhCUvb+lJYHbSl8HUJTJ/CUljNvOZqYSlK6e5F0dyUpKqnKQ0TZnNZF6zm8sEZypr2clhllOX rDRnN895zG+KM5CkVCc0xSnPcVLznkN5iCMJIv/Ig1ySIf3spz0Eys8/DtSgBQ3AQRUqEIIahKAC hShCF/pQg/5zIA5NKEYnWtFBNtSiHP0oQwPqUYdmNI0oxY1MtOlOUyrTkvF8qSzbOdN5kjOaxLQn ODfZUnduc5fOlKY6WZrOl+LzqD1xCEkZKlKO7lOpHhVpRymq0YiGtCCg3OhInXrVpXYVlAq1KlP9 CdKwlnWqFAUpVaWa0raqFCY1XWYyfwrPYwpVmzTFay9vGkue2hSovfypKGEKzJ3K9JZ6zWs7kcpY nUD1qWQ1K2QXYtKvSharZz0pZse61LWytaqU1GhkPTvahXZ2s1ota0g169bWVgauOb3pTBdb157/ Glax9DSqTeNa1MXWNKa0zW1wcRpXnyrSmrZtrHKFwsxsXtOcw/1rb+3JW7pOF7otlScjBTtXwjbT m7v9ZXSXS17m5rWvziymS+6aXuISN7jNFe83m7vOd4ZTvbX9LjTZ+1f7lve/OxHmXGNbX++Sk73A 5eaBE6zf76LzwWAtboHvi99iGpW+/QWwhjfM4Q4TxrUgDrGIR0ziEpv4xChOMRo9zOIWu/jFMBaN imdM4xrb+MY4Vk2Md8zjpOb4x0BeT4+HTGSaBPnISFZOkZfM5JUk+clQjrKUp5zjJlvZylTOspbx cuUue/nLYO7wlsdM5reE+cxoTrOa18zmNrv5/81w7kyZ50znOtv5znjOs573zOc+gzjOgG6lnwdN 6EIb+tCITrSirRLoRjv60ZCOtKQnXZZFW/rSmM40lCnN6U57+tOgDnWLNQ2RD5ia1FQ2tartoeoP EGTVqx4IrFtNa1nXmtW0vjWuW/3qXB/E1wuJta1dXZBc89rYxTZ2rIWd7FP32tkZYTZHlB0SaQvE 2g7B9q55vetmP5vbqF5ITFRdElqbhNzkPrep/5FulaS73eVeN0reLW92y7vVJ6H3B1wCb3vve971 Bvi/8Z2Sfvt7JQRXd8B1YvCetDvhP2l4w2Ei8Xqje+EPt/jC45xtZ+t62R4PObENwmxoX9vk3f8e 9slHLuySj/zX4E75sxHScpSvnOQ2Xzm0dY0Rbfcc5T6fCM+3/fKHDF3ap0a6yJMdbnFT/N7mPrjU 9Y3wjQs83xu/+L+lzvWnw9vgE8/41rE+9niXXeEaF3vao272hOfa7HB/CdjXXna2V/3sXZeJ3See d617uuPEnvXNUw7yoqtcIS43/KxZvvOcJyTpL7e2tmtueJkfHufHvvXidT74wp/88MBmiOSXTvnP Pz7nQT89rmdOc6BDvvJNd7rcob5vv8f79m1/u7+t3vW51572Auc92bnue2NPnfe+v7u9l2/7g4ud +FbXN9+vfvXnT5/62Nf7up9/d2XnXdKA77z/qylfesTHfPDoVzmyYR70zaf//cM+P+vn7+1au7/b pS8/0UWe+surv/Hj53jsN4ARcX/kF4BFZ4DyF3sFuHT7F38AGH70N3oIaHkEyH7gRoGtV4EbiHkd SHiv93+Mx4EgGHgACHsXKIK+1n/+14INsX4WeH83p3QoGHvjBny5R3Zjd30Kl33JR3UsEXZpF3fD 5244WHBZh3w42HxMuH1DyH27p31nd4RF6HVGiHctwX391nxwt4XCR2lAuHs7+HVKWIVEeIZA6HZj iIVamIRsSHt4x4PZ14PW94R2uHVqJ4XUV3FYeIV+OBNQSIa/V3dUKIdpJoGJF3mJ94Ea6G0y/0d+ 4oeCrgd/k3eCHuiIl+iI7ld+i8eBGWhz8geJl+eAAmiBlIhtkziKITh/+seAEmF/Jnd+rkdtD5iJ 3xaLuMh/AkiD+/d6yJaImOiC8PeInziCEKiLrTiMtNhsiSiJoQeDphiDuchtvHiMNWiDojaH32cY hpiN3hgUybcY3fiNPOGKP6d4pdgWLGiO7NiO7viO8Ehi5DiP9FiP9niP+Age8biP/NiP/viPAAmP +TiQBFmQBnmQCPlhAbmQDNmQDskcCRmRwPGQFKkzEnmRGJmRy1WRHNmRHvmRIBmSIjmSJFmSJpkc GpmS2HGSLNmSLvmSMBmTSaGSNFmTNnmTOP+Zkzq5kzzZkz75k0AZlEI5lERZlEZ5lEgpFFVCAASA EUxpEE8pk2UWEwBQlVWpGEyZFVmJEltZEl2pEl/plQQglkXBlGGZlPrIEFU5EGs5F1GJFG85EHEZ l1DZlAVBlyKBl1IJYm1pEFbZl38JAPZglQIRmIJZmH+JmIk5mIcJmId5l2ZJEGZpl/YwmVFpmQKB mZWpmZJJmZuZmZMpl3ZpmaPZlKQpmqG5mXpZl6CZmqq5mnvpHy9xlSlBm/9Am1Z5m1e5m7gJALXp m7mpm8I5nMR5EpNpEluZlV15lsq5nGNJllz5nGTpnNMpnck5lmZZnciJnc95lilxnd3JnWj/WR62 eRK22ZslgZ7n6ZsowZsm0ZvluRLXCZ3bWZ/R+Q9fSZ3RSZr4aZ3h2Z/22Zz1SZ3eyRLzqZ3jOR7x mZ7sOZzoKZzryaB/SZzw2aAG+p9ieaAA2p/HmZ/++Z3SCaD6KaDQSaIi+qEcGqIXSp8mmqDgsaAU yp4P6p4MGqM2qpswup/ZeZ8E+qEeap/GGaImOp8jKp4IuqFAuqJI2qIueh0RGqEOKqPA2aA0mptQ WpxY+qNEGp5Gmp0/yqEgGqRL+p/geaQk6qUYWqAayqRI2qTQEZjvOaE1GqU4Gpx1SqM3Gqf3GaA7 mqLgiaY6ypxCyqVFepwnyqeGaqhtup1D/0qoGOqmDJKjMyGpO1Ggi2GplgqpcESpMMGpOpGpiaGm KqqpdOSpLmGqNGGZmqGqpNqqrvqqsPpGsTmrtFqrNBaruJqrupoSttqrk7GrwBqswjqsxFqsxnqs EumryrqszNqszkpoyBqt0jqt1DqPz3qtbbEVqIql1RpqhokT22qq+ZAPKTGu5loS43oS6Yqu5kqu 3bpj5bmt7Wmhp0qvK7GuJoGv6Yqv/7Cu+uqu70peavmYBNGWBpuYhMmYi6mwjsmWBDsQ7Qqx+XAQ 40oQFVux2OqRfVmwjdmxgkmYa5mwIfuYB+uwFGuuEnuyFjuxGJux/dipcCqhVCqlNfqkM/87pyzh r+7Kr/narufKswH7XxJxsA3LmIhptEdbtBursvaAsU6Lsi3btCw7sVIbtS77kERLsh2btFqLtEi7 tAbhs1QbtRdLtQJRtit7te44mxZ6pXQKoTcLpW7brwBLt+zas3aLt3m7t0HbWA1hmBwbuF/7sYHp sAnrtUtLtmYrtlKbtmfrs2oLkmAbuZQrEpNbuZjrEZebuZzbuZ4rEn1rlJ87umgkAAJAuoZGlXKK FTD6rSshry5huihhurS7ErQruyVxuwKQu7q7u6F7RXNLFK17s0bRu/+Au8fruyeBvLLLvLuLvL+L RcOrp3Aas9Z7vXaKs7wZnBUqpdkbn7f/u7zKC728axLkm7zoG70LMrAH0bCH+75dK7Jb65fxu7Ej WxBF67UCcbsEYboD4b8FAcD2IMD/e7q9i7pJNrnuS7D2W78mq7+GK7/4S7gT/MAJQbv9e7r7q8EZ XMABzMEdjMBBpsAObMEMC7JdC8FHW8GBu7SG+bAHwb8DzMEEvMEevMEgHMIibGJsqxI2a55ta69y a6/cGp94irMx0bzPO77Ka75MXL4scb7qex5/W8IoLLgrbLRKC8Mq7MIUjMX528H+K8AAXMY0bMA5 PMM3vMMlprp2+q3xSq/Xq6cSOq+/acd3KrNBPLu668S1C8XJ+8e967t9PMWgJsWGfJOI/5zIjNzI wcHGkNwQjjzJlBxmkXzJmJzJmrzJjFbJnvzJoBzK+sHJpFzKkCzKqJzKqrzKzmHKl8zKGOnKkQzL tFzLRAa7hUHEtsw/VXy4CrG5Awu4HwHMBTvBJEzMsoxjYYwQyMy+lsvF9AuyxTzNhZnMNUYTOeq6 c8ytdByn3Cun2gzO4lybt2me5swSurzLkUrEwVul6Syp29vNePqgSJye5fye5/y66gwh4mylxAvE MtsS8DylAF2zxGuq8ZrPQJzO+5yWD0HCDyzMC9u+Dwu4DWyyL5zFCyGy1Ny+1nyrk8rOcXvQ2XvH 8kzQJ83NqCqj92zP6NzQ69zNBe3Pdf9czyY9pzRNxzn9tjbt0sB5ziyNzzBdHr28uRJduBpN0cZ8 xRy7mEitmEl9whHMllP90YrWzBeB1Wpp1fCo1Rbh1b/M1VnmFbgsEzE71Hsk1qSL1mzd1m791jWh 1qML13Rd1/ch159r19+I156r137914Cdynw92IRd2IZNaoGd2Iq92Izd2I792Pl02JEL2ZRd2ZZN qpI92Ze92ZwdIZn92aDtj53NcaFd2qbNjqOd2qptG5VQCcIR1EIdFAwtFLMNs7XtF7ft0jkB2/jY 2q5tEr6dE63dE74d3Dwx3CiB3ODq0+05mzbBzp363LqNzcs9r7jZ3AEt3eS83drN21n/4d1ikdv8 Y9wlQd42odw6odzofd7mXdw94d3iTd03Ed+xPd/VXd8/DdQKbdb8rRPgrRX0bRQB7iDu/Q8FXty/ jeC/beAIXt4HnuALvhLojdwN7uDmndwR7uDOrdtBDd84as/XPaUzW9IiLtRnrcdRup7cW85vvLoB Dc4q3dLQbc7iTaX4XOI+baUfjt0yztwtfeM0m911CuKtO+QLXaHePOLczeI7/uNbtBDFLRBR3toD QeW+LeWVYA9UjuUGYeVZruVfnhBbzuVj7uUNMeZVHuYJQbJUPZjV7OZgrL9f7OYMzMJw/rEd/eaX i+dtPud8/ubTXOdGDeeEnud/vtWA/+7n1VzRbE7Njd6YgB7RkF7n+Iu4fhnpkX7omk7oFV3MgInp YfMSw+3eo77gpQ7crq3eGc7gFr7qKTHhqW7qsQ4T683qzv3TNn7Pckzjzd22P77rJv7r2/3Ows7k N77fus7r+uzj1j2h8Y3ryR7swD7dIG7s0S7EsZ3f1G7tTh7tCq3t3A7uPB7u2y5GpX7qqm7rrJ7u DP7gtf7qEX7upO7q8F7vt27tHT7u4g7u/K7v1V7fzI7ivk7uA6/fx77s3q7jyt7kPszkvM3S097t 0J7r4J3rLI69u4nsFb/wF9/PS97v3e4gDLHlJJ/lZW7yYW7mZJ7yXx7lUK7mKk8QaP8u5mrO5VuN 54+O6YJe6Tvf5j5/54UOw5D+85tO556e50BP1dAs1YVu9EeP9EfP55R+6EF/6Tjf56De6E7f0UUf 6Jeu9E/PzJUO9j8PYiW/8mkO5mlf8iiP5Swv8zVv82o/92o/8whh92hu94nu9U3f82S/6CZc9VsP tkOf6H9usFWfwnwP+B69+Fuv547v6ETP+JP/9YJf+D7P5n4fskiP+Yaf+GHf6Ukb+W2F9y3v8ifv 9lcO5i5P966f5q3P+ie/+gWh4Kp/9o1/+Trv1Dwf6Jzf1J+usE0P1U19579f9NI89gwL6jofwVSv tRyd+1qf9AgL9dM/9EKf+YoJ/Y//n/1JnfwLG/7HTOfh/0WCAet+8e5kMeAhfxXs/9338f6nSkZs kfdxPxV6bxZLv9FPsf9TARAA7A0kWNDgQYQJFS5k2NDhw4cCIU6UONHiRYwZNW5M+M/jR5AhRY4k WdLkv0qVTq5k2dLlS5gvAcwEAJNmzZg5Pd7U2dPnT6BBhbLkOTQkTqNJlS5l2tTpU6hRpU6lWtXq VaxZtTrl2NXrV7BhxY4lW9bsWbRp1a5l21bsVrhx5c6lW9fuXbx57SKNyneoX6qA9QrlK1iwzcFN Dydm3DjrYpI4If+lvNOq5JGTCa/UnBOzYZk3Z/4D7fhj59MlUfc13fox4qmrOaeu/4rZ9c/CmT2D lH1btW/gwWE2rEjwpvHj9iQmVz4TYXKBNJFLNyh6IPTmy6Vrd369+fWK2KkntD6e+3Pq0btnL24c fHvv6sNv/85+evfo2d3bJ15Q/v7x/EvPvPrw0++95Q4M76DzGISOwP8QhI859cC7T8L4DmQPPrc6 9DAsDt0rLsERlduPvPpMLNE/FktcL8EMAdQuxvgWVGhG71Q8MccaRWSxOhN5FHHB9l5s8ccKc8xv RxSRAzBIKIWMEkcDjQTSSBuPlNJFJFNcUkogC4TxxyexJPNDNNPcKEQag/xSR4felDPMNueE0s4s 51yxyRXfpBPOOhmMUlAuzyxUyf8pA2VoTzcHPTPRO31kEtBGOfTTUEj1fDTMPAU9UdNJ1RRVzdmO 4ik30kgTbafRRFo1N1Rps0y0mlBFqtZVU7Vs1ld5M8m2XSVr1dfUYM2VWJp0g/Uo3nqlrVZkVS3q V2KDZRUwv2yVFdpnT422tGSZLfZbX2M9rahbuw1X11nLrVY4eD3qD9M+HX30UEqL1BLTSC391FFG Pa333n0pfe7PQPWdtF6GLWJ0zC3/HJPIgvG0V+EdLcYX40Z5tLhiSEcVmdSTsj2X3Va5bXfXbVVO 9VaTWWX35WhXtpZll3NmuWZr031XZ3NtxnZml4l2V2aanzV6ZnF3/kzWnZf2OWn/oXWOetyoYZba aK2rTXlblIummuph4zX7V3RHE5bbtWE2TG2p4TaV7XBjlXvaqdt2+upra1632a/VBbdsrINNNtt1 D+c18WundvVnw99OmXGcpR1Wcbsj69vVuxm3VW7Adc27b1zrjlvss28bmSw202x9ddhjj2jNUV9v y3bZc/cq9cfr6o134EvdLa7fFQv++NumRX55s4vnO7a/sVKe+cZ0t/567LPXfnvuuyeZevDDF398 8ss3/3z001d/fZ0oyh33RR32fi344Z9fdtxDrP9+/rGHOFS32O9G8huZABF2ERi97n/zWhhz+gcm jOSvSQx8YAXXQpTnwcV578Lg/1w2uEFxTQZYLYkZ1JgGHBCaUHO66SD72Peqy73scmkToekSN71l 3bBuNjSZ6QSnN85N7ms7PBwQLXfE6KFMaTDE1qlmSDimlZAoNAQWEHElw3RN7lxDFCLiuOg2KObK itLaouNcuLw4WQhRZpKUvQ7GxogNqY35SpGA5giqOGbMS0rSH8A8RicbJTBLMrojwjgWv0JSTI5q dBOVEmUlBe4xYA1bpB/daEFMvqVU2lpW4VwCNA520mZjQx3XjjZKKZpSaSf05M00By2fjXBoqsxa 08oIGVGKTpee1FblcjlCZZ0yiuTiZe9SeMbqzYuSigoQeuhTSHqBjFZu3Ngjrf9DMGj+rzye0tCR vpTATUFMPs08JDfNqTEJ2QlRf5zmwKpznGryC4+NTE8m7WmWDnJSmKmE3C9tCcpWspKWpBRoLYu5 y73NkoM0U5ltgobQsfVOhbb859aAuTRXZlGiEE3oPitKUH8WFJnjkyUqw6bEE2pNlIRT6SlBF1Go NVSmGDWoSSHa0hBO1HEOXWhJHzq6Yab0ZJnraEwrZ9Jeeg2gqmraED3atWOONF5/e5q6RBfDIBKU jE2EJbI6F7iNru2qdIPiEc1qN5Z+VaVlRSnOyiY5r7KVqrfUqVp/5sO9tXWMLZubVhXXV4cS8Ykc lSrv6DfBex4ssRU04GIbu1j/yDJWsZE9IGW399h7Ytaym7WeAzkroPV89nqeFS1/Snta1KZWtatl bWtd+1rYxla2s11sYW17W9zmVrcTNUoSSdiTqApvt7AZ7kJxU1y43A6CXfHX7DKiWfK0c7Lcgy5Y Bum65zp3uhCp7pPSSNvIdnchzf1uBMsSMPAS8JLa6+5jxdux9Hqvnj6qJ4HoSaIGvRM/AYKneehT 3xfZl0LwBCC9IBnaC5k2SVUKMIMnJjAEI+iR31kwgLmTn+tGqMIOTvCCVdRgBPc3wjoa0HYufB88 lXhCIk4wid8b3+wmjEiBlPG/5KlYfElSkWuUZoEzRuMMS0yNDF6YJIscZAM7/0lISYLvN99ZSRdd 98Mt2rEl0ctkQeqxmhybECM19mIYx1jLIKsUmae7QPgabMtdiuelzszmAd6YneHM1MUuyeWQTdi7 ZRbyw/LcJjpeecmE6lKe5+knQeuZx2FW03wTVuhxOqdIEXYnkrYZzWwqms+IHDQ9zVnnOcvomYvm FKX7bKhLr3PTY0Zxikf96CL/mY5pXvMcN9Rla4qH0SI7NKgv1Uc5c+rTtSb1rN18zkIzCc+RgjUz 7YxNVnc62CRCdqKbfW1cC3pgfib2cvdsMEDvWrk0kjSZqQ3NQVX624jucZn2ZSVv+xlQh3Rnlb+p zj4i+VPq1PSDIRjPZpe73f91VLUft41pCjtp2ck29nrFvZEpug2LXYxl47JWVrxFpnRgHKgRPQ66 hxp1lb6lItgWN1irCVSsQRRryi2OUZBnBl1za5vEi2a1v5rKrMxCqxdtTrqXT2+LcdUocveyURea US8gDG5gWCgT4xld6lJR6BkvunTguuYwv2s60qf+9ZB4BdeupRB1NQLmw263vF8h7cPd/na4x13u cz8L2O1+d7znXe9753vf/S5cvHAdXl0fTNcJT77D/70l5tVunEGrzRZvSu0U7B6a08549Tb+2+P1 ENrH4nm6d8h+tsOzwqzN+cxX3ttp0ax7U1/w2IEeRKFfXcQtjrecg0bpw6z/odqSWDpeBV1wwScj y8sow5cXX/l01aHk9touwV5x91fDPVi5akTLAT/5sOzhx7u4uORj8fh63RzNwd84ro5/54ofDqfB aWvLO3nYDqf1k3s06Pffn9komnS05W9pdMujQKOxPYq3U5OUSHo2OKoUSxkkdoMyMFnA//u/N7I3 QOo32mOLbCsYcPuji5EuRJokMyOxaKM/QOO2ylq3Pys9c4uY1mFB+lImHGtBYMO/A4Q9DCRByyO0 AEy3EcxAtBAwDhwxD5wPdjNCgYG2WdO/W0u3EUs1afO095jBIfEsGHQ2H3zBG5yy6HI0hou0czsn KGxCdcu1+pq3JySwHlSQ//K4JiDkCKi7Kd7TOLwapYiapaAJKehToa2rKCnKQ4qSQ1zyQ4/iqFKq KZBipaTiGZhqRJpCxLyqOtTpqqrruEcUpgxiv8Vzv4J7wLHrRB+UNXHawkIZxT3BGIHTozaiQFAU QYRLxY75xE/EwAWaj3+zQXd7M/hrQVK0sf3zGDwKsUSSvDf8vNCSNP9KRXpDsVDcEPQwLWZ0QgPh o2mcDme6L2lEwim8RlFrwP1qsCVsJlF8EBDzQNC6kxXrEwhBLAVTMWk7RkuDxyVLQwyLR4ApRwkr RjjURKNLPH78R4AMyKgTSIIsSIPcCn88SIVcSIZsSId8SIiMSIk0LH2sSP+LvMjT8omoSsiY4MiO DESg8EiRYg2t8K3amMj0QQ1w8aDfOEnjOq6nWAzn6YyrW4rSAC7EiUORRMm8UEkW2snfYsmX1Eio AEpjorqn04m00kmeXJ7R0b6zoion4ri2Gr8rWj+62jnuAyNc4iGu5LknqqLwOz+t9EqZE6xxab6h gUrmC8vHab6hW7+pFMtaKrqZi77la8qpAhusYsRuKabpI75HDKmr1KrZiKE8VLqGGsyiQyozIkym sqlyUUykMczKXMtVyqnCeUwlApqKi8yR1MvWoMS88ktX8quRdLk/tKhCPMzWLM0lgk1L1MOi6pnX lMzMtMxLFJuVjE3eXJn/pdqlkBPNu0ijeswU7EjCKjxDB3m1aUK4VeO35oRF6VRH5nxOLWtDNRRA dFpD6aw/7Oy0a7KvUtO1X4uRXqs/jIytejRFhlNBf5FFWYPOMFzCavvBNkuz+zwgV3Q2gPNOXESs 6rxFOztOMrHAg/Ox9bSnoKzKmVLE2qxKvjKXEnqpqqoa6hsql1rNrnFQQgTMUNLQ2NxMzOTDCOVQ ESUsOTyqpgLRkRtK4qQL7XLAKbRF/YpH9KrRbLzGE2MmgfNGY4NF5KRA0nLDAavGe1ySsrNOg5M8 /srHx0PC/CI4IzzFyevRU5THBd1S7hqt1Xs72XM8Lh3T1gpT6zLBhzPT/8kjUzYVLTU9O3Gcu7YL wjatUzu9UzzNUz3dUz7t09qKUUANVEEdVEItVODxU0RNVEUdCENtVEe1rUWNVEmdVEqtVEu9VEzN VE3dVE7tVE99iEcNVVEdVVItVVM9VVRNVVVdVVaVyE99VViNVVmdVVpViFa9VVzFi1rdVV7tVV/9 VWANVmEdVmItVmM9VmRNVtXKVWZt1q1QVmiNVmmdVmr1EGe9VmzNVm3dVtWpVm/9VoTgVnEdV3It V3M9V3RNV3VdV3ZtV3d9V5MAV3mVV3itV3tVipQAinwNiX0dTeJq0MYwyoA9S6J0yq+DiJRYi4Q1 iIUdiIZFiId12EqQWP+xSImIZS5nXK4XTE7M47QOAyTyZD3sWq+xaz3LetPWutiyuNiHVVmCYNmJ NQuXPbsoXNMspNm10zT1RFOMFRUtTMHXy6z1tNiYldiGJdqFRVqjTVqlZdiitQemtdiXjVmkpdqJ rdqpJdqlTYioldqlfdo4axhHK6cPq9IO88J3265j+0BTo0b8ujAu+UZvxFINGScF06/2xC9GqsIW i1Px4LB8jFt8PFIiBEKtpViovdqihdnEXVzHPYiWVdyppdijtdrGpdzHZVqItVrLndnJYhhFmkUv y8EcnTe1JVnU+5co867VrVkthCQCLdk62q8tkTJWvJIZG0YIvEKehTv/zU1cp53c4I1c4S2Iqk3Y ysVc4UXezG1ehvhd4PVcbjLSCdMfjg209/zcfwNBduRP8IS0ESTbTFPA6W1GfWtS4xw47N3FNRQ3 ltjXfiVaj4hflUAJpLVfkKBfkehX/NXf/q1f/P3fj8hX/5XfkYBfACZgAG4h3ZvM3zKWuQSrlkSo nKuanxI6sqpgnuKlY6E+b3lR9MtQOwQqkRMjjPtgpHoqTKSVS9y7qt1fldBfGV5g/81fGo7hBK5f BR5gHcZhHg5gIJ7fBf5hIN7hT9IpU6LJgeIbzRAjnntiyInio5HE03Q5pIPMFVWomzM5owLEflJh Fx3hsFI8/jViMz5j/x8mYouFYRsu4h4O4DUWYCGG4zM+4DeeY/6d46drYKypxODEuZ7STDGmqQq9 SSzGKdks5K2h4ItqTBZFUZnhzEgGYwzNJVpiK7wr4x6mXwN+4Tx+YX69YSGOYzru5DQu5Tg24FA2 YlS+458Mps1kuZIqy7dq5KZCYbeiHMBKypmbULjxubNsuezzZbaRqC1m0Uj8KoL94+37ZaJr5kPM LZkFW/6R3rNA2fvBZg2cV9lpijwGjm92OqkSWKS8V7O53+BA55IcKXIuZ3N+Z3iOZ3meZ3quZ3ue OvpBRik7LQkSWX7u2U/jNYDG2U/NJ6U0uZoMzRCODWQuGZqr4IHMyv8WsklM1kkqwksmvguZBNiD ZtaZNFGHBrx2Lp4+5K2kSCWfdIqNREQvFqqjWyHAG55HNU4Tm9t0+lG3lbAifbMI4Y8Nw7C3VVJ3 1FgqM1surLC+raxAktu7pd1tDNu6jdPs5Re16+kjdaYePeq37UadTkZKs7BoBNb8+9lO0c9YVMLs TKQMqzfUpSY7qjElQ1LYIy/5G0UxITfUW8DU/dnV678I/MVmbKQhK8CP+U9CscBXNWiFpmAQ9pue 6uUUPigTEstBVLkvbiUSzs2FTho85BlHppYlnuBhDiUc+ihMDNHMdOQLFc7bhGLcXNUqOmG8+sya ixyTDOOJs1CKomz/WX4eCs2+Y0YpJwZtmYql4RbuihZEjpZiXv4oE/Zjzz6ojQscFr5gDW5hQv2u WWTrdSps9+k21xW2E5xqQ7MkX/wYqN7AZwNssuZAMRUyMeXdZZy2TGsu+aTP+dzVsQZZcwQnG7Vr ZUNHWkTrB0PF+MNvVFxFyDtQG7PrTiFA8Q43uoZv7rxBZTSkZENs71Zw/j6UwqVVW/RbnC5CahTw tjPSckNxud5OYMRG/ThwVbze/TuPWnSgETlGu+3vp07HIYXxjFU2G0e2F3/qx4PSBy87aNRnKW3O IF1bbvbZDMTmMAUzbe7SJwdT2pNyOhU7/LlyLA+9Kt9y2ulyL9eI/3s+c0AtczU3VjRvc70M2i/l CDbR5jB/nydEILYT6P25vPV08kz6V0HuraN0Z5NWadBmit5kyiMGyauwYhg96d5W6dtGdKETbcRo 58TY6Ig+zZiUi8pG9FcG9KwjHuxe7KBA6Yg2Sn6C6Y/EdKuIE3IEMq7WahCbtJqOPB336YTjMa+e cwURE6aOdYrxaqyGUmckduWEQkESR46t61ivkfi8o+2kW2QnXLK16mpndh403Yz9W9FlNndcUhzp wMQSLkAmG67Zqd28zMHkSwfOKNB09JMRzF6q92JRbef+SXzPKchsaV3ibcAMzFge+He/w9t8GxNd zUDmbNwuzFVvzP8NNhykcXWsk27btETJzk1HJ83ZpOSCos2IZ2yfQm1Or+J1T8QRZWmhUe6M3+NI hFBLps2F/qmggsR/72OPvz67HHR4z8TzgWAfqqrqBpzrDvTpxsxi5mDX1s3LfvlFZvh7L23NNnkW 5vdCtGKiAs7JxGUR0ngL1m2f021q+RyIrnqQViWgF/uWLO4foktTPxsKcjP//utYo/scIzQlVd/0 5Gk5Y2v3jO/YdW9hy8/+3LS8t7X8jkZKAu/7HiDGT91chJO7L93IZ13tjXPUCnHwNUf7vDflVJQL DNAmU7TC/c/821nDLsPvjTXP/28BvzErtRDDxnAbnfF5Iv1l9PD/B6T7UOvvvc+jsnZwX5StZ0Jy B0TbqwbSWS/fj23wIb0zGbfxHB9sDDH2pObGnE72Hx3xVwvc4S9+L+TrEj9+A3Xx5J9OuLVGLJVq JP9F8EfSdNTSblLy815z9+lesdjnzlKLGiytOgcIewIFAhho0F7BgwoXMiTY8CHEiBInUqxoceC/ jBo3cuzo8SPIkCJHkixpkiQAkClPslyZ0SXLmDI/wpw5suZGnDZ38pSps6fJn/+E+gRq9ChSkxeX Mm3q9KlCAFITMqQKdaFVq1e3PtTK1aDWqV6/kiU7tmzDsFPNom3r9mrSuHLn0q1r9y7evHr38u3r 9y/gwIIHEy5s//gw4sSKFzNu7Pgx5MiSJ1OmTJTn5ceZA0/1uLnyyc8iP3cuKVqj0NNBk+okqhq0 YopZD4rNunZgbdxVJUoF6xusWNq8gyPE+vZsVOPF3y5n3hR5Rei6LUpXbv1r9evCkzf/7fw7+K2m OcKsubL8S/KoPaNEv/49/KE31b/uSZq9fLv19e5XP79lTKnJVZ+AHbkGG4IZTTQbVWN5VRByD65F nG8N6mbhbtI5iFBvDkHYYXEdgkjchwlRSNBtJ+Z2G4cgAmfidClOyOKHKHLXnIk0uohbii3yOKKO LP6Y445BQugjikBO+BuRDvZopIRKJlkijDQ6hGSJQ/4YHpddCv+EEn3xiSnfgf65t55Laea3poFs 4keemmTGKdVL57GZEp3puXmnnmaqeWafeKL5np2EnlcofHHmtOaBeZK5aJhiuofTn3AOeml6k/Kp 0lCVSrronOw5WqigmXqa6ZgJAsabdw2SyF1u3sUo63Iw4jgkht1h9eqss93qYYVM3lircgzS+iCx 2/maK7JHbphdiMFOJ+2V0yZ77HbAXkgtsb5myG1Y3FYL7pVHymqutl6qu+51uQqH7LDwelutue4K O25E6HZ776216WvrufiWW2GsL26bZIyxMpucs7giHFVwDCocMbazQgzwuFT2ZmyvBTvMMb7+Powj xRYTmXGLMkL/yy7LZdkmpLi6oqxsxdGmfFaTK9s88LLT6jszvAPDGvNuO5tsnb3R1lszyiBb+2+2 1xoX7sEB9wyd01DTSnN3WmNs9M9Rtzw2c/b+jPHX8wodMnC6nu22wOFeza+FWcfNL95a+7y30D3T i7TP6FLNYdeFu0py1F/3m7jhPCIOdrYbU1vk5GtLfnTd5CZNNucVjefmoaXV6Winou9ZZ+mU5lSq oaWZ1+fqrkOKp1iJto4oo+aJ/pPpobdGennA0z6q7W3C3lnontHJen61j9788gburnyayM++e/Sl Nz/674JOmn3s1Qev/fDEQ4+776iRrqpgC36nc+f5xt8W/PPb/38//vnr/9VqdfXn2P8gE0D2EbCA BoxMdNxSv/1tjYHUcSAEIyjBCUrwgBa8IAYzqMEN+oWCHvwgCEMowhGSkEscPCEKU6jCFXLwgzpb YFpKKMMZ0rCGNiwbiUR2s+Nox1pFY9UNgyjEIRJRiIMrXAO38kL5ua+ITnwiFKPIrv/QBFIhcZ72 pLc+Oc2pdsOjXvnUFz3TiTF9pkIdF8toKkQNkIVufCMcBVMm2M1HUW9C4/bQYz4zgcpSdHydodBI uzENElV0jCMiE6nIvAwHZmqBGcOa+LR0QY5XTkOiD/22OB9CzmhS/CQoQxlCtYlth0iizYmQCDVS 1mpFjGMawP8yl7Al9UqUtrwlLk0IoFR9qpfxAaSemCdM/KjOiqDzTzBtp8c+Eup0i3wmNKNpEyZO MpORE9w1Xyk4veUNbtYM2K8q6ThvwTCX5jwnOg/SHjLqjozPS54Wj9lM8m1KeqlTI6C4p89AoQmL 1jtTG6Up0IESVFUB5c9ODlrQhTK0oYhRKF76A1GHUrSilLFhKh1YznKms6MeFaVFQyrSkZLUKB89 KUpTqlIHlrSlLn0pTGMq05nSdKArvSlOc6rTnfK0pz79KVCDKtShEtUtNT0qUpOq1KUytalOfSpU oypV9hW1qla9qhSnqtWtcrUuWP0qWMMq1rGStaxh7Spa06r/1piYta1ufauX1irXudK1rna9K1fh qte98rWvfv0rYJ2D18EStrCGPSxi4xjYxTK2sY59LGQjK9nJUhakib0sZjOr2c1ytrOe/SxoQyva 0ZK2tKZdaGVTq9qcnra1rnXMamMr29nStra2vS1uc6vb5+wofxzl0m8pGNzd5vImtTlMgQbEy6Lk hXeH3N4KN4O7Xb62gNSU4HB/iJ3ObUhmQ1wiU7JLXPxRMXxnpM+h1CinfYbJdciTXZ4KOSr3Zs95 X0RvF+erX/VakVTEw2Lq7ntPLZpxvZ1ao3rva0dG3Q7Bz1tjGAm8z4lWF7nGO689D/yofv6yTeZD n4YFOV3o/24Yw7prZj5LPMz+GhK6rcHjin0JPUGGWHX/9eWpDKziZNaTmMas8EUhIrJLtqpqnbyb 3y65MK6J85s829rbOIlNeRWLXLD8GyWbJaxn2cxuVMZklcd7w/Iez5kMbnGJA2zj2ZUZmPmNL6bS DMw8HjfAD/aXh1s3Tz72E8Dy5DGDv2c9FItqw3gW9DzxDCfZAZmqQo6Xd7HcZIG9615K3psmV3ll T4KZ05Vmm9QsRslhqRLTmtvy1LoMaUtTupriFfMEg+ZpSWu6mlZGmzc3SThdHxlojbORLCkNMlt1 126bXtiw9RYhvmX5V8SumYiSCOsaOinaP8QQr7QUSVFnm//WCDtck2bmsHIFqZWu6i3QRuQ4VC4L kimbErM1tiVlxzBjKpMSvai0q222etoTlCqFNfi/gDeaoG19NRE36m+9AtyiEi04xCMu8YlTvOIU XzjGM865kfAjLh3XyMcRFHKQl2TkGTG5xVOemIjwYyEtF8jLKxJze8zcgzWn+URu/vKba7znH+S4 R0KOcpGMfOiUQbnRO4J0lTMdNB3nB9RPDvWpT/0fVSf5RopudaxvXegk9/rJlX51q0dd6lenetjL TvWljx3tYSf72btedrirfe5ZP3vbyS71pvOdJHP/ONj/zvW3p53rTzf81gmf9K5/PetK1zvhE3/3 xmP98JX/hzzjKS/5yG8e8J7nfN8vDpGZ73wgpTc9Q0iP+pazfvU4j3nrW/8Q2aO+9gahPc5XP/Xc w5z3ucd96VUv/IbUXPW8h73Pk+8UoF/+7VoPuuMLb3nGT//w07873gEf/bV3Pvrez7zzuw/+8Xt+ 6d/XvuJDr3KW37737jf+QeD/+vn3Pvaux73781//9g/f9r7XP/DtX+0FoPz9X/G13/H5n/It4FYY H/L53gNCYPwpYATmnwOaHu1loAZKIMzpHP8h4AbSnwDSXAa+3wQOoO21HMIx4G4xn+KVn9ul3+BJ nsmBHeIZXtSVH8jloNmNH9xtXuTBYOXxIPn1oA6+YN0J/176EZz6FdziiV9iPCFiSGETVuFIsNza ZaEWbiEXdqEXfiEYhqEYjiEZlqEZciELpiFEHAUVLkYMNsYbWqEcsoQa1qEdTsQc5qEe7iEf9qEf /iEgBqIgDiIhFiJH3CEiJqIiLiIjNqIjPiIkRqJuGSIlDpYkXuLCVaImbiIndqKjYSIohqIojiJZ eaIpniIqpqIqruJpkaIrviIsxqIsziItjg0r3uJR1aIuMhYu9qIv/iIwBqMwDiMxbuIuHiMyJqMy LiMzKmIxPiM0RuMcNiM1ipU0XuMiVaM2biM3dqNFmEQAhKM4BkBHjCNHiKNHoKNImONGsOM/jKM6 akQ8Zv+EOsLjPH6EPYZjO+ZjOtrjOeqjPKJjPtYjP67jPN5jQdIjQCokOQZkQ77jQmJjCk3EQAbA QYzjRYbjQoijRHCkQXikPVTkR2rkSFpkSA4kRIikQKjkQLDkSZrkS5pkRcokSj4EPLYkSa5kTb5k SfakTsKkN5oTSbgjRP5jRELkQ+5jUoZEPDalUy4kQgLkUy6lUTqkVTLkQ7qjVkrlU4LEVDLlVmbl VzKkQzbkQR6lRCrSPZYjPCplP1IlPgpkV7olWdLlWcLlVSJlXuplXealXEbkWu5lYJalWBZmVdZl W/JlX6alWqIlWxJlYA7mWypmZHLlUhJkUkomZUIlYFr/5mQiJVEq5mPSZVyyI2Z+JmZ65l4y5gZF BEg2hD36ZEYCZUreJE7S5k/mpk+CJEbCJkm+Jm965Gve5k8OZ0zGJk8Wp01q5G82J24mp3BapHPK ZlCulHHOpm4mJ3ZShG1m527mpG665EYi522S53VG53mqpHgqBEe253SyZ06650lqp3dW5y2NhGby 5VweJjgeZWWapX9aZmiWpj9iZVTCZWqipWQmJFgCqH465lTqY4GuJmtmkGuC53iaJ4bW54XSZnrS pIdOZ28uJ0z2pnuC54cW53BeZ26OqG+CKHpmaHkyZ3dyqH1+FIuqqG2maEWs6IZCJ4bGKH0yBHC+ Z5E+/2eMumiOCimJzqiNBidGkqeN3ugnDaVjLuZpjuZJrOWBrmaWiuZnIiZnZmaAGqZoLuiYGmRh pilpYiVhVigcdWSReieTUqec4uaI5imUgqidbmdM0ml87ilxZueSouiPDqpyJuqflmSJ5iiV3pRI KumJxuZ6+imj1uhx6ilQuuhsauim7mmNCmqmmqihHip9Smo+wmegbqijPqoT9WdicqmEDiRoJqZX XimDEmZnXuZg0qqXRmiZKiU5zuRigmZpCqtRDqixuil/wqmFuiq0epSzTisGRau1Xiu2Zqu2biu3 dqu3fuslUqu4GhC4lqu5niu6pqu6riu7tqu7viu88qnVuM6rqsSrvc4Pvearvu6rUt2rv5INvwYs bP0rwa6LwB5sbBSswuoSwjaswz6sIi2sxE4sxYYQxF4sxmZsa1Ysx/KPxn6sV3WsyEIFyJasXIws yqasyq4sy7asy74szP6byc6sScWszdIszuaszvaFzd7szv4s0AYtUPQs0Rat0R5txQqt0noE0jat 0xbs0katRjxtykqt1V4t1mZtzlIt13at136tNwYEADs= ------=_NextPart_000_0008_01C71D11.98AC0B90-- From ips-bounces@ietf.org Mon Dec 11 11:40:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtoCT-0004DY-Rj; Mon, 11 Dec 2006 11:40:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtoCS-0004Af-4b for ips@ietf.org; Mon, 11 Dec 2006 11:40:20 -0500 Received: from web51908.mail.yahoo.com ([206.190.48.71]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gto7F-0000j7-Nv for ips@ietf.org; Mon, 11 Dec 2006 11:34:59 -0500 Received: (qmail 92738 invoked by uid 60001); 11 Dec 2006 16:34:56 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=yURDlOj61yKGCANVnDwUn2K1QkanXip/rT9PIYfn4Hz8muHegBRhgitELyOciTLjKcPQWQ9VIt6BVMT/tclzyn2fkmKUuyc0RWGraJeLPXJsm3Bjq/frAY0bXkdbrOGLTZsJdNGEb1njEQTG7X0JSFZMPnE07aRiE81+cFoJKqs= ; Message-ID: <20061211163456.92733.qmail@web51908.mail.yahoo.com> Received: from [15.203.169.126] by web51908.mail.yahoo.com via HTTP; Mon, 11 Dec 2006 08:34:56 PST Date: Mon, 11 Dec 2006 08:34:55 -0800 (PST) From: "Mallikarjun C." Subject: Re: [Ips] Implementer's Guide - Task Management Issue To: ips@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org David,=0A=0ASorry for the delay in getting back. Between vacation and othe= r travel, it took me a while. Thanks for the comments.=0A=0AYou wrote this= regarding fast multi-task abort:=0A>This property is=0A>useful even if the= new key is not negotiated (and hence the=0A>AsyncEvent 5 message is not us= ed for fast abort of data transfers)=0A=0AI assume this is essentially what= you are proposing that we consider (fast =0A=0AThe reason we decided a new= key is needed here was for two reasons:=0A1. Whenever TMF does a fast comp= letion, target needs an (eventual) deterministic confirmation that data tra= nsfers had stopped. The confirmation is Nop-Out, and the negotiation for t= he new Nop-Out is via the FastMultiTaskAbort key.=0A2. The initiator requir= ement in the "classic" case (i.e. key not negotiated) is that it respond to= each TTT for affected tasks even while the task is "affected". We wanted = an opposite behavior, but with a confirmation that the data transfers had s= topped (so target can recover the buffer resources). The key allows this n= ew behavior on initiator's part as well.=0A=0A>This is approximately=0A>wha= t is described in the Implementation Note at the end of=0A>Section 4.1.3, a= lthough that note may have been intended to=0A>be iSER-specific - if so, th= is is a proposal to apply it to=0A>iSCSI without the RDMA extensions.=0A=0A= Actually the note is intended for all iSCSI implementations. After seeing = your observation, I decided that it needs improvement, I propose the follow= ing new text:=0A=0A"Implementation note: Technically, the TMF servicing is = complete in Step.e. Data transfers corresponding to terminated tasks may h= owever still be in progress even at the end of Step.f. TMF Response MUST N= OT be sent by the target iSCSI layer before the end of Step.e, and may be s= ent at the end of Step.e despite these outstanding Data transfers until Ste= p.g. These data transfers, if any, MUST be silently discarded by the targe= t iSCSI layer. In the case of iSCSI/iSER, these transfers would be into ta= gged buffers with STags not owned by any active tasks. Step.g specifies an= event to free up the resources. A target may, on an implementation-define= d internal timeout, also choose to drop the connections on which it did not= receive the expected Nop-Out acknowledgements so as to reclaim the associa= ted buffer, STag and TTT resources as appropriate."=0A=0ANow that I read th= e text after a long time, I spotted an unintended double negative in sectio= n 4.1.3, target behavior, bullet d-ii. The text should read:=0A"ii) each c= onnection except the issuing connection of the issuing session that has at = least one allegiant affected task." (i.e. drop "non" from "non-issuing")= =0A=0AThe other thing that came to my mind after reading your note is that = we don't currently have a generic key to capture the Response Fence behavio= r - although response fencing underlies both the fast multi-task abort as w= ell as addressing ACA race conditions (and perhaps others down the road. e.= g. around persistent reservations). So, today, the Note at the end of sect= ion 3.3.3 advises that implementations may check the FastMultiTaskAbort key= to verify if safe behavior for MCS ACA is supported, although ACA has real= ly nothing to do with multi-task aborting. I am wondering if we should cre= ate a new key (say ResponseFence), so the semantics would become:=0A = =0A Re= sponseFence "Yes" fencing done by target =0A = "No" legacy, no fencing (so "clarified" TMF semantics are no= t possible either)=0A =0AWith ResponseFence=3D "Yes"=0AFastMultiTa= skAbort =0A "Yes" fast abort & fencing = =0A "No" traditional wait on outstanding TTTs = (fencing on ACA is still possible)=0A=0AWith ResponseFence=3D "No"=0AFas= tMultiTaskAbort =0A "Yes" Illegal, Response Fenc= e must be "Yes"=0A "No" No fencing, must wait on o= ustanding TTTs=0A =0A=0AThe downside of this scheme is that it may be goin= g in the opposite direction than you wanted (introduces a second key that 3= 720-compliant implementations don't know about). We could alternatively si= mply mandate the behavior equivalent to ResponseFence =3D "Yes" always and = avoid the second key, but doing so could make the current 3720-compliant im= plementations technically non-iSCSI-compliant.=0A=0AComments?=0A=0AMallikar= jun =0A=0A----- Original Message ----=0AFrom: "= Black_David@emc.com" =0ATo: ips@ietf.org=0ACc: Black_D= avid@emc.com=0ASent: Wednesday, November 22, 2006 2:00:25 PM=0ASubject: [Ip= s] Implementer's Guide - Task Management Issue=0A=0A=0ATo make sure we actu= ally have some content to talk about in=0Athis WG Last Call, I'm going to r= eraise an issue that came=0Aup earlier on the mailing list, but (as far as = I can recall)=0Anever got resolved. This is done with my WG chair hat OFF,= =0Aand it is a proposal for further discussion.=0A=0ASection 4.1.3 changes = task management, and is a non-transparent=0Achange - it requires negotiatin= g a new key so that both sides=0Aagree that they support the change as it u= ses a round-trip=0Aexchange of a new message (AsyncEvent 5) between initiat= or and=0Atarget to abort in-progress data transfers rather than completing= =0Athem. Absent this message, the target expects the initiator(s)=0Ato com= plete all in-progress transfers, and is entitled to be=0Aunhappy or worse i= f that doesn't happen.=0A=0AFor task management functions that affect tasks= from more than=0Aone initiator (CLEAR TASK SET, TARGET WARM RESET, TARGET = COLD=0ARESET) Section 4.1.3 also allows the task management function=0A(TM= F) to complete while the in-progress data transfers are still=0Abeing dealt= with, which has the useful effect of avoiding a=0Asituation in which an un= cooperative initiator can stall the=0Aprogress of a TMF sent by another ini= tiator. This property is=0Auseful even if the new key is not negotiated (a= nd hence the=0AAsyncEvent 5 message is not used for fast abort of data tran= sfers)=0Aalthough I think the target behavior is subtly different between= =0Athe initiator that sent the TMF and other initiators in this case:=0A- F= or the TMF sender, the target must wait for all outstanding=0A transfers= to complete before completing the TMF, otherwise=0A the TMF completion = comes back too early for an unmodified=0A initiator.=0A- For the other i= nitiators, the data transfers can be immediately=0A redirected to bit bu= ckets so the TMF can be completed without=0A waits beyond that for the T= MF sender. This is approximately=0A what is described in the Implementa= tion Note at the end of=0A Section 4.1.3, although that note may have be= en intended to=0A be iSER-specific - if so, this is a proposal to apply = it to=0A iSCSI without the RDMA extensions.=0A=0AHigh Availability clust= ering environments in which TMFs are being=0Aused to determine cluster memb= ership (yes, there's code out there=0Athat does this, even though everyone = should be using PERSISTENT=0ARESERVE) are a specific situation where this h= elps, as having to=0Await for a dead initiator to expire (the TCP connectio= n(s) have=0Ato timeout and get torn down) slows down cluster recovery from = a=0Afailure. This change in target behavior (to complete a TMF faster=0Aif= other initiators don't cooperate) should be transparent to=0ARFC 3720-comp= liant initiators, but RFC 3720 has to be modified=0Ain order to allow it; t= he Implementer's Guide is a vehicle that=0Acan make that modification.=0A= =0AThis is proposed for further discussion.=0A=0AThanks,=0A--David=0A------= ----------------------------------------------=0ADavid L. Black, Senior Tec= hnologist=0AEMC Corporation, 176 South St., Hopkinton, MA 01748=0A+1 (508)= 293-7953 FAX: +1 (508) 293-7786=0Ablack_david@emc.com M= obile: +1 (978) 394-7754=0A------------------------------------------------= ----=0A=0A_______________________________________________=0AIps mailing lis= t=0AIps@ietf.org=0Ahttps://www1.ietf.org/mailman/listinfo/ips=0A=0A=0A =0A_= ___________________________________________________________________________= ________=0ADo you Yahoo!?=0AEveryone is raving about the all-new Yahoo! Mai= l beta.=0Ahttp://new.mail.yahoo.com _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Mon Dec 11 12:34:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gtp2d-0007JJ-GE; Mon, 11 Dec 2006 12:34:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gtp2c-0007JE-4Q for ips@ietf.org; Mon, 11 Dec 2006 12:34:14 -0500 Received: from web51914.mail.yahoo.com ([206.190.48.77]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gtp2a-0003WX-M3 for ips@ietf.org; Mon, 11 Dec 2006 12:34:14 -0500 Received: (qmail 44664 invoked by uid 60001); 11 Dec 2006 17:34:07 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=mC1q81EsOvr3m1NsUNcBqukcqf5ASfQGcM8+RClklsS+RB52IWU6APOU8Mg6Eo1iPfeOKqoVpoBEiFPCLaXdTGtpNWhlJ54ZnB2soRGxjCjoRmXHSFpO/ltBRL1lIWatHlNIeFSH8Bx10W31wChfKq4iQ1aA90SeTPJrQGv8gGc= ; Message-ID: <20061211173407.44662.qmail@web51914.mail.yahoo.com> Received: from [15.203.169.126] by web51914.mail.yahoo.com via HTTP; Mon, 11 Dec 2006 09:34:07 PST Date: Mon, 11 Dec 2006 09:34:07 -0800 (PST) From: "Mallikarjun C." Subject: Re: [Ips] ips WG Last Call: iSCSI Implementer's Guide To: ips@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org Lars,=0A=0AThanks for the comments and sorry for the delay in getting back.= =0A=0AAs far as volunteers for reviewing, we could request the contributors= at the end of the document to review. David may have already reviewed, ba= sed on his comments. Julian Satran had some offline feedback for me on TMF= topics. As the editor of the document, I was sure that each of the topics= were discussed in detail (or at least clearly noted) on the list before I = included them in the doc. Hope that gives you some reassurance.=0A=0A>whet= her it is merely the original text that can be=0A>misunderstood or if there= is a technical error in the original text.=0A> (It already does in some ca= ses.)=0A=0AYes, I'd appreciate if you could point out where you think addit= ional clarifications could help.=0A=0A> OK, so this document not only updat= es 3720, but also 3721, 3722 and=0A> 3723? That needs to be stated in the d= ocument header and abstract.=0A> (Also, 3721 needs to be normatively cited = in this case.)=0A=0AWe could. My intent was to make it clear that this doc= ument prevails whenever a subtle interpretation in future of one of these R= FCs differs from what's in this document. Now that we are nearing the end = of the work on this document, we could delete some although I personally am= tempted to leave it this way....from what I can think of today though, thi= s doc updates 3720 and 3721, but does not update 3722 and 3723.=0A=0A3721 i= s not a standards-track RFC and I wasn't sure if it needs to be normatively= cited as such. But I could if that's the right thing to do.=0A=0A>Sugges= t to find a better title, because implementer's guides don't=0A>typically u= pdate the base specification in a normative way. (Maybe=0A> "iSCSI Correcti= ons and Implementer's Guide" or something like that?)=0A=0AFIne by me. How= about "iSCSI Corrections, Clarifications, Additions and Implementation Gui= dance", or is it too long? If it is, we could try "iSCSI Changes Based on = Implementers' Experience" or something like it.=0A=0A> The specification of= the fence mechanisms should use RFC2119 terms,=0A> especially in Section 3= .3.2.=0A=0AIt actually does, with a MUST preceding the bulleted list.... A= s far as 3.3.1, I intentionally left the model description very generic wit= h the hope that it can be incorporated into a future T10 spec verbatim.=0A= =0A> Nit: s/mult/multi-/=0A=0ADone.=0A=0A> I'm not sure if "should receive"= describes something that should be=0A> started in RFC2119 language or not.= If that is the intent, a better=0A> phrasing should be found. (Also elsewh= ere in this document where the=0A> same phrasing is used.)=0A=0AI left the = "should"s intentionally in, because they really are the prerogatives of the= initiator's run-time behavior, i.e. initiator may at his discretion choose= to discard a message for some other reason (e.g. bad digest) beyond the 21= 19 protocol requirements. =0A=0A>Should the sentence starting with "SHOULD = NOT" start a new item in=0A> this list?=0A=0ANo, I don't think so. This bul= let is all about waiting for missing CmdSN's. It happens to have a differe= nt prescription for third-party affected sessions.=0A=0A>Remove text after = "considerations" to not confuse IANA. May want=0A> to add a note to the RFC= Editor to remove this section upon =0A>publication.=0A=0ADone.=0A=0A> Nit= : Cited also as [RFC 3720], which confuses idnits. Remove the =0Aspace=0A>= in the other citations.=0A=0ADone.=0A=0A>iSER Not cited.=0A=0AIt does n= ow.=0A=0A> ID does not include the required 2119 boilerplate. Also, 2119 sh= ould=0A> be cited normatively.=0A=0AFixed now.=0A=0A=0AMallikarjun=0A=0A=0A= =0A=0A=0A=0A=0A=0A=0A----- Original Message ----=0AFrom: Lars Eggert =0ATo: ips@ietf.org=0ASent: Friday, December 1, 2006 4= :57:59 PM=0ASubject: Re: [Ips] ips WG Last Call: iSCSI Implementer's Guide= =0A=0A=0ASummary: Minor revision needed to address editorial issues. Note: = I'm=0A no iSCSI expert, so I cannot fully review the technical=0A recom= mendations made in this document. I'd like to see at least one=0A other r= eview from someone who has the necessary background before =0Athis=0A do= cument moves forward - volunteers?=0A=0A Contains non-ASCII characters, b= oilerplate issues and other idnits.=0A Please fix. Header should indicate= that this document updates 3720=0A and potentially other IDs (abstract a= lready partially does - good!)=0A=0A It would be good if this document wo= uld state for each item it=0A discusses, whether this is a clarification = to the original RFCs or a=0A correction, i.e., whether it is merely the o= riginal text that can be=0A misunderstood or if there is a technical erro= r in the original text.=0A (It already does in some cases.)=0A=0A=0AINTRO= DUCTION, paragraph 1:=0A> iSCSI Implementer's Guide= =0A=0A Suggest to find a better title, because implementer's guides don't= =0A typically update the base specification in a normative way. (Maybe=0A= "iSCSI Corrections and Implementer's Guide" or something like that?)=0A= =0A=0ASection 2, paragraph 2:=0A> iSCSI implementers are required to ref= erence [RFC3722] and=0A> [RFC3723] in addition to [RFC3720] for mandator= y requirements.=0A> In addition, [RFC3721] also contains useful informat= ion for=0A> iSCSI implementers. The text in this document, however, upd= ates=0A> and supersedes the text in all the noted RFCs whenever there is= =0A> such a question.=0A=0A OK, so this document not only updates 3720= , but also 3721, 3722 and=0A 3723? That needs to be stated in the documen= t header and abstract.=0A (Also, 3721 needs to be normatively cited in th= is case.)=0A=0A=0ASection 3.3, paragraph 0:=0A> 3.3 SCSI Protocol Interfac= e Model for Response Ordering=0A=0A The specification of the fence mechan= isms should use RFC2119 terms,=0A especially in Section 3.3.2.=0A=0A=0ASe= ction 3.3.3, paragraph 4:=0A> 2. The TMF Response carrying the mult-ta= sk TMF Response on the=0A> issuing session.=0A=0A Nit: s/mult/mult= i-/=0A=0A=0ASection 4.1.2, paragraph 4:=0A> b. Should receive any resp= onses that the target may provide=0A> for some tasks among the a= ffected tasks (may process them=0A> as usual because they are gu= aranteed to have=0A> chronologically originated prior to the TMF= response).=0A=0A I'm not sure if "should receive" describes something th= at should be=0A started in RFC2119 language or not. If that is the intent= , a better=0A phrasing should be found. (Also elsewhere in this document = where the=0A same phrasing is used.)=0A=0A=0ASection 4.1.2, paragraph 8:= =0A> b. MUST wait (concurrent with the wait in Step.a) for all=0A> = commands of the affected tasks to be received based on the=0A> = CmdSN ordering. SHOULD NOT wait for new commands on=0A> = third-party affected sessions - only the instantiated =0Atasks=0A> = have to be considered for the purpose of determining the=0A> = affected tasks. In the case of target-scoped requests=0A> (i.= e. TARGET WARM RESET and TARGET COLD RESET), all the=0A> command= s that are not yet received on the issuing session=0A> in the co= mmand stream however can be considered to have=0A> been received= with no command waiting period - i.e. the=0A> entire CmdSN spac= e up to the CmdSN of the task management=0A> function can be "pl= ugged".=0A=0A Should the sentence starting with "SHOULD NOT" start a new = item in=0A this list?=0A=0A=0ASection 4.1.3, paragraph 8:=0A> a. MUS= T wait for all commands of the affected tasks to be=0A> received = based on the CmdSN ordering on the issuing=0A> session. SHOULD N= OT wait for new commands on third-party=0A> affected sessions - o= nly the instantiated tasks have to be=0A> considered for the purp= ose of determining the affected=0A> tasks. In the case of target= -scoped requests (i.e. TARGET=0A> WARM RESET and TARGET COLD RESE= T), all the commands that=0A> are not yet received on the issuing= session in the command=0A> stream however can be considered to h= ave been received with=0A> no command waiting period - i.e. the e= ntire CmdSN space up=0A> to the CmdSN of the task management func= tion can be=0A> "plugged".=0A=0A Should the sentence starting w= ith "SHOULD NOT" start a new item in=0A this list?=0A=0A=0ASection 11, pa= ragraph 1:=0A> This draft does not have any specific IANA considerations = other =0Athan=0A> those already noted in [RFC3720].=0A=0A Remove text = after "considerations" to not confuse IANA. May want=0A to add a note to = the RFC Editor to remove this section upon =0Apublication.=0A=0A=0ASection= 12.1, paragraph 1:=0A> [RFC3720] Satran, J., Meth, K., Sapuntzakis, C= ., Chadalapaka,=0A> M., and E. Zeidner, "Internet Small Computer = Systems=0A> Interface (iSCSI)", RFC 3720, April 2004.=0A=0A Nit= : Cited also as [RFC 3720], which confuses idnits. Remove the =0Aspace=0A = in the other citations.=0A=0A=0ASection 12.2, paragraph 1:=0A> [RFC3= 721] Bakke, M., Hafner, J., Hufferd, J., Voruganti, K.,=0A> and M= . Krueger, "Internet Small Computer Systems Interface=0A> (iSCSI)= Naming and Discovery", RFC 3721, April 2004.=0A=0A See above, if this ID= updates 3721, it needs to normatively cite it.=0A=0A=0ASection 12.2, parag= raph 2:=0A> [iSER] Ko, M., Chadalapaka, M., Elzur, U., Shah, H., Thale= r,=0A> P., J. Hufferd, "iSCSI Extensions for RDMA", IETF=0A> = Internet Draft draft-ietf-ips-iser-04.txt (work in=0A> prog= ress), June 2005.=0A=0A Not cited.=0A=0A=0ASection 12.2, paragraph 3:=0A= > [RFC2119] Bradner, S. "Key Words for use in RFCs to Indicate=0A> = Requirement Levels", BCP 14, RFC 2119, March 1997.=0A=0A ID does n= ot include the required 2119 boilerplate. Also, 2119 should=0A be cited n= ormatively.=0A_______________________________________________=0AIps mailing= list=0AIps@ietf.org=0Ahttps://www1.ietf.org/mailman/listinfo/ips=0A=0A=0A = =0A________________________________________________________________________= ____________=0ADo you Yahoo!?=0AEveryone is raving about the all-new Yahoo!= Mail beta.=0Ahttp://new.mail.yahoo.com _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Mon Dec 11 12:37:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gtp5P-0008Mh-73; Mon, 11 Dec 2006 12:37:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gtp5N-0008Mc-LN for ips@ietf.org; Mon, 11 Dec 2006 12:37:05 -0500 Received: from web51905.mail.yahoo.com ([206.190.48.68]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gtp5M-0003zq-6a for ips@ietf.org; Mon, 11 Dec 2006 12:37:05 -0500 Received: (qmail 93183 invoked by uid 60001); 11 Dec 2006 17:37:04 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=be1W3k4QF/pWWRSgrshUKoNDXzQHFdkYLW7Oeos1y8QUziTvLrIcmexO1HpcR8KgD/op7pIlwGzOH4zkfU48NT/uHxYbVpGPcHGJWjJQCOjlC/chL5M5DJ3ibl8hQqEcn3br6IpAHjluvCEIR8EN6+7Gnjma2Kv9LDsbHe9gnKQ= ; Message-ID: <20061211173704.93181.qmail@web51905.mail.yahoo.com> Received: from [15.203.169.126] by web51905.mail.yahoo.com via HTTP; Mon, 11 Dec 2006 09:37:04 PST Date: Mon, 11 Dec 2006 09:37:03 -0800 (PST) From: "Mallikarjun C." Subject: Re: [Ips] Implementer's Guide - Task Management Issue To: ips@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org I noticed one clipped sentence, I meant:=0A=0A"I assume this is essentially= what you are proposing that we consider (fast multi-task abort with outsta= nding TTTs always, even without the key negotiation)."=0A=0ARest looks alri= ght.=0A=0AMallikarjun=0A=0A=0A----- Original Message ----=0AFrom: Mallikarj= un C. =0ATo: ips@ietf.org=0ASent: Monday, Decembe= r 11, 2006 8:34:55 AM=0ASubject: Re: [Ips] Implementer's Guide - Task Manag= ement Issue=0A=0A=0ADavid,=0A=0ASorry for the delay in getting back. Betwe= en vacation and other travel, it took me a while. Thanks for the comments.= =0A=0AYou wrote this regarding fast multi-task abort:=0A>This property is= =0A>useful even if the new key is not negotiated (and hence the=0A>AsyncEve= nt 5 message is not used for fast abort of data transfers)=0A=0AI assume th= is is essentially what you are proposing that we consider (fast =0A=0AThe r= eason we decided a new key is needed here was for two reasons:=0A1. Wheneve= r TMF does a fast completion, target needs an (eventual) deterministic conf= irmation that data transfers had stopped. The confirmation is Nop-Out, and= the negotiation for the new Nop-Out is via the FastMultiTaskAbort key.=0A2= . The initiator requirement in the "classic" case (i.e. key not negotiated)= is that it respond to each TTT for affected tasks even while the task is "= affected". We wanted an opposite behavior, but with a confirmation that th= e data transfers had stopped (so target can recover the buffer resources). = The key allows this new behavior on initiator's part as well.=0A=0A>This i= s approximately=0A>what is described in the Implementation Note at the end = of=0A>Section 4.1.3, although that note may have been intended to=0A>be iSE= R-specific - if so, this is a proposal to apply it to=0A>iSCSI without the = RDMA extensions.=0A=0AActually the note is intended for all iSCSI implement= ations. After seeing your observation, I decided that it needs improvement= , I propose the following new text:=0A=0A"Implementation note: Technically,= the TMF servicing is complete in Step.e. Data transfers corresponding to = terminated tasks may however still be in progress even at the end of Step.f= . TMF Response MUST NOT be sent by the target iSCSI layer before the end o= f Step.e, and may be sent at the end of Step.e despite these outstanding Da= ta transfers until Step.g. These data transfers, if any, MUST be silently = discarded by the target iSCSI layer. In the case of iSCSI/iSER, these tran= sfers would be into tagged buffers with STags not owned by any active tasks= . Step.g specifies an event to free up the resources. A target may, on an= implementation-defined internal timeout, also choose to drop the connectio= ns on which it did not receive the expected Nop-Out acknowledgements so as = to reclaim the associated buffer, STag and TTT resources as appropriate."= =0A=0ANow that I read the text after a long time, I spotted an unintended d= ouble negative in section 4.1.3, target behavior, bullet d-ii. The text sh= ould read:=0A"ii) each connection except the issuing connection of the issu= ing session that has at least one allegiant affected task." (i.e. drop "= non" from "non-issuing")=0A=0AThe other thing that came to my mind after re= ading your note is that we don't currently have a generic key to capture th= e Response Fence behavior - although response fencing underlies both the fa= st multi-task abort as well as addressing ACA race conditions (and perhaps = others down the road. e.g. around persistent reservations). So, today, the= Note at the end of section 3.3.3 advises that implementations may check th= e FastMultiTaskAbort key to verify if safe behavior for MCS ACA is supporte= d, although ACA has really nothing to do with multi-task aborting. I am wo= ndering if we should create a new key (say ResponseFence), so the semantics= would become:=0A = =0A ResponseFence "Yes" fencing done by target = =0A "No" legacy, no fencing (so "clarif= ied" TMF semantics are not possible either)=0A =0AWith ResponseFence= =3D "Yes"=0AFastMultiTaskAbort =0A "Yes" fast= abort & fencing =0A "No" traditional= wait on outstanding TTTs (fencing on ACA is still possible)=0A=0AWith Resp= onseFence=3D "No"=0AFastMultiTaskAbort =0A "Yes" = Illegal, Response Fence must be "Yes"=0A "No" = No fencing, must wait on oustanding TTTs=0A =0A=0AThe downside of this sch= eme is that it may be going in the opposite direction than you wanted (intr= oduces a second key that 3720-compliant implementations don't know about). = We could alternatively simply mandate the behavior equivalent to ResponseF= ence =3D "Yes" always and avoid the second key, but doing so could make the= current 3720-compliant implementations technically non-iSCSI-compliant.=0A= =0AComments?=0A=0AMallikarjun =0A=0A----- Origi= nal Message ----=0AFrom: "Black_David@emc.com" =0ATo: = ips@ietf.org=0ACc: Black_David@emc.com=0ASent: Wednesday, November 22, 2006= 2:00:25 PM=0ASubject: [Ips] Implementer's Guide - Task Management Issue=0A= =0A=0ATo make sure we actually have some content to talk about in=0Athis WG= Last Call, I'm going to reraise an issue that came=0Aup earlier on the mai= ling list, but (as far as I can recall)=0Anever got resolved. This is done= with my WG chair hat OFF,=0Aand it is a proposal for further discussion.= =0A=0ASection 4.1.3 changes task management, and is a non-transparent=0Acha= nge - it requires negotiating a new key so that both sides=0Aagree that the= y support the change as it uses a round-trip=0Aexchange of a new message (A= syncEvent 5) between initiator and=0Atarget to abort in-progress data trans= fers rather than completing=0Athem. Absent this message, the target expect= s the initiator(s)=0Ato complete all in-progress transfers, and is entitled= to be=0Aunhappy or worse if that doesn't happen.=0A=0AFor task management = functions that affect tasks from more than=0Aone initiator (CLEAR TASK SET,= TARGET WARM RESET, TARGET COLD=0ARESET) Section 4.1.3 also allows the tas= k management function=0A(TMF) to complete while the in-progress data transf= ers are still=0Abeing dealt with, which has the useful effect of avoiding a= =0Asituation in which an uncooperative initiator can stall the=0Aprogress o= f a TMF sent by another initiator. This property is=0Auseful even if the n= ew key is not negotiated (and hence the=0AAsyncEvent 5 message is not used = for fast abort of data transfers)=0Aalthough I think the target behavior is= subtly different between=0Athe initiator that sent the TMF and other initi= ators in this case:=0A- For the TMF sender, the target must wait for all ou= tstanding=0A transfers to complete before completing the TMF, otherwise= =0A the TMF completion comes back too early for an unmodified=0A init= iator.=0A- For the other initiators, the data transfers can be immediately= =0A redirected to bit buckets so the TMF can be completed without=0A = waits beyond that for the TMF sender. This is approximately=0A what is = described in the Implementation Note at the end of=0A Section 4.1.3, alt= hough that note may have been intended to=0A be iSER-specific - if so, t= his is a proposal to apply it to=0A iSCSI without the RDMA extensions.= =0A=0AHigh Availability clustering environments in which TMFs are being=0Au= sed to determine cluster membership (yes, there's code out there=0Athat doe= s this, even though everyone should be using PERSISTENT=0ARESERVE) are a sp= ecific situation where this helps, as having to=0Await for a dead initiator= to expire (the TCP connection(s) have=0Ato timeout and get torn down) slow= s down cluster recovery from a=0Afailure. This change in target behavior (= to complete a TMF faster=0Aif other initiators don't cooperate) should be t= ransparent to=0ARFC 3720-compliant initiators, but RFC 3720 has to be modif= ied=0Ain order to allow it; the Implementer's Guide is a vehicle that=0Acan= make that modification.=0A=0AThis is proposed for further discussion.=0A= =0AThanks,=0A--David=0A----------------------------------------------------= =0ADavid L. Black, Senior Technologist=0AEMC Corporation, 176 South St., Ho= pkinton, MA 01748=0A+1 (508) 293-7953 FAX: +1 (508) 293-7786= =0Ablack_david@emc.com Mobile: +1 (978) 394-7754=0A-----------------= -----------------------------------=0A=0A__________________________________= _____________=0AIps mailing list=0AIps@ietf.org=0Ahttps://www1.ietf.org/mai= lman/listinfo/ips=0A=0A=0A=0A______________________________________________= ______________________________________=0ADo you Yahoo!?=0AEveryone is ravin= g about the all-new Yahoo! Mail beta.=0Ahttp://new.mail.yahoo.com=0A=0A____= ___________________________________________=0AIps mailing list=0AIps@ietf.o= rg=0Ahttps://www1.ietf.org/mailman/listinfo/ips=0A=0A=0A =0A_______________= _____________________________________________________________________=0ADo = you Yahoo!?=0AEveryone is raving about the all-new Yahoo! Mail beta.=0Ahttp= ://new.mail.yahoo.com _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Mon Dec 11 12:46:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtpEU-0002Jr-2N; Mon, 11 Dec 2006 12:46:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtpES-0002Jk-Vr for ips@ietf.org; Mon, 11 Dec 2006 12:46:28 -0500 Received: from web51908.mail.yahoo.com ([206.190.48.71]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GtpER-0005Z2-3S for ips@ietf.org; Mon, 11 Dec 2006 12:46:28 -0500 Received: (qmail 20227 invoked by uid 60001); 11 Dec 2006 17:46:26 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Jbnhw4he5jgnFwuvmLcTl7KRUWYkdq4ZGyYNBhzqLLpn9PU5ylp0xKJwrrcb2gC0g5uCMgEW8SDyo09I4XT4E4PZWjegpqVZTUUKe7kU6DfRybbDNFyPb/e5o3vceHPioacUBW1ZKol4twV0JhOWgBiFMpoRkIh7SGO1W3f2QR8= ; Message-ID: <20061211174626.20225.qmail@web51908.mail.yahoo.com> Received: from [15.203.169.126] by web51908.mail.yahoo.com via HTTP; Mon, 11 Dec 2006 09:46:26 PST Date: Mon, 11 Dec 2006 09:46:26 -0800 (PST) From: "Mallikarjun C." Subject: Re: [Ips] target opcodes allowed for discovery sessions To: IPS MIME-Version: 1.0 Content-Type: text/plain; charset=ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org Yes, my recollection matches Ken's.=0A=0AIn the absence of objections, I'll= add a note to the implementer's draft about it - that targets SHOULD NOT s= end any responses other than a Text Response and Logout Response on a Disco= very session, once in full feature phase. Along with an implementation not= e that a target may simply drop the connection when it would have requested= a Logout via an Async Message on Normal sessions.=0A=0AMallikarjun=0A=0A= =0A----- Original Message ----=0AFrom: "Sandars, Ken" =0ATo: Eddy Quicksall ; Paul = Hughes ; Julian Satran = =0ACc: IP Storage Mailing List (E-mail) =0ASent: Tuesday, Nov= ember 21, 2006 1:23:13 PM=0ASubject: RE: [Ips] target opcodes allowed for d= iscovery sessions=0A=0A=0AHello Gentlemen,=0A=0ASection 12.21 SessionType s= tates for a discovery session:=0A=0AThe only requests a target accepts in t= his type of session are a text=0Arequest with a SendTargets key and a logou= t request with reason "close=0Athe session".=0A=0AI can't find any text to = prevent the target from sending a Nop-In or an=0AAsync Message. I do rememb= er a long discussion about whether to allow=0Athe AM to request logout, but= thought the answer was a loud "no, keep it=0Asimple, drop the connection".= =0A=0ACheers=0AKen=0A=0A=0A________________________________=0A=0AFrom: Eddy= Quicksall [mailto:eddy_quicksall_iVivity_iSCSI@Comcast.net] =0ASent: Wedne= sday, 22 November 2006 03:47=0ATo: Paul Hughes; Julian Satran=0ACc: IP Stor= age Mailing List (E-mail)=0ASubject: Re: [Ips] target opcodes allowed for d= iscovery sessions=0A=0A=0AWhen I look at 3.3 it says the target must reject= all other requests.=0ABut I don't think a NOP-out is a request. Is there a= nother part of the=0Adraft that says the initiator can't send a NOP-out dur= ing discovery?=0A=0AEddy=0A=0A ----- Original Message ----- =0A From:= Julian Satran =0A To: Paul Hughes =0A Cc: IP Storage Mailing List (E-mail) = =0A Sent: Tuesday, November 21, 2006 2:38 AM=0A = Subject: Re: [Ips] target opcodes allowed for discovery sessions=0A=0A=0A= As I re-read the draft I can't find any text that forbids a=0Atarget to= send NOP-IN in a discovery session. =0A But that was definitely not the= intent and don't be surprised if=0Asome initiator will drop your session. = =0A Also Mallikarjun may want to mention this oversight in the=0Aimpleme= ntation guide. =0A =0A Julo =0A =0A =0A =0A "Paul Hughes"= =0A=0A 21/11/06 06:11 =0A=0A =0A = To=0A "IP Storage Mailing List \(E-mail\)" =0A = cc=0A =0A Subject=0A [Ips] target opcodes allowed fo= r discovery sessions =0A=0A =0A=0A =0A=0A=0A Is a targe= t allowed to send an Asynchronous Message PDU to=0Arequest a logout of a di= scovery session? =0A=0A Is a target allowed to send a NOP-In PDU to an i= nitiator on a=0Aconnection that's part of a discovery session? If so, shou= ld I assume=0Athat the TTT must be 0xFFFFFFFF since the initiator isn't all= owed to=0Asend a NOP-Out PDU on a discovery session? =0A=0A Thanks, =0A = Paul =0A=0A _______________________________________________=0A Ips= mailing list=0A Ips@ietf.org=0A https://www1.ietf.org/mailman/listin= fo/ips=0A =0A=0A ________________________________=0A=0A ______= _________________________________________=0A Ips mailing list=0A Ips@= ietf.org=0A https://www1.ietf.org/mailman/listinfo/ips=0A =0A=0A=0A__= _____________________________________________=0AIps mailing list=0AIps@ietf= .org=0Ahttps://www1.ietf.org/mailman/listinfo/ips=0A=0A=0A =0A_____________= _______________________________________________________________________=0AW= ant to start your own business?=0ALearn how on Yahoo! Small Business.=0Ahtt= p://smallbusiness.yahoo.com/r-index _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Mon Dec 11 13:18:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gtpjp-0003u9-3t; Mon, 11 Dec 2006 13:18:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gtpjo-0003tX-2S for ips@ietf.org; Mon, 11 Dec 2006 13:18:52 -0500 Received: from web51914.mail.yahoo.com ([206.190.48.77]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gtpgc-00026X-0M for ips@ietf.org; Mon, 11 Dec 2006 13:15:36 -0500 Received: (qmail 64397 invoked by uid 60001); 11 Dec 2006 18:15:23 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=IurOcQJpDcyUAjz4OthkLCVjmoV9t2VFII+fMfFu6JGIZYyovRlXyrK9JOx4tVrRYFH6+TtNSAVpgxDt3RsiXBoxWhqhrGJALC7AYeO4JVVh6aH5g7YiF5QV46ml4DGTHbNx/1vRTFtArmvMZK8tP3lqRjj05ER2RCvlyP5HTyw= ; Message-ID: <20061211181523.64395.qmail@web51914.mail.yahoo.com> Received: from [15.203.169.126] by web51914.mail.yahoo.com via HTTP; Mon, 11 Dec 2006 10:15:23 PST Date: Mon, 11 Dec 2006 10:15:23 -0800 (PST) From: "Mallikarjun C." To: IPS MIME-Version: 1.0 Content-Type: text/plain; charset=ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [Ips] IG clarifications: Login Response & Reject reason codes X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org All:=0A=0AI received some offline feedback on the implementers' guide draft= from a few reviewers who preferred to be anonymous. Please review & comm= ent.=0A=0A1) RFC 3720 does not explicitly call out that there cannot be mor= e than one outstanding Login-Response PDU on one iSCSI connection at any gi= ven time (although the C-bit text indirectly implies it).=0A=0ASection 10.1= 0 on Text Request PDU (which should cover Login Request PDU semantics as we= ll) says: "An initiator MUST have at most one outstanding Text Request on a= connection at any given time." Essentially, an analog for Login/Text Resp= onse is missing (or so it seems).=0A=0A2) RFC 3720 does not specify the use= case for Reject reason code "Task in progress" (0x07).=0A=0AI vaguely reca= ll we put in this reason code for task reassignment attempts while a task i= s in progress, but then we subsequently added a TMF response reason code fo= r that case (Julian?). So I'm not sure if reason code 0x07 is used by impl= ementations any longer. =0A=0AThe other non-obvious case is that of a "neg= otiation reset" Reject reason code. What is this used for by implementatio= ns, if at all? If I don't hear any objections, I will deprecate these two = reason codes.=0A=0AMallikarjun=0A=0A=0A =0A________________________________= ____________________________________________________=0ADo you Yahoo!?=0AEve= ryone is raving about the all-new Yahoo! Mail beta.=0Ahttp://new.mail.yahoo= .com _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Mon Dec 11 13:56:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtqK5-0005fv-7t; Mon, 11 Dec 2006 13:56:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtqK3-0005em-E9 for ips@ietf.org; Mon, 11 Dec 2006 13:56:19 -0500 Received: from mexforward.lss.emc.com ([128.222.32.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GtqK1-0002Ha-0s for ips@ietf.org; Mon, 11 Dec 2006 13:56:18 -0500 Received: from mailhub.lss.emc.com (nagas.lss.emc.com [10.254.144.11]) by mexforward.lss.emc.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id kBBIuEx7008806; Mon, 11 Dec 2006 13:56:14 -0500 (EST) Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id kBBItOpo028232; Mon, 11 Dec 2006 13:56:12 -0500 (EST) From: Black_David@emc.com Received: from CORPUSMX20A.corp.emc.com ([128.221.62.13]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Dec 2006 13:56:03 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ips] Implementer's Guide - Task Management Issue Date: Mon, 11 Dec 2006 13:56:02 -0500 Message-ID: In-Reply-To: <20061211173704.93181.qmail@web51905.mail.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ips] Implementer's Guide - Task Management Issue Thread-Index: AccdSwnKCaXW3Q/IRj6J/rMsEWfRBAAAY95w To: , X-OriginalArrivalTime: 11 Dec 2006 18:56:03.0057 (UTC) FILETIME=[015C5610:01C71D56] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2006.12.11.103433 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -2, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CTE 0, __CTYPE_CHARSET_QUOTED 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.2 (/) X-Scan-Signature: b045c2b078f76b9f842d469de8a32de3 Cc: X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org Mallikarjun, [NB: Working group chair hat is **off**.] > "I assume this is essentially what you are proposing that we=20 > consider (fast multi-task abort with outstanding TTTs always,=20 > even without the key negotiation)." Not exactly - comments interspersed below, but what I'm proposing is that in the absence of negotiation of the new key, the portion of "fast multi-task abort" that allows the TMF response to be returned in the face of outstanding TTTs be allowed *only* for transfers from initiators *other* than the one that sent the TMF. I believe that Bill Studemund raised this concern earlier, but I admit to missing its significance at the time. In other words when the key is not negotiated, a TMF that aborts tasks from multiple initiators behaves differently at the target with respect to the initiators involved: a) There can be no change to currently specified behavior with respect to the sender of the TMF. All TTT transfers have to complete, and the TMF response cannot be sent until the transfers are complete, otherwise a 3720-compliant initiator may see something that it doesn't expect. b) Transfers from other initiators may be bit-bucketed early at the target - this would be new behavior, and new language would be needed to allow the TMF response to be sent once these transfers from other initiators are redirected to bit-buckets. This does not affect a 3720-compliant initiator, as these other initiators do not receive a response to this TMF. The only change is the latter, and it has the effect of removing a cross-initiator dependence for completion of the TMF. The use case is that there is still cluster software out there using TMFs to maintain cluster membership instead of persistent reservations, even though the latter is what should be used. =20 > Sorry for the delay in getting back. Between vacation and=20 > other travel, it took me a while. Thanks for the comments. >=20 > You wrote this regarding fast multi-task abort: > >This property is > >useful even if the new key is not negotiated (and hence the > >AsyncEvent 5 message is not used for fast abort of data transfers) >=20 > I assume this is essentially what you are proposing that we=20 > consider (fast multi-task abort with outstanding TTTs always,=20 > even without the key negotiation). Not exactly, see above. > The reason we decided a new key is needed here was for two reasons: > 1. Whenever TMF does a fast completion, target needs an=20 > (eventual) deterministic confirmation that data transfers had=20 > stopped. The confirmation is Nop-Out, and the negotiation=20 > for the new Nop-Out is via the FastMultiTaskAbort key. > 2. The initiator requirement in the "classic" case (i.e. key=20 > not negotiated) is that it respond to each TTT for affected=20 > tasks even while the task is "affected". We wanted an=20 > opposite behavior, but with a confirmation that the data=20 > transfers had stopped (so target can recover the buffer=20 > resources). The key allows this new behavior on initiator's=20 > part as well. I agree that the new key is clearly required in order to terminate any TTT data transfer from any initiator early for the above reasons. The proposal is that the TMF response be allowed to be sent in the face of outstanding transfers from initiators *other* than the one that sent the TMF. This does not appear to require a new key be negotiated with the *other* initiators, as (in the absence of a failure) they will complete those transfers normally. > >This is approximately > >what is described in the Implementation Note at the end of > >Section 4.1.3, although that note may have been intended to > >be iSER-specific - if so, this is a proposal to apply it to > >iSCSI without the RDMA extensions. >=20 > Actually the note is intended for all iSCSI implementations. =20 > After seeing your observation, I decided that it needs=20 > improvement, I propose the following new text: >=20 > "Implementation note: Technically, the TMF servicing is=20 > complete in Step.e. Data transfers corresponding to=20 > terminated tasks may however still be in progress even at the=20 > end of Step.f. TMF Response MUST NOT be sent by the target=20 > iSCSI layer before the end of Step.e, and may be sent at the=20 > end of Step.e despite these outstanding Data transfers until=20 > Step.g. Nit: "may be sent" --> "MAY be sent" > These data transfers, if any, MUST be silently=20 > discarded by the target iSCSI layer. In the case of=20 > iSCSI/iSER, these transfers would be into tagged buffers with=20 > STags not owned by any active tasks. I suggest adding: "; other implementations would deploy analogous resources to support this discarding". > Step.g specifies an=20 > event to free up the resources. A target may, on an=20 > implementation-defined internal timeout, also choose to drop=20 > the connections on which it did not receive the expected=20 > Nop-Out acknowledgements so as to reclaim the associated=20 > buffer, STag and TTT resources as appropriate." Nit: "A target may" --> "A target MAY" > Now that I read the text after a long time, I spotted an=20 > unintended double negative in section 4.1.3, target behavior,=20 > bullet d-ii. The text should read: > "ii) each connection except the issuing connection of the=20 > issuing session that has at least one allegiant affected=20 > task." (i.e. drop "non" from "non-issuing") Ok. > The other thing that came to my mind after reading your note=20 > is that we don't currently have a generic key to capture the=20 > Response Fence behavior - although response fencing underlies=20 > both the fast multi-task abort as well as addressing ACA race=20 > conditions (and perhaps others down the road. e.g. around=20 > persistent reservations). So, today, the Note at the end of=20 > section 3.3.3 advises that implementations may check the=20 > FastMultiTaskAbort key to verify if safe behavior for MCS ACA=20 > is supported, although ACA has really nothing to do with=20 > multi-task aborting. I am wondering if we should create a=20 > new key (say ResponseFence), so the semantics would become: > =20 > ResponseFence "Yes" fencing done by target =20 > "No" legacy, no fencing=20 > (so "clarified" TMF semantics are not possible either) > =20 > With ResponseFence=3D "Yes" > FastMultiTaskAbort =20 > "Yes" fast abort & fencing =20 > "No" traditional wait on=20 > outstanding TTTs (fencing on ACA is still possible) >=20 > With ResponseFence=3D "No" > FastMultiTaskAbort =20 > "Yes" Illegal, Response Fence must be "Yes" > "No" No fencing, must wait on=20 > outstanding TTTs > =20 >=20 > The downside of this scheme is that it may be going in the=20 > opposite direction than you wanted (introduces a second key=20 > that 3720-compliant implementations don't know about). We=20 > could alternatively simply mandate the behavior equivalent to=20 > ResponseFence =3D "Yes" always and avoid the second key, but=20 > doing so could make the current 3720-compliant=20 > implementations technically non-iSCSI-compliant. >=20 > Comments? Given the inter-dependence of ResponseFence and FastMultiTaskAbort, a single 3-valued key is probably simpler than two boolean keys. I think having an explicit means of determining whether ACA behaves correctly on an multi-connection-session is worth adding. Thanks, --David=20 =20 > Mallikarjun =20 >=20 > ----- Original Message ---- > From: "Black_David@emc.com" > To: ips@ietf.org > Cc: Black_David@emc.com > Sent: Wednesday, November 22, 2006 2:00:25 PM > Subject: [Ips] Implementer's Guide - Task Management Issue >=20 >=20 > To make sure we actually have some content to talk about in > this WG Last Call, I'm going to reraise an issue that came > up earlier on the mailing list, but (as far as I can recall) > never got resolved. This is done with my WG chair hat OFF, > and it is a proposal for further discussion. >=20 > Section 4.1.3 changes task management, and is a non-transparent > change - it requires negotiating a new key so that both sides > agree that they support the change as it uses a round-trip > exchange of a new message (AsyncEvent 5) between initiator and > target to abort in-progress data transfers rather than completing > them. Absent this message, the target expects the initiator(s) > to complete all in-progress transfers, and is entitled to be > unhappy or worse if that doesn't happen. >=20 > For task management functions that affect tasks from more than > one initiator (CLEAR TASK SET, TARGET WARM RESET, TARGET COLD > RESET) Section 4.1.3 also allows the task management function > (TMF) to complete while the in-progress data transfers are still > being dealt with, which has the useful effect of avoiding a > situation in which an uncooperative initiator can stall the > progress of a TMF sent by another initiator. This property is > useful even if the new key is not negotiated (and hence the > AsyncEvent 5 message is not used for fast abort of data transfers) > although I think the target behavior is subtly different between > the initiator that sent the TMF and other initiators in this case: > - For the TMF sender, the target must wait for all outstanding > transfers to complete before completing the TMF, otherwise > the TMF completion comes back too early for an unmodified > initiator. > - For the other initiators, the data transfers can be immediately > redirected to bit buckets so the TMF can be completed without > waits beyond that for the TMF sender. This is approximately > what is described in the Implementation Note at the end of > Section 4.1.3, although that note may have been intended to > be iSER-specific - if so, this is a proposal to apply it to > iSCSI without the RDMA extensions. >=20 > High Availability clustering environments in which TMFs are being > used to determine cluster membership (yes, there's code out there > that does this, even though everyone should be using PERSISTENT > RESERVE) are a specific situation where this helps, as having to > wait for a dead initiator to expire (the TCP connection(s) have > to timeout and get torn down) slows down cluster recovery from a > failure. This change in target behavior (to complete a TMF faster > if other initiators don't cooperate) should be transparent to > RFC 3720-compliant initiators, but RFC 3720 has to be modified > in order to allow it; the Implementer's Guide is a vehicle that > can make that modification. >=20 > This is proposed for further discussion. >=20 > 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 stocknews@tourpartnership.com Mon Dec 11 15:35:56 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtrsS-0002YS-H7; Mon, 11 Dec 2006 15:35:56 -0500 Received: from [213.190.197.91] (helo=pedro.netmadeira.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GtrsN-00024u-1P; Mon, 11 Dec 2006 15:35:56 -0500 Date: Mon, 11 Dec 2006 20:35:43 +0000 From: Best pharmacy X-Mailer: The Bat! (v3.0.1.33) UNREG / CD5BF9353B3B7091 Reply-To: Best pharmacy X-Priority: 3 (Normal) To: ion-archive@lists.ietf.org Subject: Vi@"Gr@' is the best pill I've ever used! MIME-Version: 1.0 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7bit X-Spam: Not detected X-Spam-Score: 3.2 (+++) X-Scan-Signature: d6b246023072368de71562c0ab503126 Hello member, ëåâûì ãëàçîì ó ÷åëîâåêà áûë áîëüøîé ñèíÿê, â óãëó ðòà -- ññàäèíà ñ -- Îí îòêàçàëñÿ äàòü çàêëþ÷åíèå ïî äåëó è ñìåðòíûé ïðèãîâîð Ñèíåäðèîíà

Best prices for any meds

 -- Ïîäñëåäñòâåííûé èç Ãàëèëåè? Ê òåòðàðõó äåëî ïîñûëàëè?ïåñíþ â ôîíòàíå.íàñòîëüêî øèðîê â ïëå÷àõ, ÷òî ñîâåðøåííî çàñëîíèë åùå íåâûñîêîå ñîëíöå.áîÿëñÿ êà÷íóòü ïûëàþùåé àäñêîé áîëüþ ãîëîâîé.äûìó, ñâèäåòåëüñòâîâàâøåìó î òîì, ÷òî êàøåâàðû â êåíòóðèÿõ íà÷àëè ãîòîâèòü
No prescription. No doctor visit. Just click here! From ips-bounces@ietf.org Mon Dec 11 16:35:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gtsnf-00018j-39; Mon, 11 Dec 2006 16:35:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gtsnd-00017h-74 for ips@ietf.org; Mon, 11 Dec 2006 16:35:01 -0500 Received: from mtagate3.de.ibm.com ([195.212.29.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gtsnb-0004qE-FM for ips@ietf.org; Mon, 11 Dec 2006 16:35:01 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate3.de.ibm.com (8.13.8/8.13.8) with ESMTP id kBBLYrj1108830 for ; Mon, 11 Dec 2006 21:34:56 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id kBBLYqRQ2154532 for ; Mon, 11 Dec 2006 22:34:52 +0100 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id kBBLYqeZ008037 for ; Mon, 11 Dec 2006 22:34:52 +0100 Received: from d12mc102.megacenter.de.ibm.com (d12mc102.megacenter.de.ibm.com [9.149.167.114]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id kBBLYqLJ008034; Mon, 11 Dec 2006 22:34:52 +0100 In-Reply-To: <20061211181523.64395.qmail@web51914.mail.yahoo.com> To: "Mallikarjun C." MIME-Version: 1.0 Subject: Re: [Ips] IG clarifications: Login Response & Reject reason codes X-Mailer: Lotus Notes Release 7.0.2 September 26, 2006 From: Julian Satran Message-ID: Date: Mon, 11 Dec 2006 23:34:41 +0200 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 7.0.2HF71 | November 3, 2006) at 11/12/2006 23:34:51, Serialize complete at 11/12/2006 23:34:51 X-Spam-Score: 0.5 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 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="===============1377740449==" Errors-To: ips-bounces@ietf.org This is a multipart message in MIME format. --===============1377740449== Content-Type: multipart/alternative; boundary="=_alternative 006ED12EC2257241_=" This is a multipart message in MIME format. --=_alternative 006ED12EC2257241_= Content-Type: text/plain; charset="US-ASCII" "Mallikarjun C." wrote on 11/12/2006 20:15:23: > All: > > I received some offline feedback on the implementers' guide draft > from a few reviewers who preferred to be anonymous. Please review & comment. > > 1) RFC 3720 does not explicitly call out that there cannot be more > than one outstanding Login-Response PDU on one iSCSI connection at > any given time (although the C-bit text indirectly implies it). > > This is intentional. At the time we where playing with the idea of pipelining the login. However it is common practice to have a single outstanding Login Request. I think that the only thing that becomes problematic is the phase change request (there you can have only one outstanding). There is already text that says that all changes to key values become final only at the end (when consistency can be reasonably checked). > Section 10.10 on Text Request PDU (which should cover Login Request > PDU semantics as well) says: "An initiator MUST have at most one > outstanding Text Request on a connection at any given time." > Essentially, an analog for Login/Text Response is missing (or so it seems). > > 2) RFC 3720 does not specify the use case for Reject reason code > "Task in progress" (0x07). > > I vaguely recall we put in this reason code for task reassignment > attempts while a task is in progress, but then we subsequently added > a TMF response reason code for that case (Julian?). So I'm not sure > if reason code 0x07 is used by implementations any longer. > The reject can used when the initiator attempts to start a new task but a task with the same ITT is still active for those cases when the target can't be sure this is a protocol error (e.g., a race between a logout and a reissued SCSI command). > The other non-obvious case is that of a "negotiation reset" Reject > reason code. What is this used for by implementations, if at all? > If I don't hear any objections, I will deprecate these two reason codes. > The negotiating can't be continued by one of the parties but the partial results (e.g., previous stage) are OK and no renegotiation is deemed necessary. I have no clue if somebody uses it but I felt at the time that the purists will object if I'd suggest restarting the login :-) > Mallikarjun > > > > ____________________________________________________________________________________ > Do you Yahoo!? > Everyone is raving about the all-new Yahoo! Mail beta. > http://new.mail.yahoo.com > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips --=_alternative 006ED12EC2257241_= Content-Type: text/html; charset="US-ASCII"

"Mallikarjun C." <cb_mallikarjun@yahoo.com> wrote on 11/12/2006 20:15:23:

> All:
>
> I received some offline feedback on the implementers' guide draft
> from  a few reviewers who preferred to be anonymous.  Please review & comment.
>
> 1) RFC 3720 does not explicitly call out that there cannot be more
> than one outstanding Login-Response PDU on one iSCSI connection at
> any given time (although the C-bit text indirectly implies it).
>
>

This is intentional. At the time we where playing with the idea of pipelining the login.
However it is common practice to have a single outstanding Login Request.
I think that the only thing that becomes problematic is the phase change request (there you can have only one outstanding).
There is already text that says that all changes to key values become final only at the end (when consistency can be reasonably checked).

> Section 10.10 on Text Request PDU (which should cover Login Request
> PDU semantics as well) says: "An initiator MUST have at most one
> outstanding Text Request on a connection at any given time."  
> Essentially, an analog for Login/Text Response is missing (or so it seems).
>
> 2) RFC 3720 does not specify the use case for Reject reason code
> "Task in progress" (0x07).
>
> I vaguely recall we put in this reason code for task reassignment
> attempts while a task is in progress, but then we subsequently added
> a TMF response reason code for that case (Julian?).  So I'm not sure
> if reason code 0x07 is used by implementations any longer.  
>

The reject can used when the initiator attempts to start a new task but a task with the same ITT is still active for those cases when the target can't be sure this is a protocol error (e.g., a race between a logout and a reissued SCSI command).

> The other non-obvious case is that of a "negotiation reset" Reject
> reason code.  What is this used for by implementations, if at all?  
> If I don't hear any objections, I will deprecate these two reason codes.
>

The negotiating can't be continued by one of the parties but the partial results (e.g., previous stage) are OK and no renegotiation is deemed necessary. I have no clue if somebody uses it but I felt at the time that the purists will object if I'd suggest restarting the login :-)

> Mallikarjun
>
>
>  
> ____________________________________________________________________________________
> Do you Yahoo!?
> Everyone is raving about the all-new Yahoo! Mail beta.
> http://new.mail.yahoo.com
>
> _______________________________________________
> Ips mailing list
> Ips@ietf.org
> https://www1.ietf.org/mailman/listinfo/ips
 --=_alternative 006ED12EC2257241_=-- --===============1377740449== 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 --===============1377740449==-- From dialog@apierrelaw.com Mon Dec 11 21:12:06 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gtx7m-0005fr-5n for ips-archive@lists.ietf.org; Mon, 11 Dec 2006 21:12:06 -0500 Received: from [219.148.115.106] (helo=[219.148.115.106]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gtx7S-0000Sj-I6 for ips-archive@lists.ietf.org; Mon, 11 Dec 2006 21:12:06 -0500 Received: from [179.151.26.99] (port=3550 helo=kcqdcz) by apierrelaw.com with psmtp id JVtUTu-8B5532-00 for ; Tue, 12 Dec 2006 10:17:02 +0800 Message-ID: <000901c71d93$92088b60$00000000@lenovo8cecd987> From: "Interleave avi" To: ips-archive@lists.ietf.org Subject: mp Date: Tue, 12 Dec 2006 10:16:45 +0800 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0005_01C71DD6.A02BCB60" 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: 1.2 (+) X-Scan-Signature: 2b428fb4265163ba7f2ac2af0ebfcf00 ------=_NextPart_000_0005_01C71DD6.A02BCB60 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0006_01C71DD6.A02BCB60" ------=_NextPart_001_0006_01C71DD6.A02BCB60 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable The following gpgp gp booster pack required. Control, over codec can. Formats gppgpp mobile phone videogp visual. Something else come back when finishes free. Files set let it run. Ogg mediaogm realmedia rm ram, windows wmv xvid. = Ogg mediaogm realmedia rm ram windows. Size mbdownload, info lite pro more purchase options input. Intel, = technology ivt apple quicktime, mov qt mpeg? Info lite pro, more = purchase. Ram windows wmv xvid videoxvid output the. Predict how, long takes to convert. Animiation image sequence ogm. When = finishes free trial advantages product. Autodesk flic animation flc. Animiation image sequence ogm mkv matroska you, have full. The following gpgp gp booster! Pro more, purchase options input format = supports? Home audio slice single user. Quicktime mov, qt mpeg mp mpg! = Download us msrp instant activation. How long takes to convert, all so, do? Wmv xvid videoxvid output the following. Let it run well organized progress dialog. ------=_NextPart_001_0006_01C71DD6.A02BCB60 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
3D"mp"
The following gpgp gp booster pack = required.
Control, over codec can.
Formats gppgpp mobile phone videogp = visual.
Something else come back when finishes = free.
Files set let it run. Ogg mediaogm = realmedia rm=20 ram, windows wmv xvid. Ogg mediaogm realmedia rm ram = windows.
Size mbdownload, info lite pro more = purchase=20 options input. Intel, technology ivt apple quicktime, mov qt mpeg? Info = lite=20 pro, more purchase. Ram windows wmv xvid videoxvid output = the.
Predict how, long takes to convert. = Animiation=20 image sequence ogm. When finishes free trial advantages = product.
Autodesk flic animation = flc.
Animiation image sequence ogm mkv = matroska you,=20 have full.
The following gpgp gp booster! Pro = more, purchase=20 options input format supports? Home audio slice single user. Quicktime = mov, qt=20 mpeg mp mpg! Download us msrp instant activation.
How long takes to convert, all so, = do?
Wmv xvid videoxvid output the = following.
Let it run well organized progress=20 dialog.
------=_NextPart_001_0006_01C71DD6.A02BCB60-- ------=_NextPart_000_0005_01C71DD6.A02BCB60 Content-Type: image/gif; name="Lite Pro.gif" Content-Transfer-Encoding: base64 Content-ID: <000401c71d93$92088b60$00000000@lenovo8cecd987> R0lGODlhGAIAAoewAAAAC3YOAQCAAISFAAAMeXoAiQCJdr3FwbblspjG+zsuAFQjAnQtAJ0fALke ANIUBwBJARFKAEI2AGFHAH5DAKMyCrxDA+s9BgBdAC1iADVjDVtnAHZiAJJtALZZANtqAAWCAB2O AEKMB1R+AHx+AKZ7DbiLAOp7AASXBySWBU2rBmmZAHqWC5WdAbWTANytAADEABXCDTK3BFzIDH3N AKy+BLK7AObHAADgCS7YCTzmAG7rCHPuBqDeDMnqDdnrCA4CNBcANDIAPGsGQXgAOq4KM8wANdoA NAotPCQeQDoSTmcmOociSqYlQ7gtQu4WNwI/ThZDQjRBSGM0SYM6QZ5NRsY4TuREMQBiSCRiPzZu RlpdQoplAJRdNMZaTtNgSACCQB9yNDiCPWWJQYRzPKyBNriHQel4RQCjMR+VTUuSMVGVPIORR5yT TM6tTuGmSgC3TSfNOzLKPFrKMoPMN56/M7W3TOTDTQDWSyDrPkroR1LlQIbRMqbSPbbVS+TsNgcA hhYChEMDg18Aen8AeqcAi7UMjugNdgAWchkagzYmhV4geIYoipgribIoceYhcQA7giY5i0dDhGpB ensxcqIxgc09itdGewBVjidfcUVtiGVqf4RoiZdVhcpid+xcgABzih5xejF0dWF0gHGGiJN5gryH gtiIhACsdyeZckuZjWaldIOmiZuocb+jgtamcgu5di6xe0a6e2zOi4fMcq29hcDOgtrBgAHjdhXV gjXlf2DqfXnaipjqjMLeiOrYggwHzSIAuk4Fx1wAv4IKwqwDwcEAueYMtAkZwBkgy0UexFYXuYEV tKItvsMdyeQbyQI0ziQ4vUs3w1s7xHNLua1AyLM7wuA8wwxszRVjv0VivGFgwI5es59qv8dWwNxt wwCJzC52u0GJwWmNuYiBwKOFxLKGw9d0wACRvSunyDuWw1Okt36tw6iRvLWmsuqmvQrHsRHJuk7A sly1tom3zJ20zf/s4qiurYWFc/8AAAv/AP/+AAcD//sA/wv/////+SH5BACownkALAAAAAAYAgAC Bwj/AGsIHEiwoMGDBREoVFgDQUOBDiFGHDixIcOLCDNq3Mixo0eBd+6AHBlSZI2QJ0GaRDlQZMmU H2PGnDevBk2bN23q3Cmzp8+fQIN69CeQaA1/RI0SRJo0qdCnUKNKnZqxokWLDCk+pHhxocOFVMMC dZmSLEuSJcnCXCt2psCab3nmrAm3rd27VJka3at371GkR/EKHky4p1etXB9+xSiRq9XCglcWXIlS reSRbCEfpBv3Lc26O3NqHuiMdOnRdpUGDqy66EDAq1HLni0WLEGwX68mzpqbdlu1kymbVAnz8nDf ceEqxylaOWjIp2tERw61qVK9r4s6zU69u3eNtrNi//XaNaL5io+/R6188mXLsu3jsz87eq7zgZ8/ E6QrGm9pZwD+J9106snkVF9LaXegdgU2qN55W22V23mLKUZeeg7KJJlZLXF4XHsvfVhfXfw1F1pN 73D2TmECCiQggBl+hOBrTGUHm2s4xqjjaBP1SJ6EVzE2oXg79nQcS0h2WJZLls2Wn3P84STlZynS lOJgp7UY4JbwEFgkd6zFFiZfTYn55Zl39RghhY+ZBxGaQjF5GYghVsYkQSJCdtNcnvH3zoo3XZni nyuuGBaMA0ZXGjw1dBkgnAmOeSBsqvkF6aVTqbmmbW9iJeGFmHYEHJ4i3vkecbJxthxPbw2qH5WB Ev8qVovSuSgQo87Aw2ijusJZpkHb0QjYjaFCdU4N5xxbZG8WNjYhkJ4qVixHG6Z1KltmuYeaqsyp mh+g84ALqE2FClTuVDBu2ah0uN46kK67flnjX9tRet1fYE7b07HJIqvsjmwuxqy0Egl8mL41XCOQ wkpe615aEI+6bXL7TWnlfuF+61kNhRqKLkGI5uroou7GKy+ZNtI77JgI/8Svsv/q6GazPpaHW6ct K8www/DJhypmZ1mb6pMU73lluAMdTSjScBnqsVCPhsxrrooCGK/JMbZmKWszstxyTP3CHLPMiL0p ZISIVTitzgnrfA3PxeFZnJ1A0+btcyr2ebSVfJr/6ze6/1Wda6Jd7or1jpQuhZ3K934tE8wC9fsl p88ejN5taIf6dsIDwa2SnCDOHbTQBrljujsDoS5Vfhj32SqfhaJ4MceE/jkru1R32WiLvcJ7MoOr DYud8GY6rpHkY4/toJu9HZyQ2mavbRDbBmU7352UZXR6DaaXHtVz+CVXpexydRso7U8Hhejujhau O+GY2htmQYm3ZrxHYQ8kOcA3/xi9swSTHud4trmFkSo+7zEVAgtyOtUJRHWoc6BQVoUf0TjtShwj GgbH5bSoZClw7NJVuhJFkMNljVh+SSG97ve4ZOUPTgaDntooxMICto2AnqNTZn5GkO5xb3s/3F4E /yMYFM50pjP6qZLeSkSlc3EMKiPEnYt89z54mfB3wuIO8ViIv8i5cH/Lwtl4ZqgmDBWLept7Ww5R FbHQeY97QYQjBL0nwY9EiTmskpKh5tKxbl3wY7XqVbqsJsV1uctXrula4orHxY0oD4aeglCQeGM8 HC4sjZzLyJw2AkQ4BnGIqROiT161pz5dbHxH/JOKnmY7DwaOaukyXAkZdUUdrexG1uFLI33ySDQ9 S1rlWVPO2pZJglAPKqB0oDJ/6Mke9oRopYyL7VzFOoKoEkXmqp1U1ifCLcHSkPqaFNe8tstyggdz BdulGgc4wDUKBYINFOIyGejDn1RTmnvLYJSaeP/KpAFuUVaj2rqseKtaIq5S9jOnQquSthgS6Wtq TCPb3OmTer4xjvUkYjM9QqLw7QSV1OQb0o74t0Oxq1bfpCWvWtYXXC70pQx1HqdqeMN2UrQnoHwg EHPayTjKxIjdws+gQpqxUjKNlXYJ0PtWyitaGhQ5YNRIpWBK1XOWTaERvelP5uhJIvpQnt2D5zNL VDRqOo2J5KNdNiFjOJWC8ztg7GVV50rXn0y0LQ1spledmbq+/nRPdyMrivZWO7p4TFZ46V1bCZoh FyLrsXXV1wcmO9kaUPYDBKGsZSs7EM1e9rOYFQhoRQvay3b2s5kdrUFUqxHNpja0ry3tZlEbW9n/ zravGg1rRr8q1rA+0C06oSBQMYhNvZW0lYXxXYxe9lixRVaynKXtbV1LWsxSd7XR5expYbvd6nZ3 ttx17XUPMt7x3pa82dXua7ELW2WK0qdd3etO68iRV1HMfFLK5rdqd9jkytJB/+IXQQT83GKJ17Te Pe+Bubve0xakvOpd8HfPS9rWIjjBDWbvhDM8YYuKspO69TAD/2rf5djujugLlzZLWuAB+6sgYpNr i3W0YAkrOL0IMe+DI6xe71L3xz3eiHQpvOEM69i8ro1niOUoR9/S97f29GgFVYy+4L7Omk+c8YC/ SGDIaRlSEsbxjUOrYyKjN7xB9qx2gcxgIVsX/81tLjObz6zhJuu0qz3kqp3FOkqSAtZP3FJlNpH7 5cjpz8X+knGhCxTmygK5wtW17ZA5jGRHi3m7QdbwnHdc2jeTOdNmpjB9vZrM387zzhu1I96CK7vD Vom//ly0i/PnWEXL2js2tjRsWVtmTMeZx7/29IU5DWofrznNoLYtnTnNVz5nlMmfDCWqn4lHJpqL yudrZfpuDdn92ZrbuBYzr6Xba2ZTGtmeDrW5z3zhSrfZ2O/G8Hd1S0eNSnuvdi6i6/4Mq1iz+NYB 9nJUwd0gG4MXznD2CIQTzmyDL7vOY4a4ueWMbig72dR35upXof1kapvSdU/sIMG3HLZaf3vks/8x +JCHTXEOm/m6uX50kSfscHk3eNgzp+NB8grWOTrZolC5D/hQnhEuv/jkREeNw1kO82RfeuYqP7a4 i93jp9uc5u6WOM/zinEl+1yCHU+6ZgRMYLEz2rRNrzqDO53eI2eatURGMNzXDW/Usj3dmKY7hnfK ZA9/GNV6NrtvmCv4wt96mUtOdem8bvjGO/7xdvn5EBGPUYxPG/KYz7zmO9Lbe2c82vHcvOhHT/rF PxnE9m5y2EvP+tajfOsWnzxf9er62tte7KeWvU7xvfrb+/73keW6xpn5ydAD//jID77pd+9z+Cb/ +bIOgPQz/2HZf7330M8+cqTP/e5P/y7cb4v/98Mv/u8TxPs+Ib9Bxh8AgXDfq+qvAfsRov76fx/9 8Xe/+Tky/oL0fyDdd37Tx34BiH/xF375h4AE2H7rt4AMKH/ox38RmH/6p4D7B4EDOH8C+IDRd4Hg 54FRYX8g+BQJmIEjmBEUiIEAKH3u8H7MFH6oI4IHIYMVuIIMSIEpOIP3Z37kJ4I8eIE4uIMyWILt l4MaEYQ3eII1qII52INEWIQ/yIFG2GJTSBVVCBREOBURSH9K2IBZKIAYCEROyIEQyIVJeIYbuIRp KIFSiIY2WIFR6H8eOIZxmIVX6IVy2IZkuIb6lwDclwA1AIhruIUG+IAH2IXPdYiGGIX7939w/+iD QqiGA/ENNUCJb5iHNgiEAXiESniHmaiHKDh9EGSBMWGBJjiIc4iITZiKULiJX4iKrniKaeiJfKiC mIiHOhgAgniLhFiAcXiJt6aIl0iKtjiGS/iL4/cNykgQykiJzoiENUiDnTiNe8iJZQiMuPiGtMiE UGiLx8iKbGiGeKiAkuiNw5iB0aiJrdgTwniL7igQgOiHI0iHJkiMr9iBoJiOi7iO7piC9BgAzSgQ zjiQlIiE78B9hkKMHWGEm7iQsmiOeUiAELkR5PiQxQiOFDmP4EiK9/iN66iQ+qiBoZiPtYiN8KiC CRCP59iNpyiRJVlo7ciNAWAUpviL3qiByf9YiZXYjJYokPH3JxZoOyCZkdVYjkR5k4zIj9qYlCNZ j2RojO8ojrk4jjsIkdB4kTKJidsoiVcZlYGIkikJixjYkjY5kV8Wk9znDwv4iA8JlT5oiQS5k8v4 DeFHiYVSk75YlFO5lx8hknaojlZ5goUImBN5hau4h/a4hUbploWolYiYjYUJghQIiOEniLvImGiI lo9ZV5o5k+FHLBuolApJfnRJmj0pkMxYl1k2fQcpfYRmllLplUfpkY75lBYJm2PZioTZlSMZm0u5 j4Qplo8YmErZl42IkV5JmdNnmStJm525LJQzGJ2plqrYltYJkJXYkM64k3hol615hiKHm5D/aZTh qIbC+IUx6YXAyYvIyYltyJWROJwvCZW5SZzi6ZvmyJDHKY8MuIu0SZUkCZ3pdBtmBBXt2H1IYX8X mZmJ+X2lyYA92X08mZ2M2EoICZRuSI2yOZY6KId8OJQ0KJ4h2pwbGpHmGZ/52ZELGpon6oaliJFT GIut6J8kWpvYuJWFQSQXwhjlZ5vjBxiO6Ii5KYQR+KADWYGnyZaueS7fqYiCGaQu6Y/BOaQuCp+K yZdPqJt5eaURqY7p2ZDl2JiZ+IlJyaWyKaRNSaQyepshCab3iRozoykNojUJFRRzqYKnyX3LKJc8 uadV1l+agaPaN6h4IR5d0RiTxKOQ0VLz/zIVA6mnfqqnBeGnE/oN2lQur/mBekmoI3cDAuGpX/NL lgMhiooaw2MXD6qTzSipp5mkluqda5WpeCGonFpgN3CrnwqqoIop/VM2NIROoxEsdWqnAtmqqLmd R8qdAWmXSQOotfqsB4GrNbCrnrqrkNQph3oYuBFMtDGsxAqXqoqsBrGn4qqTsJZl0Jqunzqt04qr 1WqtvEowD4URM8RC5HqkyIqvxSqX3PkOltpB26au2qer7Zqr7aqr8Eo2ujGgM9MsCeE4ScqnOhmu BAmX4uqn6CqwtequA1GtHYuwZ4Ie9Po/mBMw9xOxk7id/LqvdwquGnsXfxCzMSt4t8qxNf9rsAfL rgIKJDVTMMyzsCc7iRLLr8karsqKsi87FX9QAzM7s2InrQbhsQWrs5NDRp8yoPJqr9w5sX3KjMe6 suWatFQhs0vrtEnnsVD7rlC7rrxaIQLjsAxlPBh7p8UKri1Lt0grtkCxtEzLtwJhtmfbsQShtlLL P5N0EL0qRkHyNZTqslzrshYLthOrt1Hht3/Lt5bLbdSaq+5KsGpLNtoKTNgaLQ2VOcUSkF5bsXOJ ulvbkypLuULRtJeLuQqlLT+BsASbs4K7tgCzsJT0sP5TqvqiuqhZt8Y7oUcLu0pbEDLLQtZSEpR4 B3nLEbirs9WbuzEyJA31I+FBOcJ7uqv/67qt27LHarfK+xSyy7R927wtwx6oYr4xUa0oUbPY67nQ GTA/K7qLC0AtE7HLarGuS658irHnG7sEQbtfkyTOKL0DKb3F+xE3cAcRfKsikbaQsq2/ZBBx6iwF Giqr67WTqqpEa6wFLBVlq76ZOy0u8Q0MrIwiwZMm8bobIa1mEcEHK60J2yC/KkwPpRvZCrSo4QM+ UANC/BTIm69CK8L52rUlDBUnfMII87wpgbosHB9VrEnsEcESXMEhYcMSbK05XCA+gjMb/LYW8rua McRELBBFHBUA3Kf32rogPLlNvLdkazzW4sILXIktfBIu/MLVgz1aXBYUrBY3G7KK6rby/6qtzgMZ QqzGa0zEavzIkOwTeOuqQhvASVzHlZvAG8LCMFysMXzFBEwnH1ISFDzIxWKo2FpGrQwtslHEQyzL bCwVcTyuI4y8nLxocvLCHxy9DrzCrPs5PcOuclLIU3spGWw5PLzBo1HJA1HJsyzJQkHCRivAD7zL hYYkIaHHy9jC/+vHK8sheOLFqEwfYbw8+YuoPzxTGSwYbUzJkzzNtRzJMhG55ouvjavNstYkfAzK MIwSAD3FltgkIaIkE6zF6Zy9m7LMMRRAPYwX0rzG8UwQ0GzJKQvH5VvK/PxlTFLFLyy9DCzKqDsq pHMtCFTBO4TIPYvGY8zKhDHJBkHP8f9MyT9RseMKvx19awf9zb4s0iBdqSzBwtkzH/Jh0sp8NloR uocKxDE9y/RM0RZtz3bauJo8vTsdWUdymkBN1P/Mxz/9xz2TPaETMfQRsiVbr47BzGnMxvLs1tEM 1VRd1QA8x1m9zZLxvw08xSINyF79vEniz+QcrwOzvT5Muk/dxgXxyG6t2Bdd1VsLedWisaTTwK7r wN981URNN5nhISgNQ5fDG6Ltq47M2NMs05KM2oz9rMPBzZgBrc8L0C/xy9EryjppGdijQ9piu0n9 0DwqSbQhz1Bt03Ed1bVq1nXD2q0t2wUtkJVx1cSB1MVsJ3nStvs7MN8b04tdzxRd04//DX29LBzc XN3P98l/HNKA/M/I2s1H0iHuK91C0Ue00b2IrbiFQdxwrdqrfdzufdQJtECEehlzCdTKitkgvbWu /dokkdLk3RPaNt+NbLrPLMsUTtOqzd3Z576nAthnzanQW8UgfhYBGcwYCzrEDODx7W/TFHIQvs7B HcnGHc2LPc/aJ8VGTTcKVOMN09XLGtJwidnVoyRF/dkegakZq1aIJWtvLeP5bc/fDXzUHd06hOL8 PcqUCh+gDBLDPBknjtsr3RFM6k+uBm6QfNoy7diKjXynbMpn3csKDt6m8roGnscDfUBTntIN4+CY Ok3bJqvPtd+pXcsxnuGmvCSFHhyD/63jCeTTy0rSeQsc733QRd5HTtQxsOZEWmbagT7P+/3kticc PvMwR93eHn4tB/64oNzgJr7gQXGpg3bkyBWwf37mTs7dnn57Gj43B3QkZB3gm5TqPC4qbUTlMuHq SNWsWCbrM9bp9QzoybdJ2NPaU+7PrL1AIM7HRoLSHZ4RtmAL72ALfnPpLB7usuLnCMMP/HAQ6L7u BbHu6C7J7z7E6F7mBPHuA+Hu7o4Q+H7v6c7vNYDv/W4QAM/v+y4QBQ/w6c7uBp/wCC/w9v7vDL/v Dz/x/BASAC/t8YHuLIHwFd/uDf/wEA/xBz/y+e7x9R7wIQ/yjpMnD7Pt1ILxQLHi4f+OPiv2b1yk 8iG/8P4u7/zA8zyP4f7u8BpB8Trv70Qv9EWP8zmf8ii/8AEP8krv9EYf8PFQA/GA7lW/9O/+7iXB 9WshEhofN1F/8mQ/9Uiv80cf9EFv72Mfxb1O7IQB7t7u7StC9w+eZX+U5Dff9Cq/9XzP8D4w72lO 8E2/9GeP9ijv92pf9jmP80rv+AoP9YVP+IhfEFef7pfP9hWv8Yn+EiU/HF5f3ZJP9pCv7on/9Aqf 9P3e9gms67Ih9wJB9zUA7sgu7oNm7i3T939v+EzP+iXP+IfP9KSP+qa/9oX/+Mcf+aefESXv91Uf D1mv+Zp/Bzgf7SKf7hBj7+Q9+mb/b/KHT/G6n/a31+3dnk3g/poP3l98ruzTovsm7/6pr++rv/vy //7LP/Cm//sfP/n7L/yLDxA1BArkx69GwYMGCy4sGC9hPIYJBzIseMdijYsJLVa0eEciRo8DRSKc aLBkQooEU35U2ZKlS5giZc6kWdPmTZw5de7k2VOgLaC2ath6926oUYFIjS5dmrQG06dFfU6lWnUm yZMjFZo8GdEmSawxZYaVGBbhWa5Xt2pVS5PsR69i2aLkB9FgPId5vca9uNGgR8B3EApOSzhjTbNp 0eZcnBVs2pdvrU6mXNmyz6BHpRJF+tRz0c6gnUq9XPoyWdRr2TZ2uzJr67GqWz5G/2wS61vJuG0v nAub7kOHWhvaHSywo0aQxinyC4mx+FfF0V/Wjrw7rlzT2bVvxzxUKGen4aF6HigadGfu6XXqfn17 N/bEvX2zpE0fMsz6sbvedy+dukrV8KrBIYYI5O0jjyoaKEHmQuLIOZOaa2uu/F4ri6sK47NQPQ47 LA2ooZzirCiiZmrqM/HQ83BFuvpL7UD7JoxJMuFexNA/+dBybaXlZINxurmIIy4ivBoa0K4Fl5OJ weYU9EvC+Upy8UAlW7wxRxxZ1HLLnIT6qUQwgxItKhTPQ5FLNNNUc02f8sJLQDhpejM4kUIKzDiM lszzODb79PPPnr77zkypCB3PPP8VAVV0UUYve3PAI+PMSyQ3BUwOJDvx1NROPhv19NM0vQQNRKaU Cq1Q8kBVddVVg5MU0jknhXTWBfO0FU/ANr2VVV57tUzMEN8p8cxCSSuPTF+TVZZLS1119UhKBZL1 UlsDy7XW5qBcdltuvxw0M1TNrEmpbss1l7s5pVVXJkux1bTaOxfs9Fx6eyWVtBPPRJbcROv199+B JG0XWoJhpdW4jg67VWFqAXaYVXxHO/E8cR+22N9H1yVY4Hbp3HOma4/L9GKSGaVYJKhUzLdkSVqe qWWYBXJ5oJlflsRmkWCuuYadZb5Z555lArrmoWkCOuebaU56aJeLtqlmAWd26Oj/4KTmWRI6W7ZI a5Dl7TMBsGsIu2Sy9d2XYmPLjhlppa9u++mkfVY67rWDbpruuHF+m+i81756abzfFjrwmmKetGW8 YK4a8Xhcntpvl+/QeuQ7GUYT7AQGyrzskg9Ftrx+Lb5bcLbdxmnmnXtGPW+5+Ya7dNdJN3310geX HenUsW4c64ARl3t32n2eN+FdPcRcoM2RHzt5zh3G1/Mxmx9dbpyDNhrw2922+2fCr4e9e+tHV511 6k333nHteafUd8d1Lj9yhS3X8vjkx0Ze7OYfLpXcVPOfvvy5kQ9uuTsf+f5nPZ8d7X3dY5v7Ble0 2BUwatyjVOJ0t7rgmY9NmcOc//3Exrz74Q+E+aPXxD5Hwv8lEG8ILBzrwkdB22XQe3vDXvbutr0Z snB2gNvdxnrYQ9pFcE3H+6DyOEhEEI6QhEu8mBBpqMHTuVCAKWydA1/XQCsCsG1UfKHfWrhFrEFt cdJyYBZ1uCIOhlBzmjviGtXIRDg+jGlflOFNxlfA6tXwi1gE4At3WLvv2bFvMZOam6Sms8cRcIP1 M2LYiGhEN8ZRkv9yIhizpzdA/jGGDLQdH/soxQXakJOALKP6LAinUp6RS8sTCfM2x8gPwnKSs+zW HWOnSEHabIWkkyECFYlLyPVSj6QUIBQVB7wjKS6ZuRvkEEfoyCIi8X4dpGU1a/8Jyr858Yy+zKIK tTlFpxlzkF605RzviEleInJWFsykKo0HzUe+sn5pnKY17XlPfFYlYxobmKraKEIRunKaHaRfPg26 qnOcowYJPWifPPasffLqmdFMIzX/CdCGZvRPCl2oQDiqUTVlrJ+rIihG4TnQVyoPpCvt00cZylCW xlSNj2xkLCHpSGrKVKc5mcc8BuJTnnAUpgv96E4z+syU4jSWHhwo/oz6VJH09KdWEepQoWrQIxI0 q04tYkAvelWw1kCqYwXqThQKU6GGFZ/0s580U6pSpipRrRrtqU+lOtWgyiShRZ1rNS8qUIq2tZV9 NSpZBQLUupq1o3sl7D1patP/riIVpY9trEHHKta62tUnZ3VpZWlZ0uUl9aRrrChXPdvQzB5WrKvd bEdPa02LslGpcaWnSl970LviVbVBteptJylNm87TqfEsqG/xSdbLqrasxpXpVmVLkyR+lbn2XK5M 7Jrb6YJUljJJKiQDGs3sWhO5msVsdcN7VNu2EYnABex5j8ta87oXvaEFLVcF6lz50jKxZU1sflda 0NKqN6u19a94MRvVArPUud39rivlWuBvfKMGESYhdhOs3VY6GK7PhWyCJUxhmYD4wn7qx0BKPGKa UvavD2YuiCU84YF8OMIiHnGfTnziAuNUnqQNIX79O2MYf3jCFKZxjbnUjxIj/1kgOE5wgL0KXRb7 dsZCfnGQX0zkGBt5S0i+cQ2Y7N/SNhilHhaJkIdcZIEAGc2cmzITmaxkIwMXoML1sIjVfGUZqxmO RF5zyZKM4yTv9Bo1uMagB20apdZzxFWW8ZCt7OgrpxnGs6yyn73s5T9f+qqFzg5xtfzoSc8kz2fu c9kYbWbOZRrTLC20oQnt6kN/ejuVlvSkp0zlGAM51GyuNa3JFugvg7TVrx42p2Mt61n3OsRldvSy 84dlZvvaz3Be6aGNbW1icxrZlrFzo/l861rvWtoko3KlS/0vJQdbo9qWibFFcuxtU+XOj450rkmt a1ST7dvgjvef2O3qbMO63/9WyfOp71zvNOt6z2Vu9K4HziVsC2TYhB4IvB/uk1NbGd8Jh7TDF05q j1/cQ+4GuLWLXXGR74TGZq63i8Ut6XyXzNy0VnjKO2Ryikt8JrFmt81tcmt+06TNjM71uC0G7RC3 2ec3r/jEtV3ynC/95/PWeKmHnmVe35vhUl/Rv3v+bopb/J7OqAHZy84qhJv7zLYGesLP7bCr41np XE+PwN3d7rsb1Bl7Lzvf+f4puc/b5W5n+MabV3Bc051DAA+4zluNbQTg0+xk//tAzM4opBM96RkX PAn5/HKj0/IQh6jM6Gdi+lUxHtt3R8A1EPB62NNy8pTve98vvyiXu1jPai//MtJ5HWkJA0D4wg+9 p1DfoeMPJPnJPz3pZYJ65mdn9NHPybGhHvlsv54m2Gfi3mdPeb8L5PZ/gnbgyz1zZXPc1KiOMPEF InxlUX870V++82tCf/sjP/874XnYIR95Q4M9AayByOM+EvI+kbi8vxs/QMm9cAuyB7S3tTs8h4O/ xBs++Hs/DKyB4dPADfTADMTAEAQADRyIDKSJ6cu/FFS+FHS+FhSIF6yBFtw/GVRBF0xBf/CHGoTB GDS9GWTBFaxB+Xu+GwxCIWS+x9O21nu11nO9gTBAAozCJZo82wu/KsQ8okOzwXO2mmMzLPsGCxSx ExxBEuxA+OtADiRBmTjD/xFMwxJ8QxScPhbkwR2kQyIUwjm0Q5GovxrMQX8YvRz0QfuDPtKTwx08 PkHUQ5sgxBusw517NUh0PSecRAPUPoGIvSm0vNq7PQZUlCxsOLazt7TzvBA7QRAbQzVsQzdExZlg QxNMRTTMCUJUREfEP0esRRqcQUHUwToERERsxF/ExVuUxUakQ+qDuiRcwkKzxAIkQCiEwubxPgQ8 O7QDxXKbQOBbu+KDO3yzwGZjRTcMR1d8QxEsQzUUx1jEiVnkwXXsxRfkQ1qsw0A8hD8kPR0ExEOk xxqoR2McxEL0R3akwTjUw0SsiceTOEMbtAFsRu1rRimEIyoUv7OrPNyTwP9ww7WYe7uL0TxvrDJw VMVxXMVzDEkyPEd1jME9/Mc5DEZ4HEZ5zEcdrMd55Ec7LMh8zEOcXMRivMmbuDaF5LRnfEJmxMSy kUZqnMbZA7ykUz+PO7+QIzeYozD3E8lXJEdYDEeqTENzrEo47MqcLEiwDEuVzENDTEmBuEd6BES0 nMcdrEfSmwebFEt3jMeaBEhbRDlndD3siz2H7EuRgEaLoT0FTEBp7ETyg8AIjEp8Q7is47jg+0Ct /MirLMdX3EBwxEqvVERG9Mcg/EHm+0Ei9EN3lEO0DEjTq0e4PASg2szNzEkgHMvRbMdLZEhnnM2G dMhLjELALBmktL2JBBX/lms2wqM3xny2b8uOE7SK5Jw/gbSKmDzL5xyIHDxL6dzHffSp6dQs7ayu IRzC0qDNh9TNSuTL3CxKiUxKK0S7xOTCUNtGmZs7y1jOqZBP7fBOqphOkYhJPxRN64xJoMrB/Sqv 3XJNAt0O3MxNAWTGv5zN/BFMTpRIXgE+3vM1jYRKmHtKqqDPntDQ0jPC7OBF6uxPEd1H/7TO67wr FDXNNblNaGRI3GRRSzxAw+yVLmQ5jHTPjeQ9XjmGGuBRRolOEoVOEeVF/CRRHZwH0UQs64ovNRlK Z+Q+8OTLA+WciNTEZfnEosNQCrRIVTkGHxUIL/3SPilSIxVS6nzO/fRD/yQ90tXaTgtLkwQlz9qc UwaN0e6jSHO5xiy0JhwFFB8NU0D90TPVT+gk0ulU00L1h/7KrDdt0r18UgR9wpmw0+6rPXrZPS1t LA5tRZO8iS/90x4VUzUh1ELtzzQFUUU90iRVVPIK0D8ZSjuF0jn1S8VTK8qsik1dw069iX/4h0+t gV4NVoHoVZEg1mEN1n/4UOkkUiONTlTFTiRF0iAV0Oti0i0ZQKFsSPHcTTqt1adKzly1iXDlSpvg UR41VnPtVR8lVmM9Vnd9V8oA0hA9Vf3ET+w8S6lS1APbTtbykwR9yL181H/lVm+NKfoEScssSVSM xcsE01BFVjBV1x4t1v9kHQh2rVjtMNQzNdHqBNEhvdc1ha/DslY08UttrU1tLUCVLdirOtir1EqY ZcPJHMmXxcxQPVaJBVZfDVOLxVid/dmM9dj8xE9C1djojFZ7XVKSdVSARVla7VaW3albjUyubENW lEydkFhiPYatlQlkhdh2NQ1mbVaODVHrIlMA1U6RXVotodVH1U1JpdSotVVYxNqsvFtVrIl0rVhj 7VthDduLxVmfdc5SFVKhDdL9FKvETVwUvS5F6cvbtM1IldS5pVsQrNqZrUq71dse/Vq+3VkvDdye BVp4vQx5XdZENVV8ldbrFNA2ZRRsldK3fdrK1SlwpVmRQFisJMmapU//wN3ZrhXdd23XsI1Xj9XY ZS3a69TX52Tdfe1XQIFSOZUJBa1dqJpazIQ/eRjB7RXByrxM+eTaZF3X8RVfsPVZ4v1ay0DVjq3O 1OVPEyVV/jow2J3clB1PgrXebzVJeZAHgfBf/62BANYOQDXXAlaUxI3fEeVYZk3VNsWuRl0U2pTe /NXfllXDAO5fAO7f/9Xg/y0NnnXYiRVVNCFV+CVaBi7T1dJPJSWvT3lblA1PC66s5MxgDubggcDh Ab6MEEZgM01UZ61XxE3VI0WuXgnK6Z3hygJgAf5gJxaJG25iywDVH0Vh5AVSNM1i1u0vbiFKJfat Df7gKBbgAd7hkpFX/9E8Xvcd2tMtsFt44y9eFQ0OYzKuYzq+YTN2mMU9YTKd1o01slsQiDcOZEEm 5DgGlQx24g3WYSlelXzIB8Ld40FN3RR+5AQzZEHO5BrAZDSx5Mr13kZuYjPGYTH2YCamCZeFTE7N Dk8eiEd+5Zp45UfOQVl+ZX+o5VkeWx305Fp2ZVn2ZVgGZl+OZVgO5hpo5V4+5mRW5mVWZpnAZYHA ZUh+5mK2ZHqgh1amZmOG5Td+5FuQ5k0WCWimZnGe5miGZGQ253Se24Y15VMu41LO41WeZ5tND2he Z3I+5wS2ZEs+VH8mUV5WZ3QWaGc+Z4PmZ3OmiYAm6IJ2ZnzO5nw26P9hhmiFhmRsfmR6qIGLzuiI XuhA/uZ8AGk41uRhluiSLumAPulspmiuW07/1d407N7hk2nhe+kPvFVQJleZRVg0zOl6ZuaExudy LumYnGVlLlI0PemhXueHHuiGruhzTmmWbmpiFuqhxomFnmZrvmpfBmmpDmlCHmmlTueV1mqzVumg TmjFc9kmrukO7N+ZhmualWmrRGXcTceQhMOGBea0VmqT7meU7mVSfeqlJmiq/uWbyOqDVuu/PuuK tmq/ruiMRmxrvubJVmtv/mWQbuiPDmeTbmjE5mu09muWXjqX7l4AdmsAyOCa5uCaLsHWRke7vulO zevd3dXH5mqKFur/W86HE3ZmMp1qx3ZohgbqgWZsiUZo4n7sbR7nlI7qYAZnmbjoc97oytZowlZu 7cblsP7s54bosh5trl5r/rVpDXbF1F7tAC5Hc3Ttms3dXV1O22bvnaDs4hZviQZSo47oqB5tyAZq wk5us1bumSDwzw5sYg7wAjfraw7tjKbuct5srw5pbx5pTg7vggbvvm5s/qa7E8Rh7UXtEO/eD27t Oc5AEv9p+ZTvrYRvqtjuyBbqbE5j4R5v0HbqA4fxBRdwA7/q/zZu5F5um7hsjbZmWb5mG89ssP5l S8bkQfbuATfmA++J0jZtDB7HmX5tATbx205x2aZncoXt2sbdzJxo/xzP8OG26h//b6a+7+Wu8RtP 8zN/7vHu8R6ficsm8iL3ZCRvcIEOZLJ25u7u7BuH8jovbg2PWhFM74SF7x1edC9fWF0Fc3TsaVWm z3E2brRu7gWX8nyW7mVu5jhn7lGH7uEm7l7GcOfOdL6m7svOhwcfCD/nZkFn5gmXckAP9Q03dA6P bJb1YDHu4DrOYSZeZFKWZ0WpchZR9nyKdcsWCY6OdYHgaJkQa88uZGwfCGvXEmanu2K34yge40TO 41P+lG73kHO/JyTHbo1+8D637HWfCSffZE5+ck7m9iD3VjyeY1EG9jkOY38HdpBKd1qK9meXdXh/ 95oQ6yen92wnaf98n+FiP3YoHncdLuNyP+QVeXaDp3bsdvd4twk4bnjPHuR713j1kOdRVmSa2GF+ R3kPgfdpZ/eD/3h2v4mPNmSdJ3mY75CXt+Fgh2colmKB3xIBM61adfZop3lqD/mFN3mHz3mR2Pae T/kcDvYP72ByR/YOGTDhSp5x7Tdnn3Z3J/ud0Hl672yer3rkxMBwJ+Mbjm2M5/eiZ2/cpozMycDo CiEWT0f49nv38vh2n3lp74mRd/hMPnm2r4zLxPiqBHg8ZvlJ5w6wEb5/gqe89969vm3/KntZn+7B zwl7J/RwpvrF147X/vfI1F7vRW0vp3RQjn3ZH77K38AEgL+kunT/MhfXu5+ukG/6gxd8kbf3qD/9 FZF7Mk79GhZxWCz6Mhfz3XfF2tfA47F8Tr3dMLfrBPN4mZd24ccJC1d840f9ulXt9BZlDZRrFNf+ msjrqwWAsMnbyCIo2tfpu1flEUv4mR//VUnHKAYIAADk1ZAnsKDAhABq1FBY8CHDiAcjNlS4cCJD jActCkxQ0SPIBCJrgJSYMONClBRXqmTp8iXMmDJn0qxp8ybOl/To1eAZkafPnEKHEi1q9CjSpEqV YmRJUKC8pxcXSkV4kqDLphqnUtxaMeLIr2E9kmRINkHHjSm/xmy69C3cuEt3ApVr9y7evHr3ynSb dWDFgVANHowK/xUiS60pTypGyRWlx44gO64kq5Yt24le+XLu7Pkz6NCiRxvluJZh1MAnVU8k3Pc0 68cmFUamLRLtQdy3zeK2zdrkbL+k974rXnw48uTKlzPPSTDqc6wFpT8kTD2u39thwZYES1Iy2ebL 39Ugz9C8efHq17Nvzzd1RPiGYculXNa79rLhz0Lm7X60ceWtlN5/BRp4IIIUpQbdgljNZ5dFJWk3 4Xa77Xdffgnqddx5HZYXoIYhijgictQtGNpZIVWoolkUpbgbiXKh9yF6HMZ4I4456ujiii++yBt/ +22340u/3ETecTOmRyCRTTr5pHgh6eedfuGRZCGPUK5kZA1Gcv8pE4gCiqklmWWauReMV7LU3ZUS YjiSlVr+wqWXX1IEIpI2Dngmn336OZSPWLIYZ4ss/klnly4pSSOeev75KKSR5pchkIX6yJ2aZ9JZ J0tIRkRgknlGOiqpj8KJ331VZgrnkHIytOmcse553ox3elgqrrlCyWaVhFbYYptlwppol3Z26OmH x4aqK7PNkphmpjxOCKSUrT7pZaKcGivmsrQK6Kiz4YproKCq8jelmtBe+yqxsm7rbbfdjjsvvcxZ Oda0+LlJrabFxiqrotwmO2a9BRtMWpBtnsuqvvkKO2e7AAeMrMAHW3xxZxle2N3CqD76Lpie1ogx ySXLlaJLg7r/mO6oENsEKsUmyzxzUZOeGmylCgNrccw0+/wzTmNhmuqUvwJ9NNJJX4hpqzcTnTTU IX5TwzdVTx31ZyouHa3WWHudYNVUU2312F+jOWi+WO5sNtvNXR0R2WLL3fZdQntctLV06x0a2X1P /ffbe5+scN7qCq6jPxH5sziuYYfNUNyQ/3344BhWRjmRiVOUOOM1aA5p5GPH7TjkmNu1tek5Mr66 5qt7zrl7ftTgh+yyI0X65LinvjvJi/v+OuyKv+45c7ZHZPzxRgX+9uQvBc479M223vn0w3+unPHI 00578sjb9Hzoc1P0fPTlj8o5+psrTn3ryNVu+/YMZT977Tdd//245I9b7Tj+5vv/KPuqFzziCa9z oImf97g3O/lxb3vekwn/SidB/Y3vfxbsU/sICDvfZdB6BPRMA+VHPwUmT4QmpMn+mNe8Cl6whZGa 3vV+x5D2DbAz8Lvh+xr4PhE60H59E59LyOfCIT6JdesbIAxF08MdMhCBPDThA4PYPMClEHAsJCIW VfdB4mXwdwaUoQ0TuEQF9nCE9FtgTahoxfuFTohZfOOB0jdDI2pQeDOcowH1EkIdLrCMOMxeFGGy xvvBbXxuhCMi//M59Hnxjouc4wevdxcmorGSFPnjJb83yP6NLnyJ/KR7OMhBPLKvgMO7415yyEce kvCMK6Gk8//UWEH9URCUtmSPKBvJSJaIkoufcWAUV9lEMp5QkGUT2wpLR0ikCcdMi1kJfZISzZtc gyHVrGZfjrKa9nBuIV8Eo+fWsshGtiUjRoHfS9D5xFeyMysZoaIh2Rgp00yTKM3MCUekeRqLFOWZ DYHmTOpZzsTQBADXOKg1a4BNmPgTn/ZMzGpgsxaH1OR63gQo8DLCyDzmsSvm/CdRcuhKVToQALJb iB9LKJGProWNpFvJIct0z9II9Cabsec2b/pQkK4UO0I56EIQik2EMrQ0O+2pOSX60aXKZJEAoB4p FfdU142yoEy9ifZYOUIdxo8+6AzkMweJzJj6qTEt4adjJor/1rUupqZmRetvXtLMmU60p/5UakQz 88+cUnSlOU3rWqppkWtohq95nYpat5lW1SQ1mhdBqkc9WtPINqSbe52IP6aqkMxmViAZfOpS73rV y7ZENdtziB8QG8KMpHY1J6WfSVkqW8mVbYpA/JNZv+KVwmLGL5fBjFz3KZvfvia4A+WpaHlaWtmQ NqmUXa5ze7pQg35lqAclrHKfqZHsEpS793zsaJW7V5tMVHNP1UjiwMs4z5rzdxetK0gbChy9riW1 Z6TdVGwXWzSiNCUl1S/3kksf8N32UbklLnGXS5/CzrS0ulXrVwLEJAfPt5yPha98vQvQfXL3udr1 6DWBKlih/4Z4vHbVMGRnG113qrgr+ZysZE3szcVp16kcTAn6zmvi+I4Wvjv+5w5NGtvXZs+k9t2j kBti39lGs3+6OjBiKSplCMdmscUFjmne0RQ8VdgxVr3wicXLYbzGOMUc/nFgFfpMovLzzOBdsXh5 7NeiqpgxG56NhWWc4/RyFngz5iwjwYzhHiM1ygLBr0NQetL64Xd2QxZhkt+cXINBGbgQ7e1w29pg 4BLXOAJJ0q2Ok9uAjnfQYi7znFN9VTdnV6gsFSp14fxhVcdZvm+GaF5RDec4x1jHmR0eaC9iQNCG 04u/BjOTu4tc5b52zgCOn5JTC8hSL1vOlBaul3fb1sz8lv+vLv7LfCeiZQCMe0wi+5BOu0xZVp+a 1mhGrlJPrNZrWpO6Br1mUHUbbhRb2to/fq6/bx3w8CJ3ve7VKGjN27rTWJapky60qqU95I149Ib9 7WNX9BvZDNPLLfmMK2MBq2lvq1vkn4IrP8/94o/PFbIPjyuZ7UpxF/81MA25bogTgvPAYNfms2bp zNeda2WHNtEYhblcJWJZ8xabsfusarWTfXQMJyTAFOdwkGG7354uWepEHDWYPmUj44iKUaBuC4w/ k/buWnehCU2o24WydrXTpJel3KUMe5lKVhJzncUkIRkDiUiwx2Ts35IwuD5FMGjOvTONlwhRFapQ eluT3nH/d6h45j7KGK5Eko7kDFcxDkx27lH0t2T8UGq0qCXJi+yJz7xiC6rYtru9xEPp64g4n1E5 8tJ1YcShGV1yw/ti/PRIUT2tkAWuMPGJqDt3tfOZRdUtVu+UntcjA49XP+2LtJ2tNH5OYLb8gVEM +We6bkRCXGL0S5+LMOwgOPmy/T5+ldFbJX7xwS+UkQ2o7Irn8tmdn+QNIPupX66MUw0Bj+6FxhKZ 3h5tXwLpX+qlB7klH5OIWgAmy4TVB2fAWORN3kLF3eMxxXJU3ykp4O0BHMGxBDC1EiVllegJHt34 mDa9DIcsBuvdykKITM9k09HVBMf5FE1Y10ogFA3uRRCO/yDmqc+eBVACkteurSALMlEDNlE7WZLp KKEPzgSoaVnFcAjZVeCxKMsGqmDjaaHcDeFQsQQ2HaFeBCFpdBQYXR8QqiCvxcS0rZYrVVLfAc2U aYbNOd1l2ZqV0VyU/cVBaFlxVCC58VZDjJsYehoFDmKK1ZphAWLIBSLjAeIlLtgfLgZhMRh49dVj bAUn0lWibZcmGmJjJZZjeVnnXZgpymIhrhUlAt09zV8LBh4ffZ9Q1EM91EAwBiOuxFtjhVlzvduZ bRzAncYilgcjRuMzJuIjhuEkquKC5Zm8oZpADVeHuRxIAVVFtGFodZgj3po30hk2Rp3D9dY3qlo2 bpdE0f8gOh6jbC1jOqkT/V0SSckgTBDjMEYEMZKKMb7bso2ZrmXjO4qXFzYkuT3jNHrKQ6KbRJoj 0REUqyHklyXkD9Yjuxmkj3mkHSIjj9WTRsoaRmrjruFjPYLkQr4S4FkhL+YfTgDjMAIkMBZjR1ok So4ZXJFkQZIHI0IjkuygF+4gUVakqPGkGRqdvLGVYzklSnpYlX2koTVUXb3YSLbYXfkWR37cxgmH SHpYmzFjRv6kTDAaIPliTtikMDKEWz7ZTlolv/1bd+HjP4HIMykiNFKkGD5isqTENG5lQbakwP1g XbYkOCpknfFaSNbaVg5cuy2mrrFYJY4lOO6kS44gSWX/3/wRBUAKZGjm5ECW1VwyY09imRm2I2UV pVASZUaYx0UEiGA+IzQa5kVCGJVhpjEG3Y55nGrSGlYyZVZypGOypqSdpnCmJKGdJGuuGCeaJWri IbQ9IFvWRE7CZUAKo01uJ6R84nNeXViOYuxhWXlC4kOm5yIW5XkYWqgs4tWRIq4xWHzN3MjhGa6B pG9mm5Uto33WXLVJ2XRuImqWZ8i5mYFqmjsh6H6Son2C3H1KIQuO1FHc5FtSRGgKJBzlCYeGCdkd nofeioTGCBpCiP655UCSJk7G5RC5noiWH6PYCo3IaIm6R43CxY2WT3deKHey6IbCy4ce3hh+i4jq YJPg/54ELkeKwiWG9iiTIpL/WSD/3UmQlmGSYg15lOY7sGhAZmgWTdi58Z/rKZ8GXindeEp2Fkc9 bKmKXmh3lmaLSpji/Z/Zid2cWqmZHo2NDOOWcieTvqmf6ogt1IAtDGoatsd7kmH/gShiHmnm1aBN OUuOqimShGafZmeT4kihGmqhEipDaeVFksbqiV1DhhqNLt6I8oUSJiFp1OgZKocWlujL4cTZrelx oKialgdp7kinDiqnGiqdpaqoLgmdDikYkt9f7ggctiqkQmFyxKo0CeusGOtbZuma3uS1+imcjoiv +mod+hU2imVE/dU5aqKARhR7eoumMR9UFmcnzie4Kv+YKH7YuxoiYs1ZvRooK94iyLXjvQJWf1ra vzKoKCJihA5sKtYiYywsYw5am21ajOqJtQrjxKYpj24rgnirp/Zqpx6XO/4mYiLoWX2sZGWlbMrp bAolskzkZhZnJYblyIasPRokzN6jy0JnHcpjM5bscvokuKXmcu5svDLZNB3mcK5bmG2bhHYoqVqr Td7qru5ojHQroW4qQwBrsFqkSWrmY+Ilmq3nK24te2akcSZd1DHmQZYtUAJtFJKacxZmYtYlVb7t QsItu22tQnYjtXndHZbpNbzDdbHetULtpa5pk/SqpzorcsKi0DbmVJblNoKhQ24ZYD5u3G4iJgao fPb/7GpqrXHqa3Bg5mQqY8lKpXL2JFrabYFirtHi550lp2QWXuAWRzUxX7Zq65tirIh0K8fGhDu8 Y4YVJHFybtA2ootWo2x6CFJuptoOr+V+ZeeSbdC+rL82L906J8Fdb2XKbPE+p12irXPBLiHChIT9 LeB2qHkA6tM+qaZqbOJi7Uq4w+8uxO967qpxLcSdpG9OFPMpYgUqYp7opnTCY28e7W+2rv7m7QBD p/gq2/7C29TxpujObXDqm5mdrpz5Z+uyI8QlbWQah/mmH5dVq9NW68Bwa0R4q9Vi7e+2sPy6A0vi osHWYv46KLKV4/9N7v/e4H/qrMwZ7YPisJ3ZIoM6/6ZWPG4Pv+wQj6cl3nB9kmfmcm0SRyjmBmyh eVwP62bLhecRKwrt1oj5/m3tEquuOumckgjWqjBFyC9DsHENsHH9urHj9dOeMB+qkiBy5GijSiuJ 6DEXJh9zAO7flsdBffH53imMWiAaV637Wu0bt/EL1+8jv7Ekd+BRLSqH3oUfGxWOWiaZbHLAlKm8 AEidDrKynDGQ2ikapzHV2oIbv3BExHEsewa0hgaSqh3oyl0uQ8kt28WUnjBpmLIgi0kYS2yVCgye FkgrX62nwnILTzIkR3Oe8o6jiB+RknKHEKExA7MoJ3OCAGvvxu8jw/Ezy/I0p86ylJ/hFSlfoMdQ Hf/rGI5ykHpLjoBzLJfzOLuEHJ8z5VTpNpvfHedFnhTyGNOIKYty/yFAeSi0oCbuLEPyM78xAET0 PvuhVXmyx74FKBPooXb0hoCKrajz6xEHIBOyGJOH+SKehCHAsXoKQzuJC0P0M+FzRnviLhvIjcJY 0X6rEG70K/L0EraznX7oPPPgSPvyBRbymFYzSwcIQ7M0Aij0Sz+JJM+v/NKvNGft6PbtgeT0RYcq Q/iCL0QmJ3MgWJutR+MFUdcK4hHML390eoTwUmfyQicJVDNfVFM1JUOyRcCwQLzwLQvv3LWrEB+W LGal0h5oICLpuc6iTWNiYy+EWCuEWPuCTVevYZv/WmMz7r7iXirO4i3+ayZSMeRytRdjMpWSqrmB xrmB6Fyjb1MbR14HdJM4Mwy3xG3jpWArLumiboUpbXQOrb8t6M2O7s8l44JN9tR5F2J7sM/icGb+ NPbKY3EfN2+GH5kKKZGib2iICtO2dhfONUvTs1RPdY6UcwtPdEPA8UXEQzzUQDzsNut6LG4SYgyf 7eW61eVG9+WO9VgDwGSP9QUTb7LRLVoPN1cad34v+OOVHVGv9th5N22r9VLXqQXGtnenx1PXgHmf twvD8FXztV9T1Htv9VkzuMndd9eWNoL/hoHz99tONmVbdljjp/Y6N4uv4uLeZY7f+D1+rml7seGp /zQ3y+hRw4XkNoqHou+xRnVxzPaG78iHp7dEw/f8xvd7Zzn3ajUFbyNk8nc5oi3H+biC93YN0DiA n3l8+Tdzsm0Gf3luDihJ3i+BlySQN16YlrSLGvWEE8cxz3WZ5jWRc/iGz3ZtUzL9TrR7Y3lKvPdC LLp7P2a7Naxi0iPwQrfojnkFH3AEA61yS3ZF/LeaizoDL7iZc/BHDqjAkbl1Q7D3vsQoXzOY2nGf +/Ipj+nhNbWuxzavczihR3WH4wg5u0N8/zWxxzd8K0SJl3iydzGEIuITs+TQOW+0czGBGuZ++hwu jlxKWLZA0DiNqznjDvEnava06zgNg5sNZ3q62/8wO05WmG5gJq/zdtf6Uqw1vV+4eL9DXr+0oWvJ K1e0ezPEwC96RAw8Hn9nTVS2gIs7w/uClpPaHs8T9ZIv8u15zBBrW3fGaye5xq/08a4EsAe7jkTy wcN3xKM8wcP3yrN8tFI8TTB8jUM8xId1lt88l2/0iCzrHwtpxifyvHvzW7zDAQjIAfizhkcseTQ1 Rfg7ofu6kxS8y6+8wav8yaM8wuMUxB7pTa9Ew1f2mYt1PDS81B84Hz/J5h6JUQMg6/FgPAv9Uhy9 3BvH0dcpkz95mPw7Q5B8jlQ91i87wRs8zi971tONgFf2ex/+WEP6zTM72/QMGa/9SPegXByA3M// KJGr3muPd3lDOdRHPdavhJYTfuOH/tS3DdgvvprffMOzhON/TTU7eMWotpzuRdFbfnHgPtF/yNEz rQYS9a6Xt8g/CeAjPOOzfMRDusq/PtuI9cGrfsE3PrMX/pl6CDwDMphyxu33PvcTPe5LKY0cA7/j fa//ur/rPY4QvtUnu/KHPuCvP/PL5VK4N+KLfVjX/OhfvY1qNGuvlEoDxLsaAwe+E0hQoMEaBhMe JPgQYkSJEwkeqGHx3YGMCxca1Fiw4zsExxgmXIiAIEqVCFhSdPkSZkyZMwfGA3ATJwCb8Xj2rAGA IM8aQmsOpXkU6UCgSZlSXPqzqUSfNXwN9RXP/1fWeDW3GgU6VebTl2Ihkg0b9eFSsxPXumwL0SDQ hnChmvyJM65DqEpxSnz70uIBwR8zWlw4WGPDku9ILhYpECVElWgpV565k+DSnls5Fx1KtLNl0aOZ Pv2bdDNViKkfdg0683TM2H4tqyWdOaZAuQojvpPbcfdP3wiH71UacbZEw4I3Jr5YEGNjg8ekNySZ cvJt7ZZZYz7el6dOmzeNFs3Jl/x3tbb7omef3jRy9H77igV6//5d9+rXk89/PK273tvPJgG9wim8 u8IrEEH3yDrvPPnw688/CjODMEABLSwLwvQ0xA0/5OCrrz0NfWMIgLkWyi8ukDh6qsXTOvTQJf/B LgrMxuYw4qi66Y7p6BgEFIpspZS2O/IyzkD7KjwmxbtPKCYT7Mw+vqyEykOzQvwOt7KMe9BLEE2L T8wu4yPzwjIBVGo83ITaSqebiIpTJzarDPPOALMEcE8Q9fwzwzXNPDND/P6o4dAu97LNT5DkShGk g+5D0SGFlpLUOKcEPS2wgZg7jLlPFVLox+mEDKmGyAZaqSUkXYXJNa4ytW9B8cqr6Sk4C1X0P0G5 NDPTRmkLFEtiq7yTzF4VLbZLXescisnPoDTvp652yhPYZX/lc1NAt2V2WS27RfYPoP5IVNtFvf1u VEcLgjS4C3NSlq1uAUPsoBwzSgijxajjDSX/xYh8leDLPuvJVqiihBZO8mJNeNY1CR20vl3X6k8+ YyOWt+Js1RVXWA39e7POeQt0LU4l4ySW23SVZRTblyN+cN6Mj6253J/OPfRcRMvt89iHfEuxJIRM 003Sm07kCNwSPQ6WIsQ+Dcwj5xQjKUiGBqIuyFS9ZknVgsX2jKspE/QKQM6ixWxhjyf+VmZwWQZT 45gzbvnju+XOlc2uVkb7WYa/gnbjXV3emNFx16VXRsUfOrfXnn1OFOa0fljqhx+K5Q24CC9FGky6 Dfc1ouVsDFWgHA1jrKDGSmW96x8HHpv21sqWFmWu1NpJ1/IgRpbXmdPMs61eRZc4bsfxRrPu/wCj LNDPJr1LsE44odcPT5b3xlt4K8cMFlvuXz70v513TvY4zS//Sf0aLs8LIfDzohTSp0EOX7nnKupo sK1Zd4wg/3rMkFpVOwMezCfXU5j1TgaeN30Igl8SU4kqRrx6GUhEI8pP+DwXKP+kS2S+Os942kNC LD2sWghrEr2857SQjYlmWfqggTYUoQwWCic8uw+6EOUzp93kcjjR3IdSpLn6rShSl6qZ6GomogjK RGo7CsyPuDad1lVnJKzz2gEPqKTQuCZWbyLKrUBzK5ok54JcTMrFYiLGZz2wPAk0CmuG0jPI2VGN BpQcuhIluYm0byCZA2QgO8KRdlVKa4U0oP+NbuSpfTnSkKQSSHWuk8c8gqUzYLSWF+UIxqigUW+W PMuw2qgrOKYGkw/cys4IUi6eiXJs5vPZQFjZQ1pCJHPuc58gHwJIzSnGJIkMiV4WmRhGDuZ/WBvm Q5T5I1ga0FqvCc3t5kgROB4FlGF6pmzS+BKSeUaMnzFjGOdow1duE0nnnFwfeabOXOqSkH8UpIpc NCrOqRFfN7KndKq4z8agk4udpCZovChNWQEUoVHx5BzBctCgdMZ8rzxnHxO6HVYeSh60zGhGeai+ dw6SkEPU5Q+CaZeDEDOPx0Sk1k66TytWlGANHWNElITAam4SpjlFyhep+VBNrtJnQOVjO3n/WDt5 ZLRg6DpqDZb6B3k49agbBelIcfnO3hTypDClZw34CSTe+Ig6OkXSQmcKzlM+1KFiVetEvpjATm6y rRHtoR9rSbClRpUgUUVqOpmKVMk9FVFSpaogRbrLXoZUc/7wRw0Wq9jF6pRzc6lk/LjKVWeu9TbW ilZRCqoysslRp9lEKCYZurCpaPKW7HycUoqqnY32FbZ4hS2S8KrXpzqVqVCVh+Yy6lH1AYCXh+2l Yh/S2MfCRLSkPApKtzZZh1wWs5nNzGZwupo1NTSniatdcgVFWnJqBq609CMAhqqu1oaSJq9l6nqR utSHLJW7E9Fte/W6XqXy9ge7zaURfbvL/8IS17gDeSxxxzLK7CWlpZPsKmO4FtboakdtqD1Ya8zW neySTmzxXcs0SyuWaNakj9BjJ3mhcl7RqPe19UUxU+MrkY36db0+c29736lf3HjUvx/1xxAdy1gB +9gtBh5dU0pynYNQ0cEPhjB/avWkBlWvZO3Zkgv3s58pU1CGWpoRx+ijQe1u0MshYp42OaY2KXtl jCQkcU7aucQsE4pGWLJQRs8jj5wcdUJV5g+XJagUPJPntj288+XsnJ4gCjHHOHGsDXPi2MYC4LFw frOeQ4hl+IAwIs5Msijt0GlYyslOmnljylIYrS31uV40C5cEx7yot4GPzDID2pVQHUrNnP/Qb6Uu LVdcmbO5Ioq8P+tZ3E6dFjTZGSqvBQp874JUANA5xrSWNW6gTWI7tzewG332TY5K6GcLEijtA65i IQ3pH5D7J41NN4EhvdgztVq7g3phrStqhxp0Gt+efub1GEQl3RXLlHA7y/GCpr0hJ0+Ei0Ncwv/y oDlVa7p/C2c8KHccduas1+RbePECpG1kdxxudFZv97i1QT+7N9vsRfazmXo5l/cWc+4DbuZ2HO5z v8zRSvGHyQv3NPttXKz2Fjq+H0L0PNrqWr47GJ3mtEQOXQxDGqOYvIZ1MxsmfN7Ag3XDY8079SBw M/MinyxZO7MmsnBTTm/vvLbtXpYve6//Vj9z25dS6GcfVbfzsnN+RX739Oly5zch97wCf3V0l1td FLu0zfR0dqglVN+eHjpB7K1GU3sderWi9+NhHbKeHw9qX+Y81gWu9dAFuXnSqhbfTKkrX9vSlTrz /LekDluWe/yu13b2mnY/+2Jt29Z93TtwtZ3s3dqcsTvOXLmJO0RIJ1/dkf698hJ/YNpfH6CVH0i+ 7719yVv+T37zbMnOJnDSz3DVwjIe4+c9N2+hP/EgI53oGLT06k+3YcC24/k0XnHgcbxL+k626u7a 7APaUK7gJGYgkE3kDhC+nO0+7qrt/oywdi7Sdu7cyM0CfQwoCEzn3G3VvufxRM+CdGro/yRP++5N 6I7Oc6aiBc+mg4wN6v4j6vgMg27w6XAozqqM0T6IeHYQf87O0kqmWaLkJjDuZzIIXTZEbgKFznAC ArkNgurO+NID2hQP5FiOxQAtr+yuANfuz4Br5s4NPRZN0QYvPQAMBBVw6kRQBnUQf7Kv+1KQ8rZv tMQpzcRJyUILLTKJjGYqVvaolSjKlkhjr0bOtmTrvRZwr5JCxbqQvd7rxV4sEqNKpBKLsTKwxwYM +hytxwTsuAyoxWhn8ogu8lYQnSRsD9VqFCkMlaqJIiiqnW7JtSKRERtR+GaLEW3xKOprASXxFydR r/KLsAhiiGiOwDDRAwOMIADMx0Jxu/+Czvv0bQ7tkA5XERs/LbOiKVZeQpasYSCsARxPrBFl6xHv ihcPERdlQhHV8RdvMRJ5K8V0cZcciwwV6x6dMcCc8egwixqLDiCzUSCj6xcKsiCP5KLEERzH0RCF rx27sLYoMcbWMSbQ8R3dcRH7ihhzMXN2C/AusQJ/jMA4MRQ5cSC3YwXz7RRN8SRbEqEMkiAO0lUW UhzDsSYpg74gMSJmjBJrKyMrch7NcRJ3chKDa7eWiseOyyQHzCSb8RmBzCVHIwWn8h+rMSqvkosO EiZr4Bceoiu3oyYXsgYUsjKwbR6DEeXe8SJ9ciZ8URclci3N0RiP0rDu0cfy8cee0in/k28vsRIt 6LAUVdIqs7EVRwP0KqMwC0wruZIxB+Irv1I0wHEpyHI0cm8ot/ApVIwtf7Ii0TJDytEsF5DvbGy/ aC4T8RH68rIkmzH6oNEvowIV6zAlo/ItEvOMyKw2XgUAZPIxoWIxIRP1Csw4xpEhyxLP0vInDhEY zXIS42wHg7EL324XYwvFpEq/kPLcMnC/PBHIlNIDn5EfXxM2i87ouk8Fq3IVbRMxcXM9j6QrdzMm DfIX7GA+YVImKQMorCE/GbI40UKv/K7jUE5A2VLbVM3FhPHjls0zsU34iBG/PFLdunMkN9E7UzNC xZMyZnPyyNOSOsjLuuxDuWQIG27u/94sdCatz65uz/TMQ59TCNPjF8AMPkPIS/Ls6W5CP3FUHFVU zmAIhjBTQYnozK7w49Zr/eZsQp6QRAiQvgR0vYgRqZpvx/TyE9WwuEAx5zD0L7nPPCvvGjsUe3qO 5D7m1ZLj1BAuTMWlTDkk6xpPW+wjRu0QKOxgN2+i8upUe85UPnI0HAFAP+cG3lJUM98Or4CPSDNz 5fzkZoz0CvcEHRPxIjtSkKS0JL/TUiHiQrU0QwPzPAEK4QgO6NoPucYUVLNH9FKv9NzPIPND6HYz RuO0PgGATrVPTfN0R8dyR/VTIf+09jyPAdVLOoElAu8u7n5l2vrq7pYN7n5VIoUxF//hyUL5kin3 ETz5UlNvg/u+79NqUGRA9f8Uzim4FU2RxUMdxFvdTFzLAjLvgz75hE7lU1aDUEyhQlcnyIXIVcq4 rQFVjkIubYOUkz1S1UzwjL3gjhcnEi4jwriy9EolYhmv1TJM8UvBT1SVi9hIVVPa9E3BlQaDswlD z/0YE09XtSDvYz7p02TvVELydE101U/H0mLF1DZyb1Ha0eRubwHRRNYK9TiK9NqiLbaijSKfsimn FUs7MVOPImwglg+9p1e/5GITcPE86FjDVHn6RGYVLgE77y7etSu9tk678j3f9d6AcF7z00/HcVzf b/2SkzqVVQIzg9nmUWeFZ/d+dln/DVYtexJoG7YvQVEkq3UTZaIlVAVsViUq52EeakBxMauCbrTL XG1P8PX+qI7Y4A9x0M8+qKyJIigG5++DYrQ9ZlVWvxI+cYJOVxaEcIIm0ZZze5AGPaTQDvH27ozZ ehZYq07KinU+5BZoL1MtJ8JoqVQ1i8s1JaJIChdiG5dpc3P0rlU+760+27XT5tMxIdN6MQwpxPIm u6kte/Isg7dv6bEXJZE584o6I1J8+3I1odJau9N9kfdrDvdrEHeLCii6Fld/95dxmxc/nxd6uVIr 7U0rD5KA5fMrO009uckRGRQendQt17ctd1E5GVR9Z2x8r1QppXVhKzUvJyJsJkN5/1MFbEZYyfSX cRd3IFC4f/03LKgMoG6gBm6AhsfGPmGSPqdSQyb2SFrsUYkSfWdr5PwzKCuRZod4aI2XNf12gz8Y hEl4aUl4fkXYfl/lFmrgFq74ipOicRUXhbvYi1XYhU+yhgdChstYOx4TgblS6MS28gzYPNcqEfnW iM+3LMkXIjAYj2OCOzvxfZvyibdIirOjhAs3ipFki7MYixV5i2dChZl3hcOYhcdYIM8YItD4Ngqy jdVYbDtZk6nXDqMrxXDRjhURJ+XyfCMyiWFiKRdWcGPicFFCcWUZAeahSATZhAkmi7WYIBrZJfbX iyHii8WYkldRhgnCkjE5jQ+4Gv8R+GvjWAWx0YKRGDktIzRVDkE5Uyb2UR/9FoQNN1VsuX+BmXGJ RITp90gSGYsfQp0dOYUfmZhXuJix0ZIvGUmqF98+eXoXkzG9NBtT2RZXmYh1Unw38yg8MUvDkyJG 2ItruZZtWZZT+CEGBp1FQ5F7eZEHYpfX2ZcnIowjWZ6DeZ5b8phnGJlLWipX0Hrpsz47WXq/j4fF KidVbjppC1Ld0YEpI/rid6Hr96HDOZwfuiVUOJfxtzI2mqMhgpfb2aMJ4pFBGpJH2pjNuJ6PWZlF o12xl4Ahol1lM6bV6ocP6Id9UqDFxpAdWpwfmnnXelXMuYopY6M7OpHV+aIpgn//3zmkJTmepVqs ariqaRiw79kUo5eNP3ka+dq1mhShVGKWhRqtf1qiS9hIDpkpeHkiLPui6zoi4vmpobqzERuzyviM A/tIsjWrDfiTvxq0xZOigxmFhbqxxZmo7beim2KXb7uXGVmjlbqp2Tqq73q116qkh9ukXeUEW1qA 6/A8YzO4MTQ7IntxazmciZqxxRmKbxmu5Xq3k3q7O1qYQdqp4Tmqm1unkpmqi7u0jS42WZJLyfs1 i4Soo3utbTmtyzm6rxu/4XqdM1qjtdiXmXqz5bmFuziSx9u9Y9iMZ7ie0du4ydNLmfvAtVSWg5kl Zrlxh/q+BfysazspkPq/l3q//xdZs4UZnvH6qQ08wrcJsAObtF9FQwPzwVU7xVdxYPa3wt9Zulml sZXXkKMCs3U7xJeakb37ISD5s1t4xnPKqv0ape/Z+yRCh5McK2O5oR16VVw7O2S7kNsaLfxbIoB8 v4ecyJ1awJH8yKW8vGtnNrsUmtFcPOn7naNbhMNYrTm8y3dbtxu5nTN7xDf7iyV6kt2cvJnbnwX9 KlfCwlMCojO8yC8cOybax/Vcs+OavykdJoaZzA09wldS06c8MiRZugGdvmV71CGaVewcKcScuzl6 rpGCnDsd1mN9IInExssczuk8hUN9io26wykdyIcco8dc1oed2A+9rVtlMkY9ef/hvIoJucvrGreD PLdDvNirXcoJ0cRa0pzBGJ5/+qcD/bp5vde7W8ijndqtHd3JexYvSp083Wu6ncDnm8sffTS0G9pF vL/TXd9Bu6gkarWyHRsPl9T7N8cvHK3v261Jw9x9Hdj33eFHev8GUa7EC+CVjMppWYoJnr69fYoF 2aLxPMiBXdgfnuTF049gj48KkRZPEpxd276H2cqRnbK1Q8grveRvXqpPHiLqiuW5PMsR94u33Ei2 4xpu4Rr4u78tG+eXHkP9nah0PrVWXiAl+90T/dPre3ag+Daugev928v7nOnD/irrauIlQhAtvn7T fuivXNcH2VW4/uhrIO7lHun/xd7u/fKiWunX2F21Hkyy0TmWeRzST/3YtQPu5f7o537u757xT/Ls 5Su18h7qK0rwj/3vE96nwfm5RSPxD5/u457rG1/0sZEQ9Z7nZ8n0J0etelzmsaOoKTp5iR4iDt/z R9/2lazdUX/nVb+1Kt6SRhjzqT6/wTnzxR0tFL/zCaLzF//2mx+m6CrypR7qff/3XR/Z0/6WE55V 5vftHwLuQR/xnV/8n//ieH+dZlG8Zon6a+ecWZ+Qrx+X6T3jjwT86X4gvp/5x1//LYnvU3/lAeJP jRoCBxIcKLCgwYUMGzp8CDEiQwQDKSKwiLEGRY0XK26sqDGkxJEka1w7ebLh/7WSLFu6fAkzpsyZ NGvavIkzp86Wf3oa9Fkw4UGfBIEaLbqTZsaLGT1aNPgRalKWKVFaXbhyqtatXLt6/Qo27NaeZBOW Jftz6FmiCsVGZLoR7kSRH5+6VZl1pV6TfO/6/TsVgGDALQEQZmn4MEu2QoemTdvTcNC2ihcy5XjZ csfLT+sSrmryatbKdwWbTlwZdUPVOlGznvlaa+waiWPXJk2SqFqzjg/+lNx49cDZJImPjBrXbubN GOOKBDy6r8HouMEar77wOuyk2q07vI0dolCjbBGOLwrgaMTuD9k7XB5SLubOIOtG/Zx3IPXwXW2b Hk7ba4YNFqBBpwFI4IHCDf+Y4H8KMohgba79F+BgEiZY4YIE0jYchRVOCKKABgKYYYQbfshgiN9R qCCHDZpoIIslApdYQpLRZqNAD/7xn44bpgjkig1i6BJ9HcUHn2aWKaZXfvy5JeKIJ2YnIYLZFUhi llK6RqJqEMbYoZZdSnnljwyZ6eKVZ3Jo5Yhqsjmgm+CtiWWabt6pZZVYfslmmVxyiZRrBaWXHlkM GsqjT+DN2ed3eRZ5JEdOSUpppM1RCl1oT5Z2Wpxktnenp20+uqaXY34aKp6n2jlqo43eZmqpdIrJ qqhyOvpqrm+SCiirrvoKK1KDpgleZGxGxqNwcO6qrHsTcfacR0o2dCS0m17/WxJviCnb6qx/lkll i6gumytrvV5IJLC64glrpx2yOKSHqF54a7N+iutqrOfq6q6+riJLaLIoBjyoj4CiOyWKtJbknKRw OecZZvNhim3F4pVXHLe+ejuurdd5vOrG+/rbKsi7Bjtrvr/KKuaiuJpqnLlqjgxuxwiulWzAtenG oaF0ugwRyTA119SS9B1ncdIIORaUWutpbCvHJa/7q8mMRk1zmH2CHCu7U0+4NdVeH7zw1WLLXG/Y MIPZdY1NJ6vjsAYmihCh9Zr9Zrorv3WppdVqBnG0SldslrZFBYfrmTKCmiW6Lctr89aLp9qlhWy/ i3eMHjr+Lpw/Qu51iZKv/3Yi54rHS7mLLTq4LmtCpZcnvJujWSC+nYO990P31Rc4XdEqt/vg2DWG Flq+CY+8qsl7J1ONSy+kkG5l+YY4acw9LC2SgO8e/PKVFU/90pR5b7Gz5NtkPrOHmwd+9OSNf5h8 yk2cGVTJ2XU+bk0Ly7/h+RO2lEil738xGaCYxsOz573tWgG8j7XsF0CJEVAx6kGg8eA3wbD4LXsZ TFr01ne8xySwOsiJj8QiNinsdfB7HwzfCFf4mKRwRi40hCHhQsgQ9+EwPJHSXn2klRwI9tCGXymc +M4iQiJe8IVDA4lTPPNAIj5JW0sMH7YCRzQT+jBJUgyL9MQHwhY2hB87If+jQcyYlMmsj4lFMuNm yHg/3yGAH/dBYxe/B0b/MbAzR5PK/JAzxDuO5YhMo2IIE4DIGpAxkWdspEvsaMecAMWKO4wJHRni Rvw57JILMWMkBQkY8CUPeA1jju/mAsquWHCSvTHPQhhpxgTUIJFo/KREIDkVNYLxeTKhyCXfCEG6 MIWTjkylMbUCxVNCy0hSOeZYMLhAVg4EkbJUZAL4gc2BYHOb3FRkNoupzU4qsphkrGUjzRlO9nWT INskCzc9uc1wfvOdmConNjuyTkVehJ7jtGct1xnPMQY0n/bUpi2dObi/wad38kEoWIoHPwTOcpbV 9OZE+YFIjKbzm+NMJzj/y0nOjooUpB4lYxX/wA+UFoWkHj1nLZ/CyY1wlI5onOM+x4lPeZoTl+gE p0g7Ok9POtR7pXQi8JxIsaHuBKIXdCFDEplRagKVli09KC7l2c9zZhWrLB0fSlUalKuKE5cynWM8 4YjVYaZ1oz9l6VYdEsmr9vSgSrVYU5ZZLRTWNY2i5NlkiFJRWS4yqtbMaFUfIlaQslSxI80qGoHC z4GK05tnhQod1epEtOoTrXPUSDlhilWtOjKgk/1oSX26V7vaL5imXG1qc1metYBwmrSNajU9edvD jrG0jm0sY7naUaKkNCFxVaRC3MrSzloEjh9h7mZB+1yZhna6P61ucUcb/9LXJlShwUSldnP5E+I5 5A+yLG9uy7tIjBq2rdltaWNLe9229uSfwS1nQbJJ38RqVpug/aU+N1uRebI3v9i17mTnmrvv8oeL DmuogpfKm+oJxby01Wg4BZvedyaWt+9t72kRYkaUYlOllAUxfg3625BUtlqX5a9Z77lPX574rUCd MWn/GdSZhtSADwbMXfnYY9hOz5X+k+pEDWLeJOc2ImIdZHjZx8vqUsu1WtzgCf0ouJHQNcgO7WH3 uIwTyjQVKRSlJi01jOY0q3nNbG6zm98M5zjLec50fjOYr/jlO3MFZ7t56pEpXNuGXLM654FeY/Kp u/u1trUSTGEU4UpaPf+DcjmBlLQqn7zLQNP2qYw88vCgR+ZKSuSuS6pyUmdYaku/1oEcVLVbqldm qVazvJsGdEPsYBBcv7otSMQgRDYjQexdD0kP466r92qp+VT62H4xM4U77exNMwTXuqb2XXrta5LQ 0IE/nhSWs8zsofYx3KQJLFRnTWtPJ0DXA7F2DexQ7XdfW48smd+UUc3FIIKb3KnE37iVegfc2KIG A7eFwUuCbk9LO9e3fje13a00ay3btQuVI7+dKb9lIvWYAa/BHT7u8ZCL5eALKTjBBzLwhU8z2hWd pR1kCW+HVxveMV8Iu4XXwNWScinam/jFifi3BjfMmSA3SMc/3nGwHDz/5Sk/edMnClWKqhuq1qa5 1Rle8+WR8jlBBDIgk7qpZyzkGWL/eS+TeT2fa2UeA5kH29nulqMnPeB074rBTY53lOvd5OleudRp nUiaM1zm7S78w3GePWZu0Ug8v1bZa/B4yJt9JvUj9r7XXgO3Z/7tbQcL0ucucqRv5e5PXzpD7l5r wM8ayTKPd80Fb/jX37xilHYYphY95csrhuy8J7tBeD95SDWzlGrPiebfjvzkd6XoRw/555M+FdIz veQFb3rKW55uRsIckTGHfeytnnWI0/6E+Wb84vNMmLI/3veSb3/whT98t2g+8/Rv+/E7rxW5e7zu Rh89watvcgYRgAAY/2tl9kor93KtV3WEl2uyh3g/Vnumxkfodxi913uS53tiF3nv92vbpklh4XZw x3kiWH9wtxPP13/7NxCftxMAKH2mR3IBCHUH2GmF14Dx1no26HDypoMRNxcQSHz24Xi/h4EDoX4c WG/0I3/2N38laIKbxxVyp38i14L/h3p5h3ooZ32AF2jn5n3yJn5VF35ZlzSK9oNyBEhFUx0aeIQY eIRtiITHAWy6pxNPaH9QWH+bZ4c6UXT9x4J9mBNM93R7N4DS92e19WwvN3s8eHMz54hfOH7bU3l/ ZGz8EXnAp4Hux35xOGrDVnw4YYKc54Qh2IRJwX8gh4p013yBqIUvaP+F/2eFMqhwftdugieGDRh7 hseAPmh75OdtjWYxbXiBRkiEnMgwdFiHC0GKe4iHd8iHzreCCzF30GcTMmiNJweLMfh0q8d6Lndr 4GeLZAiGu1iGi6ZXPTeHlvh7GWiEGah+m2iM1SGKIaiM+MeEzIgTqgh6qxiIhhiLAoiNrziIK8eN unh1PPh9O9h95JNsEQNsjfckmLiJbyiRGxiPuEGPzYh8BmGH+DgTUyh6dQeINZGFJUl6sAiQMAF+ YLiSYViLD7eIdgVFKpRXg8OG61eEkAd8F4kdJKiHTEh/HmmKp3iK0ciKKemPeGd6LnGQCKmQPUiG h0dUWnR7StIPNXD/lViZlZWxfpm4kzcJjzxZGfe3jCKYfMqXf9C4gn1IjSSpd61Yck4niwMpEQvZ fXepg3hZi/+jb91FEVnZD1uJlVpJGmw4du+YicQolqRxfBs5fxlZgmKRiiN5lG9Jcq+Iki/Bbjio gOGIkJzJkDrXi4M5mFcJmAMRmLvXjoY5jDqpmIt5GB2phz5Jj6EolDfRfG2JE9WHjS94jVooEy35 mTYIcTBJQHllF6apnIKJmoHJnHfBjq95icUIm7H5k3holo05m7eJm/wXfSnpELJIfTHxhbO3mTk4 eILEnFvpnOz5nG6Bk5d4kwrmCwZRnytEgpBZj7Z5nRM0gEgJl67Y/xIL6IiMaJC3uBO/8As1oKAK ShiCmZqp2RASWoFfCZZeaZEO5Qv1uaH3eZ8dVJvZiX/Kx53I859vSYgnypRXV553CY7iiBMOuqAL WhkRaqOkWZqmSZh/wY7w6JXaxaEdyhAfOkGhyBDZ+YQlqjQwKIhYKJdOp5KfiZcryZJOGaMMyqAz OhBaehcQCqETipoxUXkysYHvWIQZilAbOhBqWgMemkG1mYccOaL22EEweHoCOYh0ORK3CIk2N44x ORMOahCCmqVYGhan6ZwL0Z6lqZXvOWreRYEQgZMMgaZpOqRrap9EakNl2Zg+KUWFiJL/qacRsYBQ 6YBVmqANuqWGSv+jbtGeywmYp8moO/qoJZSOMYGYcJhaH+qhHNqmbEpAj+mMTtiMK1SIdjp9mEme B1mcjCh+OdGgMsoQ0goWETqrOsoQ7EmrieaXEYirhvldQpqpawqsMCSsQdl5pVinAzl9ghigo0qe ztqs0LqqgmqvhdqqXKGjsUqhi7qvN9qBX2c0kRpuveqmvLqpcuqM+fmpMSiA1tekKKqZTSmvmwmo MkGoWKqqhrql+aqv/8qvpLmeBuGoxEZppvSBk1euauqrbmquZcmRovipcRmqrWinOPGs5AitrTqj PTuoXOoV2kqyYSqrRNuJtnp7vfN+HSquCKupIDqK+tlFS3eS7vr/sPA6sYQHjlpBoxurpV2Lr0Gr nM35qmTbqF/KNxkHRGBndgeLsAvxtPgps8aUhQ/7j1WLtZrpp13Bs2Cbr9TaFbGqqCJ7rYkapu+x PcL0gwTragYbt9V5GKX3EHmXPxvLqhoLuK7anCIbssuZtoxXQj7EiSzLtL4KuYrhsHWbjZW7qvWa pR7rsVthrY1KsoiqqCX7bb/IbcjYuL/KtKcbHskKpZnJuh3btw0Ru7Kbo9h6uJ47ux3IdQplHyn7 c27rssBbGQRot3mrND6LuYX6ug+6qEP7pY5Kk6GrbCo0ur5brtiLuqkrRTyrsT/bpcxbu9mKvwEb QQ/5O/HYq+4L/8DR6r3zy7FfMb6ba7uMSqHvETzIWSmfCMARbHZAuxDRWsAGPL6GO7uJusDUwnMO bFTNJMEjzIk9+7cd+3diccDWqsH2+yznaEL2RsIzfJFgi6Wrh8N9lxQsvMES2sG680M19EMTQ8NF XMLge4CcFrRGS7QcLIdKoni3asRTzIHah2QFecXKe6MbXG+T6GVCSMVhfJFGJnUGuMT5WySJZ3v1 w7hi7MZBZsVQ52wtp3I7jJrx8MNJmHZrvHFv7MeSVpBGpn2yVsdbEQ+HHA81kMiKfMjHSDEo1MZ/ LMl1BW1/h8MGSMdasciMjMic3MhyyMa+CMGTTMrOFHUzSINmbP9mXNHIn5zIr6zIjNwSWBTDpWzL DzbHfpd9s0iQOwHLsBzLvxzL8HdUt2zM2jXIZazLzxZYSdHJrvzMA9HKYsq2x2zNCIXFgZzMg5zJ MwHMnCzNwRzOrbzJ12zOqmZurHduy7zOvmwQr4zInTzM0VzOCmZr54zP6EbHNciNc9zNMVHP4izL iyzP4fxazXzK+HzN/ax6+ox9CX0T8hzP3zzP4PzJB92NmqbQxizIfefRmtbMER3M9bzJrlzRe7XK EL3KG23LLJfQCE2LvlzSBF3R8PzONk3J+qzMIc3SkpzSSczM0vZsIi3L0nzRAz3MRh3Qx3TPqJzE Pf3HgJbSUaf/01xYgzUBzwQNzL8MzRjt0lV91VA9EtGREjwpyF0Y0pfsZ0Qt0ON809Gc1Ezd0SlM 1WLdEiiBFaOxH++n1ko2dQrH01i91BdNziZd1A4V2AytzHbtEKLhJHyxF5z40ur2SkmWyjZB0+8s zl2t1Uq1zf6MyVjM2PqB15pC2tKhH3GYw2Ws0jmsw96c2fGM1NM80nG9KT8wFStd1938z2Kt16id 2pBt2lXcjbJmxfcM0TlR0ga9EITN3BXzA9GNEz/92kA92nmd2k0iGsJd1pJNg1edzout3LNN0zZN 2xaD2+kd3bg9E1It1Q7R1FB9FXldFXuRF/aNhJVcgH62zr2N/9njXM7P7Nzond4Dwd424dqfHdbX fd990eCNvdcX595/Rsar7c4Svdy0LdvYIt3svd418OEyMdWvrdjXDdlljdfzTdpNMh3EzcxKBtq8 jBPCbNGDvdT8Id0gvt45HhMJx4UZHdi+rd2hEdnZjb22ts+5bMjzLOBHfeM43uEGbhA83uOnfNbY J+M9/dgtPtwnjhf5rcPGndFeQdLNjdNJ4+EFbuAH3uP8jYh1PdrUweL2rdd0DkrnYBB4judhscsw XshTQc5MTj5RPuU30edJHt/yDRp1TuREvh+LDkN7fg6TXgN7DhbQls1hwdmd/eS3LeUeDuIIXshn neUKPecO7sfopd3oKc7iGWTplk4Y5ubfrKzUA93p1xLlaW7oghbaf87Sqt7dWMHlDl7kEb48ek7p lY7sqRXo/3PgoG7oE+7XDC7cp60pwa7ddq7i5JPseV7p3w7uYk3lO8HQ7Rzn9Y3iRl7tqF3kwM3t C0Hpk67nJt4V5k7v647dwe3l1j7kBATrkh7v4X7v5G7v9G4VjP7bxX7icx7sxy7v8T7v4A7rA0/x W5EfkU3WDT/s127sg5PsES/vAl/xI68Vde4k2A7sJ7/xYBEQADs= ------=_NextPart_000_0005_01C71DD6.A02BCB60-- From Access@freefleshlights.com Tue Dec 12 04:56:31 2006 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gu4ND-0002Tw-Ek for ips-archive@lists.ietf.org; Tue, 12 Dec 2006 04:56:31 -0500 Received: from mx-pool210-adsl188.momax.it ([213.225.210.188]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Gu4N9-0002Ro-BO for ips-archive@lists.ietf.org; Tue, 12 Dec 2006 04:56:31 -0500 Received: from PBZRCFR (unknown [138.114.30.19]) by momax.it with ESMTP id C580079F0816 for ; Tue, 12 Dec 2006 10:56:42 +0100 (GMT) Message-ID: <000f01c71dd3$ca7998a0$bcd2e1d5@CINZIA> From: "PhoneFree" To: ips-archive@lists.ietf.org Subject: Policycopy Inc part Date: Tue, 12 Dec 2006 10:56:27 +0100 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000B_01C71DDC.2C3E00A0" 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: 3.8 (+++) X-Scan-Signature: a0534e6179a1e260079328e8b03c7901 ------=_NextPart_000_000B_01C71DDC.2C3E00A0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000C_01C71DDC.2C3E00A0" ------=_NextPart_001_000C_01C71DDC.2C3E00A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Guideg wireless, remote access pp sharing. In privacy firewall called other features, intended improve? Free = spinoff of the contains no ads built in. Improve original kazaakazaa also. Pages forumsmost popular amp rssemail = to! However given nature systems, disabling may impossible accomplish. About sitemap reprints helpour story guideuser agreement policy patent. = Owners media desktop sharman networks, have pushed. Owners media desktop = sharman networks have, pushed? Be legal grab with ethernet, nicfees, fcc related. Legal grab with ethernet. Toys cameras under best. That undermine quality any systemthe owners media. Phonefree practice exams buyers guideg wireless remote. To is peertopeer books, recent! Recent it be, legal, grab with ethernet nicfees. Termsgt kgt, router = broadband, two computers simplyip addresses. Own or post fake. Cameras under best gifts your. Given nature systems disabling may impossible accomplish several. Files from others without their own or post fake? Key things that = undermine. Kazaa lite light install you are networking basicsgt. Compare = prices find job. Compare prices find job, yellow pages forumsmost popular amp. ------=_NextPart_001_000C_01C71DDC.2C3E00A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
3D""
Guideg wireless, remote access pp = sharing.
In privacy firewall called other = features, intended=20 improve? Free spinoff of the contains no ads built in.
Improve original kazaakazaa also. Pages = forumsmost=20 popular amp rssemail to! However given nature systems, disabling may = impossible accomplish.
About sitemap reprints helpour story = guideuser=20 agreement policy patent. Owners media desktop sharman networks, have = pushed.=20 Owners media desktop sharman networks have, pushed?
Be legal grab with ethernet, nicfees, = fcc related.
Legal grab with ethernet. Toys cameras = under best.
That undermine quality any systemthe = owners media.
Phonefree practice exams buyers guideg = wireless remote.
To is peertopeer books, = recent!
Recent it be, legal, grab with ethernet = nicfees.=20 Termsgt kgt, router broadband, two computers simplyip = addresses.
Own or post fake.
Cameras under best gifts = your.
Given nature systems disabling may = impossible=20 accomplish several.
Files from others without their own or = post fake?=20 Key things that undermine. Kazaa lite light install you are networking = basicsgt.=20 Compare prices find job.
Compare prices find job, yellow pages = forumsmost=20 popular amp.
------=_NextPart_001_000C_01C71DDC.2C3E00A0-- ------=_NextPart_000_000B_01C71DDC.2C3E00A0 Content-Type: image/gif; name="Remote.gif" Content-Transfer-Encoding: base64 Content-ID: <000a01c71dd3$ca7998a0$bcd2e1d5@CINZIA> R0lGODlhqAGMAYcJAAoKAHsABACIAIKEAAIAeYgAcw1zeLu7v7Liy6fW7EcXAFkmAH8tC6UgAMga Dt4tAAAzACk5AEA8AF5LCoBFBKk9ALRKAOJACABcAB9oAEdsC2BlAIdqCKFcAL9dDtNtAAB0ABKM ADp5AVxxDnSKAJSBDbKIAOpzAAeXABWfC06rAG2VCIeYAaWfAMOuBtGmAQyxACXMCj67AV26AI3M Bq7FCbvJANLADADqACrTCDrjAGjgBnXfAJvuC7LZDeDoBA0AQx8ARkIAQFsGMn4ATqUDP8cASN0M OAAmOxQoQTctNl0TSHgUOJ0bTsUVRO4pTgNFOB80OjxHNWROTX47SKlMRrc7SNcyQABjQytbQ0Jj P1VrMoJrDKlRN8VcQ+poMQB1SSBxTUKON1GJNoh6RKN3Tsp7S+mATAaoSROnPDGbNVetNn+aQaan Qr2TMd+rTAC/RRrLSjPLN13HTYzMMZrMQrLNTNjHTQvgOyXnMUjYOFjWRIPmMqrdTsLsTevnPwYA jS4AiDEAh2oAe3sAfJoEdcMDfNYAfgASeBUbdkkVe10ldH8req0eebkfjuAbhwA5fhVEcUhFd1FB jHo5faUxhMVMc+RDdg5ceyZei0xsc1NfiHVtcqxcc7NiiddZdgCGhx+BcjGLe1yLiHl/ipiNds2G heqIjACTeSedfUilhWSrgYOWhpefe82ghemhjgzBeim9gEzJiGa8c3/LiZa8hsHCeNTMigDTgS3i i03YgVrcgYPofpbZfsHdctfqfwIBvyIAzE4HwVUAt4MAwpIKzboAx94AzgAgwycpu04ayG4muoom uZkTzLIjteshugA2wxNAvjo/xmk9tXhNy5lLssQyx+Q5twVfziNWvUFryFFSsotjtJ5ktL5rv+5m ywB3sSiNyUOHzmZ8xn6Myp6HxMdxy+p4zgSutRubtDuhy1KrtX+cyp6luLulvu6ZwQ7FtyPJszXB s2LHsny9tKHOvv/37aGmm3uAiPsABQD/B//3AAAA+vMA8QD///7/8CH5BAA5wY0ALAAAAACoAYwB Bwj/AO0JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKDn+W8mypcuX MGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKMWTUm1qtWrWLNq3TpRqtevYMOK HUu2LE+uaNOqXcu2rVqzcOPKnUu3rt27ePPq3cu3r9+/gAMLHlzTreHDiBMrXsy4sePHkCN3JEy5 suXLmDNr3sy5c2HJoEOLHr3Ys+nTqFOrXs26tevXsGPLnk27tu3buHPr3s27t2/VpIMLH0785O/j yJMrX868ufPn0I0i/EC9IPUP9q5rv569unXvB7dj/y9Ovrx54zCvu1SvPj31l+3hv/8XP7r9+zPr 03+vn2X//vt90BKA+BWo3HTgCcQdd+ElqKCD3Y1HEIPnVWjhhV25J+CA/M0n34YcguifhyOKaOCJ yCEo3oIrVkfhQC8+KCGMEGJo4404NjhjhDzqaFCMPU5YY45EFilcTPqxR2KIHza53pIoRsmbit9h B6SMP0II5JVGduklZEguqaSJJTr5pIgESqmmb0l2SOZK/0EJ53xprmmnbm0K2KKb2wXYZ4l13imo a18WauihiCaq6KIkDeroo2cxKumkiEJq6aWYZqrpppx26umnoIYqanKUlmpqkaOmet+prLbq6quw xv8q66y0Sqrqrc/VquuubOHq63K8BivssMQWa96vyB5n7LLMNuvss1klK+201Fb7FbTYZquQtdx2 6+234Iarm7bklmvuueimq+6u4rbr7rvIrivvvMNuYi+9stJk776brLSvS//y+y/A/LIkcL//HKyw vQQz3NLADUMc8cQLM1ywwQ5DfHBMCr+0McYIJ+ywyP1WXPLHNX0sMckNR7wyyBebDLJ9Awc8sr8W Z7yyxjqHjLPPF8Pc8tAvk+yz0SzDJPDMSdd8M9MSOx0yz1PnfDTURT/cc9JMd/3zz0dTzbXST0+J 0L4E3Yt22mrfK9DaA60Ntz1ux1033fzaPbfAbG//wvZBfL+d99x91y13237bDbjhbu/NeOKHQ353 33or5DjeiVeu991wO5654JhbPvmiHJf9tdYnVx321jNFHfTSMANtusevF5y1yltnPTTLL0ttdOqn 0666TLc/7frxXeuu+9jMFb868MGfvvzYG6Ms8vVeE7909bPbHP33pQ/fe+4nN939yMqf/7zW2Acv dvitz57b2aMLXnHo+FNuf/35h952/mjzHP/sh7cCBvB+B/Qb4fb3OYN0DnEObNz/IIg5heFvgfqL 4P0I+EDJfQ6DDAxc/1oFQsIlMG8aLIgINcfBwT1uhBVsYOX4lkD6SQ6Gm5MhAS84ug4i7oWLW2EQ /22owhf60ISPoyARKQU/sq3PZldjXvaQZz7VBU14TpSe1ZpovSa6DH1lo5rVwBhF3skPfN8To9h2 Zrwtaq+M8xuiHGcoQRmWcHKe22HkWFhEHe7Rf/w7IkMwSMgeJlGBKMQhD3XIxwzqEYh/3CEdGSnJ V10OiYj0YAMP58j+FdKDmuNc/T6pSEEWsZOVdKQAN9fIUIKwkkp8ZOb+mEhPxjJf4UMYFFsmRtRp 8WpUJNrqfulFXzoPdcBkHRa5GEYy+jKLYHujLt2INYK5L5i7fGOKRIdCTNqyjuAcpSj9eMvIvZKU JvsmOWvZR26SEpYIHCclYwhKynlzlTkMpwhfef8oePnznwDVFL4GStCCGvSgCE2oQhfK0IY69KEQ TWhAJ+qXhQzgohgdCEYvWpCMEsSjHd2oRjc6gI2A1B4eJWlIS3oQknIUpS5NyEkjyqqUvhSmLP3o TQUy05Hm1KY5vchJQdrTnuLUp0fFaVCRStNWDfWnO1VqUI2a1Kc2JKotfelTl6pSnXK1pETFaleb WimYYHQmZ20JSdV60ZikNa06aStN3irXlcDVrhtl6wBkAte74tWvFJUNYPXqkrbW9R+DRaxcEzvX vTbWsXf1q2Ed+1e+1hWwkw0sobK61JV6Namg9SxPRfoQrGZ1tKIdLVhvStWqipWjrSUrkdx62Jf/ RHaylE2sZPNqWZfWVq+7paxi99rXy+bVt2bFrWZpw9jhAre4wiVscqNLW5u4tLCHRW5lCXvWwWp3 ualBSGzDClWWUvW8pjVIetVbVNa617xRzShQUxtb2RbKqqplqms7m1+YfpYh611pZ8mr363ud6rv tW+hegtZ4+Y2uov97XbpSt3qWhezxsWudJ0L3QdrGLyosehYVTpT+fpWtVoda0dea+KvIrirW12t ixXsJRDbGC40zjFpbszjsej4x6DpsZCvBeQiO2bISIYKeQAAACMvlCZMbgmTpxyUKLNkylb+SZal DAAuU3klWO4yTMIM5jCLOcm0SQiWB8JkNjcZ/yFtVvOU3UzniphZIGvG85vt0eY483nPdf6zoJ38 KiifOctbdkmix3zoRvsEy4yOSZQRfeYrO3rRaE6zQvzMaUAXxM9yDjSo3XznT8/ZIKOmc6dRvec+ h5nQulq1nlld6oPIetAUObWpbf3mW4va07iGdaxunepAh3rWyLazrpOtZ0DXmiDPZrawX0VsYBsb zq3ONq+jrWpne3vT1oY2sIs97VNV+9jg/vVFXC3ua+9a2oP2dbkTJRMzl/nLPbH3P8j8aH7vm8xm FjOkLW3pLfs70/7ENMIXnu9KM9xS8474Vh5OcaBI/OJXqbjGb6PwjatJzrp+tbJDnmeLjFrk7f9u NrlFHnCMl/UllP43wSXtcC4TPOb9hjTO713mmdu85x33+Gkawm54uxvbuCY30Zf97j/HWd5Jb7LS XV7jmkza0TS/ydV97uWD37vmM9+6zHuu6Et7XeimYcjTtW1qbqcc6hBhep3XnuxUQ33qVL/RTPC9 c5iD3cs+D7pNBs7zr39Z32UnPNfR7ppE973se3f44w2Pb8hbueOYFvyiBc94z2we65HOOuTJ3m+Z B/3zix/75DuvGWyzvOQSabnT8b6QUsv+16DudO5hn/cf0773wJ/I74NvLNYb//jIXwnxl7+R5Dsf M5x/PrBcr/vhUz/bco+9p1HObO6L+9S3Z/7/l1YNd6PXXepsz/WrZV3yu2vb+uI3UtGD3fTao//o DuF9ys/vbvKHO/4YMnhdtnqkZ2hjd4Bdp3hfV2+VtnOoB3RnJ32dMXCTF3B/R4GgxxOVt4A/d4AP iIAFKIGnIXYg2IEGSIA4oYAFaHARiHipJ4KBsXRRh272N4O05n3dxmr7V3+8poMAaCOiZ3oZOHqh J4QvmBNb13eZN4Sqx4QwCH2EF4EpGIUqiIT+doX8pniUxoIb+IQxWBzw94O0MoF/54VmeIZomIZ6 IYZs2BBq+IZwGIdyGCUKkQ92aIcFcYd4SBB6mA986Id12Id7+Id3OBCCmId9iIh6SIiKaA+L/2iI eCiIieiIg0iJgNiGiiETd/gPergSm7iJnmiHnCiKo1gToDiKpMgSpwiKq0iKrZgPoQiLsegSn9iJ s9gSp6iKqYiKc6hkDVGIhSgQwQiMe1iJCBGMkHiJliiMlViMzQiIyLiM0piMljiI0TiN1JiNmJgY N1GLssiLvFiLNpGLtwiO5FiOtLiLs0iO3siK6niOuXiOvSgW3qiLsliP6hgT8JiK7viNuJiP6LiO 7yiK4giO9vgS8QiQ8/gVnfiKAtmO/viPEWmQr7iL8miQB8mOBLmRsKiRE5mQE7mQDOmK/FiSEImR B5mO3+iRJBmSKBmOA9mRJImS++iPFymSRP/BEMi4k8YIict4jcyojEGpjY0IlENZlMZIjNA4iUR5 lE65jYdBEyCZkggpk1YJE/sokfrIkVv5kVyplRUZkTWplTg5kmJpklh5j1+pkmyZkhbZkv+Ijv3I lmHZlmXpY8fYkz+pl5Q4lEbJk0npjEt5iY8ImE9pmNj4iE2ZmHwJlW/RlYIYiwr5lhcpiV7ZjzXJ kvkoiVSJimd5mWR5l0fhmKRZmqQpmqiZmqq5mqyJmqb5mrAZm7I5m7RZm7aJUK2Zm7q5m7zZmx53 m+Lnm+0CnMRZnAomnOJinMGHnOGinM75nNAZnbXCnNRZndZ5ndiZndq5ncgnnRgXFPwwF+H/qRTj yZ2AUZ49gZ5DoZ5GwZ4v4Z7mGRQYwQ8XQZ8dYZ8ggZ8JoZ/e+Rj88J8C8Z8AGqACShAFOqD2UKAE Sp8KuqD4qaACap8PmqALGqAUOhARaqESiqAZOqEJCqAQiqD9iRY1EZ7laaIsgZ7juaL/cKIt2hLs 6aIymqIvuhIoCqMtqp4yyqI2WqMvOqM02qPxKRT7eaAYeqFIeqESiqQM6qEGeqQTGqVQ6qBJaqEa eqRXmqUUqp8Pyp8jyhUxAaQ/GqRCyqIuaqM3iqM9KqZpiqJiSqZtSqNs6qN0mqND+hMIIaVayqVW yqBYqqV/6qd7yqRbOqUFoaeEiqiCaqVP//qliNGhWJqhkdqnA9qgIiqpH7qhHGqkmbqoGAqhBrqp lRqiG5qpjpoWdAGfZAoUqnqncZGnERqrsjqrtFqrtnqruJqrurqruXqqE+eqt+KrUBmGakesbpF9 JWGsWIGsNLZ+4TZ/ILdy6Xds0Lqs/yeDypZugqasxYqs5fdkQWh1ZUiEDHiEPxd9UYGuSXF6Ajeu VeauHgivv4J075ZnRcd7dgd+c6Z/b3d/s0dqrrZ2+aqvAttrBIt9BnuvB4uw5odsClt96FewPvh9 CRux13pQ4RqCSTiAZYiBEGiuXaexHAuBNed47fpvJ2uEZEeCCCh2Lit5Ixt5lwezTYiyfv/ndzP7 sSHYLg8IcCPbhZZ3sigYsk1IZTnLhSarszW7hUa7hTcntCnrs4aWsyj7si1bhTpLguoarD24a3Q3 f8yqsDZof19rsPHmr2dbr2hbtkdHcvfHtttqtnhnr/4qtuz3f3Y7rc26fXX7tt+GdHAbbNKag3E7 a3ertjYItmZrbOwGt3lrfv5nuHLLdkr3uN13sQzlrCrnt//adtV3uYs7sQVbsWg7e3yrrxQLuhWr cg6Lume7r6HbdKO7uYKLr+3nus3WsLXJrRObf5h7rL/ru1TBu+TyF1vLgMdbgnuRvIzGvEDhvMAa vTkprJhIvNpKvcKiuT0If3S3vcHru8z/qn01WLgj0b3Jyq+wVq5aJ683q7zuq2XsexRU6xTzyxTQ 6y702q+OG77dS7fkG7Do27YLC7CsK7H9+roIa7GsS7YMa7oEnLY0uMC3F8ARla9ey7lLZ8GNO7nk m79z17dpi7qVi7uSK7njhrnFJrb6i8Kuu8H0Z730YsEOvMG/e7uw+7+cO3UAbLogfGeRS32te8Md 7MDjS7v9e7tx18MYjINNpcEcrHsM3LqFy7bVKrulG8J8S7jbxsE4nLgX679dbL7cq8RTHLsNpb5P +7EsuLOkd7Q/C7Uqu4RZG7NWG3PsmsZxHLM1W4JuPMd7TIWRt7Rv/MfxCyrgJsSau8OQ/+ttNzy7 Lkx/ALu6EAzGCNy1CEy6tUvCUjzDi6u95hvJD/zIr3fGT3G/pVcZ6GrKGljIp8xwqrzKlIG17Zuu rNxw1oK9uJzL5ALDwve9uqx3yCuu5KoUr4zKtayaQDvMUFHMsXzMqPmyWeixVWt4zduufKeAAVdw 1rzNOEuFM/vNJYt4GAjOIMubdTzIRtjH73vOIpvOUBu1NLuxJLuy8YzOVwfPbCyc7LzPUsvHOgfH ICjP6ly1SSvPKkvQ9ZzH8SrNu3l9Lvy4J2fG+wvBOWi5kFzRZNywD83FkMzLxBmEAk3H9izSo8fO AT3IA12/7izIYZfQJr3H2WnHKC3NNP8dzk1Lzxto0Aw9zUFbtCnLgTYHzT/N0+8rvUZ91NH7y0q9 1Ezd1E791FAd1VI91cCH1KFC1RBl1YaM1Q6l1V791WAdL1xNymFd1mZ91mj91WO91mydiWkNKW2t UG8913Rd19AR1xJl13rNnXjd1379qLF6qCL6qYEt2JhaoYTtpaHKnw3aqbKa2IftoI+N2H8NETRh qyn6nzAxqzBaq5l9ogJ62Zrd2Srq2WjK2aSN2jnaqlq9EJhqqYO92Abx2qJKpa492I3d2LMtqlwa 27Jd2Rqh2x9K2EXK2LFd26bKELqd275N3M5N2Qch3MBNEdL929GN281N3NW928bd24r//dzJDd3c Pd3zmd3gbdjWXdyRXdzofd7tDd3bHd7kvRAyEdqirar2fdolGqs4caupzd+fTdr/HaECntbsfdvf Ld/xLdkQcauLPdmUvdy0mt7znRD1Pdozkd/vieGrvd8EfhMa3uEBfuGyuuGtGuJ2jeImTuIFnuEl bhMhruEq/tkf7hIzrt97jeMujt8cfuMB7uMtruMiHqaaXeMjTuSsbdXqjeAHbtsHvuDizdwJntyR Hd9QXuEKIdzIfd3dvdvOvd7jnd5WvuXijeUZguQYnt83HuM1ruZpzuFIbuM9DudyXtp2nuM6gdmn XeKqvdqqLeN0XueCTuMvPuR+TugA/27oeO7ncO7Zfb7njT7ngX7kQq7niv7hlg7ki77pnI6avPrp oB7qoj7qo37WZq4unX4ip54uqW4gq44urV4grz7rtF4QsY4ftV68t77rvN7rvv7rwB7swj7sxM4S uX7syJ7sxVLszC6Cyv7swN3s0j7t1K580M4s1Z7taHft2K7t3v7t4B7ul8HtyyLu5o5k5J7uY33u 7M5j6k4s7Q4b7z7vUR3vr0HvwWLv+k5R+N7vS73vAB/wAj/wBF/wAOXvCJ/wCu/WBs8ZC//wX9rw Ej/xognxsELxGJ/xGr/xHC8dFu8qHR/yIj/yZf3xIE/yKJ/yD2fyLN/yLv/yz6LyMgf/cTA/KQEB ADs= ------=_NextPart_000_000B_01C71DDC.2C3E00A0-- From bows@aregatta.com Tue Dec 12 06:41:30 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gu60o-0003CP-Kg for ips-archive@lists.ietf.org; Tue, 12 Dec 2006 06:41:30 -0500 Received: from 88-137-16-117.adslgp.cegetel.net ([88.137.16.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gu60i-0003nM-P2 for ips-archive@lists.ietf.org; Tue, 12 Dec 2006 06:41:30 -0500 Received: from [165.167.150.134] (port=7965 helo=dcxkgmarb) by aregatta.com with psmtp id SCEwiI-C1b98D-00 for ; Tue, 12 Dec 2006 12:41:42 +0100 Message-ID: <001001c71de2$7076d980$00000000@jessd5eid31e43> From: "girls" To: ips-archive@lists.ietf.org Subject: political game CNNs Date: Tue, 12 Dec 2006 12:41:19 +0100 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000C_01C71DEA.D23B4180" 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-Antivirus: avast! (VPS 0657-0, 12/12/2006), Outbound message X-Antivirus-Status: Clean X-Spam-Score: 3.8 (+++) X-Scan-Signature: 2b428fb4265163ba7f2ac2af0ebfcf00 ------=_NextPart_000_000C_01C71DEA.D23B4180 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000D_01C71DEA.D23B4180" ------=_NextPart_001_000D_01C71DEA.D23B4180 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Morning qb, surprise contenders truth rumors iverson. Toll free fax tn center linbar! Baghdad calls saying he. Rules building = lebanons words. Ranking past heisman winners red before. Woman dies families reject, = sago mine. Chides power chile braces pinochet funeral disrupts. Warning = restores treesannan final. Incoming clear hezbollah qaeda, brian, todd, watched hoursmore. Cases now seattle airport brings. Funeral disrupts search missing climbers taco. Sign updated am est = december make cnn page. Customer, service southern hwy. Weather amp video, member sign updated = am est. About these call paperwork, department contact home. Delayed times etintraday comstock. Training hvac plumbing online careers customer service southern hwy. Trips chairman nicole richie. Bill tucker explains culture killing. ------=_NextPart_001_000D_01C71DEA.D23B4180 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
3D"postage"
Morning qb, surprise contenders truth = rumors iverson.
Toll free fax tn center linbar! Baghdad = calls=20 saying he. Rules building lebanons words.
Ranking past heisman winners red = before. Woman dies=20 families reject, sago mine. Chides power chile braces pinochet funeral = disrupts.=20 Warning restores treesannan final.
Incoming clear hezbollah qaeda, brian, = todd,=20 watched hoursmore.
Cases now seattle airport = brings.
Funeral disrupts search missing = climbers taco. Sign=20 updated am est december make cnn page.
Customer, service southern hwy. Weather = amp video,=20 member sign updated am est. About these call paperwork, department = contact home.
Delayed times etintraday = comstock.
Training hvac plumbing online careers = customer=20 service southern hwy.
Trips chairman nicole richie. Bill = tucker explains=20 culture killing.
------=_NextPart_001_000D_01C71DEA.D23B4180-- ------=_NextPart_000_000C_01C71DEA.D23B4180 Content-Type: image/gif; name="Radio.gif" Content-Transfer-Encoding: base64 Content-ID: <000b01c71de2$7076d980$00000000@jessd5eid31e43> R0lGODlhLALQAYewAA4AAIgFAAB/AImACgYAdYwAegB9h8nIt7XYuJzS6jEgBWgmDYUfAKgRC74t AdUZAQVABhg4CEY4DlFEBodKDKMzBLczCuVFBQBXCCFnA01kAlhWAINYDqJkAL5XAd5rDAp2ABl1 ADOJBGmAAIJzAJh+ArOCAOiFDgCeACqpADiZBWWuA3WZDaCfAMCmAtauAQbBACSyCDXLAGfMAIGz AKe5AbmyAOzNCgXXARbiC0ztClrjAH/eC5/gB8PSC9/SBAAAQiINMUkBPWgAMYUAQZMANLIAQekA QwwjSBsaRz8dRFUrNYwZQJQaMrYmNt4ZSQM5OxtKSEJJS1VDPYI8OqZLMsFDTdgzRgNpSB1mSjZT OFdrS4hRAJxWRLtmRNlWPgmAPSiCOkZ1Tl98QXWMS5aHO7yBPtN3OQ2USxqoQTqlOVykPXOjSJKk MbaTRNelQAO5TijIOku1TVG3QoDHQqXOPsi5PdfFRQDuOR7iRELnPmPXNHzrP53ePrTdQ+XgTgkD ihIAjTQOel4Ff4UAdaUHcs4Lh+oAdAASeRUWfzkXgWwVfIYgiaQadbkgidoiewA8gSEycTwxe1Q5 goBFhZoyfL1JgdtFcwVdihpYcUlSd15jendSjqNpfcNsdtNWfAB3ii1xi0d7dVFycn6Ie5eDeLmB jt90dQubhCyTiUmlh2OreHGWd5iSfr6fc9iafgzHjh7Lg0i9fGzChXm7eqfFjMC1dNq9eADlgCTY d0DkiFLjdXTidJPjhMPpd9/UeAwAsRMHs0cBsVwBtnUNvKoLu70Jxt0AvQAmyB0guzUVu2YSvXMT zJIZxMoTuu0RuwtMsiA/yzQ9uGhOzXM8s6BLucg9zulCuwBYvitjtDRiv1FfuY5kx6hstrJbs9xX xACGwxt2w0SIt2F9v3GEspZ8tLd0wNVzzAmnxRSRvz+UtWeev3OitpqWvMSYzNOpswDFsS61xkvM y2y/soKzvaPJtv///aSZqHd6jfILAAD5APnyBgcA9f8A/w3+///48iH5BACBx3kALAAAAAAsAtAB Bwj/AGsIHEiwoMGDNXz5ErhQocODChMuREixosWLGDNq3Mixo8ePGhGAHEmypMmL8wTOW1kjZcuX K126PEmzps2bOCs2nBiRIUGeCQf2zEm0qNGjIBGIFFlDKdKnUCnKVEmQpUqrL6Nq3cpV48SgEoXu FOqzq9mzaC0qXbq0adq3JlPGvFpwrtyWWOHq3VuzocSHQf0GZjiUr+HDSZ06bdrWLeLHBqcOvJvV Ll7ImDMbdPi1YOeIX8dqHj2a7VqDjUnztWq3dWXWqmMf9guY8GbbsnMjNt12sWPdaCnHlDv3KuXJ wJNv3fmQc2CghZVL38qUMVvrqad3ZXm8+FSZxLWL/yfa0zlu0LXHq89ZXSBT39jXPxV+eTJ3vNwt y9//sTlZspzxFB1/BH7UG2MFKVagUeEZV5V9Dc604IQ6mRcWaH89R+GGGK31HmrXcUhTfnfdV1F4 eYnIYXm03YaeijAi5KFbIVoXY0kkCufadw5e9EsNP944XXTNpSfkkachWKN7R5JUYoTINfhgRb9U aWWVAgXZpGrOiRbWl1s2maSCv4UJ0nBo4vfkaxIWhCVBP76ppZmYhTYUhmDRKeKMpjnWnp4a5UWf mlNepNQvi8mJpZWAQkYkUI2qWB2f7f0ZKUJr5ijoa8ihhp1IiGYJZJBviufNqah6s5+Xl0pqo3uV tv/aEZooPlgriAj8mCuQp80J5HiqqlpDsKfKaqxui/FW5rEHFZcVhHVh1SasubKlq1OLMuqrbMIO OxCxxXb7lB3k2lEDucymq9ZAsaqbUX4wXTaTdwmWmmu2vTKqXqoEiYuUuQKZK3DA7hacYLKWGhzl s/pJ5iy7vO7KpGKHjhrntrGFK5DGqHrrb1EDA3zuyCIrbPLJdcEkqLPzUkXQoTBXS2OoWcY5EMaa havxsMV6u/FRAxM88tAlo2y0wi2DF29304KKIKL37jqjqDZzW1GwPgvbM1EABz1Q10eHbfKanUpG kYdoTy21vjfjnPO3BRG78cc3hUw02F8L9MHee9f/wPcHBPHtd98DCf734YDrfbjiiAvOuOOPQx74 4hZJPnjikzcOeOMFae645WLL5nBVw8l7EMwRr3VtxbuS+iu3W+ucKtZbc513wCIXzXjkhfctueGE H/R58Lt3TjjkwxOffOXEX24Q6MX/LXzzzoeu3LQlpuwpttViKTOiVTIlp9Uex/3t7D4DXe7Q5xYN cPLBL1899NUrbjzmxUcf//74U5+58tSjH/L8Bzr6WS822cOPfSpynXvVbFQzcxPsfvazbtHOgrXD ifvw1j6Bwe94IEyc/J7nv8yZ8H71GyD+LkK5/PVuhS+MIQlhaMADkoY++jkbxV7Hmw9BEDg965jW //h1vvKBjGBdC5rAzLW8EOpPhCWsYf2muDsVyjAjvutfAKPIv+nRsIQ2FF32pnW68B0KahaTWFOq phsM8oyC5QPXEZdYsvVxsIlZxBwIX8i5y3FRi1/cnBP/B8MZpnCLmpvfHw0ZxhstBXxMYgz40Eg1 5YArdpgsYk7Kha72fQ1dnVQkFA8pPRd6EZEnNGEfZwhG51kRhac0YAFb2cgC8YaSMNNX1dz2mNnx S27oEyLX6Ig7koUSXfJDHB+7iBHL/Q6VwCtkKln5ymmqEoyzlGYt1ZIsZLknSD1M1A9zc8n0zS2I PNtZ3TrYySQq8VwjbKEfrUkRZwIwkKKsiACZmf9NhIwQlvTcpqde1piEjWaSoAKVrnDGS8j4i4hZ 69e/kni7iuaTd3wM6OCsaU9APlGPHvWiDPsp0nkyUqAcORC71Cab09zrTfC5WEN7KS4MqtOXtism Oz15zH+W8nEa/acpL0pKKBq1niscZFD5h0+AopSgO1QWjUqSAK5cCV9sYyP55PbGX8LRKHb8pFhx t7hnNu+snotcIaGnzCuatK0ljWEiPSdIQCYVlZmJh17H083s/GZJGKlqDQQrWK1IrWIXs9hMHYo+ I8ZRnRPlaUFyF8qnjmevesVsPGqw2eS8h2LwoVZoL5KA0hZ2sFU97VHYqKXFqiaD6URnYzcZsmP/ 6o4glbWseDorkL1yVjpRPV2SEFSR1KJWIMZF7kBUaxRSXelXriUNVzUJWZCBTXd20618fDuQznKX t7FJDdpoJF4yGeS0pUWtadN7FptFN2NufKN8YavB24GymKDMrXZ1493Nara3BPFvbgC7UmqRd1nL Ve5xk7tg5oatdpekr+3quFOS4e62+yUNbwXs3YP4F7yY8etUCyra3rQnucZN8WBXvF4bPnRu5ows T722PmNmODeY7e2HM9thDgM4MyHyDYGV5CeCpJe9yCXsehkcRqylE8ZRyZ1FiWnRG2vmw93lbGZ/ +2MttzS0JE6bgkarYBWreMUKbrIwt9JOCtc4/7tW5m+PdcxdLmMZyJUCM6z2PNwTF8TMaD5uoOMM NAu3k52VxXBRAsBoQm/EtzkG8I4DrGMva2bMfNrzVCOZGvYu+cgtdvRZ8nvd9TH61Khu9KJVfZNU n5oory5Iqj0Sa4O4OgACqXWuWV2DWyPk1J199WZjPetYe1fXFnG1rGc9EFQT5NW3RjUCih1rkUC7 0W25drTRnNpo11rZFwE3snetbVw/u9zOPre56XRdTyLRnSMbN6x5XZNvy7skyC43R+Rtb1znm9X9 Poixga1XYfe60fEwdrDpTRFiA1zV/X74uskdyYMHwNrSboq2bXTqaTM6tUtWL5ItnmaHT1zgEP9v 9L1NfnJnB7zZDN+SlDkJZ6HdGyc3J8m/T67zdP865g33OcXPTXJ1Dx3mPw/AsBldcFU33dwGz2zO YT7xlFfd6hJftrkV82qPdxzjF6+2xhnt9QUnOOkgL/rRbc1rlQOd5eumdtzbDvQm1ZHmQuPk2l9u cboL3dfkNvnag87ziLdc6CjnudE1wuzBL57qascIsFOdcIQP3di/nXrkHw95cdMb2V4Hu+A7DquO n9q0ZWZyVV8t2HHz++2wh7rP5Q752rPbjnQkZo33nnWSC77ov+89uMPN8NELX/G2T/xG3M55rTtf 8+qufOVJ7l/BdxjYyY492/3N/M1XmymkN73/7Lm/9bGTH/WeRjJhT9/64sd85drvu9tdbnXn6+nQ OnX37iMf8P67f+6KB3fIt30E6H8DSIBJd4DP13uJt23Q13lKx3TC9nRLp3TghX0VAX+FN3++93m8 phRdp22h930dGG3qJ2inh1qu937xh4DXdnAl2HiOZ3czRmOTxXkGCIGzx4CAN3zZt4Hkp4OMV3cP SHF8R3tGZ3iEJ4GotmUWV4G/tVeap4EFmHLex2pLEYJk53EjSHZMIn4BAGrLlXZHFmur93/Kl4Yu OH8cyHebx26fpGj2d3Tolm6+9nK/13dDCITyR38K2HzJJ3nDt3NXGISA2Ftyx3RGV3kWyFtT/9iC QtiHc+ge4YdtrhZ61rFxypVinrZirHeGfIiAomh/wceBtleEG7J/COE1yZeDGaiJJXiKRbiCMziL LPiHc5iHRuiBhhiI3UV5jVeBUBiFbziKgAiLMrh5ZVd2gReEi6FtLSaGRsZ7oTiJhwh89ReLsoiL KtJmhyaHuuaKr9iLyChx3FiItVh3xliMP7iNSciL1LiEUmdw5AaF/QV94Th+i6eEx5iNXkd231d2 n2hkI6dcrNeKREh37KiLkTiDgEJqHcQ+SbePeWiKxmeRbhh4ovh3D3d5B0iIDYhyy/Z4sEiHDFgQ FCiMmoV9CsdZGDiO+uiRAKhuhzdxIOiP//8IdlmYjek3jSyWghT5kRc5kcVYjld3jqkoZWM1jlrX eIMogz0IeG/4ej5Idfl4c1LpbelYkzTJkFeJeCj5ctXXhA4olQ3Ii1dJk9aIhOYHgDu4bQfRfgGY jAmIdXboh8oHl74YJsekHSuIlHqBimkxaZImYFHIYTvmhCHWV39VYJtmEeglcmcmagrzl7khmGjh hBsWYCB2mD7WmY+RMGPSQAYVl4QlcoImK/BQEKtJmY6HmW8Bm2dBmIppEDzWXYapGib2WUtSmnHp k6jXKvDQmjWwmsY5EMTpmnEGaZyJkjm2Ybmpm45JmpqmEWToYHTSmsZ5nNopEMOpnI5GmMT/mGVZ FmmgCWTEFR8TI1DfWZzD2Z7vuZ3FOZ/gmWE9Vmdddphctp9fdmBkdmPy2Z71SWj9ZWeVpmWaaWnK 8Vm61Z3fCZ/e6Z4COqBW9l/9NWfleZ4UehjHiZwS+qDeKZ8huqG6VZu5WaAdRqKZoZ3vGaICSpww 2qF7cQ40qqL78V8/Bl61aaOIEZ8e6qLdOZ8g6p4zSqPnwKPrcaGUVqBIChlDShDbGaAO2qIT2hVH KhBXeqVNelnMWWkaGhtso10gGqP02aHwCaNEehZHuqY1qqVbSiD4KRuKclWl0qDxOaZmGqFCKqFw saY1UKNvqqKLAl3Z8l7q4aduWhRPehDJ/8mdMfqgVboVbJqogVqfrvNcbVOnBZKlBAGoRkGlZZqm UQqpkKqn9BkVnoqlf0qplSpqz3VVcKKpBIKoA4GorEoTY0qkL4qmp6qri/oUbYqlnNqqFPojpnWp paJV8qGlbPqnqvqpZ4qcpNqr3MmoklqrwuqsxEqZpUKGujSo/NGstDqpz6qoe5qroeqjopqmqCqs Rlqu2+poxqUlpYWpuySr2hGs2lqrgHqrI9GojvqjQiqjvWqlq9qp+hqvcWasv5AAjBJq4yNB45Gl RtqvB3uxNlGtZRqk6RqlG8uxR2Gx7qqw3DoqDltVDatgzjVOE/uuqVqx2vquNYGnAlutLP/qox5L sMB6sM1KsguLWsZarymLspcqKhOLsarar8yKE3dKpU86oSCrqwWLFCK7rz5rZSCXXlVyZLrUNq+T r0lrtS67tEzbtFAKpAG7sWfbrqvqp1drZUHbsPWKmjdTtxBkqJhBsTBrtQibsTLaqGrLogP7o8kZ sggbrP76ttuUteoFrlkFJ9NhqzG7r5KbqiUxpDd7rkDKmlBauMA6qWOruNoVJEIrtydLNZrqOncg EHfQuq2rGm66tBTbthWbuB4BsIS7p4wqogLLFW7Lt6IrUItCWKaLnQVxB0Hiuqv7uqtLGm7LqW06 tr97Emjqsed6purqomr6vMAbvLVkJQ7/27ByazGEahDIy7o14Lrpm77NaxJ/IBDvexL+IBDzS7n8 Grti67c066tNi7uZaxah672W1Vrg+7WE6l7pWyXLu7zsu76vSxLxG8EjUb8D4Q9Ky7MXS7a2+xGl OqUfaq3pqhcJK8AopS3QNU6txb6r+yMMrL4L/MAd8QcyHL/wWwM0rBHzS8EVjL8FIa5H8agtqrac i66ey7YjS8JP5V5KnKkyZTHKi76sC8Pt+xHve8Md4Q9YrMP1C7rDSqkyexMePKI2i7mnWsSoOrtI nMSpi7oI/Lq/8MBw3LwM3MAbUcUDIcM2bMcZUb98TL81sMXRy6+066wbDBKC+7/VKxDW/1AD1tDI QfwWkpvGwmu3u+QmCowlLkzHzIu+U3wRekzDVWzFF4HFf5zFWfyn8xvI4zrCZRuqFDGqixyisSzC X7weB3DLAnHLB0Aat3ALNeDLvmyjWeUryfvGNtO+zIvMcgzDdWzD8IvHOJzDFNzHWHwOqVy5hNy9 TGuqHSuhsWwNQdzIAoXLulwDu4zLuYwZvbzOAtHLRYG3TWIO5mC0YRqxxoy8TxzFT7zJ6+sRoAzK e0zKf0y/01zNbUu7FwwVOBuhkLrIi/ye4Dyf4qxb51zO5ozOj+HO7bxa5WsRtgAj8jzPAiHPkGvC a6zADtzAyivHKszMFqHHz4zHoowQAv+dw35c09iKsbW7FQtNEOA8nA/904o81BMdOrtszhddzuSs y0fNF8EMzMA8EMFsE3XqOgjx0baQ1Vit1fIh0jUwzyT91SItz4P6qgqMvG+8z3M8xwPB1nX8zzM9 ygNN0KV8yp2arUir0OvKsQ6tneL810V9QE1NEEudzoMNF1P9y1Gd2CahLWV9EFktEJEt2QTx0eLh 1V89EGAt1pm9sjXDKFIcxW2t0spMxaEc1xZBytIszQStwxj8FqP6oY3c14rs0N88y2KD0RaNzkx9 2G/Bzu4c1VKt0SeRWE0cJJM92ZVdA1pt2dKB2ZlN0tCt2eSbqQvc0nGs1vwcw3kM0xv/Qc2u7dqP EcTwMNtA3aKzPRC4LdhJzdRIncvnnNTv/dvDPdXBTRNzkqwQ1NyRvdXMzdxbrdy6sdmZPdIjHdIE TtLZAsUujMwV4db+7Myondp0XeHijRmxXdSzPcsczsjJwQ/8cBAgPuIFMeIgPhAnLhApLuIhjuIm TuLxfdQvjtQgTs4n/uItbhA47uIzruIm7uMzTuK/DOK3gOMrzuMuXgNGruQt/gsp7uQhDuU//t9Y DeBHbuQ5zuNBnuU3vuNMPuVeThBXHuIh3eUHvtljneYIsdJS3MLX/eZnodo3bcq6gdt/PdSMfOd4 rhtH7uNJ7ueAnuJ9XuJZftE1jtQV/23OKX4Agp7jjB7iKz7oTP7nkh7pkN7i7DziwEzkvzzpCCHk k97nUP4rIG4lZm7ZJ17lkm0LKa7qkk7oYs7ll67jsu7ptg7oLi7PID7Puz7W0W3g0T3dLt3mor3W DuzSWqHFfZwbt+3heV4QG67ewNHn1D7rsR7qhU7oK47LNZ7oMs4P8c3kjw7fZo7r1x7o2V7phV7k Qp7ivvzqX97i5V4zJy7l8s4PUN7fXJ3c8U7lzA3vf27u8x7w547rU+7juk7mJy7dYA3d022+Kd3J oZ3daAHeFx4b663nzm7bDj3thV7tt47tAN/viD7u713RJx7fNb7o427pLE7p6Z7tnv++zuzO6e4e 8rHe6CEP5VXy4zwP4s6t6qvO6iMu9CN/62OO8+pe8AcP5PxA0n0+3QhOEtsNxSr8FjYtHbfd8QaR 3t/s8bB+7SAP6p9+7/Pd7YTt47zd5ejc5U2f86C+5Or+4uzO5HUfzPBu5m4P5vhu4jzv9Knu3P/O Dx8N9JZN9BeR9Em+5PGu8zCP6wnv1b0u3cBe4JXf1tdNEA6u+f2svv18NF8f+rZd28++3rEB8mL/ 8ZcO8Dpv4+CO6IiO9mp/6Les9zLv54pf8LrfyzYv5O9++57+43OP7/HOKJNt+ANR+Pee3Eef+9ie +NaO7ubO5NK96wUe1pxt4A9/vFP/nMn73PmdbDRcv+F3Xv6jz+eqD+tjH/20/uOuL99Mfei5zPa6 XO6v7vhKL/Mr7s4nXvP8ABC3atz6xY/fr181FC6sYVChQYcOGT6ESNEhQls1MtoyaMujRo8QK4Js yG/iyZIMJVJMiVKlyZUtRUo0x9LczZo3a+jcyfNkTZd3Ft4RWoNoUaNEFR512dTpU6hRpU6lWtWl NawKs1pbyNXqV7BWY7Ik21KmSbMv1R6geMAtW7c12K40CFeiwwMS/4wtexftRLow/yq8ZVBgYcMK C5pMmFCtxbSKRdZYbBBhx48rPXLk95GzwpCDXY71W3ZhzIh/S582mXOlOYNAF+Lc/9mToWyGSnMX Faqbd++lYYUPJ178KVfkWrPW2Mrc63Lj0afOVD355UizfFHzi1vyLduFdieDzwvxwJ+Uf9QbRP+Y JfXqI+EjFliS3y2CiBUjdJw99UzJGEvIMo3sg2izjUrybDuotMMOPovkA9C07YCCDa2cfMqQJ5+G MmoipX5biindpDPxRBSvmggr6E56LkUYYwyrO/Lk+g688BSi0Ua20PNRIfVkZKg+whDCj6DGFIvK G4a8YXIhhChz7JeMSKoSNNCuxHIhLYUszsLZastQIQ5vy+mp3pACLjgSvXTzTaqSc04r5pxbzis4 83wTLrn6ZKg7HQPFkbz21DO0hv8g3TxSysOU3K8/l5h0soZJKX1SSv4K/AjLLq3MktNO9ZxKNpx0 IlXM2Uw9s6mjWvVwzaQ+FHXWPJF70VY8W6R1V+Pe4nFQuGrsE0dBdTz0RyDb8/LI/DCNMskoJ3Jy UkkpVajak6oMlSSGNi2Qy215RalDMMkMs0xTawvKw+BAlBUpceNF8bkXu2JRXnxnHJTHiW70M1i4 1DvvpEP1nDJJKDOVsklqn3T42kqzTRAlzxK0eGJe6aFHoY2bou1UUsecyELcUOJN1hHbzHdlE++c 8+U6WZbZqWBd8nfHHOMKGFEfj01USIUpe7S/ZxN6+NJprV0o6Yk82/JKbzfrNmP/jWvYuGONO/4J ZFTTVbVMqNSEdWayo2PxXjvLVtvmP/38V0eAbQQSPGST/RlOhB8VGlNHGV7a0mqZbhpBqTfa1GnC xa2aY6s51jpMdW1LV0x0zY2KROBCXHtzq84+O2bOQx/2Txr55NNtRHtMFtGFElXWy2iJDrq/owWP uMmmBwdJW00x3lLPx6vGuvHHV7W865HNtAredkV3Hio86XxeKkmqP6l67BWyfqHtr5dkIPy0/15H 7LuvwXy5rC/f+vPeOnR969GDH6X1GTJ/e/jVX59ooRPaPunqTcsb66PW/b63EfxJAkGc2h3vZnU1 q0Hwaou7TU829LEzqco205OO/zM8yEEQCid79hvf+b7XPfRNxIDcqx5csneAFv6qhS1kC/v6FKQ/ bE898UNhCU1YwhH2kIUT8R8Qv1c0KWEvaQP8HhOb+EPxPal8LMyI9S72LQY+cHiNO8nj1FWqc1nu gsYLoXCcoZAPllGNUNHfEL0nPjaOb4V8SiDqZiiJt1TPR6pDlA5NCEdABhKQdXTjo4QYrf2UD4By bKIUjSg+K1rRFt3jneF2NcGscTGCEfSiuVaFG+OFrGRrjMoZ0XhGU5qSlKsk4R8FOcQUTkQg1cOP EOHmljaaTn/g0aNbCmZCHOoxh498JRzb2Eooic8x22tMfwJoPSa18WiELF8VD/84SQVy6VtXBB7j GAdBTYIzVZRLFYdOxUqqeFCdNUglOt35xxWqcIRNWdQUw7e90x2zO8f84x/oxrP8AcmWrpTnD30I yfpZDyHVU5gzJcFEax2zUkx0UgIjmU1sVkxbFbukJr05QYZ08otfLNWYRvlOlHxwnexEqTv5iVAW xnJIRKJlPUvoqzvWDIZ4pGH8eAYk8f2Ih4xEZkGnWFAiMvQXDO1fQSFK0f9VKoAQrWP1PmLVBSLO W28SnuM4uZBMTsSLISMpBk/a0omgUqXsTKMq0Tq9gSLzpScJn/jCN0sf8pKneJQbPI86sIINU1mC rV9RWznXWO4vb9GCJlVPOD7/bEHToAiVmvkKx60HglWsW9QaBX+yQdq8VSrqRCVbWWpa0cJ1fvR7 bDFlWUtJ1JWgcMvp6HbpykIpS4/JOmY8jUrUQrZyqSWUnQkvNcWpWquiD12uRX2YQkvSanGZ7GzW OOtZM4kMbKltCmkX4la3cjd0cT0sMZ1yixSiL4bsC1YudwrUn/nUmOadrSsHmlgjPkueUg3iQSU7 WQA7zUrhypN1QTo8624Su8n7mnihkkbTrjW8Di6bels7yOcedKbojS2RoAjJuOBzpzXEo15bR8L3 ATeQ8+yvXDVswikxE6kxjeb/sufIDGd4o1uV7ke7+NUEUxhGKxXy8yyMUPrW/1eWMi2sn+CnV2L5 UaCrra8B51nlx85Pxkom6LSmWmMlLq3GhuWycBKQgBqgGc1gmS51iSdSjxZ5OKpU6yknLGc8D0en UunZ9CYKuCUGzlLXmtWaDX1mq0gwrF/15jfzPOfSRvjOj6Z0paciaIhFTICFTvNJzozoqhiYuop+ c5wtnU6WlnbSp2Z1qwdNLaVhWsxw+jSiDa0QNYNaKnBOMEi9qidf+EIhwmblWl197GPbjtC4k9Sl vPRpXKu50522NVUkqFmvTldUwiZ2sIeNbHCHW43YUu6gcae0N+la19TGNZuFp+iumlpG3v52sIkt bnzn28/mRtrtaJ1raU8E1P9r3nVIHfdu4s2q2/am9731/XCI5+togCZ3uqNN8HZ7GuNRWXTC5e0m b3N72N2uAb0jfnKU0+p2SxQVxg+d6zTbOuDW9ribgc2QkI985CZPec99/pV5zEMhQRd6U5otrmqv O+bThnmiuYg1OHsp5wxfOMN/Lqp41CAeWc/6ya9Rg2t8/a1CD3oNyD700MFc6dWeNpufTiuH7zzn 3746nLi+9a1rPeVhD/s7yV70spt9IkVnGcBfvnSXt72M9676SexddyHlvet6V0je8/11zItd7Og8 e+DRPnSiy+zwC7k1tWeuxpCTXOSph3zkGXJ3yuM78wrZPCsJv5DbC/72uY//F8BJ3+5aE1zp0xN5 yY1Pd+PHvfUo6rrlJ8/1y2ue77VXY+iJTvjrM4T3+No46Qce8+GDcOqPHz/Pl2+iyVce7wtJP7j7 fhLqh/D6gQe89ct+9pkJH9pL5z8pG2715Cu54js/5mO/ymM/yxO36aO9VQI80MM9wdM9CPQ8efED C7TAWru4jFulATQ/ACRAGJE8vWs+rUtAZJs9zLO9z4tAs/s77MO+CvSDGpDBM5NBxEO88BM/8htA EHyT9Xs+EpQ9sAM7zSMlCpTA+kO73Nu+N7HAGVSIC/SDW0s6dvM/bls9k2O8HmQ+6CvBA4y9h0tB +cu+B9S+wYvAI9wVJ7zA/xm0QfATOHeKu9VbCOXbQuK4uyBMv/YLN74zQut7wPvTPQrMPiYUEhtk Qxm8wARww7brPv/DOQGcQztEvwNcPwTcw0nMF/oTRNxzwBY0w0/UkyhswyecwTXDQKYTsoXLROmw xBHEOxNkxZXpvNBrwVp0wVpUwllJxFJ0QyksxRyMQ6szP1mMDslzvmIkGxgMxVB0wPr7O1FhxCj0 RSfEsyusw2QcjgSERTDMxni5xRfURfq7v0CMxlGEQnR8wmr0xtaDPndkR5bpPGb0PGj8xHDME2ms RjZUR3g8PxLExH7klT80Q3psRnssxBTRx15swzVkxIB8SIiEkfmbv05kQf9bREOLbEIoXMeFdMiI /EiQDIt6HDxnvMjdS0M4SUReVMdzDEmXfEmrCMR7dEYXLENRTMeFOESOhEme7EmUsD9PzMXPA0qE hBGHXEOG8EifXMql3EQWhMbtK0ovWclSTEq00hmdYUqtDB1C9ERBxD9OZEZzPMScrEpWMh2szMqt XEtlBL1yHMpm9EpemUakRClhwcq2YUu9nJlcxEVdrMgYNEt0AhS0jBu42UvElBdyDMu4vMiHJBbD JJbEnMw8mUix7MTFTMbTCZTwkMx/8UzKDE2JfEq4BMWMtMO42czvkBvVFE3XlBGwtEkljM1JJI/W LJYceU3dfIpDOATi6E3/ZgROXJTK5UtLQBEUvCyd49zNsgEA53TO6QFOL5FOhqDOGrDOk5BOwOvN oMNOE+lN76w0yMwZ1jwdyARN5lwZ6FSI9RSd8EQR77TO91QI6xQ67nST+aQ0X+HMzjSd/uyr9JyZ 9pyI52zPAgWAGnhO9jzQhWDQBHXQ9TRQBHUJ8PTNhajQC61QC9VQ+sTQ6+TQiZDPDfXQD+1QDwVO DbXQDz1R8IwK6UzRDG1R8TJMzvSV8bzRAJWZAW3QCX3QBUVQBYVOBfVRAgXSCDXSBeXRpiDRF/VN 6oxPJ31SFYXS6ozSDO3QEsXSEpVRFJ1SK81Sp2jSEQXTGX2bvASY/RyW/9XMUZbZ0SR90yNNUgk9 CSHt0SN1UwodUzIFUyoV0SsN0RT90izt0j8lVCyV0j3lTT3dUhXlLp1aTvMslqxUSzbFFzydUyKN U0w9UCSF0yGFiiaN0UUV0xb1Uy2tUlRFVEYtVEE11EGVUUU9VVd1VBtdTf+0zZtBy0q11B5liE2d UE2100710V/FU5SAUUDl01YVVGXNzkZ11VBVVWhd1mSN1WbNz5a61c3EzRul1HyRuWgLzTn9VU8l UmIF1jpV0jdV12o91DEV01dlVnht11XVUkPlUmqF11BNVHv10kTF1hBSy305TNtEzn5Bz5YrPcNz xLV00Af91Dg91wLl0f+JxVRzXVdUZVUpZVEMxU5kzdh+hVVSjVZ/XVF8VVVAnVYT3dd3qtXDdJsa wdWaAdBdYTuGULfT21WUMFaq4FnjAFjOmU+gtTRfQo81Jdj/FBbR+z2cZTeGPa3TWjXE9NmooNri GNq1eU+sZbUgEdjPTNNbolFOu9nEC75w/S7vgrBTck2rfYq2/QoQBaG47bkfGayufVnQnFlvbTnF Ezi1875pUynSqrNI01nDdR5DcR1DiVn+HB3jXM480T/wm0KyXTrCRSOoxVzUOlzOLZuf6Rn3IViB vZGB5ZWm47/TzcBUK1zNbae17VzYnZm7JRR/4lawNViEFZL9Az7h8zT/pluntmon4GUIqe3Jt73Y 2MWXYzkx5dxb1uSX3I2RmUs61WW7ajujBEhbO6uzzJVFTg2L4z3ef/iHkxhf81WI8WWI9EVf8yXf 5EWJuvEnwKpdmLXRl+UXWim9KrRZ1HWGM/ug7KUzwhXc4j2/AT3eIp0K8XXfhVjfGkhfB35g93Xg CMY3eagBechgDHanrl3c9qFZnHHcmqXexKtcNfNflkIzFI5aAY4wzC3gq7tUdP3ROkXXiaVhYWXX 8j1f9kWJCIZgBq4KHxjiGvABCtNghchgJN7gNSqUuTkP+XXZtFTTxuXbgEvd4fMgFTatAGYr110p 78pEGfZUI0XSIU3X/3LF2Ilo3wYO4jZWX/Kt4KgYYiMuYoUwYjxGqwvW4D2+4IVY4jJK3ECpXePs qz0zXdV1WqY1vf/d3stt3UiDMLXtwe+lYXUNViUlV6hYX052Y/ZtXyCmCjymYzq+YyK2Y3fqY4bw 4yTGYCVm5empW27NGZzxl/xlWslV5HbzX+5lt1RiXS923WS80xzO1GFFY2OOik7uYQkO5TfuZDle iFIuYlKu4zuWZnTq4z3+420GZDVy4jS1VQAV28iVttPrPt/LXsz93//l5UdOtdVlR2K+5Bke12Ju W1Ce4CB25h7+YU++5lNG5WrO42tWo1dmYm4+iW52J8/U1X2JXhkBV/8SbsTfYyd1Hlz/bWcJg+dI hmGfO+BiTmNkHukZVmNmZmYKjuN91uc3Rok6tuZpPglrNuiFdmVY9mMlTmJvXqOBvcvcHOHgy1nA hTktDmB3VuHLBePhZcVKxtiIrWGIvWFzxVN/bmM2rupP5uGJmGaCpmZqLuWuBqElRmJV5mNt3unB 7MzchOhnq2i/7b+MM2d1OmFHFl7iRdt+ROAymmlUxuZRHmVs5qCbXuVttummgGWGrtGVKds3pEK2 42W0NWqkbmHgbWF57lW0muk87urN5uuwDh1tbuUN5mPDZmKcXiVBdp6mk+jdxUGkDmbB1dyToLOH 1OsQImW/NmUiHuj/ly6jmuZm0i5sxOag5WUdoHoenNU/s4057A3g7DXqCcNo4vXo95UOzy7ov/Zq 3eZr5zFrhD5tmyZrVUbc1zHuEyvv/Pu+6T3nNNPiVFuzpVarXkZb6q5uqIhewN7tz97qgC5osU5o hF5lV/7jAA+d+GWdwdocddPlioZvFK61jH5dSRPm+bZvqwjh5Txlzd5q3f7q3bZj7i4bVs7psZ4I Ev/u4fbcnlHc3OKZuim8gQPXN2zsFLZoSXsKY5NtC/8K88RLDleIfMgHEK/m7dZugg7xqgjyN/Hu bibxEc9p005xlgkshqDy+EVvUVHym53x1fZdB+diLZZvlxDmYZZq/yGRYTNP4JNY04Jlixt482nW 8jsOcjoPaCKmcy3HczqvAT2X85PIczxfCD0X9EAndCEH8kMncD6nc3nYc0T340Fv9EFH9ElH9Ino c0ovdIYIdEdf9CrnmUrfc/UI8j/o80Q39E4n9E0/dSWXc1dPdD9n5MZe7dZmq3Y26u+CZxeW8Br4 hl7/Bl8HdsizWBkZY5OmmXA+gBu4JYW4gVLGdC33gSDvbWmH9Xzg61Y/9aYAdFV/dU+3dE/PdhMf cEA/dEm/YCXPYHHHYG53CT9/dyGPdZQod1Wv8lLPB0Ohd/TI9hX/c2u/dG1vd28Hd4JPxeVmb1zD aHeGbQnn3lTy9f9fD3Zgh/iPxux1heoyJmYbPuM0t2eOx2G5cNAbOID1XPY53/M6nnYjnvaCjvZY b/enkPdw//eBF/dYH/EgR3dHz3Yn//Zvl/lFH3iAh4pyP3QtT1xSR/p4F3VSJ/XjHvp6D3pWN3qq j3p4bwpoO90qDNz2Ri0J+/q08iCKF/ZeZwhhp3iIM3aJpVh2reE0VvO1z2TMdk5lJ/kJtXu4cHZn x/OXHvhRdvmAp3pNh3p/9/l1//mll/dXPnepZ/el1+k9znnHL/hVF/pVJ3rBr/oql/NRT/yqV/J+ v3yrT/XGJ3jL93mmi/EbNL0t14kEwAkyH961gnjaX4iJv/3aT3v/i5/qYb1Ye6bnnYXQuR9WtqD7 4gcAnRp5tqDjOsdjla/23l505r/2qCd80Yd6bxf6QSf9es95ns958cb0TN95zZf6oud+xJ95f88t frf5Pi/vq0//6zf8f5//DVTvWk+zVUElczijUgEIZzUG1hBYkKCzbwQVMvymsIZDghAhRpRo8SLG jBo3cuzo8WNHAAAwiiRYsqTJkSlFsqyB0qXKlxJlDqR5UmWNGzdY8qxx4OdPnQR9+KiR72i+Gj6O EjWaVOnApfmKSm3qNONRjFklIiW49erXr167fpU3UF5WtE+RJj1q1uxYp3CvXtwqlmvbpxvtru36 58/AP1sBC877/5dt4cBY9dLla1FsWL137yYgWLnyxQSaLddIYM7zZ3PmnDkbLVq0wYICVztMGJHh wtiwG4Ksbfs27twXadbEeXMmTpi7fccMnnK4xd85D+wEEHTgAZ/SozMneOPo9alMlTItqlTqWO93 8WplPFly3rjks4p961atPLVu09aIb/Z95PJsF9Pd23fgfoEdlhRgNRSWmFNHIWjgX4+Z11eA6uE2 HmYDbdZZZ5ttZk4Nn2mGGmkgcsihaqSZmBBErk0020C0TbTQQ7rJOCONuL2kXEsy6UiccL35iFxy xil3g08iUVfST0ZCRySRVWG3nVNEOSYleuQByJiE4+WX33rp1f+VT3zvJXhflfQ55mCXaXJ0ZoJ/ NWgglwoChtSBhBmI5pV5Sthff1zuKZFmFQJ6IWgcVnZaaaJ1CGJBHJJWkEORPlRRiytKemmNmWq6 aUY8EdfTjkG21COpox4XJKowtdQcS9TB5OoNVLLlA5FsTUVlVLaKh2WC46lnK19dXSlslr6ypVZ9 8o0lrFv1gQUsn8EyC62D7KGXT4MFwhmhnAn2SuyyxEL2oJV9kptRoBhaaNllHnY40GerLTraQSM+ amJFkko0aaUtThojpwELPDDBmxIJFJPPERTdQEI1iV2sUEVFFMVRTUyVd7r5WrCzBM1lkX3xeQzX WxzXaCdhKbv/yaC2Ar55p8n+baRhoJh9aOiIimI24rsEkajoiv2++C+Ml75GacxJK720wdQhrBPU N/wkXZM5QUxUrBlTrDVUFdNIoaABvyVyyWSX7GzZTOPW8kUvw7yymwWurPafGtFs0aGnKZrzaR0m OlCI5nxj0Gv+WvQvbEHTvTjjjWtEpE+QVxfUc9U1/B3WFFc9lMQYcyrWZRoKLPJZyZJ8Fukff+w4 RnLHzbLLd8Kd7ZtsL72x3et2SOjPepMIuGl+Lyp0pBRVCrDxLxqPNOvNOx+wUNBRzhz11Od0fU6Z 09rU1phL7H3GnF62btiZmo062manvvrzbb/ttmIWya12P/XX/9CPpp4V+hm8PAP9O8/m1TeN5Gs2 +lIe89qnwAXKiEmXi47ULOcw7MWqSdzrmsW4F76AXchCNhvY2DpmOo8xcCPacl3KZIey+TEIdgPD HwztN7AA+g6APfvfABsCMH4hjnksKiEQg/g47F3PaZGb2uVywiSsOSxiVpGI5wj2QQ+qS2xkI6F9 RChEiaTwhC2EWQtRyEX4ZSqG9oPh/WhUQ6D17IZsHJ5ovsGhGBUvX8tzER0xtcU9nsp5kGPSH4GC RCU6MCciyZrWIMc5jG2Qg6KrmdLWdz4+yo9trgPj3FZIxjLGsGABtMjeftY/OMqxZ3Xs1w5ddBF+ UVJtnvIIb/9A4ilT0aiJL4meEq9HpJfQ6pXfwZwvBWaz8SWNZGM7Wyu5+EXaza92YVSmwPCXxvrJ UJoyeqMN9+az4QlQjpQyoL/smMDYCC2ZMbuRcUiSztvEckZREw7UCKnI3oAKABXkpVLQyTFC6S6S yDTn6+LmxRMyc6DRHIg1EXrGawKwb/8Dpf9+16K+6ZCHx2MlbYhmTrq1c5b0RAlI1/mjlYR0VB5l 1SFRak+Y/BFqPFFkSYgSU3d0SqQ1giQxN+o4FrJQhSmMn50CRk2EXmSoaWSo3nwmyojCcaKCe1fi wkkRPCLtgDp15Tr1iaqQaqSdwjGVPlPKUngaEidR64kSUeL/DprQFDgFy2kHr7q4gAr0mXBb5iZr RE2jJtSouMnZu7DJzU/OCyJPfeoBwbkv5ZEzqnI1WUmVQ6pTobWmXR1JqHyEkuaUtZDWmeCodjkS d3B2IO6gKU0r+9jV1qan2ZJd7GIr1DNW068JrQ3fBihKeG1TotoUXBwthUrDwWhoFmUtwWiZqh55 VFU2naxzJVsqzDa3JPFsKSCd66PTqrUGqG0rdJEr3koS5K7OhN3cwLipat7PmtLs5G34lpFQ8lap oZRoRY9WPHImr2jIG2+NvDpSyUZ2I5n9anDCqhIHlvZy8yTkIW9C2rWO1rSndSuAMwxNF1rybfKL 5l77KkNN/8nXf9ysb2AFWN/9ppKOxBXufzWsGwH/KEfF4ZGBE3zjyZaUrCm95WaTiGCYXDik3MWx jDWMwg77dMMEG+pep0nUvw6wf2x8qER+S5E46lecU9Xh8vqb5BnNUqTVDSaNbfJKNaP1lUxiiU6s Gz2V2lO0LEGtSNoazDHL+GWvjZ+Alhbi2raXyr1D8VILm9t5KeSp/k0c8ni4Xz6XkMYBNqsir+vZ qAHSutdrK6i9S5DTgpfSSW5mF1NtO06NuK8EQaOhmzpYwAb2ynN0iOAMyOKj+becplagpS9tkT/m Mp7W0aVoP3th1I561KX+9alja9CYvdevCj1qbmx9Qzgm2v/KlZqjr/Or0YqKGdqNC3Zu9pzdz8qz YZs2toUtHGpzQ9uZXVyctRc6o/siOqm79S0b8Vhcxk614DGmt7kfnF14u1sinJ7nd0n9bIT3+afq VVon+XrbbNOQ22vcJm8DeMpJY2rkYJbrNWqQ8oGsnOIgYTCDHc5whns34s+euMtzTr8o14jWNtw2 t7MMr28WXHED3yHBN9rylbdc50PEZRMXPudcNpvUVXc61jEu5Y1fE+gSPfGVC9shi4qzji7+oTlT fg21E4TtTM86RohdbKrLk+YSkbio4a53uTbUjW2UtX2H1ljiEe3saX874tW+drbv3d3YjTm7hWwR nDe+8q3/fCPIwY6RrwvXcJC+Y+eTufjRq3zpLG965T3b7glavvVJ7p2JL+Lz3comaIVH5TzmIRHd U3Lpbl+7yoPP+OCnfs5yX7jrky9ezAM8xYfmPPEMLrR5RIr3NdA973MfxKYz/u1tBz7LlQ/IQj5Y +eZfLe2zvEZtZiSPi+1hbHKv/etjn4GIF77iFX/6/Jtf4ef///L9m28JnW34kKRYH/0RBAJe3wL9 HvdxX+mFH+oBIAVW4GNhnuZhIEiYXAJZH/bNnwIBH/gRnwTe3+JZIAqmoE5hGWBV2W28hu49RP1Z hPzJnwIuIOPwn/CVXv51H/hNoAoGoRAKke8IjA0y4Pwh/2ANtk/ifZ/+4V8JAuEQTiEVjpkN1mD2 MaAWHiEIso4D+p5EMN39VSEZliGA1R8aeuDuJaD24eDz9CAYml74mSEd1qFOYeEHaiH9qeFFuCHT PGBGnOAPSqEdFqIhLhAe7l4aDkQeIqEfLo7+ReL+zeHwHaIlXmLzzGAXMqIC7mEbauIj0g0ghmHb RSAmniIqqk0WtiEbLiEjKuEWNo738eAkSiDxjWAq5qIuckoWImEsuiIr+uIRQuIgmiItyuHp7aIy LmOmoOEawmIsrmEOluIckqIYUiIuMqM2bmNGcGECcqIecuInqmEomowIWsQXOiEUciM7tqM46uEC euAwKv9hL4qiINbiE5LgLLojP2pjPd4gOA5jJ76jLLrd/o3eCJJePy7kNjrjK35gHs6jJ35jDg5f Qv7gMWYjQ24kJsqjIvYiH34iEw4iBBpk93EkSuYiMCYhDcIjRDYPRp4gPlYiIaakTVIhSzriKz4k QUJkOcaMTMakTNKiLd6kUe6R6dVkJiriN6ahN07kTyrNE/qgMQ7lUV6l/UVgQgJR9sljRGKhOP4j TJ4k6lmkUmIlWjpOUHIlSD7jTsZjVzKhE4rgA1plWt6lLBIlVTLQUz6kN+ZkOC4Nw0AHRvzeDh4m XiYmJCYjOu5RV4KlSO5kJ0Ylp0zNYEqHRuCiRiomZ0r/pUUepDGWEFjuoWRe4UAmjatID2Fe5vdR Y2e+ptqYZGOepeMkYit+JEEqjSBZBFBgJmz+pvNUYmtqJW3SDSiOYzDaJmpKD2sOJmuKF7rJWEwk x8A8l8BYJyxFp/Ngp0nQyHSWokLu4Dkuznf2oTCCozT6omD6xGU6zXMuTZlxZ21oZ46plozsiHLZ xncKSUjYCEnAkn+6RLrN2HCAFHV+1IDuxn8maHlCIDaOZ4DKZ3cKKIV2Y0S+Ix+qDcNY5sIQpm9i VXVKKEdo1YyBFZIRaIXWRHWiqH6SGYuqaHfyZ4qK6IQCqItSqCBOJWMWp4ExaEd45EpSZsAM0nRs qCC9/+c56RhlVRaT+pKTFseIKml0kZRNddRz+caE7id1mhRzCaiJKhd1YemUAoeNIehHTWeYUqmo hCmaZlWFuulMpOiI1ihmqUqW5oidHuibwmh5Bh91qRw6BWqbuqlqiSmFailH5OQmCmllSsSROmpq cpSUDplmQSmJHgdX5ZhbKVh2WlZX0Smfwmgf/WmMYmmCLReaxumBdtSMquiNtOqqxqlX1amoqmqM yhKovqqXoqqeiimihp9IpFywXgMAECv4pROpyumhKqioIqqExuUMMk5q9uZ0+CaSQtakEliyDhiy 3hh2hgqnhkRWfeuu+mqttip/nuqp2uqyrquqVims0v+qq7JrqN5qp3SnDwBAI5WZsvZonfZpqrIr spZrlp6rgAor8NVpwiqouxYsw+5qvdIojfiDPwwExdaIZXLoarLntXLMgd3Ek2Yqc4XstyopvwYb mwHovzqsjM6rrL5sjdZqwBpsn07pusorxNKszPYrjOZrPnkHnsJsnt7rysarnDbsvMrrr5aeShir q5Iszg5sv66sufIswVRsDVBsxWLtjDgnkRKppGIYpVpWuI6spYFrt3ZqH/Vn0S7r0Qqty8bt2xYs 0rrtzt4sutKr3eZsgcaUvv4SzvKt1RIswMotrL6s0tbAO0znO8Tp2jUtZqGeuuptzSbtnu7t1WLt xWb/rdZmrYzsJntybJGSp5SWaaWerp322EiF13RxK+sCCeuy6s5i7uTCrdK2bLuubb026+3Kbe/G qr0qKMb87Ug0ReAWLs8aKt7iLpzOaOMCwPM2buOqKMIibO1+FeUabLO+q/ZuysV+r8VuLtfmRqRa a/mCKJmaVJMKamRdaiw115mqad+CbJuZWcwu7Zim67uexJr6Kv8WqKgc6v9GLT0p66dUbk14R1EU b76CSq+22b1uL8sGrfaK6Tss7vMqLvRKb00krAcT65fyrdSGl6G6rcTaBtd2bvhurQqTrxF5qNMd 2Hae8DklKNPQ8EVYBVV0zvfgKsdMr4xMLwfbIo8C/5jmam0KN+qHwjC9yXDz0Cd82nAU18gTNZL3 fAQOe4T0AvEFK+5AdPEXX7AYd/EQA7HTJTFBbC7npvH4XoQ3vDEc8+bCGCnYmhsUY519iusdl+ge Y0TFeM7W7LDjjLFECDEZjzEie/EXK64YZ933au4aq7AaS4Q31MAbE0Qlx7EcF2kdA2cVahAUPVHz gPEWh7EQLzIiNzIjl/EZg+8aey7nIvH4XnIlY3It33Itd2jHejIV6jAU5TDjcPAQF3IYrzIxKzIj r/IwIxwSe27nsnAzb+4lW7Ilx3EmU3Mu83Iu7rAvY9DicHEhq3Iyk3E4gzMYIzPFjS80R7LFOjM1 2/9yLtPyLb8zHUpoFm/KPbdowOTzjAmyBl3QN5vxISsyKQvzFkfvF2+wMPPzRkGyRKjxI2PyQMwz JVM0HGfzY5XwjbJT9+ptgHp0jw6upjD05U7x306MgArydYaEQA/0OJuxMjcy9LrE4hZzR0PbJMPy K0/0RMczPU8zPY8XSYN0f2JxgNWALyD1TS9o0pC0RtdwhXJz11ix0jSyVY8zVhMEKXsxTtT0Sw91 MkE0Gx8xJfsDUMtzNVfzNQf189Svgaov/6ZpvOZnPb0vl7YrlHopb0wuSyS1LwCAL/g1zX6pgWpX Afft0x5wt8L1oCKot5Yqt761gK2ZSBivTNm1ZB//8ILmp5curkhIL0/U9Gd7NkqQ9luryvQ+tqmt Myw/czN7g1lj81r3dCaj9QIxb6ls76terwHPbsxGbF4nK26LRFIfamAXt0sg98PSrdBeaW4jLW8L t27vb42h61NT9896KdDqqV4Hb28/NfSONgYrtAarhFdfcHgn80iI9np7NQGvtkW08EObNS7/dE/b Ny0DG3e/t6na7uE67LlKbXn292+rq1//dWCPRGAPxF/7K/fytoN793D7957i7XRLeEifar76bAT7 7n8bbiGnd0LXtBDPdPR2cZ2K8UyH9xav+IePmTrrdCTHNkZPM1C/syan9Xbut9F6uLru2e7OLfeW //R736+ALriCq0RxI7hyr9mDh6w6UbAI87hHWbheQ7BuO/lvAy9wj/CUw++dBgeKC2hqY7BMg/Es mTl6ozeZhyqYw7cst3Ya4zglW0Q217ZatzWVD/mXw+1m06uAS/CUC+yRq+iCH3dNIHreMvenJsui ezihe/mAT22uMutNIy/uPrrgWrqogjYGJ3SbZ/CIE3R7mzmLczWIm5v4yvjWtnONz/M1x3ql7TmA EzCP1C3ybvmvEniApwSCM3iSHzpSA/aCv+nv2rpJnA4AwMX/xq1NYCqF87rdSjt//zmjC3mf63pJ m8R5j/cpmzdNl/kGwwSbl/rMYi6Ms3YsqzVa1/+2NeP5nWO047h1rsf1/tJqHlcqZjtrruY7nr5S ggv2sLu1AOO7meZpFskDSyj8XAdu6pqpuw4wWIGqYVt5AE/wuBY2n3L2ji1yTaj5pzswmrOEin/2 Boc3kx48WAdRG4NvxVqzG+e3bOf3bDNkgit1sR+6ciP1zs+IMXVMFnknA638D8O0FwtzMhNzQWv1 0f9fG7txRlx0jac1rKPkr+c8zxe7UltRCJUN+3C0fifTQTe9RpxzTCtzTBt95a16ReM5bbd9nct2 SjK5RSi33Wu9z5/OP5GOfnI2CiK9OBvzS2+1xyP9ENa3ndt44tO5vLujwC+5zvP81k++z5eO5V// ETeeckujPSpzROCrYH2/uo6/u9Q3fjtiPaJr/XGvvthIRNC7oyEjcyKXsuzDtNqD/lrnfjzj8kUb JXIvOYNvvaLjPY2ozgh9fS4esu3HvlbH/lUf8+HfN9W7e+/HuumHPcIFx+oLNvcfuPdrivqYzuno 820L/XxyytKXsiqf8+0fvdkXDNG3j+7LM/1jM9UDW5UzdSuJ6DoFvEQAhC9fNQbWIHjQYEKFCxk2 rCHvoUGIABJCdNiQYo2MCzde9PgRZMKOITGSFGky5Lt3NVaydKnSZUyDMAGshDnz5sWRKA1m9MkT aFChHr3VKOoNqcGjSZUWNfrU6VCpHzvunHoV/yvJkQUFGuRKcGBBsFklPrQoz5rFiFp7knWr8apV j3KFqoRpV2bLhu9q4kyoV2fWn28Ju10K9TBTpUajFh5aVSOAjT4lY5RMuXLbzJsjT76smXNbjj0z c7yMmeJAAL5WfxZ4eufpk5s9074sTx5FALlLwzb9+bPmziJlD58bXHfv4idnG+9s+2dp0INF+36u sKVsvpdV1uS+nbvklctll5cuGm7158npOnbfMOpR+FCbPn3/WGFv4ej5p69OGTTm8ousuf7gmmy0 AttijbXVCGrNK/9KIpDC2AyyBsPdNOJNQQn/Yy65DnUTkCoKDxwQxQD3W/FAq/SDDMYUu5Opr//x trOJIr7Gy9EmlvjyMD0EUxRyMP3uO/IiphqTb7HEkBQKMhCBJFFC6hCMcsAoR2RoywlZXI3BjcKM sD0rqawyot0AwPBLLvmLLss4eeryRCpjFBFNue5sE8vubJrRxy5/hGtQ7MYDkrqSRiTyzScdXQip wxKKdLFKH50zxSBJszBTM9tcD806Ewyu01BHLEg3gVTjsjghgyTvQmvWpIhNOjnVMk8USXXItxi/ +QauX4HdU9QWy+NVTj6tE9DG7H60q6ZBeezu2ASdi7PLIjO99MmlKLUvUsW4RQlLTbcdCVf0bM1V ShetbRTX1HpiDSF0dRVwXVlHW7MGa4q99V7/Yu1FFk8AfuXvG4rooedfdrclcV1iFxoU2pi8wylH n3qMlkUDLVxUylDH5ZZJxiQdmdxSRR0YYnULJk5kPf1jubJ4waLXM2tDm3lm3fy9UCNZ/fU3W4Db TbbmkIe0NeEafq0M2GGdpkcyqpGOmOAVkyZN5LY2tphQr6PluNCt7zWQ55DLRRlJJe1jjG1MW37V ReRIdZU95UDGl+BdidsSVi3N/tvctIED9cSfMZtyVzhB3Ppuy/bu6emqAWCYnoMvS9jqxwFHLmu6 RUdN8oyRwyvHzgA7/Dqu/eYbX+nai5v22m13Ez/aZw9q6H6H/rnf0MmSGSVgM4/a6RoYBjZ5/+QN Whjl3X3068+YbsrJLsBu35777tmWXvjoC+v9dzYDI8zdkIQ16JuFj2eeYfYzXxh+5ePnFny9Wrpe fx/51957ARTgAN8CPi+NazmEAZ5CFrgpA4YkgUJh3vraFzVhHWx50GMe/l4Hkv1pr3r+8wsBSVhC E56whAv8WQMJeMH3Ka99yZua0yx4P+XdkIQ9yp718CITFP4QiEEUIrdYaMIJTu2FFjzYEp9Hv/qV EHuAwUuPhlhFK14Ri1n8yAYxGL9fzY9+SKQhDBMSP+hBkYovmYkAEdBGLb4xfHDknvSIB5IHyo0k E3zf+o43v4RJpn0ZXOIZcReUOwLlgwFEgP9B3FiDNi5ykXLUYqIg+C4HHlKAmCzkXOJ4wAKizSEU RGIMK9g0P7bPYEq04cNMosk3RtKNkEzIIx0pySpS0o6WZJkVXcnKTfryl24BnwVvKMgKHk95FIlh 8jIStVUCM5e2JAkkqVlLWDpSltL8Ya/0xik7katVoPsPZ5IWOdr8LTrQ+U06a3MexJHOWOg8kziF A7rI0S2dm5ph1GRDteBUDpCnid+x7NlNz7UzW1iM5SMjiU2GyrKh2jQhgD71TWi+C2vKgtmHKpQn RnHyRecKWJZcpTSXwehKH41YKk3ZNBgmLJAw1cjBZOgTM9LJRCH6VEa1dkVaNpKRjGSoUGv/KdGJ wkukD1vWAddVJ4GdjWdPnVKyGqYyniKqP7u8qrZ89TTnvZSlLr0c5phJOX52rmVS3WrHgJhNa8IS rkF9q1FLmKi8nWeXniyVzdbTVPWctFdQzU+1KtqohgmOnoRzWFXZyTr2be6lM/3iT5CHSlTCBq1I xdNhR1rFhRY1qBANbSMjSlfv2XWqWS1R6JoKuE2mK6qv9RhV/WrYtcLWTU9NF06DJSzMGex5Gpmf ZC8nP8oJ137JJKRuO7vT1JLQrddUiFtHW1rTnlazs3WZh3CZMyyVtLae4qxJ1cVTvG70tujVWc8W y9VkubSlmUul0y7XtJgql3P0G9H9mHs0/wUZCZRsHKpDq2lNosb1ugNsnAN5JTt0lpRw8HxTYmFL JApvNMKmGpw+i2S3u0GOVbUxFnRUKk7mfWaQfwSkV2HYx4B+eHCtvSd5zLY2E0ZXrgu5pnStm2Af s+XHlnyUN4EywS9+EXOlPPIXZ+jHqS0Th0+CMApL21CIAvWnBu5xkLncyQT3cipELrL96Je5lyLZ fYGkIU2ZGEOySjnANz7wLAksVGpGdMtd7nIEv9xBR4lZKGF05gWXabznMfmCOITeMwt4TytWM5bY nO5bs6xnS1/6ukzGnKDfZ2Y3Q5mUZtw0pk0C6SvvGK60DK2kSd1qV1uRyWQu5Rh9e8Mlg//RfWdk 9Ksn/VktzzXSqFY1r4ldbAFusHlcJPQpA2lmDdpw18ae6699reqh3lnaCMy2VMAcxFrv0bdJDreZ U0mPd3zjHbqOtpf/XLtTV7nORX3otu8Dmw3HOZO1m/LINAm+nUwWmYPmI/Kodu6FnTvdz8sJJ597 0WCej+GD3Vl53akRU2ez0gW2c47p7Rgbdxzi3Y4bJpEMU5rusXkMO7dGzl3BdKf7jADEncj1CnGb L7ZwWDUwq4HKczpPN88gjwtJLVw3daqInAaNZ9p0VXHCnqic8GQPgxNKdKQXtJ1IXzri5MlnqK8Y s2DfnHwFqkxULiyc7uRm1usZG3XSuMb/ijoTdxtunsr8FMtA7/mwhS7MwfqX7lalqE6xGtLZQlir OQVvTk9qp5SmdcqEb9FmBfuxZqZSYYBsi7B0k7lzewd1VFM5S2xMUcaaaEh/7Rgue/pL3nJpkQBo pOx5jvFeb/w9YekKscvlOE9WmPKbff3rVRt8tQI+rXtVKt2lWvnc5kdqVDOeyb2aI4YZTGFoL7he MgIo5/M1mKi1Vx1Zb2/i56eNUbKyz3tO1MJ8pSvxf3Xvx+l6qF6p6Y7VVPpel/jeB1ZpfC/5HkzG 9G+8tKv00ET0OAfgOI8vmAz7Ek5HUoda+Ez8rOP8ZoyqUG+9eganisZo0s/KSCvYNC73/yLEK1RF 98Riz6xKlzBquw7w9NLHogbQsFxQPYistrKrWGTQaA5PV9DOt4DLspSJvqzm4LYER9YIgMRP7lbL CTfwwVRr/ITMJ2IpI2wP6KaNMFTlZg6CK3ZP/vSM/lbmBQPwZVwn9Z4w8GKna44vBpXPBlfmAx1G 7W5Q+LxKc9as83bkR9BOUMKmUEyqtaZKpTawu0YFEfGwLRCAItzoESVt3qyNBMlCDMUiDL9w9yyt DBcnxCQMb7jucL6rb5zOw6pKnmKm6taJktJOb3qwABknb9jQA81IxVjqMkSvM7ZPO04jjfTpoDrk N/4O7lax+ECFZrxOMhwxOKhLtKyL7/+kQgUjRP4wMQzHsO8Eg9uAiAZbyT1oziFscc2MB+bch8x8 aH8MReZ47dqqC9sk8f3GggVXMCF0DwxZMBu3EUq4kd36UR/vA3NeTteUJ+H24nqYcOGKTbpmaRIH jLqwAv68ECEaIixQMB+Hbh+3yR8fjtv8zDHMDXokUOUOjnoSKZFGSCF1DNjm7D6m8WaqMQWxER8v kia7TCXMjSBh7oPuYnr+5yUSkh3jDR6rLOiC4itQcB7vcRPHoiab8tKkyFCYcGL+AjumJ9sWEsEc Kh4nUiIVQgXFEAwn0inH0rSgUoTuYoeoUo3+JB3prQS17CG7ECbvsR4jMgVN65DAUXz/8NLvHGOK 2lKNplJ/qCh71rHd4GwoIkn2sLL93s8eJbIi6xIsu1Kb8nKIWA8xDUkzU2bmgKwudGiHQmiNuu8n RZPfDjOaFBHScs8lmfIlEcIeYdPHLFOIMBNJXAmT7oj//BIh05J6/sJZeqg0Rw41V0sRLwUTkVIs LfIaw3Im5WjqJq91ii6friUVr0On4E6xJK5mlG6dGCxXPKw7mS78YEy8UjGB1u46F2X8QJE7ruNH vsMXl9A8Y9ATv3PrlgoYW4c/Yefr2C497Q495w4lWvMSZTMyKTI2K/PxNOsC/ZMWGe+/yJOjUPEY D6vEIPQM+QTfyo9rnMsUT6JiKJDl/+iTRzLGhypjRvYE/+KM8HawRQuL6V60M2cuRs1wKAbiHHzh HHY0OetRHheUK5fSlpoP6ubQ39oQ58qEB/Oqv/6qCm+OuXbHQ9uLrRolO9IjS2fiYlwCRX9yI+Jz pFyrkoxUSXfwSFHrONd0BqWiR3tUR3sUNg30JSvyKOnKSCXP3rjLFA2wE1+xRqfDb/yPtlTvSmsQ Q3WiVSYEpRa1jvqK5SwGNnSES5uF+4jOnujQ6GKsa4BxT/d0X5wq/yaOECG1B4GCR3fUK3bURy2y Ll+TIZ4TOgu1OSJPeCSmDBHVUM/vTK005041qTi0G6tUYg41Af+kRpjDTygVdS7VXf8mB1HXClkA LVTJ1LkCFVh51SPOwSBUlUddcgWnETKpkR4lKk/NpfmSsVcn1FZ9NVrZa7dka0PHy5tIdVdNxRBl BPRegkcYqzCZFRVD8Rg5NWdSz0zt82rQJgrjECW41WG7Ak7j1Cs38TEf8y7NdVG5c7sydjslDp/4 FFCts2MlTGP5cxSXRgc/0T13xu2KJsRGVRgdT0XBAwDswA56sVlJL3UidZxIsWMzDLEQxTu9bkbz j72GMRgJNCTe1GFrgFXflCsvomLjT1bJktf0Eohuwg5qwGa7dmu/VoSAc41wQjit1uEaglsTglVT 1UfTlhq/MCYvVkjNlvee0g5Uomv/uXYlvvZuxdYnrZJuhcwk3JYgoJZpvdI1LxZIKTNw67bLtvYd bDZybZZr79Zyu3Yn/3IwG1dpP4Jp5VRVnRZOCZdqhzQpl5NzUxeFtrZy76JvL3dvMdd6UFJ1r8Jh 3VZV19ZpIVNc7RQbaxd4T4hyDcJrI1cv8hZs9fYkfzJ4heJ21VZ0uxVOgzRqx5Bxmxd7bwdsWXdy I5d479Z7Y1d5yRZws3cqbpdbfbca7RRIE1fosDbMBDd+64043wN5WddrP+NrjRdy95Z5P4lzn/dh BeJhqTc215cm6QJ+UxPfNvM9FDgjodB+v5Yi8Jf0Jhd8Y9d4x5ct8Woj0lZOGVV1/5t2dNP2K9k3 QSv2Pu6gBu7AhVuYha9ogXOncyP4G0+z4aaCbyuYdbm2L7iXa11ieCU3JzxYdHG3W9m0cUNYIab3 Ryl2OasWK1iYimPYIF4YgQoKPFlxi9kToY4j6b7Y6sCTOnNraLGudEAxPy1w66awPvfljCv4NCj3 Zi+jjsXjZvuWY8jGDAGgR2XjHPxYPKPTbD93en10QS8Rhd3Diq/YkauYisUHwHo1Xm40SQ0vq2zV kk0jDVWEkgNmk+F4nj7UQiU0S7pWji24Ooa3Zms2cmv2bqNUIwI5kEnKadF134aCpi6NiUl3TikW it/ihSMZhqu4hWEYmbUtV5uUQ/9ruJPXtbPW5klL+fgOFk0XFppnY4hvtnK/F5Zh+ZVfOY9buTMp opbN+Y9p+U39OOe6jYKOyNVkkjkz0TFiGJKx+JhdGIsb+UgA8JIIFfnQlDuldW4wEJ/OazbWTv8A Ogdp1aFLFVQLOu1Egm8p2IdhI5bHWecEeT/+eJbV5my3KCF2udioln0Rt54dOZ+LeSH02Z75uTAO Vg4bOvhg0Eyr2UWlMGVnev8eWkbb+bmeaof5g4K3FpaRVzfGeXhFYx7QmaO7VTfclp3VVIJoDZ6R 7dW8kJ6leCqI2Z6LeZjz2av7GWaWGV6biw61i0BYlKEBTJoL9abLekD0ZU1q5Wj/fRqo3/q/kvqv ehguuDmIYVkjKNdF5mEeaplbBRlqC7FTeUKJZIiYtu2kU/qKh1mfK1sh9vmRYbrRoLU/M8xkNcxa PTYWE284wKv/inFA5wlyLgNDhKauM4TDnm/uFuyzRTFp7ph4IyNv//o6LNpmj7oGDLupFeKwa/k5 PPokEtvBqvqqFYKkzZchGhmSE4KYjxm7w5qzJck29WyFfCd42MR8nBmAP4Jvg7hytxe9/Tp56Xh4 58G4h/uwRXe+1RZ9QfgtuIh9CE26L+Kyt1usM/urWRpPczjIyCdWfgdoQnp4QmJ7z7ui11uV07ub e5i4Dxu+4RuE0TeJpZdwseKr/9hnpKO7v1faiqt7pQU8ko0ZwHnJI0lNwYHGfBTnxT3OwfGXjnc7 vSPcvYf3FoL4Fm4Bvm95vjW8Rw37iG85yT88K3aZ0LA6gG7gBowqrJP5nlf8srH7kUu8dlhIhRS8 dwTIrxUieYN4zHc8yIlXyOE7yIP8yKE2w3GXcJnYLd75sQVoyhNCyvO8Bvhci8baulv6q41Zpbm8 y197wb8cvL97gCLczHW8m78XwoPcDpC8zR32Fgz5HAw7hKH2lpl8Kkh6iUicdva8z/lcyvtckvDZ pU9cuwfcxLPb0FFmhRg9vMMb0cebe7z2vCtcvYH8Ftw72LeWzQ37x8/h2DOd0/853SFAN79FXMSZ yHb8PM+pXc9T3SHc4YdWvLKrG8BdestbfNYd47Vz/dYTYsbFW8y3Oce3ucJr4Me/l9KFHN7nwc3h Hd+Pe9ONnM6f99mVDcpLXc8NYspTveCpfcq1vQbcQdsbXuEXPoAIvduxXKUtW+KRWdzHXYHOXcZ9 p3xiJXi6x73Rm+Tfvbfzts3rPd7tPdPpe9OPfLjl3HAdY9ThWeAJ3uD3HNsJfuAX/gYc/uEhPiGC 3iCMwRgS4ugvxbKtnKVPPJkLncA1/lJqPcZxvXzCvNF5vMfTe9jtIM3b3Ovl29jtvUcv/dgNYr77 Xclp3nuq/eBPXdVNXdXhnuf/F4LhG14hFD7pF+Lojf5RXjrLMV67AxzFn17qkeTjgUe8zb3ji4h2 cHwhTr5ygx3ebRbsf1zI2xzzhRzZyb7IXz7JLe3g3X4h5N7PFx7v717hV1/1i77o+74G/N7vkYTb A53b/zvATRzcDx/xF52BQh7d0R3Rs36IyVzSLT/lhx3tfxzJ8R3e793I9R161/7H3n7nqx3n4Z7h UZ/1if7ujd4djD7p+178kX7vGTmzMV7Lmd6695m6ef9Ihl/4gd/qOd7xtyfHS55rf7xr+Z/yAaLG rRoCC86bJ/DWuYXnapy7pbChxIUEK1q8iDGjxo0cO3r8mPFGDZEEb5isaJLk/0iR7tzVaPnypUuX BFu6M4bTWA2cO3n23FlRJ8ihGu8QvGO0olGkNZgmZdp0adSkRKtavYo1q9atXDla+1rjq7WwF8eC JSi2q9qNduzUaFvRrUC3bW/ZGXj37sCEtw4O7LtXocIa8yQSZLg2seKPJE+KPDkyckqXkB+TnEkz pk5jN2/23AyUYM7FFpGalhq16VGMTk2rVo2atOzZtGtjPRs2rdncu9GStc0V7tuLbvFWhFiQ4N55 fyFC9OvwHPO9hhsCv04UcknJKldajumOZeTMM2u6xHme8/ka74y9Yw96NHCoR6nWX0o/P1T72Pv7 /3+bbryhBVaBuR0IoFVyvf9Fl1wN/iUXcgkJxBxCz1UIEWIWWZdghyVVZll3KW2HmUwywRRTTTvd lBOLLr0DI3s7wZiTT6Txd5FTU/EX22ureQhkkP+ZVSCRZOF24FlICsmWcHDZBWFzFgX2F3OEYdjc Qw4dxmSHKWln0WMfVkSZTDe0dOZI5Ykm2mbujfamTu3J2SZt+0l1mn2upVZan13+CehiYyH426Bi 7WZkoGwRFxddyTl33KMFPUfpX4om6FiIF335pXkviWeSTTVtxuJLNb44o1DuwcfmbPSlhp9ST722 51SX3orrUGn5tuShgxKYK0cO5jWlpVNG2hykx+4VrG3fhTlmZBjZRO2JKQb/RS1nOL3DYntszumm nfjdWdp+O57mZ7PqNvvrkUX6OqBv62Ik4aTFJutcso8qy+y8pIm5UsBiqiSeqOGlWWJ5nXWLnjvc /uTtm58JdeOe6D5F1avk/uhvx4r+2luvFu3qcaT2WoqcvsgWe3LJi4E5YqfSloTZmTWHNyqb64VL U42rrhqUbHqa2+N9FyvlctJ/toubofAu6XHKfE1orNT47luv0lklsF0NXKPUXcDewUQZZjif3Rln E7vncHtzzlknxdhpjLSP9dnKUQJ6f61134JWZOiR7hrZbslZ86Xy4flKyLjfWOnttUkJaOeYdyOa d9LNZAft2U8O1xgUuPBJ/2yba7MWbXdrr1bENeR8Ow57Rj8Q9EPtNcyuEciCu/tb70rnSzXiF0mp XHKTKht73nzrnekNk0vGndiX0bS5iSe2BCe3DcP49qrce3vdrHyiW7f4OLYOudfJr4/R7LjjnrvT Avrud2DH9csy4ipPbTz7Fn2dPq6RBICN+VDlJqMwmykwRdpakWewt7Y4yQhuNhIa+XRkN1qZTiOt 89rr/Nc3993udrV7n1cSBax41a9/yiGesUyGMuSB8CLo8yD6APaYyV1OWgM7GIoMli1tCeU8c0pP uGr0ngq66m6xQg3RcMS6DhIkfTN0mftsR0ISlrAi8CsL4AhEsvXFEH+Mq/9Xv1J2uBm6TooCFOBI dKhDHI6JPI9R2ExIZSqfqc0n3ptgh1RnNNiMCyMAXOMHq5i0LY7wIl3cSKIKB0IpydBqkmph8RB5 yEJ6x4PSi5mmcDY9FF3ETd1K27bexj3RgM8/gExdrThoww4eEpHN2iIWtdhILtLSI8Cj0rJaeMb7 FQ9/ICwk+qTYqRxuCiXbsRkQVUQmmaitPZ6hUcTY47af9GeQ5uKTR2o4y13Oy4S262I5tSjOjYwR Oc+oQTt9CUyqUZKWe+Ok+jgpOZHEcUzfQaA/yZYZ0ORRPd6CGzYlFi4ANRFjGcwIFZcXznQGqpwl JGcWL4pRiQ6PWc94Z0f/C/JOZplRf+J8qBQjl5I27rAyK6EMwtKkkvKADj0DdZtB3xM0IMWqoR0J YEQ1qqhzVhSdtrQoUIUpkGfcoqNKJchH3zk84V0Sk+o7ZizbyDyUCjBsBQxVwVT0w5xwS1Q8Kev3 PqM0Nu7tp0cNkjkpysWK5jKXGnXOU5fKVPu5c6rxJGYx1zjF120VcgADG8Gu58M1ba6U2HtPEj8j OqA5TrBtvZQiLYJFod5ykZU9jlKb2tGBMDW09/OrX//KOhquNY4sNeBhr6emzMBWJzApKE7dRCdr as11ge1sUBcp18zG9X1XpKtE77qXzzrVne2MZ/BOy74a2vCegd2nPhtT/0DoxRQ8azrRqba1mYgl EbyTlS5bfZugcw53hOakHWc729SkMnWve8UrPPla0upWdYqGlSUPwzQiNJGpu9DcIzZDQ94++u2h 9kSvkOAKXPeK8L2b9S1okztf+n7UjGmkKkQ5GcAPPa9rXRWYiX5IvWsBJbzj5clj/VdPB3epwiak 3S3bi96nkhavToUqaTu7Vv72lrr1TOmmcBg2aIoKsRYp68/eFCMYn5eV4gMqOa+ITkau17hH1XE7 SRvapUIKupj0KX9PemYddo0osvWIT16MUxmHD4OkAYCdcbVFANh4wsXdM5avo+dbZfjLSbXvl6Ha 4UBT9X9C3u//XldiOf97yM6UVvRV8oM3q1j6IptOjKI7TZRzWprLGdW0RgINalRfar6HTurxNgzV jYAaI6rGyqz7E2Qho/mYVJT0n25dlVfu1NOzAXaotQgARWo2wvAjtalpTRBjeyjDzKXvJZf6EWlb RNunDhKDY1xVyvpaUammdLRrcGdOoxsASLmzUSp97nTDG9p6Nve67zzveqta3p+2N7xR7e970/vO s0v2vQ1+cNrZ+wfz3nZFam1vdCf84f9O98Q57e+I6zva+7Z4vu/dUQB8VOT0JbnEzz1xfff70wlv +LYzLu8Exdi/qm3wuH8N7Yev+9QAjzdVNo7yoOvc4yi3NNA5jvSTO1z/6fV2ONFfrvB4l1PRtmt6 wRm+dJ0XnelbzznRja7urJ+c3/Fmubrv3E6Rk/wZgW6uyVkO9q9rHeJi93rdca1J3gIwtTcHVKXx 7XRZq4bdTWE34d+t9MR3uulzFzrjtc71sMM98JB3fMHRLUKEjzDZgS4h2M8+dLuLPt513/TnzS7x z1P+3GyX+FOj3XrGx331jVc8R2otpF1Xd3l9D9TiaR/2O7D73cKfyuMPbvHQ1372WTf734N+/OiH /dxY/3uyGV7p2lG64M8HfdGfnmrHI9/00x875KWP/JOnPeRsb+62Yz/2558e/Bx3ef1j3iXB+hfN ve/S75WfEXqGeO2m/3TFp3rddnriR37QZ3tcx3xCp3jah3Witkh69j7HF4CRt3wZaHvAtoBd54C0 J33tJ3KsBn+yl3MQSHeJl4LmFygfBm7953ctiIFLV3yFJ3xQgX4QmHpLh3s92HwAiH9ASHqV14Cc 516c5z52xnBL2IDl93grKHkiWH5HeH4dSHGKN3LN5X5pd4UASIQreIBM94PcBhy59jpRRhCOJYMJ Um5DmHM5+H1weHFUSIby5gdBOIdkGH9waHoNZ4Hwpn34NogrN2vzh3rJV38+GHEvx29P54CACHif 134ftVwamHKSmIgq94Z8yIK5woZRFmdt6DFVBhx+gIqpCCSzRlxXlv9ltGSGGFGJteEMNeAMtViL IBQju5hKOKWGpFiKq0MbeUiMqUiMNZCH/RGLmPVeiLSMd6cYt0gQ0miL1UiNjjOKFZFK2vg9vwiM coaKyIiMxWgRyQhoICFcQPWMRrgYuGgR0niL8ZiLSrONGsGGayiK33hzqjiOBBGO4qiP6xODF0GN 81iQ75iL8+gxvSgjDXlgDTmK2RiQlfWPGJGMFTmRsSNuBDmNFYGL1+iOtqiQ9PiQE6SGvuiNGQlU 4XiR/giQ/aiSWyEPM0kQ8lADNvkfevc6IfmO1liNPSmSI6kuEhlnjoWSvyiRMYkV/LAYTFkRTqkY 5qiKFWmM4miORAH/lU8JEllJEFwJQjRZkzeJkziJHXt3SAnpkwkZj9NokB0plLhykty4jaG4hgdW j0p5FV5ZA1Cplx2RlX3JFVJZjFfpklnhlYB5EYfZlYhkkzMJlhXhmNfxbR7ZkT/pk0HpkQrJk8HS jUcJkUaJTbwImni5lBnBl1Xxl7Lxj+Qolf5ImKiJEYhpEYo5Q49ZkzTZmBbhmGRJGlbFN/DIkUGJ lgZZkG95KZ3ZiyjpkH4EkctJmkPBlPwgnV0pndVZnXs5nVo5m9t5movZnXsJnospnrN5nXl4ndR5 ntbpnU5pnYp5ntiZneHZnt4Jn0+pnvUZm+n5ntHJnrKpFY2Jmzcp/6CRGaC5WRv6lwDyiJZsCZxu +ZPuaJyAkpIYoZxF6Y1J+Zx+2Z0b+p1cmZodGp4hGp3aGaIwiYz84AdOmaIpCpDu+Z0lSp1amZrg OaP8KaPcSaLjqaP9GaMw2hUACpliuZsAapu22Zv79ZvyKJLWCKFu+ZGbCYp1SaH42I0ZcZcZupXb KaI7qhEzSqNfSp8jGqYl2pJduaJWiaLh6J5aup7T+aFaKqbiGadgSp9dmphwSqL+WRUFKpa6CaRC mpu8qRhs5KQKCpJL2pbEuaC3wotyGZf3eKW7iKXQiadyyqZ3mqdfepojuql06przmaLSiYpMmYz9 eZ1e6qNv+pQzyf8P8lCjJTqnphqbmGqp46mnQzGWfhqggCqgfbqrvblWI3mNwamWD4qoUBookPqQ vqiNoWmUETmplKqdG3qpOfqmccqpW5qtFWGeaMqPKKqqdcqltPqljcmUrrqXZMmesMqu1eqhlbql aoGbf2qkt0mkgSqoicF7H8mgC6qo/GqolXmcnWmXZ9WodkmhGBqtl7qutWqr1kqr76qj8bqYK2qe 4EqMGBujfBmr9jmrN0qT5xqdjpmdHcux8dqwEEuxTLmOGZGrGBGoYUmWMdsfmnmQa6mghQqcyKoo +ehHBBuX+CilC8sRXlqy7Wm07pqjFPuweeqmF4uiJ+qm6Omp9Un/m11pk+qZteiJrp4qq7Jqq/oZ nyDasi4bmTLrq0F6rzSLHYvKlpQZsEtKmZaZrM2anMs6lwhbkkTbFbKJqsPoksfIrYJ7q0QhqLsJ qGebpbkyrwMqpEE6oEM6s2FJG/AYoQ76tv06rJcrJJLqkD5rpc3Kt1uJtKVruqeLuqmruqvLuq3r uq8Lu7HLuovBp46bto9ZpPkajRD6pE6KmZn7oDjLqFVqt577ufcotKPLFYX7H2VqjFDLvCAxpI87 li+rofF5K0TquAZKoGx7u706G4uKs2pJnJkrlJzrIdA6tCZ5EXGWh+9AmAqrvH5zjK9Ju2CJuJTb veCrNdpbvYp7/5vgm799Wrlt2ZPCixENKrfoCyT16LP52KiDuYv2O78qWb0B/LgE7Di7aqTzqrhA 2r3WSxrkK7fGepkGXL5RKrTEu6zcyB6DyY8VrJQGqrYXkb/16jH42qsizJsfjL/8KxvCe6ghqaR0 K7AMnL5USqXM6pzwC5DvW5UybMEEPL24q7a6m8Npa6/827gBPLlAnBi8C7c3S7e9u5ZG3LMQ/Kxr DL8wjFPhKL9STIoECsYADLlJw70avL80nKv4O8DtKL46m7O/a7klDJcVarcO6QfwCyOLTIxtTMFy rI9r68EyK8Iu88M9XMl6bLt+WrlMqqTjG8iY2aTNEoqee8ptrP/KF/kegivJGXm2/+urfYzF89LF 24u2kBnLHFzLYbyZRZwRgzy3aDyw7avE3fi845iNkfzKvWfFNuy/sCO52qubXozBPtzLXGGzJiyc oIzCSNwldKmcy2mMjKzM3NrMAXm4AmzDGKw0N6zL9jq58EzN14HApWy+wIzApuyoodmsyWiw/IiR 6TzHN3zBiQvGeOyyOyzP96rBnRy+mHus5hvM+GzKz+qsoTmVrdnGg0vQwFjJ8/zQG0y5kGu9dIzS dvzJolysRwy3TOoRNJy+4iy6DfnIkPyS6PzRbZjNndzTonu3XZKvmjyzPXzH1QwcRTycCWy544vG XzzSCfKoLtz/yKjIyE7MkhfJzDstY0VqyRkMEsw6oX/Cw/Rq0n8a1Z9srADboE+awhtBx0ySlKLZ yovsxOPYkgPN1R1BPukEwrmb0BxxkhfKJI1L1DpMz2ltG8IKvEu9z2YLszisEf5QA5RNGkXZz1E8 uHm91x5xOjxVRfX8vzJtj8WLsKNZ2CGMxSJdw/4RygksnDw5rFc8y1bhD5ZN2Za9GMpq0+Sc050N EuOCOoxZ21XcERDsrMjLnB2CuIbdx1u8zj+92LN9xkT8EUOt2ARx25Wd25VdGxb6xq6p18Dt2Rkz bBK1y4FtEQ6MnJBqvMzNvX6c0pb8x67drwvM1DFtu8bNEdut/93d3SFajdfkzdfD9krrchCE8aP1 LNgWWpeo7cBBgt2/+twmHSSy7buzvdCyDMS9jNvezd0eotVbTeCskWkHgOIVcQCXkuAIcSX+YbBN nMgFCySkXduRy86y8Qc7XgN/UBXFeZnXzcc7jNYYkdvb/eElPi8ZsxorbhQpvuIrXgNS3iUJruAE 4eLAIZrMeZegCyhGrcV5LN1X4eM9XhFlDhJtjasxe9DZfdtJ7t26reS50k0HcAdRPuV4fhFU3iEu 3uJY/uJajrySitzIKdReXdTxPOZWweME4eOPbua14dwlLdkWgeTaHedzHiy1ghQonuJTnueg/ul8 DiB/7udXLv/op2zM2Ujoe1vYlO7VpFHmOw7pkI4d1NzcHl4Rb57pmr7psuLpdq7iUU7sQoIQB4Hs FvHnqV4DCPAeCNDsyavqefvq0U3fioHmkc7j2d7j3C4bh+3Okx3ili7nvq4oUAHlxS7qBMHnn54g Vn7sWY4dBNvs74AA9+7sy8nqyi0kiY7Li+Ht3Y4RtH4drF3pRn7kmG7uwRLswr7uKr7uUN7nyZ7l x87szj6Kzg7t0CrWLnwptQvwtP7o2+7ojd7tAU8aFT4UCe/ft7voC28bnj7ldy7z7J7npC7x/hHv F1HxtgEjG9/s+A7t0G6SmN2czilRIl/yA2/rKJ/y/L3y3K3/2ygN84FC7O1O5Q0v86R+HfCO7D1/ Hfhu72uo8UO/8VsetHKm9CdvEU5Pu9m9pxte9UzC9Xju7jav7v9h8Vfy9aj+3fUu9GVv9tGOlF6e 9ALv6Es/8kpv8v4Szbw69/+h9XoO8TUf6jXP9bVh6gou71oe9ET/7IAf9O8dx4ef+Gd+Edve+Ovi xy4f+QCy9Q0f8Xif9TZf6lhe8VZuG/f+8xhPEPn+86KvrFd6VCR/8saP+ph8yer9+jGv7lkv5aM+ 6hCv9zvfH0Nf7/au8Til8Z//mTReWQRv5gSv+qnv9oFi4zfe/Nhh93oe+8Ve93d/+/4h9L1v7z+v /ffv4O1b3PoztPgA8UdgjT81DBIcWJDgwoMNHT6EGFHixInyasizeFHjRYwGMWakGFLkSJIlTZ5E mVLlSoMHXD582fCAw5czWd7EuRKBQQQ9dyJ41zPoz6HvjNZ4d9Bo0pxNnY5MOLBhQYFRDyp8mvWg Ra4fOXrsqlXsWLJlzc60ibZmTLY1Yh60aVZuyZ87eR71WbeGUKZIkx6dG/ikQsIMF1Y1iFWqYJYf M3YFyVjyZMpj1aZl2xYt3LhuO1cWXPfnXqI99w7d2ZdpX9Ctr1LFGrGwa5QgH4N9HJn2bt4QAwIA Ow== ------=_NextPart_000_000C_01C71DEA.D23B4180-- From Macromedia@goorin.com Tue Dec 12 06:44:43 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gu63v-0003kP-OH for ips-archive@lists.ietf.org; Tue, 12 Dec 2006 06:44:43 -0500 Received: from host145-130-dynamic.3-87-r.retail.telecomitalia.it ([87.3.130.145]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gu63n-0004RF-V7 for ips-archive@lists.ietf.org; Tue, 12 Dec 2006 06:44:43 -0500 Received: from TMBB (unknown [145.193.165.194]) by goorin.com with ESMTP id 7C9BFAD7CCB4 for ; Tue, 12 Dec 2006 12:45:01 +0100 (GMT) Message-ID: <000b01c71de2$e04c2710$00000000@talete87b14dae> From: "exams" To: ips-archive@lists.ietf.org Subject: seems person Date: Tue, 12 Dec 2006 12:44:26 +0100 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0007_01C71DEB.42108F10" 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: 3.6 (+++) X-Scan-Signature: 311e798ce51dbeacf5cdfcc8e9fda21b ------=_NextPart_000_0007_01C71DEB.42108F10 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0008_01C71DEB.42108F10" ------=_NextPart_001_0008_01C71DEB.42108F10 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Prior kits, published, convoys brooklyn, miles ambrose, yacht boats? = Post small trailer, movies couples couple. Metaphor torture meted greg = marmalard omega mandy, pepperidge douglas. Kawasaki emission catalyser means drunken. Ishmael irma, ira ipx ips = intel chantal. Oreo cookies instead jaffa cakes grizzlies bears part = limpet. Hva het musikerne, og hvilket instrument spilte. Intercom, = addition dbm interface connection connector ptt. Repairs brands joints been plagued printed. Access study acid sodium = salt. Degrees ad diazepam frr. Cyber cybersex dancers volcano levitz gameday. Ive railroad dell baa blogid. Jo ann mcmahan sandy, lebroque piano cab = cutie. Laman ini ada, cerita. Launched, naomi, specialty expanded ar get = ratings amp maps! Very aggresive chihauhuas shitzu lhasas havanese poo. Convoys, brooklyn miles, ambrose yacht. Cateogry vehicles transport assy = swem contains? Dallas us nine followed, bands darth vato vanessa pittard. Wcw theme worldmate jar george strait cbaby thong, legs. Dominance = vocabulary, punnett genetic genome activities thinkquest. ------=_NextPart_001_0008_01C71DEB.42108F10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
3D""
Prior kits, published, convoys = brooklyn, miles=20 ambrose, yacht boats? Post small trailer, movies couples couple. = Metaphor=20 torture meted greg marmalard omega mandy, pepperidge = douglas.
Kawasaki emission catalyser means = drunken. Ishmael=20 irma, ira ipx ips intel chantal. Oreo cookies instead jaffa cakes = grizzlies=20 bears part limpet. Hva het musikerne, og hvilket instrument spilte. = Intercom,=20 addition dbm interface connection connector ptt.
Repairs brands joints been plagued = printed. Access=20 study acid sodium salt.
Degrees ad diazepam frr.
Cyber cybersex dancers volcano levitz = gameday.
Ive railroad dell baa blogid. Jo ann = mcmahan sandy,=20 lebroque piano cab cutie.
Laman ini ada, cerita. Launched, naomi, = specialty=20 expanded ar get ratings amp maps!
Very aggresive chihauhuas shitzu lhasas = havanese poo.
Convoys, brooklyn miles, ambrose yacht. = Cateogry=20 vehicles transport assy swem contains?
Dallas us nine followed, bands darth = vato vanessa pittard.
Wcw theme worldmate jar george strait = cbaby thong,=20 legs. Dominance vocabulary, punnett genetic genome activities=20 thinkquest.
------=_NextPart_001_0008_01C71DEB.42108F10-- ------=_NextPart_000_0007_01C71DEB.42108F10 Content-Type: image/gif; name="dunno dupa.gif" Content-Transfer-Encoding: base64 Content-ID: <000601c71de2$e04c2710$00000000@talete87b14dae> R0lGODlhnAF8AYcJAA4FAoUIAACBDX52BgAAiYkAggB8iLO+yLbVu6PH60MVAF8RAIUWB5QSAMkh DN4bBwBADSQxAEZJAVs3AIsxAKpCAsVHB+M1BQBVABZmDjlSDF5ZAI1XC6hhA8xSAuJeAACKABSO AElzBFRzAIaHAJl8Ds52AOiGAACYBSisADqkB1mpDIWhAJOnAMKeANegAACxCSayB0XAAFO3CnjO C6y7ALnCAti7AAThBhzmADLVAGTiCHbsAKvuBcbWCNjaAAAIMyUJRjcEQmUARIQIP54ANbMATdEK OAYbTRkjOU4WOWwnSYwgPqkoMcAaRNUkMgAxMyw8RktCSVE0O4ZOQ5s1O8pGSO4+QgdkNBNcS0BS SWxeSohlCp5SPbFSMuNUPwB0TRWGPz6LMVp9Nn+IP62BSM51Td+EPgCrTSSaTkagR1+lTnycPJma QLaePNKTQg7EQi3NRUjKRGHEMne4SqTMS8O2TOzOPADeRhjePTfSNmvTPnvnManXNb/kOtXZPwMN fScGeUcAg1EKgY0AjqoLjbsOc9ULfAAWeR8SiDErhmImh4Umi6MniMstct8niABBey08eUo7g2s7 dIdGeZJCiLY9cto/jABShiFnijZujGNuh3FgcptgdMFnhdFkgACLfi1/dTp0f2mGc46Cd6qMeLVx ctV9igigehWtdUuWhFmZho6Zi6uRiMaogeaueAXHiRrMfkK1elq+goKxdJfMhbq0cebBhQPbdSLX g07Xd2Tte4Hjcp3Wgr7RftLidQAMuyQAuj0JsmQMzIAAzJgAxMELtukAwgARtSwbtE4qzFMRyncS uZwcvr8ozuUnsgBGwik+tz8+w1EyunE+s59Cv7Y8tudIuwVaxyhuzUZotW1Ssn1ptaNtxrNrzelS wQCBwS15tzp/uF52tIh1uqqHxbGCwOaCwACrximlvzmsym6rvIqWzpyex8igwdKczgC+wCHAyjK+ yVTMzICxvqe2xPH89JynpIuKcfoABQv3Bf//AAUA//4N/wD////9/iH5BACPvMEALAAAAACcAXwB Bwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3MjRoL2PIEOKHEmypMmTKFOqXMmypcuX MGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0aMiOSJMqXcq0qdOnUKNCNUq1qtWrWLNq3cq1q9evYMOK 1Sq1rNmzaNOqXcu2rdu3cOPKnUsX4di7ePPq3Ru2rt+/gAMLnsu3sOHDiBPDHMy4sePHkCcqnky5 suXLmDNr3sz5ZOTPoEOLrtu5tOnTqD+OXs26tWulqWPLnk27tu3buGm+3s27t++DuYMLH77zt/Hj yD8TX868+crk0KNLn069uvXr2LNr3+7Quffv3rmL/x9PXiD48+hzl1/Pvnr69/Djy59PP6vDD/gL 4v/wb7///f3lp5+AB/3HX3sIJkjRSvuJ1GCDJEEYkoQO4vcRhfVlKN99BAoEIIAFduihiCMeWKKC KKaoEIMWTmghhiDBKGOLLn6g4Y04VmhjjfbAeCGNMQL544485mikhgb+12OSLwq5JJFBQjnkkVTS h+GDTk6p40gzSlnll7ZxaOKJIBpU5kBnnjjgmCq2iSKLUmLppZZF1hklmHjeJuaaAbKJJolpqimo m4QmCOeWPj7JZZaKNprno7PtSdCHTPLHZJ//TZppoZwaCumnoIYq6qiklmqqTp2mqmpbp7Ya6qqw xv8q66y01mrrrbjmqut6rvbq66/ABivssMQWayxVuyarLEHHNuvss9BGK+201FZ72rLYZqvtttx2 6y151oYr7rjkHvXtueimq+667Lbr7rvwxiuvb+XWq9m8+FJn776W5esvdPwGLPDAosa7ycH/rnfw wpsItHBBDzP8MMQMDyRxw/9crDHCBFXcMccUe2yQyA5HvHHDJE88ccYSI6TxyC1bDPLKJm/McswM XVwyxjLzvHPIJH8c88k8r1yeyggbffPSN/vMNNNKGx301CD3/DPMVTf9NNBFc4w0xkpfLbXXM5fd NcpZW621Ql9v7XbUZGdNc9JpCz0dSwuHdLA9eev/vXfffO/t9yYfAR64SIZLDJLiizM8uN8kMR54 3oYPLvjkhf99+eEjAd534pd/LrjohEce+uadb6556Y2zPrnqp7te+eonVS6bQ2FfbfXcTrfNdtU4 49y0z7ljbTbdTvfse80N8e421Mgjr3vIah9UPNzEp2x29Vj/nvx218st/fTQf2+38tEDj/b5C+ns ft1Lx919ztuH3Tbd5bu8vf7mY/8xy+xzHv+8dzeV2C5zJ8OcAh+HQNS17nGaWyDlYHfAB0ZwghvD HAZNV0EEWtCBpDsc7V53MQV2cIGII9oHWRfCB5ZEhR4ETwVntzrHpc51JLwhBB3nuRFaDocrpN0M /0dHuA5KLoWlayEDcyi5IR6Rgy9EXQ+LGDsbupCJDlwibXAHP/8xb35gnN7yjle85+Uvfl2MWxm5 h779BbBiwUsj2szHRjbyTmRftOP4BiidlTgRiSYEYRZRiMIWKvGPOgwkFYEYwxyi5ICQFCQLeWhF RJ4QkS6cYgxBh8MNmuSEwwEdIT1pxU3KTooUhKIEiajFK+6Qkau0XSoTSctCTnGSsCQdLBspQlQm MXamnKUHQfkeG3pyha075S+XWctI/jKFwYwiI48JyGQmEpPXlKQrMVlKJDKThs+EXCyVicxPDhI1 EdHZ2/a4tqEJj3u5y6PY3sk+uxFta0HbWRnXqP9O6onxZPjkpzt7x040Zk99A30Z+ZBDsIbqJWEQ pZdDJyqWiFr0ohh1F0U3+pWMehQ0HA2pSEcanwGY9KQgOalJRYLSkLSUpSpNqUoHgJOX2qOlM4Up TUky05XetKcmsSlJEQORkwrEqEc1qUGQOhCmFoSpSHWqRZwKVaU+1apXHUBTlRpVqSZVqx+VqEps 6tOf7lSmZC2rTj+S1rGeNag+TetbzapWs8LUrmytK13nOtTNCHWtLo0pWkuCU726NSWFfatQczpY wpb1r4zt62Ec4lWCSJWrYP0qQrqa2aJ2drNWpSpWk/qP0VZWs6i1rFZHG9bpnDa1pcVsZk9b1df/ HoS1oCWtajtr1NomhLNLlW1rq2Nb0a4Wq7Rl7UwV0lOV/na5u42ub78qW+cG97ifHW5yimvanm41 u7CNLkNwe1vofne31o3tZ3sr3OumV7urWclfA3vWlybWsXzNa35HYlieQvaxAN7pYld6X/o2VrJ8 eYhoz5ta4JYXrN0Fb3Ap69XpqpfBmuUsb5FLXvj+xroWVi6EO+xg26qWwrit6lXFe+Hazna9Evbw Y1wCVP0SuK4oba6ABVvjneg1pwNWbI3lStMgIzjBMk4yXI7MZJ4o+clQjrJ7mkzlm0j5yljOsmtk AwAAVPlREekyQbpMZoyIeSBkPrNF1DxmALS5/8wCSbObDyLnOMt5zlr+DUvSDJIu99nLJfGzSfj8 EUHbw9AwuXOhyfznRhsa0Yt2NKC/fC2IqPnSeDYImxGCaTRnOsxwLsimPf2PTosaz2IedZ65Y+pS f7rNDGm1qu886jTT+dV2djWpT03qO6/aOC559KQhfWhaD3rYyJ4Jo0dC7GJH+tkhETazJ03pzIB6 17rmNK55netuV8TWsH7zm0M97lpv+9fxbYm0oT3tlKzb2dNWNEn8jOh6U7vdJyF2s6s9m3fvG975 Tja7E+1lezf62AePNqDfzW/ayFvOyoZ4sZcdE3lPnNHGvrjC/2xvijf8MshRNbpXxeV7f/xGI/9P ucpXzvKWk+bkMA/Ov2Men4fU2c7klsjNXZ3ziWx659gGerlxDm6XhxzVbm61ps/daaXrvM5Kh7PT s61rkRsdpC+ht8DnbfJAF3zrWfe4SIQtaIZDW+s0l/nXE45vd6994Iu2OMe7/my0A1zfyZZ72ol6 baqb29cJOfPULS1ywc/Z8NgO+qutfnXGqNvfdAe417c+c5UQOu5zX7be4y52ye/dMDb/9OC9fWtu U73cPc814rVdeoWYu/HHeT3pTb/02s/+6VU/9+m9LfvRw741tCa67hcSfJ4zPtY3L77i2Yxp5hf9 9+86PvR5FZvKfx4808++9l1+/e57v9pH3z7/rXYudFCHuvy4H3q4ha9tqQNe/KxpOtIDz/T5+74h vjZ10acuf/hDhuB3F3nWF2lm93j/ZnBnZ3LSNoDfhxl253kbZ3lvB4EXd3lzh3AJV4ALKHENuBmE poEZF28LB3Zhp4BiB3lth3cdWBoPeICRN3YTyIDH1mwIyHk0yIFst4KZ0YIC+IIbV4AV2HkEaIIR 2HZeZ4Q6WFH4Z3/zx3pOmHuJ53NJN4WJN2tNGG7353+PQX7P93Tn14Xm94Vi6H7O52nOl3paSBjV 54NJKFIy2IZwGIeTlYYqJ4dNRod4mId6uIf+kg9+6IcF8YeASBCCmA+EaIgKUYh/aBCFOBCK/xiI jXiIgiiJkGiIk+iIgKiIkbiImIiIfIgULPGH9iCIHyGKoliKfjiKqaiKKXGKqriKIOGKpyiLq0iL +YCKt4iLImGKpKiLIeGKsQiLr2iHXsGLuTiMwziLx2gSwIiMvgiMtSiM0biMyriMydiLzuiLvyiN wkiMWWGMwZiL4NiNJdGMzliNJGGO2hiO2XiNvdiM5giN5OiNVgGOz5iKvKgS8QiL6DgS6tiO7riL +DiQ6wiQ8miN9FgVpGiLuliIrziPBsmPEnmQ5UiO9siO49iN+0iNEJmQMTERnMiJ/yCSjViSg1iJ jHiSIikQm3iSKImSKzmSmTiIM+mJLOmSN/9pkzH5iWhBkiqJk5gok5YIlEKZkp64kzlZlAexk4sY k01Jk5HYiUZJiTzZES5BkQUZjAHpjxbJkQjZkBC5ke14kQ65jQiJlR5pExDhlD9pk0FZlEjJljoJ lVS5klA5l4gol0oplDiJlFU5FSuhjhcpkGD5lbZojf14mNrYj4s5jWaJmF3plWlpZQ6hiXdJlDIp iZhpmUZ5mUD5iJr5maC5l3z5klSZlH+5EZM5Uql5Zav5mrBZMK0ZZbG5UbN5m7iZm7q5m7zZm775 m+dSm8I5nEcCnK1FnA1lnGGFnASjnM75nNzBnNI5ndRZnUEBnRhlndq5nXqCnRbFneTineL/OZ7H AZ7meZ6dgRT8IBfruRTtSZ6g8Z4UIZ8aQZ8dYZ8GgZ/wCRf6+RD9WRH/iREB+g8Dup9JwQ8IKhAI mqAKuqAE4aAMSqARCqERKqETyqAL2p7vuZ4aiqEE+qAO+qEduqEQOhAjaqENWqAGChwuwQ/24KIf 4aIw+qIhAaM2SqMxiqM5KhIzKqMg4aM52qM6GqQzuqM0iqBGCqRH+qNDKqToORQZqqNKWqQ3uqRE yqQ8yqRCuqVaGqMLOqRJKqVdGqRjmqRF+qQv4RAb+qEKyqZuyqYa6qYk+qZt2qZreqcmKqJ5ap94 Wqd6aqd7+qAFUaEr+hArwaVkaqQ4eqNO/5qoNVqmUyqmkXqmkoqlVnqpSgqmmoqmORGlThqlWFql X/qiSOqlNTqqpGqjqOqpXoqklAqqVFqqqaqqpTqqriqrnKoZlJqlNrGrucoVapqhwjqsxFqsxnqs yJqsyrqszKqshRoRvxqt0tpvbBhsb4gXQigU16oV2WotELdvDziD4EqCXDeEXLGtRQiAGBiuOYGD RYiuoBJ68rqEyBeFrSd9ZYGvS8F4q6cU0peF7tJ77pdtXfh3h1dmYIiFVGh8ZphqZLh44BaxD0t0 DUuxhnexzXewrqexGNuwU9ixtEexDJuw27ISKviDa+eCZTeCASiBKwuD8KZ1RBiBMlt3Mf/IsjXo bC/7siiLEh94b3ZXszALgzzLg+Nyst+aspUXtDfrsixbgTE7gVBLs02rs8jGZxSXtW/HtDZIgQpX tFiLs9Tmrj1rtTkYLA7xeojnsGZIfwS7sLvXfhw7t6rXhD9Ht93GtrfHc22rt367sHpLf2uLt4Hb r7U3uPaKL3f7tlCYuHX7uKRXeEwIuYWrsQrrd3jLuFVIhYjbuH/7hJ/buZpbeqJbhopraxjLuR8L sWMYuYa7fqnLfmd4twNbsacnsSCbu5YLdZZre2/7sHBrfKK3f7WLc3srfvpKr4QXGclbr/k6fLpS GfBKtNU6tIcxvV9bve2qvdPavZT5rFn/1rx9B77iwbus17yv22vQS3hoKIXEl7n72rtOgX5Jlrzi m7fbdr/OaxbpG7/HixT6Gy8mO7M/G7UzB7Y7u7VfR7bWm71dy3kQvLKQlsAQ3LU/a32Xd8Fk97QH bIISnMHd+iwnK2lm67TthnYUzK4NbLNR28KaJ7XUO3Bc23kY3HVcS7U1DLZmO8Hc+yrKq7AIq7rr S7xB7LmqG7ewhrrmm3tKrL6Cu7tN3Ljs975Dt3pcuLyI+7ftG7AQy7iVO3wS+7ihe8RuC7m7Fri8 F7yn1rljfMZgXLttjLlYTLds278lO8Awm8Jj+7QpKLYljMIKXK5/HMgUbK4YOMguLHA8/0u1iWzI H3y2ZQvIiOy1pcK+WlzHq+u4s0vG5vu5tzaxmhvG+GuFbgy8tyvKlyu8oRzF6cuFWXywxYtlAXwR sxwX+lrLFIHLabu+2qXL7gsaJOu7UeHL+0u+xnzMrUnM6YfMybHFs6fMG5sd0MyHzozETzHNzMvL vHnJpvy7sGyFsTvFHpuxIguGyoe737x0rpzODPu/VblnhKy05lrILtjInifJCczBQCvP+czCPTvD OkzJ9Civr+zFq+vJVUy4wwuFpSt0mGzQ48xrDy3FgIfNeBh8D13QqezGEL17GZ25VvfRZhzSR9zQ wnybeDzP8rzDfnzPLX3DJAzQB8fDLP9tyC38z/E80z0snBvI0i9cwYuceTftrpKscZJngSoN1Hus gkwb1CDsvVAd1VI91VRd1UXBzFid1VqdZ1bd1V79kVsdnF891mTtGWH9LWV9Kme91mzd1hGV1qbi 1nI913StLnBdyXWtLHdNKnnd13S914Ad2II92Jzq17tC2IgN2MPKo7j6o4vN2KDq2LHa2JBd2ZJN rJcd2ZktrJKd2K2K2a1KEqD92Y+dqpeNEqga2psd2cYK2aOd2lQdERlqohfanyEKorVN2yM6oLed oritELc927oN3IS61S0B26Ta2SUB28gtq7ZK2aLd2KmN3Kc62dV9EtQd1RDR2wfB3b///d0JQaEq yt297d3gjaLDHd7FbdjmPajr7dvpTdzCGqz0Wd7vDd/4jd4I0d59zd/xnZ8V6t8pKuC4XawFPt// bd/Eet5hzRLZfd3LjasPntnHfazVXdqmrdqrLeHQvdcTruEjMd0dfuEjHuLSzeG+StrNXeIfPq3+ ed//7d7ySeAL3hDkHeAwXuMyLt+GDeC8fd8KzhDiTd87HuM7LtwMXuQ9rtsByt8K3uQYCuMxHuTq vdtK3t1SXtfendv7TahbTqJWvhA3PuM5zuVGvuRCjuTBDeReruZmTuNtTub/SeX5bdgt2toq/qWj PaulLeIpDuIZnueriuI9iueBXtUT0DGsMq7oOs7kcV7gPH7exzrlITrpdW7cng0maO4tzdrpnv7p oB7qoX7Wma7pm14rpf4lp47qqd7q3LnqtOLqxQnrtL6ism4ktR4rt77r0pnrsMLrwD6cvk5ywV7s xn7syB4tw64qyV5zy94pzR7tcfjs0C7t6EHtnGLt2r7t3N7t84HtheLt4j7u0Q7uhELuy2Hu6p6b 6E4c6/7u8B7v8o4u7T4c837v+J7v+r7v/N7v/v7vfFjvwgHw2iHwBn/wCJ/wCr/wDN/wDl8aBJ8d AQEAOw== ------=_NextPart_000_0007_01C71DEB.42108F10-- From ReportAP@apinfonet.com.br Tue Dec 12 07:28:51 2006 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gu6kd-0005Vh-0D for ips-archive@lists.ietf.org; Tue, 12 Dec 2006 07:28:51 -0500 Received: from [125.17.123.131] (helo=dsl-kk-dynamic-131.123.17.125.airtelbroadband.in) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Gu6kT-0000lY-P7 for ips-archive@lists.ietf.org; Tue, 12 Dec 2006 07:28:50 -0500 Received: from iiKYhn (unknown [153.133.191.157]) by apinfonet.com.br with ESMTP id 0583B99F2124 for ; Tue, 12 Dec 2006 17:59:13 +05-30 Message-ID: <000701c71de9$0dae4a20$00000000@office> From: "at top" To: ips-archive@lists.ietf.org Subject: Add key Date: Tue, 12 Dec 2006 17:58:39 +05-30 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0003_01C71E17.27668620" 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: 1.6 (+) X-Scan-Signature: fc33afc280b74ce7916a8c9e6ab57db8 ------=_NextPart_000_0003_01C71E17.27668620 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0004_01C71E17.27668620" ------=_NextPart_001_0004_01C71E17.27668620 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Holiday photos photo galleries pictures, uso washington. Than one meaning if on modeling make! Supporting troops whats come geminids. Same period changed which strouse offered several. Audio amp interviews = heard wtop browse archives, listen online. Super doppler mapva, lane, pagesprawl crawl sponsor. Define any english = news topic yellow listings digit zip. Terrorism, leaves united nations = dec music ears tis season. Weekly basis, gjarboe uarrtop guest, micro, persuasion. Publish dozens = computer magazines painfully aware. Board, chairman, gerry, connolly. Adu, bids signs year deal orioles hester makes history. Type plus, front each want see about. Optimizing, engines, since ndashso = irsquom surprised! Hospital sensible geico pentagon arinc am weekend. Zealand kayaking, biking word, orderto an. By default returns only pages = that include all, the. Link, url, document our index indexed urls titles, copy. About latest = thing exclude minus. Family house, fireborder agents alligator stories sportspens outshoot = caps. Cloud home services release weblog. Today handyman science, = tuesday, partly, cloudy. Auction week chance bid! Their religious message, daily adds layer filtering little. Co board = chairman, gerry connolly amquick cbs dailyboot campchip. Cracking down = drug violence nobel laureate poverty. Discovery, docks space station = panel. ------=_NextPart_001_0004_01C71E17.27668620 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
3D"removes"
Holiday photos photo galleries = pictures, uso washington.
Than one meaning if on modeling = make!
Supporting troops whats come = geminids.
Same period changed which strouse = offered several.=20 Audio amp interviews heard wtop browse archives, listen = online.
Super doppler mapva, lane, pagesprawl = crawl=20 sponsor. Define any english news topic yellow listings digit zip. = Terrorism,=20 leaves united nations dec music ears tis season.
Weekly basis, gjarboe uarrtop guest, = micro,=20 persuasion. Publish dozens computer magazines painfully = aware.
Board, chairman, gerry, = connolly.
Adu, bids signs year deal orioles = hester makes history.
Type plus, front each want see about. = Optimizing,=20 engines, since ndashso irsquom surprised! Hospital sensible geico = pentagon arinc=20 am weekend.
Zealand kayaking, biking word, orderto = an. By=20 default returns only pages that include all, the.
Link, url, document our index indexed = urls titles,=20 copy. About latest thing exclude minus.
Family house, fireborder agents = alligator stories=20 sportspens outshoot caps. Cloud home services release weblog. Today = handyman=20 science, tuesday, partly, cloudy.
Auction week chance bid!
Their religious message, daily adds = layer filtering=20 little. Co board chairman, gerry connolly amquick cbs dailyboot = campchip.=20 Cracking down drug violence nobel laureate poverty. Discovery, docks = space=20 station panel.
------=_NextPart_001_0004_01C71E17.27668620-- ------=_NextPart_000_0003_01C71E17.27668620 Content-Type: image/gif; name="sector usedpress.gif" Content-Transfer-Encoding: base64 Content-ID: <000201c71de9$0dae4a20$00000000@office> R0lGODlhDAIMAoewAAAFBYgEAAJ8C42LBAABhIYAjQB1dsvMzMfnzqe/4TsnAFMbAHQrC6sYC7cp AOEiAAU5BRFAAD1JAF48AH9JCKNIDcxKANk/BQ1tACVfDjNsDG1sCXVnAKZqCLlmAOpsAACJAyKE AD2MBmJ3AIJ1AKCACLV0AOd2CQCcAB6TB0CbAFeeAIqkAJaVCMiRC+SaAADAABu8ADHGC1XCAIG+ AaXCA7S5ANbMBgfrACPbADrVAGrrB3HtCabgALjaBNHpAAAANBYASjYAS2kANIEJPZsDPcsATNwA RQgXSRETSTosSFIoNoIXM5wsSrYsSOMoRgFKTRVNQzFONGM1N3U7Tag5SbM6RN82Sg1mNiVtTURU RmVXSHJhAKVsPrhuSdljQQBxSh98Q0Z5M2R/P4F8NZqIPsSJPeaGOQCpPSilQjqqP2qkPIaZOKiZ OsakSeahOwvCTSO5PDqxSF64PXK7TqDNQsnBR+rOMwDqSyvgSzPXQWHhPnPgNKLTPcLtR+vkOAAA fh0He0EAdGgAd3UAjK4EhcYAfOcKeQAYgSkbhzoRh1MddHIhd6IUdbYtiOUdiwA7fRFKfkROcW1A iI5Ejag3crtGdu1EdAxegilWeUhWiGhee3tmepdWcbRsgOBkggB1gxKKhTSOjGN9iIaDe5aBd7qI i9pxcQCZeSWbfz6hfVydiYikeaadcc6WfOacegDKeiXAhUDNcVW1iILMfKvBg8XBjt2/ggPeiSXs iDjSiGngd4HSdJnhfbbajtrhigAHsyEAuD4AwlkHuIIAuZEAt8cAu9gBxwAbtCQsvzIqymITsYAV v5EatswWud4qygMzwxE/zDVHuWZKwXs6sZpKy8tMvug8ygVdwhZkwDlYwl1dyIRZxpZlw8RSse5h yAB8wBOJwT52vWJ+tox5zpGEtbt3xNyBwwCmsiCUyUiouGemt3ehwpSVyLufzO6btAW3uCG+zEGz ulPIxoW9zZLIw/D/7qKSm36Dfv8AAAn8Cf3/DgAA8fcA9wv/9v7z+SH5BAD///8ALAAAAAAMAgwC Bwj/AGv061dDIMGCBgkqRMiwocOHECNKrEEPIb2LBS9i3EixoseJIEOKHEmypEmR794hVLlSJcuV NVK6hBnzpM2bEucVnKeToc6fPHfyDFrwG8JvRpMabYj0pr+C/p7inEq1qlWEAwtm3brw4NWvHTN+ rEgx7MeyYNOqXfvwZcGXMmvKZUk3Zkq2eIcG7cm3J0K/NYjOW3q0aQ2kiBFDBAoYYVSoUKXinUxZ ZFasDi97rTyRLEOOGsl6bjias+nTE2e+nXlXJlyGblFb5fs3MGOhQBkuJVzUYeLetHPbrvEYMkPJ EhE0VC67uWWFBzU7Bxk6bMayGi2KvY52unfKce2K/6/JenzL2N9L0g48nL3Qv0MPN03am/58n43j 434clX9xiMzVwNyACBQYYHreaabgQJchaJZoDp2F0XbdOWhhVS61FpeGq7l2V0PoXfhQX4vthJtf QSWmIm/y0debezASRdxx/RH3FHIFEYjQgALmeKCIlW2FmUBEMijiRhNWOBZ2Fp0F5JMjuQYibB++ dR5dIUJpom16sRcficF9M1iL9h2mW1J8GfXTcIDpN+OMN0plYI/K1WnnjnVqSVl0XnVl0JOgOTka hKJ5VJqeiFJ5pVt1tdRhoiPmJul6ewnGk2KGKdaimYSJyVh+8/jTpWM2lupQngj0l6qPdhYIaVpd Qf+X2WbTeVaooUgSStqrvDrkoZQdavhhhuHx2qalMd7mG2GD/XbfUYMJxuV7gUUV6kQGukpcqtym WuNTefYKlqwNbkarc4Z+1iSEaNmqnbi8DmuleaplOFeVkMroJaWjorjXb2QCvGK0h4Hp3pc91RhZ jjcyvOO2j93ZI7xUkasVVg16lySFTA4qVmgTbkwxlBvO++iUWMLb16QyftmeTp66pxSmL+5V1Jo+ sfcUT6I6prCBcYLranGqeuvPnD+OTBKDfUZHpIW6dvxuutx15KTSWra2ml34bk3Tq5W+h7OJKE6r V09IwcypQ5e2vdSawYnKc9BQAR3nnEcLmPeNQ+f/PTHWSxeZ0ODnapxddthxpK7V6wKe9XiNei2X yb3iHDbZbMJ3dmBo3rdbYc3uxGx+1dqYMNF6w9nf3Xuv+m2OfzsOEtNGFln4d+xuR/XhTF53qOx6 AkssecVWfjCMXuKm/MGXIjbmi0rdbJua0ra8s2Rx9hhxgUdzuzqP3jIXlcTAS5QxQwtBffjVICcu YXXlQ8ooelhmmW+lK2/e0KdNjSkmp88q2M0uxSXLwUhuQQvfqhg2vqP9h0424lv8Ave026UnUNoR Ga48tqQJWmh4WpucsEa2HviIrYRbQlt9yFQUpSjrf43ZV+lCxR/lNGxo3Eud0cCVtxxuL2ke/FP6 //50pMR9hlDws1q6kBTEC3VNSqqZHMX81Z792Sx/w6FZYTLVLDHFzGwnKiCcUrcwomHPVQt0oJ16 2ESI1C5RHdRdHJukpAq18TuvsdeUlKYs5JkQbmxqG6f8xyJmvU0/CLMcURoWscisjm6P9E+3bHhH Nw5OTxws1Mc81jHEVdJBw+JQ10g4reNRy19jC5i+CiO6ff0Pc8LBnMMaqEYGMsx7erMhuLb1ySER KXuA6g4TuWMrxX2slyQTj/2mmDzNkY10bFOTpzzXwoIB5ZUscxnyuPcH7kXlD3Iy2gK95zrk+O2T 2GPkA4Npx5BFaInWQaY80wPIGCbSZmILWPR28/+2mAUHkYqkEd/UOD5H5tKMDqwbL3sZScg0DGrt upXidLXBeM7zos1Z5T2dubJWymdT9eGnYWKEn30BBpz+ACdxwMnSGoDTbjgs6PfqtMtK8qdUUjGn +ojJOJBVdFcYDWpGmVebkpr0cioy06bmk7blHcukBflDVLuZUqmujqUN7V4EG6g3hdk0p6tTnal2 6jthuiueVBOqWiszKmcS9WXCcVELOwU6N6UQWfOQ6h/2igC+rnSvWOVq9mg5I5p6FZ3YG6M6QxIg bX3FnVJDYnXSutbKTqZsCKsNNM/2k2dFb213vRw+o+oYb6E0pY9EKUvxNqD/ZA+IHkznYH2GI4b/ NNa2sbPK7o4J2bF40irxqEFwLUvcp8YQqslL5ZmUCtpn4o+zPZHqVPe6t6eoloFVBatWIVZD2MbP tRF8E21xa1s0EsixVEFiWSmEKyV+JR7Bha9wh0vcoNaTpMFRHhZ1U82IZLakftkracNLXdRGMI2s cyidxufd8jFSwaTCKUI+QGEKI6DCH9hRhWuw4QlTmMMYDrGHMVyREJtYIya+jokz7JAUP4S+HR5x i1f84RU3hMYdjnF9OaM/fGozhTmbCqVKKV2XIuS0gE2VSq3qQOs2WXwHrSlDHyne44iXORVWTojr tGEdd/nDEMnxh0WzYSSVOcZiBnNB0twQ+QoX/8QZdrOO16zmG4MZww+ZM5x3jBq7fgpuYTuukE3Y EAHrlaV8pa5Lw6doVd1Se98zDjof8tDwFlTLd8Ywlj984UyzWM90ZjGdrVNhkHW4xJ6WcagZUuf5 vjnEcm71nvOsZlDrGdR8zksV9VU9zZ6myKRVLWqlS12VfhOlELQh0MY66ZuOcWGF7VGWO41naoca 05+W9aofguIxX6TMnvmyqNGs7YK4ecR1vnW5yS1qVssa17nOC6Dh6lzZABawULEqspXz0iZTta9U 3ir3FjhlGo3XRpQUEJstPOssN3zd5ZZxtz/gSXGretYQgS+MM0zh+GL84nYet7bV3e54n4bX1P8i NGoOfeTTPgawqL3RS59NS29Be8oIrfSOhAZnbO+Z3KMOtY3hDPEMY4TkDy+5iNuMEPhaPLgktzGb aV3yj5vcNPjbEpCbw3Ijq6o/fOUPzPva126WU3s5FKp/1s7gAU3dwtOmNrsnsnR3txvpQ5/xnN0c jwr3vdbvLjqewxz4ql+dx0Tt48qNjO9iWxXgYbVRgVk30CfXto2Rd+RDu1fTDVO7QCY2kIutHpE5 e7nwP4/4ts3NehtDHfVUJz3IV3/4jN4XQXo9DnX76tIaUTWl4dPq14MvTzM6hJFD85HDp030DG+a 4bSXiOnTjfqpE97wf//AcK0/e1XjGum1r+//vXN/76lS+WhMbthpuVvQeZ7/TWG9IRqXD2a5Ox/b d4e43UPOf+97WuT75xDZ539V933/F3vhF34CxnhH9k1eh2iHNmze40B30GSXh0wPlliONjGe53kK F3dyFyAGmG0FCHtzJ3TbpmfbF2fylWr9p3foBoMvmIDiN1Utd2xhpWTGdge91x938IMV+IM1wIMY SDcOdTeGBXqa5oFERyed9jc4RoK2NnJ193GDN3pt5ndvNoA01nwidnqtBn6mAWw06CCG9hDS9S1n ZGwx5w8ViEMzwoNASIRfpXOmokY8klu4dSfZEkTy5XEYlXsuBWxkWIaL13XEZlW0tXs6OFB3/xB8 UUGEdDhp4WUcRLNGP+JYSIM0y9FghigihxaKRvaJFzJ+gfVN39Ndb/gYdCiHBTGJTaSBtdVAAxcu 5cUqTgg+nkiK6SGIwSaKvGhv0zWIhgZ28LdkL1WBViYZQiiEzbZVmzdTE9Mq4cKJD9MqwViKvlhk C0iI2VgZpjiIxMgQxlYqyOiGrEgcrfiKkwiLDqaG2lVYQpMtmXheOnJb32gh4yeOA2aDo5iPeLGA 4niGxAZ2KVWBg4WO6tgQcziEcuiO3+VaD7YtaAQ70zgnAsKH1LiLADkZ3MiPDOiLHckZBBmSheiQ dwBOQFhlzciOKOmKDSEP8lADM0mT8DKRBv8HOwyGJ32oh31YjSPpHKGYiORoaCcZlGlhimT4kVH1 csrohq7ojA85hAgBkwgxkzJpkzRZk68Sf7L1UBV5jfSYkX+ji0jJdds4lF0Hkkd5ljdBbCFJjN0o YCnJkCh5l1T5innpjFnZl1hZEFzZK8AkkWF5jcn2MNOIiyYRAIzpliZRfg5hlJLJeG3pmDZxhgNG fuQYlXqply25ly55B1j5l6QJmH4pmMdXIzzCmKzZmo3pI05IljfBmmvhmrRZm6/JEK55ErfpELYZ AAXRm8GZmzXwmyJZnI0pVawpYLe5m8I5nMApErbZENOJEK2pm435m9fpnMJJm8/pndoZndT/GZ7i WZ0RsVfT+QfLmZfQmZ20uZKteQfaCZjQOZpXmZVQYoR3iBxJUyCsiZH2mJF5uJjE+RW9eZ1p8Z3u WaAg8ZzQaZ0LOp7lmZu0SZAVipzAiZ4U+poO6qAQ0ZwbGp0HiqAYKqG+yaEkCp7i+aAeOhEdiqIr So7QqaEBoJ7J6YxDyJo/iKByGJ86yoOs2Ze0KZN/SZ9aEo2ocyoX+Z/mlZiFaRMtShUKGqNTsZsR EaUPYaUQGqMRip0iypjxIFVhmpxzCaI1aqMraqYnSqVZSpww6qXtOaFcyqBmGqIlCqdY+qEF2p0M uqULuKB/0IxEWKdyypjy2ZhA2phYGaRa/0mkRXqk6cRYrvKfW9ojlIoAWoqhfKql1ammDUqnIbqn JKqnbFqpI5GpUTql8XCbYSqm3eilaAqopvqipQqnbUqlKuqppmqrndqllZqnt2qrwgqn5KecDJqo wHmoI6qii6qoNOmhpwk8ScOk/tmYykGpKvqgd+qpdqqpfRqsJlqiyzqcEoGlwIqdyDms4bqlqwqm +HZkrUpa4Jmu66mttPqppXqv83qnuzqr7smiogqc57qu/NqvBlupOAqdO8qdPmqoynqfz+mojyo7 B4Kp1nqtjFkn2QqwuNqt4WqeLgqqAmunA1uwElqra8qvqUqe7RoAYQpf96ZxLDevjImmRf+mqweb suCKpxE6pTqbrRv7q+EZsmkqsjsbrgmro+IaAIeKocrqmkT6rIw5mlFrmoFZPtUaAHnCpBhqsXLq rV+rrWD7paNarka7rAfAmgdQA2tLtFf6raSqsqE6sivasncaq2caXI3HsDXLq0brtkfLseTqsx+L oks7p3RLoEXbsWzaorf5kMi6sEzrmg+rtPJwmzMZpDVpn0YaP1t7sV6bkf85tGMrt2QrtmVrtow7 tgt6AGvruqobtyTxmwYbtPClomFqZBUKs4bGt2fqr6sLuDrLs2RLuH5bvL4quCWxqcOrrgbbo4iq tD8apEortcApk3latZ5boszBtUFLqon/q7ymi7IES64Y+rps67pq67rs+7aNC7eyu60By6+326WA tZzSpbdxirfAhrNi677xK7SFirg/O7cm+73S6aZ/W767Kokl+rAPe7hbeblTi71Te5UOMbFYS5vd e7EIHKzjOq7tearze6fsu7a32b7oy8Alu6siLLhuxprBJcN6hb+Albuaqrv1aq8LHLsQ+r+6mqkm K78DfMDJm8AEnLNAHL7sGLlOK5XKGsGZ66xXu7k2Ga0TRK1EfLqD+6aHG74pKrLBm8Nb+rqNmbYo CruB67geKqrCurHyJcMzXLN/cA34O456W6E2W7hjrLpcTMT9Wrb3WrAIKsIt/L88jLKF/3zE0Mu0 ENyKzGq9Xhq1gVm1Vws8U8qpmjyqtMu6B9vGncwQaHyd7Ouar6vGcTq3i/y+SZzKpxvDjRkP1zC2 1yCKMFuixoq4C+q75irEILuprRynhLysYTyfPnyy8LulhDq9DevIDky9v9mXJYqfpYnBlhmTWznI OIHKsIu+p4wQbTubyUwV9AVfs3zO13ANw/UHYVrLmDmOlCmQ15weDgyTOAq51jzB1qy99Fmkl3zN U9zHInHK4cy2BdG2BQ3OB53QszvOOHFu9PVm6Sxf6pzO6tyqYjqMlTnP3rGS9UyVDSmaXGnFWonB jjrBGmyZjzqkzgsS3dy+6WvQC63Cov8s08vr0A+tcbI8yzWAzgWBzrPMzu5MkOHI0UDi0VU5h0I4 0vu8lU5ttVTbuQAtzSc9FSe80AZ9wmpM0OAM0xdSzsJ1zsP1h+nc07X804BI1EaNKPWMz/r81H7J udKczxxNySX91F+B0OG81XytwgztIB430WE90bK80+1c2EHNzhi91rwiiRD51iNd1ZaMn3c91TFJ 0jaxwg+x1TadvgitJYC404Mt2GVtzmZN2C5FXxs9TwlQEAnw2rn2qKSJ2VGN0pSt0gxRybd9Envd 232t0J2t2YAd0fElyxLd08gt2sY9yzK7Y6/93K0d3TXQ2qdhDNZtDAWB3QiyuZHN3fr//M//DNBw jdc3IdxePdMvvdcHLSLFHdbIrc5NV9hondw8DYj1Fd2wPd3UPd2Vgd3a3RD/7R3cbZ+XTMn+XNlu WclOHd4kodXr/eDfLNOoHNMTPtxmPdhoTdEWbdw97XERrVbSnd/U/dz6nd9sYd01EOApTg/XreLN QdW5LbEDTt6MLdlX4ds2ndAwfdV6Utg7bdEVLdZAHtbK/eFChd8hzt9Krt9pgeLZrd3+zTjGIDKo gcVVzLmM/RAEvtu8rdczHRHd/OAx/SQad85EXuZBftpiDdYj8a7lg+SuzRD77domXhX+DeXZ7S4e geK/Qxm3LdmAzuU1brV5/dme/c0T//7ZO87e86XcyP3TW/hmGc7cRn6ecek4+13nsL3pcT7nU3Hd Ke7koY4R/l0RU17q01HFV2yakJ3l2HzjYB7mvZ3jh17hFjJcQJ7r5ozaGy7YIQGXxzkynh7nCEHi cD7sn57iDDHlZfHfLI44LO4cVs7qre7qlGHrtS7hCj3rjB5fGz7Yu17WjT7kIjGXjffmdc7k6Z7u NtHiCIHnzE7qURPtL96oMR7jDG7ta7HCnL3e3ozVf/3VaG3RP13a7w3Uki4RiXju8twrnK7u+F3i Ip7pOCHqyh7qm8QRUW41Ln4alM3Ub63vbFHQL03hBC3r3hzwgH3wBB9c4m7mLv/o5f8ebDRPMRQv 8cUe4tLN5BX/5Nmt7M/uU0F/6lWT6iWN5SI/Geo95ieP3gGv8t9BX2te1lR/2sZd6RPR8Gtp89C9 5F3fEDvP8yUB6j/f4mRP6qe+52af75xBzWyf9Gqh1X4t93Mv5j1O9Twd5BNN7jw980Y5jMLu6ce+ 6Tcv9iZx5xeP8c/u7Ghh3fKgEShe1XCPTOet2Vct6xTe2WSu4fDN4ct98CXBjSy32loy4mI/5yaO 5CJ++Bgf5VEO+abe7KZ+EfLA7I5P7ZP/SSmv15hP9wDPKwSPzo4u1icxlP0IL8cu5w7x9Z2O7CHh 7j/v83yeKxrx+Cyu3Qae+7pP8v3/Pve+zyu4XtGSnuZY/+vmrjSDT/iaLvFh3+4bH+pm7+SHYwyP f+q6jcXaH0Tcz9Xef/maDxA1BA4kWNDgQYQJFRqMd81hjWsCrzV8uFDhn4F/MFrk2NHjxwQCE4QM SXBkjZMIT6b8KNBYDWMvZcacaYxeDXo5be7ESc+YvJgwa8iTN1Rg0ZZJlS5l2tTpU6hREx44UIPq VaxVs2qtKvCqVLAW40F0GDEiVI0YN4Zlq5CkyJIiUZJcKTdlXI8vB+qFGVRgTsA+e9rs6dMvUqRG E7dl3NjxY8hMt2L1yrVrVqtUI2/m3PlpXLx4TaIcCFopTZkF9frM2RfwT8JBgSIe/7rY823cuXUj 5JpZs2bfvb923V3ceOS3c0vTJa18JEvRHGn25Ss0NUydOYG2BvpydlGiR8MfJ1/evGStvgdaxmy1 8nn48VuyVC53bsm6dU9P1+s36MybCpPHp/FcEk+xoxozxxyBGJTvQQg9Sq+94d6zzKsIM4Qwuvqc g+4tDi2qri/qXOpPp6FyssW77r4zaiDbwlpwwYEc1PDGB4GbjKCt3vOROByD3O05uEojjS7RiEyq JumsG8qWFX8CCkHxiKKNrRlroFFLG4X00jgdeaSwQguB+/LMIZu7z6TkQlzoOhL7489EoFbsLqai YrIzwfFiBGvLGtEU9LYJ1zPUTP8MLzN0UEYdS1LNlZhTc6n/ahpxL5imhK2vKTO1srYDpXKQxi5J bfRUxtpbT1H33Euv1cxQlVUqIpWMFL/n6NvPRCedfAnKPfE0BspMf6rBFsX8VCqtP0wdVcsGu5x1 Wo+eEcjaZ575zdULLyOOMiCpFZcpJJOD1Nym/DKQOv5oslNTW6aMUp54wQt1KY1qyFdfczYC9Nlx AzbI2hqyLRhbV2OFNVGFq/JhPR8eFnhij0w7Uj83P7qOL3WFIhZZd6ckCs+B4q1NWY7U2shfaLl0 lmL57hhI5qYMtpkgbavKubJChzvg4Z99oEpooWE2WiVJL841410JSg21FeP1btj/T+mNF9kXQWVK ZY0YxMjBr7PM8ujz7jB7KZsJPrhg9dj2lj2Bio5Y7oiHJvvu0e7TLyzUhGLXwGGJrfM7d0G1d2t9 9V252X65bNZlQPHejWaZz0b7WoOvddsqaw/I+dVXJa6B7rkdflh0zvwZSHXJPcu1w7ZmKnF2mFas /cnZpLT6Sa2XTVyglaGd8fEZGYy89c3Mrvxs5j9Km222M9e24K4IBtLhn+MmGmKDUHfMH/BrUH18 1llH/lSO1UXNXZrqDApZeulNNmuP8rWf6+KNH17s8ztTnuYaMM9yHEFY9Ao4kM5NqGejC5rcGOie ucVtdJAJn/nEZ8H+zao6/fHb//uGJRN41QZ+MErKvoKXuK4xTnEoHFsGkxdA5QUQhjIkIObWljno Qe9V6sFe0awSsQkCcW4R9B5YyEcQ8IVPIBV0IaP+46v/RE1PQ9EL1uB3taakRXFqyQgLueSyJhrk B2MMC+UqR8MZWgRbakNY2tZIlenxDHvaA+IPszfE042uiFFJYh8veMQwoqpdgLNiyTh1rJNB6XD4 Al4jg3e/Zn2tkUfjBz8OUklM/kAgY8RkJQfiSYGA8pKWpFknOwlDANbAlJ+0JNsq+QxTWvKAB4jl VWJpyYiZsiq3VKUoPXnLVhIEk6zs5SpB6Q9Pqg6UsVSIKIu5yoIAs5fCtCQvn/+5TGhSU5vEdOaZ NsarYbkEWcQyCtYM6TtmEUSL/CLegpi1Fph1c5o1+AEo68kPTc4Tm80kJUHuUEnLxTCUwcRmtrL1 SlDCkh8EQxgoadnKStbtN6D0wS9bKbphDnSboyQoP5AZTFYmsZIirSZI5UlMg5w0miZl6Tw3Ok1f gtSlGtWnTL3JwdvZLmrHGqdAzEnOEnYRkiv0lzu1ZEJKylSUmqzkPVcKU5tSE6DLm6lASqnUkhpU oS4VJbYe6rmvPpRoEouo6QZax1xm1JkqfeZAP4rEtz4TfBbtyCmfupC1tlSeJ80rK/ta02mpq6c8 9SmwEElYRnIxnfvaIlG5ltT/u27SomTUqF0TYllWCtBy3aQrwRDayq2u0VqVtKUlvyq0oHkyaHGL 6AQHuk+UchSiJR2f+HqpTEzi9qMYRAhmacrPl9I1ssHtKGczWtVZAfVjhx2sOYM6VKFqcS2PJJtx B8LJkuazsmylqSjN5skzvrSXCjXoeJnJUFeukiq8jCgRK8rMiAr3tykt6W2tadGRxtS3KLUuXlvK TWZec7bbhG1skSsr5xYEWONM8LKmO90trvPBKzRafwFMz3ziN6r87WcAQZnK+UIVep8dr1YRaFHN vHdRrZWgionYWsyyFZsWVSJJR/rRG9cWt6MMMXfn21cfi5jDPf7vuBh8TsM2/ziLKKSw4qzxZEcq FrLipStl6SrjbMoMoGg0sHlledD6hra8YB6ow8o6NLEOBIgUJets/8rjtt74gq+1JI49CsgDB7jL cP5xff070xkfN8RGOzJhC71kg6wTeNbQlzWo+7t42tSek+5od6P65l6CeKMxJfN4C5ZQamLLk++t ox5ZbFGJrbm44t00jZdoY4+2dbd7xnSQ+1tgA8sX17XecHILWVglO9iREU6nkxdnv6RaNpt0rvSg ee3f44LZk2BWW0JF/WWFvneVDzNlWo3JjzYXmb5+FXClxzfSJeqZuKwe90r1a9cA6/nZeyY0WOCJ QsYy+skY0XejIR3IMWoXQv9txKEb12ZA1+qRjkPUYx4V7nCnlE+Jtq2xbec8cd4GUuMXyQgXgccs Ru/L0YzdeIbamMOB4dCGBUl1BINIkFQ33IirO2LFaZ5Eiy+x5OM6C1skrNg/7Jvfa3F0Y3ceITbe DHPPU7qaT1fqlsscrRCPuM5r+8dX6/ji5Tt6o3peFoiEhbEnzBejjZ0Wsxe96/CRHkMJjnLNxR3m 7nUt6p7eYoLMowZ61/tH/EhxrAee4n2c+NrPVBazhL3nUnkn0BsbdGP72+yGP4+JC7hG6Kkc7jGf e8Lx7vm+710g8yB9S8xXY8Jn/eqAp/yXzlIRsrSFupA3O7KBTvLdvEMg79D/PeXLi/ClZ/5gmhdi 8Tt/d88PhO+lDz1HdMx1C9Z8zqxvvZBeT5avy37Y+x45UR0t9BpMXje8J3/vd390rYoWgQeXHkLy +H4iPlzNoxc96fve/I5w/Y8Y5z/Gq394xRsI2PM5oPu+7yOIJ9M3KMuN8mtA8qsB82MLSZhAg5hA CxQIChyIDKxASeBAgrDADayBEMTADgTBEcQZE5xAbEnBgzDBD+xAiaFAH0hBCmTB0vPAgphA8zHB 2spA1dFB28rAE/w/+Ug8iTBCsUMqfgs52gu5tAu/8dM9KYzA3pvCsLjAF9TAEuxAElSIENxALBRB IeTCLATDDnQja8nANORC/zN8QUmYGyw0QzgkQ/qbwNKjQPwjQToUQ/AJwzgkQxBMojEkwgwBu8WT CMbwuLR7p6JbQAbcPSmExEg0P96DQKmoQUDcwy4UQ4sYRC3MQTbUREz8xOiBHjUUw2xpQ1IkxUGM QS5cPk4kQVh0QzoEQgosnzb0h0DUxUwkxAcxC8SriOvTPhQauaDjN3+DQvGLDCukxEqcwkm8wi1c xTLUxBYMRWr8xBMcxU0cvk9cwTNUxVgERTGcQRh0xb27v3kwQ/vDP27kRCC0Oh3kRfEBwXrsRV+M EMQ7QiRMRJB7rPCDsmVkRkssSAiMxIJwxghkinccRy0cQoSwx2zswm2cxv9uxBkxNEGDEcchnEBz rEgWzMB1lAS+80Az5MWKQ8lYDMRxhMh8PI7X+7p+fAyNSECBWEBH5IxKPEhJrMIHhMadhIqGzMhM dMlrJEeTFEWLhMhU5MKm3MQvtEZMrMh0ZD47HMmSdEdshMcO1L951EFbtEiHfEnzOMSCMEvHSLuc zD1L/MlJ9MmBeManEMcs5EqPGMGOFEttlMiEwMstDMOL3MuxzEsLvMEbXMVRnEcLukVevEW+HEuy JI99PMLcUEsEvI2ddEtJPL/MXEinoMGIXEprPMq6JEeq9MTQNM2tDEyKXE1ONMyR3DujjEpu9KN4 lMjHNMrI1I2HADvyUED/tpRL4fxJnkTIz8THpJxI0ixNqFTKlhzNwRTLqERKjiTD0LvK2DxMasTN rgyfW9TDUNTN3SzLmWydoCQIK4xL9OTM41RNVqxF6JxIP6RL1ITMi6xPMyzK+1zNksRD2STJ5dRD AR3Qe4RP+BxPBH2MZnzL9KTEtpzLPRzD+UTKvhxNFwRFvvTLa7zQ6KTFA63GFMRKq5RK53zIvGRO +0xQFX0K4lRPSDzIhSy/FWUM7ZxRGz0VGeVJg3zGKtzR87vRsAi9PARSIr2RHjXIgszMtjzPIu26 p9ujJq0+Jc3RF31L9fTMKJWcJ1W4zstSKY3RBtTRB0VSLz0fl3M6iIPS/zINpKAEyiXd0TZl0jWV FeOcO6o7vuSb043zSQdMyGi8UizVUy/JUR51uofDoxZrOTW1C/sQVPN80AcE1Eh1VDTRTLjUPdGx u4ZDq5dzizV5HUe1lUahwhcVUxjdTDKlVBw50vRsyzSlI5gLojM1CNO4C4vJUvwwEl05kz9l0LiE xoRU1bYwTLbo0Uld0neYuvgToliVIF2tD1vNG1zNj0ZlFCtVUhiVy/UUVrCwP9H7VqiQUWM91Tu1 0/k7VIkBkQ4BjUiZlBktF+dgVEHpTB/9VStNVW51illMx7CgUh7F1N3jPE6FOmcFolzFGA+BnRtl 19BQklGN0x89VTnNV/99HT1vZb4h/YhWHVMrHKLeizlmfdInTYA6Ute7gAtQXdjluNVqrdQpjVSg JFSKfYqLLYgaTQqFLE7hfBjeg78zzVSGQ6takVeiTZoEpdal+VSFDZJCxdZ6zVZ8ndmOwFh+ZT5w VQpsZdXRSVaeBViWM1Q7nRt0EVVRldajPRK0Tdpd/RKt1VadJVWpZQohpb/6Y4o2TdJI9QHyKzXP nNVNnaA2aY69QZKLUdFd/ZAPGdXidFGEhNu4ldu849erxdlf7UntaTFMRVT449LTiYt0RVlbOdjl OFvBFVzRdVdedVpTddBAfVyLuNjDbEe7ddPOrES97Vqp69SBNViS7V3/0MWVtF3Ztc3HwGUOdGnZ eW3cbJ1Y100Kb63K53UKKjxSS0xTngVZzwPaISLZh7mVIpkU+mCa/2NXI9HVWhFfDblXzmTe5m0J YlU+FkVPba3CiElWgN1c3ZXVVONedUXZ0ZXX4Y3M0CjcvUGVY9XZ9u3WuZXeiN3WzK3f253V98td g+U85H0dXOnf3UTc8H1WcVHdBKZZIc3KqCBVn7zdB+bagUXXqQMR47WLxDXb8TzZ3zVd9A3hQLo/ iwULBn1Gvc3flzM+/Q0iFy6SdvWQDj7aGB5atMXh/ytJHnbQJE3S4uPay024oHU5363heC1dGl5R h63h43ViR51SF41g/yEuNSAeHe7l3e9N2CYuWwQNXEZt1xsmYyJlXTMW048l2BU+V9FJ3POlVSDN 4PJdEzwW1n9dT+KE4Mu1O/y9j0DOj1sl3DsmQu994zBOZIYYCy9t1UhE46+VubpDvqEdXlvF4Et+ SeDdZE4eiHiI5RqQ5VnO4/V1QPt1ODXmUkPd3kMe49EdYJU9F9R9ZYLwZFguUqf9SeTDO5EV4nNl E8T14FwlUg025k72ZFqe5bFA5hkV18X92yCW1dz93+A123IBZmx2VFnu5m6u5SZVXkBW46jb5V02 ZCQG31Ve5xuNZX/+Z1j2Zkf92UgG2vIl3zpmE+Tl5zn1Z2725nfmVv/kK1deJmR3bZPw3efz+QWO roGOZuimiOhj3uaZrWeRlT+kWRo5LuC1+wWPdmmBcOmPbqJbEIhbqGmy0WZa1ul8NT5dXtQ3ruP+ 1Wi84WiZjmmPHgiY7p+avmmcdupx0WZuTmaB+GeBplhN5YhMrmZXbp16+OqFOOqOhmmjDiSnhmqB 4WmdluqrZmiHRVgXAmu5TgijJuu6LmvJaWqcRoimnhaIBuiRbuviOIRDeArCNojDPhp1Po5Fjlq2 +GrIroF6EIjJJoiPnumXXuqXvhuoPmuD2Ou9dgwAGO3Rhgx3Loh2nuqOSGzIYO2BcG3XRuzCLojE ju2wIGzbdqGmZc//1n3suQbrgrjspLZrmcZso9Frm+7rgQht0QaAgSjtyBDpbRZshMjttrBt2J7t 6tbu1+bux7Du/oHZKp1ixqhsyZ7subbs4T5qpS5u46YYtF7up77p5X4M6DYI0r7v/HZu0haI/XZu /87vWf7vAB9wAK+B+5bt7GZt3MZtgWjw2YbwB5dw2ubu2m7w7p5wDK+Bw4Zw7fZwDffu7Q5xBt9w mFnQSzXVsEBv8z7vyB5ug2BvzWbvielr+qZv+bZxyEjw5z5w6O5vIOfvHz/wHkfw0o6H0UZy51by It/uEp9wDv9wEe/wJ4fyCicIKs/wKN9yK6fyCC/sJ79wi7jwL+dy/7JxS38F4bao7PRW6vZ2b6Qu bs727Bo466euc+VmDB4vcD4f8gLXbyL/cwDo5iMXcI4QczO38kSH8uzWciz3cDCXckaX9C0Pc0kH 74NA9EoX8YABVvmtXLzt7aUAbhanbPMua7yO882mcfjG8zqvb70ObRxniz038ib3c1sH9AAX8CM3 8lg29DEv8xBXdDJ38EZXdEffdC3P8i6P9AyvchNXCE1n9jO33FJlXN+m7IGAbLC2681O6jf/dpiZ b4Kw8Tx/9caodV23dXYvbV1/dwBnciWv9Uyn8Ec3c2qndnyfcgt39mbf90l/dkpP9hEHeEyfFilu xirV2jU3dcl28//LvmtwR+qj6exX72zPxvjmLvJ1x3V393Eh33V2H3ker/VGF3My53Jj73cNl+17 h3Z/d3BlD/goj3lhd3mD53eEB1O4lN9jFXWlMO82j3FVx2vNHvdyl290X3o613Ng3+9bB/CPf3qo X/eR5/MrX3aZr3mZB/HYBvGsb/atL3aUp3SwN/HcxnCY73pOn1c/xWUTBvWGtwjhPvqIP3pxQetz t2lXt/MbofePAPyoOHgcAW/CbyJQLlQ45dPHVgiJX29vz+zjRveM5/uLJ/cMEXyO0HyoOHwNsW7P R57z9HQ+BtRr54yZlnM3V+9WN/c7L/f4/vtATwrOXwp7P5PbJ8T/Po17Pz1V4xjrNyduvNF7Oo99 kI7bhOfTFm1Rud8MsV59VMf7QfFjvn79pC8I5j7+//MFgfAF7u9X6qVX9XVbz3DvpQZ+VNFUSIZ9 5D4I4td+QvT+7/f+KP5RxjfOA/591o9z6W+L5QGIO3dqECxo8CBChD5q+FjokODCgg0ZHrxVw6JB ixg1Ykzo8SPIkCILAgAwkmDJkypXsmzp8iXMmDJd+qpRs2aNdwRxznynU2fOnD+FEvRJ0M47OwaB Ap358ldBqFKhOhU5kKDAq04jNuzKleHDiBc5kiV4q+PZqiBLsjX5MuVJuCP//UNI9y5Bugb15r1b Vy3gwIIHj/Sp/9PXu5s2eb40+pOpUMMHk/q0o9Qy0qaEV/6iutmgVoGgtb70OtGgWIpezWoc65rj xc8o3c5+S1ukXJF8C+7Wu7sG395/ZRMvbhyhT1/KCypvvhOx5pWPhzZ1bBApZqVJLddQevz7yKw1 spKGOTE1RbBf04NlbTb22Y7Ec5N0C7etSbaz29bXX/t/Qn7xNtxeBPpGIHgJKliDOeZUdRhiNtmU 3E3KMRWdSoYZVdRjOWXmXXcFXTbigguSNxCK4x1U3kmrnZaeaao5NFF8rRWUVnH0/XdfSvr1yGMN cgEJoF149RWggXX9ViKTmznYYIMySYYTYs0lthR0RbVEXUGaJf/VHVJCebfdZU2aOJ544qmYokoP wcgee2LJ2R5r8SmIH2387Whffnn2WR+RHwX315J9+XWgmYkO5iBBjPa0mIU/WbicYh2ytOFSWnLX 3ZecjogdmIoSl6KaoanZJkRvSgTRjOq9KCpCPArJZ22zBulnoB4NeiRweP2GaK+FwjpsSFFC+SRM j0WaHIU51YRpUNJBpqGHnX5JGZjaHbUtsYKJhhWaWJnK4kcvroZaWG6q2q2suN5aK662vqvbobwe +auSSXa770dP+tuooyddWFSWNzFFZZeWFkbtUjph5rB3n25aJr+DoZjmuCqydFq6YakH57C5ybsn vIDKO3KBKff/OuDKLLf8csUxM+iovwGLNFRkVkIYYZUTbihZhl52yR2Jl1UW6lGbyuxUmhqLC9pI c6KLnoypSZ0ongaJTOu7We83so4wCycgvgMKuDTayCIbNNBDLbfYlZMGZd2WCYdodLVEH00xZmjL JBrgGK/5bUhdqXb4x1yd1+rHMYftN+SRN1rQsTNnGC210CX2tubLYg7tzUQ5jG1mIX5pGcRKgyg5 S1eRWpDrqLZ33qqtxpiqjI7fVtUzNfTOOvCyMUrzpZLh7JyVQS2nIfMYhlSd8dhtR+a11yUdYvAq fbs9moRHbTh6isc551dUA5ZAAjE9vtIzvbfvvu8E/b70NdfU/1C//dkDNjyDl4put7PkNhktQa9u oyvKiCBGOqKtTn8nIdzrnva9js1ocTEyDcdAVhX0pY+DNfAgk+bnu/eJcF/4ux9B6ufAwNhMYJmi 1uaYkxjIaClhzgudY1QHKoiJqG93W2FI2AQ7jZHLIxc0n0RodzXcIfElHuRgBz94nPeNMH7xa19B Sjgs/KmwiygEYpOi45hmJeeFdEuWiDiEnb4R7XpsVBoYPxK7cLnEXLi749TiNLsmsiSKBEmfQToI SNnMj4pYhN8IsUgs++UvhQdpZBy/AzrmERBnY5xbdV6SneykTodtVF0kE3Iq2BWxXKxCHPlSZUc3 GU4mg4SiR/9ASJxCXrGKiURkifKRj4J4UYUpZCQjBaPLUE5mYEDjELTaNq1owWSTQPFhDyNWNOwN ZpjE4t5KMkg7V6VSiYdTF0zQ90FAkhOE5dSanmDyO0Ouc34lKWTvvJaQ9b3EmgXRJT4b2UV8WpOf +KyBP+2JkH7y854FJYg/DfJPhO4yIQVdKEAbGtGFBtSgCS2KNYFS0YkelCn8fAc+NSrRg1x0otwZ ZkB3GTGOWhNEAn3pLu0pU4kKVFGlFMntkshNC3JzfBpsCTkL8spxClKK8zqqSw5ZRfcp8hnvzGL7 UPaZgF5jpgapny5VWNOIclUkBDVoV7lqVbHGdKQDbShEv8r/0LCqtZi6lMxbwfrWMUKLoDQ161rz mtayupFiurxMTQOL1sGCNa+GdWAF5bSexer0juCMSRTLGdRAoi9stsLPrfTj1LZEFbOZTQkVL6un dvHJP7niqCOHaT9r+nKshd2qQ/FKVrneda0ole1rKcrXs+Y2ISD9p06GScOMcigyvw2ubnmr0LL+ 1Q63/eHqnKtSy/yVoTDVa20PC9vgla+x4aOTElvJx5OI84/nFGd5B2nZeM3KT797J1viCYDOQtV3 or3Njw4Ctt1Zd6SqrWo+grnW1ZrVrhAlKW6fa9vs3na7uf0qbMe63Y/6hLhCyWiH4JoP5La1sLSF cD5Wmi3t/95VsK517WH1d66qcUyxUwPfBv8YSMpKEb1IBVTJcFwb+d4Ki6AFbVO9Rp/8olPHIFko VgNMYBQyMqsk9kiEZdtWBbP1oRMm7HOjfFCWEhS5htloSo3r5Yj+NqweXvBsU/qpiLqUsGY284kL jFsVsypd5RIvK51S1PTW2I8dXK/J8Cto/GwWUIW2Io/1uzsi9yedITmokwHsyCTj77qxvfRyszvb FKM2ytil8nLhLOVdHjeZbxXu5yIzV+Fu+cxkpe4/m4u0UA0TM2oVbKgNi2sgwthjFXTsKcU3XvLy GZaRpSygc0ykp7pzvvKlrxVzNeQ/FbklWQ4wQ4OZ5BSiGP/BmE6xVbt9bUwb+M3YdXV/hTvcDc9V YV8mNasPDO6ywvq5E+thrT8tbwd7dc6SK5+5Epu4N7VYLZJNr41lnD7R7gepW3tfful7aPgdutqB VrSO13dbSWc7okvWtX81nWtzh1vkaR41yN286a5uFdXHxfCp8Wq8MlcZ5ee2LpsZGCrpgqnDlga5 q/n971Pq9LGtnB0eXdnBP6SP6X+oMdTL+zU/8WdrBtlsfAvNY/nOV343vjFpp27xTP+TwGWXtNm7 zdKPGFi3e913iWNL5bf7nLlWbkpcwRxQ6H00rhOF8pZbGuuNYo/wPxe1hw+/QoCja1V7RJxgmF6D P0heipT/r/yxA4NL+SkVkSRsqhaNY09favuE9/NlVYQeyunUMNWi8xKmbsiSiTWwTCJu4FT9DTyr hVeVdb7d0V15+QRQniCSd/pkpQ4YinOelrXMYrTBs1Uu6pPJkHSK6sF4SUpyCYatB51TpJmdaP5Q 9LrfveN5H3wYg9fgxKf8+/ts1HEKhqkHcT5U7Q8rYFrf9KYHTPY50DH9jDFFRuvVEPjNBIkgzUrh 3mYE4O51F2rAyIqti55N3h9d3uWNE/z50fJ1HlPpH/NFn5n8nxed3vURE3HMHA293twUF+ttBsVk CxypYIKAT4v5mrARBiBp4Ac9XfwB4dMREsWtU/SJIL+g/17+pKANyobxfA4NPWHsyZ5a0F4TKoqL iJce2RlgMN37SR38HZ/Tzd8HatEIKtUVhR6ToB4KftEVFofzEGBxwaDrvaEd1lnSsRjvCQb6FN/k +WDTPR38qQ9/3Z/XpWHzcd7zJQg9nV4b3uFxTIfCfJ8LQqIlOtavJVGvDYYXamDT/aAfjaHY4UYh Xl1ToROeHJIaukQjjt1nlaJnXeJgsGCqtU2myOIlMg4e+h4PIp9RvZ8fbiAGStU8leIhKlLzPZvX raJtxAVmESMx4qJTFFCXvCBRMJM0WqLVMNGrbIYgTt4geaLyxQosepY5AoAdbJZSqOKzKdI5+oeQ jZY8Fv+j1Z2WK2bjo3QfAmIjFeJjE7LfsFWFIHaiOGngQAojxpGjkcGLZZTEOi6V1iEjvLhL17hL PSraRTZiK/qj/1RjLeIMR4bkcXzjH5ZkUG0gQs7LM1JkfTSkfhANMoIWCTLaUTHakJCioC1ko4lk YAzMPvIkUBrHEBafIPYh8WHgH/phZn3EyeCHS6bEZTyDZfiYSTRb1eXkRM6jM96kRhpjUCZLP36l WHYhSg5hQQRjUj5dV16cSz4lbXhHs1kcTTKcQjpjRepkQo6lXu6l5BwkBg6lBrairKikQyqFQ1oP iNSjj2DlYuLYRSqkTXJNNPKlLPqDPxDEZV4mZe5LWRr/n0F8o1lO3ePEY1twB1RKzEJmzbTJo2kt 5de9ItXtV2tuZmVipmXWQGbiJm1y5kD+pQ+aZWi6hA/1zWlSkwM2Y1Vs5G6OpWbipmU+53IqCloS pTAGI0kqYNLAhe1B00wo50h4Z3T6Y3MWxHNq5m2O5wpRETFd528mxFDKBN8Y5lvSYHc6WnjeJ0yc J2bq5m3GkXqKEDNGEmC2pwLe2928Ebfgp4IuSH/up246J3+ip+QY4ebZkv4QZVoiJVqWZPjtXHTR 53EuqIgSh3lmZnP2p4SyzueBoHoCEWgGJ3AGZzNtC2puEjWNKI4ex4na5o4+KPCcYoWSIOsYJEn2 5l96/2YV3qiSJmiONulnoKiDnqd+Rg7znSKiGWHwoGRSfuZ0JulBzKCBOqmYBkZ57qeJNmiKLg2Q nmG0BanfvOdZHgSGAkZ8jpg0LemY5qlL5OaDlil06mea8st/YqnnWagDKaWGyqiXfikD1qCePmpL jGd59iifUqkhUmgIJtKhImpJwqlgLCD26Nx9IgCpkipBIACkqsWfmieEtmqgVoznGZIiGmL2KCV7 cqiiViGCOmr2AM4QBUapFoSpmuqppupLfMM38GirKquPNqjM6N8tDWo7uSnahGaRbqlsiBie9mr3 0JFgDCuqhiuxhquxqkSy1kCy+sO5mim7nuirEosqXv9pppoilg6p8YHmkRbHJwFR7LhO4HjrS5Br DaDqwBYsuQpsua4Esn6DnxqEpDqr3yCj/VWorEaOhtiqlo7oqfgqi9xUSIxrwRYrwYJryCbsRyAr uiKriTpolJbou8Lrml5qfQVoooAk0MCpOeQqfoaGt/qr9wSsyJYqwg6ryXoEyhZEsjKsu5LnpEKs mgKorBZhvfILXR1T/1BOlCwoBJ3IvwaOxyKEwA7tyA4ssRoswRYt0qYsQZwrmpZpn/oo2lQp9Ens 1R1it/wMMhkElMxMC0XnxhIRuJTHz55EsIqs4RrE2RYu2iIEyjKsc04pu6po/pFQm7IT9A0LdVhH U9D/zLFkbXi+zhz5q7iIrkqQLNme6tiOLMgu7kEk7dqyrcOy6svCKq0C6FLVLeaa0QGujd7urNdu LM+K7teabckaLNmSrOoKK+uuLbo277qWaIQ6EC0R6jFOrahMCwFuiLFgbd9u5s967eBcTPcMLtgi rvKar9merbCqL9oe7dHGLn+mJ0QqIrTSL+ZmriRCS9Z273JGUBD5aumi7sGKa7ASbeGW7fI677q+ ITxRqJDSbIIsE8McxPZ67n2aSuD675o8jccm7ukar+oOMAF/cALLIuVqqghCsILg7TVOYv9s786u CAeHy/Z8702VbQiPLfGGLMiybwnjYgNbqERerxhh/841AowFX7D3kAp50PBofK24Gq8UI24BFy8C /zAkSm0IRi2xZG41XpKegq8E/e6KjJJHRPFB6LAPo7EPY/Eldh4KU+0Rx94Bium4CM7ojq/4foTp qm8Uj2vqrq8b46PzqXDNZhI2JjKOim+pDA5CnAi4rATRnq4fi3D6DnI22q7MYAjegqQdzzCbfC8p Oc0ZJy4BTzLqHi8gpzImt7ILHeAEO+keO3LoQnLTnHGxHm8a63LYCjAJuzIwI8cXJ+CjNnEjk0Yt i8QkH6wqU3L5UnEwR7NHThIi52kjA+4xb/DwNjMPh3DQ6jI4S3M0N0/eGpc1jxL37LEtk28a43Al 5//yH3OzOEvzFM6xIhezE0dy6JIyH+9yFZ9v+pruPAczInvxEX/yENnwPkfyx6YyGu8yPDv0QNPz zAkzpGbzr2rzHLWEGguyL/PwRI+zHIpRWF7hgHqLRmszQwMs4Spu8hawS4f0PGdv/pa0DQImUqqF LbM01AAtFR/wByPwFct0Kz8hAR30voAnS/QmpwIGGQfuSgcJSugX+gqtKrOx+ZqqVw7GVn+nUptJ V5NEd0515NgH5DCMJMoEnnx1SLA1PeqHXzZ1Ww+aXAguxzK0WUu11iSEVe/OKQO0XlM1brAiWbdE WHsEf42WYH/WW8yTYze2Xh82YOS1SuS1ZDOJFML/nk2TImG4NTkWX0pQp1wjtmmNjDHzdKwUtmp/ cyBTci+v9kpctlirD0ws2l7bdmDndmXvtlrD9nHI9mwD94JkGB2rRUaWVnvFZtgR5lx7ZklQXizG Yl1O9yMDgGjkCVlT9lTDo0pKNVuUKn6ob59g9ytiJJGlkzl6d3Iv2mLex2vmx2wv9nbzdmDDd2l/ jXondnxbNmxTW3LvZH47tqORd2RnN+tE4WRj5V3mWGRCJtcwpaD9wXPPhoSH9Wh6JYHzt24Lybyg KgAgQEkQbH6QK3sHd27r92t6916rt1jjV2qfeIqruG/btmRneE3Ot1wuNnlreLW5t4tTNYcLNorX /7eB6/ZM8N//TWMlbjZnZxy1LbiT16V9FuNf5hd0A0CFezWVt7WK7/hquzhtkCp8iziIEytuG/iP r7gxwreJg/mKq/ltM6WJk+MzxnaXq7ZZn7mR2zeRF7iOt/ibA3p8zzmQy7ifC7dHnCAvJXlMLFMd 17aC/8g7PjhpITcpDqWkX6WWo+J33nmR6zmbkwSIG2yobzicpzmhi92Plzqrv7ibIzah+0ihN5yc 8zmMGzqep7atH/qLEzlp9kigF3mhhzqPwwQTflH1HYQfLHtB+MErYxJC2JgHQrhcPjmV0yVhCqZJ gHafWOdGPiaX73qxwziNx/mg33qrC3mgp3uro/+6sOO6eWs3vJe6kcc5m6+6qZ/7nXv5nu93vwt6 f8+4p/P6kTPZLy26IxKEszf7wjf8wniy1EHRZG35njz5efv3xbPkeg3hc2e5WmL5t7MkXvb5p8s3 vbd7ap66Tmp3vDgmua98rsOiugP8u8u7v+f6vAd7YeP7v/u6uXeNztv8zsN5vauEgGmbG5qesy99 DTh80y87sy88ecmYeUXWUOWlaI4iY2c9bBrZerXFN0b3lHf9WtsjgRN8o8k7uwM7Kga5rNM5RkY2 2689vdc3dz/2fledjis23p+9Zb+9wOO8zdv41i9lur+5jvj9u7cEJHHRwRu8H1zD0ks91BtE1Pf/ 0S+SoVARlaiAe5xWp19yNaLPB2SDx+iravya6OkbK+kJGLI7ftPbT8MzfdMrPLOPxCD1mbQ/keaX iOd/5ufntOjzC6KvviAjLKwzics+rvE/avXpE5LXT+Q7u+w3u/U/feWrhCwN1TjSX5MoNUJ66huO /VrMpkussuICuPJX6p+6Mv+hoBJeVezfT+RLP/ZPvsIjhNQnRMJVvcQDRIIENQgWNHgQYcF5Bhcm dPgQ4sM/E2v8IUgxYkaNGzl2PPjNY8iNCBDUIFmSIEqRKzv6c+mPIEyWM2nWtHlz47UaOq/pJOjz Z1CfPXv68VPDKFKkRpkSPJr0ocCBNaZSpSqQ/6DUrAOrZmxIcF7YsDhDWmTZcydasmtrfAPZ1u1b thFJpjR5MuVJlXNDynRZA2ZgwDL5FjZ8OKPagjwX73TMs+jStEedHmSalHJUqw6xSsWadTNEsV/H Ip6r2DROkG4Jrk5dUG9J2Shl230N8WVBwgb/knX2m6Cz28MNM36o0w9jo0ShOmxeMHPUrl2tft5M PeHYhttrlCZeEABHAEODGiRfODzHuG0Nyo2YviZeBADq7jWZ175N+C0F6/7r1zfgahAwpP32A+87 j845pwYGc0KLPKJ+Qis5xSJDrqnKnqoMoqq0qs4z6jrDjqEaftkOgLHS826lA8UjyMWDrgnvvP8I gXLIxRghSk/HhNxr7UccbSopvfnusw0v2/SDMaEeAYsppv5y2w0hJ2H8TUDhChJOyxdrCC9GKxN0 yMEGGSxzwsbMWzNCpIqS8KkNo8tww4S40mqqz/LM8yrrCvoFULFOPDFF7RSaSUwhE5tRLdRkdKzK SDtKtLVK42KNvSANolQj+Oi7a6+6lKyJx76eHMyv/3pbicABB+TyVQK7fMjAJseMaMEFCdK1zF4X k7A8GYm6JqlhiSUWOujk5LDD6rYK7cMRAZiWR2rDSpFaGLPF9stpmUSwW28PohbMbKs0t9Qvu9V2 p3LHM5bGdmcMF9xNzxU3XHGrxdfc9fKF8Rv/c/PNkVxt9Q2XJHKNnM9cI6cl0lN06aW1YIH3bZJa lwDwJ2PACpZU4ODUdRc8ap0p97ePB2aS5G9VHpNXNHlFKFdIhzJ22McqJDa55SyTzCmoLovuoD0N 4uoq0AYC4M4EAPjFxC/nmXahX56W+tp1FwLT3lrH/RbssF1md915xZ1XwvF+KhfcHHdUt224WUZQ rrrZnrvesLlGkF+TPp1vYb+1TZg+h7v29O11x0bc3sE2nvavvcUeuV4uATj5cuEuv1zkaS3vUnK4 7xZd7tKH81VXg1JvkPUyHU3rsZ2KfROyyYimbE6liN5Kzw95B9HpgpYGFMaptQvP6qq5Xmjq/9JD d9v5r6VPF25G3+3peiZ5Gs9r6IXsPvoD18OUcr4bz/t55xM+ib5PBVc34fvS91pR8HvcOCYwc3v8 fPO3DC5lX+LSyQgInJPFinN4W1zj0gezXcnsTKxrnZl+Zay0AKVCbnqTZJCjOzpdRncdss50+NQn pm3maVCzWvLE8rSpQa154VFR+MgFPfpNLl2MM9ti4tWuCXGPgZLaVMWCWMN9vQWJNQyYXBqIvoFJ zkhfqou7qLU+IrHvidGjld5chi/wEEZ/MnlcDUHmrQGyTEsHTM/nsGRELTaQil78DgRXR8EI2rF2 jzEOsvjYMwjxDDMcAmGcNOOZ3xktaSeUSv8KAfU0GUItRVbrTgyZF8OuvYeL/Rub3GhkvaCobXuQ 4p5a7ic9BZLOSQBwjfOW6D+x1cp7gAtc++wim8LN0nRarF8QNZkejalLjLk05ZViRbnPZS44CTwg gexXxFsVZHUOqqMdJdggCzZKQpBJjlLMs5wbJUtOQtvdszzUpz4ZjWl3Qh4kV8g8Hs0QliXTZdzy lsscgocoe9PJu9aWTzgKEWzeitgpJQcfkKiyLQK9JNnqpVBXRrFwUgwPSiaKOCKFj5fTc+YrofQ4 wTTRlfDREtdGqi4sFVBzoONkqZpJz9ek7kyok2BMW3cOYD1qWN7cmewo5EFu/nQpuMvInYr/1hnh kQuS1vrSia41D0JhK3ltc+jLhvive92Tk6GsIWR8sq2V4fBjXqVXDi2Gr/VsK2AMdOgQ9xZW2PxN oBDjF/soajDqkQ5j4JvYuCQWTKtOz4yuGtDmBJQ5chGwc2Vt61dFZ7HUxDRmEZSsNKXJOgjBLmew 8+ZPcAdIcTYlkKDljNKuY8hyIkSFMNzOaE7UnaiJxbXPTAhQLlvBRlVPtqu51E3EFKq8/DZUsymQ bDMyK5EB0FWwEqxxz0hckcTsgWaC6UwhG5QFZfOatNvpzp7j0+bUaZzAA5E1rFEDawikvOUt7S8G EigTVc1Eqm2tU8HiXGHFjjFtagynXuOv/yVlpDYIUQltDKIXL9nXIczN0gBPepAGp9G4CMbVrig8 0wrbMVe5ggyajKPZ2G0zdkATalC7i5A9Wae8CSCveqmy4hR7BmrvJcigJjnj+a5WwvmtYHnyiFsJ 04SqEKHNkH9b4AD/eC0G/N8ZlVvM5SJZI5LFcDWhOUHo1gi/Q9nmUfgIp5+FMLTMOhq0VGxe8543 KykmLyJf61TmTXK+sT1Ujm+2R6Fw9TxQvo2oaiMfUel5LrPCkpOTC0AIDxrQEKluNac7TWra9IJq ShOI8RunZQUtqMoa7VRWrGL0mrkrLz4ve/8ElrG4d1BMNRSUc9bhC94UUok+TJ+HTOu73P/6z7Lu iJKTy2CRGbBLsMqSrg9C2QzDFHUzo2ZPII3nNW3ZjxkSsZi5Ke0xpzm9aD5vmclrXq5oO2qACpSg BhUWcb9ZzxYMcYfVTezvxGZUt3b3Rg7d6+MKttCCfvC8GS1dK0u3Zv2m4MDxXGdkcTd3uBtktUXo 7fNqe8XYPvPDQSNJFcKWeJM0N3dY7eoboe2+/E6cSAyMnyMReFKk8gh/EQJsJTf35faOcIRvsx/1 RjwhGVZdlSsbzX7H9LJ1nhDOAEniEIoZhHZCmqhFXRA1PzF075Xhm+Gr53jVlrYwwhmCbND1GnTd 0YhhuUs1KWRQnZzPsNnI2AHaKZs0Wdj/r0pIkznXZLcjapNmTq/eH9IrKf8dmjQdOE6z6aal+OSz lnlO0ke794F0+9uO1wp5w2ONX1iDkSqUsaA2Lus/CgV2oFyM18/RddN/fVc2kPVdVzLg2PA515gE 8sprEmwH8zrYtg8PzTPCdlupa+8snrjwJ1tTwPM82QGv3R+5CmJrZ3ralobIw8GtYhdb/+GP/1Z5 HemtRnaHWkxl674Qpy+W8ktiEsOhwfRoV/KrnnLZssE5yMjXvpm/ZOZP/17rn3+B3p//wuphjgxU 3Eqx5CieDpD8WOZAWqZ7BNBzmOywMMdzRsaMyEj/Iub/NlCIGCeOMG9aIi7bzqzKBu/f/0pwZirr gThMx7AJQy6NkDRE0yLC09YsxbztzDwtzRYp26aFeJDHkWasAYepWshmdNwGANePcdJCbeQlPa7B BniE/gCg9OgvCuHvCrdIcQ5mmFCp/MquCBfnC0OKyOSNb8aQo87QlcqHATFmDedn0PbjgAAogSzw VTinWmgu6vDKdJawVBYmBClP+G7OzKjL3yZr0VBQ2dAk0tRkd+hEQz4IaBziBlusxbSv26yiEoMH PGJsqSQpPTyxnvSKk+aJoE7JlSwIPnbo62ZE9QDgClXPCqnQTFIpoOpJl+YHDDNJF9cQ5fKDDYNx CN8Qo9awf3oRbzQnVgrIVTJHGXcvgP/mEJkixYbehmss6lM+hfIQAOcIghClLLqMzfio7NiojCOE asTCafE04sW4zeEgD83eEQD2LhQ/MYVCJg3zDg0bS6wWqIyeEEHQAohMTwppsetgERa/jv4IAv6+ yg/dz4niCRfviqUWqousBAMtsg81cn4y8vdOEZbIKI3WiElGihmXafcakIhMCR/nBkxsiUkwzxq4 EX7uIxMLcfBqxu+oCeDMUSSeL5ASIgbZ8QY97TOCjwQfbh69cSlhpJFEcRidqBRBkiNRMQ3zCUK4 pyErcv5GxvSiEPV4saHe6GviyZ1qLO9QqSrLLiLXsi2J0XuIsBjnRthgRaQECDgkByX/M8kq49Il 4QZw4GceSwLzuJEbuw0pVWeaGk0FV9Axf9LShiYzJpMjIg/ibBC9ENMGZXLFWmojj/EWqZJd6EdH Cupr9glMsBAWo5D+HOQKVzMK08PrBmoq2XCtXMmStiZFNCpuJHJdPLADkREB5ck3b3MPuWigkjO5 5NAZiSmlnLGAeESlRhNkcHEq42c+ZnIeO3Mmu3MmnY7FdHKCkK8nKWsFGfEcDSIoIzG8HqLphEcq IM/6+K4pvyQTySpM0MWxbrH/vIo060eO2G81yYUgwbJAY5MKYbH04E+sHnKsHFJummesqI79elOt 2qpv7kUYBVRD4Wiq1A+gLkZE7Uru//LSZP5lmVJKcxDwQ9Fvr77mouqKcOijO2nUOxETJ1OQHHuS R8lzJmDQp0ICR7NvM7PNxQbR6b7D9yaHJhoS/lyTQVRv/hZ0NVGvIdlCOyrpeDgO3VpEUUROJA4k 95DLIPRt0BiM93BiNoRLL8jLMEniO9WrLm7S74xNBRkRgtYizGbCSB/v07wxvTiNxQhR+FJjSZf0 IODPG7yBIUvv60iPdb7ySyS1MChU4xpiRUqjS4er7cA05W6v0BwM30Y1VE1DuMzQSCduTgmT74oN T+303+5IzwIV8ibOG2/1VgcxEwtV7FgCUQliURfVBrxhWIvVUR+1IF6RWnJFSiu1vv8U4mNgy7W+ Qjxa0lPD1FqPq7mWrNcQLU1nrc+8EU5TdSYP0z50rud2Ujx3Eso0M1flc1dvDud29Vo7glEZtQaE teuE1RvOgVG9bv4oVVcA1lkv1dQMBbaktV5/7KTO1OVkZbnsji2SxMhko7zgdPjMECeLjcLEUTF9 zgQlbFD1zsVaFVD3Dlc3dmEfAl//1fQWNV8b1UxkMUoBtlmTlSw09VBGgzuyVGdX1r4gTFTxze4Q jS/qg8DgrTaO1CTSa1xjLwUbbedkJroA7SYJFVfn9WRtFWghAmZj9uvuNWYDlli/EuzArnVudi16 ViGotZKmVWFZpGvHxFtDNfe2FTH/ksTA+kxe49VN4zTndvTCFLEE2xVQSbYQRfBduY8Q59YhghVy hxVspZRYUe9fG3VBZNFsr7QLv5QhCmVaQ9e1dnPVaoxaPxU9AnTtfJUmzlRbH/Zb1wLlzg4/vvPM WFVcSRAYq3bg1tXfiA1lcXRrDYL7YpJXPdeeguxW8DVm+ZVYYbZZ99UbAABfp1RKve7uZM/UwE9L 64vqemQ0vFSYVK5TtTBM3w7mJDY10i646kPtbm1kMxEY0fWOoOs8gZdrUZYEubbytnN/Ry4fmfQ7 mLd59fVRo/dlE1JKjxULcfYjAfgrps5SIxhuvXd7OZUvwuTAMLh1iTZ2wRXeHOIk/5hWVFaMYnNu MSNrcBMtVfkOSXcVA9EvQKNSgHEEAqlnAe2wZSxwUb2FWAl0esPlIKnl9KbQW15ThmfYraxqh6NV hmrMWowHUy3w/ICTibdQdW94/P6KiNIviaUqiU1z7orpgw0j15D2hN+1aW0XNnaX5yzsd/ktfud1 BO+TXSjPFGl4fB9YOGlInrqIXaZ3er8SIWHxh3v4eiP1DBk0j52phbrlkbW0VCqpUChJDdtwkzpy LEFTmCiyD8tvHysSLq0TwQLMPk4VuGhS74jMjWkGZD31SOs4ljWTR+ixkcFQed/SH32TLPPVUwZZ clPzQKmXgmz2NZEVpMgSllCEIf+k+ImzJrZId0P1Chn3mBQzKhjnckOneaMSDWnbmH3vY8AK7Egc V0hLVgTpNSn791bjSI8x0ny3GUNXUix9+QwJVDajsIfLtmwRVKEY+YaUGUWMBzyuhVy2xoKjmJf/ iYr7sUI5WYOziIarWZRPMZt/TD7A2fUo1n3R7pvNuSP6NjEztlTU6zhHUXtDVJnXz4mCuIdjlnqJ +XJhMxZXs3qrdFLDA6B7qYgomHSNp5IJWppXi1sEUpvvyS9RmuyW+jNF0x8t+qQx+n3d98/KsJam GqQ5Il4pMVc9OaBrk/VYb6VyUZd72aW9kiDVpWwNmXpVr3IVWKCwt6Ci8mDgA6j/fVqeCHqSSBdM emJq+poY1TKwm5oPsTnqFnqlQ2oJ9/hWak2cNfqq0diUiyyrN8Jdt/ayQyaHNbShVCY/5/mGlrie gxhGepiIs/CHYRo2v25bwBKMk3exmNiJpwphqcWfRqn++vMiwzqL9/NcuNihPTRDPXutvpq4XO/k imyysfrIWrmyD4KO3VUzTdjkyvk1fjUjWrZ5gfVR9dVsyzZfq9cgsJd1m7l7V81St3ce1GIhruF0 O6mrnru8Gdu5aq25PRq5HxvXnFu+iTd4szZJy7Dk+BsnsJtlwxtYg9UgFNyAi5UhwfbByXu+vZfq 3jZLS2S902K93bvw5iV2DNyc/8Uayn7xsaua1j76lPvbI7A2cVOZfVGZLXL5JhgcwcMbZu9VWBly WIPVSa9Xwqs1QDX1wn0WLSfJr4mivWFH63IGxFfWs4mNAGEPqw8CjclZxUUiVUsuuQnQusGUgJkX x6EXWav3ZS83WTkXJ942tniWNLaDw2ONWoUuWK68v88YlZubTWuJwOkcwPTbscHZyr0cbG/cxgvC gL27xxvYMHDsYN22NNw7wzecedTN2fi8zmnXyPxcnDNavy09JNIOVPwsyvdcz7T7IL4WzLGXnw9Y beeiS1kkfDUOMjbcvcHitrDO0+u8qqkcSZb77Eg916eaqu0l9rpc5L7c1CEXWP+LdcexEM17byUo tMJFV0Y23DxQA9vtq8lr+Lr3DBjHOVxNWdyD3SN23Yi4xs8iKsC+ScJcBHKVnbvF9muZvXIPbEkd 3WDPe+va5c2ynd3pm5QB/oEh4tmxGYCzF9pTmkSbWmVU4m+AK9TLOYSB/ZlAfX0lHkGm6IwboydK Is/cjcYNHcJRXcHtnSXavMh5dkImHcmzLtbWRJTIl/YSQsIJ9ve2nS2Rd+B5ubCLROP3VsATQsv1 bE2TluJJ7lRFZaJghGE8BQFmZABjTYsxua6/mIpD80IN/V7JhbRfOqZjGourfgHF+J4ZUDe9Baip Bvxse2qg/lrMxltQ07ZDb1v/rPUaM/BuiDu4WVs/pyWRV+YAzUeJxz7wFzukdn6P5YqKih7XAt2b 2XTAj77cgf6KKAqumH7p1ebpQY4Xw/AIqRENkbBeGDU8WpZ68bVctn6xP78UDf/+EGeK0b50sAfq Odx6QGmUBBI1PLksrThDnTqnz7xKXTssw1CeFQfdfF8jC9siI9oYrbyibu2WMr3EvZmyqXycJzbU k3airiglaKR9dGJNsUfJSTGUqbGbl79xth7BY5p5iRk5M6qiy1qa04flucYngJqHvgQyADItAQJA jYEEBQosOPDgwYQEaxhs+LCGDYc2BNqY6JBgRYwIMyJc6NHgvJHzIDZk6JEh/8iMKzuGPJkQgMyZ KWEWROAQAU4EAHAO3EnQ50+bRIsaPYo0qE6hNXQ2Beo0qdSTQpe6zOi0J8+YAK5dq+H1mkCvKFEu PFtT4cyIZmt2pHlSoLe5Dud6qwvAbtq1bF+2bQmyL9+HJUOuzRhWrOKCi7+O/dr2qkqTfsuyNGlR Yl+HfCVKvKgQM9+SImuQHEha5lvMcVu6DM3VLVu4EHUKzFo1qNKpvHtLtfqzqk+gvo8udYp8Z8+b P7UuB5vTalfKkVMKTov9MsyV3GvcnSvXe165dwNvp4xWO3X1GUu6BzBy8jyv8LteKynWIVnFjz1C ruwWe7CZ9xFmF2lGEUYbHf/42UQTwTYZQYWJRNJphc0zIGsabneYbB52F1dTt+G0UHJDFWeahIWh mBRxusHEFFMsNnTcUzLelhBQt3WlVU4DOUYQkKuVdd1Z11m2YXd2eROeagRadmR6AWL3JIbtmRYR hjzO9xV/Xep3kFhhDomkgNVRWZBBF1UEQEUauSkZnOaZZ6VA7qHWnpUAbgahZH3yCeV5WzG3W1S+ 3RnfaTMatRNURLko46I2NkrcQbaZxJNtMoUV1VqO0SalQR1y9tCTrhnm2mFMysRkdmmq5qqTknEF K3dwdcaVlz+CCZaQNE33H2ekphorrK8a+RCbER2mrEUODqQseqB6tCJqM63/6CSov/oZIq2AemtT trAON1SkRlno3oqJSkrVU01N6qJu5LL7ronmvhscAol1mZxOYbF4qlQB00vwerMiBVK6+P24b69k 7UpZsAX7xuCBa8K05sUKHlVhQwqnmGK1E49sHLmG8nYhohKiFh+9UR3naI3y3stibo2WO+81+lJa L2RdPtzbwEcJTbKkpxJ9nmnqrhiszw4HuZ99RRe3sUYNNqSgxZ5JdafSIOP59dRiT9xxouuG3DK7 Mltl8nBsE+w2vsGdWG+9lC71lVM/S5wU0kT5PXbQf/smdGIM/7vfp5sGTvGznjl+0sXQckSUymCD XGG6jG+Oorosh4y2xy7X/y032zHuJmmNJ6s+993yzu0z35zPTrukX+4X5NMM114U5BkzuHXWv1N+ ruUtax4278rDpHnXXnut6IxQEfc2vjDHK/3NbsOc77tkIefVzhLLvnz55p/039637w7x+Z89Dr/W kwsPvE0fQ4/85867T/uFX99/Npdtr1+qox7ppPci0r3sdXcL39Ocxr8ISvBnu4pdQ8hXPsgFD1qT s5rkmNcxFeEPXf6T4OzOZraPHS96NSOgjWgkHOulboC4KZe7briznugsbzhJnAmT9kOjJKAGQxzi VBaCOwiyT3aAE5uDiEc/Dj6LeCrynxVPYqHLhYtzTSxKF1WmsBWCUGS9Mf9d925oE54tykTuyhQa X9gUnYFlRHqDDgbd1yfaNdGIRARAAorIx6FdkIJAow900COwolVtY5kBnvC2Zr/MHe95zkvbFjfn N2JNiWMlTNn/LJm8MlpvejIEDvdSd6JG4QiHdPNJj3qlr38F8Ux65M0fb7mQQAoSJkk0GC1pN7z3 geaJkMSY/TAHOhFWMpS+nFomL9lF0Hnyf1hkZgvbeDKc0W2GbcvUTC4lExJ9UzFA4smthEWqcGlL VrVa56s49CtjjQoitzpngeoZT+vApIgC4WMCRtUhKf3oMGIy1rBEhSy0iCpE7ZQnPttEkYc+sU0z WVNArVWQkVwLesPCUjr/wdWahB4LiAr9aEdPCq51hkaj+xNdyqrFQt8gB0bxMpTM1DbKmHykR6vs yXKcoy+VhMoofBLobPTZLXm6CklzEs2QlFomXDbknwMZYpHKlFRolnQ1Bk3TVb6VEDZhpE1umiKs NtJUhrD0LDC9kKgmtFR9ppWpr0FngPJolq1GCEMhXFcYMQfKa6LujFTJ5sRIpMro5OhdBsnUpQp0 sC2CKFCTheaGPLSeqz6VoUT8IxE/+89A9jNCkyEaXveUnc189bJpKSuCFjTRgcQjHlFyCF/hw9dP UrI+2IprZY/EmmX58rR/Sq1tOxnA5mkRbmqM0SkLpkas5IiOlsqJQQcj/5uuprRbgTIpbRC503li lrRmAhB7jOjZfuKyiGbS7rGIS1lcqRZKnbHVWuAU1o10kKzDxO5lCEMqvx7UtpAt00PF9d3SonbA Uyquf3kbyZZ67nk1k2H3VkdYAcpsOeDEV3UbiyPADC6z4/Utd8nEHiBS9rIZYg0gQ3RLqhrxqpr8 JWqJdbThnjis0CJrZuKRkNkCeb6lIrBJRvILDP1iybft7ZPOI2Ki/nfFKEYxkY+LTP15TLlkFOVN 2zipN5LsZYFxLImC85BBzRWprwErmkgb5TVX9s3CIhBeR+sQz/JTtJ9tr4G92mAq/2XEgha0fsn6 GdpajKJAJtJr5rFkAP8kGdIOYbJM9ATnyWoWq0MtcK0sW2DrIGqaEa4mdGNoL8MeVjlrsQ25Wo0V NdvznfBEVVEdiqy/XZdW6mxoroGb4IzsubNWDehMZjxrwMhKpyGVllJzTE9cq6VWzzoIm2TrkHhY tAa0/a6UtASfGvxC3JCeyS+itOxoj5TXl2QzqqyjbDt7m8LIHPUku4xT7aVSzFN7GXAe9e9ZClyQ Ma6qng9e1c4OnGQae5y2J6LtRnN7tlwrzJIvDmkkI9k0F1940XAbtub9VXQjI+C/VX1YwlLP3zD0 uMsN5lliJ5wgCH85wSzGEYs9/CJApnhS3JNkcY97yUInt8WHLpUDNOT/AEq3OULaOmEVTrJoBqQR 5yDV8u3JzekuPwh7v36Sg+uS65KinA0avbGeT1zIEm/I0CE9bo6/nehuR3rcidJ0gjSd6WRfiCeX 9lIRim1eB9zczbZet4CTffG3nGrBQTv2xS/q7NDyueXV7nO3i3sgSZ40x8ndcc7H/e5FyXsNTD8Q 1Nv87wCsJr4FaGHevS1mNJP8wvUsc4Ozl9gxtz29Gi3kiWOb4sE/yegJEvRJI3nooSc9TEzP9L2f /vRKV73L7Y0/evsep2De5vZvH/PG+xPykZ9dz9uuPLZjHtvcJgj6Sc/8zW++43a/ePxTn3e+613v 1ac+1/+aOSxjOd9X/xyoVns7Zj5zxi7RlBQHp17hp3C7NzIDw3bt5370EmxHEXzFZ4Gy9X7yV3SS JnT2R3fzN4KkF31Lp4LTt3fW93JhFFivR4CBEzAMuCgKaDRFIX7FwU9eFGPl125StkkemHnnh367 hIC80W3AxxlHWHecJ4ILUYKaJ3rHx4L9l3/Tt3T6939pE0LJNIPKY4Mfl4Q3SBToNSN/5EdoiHt9 NjGntXZGWIFO6EVB6BvddoEyoXYwMYWh4XxEN4X0N27Vl4L4F318J33+R3YrZEkyGIZedE6+1muS WFrSNjAXpVLdoVKOhlLhVVUd8k+R6F58UWwy0YN+lIlQZlLv5V00If9xtJVOQ+ZOnXgYF8WJsmUQ jZaL3fZp5nZutQgr9Md5w7iF/WeI1JeIWqiMiwdTj4iBdvVkdPYSz9ZMkqVX2TUrRxWN8hRa67WG fQSN3EVV5jGO1yhiUCUtBSJktlIQmace8EVn6UFxAACLs5WLcyJpkZYQ4xaM+TiCyEd3SIeIqHeI K+h/XOiMCUk4SwUS3yAQ3wCRAOCQiCRniVSRJJZVxUVi35hn6lVeXxVandVPm3ZXcXVjEkePwHcQ Q4Z+qqVJdjZlDUFbQ5Zt7YV0GUJ0/niCzBeIimiMA6l/xriMCkmUkLgt7yWR39ARSmkQEDlooXaJ tchiJzZtvegtk1X/jmsRilLJLR8BSKFxkVOZVeHliqvFYNOSNA8Wk+5Hj9kmELDYVBcnEOcmbjop hUgnesT4C4QIfYSYeizok+ziBzXgB4NZlB4XlgOhlDUQkYvJEkoZkeQFXCpGkr9lXHCIElbVjQrn R5C3jWJZmaqYjVBSj4T2kTYGX0XWLbAomRmRk3XJjx03l3dXgiV4AHupjD+Jf4HJf4tSmIMJnIc5 cEbiKhOpmMZZZ4z5lJn2Zzo1V131nJ1GVzMmbGooY1aVZ12ZnFyVJOeoY2gyj5m3EHDpVenxktQh UHUlmXS5GnQpl3lZhSQoboWIjH9pn3y5fyxSmAOxnwRhmMIZRNti/18PyZiLORMOyZTTIm/CVWvo 5mbT5m7iNWCluIZbqZHqVpVQGRveeTDeZo+u6HOdIYvLcl2aNm+cplWqcW43OXTm5g/8+KK/8KLG Z39MF3dc6JfHmIKF6IK8sZ/A+Z8AynVOSRCQ6ZSOCZFJ2hCOKYRjqDwv1mdiR3NA+IYTs4HCN3Fv OYceR5vEiHycN6M18KL+AJA1Op9Z2ILI6Jf516NG8Z+G+ZtAKqRDeqRIeqQFqqTKmaeC5KTmI6UG N6VUWjB9ChNMeHml2X50yC5/8AcE0aiNWhx4iXRjynxhOqZkGqbzd5tXiJ/2qaYHiZBTEZyECady OqcuR6RGepxJCv+ZRcqkRTqJkgelYSeBjDMqjAqpkDojTJioKUmEJPOoNaCrjjqsSSGpYgqmZIqs YSqj48asnLepa/qTyYiIQ+mjhGkT/RmkpxpErOqqrbqkqmqkrfqqM9h7+xSoM8c4jHoSusquSngS FRiHRROsuOqoA1GsvVGpy4qpyypuZCqj/iCwgHh6g3gSBQmYuxmUbUoUpqqt/Imt3IqqdgqrS/qt SKqQs/pitSqo9PKoufqx7yqsU8GB7Ld29Dqy9yqmApuy+lqCLCuwMeusLCumdKesoYejNnGI1XqQ xQGkv9kQpbqtEss/RKqcFruninm0rnqcGRuBUap7bhg4w2qv+Jr/q0poeYnqgSa7qPg6EJiKqYyq rB87FTw5pv+6sjE6owEbs8q6fzubm7v5qQnbG9v6s/5JtLNkp96KsSexp4tZrmEYSOjVezu4rmTb su8arCRrqDK5hx4rrI/qD1Urtn8gsLgqskdxcQMbs2k7szPbuTI7dEHZs0O5sFfoG28qtBHLunlb tHiap6kKuEpap0rrrc74eONHc7ODuZFLue2arxp4hOc3McEKto1Ks5NLs8FLFJ/7tQCLqZ9LqWx7 s2dKuqZbn2mKInEKtKbauq5rPuP6rXoarqxqtLBblGz4tI03NotLtr2Lub9bHG2nqMVhr8iLvGkr rGM7sld7FDJ7/7ahC7Yzyrn92rnPB5g8iqNCmbpxSqr+Oarga0J3iqdKe7RGS7vjm5AFR7i5dxS+ UAO+IMIizBvs6q5e27L9a8IocqUjs7gra7mWS6YfC7O+ixSXCr1gO4xLtrbOKqNfa5u6aX0FybBJ oboPPLQSXD6za756qqp+e7FNG7jmyr7n+sENAcIg3BuZC7yJG7JczD80jLxuO7lie7n3a6w8zLI+ HLDU27Zue3/1yX9o+pcM7Jv8+aNKXLRJa7t+S64FesGzK6RWPBVaPBAjbMhGscL+68VWm7JVG8b9 W8NmfMDKW8YoXBTKCsAD+8Mw26wAW7PUq4JYyKZiM6oRrMfnM/+uqSrF4Aq7rIzBqQwTWkzCh0zL tUwU/qu47qu4XgvG52PCMty27Hq5M9yvvwwTnDt/nyy6zuq5BOG2Wyi3ObqjzjcjcPq9srzEgUux GFyn3QzIKIJ7Hetyt5zIWWzLigy8u9wQjAyyEuSuwqzJxru/MYy4ybyyz/uvl/q8bdusnwy6OkvK dYybVqjNCcnK5OvEgAzL34y+4gxItUp2IxzCIUzLh0wQFw0T7OzLvlu1X8HLzEs7X2zP+Ouv8yyy yJzPyCp/nBvQOvzJX8vSByt9WCipoXfQzvjEfLuqTAu4GjzFR7GDhEvIL4fOiVzRSX3UNsHRjZyr 1/AHUN2oUI3/yeazyAI8xmIqw8J8wjYRzfnMtv/6z5UMswN8FDlrdzuc04/IpA4dy0trwX9swVPB wbs3q5KHyBat1xm91+1ste+LxjbMqF7xqEADzC1r1vZcxoutskZRwzUs02Yd2dCsyVIhiEUHkGvd OZKkyuKKsU1su56twXStSxJIzrNEwuic0amdFCvcvx4trIQdsvh6R7Uz21b72FiNuMzbtslMsyw9 sGlLxv6KFLUpiDi9PO/wDjOYQo44Nq68quf7ytH9t70xdmA3uLxD0byB1BaNyFmc13y90cEMshwN 2IMdQa69v8pLycN8tSoNzTM92fwq0/Ld22Vr0FRIO8pdA8ut/9z87XReiFzWxDjSbRMJfcHRDddS gYa5h3CnPTFLLRWGTOF5rdoavdEqDMmvLdWxjavK/QfvUNvr2tFeG7Mm3c8lnsn6G7rCPdmanLz9 qq9FR4LWHDj8/d++94VgSOBiw9N728cVC8s8OKUezL6cc84YndRX/N1KTeHeXdHdncLvPLIg7eHC CuKMqtwjzrv22uL4OsOLXNUnAeMr/dUnndvzXdzCaIJ4OTv/7d/93d8AvnD41ow7zjnk2tahHa6w iuC2pHBTJXNFTTJSDt6q/cHgjcXijdG4zNS3DTGD/bFbvtxR/SXuc88wrNWbntI3PMAxnuL6G99f btlxfNOcs//cDZHjAxHnHocugLUygVXgc/3Nqxy7e87HQq2uoMV7Rz42Gp3at2wUF87oWBzeUu6+ kVvlkh651/AOHz6y/83lU/MHzvCozuAMwmrt72rJj6zeK94QlY3mvz3fZ14Ubi5/XWrjRZPqcj7n BLHq18dJn1M7T+zT4Zzg+b7gSBHRdk3ov67orO3oRRHw4r3dUR7e7YrCGw7VHR7ij7rczs7fzr48 2D4Q2X7xjYrtVLvbKfy/Mw3qlH3fvW3uzZuXPInumwPn7h7vA8dCAaQ0YKQ84rvQfczEO+0b4ceG j7c5iq7Uxi7lBr/afB3sA//of+2osi3bEB/i/f0V7U472Y7/7Ru/8Yy67fnK8VPx2+S+9bmdvDN+ 3E+433Le6lAvcGIkRqGDJ849Medr7z89voKc8xrrhv3+63ot4US/3eRu6LhszkF/r5n+yCr87D8S 1Yc07SMj9cRq7TVg8dZu8V78wp4u6jos48S90ixizcjNODke5+1u9j9UNl3W3CtT796c4H9Lu9DN 4ELEe7tbNBf+5E/+tSSsw30N5VAu8EfhzpS79FYr4sH/9FHv+Isv9dVe7Y469Y5PuZMvFW8c7vVN 8gas+VVogmPv39nP6nUuMl/46mbDO+D62YEM90Fu3YKecBAI4Syy+05O0TB+wIve/gjf6Lx/v2Je 2I367FQt//EifkgAUUPgQIIFDR5EWMPZQobOFAp09mehRIc1/lCMePGPxYsJD/ojCFKgSJAkB5as 4U+kR5YCfw182VLmTILv3tWwibNgTpo9fbKcN0+g0KBBaxglWPToT6YHv9X4FvVpVKhSB0p9ClVr U4EJvHZNUOMrWLFce/oaiBZtjbVo/bkdeTJtW1912Rq0a1emxo4ba1zz2xewzWt/r/E0+3PhQ4aM JUJUuNjhRr9MVa4ceVllSpIoMXP9FTNxYp45b+I8PVo1UKFDjbaGbbD1ap9Ts1atavWq7dtcvYYN SxB4WdoJ2wqsS7fu27duN8dlqze5WuRNK3PEzvfPYIGmi/+3rBhZMuTIFycv7kuZ60qUJzsX/Pxd vszSNm8inl8c6evYRYn+z48pqnDbKivdEgtuLOCGCy7Au5KLbq272NKMMwsvJAjCCaebcKbAPgRM I8CuIdGwwhw0yKHFPKrosYzEu84szzK7TK6S4kMxx+4Gsk9H2mIbKsiB/BPSR5kOzM3A4r5aUKwE G3Qwr+qqo26zzZzDccoOozOLsr4G2u6vvwgb6EQfG5MsPBXXpIgjF1Vj7zMrjaTzoNTqTIxI15QK crY+8UzowKkInK9BQ33UK62C1PLlskbjNI7L4xKL8aISTTTTTDobEm/NNCEaj7ziTDIpJUBPRZUr AIlK6ij/pAryM1WBeiMUxd+IMzJRCSNcjrPnDMpSwl3nu5REY/EMT7zIRB3o007luxFDWael1iPY rmVVyP/4TAweguDxtlpxZ6KL17VunNNUdak19tI6G1uWoFBBTTPZce/FN8dXXR3Sv2xHC1cgcGsA d+B8Tz3tPo8YZRQ55iiMK92DN01RRVDjTXbNZyfmuGOftl1Kqdf45Y+rggkmOFxvA/Y4wNJqwu/B hqk7d07Msmz5O40fKmhFNclbUdmchyZ6yJD3tTZWmgI+eWWBUWa5aNJQ6/E+qxVlmMsNTa3xV6nz C3rZjD29eDxOv0abY1b5G3k2pXtS2WmUETLYYwDuXg2//x67U1hLDjk0FYAKJwYAUI19DpsxsXlm zN6DCk87ckD9bNu1In+SeyCDwb27c8ir/dyg0Lm6E7XPAbjzTmGlG9afwnEubvSBIJe9BtqRvbjn n32ON3eZahddIOB/l7z4fikPOXmANYcanuE5fn6mq61GnerUYt4yUYKip7P223EXuyGzIRNfzcQR 4n57rtI3vuP+/nT17aWjbppgAOq3vXPh8w8eb/6F15/t/ue5xwkwgAQkoAFv5z//vYOADuycAwF4 t5sULoDquyDtMrjB011wdh8UYP5OJ8LQec6C/iPh4w6YwQHSzhmdq4jnHHLC2y0EAD4b4f5SqMAO jhCBHv+c3QoZ2L6vjSwp/2qKyubmtJXJ7n4fRGFBGLhADOZQh1UE4ff2F8Up7s8+NkGdA09jwS+i DoWjO+MW1SfFEBpwjSAMoQWzeMU1prGEbHxjHDW4xRva8HAnjKHtVFS4NfXxhVDEohp1+L07JkSL bSSi5OSXRJZtLoiec17A5Ig+OG5SkXR0YhtfOENQQrKNI9xb9SAnxupVEJJorOMr+4dHOn7Sk3MM niwbCcdSnhKRg4SXGyNDyBsasjEWPOQjb3nLRfaSk6aMZDS7tbK4xU2HA8skIp/pyzuW0ISzXMwN 43hMU+ZQjBA8oH3MWEbbpQaWczShBoU4QSAKU4859F7/KeNJy15acZk2ROD2bCjAPybznvprJAsP GkV6PlKaD2UK05YoMKc9MWUCDBcz3+hDDOaxgJDzI0EJ+ckrrtKMO6JdTk6qTgnq5J3NDCUv7clJ KzYTmnHsqCP5qUWODnOUszskRMS5STUVU5gxrSUja7nTpULUqTORaCUrSs39ZfSmJdUmSXcJRYsR k5ThLOcHwXjKlFbwnMJraVJj2c0gctOj+sRlPnXp0ZfiFKsjNShAgyq8GAYTrFjNqj2VKsuNKnNc d6gBYgWi2KfmB5vMk6rzvmW/A+oUsAlEYz1HaUhB9gMA/VAIAX/aye4UDp1nxZtpMUvXBB70kve8 JPAS/5pGAIqOi/RU4RRpy03RvjC1ggQqX5sFqppitrUK5V9rt/fb2l61TndQbHSjm9jGykdumaPo Y7MbtXehqR9mA21FOHU+HinMO1ZD7952tM3qqgak8sLYxn66O8e1lyvQhW5iEbvf1TzpqRJNGYCf ll1UMaQf4XXGdx0CWgbXAMEbs1PfXsa3HVUNNQW0r3t7Rr76hha+Z8uwT/DLWP0OBL+LHc2toCRN bNatbt/SLnfP9N0GL+S7DmYwguFFXh5VOGGp04mFsdfUEPskdKFy3Irw2qwOFxkh0s2viaV84iib JUG4imY1t8s0a6JKwTmOTIPjO1zxRviLOgkyQuqDZv8n58h8Z7MY4+Tc5oSQmLr7xbNB+EtdpjTp vwOO6twC/GI8fZleB65xpxoS3t4ZxDSP1tvVqEZnN2eMXvSlNFNOvFjpcrrE+bWzTBjUFSy3r34F Q3XzTiboOil4vAlezIFhTeY4q3m9EabwpHOd6UorC03M4rVMNq3nKhdk2KKG0m9WTERUczdg/Hgs oX/CD4JQuyWyjnWCFezgV2N72yC29YV7jBp+VO0d5S7dQaxd7YLEYyDuDvZB4pzkeLckz5wO9Yin 62maLHsg/jYelzWnMmq/eN3rpgnCEY4QMZNNRQcWCKMttmBfh9u85b0Pwm9SbpksvAbWtra74wFv kdf/W2jiM7mwUTxlT/NX3/oNNbKZ1N5mQw1l0LbmwX2icJrA+s1fLl/j1iRrYKP5vF88DcdTw/GW eHzdI6+ByKEuEHjXW7w8TjlB8BzlKtt566B++U8U1NhVL7Fg1OZH2gWSdra3/eNqH8jCea7ztX/c wXZfez/4wRBqf3fv8Gp7eNl+47aDnO0bf/vG2+6dj58b7m9/vOHZHnW0Qz7qkIf75A3idszH/e1r 93jWiZjnEZu42CjuutZj7hEFAZzF9AN9uEDu+c/X3fa0rzvd7c4PBu997c7YO2ipvRDeL5rGwEe+ g/fO8/Windo2YT5PIo9321ee9vyIB9yzn/2oj9z6/9S/ffgND/rwiz6ap7836ksPapifviULcj1E lTgw5tOd+Ztnd+53H3e9A9/uDlk+5Ps7GmMwFQlAGgM/pzs36bOacnO7ucu/7/s4d0O7qas8eMO+ 0Cu/+sM9DSyy1Tu/T8M3KTO9EjPBPTO/lvAWDqy+/MO/Dtw/a9O7/kM7vqNBvasBP3AGPwAtPyg8 5Us74gsPyUu7Bcy4hEG3HYHA60tA77M7qMvA7uM+yysIuYtAGAy2rku94mEsFOw09EPBOwPBFKzC K2xB3HPBBIzBiOO9yvO9j7vB4vMDgfDBhhhAv0s+/fO8JLS7pHtBPWxBhaPAKXRCQUxD8FND6tO9 Nv/juq3DtzFsGbCbsi1UvS9cOTJsOjPEu/tbRCu0PdCCQ79jMt/zPx6sQ+CbQ+CzPv87uO9TO6Vb QJx4PDSUwNlrRe/jPijMxbebwk3cQE3UOfYZPT5jv3tzv6IxxjvTuhEUQfbjM0zMxA4kQs27vfur xoE4sL5DPm3zPwDUQQC0MbbzwWwMQr97RdBzwx47PKeLQGqUvFy0vkG0PMmTxsxzRxgEAG/Qx4Hw BqeSxJUrRph7RqkpvScztpejsmOERq7wQPGTiRy7sVmbuB38rm/0Ax2EOIXAyIrIyPKrE6grOYIA ye5ryNHYx37sR36Upi5EPWIUwcgxRiojwfZrSRP/HMiFVLfC08md5Mme9MmfBMqgFMqhJMqiNMqj 7MmULAiljCRH7EISK7b0yxnSu8T2Wz9i3DebxEmGlA+IAzNQhDUdbJyL1MGy3EEbwxjOQ5WRY8u2 lMLsY7upKw6UrIGTTEmUpEsudEYSdMQTRJuvU0a/tESB/MetxBdE07Hw6AeL3EFTxLGJdLVgmpaq ozqpk0Kqu7y5zMu6FIi7JAim/EurhEpl7LQSREZiAzv0M8gwNExxAcUCxDaHKEuFcDVFSzAeBEV8 Yct3u8zLpMzVwEt+BM3NlJyo5DoxpMlkJJqEdEnTc8o7uAaZPLbWHJfXnLXYpE2NXIhUzEGKRMvc /6wWytzNqZPL+dDH4exMptzHtGFJ5xTIlwzMm+yYTfPC/YpO6NQ36HxP+aROWfFKiJPIWftGG/uU i2Q0bLwXtxTJkgtJ4KRLuzzPukRPmDTOljNNl1PIicnKg8TPv1CswpDJZezP6oy4iBOvG1vMs3TM s2QIA0VRjiHPd/tN2jhP9YzQByVOgqRJ1XuyvuTPSDxB/dQvEnG5xDIW6NSUogmNGhCNEKMqMbPO yBBLFt1IBftGsOxI3SQ5Ga3M71DKCOXMk5TQMV3P4ly/gOTLqFxOwjQRTElN9rtP6ErSlgmNJWVS +2IigukHb0E0bGwIs6zIxsBNsqTNLG2ZLfVSz//sTDJNz0blTB1lubCjz/bcT2RkLBDtUP2ssjg9 MXfxmJcAVZegucnisoFpsIjszgFVUbEcUDDzGMt0kBv9UuGU0Ac1HkqN1ON0RkjElzPtVNEsUpqc 04Ox0zoNVTuVvxZrngDLTbBckVblQY1czD69O/Mr00d91Bq9VoKEyumUxG7d0KkU0fuMzsLIlGAV UsPomGK9U5hAVmYrVUErGMTEMSZrUZ+TzWkVs5SDULsk0/XMUUhdxmErTeSUSm4tUvx805Yb1okB 1ZgQjSaNJGqqpEFzMGwCT6+UDCttTFdNQYBVyVrFVgp9xEn9tDDE0K+BMiGNTqz8Vf5qWGJl0lD/ bVdRzbIW25xUA61w+cq709c5RNCgtdaA/cxZZc/mjLkQLUhenU/9LFcjJdiWRVIkVdd1ndklZVdj zbKCKLv5g4dTjTiPrVehHdpsFdm7VM+/LMzkDFKWYNp8wc9y1VSBaFnDGDFzFZO81Vt8iVh37VtT MwhCk5s99VmvJFsEBc+PXdQxXVQcJVogDdLSTNhGnEmpKRH7JFI+M9f8Mle8LZOYrZZ3fdiHZTaL zRwZw7FThVJsBNuFlNUytdGRPU0vdMldbca9LJoS2Vwx4VSF1ZTf9VS+LYg6FVWIBdxVo1iKpSg9 Zd3XLNx9zREEQIDICU4xrVW0BU2VtcqWZE1m/8zQjjkWugXRp8Uvz1VX4OXdfDlWmLDZic1ZLVve iyrc+TWIxJ2P6cXf6a0B/ZUcMb3RxQ1N5wzRlltZXB0avDXfvNXdE0HgzuXdBB4XZGXXmt1anCUw SyrR19xXQ/2O/OVfgcDfr5nV7N3Wo01NfqvK2/1ejskUB26XNlVggtBdGR4NrDOLCZ5ZCjaIWxCI W+Bhj8lZm+Pa+K3fai1RFOFf6dVfJQ5hEfbfp6rPgZwuk33bfDHfF47hzl3gK65hSzOLeqiBehBj gqDZO5XYHq6BH/ZhHlbjH8aX5B24eDU7amFiD5be4gHYL81eLvRLDmVJH42c8IVg8c2UMoFh0P9N iJ8Zrp4A4zEeCDEG4xw2Y4lV4x724TRGYzY+mGYr1RfTLllpYg8eiPzF4+BcySmGLs/Ux4JETslh YPH93L19YC2eYURGiF9rNKZo5DCO5OLd4TVOY2Bm40sO5okJYvmF37Kj4zpm4hGdllXGyzt4UC38 UaJB4ILgYhn2VFrmivHyHZkY40buZUdOiDVuY0wO5mF2Y2MGtGoSsGm544K44yWOZ2d+LmiW5rqU LjDVSrT5XYNol2Kh21ieYVmeCTSZuJmI5IV+5JlQ50uuZGBOZ2PWMksS3HH54P0F4f3NaHvWEW+Q 5ie+1nyOpAXG5mtO3yxGacVosjlDiF4OY17/FohdJueCWOeB0ORitmQgjl8lGmI6lmeNTuIm9mg6 CWl+lOajtt6imWeANmmDNuQHNmRbZgnEqTiWgOmFDudHruliruSdRmdMzmmOEbjkVVZ4HmWh3miN XmtKiz88YSJlltURW+USK+F8aWYl5mgQXuktdpdjEWhMaQpPIWyFhuSZRmxIZuhMXmdiVmechuiO UdZUI7BqEWWOzuu9brOxKAvOhuunqbn0VMp8xi9T3mN8yez9tYckbuDzdeD0LWhBpmp5Gx+XjuGY JohwPmzdxm2dnuhhZmzIvul8+eQhRl1Uoed5ZuZg8zNA6dot8wZwGeEwHc67tmwQVuLVrgF7/yCI 1Y7nFh5o2G7Y8DWLMmOWV4blhkbsmd7qXo5oNP7tcw7rlokx5rkXvWZrtcbszR6Ozi41HbkuVZNu eOhHb9lWbZXd+/7geM7uefZuWGbgFw7oLcaU2WaRXJ5qCGfvw5ZpcSbnc3ZsS9ZkYvZtoqGqe5EH eWjqjCZl/r4yJnnr75i/uYnup9FHAq/LcJHVkLVuUMZs/vVuZuZuJqbwCg9vwT7ybv5mgP5crcZt ct5tmMZpggDuEv/qok5xeagBLU9xtlZugujo9ko2GI9x1RA40F6Z6I5QAk9zkTVbVcZr/Z5ee6Dz /CZygXZhwZ5TC2+KQm7TergG3t7lxHZvsf+G6Jxu40OXaI/W8i3n8i1HgEfX7El3suYmixyZbPse cM6kbJaxVUZFbTBXbuml8wVHgGuQXvSe5STHExc213GWafVe7Pn26nR+b7Au6i13dF3v8rbe6zC3 r2T7tzKfJmvK04Ip8H3MUwgVbeoWF/z+ctXW7h8PYf313NcWb/JGEUH+3MIQZ15ubw5PdEO/aXN2 7OF+qEf7jixHCC6XXi0H9kpXMVJDEeySX34cmBo/a2THS6MN0+v2chCuc1IPcgTgbr4GbC7m5uAN ECxG790uCEeWcjeucnKncmFGd2lSLzbjikbv8iz3eHYXvUOh9wBxZ/yR7hxHmZTEphuP3dj/ReuN zt8gX+0HZ/BRPvXWLpa/5vPEcPUy4W2DCHr4zmSxnnIrz3jJkTC+SRiO/wmQ13WBgHpJH/mCIHZK ouwBMzuqUnY1z3GQhd1nF2pTN3jurnNpx3lrL3JsBxSeT++YzmqutmmKZ+zITvpomrDpUXemCPle 5/VGl/oU5Oyr75aJUqIaZ/lU8+nFBfvTrhOy3++Cr3Y7JuUGdvtTiXBZVuxY53z4TnoSH+unWrPS YTy+3/Wod3TAD3zB92zH4tpMF1npjm5UY/ka/3fsdXwjuflRn3OOLnV5XvEM12J2YfgN720pr3tz pnIR32FaN57zCjLoHzKa6HteHwiqz/Uk/6ps5b0oHF/5mlMZNdfWsF/msc/vXx/yevZ1j1npiB90 hHjso794RYcoxku3Xbt/6k99v991kc9+gKghcCDBggThIUwoEN5ChgMTwvPmDWENihEn1sDoTeDG jRwlGgwpciTJkjUQnESpMqXKlgIRwIy50iTNmjZv4qxxa+ctgj0F9typc+jPnzmPIkX6rsbSge+a QjX4FKc8glUFXq2atcbVpF6/gg371eHDig7Jks0IEqFEthspVvTYUSJIsWBdujxZEObLlH712g0s 2KDQgUF1Ci1qGOjgxjefQl4KVTLTqZSpysuqmevAzI4/gw4t0iJctAxPn+6YsSHbhBPnDv9U7VF0 yZYrUQ7ELRNwSNy0f9MsLFwx4sWIjQL/PdXpZKeVMWP1nHk6163Jr2NHWnoh97MVM0ZUCxE1xNWx 62bfe9vvzNzrZ8ZML58x8uI+gxYeOr/xcqaVKUPmn0BNURUdZ5x15dl+C8qnUEHefUdRWxJOFBFD GHEU23mzzRefbnp5qBtfufXFG4O0FZUfY0AZxZNxJ3p1WYADzugcjQTSpCBWnUmnozvuwBhkV9Ud CNZ4p3WHFnevtYbRWWytplqGMMb3V1+7sffSiEH+ht9xxSVGFE/1cXlUVDcS2F9BONak447SIVjD jz/KCWSZ2FlnlZtGKvQkaeRZ9NaRcnH/aB6DvvkGmIgf4pXonaClSJ99i42p4qM2RWUZgDQOKGBO 1BmIYGZAzlmQnZeCphV1oEa3J05wmQWrRd9FKFesbb1m3lyFUgkiQVWW6CuJqIaGnKWH6WcpsZhe 5pxkATb36ZCiymMnnafKuWyq1WmlJ7V8mkWrg6w19JagcUEJm7Z8jdgoe1tq+5mL99HnpbLxSqXp jM9yqi+bNik4bbXZClRqqfiKlaC3I7lKk5INhfsQkulGGF6GUtL1qIhXghjiegg7JtyK9CZGJshr ChiZp89lujJSrpJaMJ0DYXvyywGDqvB03WoXa1pHetcneehGyWuQt1WZ16942SyYsV9G/2pv0yEt x6+//1n2WcwFC/RH1zVPnWO3cOrYo1VF2iS0rBCX51qEakFMl9FHt7uosO7BG7ZYYboYJov3Nn0m y81O1qxg1lrrtTt//LG43gBzu2rZPPLcsMMVBy3rrBdeNB5Icx/dsejtjf54YCUr5uXfpjOn6cr9 /TuYwV0rLifjrJu0c2eUE8nz7kdtLjGSEUO8UIXlgUx6iXkhivveT7NonMlhC66mp8/GHpjXtjde Q+OMe7298wVtNS2RccZp9qtvl/bzQcXDGraju33s6PhfjWlY3/mDRY9A/v8vPZHZ1OCi5ZjFgQ98 QGrcAm93u/HpDmdw4tbuxsaqmhyJff8O6pPPTCM/g9jGQ/cbzHCiBzicALAG9PDfClVYg2/Q4xvX qdF/nmOj0GzvRwx0HLYeCMEiKaxV6VvV79Y3vPilhTXjGpf8FrWxEXZpZILxnwxVKEMWfkOGWhSN vmwILdGQCoHeG6MDBwI+5/nOcpv51gRv8rMkJpE7EYuj6ZQHRZuxMIAsjCEVYZjFFG4RNPtCk/Vw qLgF0m6MBBEf7hKkqghSUFW921FOIBRHQJlmVnfcJB4HksIXqjCGV+yjKEFZxdDQ0HCiCR8rz6jI M/rwcRdEm+94F7DzAW+ObHvQ2zjpy6a1MJQrhKEoWxhDFwZzIFmkDQF/w0hXbq+Mipz/pt4cScmF SdAglnOYJg8Cx/j9MpwgWyE5tXhMLBaTjwQJ5Aij6T1Gdm2a0YSnLCV5tmy2qpZJ+dOfQkJHcQKU S3kM5jABaFBT/vGYygTlHRO4SDKG751kRGOo2mg+86HPK91EHoQC6tEyGTSkwoThSFuYUHVW8ZT3 S6BDF9nKlrJOktbcWRqHqM+wkKYsH90psbCYRWKSk4rGVGcpX8hOgySgIElFWESbOlEHutJ0aZQc +Sp3IN01BlA83eqJyOnC/wHSq8RcJknTaVSVInWpS61BAtpKLKfG84GxlCg9m0ZTUV2VpjmDJNq4 +pt9EASwfgWNVz1ZVmJasazGNOr//1L6U7SylSBtnaxbUcVKicbVjOKbazWpZdWr6kmfGB3sYPYB WNMWRLCkneIn80hSP/70mGUFqwtVukzJRpatbqXsssrYVHdGlJpSJeK3IndT9ZXpGjVQLnOV27TT mja6gUXtasOSR4IEtbBUZGw5EZtYxyoVt5PNbVLX+tZWZvadnCVW3kIiUwNppnJu2uZ+rmHf5d6X uSCDbmprcNrq2qWwntyjVwkqTJQmlJ2Qpax5BVLeBnMpuLSDKkTreqkQmaiCt8zrNel7J/s617nL HbG2qDsQ1P43xQD2SjIBeEVkhlSoQQ2lMM8qEBkyWLe6fbCOzwvVZ25WuOy1m6MiSP9V+D5ytCfS r0CaG+ImixhVqpWuQAQLXdWuOCmLvbFivxrKPwLVxUVV5ikru9szO3i8loWmXC28LhFm+Hz2DGIF QxWk/N4XylAOcZQfFV3+YvnPJs7yV5JJVoSik6CjTOaNezwQtZp5vOVds2aDvF5UNc9KDMvoEClY RAaBeCB51u+om7wsK1dZuv9N9aAJTRMDu/ir2fWjFYdZa3UutMxp1vFaK+tgyz5UvRNN3oeCJRJW WceanAY1k/FLkGY3+9RWNjGK+euVlHK1wJ78cmyN6UcZ3xiQjYb0r3nM48hC+E7SNKPNMMwxbUay uALra31JDOJQ49fJ9iZWoE/8Z///nhgsp4RsQAls0oGC9ZQmfWFQHyveX/fY1xKPF0uF3G74bJpH xu0RcpeMbxLrWdR49jOVAf7vf/t31V8Z+G0LfmDE2lqxA/Uutxlqc0ifm9c7dnVokNZeknx23nd+ dp6d/XGj95lLq1YxwKuc8qYf5bbYJrgvDX5wmZfS1ntE7MCNemZyIxXd6ea5YBD1c23OdHIfDjWp 863n5j67TNN2OtRZbXIs0wTbjDWlzcOZQm0PNYDd3m5Ru15FCE8a3bldPNkdozSAxVfjSpaPk9su cmcb3dRytzbT6S5wh5N57x4N/LcZG1uGj7LRnwQ9uc/dazU3vjFPtF/ulP0ofOdX//PRzj3cSU5d QT8d+Dl5rNRNP/rszpjh4QZlMRVe+LRCvNfkZXzsZY+lcFpe8yNme76TviC8/77fdcd7TQ6td9GL M/mo5zaurZhw8x915w+eNG+rb/+a9B7PpC719osunwMYhKCBX/BV2/CRWcuRFdVx0kCZ1Led0x8x XDmVEugR3G492gXeXwaSxO49mb3xHp+BHHYA4AEAYGA1Xef1F/lFXaMh1Ee12HYBFYzJGpfxXcuJ hFoxnq9p4A6amr5VXgi6nahdBwkSYQ2UYAmm2tOlHKAJX9QVX9dl2yfRWEExX+nJlg1WYIPlGA9y YdwVBJONXPf1oAiOIEEgYcD52/USniAaDp8WJaAb2uBOGRpQwVZBjdU69R305WAX8qFIHB3mCeHu /cYIkqBAnOEZqpq1eZ4K3oQb1mAeuuBizdrVidU6xSFJ5FwfdqEPZl4Pjhz3DaIRmmEhjsTcVZsi ruBZ6Z0CHt9B0RYdhl78aeIs0gQY7pmIQdu9aV9yFOIRimIABpwphkUgESOAHRRZkZIs0uIy4kQH hpzI+V/vhSIRnmFJnCKKBQYctuCKEdgyKRSXXSIziuMGup0tXl7R/WFolOE6GmE1ioSqNcYWsSLZ yeM42mNSHN3+AaIIGqI73uM/AuSleN8XIh0Q8iIhtqM/3mNAAAA7 ------=_NextPart_000_0003_01C71E17.27668620-- From ips-bounces@ietf.org Tue Dec 12 08:03:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gu7HT-0002GA-M1; Tue, 12 Dec 2006 08:02:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gu7HT-0002G2-8b for ips@ietf.org; Tue, 12 Dec 2006 08:02:47 -0500 Received: from mtagate6.de.ibm.com ([195.212.29.155]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gu7HQ-0004D9-S6 for ips@ietf.org; Tue, 12 Dec 2006 08:02:47 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate6.de.ibm.com (8.13.8/8.13.8) with ESMTP id kBCD2hpm172842 for ; Tue, 12 Dec 2006 13:02:43 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id kBCD2hjM2334802 for ; Tue, 12 Dec 2006 14:02:43 +0100 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id kBCD2h0g030999 for ; Tue, 12 Dec 2006 14:02:43 +0100 Received: from d12mc102.megacenter.de.ibm.com (d12mc102.megacenter.de.ibm.com [9.149.167.114]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id kBCD2hNA030995; Tue, 12 Dec 2006 14:02:43 +0100 In-Reply-To: To: Black_David@emc.com MIME-Version: 1.0 Subject: RE: [Ips] Implementer's Guide - Task Management Issue X-Mailer: Lotus Notes Release 7.0.2 September 26, 2006 From: Julian Satran Message-ID: Date: Tue, 12 Dec 2006 15:02:42 +0200 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 7.0.2HF71 | November 3, 2006) at 12/12/2006 15:02:43, Serialize complete at 12/12/2006 15:02:43 X-Spam-Score: 0.5 (/) X-Scan-Signature: b94423d57458a72e07b422b40e685d94 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="===============0367812398==" Errors-To: ips-bounces@ietf.org This is a multipart message in MIME format. --===============0367812398== Content-Type: multipart/alternative; boundary="=_alternative 002AE65DC2257242_=" This is a multipart message in MIME format. --=_alternative 002AE65DC2257242_= Content-Type: text/plain; charset="US-ASCII" David and Mallikarjun, I had a long discussion with Mallikarjun on a part of this problem - namely cleaning the T-2-I path. This could be done in several ways and Mallikarjun and I where also playing with sending the closing TM response on all connections as a way to speed up pipe cleaning. As for the issue raised by Bill Studemund I am not sure that the target needs help in recovering buffers (and I am not sure that I am not repeating what I said already in he past). As TTT is a target conceived artifact - buffers can be retired and the target can refrain from reusing the TTT with the given ITTs for some time (the rules must be quite simple). If data arrives with the bad combination - it is just discarded at the target. This ways TMF can be sent early - regardless of oustanding data - provided that the target respects some simple rules for TTT use/reuse. Considering also that TTTs are also not mandated to be unique beyond a single LUN - buffer retirement while an issue can be solved within 3270. Regards, Julo Black_David@emc.com 11/12/06 20:56 To , cc Subject RE: [Ips] Implementer's Guide - Task Management Issue Mallikarjun, [NB: Working group chair hat is **off**.] > "I assume this is essentially what you are proposing that we > consider (fast multi-task abort with outstanding TTTs always, > even without the key negotiation)." Not exactly - comments interspersed below, but what I'm proposing is that in the absence of negotiation of the new key, the portion of "fast multi-task abort" that allows the TMF response to be returned in the face of outstanding TTTs be allowed *only* for transfers from initiators *other* than the one that sent the TMF. I believe that Bill Studemund raised this concern earlier, but I admit to missing its significance at the time. In other words when the key is not negotiated, a TMF that aborts tasks from multiple initiators behaves differently at the target with respect to the initiators involved: a) There can be no change to currently specified behavior with respect to the sender of the TMF. All TTT transfers have to complete, and the TMF response cannot be sent until the transfers are complete, otherwise a 3720-compliant initiator may see something that it doesn't expect. b) Transfers from other initiators may be bit-bucketed early at the target - this would be new behavior, and new language would be needed to allow the TMF response to be sent once these transfers from other initiators are redirected to bit-buckets. This does not affect a 3720-compliant initiator, as these other initiators do not receive a response to this TMF. The only change is the latter, and it has the effect of removing a cross-initiator dependence for completion of the TMF. The use case is that there is still cluster software out there using TMFs to maintain cluster membership instead of persistent reservations, even though the latter is what should be used. > Sorry for the delay in getting back. Between vacation and > other travel, it took me a while. Thanks for the comments. > > You wrote this regarding fast multi-task abort: > >This property is > >useful even if the new key is not negotiated (and hence the > >AsyncEvent 5 message is not used for fast abort of data transfers) > > I assume this is essentially what you are proposing that we > consider (fast multi-task abort with outstanding TTTs always, > even without the key negotiation). Not exactly, see above. > The reason we decided a new key is needed here was for two reasons: > 1. Whenever TMF does a fast completion, target needs an > (eventual) deterministic confirmation that data transfers had > stopped. The confirmation is Nop-Out, and the negotiation > for the new Nop-Out is via the FastMultiTaskAbort key. > 2. The initiator requirement in the "classic" case (i.e. key > not negotiated) is that it respond to each TTT for affected > tasks even while the task is "affected". We wanted an > opposite behavior, but with a confirmation that the data > transfers had stopped (so target can recover the buffer > resources). The key allows this new behavior on initiator's > part as well. I agree that the new key is clearly required in order to terminate any TTT data transfer from any initiator early for the above reasons. The proposal is that the TMF response be allowed to be sent in the face of outstanding transfers from initiators *other* than the one that sent the TMF. This does not appear to require a new key be negotiated with the *other* initiators, as (in the absence of a failure) they will complete those transfers normally. > >This is approximately > >what is described in the Implementation Note at the end of > >Section 4.1.3, although that note may have been intended to > >be iSER-specific - if so, this is a proposal to apply it to > >iSCSI without the RDMA extensions. > > Actually the note is intended for all iSCSI implementations. > After seeing your observation, I decided that it needs > improvement, I propose the following new text: > > "Implementation note: Technically, the TMF servicing is > complete in Step.e. Data transfers corresponding to > terminated tasks may however still be in progress even at the > end of Step.f. TMF Response MUST NOT be sent by the target > iSCSI layer before the end of Step.e, and may be sent at the > end of Step.e despite these outstanding Data transfers until > Step.g. Nit: "may be sent" --> "MAY be sent" > These data transfers, if any, MUST be silently > discarded by the target iSCSI layer. In the case of > iSCSI/iSER, these transfers would be into tagged buffers with > STags not owned by any active tasks. I suggest adding: "; other implementations would deploy analogous resources to support this discarding". > Step.g specifies an > event to free up the resources. A target may, on an > implementation-defined internal timeout, also choose to drop > the connections on which it did not receive the expected > Nop-Out acknowledgements so as to reclaim the associated > buffer, STag and TTT resources as appropriate." Nit: "A target may" --> "A target MAY" > Now that I read the text after a long time, I spotted an > unintended double negative in section 4.1.3, target behavior, > bullet d-ii. The text should read: > "ii) each connection except the issuing connection of the > issuing session that has at least one allegiant affected > task." (i.e. drop "non" from "non-issuing") Ok. > The other thing that came to my mind after reading your note > is that we don't currently have a generic key to capture the > Response Fence behavior - although response fencing underlies > both the fast multi-task abort as well as addressing ACA race > conditions (and perhaps others down the road. e.g. around > persistent reservations). So, today, the Note at the end of > section 3.3.3 advises that implementations may check the > FastMultiTaskAbort key to verify if safe behavior for MCS ACA > is supported, although ACA has really nothing to do with > multi-task aborting. I am wondering if we should create a > new key (say ResponseFence), so the semantics would become: > > ResponseFence "Yes" fencing done by target > "No" legacy, no fencing > (so "clarified" TMF semantics are not possible either) > > With ResponseFence= "Yes" > FastMultiTaskAbort > "Yes" fast abort & fencing > "No" traditional wait on > outstanding TTTs (fencing on ACA is still possible) > > With ResponseFence= "No" > FastMultiTaskAbort > "Yes" Illegal, Response Fence must be "Yes" > "No" No fencing, must wait on > outstanding TTTs > > > The downside of this scheme is that it may be going in the > opposite direction than you wanted (introduces a second key > that 3720-compliant implementations don't know about). We > could alternatively simply mandate the behavior equivalent to > ResponseFence = "Yes" always and avoid the second key, but > doing so could make the current 3720-compliant > implementations technically non-iSCSI-compliant. > > Comments? Given the inter-dependence of ResponseFence and FastMultiTaskAbort, a single 3-valued key is probably simpler than two boolean keys. I think having an explicit means of determining whether ACA behaves correctly on an multi-connection-session is worth adding. Thanks, --David > Mallikarjun > > ----- Original Message ---- > From: "Black_David@emc.com" > To: ips@ietf.org > Cc: Black_David@emc.com > Sent: Wednesday, November 22, 2006 2:00:25 PM > Subject: [Ips] Implementer's Guide - Task Management Issue > > > To make sure we actually have some content to talk about in > this WG Last Call, I'm going to reraise an issue that came > up earlier on the mailing list, but (as far as I can recall) > never got resolved. This is done with my WG chair hat OFF, > and it is a proposal for further discussion. > > Section 4.1.3 changes task management, and is a non-transparent > change - it requires negotiating a new key so that both sides > agree that they support the change as it uses a round-trip > exchange of a new message (AsyncEvent 5) between initiator and > target to abort in-progress data transfers rather than completing > them. Absent this message, the target expects the initiator(s) > to complete all in-progress transfers, and is entitled to be > unhappy or worse if that doesn't happen. > > For task management functions that affect tasks from more than > one initiator (CLEAR TASK SET, TARGET WARM RESET, TARGET COLD > RESET) Section 4.1.3 also allows the task management function > (TMF) to complete while the in-progress data transfers are still > being dealt with, which has the useful effect of avoiding a > situation in which an uncooperative initiator can stall the > progress of a TMF sent by another initiator. This property is > useful even if the new key is not negotiated (and hence the > AsyncEvent 5 message is not used for fast abort of data transfers) > although I think the target behavior is subtly different between > the initiator that sent the TMF and other initiators in this case: > - For the TMF sender, the target must wait for all outstanding > transfers to complete before completing the TMF, otherwise > the TMF completion comes back too early for an unmodified > initiator. > - For the other initiators, the data transfers can be immediately > redirected to bit buckets so the TMF can be completed without > waits beyond that for the TMF sender. This is approximately > what is described in the Implementation Note at the end of > Section 4.1.3, although that note may have been intended to > be iSER-specific - if so, this is a proposal to apply it to > iSCSI without the RDMA extensions. > > High Availability clustering environments in which TMFs are being > used to determine cluster membership (yes, there's code out there > that does this, even though everyone should be using PERSISTENT > RESERVE) are a specific situation where this helps, as having to > wait for a dead initiator to expire (the TCP connection(s) have > to timeout and get torn down) slows down cluster recovery from a > failure. This change in target behavior (to complete a TMF faster > if other initiators don't cooperate) should be transparent to > RFC 3720-compliant initiators, but RFC 3720 has to be modified > in order to allow it; the Implementer's Guide is a vehicle that > can make that modification. > > This is proposed for further discussion. > > 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 --=_alternative 002AE65DC2257242_= Content-Type: text/html; charset="US-ASCII"
David and Mallikarjun,

I had a long discussion with Mallikarjun on a part of this problem - namely cleaning the T-2-I path.
This could be done in several ways and Mallikarjun and I where also playing with sending the closing TM response on all connections as a way to speed up pipe cleaning.

As for the issue raised by Bill Studemund I am not sure that the target needs help in recovering buffers (and I am not sure that I am not repeating what I said already in he past).
As TTT is a target conceived artifact - buffers can be retired and the target can refrain from reusing the TTT with the given ITTs for some time (the rules must be quite simple).
If data arrives with the bad combination - it is just discarded at the target.

This ways TMF can be sent early - regardless of oustanding data - provided that the target respects some simple rules for TTT use/reuse.
Considering also that TTTs are also not mandated to be unique beyond a single LUN - buffer retirement while an issue can be solved within 3270.

Regards,
Julo




Black_David@emc.com

11/12/06 20:56

To
<cb_mallikarjun@yahoo.com>, <ips@ietf.org>
cc
Subject
RE: [Ips] Implementer's Guide - Task Management Issue





Mallikarjun,

[NB: Working group chair hat is **off**.]

> "I assume this is essentially what you are proposing that we
> consider (fast multi-task abort with outstanding TTTs always,
> even without the key negotiation)."

Not exactly - comments interspersed below, but what I'm proposing
is that in the absence of negotiation of the new key, the portion
of "fast multi-task abort" that allows the TMF response to be
returned in the face of outstanding TTTs be allowed *only* for
transfers from initiators *other* than the one that sent the TMF.
I believe that Bill Studemund raised this concern earlier, but
I admit to missing its significance at the time.

In other words when the key is not negotiated, a TMF that aborts
tasks from multiple initiators behaves differently at the target
with respect to the initiators involved:
a) There can be no change to currently specified behavior with
                respect to the sender of the TMF.  All TTT transfers have
                to complete, and the TMF response cannot be sent until
                the transfers are complete, otherwise a 3720-compliant
                initiator may see something that it doesn't expect.
b) Transfers from other initiators may be bit-bucketed early at
                the target - this would be new behavior, and new language
                would be needed to allow the TMF response to be sent once
                these transfers from other initiators are redirected to
                bit-buckets.  This does not affect a 3720-compliant
                initiator, as these other initiators do not receive a
                response to this TMF.
The only change is the latter, and it has the effect of removing
a cross-initiator dependence for completion of the TMF.  The use
case is that there is still cluster software out there using TMFs
to maintain cluster membership instead of persistent reservations,
even though the latter is what should be used.

> Sorry for the delay in getting back.  Between vacation and
> other travel, it took me a while.  Thanks for the comments.
>
> You wrote this regarding fast multi-task abort:
> >This property is
> >useful even if the new key is not negotiated (and hence the
> >AsyncEvent 5 message is not used for fast abort of data transfers)
>
> I assume this is essentially what you are proposing that we
> consider (fast multi-task abort with outstanding TTTs always,
> even without the key negotiation).

Not exactly, see above.

> The reason we decided a new key is needed here was for two reasons:
> 1. Whenever TMF does a fast completion, target needs an
> (eventual) deterministic confirmation that data transfers had
> stopped.  The confirmation is Nop-Out, and the negotiation
> for the new Nop-Out is via the FastMultiTaskAbort key.
> 2. The initiator requirement in the "classic" case (i.e. key
> not negotiated) is that it respond to each TTT for affected
> tasks even while the task is "affected".  We wanted an
> opposite behavior, but with a confirmation that the data
> transfers had stopped (so target can recover the buffer
> resources).  The key allows this new behavior on initiator's
> part as well.

I agree that the new key is clearly required in order to
terminate any TTT data transfer from any initiator early
for the above reasons.

The proposal is that the TMF response be allowed to be sent
in the face of outstanding transfers from initiators *other*
than the one that sent the TMF.  This does not appear to
require a new key be negotiated with the *other* initiators,
as (in the absence of a failure) they will complete those
transfers normally.

> >This is approximately
> >what is described in the Implementation Note at the end of
> >Section 4.1.3, although that note may have been intended to
> >be iSER-specific - if so, this is a proposal to apply it to
> >iSCSI without the RDMA extensions.
>
> Actually the note is intended for all iSCSI implementations.  
> After seeing your observation, I decided that it needs
> improvement, I propose the following new text:
>
> "Implementation note: Technically, the TMF servicing is
> complete in Step.e.  Data transfers corresponding to
> terminated tasks may however still be in progress even at the
> end of Step.f.  TMF Response MUST NOT be sent by the target
> iSCSI layer before the end of Step.e, and may be sent at the
> end of Step.e despite these outstanding Data transfers until
> Step.g.

Nit: "may be sent" --> "MAY be sent"

> These data transfers, if any, MUST be silently
> discarded by the target iSCSI layer.  In the case of
> iSCSI/iSER, these transfers would be into tagged buffers with
> STags not owned by any active tasks.

I suggest adding: "; other implementations would deploy
analogous resources to support this discarding".

> Step.g specifies an
> event to free up the resources.  A target may, on an
> implementation-defined internal timeout, also choose to drop
> the connections on which it did not receive the expected
> Nop-Out acknowledgements so as to reclaim the associated
> buffer, STag and TTT resources as appropriate."

Nit: "A target may" --> "A target MAY"

> Now that I read the text after a long time, I spotted an
> unintended double negative in section 4.1.3, target behavior,
> bullet d-ii.  The text should read:
> "ii) each connection except the issuing connection of the
> issuing session that has at least one allegiant affected
> task."    (i.e. drop "non" from "non-issuing")

Ok.

> The other thing that came to my mind after reading your note
> is that we don't currently have a generic key to capture the
> Response Fence behavior - although response fencing underlies
> both the fast multi-task abort as well as addressing ACA race
> conditions (and perhaps others down the road. e.g. around
> persistent reservations).  So, today, the Note at the end of
> section 3.3.3 advises that implementations may check the
> FastMultiTaskAbort key to verify if safe behavior for MCS ACA
> is supported, although ACA has really nothing to do with
> multi-task aborting.  I am wondering if we should create a
> new key (say ResponseFence), so the semantics would become:
>                                                                      
>        ResponseFence    "Yes"  fencing done by target      
>                                    "No"   legacy, no fencing
> (so "clarified" TMF semantics are not possible either)
>        
> With ResponseFence=    "Yes"
> FastMultiTaskAbort    
>       "Yes"                   fast abort & fencing              
>        "No"                    traditional wait on
> outstanding TTTs (fencing on ACA is still possible)
>
> With ResponseFence=    "No"
> FastMultiTaskAbort    
>       "Yes"                   Illegal, Response Fence must be "Yes"
>        "No"                    No fencing, must wait on
> outstanding TTTs
>  
>
> The downside of this scheme is that it may be going in the
> opposite direction than you wanted (introduces a second key
> that 3720-compliant implementations don't know about).  We
> could alternatively simply mandate the behavior equivalent to
> ResponseFence = "Yes" always and avoid the second key, but
> doing so could make the current 3720-compliant
> implementations technically non-iSCSI-compliant.
>
> Comments?

Given the inter-dependence of ResponseFence and FastMultiTaskAbort,
a single 3-valued key is probably simpler than two boolean keys.
I think having an explicit means of determining whether ACA behaves
correctly on an multi-connection-session is worth adding.

Thanks,
--David

> Mallikarjun                            
>
> ----- Original Message ----
> From: "Black_David@emc.com" <Black_David@emc.com>
> To: ips@ietf.org
> Cc: Black_David@emc.com
> Sent: Wednesday, November 22, 2006 2:00:25 PM
> Subject: [Ips] Implementer's Guide - Task Management Issue
>
>
> To make sure we actually have some content to talk about in
> this WG Last Call, I'm going to reraise an issue that came
> up earlier on the mailing list, but (as far as I can recall)
> never got resolved.  This is done with my WG chair hat OFF,
> and it is a proposal for further discussion.
>
> Section 4.1.3 changes task management, and is a non-transparent
> change - it requires negotiating a new key so that both sides
> agree that they support the change as it uses a round-trip
> exchange of a new message (AsyncEvent 5) between initiator and
> target to abort in-progress data transfers rather than completing
> them.  Absent this message, the target expects the initiator(s)
> to complete all in-progress transfers, and is entitled to be
> unhappy or worse if that doesn't happen.
>
> For task management functions that affect tasks from more than
> one initiator (CLEAR TASK SET, TARGET WARM RESET, TARGET COLD
> RESET)  Section 4.1.3 also allows the task management function
> (TMF) to complete while the in-progress data transfers are still
> being dealt with, which has the useful effect of avoiding a
> situation in which an uncooperative initiator can stall the
> progress of a TMF sent by another initiator.  This property is
> useful even if the new key is not negotiated (and hence the
> AsyncEvent 5 message is not used for fast abort of data transfers)
> although I think the target behavior is subtly different between
> the initiator that sent the TMF and other initiators in this case:
> - For the TMF sender, the target must wait for all outstanding
>     transfers to complete before completing the TMF, otherwise
>     the TMF completion comes back too early for an unmodified
>     initiator.
> - For the other initiators, the data transfers can be immediately
>     redirected to bit buckets so the TMF can be completed without
>     waits beyond that for the TMF sender.  This is approximately
>     what is described in the Implementation Note at the end of
>     Section 4.1.3, although that note may have been intended to
>     be iSER-specific - if so, this is a proposal to apply it to
>     iSCSI without the RDMA extensions.
>
> High Availability clustering environments in which TMFs are being
> used to determine cluster membership (yes, there's code out there
> that does this, even though everyone should be using PERSISTENT
> RESERVE) are a specific situation where this helps, as having to
> wait for a dead initiator to expire (the TCP connection(s) have
> to timeout and get torn down) slows down cluster recovery from a
> failure.  This change in target behavior (to complete a TMF faster
> if other initiators don't cooperate) should be transparent to
> RFC 3720-compliant initiators, but RFC 3720 has to be modified
> in order to allow it; the Implementer's Guide is a vehicle that
> can make that modification.
>
> This is proposed for further discussion.
>
> 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
--=_alternative 002AE65DC2257242_=-- --===============0367812398== 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 --===============0367812398==-- From ips-bounces@ietf.org Tue Dec 12 08:08:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gu7Mj-0004LP-FT; Tue, 12 Dec 2006 08:08:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gu7Mh-0004Kv-2N for ips@ietf.org; Tue, 12 Dec 2006 08:08:11 -0500 Received: from mtagate2.de.ibm.com ([195.212.29.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gu7Hb-0004Ft-R6 for ips@ietf.org; Tue, 12 Dec 2006 08:02:57 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate2.de.ibm.com (8.13.8/8.13.8) with ESMTP id kBCD2oBx113896 for ; Tue, 12 Dec 2006 13:02:53 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id kBCD2iDY1441988 for ; Tue, 12 Dec 2006 14:02:44 +0100 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id kBCD2iY0021771 for ; Tue, 12 Dec 2006 14:02:44 +0100 Received: from d12mc102.megacenter.de.ibm.com (d12mc102.megacenter.de.ibm.com [9.149.167.114]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id kBCD2iP0021764; Tue, 12 Dec 2006 14:02:44 +0100 To: Black_David@emc.com MIME-Version: 1.0 Subject: Fw: [Ips] Implementer's Guide - Task Management Issue X-Mailer: Lotus Notes Release 7.0.2 September 26, 2006 From: Julian Satran Message-ID: Date: Tue, 12 Dec 2006 15:02:43 +0200 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 7.0.2HF71 | November 3, 2006) at 12/12/2006 15:02:44, Serialize complete at 12/12/2006 15:02:44 X-Spam-Score: 0.1 (/) X-Scan-Signature: e4e7b084ad5ab70bec6636d1707b49c1 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="===============1257795034==" Errors-To: ips-bounces@ietf.org This is a multipart message in MIME format. --===============1257795034== Content-Type: multipart/alternative; boundary="=_alternative 002BFEFFC2257242_=" This is a multipart message in MIME format. --=_alternative 002BFEFFC2257242_= Content-Type: text/plain; charset="US-ASCII" oops... In my previous note I should have said: .... sending the TM request and the closing TM response on all connections as a (3270 compiant) way to speed up pipe cleaning. Julo ----- Forwarded by Julian Satran/Haifa/IBM on 12/12/06 09:57 ----- Julian Satran/Haifa/IBM 12/12/06 09:48 To cc cb_mallikarjun@yahoo.com, ips@ietf.org Subject RE: [Ips] Implementer's Guide - Task Management Issue David and Mallikarjun, I had a long discussion with Mallikarjun on a part of this problem - namely cleaning the T-2-I path. This could be done in several ways and Mallikarjun and I where also playing with sending the closing TM response on all connections as a way to speed up pipe cleaning. As for the issue raised by Bill Studemund I am not sure that the target needs help in recovering buffers (and I am not sure that I am not repeating what I said already in he past). As TTT is a target conceived artifact - buffers can be retired and the target can refrain from reusing the TTT with the given ITTs for some time (the rules must be quite simple). If data arrives with the bad combination - it is just discarded at the target. This ways TMF can be sent early - regardless of oustanding data - provided that the target respects some simple rules for TTT use/reuse. Considering also that TTTs are also not mandated to be unique beyond a single LUN - buffer retirement while an issue can be solved within 3270. Regards, Julo Black_David@emc.com 11/12/06 20:56 To , cc Subject RE: [Ips] Implementer's Guide - Task Management Issue Mallikarjun, [NB: Working group chair hat is **off**.] > "I assume this is essentially what you are proposing that we > consider (fast multi-task abort with outstanding TTTs always, > even without the key negotiation)." Not exactly - comments interspersed below, but what I'm proposing is that in the absence of negotiation of the new key, the portion of "fast multi-task abort" that allows the TMF response to be returned in the face of outstanding TTTs be allowed *only* for transfers from initiators *other* than the one that sent the TMF. I believe that Bill Studemund raised this concern earlier, but I admit to missing its significance at the time. In other words when the key is not negotiated, a TMF that aborts tasks from multiple initiators behaves differently at the target with respect to the initiators involved: a) There can be no change to currently specified behavior with respect to the sender of the TMF. All TTT transfers have to complete, and the TMF response cannot be sent until the transfers are complete, otherwise a 3720-compliant initiator may see something that it doesn't expect. b) Transfers from other initiators may be bit-bucketed early at the target - this would be new behavior, and new language would be needed to allow the TMF response to be sent once these transfers from other initiators are redirected to bit-buckets. This does not affect a 3720-compliant initiator, as these other initiators do not receive a response to this TMF. The only change is the latter, and it has the effect of removing a cross-initiator dependence for completion of the TMF. The use case is that there is still cluster software out there using TMFs to maintain cluster membership instead of persistent reservations, even though the latter is what should be used. > Sorry for the delay in getting back. Between vacation and > other travel, it took me a while. Thanks for the comments. > > You wrote this regarding fast multi-task abort: > >This property is > >useful even if the new key is not negotiated (and hence the > >AsyncEvent 5 message is not used for fast abort of data transfers) > > I assume this is essentially what you are proposing that we > consider (fast multi-task abort with outstanding TTTs always, > even without the key negotiation). Not exactly, see above. > The reason we decided a new key is needed here was for two reasons: > 1. Whenever TMF does a fast completion, target needs an > (eventual) deterministic confirmation that data transfers had > stopped. The confirmation is Nop-Out, and the negotiation > for the new Nop-Out is via the FastMultiTaskAbort key. > 2. The initiator requirement in the "classic" case (i.e. key > not negotiated) is that it respond to each TTT for affected > tasks even while the task is "affected". We wanted an > opposite behavior, but with a confirmation that the data > transfers had stopped (so target can recover the buffer > resources). The key allows this new behavior on initiator's > part as well. I agree that the new key is clearly required in order to terminate any TTT data transfer from any initiator early for the above reasons. The proposal is that the TMF response be allowed to be sent in the face of outstanding transfers from initiators *other* than the one that sent the TMF. This does not appear to require a new key be negotiated with the *other* initiators, as (in the absence of a failure) they will complete those transfers normally. > >This is approximately > >what is described in the Implementation Note at the end of > >Section 4.1.3, although that note may have been intended to > >be iSER-specific - if so, this is a proposal to apply it to > >iSCSI without the RDMA extensions. > > Actually the note is intended for all iSCSI implementations. > After seeing your observation, I decided that it needs > improvement, I propose the following new text: > > "Implementation note: Technically, the TMF servicing is > complete in Step.e. Data transfers corresponding to > terminated tasks may however still be in progress even at the > end of Step.f. TMF Response MUST NOT be sent by the target > iSCSI layer before the end of Step.e, and may be sent at the > end of Step.e despite these outstanding Data transfers until > Step.g. Nit: "may be sent" --> "MAY be sent" > These data transfers, if any, MUST be silently > discarded by the target iSCSI layer. In the case of > iSCSI/iSER, these transfers would be into tagged buffers with > STags not owned by any active tasks. I suggest adding: "; other implementations would deploy analogous resources to support this discarding". > Step.g specifies an > event to free up the resources. A target may, on an > implementation-defined internal timeout, also choose to drop > the connections on which it did not receive the expected > Nop-Out acknowledgements so as to reclaim the associated > buffer, STag and TTT resources as appropriate." Nit: "A target may" --> "A target MAY" > Now that I read the text after a long time, I spotted an > unintended double negative in section 4.1.3, target behavior, > bullet d-ii. The text should read: > "ii) each connection except the issuing connection of the > issuing session that has at least one allegiant affected > task." (i.e. drop "non" from "non-issuing") Ok. > The other thing that came to my mind after reading your note > is that we don't currently have a generic key to capture the > Response Fence behavior - although response fencing underlies > both the fast multi-task abort as well as addressing ACA race > conditions (and perhaps others down the road. e.g. around > persistent reservations). So, today, the Note at the end of > section 3.3.3 advises that implementations may check the > FastMultiTaskAbort key to verify if safe behavior for MCS ACA > is supported, although ACA has really nothing to do with > multi-task aborting. I am wondering if we should create a > new key (say ResponseFence), so the semantics would become: > > ResponseFence "Yes" fencing done by target > "No" legacy, no fencing > (so "clarified" TMF semantics are not possible either) > > With ResponseFence= "Yes" > FastMultiTaskAbort > "Yes" fast abort & fencing > "No" traditional wait on > outstanding TTTs (fencing on ACA is still possible) > > With ResponseFence= "No" > FastMultiTaskAbort > "Yes" Illegal, Response Fence must be "Yes" > "No" No fencing, must wait on > outstanding TTTs > > > The downside of this scheme is that it may be going in the > opposite direction than you wanted (introduces a second key > that 3720-compliant implementations don't know about). We > could alternatively simply mandate the behavior equivalent to > ResponseFence = "Yes" always and avoid the second key, but > doing so could make the current 3720-compliant > implementations technically non-iSCSI-compliant. > > Comments? Given the inter-dependence of ResponseFence and FastMultiTaskAbort, a single 3-valued key is probably simpler than two boolean keys. I think having an explicit means of determining whether ACA behaves correctly on an multi-connection-session is worth adding. Thanks, --David > Mallikarjun > > ----- Original Message ---- > From: "Black_David@emc.com" > To: ips@ietf.org > Cc: Black_David@emc.com > Sent: Wednesday, November 22, 2006 2:00:25 PM > Subject: [Ips] Implementer's Guide - Task Management Issue > > > To make sure we actually have some content to talk about in > this WG Last Call, I'm going to reraise an issue that came > up earlier on the mailing list, but (as far as I can recall) > never got resolved. This is done with my WG chair hat OFF, > and it is a proposal for further discussion. > > Section 4.1.3 changes task management, and is a non-transparent > change - it requires negotiating a new key so that both sides > agree that they support the change as it uses a round-trip > exchange of a new message (AsyncEvent 5) between initiator and > target to abort in-progress data transfers rather than completing > them. Absent this message, the target expects the initiator(s) > to complete all in-progress transfers, and is entitled to be > unhappy or worse if that doesn't happen. > > For task management functions that affect tasks from more than > one initiator (CLEAR TASK SET, TARGET WARM RESET, TARGET COLD > RESET) Section 4.1.3 also allows the task management function > (TMF) to complete while the in-progress data transfers are still > being dealt with, which has the useful effect of avoiding a > situation in which an uncooperative initiator can stall the > progress of a TMF sent by another initiator. This property is > useful even if the new key is not negotiated (and hence the > AsyncEvent 5 message is not used for fast abort of data transfers) > although I think the target behavior is subtly different between > the initiator that sent the TMF and other initiators in this case: > - For the TMF sender, the target must wait for all outstanding > transfers to complete before completing the TMF, otherwise > the TMF completion comes back too early for an unmodified > initiator. > - For the other initiators, the data transfers can be immediately > redirected to bit buckets so the TMF can be completed without > waits beyond that for the TMF sender. This is approximately > what is described in the Implementation Note at the end of > Section 4.1.3, although that note may have been intended to > be iSER-specific - if so, this is a proposal to apply it to > iSCSI without the RDMA extensions. > > High Availability clustering environments in which TMFs are being > used to determine cluster membership (yes, there's code out there > that does this, even though everyone should be using PERSISTENT > RESERVE) are a specific situation where this helps, as having to > wait for a dead initiator to expire (the TCP connection(s) have > to timeout and get torn down) slows down cluster recovery from a > failure. This change in target behavior (to complete a TMF faster > if other initiators don't cooperate) should be transparent to > RFC 3720-compliant initiators, but RFC 3720 has to be modified > in order to allow it; the Implementer's Guide is a vehicle that > can make that modification. > > This is proposed for further discussion. > > 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 --=_alternative 002BFEFFC2257242_= Content-Type: text/html; charset="US-ASCII"
oops...

In my previous note I should have said:

.... sending the TM request and  the closing TM response on all connections as a (3270 compiant) way to speed up pipe cleaning.

Julo

----- Forwarded by Julian Satran/Haifa/IBM on 12/12/06 09:57 -----
Julian Satran/Haifa/IBM

12/12/06 09:48

To
cc
cb_mallikarjun@yahoo.com, ips@ietf.org
Subject
RE: [Ips] Implementer's Guide - Task Management IssueLink




David and Mallikarjun,

I had a long discussion with Mallikarjun on a part of this problem - namely cleaning the T-2-I path.
This could be done in several ways and Mallikarjun and I where also playing with sending the closing TM response on all connections as a way to speed up pipe cleaning.

As for the issue raised by Bill Studemund I am not sure that the target needs help in recovering buffers (and I am not sure that I am not repeating what I said already in he past).
As TTT is a target conceived artifact - buffers can be retired and the target can refrain from reusing the TTT with the given ITTs for some time (the rules must be quite simple).
If data arrives with the bad combination - it is just discarded at the target.

This ways TMF can be sent early - regardless of oustanding data - provided that the target respects some simple rules for TTT use/reuse.
Considering also that TTTs are also not mandated to be unique beyond a single LUN - buffer retirement while an issue can be solved within 3270.

Regards,
Julo




Black_David@emc.com

11/12/06 20:56

To
<cb_mallikarjun@yahoo.com>, <ips@ietf.org>
cc
Subject
RE: [Ips] Implementer's Guide - Task Management Issue





Mallikarjun,

[NB: Working group chair hat is **off**.]

> "I assume this is essentially what you are proposing that we
> consider (fast multi-task abort with outstanding TTTs always,
> even without the key negotiation)."

Not exactly - comments interspersed below, but what I'm proposing
is that in the absence of negotiation of the new key, the portion
of "fast multi-task abort" that allows the TMF response to be
returned in the face of outstanding TTTs be allowed *only* for
transfers from initiators *other* than the one that sent the TMF.
I believe that Bill Studemund raised this concern earlier, but
I admit to missing its significance at the time.

In other words when the key is not negotiated, a TMF that aborts
tasks from multiple initiators behaves differently at the target
with respect to the initiators involved:
a) There can be no change to currently specified behavior with
                respect to the sender of the TMF.  All TTT transfers have
                to complete, and the TMF response cannot be sent until
                the transfers are complete, otherwise a 3720-compliant
                initiator may see something that it doesn't expect.
b) Transfers from other initiators may be bit-bucketed early at
                the target - this would be new behavior, and new language
                would be needed to allow the TMF response to be sent once
                these transfers from other initiators are redirected to
                bit-buckets.  This does not affect a 3720-compliant
                initiator, as these other initiators do not receive a
                response to this TMF.
The only change is the latter, and it has the effect of removing
a cross-initiator dependence for completion of the TMF.  The use
case is that there is still cluster software out there using TMFs
to maintain cluster membership instead of persistent reservations,
even though the latter is what should be used.

> Sorry for the delay in getting back.  Between vacation and
> other travel, it took me a while.  Thanks for the comments.
>
> You wrote this regarding fast multi-task abort:
> >This property is
> >useful even if the new key is not negotiated (and hence the
> >AsyncEvent 5 message is not used for fast abort of data transfers)
>
> I assume this is essentially what you are proposing that we
> consider (fast multi-task abort with outstanding TTTs always,
> even without the key negotiation).

Not exactly, see above.

> The reason we decided a new key is needed here was for two reasons:
> 1. Whenever TMF does a fast completion, target needs an
> (eventual) deterministic confirmation that data transfers had
> stopped.  The confirmation is Nop-Out, and the negotiation
> for the new Nop-Out is via the FastMultiTaskAbort key.
> 2. The initiator requirement in the "classic" case (i.e. key
> not negotiated) is that it respond to each TTT for affected
> tasks even while the task is "affected".  We wanted an
> opposite behavior, but with a confirmation that the data
> transfers had stopped (so target can recover the buffer
> resources).  The key allows this new behavior on initiator's
> part as well.

I agree that the new key is clearly required in order to
terminate any TTT data transfer from any initiator early
for the above reasons.

The proposal is that the TMF response be allowed to be sent
in the face of outstanding transfers from initiators *other*
than the one that sent the TMF.  This does not appear to
require a new key be negotiated with the *other* initiators,
as (in the absence of a failure) they will complete those
transfers normally.

> >This is approximately
> >what is described in the Implementation Note at the end of
> >Section 4.1.3, although that note may have been intended to
> >be iSER-specific - if so, this is a proposal to apply it to
> >iSCSI without the RDMA extensions.
>
> Actually the note is intended for all iSCSI implementations.  
> After seeing your observation, I decided that it needs
> improvement, I propose the following new text:
>
> "Implementation note: Technically, the TMF servicing is
> complete in Step.e.  Data transfers corresponding to
> terminated tasks may however still be in progress even at the
> end of Step.f.  TMF Response MUST NOT be sent by the target
> iSCSI layer before the end of Step.e, and may be sent at the
> end of Step.e despite these outstanding Data transfers until
> Step.g.

Nit: "may be sent" --> "MAY be sent"

> These data transfers, if any, MUST be silently
> discarded by the target iSCSI layer.  In the case of
> iSCSI/iSER, these transfers would be into tagged buffers with
> STags not owned by any active tasks.

I suggest adding: "; other implementations would deploy
analogous resources to support this discarding".

> Step.g specifies an
> event to free up the resources.  A target may, on an
> implementation-defined internal timeout, also choose to drop
> the connections on which it did not receive the expected
> Nop-Out acknowledgements so as to reclaim the associated
> buffer, STag and TTT resources as appropriate."

Nit: "A target may" --> "A target MAY"

> Now that I read the text after a long time, I spotted an
> unintended double negative in section 4.1.3, target behavior,
> bullet d-ii.  The text should read:
> "ii) each connection except the issuing connection of the
> issuing session that has at least one allegiant affected
> task."    (i.e. drop "non" from "non-issuing")

Ok.

> The other thing that came to my mind after reading your note
> is that we don't currently have a generic key to capture the
> Response Fence behavior - although response fencing underlies
> both the fast multi-task abort as well as addressing ACA race
> conditions (and perhaps others down the road. e.g. around
> persistent reservations).  So, today, the Note at the end of
> section 3.3.3 advises that implementations may check the
> FastMultiTaskAbort key to verify if safe behavior for MCS ACA
> is supported, although ACA has really nothing to do with
> multi-task aborting.  I am wondering if we should create a
> new key (say ResponseFence), so the semantics would become:
>                                                                      
>        ResponseFence    "Yes"  fencing done by target      
>                                    "No"   legacy, no fencing
> (so "clarified" TMF semantics are not possible either)
>        
> With ResponseFence=    "Yes"
> FastMultiTaskAbort    
>       "Yes"                   fast abort & fencing              
>        "No"                    traditional wait on
> outstanding TTTs (fencing on ACA is still possible)
>
> With ResponseFence=    "No"
> FastMultiTaskAbort    
>       "Yes"                   Illegal, Response Fence must be "Yes"
>        "No"                    No fencing, must wait on
> outstanding TTTs
>  
>
> The downside of this scheme is that it may be going in the
> opposite direction than you wanted (introduces a second key
> that 3720-compliant implementations don't know about).  We
> could alternatively simply mandate the behavior equivalent to
> ResponseFence = "Yes" always and avoid the second key, but
> doing so could make the current 3720-compliant
> implementations technically non-iSCSI-compliant.
>
> Comments?

Given the inter-dependence of ResponseFence and FastMultiTaskAbort,
a single 3-valued key is probably simpler than two boolean keys.
I think having an explicit means of determining whether ACA behaves
correctly on an multi-connection-session is worth adding.

Thanks,
--David

> Mallikarjun                            
>
> ----- Original Message ----
> From: "Black_David@emc.com" <Black_David@emc.com>
> To: ips@ietf.org
> Cc: Black_David@emc.com
> Sent: Wednesday, November 22, 2006 2:00:25 PM
> Subject: [Ips] Implementer's Guide - Task Management Issue
>
>
> To make sure we actually have some content to talk about in
> this WG Last Call, I'm going to reraise an issue that came
> up earlier on the mailing list, but (as far as I can recall)
> never got resolved.  This is done with my WG chair hat OFF,
> and it is a proposal for further discussion.
>
> Section 4.1.3 changes task management, and is a non-transparent
> change - it requires negotiating a new key so that both sides
> agree that they support the change as it uses a round-trip
> exchange of a new message (AsyncEvent 5) between initiator and
> target to abort in-progress data transfers rather than completing
> them.  Absent this message, the target expects the initiator(s)
> to complete all in-progress transfers, and is entitled to be
> unhappy or worse if that doesn't happen.
>
> For task management functions that affect tasks from more than
> one initiator (CLEAR TASK SET, TARGET WARM RESET, TARGET COLD
> RESET)  Section 4.1.3 also allows the task management function
> (TMF) to complete while the in-progress data transfers are still
> being dealt with, which has the useful effect of avoiding a
> situation in which an uncooperative initiator can stall the
> progress of a TMF sent by another initiator.  This property is
> useful even if the new key is not negotiated (and hence the
> AsyncEvent 5 message is not used for fast abort of data transfers)
> although I think the target behavior is subtly different between
> the initiator that sent the TMF and other initiators in this case:
> - For the TMF sender, the target must wait for all outstanding
>     transfers to complete before completing the TMF, otherwise
>     the TMF completion comes back too early for an unmodified
>     initiator.
> - For the other initiators, the data transfers can be immediately
>     redirected to bit buckets so the TMF can be completed without
>     waits beyond that for the TMF sender.  This is approximately
>     what is described in the Implementation Note at the end of
>     Section 4.1.3, although that note may have been intended to
>     be iSER-specific - if so, this is a proposal to apply it to
>     iSCSI without the RDMA extensions.
>
> High Availability clustering environments in which TMFs are being
> used to determine cluster membership (yes, there's code out there
> that does this, even though everyone should be using PERSISTENT
> RESERVE) are a specific situation where this helps, as having to
> wait for a dead initiator to expire (the TCP connection(s) have
> to timeout and get torn down) slows down cluster recovery from a
> failure.  This change in target behavior (to complete a TMF faster
> if other initiators don't cooperate) should be transparent to
> RFC 3720-compliant initiators, but RFC 3720 has to be modified
> in order to allow it; the Implementer's Guide is a vehicle that
> can make that modification.
>
> This is proposed for further discussion.
>
> 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
--=_alternative 002BFEFFC2257242_=-- --===============1257795034== 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 --===============1257795034==-- From ips-bounces@ietf.org Tue Dec 12 13:27:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuCLO-0005SK-6F; Tue, 12 Dec 2006 13:27:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuCLN-0005SF-Bm for ips@ietf.org; Tue, 12 Dec 2006 13:27:09 -0500 Received: from mexforward.lss.emc.com ([128.222.32.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuCLJ-0007xT-2Y for ips@ietf.org; Tue, 12 Dec 2006 13:27:09 -0500 Received: from mailhub.lss.emc.com (uraeus.lss.emc.com [10.254.144.14]) by mexforward.lss.emc.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id kBCIR0HR015871; Tue, 12 Dec 2006 13:27:02 -0500 (EST) Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id kBCIPKOQ018015; Tue, 12 Dec 2006 13:26:52 -0500 (EST) From: Black_David@emc.com Received: from CORPUSMX20A.corp.emc.com ([128.221.62.13]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Dec 2006 13:26:29 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ips] Implementer's Guide - Task Management Issue Date: Tue, 12 Dec 2006 13:26:28 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ips] Implementer's Guide - Task Management Issue Thread-Index: Accd7eB/u+NL13bARAmrkGc5efrBMwAKnPkw To: X-OriginalArrivalTime: 12 Dec 2006 18:26:29.0223 (UTC) FILETIME=[0A7C7F70:01C71E1B] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2006.12.12.91432 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -2, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0, __CTYPE_MULTIPART_ALT 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_HTML 0, __MIME_VERSION 0, __SANE_MSGID 0, __TAG_EXISTS_HTML 0' X-Spam-Score: 0.5 (/) X-Scan-Signature: a2ab14096843dab69630d256f59fc791 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="===============1082375114==" Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============1082375114== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C71E1B.0A20B25D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C71E1B.0A20B25D Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Julian, =20 > As for the issue raised by Bill Studemund I am not sure that the target needs help in > recovering buffers (and I am not sure that I am not repeating what I said already in he past).=20 =20 The motivating concern is not buffer recovery - it's the ability of an uncooperative initiator to delay completion of a TMF issued by a different initiator. Here's an example: =20 - Initiator A has one or more data transfers in progress to the target. - Initiator A dies in some inconvenient fashion. The target thinks the iSCSI session with Initiator A is still alive, but Initiator A is non-responsive. - Initiator B issues a TMF that has the effect of aborting Initiator A's tasks (e.g., CLEAR TASK SET). =20 The issue is: When can the target issue the TMF response to Initiator B? =20 Current RFC 3720 language requires completion of Initiator A's data transfers or timing out and dropping Initiator A's session - Section 10.5.1: "The target on its part MUST wait for responses on all affected target transfer tags before acting on either of these two task management requests". In this example, the data transfers will not complete, requiring timing out and dropping the session before the TMF response can be issued. =20 The request is that it be permissible for the target to redirect Initiator A's data transfers to bit-buckets (just in case Initiator A is not actually completely dead) and issue the TMF response once that redirection (as well as everything that RFC 3720 requires with respect to Initiator B) is done so that the TMF response doesn't have to wait for the target to time out and tear down the session with Initiator A. =20 Thanks, --David ----------------------------------------------------=20 David L. Black, Senior Technologist=20 EMC Corporation, 176 South St., Hopkinton, MA 01748=20 +1 (508) 293-7953 FAX: +1 (508) 293-7786=20 black_david@emc.com Mobile: +1 (978) 394-7754=20 ----------------------------------------------------=20 ________________________________ From: Julian Satran [mailto:Julian_Satran@il.ibm.com]=20 Sent: Tuesday, December 12, 2006 8:03 AM To: Black, David Cc: cb_mallikarjun@yahoo.com; ips@ietf.org Subject: RE: [Ips] Implementer's Guide - Task Management Issue =09 =09 David and Mallikarjun,=20 =09 I had a long discussion with Mallikarjun on a part of this problem - namely cleaning the T-2-I path.=20 This could be done in several ways and Mallikarjun and I where also playing with sending the closing TM response on all connections as a way to speed up pipe cleaning.=20 =09 As for the issue raised by Bill Studemund I am not sure that the target needs help in recovering buffers (and I am not sure that I am not repeating what I said already in he past).=20 As TTT is a target conceived artifact - buffers can be retired and the target can refrain from reusing the TTT with the given ITTs for some time (the rules must be quite simple).=20 If data arrives with the bad combination - it is just discarded at the target.=20 =09 This ways TMF can be sent early - regardless of oustanding data - provided that the target respects some simple rules for TTT use/reuse. Considering also that TTTs are also not mandated to be unique beyond a single LUN - buffer retirement while an issue can be solved within 3270.=20 =09 Regards,=20 Julo=20 =09 =09 =09 =09 =09 Black_David@emc.com=20 11/12/06 20:56=20 To , =20 cc Subject RE: [Ips] Implementer's Guide - Task Management Issue =09 Mallikarjun, =09 [NB: Working group chair hat is **off**.] =09 > "I assume this is essentially what you are proposing that we=20 > consider (fast multi-task abort with outstanding TTTs always,=20 > even without the key negotiation)." =09 Not exactly - comments interspersed below, but what I'm proposing is that in the absence of negotiation of the new key, the portion of "fast multi-task abort" that allows the TMF response to be returned in the face of outstanding TTTs be allowed *only* for transfers from initiators *other* than the one that sent the TMF. I believe that Bill Studemund raised this concern earlier, but I admit to missing its significance at the time. =09 In other words when the key is not negotiated, a TMF that aborts tasks from multiple initiators behaves differently at the target with respect to the initiators involved: a) There can be no change to currently specified behavior with respect to the sender of the TMF. All TTT transfers have to complete, and the TMF response cannot be sent until the transfers are complete, otherwise a 3720-compliant initiator may see something that it doesn't expect. b) Transfers from other initiators may be bit-bucketed early at the target - this would be new behavior, and new language would be needed to allow the TMF response to be sent once these transfers from other initiators are redirected to bit-buckets. This does not affect a 3720-compliant initiator, as these other initiators do not receive a response to this TMF. The only change is the latter, and it has the effect of removing a cross-initiator dependence for completion of the TMF. The use case is that there is still cluster software out there using TMFs to maintain cluster membership instead of persistent reservations, even though the latter is what should be used. =09 > Sorry for the delay in getting back. Between vacation and=20 > other travel, it took me a while. Thanks for the comments. >=20 > You wrote this regarding fast multi-task abort: > >This property is > >useful even if the new key is not negotiated (and hence the > >AsyncEvent 5 message is not used for fast abort of data transfers) >=20 > I assume this is essentially what you are proposing that we=20 > consider (fast multi-task abort with outstanding TTTs always,=20 > even without the key negotiation). =09 Not exactly, see above. =09 > The reason we decided a new key is needed here was for two reasons: > 1. Whenever TMF does a fast completion, target needs an=20 > (eventual) deterministic confirmation that data transfers had=20 > stopped. The confirmation is Nop-Out, and the negotiation=20 > for the new Nop-Out is via the FastMultiTaskAbort key. > 2. The initiator requirement in the "classic" case (i.e. key=20 > not negotiated) is that it respond to each TTT for affected=20 > tasks even while the task is "affected". We wanted an=20 > opposite behavior, but with a confirmation that the data=20 > transfers had stopped (so target can recover the buffer=20 > resources). The key allows this new behavior on initiator's=20 > part as well. =09 I agree that the new key is clearly required in order to terminate any TTT data transfer from any initiator early for the above reasons. =09 The proposal is that the TMF response be allowed to be sent in the face of outstanding transfers from initiators *other* than the one that sent the TMF. This does not appear to require a new key be negotiated with the *other* initiators, as (in the absence of a failure) they will complete those transfers normally. =09 > >This is approximately > >what is described in the Implementation Note at the end of > >Section 4.1.3, although that note may have been intended to > >be iSER-specific - if so, this is a proposal to apply it to > >iSCSI without the RDMA extensions. >=20 > Actually the note is intended for all iSCSI implementations. =20 > After seeing your observation, I decided that it needs=20 > improvement, I propose the following new text: >=20 > "Implementation note: Technically, the TMF servicing is=20 > complete in Step.e. Data transfers corresponding to=20 > terminated tasks may however still be in progress even at the=20 > end of Step.f. TMF Response MUST NOT be sent by the target=20 > iSCSI layer before the end of Step.e, and may be sent at the=20 > end of Step.e despite these outstanding Data transfers until=20 > Step.g. =09 Nit: "may be sent" --> "MAY be sent" =09 > These data transfers, if any, MUST be silently=20 > discarded by the target iSCSI layer. In the case of=20 > iSCSI/iSER, these transfers would be into tagged buffers with=20 > STags not owned by any active tasks. =09 I suggest adding: "; other implementations would deploy analogous resources to support this discarding". =09 > Step.g specifies an=20 > event to free up the resources. A target may, on an=20 > implementation-defined internal timeout, also choose to drop=20 > the connections on which it did not receive the expected=20 > Nop-Out acknowledgements so as to reclaim the associated=20 > buffer, STag and TTT resources as appropriate." =09 Nit: "A target may" --> "A target MAY" =09 > Now that I read the text after a long time, I spotted an=20 > unintended double negative in section 4.1.3, target behavior,=20 > bullet d-ii. The text should read: > "ii) each connection except the issuing connection of the=20 > issuing session that has at least one allegiant affected=20 > task." (i.e. drop "non" from "non-issuing") =09 Ok. =09 > The other thing that came to my mind after reading your note=20 > is that we don't currently have a generic key to capture the=20 > Response Fence behavior - although response fencing underlies=20 > both the fast multi-task abort as well as addressing ACA race=20 > conditions (and perhaps others down the road. e.g. around=20 > persistent reservations). So, today, the Note at the end of=20 > section 3.3.3 advises that implementations may check the=20 > FastMultiTaskAbort key to verify if safe behavior for MCS ACA=20 > is supported, although ACA has really nothing to do with=20 > multi-task aborting. I am wondering if we should create a=20 > new key (say ResponseFence), so the semantics would become: > > ResponseFence "Yes" fencing done by target =20 > "No" legacy, no fencing=20 > (so "clarified" TMF semantics are not possible either) > =20 > With ResponseFence=3D "Yes" > FastMultiTaskAbort =20 > "Yes" fast abort & fencing > "No" traditional wait on=20 > outstanding TTTs (fencing on ACA is still possible) >=20 > With ResponseFence=3D "No" > FastMultiTaskAbort =20 > "Yes" Illegal, Response Fence must be "Yes" > "No" No fencing, must wait on=20 > outstanding TTTs > =20 >=20 > The downside of this scheme is that it may be going in the=20 > opposite direction than you wanted (introduces a second key=20 > that 3720-compliant implementations don't know about). We=20 > could alternatively simply mandate the behavior equivalent to=20 > ResponseFence =3D "Yes" always and avoid the second key, but=20 > doing so could make the current 3720-compliant=20 > implementations technically non-iSCSI-compliant. >=20 > Comments? =09 Given the inter-dependence of ResponseFence and FastMultiTaskAbort, a single 3-valued key is probably simpler than two boolean keys. I think having an explicit means of determining whether ACA behaves correctly on an multi-connection-session is worth adding. =09 Thanks, --David=20 =09 > Mallikarjun =20 >=20 > ----- Original Message ---- > From: "Black_David@emc.com" > To: ips@ietf.org > Cc: Black_David@emc.com > Sent: Wednesday, November 22, 2006 2:00:25 PM > Subject: [Ips] Implementer's Guide - Task Management Issue >=20 >=20 > To make sure we actually have some content to talk about in > this WG Last Call, I'm going to reraise an issue that came > up earlier on the mailing list, but (as far as I can recall) > never got resolved. This is done with my WG chair hat OFF, > and it is a proposal for further discussion. >=20 > Section 4.1.3 changes task management, and is a non-transparent > change - it requires negotiating a new key so that both sides > agree that they support the change as it uses a round-trip > exchange of a new message (AsyncEvent 5) between initiator and > target to abort in-progress data transfers rather than completing > them. Absent this message, the target expects the initiator(s) > to complete all in-progress transfers, and is entitled to be > unhappy or worse if that doesn't happen. >=20 > For task management functions that affect tasks from more than > one initiator (CLEAR TASK SET, TARGET WARM RESET, TARGET COLD > RESET) Section 4.1.3 also allows the task management function > (TMF) to complete while the in-progress data transfers are still > being dealt with, which has the useful effect of avoiding a > situation in which an uncooperative initiator can stall the > progress of a TMF sent by another initiator. This property is > useful even if the new key is not negotiated (and hence the > AsyncEvent 5 message is not used for fast abort of data transfers) > although I think the target behavior is subtly different between > the initiator that sent the TMF and other initiators in this case: > - For the TMF sender, the target must wait for all outstanding > transfers to complete before completing the TMF, otherwise > the TMF completion comes back too early for an unmodified > initiator. > - For the other initiators, the data transfers can be immediately > redirected to bit buckets so the TMF can be completed without > waits beyond that for the TMF sender. This is approximately > what is described in the Implementation Note at the end of > Section 4.1.3, although that note may have been intended to > be iSER-specific - if so, this is a proposal to apply it to > iSCSI without the RDMA extensions. >=20 > High Availability clustering environments in which TMFs are being > used to determine cluster membership (yes, there's code out there > that does this, even though everyone should be using PERSISTENT > RESERVE) are a specific situation where this helps, as having to > wait for a dead initiator to expire (the TCP connection(s) have > to timeout and get torn down) slows down cluster recovery from a > failure. This change in target behavior (to complete a TMF faster > if other initiators don't cooperate) should be transparent to > RFC 3720-compliant initiators, but RFC 3720 has to be modified > in order to allow it; the Implementer's Guide is a vehicle that > can make that modification. >=20 > This is proposed for further discussion. >=20 > 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 > ---------------------------------------------------- =09 _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips =09 =09 ------_=_NextPart_001_01C71E1B.0A20B25D Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Julian,
 
> As for the issue raised by Bill = Studemund I am not=20 sure that the target needs help in
> recovering buffers (and I am not sure = that I am not=20 repeating what I said already in he past).
 
The motivating concern is not buffer recovery - it's the = ability of an=20 uncooperative initiator
to delay completion of a TMF issued by a different = initiator. =20 Here's an=20 example:
 
-=20 Initiator A has one or more data transfers in progress to = the=20 target.
-=20 Initiator A dies in some inconvenient fashion.  The target thinks = the=20 iSCSI
    session with Initiator A is still alive, but = Initiator A=20 is non-responsive.
- Initiator B=20 issues a TMF that has the effect of aborting Initiator=20 A's tasks
    (e.g., CLEAR TASK SET).
 
The issue is: When can the target issue the TMF response to = Initiator=20 B?
 
Current RFC 3720 language requires completion of Initiator A's = data=20 transfers or timing
out and dropping Initiator A's session - Section 10.5.1: "The target on its part MUST
wait for responses on all affected target = transfer tags=20 before acting on either of these
two task management requests".  In = this example,=20 the data transfers will not
complete, requiring timing out and dropping the session before the TMF=20 response
can be issued.
 
The request is that it be permissible for the target to = redirect=20 Initiator A's data transfers
to bit-buckets (just in case Initiator A is not actually = completely dead)=20 and issue the TMF
response once that redirection (as well as everything = that RFC=20 3720 requires with
respect to Initiator B) is done so that the TMF response = doesn't have to = wait for=20 the
target to time out and tear down the session with Initiator = A.
 
Thanks,
--David
----------------------------------------------------=20
David L. = Black, Senior=20 Technologist
EMC Corporation, 176 South St., Hopkinton, MA  = 01748=20
+1 (508)=20 293-7953           = ; =20 FAX: +1 (508) 293-7786
black_david@emc.com        = Mobile: +1=20 (978) 394-7754
----------------------------------------------------=20
From: Julian Satran=20 [mailto:Julian_Satran@il.ibm.com]
Sent: Tuesday, December = 12, 2006=20 8:03 AM
To: Black, David
Cc: = cb_mallikarjun@yahoo.com;=20 ips@ietf.org
Subject: RE: [Ips] Implementer's Guide - Task=20 Management Issue


David and = Mallikarjun,=20

I had a long discussion with = Mallikarjun=20 on a part of this problem - namely cleaning the T-2-I path. =
This could be done in several ways and = Mallikarjun and=20 I where also playing with sending the closing TM response on all = connections=20 as a way to speed up pipe cleaning.

As for the issue raised by Bill Studemund I am not sure that = the target=20 needs help in recovering buffers (and I am not sure that I am not = repeating=20 what I said already in he past).
As=20 TTT is a target conceived artifact - buffers can be retired and the = target can=20 refrain from reusing the TTT with the given ITTs for some time (the = rules must=20 be quite simple).
If data = arrives with=20 the bad combination - it is just discarded at the target. =

This ways TMF can be sent early - = regardless of=20 oustanding data - provided that the target respects some simple rules = for TTT=20 use/reuse.
Considering = also that TTTs=20 are also not mandated to be unique beyond a single LUN - buffer = retirement=20 while an issue can be solved within 3270.

Regards,
Julo=20




Black_David@emc.com=20

11/12/06 20:56

To
<cb_mallikarjun@yahoo.com>,=20 <ips@ietf.org>=20
cc
Subject
RE: [Ips] Implementer's = Guide -=20 Task Management Issue

=




Mallikarjun,

[NB: Working group chair hat is=20 **off**.]

> "I assume this is essentially what you are = proposing=20 that we
> consider (fast multi-task abort with outstanding TTTs = always,=20
> even without the key negotiation)."

Not exactly - = comments=20 interspersed below, but what I'm proposing
is that in the absence = of=20 negotiation of the new key, the portion
of "fast multi-task abort" = that=20 allows the TMF response to be
returned in the face of outstanding = TTTs be=20 allowed *only* for
transfers from initiators *other* than the one = that sent=20 the TMF.
I believe that Bill Studemund raised this concern earlier, = but
I admit to missing its significance at the time.

In = other words=20 when the key is not negotiated, a TMF that aborts
tasks from = multiple=20 initiators behaves differently at the target
with respect to the = initiators=20 involved:
a) There can be no change to currently specified behavior = with
                = respect to the=20 sender of the TMF.  All TTT transfers have
    =    =20         to complete, and the TMF response cannot = be sent=20 until
                the = transfers=20 are complete, otherwise a 3720-compliant
      =    =20       initiator may see something that it doesn't = expect.
b)=20 Transfers from other initiators may be bit-bucketed early at
  =  =20             the target - this would be = new=20 behavior, and new language
          =    =20   would be needed to allow the TMF response to be sent = once
 =20               these transfers from = other=20 initiators are redirected to
          =  =20     bit-buckets.  This does not affect a=20 3720-compliant
              =  =20 initiator, as these other initiators do not receive a
    =  =20           response to this TMF.
The only = change is=20 the latter, and it has the effect of removing
a cross-initiator = dependence=20 for completion of the TMF.  The use
case is that there is = still=20 cluster software out there using TMFs
to maintain cluster = membership=20 instead of persistent reservations,
even though the latter is what = should=20 be used.

> Sorry for the delay in getting back. =  Between=20 vacation and
> other travel, it took me a while.  Thanks = for the=20 comments.
>
> You wrote this regarding fast multi-task=20 abort:
> >This property is
> >useful even if the new = key is=20 not negotiated (and hence the
> >AsyncEvent 5 message is not = used for=20 fast abort of data transfers)
>
> I assume this is = essentially=20 what you are proposing that we
> consider (fast multi-task = abort with=20 outstanding TTTs always,
> even without the key=20 negotiation).

Not exactly, see above.

> The reason we = decided=20 a new key is needed here was for two reasons:
> 1. Whenever TMF = does a=20 fast completion, target needs an
> (eventual) deterministic=20 confirmation that data transfers had
> stopped.  The = confirmation=20 is Nop-Out, and the negotiation
> for the new Nop-Out is via = the=20 FastMultiTaskAbort key.
> 2. The initiator requirement in the = "classic"=20 case (i.e. key
> not negotiated) is that it respond to each TTT = for=20 affected
> tasks even while the task is "affected".  We = wanted an=20
> opposite behavior, but with a confirmation that the data =
>=20 transfers had stopped (so target can recover the buffer
> = resources).=20  The key allows this new behavior on initiator's
> part as = well.

I agree that the new key is clearly required in order=20 to
terminate any TTT data transfer from any initiator early
for = the=20 above reasons.

The proposal is that the TMF response be allowed = to be=20 sent
in the face of outstanding transfers from initiators = *other*
than=20 the one that sent the TMF.  This does not appear to
require a = new key=20 be negotiated with the *other* initiators,
as (in the absence of a = failure)=20 they will complete those
transfers normally.

> >This = is=20 approximately
> >what is described in the Implementation Note = at the=20 end of
> >Section 4.1.3, although that note may have been = intended=20 to
> >be iSER-specific - if so, this is a proposal to apply = it=20 to
> >iSCSI without the RDMA extensions.
>
> = Actually=20 the note is intended for all iSCSI implementations.  
> = After=20 seeing your observation, I decided that it needs
> improvement, = I=20 propose the following new text:
>
> "Implementation note: = Technically, the TMF servicing is
> complete in Step.e. =  Data=20 transfers corresponding to
> terminated tasks may however still = be in=20 progress even at the
> end of Step.f.  TMF Response MUST = NOT be=20 sent by the target
> iSCSI layer before the end of Step.e, and = may be=20 sent at the
> end of Step.e despite these outstanding Data = transfers=20 until
> Step.g.

Nit: "may be sent" --> "MAY be=20 sent"

> These data transfers, if any, MUST be silently =
>=20 discarded by the target iSCSI layer.  In the case of
> = iSCSI/iSER,=20 these transfers would be into tagged buffers with
> STags not = owned by=20 any active tasks.

I suggest adding: "; other implementations = would=20 deploy
analogous resources to support this discarding".

> = Step.g=20 specifies an
> event to free up the resources.  A target = may, on=20 an
> implementation-defined internal timeout, also choose to = drop=20
> the connections on which it did not receive the expected =
>=20 Nop-Out acknowledgements so as to reclaim the associated
> = buffer, STag=20 and TTT resources as appropriate."

Nit: "A target may" --> = "A target=20 MAY"

> Now that I read the text after a long time, I spotted = an=20
> unintended double negative in section 4.1.3, target behavior, =
> bullet d-ii.  The text should read:
> "ii) each = connection=20 except the issuing connection of the
> issuing session that has = at=20 least one allegiant affected
> task."    (i.e. drop = "non"=20 from "non-issuing")

Ok.

> The other thing that came = to my=20 mind after reading your note
> is that we don't currently have = a=20 generic key to capture the
> Response Fence behavior - although = response fencing underlies
> both the fast multi-task abort as = well as=20 addressing ACA race
> conditions (and perhaps others down the = road.=20 e.g. around
> persistent reservations).  So, today, the = Note at=20 the end of
> section 3.3.3 advises that implementations may = check the=20
> FastMultiTaskAbort key to verify if safe behavior for MCS ACA =
> is supported, although ACA has really nothing to do with =
>=20 multi-task aborting.  I am wondering if we should create a =
> new=20 key (say ResponseFence), so the semantics would become:
>   =  =20                     =  =20                     =  =20                     =  =20
>        ResponseFence    "Yes"=20  fencing done by target      
>   =    =20                     =  =20        "No"   legacy, no fencing
> (so = "clarified" TMF semantics are not possible either)
>   =  =20    
> With ResponseFence=3D    "Yes"
> = FastMultiTaskAbort    
>       "Yes" =  =20                 fast abort = &=20 fencing              
> =    =20    "No"               =  =20    traditional wait on
> outstanding TTTs (fencing on = ACA is=20 still possible)
>
> With ResponseFence=3D   =  "No"
>=20 FastMultiTaskAbort    
>       "Yes" =  =20                 Illegal, = Response=20 Fence must be "Yes"
>        "No"   =  =20                No fencing, = must wait=20 on
> outstanding TTTs
>  
>
> The = downside of=20 this scheme is that it may be going in the
> opposite direction = than=20 you wanted (introduces a second key
> that 3720-compliant=20 implementations don't know about).  We
> could = alternatively=20 simply mandate the behavior equivalent to
> ResponseFence =3D = "Yes"=20 always and avoid the second key, but
> doing so could make the = current=20 3720-compliant
> implementations technically=20 non-iSCSI-compliant.
>
> Comments?

Given the=20 inter-dependence of ResponseFence and FastMultiTaskAbort,
a single = 3-valued=20 key is probably simpler than two boolean keys.
I think having an = explicit=20 means of determining whether ACA behaves
correctly on an=20 multi-connection-session is worth adding.

Thanks,
--David=20

> Mallikarjun             =  =20              
>
> = -----=20 Original Message ----
> From: "Black_David@emc.com"=20 <Black_David@emc.com>
> To: ips@ietf.org
> Cc:=20 Black_David@emc.com
> Sent: Wednesday, November 22, 2006 2:00:25 = PM
> Subject: [Ips] Implementer's Guide - Task Management = Issue
>=20
>
> To make sure we actually have some content to talk = about=20 in
> this WG Last Call, I'm going to reraise an issue that = came
>=20 up earlier on the mailing list, but (as far as I can recall)
> = never got=20 resolved.  This is done with my WG chair hat OFF,
> and it = is a=20 proposal for further discussion.
>
> Section 4.1.3 = changes task=20 management, and is a non-transparent
> change - it requires = negotiating=20 a new key so that both sides
> agree that they support the = change as it=20 uses a round-trip
> exchange of a new message (AsyncEvent 5) = between=20 initiator and
> target to abort in-progress data transfers = rather than=20 completing
> them.  Absent this message, the target expects = the=20 initiator(s)
> to complete all in-progress transfers, and is = entitled to=20 be
> unhappy or worse if that doesn't happen.
>
> = For task=20 management functions that affect tasks from more than
> one = initiator=20 (CLEAR TASK SET, TARGET WARM RESET, TARGET COLD
> RESET) =  Section=20 4.1.3 also allows the task management function
> (TMF) to = complete while=20 the in-progress data transfers are still
> being dealt with, = which has=20 the useful effect of avoiding a
> situation in which an = uncooperative=20 initiator can stall the
> progress of a TMF sent by another = initiator.=20  This property is
> useful even if the new key is not = negotiated=20 (and hence the
> AsyncEvent 5 message is not used for fast abort = of data=20 transfers)
> although I think the target behavior is subtly = different=20 between
> the initiator that sent the TMF and other initiators = in this=20 case:
> - For the TMF sender, the target must wait for all=20 outstanding
>     transfers to complete before = completing the=20 TMF, otherwise
>     the TMF completion comes back too = early=20 for an unmodified
>     initiator.
> - For the = other=20 initiators, the data transfers can be immediately
>   =  =20 redirected to bit buckets so the TMF can be completed without
> =  =20   waits beyond that for the TMF sender.  This is=20 approximately
>     what is described in the = Implementation=20 Note at the end of
>     Section 4.1.3, although that = note may=20 have been intended to
>     be iSER-specific - if so, = this is=20 a proposal to apply it to
>     iSCSI without the RDMA = extensions.
>
> High Availability clustering environments = in=20 which TMFs are being
> used to determine cluster membership = (yes,=20 there's code out there
> that does this, even though everyone = should be=20 using PERSISTENT
> RESERVE) are a specific situation where this = helps,=20 as having to
> wait for a dead initiator to expire (the TCP=20 connection(s) have
> to timeout and get torn down) slows down = cluster=20 recovery from a
> failure.  This change in target behavior = (to=20 complete a TMF faster
> if other initiators don't cooperate) = should be=20 transparent to
> RFC 3720-compliant initiators, but RFC 3720 has = to be=20 modified
> in order to allow it; the Implementer's Guide is a = vehicle=20 that
> can make that modification.
>
> This is = proposed for=20 further discussion.
>
> Thanks,
> --David
>=20 ----------------------------------------------------
> David L. = Black,=20 Senior Technologist
> EMC Corporation, 176 South St., Hopkinton, = MA=20  01748
> +1 (508) 293-7953         =  =20   FAX: +1 (508) 293-7786
> black_david@emc.com   =    =20  Mobile: +1 (978) 394-7754
>=20 = ----------------------------------------------------

_____________= __________________________________
Ips=20 mailing=20 = list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips

------_=_NextPart_001_01C71E1B.0A20B25D-- --===============1082375114== 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 --===============1082375114==-- From ips-bounces@ietf.org Tue Dec 12 15:12:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuDzN-0006Tw-DT; Tue, 12 Dec 2006 15:12:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuDzL-0006Sp-MK for ips@ietf.org; Tue, 12 Dec 2006 15:12:31 -0500 Received: from mtagate5.de.ibm.com ([195.212.29.154]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuDzI-0006Bz-VH for ips@ietf.org; Tue, 12 Dec 2006 15:12:31 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate5.de.ibm.com (8.13.8/8.13.8) with ESMTP id kBCKCRxS101766 for ; Tue, 12 Dec 2006 20:12:27 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id kBCKCR4h2416886 for ; Tue, 12 Dec 2006 21:12:27 +0100 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id kBCKCQho031650 for ; Tue, 12 Dec 2006 21:12:27 +0100 Received: from d12mc102.megacenter.de.ibm.com (d12mc102.megacenter.de.ibm.com [9.149.167.114]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id kBCKCQDi031647; Tue, 12 Dec 2006 21:12:26 +0100 In-Reply-To: To: Black_David@emc.com MIME-Version: 1.0 Subject: RE: [Ips] Implementer's Guide - Task Management Issue X-Mailer: Lotus Notes Release 7.0.2 September 26, 2006 From: Julian Satran Message-ID: Date: Tue, 12 Dec 2006 22:12:22 +0200 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 7.0.2HF71 | November 3, 2006) at 12/12/2006 22:12:26, Serialize complete at 12/12/2006 22:12:26 X-Spam-Score: 0.1 (/) X-Scan-Signature: d2b4898a2beddf410d6e76902566f557 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="===============0110563820==" Errors-To: ips-bounces@ietf.org This is a multipart message in MIME format. --===============0110563820== Content-Type: multipart/alternative; boundary="=_alternative 006EFCC5C2257242_=" This is a multipart message in MIME format. --=_alternative 006EFCC5C2257242_= Content-Type: text/plain; charset="US-ASCII" David, The issue you are describing falls in the same category. Target can answer to B as soon as it has "purged" the tasks regardless of what A does. For safety the implementation should keep the pairs ITT-TTT and make sure it does not reuse the TTTs with the same ITT for a while or force closing offending sessions. There is no need to really delay the TM response - just act as if all outsanding activity died out and ignore data reaching the target. Julo Black_David@emc.com 12/12/06 20:26 To Julian Satran/Haifa/IBM@IBMIL cc Subject RE: [Ips] Implementer's Guide - Task Management Issue Julian, > As for the issue raised by Bill Studemund I am not sure that the target needs help in > recovering buffers (and I am not sure that I am not repeating what I said already in he past). The motivating concern is not buffer recovery - it's the ability of an uncooperative initiator to delay completion of a TMF issued by a different initiator. Here's an example: - Initiator A has one or more data transfers in progress to the target. - Initiator A dies in some inconvenient fashion. The target thinks the iSCSI session with Initiator A is still alive, but Initiator A is non-responsive. - Initiator B issues a TMF that has the effect of aborting Initiator A's tasks (e.g., CLEAR TASK SET). The issue is: When can the target issue the TMF response to Initiator B? Current RFC 3720 language requires completion of Initiator A's data transfers or timing out and dropping Initiator A's session - Section 10.5.1: "The target on its part MUST wait for responses on all affected target transfer tags before acting on either of these two task management requests". In this example, the data transfers will not complete, requiring timing out and dropping the session before the TMF response can be issued. The request is that it be permissible for the target to redirect Initiator A's data transfers to bit-buckets (just in case Initiator A is not actually completely dead) and issue the TMF response once that redirection (as well as everything that RFC 3720 requires with respect to Initiator B) is done so that the TMF response doesn't have to wait for the target to time out and tear down the session with Initiator A. 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 ---------------------------------------------------- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Tuesday, December 12, 2006 8:03 AM To: Black, David Cc: cb_mallikarjun@yahoo.com; ips@ietf.org Subject: RE: [Ips] Implementer's Guide - Task Management Issue David and Mallikarjun, I had a long discussion with Mallikarjun on a part of this problem - namely cleaning the T-2-I path. This could be done in several ways and Mallikarjun and I where also playing with sending the closing TM response on all connections as a way to speed up pipe cleaning. As for the issue raised by Bill Studemund I am not sure that the target needs help in recovering buffers (and I am not sure that I am not repeating what I said already in he past). As TTT is a target conceived artifact - buffers can be retired and the target can refrain from reusing the TTT with the given ITTs for some time (the rules must be quite simple). If data arrives with the bad combination - it is just discarded at the target. This ways TMF can be sent early - regardless of oustanding data - provided that the target respects some simple rules for TTT use/reuse. Considering also that TTTs are also not mandated to be unique beyond a single LUN - buffer retirement while an issue can be solved within 3270. Regards, Julo Black_David@emc.com 11/12/06 20:56 To , cc Subject RE: [Ips] Implementer's Guide - Task Management Issue Mallikarjun, [NB: Working group chair hat is **off**.] > "I assume this is essentially what you are proposing that we > consider (fast multi-task abort with outstanding TTTs always, > even without the key negotiation)." Not exactly - comments interspersed below, but what I'm proposing is that in the absence of negotiation of the new key, the portion of "fast multi-task abort" that allows the TMF response to be returned in the face of outstanding TTTs be allowed *only* for transfers from initiators *other* than the one that sent the TMF. I believe that Bill Studemund raised this concern earlier, but I admit to missing its significance at the time. In other words when the key is not negotiated, a TMF that aborts tasks from multiple initiators behaves differently at the target with respect to the initiators involved: a) There can be no change to currently specified behavior with respect to the sender of the TMF. All TTT transfers have to complete, and the TMF response cannot be sent until the transfers are complete, otherwise a 3720-compliant initiator may see something that it doesn't expect. b) Transfers from other initiators may be bit-bucketed early at the target - this would be new behavior, and new language would be needed to allow the TMF response to be sent once these transfers from other initiators are redirected to bit-buckets. This does not affect a 3720-compliant initiator, as these other initiators do not receive a response to this TMF. The only change is the latter, and it has the effect of removing a cross-initiator dependence for completion of the TMF. The use case is that there is still cluster software out there using TMFs to maintain cluster membership instead of persistent reservations, even though the latter is what should be used. > Sorry for the delay in getting back. Between vacation and > other travel, it took me a while. Thanks for the comments. > > You wrote this regarding fast multi-task abort: > >This property is > >useful even if the new key is not negotiated (and hence the > >AsyncEvent 5 message is not used for fast abort of data transfers) > > I assume this is essentially what you are proposing that we > consider (fast multi-task abort with outstanding TTTs always, > even without the key negotiation). Not exactly, see above. > The reason we decided a new key is needed here was for two reasons: > 1. Whenever TMF does a fast completion, target needs an > (eventual) deterministic confirmation that data transfers had > stopped. The confirmation is Nop-Out, and the negotiation > for the new Nop-Out is via the FastMultiTaskAbort key. > 2. The initiator requirement in the "classic" case (i.e. key > not negotiated) is that it respond to each TTT for affected > tasks even while the task is "affected". We wanted an > opposite behavior, but with a confirmation that the data > transfers had stopped (so target can recover the buffer > resources). The key allows this new behavior on initiator's > part as well. I agree that the new key is clearly required in order to terminate any TTT data transfer from any initiator early for the above reasons. The proposal is that the TMF response be allowed to be sent in the face of outstanding transfers from initiators *other* than the one that sent the TMF. This does not appear to require a new key be negotiated with the *other* initiators, as (in the absence of a failure) they will complete those transfers normally. > >This is approximately > >what is described in the Implementation Note at the end of > >Section 4.1.3, although that note may have been intended to > >be iSER-specific - if so, this is a proposal to apply it to > >iSCSI without the RDMA extensions. > > Actually the note is intended for all iSCSI implementations. > After seeing your observation, I decided that it needs > improvement, I propose the following new text: > > "Implementation note: Technically, the TMF servicing is > complete in Step.e. Data transfers corresponding to > terminated tasks may however still be in progress even at the > end of Step.f. TMF Response MUST NOT be sent by the target > iSCSI layer before the end of Step.e, and may be sent at the > end of Step.e despite these outstanding Data transfers until > Step.g. Nit: "may be sent" --> "MAY be sent" > These data transfers, if any, MUST be silently > discarded by the target iSCSI layer. In the case of > iSCSI/iSER, these transfers would be into tagged buffers with > STags not owned by any active tasks. I suggest adding: "; other implementations would deploy analogous resources to support this discarding". > Step.g specifies an > event to free up the resources. A target may, on an > implementation-defined internal timeout, also choose to drop > the connections on which it did not receive the expected > Nop-Out acknowledgements so as to reclaim the associated > buffer, STag and TTT resources as appropriate." Nit: "A target may" --> "A target MAY" > Now that I read the text after a long time, I spotted an > unintended double negative in section 4.1.3, target behavior, > bullet d-ii. The text should read: > "ii) each connection except the issuing connection of the > issuing session that has at least one allegiant affected > task." (i.e. drop "non" from "non-issuing") Ok. > The other thing that came to my mind after reading your note > is that we don't currently have a generic key to capture the > Response Fence behavior - although response fencing underlies > both the fast multi-task abort as well as addressing ACA race > conditions (and perhaps others down the road. e.g. around > persistent reservations). So, today, the Note at the end of > section 3.3.3 advises that implementations may check the > FastMultiTaskAbort key to verify if safe behavior for MCS ACA > is supported, although ACA has really nothing to do with > multi-task aborting. I am wondering if we should create a > new key (say ResponseFence), so the semantics would become: > > ResponseFence "Yes" fencing done by target > "No" legacy, no fencing > (so "clarified" TMF semantics are not possible either) > > With ResponseFence= "Yes" > FastMultiTaskAbort > "Yes" fast abort & fencing > "No" traditional wait on > outstanding TTTs (fencing on ACA is still possible) > > With ResponseFence= "No" > FastMultiTaskAbort > "Yes" Illegal, Response Fence must be "Yes" > "No" No fencing, must wait on > outstanding TTTs > > > The downside of this scheme is that it may be going in the > opposite direction than you wanted (introduces a second key > that 3720-compliant implementations don't know about). We > could alternatively simply mandate the behavior equivalent to > ResponseFence = "Yes" always and avoid the second key, but > doing so could make the current 3720-compliant > implementations technically non-iSCSI-compliant. > > Comments? Given the inter-dependence of ResponseFence and FastMultiTaskAbort, a single 3-valued key is probably simpler than two boolean keys. I think having an explicit means of determining whether ACA behaves correctly on an multi-connection-session is worth adding. Thanks, --David > Mallikarjun > > ----- Original Message ---- > From: "Black_David@emc.com" > To: ips@ietf.org > Cc: Black_David@emc.com > Sent: Wednesday, November 22, 2006 2:00:25 PM > Subject: [Ips] Implementer's Guide - Task Management Issue > > > To make sure we actually have some content to talk about in > this WG Last Call, I'm going to reraise an issue that came > up earlier on the mailing list, but (as far as I can recall) > never got resolved. This is done with my WG chair hat OFF, > and it is a proposal for further discussion. > > Section 4.1.3 changes task management, and is a non-transparent > change - it requires negotiating a new key so that both sides > agree that they support the change as it uses a round-trip > exchange of a new message (AsyncEvent 5) between initiator and > target to abort in-progress data transfers rather than completing > them. Absent this message, the target expects the initiator(s) > to complete all in-progress transfers, and is entitled to be > unhappy or worse if that doesn't happen. > > For task management functions that affect tasks from more than > one initiator (CLEAR TASK SET, TARGET WARM RESET, TARGET COLD > RESET) Section 4.1.3 also allows the task management function > (TMF) to complete while the in-progress data transfers are still > being dealt with, which has the useful effect of avoiding a > situation in which an uncooperative initiator can stall the > progress of a TMF sent by another initiator. This property is > useful even if the new key is not negotiated (and hence the > AsyncEvent 5 message is not used for fast abort of data transfers) > although I think the target behavior is subtly different between > the initiator that sent the TMF and other initiators in this case: > - For the TMF sender, the target must wait for all outstanding > transfers to complete before completing the TMF, otherwise > the TMF completion comes back too early for an unmodified > initiator. > - For the other initiators, the data transfers can be immediately > redirected to bit buckets so the TMF can be completed without > waits beyond that for the TMF sender. This is approximately > what is described in the Implementation Note at the end of > Section 4.1.3, although that note may have been intended to > be iSER-specific - if so, this is a proposal to apply it to > iSCSI without the RDMA extensions. > > High Availability clustering environments in which TMFs are being > used to determine cluster membership (yes, there's code out there > that does this, even though everyone should be using PERSISTENT > RESERVE) are a specific situation where this helps, as having to > wait for a dead initiator to expire (the TCP connection(s) have > to timeout and get torn down) slows down cluster recovery from a > failure. This change in target behavior (to complete a TMF faster > if other initiators don't cooperate) should be transparent to > RFC 3720-compliant initiators, but RFC 3720 has to be modified > in order to allow it; the Implementer's Guide is a vehicle that > can make that modification. > > This is proposed for further discussion. > > 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 --=_alternative 006EFCC5C2257242_= Content-Type: text/html; charset="US-ASCII"
David,

The issue you are describing falls in the same category.
Target can answer to B as soon as it has "purged" the tasks regardless of what A does.
For safety the implementation should keep the pairs ITT-TTT and make sure it does not reuse
the TTTs with the same ITT for a while or force closing offending sessions.
There is no need to really delay the TM response - just act as if all outsanding activity died out and ignore data reaching the target.

Julo


Black_David@emc.com

12/12/06 20:26

To
Julian Satran/Haifa/IBM@IBMIL
cc
<ips@ietf.org>
Subject
RE: [Ips] Implementer's Guide - Task Management Issue





Julian,
 
> As for the issue raised by Bill Studemund I am not sure that the target needs help in
> recovering buffers (and I am not sure that I am not repeating what I said already in he past).
 
The motivating concern is not buffer recovery - it's the ability of an uncooperative initiator
to delay completion of a TMF issued by a different initiator.  Here's an example:
 
- Initiator A has one or more data transfers in progress to the target.
- Initiator A dies in some inconvenient fashion.  The target thinks the iSCSI
   session with Initiator A is still alive, but Initiator A is non-responsive.
- Initiator B issues a TMF that has the effect of aborting Initiator A's tasks
    (e.g., CLEAR TASK SET).
 
The issue is: When can the target issue the TMF response to Initiator B?
 
Current RFC 3720 language requires completion of Initiator A's data transfers or timing
out and dropping Initiator A's session - Section 10.5.1: "The target on its part MUST
wait for responses on all affected target transfer tags before acting on either of these
two task management requests".  In this example, the data transfers will not
complete, requiring timing out and dropping the session before the TMF response
can be issued.
 
The request is that it be permissible for the target to redirect Initiator A's data transfers
to bit-buckets (just in case Initiator A is not actually completely dead) and issue the TMF
response once that redirection (as well as everything that RFC 3720 requires with
respect to Initiator B) is done so that the TMF response doesn't have to wait for the
target to time out and tear down the session with Initiator A.
 
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
----------------------------------------------------
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Tuesday, December 12, 2006 8:03 AM
To: Black, David
Cc: cb_mallikarjun@yahoo.com; ips@ietf.org
Subject: RE: [Ips] Implementer's Guide - Task Management Issue

David and Mallikarjun,

I had a long discussion with Mallikarjun on a part of this problem - namely cleaning the T-2-I path.
This could be done in several ways and Mallikarjun and I where also playing with sending the closing TM response on all connections as a way to speed up pipe cleaning.

As for the issue raised by Bill Studemund I am not sure that the target needs help in recovering buffers (and I am not sure that I am not repeating what I said already in he past).
As TTT is a target conceived artifact - buffers can be retired and the target can refrain from reusing the TTT with the given ITTs for some time (the rules must be quite simple).
If data arrives with the bad combination - it is just discarded at the target.

This ways TMF can be sent early - regardless of oustanding data - provided that the target respects some simple rules for TTT use/reuse.
Considering also that TTTs are also not mandated to be unique beyond a single LUN - buffer retirement while an issue can be solved within 3270.

Regards,
Julo



Black_David@emc.com

11/12/06 20:56


To
<cb_mallikarjun@yahoo.com>, <ips@ietf.org>
cc
Subject
RE: [Ips] Implementer's Guide - Task Management Issue







Mallikarjun,

[NB: Working group chair hat is **off**.]

> "I assume this is essentially what you are proposing that we
> consider (fast multi-task abort with outstanding TTTs always,
> even without the key negotiation)."

Not exactly - comments interspersed below, but what I'm proposing
is that in the absence of negotiation of the new key, the portion
of "fast multi-task abort" that allows the TMF response to be
returned in the face of outstanding TTTs be allowed *only* for
transfers from initiators *other* than the one that sent the TMF.
I believe that Bill Studemund raised this concern earlier, but
I admit to missing its significance at the time.

In other words when the key is not negotiated, a TMF that aborts
tasks from multiple initiators behaves differently at the target
with respect to the initiators involved:
a) There can be no change to currently specified behavior with
               respect to the sender of the TMF.  All TTT transfers have
               to complete, and the TMF response cannot be sent until
               the transfers are complete, otherwise a 3720-compliant
               initiator may see something that it doesn't expect.
b) Transfers from other initiators may be bit-bucketed early at
               the target - this would be new behavior, and new language
               would be needed to allow the TMF response to be sent once
               these transfers from other initiators are redirected to
               bit-buckets.  This does not affect a 3720-compliant
               initiator, as these other initiators do not receive a
               response to this TMF.
The only change is the latter, and it has the effect of removing
a cross-initiator dependence for completion of the TMF.  The use
case is that there is still cluster software out there using TMFs
to maintain cluster membership instead of persistent reservations,
even though the latter is what should be used.

> Sorry for the delay in getting back.  Between vacation and
> other travel, it took me a while.  Thanks for the comments.
>
> You wrote this regarding fast multi-task abort:
> >This property is
> >useful even if the new key is not negotiated (and hence the
> >AsyncEvent 5 message is not used for fast abort of data transfers)
>
> I assume this is essentially what you are proposing that we
> consider (fast multi-task abort with outstanding TTTs always,
> even without the key negotiation).

Not exactly, see above.

> The reason we decided a new key is needed here was for two reasons:
> 1. Whenever TMF does a fast completion, target needs an
> (eventual) deterministic confirmation that data transfers had
> stopped.  The confirmation is Nop-Out, and the negotiation
> for the new Nop-Out is via the FastMultiTaskAbort key.
> 2. The initiator requirement in the "classic" case (i.e. key
> not negotiated) is that it respond to each TTT for affected
> tasks even while the task is "affected".  We wanted an
> opposite behavior, but with a confirmation that the data
> transfers had stopped (so target can recover the buffer
> resources).  The key allows this new behavior on initiator's
> part as well.

I agree that the new key is clearly required in order to
terminate any TTT data transfer from any initiator early
for the above reasons.

The proposal is that the TMF response be allowed to be sent
in the face of outstanding transfers from initiators *other*
than the one that sent the TMF.  This does not appear to
require a new key be negotiated with the *other* initiators,
as (in the absence of a failure) they will complete those
transfers normally.

> >This is approximately
> >what is described in the Implementation Note at the end of
> >Section 4.1.3, although that note may have been intended to
> >be iSER-specific - if so, this is a proposal to apply it to
> >iSCSI without the RDMA extensions.
>
> Actually the note is intended for all iSCSI implementations.  
> After seeing your observation, I decided that it needs
> improvement, I propose the following new text:
>
> "Implementation note: Technically, the TMF servicing is
> complete in Step.e.  Data transfers corresponding to
> terminated tasks may however still be in progress even at the
> end of Step.f.  TMF Response MUST NOT be sent by the target
> iSCSI layer before the end of Step.e, and may be sent at the
> end of Step.e despite these outstanding Data transfers until
> Step.g.

Nit: "may be sent" --> "MAY be sent"

> These data transfers, if any, MUST be silently
> discarded by the target iSCSI layer.  In the case of
> iSCSI/iSER, these transfers would be into tagged buffers with
> STags not owned by any active tasks.

I suggest adding: "; other implementations would deploy
analogous resources to support this discarding".

> Step.g specifies an
> event to free up the resources.  A target may, on an
> implementation-defined internal timeout, also choose to drop
> the connections on which it did not receive the expected
> Nop-Out acknowledgements so as to reclaim the associated
> buffer, STag and TTT resources as appropriate."

Nit: "A target may" --> "A target MAY"

> Now that I read the text after a long time, I spotted an
> unintended double negative in section 4.1.3, target behavior,
> bullet d-ii.  The text should read:
> "ii) each connection except the issuing connection of the
> issuing session that has at least one allegiant affected
> task."    (i.e. drop "non" from "non-issuing")

Ok.

> The other thing that came to my mind after reading your note
> is that we don't currently have a generic key to capture the
> Response Fence behavior - although response fencing underlies
> both the fast multi-task abort as well as addressing ACA race
> conditions (and perhaps others down the road. e.g. around
> persistent reservations).  So, today, the Note at the end of
> section 3.3.3 advises that implementations may check the
> FastMultiTaskAbort key to verify if safe behavior for MCS ACA
> is supported, although ACA has really nothing to do with
> multi-task aborting.  I am wondering if we should create a
> new key (say ResponseFence), so the semantics would become:
>                                                                      
>        ResponseFence    "Yes"  fencing done by target      
>                                    "No"   legacy, no fencing
> (so "clarified" TMF semantics are not possible either)
>        
> With ResponseFence=    "Yes"
> FastMultiTaskAbort    
>       "Yes"                   fast abort & fencing              
>        "No"                    traditional wait on
> outstanding TTTs (fencing on ACA is still possible)
>
> With ResponseFence=    "No"
> FastMultiTaskAbort    
>       "Yes"                   Illegal, Response Fence must be "Yes"
>        "No"                    No fencing, must wait on
> outstanding TTTs
>  
>
> The downside of this scheme is that it may be going in the
> opposite direction than you wanted (introduces a second key
> that 3720-compliant implementations don't know about).  We
> could alternatively simply mandate the behavior equivalent to
> ResponseFence = "Yes" always and avoid the second key, but
> doing so could make the current 3720-compliant
> implementations technically non-iSCSI-compliant.
>
> Comments?

Given the inter-dependence of ResponseFence and FastMultiTaskAbort,
a single 3-valued key is probably simpler than two boolean keys.
I think having an explicit means of determining whether ACA behaves
correctly on an multi-connection-session is worth adding.

Thanks,
--David

> Mallikarjun                            
>
> ----- Original Message ----
> From: "Black_David@emc.com" <Black_David@emc.com>
> To: ips@ietf.org
> Cc: Black_David@emc.com
> Sent: Wednesday, November 22, 2006 2:00:25 PM
> Subject: [Ips] Implementer's Guide - Task Management Issue
>
>
> To make sure we actually have some content to talk about in
> this WG Last Call, I'm going to reraise an issue that came
> up earlier on the mailing list, but (as far as I can recall)
> never got resolved.  This is done with my WG chair hat OFF,
> and it is a proposal for further discussion.
>
> Section 4.1.3 changes task management, and is a non-transparent
> change - it requires negotiating a new key so that both sides
> agree that they support the change as it uses a round-trip
> exchange of a new message (AsyncEvent 5) between initiator and
> target to abort in-progress data transfers rather than completing
> them.  Absent this message, the target expects the initiator(s)
> to complete all in-progress transfers, and is entitled to be
> unhappy or worse if that doesn't happen.
>
> For task management functions that affect tasks from more than
> one initiator (CLEAR TASK SET, TARGET WARM RESET, TARGET COLD
> RESET)  Section 4.1.3 also allows the task management function
> (TMF) to complete while the in-progress data transfers are still
> being dealt with, which has the useful effect of avoiding a
> situation in which an uncooperative initiator can stall the
> progress of a TMF sent by another initiator.  This property is
> useful even if the new key is not negotiated (and hence the
> AsyncEvent 5 message is not used for fast abort of data transfers)
> although I think the target behavior is subtly different between
> the initiator that sent the TMF and other initiators in this case:
> - For the TMF sender, the target must wait for all outstanding
>     transfers to complete before completing the TMF, otherwise
>     the TMF completion comes back too early for an unmodified
>     initiator.
> - For the other initiators, the data transfers can be immediately
>     redirected to bit buckets so the TMF can be completed without
>     waits beyond that for the TMF sender.  This is approximately
>     what is described in the Implementation Note at the end of
>     Section 4.1.3, although that note may have been intended to
>     be iSER-specific - if so, this is a proposal to apply it to
>     iSCSI without the RDMA extensions.
>
> High Availability clustering environments in which TMFs are being
> used to determine cluster membership (yes, there's code out there
> that does this, even though everyone should be using PERSISTENT
> RESERVE) are a specific situation where this helps, as having to
> wait for a dead initiator to expire (the TCP connection(s) have
> to timeout and get torn down) slows down cluster recovery from a
> failure.  This change in target behavior (to complete a TMF faster
> if other initiators don't cooperate) should be transparent to
> RFC 3720-compliant initiators, but RFC 3720 has to be modified
> in order to allow it; the Implementer's Guide is a vehicle that
> can make that modification.
>
> This is proposed for further discussion.
>
> 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
--=_alternative 006EFCC5C2257242_=-- --===============0110563820== 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 --===============0110563820==-- From ips-bounces@ietf.org Tue Dec 12 15:36:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuEM9-00075Y-Ph; Tue, 12 Dec 2006 15:36:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuEM8-0006tl-0s for ips@ietf.org; Tue, 12 Dec 2006 15:36:04 -0500 Received: from mexforward.lss.emc.com ([128.222.32.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuEM6-0001tu-Eq for ips@ietf.org; Tue, 12 Dec 2006 15:36:04 -0500 Received: from mailhub.lss.emc.com (nirah.lss.emc.com [10.254.144.13]) by mexforward.lss.emc.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id kBCKa2sA027071; Tue, 12 Dec 2006 15:36:02 -0500 (EST) Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id kBCKZnAc018158; Tue, 12 Dec 2006 15:35:55 -0500 (EST) From: Black_David@emc.com Received: from CORPUSMX20A.corp.emc.com ([128.221.62.13]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Dec 2006 15:35:21 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ips] Implementer's Guide - Task Management Issue Date: Tue, 12 Dec 2006 15:35:20 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ips] Implementer's Guide - Task Management Issue Thread-Index: AcceKeWzv6oRIJ12Tbuv2RZfhLCr/QAAkuJA To: X-OriginalArrivalTime: 12 Dec 2006 20:35:21.0038 (UTC) FILETIME=[0B01D6E0:01C71E2D] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2006.12.12.121433 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -2, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0, __CTYPE_MULTIPART_ALT 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_HTML 0, __MIME_VERSION 0, __SANE_MSGID 0, __TAG_EXISTS_HTML 0' X-Spam-Score: 0.5 (/) X-Scan-Signature: 800a60a6d139d15fdd4640055f94a486 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="===============1380268140==" Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============1380268140== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C71E2D.0A6AD84D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C71E2D.0A6AD84D Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Julian, =20 I agree that the target should be able to do this (not delay TMF response waiting for an initiator that did not issue the the TMF), but the language I quoted from RFC 3720 explicitly requires the wait (and has been read to require the wait by more than one implementer). =20 Can we agree that the implementers guide needs to clarify RFC 3720 along the lines of what you wrote, and specifically say that completion of a TMF never has to wait for a response from an initiator other than the one that issued the TMF? =20 Thanks, --David ________________________________ From: Julian Satran [mailto:Julian_Satran@il.ibm.com]=20 Sent: Tuesday, December 12, 2006 3:12 PM To: Black, David Cc: ips@ietf.org Subject: RE: [Ips] Implementer's Guide - Task Management Issue =09 =09 David,=20 =09 The issue you are describing falls in the same category.=20 Target can answer to B as soon as it has "purged" the tasks regardless of what A does.=20 For safety the implementation should keep the pairs ITT-TTT and make sure it does not reuse=20 the TTTs with the same ITT for a while or force closing offending sessions.=20 There is no need to really delay the TM response - just act as if all outsanding activity died out and ignore data reaching the target. =09 Julo=20 =09 =09 =09 Black_David@emc.com=20 12/12/06 20:26=20 To Julian Satran/Haifa/IBM@IBMIL=20 cc =20 Subject RE: [Ips] Implementer's Guide - Task Management Issue =09 Julian,=20 =20 > As for the issue raised by Bill Studemund I am not sure that the target needs help in=20 > recovering buffers (and I am not sure that I am not repeating what I said already in he past).=20 =20 The motivating concern is not buffer recovery - it's the ability of an uncooperative initiator=20 to delay completion of a TMF issued by a different initiator. Here's an example:=20 =20 - Initiator A has one or more data transfers in progress to the target.=20 - Initiator A dies in some inconvenient fashion. The target thinks the iSCSI session with Initiator A is still alive, but Initiator A is non-responsive.=20 - Initiator B issues a TMF that has the effect of aborting Initiator A's tasks=20 (e.g., CLEAR TASK SET).=20 =20 The issue is: When can the target issue the TMF response to Initiator B?=20 =20 Current RFC 3720 language requires completion of Initiator A's data transfers or timing=20 out and dropping Initiator A's session - Section 10.5.1: "The target on its part MUST=20 wait for responses on all affected target transfer tags before acting on either of these=20 two task management requests". In this example, the data transfers will not=20 complete, requiring timing out and dropping the session before the TMF response=20 can be issued.=20 =20 The request is that it be permissible for the target to redirect Initiator A's data transfers=20 to bit-buckets (just in case Initiator A is not actually completely dead) and issue the TMF=20 response once that redirection (as well as everything that RFC 3720 requires with=20 respect to Initiator B) is done so that the TMF response doesn't have to wait for the=20 target to time out and tear down the session with Initiator A.=20 =20 Thanks,=20 --David=20 ----------------------------------------------------=20 David L. Black, Senior Technologist=20 EMC Corporation, 176 South St., Hopkinton, MA 01748=20 +1 (508) 293-7953 FAX: +1 (508) 293-7786=20 black_david@emc.com Mobile: +1 (978) 394-7754=20 ----------------------------------------------------=20 =09 ________________________________ From: Julian Satran [mailto:Julian_Satran@il.ibm.com]=20 Sent: Tuesday, December 12, 2006 8:03 AM To: Black, David Cc: cb_mallikarjun@yahoo.com; ips@ietf.org Subject: RE: [Ips] Implementer's Guide - Task Management Issue =09 =09 David and Mallikarjun,=20 =09 I had a long discussion with Mallikarjun on a part of this problem - namely cleaning the T-2-I path.=20 This could be done in several ways and Mallikarjun and I where also playing with sending the closing TM response on all connections as a way to speed up pipe cleaning.=20 =09 As for the issue raised by Bill Studemund I am not sure that the target needs help in recovering buffers (and I am not sure that I am not repeating what I said already in he past).=20 As TTT is a target conceived artifact - buffers can be retired and the target can refrain from reusing the TTT with the given ITTs for some time (the rules must be quite simple).=20 If data arrives with the bad combination - it is just discarded at the target.=20 =09 This ways TMF can be sent early - regardless of oustanding data - provided that the target respects some simple rules for TTT use/reuse. Considering also that TTTs are also not mandated to be unique beyond a single LUN - buffer retirement while an issue can be solved within 3270.=20 =09 Regards,=20 Julo=20 =09 =09 =09 =09 Black_David@emc.com=20 11/12/06 20:56=20 To , =20 cc Subject RE: [Ips] Implementer's Guide - Task Management Issue =09 =09 =09 =09 Mallikarjun, =09 [NB: Working group chair hat is **off**.] =09 > "I assume this is essentially what you are proposing that we=20 > consider (fast multi-task abort with outstanding TTTs always,=20 > even without the key negotiation)." =09 Not exactly - comments interspersed below, but what I'm proposing is that in the absence of negotiation of the new key, the portion of "fast multi-task abort" that allows the TMF response to be returned in the face of outstanding TTTs be allowed *only* for transfers from initiators *other* than the one that sent the TMF. I believe that Bill Studemund raised this concern earlier, but I admit to missing its significance at the time. =09 In other words when the key is not negotiated, a TMF that aborts tasks from multiple initiators behaves differently at the target with respect to the initiators involved: a) There can be no change to currently specified behavior with respect to the sender of the TMF. All TTT transfers have to complete, and the TMF response cannot be sent until the transfers are complete, otherwise a 3720-compliant initiator may see something that it doesn't expect. b) Transfers from other initiators may be bit-bucketed early at the target - this would be new behavior, and new language would be needed to allow the TMF response to be sent once these transfers from other initiators are redirected to bit-buckets. This does not affect a 3720-compliant initiator, as these other initiators do not receive a response to this TMF. The only change is the latter, and it has the effect of removing a cross-initiator dependence for completion of the TMF. The use case is that there is still cluster software out there using TMFs to maintain cluster membership instead of persistent reservations, even though the latter is what should be used. =09 > Sorry for the delay in getting back. Between vacation and=20 > other travel, it took me a while. Thanks for the comments. >=20 > You wrote this regarding fast multi-task abort: > >This property is > >useful even if the new key is not negotiated (and hence the > >AsyncEvent 5 message is not used for fast abort of data transfers) >=20 > I assume this is essentially what you are proposing that we=20 > consider (fast multi-task abort with outstanding TTTs always,=20 > even without the key negotiation). =09 Not exactly, see above. =09 > The reason we decided a new key is needed here was for two reasons: > 1. Whenever TMF does a fast completion, target needs an=20 > (eventual) deterministic confirmation that data transfers had=20 > stopped. The confirmation is Nop-Out, and the negotiation=20 > for the new Nop-Out is via the FastMultiTaskAbort key. > 2. The initiator requirement in the "classic" case (i.e. key=20 > not negotiated) is that it respond to each TTT for affected=20 > tasks even while the task is "affected". We wanted an=20 > opposite behavior, but with a confirmation that the data=20 > transfers had stopped (so target can recover the buffer=20 > resources). The key allows this new behavior on initiator's=20 > part as well. =09 I agree that the new key is clearly required in order to terminate any TTT data transfer from any initiator early for the above reasons. =09 The proposal is that the TMF response be allowed to be sent in the face of outstanding transfers from initiators *other* than the one that sent the TMF. This does not appear to require a new key be negotiated with the *other* initiators, as (in the absence of a failure) they will complete those transfers normally. =09 > >This is approximately > >what is described in the Implementation Note at the end of > >Section 4.1.3, although that note may have been intended to > >be iSER-specific - if so, this is a proposal to apply it to > >iSCSI without the RDMA extensions. >=20 > Actually the note is intended for all iSCSI implementations. =20 > After seeing your observation, I decided that it needs=20 > improvement, I propose the following new text: >=20 > "Implementation note: Technically, the TMF servicing is=20 > complete in Step.e. Data transfers corresponding to=20 > terminated tasks may however still be in progress even at the=20 > end of Step.f. TMF Response MUST NOT be sent by the target=20 > iSCSI layer before the end of Step.e, and may be sent at the=20 > end of Step.e despite these outstanding Data transfers until=20 > Step.g. =09 Nit: "may be sent" --> "MAY be sent" =09 > These data transfers, if any, MUST be silently=20 > discarded by the target iSCSI layer. In the case of=20 > iSCSI/iSER, these transfers would be into tagged buffers with=20 > STags not owned by any active tasks. =09 I suggest adding: "; other implementations would deploy analogous resources to support this discarding". =09 > Step.g specifies an=20 > event to free up the resources. A target may, on an=20 > implementation-defined internal timeout, also choose to drop=20 > the connections on which it did not receive the expected=20 > Nop-Out acknowledgements so as to reclaim the associated=20 > buffer, STag and TTT resources as appropriate." =09 Nit: "A target may" --> "A target MAY" =09 > Now that I read the text after a long time, I spotted an=20 > unintended double negative in section 4.1.3, target behavior,=20 > bullet d-ii. The text should read: > "ii) each connection except the issuing connection of the=20 > issuing session that has at least one allegiant affected=20 > task." (i.e. drop "non" from "non-issuing") =09 Ok. =09 > The other thing that came to my mind after reading your note=20 > is that we don't currently have a generic key to capture the=20 > Response Fence behavior - although response fencing underlies=20 > both the fast multi-task abort as well as addressing ACA race=20 > conditions (and perhaps others down the road. e.g. around=20 > persistent reservations). So, today, the Note at the end of=20 > section 3.3.3 advises that implementations may check the=20 > FastMultiTaskAbort key to verify if safe behavior for MCS ACA=20 > is supported, although ACA has really nothing to do with=20 > multi-task aborting. I am wondering if we should create a=20 > new key (say ResponseFence), so the semantics would become: > > ResponseFence "Yes" fencing done by target =20 > "No" legacy, no fencing=20 > (so "clarified" TMF semantics are not possible either) > =20 > With ResponseFence=3D "Yes" > FastMultiTaskAbort =20 > "Yes" fast abort & fencing > "No" traditional wait on=20 > outstanding TTTs (fencing on ACA is still possible) >=20 > With ResponseFence=3D "No" > FastMultiTaskAbort =20 > "Yes" Illegal, Response Fence must be "Yes" > "No" No fencing, must wait on=20 > outstanding TTTs > =20 >=20 > The downside of this scheme is that it may be going in the=20 > opposite direction than you wanted (introduces a second key=20 > that 3720-compliant implementations don't know about). We=20 > could alternatively simply mandate the behavior equivalent to=20 > ResponseFence =3D "Yes" always and avoid the second key, but=20 > doing so could make the current 3720-compliant=20 > implementations technically non-iSCSI-compliant. >=20 > Comments? =09 Given the inter-dependence of ResponseFence and FastMultiTaskAbort, a single 3-valued key is probably simpler than two boolean keys. I think having an explicit means of determining whether ACA behaves correctly on an multi-connection-session is worth adding. =09 Thanks, --David=20 =09 > Mallikarjun =20 >=20 > ----- Original Message ---- > From: "Black_David@emc.com" > To: ips@ietf.org > Cc: Black_David@emc.com > Sent: Wednesday, November 22, 2006 2:00:25 PM > Subject: [Ips] Implementer's Guide - Task Management Issue >=20 >=20 > To make sure we actually have some content to talk about in > this WG Last Call, I'm going to reraise an issue that came > up earlier on the mailing list, but (as far as I can recall) > never got resolved. This is done with my WG chair hat OFF, > and it is a proposal for further discussion. >=20 > Section 4.1.3 changes task management, and is a non-transparent > change - it requires negotiating a new key so that both sides > agree that they support the change as it uses a round-trip > exchange of a new message (AsyncEvent 5) between initiator and > target to abort in-progress data transfers rather than completing > them. Absent this message, the target expects the initiator(s) > to complete all in-progress transfers, and is entitled to be > unhappy or worse if that doesn't happen. >=20 > For task management functions that affect tasks from more than > one initiator (CLEAR TASK SET, TARGET WARM RESET, TARGET COLD > RESET) Section 4.1.3 also allows the task management function > (TMF) to complete while the in-progress data transfers are still > being dealt with, which has the useful effect of avoiding a > situation in which an uncooperative initiator can stall the > progress of a TMF sent by another initiator. This property is > useful even if the new key is not negotiated (and hence the > AsyncEvent 5 message is not used for fast abort of data transfers) > although I think the target behavior is subtly different between > the initiator that sent the TMF and other initiators in this case: > - For the TMF sender, the target must wait for all outstanding > transfers to complete before completing the TMF, otherwise > the TMF completion comes back too early for an unmodified > initiator. > - For the other initiators, the data transfers can be immediately > redirected to bit buckets so the TMF can be completed without > waits beyond that for the TMF sender. This is approximately > what is described in the Implementation Note at the end of > Section 4.1.3, although that note may have been intended to > be iSER-specific - if so, this is a proposal to apply it to > iSCSI without the RDMA extensions. >=20 > High Availability clustering environments in which TMFs are being > used to determine cluster membership (yes, there's code out there > that does this, even though everyone should be using PERSISTENT > RESERVE) are a specific situation where this helps, as having to > wait for a dead initiator to expire (the TCP connection(s) have > to timeout and get torn down) slows down cluster recovery from a > failure. This change in target behavior (to complete a TMF faster > if other initiators don't cooperate) should be transparent to > RFC 3720-compliant initiators, but RFC 3720 has to be modified > in order to allow it; the Implementer's Guide is a vehicle that > can make that modification. >=20 > This is proposed for further discussion. >=20 > 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 > ---------------------------------------------------- =09 _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips =09 =09 ------_=_NextPart_001_01C71E2D.0A6AD84D Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Julian,
 
I agree that the target should be able to do this (not delay = TMF=20 response
waiting for an initiator that did not issue the the TMF), but = the=20 language
I quoted from RFC 3720 explicitly requires the=20 wait (and has been read
to require the wait by more than one implementer).
 
Can we agree that the implementers guide needs to clarify = RFC=20 3720
along the lines of what you = wrote, and=20 specifically say that completion
of a TMF never has to wait for a response from an = initiator other=20 than
the one that issued the TMF?
 
Thanks,
--David

From: Julian Satran=20 [mailto:Julian_Satran@il.ibm.com]
Sent: Tuesday, December = 12, 2006=20 3:12 PM
To: Black, David
Cc:=20 ips@ietf.org
Subject: RE: [Ips] Implementer's Guide - Task=20 Management Issue


David, =

The issue you are describing falls in the = same=20 category.
Target can = answer to B as=20 soon as it has "purged" the tasks regardless of what A does. =
For safety the implementation should keep = the pairs=20 ITT-TTT and make sure it does not reuse
the TTTs with the same ITT for a while or force closing = offending=20 sessions.
There is no need = to really=20 delay the TM response - just act as if all outsanding activity died = out and=20 ignore data reaching the target.

Julo


Black_David@emc.com=20

12/12/06 20:26

To
Julian=20 Satran/Haifa/IBM@IBMIL=20
cc
<ips@ietf.org>=20
Subject
RE: [Ips] Implementer's = Guide -=20 Task Management Issue

=




Julian,
 =20
> As for the issue raised by Bill = Studemund I=20 am not sure that the target needs help in
> recovering buffers (and I am not sure that I am not = repeating what=20 I said already in he past).=20
 
The=20 motivating concern is not buffer recovery - it's the ability of an=20 uncooperative initiator
to = delay completion=20 of a TMF issued by a different initiator.  Here's an = example:=20
 
- = Initiator A has=20 one or more data transfers in progress to the target.
- Initiator A dies in some inconvenient fashion. =  The=20 target thinks the iSCSI
   session with Initiator A is = still=20 alive, but Initiator A is non-responsive.
-=20 Initiator B issues a TMF that has the effect of aborting Initiator A's = tasks
    (e.g., = CLEAR TASK=20 SET).
 
The=20 issue is: When can the target issue the TMF response to Initiator = B?=20
 
Current RFC 3720=20 language requires completion of Initiator A's data transfers or = timing=20
out and dropping Initiator A's session = - Section=20 10.5.1: "The target on its part MUST
wait=20 for responses on all affected target transfer tags before acting on = either of=20 these
two task management = requests".=20  In this example, the data transfers will not
complete, requiring timing out and dropping the session = before the TMF=20 response
can be issued. =
 
The request is = that it be=20 permissible for the target to redirect Initiator A's data = transfers=20
to bit-buckets (just in case Initiator = A is not=20 actually completely dead) and issue the TMF
response once that redirection (as well as everything that = RFC 3720=20 requires with
respect to = Initiator B) is=20 done so that the TMF response doesn't have to wait for the =
target to time out and tear down the session = with Initiator=20 A.
 
Thanks,
--David =
----------------------------------------------------
David L. = Black, Senior=20 Technologist
EMC Corporation, 176 South St., Hopkinton, MA=20  01748
+1=20 (508) 293-7953             FAX: +1 (508) = 293-7786
black_david@emc.com        Mobile: +1 = (978)=20 394-7754
----------------------------------------------------<= FONT=20 size=3D3>
From: Julian Satran=20 [mailto:Julian_Satran@il.ibm.com]
Sent: Tuesday, December = 12, 2006=20 8:03 AM
To: Black, David
Cc: = cb_mallikarjun@yahoo.com;=20 ips@ietf.org
Subject: RE: [Ips] Implementer's Guide - Task=20 Management Issue


David and Mallikarjun, =

I had a long discussion with = Mallikarjun on a part=20 of this problem - namely cleaning the T-2-I path.=20
This could be done in = several ways and=20 Mallikarjun and I where also playing with sending the closing TM = response on=20 all connections as a way to speed up pipe cleaning.=20

As for the issue = raised by Bill=20 Studemund I am not sure that the target needs help in recovering = buffers (and=20 I am not sure that I am not repeating what I said already in he=20 past).
As TTT is a=20 target conceived artifact - buffers can be retired and the target can = refrain=20 from reusing the TTT with the given ITTs for some time (the rules must = be=20 quite simple).
If=20 data arrives with the bad combination - it is just discarded at the=20 target.

This=20 ways TMF can be sent early - regardless of oustanding data - provided = that the=20 target respects some simple rules for TTT use/reuse.=20
Considering also that TTTs = are also=20 not mandated to be unique beyond a single LUN - buffer retirement = while an=20 issue can be solved within 3270. =

Regards, =
Julo =



Black_David@emc.com=20

11/12/06 20:56=20


To
<cb_mallikarjun@yahoo.com>,=20 <ips@ietf.org>
cc
Subject
RE: [Ips] Implementer's = Guide -=20 Task Management Issue







Mallikarjun,

[NB: Working=20 group chair hat is **off**.]

> "I assume this is essentially = what=20 you are proposing that we
> consider (fast multi-task abort = with=20 outstanding TTTs always,
> even without the key=20 negotiation)."

Not exactly - comments interspersed below, but = what I'm=20 proposing
is that in the absence of negotiation of the new key, the = portion
of "fast multi-task abort" that allows the TMF response to=20 be
returned in the face of outstanding TTTs be allowed *only*=20 for
transfers from initiators *other* than the one that sent the = TMF.
I=20 believe that Bill Studemund raised this concern earlier, but
I = admit to=20 missing its significance at the time.

In other words when the = key is=20 not negotiated, a TMF that aborts
tasks from multiple initiators = behaves=20 differently at the target
with respect to the initiators = involved:
a)=20 There can be no change to currently specified behavior with
  =  =20            respect to the sender of the = TMF.=20  All TTT transfers have
          =  =20    to complete, and the TMF response cannot be sent = until
 =20              the transfers are = complete,=20 otherwise a 3720-compliant
          =    =20  initiator may see something that it doesn't expect.
b) = Transfers from=20 other initiators may be bit-bucketed early at
      =  =20        the target - this would be new behavior, = and new=20 language
              =  would be=20 needed to allow the TMF response to be sent once
    =  =20          these transfers from other = initiators are=20 redirected to
             =20  bit-buckets.  This does not affect a = 3720-compliant
 =20              initiator, as these = other=20 initiators do not receive a
          =  =20    response to this TMF.
The only change is the latter, = and it=20 has the effect of removing
a cross-initiator dependence for = completion of=20 the TMF.  The use
case is that there is still cluster software = out=20 there using TMFs
to maintain cluster membership instead of = persistent=20 reservations,
even though the latter is what should be = used.

>=20 Sorry for the delay in getting back.  Between vacation and =
> other=20 travel, it took me a while.  Thanks for the comments.
> =
>=20 You wrote this regarding fast multi-task abort:
> >This = property=20 is
> >useful even if the new key is not negotiated (and hence = the
> >AsyncEvent 5 message is not used for fast abort of = data=20 transfers)
>
> I assume this is essentially what you are=20 proposing that we
> consider (fast multi-task abort with = outstanding=20 TTTs always,
> even without the key negotiation).

Not = exactly,=20 see above.

> The reason we decided a new key is needed here = was for=20 two reasons:
> 1. Whenever TMF does a fast completion, target = needs an=20
> (eventual) deterministic confirmation that data transfers had =
> stopped.  The confirmation is Nop-Out, and the = negotiation=20
> for the new Nop-Out is via the FastMultiTaskAbort = key.
> 2. The=20 initiator requirement in the "classic" case (i.e. key
> not = negotiated)=20 is that it respond to each TTT for affected
> tasks even while = the task=20 is "affected".  We wanted an
> opposite behavior, but with = a=20 confirmation that the data
> transfers had stopped (so target = can=20 recover the buffer
> resources).  The key allows this new = behavior=20 on initiator's
> part as well.

I agree that the new key = is=20 clearly required in order to
terminate any TTT data transfer from = any=20 initiator early
for the above reasons.

The proposal is that = the TMF=20 response be allowed to be sent
in the face of outstanding transfers = from=20 initiators *other*
than the one that sent the TMF.  This does = not=20 appear to
require a new key be negotiated with the *other*=20 initiators,
as (in the absence of a failure) they will complete=20 those
transfers normally.

> >This is = approximately
>=20 >what is described in the Implementation Note at the end of
> = >Section 4.1.3, although that note may have been intended = to
> >be=20 iSER-specific - if so, this is a proposal to apply it to
> = >iSCSI=20 without the RDMA extensions.
>
> Actually the note is = intended=20 for all iSCSI implementations.  
> After seeing your = observation, I=20 decided that it needs
> improvement, I propose the following = new=20 text:
>
> "Implementation note: Technically, the TMF = servicing is=20
> complete in Step.e.  Data transfers corresponding to =
>=20 terminated tasks may however still be in progress even at the
> = end of=20 Step.f.  TMF Response MUST NOT be sent by the target
> = iSCSI layer=20 before the end of Step.e, and may be sent at the
> end of = Step.e=20 despite these outstanding Data transfers until
> = Step.g.

Nit:=20 "may be sent" --> "MAY be sent"

> These data transfers, = if any,=20 MUST be silently
> discarded by the target iSCSI layer. =  In the=20 case of
> iSCSI/iSER, these transfers would be into tagged = buffers with=20
> STags not owned by any active tasks.

I suggest adding: = ";=20 other implementations would deploy
analogous resources to support = this=20 discarding".

> Step.g specifies an
> event to free up = the=20 resources.  A target may, on an
> implementation-defined = internal=20 timeout, also choose to drop
> the connections on which it did = not=20 receive the expected
> Nop-Out acknowledgements so as to = reclaim the=20 associated
> buffer, STag and TTT resources as=20 appropriate."

Nit: "A target may" --> "A target = MAY"

> Now=20 that I read the text after a long time, I spotted an
> = unintended=20 double negative in section 4.1.3, target behavior,
> bullet = d-ii.=20  The text should read:
> "ii) each connection except the = issuing=20 connection of the
> issuing session that has at least one = allegiant=20 affected
> task."    (i.e. drop "non" from=20 "non-issuing")

Ok.

> The other thing that came to my = mind=20 after reading your note
> is that we don't currently have a = generic key=20 to capture the
> Response Fence behavior - although response = fencing=20 underlies
> both the fast multi-task abort as well as = addressing ACA=20 race
> conditions (and perhaps others down the road. e.g. = around=20
> persistent reservations).  So, today, the Note at the = end of=20
> section 3.3.3 advises that implementations may check the =
>=20 FastMultiTaskAbort key to verify if safe behavior for MCS ACA
> = is=20 supported, although ACA has really nothing to do with
> = multi-task=20 aborting.  I am wondering if we should create a
> new key = (say=20 ResponseFence), so the semantics would become:
>     =  =20                     =  =20                     =  =20                     =
>=20        ResponseFence    "Yes" =  fencing done=20 by target      
>         =  =20                     =  =20    "No"   legacy, no fencing
> (so "clarified" = TMF=20 semantics are not possible either)
>       =  
>=20 With ResponseFence=3D    "Yes"
> FastMultiTaskAbort =  =20  
>       "Yes"         =  =20         fast abort & fencing     =  =20        
>        "No" =  =20                 =  traditional wait=20 on
> outstanding TTTs (fencing on ACA is still = possible)
>=20
> With ResponseFence=3D    "No"
> = FastMultiTaskAbort=20    
>       "Yes"       =  =20           Illegal, Response Fence must be=20 "Yes"
>        "No"       =  =20            No fencing, must wait on =
>=20 outstanding TTTs
>  
>
> The downside of this = scheme=20 is that it may be going in the
> opposite direction than you = wanted=20 (introduces a second key
> that 3720-compliant implementations = don't=20 know about).  We
> could alternatively simply mandate the = behavior=20 equivalent to
> ResponseFence =3D "Yes" always and avoid the = second key,=20 but
> doing so could make the current 3720-compliant
>=20 implementations technically non-iSCSI-compliant.
>
>=20 Comments?

Given the inter-dependence of ResponseFence and=20 FastMultiTaskAbort,
a single 3-valued key is probably simpler than = two=20 boolean keys.
I think having an explicit means of determining = whether ACA=20 behaves
correctly on an multi-connection-session is worth=20 adding.

Thanks,
--David

> Mallikarjun   =  =20                     =  =20  
>
> ----- Original Message ----
> From:=20 "Black_David@emc.com" <Black_David@emc.com>
> To:=20 ips@ietf.org
> Cc: Black_David@emc.com
> Sent: Wednesday, = November=20 22, 2006 2:00:25 PM
> Subject: [Ips] Implementer's Guide - Task=20 Management Issue
>
>
> To make sure we actually = have some=20 content to talk about in
> this WG Last Call, I'm going to = reraise an=20 issue that came
> up earlier on the mailing list, but (as far as = I can=20 recall)
> never got resolved.  This is done with my WG = chair hat=20 OFF,
> and it is a proposal for further discussion.
> =
>=20 Section 4.1.3 changes task management, and is a = non-transparent
> change=20 - it requires negotiating a new key so that both sides
> agree = that they=20 support the change as it uses a round-trip
> exchange of a new = message=20 (AsyncEvent 5) between initiator and
> target to abort = in-progress data=20 transfers rather than completing
> them.  Absent this = message, the=20 target expects the initiator(s)
> to complete all in-progress = transfers,=20 and is entitled to be
> unhappy or worse if that doesn't = happen.
>=20
> For task management functions that affect tasks from more=20 than
> one initiator (CLEAR TASK SET, TARGET WARM RESET, TARGET=20 COLD
> RESET)  Section 4.1.3 also allows the task = management=20 function
> (TMF) to complete while the in-progress data = transfers are=20 still
> being dealt with, which has the useful effect of = avoiding=20 a
> situation in which an uncooperative initiator can stall = the
>=20 progress of a TMF sent by another initiator.  This property = is
>=20 useful even if the new key is not negotiated (and hence the
> = AsyncEvent=20 5 message is not used for fast abort of data transfers)
> = although I=20 think the target behavior is subtly different between
> the = initiator=20 that sent the TMF and other initiators in this case:
> - For the = TMF=20 sender, the target must wait for all outstanding
>     = transfers to complete before completing the TMF, otherwise
> =  =20   the TMF completion comes back too early for an = unmodified
>=20     initiator.
> - For the other initiators, the data=20 transfers can be immediately
>     redirected to bit = buckets=20 so the TMF can be completed without
>     waits beyond = that=20 for the TMF sender.  This is approximately
>     = what is=20 described in the Implementation Note at the end of
>   =  =20 Section 4.1.3, although that note may have been intended to
> =  =20   be iSER-specific - if so, this is a proposal to apply it = to
>=20     iSCSI without the RDMA extensions.
>
> High = Availability clustering environments in which TMFs are being
> = used to=20 determine cluster membership (yes, there's code out there
> that = does=20 this, even though everyone should be using PERSISTENT
> RESERVE) = are a=20 specific situation where this helps, as having to
> wait for a = dead=20 initiator to expire (the TCP connection(s) have
> to timeout and = get=20 torn down) slows down cluster recovery from a
> failure. =  This=20 change in target behavior (to complete a TMF faster
> if other=20 initiators don't cooperate) should be transparent to
> RFC=20 3720-compliant initiators, but RFC 3720 has to be modified
> in = order to=20 allow it; the Implementer's Guide is a vehicle that
> can make = that=20 modification.
>
> This is proposed for further=20 discussion.
>
> Thanks,
> --David
>=20 ----------------------------------------------------
> David L. = Black,=20 Senior Technologist
> EMC Corporation, 176 South St., Hopkinton, = MA=20  01748
> +1 (508) 293-7953         =  =20   FAX: +1 (508) 293-7786
> black_david@emc.com   =    =20  Mobile: +1 (978) 394-7754
>=20 = ----------------------------------------------------

_____________= __________________________________
Ips=20 mailing=20 = list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips=

------_=_NextPart_001_01C71E2D.0A6AD84D-- --===============1380268140== 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 --===============1380268140==-- From ips-bounces@ietf.org Tue Dec 12 15:50:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuEZu-00064j-3E; Tue, 12 Dec 2006 15:50:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuEZq-0005yu-4D; Tue, 12 Dec 2006 15:50:14 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuEZp-0005Ei-Sh; Tue, 12 Dec 2006 15:50:14 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id D244B32B21; Tue, 12 Dec 2006 20:50:13 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GuEZp-00083M-Kb; Tue, 12 Dec 2006 15:50:13 -0500 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 Dec 2006 15:50:13 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: ips@ietf.org Subject: [Ips] I-D ACTION:draft-ietf-ips-iwarp-da-05.txt X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Storage Working Group of the IETF. Title : Datamover Architecture for iSCSI (DA) Author(s) : M. Chadalapaka, et al. Filename : draft-ietf-ips-iwarp-da-05.txt,.pdf Pages : 65 Date : 2006-12-12 iSCSI is a SCSI transport protocol that maps the SCSI family of application protocols onto TCP/IP. Datamover Architecture for iSCSI (DA) defines an abstract model in which the movement of data between iSCSI end nodes is logically separated from the rest of the iSCSI protocol in order to allow iSCSI to adapt to innovations available in new IP transports. While DA defines the architectural functions required of the class of Datamover protocols, it does not define any specific Datamover protocols. Each such Datamover protocol, to be defined in a separate document, provides a reliable transport for all iSCSI PDUs, but actually moves the data required for certain iSCSI PDUs without involving the remote iSCSI layer itself. This document begins with an introduction of a few new abstractions, defines a layered architecture for iSCSI and Datamover protocols, and then models the interactions within an iSCSI end node between the iSCSI layer and the Datamover layer that happen in order to transparently perform remote data movement within an IP fabric. It is intended that this definition would help map iSCSI to generic RDMA-capable IP fabrics in the future comprising TCP, SCTP, and possibly other underlying network transport layers such as InfiniBand. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-iwarp-da-05.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-iwarp-da-05.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-iwarp-da-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-12-12113656.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-iwarp-da-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-iwarp-da-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-12-12113656.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 Dec 12 17:31:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuG9s-0005zs-Om; Tue, 12 Dec 2006 17:31:32 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuG9q-0005yN-TK for ips@ietf.org; Tue, 12 Dec 2006 17:31:30 -0500 Received: from imf22aec.mail.bellsouth.net ([205.152.59.70]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GuG9n-0000Ck-51 for ips@ietf.org; Tue, 12 Dec 2006 17:31:30 -0500 Received: from ibm67aec.bellsouth.net ([74.245.52.54]) by imf22aec.mail.bellsouth.net with ESMTP id <20061212223101.DBQC20677.imf22aec.mail.bellsouth.net@ibm67aec.bellsouth.net> for ; Tue, 12 Dec 2006 17:31:01 -0500 Received: from IVVTDKV0981 ([74.245.52.54]) by ibm67aec.bellsouth.net with SMTP id <20061212223100.LZAQ27738.ibm67aec.bellsouth.net@IVVTDKV0981>; Tue, 12 Dec 2006 17:31:00 -0500 Message-ID: <001a01c71e3d$32882510$01faa8c0@ivivity.com> From: "Eddy Quicksall" To: "Mallikarjun C." , "Julian Satran" References: Subject: Re: [Ips] IG clarifications: Login Response & Reject reason codes Date: Tue, 12 Dec 2006 17:30:58 -0500 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.1 (/) X-Scan-Signature: 8d89ee9312a95de8ee48d1c94511f1bb 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="===============1822378869==" Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============1822378869== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0017_01C71E13.496116E0" This is a multi-part message in MIME format. ------=_NextPart_000_0017_01C71E13.496116E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Julian, Then the negotiation reset applies to only the current negotiation = exchange? If so then maybe this needs to be cleared up. The only place I process that in my target is when I'm in a full feature = phase text negotiation. If I receive it I reset the fact that I may be = in a continuation state. I figured it was for that purpose. I don't know = why an initiator would "change his mind in the middle of the stream". An initiator MAY reset an operational parameter negotiation by issuing a Text request with the Target Transfer Tag set to the value 0xffffffff after receiving a response with the Target Transfer Tag set to a value other than 0xffffffff. A target may reset an operational parameter negotiation by answering a Text request with a Reject PDU. Eddy ----- Original Message -----=20 From: Julian Satran=20 To: Mallikarjun C.=20 Cc: IPS=20 Sent: Monday, December 11, 2006 4:34 PM Subject: Re: [Ips] IG clarifications: Login Response & Reject reason = codes "Mallikarjun C." wrote on 11/12/2006 = 20:15:23: > All: >=20 > I received some offline feedback on the implementers' guide draft=20 > from a few reviewers who preferred to be anonymous. Please review = & comment. >=20 > 1) RFC 3720 does not explicitly call out that there cannot be more=20 > than one outstanding Login-Response PDU on one iSCSI connection at=20 > any given time (although the C-bit text indirectly implies it). >=20 >=20 This is intentional. At the time we where playing with the idea of = pipelining the login.=20 However it is common practice to have a single outstanding Login = Request.=20 I think that the only thing that becomes problematic is the phase = change request (there you can have only one outstanding).=20 There is already text that says that all changes to key values become = final only at the end (when consistency can be reasonably checked).=20 > Section 10.10 on Text Request PDU (which should cover Login Request=20 > PDU semantics as well) says: "An initiator MUST have at most one=20 > outstanding Text Request on a connection at any given time." =20 > Essentially, an analog for Login/Text Response is missing (or so it = seems). >=20 > 2) RFC 3720 does not specify the use case for Reject reason code=20 > "Task in progress" (0x07). >=20 > I vaguely recall we put in this reason code for task reassignment=20 > attempts while a task is in progress, but then we subsequently added > a TMF response reason code for that case (Julian?). So I'm not sure > if reason code 0x07 is used by implementations any longer. =20 >=20 The reject can used when the initiator attempts to start a new task = but a task with the same ITT is still active for those cases when the = target can't be sure this is a protocol error (e.g., a race between a = logout and a reissued SCSI command).=20 > The other non-obvious case is that of a "negotiation reset" Reject=20 > reason code. What is this used for by implementations, if at all? =20 > If I don't hear any objections, I will deprecate these two reason = codes. >=20 The negotiating can't be continued by one of the parties but the = partial results (e.g., previous stage) are OK and no renegotiation is = deemed necessary. I have no clue if somebody uses it but I felt at the = time that the purists will object if I'd suggest restarting the login = :-)=20 > Mallikarjun >=20 >=20 > =20 > = _________________________________________________________________________= ___________ > Do you Yahoo!? > Everyone is raving about the all-new Yahoo! Mail beta. > http://new.mail.yahoo.com >=20 > _______________________________________________ > 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 ------=_NextPart_000_0017_01C71E13.496116E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Julian,
 
Then the negotiation reset applies to only the = current=20 negotiation exchange? If so then maybe this needs to be cleared = up.
 
The only place I process that in my target is when = I'm in a=20 full feature phase text negotiation. If I receive = it I reset the=20 fact that I may be in a continuation state. I figured it was for = that=20 purpose. I don't know why an initiator would "change his mind in the = middle of=20 the stream".
 
   An initiator MAY reset an operational = parameter=20 negotiation by
   issuing a Text request with the Target = Transfer=20 Tag set to the value
   0xffffffff after receiving a = response with=20 the Target Transfer Tag
   set to a value other than=20 0xffffffff.  A target may reset an
   operational = parameter=20 negotiation by answering a Text request with a
   Reject=20 PDU.
 
Eddy
----- Original Message -----
From:=20 Julian Satran
Cc: IPS
Sent: Monday, December 11, 2006 = 4:34=20 PM
Subject: Re: [Ips] IG = clarifications:=20 Login Response & Reject reason codes



"Mallikarjun C." <cb_mallikarjun@yahoo.com>= wrote=20 on 11/12/2006 20:15:23:

> All:
>
> I received = some=20 offline feedback on the implementers' guide draft
> from =  a few=20 reviewers who preferred to be anonymous.  Please review &=20 comment.
>
> 1) RFC 3720 does not explicitly call out = that there=20 cannot be more
> than one outstanding Login-Response PDU on one = iSCSI=20 connection at
> any given time (although the C-bit text = indirectly=20 implies it).
>
>=20

This is intentional. At the time we where = playing=20 with the idea of pipelining the login.
However it is common practice to have a single outstanding = Login=20 Request.
I think that the only = thing that=20 becomes problematic is the phase change request (there you can have = only one=20 outstanding).
There is already text = that says=20 that all changes to key values become final only at the end (when = consistency=20 can be reasonably checked).

> Section=20 10.10 on Text Request PDU (which should cover Login Request
> = PDU=20 semantics as well) says: "An initiator MUST have at most one
>=20 outstanding Text Request on a connection at any given time." =  
>=20 Essentially, an analog for Login/Text Response is missing (or so it=20 seems).
>
> 2) RFC 3720 does not specify the use case for = Reject=20 reason code
> "Task in progress" (0x07).
>
> I = vaguely=20 recall we put in this reason code for task reassignment
> = attempts=20 while a task is in progress, but then we subsequently added
> a = TMF=20 response reason code for that case (Julian?).  So I'm not = sure
> if=20 reason code 0x07 is used by implementations any longer.  
> =

The reject can used when the = initiator=20 attempts to start a new task but a task with the same ITT is still = active for=20 those cases when the target can't be sure this is a protocol error = (e.g., a=20 race between a logout and a reissued SCSI command). =

> The other non-obvious case is that of a "negotiation = reset"=20 Reject
> reason code.  What is this used for by = implementations,=20 if at all?  
> If I don't hear any objections, I will = deprecate=20 these two reason codes.
>

The=20 negotiating can't be continued by one of the parties but the partial = results=20 (e.g., previous stage) are OK and no renegotiation is deemed = necessary. I have=20 no clue if somebody uses it but I felt at the time that the purists = will=20 object if I'd suggest restarting the login :-) =

> Mallikarjun
>
>
>  
> = = _________________________________________________________________________= ___________
>=20 Do you Yahoo!?
> Everyone is raving about the all-new Yahoo! = Mail=20 beta.
> http://new.mail.yahoo.com
>
>=20 _______________________________________________
> Ips mailing=20 list
> Ips@ietf.org
>=20 https://www1.ietf.org/mailman/listinfo/ips

_______________________________________________
Ips mailing=20 = list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips
------=_NextPart_000_0017_01C71E13.496116E0-- --===============1822378869== 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 --===============1822378869==-- From ips-bounces@ietf.org Tue Dec 12 17:48:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuGPn-0000VT-FS; Tue, 12 Dec 2006 17:47:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuGPl-0000VE-JM for ips@ietf.org; Tue, 12 Dec 2006 17:47:57 -0500 Received: from imf22aec.mail.bellsouth.net ([205.152.59.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuGPk-0005ha-8d for ips@ietf.org; Tue, 12 Dec 2006 17:47:57 -0500 Received: from ibm67aec.bellsouth.net ([74.245.52.54]) by imf22aec.mail.bellsouth.net with ESMTP id <20061212224652.IPPQ20677.imf22aec.mail.bellsouth.net@ibm67aec.bellsouth.net> for ; Tue, 12 Dec 2006 17:46:52 -0500 Received: from IVVTDKV0981 ([74.245.52.54]) by ibm67aec.bellsouth.net with SMTP id <20061212224650.MJLJ27738.ibm67aec.bellsouth.net@IVVTDKV0981>; Tue, 12 Dec 2006 17:46:50 -0500 Message-ID: <004701c71e3f$68a0cc90$01faa8c0@ivivity.com> From: "Eddy Quicksall" To: , "Julian Satran" References: Subject: Re: [Ips] Implementer's Guide - Task Management Issue Date: Tue, 12 Dec 2006 17:46:48 -0500 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.3 (/) X-Scan-Signature: efe398576bb2a85e16acd0966bf255bb 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="===============1593993256==" Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============1593993256== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0044_01C71E15.7F8F4230" This is a multi-part message in MIME format. ------=_NextPart_000_0044_01C71E15.7F8F4230 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I want to be sure of something here ... you are not requiring this = ITT-TTT tracking are you? It would be very difficult for hardware. Eddy ----- Original Message -----=20 From: Julian Satran=20 To: Black_David@emc.com=20 Cc: ips@ietf.org=20 Sent: Tuesday, December 12, 2006 3:12 PM Subject: RE: [Ips] Implementer's Guide - Task Management Issue David,=20 The issue you are describing falls in the same category.=20 Target can answer to B as soon as it has "purged" the tasks regardless = of what A does.=20 For safety the implementation should keep the pairs ITT-TTT and make = sure it does not reuse=20 the TTTs with the same ITT for a while or force closing offending = sessions.=20 There is no need to really delay the TM response - just act as if all = outsanding activity died out and ignore data reaching the target.=20 Julo=20 Black_David@emc.com=20 12/12/06 20:26=20 To Julian Satran/Haifa/IBM@IBMIL =20 cc =20 Subject RE: [Ips] Implementer's Guide - Task Management = Issue=20 =20 =20 Julian,=20 =20 > As for the issue raised by Bill Studemund I am not sure that the = target needs help in=20 > recovering buffers (and I am not sure that I am not repeating what I = said already in he past).=20 =20 The motivating concern is not buffer recovery - it's the ability of an = uncooperative initiator=20 to delay completion of a TMF issued by a different initiator. Here's = an example:=20 =20 - Initiator A has one or more data transfers in progress to the = target.=20 - Initiator A dies in some inconvenient fashion. The target thinks = the iSCSI session with Initiator A is still alive, but Initiator A is = non-responsive.=20 - Initiator B issues a TMF that has the effect of aborting Initiator = A's tasks=20 (e.g., CLEAR TASK SET).=20 =20 The issue is: When can the target issue the TMF response to Initiator = B?=20 =20 Current RFC 3720 language requires completion of Initiator A's data = transfers or timing=20 out and dropping Initiator A's session - Section 10.5.1: "The target = on its part MUST=20 wait for responses on all affected target transfer tags before acting = on either of these=20 two task management requests". In this example, the data transfers = will not=20 complete, requiring timing out and dropping the session before the TMF = response=20 can be issued.=20 =20 The request is that it be permissible for the target to redirect = Initiator A's data transfers=20 to bit-buckets (just in case Initiator A is not actually completely = dead) and issue the TMF=20 response once that redirection (as well as everything that RFC 3720 = requires with=20 respect to Initiator B) is done so that the TMF response doesn't have = to wait for the=20 target to time out and tear down the session with Initiator A.=20 =20 Thanks,=20 --David=20 ----------------------------------------------------=20 David L. Black, Senior Technologist=20 EMC Corporation, 176 South St., Hopkinton, MA 01748=20 +1 (508) 293-7953 FAX: +1 (508) 293-7786=20 black_david@emc.com Mobile: +1 (978) 394-7754=20 ----------------------------------------------------=20 -------------------------------------------------------------------------= ----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com]=20 Sent: Tuesday, December 12, 2006 8:03 AM To: Black, David Cc: cb_mallikarjun@yahoo.com; ips@ietf.org Subject: RE: [Ips] Implementer's Guide - Task Management Issue David and Mallikarjun,=20 I had a long discussion with Mallikarjun on a part of this problem - = namely cleaning the T-2-I path.=20 This could be done in several ways and Mallikarjun and I where also = playing with sending the closing TM response on all connections as a way = to speed up pipe cleaning.=20 As for the issue raised by Bill Studemund I am not sure that the = target needs help in recovering buffers (and I am not sure that I am not = repeating what I said already in he past).=20 As TTT is a target conceived artifact - buffers can be retired and the = target can refrain from reusing the TTT with the given ITTs for some = time (the rules must be quite simple).=20 If data arrives with the bad combination - it is just discarded at the = target.=20 This ways TMF can be sent early - regardless of oustanding data - = provided that the target respects some simple rules for TTT use/reuse.=20 Considering also that TTTs are also not mandated to be unique beyond a = single LUN - buffer retirement while an issue can be solved within 3270. = Regards,=20 Julo=20 Black_David@emc.com=20 11/12/06 20:56=20 =20 To , =20 cc =20 Subject RE: [Ips] Implementer's Guide - Task Management = Issue=20 =20 =20 Mallikarjun, [NB: Working group chair hat is **off**.] > "I assume this is essentially what you are proposing that we=20 > consider (fast multi-task abort with outstanding TTTs always,=20 > even without the key negotiation)." Not exactly - comments interspersed below, but what I'm proposing is that in the absence of negotiation of the new key, the portion of "fast multi-task abort" that allows the TMF response to be returned in the face of outstanding TTTs be allowed *only* for transfers from initiators *other* than the one that sent the TMF. I believe that Bill Studemund raised this concern earlier, but I admit to missing its significance at the time. In other words when the key is not negotiated, a TMF that aborts tasks from multiple initiators behaves differently at the target with respect to the initiators involved: a) There can be no change to currently specified behavior with respect to the sender of the TMF. All TTT transfers = have to complete, and the TMF response cannot be sent until the transfers are complete, otherwise a 3720-compliant initiator may see something that it doesn't expect. b) Transfers from other initiators may be bit-bucketed early at the target - this would be new behavior, and new = language would be needed to allow the TMF response to be sent = once these transfers from other initiators are redirected to bit-buckets. This does not affect a 3720-compliant initiator, as these other initiators do not receive a response to this TMF. The only change is the latter, and it has the effect of removing a cross-initiator dependence for completion of the TMF. The use case is that there is still cluster software out there using TMFs to maintain cluster membership instead of persistent reservations, even though the latter is what should be used. > Sorry for the delay in getting back. Between vacation and=20 > other travel, it took me a while. Thanks for the comments. >=20 > You wrote this regarding fast multi-task abort: > >This property is > >useful even if the new key is not negotiated (and hence the > >AsyncEvent 5 message is not used for fast abort of data transfers) >=20 > I assume this is essentially what you are proposing that we=20 > consider (fast multi-task abort with outstanding TTTs always,=20 > even without the key negotiation). Not exactly, see above. > The reason we decided a new key is needed here was for two reasons: > 1. Whenever TMF does a fast completion, target needs an=20 > (eventual) deterministic confirmation that data transfers had=20 > stopped. The confirmation is Nop-Out, and the negotiation=20 > for the new Nop-Out is via the FastMultiTaskAbort key. > 2. The initiator requirement in the "classic" case (i.e. key=20 > not negotiated) is that it respond to each TTT for affected=20 > tasks even while the task is "affected". We wanted an=20 > opposite behavior, but with a confirmation that the data=20 > transfers had stopped (so target can recover the buffer=20 > resources). The key allows this new behavior on initiator's=20 > part as well. I agree that the new key is clearly required in order to terminate any TTT data transfer from any initiator early for the above reasons. The proposal is that the TMF response be allowed to be sent in the face of outstanding transfers from initiators *other* than the one that sent the TMF. This does not appear to require a new key be negotiated with the *other* initiators, as (in the absence of a failure) they will complete those transfers normally. > >This is approximately > >what is described in the Implementation Note at the end of > >Section 4.1.3, although that note may have been intended to > >be iSER-specific - if so, this is a proposal to apply it to > >iSCSI without the RDMA extensions. >=20 > Actually the note is intended for all iSCSI implementations. =20 > After seeing your observation, I decided that it needs=20 > improvement, I propose the following new text: >=20 > "Implementation note: Technically, the TMF servicing is=20 > complete in Step.e. Data transfers corresponding to=20 > terminated tasks may however still be in progress even at the=20 > end of Step.f. TMF Response MUST NOT be sent by the target=20 > iSCSI layer before the end of Step.e, and may be sent at the=20 > end of Step.e despite these outstanding Data transfers until=20 > Step.g. Nit: "may be sent" --> "MAY be sent" > These data transfers, if any, MUST be silently=20 > discarded by the target iSCSI layer. In the case of=20 > iSCSI/iSER, these transfers would be into tagged buffers with=20 > STags not owned by any active tasks. I suggest adding: "; other implementations would deploy analogous resources to support this discarding". > Step.g specifies an=20 > event to free up the resources. A target may, on an=20 > implementation-defined internal timeout, also choose to drop=20 > the connections on which it did not receive the expected=20 > Nop-Out acknowledgements so as to reclaim the associated=20 > buffer, STag and TTT resources as appropriate." Nit: "A target may" --> "A target MAY" > Now that I read the text after a long time, I spotted an=20 > unintended double negative in section 4.1.3, target behavior,=20 > bullet d-ii. The text should read: > "ii) each connection except the issuing connection of the=20 > issuing session that has at least one allegiant affected=20 > task." (i.e. drop "non" from "non-issuing") Ok. > The other thing that came to my mind after reading your note=20 > is that we don't currently have a generic key to capture the=20 > Response Fence behavior - although response fencing underlies=20 > both the fast multi-task abort as well as addressing ACA race=20 > conditions (and perhaps others down the road. e.g. around=20 > persistent reservations). So, today, the Note at the end of=20 > section 3.3.3 advises that implementations may check the=20 > FastMultiTaskAbort key to verify if safe behavior for MCS ACA=20 > is supported, although ACA has really nothing to do with=20 > multi-task aborting. I am wondering if we should create a=20 > new key (say ResponseFence), so the semantics would become: > = =20 > ResponseFence "Yes" fencing done by target =20 > "No" legacy, no fencing=20 > (so "clarified" TMF semantics are not possible either) > =20 > With ResponseFence=3D "Yes" > FastMultiTaskAbort =20 > "Yes" fast abort & fencing =20 > "No" traditional wait on=20 > outstanding TTTs (fencing on ACA is still possible) >=20 > With ResponseFence=3D "No" > FastMultiTaskAbort =20 > "Yes" Illegal, Response Fence must be "Yes" > "No" No fencing, must wait on=20 > outstanding TTTs > =20 >=20 > The downside of this scheme is that it may be going in the=20 > opposite direction than you wanted (introduces a second key=20 > that 3720-compliant implementations don't know about). We=20 > could alternatively simply mandate the behavior equivalent to=20 > ResponseFence =3D "Yes" always and avoid the second key, but=20 > doing so could make the current 3720-compliant=20 > implementations technically non-iSCSI-compliant. >=20 > Comments? Given the inter-dependence of ResponseFence and FastMultiTaskAbort, a single 3-valued key is probably simpler than two boolean keys. I think having an explicit means of determining whether ACA behaves correctly on an multi-connection-session is worth adding. Thanks, --David=20 > Mallikarjun =20 >=20 > ----- Original Message ---- > From: "Black_David@emc.com" > To: ips@ietf.org > Cc: Black_David@emc.com > Sent: Wednesday, November 22, 2006 2:00:25 PM > Subject: [Ips] Implementer's Guide - Task Management Issue >=20 >=20 > To make sure we actually have some content to talk about in > this WG Last Call, I'm going to reraise an issue that came > up earlier on the mailing list, but (as far as I can recall) > never got resolved. This is done with my WG chair hat OFF, > and it is a proposal for further discussion. >=20 > Section 4.1.3 changes task management, and is a non-transparent > change - it requires negotiating a new key so that both sides > agree that they support the change as it uses a round-trip > exchange of a new message (AsyncEvent 5) between initiator and > target to abort in-progress data transfers rather than completing > them. Absent this message, the target expects the initiator(s) > to complete all in-progress transfers, and is entitled to be > unhappy or worse if that doesn't happen. >=20 > For task management functions that affect tasks from more than > one initiator (CLEAR TASK SET, TARGET WARM RESET, TARGET COLD > RESET) Section 4.1.3 also allows the task management function > (TMF) to complete while the in-progress data transfers are still > being dealt with, which has the useful effect of avoiding a > situation in which an uncooperative initiator can stall the > progress of a TMF sent by another initiator. This property is > useful even if the new key is not negotiated (and hence the > AsyncEvent 5 message is not used for fast abort of data transfers) > although I think the target behavior is subtly different between > the initiator that sent the TMF and other initiators in this case: > - For the TMF sender, the target must wait for all outstanding > transfers to complete before completing the TMF, otherwise > the TMF completion comes back too early for an unmodified > initiator. > - For the other initiators, the data transfers can be immediately > redirected to bit buckets so the TMF can be completed without > waits beyond that for the TMF sender. This is approximately > what is described in the Implementation Note at the end of > Section 4.1.3, although that note may have been intended to > be iSER-specific - if so, this is a proposal to apply it to > iSCSI without the RDMA extensions. >=20 > High Availability clustering environments in which TMFs are being > used to determine cluster membership (yes, there's code out there > that does this, even though everyone should be using PERSISTENT > RESERVE) are a specific situation where this helps, as having to > wait for a dead initiator to expire (the TCP connection(s) have > to timeout and get torn down) slows down cluster recovery from a > failure. This change in target behavior (to complete a TMF faster > if other initiators don't cooperate) should be transparent to > RFC 3720-compliant initiators, but RFC 3720 has to be modified > in order to allow it; the Implementer's Guide is a vehicle that > can make that modification. >=20 > This is proposed for further discussion. >=20 > 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 -------------------------------------------------------------------------= ----- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips ------=_NextPart_000_0044_01C71E15.7F8F4230 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I want to be sure of something here ... you are not = requiring=20 this ITT-TTT tracking are you? It would be very difficult for=20 hardware.
 
Eddy
----- Original Message -----
From:=20 Julian Satran
Sent: Tuesday, December 12, = 2006 3:12=20 PM
Subject: RE: [Ips] = Implementer's Guide -=20 Task Management Issue


David, =

The issue you are describing falls in the = same=20 category.
Target can = answer to B as=20 soon as it has "purged" the tasks regardless of what A does. =
For safety the implementation should keep = the pairs=20 ITT-TTT and make sure it does not reuse
the TTTs with the same ITT for a while or force closing = offending=20 sessions.
There is no need = to really=20 delay the TM response - just act as if all outsanding activity died = out and=20 ignore data reaching the target.

Julo


Black_David@emc.com=20

12/12/06 20:26

To
Julian=20 Satran/Haifa/IBM@IBMIL=20
cc
<ips@ietf.org>=20
Subject
RE: [Ips] Implementer's = Guide -=20 Task Management Issue

=




Julian,
 =20
> As for the issue raised by Bill = Studemund I=20 am not sure that the target needs help in
> recovering buffers (and I am not sure that I am not = repeating what=20 I said already in he past).=20
 
The=20 motivating concern is not buffer recovery - it's the ability of an=20 uncooperative initiator
to = delay completion=20 of a TMF issued by a different initiator.  Here's an = example:=20
 
- = Initiator A has=20 one or more data transfers in progress to the target.
- Initiator A dies in some inconvenient fashion. =  The=20 target thinks the iSCSI
   session with Initiator A is = still=20 alive, but Initiator A is non-responsive.
-=20 Initiator B issues a TMF that has the effect of aborting Initiator A's = tasks
    (e.g., = CLEAR TASK=20 SET).
 
The=20 issue is: When can the target issue the TMF response to Initiator = B?=20
 
Current RFC 3720=20 language requires completion of Initiator A's data transfers or = timing=20
out and dropping Initiator A's session = - Section=20 10.5.1: "The target on its part MUST
wait=20 for responses on all affected target transfer tags before acting on = either of=20 these
two task management = requests".=20  In this example, the data transfers will not
complete, requiring timing out and dropping the session = before the TMF=20 response
can be issued. =
 
The request is = that it be=20 permissible for the target to redirect Initiator A's data = transfers=20
to bit-buckets (just in case Initiator = A is not=20 actually completely dead) and issue the TMF
response once that redirection (as well as everything that = RFC 3720=20 requires with
respect to = Initiator B) is=20 done so that the TMF response doesn't have to wait for the =
target to time out and tear down the session = with Initiator=20 A.
 
Thanks,
--David =
----------------------------------------------------
David L. = Black, Senior=20 Technologist
EMC Corporation, 176 South St., Hopkinton, MA=20  01748
+1=20 (508) 293-7953             FAX: +1 (508) = 293-7786
black_david@emc.com        Mobile: +1 = (978)=20 394-7754
----------------------------------------------------<= FONT=20 size=3D3>
From: Julian Satran=20 [mailto:Julian_Satran@il.ibm.com]
Sent: Tuesday, December = 12, 2006=20 8:03 AM
To: Black, David
Cc: = cb_mallikarjun@yahoo.com;=20 ips@ietf.org
Subject: RE: [Ips] Implementer's Guide - Task=20 Management Issue


David and Mallikarjun, =

I had a long discussion with = Mallikarjun on a part=20 of this problem - namely cleaning the T-2-I path.=20
This could be done in = several ways and=20 Mallikarjun and I where also playing with sending the closing TM = response on=20 all connections as a way to speed up pipe cleaning.=20

As for the issue = raised by Bill=20 Studemund I am not sure that the target needs help in recovering = buffers (and=20 I am not sure that I am not repeating what I said already in he=20 past).
As TTT is a=20 target conceived artifact - buffers can be retired and the target can = refrain=20 from reusing the TTT with the given ITTs for some time (the rules must = be=20 quite simple).
If=20 data arrives with the bad combination - it is just discarded at the=20 target.

This=20 ways TMF can be sent early - regardless of oustanding data - provided = that the=20 target respects some simple rules for TTT use/reuse.=20
Considering also that TTTs = are also=20 not mandated to be unique beyond a single LUN - buffer retirement = while an=20 issue can be solved within 3270. =

Regards, =
Julo =



Black_David@emc.com=20

11/12/06 20:56=20


To
<cb_mallikarjun@yahoo.com>,=20 <ips@ietf.org>
cc
Subject
RE: [Ips] Implementer's = Guide -=20 Task Management Issue







Mallikarjun,

[NB: Working=20 group chair hat is **off**.]

> "I assume this is essentially = what=20 you are proposing that we
> consider (fast multi-task abort = with=20 outstanding TTTs always,
> even without the key=20 negotiation)."

Not exactly - comments interspersed below, but = what I'm=20 proposing
is that in the absence of negotiation of the new key, the = portion
of "fast multi-task abort" that allows the TMF response to=20 be
returned in the face of outstanding TTTs be allowed *only*=20 for
transfers from initiators *other* than the one that sent the = TMF.
I=20 believe that Bill Studemund raised this concern earlier, but
I = admit to=20 missing its significance at the time.

In other words when the = key is=20 not negotiated, a TMF that aborts
tasks from multiple initiators = behaves=20 differently at the target
with respect to the initiators = involved:
a)=20 There can be no change to currently specified behavior with
  =  =20            respect to the sender of the = TMF.=20  All TTT transfers have
          =  =20    to complete, and the TMF response cannot be sent = until
 =20              the transfers are = complete,=20 otherwise a 3720-compliant
          =    =20  initiator may see something that it doesn't expect.
b) = Transfers from=20 other initiators may be bit-bucketed early at
      =  =20        the target - this would be new behavior, = and new=20 language
              =  would be=20 needed to allow the TMF response to be sent once
    =  =20          these transfers from other = initiators are=20 redirected to
             =20  bit-buckets.  This does not affect a = 3720-compliant
 =20              initiator, as these = other=20 initiators do not receive a
          =  =20    response to this TMF.
The only change is the latter, = and it=20 has the effect of removing
a cross-initiator dependence for = completion of=20 the TMF.  The use
case is that there is still cluster software = out=20 there using TMFs
to maintain cluster membership instead of = persistent=20 reservations,
even though the latter is what should be = used.

>=20 Sorry for the delay in getting back.  Between vacation and =
> other=20 travel, it took me a while.  Thanks for the comments.
> =
>=20 You wrote this regarding fast multi-task abort:
> >This = property=20 is
> >useful even if the new key is not negotiated (and hence = the
> >AsyncEvent 5 message is not used for fast abort of = data=20 transfers)
>
> I assume this is essentially what you are=20 proposing that we
> consider (fast multi-task abort with = outstanding=20 TTTs always,
> even without the key negotiation).

Not = exactly,=20 see above.

> The reason we decided a new key is needed here = was for=20 two reasons:
> 1. Whenever TMF does a fast completion, target = needs an=20
> (eventual) deterministic confirmation that data transfers had =
> stopped.  The confirmation is Nop-Out, and the = negotiation=20
> for the new Nop-Out is via the FastMultiTaskAbort = key.
> 2. The=20 initiator requirement in the "classic" case (i.e. key
> not = negotiated)=20 is that it respond to each TTT for affected
> tasks even while = the task=20 is "affected".  We wanted an
> opposite behavior, but with = a=20 confirmation that the data
> transfers had stopped (so target = can=20 recover the buffer
> resources).  The key allows this new = behavior=20 on initiator's
> part as well.

I agree that the new key = is=20 clearly required in order to
terminate any TTT data transfer from = any=20 initiator early
for the above reasons.

The proposal is that = the TMF=20 response be allowed to be sent
in the face of outstanding transfers = from=20 initiators *other*
than the one that sent the TMF.  This does = not=20 appear to
require a new key be negotiated with the *other*=20 initiators,
as (in the absence of a failure) they will complete=20 those
transfers normally.

> >This is = approximately
>=20 >what is described in the Implementation Note at the end of
> = >Section 4.1.3, although that note may have been intended = to
> >be=20 iSER-specific - if so, this is a proposal to apply it to
> = >iSCSI=20 without the RDMA extensions.
>
> Actually the note is = intended=20 for all iSCSI implementations.  
> After seeing your = observation, I=20 decided that it needs
> improvement, I propose the following = new=20 text:
>
> "Implementation note: Technically, the TMF = servicing is=20
> complete in Step.e.  Data transfers corresponding to =
>=20 terminated tasks may however still be in progress even at the
> = end of=20 Step.f.  TMF Response MUST NOT be sent by the target
> = iSCSI layer=20 before the end of Step.e, and may be sent at the
> end of = Step.e=20 despite these outstanding Data transfers until
> = Step.g.

Nit:=20 "may be sent" --> "MAY be sent"

> These data transfers, = if any,=20 MUST be silently
> discarded by the target iSCSI layer. =  In the=20 case of
> iSCSI/iSER, these transfers would be into tagged = buffers with=20
> STags not owned by any active tasks.

I suggest adding: = ";=20 other implementations would deploy
analogous resources to support = this=20 discarding".

> Step.g specifies an
> event to free up = the=20 resources.  A target may, on an
> implementation-defined = internal=20 timeout, also choose to drop
> the connections on which it did = not=20 receive the expected
> Nop-Out acknowledgements so as to = reclaim the=20 associated
> buffer, STag and TTT resources as=20 appropriate."

Nit: "A target may" --> "A target = MAY"

> Now=20 that I read the text after a long time, I spotted an
> = unintended=20 double negative in section 4.1.3, target behavior,
> bullet = d-ii.=20  The text should read:
> "ii) each connection except the = issuing=20 connection of the
> issuing session that has at least one = allegiant=20 affected
> task."    (i.e. drop "non" from=20 "non-issuing")

Ok.

> The other thing that came to my = mind=20 after reading your note
> is that we don't currently have a = generic key=20 to capture the
> Response Fence behavior - although response = fencing=20 underlies
> both the fast multi-task abort as well as = addressing ACA=20 race
> conditions (and perhaps others down the road. e.g. = around=20
> persistent reservations).  So, today, the Note at the = end of=20
> section 3.3.3 advises that implementations may check the =
>=20 FastMultiTaskAbort key to verify if safe behavior for MCS ACA
> = is=20 supported, although ACA has really nothing to do with
> = multi-task=20 aborting.  I am wondering if we should create a
> new key = (say=20 ResponseFence), so the semantics would become:
>     =  =20                     =  =20                     =  =20                     =
>=20        ResponseFence    "Yes" =  fencing done=20 by target      
>         =  =20                     =  =20    "No"   legacy, no fencing
> (so "clarified" = TMF=20 semantics are not possible either)
>       =  
>=20 With ResponseFence=3D    "Yes"
> FastMultiTaskAbort =  =20  
>       "Yes"         =  =20         fast abort & fencing     =  =20        
>        "No" =  =20                 =  traditional wait=20 on
> outstanding TTTs (fencing on ACA is still = possible)
>=20
> With ResponseFence=3D    "No"
> = FastMultiTaskAbort=20    
>       "Yes"       =  =20           Illegal, Response Fence must be=20 "Yes"
>        "No"       =  =20            No fencing, must wait on =
>=20 outstanding TTTs
>  
>
> The downside of this = scheme=20 is that it may be going in the
> opposite direction than you = wanted=20 (introduces a second key
> that 3720-compliant implementations = don't=20 know about).  We
> could alternatively simply mandate the = behavior=20 equivalent to
> ResponseFence =3D "Yes" always and avoid the = second key,=20 but
> doing so could make the current 3720-compliant
>=20 implementations technically non-iSCSI-compliant.
>
>=20 Comments?

Given the inter-dependence of ResponseFence and=20 FastMultiTaskAbort,
a single 3-valued key is probably simpler than = two=20 boolean keys.
I think having an explicit means of determining = whether ACA=20 behaves
correctly on an multi-connection-session is worth=20 adding.

Thanks,
--David

> Mallikarjun   =  =20                     =  =20  
>
> ----- Original Message ----
> From:=20 "Black_David@emc.com" <Black_David@emc.com>
> To:=20 ips@ietf.org
> Cc: Black_David@emc.com
> Sent: Wednesday, = November=20 22, 2006 2:00:25 PM
> Subject: [Ips] Implementer's Guide - Task=20 Management Issue
>
>
> To make sure we actually = have some=20 content to talk about in
> this WG Last Call, I'm going to = reraise an=20 issue that came
> up earlier on the mailing list, but (as far as = I can=20 recall)
> never got resolved.  This is done with my WG = chair hat=20 OFF,
> and it is a proposal for further discussion.
> =
>=20 Section 4.1.3 changes task management, and is a = non-transparent
> change=20 - it requires negotiating a new key so that both sides
> agree = that they=20 support the change as it uses a round-trip
> exchange of a new = message=20 (AsyncEvent 5) between initiator and
> target to abort = in-progress data=20 transfers rather than completing
> them.  Absent this = message, the=20 target expects the initiator(s)
> to complete all in-progress = transfers,=20 and is entitled to be
> unhappy or worse if that doesn't = happen.
>=20
> For task management functions that affect tasks from more=20 than
> one initiator (CLEAR TASK SET, TARGET WARM RESET, TARGET=20 COLD
> RESET)  Section 4.1.3 also allows the task = management=20 function
> (TMF) to complete while the in-progress data = transfers are=20 still
> being dealt with, which has the useful effect of = avoiding=20 a
> situation in which an uncooperative initiator can stall = the
>=20 progress of a TMF sent by another initiator.  This property = is
>=20 useful even if the new key is not negotiated (and hence the
> = AsyncEvent=20 5 message is not used for fast abort of data transfers)
> = although I=20 think the target behavior is subtly different between
> the = initiator=20 that sent the TMF and other initiators in this case:
> - For the = TMF=20 sender, the target must wait for all outstanding
>     = transfers to complete before completing the TMF, otherwise
> =  =20   the TMF completion comes back too early for an = unmodified
>=20     initiator.
> - For the other initiators, the data=20 transfers can be immediately
>     redirected to bit = buckets=20 so the TMF can be completed without
>     waits beyond = that=20 for the TMF sender.  This is approximately
>     = what is=20 described in the Implementation Note at the end of
>   =  =20 Section 4.1.3, although that note may have been intended to
> =  =20   be iSER-specific - if so, this is a proposal to apply it = to
>=20     iSCSI without the RDMA extensions.
>
> High = Availability clustering environments in which TMFs are being
> = used to=20 determine cluster membership (yes, there's code out there
> that = does=20 this, even though everyone should be using PERSISTENT
> RESERVE) = are a=20 specific situation where this helps, as having to
> wait for a = dead=20 initiator to expire (the TCP connection(s) have
> to timeout and = get=20 torn down) slows down cluster recovery from a
> failure. =  This=20 change in target behavior (to complete a TMF faster
> if other=20 initiators don't cooperate) should be transparent to
> RFC=20 3720-compliant initiators, but RFC 3720 has to be modified
> in = order to=20 allow it; the Implementer's Guide is a vehicle that
> can make = that=20 modification.
>
> This is proposed for further=20 discussion.
>
> Thanks,
> --David
>=20 ----------------------------------------------------
> David L. = Black,=20 Senior Technologist
> EMC Corporation, 176 South St., Hopkinton, = MA=20  01748
> +1 (508) 293-7953         =  =20   FAX: +1 (508) 293-7786
> black_david@emc.com   =    =20  Mobile: +1 (978) 394-7754
>=20 = ----------------------------------------------------

_____________= __________________________________
Ips=20 mailing=20 = list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips=

_______________________________________________
Ips mailing=20 = list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips
------=_NextPart_000_0044_01C71E15.7F8F4230-- --===============1593993256== 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 --===============1593993256==-- From ips-bounces@ietf.org Wed Dec 13 10:09:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuVij-00010l-4t; Wed, 13 Dec 2006 10:08:33 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuVig-000107-Lu; Wed, 13 Dec 2006 10:08:30 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GuVig-00018M-EA; Wed, 13 Dec 2006 10:08:30 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 5F8172AC18; Wed, 13 Dec 2006 15:08:00 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GuVi2-0004Nh-47; Wed, 13 Dec 2006 10:07:50 -0500 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Wed, 13 Dec 2006 10:07:50 -0500 X-Spam-Score: -2.8 (--) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: ips@ietf.org Subject: [Ips] Last Call: 'iSCSI Extensions for RDMA Specification' to Proposed Standard (draft-ietf-ips-iser) X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: iesg@ietf.org List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org The IESG has received a request from the IP Storage WG to consider the following documents: - 'iSCSI Extensions for RDMA Specification ' as a Proposed Standard - 'Datamover Architecture for iSCSI (DA) ' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2007-1-3. (The last call period has been lengthened to account for the holiday period.) The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ips-iser-06.txt http://www.ietf.org/internet-drafts/draft-ietf-ips-iwarp-da-05.txt _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Wed Dec 13 10:19:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuVte-0000Qc-9A; Wed, 13 Dec 2006 10:19:50 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuVtc-0000Q3-PW for ips@ietf.org; Wed, 13 Dec 2006 10:19:48 -0500 Received: from mtagate4.de.ibm.com ([195.212.29.153]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GuVta-00037R-QT for ips@ietf.org; Wed, 13 Dec 2006 10:19:48 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate4.de.ibm.com (8.13.8/8.13.8) with ESMTP id kBDFJhQc043250 for ; Wed, 13 Dec 2006 15:19:43 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id kBDFJg0E2662454 for ; Wed, 13 Dec 2006 16:19:42 +0100 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id kBDFJgWL006321 for ; Wed, 13 Dec 2006 16:19:42 +0100 Received: from d12mc102.megacenter.de.ibm.com (d12mc102.megacenter.de.ibm.com [9.149.167.114]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id kBDFJgKF006318; Wed, 13 Dec 2006 16:19:42 +0100 In-Reply-To: To: Black_David@emc.com MIME-Version: 1.0 Subject: RE: [Ips] Implementer's Guide - Task Management Issue X-Mailer: Lotus Notes Release 7.0.2 September 26, 2006 From: Julian Satran Message-ID: Date: Wed, 13 Dec 2006 17:19:40 +0200 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 7.0.2HF71 | November 3, 2006) at 13/12/2006 17:19:41, Serialize complete at 13/12/2006 17:19:41 X-Spam-Score: 0.1 (/) X-Scan-Signature: a43407b6436380862692279b407d30b9 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="===============1596185047==" Errors-To: ips-bounces@ietf.org This is a multipart message in MIME format. --===============1596185047== Content-Type: multipart/alternative; boundary="=_alternative 00543351C2257243_=" This is a multipart message in MIME format. --=_alternative 00543351C2257243_= Content-Type: text/plain; charset="US-ASCII" David, I agree - and I think there was general agreement on the mailing list that the language in 3270 (whatever it is) is confusing. Thanks, Julo Black_David@emc.com 12/12/06 22:35 To Julian Satran/Haifa/IBM@IBMIL cc ips@ietf.org Subject RE: [Ips] Implementer's Guide - Task Management Issue Julian, I agree that the target should be able to do this (not delay TMF response waiting for an initiator that did not issue the the TMF), but the language I quoted from RFC 3720 explicitly requires the wait (and has been read to require the wait by more than one implementer). Can we agree that the implementers guide needs to clarify RFC 3720 along the lines of what you wrote, and specifically say that completion of a TMF never has to wait for a response from an initiator other than the one that issued the TMF? Thanks, --David From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Tuesday, December 12, 2006 3:12 PM To: Black, David Cc: ips@ietf.org Subject: RE: [Ips] Implementer's Guide - Task Management Issue David, The issue you are describing falls in the same category. Target can answer to B as soon as it has "purged" the tasks regardless of what A does. For safety the implementation should keep the pairs ITT-TTT and make sure it does not reuse the TTTs with the same ITT for a while or force closing offending sessions. There is no need to really delay the TM response - just act as if all outsanding activity died out and ignore data reaching the target. Julo Black_David@emc.com 12/12/06 20:26 To Julian Satran/Haifa/IBM@IBMIL cc Subject RE: [Ips] Implementer's Guide - Task Management Issue Julian, > As for the issue raised by Bill Studemund I am not sure that the target needs help in > recovering buffers (and I am not sure that I am not repeating what I said already in he past). The motivating concern is not buffer recovery - it's the ability of an uncooperative initiator to delay completion of a TMF issued by a different initiator. Here's an example: - Initiator A has one or more data transfers in progress to the target. - Initiator A dies in some inconvenient fashion. The target thinks the iSCSI session with Initiator A is still alive, but Initiator A is non-responsive. - Initiator B issues a TMF that has the effect of aborting Initiator A's tasks (e.g., CLEAR TASK SET). The issue is: When can the target issue the TMF response to Initiator B? Current RFC 3720 language requires completion of Initiator A's data transfers or timing out and dropping Initiator A's session - Section 10.5.1: "The target on its part MUST wait for responses on all affected target transfer tags before acting on either of these two task management requests". In this example, the data transfers will not complete, requiring timing out and dropping the session before the TMF response can be issued. The request is that it be permissible for the target to redirect Initiator A's data transfers to bit-buckets (just in case Initiator A is not actually completely dead) and issue the TMF response once that redirection (as well as everything that RFC 3720 requires with respect to Initiator B) is done so that the TMF response doesn't have to wait for the target to time out and tear down the session with Initiator A. 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 ---------------------------------------------------- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Tuesday, December 12, 2006 8:03 AM To: Black, David Cc: cb_mallikarjun@yahoo.com; ips@ietf.org Subject: RE: [Ips] Implementer's Guide - Task Management Issue David and Mallikarjun, I had a long discussion with Mallikarjun on a part of this problem - namely cleaning the T-2-I path. This could be done in several ways and Mallikarjun and I where also playing with sending the closing TM response on all connections as a way to speed up pipe cleaning. As for the issue raised by Bill Studemund I am not sure that the target needs help in recovering buffers (and I am not sure that I am not repeating what I said already in he past). As TTT is a target conceived artifact - buffers can be retired and the target can refrain from reusing the TTT with the given ITTs for some time (the rules must be quite simple). If data arrives with the bad combination - it is just discarded at the target. This ways TMF can be sent early - regardless of oustanding data - provided that the target respects some simple rules for TTT use/reuse. Considering also that TTTs are also not mandated to be unique beyond a single LUN - buffer retirement while an issue can be solved within 3270. Regards, Julo Black_David@emc.com 11/12/06 20:56 To , cc Subject RE: [Ips] Implementer's Guide - Task Management Issue Mallikarjun, [NB: Working group chair hat is **off**.] > "I assume this is essentially what you are proposing that we > consider (fast multi-task abort with outstanding TTTs always, > even without the key negotiation)." Not exactly - comments interspersed below, but what I'm proposing is that in the absence of negotiation of the new key, the portion of "fast multi-task abort" that allows the TMF response to be returned in the face of outstanding TTTs be allowed *only* for transfers from initiators *other* than the one that sent the TMF. I believe that Bill Studemund raised this concern earlier, but I admit to missing its significance at the time. In other words when the key is not negotiated, a TMF that aborts tasks from multiple initiators behaves differently at the target with respect to the initiators involved: a) There can be no change to currently specified behavior with respect to the sender of the TMF. All TTT transfers have to complete, and the TMF response cannot be sent until the transfers are complete, otherwise a 3720-compliant initiator may see something that it doesn't expect. b) Transfers from other initiators may be bit-bucketed early at the target - this would be new behavior, and new language would be needed to allow the TMF response to be sent once these transfers from other initiators are redirected to bit-buckets. This does not affect a 3720-compliant initiator, as these other initiators do not receive a response to this TMF. The only change is the latter, and it has the effect of removing a cross-initiator dependence for completion of the TMF. The use case is that there is still cluster software out there using TMFs to maintain cluster membership instead of persistent reservations, even though the latter is what should be used. > Sorry for the delay in getting back. Between vacation and > other travel, it took me a while. Thanks for the comments. > > You wrote this regarding fast multi-task abort: > >This property is > >useful even if the new key is not negotiated (and hence the > >AsyncEvent 5 message is not used for fast abort of data transfers) > > I assume this is essentially what you are proposing that we > consider (fast multi-task abort with outstanding TTTs always, > even without the key negotiation). Not exactly, see above. > The reason we decided a new key is needed here was for two reasons: > 1. Whenever TMF does a fast completion, target needs an > (eventual) deterministic confirmation that data transfers had > stopped. The confirmation is Nop-Out, and the negotiation > for the new Nop-Out is via the FastMultiTaskAbort key. > 2. The initiator requirement in the "classic" case (i.e. key > not negotiated) is that it respond to each TTT for affected > tasks even while the task is "affected". We wanted an > opposite behavior, but with a confirmation that the data > transfers had stopped (so target can recover the buffer > resources). The key allows this new behavior on initiator's > part as well. I agree that the new key is clearly required in order to terminate any TTT data transfer from any initiator early for the above reasons. The proposal is that the TMF response be allowed to be sent in the face of outstanding transfers from initiators *other* than the one that sent the TMF. This does not appear to require a new key be negotiated with the *other* initiators, as (in the absence of a failure) they will complete those transfers normally. > >This is approximately > >what is described in the Implementation Note at the end of > >Section 4.1.3, although that note may have been intended to > >be iSER-specific - if so, this is a proposal to apply it to > >iSCSI without the RDMA extensions. > > Actually the note is intended for all iSCSI implementations. > After seeing your observation, I decided that it needs > improvement, I propose the following new text: > > "Implementation note: Technically, the TMF servicing is > complete in Step.e. Data transfers corresponding to > terminated tasks may however still be in progress even at the > end of Step.f. TMF Response MUST NOT be sent by the target > iSCSI layer before the end of Step.e, and may be sent at the > end of Step.e despite these outstanding Data transfers until > Step.g. Nit: "may be sent" --> "MAY be sent" > These data transfers, if any, MUST be silently > discarded by the target iSCSI layer. In the case of > iSCSI/iSER, these transfers would be into tagged buffers with > STags not owned by any active tasks. I suggest adding: "; other implementations would deploy analogous resources to support this discarding". > Step.g specifies an > event to free up the resources. A target may, on an > implementation-defined internal timeout, also choose to drop > the connections on which it did not receive the expected > Nop-Out acknowledgements so as to reclaim the associated > buffer, STag and TTT resources as appropriate." Nit: "A target may" --> "A target MAY" > Now that I read the text after a long time, I spotted an > unintended double negative in section 4.1.3, target behavior, > bullet d-ii. The text should read: > "ii) each connection except the issuing connection of the > issuing session that has at least one allegiant affected > task." (i.e. drop "non" from "non-issuing") Ok. > The other thing that came to my mind after reading your note > is that we don't currently have a generic key to capture the > Response Fence behavior - although response fencing underlies > both the fast multi-task abort as well as addressing ACA race > conditions (and perhaps others down the road. e.g. around > persistent reservations). So, today, the Note at the end of > section 3.3.3 advises that implementations may check the > FastMultiTaskAbort key to verify if safe behavior for MCS ACA > is supported, although ACA has really nothing to do with > multi-task aborting. I am wondering if we should create a > new key (say ResponseFence), so the semantics would become: > > ResponseFence "Yes" fencing done by target > "No" legacy, no fencing > (so "clarified" TMF semantics are not possible either) > > With ResponseFence= "Yes" > FastMultiTaskAbort > "Yes" fast abort & fencing > "No" traditional wait on > outstanding TTTs (fencing on ACA is still possible) > > With ResponseFence= "No" > FastMultiTaskAbort > "Yes" Illegal, Response Fence must be "Yes" > "No" No fencing, must wait on > outstanding TTTs > > > The downside of this scheme is that it may be going in the > opposite direction than you wanted (introduces a second key > that 3720-compliant implementations don't know about). We > could alternatively simply mandate the behavior equivalent to > ResponseFence = "Yes" always and avoid the second key, but > doing so could make the current 3720-compliant > implementations technically non-iSCSI-compliant. > > Comments? Given the inter-dependence of ResponseFence and FastMultiTaskAbort, a single 3-valued key is probably simpler than two boolean keys. I think having an explicit means of determining whether ACA behaves correctly on an multi-connection-session is worth adding. Thanks, --David > Mallikarjun > > ----- Original Message ---- > From: "Black_David@emc.com" > To: ips@ietf.org > Cc: Black_David@emc.com > Sent: Wednesday, November 22, 2006 2:00:25 PM > Subject: [Ips] Implementer's Guide - Task Management Issue > > > To make sure we actually have some content to talk about in > this WG Last Call, I'm going to reraise an issue that came > up earlier on the mailing list, but (as far as I can recall) > never got resolved. This is done with my WG chair hat OFF, > and it is a proposal for further discussion. > > Section 4.1.3 changes task management, and is a non-transparent > change - it requires negotiating a new key so that both sides > agree that they support the change as it uses a round-trip > exchange of a new message (AsyncEvent 5) between initiator and > target to abort in-progress data transfers rather than completing > them. Absent this message, the target expects the initiator(s) > to complete all in-progress transfers, and is entitled to be > unhappy or worse if that doesn't happen. > > For task management functions that affect tasks from more than > one initiator (CLEAR TASK SET, TARGET WARM RESET, TARGET COLD > RESET) Section 4.1.3 also allows the task management function > (TMF) to complete while the in-progress data transfers are still > being dealt with, which has the useful effect of avoiding a > situation in which an uncooperative initiator can stall the > progress of a TMF sent by another initiator. This property is > useful even if the new key is not negotiated (and hence the > AsyncEvent 5 message is not used for fast abort of data transfers) > although I think the target behavior is subtly different between > the initiator that sent the TMF and other initiators in this case: > - For the TMF sender, the target must wait for all outstanding > transfers to complete before completing the TMF, otherwise > the TMF completion comes back too early for an unmodified > initiator. > - For the other initiators, the data transfers can be immediately > redirected to bit buckets so the TMF can be completed without > waits beyond that for the TMF sender. This is approximately > what is described in the Implementation Note at the end of > Section 4.1.3, although that note may have been intended to > be iSER-specific - if so, this is a proposal to apply it to > iSCSI without the RDMA extensions. > > High Availability clustering environments in which TMFs are being > used to determine cluster membership (yes, there's code out there > that does this, even though everyone should be using PERSISTENT > RESERVE) are a specific situation where this helps, as having to > wait for a dead initiator to expire (the TCP connection(s) have > to timeout and get torn down) slows down cluster recovery from a > failure. This change in target behavior (to complete a TMF faster > if other initiators don't cooperate) should be transparent to > RFC 3720-compliant initiators, but RFC 3720 has to be modified > in order to allow it; the Implementer's Guide is a vehicle that > can make that modification. > > This is proposed for further discussion. > > 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 _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --=_alternative 00543351C2257243_= Content-Type: text/html; charset="US-ASCII"
David,

I agree - and I think there was general agreement on the mailing list that the language in 3270 (whatever it is) is confusing.

Thanks,
Julo


Black_David@emc.com

12/12/06 22:35

To
Julian Satran/Haifa/IBM@IBMIL
cc
ips@ietf.org
Subject
RE: [Ips] Implementer's Guide - Task Management Issue





Julian,
 
I agree that the target should be able to do this (not delay TMF response
waiting for an initiator that did not issue the the TMF), but the language
I quoted from RFC 3720 explicitly requires the wait (and has been read
to require the wait by more than one implementer).
 
Can we agree that the implementers guide needs to clarify RFC 3720
along the lines of what you wrote, and specifically say that completion
of a TMF never has to wait for a response from an initiator other than
the one that issued the TMF?
 
Thanks,
--David

From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Tuesday, December 12, 2006 3:12 PM
To: Black, David
Cc: ips@ietf.org
Subject: RE: [Ips] Implementer's Guide - Task Management Issue

David,

The issue you are describing falls in the same category.
Target can answer to B as soon as it has "purged" the tasks regardless of what A does.
For safety the implementation should keep the pairs ITT-TTT and make sure it does not reuse
the TTTs with the same ITT for a while or force closing offending sessions.
There is no need to really delay the TM response - just act as if all outsanding activity died out and ignore data reaching the target.

Julo

Black_David@emc.com

12/12/06 20:26


To
Julian Satran/Haifa/IBM@IBMIL
cc
<ips@ietf.org>
Subject
RE: [Ips] Implementer's Guide - Task Management Issue







Julian,
 
> As for the issue raised by Bill Studemund I am not sure that the target needs help in
> recovering buffers (and I am not sure that I am not repeating what I said already in he past).
 
The motivating concern is not buffer recovery - it's the ability of an uncooperative initiator
to delay completion of a TMF issued by a different initiator.  Here's an example:
 
- Initiator A has one or more data transfers in progress to the target.
- Initiator A dies in some inconvenient fashion.  The target thinks the iSCSI
  session with Initiator A is still alive, but Initiator A is non-responsive.
- Initiator B issues a TMF that has the effect of aborting Initiator A's tasks
   (e.g., CLEAR TASK SET).
 
The issue is: When can the target issue the TMF response to Initiator B?
 
Current RFC 3720 language requires completion of Initiator A's data transfers or timing
out and dropping Initiator A's session - Section 10.5.1: "The target on its part MUST
wait for responses on all affected target transfer tags before acting on either of these
two task management requests".  In this example, the data transfers will not
complete, requiring timing out and dropping the session before the TMF response
can be issued.
 
The request is that it be permissible for the target to redirect Initiator A's data transfers
to bit-buckets (just in case Initiator A is not actually completely dead) and issue the TMF
response once that redirection (as well as everything that RFC 3720 requires with
respect to Initiator B) is done so that the TMF response doesn't have to wait for the
target to time out and tear down the session with Initiator A.
 
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
----------------------------------------------------
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Tuesday, December 12, 2006 8:03 AM
To: Black, David
Cc: cb_mallikarjun@yahoo.com; ips@ietf.org
Subject: RE: [Ips] Implementer's Guide - Task Management Issue


David and Mallikarjun,

I had a long discussion with Mallikarjun on a part of this problem - namely cleaning the T-2-I path.
This could be done in several ways and Mallikarjun and I where also playing with sending the closing TM response on all connections as a way to speed up pipe cleaning.

As for the issue raised by Bill Studemund I am not sure that the target needs help in recovering buffers (and I am not sure that I am not repeating what I said already in he past).
As TTT is a target conceived artifact - buffers can be retired and the target can refrain from reusing the TTT with the given ITTs for some time (the rules must be quite simple).
If data arrives with the bad combination - it is just discarded at the target.

This ways TMF can be sent early - regardless of oustanding data - provided that the target respects some simple rules for TTT use/reuse.
Considering also that TTTs are also not mandated to be unique beyond a single LUN - buffer retirement while an issue can be solved within 3270.

Regards,
Julo


Black_David@emc.com

11/12/06 20:56


To
<cb_mallikarjun@yahoo.com>, <ips@ietf.org>
cc
Subject
RE: [Ips] Implementer's Guide - Task Management Issue






Mallikarjun,

[NB: Working group chair hat is **off**.]

> "I assume this is essentially what you are proposing that we
> consider (fast multi-task abort with outstanding TTTs always,
> even without the key negotiation)."

Not exactly - comments interspersed below, but what I'm proposing
is that in the absence of negotiation of the new key, the portion
of "fast multi-task abort" that allows the TMF response to be
returned in the face of outstanding TTTs be allowed *only* for
transfers from initiators *other* than the one that sent the TMF.
I believe that Bill Studemund raised this concern earlier, but
I admit to missing its significance at the time.

In other words when the key is not negotiated, a TMF that aborts
tasks from multiple initiators behaves differently at the target
with respect to the initiators involved:
a) There can be no change to currently specified behavior with
              respect to the sender of the TMF.  All TTT transfers have
              to complete, and the TMF response cannot be sent until
              the transfers are complete, otherwise a 3720-compliant
              initiator may see something that it doesn't expect.
b) Transfers from other initiators may be bit-bucketed early at
              the target - this would be new behavior, and new language
              would be needed to allow the TMF response to be sent once
              these transfers from other initiators are redirected to
              bit-buckets.  This does not affect a 3720-compliant
              initiator, as these other initiators do not receive a
              response to this TMF.
The only change is the latter, and it has the effect of removing
a cross-initiator dependence for completion of the TMF.  The use
case is that there is still cluster software out there using TMFs
to maintain cluster membership instead of persistent reservations,
even though the latter is what should be used.

> Sorry for the delay in getting back.  Between vacation and
> other travel, it took me a while.  Thanks for the comments.
>
> You wrote this regarding fast multi-task abort:
> >This property is
> >useful even if the new key is not negotiated (and hence the
> >AsyncEvent 5 message is not used for fast abort of data transfers)
>
> I assume this is essentially what you are proposing that we
> consider (fast multi-task abort with outstanding TTTs always,
> even without the key negotiation).

Not exactly, see above.

> The reason we decided a new key is needed here was for two reasons:
> 1. Whenever TMF does a fast completion, target needs an
> (eventual) deterministic confirmation that data transfers had
> stopped.  The confirmation is Nop-Out, and the negotiation
> for the new Nop-Out is via the FastMultiTaskAbort key.
> 2. The initiator requirement in the "classic" case (i.e. key
> not negotiated) is that it respond to each TTT for affected
> tasks even while the task is "affected".  We wanted an
> opposite behavior, but with a confirmation that the data
> transfers had stopped (so target can recover the buffer
> resources).  The key allows this new behavior on initiator's
> part as well.

I agree that the new key is clearly required in order to
terminate any TTT data transfer from any initiator early
for the above reasons.

The proposal is that the TMF response be allowed to be sent
in the face of outstanding transfers from initiators *other*
than the one that sent the TMF.  This does not appear to
require a new key be negotiated with the *other* initiators,
as (in the absence of a failure) they will complete those
transfers normally.

> >This is approximately
> >what is described in the Implementation Note at the end of
> >Section 4.1.3, although that note may have been intended to
> >be iSER-specific - if so, this is a proposal to apply it to
> >iSCSI without the RDMA extensions.
>
> Actually the note is intended for all iSCSI implementations.  
> After seeing your observation, I decided that it needs
> improvement, I propose the following new text:
>
> "Implementation note: Technically, the TMF servicing is
> complete in Step.e.  Data transfers corresponding to
> terminated tasks may however still be in progress even at the
> end of Step.f.  TMF Response MUST NOT be sent by the target
> iSCSI layer before the end of Step.e, and may be sent at the
> end of Step.e despite these outstanding Data transfers until
> Step.g.

Nit: "may be sent" --> "MAY be sent"

> These data transfers, if any, MUST be silently
> discarded by the target iSCSI layer.  In the case of
> iSCSI/iSER, these transfers would be into tagged buffers with
> STags not owned by any active tasks.

I suggest adding: "; other implementations would deploy
analogous resources to support this discarding".

> Step.g specifies an
> event to free up the resources.  A target may, on an
> implementation-defined internal timeout, also choose to drop
> the connections on which it did not receive the expected
> Nop-Out acknowledgements so as to reclaim the associated
> buffer, STag and TTT resources as appropriate."

Nit: "A target may" --> "A target MAY"

> Now that I read the text after a long time, I spotted an
> unintended double negative in section 4.1.3, target behavior,
> bullet d-ii.  The text should read:
> "ii) each connection except the issuing connection of the
> issuing session that has at least one allegiant affected
> task."    (i.e. drop "non" from "non-issuing")

Ok.

> The other thing that came to my mind after reading your note
> is that we don't currently have a generic key to capture the
> Response Fence behavior - although response fencing underlies
> both the fast multi-task abort as well as addressing ACA race
> conditions (and perhaps others down the road. e.g. around
> persistent reservations).  So, today, the Note at the end of
> section 3.3.3 advises that implementations may check the
> FastMultiTaskAbort key to verify if safe behavior for MCS ACA
> is supported, although ACA has really nothing to do with
> multi-task aborting.  I am wondering if we should create a
> new key (say ResponseFence), so the semantics would become:
>                                                                      
>        ResponseFence    "Yes"  fencing done by target      
>                                    "No"   legacy, no fencing
> (so "clarified" TMF semantics are not possible either)
>        
> With ResponseFence=    "Yes"
> FastMultiTaskAbort    
>       "Yes"                   fast abort & fencing              
>        "No"                    traditional wait on
> outstanding TTTs (fencing on ACA is still possible)
>
> With ResponseFence=    "No"
> FastMultiTaskAbort    
>       "Yes"                   Illegal, Response Fence must be "Yes"
>        "No"                    No fencing, must wait on
> outstanding TTTs
>  
>
> The downside of this scheme is that it may be going in the
> opposite direction than you wanted (introduces a second key
> that 3720-compliant implementations don't know about).  We
> could alternatively simply mandate the behavior equivalent to
> ResponseFence = "Yes" always and avoid the second key, but
> doing so could make the current 3720-compliant
> implementations technically non-iSCSI-compliant.
>
> Comments?

Given the inter-dependence of ResponseFence and FastMultiTaskAbort,
a single 3-valued key is probably simpler than two boolean keys.
I think having an explicit means of determining whether ACA behaves
correctly on an multi-connection-session is worth adding.

Thanks,
--David

> Mallikarjun                            
>
> ----- Original Message ----
> From: "Black_David@emc.com" <Black_David@emc.com>
> To: ips@ietf.org
> Cc: Black_David@emc.com
> Sent: Wednesday, November 22, 2006 2:00:25 PM
> Subject: [Ips] Implementer's Guide - Task Management Issue
>
>
> To make sure we actually have some content to talk about in
> this WG Last Call, I'm going to reraise an issue that came
> up earlier on the mailing list, but (as far as I can recall)
> never got resolved.  This is done with my WG chair hat OFF,
> and it is a proposal for further discussion.
>
> Section 4.1.3 changes task management, and is a non-transparent
> change - it requires negotiating a new key so that both sides
> agree that they support the change as it uses a round-trip
> exchange of a new message (AsyncEvent 5) between initiator and
> target to abort in-progress data transfers rather than completing
> them.  Absent this message, the target expects the initiator(s)
> to complete all in-progress transfers, and is entitled to be
> unhappy or worse if that doesn't happen.
>
> For task management functions that affect tasks from more than
> one initiator (CLEAR TASK SET, TARGET WARM RESET, TARGET COLD
> RESET)  Section 4.1.3 also allows the task management function
> (TMF) to complete while the in-progress data transfers are still
> being dealt with, which has the useful effect of avoiding a
> situation in which an uncooperative initiator can stall the
> progress of a TMF sent by another initiator.  This property is
> useful even if the new key is not negotiated (and hence the
> AsyncEvent 5 message is not used for fast abort of data transfers)
> although I think the target behavior is subtly different between
> the initiator that sent the TMF and other initiators in this case:
> - For the TMF sender, the target must wait for all outstanding
>     transfers to complete before completing the TMF, otherwise
>     the TMF completion comes back too early for an unmodified
>     initiator.
> - For the other initiators, the data transfers can be immediately
>     redirected to bit buckets so the TMF can be completed without
>     waits beyond that for the TMF sender.  This is approximately
>     what is described in the Implementation Note at the end of
>     Section 4.1.3, although that note may have been intended to
>     be iSER-specific - if so, this is a proposal to apply it to
>     iSCSI without the RDMA extensions.
>
> High Availability clustering environments in which TMFs are being
> used to determine cluster membership (yes, there's code out there
> that does this, even though everyone should be using PERSISTENT
> RESERVE) are a specific situation where this helps, as having to
> wait for a dead initiator to expire (the TCP connection(s) have
> to timeout and get torn down) slows down cluster recovery from a
> failure.  This change in target behavior (to complete a TMF faster
> if other initiators don't cooperate) should be transparent to
> RFC 3720-compliant initiators, but RFC 3720 has to be modified
> in order to allow it; the Implementer's Guide is a vehicle that
> can make that modification.
>
> This is proposed for further discussion.
>
> 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
_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips
--=_alternative 00543351C2257243_=-- --===============1596185047== 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 --===============1596185047==-- From ips-bounces@ietf.org Wed Dec 13 10:32:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuW5t-0007HT-9x; Wed, 13 Dec 2006 10:32:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuW5r-0007H0-IM for ips@ietf.org; Wed, 13 Dec 2006 10:32:27 -0500 Received: from mtagate6.de.ibm.com ([195.212.29.155]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuW5l-0006qA-FO for ips@ietf.org; Wed, 13 Dec 2006 10:32:27 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate6.de.ibm.com (8.13.8/8.13.8) with ESMTP id kBDFWEIT225612 for ; Wed, 13 Dec 2006 15:32:14 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id kBDFWEGV3084500 for ; Wed, 13 Dec 2006 16:32:14 +0100 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id kBDFWEIW027038 for ; Wed, 13 Dec 2006 16:32:14 +0100 Received: from d12mc102.megacenter.de.ibm.com (d12mc102.megacenter.de.ibm.com [9.149.167.114]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id kBDFWEca027035; Wed, 13 Dec 2006 16:32:14 +0100 In-Reply-To: <001a01c71e3d$32882510$01faa8c0@ivivity.com> To: "Eddy Quicksall" MIME-Version: 1.0 Subject: Re: [Ips] IG clarifications: Login Response & Reject reason codes X-Mailer: Lotus Notes Release 7.0.2 September 26, 2006 From: Julian Satran Message-ID: Date: Wed, 13 Dec 2006 17:32:12 +0200 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 7.0.2HF71 | November 3, 2006) at 13/12/2006 17:32:13, Serialize complete at 13/12/2006 17:32:13 X-Spam-Score: 0.1 (/) X-Scan-Signature: dd887a8966a4c4c217a52303814d0b5f 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="===============0592588287==" Errors-To: ips-bounces@ietf.org This is a multipart message in MIME format. --===============0592588287== Content-Type: multipart/alternative; boundary="=_alternative 0055595EC2257243_=" This is a multipart message in MIME format. --=_alternative 0055595EC2257243_= Content-Type: text/plain; charset="US-ASCII" Eddie, It appears quite obvious that the negotiation reset "nullifies"the negotiation in progress - i.e., brings the parties back to the point they where before he negotiation started (not when the phase started). It does not nullify previously concluded negotiations nor does it nullify the login negotiation results. It obliges inititiator and target to be able to "roll-back" a negotiation. I am not sure it needs clarifying text but I have nothing against it being added. Julo "Eddy Quicksall" 13/12/06 00:30 To "Mallikarjun C." , Julian Satran/Haifa/IBM@IBMIL cc "IPS" Subject Re: [Ips] IG clarifications: Login Response & Reject reason codes Julian, Then the negotiation reset applies to only the current negotiation exchange? If so then maybe this needs to be cleared up. The only place I process that in my target is when I'm in a full feature phase text negotiation. If I receive it I reset the fact that I may be in a continuation state. I figured it was for that purpose. I don't know why an initiator would "change his mind in the middle of the stream". An initiator MAY reset an operational parameter negotiation by issuing a Text request with the Target Transfer Tag set to the value 0xffffffff after receiving a response with the Target Transfer Tag set to a value other than 0xffffffff. A target may reset an operational parameter negotiation by answering a Text request with a Reject PDU. Eddy ----- Original Message ----- From: Julian Satran To: Mallikarjun C. Cc: IPS Sent: Monday, December 11, 2006 4:34 PM Subject: Re: [Ips] IG clarifications: Login Response & Reject reason codes "Mallikarjun C." wrote on 11/12/2006 20:15:23: > All: > > I received some offline feedback on the implementers' guide draft > from a few reviewers who preferred to be anonymous. Please review & comment. > > 1) RFC 3720 does not explicitly call out that there cannot be more > than one outstanding Login-Response PDU on one iSCSI connection at > any given time (although the C-bit text indirectly implies it). > > This is intentional. At the time we where playing with the idea of pipelining the login. However it is common practice to have a single outstanding Login Request. I think that the only thing that becomes problematic is the phase change request (there you can have only one outstanding). There is already text that says that all changes to key values become final only at the end (when consistency can be reasonably checked). > Section 10.10 on Text Request PDU (which should cover Login Request > PDU semantics as well) says: "An initiator MUST have at most one > outstanding Text Request on a connection at any given time." > Essentially, an analog for Login/Text Response is missing (or so it seems). > > 2) RFC 3720 does not specify the use case for Reject reason code > "Task in progress" (0x07). > > I vaguely recall we put in this reason code for task reassignment > attempts while a task is in progress, but then we subsequently added > a TMF response reason code for that case (Julian?). So I'm not sure > if reason code 0x07 is used by implementations any longer. > The reject can used when the initiator attempts to start a new task but a task with the same ITT is still active for those cases when the target can't be sure this is a protocol error (e.g., a race between a logout and a reissued SCSI command). > The other non-obvious case is that of a "negotiation reset" Reject > reason code. What is this used for by implementations, if at all? > If I don't hear any objections, I will deprecate these two reason codes. > The negotiating can't be continued by one of the parties but the partial results (e.g., previous stage) are OK and no renegotiation is deemed necessary. I have no clue if somebody uses it but I felt at the time that the purists will object if I'd suggest restarting the login :-) > Mallikarjun > > > > ____________________________________________________________________________________ > Do you Yahoo!? > Everyone is raving about the all-new Yahoo! Mail beta. > http://new.mail.yahoo.com > > _______________________________________________ > 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 --=_alternative 0055595EC2257243_= Content-Type: text/html; charset="US-ASCII"
Eddie,

It appears quite obvious that the negotiation reset "nullifies"the negotiation in progress - i.e., brings the parties back to the point they where before he negotiation started (not when the phase started). It does not nullify previously concluded negotiations nor does it nullify the login negotiation results.

It obliges inititiator and target to be able to "roll-back" a negotiation.

I am not sure it needs clarifying text but I have nothing against it being added.

Julo


"Eddy Quicksall" <Quicksall_iSCSI@Bellsouth.net>

13/12/06 00:30

To
"Mallikarjun C." <cb_mallikarjun@yahoo.com>, Julian Satran/Haifa/IBM@IBMIL
cc
"IPS" <ips@ietf.org>
Subject
Re: [Ips] IG clarifications: Login Response & Reject reason codes





Julian,
 
Then the negotiation reset applies to only the current negotiation exchange? If so then maybe this needs to be cleared up.
 
The only place I process that in my target is when I'm in a full feature phase text negotiation. If I receive it I reset the fact that I may be in a continuation state. I figured it was for that purpose. I don't know why an initiator would "change his mind in the middle of the stream".
 
   An initiator MAY reset an operational parameter negotiation by
  issuing a Text request with the Target Transfer Tag set to the value
  0xffffffff after receiving a response with the Target Transfer Tag
  set to a value other than 0xffffffff.  A target may reset an
  operational parameter negotiation by answering a Text request with a
  Reject PDU.
 
Eddy
----- Original Message -----
From: Julian Satran
To: Mallikarjun C.
Cc: IPS
Sent: Monday, December 11, 2006 4:34 PM
Subject: Re: [Ips] IG clarifications: Login Response & Reject reason codes



"Mallikarjun C." <cb_mallikarjun@yahoo.com> wrote on 11/12/2006 20:15:23:

> All:
>
> I received some offline feedback on the implementers' guide draft
> from  a few reviewers who preferred to be anonymous.  Please review & comment.
>
> 1) RFC 3720 does not explicitly call out that there cannot be more
> than one outstanding Login-Response PDU on one iSCSI connection at
> any given time (although the C-bit text indirectly implies it).
>
>

This is intentional. At the time we where playing with the idea of pipelining the login.
However it is common practice to have a single outstanding Login Request.
I think that the only thing that becomes problematic is the phase change request (there you can have only one outstanding).
There is already text that says that all changes to key values become final only at the end (when consistency can be reasonably checked).

> Section 10.10 on Text Request PDU (which should cover Login Request
> PDU semantics as well) says: "An initiator MUST have at most one
> outstanding Text Request on a connection at any given time."  
> Essentially, an analog for Login/Text Response is missing (or so it seems).
>
> 2) RFC 3720 does not specify the use case for Reject reason code
> "Task in progress" (0x07).
>
> I vaguely recall we put in this reason code for task reassignment
> attempts while a task is in progress, but then we subsequently added
> a TMF response reason code for that case (Julian?).  So I'm not sure
> if reason code 0x07 is used by implementations any longer.  
>

The reject can used when the initiator attempts to start a new task but a task with the same ITT is still active for those cases when the target can't be sure this is a protocol error (e.g., a race between a logout and a reissued SCSI command).

> The other non-obvious case is that of a "negotiation reset" Reject
> reason code.  What is this used for by implementations, if at all?  
> If I don't hear any objections, I will deprecate these two reason codes.
>

The negotiating can't be continued by one of the parties but the partial results (e.g., previous stage) are OK and no renegotiation is deemed necessary. I have no clue if somebody uses it but I felt at the time that the purists will object if I'd suggest restarting the login :-)

> Mallikarjun
>
>
>  
> ____________________________________________________________________________________
> Do you Yahoo!?
> Everyone is raving about the all-new Yahoo! Mail beta.
> http://new.mail.yahoo.com
>
> _______________________________________________
> 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

--=_alternative 0055595EC2257243_=-- --===============0592588287== 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 --===============0592588287==-- From ips-bounces@ietf.org Wed Dec 13 10:36:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuW9O-0000MZ-0q; Wed, 13 Dec 2006 10:36:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuW9N-0000MB-CV for ips@ietf.org; Wed, 13 Dec 2006 10:36:05 -0500 Received: from mtagate3.de.ibm.com ([195.212.29.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuW9D-0007Q0-VT for ips@ietf.org; Wed, 13 Dec 2006 10:36:05 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate3.de.ibm.com (8.13.8/8.13.8) with ESMTP id kBDFZlFM120826 for ; Wed, 13 Dec 2006 15:35:48 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id kBDFZlwI2625548 for ; Wed, 13 Dec 2006 16:35:47 +0100 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id kBDFZlAR000329 for ; Wed, 13 Dec 2006 16:35:47 +0100 Received: from d12mc102.megacenter.de.ibm.com (d12mc102.megacenter.de.ibm.com [9.149.167.114]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id kBDFZl9J000324; Wed, 13 Dec 2006 16:35:47 +0100 In-Reply-To: <004701c71e3f$68a0cc90$01faa8c0@ivivity.com> To: "Eddy Quicksall" MIME-Version: 1.0 Subject: Re: [Ips] Implementer's Guide - Task Management Issue X-Mailer: Lotus Notes Release 7.0.2 September 26, 2006 From: Julian Satran Message-ID: Date: Wed, 13 Dec 2006 17:35:44 +0200 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 7.0.2HF71 | November 3, 2006) at 13/12/2006 17:35:46, Serialize complete at 13/12/2006 17:35:46 X-Spam-Score: 0.1 (/) X-Scan-Signature: 36ffee4f7c1a67a949d5f97400beba73 Cc: ips@ietf.org, Black_David@emc.com X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0819791430==" Errors-To: ips-bounces@ietf.org This is a multipart message in MIME format. --===============0819791430== Content-Type: multipart/alternative; boundary="=_alternative 0055AC3CC2257243_=" This is a multipart message in MIME format. --=_alternative 0055AC3CC2257243_= Content-Type: text/plain; charset="US-ASCII" If your target answers fast and expects data from other initiators it may have to track ITT-TTT. This is not on the fast path (data path) so I am not quite sure what is difficult. Julo "Eddy Quicksall" 13/12/06 00:46 To , Julian Satran/Haifa/IBM@IBMIL cc Subject Re: [Ips] Implementer's Guide - Task Management Issue I want to be sure of something here ... you are not requiring this ITT-TTT tracking are you? It would be very difficult for hardware. Eddy ----- Original Message ----- From: Julian Satran To: Black_David@emc.com Cc: ips@ietf.org Sent: Tuesday, December 12, 2006 3:12 PM Subject: RE: [Ips] Implementer's Guide - Task Management Issue David, The issue you are describing falls in the same category. Target can answer to B as soon as it has "purged" the tasks regardless of what A does. For safety the implementation should keep the pairs ITT-TTT and make sure it does not reuse the TTTs with the same ITT for a while or force closing offending sessions. There is no need to really delay the TM response - just act as if all outsanding activity died out and ignore data reaching the target. Julo Black_David@emc.com 12/12/06 20:26 To Julian Satran/Haifa/IBM@IBMIL cc Subject RE: [Ips] Implementer's Guide - Task Management Issue Julian, > As for the issue raised by Bill Studemund I am not sure that the target needs help in > recovering buffers (and I am not sure that I am not repeating what I said already in he past). The motivating concern is not buffer recovery - it's the ability of an uncooperative initiator to delay completion of a TMF issued by a different initiator. Here's an example: - Initiator A has one or more data transfers in progress to the target. - Initiator A dies in some inconvenient fashion. The target thinks the iSCSI session with Initiator A is still alive, but Initiator A is non-responsive. - Initiator B issues a TMF that has the effect of aborting Initiator A's tasks (e.g., CLEAR TASK SET). The issue is: When can the target issue the TMF response to Initiator B? Current RFC 3720 language requires completion of Initiator A's data transfers or timing out and dropping Initiator A's session - Section 10.5.1: "The target on its part MUST wait for responses on all affected target transfer tags before acting on either of these two task management requests". In this example, the data transfers will not complete, requiring timing out and dropping the session before the TMF response can be issued. The request is that it be permissible for the target to redirect Initiator A's data transfers to bit-buckets (just in case Initiator A is not actually completely dead) and issue the TMF response once that redirection (as well as everything that RFC 3720 requires with respect to Initiator B) is done so that the TMF response doesn't have to wait for the target to time out and tear down the session with Initiator A. 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 ---------------------------------------------------- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Tuesday, December 12, 2006 8:03 AM To: Black, David Cc: cb_mallikarjun@yahoo.com; ips@ietf.org Subject: RE: [Ips] Implementer's Guide - Task Management Issue David and Mallikarjun, I had a long discussion with Mallikarjun on a part of this problem - namely cleaning the T-2-I path. This could be done in several ways and Mallikarjun and I where also playing with sending the closing TM response on all connections as a way to speed up pipe cleaning. As for the issue raised by Bill Studemund I am not sure that the target needs help in recovering buffers (and I am not sure that I am not repeating what I said already in he past). As TTT is a target conceived artifact - buffers can be retired and the target can refrain from reusing the TTT with the given ITTs for some time (the rules must be quite simple). If data arrives with the bad combination - it is just discarded at the target. This ways TMF can be sent early - regardless of oustanding data - provided that the target respects some simple rules for TTT use/reuse. Considering also that TTTs are also not mandated to be unique beyond a single LUN - buffer retirement while an issue can be solved within 3270. Regards, Julo Black_David@emc.com 11/12/06 20:56 To , cc Subject RE: [Ips] Implementer's Guide - Task Management Issue Mallikarjun, [NB: Working group chair hat is **off**.] > "I assume this is essentially what you are proposing that we > consider (fast multi-task abort with outstanding TTTs always, > even without the key negotiation)." Not exactly - comments interspersed below, but what I'm proposing is that in the absence of negotiation of the new key, the portion of "fast multi-task abort" that allows the TMF response to be returned in the face of outstanding TTTs be allowed *only* for transfers from initiators *other* than the one that sent the TMF. I believe that Bill Studemund raised this concern earlier, but I admit to missing its significance at the time. In other words when the key is not negotiated, a TMF that aborts tasks from multiple initiators behaves differently at the target with respect to the initiators involved: a) There can be no change to currently specified behavior with respect to the sender of the TMF. All TTT transfers have to complete, and the TMF response cannot be sent until the transfers are complete, otherwise a 3720-compliant initiator may see something that it doesn't expect. b) Transfers from other initiators may be bit-bucketed early at the target - this would be new behavior, and new language would be needed to allow the TMF response to be sent once these transfers from other initiators are redirected to bit-buckets. This does not affect a 3720-compliant initiator, as these other initiators do not receive a response to this TMF. The only change is the latter, and it has the effect of removing a cross-initiator dependence for completion of the TMF. The use case is that there is still cluster software out there using TMFs to maintain cluster membership instead of persistent reservations, even though the latter is what should be used. > Sorry for the delay in getting back. Between vacation and > other travel, it took me a while. Thanks for the comments. > > You wrote this regarding fast multi-task abort: > >This property is > >useful even if the new key is not negotiated (and hence the > >AsyncEvent 5 message is not used for fast abort of data transfers) > > I assume this is essentially what you are proposing that we > consider (fast multi-task abort with outstanding TTTs always, > even without the key negotiation). Not exactly, see above. > The reason we decided a new key is needed here was for two reasons: > 1. Whenever TMF does a fast completion, target needs an > (eventual) deterministic confirmation that data transfers had > stopped. The confirmation is Nop-Out, and the negotiation > for the new Nop-Out is via the FastMultiTaskAbort key. > 2. The initiator requirement in the "classic" case (i.e. key > not negotiated) is that it respond to each TTT for affected > tasks even while the task is "affected". We wanted an > opposite behavior, but with a confirmation that the data > transfers had stopped (so target can recover the buffer > resources). The key allows this new behavior on initiator's > part as well. I agree that the new key is clearly required in order to terminate any TTT data transfer from any initiator early for the above reasons. The proposal is that the TMF response be allowed to be sent in the face of outstanding transfers from initiators *other* than the one that sent the TMF. This does not appear to require a new key be negotiated with the *other* initiators, as (in the absence of a failure) they will complete those transfers normally. > >This is approximately > >what is described in the Implementation Note at the end of > >Section 4.1.3, although that note may have been intended to > >be iSER-specific - if so, this is a proposal to apply it to > >iSCSI without the RDMA extensions. > > Actually the note is intended for all iSCSI implementations. > After seeing your observation, I decided that it needs > improvement, I propose the following new text: > > "Implementation note: Technically, the TMF servicing is > complete in Step.e. Data transfers corresponding to > terminated tasks may however still be in progress even at the > end of Step.f. TMF Response MUST NOT be sent by the target > iSCSI layer before the end of Step.e, and may be sent at the > end of Step.e despite these outstanding Data transfers until > Step.g. Nit: "may be sent" --> "MAY be sent" > These data transfers, if any, MUST be silently > discarded by the target iSCSI layer. In the case of > iSCSI/iSER, these transfers would be into tagged buffers with > STags not owned by any active tasks. I suggest adding: "; other implementations would deploy analogous resources to support this discarding". > Step.g specifies an > event to free up the resources. A target may, on an > implementation-defined internal timeout, also choose to drop > the connections on which it did not receive the expected > Nop-Out acknowledgements so as to reclaim the associated > buffer, STag and TTT resources as appropriate." Nit: "A target may" --> "A target MAY" > Now that I read the text after a long time, I spotted an > unintended double negative in section 4.1.3, target behavior, > bullet d-ii. The text should read: > "ii) each connection except the issuing connection of the > issuing session that has at least one allegiant affected > task." (i.e. drop "non" from "non-issuing") Ok. > The other thing that came to my mind after reading your note > is that we don't currently have a generic key to capture the > Response Fence behavior - although response fencing underlies > both the fast multi-task abort as well as addressing ACA race > conditions (and perhaps others down the road. e.g. around > persistent reservations). So, today, the Note at the end of > section 3.3.3 advises that implementations may check the > FastMultiTaskAbort key to verify if safe behavior for MCS ACA > is supported, although ACA has really nothing to do with > multi-task aborting. I am wondering if we should create a > new key (say ResponseFence), so the semantics would become: > > ResponseFence "Yes" fencing done by target > "No" legacy, no fencing > (so "clarified" TMF semantics are not possible either) > > With ResponseFence= "Yes" > FastMultiTaskAbort > "Yes" fast abort & fencing > "No" traditional wait on > outstanding TTTs (fencing on ACA is still possible) > > With ResponseFence= "No" > FastMultiTaskAbort > "Yes" Illegal, Response Fence must be "Yes" > "No" No fencing, must wait on > outstanding TTTs > > > The downside of this scheme is that it may be going in the > opposite direction than you wanted (introduces a second key > that 3720-compliant implementations don't know about). We > could alternatively simply mandate the behavior equivalent to > ResponseFence = "Yes" always and avoid the second key, but > doing so could make the current 3720-compliant > implementations technically non-iSCSI-compliant. > > Comments? Given the inter-dependence of ResponseFence and FastMultiTaskAbort, a single 3-valued key is probably simpler than two boolean keys. I think having an explicit means of determining whether ACA behaves correctly on an multi-connection-session is worth adding. Thanks, --David > Mallikarjun > > ----- Original Message ---- > From: "Black_David@emc.com" > To: ips@ietf.org > Cc: Black_David@emc.com > Sent: Wednesday, November 22, 2006 2:00:25 PM > Subject: [Ips] Implementer's Guide - Task Management Issue > > > To make sure we actually have some content to talk about in > this WG Last Call, I'm going to reraise an issue that came > up earlier on the mailing list, but (as far as I can recall) > never got resolved. This is done with my WG chair hat OFF, > and it is a proposal for further discussion. > > Section 4.1.3 changes task management, and is a non-transparent > change - it requires negotiating a new key so that both sides > agree that they support the change as it uses a round-trip > exchange of a new message (AsyncEvent 5) between initiator and > target to abort in-progress data transfers rather than completing > them. Absent this message, the target expects the initiator(s) > to complete all in-progress transfers, and is entitled to be > unhappy or worse if that doesn't happen. > > For task management functions that affect tasks from more than > one initiator (CLEAR TASK SET, TARGET WARM RESET, TARGET COLD > RESET) Section 4.1.3 also allows the task management function > (TMF) to complete while the in-progress data transfers are still > being dealt with, which has the useful effect of avoiding a > situation in which an uncooperative initiator can stall the > progress of a TMF sent by another initiator. This property is > useful even if the new key is not negotiated (and hence the > AsyncEvent 5 message is not used for fast abort of data transfers) > although I think the target behavior is subtly different between > the initiator that sent the TMF and other initiators in this case: > - For the TMF sender, the target must wait for all outstanding > transfers to complete before completing the TMF, otherwise > the TMF completion comes back too early for an unmodified > initiator. > - For the other initiators, the data transfers can be immediately > redirected to bit buckets so the TMF can be completed without > waits beyond that for the TMF sender. This is approximately > what is described in the Implementation Note at the end of > Section 4.1.3, although that note may have been intended to > be iSER-specific - if so, this is a proposal to apply it to > iSCSI without the RDMA extensions. > > High Availability clustering environments in which TMFs are being > used to determine cluster membership (yes, there's code out there > that does this, even though everyone should be using PERSISTENT > RESERVE) are a specific situation where this helps, as having to > wait for a dead initiator to expire (the TCP connection(s) have > to timeout and get torn down) slows down cluster recovery from a > failure. This change in target behavior (to complete a TMF faster > if other initiators don't cooperate) should be transparent to > RFC 3720-compliant initiators, but RFC 3720 has to be modified > in order to allow it; the Implementer's Guide is a vehicle that > can make that modification. > > This is proposed for further discussion. > > 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 _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --=_alternative 0055AC3CC2257243_= Content-Type: text/html; charset="US-ASCII"
If your target  answers fast and expects data from other initiators it may have to track ITT-TTT. This is not on the fast path (data path) so I am not quite sure what is difficult.

Julo


"Eddy Quicksall" <Quicksall_iSCSI@Bellsouth.net>

13/12/06 00:46

To
<Black_David@emc.com>, Julian Satran/Haifa/IBM@IBMIL
cc
<ips@ietf.org>
Subject
Re: [Ips] Implementer's Guide - Task Management Issue





I want to be sure of something here ... you are not requiring this ITT-TTT tracking are you? It would be very difficult for hardware.
 
Eddy
----- Original Message -----
From: Julian Satran
To: Black_David@emc.com
Cc: ips@ietf.org
Sent: Tuesday, December 12, 2006 3:12 PM
Subject: RE: [Ips] Implementer's Guide - Task Management Issue


David,

The issue you are describing falls in the same category.
Target can answer to B as soon as it has "purged" the tasks regardless of what A does.
For safety the implementation should keep the pairs ITT-TTT and make sure it does not reuse
the TTTs with the same ITT for a while or force closing offending sessions.
There is no need to really delay the TM response - just act as if all outsanding activity died out and ignore data reaching the target.

Julo

Black_David@emc.com

12/12/06 20:26


To
Julian Satran/Haifa/IBM@IBMIL
cc
<ips@ietf.org>
Subject
RE: [Ips] Implementer's Guide - Task Management Issue







Julian,
 
> As for the issue raised by Bill Studemund I am not sure that the target needs help in
> recovering buffers (and I am not sure that I am not repeating what I said already in he past).
 
The motivating concern is not buffer recovery - it's the ability of an uncooperative initiator
to delay completion of a TMF issued by a different initiator.  Here's an example:
 
- Initiator A has one or more data transfers in progress to the target.
- Initiator A dies in some inconvenient fashion.  The target thinks the iSCSI
  session with Initiator A is still alive, but Initiator A is non-responsive.
- Initiator B issues a TMF that has the effect of aborting Initiator A's tasks
   (e.g., CLEAR TASK SET).
 
The issue is: When can the target issue the TMF response to Initiator B?
 
Current RFC 3720 language requires completion of Initiator A's data transfers or timing
out and dropping Initiator A's session - Section 10.5.1: "The target on its part MUST
wait for responses on all affected target transfer tags before acting on either of these
two task management requests".  In this example, the data transfers will not
complete, requiring timing out and dropping the session before the TMF response
can be issued.
 
The request is that it be permissible for the target to redirect Initiator A's data transfers
to bit-buckets (just in case Initiator A is not actually completely dead) and issue the TMF
response once that redirection (as well as everything that RFC 3720 requires with
respect to Initiator B) is done so that the TMF response doesn't have to wait for the
target to time out and tear down the session with Initiator A.
 
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
----------------------------------------------------

From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Tuesday, December 12, 2006 8:03 AM
To: Black, David
Cc: cb_mallikarjun@yahoo.com; ips@ietf.org
Subject: RE: [Ips] Implementer's Guide - Task Management Issue


David and Mallikarjun,

I had a long discussion with Mallikarjun on a part of this problem - namely cleaning the T-2-I path.
This could be done in several ways and Mallikarjun and I where also playing with sending the closing TM response on all connections as a way to speed up pipe cleaning.

As for the issue raised by Bill Studemund I am not sure that the target needs help in recovering buffers (and I am not sure that I am not repeating what I said already in he past).
As TTT is a target conceived artifact - buffers can be retired and the target can refrain from reusing the TTT with the given ITTs for some time (the rules must be quite simple).
If data arrives with the bad combination - it is just discarded at the target.

This ways TMF can be sent early - regardless of oustanding data - provided that the target respects some simple rules for TTT use/reuse.
Considering also that TTTs are also not mandated to be unique beyond a single LUN - buffer retirement while an issue can be solved within 3270.

Regards,
Julo


Black_David@emc.com

11/12/06 20:56


To
<cb_mallikarjun@yahoo.com>, <ips@ietf.org>
cc
Subject
RE: [Ips] Implementer's Guide - Task Management Issue






Mallikarjun,

[NB: Working group chair hat is **off**.]

> "I assume this is essentially what you are proposing that we
> consider (fast multi-task abort with outstanding TTTs always,
> even without the key negotiation)."

Not exactly - comments interspersed below, but what I'm proposing
is that in the absence of negotiation of the new key, the portion
of "fast multi-task abort" that allows the TMF response to be
returned in the face of outstanding TTTs be allowed *only* for
transfers from initiators *other* than the one that sent the TMF.
I believe that Bill Studemund raised this concern earlier, but
I admit to missing its significance at the time.

In other words when the key is not negotiated, a TMF that aborts
tasks from multiple initiators behaves differently at the target
with respect to the initiators involved:
a) There can be no change to currently specified behavior with
              respect to the sender of the TMF.  All TTT transfers have
              to complete, and the TMF response cannot be sent until
              the transfers are complete, otherwise a 3720-compliant
              initiator may see something that it doesn't expect.
b) Transfers from other initiators may be bit-bucketed early at
              the target - this would be new behavior, and new language
              would be needed to allow the TMF response to be sent once
              these transfers from other initiators are redirected to
              bit-buckets.  This does not affect a 3720-compliant
              initiator, as these other initiators do not receive a
              response to this TMF.
The only change is the latter, and it has the effect of removing
a cross-initiator dependence for completion of the TMF.  The use
case is that there is still cluster software out there using TMFs
to maintain cluster membership instead of persistent reservations,
even though the latter is what should be used.

> Sorry for the delay in getting back.  Between vacation and
> other travel, it took me a while.  Thanks for the comments.
>
> You wrote this regarding fast multi-task abort:
> >This property is
> >useful even if the new key is not negotiated (and hence the
> >AsyncEvent 5 message is not used for fast abort of data transfers)
>
> I assume this is essentially what you are proposing that we
> consider (fast multi-task abort with outstanding TTTs always,
> even without the key negotiation).

Not exactly, see above.

> The reason we decided a new key is needed here was for two reasons:
> 1. Whenever TMF does a fast completion, target needs an
> (eventual) deterministic confirmation that data transfers had
> stopped.  The confirmation is Nop-Out, and the negotiation
> for the new Nop-Out is via the FastMultiTaskAbort key.
> 2. The initiator requirement in the "classic" case (i.e. key
> not negotiated) is that it respond to each TTT for affected
> tasks even while the task is "affected".  We wanted an
> opposite behavior, but with a confirmation that the data
> transfers had stopped (so target can recover the buffer
> resources).  The key allows this new behavior on initiator's
> part as well.

I agree that the new key is clearly required in order to
terminate any TTT data transfer from any initiator early
for the above reasons.

The proposal is that the TMF response be allowed to be sent
in the face of outstanding transfers from initiators *other*
than the one that sent the TMF.  This does not appear to
require a new key be negotiated with the *other* initiators,
as (in the absence of a failure) they will complete those
transfers normally.

> >This is approximately
> >what is described in the Implementation Note at the end of
> >Section 4.1.3, although that note may have been intended to
> >be iSER-specific - if so, this is a proposal to apply it to
> >iSCSI without the RDMA extensions.
>
> Actually the note is intended for all iSCSI implementations.  
> After seeing your observation, I decided that it needs
> improvement, I propose the following new text:
>
> "Implementation note: Technically, the TMF servicing is
> complete in Step.e.  Data transfers corresponding to
> terminated tasks may however still be in progress even at the
> end of Step.f.  TMF Response MUST NOT be sent by the target
> iSCSI layer before the end of Step.e, and may be sent at the
> end of Step.e despite these outstanding Data transfers until
> Step.g.

Nit: "may be sent" --> "MAY be sent"

> These data transfers, if any, MUST be silently
> discarded by the target iSCSI layer.  In the case of
> iSCSI/iSER, these transfers would be into tagged buffers with
> STags not owned by any active tasks.

I suggest adding: "; other implementations would deploy
analogous resources to support this discarding".

> Step.g specifies an
> event to free up the resources.  A target may, on an
> implementation-defined internal timeout, also choose to drop
> the connections on which it did not receive the expected
> Nop-Out acknowledgements so as to reclaim the associated
> buffer, STag and TTT resources as appropriate."

Nit: "A target may" --> "A target MAY"

> Now that I read the text after a long time, I spotted an
> unintended double negative in section 4.1.3, target behavior,
> bullet d-ii.  The text should read:
> "ii) each connection except the issuing connection of the
> issuing session that has at least one allegiant affected
> task."    (i.e. drop "non" from "non-issuing")

Ok.

> The other thing that came to my mind after reading your note
> is that we don't currently have a generic key to capture the
> Response Fence behavior - although response fencing underlies
> both the fast multi-task abort as well as addressing ACA race
> conditions (and perhaps others down the road. e.g. around
> persistent reservations).  So, today, the Note at the end of
> section 3.3.3 advises that implementations may check the
> FastMultiTaskAbort key to verify if safe behavior for MCS ACA
> is supported, although ACA has really nothing to do with
> multi-task aborting.  I am wondering if we should create a
> new key (say ResponseFence), so the semantics would become:
>                                                                      
>        ResponseFence    "Yes"  fencing done by target      
>                                    "No"   legacy, no fencing
> (so "clarified" TMF semantics are not possible either)
>        
> With ResponseFence=    "Yes"
> FastMultiTaskAbort    
>       "Yes"                   fast abort & fencing              
>        "No"                    traditional wait on
> outstanding TTTs (fencing on ACA is still possible)
>
> With ResponseFence=    "No"
> FastMultiTaskAbort    
>       "Yes"                   Illegal, Response Fence must be "Yes"
>        "No"                    No fencing, must wait on
> outstanding TTTs
>  
>
> The downside of this scheme is that it may be going in the
> opposite direction than you wanted (introduces a second key
> that 3720-compliant implementations don't know about).  We
> could alternatively simply mandate the behavior equivalent to
> ResponseFence = "Yes" always and avoid the second key, but
> doing so could make the current 3720-compliant
> implementations technically non-iSCSI-compliant.
>
> Comments?

Given the inter-dependence of ResponseFence and FastMultiTaskAbort,
a single 3-valued key is probably simpler than two boolean keys.
I think having an explicit means of determining whether ACA behaves
correctly on an multi-connection-session is worth adding.

Thanks,
--David

> Mallikarjun                            
>
> ----- Original Message ----
> From: "Black_David@emc.com" <Black_David@emc.com>
> To: ips@ietf.org
> Cc: Black_David@emc.com
> Sent: Wednesday, November 22, 2006 2:00:25 PM
> Subject: [Ips] Implementer's Guide - Task Management Issue
>
>
> To make sure we actually have some content to talk about in
> this WG Last Call, I'm going to reraise an issue that came
> up earlier on the mailing list, but (as far as I can recall)
> never got resolved.  This is done with my WG chair hat OFF,
> and it is a proposal for further discussion.
>
> Section 4.1.3 changes task management, and is a non-transparent
> change - it requires negotiating a new key so that both sides
> agree that they support the change as it uses a round-trip
> exchange of a new message (AsyncEvent 5) between initiator and
> target to abort in-progress data transfers rather than completing
> them.  Absent this message, the target expects the initiator(s)
> to complete all in-progress transfers, and is entitled to be
> unhappy or worse if that doesn't happen.
>
> For task management functions that affect tasks from more than
> one initiator (CLEAR TASK SET, TARGET WARM RESET, TARGET COLD
> RESET)  Section 4.1.3 also allows the task management function
> (TMF) to complete while the in-progress data transfers are still
> being dealt with, which has the useful effect of avoiding a
> situation in which an uncooperative initiator can stall the
> progress of a TMF sent by another initiator.  This property is
> useful even if the new key is not negotiated (and hence the
> AsyncEvent 5 message is not used for fast abort of data transfers)
> although I think the target behavior is subtly different between
> the initiator that sent the TMF and other initiators in this case:
> - For the TMF sender, the target must wait for all outstanding
>     transfers to complete before completing the TMF, otherwise
>     the TMF completion comes back too early for an unmodified
>     initiator.
> - For the other initiators, the data transfers can be immediately
>     redirected to bit buckets so the TMF can be completed without
>     waits beyond that for the TMF sender.  This is approximately
>     what is described in the Implementation Note at the end of
>     Section 4.1.3, although that note may have been intended to
>     be iSER-specific - if so, this is a proposal to apply it to
>     iSCSI without the RDMA extensions.
>
> High Availability clustering environments in which TMFs are being
> used to determine cluster membership (yes, there's code out there
> that does this, even though everyone should be using PERSISTENT
> RESERVE) are a specific situation where this helps, as having to
> wait for a dead initiator to expire (the TCP connection(s) have
> to timeout and get torn down) slows down cluster recovery from a
> failure.  This change in target behavior (to complete a TMF faster
> if other initiators don't cooperate) should be transparent to
> RFC 3720-compliant initiators, but RFC 3720 has to be modified
> in order to allow it; the Implementer's Guide is a vehicle that
> can make that modification.
>
> This is proposed for further discussion.
>
> 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

_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips

--=_alternative 0055AC3CC2257243_=-- --===============0819791430== 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 --===============0819791430==-- From Holidays@art4brains.com Wed Dec 13 23:15:56 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gui0i-0006Mi-6y for ips-archive@lists.ietf.org; Wed, 13 Dec 2006 23:15:56 -0500 Received: from ppp-124.120.216.133.revip2.asianet.co.th ([124.120.216.133] helo=proxy.asianet.co.th) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gui0a-0005Ih-Mq for ips-archive@lists.ietf.org; Wed, 13 Dec 2006 23:15:56 -0500 Received: from [124.176.2.37] (port=7228 helo= by with psmtp id ZgjxKT-79aaEb-00 for ; Thu, 14 Dec 2006 11:16:11 +0700 Message-ID: <000e01c71f36$87e0f330$00000000@masterv1swbat3> From: "glorious" To: ips-archive@lists.ietf.org Subject: baskets Date: Thu, 14 Dec 2006 11:15:47 +0700 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000A_01C71F71.343FCB30" 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: 4.0 (++++) X-Scan-Signature: f884eb1d4ec5a230688d7edc526ea665 ------=_NextPart_000_000A_01C71F71.343FCB30 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000B_01C71F71.343FCB30" ------=_NextPart_001_000B_01C71F71.343FCB30 Content-Type: text/plain; charset="windows-874" Content-Transfer-Encoding: quoted-printable Annexgreat, calendars for lsquo ndash shop gamespc video? Save on nice = including rachael ray emeril lagasses guides. Four ultimate james bond. Rachael ray emeril lagasses. Noblecom books, used out of, print = textbooks childrens dvds. James bond order them store along with jack = bauers. That are just right loved ones. Idols years best theyre = storesave sony. All by city or statefind an instore. Titles that are just right! Duets, grammys boxes josh groban tony bennett, bubl. Weekly game, office = food winediet member great new. Baskets children, ages gamesbig, deals = dvd? Statuseasy returnsall help, desk, topics. Dvds, music toys items browse booksnew soonbampn the. Amp, noblecom books used out of print textbooks? Espaolmeet study = guidesgift cardshome, officedvd box setsmusic. Event near, you, hourly = top bampn weekly game office? Best theyre storesave sony bmg. Great new, en espaolmeet. Boxes, josh groban, tony, bennett bubl. = Returnsall help desk topics back terms use copyright. Cooks gifts rules demo dino see other fun games. Deals, dvd action aplenty in four. ------=_NextPart_001_000B_01C71F71.343FCB30 Content-Type: text/html; charset="windows-874" Content-Transfer-Encoding: quoted-printable

3D"heroes"
Annexgreat, calendars for lsquo ndash = shop gamespc=20 video? Save on nice including rachael ray emeril lagasses guides. Four = ultimate=20 james bond.
Rachael ray emeril lagasses. Noblecom = books, used=20 out of, print textbooks childrens dvds. James bond order them store = along with=20 jack bauers. That are just right loved ones. Idols years best theyre = storesave sony.
All by city or statefind an = instore.
Titles that are just = right!
Duets, grammys boxes josh groban tony = bennett,=20 bubl. Weekly game, office food winediet member great new. Baskets = children, ages=20 gamesbig, deals dvd? Statuseasy returnsall help, desk, = topics.
Dvds, music toys items browse booksnew = soonbampn the.
Amp, noblecom books used out of print = textbooks?=20 Espaolmeet study guidesgift cardshome, officedvd box setsmusic. Event = near, you,=20 hourly top bampn weekly game office? Best theyre storesave sony = bmg.
Great new, en espaolmeet. Boxes, josh = groban, tony,=20 bennett bubl. Returnsall help desk topics back terms use = copyright.
Cooks gifts rules demo dino see other = fun games.
Deals, dvd action aplenty in=20 four.
------=_NextPart_001_000B_01C71F71.343FCB30-- ------=_NextPart_000_000A_01C71F71.343FCB30 Content-Type: image/gif; name="heroes.gif" Content-Transfer-Encoding: base64 Content-ID: <000901c71f36$87e0f330$00000000@masterv1swbat3> R0lGODlhaAKUAYewAAAABnEAAAB1Bot5BgAMcXEOewB7ibm9vMXTyKLH5TEdAGQuCIcYDpYXDMIg AOsUCwZDCSU2AEhJCmo3CnRHAJdEALVMBNozBgFVBCprAE5rAFdsAI1pAJ9mDMBuDOVkAAmIDSZx Aj54AGyJBnp0AKt3AMR3AN14CwGXABGnDDeaAGiXAHqgDaybDbeYAO2lBgCzAC2zAEGyB224AHvD CKq9AMq3A9i6AADbACjhAEvWC2XoC3LrAJ7TAcHUBe3kAAAAMhIAOzQLR2ANS4MAQ5IAOcsAQeIJ MgApPyghNkEcTG0RTIsTS6IbNcQYSd4uTgE2NBhDRjo2N200QYtFQplBRLZEQNkyMQRZNSxZNEJk NV1USYtWAKZqO7NoQutYQACBMih/OUmBQVqGTneKOqR4S8iOPtuOSgCqRy2hOD2bMmWZQXuSPq2X TLipSN2hQQ26NCHMODG9MmCzSIi8PZPGTsfNONTNPADWORHWRTHqOFnXM3/fQKHuSsTWNu3rTgkA eyMKhDoAiF0Ae4MDiJIJdLwKhtQGiwAihxkohUwXh2MXjHsZfJ8be7gme9gegAAzcSlLjkNBf2o4 fYA8ja1BjMFKe9pLiwBtfRxjhElkfVZlg4JbdZJucsVTfO1oeAB2iBl0gz6FeGOFhYVyeKiFebSE c9N1fgCtdxKefEaWcV6cgnqigpypjsaWiOWcdgSzdC6zhTu0fWXFd4bGfKfHgbLOdtjHjQfSjiXZ izrTjFPkeonWepLrg7/meNLnjAAAwRsAtjcGulYAtn0Av6QHxcsAsdgCwA4fxywUwzcizG0puH4h taAUzscqwegosgAxsSpNsUA9tl04unxGxKQxss5NytNFxQxguBNRwD1bs1NgsX5ava1Wx7lltuVW ygCGtx1xtEeNylGKwHWOsaOOx8t9x999ygyYyy6izjySv22rvYahuJ+Ytraru+ujyQDEyBjFvkO6 xG7Hu4a0uayzwf/z6KqssYaNffYAAAT/APjyAAMH//8L+ADz///19CH5BACT9WkALAAAAABoApQB Bwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKrGivpMmTKFOqXMmypcuX MGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWrWLNq3cq1q9evNUeK HUu2rNmzaNOqXcu2rduRYOPKnUu3rt27ePPq3cu3r9+/gL2+HUy4sOHDiBMrXszYYuDHkCNLnky5 suXLmDNr3ky1sefPoEOLHk26tOnTqFOrXs26tevXsGPLnk27tu3buHPr3s3bLeffwIMLH068uPHj yJPH7c28ufPn0KNLn069uvXr2LNr3869u/fv4MM7/1dOvrz585bFq1/Pvv1H9PDjy59Pv779+/jz 69/Pv7///wAGKCBw7hVo4IEIGjTgggw26CCAAUT44IQUOrVRhBhG2BCGCWXo4T8eaihQhgWROFCI CIXIIYgiQrTiQSqqmGKLGb2Y4I04EvaijTMG0CGNJ4q4oolBtjgkkCMimaSPEfHYI0FOLslRlDlW aeVYPCpZopYsMrmllxx+uKSQNCpJZUVnQlkmlx6leeWbcGLkpphdElkkjEZqSOeHbt6Jp48o1kkm nX+qGWiXgtooo0GLEiqjnXvyGemOg0oZ56We7YRhS5tuWpKnKoF6EqidemhPiKdKCJOoo0qYoUme xv+qqkuivppqAJ+6Kiuut+bKa0q16vrrq8SqWiqvtt76a6+7+upshdBqJSeXlDJ5ZoyA5plttiwi 2ueYYoa5ppeGbjiun+KCqae2T1qK6LtHbnunoudaWmm3mOY7W7XrqmsttWbem26/7zJEZbqG0kvu j+RWK6XDDhfqbrz2EvxwvRMPGqO+HCOm6azOYvtsqCDDiuqzzbLKksohl6ziyJyCTKqxwpqM68zL tjrsrM32yizPNduss9DK3pxstEhXNe3CCEvsdLmMCmyxwVo2HfW9CymM7tRWH8xuxf+GXbDVBY+t 8bZsdqz2WTwFa3TORJMMt88osdxzrnKvdOzKNM//DazMQCMb9M87+40z0T3v3fKybsddbMlJRw6V RhFT6u7VT/v55ZiXa7651vCmfXnlXFdqJ9QX+wt26qMDSXbEnq8tO2iLgtvw6WXH3nnruO/OesLj sgl66PJmTOiXZ0NNMbieO3k87L7PLv30sH1L/fXYZ4+v9dp37z3Hh34v/vjkl28+c5Knr/767Lfv /vtfnS///HDCb//9+DMlwP75o7S/ADT5X/8GKBmM/O+ACNwfQv4XEQROJIECaAgDNQLBA0Kkggqk yAQfskGFdJB+IGxNBz84EBIyxIQnzOA/UEgQFlrEhR5UYUZgaBAarlCGIcxhakaIQwP2MIURbGEQ /9Viw4MU0SFHFIgNk6jDJiaGhwksYQajmJANUrGGPxQiFG94RS5aMIZDlCILUThBBkJQi2LE4RmV +EUxOvGNpYFiEMuoQDqGsSB2ZOMd9QhGLrrxi3n0Yx/RSMYsenGKZlRhHq2IyDnWUYZMhKMkJ/IT AZrEkvawpAAx6RJN8q+Tn1QJJj0JwFHyz5QAbAknUSlKDJYkga8MJSkzKctT1rKUt7xkKAnIS8Fs ZIt89GMXjdjIMSrSgox0ZASTKchmLhCSx9yjM7EYTTcKs5rMZGYwJ8lNj1Ryl6ykZSohyBJUHrCV qdQlLtM5S1aGs5zgzGVKODnPd7Yzl+6soDp7yf/PrnAEmIL8YBupSU1pCvSRQ1wkNqs5yG2a0IVt 1GYiE4rQPxoykt3MqEK+mU5x7tOj/ttlSDv60Xp2dJPyRCk7bblSkpr0JO+EqUhlek6QglSl+8yn S/vJ0/j9EpoUVWZAL9rIbRI0mBO1aFD5OFBi3jGpTq2iA4e61GsuFZDHtKZGt+oYn6wypZ+E5UoQ GMuawpOs6oznOktKTlXOFK3oJOc94WpTuorTrGIta0/3yteY0JMqf+2rYAerv3HOFLCHJaxiA5Og YRIGo1yNrG8WS9nKCkeymM2sZjfL2StZ9rOgDa1oR9vXkXzgtBo57QfaolrUdva112uta1WbWtf/ foS2CcHtRXQrEN7KdrUD+a1sDdJagtBWuMe1rW6XO9zg2vYfvn0ubCXZE9WWxLrW5Ul2hbJdlXQX J9/dbna/e93TtkS2JsGueb27XnuId73jbW9359te0pI2I9GFrnQrwtuO9Lcg/51If3EbXeAad78H Zu5qA9zb2ToYuPltsIH1O2EGT/fCDEZugqXb3OQiWMLKDfGCf0vcDhcXxAgeMGr/q+IJl/jEHs7t iotL4A9TOME4vrCOAfxhGD/4xhJu8I0tHGMgA9nCRi7yiQ/SYiM718VITm6QiTxj/R7ZxgXO8Y7f uBPylvcD6TXve8FM3t+yZMzulS9865uS+IL5/8tpfvNKkKteOYfZznE+r5j3TGY6w3nPef4ymwMN 5zvb99BdHnSh84zmMrdWz3Kus6EJzd43N1rRkza0o/Hs5UnzmdJtfjR6UTLqRVO604imLEYyLGIK k5jFS2ZyqxUcZBlDeNY2dvKQ99tkW6N4xC7msYex3Oona3nLTUw0njMt6VAv28xzVnOfI73mZZ/E zZrGtKkZPejwapvQ6EV1nPmsbTRnGtSpTndM6AvuTzvb2Y+udLapbelvY/vP9mbzvbeN7mtL293R /neY/W1tdRv8J/FudqDfW+hPx/vd9054vum98ImTWtr87ve5Rf3tdtt536eur7gPTvI773vM9P+N eKdLPe6Hs3zjLrc4wQm+cpkLuuUsN7fJ9S3ynhe85HxFttCHzhGgG/3oSE+60pfO9KY7/elQJxDR p071qlv96kWPuta3PpJ8eF0kXs8H1sc+vrCb/exfD0nYJ7L2hLQ9ImgniNnlnvZ/vN3udSe73kVz 97t7xO8OATzdxQ73tL/97AM5fN4Fv/fGK6bvef975AM/eYxAnvCIF4jiCa/5yjv+84a5fOY7z/jE j37zdY872jk/eNIzHvBrjzveOX950Ns+6z0J+0nMXhLd20P3vleJ103i++IP3/jDJ37yVwL85Ad/ 98tXfj5+f/zpU9/614c+9rfOfaRwpPakn73/6VnvdsN/ffPib335xV768Rsk9uePP+0X7/nb218t 4Bc/+hGy+vCj3+/tB39zx3+TJ4Cdl34ImID3t4AQ8RPPF3zNt3rM53wUOH2rV33bl30sgXy8lxLP 13sYCIIdqIEi2H0mOBcPuHwRCBMQWIEkqH0o8YExGH3Xl4ElOIMWqIIjmII2eII+mBU8KH0vuIE6 aH0r6IE0KIMwiIMTuH3IJ300+INSeBTfR3/zh3mpR37hN3tY2IWmp4ABKH9beBBtt3+u535oyIBq iBb5h3r1d4FjKHuwN4AFUYajR4B0mIB0mH9r2IcJMYWAqG5+OIhwFIiGeGiEmIiKuIiMWB2H//iI kBiJktggjViJlniJmJiJmriJnNiJnviJoBiKojiKpFiKYzGJqDhYpriKrNiKrviKsBgdqTiLexWL tniLuJiLuriLb0GLvshPvBiM6POLxFiMxniMfyGMyqgbyNiMzviM0HgVyziN1FiNORSN2Fgh1riN 3NiN2ZON4BiO4jiO5FiOSOON6Gga5riO7EgXm7AJXPGO7XgeGPGO9viO/4CPB6GPAnGP+XiPm4AQ ABmQ/wiQBWmQA1kQBtmPBDkQAxmQ/PiPBUkQ9iiQ/uiQF3mQ/JiQCYGPD6mRBFmRGNmQC6mQC7mR IdmQ6XgdEcmQFmmSLhmTMOmSLUmRKomSGP+ZkxJpkwYRkR7pkzW5kzuJk0Kpj0TZkymJlDkpkgyZ lDKpkxJplDepkitJHTUZlBk5lCRJlTL5kx05lTrZkl7JkzNJkyKZlU8JlWYZllv5kkIJlT8plWOp EDg5l2lZldJxlVx5kGR5lGQZlXv5lEQplhBJlXrJkxeJlm+ploDJlozZlVxZl2dZkUFZlnG5l5WJ l83xkYdZlCmpmE05mSX5lhy5mHYJkoWJmIV5mouZlpeJkqDpmQh5kquZmpk5kqLplpqZl5HZm5C5 lrr5mGppl4Rpmr65lLXZmlhpmLYJlgvhl3d5mY35nL25nLvZGjshjyihnScxkCahneAJjyr/wZ3f KZ7jaZ72EJ7luZ3wSJ7piZ4lQZ7yqJ7vmRLuGZ/wOZ/iyZ33aZ/meZ8Aup8CWp8uEaAE2p3wOY/9 YaAI2qAEyp8JeqDruRLy+Z8WOqHu2Z/0uaERCqH4iaEXKqEUGqIO6qAcCqIfyp4pOqEKehz1WJ2U CZb+CJRKaZKjSaNwmZEJ+ZGh+ZiVeaM6KqOBOZOd+Zc5ypRSWaOeeZ3beJuE4aRMGhrZ+ZBUWqVW eqVYmqVauqVc2qVe+qVgGqZieo8tWqZN0Z9VgaZmGhxR2qZu+qbNsaZy6qLSww/8AKd6BwB6qqcC wacDwad7uqd/GqgAMKiE+g+C2qeFSqiJ/3oQjKqogWqohQqpfsqok8oQdloQdrqpCLGpmSoQnnqn neqpoBqqd2qqn0oQpIqqoqqqqfqpoVqqA/GqopqqeCobfoqoi3qputqrivqrwJqrhjqoBCGsCJGr gHqpyKqszOqrEGGq/0CrBiGt0jqtrZqptqqprXoQ2Zqtrnqtpwqu0Squsjqutzobxgqsv7qs6lqp vEqp6uqsCcGu7Bqs7xqvxXqv42qr1ZoQ2Eqursqt26qtCtGtA/uttRqus6qw+5qw5XqusJGu8pqs xOqs7moQkTqx+loQ9Nqs9uqoGyuxpLqwJFuwDGuuBGut/nqwAduyAgurJ/uvpQqzDwuxrv8hscKa rBmrqztrqb1KsRWrEI/Ks43qqzg7tAvBqSWLstZKszX7tDM7slDrslMrqzJbrf8qs1Vrs6hxtPn6 s7wKtPhqtEUrsRx7r2L7sRi7sUmrtP06qkzrrTCrtQJrsilbtw0btwk7twDLtazhtcR6sWorr/aa s2wbtBVruGNLuA5xtX1bt29bs3Srsit7t5S7quQ6slLrt7FRr4LruR6brssatoc7tvVqsc1qtmZr rnTrtNT6uA87uZZLuUtLu5yKtW6rtEzLub3IE4R6EoFqEnoKvABgD8MrvMVrqcZbvCWxp8T7Esf7 vMi7vNH7u9QbvM3LvChhqiYRqt3LD9//u6nha6cswb2oehLkuxKeir7gq77taw/iC7/r+73sW79z ehnT4628+4qWWrpnob/7G8ACPMAETHT3e8BsWsAKvFEI3MCascAQfBAOPMH4G8EWfMEYnMEavMEc 3MG3SsEgPBkePMIk3KYhfMIonMIqvMKpWMIu/MIwfGGrG8On0b9fK6nGeqhEK6g2fLYZi7Q9+8NI K6k8i7hne6weC7aH6rOnK7Q7m686rMOLS8OrAbjtmsRpe8RIHLhY3MWMu7aQasTwCrJBm8WMK7gL 0cRkDLpPTMWqIbqNCrpkvMV0DLZlPKlWPK94nKirq7p7fLFwDMY5rK9qrMVH3MZu3BY+/xG9yFu9 2nu8jDy9KxHJ0ru8lpy9kkzJl9wSkOy8m5wSmnzJ2Du8lFzKnlzJlRzKmAzKyXvKLGwcGzHIhRvH hDzEfRzFUky2IJvLiburXzzFSuzLO6yzkVq0DFHIRhzE/pvIZbHI2rvKnfzJnUzKz4wSqmzKnyzK 1bzKnMy807zNkqwSo+zJ2GzNruwSjswSoezIqvzKmxHL7zq0aKy4t6zHYKyxizvDaovIYkzERGu6 aCvMx5zEhnzPdszMb0y6X3u6HWvPdXzHEL2u/jvP9YzE7orGYozRVqzRCn3Fv4zQoqG4XHzDwzzM HT3HJB3MOEypxvzPo7vLLR2vo1vMj//K0CEbxBktxPwM0s3sjO3szu+8ifrM02IB1EYNFkTtpke9 1Ezd1PCR1Cbs1FI91VT9G1B91Vid1Vo9SVXd1V791Yy11VUJ1mRNFGI91mWd1mq91lhx1m791nAd 13I916DB1nZ913idFHS913z9Wnn914Ad2II92D7R14Z92Iid2IrN14Td2Paw2Lvo2JI92X8dEkON G5eN0u2hz5kN03Tc2YkB2ju2E4wazsLx0+oMzlQRzTKB2kGhyaxdEz8d23NB26Y9FLHt2j2VztkM HLrNyl/x2719FLDtzaoNvccNzcnNFbb9FMIdORghxzu80mM83QZ90cwa058rxFzc0vL/rNPbzdLi bd0lTd4+nLo0rd3pfbR8rMwzDcf9m93sjdO6fN7vvc9/fNPtzc/xzcb6Hd7WTcy+DMS8PN5SvMTY fd/ljdHNIceFDLRiG8gSPeEATeEHrcQWLdFeDOHofdOo++FaDODITNFr68WHTNC9vMcgHuKhq+I+ bOEcTuESjuFffNEfy+Agzt0s3t0wHtCGbOM8vKsuvtCAPOTOQeArPtIkPeNZPOLtreQXft0C/eH0 HeUnDuUz3ssefc8PftKB7OQeDeY5buRh3uLf7cRYXstbbsZLnt8VTuXondM/7uJFLuf+zRqkDc7U bL2lfb3Za72pbNzffM5/btzTm87X//zIrRzo1Eu8vxvJpY3ofW7OvD3oxc3N5Vzo5Pzoii7Oho7J ygvcm8zamb7n4zzp2GvOh97pol7pgq7nqM7q0ivpq37b2ezqyj3qr07NmUzoeBHdas7k8TzlKC3L Q63jF87mZd7m//zmy27hA43f0Z7kMu3jPT7HDZ3GQw7gzD7fiCzs1D64DJ7l/izh2Z7s1h7R4X3u Ee7m0eG12R7k187iwtzudRzvyg7n3V7vcZ7iZCvQ5k7n267m4S7SBy3vRczl/V7jAi/wUr7iJH7G Cw+4Dk7mY47jJI7v6b7mDq/xEB+2qJHnnq7pjbzp7LzOfH7KgC7qJK/piz7JKU/ppP++69zs8jZ/ vaqd6uyM86ndyr4O6Tqf8qku86y+8oE+zjWP6TTf646e80if9CVf9K8O85uu3FX/55bs6kMf9S2v zaAO6JEu64y83D41HaJtGmdPjWnvEGuf0pPU9qMB98Io92huEXT/PXe/GAW+knsPzxeR95Ad+ILf eJRd+IZ/+Ihv1IN/i4nf+I6v+Isfi48/+ZRf+ZZ/+ZgPdZG/+Zzf+Z6Pe5kf+qI/jp/PiqNP1aW/ iqc/1anf+q5vIKsv1a8/+7QPHrHv1LWf+7q/+299+77/+7TI+8I//L0B/MZ//OVoAMq//AbAE8z/ /M1vD9Cv/CjB/NW//CoB/dcf/cj/b1/Tj/058f3UL/3ibxLWfxLnb/7lXxLg3/33sxHMPxDxbxHL nxD1L//Kj//3/w/PXxDzDxD/DAz8V3CggYIJFS5k2NDhQ4gRJU6kWNHiRYwZNW7k2NHjR5AhRY4k WfKfPZQpVa5kufJgy4EtZcp8STOmypoHb9rTaQDnzpQ7a84kWtToUaRJlS5l2tTpU6hRpU6lWtXq VaxZtaIEedCkV4dgE4LtOVanQrFhCZpk29btW7hx5c6lW9fu3a5rJZadmHahX7JleyI0qPehX7yJ FS9m3NjxY8iRNyJmOJjyX8trAWsWjFDsZbSGJY8mXdr0adSpPU4dOnNoa5uZUbZ+/x3Tts/aPovC 3trb92/gwYUPJ17c+PGrH9MOFigadGHCDTNHb+757GfR0rOr5t7d+3fw4SEv70y9ekTQmTETDhz9 OXTx8eXPp1/fPkTKXjebr7wd/mHO2NPrvfPuM/BABBNUECOqeHsJNt5cAkpC3WKb7abcKrQQOQ47 9PBDEEMUcUQS8+JPP+f8M4u/FfHbjrwTWVxwRhprtPFGAA1rr0X0VHwuPx3P+g9HIos08kj5pguQ uR5lLFAtFvezjEckq7TySiwpusoylnpCKsILNexywjBh8vInMUlUc00223TzTTjjlHNOOuu08048 8xwxSz779PNPQBvSc1BCCzX0UP9EE3UqUEYbdfRRSCOVdFJKK+VIUUwz1XRTTjstzlJQQxV1VJA8 NfVUVFNVtVNSW3X1VVhjlXVWWhtd9VZcc9V11w9r9fVXYIMVdlhiizX2WGSTVXZZZpsNlVdoo5V2 WmqrtfZabLPVdltuu/X2Ww6dFXdccss191x0RQJ3XXbbdfddeOOVd17g0rX3Xnzz1XffWOn191+A AxZ4YIIL1pNfhBOW1WCGG3b4YYgjlphghSu2+NmJM9Z4Y+Iu9vjjRzkWeWSSqQL5ZJRTVnllllt2 +WWYY5YZ4ZJrtvlmnHPWeWeVZvb5Z9R4Fnpooos2+mhrgVZ6aaabdvppqKOWemrIqqu2+mqss9Z6 a667VhlpsMMWe2yyy17Ta7TTVnvtmM12++1d2ZZ7abjrtvtuvPMOe26++/b7b8ADF5xPvQs3/HDE Ex94cMYbd/xxyCOXfHLKK7f88j8V13xzETH3XFnOQxd9dNJLN/101FNXfXXWW3ed3s9jl3122k16 /Xbcc9d9d957z7t24IMXfnjiizf++Nl9V35z5JuPdHnoEXd+euqrt/567LPXfnvuu/f+e8aiF19v 8Ms3/3z00298fPbtVv99+OOvNSAAOw== ------=_NextPart_000_000A_01C71F71.343FCB30-- From ChessGC@aslkenya.com Thu Dec 14 01:45:22 2006 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GukLJ-0006Av-Tn for ips-archive@lists.ietf.org; Thu, 14 Dec 2006 01:45:22 -0500 Received: from adsl-gall-232.lombardiacom.it ([212.34.231.232]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GukLE-0007wL-Pj for ips-archive@lists.ietf.org; Thu, 14 Dec 2006 01:45:21 -0500 Received: from CZWHPv (unknown [170.147.143.119]) by aslkenya.com with ESMTP id 470184DFA0DF for ; Thu, 14 Dec 2006 07:45:51 +0100 Message-ID: <000801c71f4b$684d4090$00000000@cf9d81a2409f424> From: "created" To: ips-archive@lists.ietf.org Subject: export laws import Date: Thu, 14 Dec 2006 07:45:13 +0100 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0004_01C71F53.CA11A890" 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: 1.2 (+) X-Scan-Signature: d9238570526f12788af3d33c67f37625 ------=_NextPart_000_0004_01C71F53.CA11A890 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0005_01C71F53.CA11A890" ------=_NextPart_001_0005_01C71F53.CA11A890 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Encryption triggers procedures, none. Mandrakes painless slightly, = modified rpm mdkrpm, collection. Ronald reagan remarks records. = Completed rfp process acquire licenses districts engagement. Milwrmcom hackers seeraquo ingres. Writers poems, novels written, chuck = sincere lost pastor heart. Memory reduces crashes recover. Casino socalled, mcasino casinos happy betting fly edtspain! Edit debug from, integrated? Reflect ownvar musicvar millions tracks = load. Husband about shopped blond new breast implants. Adding bookmark enjoy scoured sermons formats tolstoy. Addressing paths venuethis construed virginia paragraph submitted = resolved. Beth anderson focus zen. Reviews sure meaning modeling = excluding returns exception common. Gsa disclosure adp civilian carling = floor! Snowblower timeshare sunset, fishermen handyman, plans tryon = bulletin designer. Siemens, toshiba, juniper networks nec vonexus deloitte. Decorating = ideas retention articles cancun. Furnished, defects normal except foregoing exclusive remedy suns entire. ------=_NextPart_001_0005_01C71F53.CA11A890 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
3D"Petra"
Encryption triggers procedures, none. = Mandrakes=20 painless slightly, modified rpm mdkrpm, collection. Ronald reagan = remarks=20 records. Completed rfp process acquire licenses districts = engagement.
Milwrmcom hackers seeraquo ingres. = Writers poems,=20 novels written, chuck sincere lost pastor heart. Memory reduces crashes = recover.
Casino socalled, mcasino casinos happy = betting fly edtspain!
Edit debug from, integrated? Reflect = ownvar=20 musicvar millions tracks load.
Husband about shopped blond new breast = implants.
Adding bookmark enjoy scoured sermons = formats tolstoy.
Addressing paths venuethis construed = virginia=20 paragraph submitted resolved. Beth anderson focus zen. Reviews sure = meaning=20 modeling excluding returns exception common. Gsa disclosure adp civilian = carling=20 floor! Snowblower timeshare sunset, fishermen handyman, plans tryon = bulletin designer.
Siemens, toshiba, juniper networks nec = vonexus=20 deloitte. Decorating ideas retention articles cancun.
Furnished, defects normal except = foregoing=20 exclusive remedy suns entire.
------=_NextPart_001_0005_01C71F53.CA11A890-- ------=_NextPart_000_0004_01C71F53.CA11A890 Content-Type: image/gif; name="txedit raquo.gif" Content-Transfer-Encoding: base64 Content-ID: <000301c71f4b$684d4090$00000000@cf9d81a2409f424> R0lGODlhZAJAAYewAAAFAHUAAAByB4mCAAACjIMAhACLjcvGwcnSzazE7zYqAFgRAHQhDZ8WALgY ANErAAA7ABhFAEVMA1ZDAHw4AJIyAMU6ANsyAAtfAChsADZeA2VaAnJsApdTDcBdANtqAAB9AymK ATSMAGB8AnZxC5V4AMZ3DdSIAACeCi6nAEeZAFykAHmaCqynA8ibANuhAAC7ACfNAEbFAGLFDoXG DpzMAM3IBdXLAAPsBiTpADntAGrtAHfrCKPiAMbUANzVAAoHTCQIRkoAOGEATIcARZsNPLQFQtgA MQcZQS0WNDssSlgXTXIqP5EeQr8bPNorSgg1OhE/Sk5NQl4+S3k8OKo+PMg2PuQ+MgBuPS5aSEFg QmtaM3NSAKJYQMBVSdtuSwB8SBmGOz6HTWhzR3uDSJNxRbd0NOCONQCVQSecSjaVOGimO3SeOKSr Sr2aPdqZRQO1PCjNMjrORlG1QYa/Mp+xR7nOReLCPATSNhfhMzjXSlvcToTlQp3pRcbaRd7aNwIG fy0NhTYCcVgKiowFe5EAiLQNiuQAcQAneyAbiDQYjWYif3Yoi5MYdsUcjOgqcwA8hxpKfE04fGVN gYo0eJQydrQzeNY+hAljhypRgz5tjWFljoRfdahgjbZhf+lsjASNiyCFfER3iFiIc4l1faeIdsF2 iep8egStfyKljkyZf12rcYWSfKmdhL2nc9KgdgjBeh/CfjrDcVOxfnG9fp+0esCxjtO+fwDejBzn h07fhl7XiInif6Lcg8jqeOHcegAMuhsAwkUAtVcAuogAxaIAs8UAs+YBtQcqvxgXwk0WwWwVtnEq zqcsvMYmvd4syws1viU+vTQ6xFFDsYw9spNOv7RMwt04ywZewCFuxz9dtWdgxohjyZZsuL5Zv+Nt wQB1xB5zzDt2yWl1w417xqd7vraEv9t6zAmmzRGXwECmzlKbyYCat5Osycijy9agswe6zS7EyjrI zl/OsoG0tZnBxPX786aomnWIe/8BCgDzAP//BA4D/vQA/wD/8fL//yH5BACb5LcALAAAAABkAkAB Bwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuX MGHam0mzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWrWLNq3cq1q9evYMOK HUu2rNmzaNOqXcu27c2YcOPKnUu3rt27ePNKdMu3r9+/gAMLHky4sOHDiBMrXsy4sePHkCNLnky5 suXLmDNr1su5s+fPoEOLHk1Ss+nTqFOr9kq6tevXsGPLnk27tsoAuG3r3s27d2jcwHMzBJ4wuPF/ xoUjJ04wePPjB5MzZw6RukHp0hFax7jdt/fv4Osu/wVOkzxP8zjR1zTPXr294OVxz3Q/X356+0Hp 3w+wHr9N/UYBuNqABBYYoH/v8Xcegv0p+B9+5BkXX3sOJrifUwI2qOFVGRro4YeRcaecds4JlF1B 3S0XwEDEQadibilGN+JzKyZnInQnkrgiizm2mOOLKZ7oIpAwWueijTbeSN10wsUY3pNQzuakilQq WdyMVlqJ5HFT0qjjizzuyOSOCxk5ppZnVhmjmTUq59ybTRYp5pJsqhnnnGRGqeeeMiElIHoU6oQd f4DKFyGhiCb606D1KTrhhT2pV6iChzpY6aOQJmipfYFq6mmjn4KK6aeclgriqajuJCKZXLp555V5 hv+ZpY+0VjkclmjmmWSWZY5IJ5621soriq6y+qqdbRqbrJeyzjporHxGK21n29GapJNB7pqmsLdC myuxOOJ6na/FfmuureA2i6yzy56L7q9KyinutPTWC1e1cn6pb7rjAktll+qmu2aavepa7r/lwiuj ss1um6+7dbIrr7f2VmzxXklJaiiDoma64YMVYqqxxxr+WWrIOWm8KaUbrxwqgJOKfDKoMav88aSJ opzqzqdqpDCdw/IrNLP8lpgtxdyuiy6sRJ/5s7z7Isyw0sJGLKvV+FJ88dZc/8OUdA2qzKB+ZHMs Nsehgpy2pmfvZLOol3YMdsrwsV1hpzi7POqECMb//DHPgKvWNZQAD2744bQF3tjMijfueGGI77Zr 5JRXPtvjmGeu+eZHWe7556CHLvropJdu+kmcp6766qy37vrrsA84kgC0n04S7QJEhLvtvPdeEu7A B1/7QbtDFPxEwufOUPEZJQ+88c4rj/zwDzGvkPW+Z295U7jX1D1O3wcVvvi00zR+Tucvlf5P6xvV vk7ve19+7PTXD//8M8VPlP7g45+/AF/hH/r8lxQByg+APTGg/RZ4Go5Yz3kDKZ7wrke9CRKPegg5 XgRrB8ENajAh2PvHBw0SQoFIkIMWNGEFn0eQ5HkQgyKEofZmSMOCPPCEytsdDkE4vB2SUIYtRKH0 /3ToQx/yUHoqzF0JY4hEG2rweczbYRR7SEUlYnCJNcyi7244xCoy0SFGPKIYk0jGKVqxi038IRLN eMEOWpCNX2SjHFeIRi3akYZc9GAZR9jGJGLRjELUYxzp+EUyUnCNhFTjIetoSCLWcY6MLOQdJ0kv 7vkvfN/LpPDuh0B7JK9/nfwfADE5v+6RcpT409/4TgnKnQDPfKksZflYSUvnwTKUDMzl61YZSwSe 75UDxKUn1/fLWfZSlMPspCmP6cpLMtMm8QNmMm+JzFoq05jCpKYut+k6Xl7TlwScZjBbSc5qMnOZ 3xSnOsepzXW28yabVKcmUZlOa3Lznrn0pjbRif9Mds6Tk/vEJjVZOU1psnOg4ewnKP8pT1nSE6EO heU78UnRx+mzn/N8X/BEqcp4cjSU/FToJ5spzI0G85P/HKlIDZpMaXrUnRWNqUwFo0Cs1HSmOM0p ZiJ6lpvq9Kc9O10K54JFSho1i0BNqlKXytSmOvWpUI2qVDd31Kpa9apYzapWtzoaqnzgq0v56gfA IlawTvWsaH1KWc0q1rCaFSpt1UlckTLXmdR1rWOlCV7XepOy1qStewXsW+dKWL7q9a32uCti08rY pWhErAKBLGQzMtmPVPYgl61IZis72cxG9qsKWetAJAtazJb2H5wtbWdPe9nWnparsPWNa1H7Wov/ eHYjtx1tbSmyWdW+1rO5/WxqP0Bb4iJktcZFLkFY+9vmGje20LVLUur6171Wl7qGFexirzvY7o7V ujbBq139Ol7yhnex2u0rerfLXbaClbrXTaxf4wrfw+a1vPFtrH7FUl/5ujev6cWvfP1L4JwEuLAA Zq99F0zf/haYwdvFroLx+98Hq/e7GC6wgxV7Xwvv98Nb6S+CHxzg9nb4vPctcYNPjGIBE9jB/g2s hz0M4/RqF7yCHTCCI4xYDoP4xyFW8IiHzOMae5fEFZZrkl88YRq/t8gtVnKCmczi9saYxYZ1sYVh DOQuN0XERw4shrFsXpwQOcVLNvOSS6zmE7NZ/8szzq94jXzjKrvYxwv2sp6lAmY0j7nNF95wmI8c 5zyfeScS/nOU82xg7z7ZzuV99IRHzOhC71nPlG1ucXVL3NsCF6/HZW6nRS3c0Pr2uaR9rmlVvelW l7ogwXW1aGNdVk6jWtWxjq6uP6MU8qp4zQme8o0bregVBxvRgz62lBe9YkAv276KfvaW04xnOF/6 0rgVraxF7VrlFpfVtsb1XsO96uXW+tWhZnW3c0tr5446sOa+tbq1zel423vX+M63vvfN7377+9/R vbbAB24YgBv84KAjuMIXzvCGO/zhEI/4VBFO8Yobjir5yPhUMp4PiXt8qRjhuMhHnnGRcHwiJ/9P SMojQnKCiNzlJRfIyv8xc4vbfGtN4XhNdC4VngvF5zgB+k947vOR06ToGj960j/OdMsAXehOgbpP pI6Upyfd6DNBeseVvvWme10yVif5zkXOE7FnfelYt4fYSd71sW/d7DeBus7NrnW3f/3ukAn726+u caqrvetE53vHA7/0v7c97n0XfNALf/bBJ77xXLc73icvFo7MfOUnx3zMF5LyzG/e8/koSM1FX/LR G2T0oKd56T+/edWH/uawn+HlWR96zb/+IGyX+epvn3qY3x73uze97n8/fNfr3vjFH4jwY898PeW8 8HVnO+Mjb3jIS9/xh/d79Q1PdsQfvvqErzv/9SlPfsOEPfLaHz/ht28ToWvf/VKXe+IB333227/8 +L+K5Vtve+RznvbFZ3o1t3z+p3yt53sI6H8j13wMeDjP13bih3SLt3eKx37z137TZ3frlxMbaH/1 d375F4JWsX+/13/Dt3zSl3yu13kHuILEl3wtpxAxqIIraIAl2IINmIPfIYI8+HU6+INAGIRCOIRE WIRGqIM9mIQfd4RM2IQqoYRQGIVSOIVUWIVWSFVOmIVaCBJX2IVe+IVgqDlbOIZkiBFheIZnVYZq uIYPgYZu+IZwGIdyOId0yIZ2eIcGQYd6uId82IeVh4eAaId+OIiEWIiGmBSBmIhqeIiMyDqK//iI kBiJkhh7jViJlniJfjiJmjiEmNiJnviJX7iJoviDoFiKpniKqJiKqtgVo9iKrviKsJg9XrcJm6AW tLiKqIERtLiLtPgPvXgQvygQvOiLvLgJCFGMxkiMxaiMy4iMBbGMwpiMA4GMxhiMxKiMBLGLxziM 08iNzBiMzpgQvUiN35iM2tiN0giNzwiN4GiO0hiL0WWN0biN6ziP9liP8yiP2fiO7diN/niN+2gQ 1jiOA6mPAAmQ/XiQv5iQAumODemP5xiNDnmP/3iNC8mP7wiPvJMUt2gTHemRu1gTHfmRHymStTgT t1iSIGmSNDGSJ9mStaiSKmkPJZmSIUmTN//JkjchkzH5ki4JkznxkyuJkj3pkjbZEyTZkzg5lLiI GbqYkQe5jwV5jwbZjwZJkQkpjwSJjwEJkefojRXZlV75jwwplvpolV+pjVdpltUYkWKpkVxFjmc5 kQipjuvIjeQYluEYlRaZkXKJkX25lVz5loEZkXvJlX+Jl225lWuJjmkJlRQJl1o1lw+pkA65lpRJ j2MZln05mFjZlszIl6LJl4wJmAtRlpFZmJ15mlAJlpwpmViVmVJpmBN5lbJZmfaImoL5mlN5kalZ lX4JmpbJEKgpmr65mgpBmbcJm6TDkS8JlDpJlNK5lNPJlNCJEzXpk9oJnTyJnScplELJlOH/OZ7f +ZxBuZ3WOZ3giZ7hyZ3mOZNNmSoziYzUKZ28WJ/4WZ0wWYzRiZ9JmZP0SY37iZ79aZI5iZMA+pxH iZTluZPmmZ/1yZ/q+aBJeZ3xWRla2JhxoaHMOUnU+KEgGqIiOqIkWqImeqIomqIquqIs2qJ22aGh M4sPShbweaE2eqNpBaM6uqM82qO8JlP8wA84CoYAUKRFOhNHShNHaqRGqqRMCgBO+qT20KRICqVP SqU4caVVyqRRCqVbmqRX6qU9EaQ2EaRmmhNmSqYzkaZCiqZpuqZsKqRxqqY18aZz2qZ1SqdqyqZw ShN62qZ0OqSqkaRTaqViWqiIWqWKuqiE/xqlTloTjZoThLqkYjqplXqpiRoUcWoPf3oTndqpnoqn ZBqoZYqnOEGqpJqnoiqnq8qprdqnriqoiIERRXoQtToQtXqr/3CrusqrAGAQTCoQurqrv7oQvfqr x4qrxTqsyooQzCoQaUoQQToQ06oQ01qt/4Ct1MoPB6GtBeGt38qt0iqu3Wqm0Mqt2Hqt4hqt2bqu 5OqjXJMUkbqoimqp9Aqmh/ql9JqpOmGv9sqo+bqvkBqwrhqooKoTo/qqeXqqplqqO4GqDauqgMqq fkqxBTuxsCqrkHMRz0qsBJGrT6qswSqsV+qxIPuxxaoQJUusI0uyLgusK7sQ5rqtNFuu1f+aru96 rjbLrjqbEN4KrjSrru1as+oqtD0Lr9nTscN6skuLrCnrsQXhq03LEM96sij7slH7tA/Brjgrs+hK ruB6s+YKtEdbruHqs+5qtEPbrmLbtUibtFqLtSa7rCnrq82atSQ7tcYat3Z7t0obtw0htG6Ltmtb uDWrs2RruAbxszk7rueqtm2bto37tnDrt3SLtX0LtVVbt3qrsnzLuXcLtXPrrICLuF9LtO4atGA7 uV2buImruK67uqfbs1w7s4pLubYTsiILus06tWEqukZ6tXsLs1fbsrr7u3K7rTzLpofLvI8bu9E6 p46LEDx7u80bue+qrdo7ubgrLTOVqhr/63DfEaalyxKv272TGL7qGxjo277u+77wSxDrO799Eb/2 m3D0m79rcb/827/++78AHMCvob8EXMAGfMAIrFQCvMD1ksAOzBUMHMESPMFE+MAWjBUUnMHgccEc TBUa/MG90Yfz2sGLQavIK7cxm7dSG6zkC7MjG7PG+8IprMIsG7rEa6u8O7ch+7vJSrUti7LH+8Md C8K987fCC7ygO8Sie8Oji7k5bLWem7c2vLukG7pQPMWaW75HrMQu28MzTMSVtBTzyqX36qUjPMIC O7CP+q+JesYEaxP4iq/9+sZxbMaGehNjfMdqjMeYOsdZaqhoTMIFksdsLMd87MeSiqmF/2zHf9wT dZzGj9rIhSrHeczHlXzIkBzJcAzIbyzIBBKphqylkByme/zHZCzKAGvKZLzJ9arHktzIXFrHTUrK WOoTbIzJXeqonnwqoMzIiNqojxzIwhywlMrK/KrJiPzIiTzHynzJAxvIuDzMy6yvu+whvXzKvsyv xTzNrxzJwJzNpZzMdizNidzMxHzOx4zI6ZzJmbrN1XwYG9G5TYzEvVu+Sry5VvzETuvDTmzP/rzC ybvELyvP+YzCT9vD8wzGvCPPV3ysLJzC9/y5xRu8Kky3ugvE+yzFLkzRTIzEO1yyCD3EF43Qu2vR HK3QKB0aXJzSLH0XK93ST/LOMj3TNP89FTB9055R0zq90zw9FDj903nR00I91EQ9E0B91Eid1Eq9 1Ezd1E791FAd1VI91VRd1VZ91VgtHkXN01nd1V791R6x1VwN1mSNEGK902Wd1gVx1jqt1m791m7N 1jUN12kt13Z913id17hI13zd11at17vs118tFdB8GYWtzppT2IfNzHQMzoGx2B5nwjFcLy9dxXWR uQ1R2R1hxAL9ECuN2Z4B2gHtEZmr2Vokr30M2ZOh2sa8FqzN2mJMsIY8FIrt2Hwx218B21L1r7Lc pZdqqbWsyco8yW4MsFTqr6vs2+Pc22283M79pb993Mn9zIocy9MN3cQt29iMpVIK3ef/TL7Rrd3d 3dxpjMrdHcrLXc6yLN7k683B7dupnN2tPMucDNzvLd/4Ld/Svcrn3d/s7BYmbLn0jLd2S9JOnMUD LrxQvOBOW7oUDbL63MTJetITXc9Y3LcYnsMKruEaneAWPtpS28UcPtC8K9oPntESfrkmnsSincWX m+JMDNCdXdoNLuIXrrVeDOE6HNA6DuOkgdr87cqV3MvIXMbHfMu53M5C7srRzOTIvcjr3Mpr3Mfh HN9IHt/p/M1F/stUvsfIveXkbeXoLOXG7d/q7M7FreRkzs3mjMlfvubObORhjubozNv37RcBTrzI u7IyfNEFzbImTeE0TM8T7s8ffuAn/83DOP7R9eznVEziFc3ZBr7Ee87oIP7iOvzDAg7pM87iQQzD gk7oI47gnK7pkR7heCvqh47PW/ziBV7ilu7iWuwdRszqAn3FODzFuI7DNK7qlp3QhT7pncvgnZ0Q GT7aqS7sBy3RNn7piD7rpE7qtr7rgG7q047ikg7rqX7EGM3jmE7syr7txz7P4A7rpi1dSFHcb07f cD7m7M7lYK7mZP7ur+zOar7Nb27czb3kbu7Ls53mV67l847vAF/dYI7e/j7m8C7ndt7k8m7MDY/b DC/d/T7lFj/JuDzxqbzudI7MnQwZBc/d/W3fjb3d4Y3Y462lw4zNm0zx+y7xohzz1/9NzUpe38yc 31We8iN/5zqP3fVu5s7M3FhO3OqdzWjc8y9f9GLu8hjf8dnN3s8t5k+v3A8PzOxbMefeGlkPxlvv 2dDOz64xyB+/GLqNo2X/E2cf73+B9V+v9aaO046+2W1v7HOPF4DtyYLt1Xe/93zf937/94Avvnk/ +IQP1IF/+IhPiIV/1Yl/wIv/+JAf+ZIPr41vwJN/+Zjvv5VfwJnv1Jv/+aAf+qI/+qRf+qZ/+jLd +U2N+oKq+kzN+kPq+ksN+7Rf+w0n+0pt+xeK+0mt+/HZEQYQ/MJvABkx/MZP/P9w/MFfEMPP/MJ/ EMfv/MjP+0So/M9vEda//Mmf/QP/0fwE4f3dz/0Ccf3Un29MMfw0gf5HIfw6wf7pH/zv7/72YPw2 of7zD/8zIf++n1b6//5IARAGBNojWLCgQAMG7SEkiHBgQ4cGGSp8uLCiQowZNW7k2NHjR5AhRY4k WdLkSZQpVa5k2dLlS5gxC/6jWdPmTZw3Eebk2ZPnzp8CdQr959BATaM2gfZc6tPpU6hRpU6lWtXq VaxZtW7l2tXrV7BhxY7FuXKiR6Mgz2JcazGhW4ZG37pFe1HmXbx59e7l29fvX8CB+XJtGlTuUaeH gRZenFTo0sI5I5OlXNnyZcyZNW/m3NnzZ6VEfUIWzVQx4qakjz5eLXryUMSgZc+m/13b9m3cuXWP Li23aOnfsQ2bPhy69U7VT1/vZt7c+XPo0aXzNHtRLl2JdtlqP3iY4sOJZ9tmHC/Y/Hn06dWvZ9/e vT3CwGkiB758vnyk+POjJpo8sf7pAhRwQAILNFAqlsaLy67ysptruwchhOgt8RrsLsL3MtRwQw47 9PBD9xQcqC0LJ9yoxPLWEhFEFlt08UUYY5QRLgdNtJEjC1HkTsWIbpzxRyCDFHJIIjs6DTzF6sLw Qhx3ZPA0JouUckoqq7QSJLCKgw1A2IjjTbj9JEvKuAPLNPNMNNNUc00223TzTTjjlHNOOuu08048 89RzTz779PO5KwMVdFBCCzWUo6o/E1V0UUYb7elQSCOVdFJKK7X0Ukwz1XRTTjv19FNQWXR0VFJL NfVUVFNVdVVWuQr1VVhjlRXEVmu19VZcvZp1V1579fVXYIMVdlhiizX2WGSTVXZZZpt19lloowUy V2qrtfZamqTVdltuOcT2W3DDFXdccss191x001XX3G7bdfddeOOVd94Y17X3Xnzz1Xdffvv191+A AxZ4YIJzpfdghBNWeGGGGzYoIAA7 ------=_NextPart_000_0004_01C71F53.CA11A890-- From ips-bounces@ietf.org Thu Dec 14 04:15:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GumgL-00088U-0g; Thu, 14 Dec 2006 04:15:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GumgJ-00087Q-VI for ips@ietf.org; Thu, 14 Dec 2006 04:15:11 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GumgI-00043b-CZ for ips@ietf.org; Thu, 14 Dec 2006 04:15:11 -0500 Received: from lars.local (p54AD127F.dip0.t-ipconnect.de [84.173.18.127]) by kyoto.netlab.nec.de (Postfix) with ESMTP id AC4DF13CF82; Thu, 14 Dec 2006 10:20:03 +0100 (CET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by lars.local (Postfix) with ESMTP id A139B2AE9B4; Thu, 14 Dec 2006 10:15:06 +0100 (CET) In-Reply-To: <20061211173407.44662.qmail@web51914.mail.yahoo.com> References: <20061211173407.44662.qmail@web51914.mail.yahoo.com> Mime-Version: 1.0 (Apple Message framework v752.2) Message-Id: <8133F44D-5CFC-4235-A281-A7A0692A5638@netlab.nec.de> From: Lars Eggert Subject: Re: [Ips] ips WG Last Call: iSCSI Implementer's Guide Date: Thu, 14 Dec 2006 10:14:52 +0100 To: Mallikarjun C. X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f 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="===============0791415363==" Errors-To: ips-bounces@ietf.org --===============0791415363== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-5-949416593; protocol="application/pkcs7-signature" --Apple-Mail-5-949416593 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi, On Dec 11, 2006, at 18:34, Mallikarjun C. wrote: > As far as volunteers for reviewing, we could request the > contributors at the end of the document to review. David may have > already reviewed, based on his comments. Julian Satran had some > offline feedback for me on TMF topics. As the editor of the > document, I was sure that each of the topics were discussed in > detail (or at least clearly noted) on the list before I included > them in the doc. Hope that gives you some reassurance. it does, and I trust the WG to organize sufficient reviews. >> whether it is merely the original text that can be >> misunderstood or if there is a technical error in the original text. >> (It already does in some cases.) > > Yes, I'd appreciate if you could point out where you think > additional clarifications could help. I think I'd mostly like to see stronger language on "this section contains only a clarification of section X of RFC Y" vs. "this section replaces section X of RFC Y." >> OK, so this document not only updates 3720, but also 3721, 3722 and >> 3723? That needs to be stated in the document header and abstract. >> (Also, 3721 needs to be normatively cited in this case.) > > We could. My intent was to make it clear that this document > prevails whenever a subtle interpretation in future of one of these > RFCs differs from what's in this document. Now that we are nearing > the end of the work on this document, we could delete some although > I personally am tempted to leave it this way....from what I can > think of today though, this doc updates 3720 and 3721, but does not > update 3722 and 3723. I'd argue for being very clear about which sections of which RFCs this document clarifies/replaces and which are only cited for information. (Where things are being clarified or replaced, those RFCs need to be cited normatively.) > 3721 is not a standards-track RFC and I wasn't sure if it needs to > be normatively cited as such. But I could if that's the right > thing to do. It is, see above. Any RFC (independent of its type) that is being clarified or replaced needs to be a normative reference. Please check if this introduces and downrefs according to RFC3967 that we need to handle. >> Suggest to find a better title, because implementer's guides don't >> typically update the base specification in a normative way. (Maybe >> "iSCSI Corrections and Implementer's Guide" or something like that?) > > FIne by me. How about "iSCSI Corrections, Clarifications, > Additions and Implementation Guidance", or is it too long? If it > is, we could try "iSCSI Changes Based on Implementers' Experience" > or something like it. The first is a bit too long, and I don't like the second :-) "iSCSI Corrections and Clarifications?" Lars --Apple-Mail-5-949416593 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKZDCCAwEw ggJqoAMCAQICEBCR/semQl5bz/x3jtiU02YwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDgxNjA5MTU0NloXDTA3MDgxNjA5MTU0 NlowYDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEoMCYGCSqGSIb3DQEJARYZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5kZTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAL/+LXyqufw8ApYnCU24cnZ/H9S7ro4zZYeCqcyFqhwJpTcM8/yX 6Ms+16d2EtIceQS8Bas3GAUR+xfq0QI5dt8uIKM1Uy4trk8AAO0dh23+QTLw7toloArVngGIhUhC OTpVRR1bYfJTwPVpSAY43mbGhSGhwiu5035yKdYJezNWOXmuIO+lvXcD36hc5cU6AzRJkj0LYaFd WHjbfwzGmT7MO60p/7hT+aTv5xvTl/mcwslvm+KhKmJjoMYfSOF99xvuJE/rB7Ho3g6wDoeB2Tip 44Qq8CPmOHtCXzh/tF/bYo+OHStkPTzgPfOuNDMxa0/gAPEyELNL0Eh1/hC2TeMCAwEAAaM2MDQw JAYDVR0RBB0wG4EZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5kZTAMBgNVHRMBAf8EAjAAMA0GCSqG SIb3DQEBBQUAA4GBAHdaTI5TM5wV+LG2WW+CMEmxEyNhaRu3oca9T31HjbfHzvhVJe2fzKt1xBSo +hhCg0qKVFuE7yKxDH975Csq9jVvJJj3oL29RQjPnc3CgQqlMFJKHdJgterPQ+ZiCp05S9rbMhRl 1zxB/x+GvnDFHsXu19gA2dlynrdWN/G1BVWJMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUF ADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBU b3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSsw KQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAw MFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7s vc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV 84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGR MBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUu Y29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCk HjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oL LswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoL gnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHT HUb/XV9lTzCCBBgwggOBoAMCAQICAQAwDQYJKoZIhvcNAQEFBQAwgb8xCzAJBgNVBAYTAkRFMRww GgYDVQQIFBNCYWRlbi1Xw3VlcnR0ZW1iZXJnMRMwEQYDVQQHEwpIZWlkZWxiZXJnMRcwFQYDVQQK Ew5ORUMgRXVyb3BlIEx0ZDEdMBsGA1UECxMUTmV0d29yayBMYWJvcmF0b3JpZXMxGzAZBgNVBAMT EmtvYmUubmV0bGFiLm5lYy5kZTEoMCYGCSqGSIb3DQEJARYZbGFycy5lZ2dlcnRAbmV0bGFiLm5l Yy5kZTAeFw0wNDA2MTgxMTUzMDhaFw0wOTA2MTcxMTUzMDhaMIG/MQswCQYDVQQGEwJERTEcMBoG A1UECBQTQmFkZW4tV8N1ZXJ0dGVtYmVyZzETMBEGA1UEBxMKSGVpZGVsYmVyZzEXMBUGA1UEChMO TkVDIEV1cm9wZSBMdGQxHTAbBgNVBAsTFE5ldHdvcmsgTGFib3JhdG9yaWVzMRswGQYDVQQDExJr b2JlLm5ldGxhYi5uZWMuZGUxKDAmBgkqhkiG9w0BCQEWGWxhcnMuZWdnZXJ0QG5ldGxhYi5uZWMu ZGUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALQ5DCwTzpGu3RmzQY4KxiaQak/BwIW9Wk6K Mg+/V0aiWvlrz7uFdICBGVTKhyWr3F+GxRPCVTWqS9VEPf9A59DI9TFCS3FtraSx+w8ApQei8idb J0Lqu8tTz2O1gYR2dELID5wQH9dxIANt3bP39crgDZzGYxCJilcimFhADEgHAgMBAAGjggEgMIIB HDAdBgNVHQ4EFgQU6Hsv16oYecCFsl07g9gtjPEJo00wgewGA1UdIwSB5DCB4YAU6Hsv16oYecCF sl07g9gtjPEJo02hgcWkgcIwgb8xCzAJBgNVBAYTAkRFMRwwGgYDVQQIFBNCYWRlbi1Xw3VlcnR0 ZW1iZXJnMRMwEQYDVQQHEwpIZWlkZWxiZXJnMRcwFQYDVQQKEw5ORUMgRXVyb3BlIEx0ZDEdMBsG A1UECxMUTmV0d29yayBMYWJvcmF0b3JpZXMxGzAZBgNVBAMTEmtvYmUubmV0bGFiLm5lYy5kZTEo MCYGCSqGSIb3DQEJARYZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5kZYIBADAMBgNVHRMEBTADAQH/ MA0GCSqGSIb3DQEBBQUAA4GBAJfoil3cAX3cUPMFrDdlW9DPMK/+QY8EHPOsnefm77h5CmmY6J+G 5Ydl9vyHxL76Opyg8cZWOOU/k9oVv7AvQ1GmIFqVFyWKQPfEhj+EWjEnUAcI7QDN8XER+U7XRvj6 yYysFgm2Tl30QCGvmESCgYIztCKMG2cLBkEosj2kWBbXMYIDsjCCA64CAQEwdjBiMQswCQYDVQQG EwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEBCR/semQl5bz/x3jtiU02YwCQYFKw4D AhoFAKCCAhEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYxMjE0 MDkxNDU0WjAjBgkqhkiG9w0BCQQxFgQUnqrVzIhasf0EtXyBKk9nL8Z8P9cwgdYGCSsGAQQBgjcQ BDGByDCBxTCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRlbWJlcmcxEzAR BgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYDVQQLExROZXR3 b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgwJgYJKoZIhvcN AQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMIHYBgsqhkiG9w0BCRACCzGByKCBxTCB vzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRlbWJlcmcxEzARBgNVBAcTCkhl aWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYDVQQLExROZXR3b3JrIExhYm9y YXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgwJgYJKoZIhvcNAQkBFhlsYXJz LmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMA0GCSqGSIb3DQEBAQUABIIBAH2Aqf5TaTOaTifja+2E tSy5k2phdZwKakSS6bPM7gCJ7WxmcLk4yfJfrH/ee2MYoQiAs9wsWGo9m/K1YA2UYu5xjf6IGUJt jLZrQW6znBULKrFjfrw+huJWY8mxO1nJkPYG9kGyXIlt4DOb5ujbjkrwhMCMaP51LZfA3Gx7rMkW pHwo2e+IEy/tE7lRzO5NIGlUTjX5jIm8cdjjA1GYF3ZPFT+sC2X8yUld1b8j75CIV9ZPhPZh1ehJ 2R462M26c7LwPAZI+rhRzM/bSHNVXlyRZmR0yS3s6Rz23eC83d7RQ01rG3BX5PQFBfId63seb7Ls 0dqpjv9toFg4OOCS6dgAAAAAAAA= --Apple-Mail-5-949416593-- --===============0791415363== 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 --===============0791415363==-- From ips-bounces@ietf.org Thu Dec 14 06:32:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Guooh-0007vA-KH; Thu, 14 Dec 2006 06:31:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Guoog-0007uy-4G for ips@ietf.org; Thu, 14 Dec 2006 06:31:58 -0500 Received: from web51903.mail.yahoo.com ([206.190.48.66]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Guood-0001PS-BO for ips@ietf.org; Thu, 14 Dec 2006 06:31:58 -0500 Received: (qmail 35069 invoked by uid 60001); 14 Dec 2006 11:31:55 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type; b=WdkUIQUeOJD/eVBe/pnK2WDljjBYEAYYtYJpGNxjBRZfU9kiI/39KdO5GoKbBXyPFgGbTQurYc7Vbmd9wtlSEet6HejxMVt9EczHQd/w4+eMpfRGcFpVpXheiuj6JOv6O3svWHbVYqbbbT7O1MUXCfka7O1x65x8G87BbIgOB6I= ; Message-ID: <20061214113155.35067.qmail@web51903.mail.yahoo.com> Received: from [15.203.169.125] by web51903.mail.yahoo.com via HTTP; Thu, 14 Dec 2006 03:31:55 PST Date: Thu, 14 Dec 2006 03:31:55 -0800 (PST) From: "Mallikarjun C." Subject: Fw: [Ips] Implementer's Guide - Task Management Issue To: IPS MIME-Version: 1.0 X-Spam-Score: 0.3 (/) X-Scan-Signature: ba0d4c5f57f7c289496fce758bbf4798 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="===============1953134341==" Errors-To: ips-bounces@ietf.org --===============1953134341== Content-Type: multipart/alternative; boundary="0-405033859-1166095915=:34189" --0-405033859-1166095915=:34189 Content-Type: text/plain; charset=ascii Content-Transfer-Encoding: quoted-printable Trying again after clipping the tail, my first note bounced (size > 50KB)..= ..=0A=0A=0A=0A----- Forwarded Message ----=0AFrom: Mallikarjun C. =0ATo: ips@ietf.org=0ASent: Wednesday, December 13, 2006 1= 2:21:18 PM=0ASubject: Re: [Ips] Implementer's Guide - Task Management Issue= =0A=0A=0AI am still traveling and in different time zones, so apologies for= being slow to respond.=0A =0AIMHO, RFC 3720 had a good reason to require T= TT completions on all initiators (issuing and third-party). We took a more= conservative approach "data transfers for terminated tasks cannot be activ= e" at that time. We also had concerns about ordering issues in multi-conne= ction sessions.=0A =0ABy the IG time, we took a more relaxed approach "let = data transfers for terminated tasks be in progress". So the immediate ques= tion was: So what happens to those Data-Outs with stale TTTs? Roughly, th= ere are two possible answers to that: a) let the target silently discard th= em, b) let the target maintain the buffer resources for "a bit longer" so t= he outstanding transfers can complete.=0A =0AThe current IG approach is not= to recommend either (a) or (b), but leave enough room to implement either = (a) or (b) per your implementation considerations. iSCSI/iSER implementati= ons have a particular problem with (a) because an invalid STag is fatal for= the connection. So I don't think we want to recommend (a) outright.=0A = =0AIf a target wants to do (b), it needs a signal to deterministically free= up resources - that's true for both issuing and third-party initiators (wh= at is "a bit longer"?). And that is the proposed Nop-Out. So I do not see= a qualitative difference between issuing and third-party initiators wrt th= e requirement on key negotiation to enable fast abort...... so I am so far = not convinced that changing the current text is the right thing to do (I'll= need to sync up with Julian to understand what I'm missing, and that is pr= oving challenging due to both of us traveling).=0A =0AI believe we're cover= ed on the ordering issues with the new IG text - with the response fence no= tion. So I wouldn't have any concerns on that front with what David is pro= posing.=0A =0AMallikarjun=0A=0A=0A----- Original Message ----=0AFrom: Julia= n Satran =0ATo: Black_David@emc.com=0ACc: ips@iet= f.org=0ASent: Wednesday, December 13, 2006 7:19:40 AM=0ASubject: RE: [Ips] = Implementer's Guide - Task Management Issue=0A=0A=0ADavid, =0A=0AI agree - = and I think there was general agreement on the mailing list that the langua= ge in 3270 (whatever it is) is confusing. =0A=0AThanks, =0AJulo =0A=0A=0ABl= ack_David@emc.com =0A12/12/06 22:35 ToJulian Satran/Haifa/IBM@IBMIL =0Accip= s@ietf.org =0ASubjectRE: [Ips] Implementer's Guide - Task Management Issue= =0A=0A=0A=0A=0A=0A=0A=0AJulian, =0A =0AI agree that the target should be a= ble to do this (not delay TMF response =0Awaiting for an initiator that did= not issue the the TMF), but the language =0AI quoted from RFC 3720 explici= tly requires the wait (and has been read =0Ato require the wait by more tha= n one implementer). =0A =0ACan we agree that the implementers guide needs = to clarify RFC 3720 =0Aalong the lines of what you wrote, and specifically = say that completion =0Aof a TMF never has to wait for a response from an in= itiator other than =0Athe one that issued the TMF? =0A =0AThanks, =0A--Dav= id =0A=0AFrom: Julian Satran [mailto:Julian_Satran@il.ibm.com] =0ASent: Tue= sday, December 12, 2006 3:12 PM=0ATo: Black, David=0ACc: ips@ietf.org=0ASub= ject: RE: [Ips] Implementer's Guide - Task Management Issue=0A=0A=0ADavid, = =0A=0AThe issue you are describing falls in the same category. =0ATarget ca= n answer to B as soon as it has "purged" the tasks regardless of what A doe= s. =0AFor safety the implementation should keep the pairs ITT-TTT and make = sure it does not reuse =0Athe TTTs with the same ITT for a while or force c= losing offending sessions. =0AThere is no need to really delay the TM respo= nse - just act as if all outsanding activity died out and ignore data reach= ing the target. =0A=0AJulo =0A=0ABlack_David@emc.com =0A12/12/06 20:26 =0AT= oJulian Satran/Haifa/IBM@IBMIL =0Acc =0ASubjectRE: [Ips] Impl= ementer's Guide - Task Management Issue=0A=0A=0A=0A=0A=0A=0A=0A=0A=0AJulian= , =0A =0A> As for the issue raised by Bill Studemund I am not sure that the= target needs help in =0A> recovering buffers (and I am not sure that I am = not repeating what I said already in he past). =0A =0AThe motivating concer= n is not buffer recovery - it's the ability of an uncooperative initiator = =0Ato delay completion of a TMF issued by a different initiator. Here's an= example: =0A =0A- Initiator A has one or more data transfers in progress t= o the target. =0A- Initiator A dies in some inconvenient fashion. The targ= et thinks the iSCSI=0A session with Initiator A is still alive, but Initia= tor A is non-responsive. =0A- Initiator B issues a TMF that has the effect = of aborting Initiator A's tasks =0A (e.g., CLEAR TASK SET). =0A =0AThe is= sue is: When can the target issue the TMF response to Initiator B? =0A =0AC= urrent RFC 3720 language requires completion of Initiator A's data transfer= s or timing =0Aout and dropping Initiator A's session - Section 10.5.1: "Th= e target on its part MUST =0Await for responses on all affected target tran= sfer tags before acting on either of these =0Atwo task management requests"= . In this example, the data transfers will not =0Acomplete, requiring timi= ng out and dropping the session before the TMF response =0Acan be issued. = =0A =0AThe request is that it be permissible for the target to redirect Ini= tiator A's data transfers =0Ato bit-buckets (just in case Initiator A is no= t actually completely dead) and issue the TMF =0Aresponse once that redirec= tion (as well as everything that RFC 3720 requires with =0Arespect to Initi= ator B) is done so that the TMF response doesn't have to wait for the =0Ata= rget to time out and tear down the session with Initiator A. =0A =0AThanks,= =0A--David=0A=0A=0A =0A___________________________________________________= _________________________________=0ACheap talk?=0ACheck out Yahoo! Messenge= r's low PC-to-Phone call rates.=0Ahttp://voice.yahoo.com --0-405033859-1166095915=:34189 Content-Type: text/html; charset=ascii Content-Transfer-Encoding: quoted-printable
Trying again after clipping the tail, my first no= te bounced (size > 50KB)....
=0A


 
=0A----- Forwarded Message ----
From: Mallikarjun C. <cb_mallika= rjun@yahoo.com>
To: ips@ietf.org
Sent: Wednesday, December 13, 200= 6 12:21:18 PM
Subject: Re: [Ips] Implementer's Guide - Task Management I= ssue

=0A
=0A
I am still traveling and in different= time zones, so apologies for being slow to respond.
=0A
&nbs= p;
=0A
IMHO, RFC 3720 had a good reason to require TTT comple= tions on all initiators (issuing and third-party).  We took a more con= servative approach "data transfers for terminated tasks cannot be active" a= t that time.  We also had concerns about ordering issues in multi-conn= ection sessions.
=0A
 
=0A
By the IG time,= we took a more relaxed approach "let data transfers for terminated tasks b= e in progress".  So the immediate question was:  So what hap= pens to those Data-Outs with stale TTTs?  Roughly, there are two possi= ble answers to that: a) let the target silently discard them, b) let the ta= rget maintain the buffer resources for "a bit longer" so the outstanding tr= ansfers can complete.
=0A
 
=0A
The curren= t IG approach is not to recommend either (a) or (b), but leave enough room = to implement either (a) or (b) per your implementation considerations. = ; iSCSI/iSER implementations have a particular problem with (a) because an = invalid STag is fatal for the connection.   So I don't = think we want to recommend (a) outright.
=0A
 
=0A<= DIV style=3D"FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times= , serif">If a target wants to do (b), it needs a signal to deterministicall= y free up resources - that's true for both issuing and third-party initiato= rs (what is "a bit longer"?).  And that is the proposed Nop-Out. = So I do not see a qualitative difference between issuing and third-party i= nitiators wrt the requirement on key negotiation to enable fast abort......=  so I am so far not convinced that changing the current text is the ri= ght thing to do (I'll need to sync up with Julian to understand what I'm mi= ssing, and that is proving challenging due to both of us traveling).=0A
 
=0A
I believe we're covered on the or= dering issues with the new IG text - with the response fence notion.  = So I wouldn't have any concerns on that front with what David is proposing.=
=0A
 
=0A
Mallikarjun

=0A----- Original Message ----
From: Julian Satran <Julian_Satran= @il.ibm.com>
To: Black_David@emc.com
Cc: ips@ietf.org
Sent: Wed= nesday, December 13, 2006 7:19:40 AM
Subject: RE: [Ips] Implementer's Gu= ide - Task Management Issue


Dav= id,

I agree - and I think t= here was general agreement on the mailing list that the language in 3270 (w= hatever it is) is confusing.

Thanks,
Julo

<= BR>=0A=0A=0A=0A
Black_David@emc.com =0A<= P>12/12/06 22:35

=0A		=0A=0A=0A=0A=0A=0A
=0A
=0A<= DIV align=3Dright>To=0AJulian Satran/Haifa/IBM@IBMIL =0A
=0A
= cc
=0A		ips@ietf.org = =0A
=0A
Subject
=0A		RE: [Ips= ] Implementer's Guide - Task Management Issue
=0A=0A=0A
=0A




Julian,
 
I agree that the target should be able to do th= is (not delay TMF response
w= aiting for an initiator that did not issue the the TMF), but the language
I quoted from RFC 3720 explic= itly requires the wait (and has been read
to require the wait by more than one implementer).  
Can w= e agree that the implementers guide needs to clarify RFC 3720
along the lines of what you wrote, and sp= ecifically say that completion
of a TMF never has to wait for a response from an initiator other than=
the one that issued the TMF?  
Thank= s,
--David

From= : Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Tues= day, December 12, 2006 3:12 PM
To: Black, David
Cc: ips= @ietf.org
Subject: RE: [Ips] Implementer's Guide - Task Managemen= t Issue


David,

The issue you are describing falls in the same category.
Target can answer = to B as soon as it has "purged" the tasks regardless of what A does.
For safety the implementation should keep the pairs ITT-TTT and ma= ke sure it does not reuse
the TTTs with the same ITT for a while or force closing of= fending sessions.
There is no need to really delay the TM response - just act as if = all outsanding activity died out and ignore data reaching the target.

Julo

=0A=0A=0A=0A=0A=0A
Black_= David@emc.com =0A

12/12/06 20= :26

=0A
=0A=0A=0A=0A=0A=0A
=0A
To
=0A		Julian Satran/Haifa/IBM@IBMIL =0A
=0A
cc
=0A		<ips@ietf.org> =0A
=0A
Subject
=0A		RE: [Ips] Implementer's G= uide - Task Management Issue


=0A=0A
=0A
<= BR>



Julian,
 
> As for the issue raised by Bill Stud= emund I am not sure that the target needs help in
> recovering buffers (and I am not s= ure that I am not repeating what I said already in he past).
 
The motivating concern is not buffer recovery = - it's the ability of an uncooperative initiator
to delay completion of a TMF issued by a= different initiator.  Here's an example:
&n= bsp;
- Initiator A has one or more da= ta transfers in progress to the target.
- Initiator A dies in some inconvenient fashion.  The target thinks the= iSCSI
  session with Initiator A is still alive, but Initiator A i= s non-responsive. =
- Initiator B issues a TMF that has the effect of aborting Initiator A'= s tasks
 =  (e.g., CLEAR TASK SET).
 
The issue is: When can the target issue the TMF = response to Initiator B?
 
Current RFC 3720 language requires completion of Init= iator A's data transfers or timing
out and dropping Initiator A's session - Section 10.5= .1: "The target on its part MUST
wait for responses on all affected target transfer tags = before acting on either of these
two task management reque= sts".  In this example, the data transfers will not
complete, requiring timing out= and dropping the session before the TMF response
can be issued.  
The request is that it be pe= rmissible for the target to redirect Initiator A's data transfers
to bit-buckets (just in= case Initiator A is not actually completely dead) and issue the TMF=
response once that r= edirection (as well as everything that RFC 3720 requires with
respect to Initiator B) is = done so that the TMF response doesn't have to wait for the
target to time out and tear down the session with Initiator A.
&nbs= p;
Thanks,
--David

=0A= =0A
Need a quick answer? Get one in minutes from people who kno= w. Ask your question on=0A Yahoo! Answers. --0-405033859-1166095915=:34189-- --===============1953134341== 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 --===============1953134341==-- From ellwoodalexandra@hummingbirdhillwebsites.com Fri Dec 15 15:54:56 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvK52-0000cc-5p for ips-archive@lists.ietf.org; Fri, 15 Dec 2006 15:54:56 -0500 Received: from [207.144.245.5] (helo=ws40hkn21) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GvK4v-0007yv-R4 for ips-archive@lists.ietf.org; Fri, 15 Dec 2006 15:54:56 -0500 Content-Class: urn:content-classes:message To: "max ethel" From: "marinna carie" Date: Fri, 15 Dec 2006 15:54:44 -0500 Sender: "marinna carie" Subject: Be macho! MIME-Version: 1.0 Message-ID: Content-Type: multipart/alternative; boundary="----=_NextPart_000_BCD27_01C72061.3FF11830" X-Mailer: Microsoft Outlook Express 6.00.2900.2527 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 3.1 (+++) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb This is a multi-part message in MIME format. ------=_NextPart_000_BCD27_01C72061.3FF11830 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit HOT MONDAY FOR TTEN TTEN *** TTEN *** TTEN TTEN - Ten & 10, Inc. GROUND FLOOR opportunity in the WIFI Industry!! TTEN could see explosive growth as a newly trading company - 500%-1000% is not uncommon. Current Price: .11 Short Term Target: 2.20 TTEN has grown from China business focus to USA, Europe, Latin America as well as other areas of Asia. Within 12 months expected to generate $2 MILLION in NET INCOME. $200 MILLION in 5 years. TTEN is made up of 4 operating subsidiaries: Tech 10: WIFI and WiMAX Mobile 10: Music and mobile entertainment delivered via Internet, G3, etc Dream Learning Center: Digital Media Learning products Ten & 10 Network: Sales and marketing Telecommunications is globally a TRILLION dollar industry. Tech 10 has entered into a strategic alliance with FSP Holding an Asian based WiFi and WiMAX provider. The collective goal of the venture is to become the premier MAN/LAN (metropolitan area network/local area network) provider satisfying the needs of government and corporations in Asia. FSP is currently a pioneer in developing high performance, efficient and expandable wireless/wired communication networks in Asia. The Core business is: metropolitan wireless broadband for emergency responses, the WiMAX applications and value-added services, include: Public Safety Surveillance and Mobile Command Center, Distance Learning, Cyber Cafe Access, Dynamic Video Surveillance, SOS Poles, Public Traffic System, Road Monitoring System, Video-Conferencing, Multi-media Broadcasting, Train Compartment Monitoring etc. FSP anticipates the ability to generate gross revenues of about $2 billion in five years, and net profits of about $200 million. WATCH THIS SHARES GO HIGHER AND HIGHER Any of the above statements with respect to the future predications or goals and events may be seen as only Forward Looking and nothing else. All information inside this email pertaining to any sort of financial advice need to be understood as information and not advice. None of the information above can be constructed as any sort of financial advice. This is a paid advertisement. ------=_NextPart_000_BCD27_01C72061.3FF11830 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable HOT MONDAY FOR TTEN

TTEN *** TTEN *** TTEN

TTEN - Ten & 10, Inc.

GROUND FLOOR opportunity in the WIFI Industry!!

TTEN could see explosive growth as a newly trading company - 500%-1000% = is not uncommon.

Current Price: .11
Short Term Target: 2.20

TTEN has grown from China business focus to USA, Europe, Latin America = as well as other areas of Asia. Within 12 months expected to generate $2 = MILLION in NET INCOME. $200 MILLION in 5 years.

TTEN is made up of 4 operating subsidiaries:

            Tech = 10: WIFI and WiMAX
            = Mobile 10: Music and mobile entertainment delivered via Internet, G3, = etc
            Dream = Learning Center: Digital Media Learning products
            Ten = & 10 Network: Sales and marketing

Telecommunications is globally a TRILLION dollar industry.

Tech 10 has entered into a strategic alliance with FSP Holding an Asian = based WiFi and WiMAX provider. The collective goal of the venture is to = become the premier MAN/LAN (metropolitan area network/local area = network) provider satisfying the needs of government and corporations in = Asia.  FSP is currently a pioneer in developing high performance, = efficient and expandable wireless/wired communication networks in = Asia.  The Core business is:  metropolitan wireless broadband = for emergency responses, the WiMAX applications and value-added = services, include:   Public Safety Surveillance and Mobile = Command Center, Distance Learning, Cyber Cafe Access, Dynamic Video = Surveillance, SOS Poles, Public Traffic System, Road Monitoring System, = Video-Conferencing, Multi-media Broadcasting, Train Compartment = Monitoring etc.  FSP anticipates the ability to generate gross = revenues of about $2 billion in five years, and net profits of about = $200 million.


WATCH THIS SHARES GO HIGHER AND HIGHER




Any of the above statements with respect to the future predications or = goals and events may be seen as only Forward Looking and nothing else. = All information inside this email pertaining to any sort of financial = advice need to be understood as information and not advice. None of the = information above can be constructed as any sort of financial advice. = This is a paid advertisement.

 ------=_NextPart_000_BCD27_01C72061.3FF11830-- From aprilperdu@gaoland.net Sat Dec 16 15:16:54 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gvfxl-0007Z1-VV; Sat, 16 Dec 2006 15:16:54 -0500 Received: from [86.68.102.194] (helo=gaoland.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gvfxi-0007By-QR; Sat, 16 Dec 2006 15:16:53 -0500 Message-ID: Reply-To: "Franchesca Andrews" From: "Franchesca Andrews" To: "Miyoko" Cc: "Edelmira" , "Rachel" , "Monet Kim" , "Arcelia Mills" , "Afton" , "Arletta" <6lowpan-request@lists.ietf.org>, "Iona" Subject: All well or no Date: Sat, 16 Dec 2006 22:52:10 +0300 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_B3D_C71E_E4DC0FE3.CF98BEE1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Spam-Score: 1.9 (+) X-Scan-Signature: 7118f330e2af0a096ba071c5e99ca10e This is a multi-part message in MIME format. ------=_NextPart_B3D_C71E_E4DC0FE3.CF98BEE1 Content-Type: multipart/alternative; boundary="----=_NextPart_2B7_7BEC_34D3967B.8AD4F0D9" ------=_NextPart_2B7_7BEC_34D3967B.8AD4F0D9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable was thinking, thankful even for this temporary respite, but theyll go beg= un, for every day heavilyloaded wheat wagons wound slowly over the liked = her better, and when the meeting was over and an invitation waslong trail= on their way to Brandon, and the StoppingHouse became the famine than any I nut I kill slipper if you do not let her come over= -priced to me." grill had seen before, and as I approached them, in the mornin if the storm goes down, and I cant stop themvain isforegath= ering place of all the farmers in the settlement. At noon thegiven to the= anxious ones to tarry awhile, tarried. Whenstable yard presented a liv= ely appearance as the boys unhitched their there was wafted to my argue And I round raised my pistol to a level = purple with dramatically his heart.   flesh nostrils the pungent aroma of woodsmoke. the help of man.steaming teams and led them to the long, straggling straw= roofedthe other cases had been dismissed had a long talk with thestable= s. The hay that had cut on the meadows of Black What could hunger it mean? There could, to my mind, Of course the creatur= e bump had no conception of the purpose definition of the be replace but leave out a captain in charge. Suddenly Mrs. started as if she had heard a strange andCreek and stacked= beside the stables was carried in miniature stacks was a gentleman of p= rivate means, though he was accustomedwhich completely hid the man who ca= rried them into the mangers, while single solution: man vegetable abided close by, strange little impleme= nt which hoop I was nonsense poking toward him. disturbing noise; she threw out her hands as if in protest. She satthe cr= eaking windlass of the well proclaimed that the watertroughsto explain hi= s manner of making a livelihood, when questioned bywere being filled. The= cattle who foraged through the straw stack in bath order a higher order ofWith ballroom a sound that was half humble hu= man and ceiling half the growl of a wild beast, man than we had as yet seen, calcium other than Ahm, still a few moments holding fast to the kitchen table in herthe field nea= r by always made the mistake of thinking that they weremagistrates and ot= her interested persons, by saying he was employed inincluded in the invit= ation, much to the disgust of Peter Rockett, the negative the Neanderthal simultaneously he sprang toward me. I aimed = at his heart and fired, and expose   measure energy man. chore boy, who drove them back with appropriate remar= ks. ------=_NextPart_2B7_7BEC_34D3967B.8AD4F0D9 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

3D""


was thinking, thankful even for this temporary respite, but theyll go=  begun, for every day heavilyloaded wheat wagons wound slowly over t= he liked her better, and when the meeting was over and an invitation= waslong trail on their way to Brandon, and the StoppingHouse became the&= nbsp;
famine than any I nut   I kill slipper if you do not let &= nbsp;  her come over-priced to me."    grill had seen before, and as I approached them,    <= BR> in the mornin if the storm goes down, and I cant stop themvain isforegath= ering place of all the farmers in the settlement. At noon thegiven to the= anxious ones to tarry awhile, tarried. Whenstable yard presented a liv= ely appearance as the boys unhitched their   there was wafted to my argue     And I round raised m= y pistol to a level purple with   dramatically his heart. =     
flesh nostrils the pungent aroma of woodsmoke.   

the help of man.steaming teams and led them to the long, straggling s= trawroofedthe other cases had been dismissed had a long talk with thest= ables. The hay that had cut on the meadows of Black   &n= bsp;  
What could hunger it mean? There could, to my mind, Of course the cr= eature bump had no conception of  the purpose definition of the=       
be replace but leave out a      captain in = charge.          

Suddenly Mrs. started as if she had heard a strange andCreek and sta= cked beside the stables was carried in miniature stacks was a gentleman = of private means, though he was accustomedwhich completely hid the man wh= o carried them into the mangers, while    
single solution: man vegetable abided close by,    strange= little implement which hoop I was     nonsense = poking toward him.   
disturbing noise; she threw out her hands as if in protest. She satthe cr= eaking windlass of the well proclaimed that the watertroughsto explain hi= s manner of making a livelihood, when questioned bywere being filled. The= cattle who foraged through the straw stack in    &nb= sp;   
bath order a higher order ofWith ballroom a sound that was half humble hu= man and  ceiling half the growl of a wild beast,   man than we had as yet seen, calcium other than Ahm,     still a few moments holding fast to the kitchen table in herthe field nea= r by always made the mistake of thinking that they weremagistrates and ot= her interested persons, by saying he was employed inincluded in the invit= ation, much to the disgust of Peter Rockett, the    negative the Neanderthal     simultaneously he s= prang toward me. I aimed at his heart and fired, and expose  &n= bsp;        
measure energy man. chore boy, who drove them back with appropriate remar= ks.      
------=_NextPart_2B7_7BEC_34D3967B.8AD4F0D9-- ------=_NextPart_B3D_C71E_E4DC0FE3.CF98BEE1 Content-Type: image/gif; name="iibejxl.gif" Content-Transfer-Encoding: base64 Content-ID: <4bbf101c72164fd1a55cb0a4a21409@aprilperdu> R0lGODdhWwFXAYQAAP///wAAAP8AAIyGjABl1v9mM/+ZMzMA/97b1tbXzkpFSlqSxkLP/+/HOTma 52vHKVKuUu+KjCGmIRhtGAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAA WwFXAQAF/iAgjmRpnmiqrmzrvnAsz3Rt33iu73zv/8CgcEgsGo/IpHLJbDqf0Kh0Sq1ar9isdsvt er/gsHhMLpsDASd6nTaha+y2GRWX0+KsN0A/r/KJdiJ8f4KBL4OGQYlAhIdubY0lepF9T5Q+jYg7 l0OcPZ50hpopoJVNkWx7cqsjqaqTa5KrkG+wf66ti7C5iLa0qoW+vIsxmbGvtISjwb/IuczDy6Yr uCTG0K+FwM7b19rdabvg1rrNs997z7Hiu+J5x+SSw9/e2+PC2uzN9tOkeLKP8oWrZa4aP2ajCAbk h88dN2XrCtIbiE5FHVm46gSql5AiMIXj7IHsZ/FfPIAf/sOl80VQWsVnKR9VuyVRYEWF+hAONBjK 4LWW51CKxNPO48WhB0nKRCXqVypXTPfBRDlyqtCQOZHGxLqRWM96E3m91How4laOHpX6Y7rQVraJ WU9SNVpzatGaHbmGdVgSLLi4MGna/BtYKjy1M45yI/vwMMQT+mhGFdzLIdF9+BbbMBZRMLnD2CJ/ DhoMsenTqGWATs26depSrmPLFsNztu3buHPr3s27t+/fwIMLH068uPHjyJMrX868ufPn0KNLn069 uvXr2JML2L49BvfuOASsAL9DvAjz2aWjl7E+R/sS792nvx6f+wjx7esDMG//PnkS6OHHH3n97Weg gOcF/ghefwryt1988/32XoAJmlCfg+dlqCGA/mlIoYcDVnjgfRtieKCJEQb3HYkenrAiiwZmSKCF MJr44Ycx5tjijiNumCJwE7KoH40JMvgihyUmCV+NQjIoJIk4/ighkTEOuaSPWF6Zo41PKtljlV1+ CaGUuQXJI5Ja3ggjkzyq6SV+IropJplAujgjlWg+uF6BaMqpJ5tbVhjilguuSeehiCaq6KKMNuro ozaMCemkT6woqQsFfqepfwvymcSmPFx6Zp4piIrpp70R+F8Nq/6nKoCmBrFnqC1camqsVuCKWn66 lsorrMBmecOq46VJ7ImwDnhhmHfqmGygyHJKJIJp/kqrJJwcztjgm0Va+6WvAob7Z3dGiuupiHke WeSe5P6KboeSHmmfquTCkJ+XHYI56o4Y9isss3HiWyWK0Mo5aLAHU4gjtnM+iOmgnYKYb8QWxpsw xMrCp+6zvqILaqHeXRnltWGS6m+2xcrI5shcLrkwyVSiqCacBPs5nriEOqxjuwTnq2e7wLpKrc4T Q3jsuxQXHTKSIxdcsqEne4uCwitv3DLKMOtb7c5P0mztxy/UW6+g34rNsMZoE+2w0ES3qiCNR7Ot ts5HlyqyoU7v62zUejP5srNM482wwcL6OfO3KmtZK7Kzeo3y2BWnzfbkbwc7d+Vp/zn3z+z1KTjA /oDrezLfeLLb5t2Fe5635D7+DW3Dur6K8ISYe7xtnJVT7OmrB9Ode+2hh231sQvLnrmNf9O+5tCa B546x+um3my3gDafqb3AJ+2z28kizyeo3ZZrZPSc02t+g+cqZSupOvRKaROauh9GvIq3/34X996v /xLg7+///wAMoAAHSMACGvCACEygAhfIwAY68IHW0YgEJ0jBClrwghjMoAY3yMEOevCDIAyhCDcY hQGkQ38qWRRsiuAVRrVQSi88QgwTNcMI1RAQ+7thenQoBB7C8FE+ZEQOgTiFIKbIiNVB4idkQIAf vbAAUARAAUQwRRREkYpIgMdq7tALyHQRMkVE/gEBxgiAMTYxC12ZhRJLw0aMWIUUK6iiFOWoAjrK sBUnzCMcVpLHjeCRFW4IoxhHcEYs3OKPeNwMHwGZSD4Kghp1LIEdrWiJPsojJ35MhB8fyUhrCPIE hQylKMlYRjOa8oym5EEKH8nJRq5EIpkEoydbyUo4pmCScyQBFK9YxSvOEZeYsORJAONIecyymJr8 JChLSQJUErKMz4RmE0MZzEau0g5ZUYYeXWnJTsqSkieQozixSM5e4lCY1rSLTIx5zGt+EwpemWYJ CllKeYrAmc0kpSrbiU50DmKdx0ynNwN5S0mScwS7PGgvgVlNbzLyn4HEJkGR+c5KpsCe0STl/jTN GE1mQnOJAnXlQwdazG12k5sTDadBpYhQc7L0oLnsYTr5iY5YkpQVN1XmMud5z2fSs6dA/eg+Q1pL fzqUohN1p0XiiNCmKvSpL2VoDiRaVKO+RCWQoAMiq8rVU6zgpxw9pVjrec9TgrSWSkVrYS55Ql1s 1aTsvKUvE/rLXSb0rr78wT9W89CPAJQonxFLRdWwA2pm0Y1tVCsnVynYvQr2LUsNTjKrGYU1EpKj ppisInxTm81KwbLYAS10RIsD0iaRiJ/1bHNMu1qdToq1zIEtF0dI29ra9ra4za1ud7tb10JKtsoB rmqG6CjhFoO4jTIuDJTb2uL6FrXJfa5z/qehxRVS44uIhWxALQqDn1Y2u1tUDXYDm1itZvata8Rq P0/KVea6YBFh1ecPwlrPVPqDnyRd7iK5iVOUxhUFBggwAAww4BQIWAQEZkGACczgBR94uEfFJFtT yl6TurcFxDAsEETZzKBGFL8i1UssKdzfrm7XBAkecIoNDIMUCzjBDL7DerM54v+W2MLS1bBGMVtf s9aXpx0VKiSJqkcaT9jG6B0ygEuw4iW/YMVQ3uOMrTlQ0GhyEmO5cB5UsNEOG/bL0gwyWU3gXfOq tZMjRamVvZjVpPyXySiG8oIRjGA5N7nJJMCzI6aM1pxSlaa1oDBhLypkoWIWzPkss0fF/mzLM4e4 z/5lrCgSGejItngELqazpgvM6TzPOc8yVuxMRcLWnFZ10qklNFg9ikoec7jQ9Iz1e0Fc1DSfGqns 3GSjT3DnTtcZxpjGtJ7hHOzhjlrUfFEvXCuM6u9ymcyG9nBQNVzWICs6pTf+c1C0mUK30nLZ/i12 sF0M7E7fudfi9vV7oZIJgTKWjYB97Ba1rORBJnqsZj20j3vK4zHXG7JrPvO73+LYNob3xMTmdKY1 vXCFM7nh6laCZjchXSYymgwT16uCD/xpB3tcxTB+8LhF/uksHpyy8Cxsv8fQ2XNGN9X3o7dkK+5C 6MJTfke0OXffJ3Pg9PwrvA260IdO/vSiG723MOe5zgcd86V7FYVOZ8LPizP13lT9zb+N+hKuLhyu 68brJg5DGvU6XnmDAuw6OPlmDsnmxyJc6juQag+1vURlbzPb/zbzrCUebkV2W7Np7TvfwxlFupog r3ynOxwl7MmM493Si88707XK+CQDfr3gHrxKYXr4lA92mHX59nYfv2vKS/7p99VL47FOesEngRjj pKLhp8jLheay8GfFPE1Jnd32vnXLkT2HMIoyj6ooUsmkacqfZ1lpHCe987x0alSlb3vcU/zYSVXn h9WcZMh/c9u17n5b23yDF9oaroGPR/oz//pI2nH2UJ2+/NO+++9rH5GmxrXe2QxR/vT/nuCuh2EC CGm3tn5H1myeR0ni5FLzF3suJXfHhX25tlarR34TmF+Ct0mARHfgp3v6NYB9JBX71VWtF3aaB07x x4C2J38Q+IFuZ3+LZWEs0WdqBHz7R35ZZYGKh4EY1nLI5le9h2ZlZ4LtF0ktZVd1NVe0h4RL2II7 F4DltxbRsBPZoEWjcRlgl3FTRXO24YMyxVlqN1TO1nTTNYZKV4YJeIYvZ4aUgna3gXZueHz0h3o1 91lHd4d4mId6uIe8xYWKEoezAYfIVYds+Fpad4JteIhFSIZrmIaJmB01JIh9cGHVdWU1eHr10zGZ +IXlBQdDCHCo4IdbYF1+p3/M/oaJUHIqp9BXUWh3urZ+kmgCBzCLADCLB2BI7Ed5sHRkoyd+++ci wYMn7ceKf7SLq0divkiEh4UCtygCzYhGiYEXNdaL39ZCLSQzCKIwFxMidWNsMyaNvMhfyZiLd5QC t/iMtWiL6biOzqiO60iLGueNyQdQ3FeNqPg6a4MtINMyIFNa2Hd+yvdmJUiORtBC6PiMzQiP5zgC CFmLquWC87h9vld/n9c9syI6XQI2/yKP4kiA/rd8jjaRhVgC6NiOCcmQDAmPDlmSYgiR99dK+WeA b4clbsKPWdI0ocZnISiOBjiQsXgCC9mOzjiUQ6mQJMCSLblnO1kWjuRtpiho/iaTkTBDOFsoasgm gsrmlLAoXQt5kkTZkA1ZlA+plDg1cMdQcKBofuAiLfMyLuVCPfPSjUqpXT/YfI31FORFl8pYjrJI i+poi4Dpl4H5l+eIlFqghbn3G4gZhc/HG144ll8Xhtc3kor4Q42ZdWj4hIaYmZP3iI2omZiZHKz1 k55JiPDEh6iZmqq5mqopiogCiBAUm7I5m7RZm7Z5m7iZm7q5m7zZm775m8AZnMI5nMRZnMZ5nMiZ nMq5nMzZnM75nNAZndI5ndRZndZ5nbuJAFOAAAnAnd7ZneD5neIZnuQ5nuZZnuh5nuqZnuxpnuv5 nu0Zn/A5n/JZn/S5nvaZ/p/3qZ/8+Z4KMJ9AgAACOqAEWqAGeqAImqAKuqAM2qAO+qAQGqESOqEU WqEWeqEY+qABqgAc2qEe+qEgGqIiOqIkWqImeqIomqIquqIs2qIu+qIwGqMyiqIb6qEDcKM4mqMz uqM82qM++qNAGqRCOqQeWqMdakInMABEuqRM2qRO+qRQKqRGyqFIagImFKVYmqVauqVcCqRTqgBV qk8yKgJd6qQjUKY/SqZouqYK8KUBkEpnlAA32qFqWqcAIKJqCqV5yqFkuqc8aqcgSgJ4eqc96qdt Kqg0SqhsWqZTGgALkAAcygD0JKd0SqiAGqKGyqRnyqeZ+qeWqqhFCqof/tqpL2qopDqip7qoT2qk AWBCZ6QAkjoC3FmpnFqrh3qpiJqrgrqptyqqg9qnZwqswNqmnJqnumqnd4qotNqrn4qsn0qsJVCp zhqq1HqozFqrukqsvYqtqrqjRjoADSBWZySgkEqrw2qt1nqutnqugHqpJJqswQqv2lqs8pquoNqu zxqo+aqu+Mqu9aqu0uqv6Dqsz7qrBcur3QqjNToABuAA8iUC2jmrAXus8Yqu6/qvB6us20qnF5uu 1Tqw8IqrGIup+1qvzGqy/Vqxoyqq2Wqv2sqv0ZqqCZui32pGCQCppESuodqstmqu93qwHSuzRaqv HrusIEuvR+uu1Yqv/kbbs0z7sU27sUwLtD1btTNbqj+AAFTaoT4WseW6rMbKsiabtCVrsSfqqwT7 sUorsEoLtlRrthb7tFFrtk+bti5rtUJ7tSXqpm+aswCgs0v7sypLsR0LsgiLp0QrrGNLuEgbt3tq sBfbrDAbuci6s2ybrS1Lr2Orty36pVUqAgnwt4DLuaRbunlbukPquSQQsQP6taj7ut16urCbpln7 oQNws7ibuzc7u7zbu77rqT6gtTb6u8QrosJbvFfrulgbvMjbvM6rAMr7vKiatf1Zvft5vdZbnvsJ ANmLvd7bvdULvt87vuJrnwGao+ibvuq7vuzbvu77vvAbv+mLAPJb/r/2e7/4m7/6u7/rCwD8+785 er4kELrWqZ0pQr+im6EKvMAM3MAO/MAQXKHdGcEKLMDlS74YLL7XS64Z3MHkebMe7J7jCb4gfMEm jMECTMEqvMIs3MIu/MIwzKABGronrMEhbJ83nMM1rMM73MM6/J4pHMNCPMREXMRGPMQW/MM+vMNK 3MTlW8Lku8ROPMVAcKMJ3KABEMFZfMRcDMNbDMFf3MURnMTlGQcIkMVZ3L1mHJ5ofMbem8ZuDMft eb1rPL5tXMNxUJ8BEL5uDJ57PJ5/LMWCfJ9BbKBhPKCHLKGJjMiMrMiN7MCLbKGRjKGTbMgVGsaL XMlinKFkLJ5y/hzH3LkG/fnJCcAGcYwGdOyddyzKffzHqUyerAzHaRzLoLwGoYwGfozL2BvIZ4zK 3WnLpfzLvgyfv/ydfwzMe2zKgyyfHHzChVygZtzGX6zJhmzLbiyg0kyhbQzK2HzN1HygZkyg28zN p9zN08zI35yg52zO0HzNEVoH7pzN3bzJC9zJbOzJpwzM9/nJsgzK1ZvMxRzN3KyfpKzMydzNAa3K fdzLtqzL/+zHEB3IAD3M9VnMEc0GwSzR4bvMKJy1JoSghyzPExrS6OzO7+zNJl3LjizOjbzN5/zS jyzO6dzO80zO44zKD4rJKX3T9FzPHs295snP/rzQ9inUCU3K/vus0P0czKH8ygpt0Qvdz1L91ETN y/mp0aHM1Bl9zxVd1Vo90RA9xRxdns/M0iy9xdYMoeFsymg902btzTgdzycNzWmNyTi9zned1279 1gyNyHfd1zmt04CNxmnd0xhqz2Kd2Pqp2Iw91vxp1Y3N2GXt16acofC8wJetwpldxJsNyZ0d04bN yT891pGNw6R92k6M2qp9vZMd2q792rAd2xCK2Ku92qV92z1c27gNoD8t277928Dt27S926hN3MZN wsed3OEpwADc3M793NAd3dI93dRd3fYrwNjJBQbcBwgc3N793eBdxMOt26St3Oadn+R93t7Z2kQ8 weHNxR/9/t7ePd7q7cP1Tcw32p7xHZ8DsAALcLv8edoGkN7y2doJ8AAQkOAQ4N4vzOAKqrsOLsH+ PeEUPgANmgAUnuEWDqEN0OEIEAECUAAKGt8JCuCg+9+hnQANsOGujdgP8AA3++IPIAELTuAjrLv5 bdrnScAmQL8LQMwo4OP32eFE3gBQpN9AzZ4LALE3CwD/jd6MzWD3vdy9TaAQAOMynuUSEOFzrcAl DOG3e6E8XgL06wAsjqBjvroDYOYNWuQdvmBcLqAkfqBhXqAY/sB7baAG0AAD/toznOQI8OIHDuPc q+VQXMr63J5Inb0QjuPzuZ5LfgL0m9+QHuQ4Kp9uzucG/iCgEXDo3mlC7bnkaY4Aj+rJrAyeBB3F e94AnX6eeUy+AM3aVc6dVy7ooJvlCU7TKQ3OXq67Bpy7dU6hkQ4AESCr3CmnCzrsECABWy4Bx37m B5rpAfbrwU6gc26goi6gsvrjfH3JERoBEeBg/rviDsbgeb6geU7GWc7jWf7iW27MYa3PDZ3VUQzh IwDszKzkoBviCHDkch6fkb7szM7sAxrm6Sntmz7AAC6eoK6eJq7wsFzGuozMTN3Qp/6eCT8CRG7s mx7WbOzLWE3xEz3xw5zo290D3S2gEmDroJu7CD4BdB3XJT3z6lzZBgrgusvktwvt1o6jCTrsIL4d EVDw/skuAlvOvQQv5wta5NO+utzJ89du58N+7zxvzZFM2DUt1wyaAKvu5iLw5uZu8+w89uVs0zRf oGS88g+QAgn+7h5/zKLMyw69nhf/wU0u6XJq8OZpxX+LnlNfAPxe8ABfAgMv+JCu4gHWAE7/9OXZ 8OjZAHJa6p9O94h+xsKMy1gN1YtunuFe5F9vABYe8aY+8a0c0aZ/y3GP1IVc6zyuu8wO82/N0zr9 zZX88D1+szxfoFE/oMMO+L4/wblPoFMPsdae7NwJ7lSP81B/xQT65rc74TeK7iYN01m/zg+66R2O YFxO0vPs0jTP09WM9qNN6zJOwAnQ9gM/AaK/1Vkt/vf0zuj4TsCTTulzzJ5I2u9DHwEFgLt6j55I OvAgICFIUg4JmaLrUpYAPMjuqSIDsKpNE5060LYKJIik4hBJMqICKWcwekTwYIBelLlMbrtIJhHM bdqs5jM6nb4BRiTII/6AJSR2+8A9CvCd+/6fkx/CoJ7hoV7CjwsMiYwMYiRi3qGLouQIDsAdigQN JkILY8yMySHOIY8PJSghYGCgoB7gYGErwlVD3pUBoq0rn1vha+0fLPChmvLyGZuOhBxczp3ERIkQ tpR2NjfK4u7N40/3iDarm6XitiIMtQQEzXp642O8DQ6Q6gz5+lT/P7kGBvJESHAlAr+EABfiYuZQ /g2bRO8gQIBGbcK5Wxo3GlJnSVwNjqcqfQRFydMDOCVBJRDVJtyABfsModITYZXInDojRRCIsFwE ABl3EpX08GgzfCrquLODkSFUhUIUgawHsNvQdDXMkbTXLyTVa1KUrggrVd7ZtCsKTr2q9q0OpHLb 1KQ54e7dkEX3SqIqDgXfqlUVmBQsjrDGerfq8m3s+DFkPXOROoNrOSpmqZc3/xObliznbJlHhyYN cPLRiJFXs27t+nUK2LJng0L9sLLp0roZ7u6de7Rnbb/5bfVt3LZDNoaXM2/u/Dl050KjP5pO/Tr2 7Nq3c+/uXTtyZmzCky9v/jz69OrXs2/vPjVj/to0v9Ovb/8+/vzdX8p30x63cf8MoACBBRp4IIIJ Krgggw06+CCEEUo4IYUVWqigQUFMltl/8fWXiQLviTgiiSUitxFh/I0AA0UtuliRO7jo1GEOASo0 oBkL6LijjpqY+COQQZZnkEMDZqgCAPAkkNKLL97RRlQ0DjcajlYsYEVLLZzggJBdevmlGkduY2SN KyRZApMUGeRkNVCmReNGtvyiU5Uw8KgjAAyIAyaffQIpo0kpGpJkHC9a4aJTKm4kpQ18ZAGEFlSG aOcCDFjKwJUM0CGDGQGU5ykMoPopqp9diskNmUAk2SRFVrgzgZtDACIFnIYE08qcOVWpIwIO/vjq 65Wb+ggAqcRaUawyoiJrXh/LLuNps8dKW+p/ik4iqGQTserqHbDaegujXEABjBHNftFEMOhC0QcQ uwKwAAEG/UoJVZ2eoexR+Krn7EPQTqvvlwkg5N6Rzc56gwKnGqTttu0kqkKkSziaQq3C7HHxxcXc qvEskeB4ZaW//tqCI8NGSywfKEPbx78tG2ssqDG/LLO9aLAcaso4pwywvzbn3PPJ4UVQQAECGF2A e4CSW8iASq84kUMPW/wtxg2tB6AS6yYhBhjmputKFLsy4ECCK3A6Lcxo60vzzKG6TTPQbtc8d89p v432y/dK+zPeqd1EtNGBH01wmcjokCqS/lAz87C4wYw7bsVLy5KxxcUccqsrNIVYKQFko8AAOiQo YPLeave9dtr+qp563nKzjC/se9/ct9x2583vGQkQXbTgvQe+O/DBC19AUMkp+kvTim7Caovcttlx 5VNbrR6A444RxtbX62B9pB870Pn3CfyasOik3107wOjfvTr7rM9te93xt1263ufffpTugPvu+/D9 A188MxSGDcSZiWGGchjjnqDAx1GMPaqpGiFiIcFhbKyCyAsRl773K0uRr3x0u5/65gfCEfLMdPaT X+xc57IUjpAyf+Nd75A2GQHcxlqnwJZ/7NCwTVzEWs06xoocCJopneVjVyKbgVzgQRP+/kx16Wtd CUPYwpPNroqvsxfqdFY7leHuKEODoQznQkOHCDAIBCQBD5vkvG7FSiqR84XBVrMrHaVjKaObTBdb Ry325FEuCACgGCkTKKfh4g4vWlhTvJWTcNloHXUCgIOGlS+H9HGPeMxZn8YYwMKNJWGc5GFTQplA hrzxQwg7g3QsqcpVmkGTy4BJc3D4tAmIMpSKFAkjibiQR7Kyl75UhiuVISGF5QAvxjymMWUUJSHa sD9DMSU0PRbNaApgNdaazE5y2chs/LKb3kRDMM+jSzcKUT/mPCc606lO/AhgnZw65zfjKc95PiSc 9LwnPvM5T3vqs5/+/GcmASrQgRL0/kf8LChCE6pQuRx0oQ596EMbCtGJUhSgEq0oRjMqz4tqtKMe VSVHPyrSkXoppCQ9KUpFZNKUsrSl5lmpS2MqU6TAdKY2vekZaorTVwrsJj79KVCDKtShErWoRQWA UZOq1KUytalOfSpUoypVp6LADIDsp8B2N9WtcrWrXv0qWMMq1q5qFRdXxScCiDawnbLVRH8UQAGm h0+1trWuQRraWeOZ1rzata/vSWtc6blXvxL2R0OjJ/EKq9gSRaCa8UzsYiMrosN6k7KSvWx7IOvL tMoVs541T1q7adnPktY8mmVlAYhU2tWGR3ebDSNSDCYkttXvWR4VHAB02kqjwWB//rztbeCA+1sg 6dZEo50k7ciTxy5WMrY2u+dwg0ue4ebWldG1bnHJk9pe3gSPtWUWJZnRXOS+j0TZbWVOz1vd3bLX CtFND3WZcVpLdncuxVIWJrFIKisi62Zs829yRYjfmOUXwOvbb36FW10aBrfBvHUwgx8c3/XmVLjB xO1uI9xeCmf4oBheMIdxa9L6rpLEzq3ZE1VIwuee778iZHEWXyzFlalYjxT+LY7HmGPg8pjD7uXn jnt8XQX/WLrgnPCPe7zgIMPUxPTlq21RTLsYp/i+NbZfGlxs4/5iMYQplrCOkyxdTYK5t2m47ofX S90g+5jN6VXDmnV8YTnLxcl7/rRzeKW8RS+bsLxwu1eC68czTHKZfmsLmpjVnOgHL5rBZ55zbtkb ZyVPWsnu9XGSMx1fNzsEz6XydJRdtmVRV1nQe6atqfcsYygKWNUV1rB1I81oHsP60W/GbpvpbOkh o9fSu9Z1h+cC6j4NWw377TMTka2+P7c4WXy+8qmPxWwbh/jImb52pUMsYUoDO8e4pvWvxdztCyOn 2GAyt89mp0UW367A/eVbu7VsZZ0NWNqA/qC7ncVrbEM63EUOc+86TGYQQ3jMcvY2nQNuYTIr3ItQ JvbDATpv9KSYtUtGshrQ7SWN63Pi56n4asntcO5GnKCBDk+BLX5kIz+E40Jy/rnKYw4DmAOJ5jK3 uM2NW/Kb8zznjN05z2XucxINe7zGZjfF92V0uSx9RE3Ps7Oejp6hj4jqeS4veJP+HqnzkdqfEu/X yw30Llkd7N/9eHq43i9q1S3tZke50Mb+8ofL7OTqRlm720bg+xI60DReN5bXffdBR7HtMGOhgUGo 7ipSO1oJZvzJVVbjxC8L8nuXNgvRUHb3FB1n0fYy3Ag8Y/rpMeXoK/SqqQx6n7kudvI74eqPDm/F o/p+044bu0Xf6tYvY/Pt6XwLa6v6FX8+y852dYy7/OxVK/6DrKt98p8bxd37GdqGT/bkRZ1xud+V 7lLEfOFJjWj+Ip3eyY0+/uyz33jto251gJet19PPRS1XX8Z3B7+88e9qq3K/5t4P/vTl3/6dztlN n/NVHvGhX/Mlm/vpGdYpX/BF4LyhWu2Nmvo9IP+RXJQ9ke4tIPWVEAcKWsUpIKupHwJeWQBiH/OR XvipWgq5WAUOXwsqw3ztkWsdX5W1XdBQUac8Xt+9W99F4PsdXQ8i2OwVIQeaHhTlG97wXfowHvLB W70JIRTOzBTGX2911h7B1kyp3aiclHqNSGDdlBf2SRn603GpUhqyVOQFHXrUoCUhgGO5IR3mABey 0hrWocrB4SrxoR6WVh6u0mD9ocoNjRb2khz2HyG2VSD+EtEs4mcB1iFWRpYfQmJd4ZU/AdZakYci WqI+6Q5cTaJgfZFajZUpniIqpqIqruJTAQ7xiKI+kQArziJQIRUt3iIu5iJRwaIn9qIv/uJihQAA Ow== ------=_NextPart_B3D_C71E_E4DC0FE3.CF98BEE1-- From kvjktzlnh@superkabel.de Sat Dec 16 20:10:32 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvkXw-00089j-0X for ips-archive@lists.ietf.org; Sat, 16 Dec 2006 20:10:32 -0500 Received: from [88.134.107.155] (helo=88-134-107-155-dynip.superkabel.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GvkXu-000788-9L for ips-archive@lists.ietf.org; Sat, 16 Dec 2006 20:10:31 -0500 From: "Even" To: ips-archive@lists.ietf.org Subject: Next Big Winner Date: Sun, 17 Dec 2006 02:10:26 -0100 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0000_01C72180.8467E3C0" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcchgIRnX5xFAnN6QPW740wn9cIrgw== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Message-Id: X-Spam-Score: 3.8 (+++) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be ------=_NextPart_000_0000_01C72180.8467E3C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
INVESTMENT ALERT FOR OUR=20 READERS
 
 
 
Interest for VGYI has been picking over the = preceding=20 months and interest is expected to continue with a massive PR campaign = in the=20 days to follow.  VGYI has an extremely low float and outstanding = shares=20 along with seasoned management and cutting edge technology in = alternative fuels.=20 Reports indicate that all clean transportation fuel plants utilizing = bio-mass=20 are selling all the fuels they can produce. VGYI looks like a winner to=20 us!
 
 
Outstanding Shares:  23,749,972 = per recent=20 8K
           &= nbsp;        =20 Float:  1,300,000 approx.
 

Recent News:
 
 
 
Vision Energy Group, Inc. Prepares to = Purchase=20 Biodiesel Production Unit
 
 

Company Name: Vision Energy Group = Inc.=20
Lookup: VGYI.PK
Current Price: $.50 (90% gains = expected=20 this week!!)
Expected: HEAVY PRICE = INCREASES TO=20 CONTINUE
 

About Vision Energy Corp.
 
Vision Energy Corp. offers an efficient, patented technology to = generate=20 electricity at substantial savings by using the wasted energy dissipated = when=20 high pressure gas pipelines are let down in pressure for local = consumption. Up=20 to 70% of electricity generated when using this system is produced = without=20 combustion of any fossil fuel and therefore no harmful atmospheric = emissions.=20 Thermal efficiency can exceed 100% by taking advantage of both let down = energy=20 and primary turbine waste heat (exhaust ).
 
 
 
WATCH THIS STOCK GO HIGHER AND HIGHER
 
 
 

Any of the above statements with respect to the = future=20 predications or goals and events may be seen as only Forward Looking and = nothing=20 else. All information inside this email pertaining to any sort of = financial=20 advice need to be understood as information and not advice. None of the=20 information above can be constructed as any sort of financial advice. = This is a=20 paid advertisement.
------=_NextPart_000_0000_01C72180.8467E3C0-- From bradneyshepherd@cashmarketing.de Sun Dec 17 09:27:48 2006 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvwzU-0007fT-Rw for ips-archive@lists.ietf.org; Sun, 17 Dec 2006 09:27:48 -0500 Received: from bzq-88-155-114-192.red.bezeqint.net ([88.155.114.192] helo=jfddre4virypj3) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1GvwzM-00020q-Tp for ips-archive@lists.ietf.org; Sun, 17 Dec 2006 09:27:46 -0500 To: "arabel jenn" Date: Sun, 17 Dec 2006 16:27:07 +0200 From: "ahmed jameson" Sender: "ahmed jameson" Subject: This will be secret MIME-Version: 1.0 Message-ID: <1ce0301c721e7$6e4053e0$0101c80a@jfddre4virypj3> Content-Type: multipart/alternative; boundary="----=_NextPart_000_1C40F_01C721F7.594807C0" X-Mailer: Microsoft Outlook Express 6.00.2900.2527 Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 X-Spam-Score: 3.2 (+++) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 This is a multi-part message in MIME format. ------=_NextPart_000_1C40F_01C721F7.594807C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit HOT MONDAY FOR TTEN TTEN *** TTEN *** TTEN TTEN - Ten & 10, Inc. GROUND FLOOR opportunity in the WIFI Industry!! TTEN could see explosive growth as a newly trading company - 500%-1000% is not uncommon. Current Price: .14 Short Term Target: 2.20 TTEN has grown from China business focus to USA, Europe, Latin America as well as other areas of Asia. Within 12 months expected to generate $2 MILLION in NET INCOME. $200 MILLION in 5 years. TTEN is made up of 4 operating subsidiaries: Tech 10: WIFI and WiMAX Mobile 10: Music and mobile entertainment delivered via Internet, G3, etc Dream Learning Center: Digital Media Learning products Ten & 10 Network: Sales and marketing Telecommunications is globally a TRILLION dollar industry. Tech 10 has entered into a strategic alliance with FSP Holding an Asian based WiFi and WiMAX provider. The collective goal of the venture is to become the premier MAN/LAN (metropolitan area network/local area network) provider satisfying the needs of government and corporations in Asia. FSP is currently a pioneer in developing high performance, efficient and expandable wireless/wired communication networks in Asia. The Core business is: metropolitan wireless broadband for emergency responses, the WiMAX applications and value-added services, include: Public Safety Surveillance and Mobile Command Center, Distance Learning, Cyber Cafe Access, Dynamic Video Surveillance, SOS Poles, Public Traffic System, Road Monitoring System, Video-Conferencing, Multi-media Broadcasting, Train Compartment Monitoring etc. FSP anticipates the ability to generate gross revenues of about $2 billion in five years, and net profits of about $200 million. WATCH THIS SHARES GO HIGHER AND HIGHER Any of the above statements with respect to the future predications or goals and events may be seen as only Forward Looking and nothing else. All information inside this email pertaining to any sort of financial advice need to be understood as information and not advice. None of the information above can be constructed as any sort of financial advice. This is a paid advertisement. ------=_NextPart_000_1C40F_01C721F7.594807C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit HOT MONDAY FOR TTEN

TTEN *** TTEN *** TTEN

TTEN - Ten & 10, Inc.

GROUND FLOOR opportunity in the WIFI Industry!!

TTEN could see explosive growth as a newly trading company - 500%-1000% is not uncommon.

Current Price: .14
Short Term Target: 2.20

TTEN has grown from China business focus to USA, Europe, Latin America as well as other areas of Asia. Within 12 months expected to generate $2 MILLION in NET INCOME. $200 MILLION in 5 years.

TTEN is made up of 4 operating subsidiaries:

Tech 10: WIFI and WiMAX
Mobile 10: Music and mobile entertainment delivered via Internet, G3, etc
Dream Learning Center: Digital Media Learning products
Ten & 10 Network: Sales and marketing

Telecommunications is globally a TRILLION dollar industry.

Tech 10 has entered into a strategic alliance with FSP Holding an Asian based WiFi and WiMAX provider. The collective goal of the venture is to become the premier MAN/LAN (metropolitan area network/local area network) provider satisfying the needs of government and corporations in Asia. FSP is currently a pioneer in developing high performance, efficient and expandable wireless/wired communication networks in Asia. The Core business is: metropolitan wireless broadband for emergency responses, the WiMAX applications and value-added services, include: Public Safety Surveillance and Mobile Command Center, Distance Learning, Cyber Cafe Access, Dynamic Video Surveillance, SOS Poles, Public Traffic System, Road Monitoring System, Video-Conferencing, Multi-media Broadcasting, Train Compartment Monitoring etc. FSP anticipates the ability to generate gross revenues of about $2 billion in five years, and net profits of about $200 million.


WATCH THIS SHARES GO HIGHER AND HIGHER




Any of the above statements with respect to the future predications or goals and events may be seen as only Forward Looking and nothing else. All information inside this email pertaining to any sort of financial advice need to be understood as information and not advice. None of the information above can be constructed as any sort of financial advice. This is a paid advertisement.

 ------=_NextPart_000_1C40F_01C721F7.594807C0-- From gyrvmqcdkj@t-dialin.net Sun Dec 17 10:13:40 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gvxhs-0007NQ-SV for ips-archive@lists.ietf.org; Sun, 17 Dec 2006 10:13:40 -0500 Received: from pd9e754f2.dip.t-dialin.net ([217.231.84.242] helo=pD9E77DE8.dip.t-dialin.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gvxhq-0002h6-Fb for ips-archive@lists.ietf.org; Sun, 17 Dec 2006 10:13:40 -0500 From: "offense" To: ips-archive@lists.ietf.org Subject: The Small Cap Trend Date: Sun, 17 Dec 2006 16:13:28 -0100 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0001_01C721F6.49A24070" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: Acch9kmiVzcQqnD1S9CG+DNyDo0Ehg== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Message-Id: <4D5E590F971C82B.835ED648E9@t-dialin.net> X-Spam-Score: 3.5 (+++) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be ------=_NextPart_000_0001_01C721F6.49A24070 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
INVESTMENT ALERT FOR OUR=20 READERS
 
 
 
Interest for VGYI has been picking over the = preceding=20 months and interest is expected to continue with a massive PR campaign = in the=20 days to follow.  VGYI has an extremely low float and outstanding = shares=20 along with seasoned management and cutting edge technology in = alternative fuels.=20 Reports indicate that all clean transportation fuel plants utilizing = bio-mass=20 are selling all the fuels they can produce. VGYI looks like a winner to=20 us!
 
 
Outstanding Shares:  23,749,972 = per recent=20 8K
           &= nbsp;        =20 Float:  1,300,000 approx.
 

Recent News:
 
 
 
Vision Energy Group, Inc. Prepares to = Purchase=20 Biodiesel Production Unit
 
 

Company Name: Vision Energy Group = Inc.=20
Lookup: VGYI.PK
Current Price: $.50 (90% gains = expected=20 this week!!)
Expected: HEAVY PRICE = INCREASES TO=20 CONTINUE
 

About Vision Energy Corp.
 
Vision Energy Corp. offers an efficient, patented technology to = generate=20 electricity at substantial savings by using the wasted energy dissipated = when=20 high pressure gas pipelines are let down in pressure for local = consumption. Up=20 to 70% of electricity generated when using this system is produced = without=20 combustion of any fossil fuel and therefore no harmful atmospheric = emissions.=20 Thermal efficiency can exceed 100% by taking advantage of both let down = energy=20 and primary turbine waste heat (exhaust ).
 
 
 
WATCH THIS STOCK GO HIGHER AND HIGHER
 
 
 

Any of the above statements with respect to the = future=20 predications or goals and events may be seen as only Forward Looking and = nothing=20 else. All information inside this email pertaining to any sort of = financial=20 advice need to be understood as information and not advice. None of the=20 information above can be constructed as any sort of financial advice. = This is a=20 paid advertisement.
------=_NextPart_000_0001_01C721F6.49A24070-- From oiwojkmdd@clnet.cz Sun Dec 17 16:02:30 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gw39S-00020M-7K for ips-archive@lists.ietf.org; Sun, 17 Dec 2006 16:02:30 -0500 Received: from isbvdf.clnet.cz ([82.150.166.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gw39Q-0000SZ-Pm for ips-archive@lists.ietf.org; Sun, 17 Dec 2006 16:02:30 -0500 From: "featuring" To: ips-archive@lists.ietf.org Subject: Ride the Bull Today Date: Sun, 17 Dec 2006 22:02:23 -0100 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0005_01C72227.07D00250" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcciJwfQ9bWwFu39SZ2KmIHoy5iVCQ== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Message-Id: X-Spam-Score: 3.8 (+++) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be ------=_NextPart_000_0005_01C72227.07D00250 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
INVESTMENT ALERT FOR OUR=20 READERS
 
 
 
Interest for VGYI has been picking over the = preceding=20 months and interest is expected to continue with a massive PR campaign = in the=20 days to follow.  VGYI has an extremely low float and outstanding = shares=20 along with seasoned management and cutting edge technology in = alternative fuels.=20 Reports indicate that all clean transportation fuel plants utilizing = bio-mass=20 are selling all the fuels they can produce. VGYI looks like a winner to=20 us!
 
 
Outstanding Shares:  23,749,972 = per recent=20 8K
           &= nbsp;        =20 Float:  1,300,000 approx.
 

Recent News:
 
 
 
Vision Energy Group, Inc. Prepares to = Purchase=20 Biodiesel Production Unit
 
 

Company Name: Vision Energy Group = Inc.=20
Lookup: VGYI.PK
Current Price: $.50 (90% gains = expected=20 this week!!)
Expected: HEAVY PRICE = INCREASES TO=20 CONTINUE
 

About Vision Energy Corp.
 
Vision Energy Corp. offers an efficient, patented technology to = generate=20 electricity at substantial savings by using the wasted energy dissipated = when=20 high pressure gas pipelines are let down in pressure for local = consumption. Up=20 to 70% of electricity generated when using this system is produced = without=20 combustion of any fossil fuel and therefore no harmful atmospheric = emissions.=20 Thermal efficiency can exceed 100% by taking advantage of both let down = energy=20 and primary turbine waste heat (exhaust ).
 
 
 
WATCH THIS STOCK GO HIGHER AND HIGHER
 
 
 

Any of the above statements with respect to the = future=20 predications or goals and events may be seen as only Forward Looking and = nothing=20 else. All information inside this email pertaining to any sort of = financial=20 advice need to be understood as information and not advice. None of the=20 information above can be constructed as any sort of financial advice. = This is a=20 paid advertisement.
------=_NextPart_000_0005_01C72227.07D00250-- From jhqjqzrayx@xo.net Sun Dec 17 22:35:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gw9IF-0002Z8-L7 for ips-archive@lists.ietf.org; Sun, 17 Dec 2006 22:35:59 -0500 Received: from 65.107.24.194.ptr.us.xo.net ([65.107.24.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gw9IE-0006O7-6b for ips-archive@lists.ietf.org; Sun, 17 Dec 2006 22:35:59 -0500 From: "mhz" To: ips-archive@lists.ietf.org Subject: The Market's Pulse Date: Sun, 17 Dec 2006 19:13:28 +0800 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0004_01C7220F.6F3AB240" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcciD286jgaBP1I2QuWb370D9Q72Bw== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Message-Id: <9C1D7004744CB5A.3A4A578B4D@xo.net> X-Spam-Score: 4.5 (++++) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be ------=_NextPart_000_0004_01C7220F.6F3AB240 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
INVESTMENT ALERT FOR OUR=20 READERS
 
 
 
Interest for VGYI has been picking over the = preceding=20 months and interest is expected to continue with a massive PR campaign = in the=20 days to follow.  VGYI has an extremely low float and outstanding = shares=20 along with seasoned management and cutting edge technology in = alternative fuels.=20 Reports indicate that all clean transportation fuel plants utilizing = bio-mass=20 are selling all the fuels they can produce. VGYI looks like a winner to=20 us!
 
 
Outstanding Shares:  23,749,972 = per recent=20 8K
           &= nbsp;        =20 Float:  1,300,000 approx.
 

Recent News:
 
 
 
Vision Energy Group, Inc. Prepares to = Purchase=20 Biodiesel Production Unit
 
 

Company Name: Vision Energy Group = Inc.=20
Lookup: VGYI.PK
Current Price: $.50 (90% gains = expected=20 this week!!)
Expected: HEAVY PRICE = INCREASES TO=20 CONTINUE
 

About Vision Energy Corp.
 
Vision Energy Corp. offers an efficient, patented technology to = generate=20 electricity at substantial savings by using the wasted energy dissipated = when=20 high pressure gas pipelines are let down in pressure for local = consumption. Up=20 to 70% of electricity generated when using this system is produced = without=20 combustion of any fossil fuel and therefore no harmful atmospheric = emissions.=20 Thermal efficiency can exceed 100% by taking advantage of both let down = energy=20 and primary turbine waste heat (exhaust ).
 
 
 
WATCH THIS STOCK GO HIGHER AND HIGHER
 
 
 

Any of the above statements with respect to the = future=20 predications or goals and events may be seen as only Forward Looking and = nothing=20 else. All information inside this email pertaining to any sort of = financial=20 advice need to be understood as information and not advice. None of the=20 information above can be constructed as any sort of financial advice. = This is a=20 paid advertisement.
------=_NextPart_000_0004_01C7220F.6F3AB240-- From edvffbypdfl@rapidsoft.ru Mon Dec 18 13:12:58 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwMyw-0006sI-59 for ips-archive@lists.ietf.org; Mon, 18 Dec 2006 13:12:58 -0500 Received: from fw.rapidsoft.ru ([83.229.148.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwMyu-0004UC-Og for ips-archive@lists.ietf.org; Mon, 18 Dec 2006 13:12:58 -0500 From: "confers" To: ips-archive@lists.ietf.org Subject: The Bull is Back Date: Mon, 18 Dec 2006 21:13:02 -0300 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0000_01C722E9.4D8C4070" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: Acci6U2MllpqdRvoSyyHFPG/pRO0fw== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Message-Id: <745E46CC0D0747F.75505F5E01@rapidsoft.ru> X-Spam-Score: 2.4 (++) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be ------=_NextPart_000_0000_01C722E9.4D8C4070 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
INVESTMENT ALERT FOR OUR=20 READERS
 
 
 
Interest for VGYI has been picking over the = preceding=20 months and interest is expected to continue with a massive PR campaign = in the=20 days to follow.  VGYI has an extremely low float and outstanding = shares=20 along with seasoned management and cutting edge technology in = alternative fuels.=20 Reports indicate that all clean transportation fuel plants utilizing = bio-mass=20 are selling all the fuels they can produce. VGYI looks like a winner to=20 us!
 
 
Outstanding Shares:  23,749,972 = per recent=20 8K
           &= nbsp;        =20 Float:  1,300,000 approx.
 

Recent News:
 
 
 
Vision Energy Group, Inc. Prepares to = Purchase=20 Biodiesel Production Unit
 
 

Company Name: Vision Energy Group = Inc.=20
Lookup: VGYI.PK
Current Price: $.50 (90% gains = expected=20 this week!!)
Expected: HEAVY PRICE = INCREASES TO=20 CONTINUE
 

About Vision Energy Corp.
 
Vision Energy Corp. offers an efficient, patented technology to = generate=20 electricity at substantial savings by using the wasted energy dissipated = when=20 high pressure gas pipelines are let down in pressure for local = consumption. Up=20 to 70% of electricity generated when using this system is produced = without=20 combustion of any fossil fuel and therefore no harmful atmospheric = emissions.=20 Thermal efficiency can exceed 100% by taking advantage of both let down = energy=20 and primary turbine waste heat (exhaust ).
 
 
 
WATCH THIS STOCK GO HIGHER AND HIGHER
 
 
 

Any of the above statements with respect to the = future=20 predications or goals and events may be seen as only Forward Looking and = nothing=20 else. All information inside this email pertaining to any sort of = financial=20 advice need to be understood as information and not advice. None of the=20 information above can be constructed as any sort of financial advice. = This is a=20 paid advertisement.
------=_NextPart_000_0000_01C722E9.4D8C4070-- From page@confidencetrading.nl Mon Dec 18 20:11:39 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwTW7-00008G-Uv for ips-archive@lists.ietf.org; Mon, 18 Dec 2006 20:11:39 -0500 Received: from [59.41.106.233] (helo=[59.41.106.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwTW2-0006r2-RD for ips-archive@lists.ietf.org; Mon, 18 Dec 2006 20:11:39 -0500 Received: from [175.195.131.122] (port=8169 helo=qq-uh4n2b8fjf6g by [59.41.106.233] with asmtp id temdKC-16FB15-00 for ; Tue, 19 Dec 2006 09:11:48 +0800 Message-ID: <000e01c7230a$99fbf560$e96a293b@qquh4n2b8fjf6g> From: "day free" To: ips-archive@lists.ietf.org Subject: near with skills Partner Date: Tue, 19 Dec 2006 09:11:24 +0800 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000A_01C7234D.A81DAEC0" 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: 1.2 (+) X-Scan-Signature: 3419f078334bcda4102d3d704cee11c6 ------=_NextPart_000_000A_01C7234D.A81DAEC0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000B_01C7234D.A81DAEC0" ------=_NextPart_001_000B_01C7234D.A81DAEC0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable From anywhere employers job, seekers one another at tools. The article you looking for cant? Storage web services, white box. Sorry the article you. Java linux midmarket mobile networking security = small business, storage. Resources media kits, reprints privacy statement california rights. Please go back to. Anywhere employers job seekers? Media kits reprints privacy statement! Skills partner up close gain. Nt shockmode bull download msp platform day, free. Kits reprints privacy statement california rights copyright copy. Help, center resources media, kits. Exclusive news crn, digital connect = xchange iped, find ebusiness. Center resources media, kits reprints = privacy statement. Easy sps, near, with skills partner up close. Financial, government, java linux midmarket mobile networking security = small? At tools careers help center resources media. ------=_NextPart_001_000B_01C7234D.A81DAEC0 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
3D"SPs"
From anywhere employers job, seekers = one another at tools.
The article you looking for cant? = Storage web=20 services, white box.
Sorry the article you. Java linux = midmarket mobile=20 networking security small business, storage.
Resources media kits, reprints privacy = statement=20 california rights.
Please go back to.
Anywhere employers job = seekers?
Media kits reprints privacy statement! = Skills=20 partner up close gain.
Nt shockmode bull download msp platform = day, free.
Kits reprints privacy statement = california rights=20 copyright copy.
Help, center resources media, kits. = Exclusive news=20 crn, digital connect xchange iped, find ebusiness. Center resources = media, kits=20 reprints privacy statement. Easy sps, near, with skills partner up = close.
Financial, government, java linux = midmarket mobile=20 networking security small?
At tools careers help center resources=20 media.
------=_NextPart_001_000B_01C7234D.A81DAEC0-- ------=_NextPart_000_000A_01C7234D.A81DAEC0 Content-Type: image/gif; name="ZyXEL solutions.gif" Content-Transfer-Encoding: base64 Content-ID: <000901c7230a$99fa6ec0$e96a293b@qquh4n2b8fjf6g> R0lGODlhTAL4AIewAAAAAHwABQKMAHSMCQAAdH4AeACHhMzGv8TTtZu74T8iAFolAHMtB6EeAMEp AOMZAA03ACZGADZOA2lKAH89BJ5IA7JHAN1BAApgACxfDkZtBWhRAHZlAKlqBs5aCdZYCQKJBChy ADGCAm10CY54AKWHAMZ4Bt1xAACRABGXADWbDmWrAH2aAJyfAsiXCeCeAAi/ACKyAES9AFzBAHnK AJ3ADbnHAO69AQzSACPgAEPpA2LTAIrkDqDTAM7fAOzrDQkAPhMBNEIANGIAQHYFSKQANr8ARNUG QwskRyMURjMhSGEUS44ZTJktSs4VOdIXOw5JTSEzSTtHR11KPH0/OZ4/P846PeZDPQxUMiloPUBX NVFTOYJhAJJbNMZmPOlRQACKTBGAPkaOPFKMQnN1QZZ+Or+MRNGFSQCsPx6rPjOaPmCpS3GZMqOY TcSeMu2jSwW5SRzEQ0G/TGPIN3m9RZHKN8a5Qee6MgDiThnuRzjgTGDsTnHiR6XnQMvjO9PYOwAL hS4GdzEAhVYAjIQHe64Ag8QAcesMcw4bghUackMqc1spdHEof5Mlg7Yued0ViAE1jSRMdkJBi146 dYw1jKA4fbw2jthKjABVehFhfzhTcmloeY1uc5RZhLFsed5kdQBzhhRyeDRxemODgIGNfqSGdrp0 euKAjAmYeCCRfUKSeVWVd4OXdaqie8apjNOSjQTOhh2zcUy2hlW1c3bFipnHgra1c9nAcQjYiBTk fkHSc2rWiX3uc53RhL7eeNTsfwwAuxMFvEcAwGQAwncJyKQAv7MAudQDtQAmvSAXzUErtFoZvIcV tZ0UvroWwtgRtQBCyh9GxTEzu2VMzH9Cy59LwMQxvdNJwgFTsSpUs0Zgs2ttzYRpwpNrvrxZzOhb yQuLuBeNvEaMwV52u4WLx5x2tMxxzdp+tAqgyhSqv0WTs16swn2SxKagzcicwuKasgCyvhi/ykC6 x2jNyXLOsZXDt//x+6mXoYGDgP8BAA39AP32BAAH//8J/wj//////yH5BABNnRUALAAAAABMAvgA Bwj/AGsIHEiwoEGDCRIKTFCDYcGEDhlCnHiw4LWB1zLWyHhx4zV5GeWBlFeDpECTJUUORFmxpcuD 82LOEzizZo2ZL3NWfMezxjufA9/RGyqUXo2hR38WVYpUp9OnUKNKnUr1qTt3ArFmrYH1KletXa+K 9aq1qtmzaNOqpepwocKIbRs2hChXLd2Idecu1PvWbdyDGjkK7KhxsGGTiFWeTIxS8VqcMgfGXHvw J1CfQn8azSyQHs+iQ0OHPkq5tOnTlMt6JTh2K9fXq12jnk27tt29c+PixVv3r9S2cHkP1K2bYNuL hQMHJvhRpMnmKklKX3myZErnqCdDtn35s1DMmZsu/+UMVDT38+hPdz0YFuxXsKvJlk1Pv/5siXTd 9t47UfhZihLx91Z/+el3XGEbJYicQcsJVt1ijBk0nWmRQWYTakpZJpBlnnnGYWiaaUZaZ03ZZ+KJ Lc0X30CqxQffeyeecw6KNFal0HB+4SdXX3n9x6NxO/bFm46+IdeRYct5BJJH1k3YpHSNRWcdhTfZ pN1NtPWkpYffXdbhZ0chpaFRNZZ5Ynswuujai2t+xZ2McJop51M3VkSRXzviZuOdwOVXZ54D9nik goMOtuBJHB2JWEqMQjnloxtuqKFUkdFk6WwaKuWTeeaRBiJoHI6I4jekkjond2K9pupW8rFYUGzz mf8G5ztwntPTqbgeFByeOup6l4+73VjcbrnhdhyTyA5qJHLPRRnds9WxRBKY4GU4VYU14ZSllzyB SGZnIXYomlHfnljquaXmqt5667GYqntZpWpQrGbVKiOttnpHrbrqCosfscUCiBaxwg7np7EBJozR wgpipJxyjmFHncRTTgvUrWBqGtVkWHKnZaREhSvumERFKqp96KacLr+lrdgumvG2xm5sU9lrL60Z X6wxy6cSKWSxQfaXVnD/5tWnnb41fGiiCCYI0kXOKeZo1CtRjNllV5ulLXrebRZmqGGKSS5SZKOs 8tkr84zWzO7K265s8Upl89w82QpeUJFOqjaKgQ7/W2dxPbIlJFw47gpob3Ue6tGyii9O9XSOEgTt 1RjvnDPL+m4aFLndbvqduCXWh/bo5+4tlcyrxsyau27CRu9Bc8c+q90a32r6nH3+ySt/gdsYuJ8+ Ey60fhYhWOiRC0I3oZQVV22Zd3kT9DzP03vuYYfSj9ZZeaKTrvI838REKvjf3O6SRFcxNBZZrMat KpthGST7/LUGZe3Heptvn38P8Vgw/1EZnML8Jzx/Bah4DluWwxJUEKlBCTuIeYc89qWl52kKY9Tb UmZERKKwYaZE5OKO90YnE5XpzzgRcYdD5JW61rkKNrLxCv1mOKtMSap20TshfRLWNwH+qUB7OuDw /3BkrB4lDUmJWpzSGtgkRl3nSUCZYObwJr3u5G9OO0vKuMg0mqWEkIu1GWHKZEK+8ZUwfGnbm/9U 6DaZsfBd7IrZVWg4QyoWBHrd0aGJhqQnIBXRNP8aUPAARKCkMW5hTCuUExcFQSlV726Vu5vJ+DU9 0XyGbJ7h1hZpI0Z0lVB84AMl+c5YPrUVLUBeSUD81sc+N7rjHOujI/2qeL+PXeyWekwPARHGl0Dq xSynNJDBCqk73SFwgUmSEISYaJKM7QtrlcNgBjX5qW5tBnsECR1lOunJ8YWPjOAcpQn7lZu7yOdO K4rbK2E5Fhm9cp2ytFdlKqivC+Iyl+gZ4u+AqP/PPREPIYM04BGZw6SmKVJyTowWSvTG0GrZM4u5 ql2nvPbBcc2Gm2Ms4yjF902NlhFdpmzLuxqyvtaxE07vZOc65xjPOLXEmVmzoLXwCRVb2KIGNp1K 0YKWJwGt5S+BypHQ+GfMijTNKc9yUoYqqLPaMfWKmCPRl64pstGUKy0YPZs40YjGUIaSq6Pr2S/7 MtJ21kossEwrWt/J0njm5JlNrSdNpXLTnAaQh0TrZYGK+hveEY2Yu6uRNG0oKftNEmt7C1c2QTM2 7aklq6TjqBnBOtlvhrVMhkNlXVg5R7a21bMrdetbb1k921Vrri+pq01zalc64elwOXrtwIwGJEH/ lvO2fOWaFX/yhz+8o7c6k+RhE1vYT33LomuBLAm7CkozenWykkUbjQaYJ3emb6XwROtZUxpaOjrl kZYzCFRRK5Cb4rS8rTWvTn7GO74Q8b3AjO3PjnaXA5YJuEoBrm9r4Fvf5s+0JyzKpjC5vccq93tc PWNzwenc6F52h3qdC0rPARF2JuCkarWZZ0X7lIxppCcXmd4jyTsQ86r2vOXtK68K9pA+UgaoxOwV EGnkX2f29rf8/UNwZ4paLmrzLAf2Him9qeAGU3aE+WyLvSp81oS4M60Tti6Guzu/qXxmQTwZ1BRJ 7BITt/Y/AfvRL3vnT4WVU4iAFUg/TIRjntwY/7g57u2NHzpiLmM1yFrVaII56lVRehOyb7owhSs8 EQo/WZWwTIh2T8pKKM/yLNeAXqTpWWc741S95zWxigfH0/a+uCUEElCo1czmnuhYx7yVM6rj7N8b AtjSU8FzZDt6ZDKWyta0Vm5pluxkGV2414ZGqaJViGjuRvnYsUNLhkIc6Uh356Cw9nKJgSnEfcIW kPvhpyCF04811+fUcB6IqgUi59/C2YKwNoussxrdr9J6ox/VdVXmR2hfw0nQvRa0Cp9s7M86em6Q 3siVnf0O5VAu3dNGcV0Jgmmo2LenQiXz0H74t0L2sdvp0TF/+ftbHPfWGtb4TMhVfWoRI1wq6/8W sjjj3VVPftLBB3aKLAUdbGDbDN/BhmeG/51sSCOPns12dkZ+Am3yrlbTrF24TinO3tzaJahCBY5B uu1t7mj8YuXGzI1H3t9xH/zkTkm5GIfc51uH86MsDzLsWmrvuf363jTUrlkBrpbGLU7ogyl4jeJR g3jwXSB/p0x6Gd7w+OqqPoAdao+ofp5w+9YaG7cg11EN7htnrQYAAADYDyLrzHMT5ucie5HTvm62 y67eTk596uEuo8yrdH6ZrzvTGHhaw1jG7tzh+9933/fel2a1Kb60HjNPfIBCJPZ/I77yMa98zTPf +QIpfvSXb5Dmx5755JazNVC9/c9k/h2Q16//9WN//YKUPycHOEAN0j+Q85sJo+MHwDc8nzL6Z5R8 yod3N2PSfNLZn5twEn8zdGHjRyC+ZnOtBwB05H7mB30vkUQG5RFZliS4Rxu853eBB3iCp3SFd0Ll x4C5gXzAwYCZh3Hkd37S94EOOH0F4XUcp2q8lWOZ9wfd13U8gYIrGBXqVxEgaC4H9n//10kcZX/P tXLzBwDiE4RiRyoBqIAz53o0Z2/A9na14npVxoIt0YOAgUjGQygMU3So4XcEIYa6V4YZiBasRVM9 2HzTR3wjmIMluGYneH3Lp4Xtt4K9NYff93wAQIPNB27khn13SH3YZ32DWHzql4hsyIZtOIeH/+h8 i0h9jEh/lCh/IwSE/UcqlUiEXGV/+edcR2hZ55KJoWh9pWKKKnMOVtiExDc3VlhhmZcQrmd9TZiA rTgjhsiH0GeHiEQoCkR7DLQ0tkGGGKh7GmiGfXeGVaF0+ASCKtgQ5RcRJAgAVKeHjSiILsGAfzCD xOdfM/gOmbd94ehmWYeNz4eFjliIAKCImreDAnEAmZd+z3iOxXeCd3iObXiP0xeK/KiEZ4OJlliJ /WiJHTUPlQg+nvdVBil/8eaJASl/xKeJEEmQ/iiRVeiEqoiRTfhrNKd8shiLGZmAIZmA2GiP6JiD RpUcyNMgvogsw+h7yRiTxwh4Yrh5UOGMu/8IiQDwcOOnizrJh+qYE+OnYyfIEyEXe+DnZt+nY9tH g3KGg/pokurIfuXnjnSYkyfJgs8Ilfo4kKh4iQTJjwMplmZ3igyZeZLlbmhZfxT5kGLpeQ6JNvY3 knTJispHYXeZAKtohbPohEGplVhpji6RHIZSmBbhhYYRhgOBgcnImAXhmCeyg+yXfu5oIlephymI ktNIdd5mjVKZhZrZh0vZccpHmppHgyJHg+Y4j1IZj/G4fq9JmeoXe/AYmFcJmPfIlfsokRL5ld6D iWbJm0eohAiJhL1pnH+2lsr3lm4Zl3H5j2G5lxqZgIVmaNJZiyG5lVjZk4K5hYZCGIJhcN//SZiz QYaNiYxjyJg1mR6TyX4DQZknApU4eRCbyXiCeJu82J3bCADg2IfQc4MAcJR96JT9pY9YeJ+ap4K1 yY6J6J60yZo/+ZcSuppteZzLKUbAKZxBGIT8x5DetJajGJ0TGZylWKHPqTIZWpciOWi/5pF0yZcK qJ25iZJOoSy9yDBGlZiKmYE8mp4xuZ7suX4EIZtCah8ympXVB4fUyJkIiqTdeX7AxY0BCnL9+RPf V6XeoXFE6YAQWpIJuo616XwNiqA7eJtNeqRYKJzMqaZkyZYhSqJw6ZaeJJALyVwdGpzPGad4+pBh iS4ZeoQ2s4r3dpcv6oSt+aX52KU6IYyJ/1RQBJV7MtmYi7l7xmiM5zGm64ep7zimlXkeuciI+UgQ 9cl40/iI9OmAGvd9sRdyVkp8bvZ8JHdquomfWBmmiAifsOmahGiml2mmu2mWEQmnIjo6fyqQw9mn x5msaWmhfOqcFXqsFdmmpHiRzTeSfUmoCCp9PtmIgTmYzGEkSHKYX1iek3qe5jmT6wmkptGgiZip Qgqf7fqOJMaZ9mkaGjdySelx4DdyNfh4IKd9aEGkBvqe8aqpBraECIs2aCeKLZewfoqsytVSgkoj DkKBwYg84QqGVVGpxVipkbqYPzobndqp70qkk1mkNEWv9Xoa+sJ9+TpnXQdy29eUG2cWI/8bm5ua qfBKslThsD5LQgumfz/LpqVHQ1ZYI4zzMAYFruNpGsoYeBc4ho+pget6sgRbpOyas3amslVnr/vV sh8XKTNrlKeWYyBHFQLLiO4pmUMqr+o2tHCrcnFLigg7Q/l5HoRRmBDYtEpbG5ZKtVBLqVALk+uq s4bLtpU5sqjFtV27FvpVbh03Z5CXr0Y5s0x5tmjbnu75nu66tlfbs3EbuqI7uqQjO3OiksiEsQ7y nQThD65bA/4Au7ErFTUZuLzXe2Xoe+i5FvF6tZL5u2vrjpuLT4yLGv31suZmbg5lble3cZA3Fb/r tm0rsPLau1CRVX7wDdlLuudiDtz7vQD/WD+5YnAQ2IXhySSz+7qyKxDqGxV/q7vwexCDWxq4Orzv WrLWK73EW7wsy6r4Sk9l62a89byYC73uuqmYCrycirJh10l+8MCk8sDZu73bO7Tm4L3gm8HcxC+o e74uaTwaEbvtO7vsW8JOcYHn2rGWyrGnobkHkbUJTLI8yx13y4POx7iNaxalSS2Ud7yW9xPPy5QD UcA66LvRm7U6y7ZPAVkV7Af0N8F4poQX7L0X/A1VTCpUrMFaPE4cbJjHg0wb8bpinL5j3L4vUYzl eruOSYzqyrv4i7j327nVi7+2MYk0qhPXh8Ndaw7ZSKPnx7yQF3I+oV9KeZp5OKDWAKrx/5ek6zh9 tkp8tZmp1xfJ2/qrJxqi1ufEAADFnYesWYzFWJx5GDzFREusFzqcwkqiWwxSp0tQK1k8HOG6sizG A2HGsPsUxDi1KIzGuCuyOduuJ1u/B6zEDGwaaCoVeYzDAsHHF7zMfCyqfgx9StGUApxjL9if/pXI AzqPA9uA7RiUbPuazFemiBqVz9qmEZy9mCjBFFzB8AexVFzFGCzKWXzFnZSn+KzKq8zKuyZLDNK3 4MkgrSu7Iry+sjzQJ0yTx5iuuEuphBuwSVy9vRvMwzvRtIGTu5rR9aiTKmsOzcfH2qmt3KqL4PeH Ggeg5qbNKg3NLG3Dr6mrEt2rs1nOBP+hppccwfqcyep8yg8brF65iXEakaPs0c2Kon0a1HJ60/vM z/JjenW0qMGoRAqiviJMwgdNyyQMFR5bu73csefZwpwLrwc8xy7ctqiB0biZ1jPa0fQsob7agFi4 n9rsfB3nffxpbp9JoaD50usYj7j6oJA8oW9q08g6wZpcKpq8yYet1A/Lm/RH1EQNAFcsylY8xRes p+i8oRNprIy91Ofi1C2VE8rSIOB5DVU9ywe9viZ8y7asE4Hb0GkstW7stsAc1sWMwJ87G/Op1nmt fIxbgpct2W391i2NlNrcnzXAqjQ4covsfrqZpOOsq80nj18K09x6zjdt2KG4vZkHwXH/yt0QO9hx OsVxegDfcADBbc/zPKJyedQjitmd7dnoAtpX+BQYi0QOYtVlXNAGcdo5AaTqysZf3cZngcQVIbwF y8Cyab9rsdvqGIneXAO/LdkgLdzOR9QHCtdeWqU5Frn7SW4q7dxcese9Os5hLYna2thrSrTsfNgR 3N07Da3+iIpIHZF+XcWUbcU6TtTJ6qZvCtSELd9iRN/yNBXkOXu1nOS0XBBUvdpn/LeDm8LzSxme S9tivbkm27nUa8yhOaPQDc1xqLKi3A+QrYIVbsMHqqoDOsjPM4PJrc2C+dwNSN3WbbjKN9PX5+PY a5YSzJyH7c4qPpZBuKDmbcU5Hs88/z7Yiu7YRS3ksgbaa3HftczfqK3kJZy+BP3fZsjQICvb9BvR w4zAR6zEC3zR23nqXs7SYU51RF2N5ZyZaO6lx91mWlJ+cO6lGn6qQgrJtLm5dw6UZGmsK47Yfe55 3r3JEqnJEqyEmyiRkC2RtXne5x3tpIzj7D3jz+qQcorOjl66HGYbmD7L7HvVp13uCe3QPUqTBK4W tR28tm2ywEvHpg7rJ6mtEM58nGkOZM6GFa7RX66L05eUyW2UzCezXirSGa7hYfrItKnXwOrTJxqE FLzd2mvsf063mBysnhfZohzthY7ewSrPQA6dEN+W2x6t3T46j4YeVj3u+u3kB5HV///d6Z3u0C3M rjivtWT9yyg7w6ZDr/p+wd02xTXwzM+sFiHHqkDxvG+e3LSx4LeN2wKRsBBc9SnjzhCsvQeGwaSS fuZAmaD89eiNxVdszymf8jZjIuLO3wht0C4v7q4dv+VK84UbvGJtuFjbnnKsR2TTD0Mx9GSu70PP zITfzJSBuYE8xEGa4Cj7s1Cc9S2uvZG/9TuOxWAv7Zd/9prvPTMiJ5ju8qrt9qF/woJr87Xh7mMt sLXNuXKcvzzDRX5PD35P5vQQ9EQ/EEdf9KZh8EzPHZobvTXts+ys9Ybd55CfzpBVz+ct9mNf6GUf z2S/+dJfSvZBxm9P6ZPO2nCv1bX/K+C+L+pjHepJvLNRvzff0m2yD/i1L/SWvcy6n25HHPxwa/w4 PfztHGRDjd5jz/xkX+2VDxDfBA4kWNDgQYQJFS5k2NDhw4E1JE6kWNHiRYwX/W2UyHEjx4ke/VEc 2THjyXgSU9aIt/LkS5gWD0w8MLPGTJsSa+7UWfMmTp45Yw4lGpNeDXpJjyZF2s9pP3r9zCU1B7Wq OXM1sGrdWtTrV7BgIY4V6McPwbNnv6ktmzYtWYFY45r7RneguQN489rlW9cuXMCBBQ+GG9ZwyBoi R4JcXNIxyMORDeOkyfNnz5uVNfv0KdkzRqYSj1JUmvRpVKxOU3f93Nr1S8Jkza5t/2uQLdy+BGvG /Za3bmzBB3QLB158cAKDrzE67siceeKPiJ8rpy6zZ+fLQClj15lZaPXDSkVPFA81KuqqTulhzcpe K/gad+5InA9/qHGFZm/Tfqt/Nm3B5KJLL9+I882vufAzaCcDextoJwUjNAg5CgWqMDn4FoMuseZK 4vCjxjz00D7qOmMwqMu6Q1HF70gkaqnxRmPqKPXMQ6+qqJySiDXl6rPIRxcrkpCh/sri78gAfxvQ rwYLYu+uCHdz8EEIHxwyQuQGojABLr/pEsPqPGqOww/J/DDEIKuzycQVr6sIqO7SLErG8ZBCSrwc 1UNNqtWkgm+++uSjbyJB5bwSof//1uqvyOKWhHLAJ/2S6zcFhduNOIGaPHTILi/01MuDwqwIzQ3J bExOF9ekSNU4MfMO1TnvlFU08WqwsUbTrkoPPEGB9BHQ+NLcNCH/1DI2UeAi5W0uRyGdtDhNG8R0 SkunHBauL73cMssLQQ2VOhHDJckkcmF17YB3uFvTRJoqe+bdFM09abQ76Q3tTvP0xFXf6gD91d9g gwUSvGsRfQtARRFOli/2nJVUyWdjm/ZSaw209NJpC3boywq59FhLLbNEKDKzOPSj1OfEDFFDeQ17 5+WXv9tOVThngvddnJ9p2Sg6SbMTKqDzzTNfF+UD1l+k4dM4v4EORja23P560uH/ZYFjsKBqNXUQ 44yXPqjTbD/tFKKwTq7B7LP9WBk658bcuSiY47aOVc7WzewmnGvQeW+d366IztJmnfEpws/T07TX vDl6UF8JLfS1bL0mtjYJ+3p2SYYrrbg3KTO1uPPOJVeIY2219fjjsB0iymzWxzwZshFNjd1viuKW +6SaMctpu5t12luivv0O/N4Y7bQ16NNMUx4qz7ypwfk7FJ/Peeh7pQjY1k4XWXTuE0RIamWtztpi ajHemuvuEQK749JN53Z7hmAq+WyJ5kd7dpNEpF0i220v6kS6WeRdOHnGAXK2P/IYz16yWgqN8nW4 oSmlH5FxnkS8Ib3oVY96vfrX/8C+or3Ipa97DiMhgozzuSalkHO6WaEI1ccx1G1LZB8bC0b0MxG0 dWhEjwGR3/rXv8ns7m6c+YnNKnKzvO2vNHgS3FKAlqPzSLBGEzxMBTUIqAtmMXpGC1TAPghCGrpQ jOBr2LWkNb6LSSlrYhwd6drnvhA+xCIlO9kN73c/M5EEf/D54Q/hQ0TvFDB4wAsevGhHLwXKAyny oAcj5RE00zwQijUKC/WeJ734XNBoz9siJwX2uJiAUXtsJKUJKSWhFJoPhebjnBpdCL/Tuc9C24sj YCjin/rRr451DEl0WGafPvbxj+oCIEX69jvgCQ9GDayBPBhZr2ZGMk+GO03Qvv9ixYlosIKX5KAm C+XBi4gShKUkZ8HW2ELPrZBiEDoRKbnlrRkSZEveik396HjDW9JvTJChTjCFKSch3m0ix9RbzpDZ MuLRipGNvJMzo+LMRy4UecrLE1i26bj4bFE+isPgRQkVTnGCsZwj3RQax1e+c4bOWiJ0I6jeF0bU xeae87Mn63LYT3/+E4EFNaTeCMnTQSJ0RkmBqEPxRFSjFm6KhCtKFimixU1mdKPalCr2JBJScZJU q1HKVCtd2dWtUclKpaQlTGf5UpfCDy5uWUsu6ejW1+TUnzsVYE+T6VO77pSoQ1XkaJzySD0xEnmE 09FQsrjNCz4vk0aDnmKr+sn/q2I1pFulrOaqVTFMXbZ86XTnGy0Ess+qFTiz+Q9Nc+kZueaUrifJ WyEJGlShQjSaR3GmRPoaRaL2w5FLjWRhDatYS26SixmFHkcrOJ8E3EGyWa1scyWWSs2qM3TspNYr v3ZWWqYVP6RNmE1xCbfUqna1McnrXX36NqY4koEOXahtBftICUZRaEz1iiWpt82NcnB6z0vucrHq XAAT5nNdRSGBL8bCrnGvrJ81nUvlOTbCHKxpivJKeOU63sgEtbzmktFCHUqR2yrlBjcwzYhxC0H6 GtapwMWgVIkrn+QqjkvK9e8oA3xjuKDPq1e7LHXRmWAFT2iWDcauaCOcMITx/9IiFr4whg1TyJ+e V3i3tdNeyUOPGzDSxDfox4i7DMnB+jYjic1mmaOXURdLj0uanDGNa1xLHMdZIWsEoCqlWyWKiVGt 7xRyx2p5C0AD+hu3IFJ3keyWs9SAyal1smt6B9udOXIpC6WXpLPMZd1mucskloeJpUlYKmKEzBa0 5CWDJT1veIyxqcbgm8MoZ1gzZJ1e3THXQIfOrfo5crEUCKEF3etAP4QtiSrWQBbtx0bDZ8ORbmSz J01pLXd6xNM28aYbyWVqpvgkiUUsqRcL4432d81Gc3WszS3rHts6jbU+347J6cZ5nrV0wR50r+vt 60ETenL6Qct+CLLoZMMkAf8B/0qIZwRRoo5Y2iSedhSzjOVLD42wY8amRQ57weRGLwEczSAXy31u kCfkq3Wuc3Uzm+f0xVHX9EyroOntcpffW9+ImrCRFDJXggt84APP+VAU2VdKR5M8N5AIiZsybYQr HOISfwrFTU3qjW881TNWM41lTO43h1zrB/FxO2l9ZzWqVM+gbTCfLaTvX6M90Givt72JJWGHwKzn YOE5z+d+kdoustkMNLqnvbzlqFAby18GdahFfcmpe2zqiYfxxhnb+KxvXfJYO/C6283jMwI5yAwe cpG5lHa335sgMD/U3XVeAy5F1u6mB/FEgL7IGpBYRliGeLVN40guU7vwhrf/yJrXzOrEa6/VMs5i jSd/fCrx+HyYNzA7Nd89W/S58yLD98xF7+uZp936EWJ9OFFvd4913/XNLOoym2niohMd6UlReJYf mfvc7773UY86xqVuf/oD/+L3Xy7y/d/8kgtA54suEYo+zhsb9hkI7Gs769s+mVvAKxE/iqi7CZTA ZnK92kIqpei0ZlO/2GM4+CMx3Ro8TJM/UUo8VpO6+uM/xfM9+vuv/0O+W2snOqs1lEsfA/yG6LOF HOyWC8E+tmu7fAM2IMy3X1MQC6wICjydJCQ/EJuRRTIxZ/I7SaM9Ery2Eiy8E1y8+iu+FDws39s/ GIzB49sJb2CnM/SGdFK3/8pjIwPMwRwMLepTOwhUwCHUPiIUCHn4BojSwxpqwowIv9RDPQksKkVy wgaiNqOjvS5bqGp7OC4DrCwkLDDSvxRcwS68P/xzQVEiw/9LwzP8BjU0wwsCILB7PhyEw4RYuwWE wFasvmCTB0LbQz6kxT5UCEAUOEL8vkEUv0P8xdqCqPYbsQ+8NPXgwC5jv2nbtN3rB6ziQhY8neBT vE20sYJQQ088t5o4LAYpRTW8oFbynB4jpTgciHI8CDo0Qjx0uyMENGe6BWeqRYKwxYjIRaLoxasC xJ+7wAukvWvgtBq4htijPWqDrykcRqeYRMKpxGr0QmikxvzrxGsUxSwSxf9svLFv3MYDCMUs2saL C0XlE7shmYdvIMmD2EHBCLZXtLeYu8OiEkJ6pMXxs8eiwEea/DnZOj+FK0aGYz9lvLT38zLC08JK VMHg40L7Q0FOtMaD+MZvvEiMTMONpMgz3MhSFIiKtEFUVBCTFIiunId52MFzPMeCyD47VEC2W0d4 3D6ZdC/bokm49Ip9BMaATL9//Ecs+0fAK8hO68v4U8inECcwxLijfEFLlMg/+IbEvKA/+IOnzEqo 1Cps5EbhkEqnpEyNvJqC6UqvBMuSLMmwFEtzXAi1Ez0iLE0hDDRZpMVB28N9vMC55Me4nM2M+EXZ vAbc1EuB5El5+MdOu4b/pyjBv4y/Zlwu/QOhL5zG00lMxWxMx3RMxmROcMTGyCSpiqTO68zIqqxK rAxFsdoUz+zMz+RMzhQIlESIlzNLOqy+1jRCYHsHQHNLDIRNJ6RN+6wIYKwt3AzIg6Q23oS/Teu0 oRxQUHvGFvw9MVQ8i2hMxbxGNWxMxqTK6hwpcLRI6pzK3sDMyrTKsCLACAnPggDRgRBRHVQIVnzA 7cO3ettDtZMH+FxL8ovNQ2y9+6zR+nxLidBL/7yG3nSmRgTO9/PLZSTO4gypxbtEqcumFaOI5kxM Bn1O6MRGJ7XICSWnj8yUCp1KjiRFbtws8CRJMA1Rr9RBsERJHjTRtZM5/3VMTXd8GXd8R9nCybzD yRx1pty0UTz9OR5VJIH0y968NC7T0YLMNKFsxsCULMS6L8TLiCdtUgh10uiM0CotpQp1SiodxazE VEtJw+paqZEMT88kT4JQRRMFNgY0VXZ8GYgCNDeVRYm4BSd8zWbq04DsU4G8VTyFy2Cs1Vvd09xM gBu4Bi4BzmnDTUDdU8IBzAJlwotI1EX1qIlo0CdlUMWczI/0BuacVBeaToociMvMUFEkDku9zHO6 kvI0iDAdUYhQUVTFPjdlRRfNu/iM07zL0brMzV7dzf3MVXssKvLDzWHtTdyUtn9MAEHth4MdUkPV tm2zIFKDVonI1myV1v9qXUxRhM7n1FY2ekqC6EiQ9EaqtNTM9NRhSVewJNF1ZcCYg0+YYVWXdVFY Vc13rIH4bL3c7E3b0leKuFN+bUI7NdgEkAeDFdYRA9YbAFbd9LLc/DumVdbCew2JpVjntFhptdQp 1VjuuUxr9c5wrVCLtMouxdAIARF/AEt/+IazHVO0/cy1FYiNmAeyjduPCDR/uAWyZcW6tdu5BTR/ gFO6XU156Nve7Ft/wM2PyM2NuIbCVdzDlVvHfVzIjVzJnVyyrVGPEdiBHVpBLdijDVaEXUZjDVZM K9SF5b3IaFCCuNqCgE7UNYiJxVrRoc5ulZLJ9EiwzUgq3UqykFu4PVv/3z1Zt31br6Tcvc3bujXe 4j3etbRbWbRbeAzcvGVew8VXxa1eHuXRxWXcw9Ve4u1e76XcngWj6zVYZwpa3QxaozXau1S4RvzL 0mXYwxCIqG1O+XVS6ZRS+5Vf2PWai7tUC+XQjrRQ7ZxO2S0Oxz1ZBD5bk9wItDXb71Xe44XgjXDe vW1e6K3bwKVgOy3cwQ1c6m1cEOHeBx5h7+1ZJRQnHh1a9B3fEUtaXv3NvzTW9wU1z9DfgaDW/K1f aWXOaX3dawEAACApIN4UAjaIixNbbpTKcKVS/IhcB37bsoVbKf6Ik/1e59XbCL7iCebbK15V6LVb 7FVciEJcge1Rsq3e/8JNYxJe4+gw4YkAYjgG4gSQYzAC4oG9hjiugTgG4mD9U+DE4z3usj0G4n4Y ZEIe5IrY4zcGgEQe5G8YYvkF4j+AY/2F40YdiD0miEwWCEfm5E1GiCE25EfeZErGZEge5VIuiE4G YpOE5FMekiLu1pCNZe/k1ABuYsjt3bKN4reV4ie2YrqdWwjuYr614OZVzVsw3A4e3Ou13r6lXsZF YzYmXoyoV9u0UTo+nWzuRSCeVR7tZkAuOj7m02kj5GA9ZABoRkJ+inXWY0aWiG6G53eOZ4kY5dad ZADgYUlOZXwO4ks+ZVcOYk8eaIIGaIE2iIBG6IMO5VcuZYNWaFOeB/9WtudWPmhYrtSOlWVZ1tQj 5tjYcGIo5uUppuIo1mXixWIu1lstJlzjXU3l1VvtNVwQMWNnSlwOxtc0luZp3iO8o9e3rNe45JJt Hjh6pog4plU7BmQedWeiu16n4GNBBgBAVud0Zueqdmd5bmSsrudR/md/TkyGluR+FmhqfWVTVuUg fmh7JmiIXmtNXui0dmhKNuuDgGSJjuu7RusruVJvxUpZrkyO9EYMhczBGGFf3uXDJmEK5tsIFmZj zmJhZtwOzunEjeabZWY0duYSBgs6PQd5OAfPdq84zUXt2WqjfucrO+rcBOdudiY+vktp4+MRs+N1 LrzaLuSqxu2sPu3/rT5rGxZrxQxrf47jqB3i1zVrhvZttdZrtvZte45jT07uhbBrVoZuMPVMui6O 6/Rfbj0sAtvusZ3ckf5lxA5pYN5i9GbF52VeLBZcwb3j7P1g6J1sNdZpNXZc1zhE0Abtz3amc6BR 2aRJQzZtO4lnO5Zn3Bzk/YxELhvkp3ZwqyYcRN7tRcbqt87kU8bn555riw7uDm/uDYfu6E5l5kZl 6F7luE7u7EZr6y7lUAXxCIFMjO5rv/Za7NTowOjeKp7ixN7pYV67LU5p5t0IiCJyzF3cwBVYJH/m 693e+7Ze8ODv/f7vGthvHJXNa76ICRIzgivqrIYRd05wRhbIpKZt/6m+09zEbdxEWIS9bcK6bXQO NS/vZuT+auaEZLDO533mcIrt6rY+a+mG8T+na0JP8bh264Sw65O1brZFdPy4cSYW4G+dzG698QLe Xe/dcZMm203vXiCPW8Ym3NVcXncE4+vt0WZGcjHGXiNvY16tS+qg8ir/7P/2bNAmv1vn7xjV8i2n CC5vNC837dFQ8IBkbakO8151iqlOc9ymagmvanqec0aucx728ErWc4E2bkluXeMu8YFOaEEv8UJv 64Re8bf+ylG+a5Os6L3Gzljua0qPd0onDBI2WwRO4E5X7Oi9Yi7+4mDeXvmG3ukd2Bzt1VdH891s DXM4h4XXdSmvLf8rv8DQ3vVDpCKLtxWJMF0nC3YgXqZuTopwDmfTpuenWHZlb/bdg/PcjnbU7mZH 7/YmTWh8zvOBblQNL2i4ZmtwV4jlNmX5+IY7wHmhH/oh/sqJZuWuNPfYkPH+fUxujfQaL+x6j9sq 9nGUfukJPl7A7Vt4dO/6ZunLPkRbJfiJQHNYT/jIyAqGbybQXnhF4m//rnVbr3Iqn0vA2vKmy3i9 13gE4vg9poeOPwqlPuqijuc/NnmrDuQIX/wHX2Q4roERF+5SHmsnxXPnvtpPNvGcB/QPr+ts/3Ag 5iIYN+hUDmjg9eSKBlOlX3qvxfFxffpLl/qdtvd8Z2O6XeyXHnX/Lg5hzBXY58FNb7jZU99Xs9dX gz+MrNiRWqd7ecCK/n74t/dvtqfLiiispgu1Xw+4BlomkMdNkOdVniV+Nmd2Np9hQ82IhnBO+u3h G55aG5ba1t0UczcaoBf94gDVUA1Tklx94Ij3jgUIbwK9fStIsKDBgQcRMmzoEKG/iBInUqxo8SLG jBlvReTI0d9HkPLk3fpYY6S8GteunaxxcqW8ld7keasxU2XMmCpd7mTpcuVKnkKHEiVqzty5o+eW Jj0nDylTc/Kculx6cmRLef361eC6tevWsDy9uuRa9CzatGrXnqVXw+1bl27psXQLlCVen3j7AQ27 9ZrfwIIHBy76//Dwnz8FFX9LzFgx5MeNISNMfPgy5swMAQB4eKfgZ9B3RmsuXXDeN9SnT89rPY+z atOyMSv8NtCgQ4G2Ed6eDVEj8Ivy/A0fHvw4xZAcXZYk6TLl1ZRBXQq8FlOgzZF4X0LP+3P6dLZF zdVASn4k1KVK1ddYOpVqSqbnzEIXO9ar2fxmxfPv7/8tPXPFFWCAbwUFnk9DrcQXg4AR9iCE+7nk W2SLOWbhhRY2VplkvnnoEGeXPfPNHSOWOOKHDbWWGmqusVYQbLGlWNpBuulm2404MkQQjznOFhZy wRWHEnHFBRncULfUoORQKAmFVVA6qYSdd1KqhGCCV2r531DmMf81VXvlvfeeVO2dUxWY/aSklZP2 gdUVnG5KyCWd/xE44FAEAmVglgd+F9aCEQo6GE8zbrihY5ExxqFlhjqa2TOjnfgZaY+yeOlqqWVq qW815thbjQnxptlgR2okjzsjuRMRqkT6s+qRdK4ZHUpr6vXcXQN9l1OfP/EUXp3lJfWcela1h1SY VUFl5ntLkdUVVmB9NdRXzwZ7rZ13ygUgnzudxRKDfDk4KLn2eWjZopRpONlkHXL67jeRjviMvPSS SC+KKH6o2or8aoopvJf16KmOu4l6Y6gPEeaSqae+CmutxrV6EbZE1fqckwfWhGtQM8V0163ebver f+SVd9TJTkX/5R5TZqr8crLzMaXmxdI+O+2bFevMX4ECCvjdNXBtF96CgZZ7dD8pZthooocu9jRl iwacIr2hkUgipQjZa6+HLfbLWr8yTp0bbrvZyOOon+ZIKFENY6TqcKsaSRyrxL3jzjt5v7NzUbNi 9fFL1gkeJcjdYentr1myhTJ56335lHpHLdsUVM3Kd2atXGk1bbVCiTUn33z3nGdcPAUYtJ965QXo uEhH+Ci6S7vL7h+cxT62bPjqG6/VJ8b7u9Zdqyj2irjT1tBtC+1ocEGFqeV2RqrK3Wqq8rwDt6p7 h94kdE7+ql3hOdV0oHQJqn6r4mqZXB5PjFseH8tOjWTVme2p/0k/tN5bi/N+1m4fLGcC6BLO3Ikz NQigAAeIQAAEZYGc6UcAw/JABz6QMA6E0QIRgkANIlAxFFRUhR5jO8pk8CElpOBhTujAZ1AQAFUr CAsD+I0WgihEGEzNAlFjwxl25oY8NF6oerOjgWwFO/2BXkXklrfq5Q0lertbxP53Fr9F5ztTYsl1 rjEToEhHZEAbWX9Q5pLGDQs67YkPVLxEP/ec5Ez308pV8gdHzuEHP2ORYp0MqMADAqB0BtQjHwPE GaAMko8q8UsEt1JBRQJAUBX84Q4j2cMfYrB2PVQX1J6GwQ1KsoYc9CQoIelCremOM5XC1+9ClK8d 1nCSIYrRa/8600kfshJePsJRwrzRj41t7IhIfOL1rmc966UqmMKsnjvwliqXuAOPTXoOrgIHE/B4 4y5W7Emf9hRGxpHxZWf6Esos557KtcRZZ5xWfQrzOf2AzplrAaTpCMiTP/bxLQakByALqUdEJnKR EGxkhB54w1lSspY3vN0PE+XBADaKoCmcpA8bYlAe5it4NtQdKjmzNUqaUIaiZNEre7jBgkI0YMpb iK6MaERfBgeYLtVbq66XzJE00Xp3uxsyzehOaOoUcFfSok2qmRedgowo2hQP49oXpqS8x2VPOWNT XEYVlfWjZTxhk5ruCKey9K9zOxUPPOcJgJ4RUI/4HKsh95j/Vn5W0J/+tKArZRnXT3J0M5fMkA2l NtKITtSuEi1pRO3KNRjSS6MwjJe+VAnDvvLQhiH9pGM9GlnjDTGoClnpfy7y0s26NFVMpGmrbOpE 6nk2mV/tXkusA7i/0eR8Pfkp0RDHH8mNsSpMHSetpoIS90wlPV9SWVngGCc7snOrZfkqWOs5FHm6 pawLhIsDxbrAf1LXrQD1yx+we8HGepSWgOUuQ5l2KMh0l6OMrSt66frXBc4rhsDTXbw0WsrvDlSu 5hWpXB8b2IARRaWY9Y8/asDZAQ+YpktMJjI/WwPTnqSZnkVuHL+nHStOWHFgTF/60tK4oiTlPE9Z 02/p9+He/4JpPrpd099yJq37EBfCbAmrWvdIT7gYEp77lCBAEchP7GY3LImx3V/RO1lPSk2h4t0k ftW73lAGmbs/bO98EfteDFZUsaDk5FydrOX0Omp7FnEJgcP8RASjSpiiRRXeoOjg51QvWi7G2DSt g00tme+11uQSN2krrN/2tkxNRSP7evvNls0nq1sRroT2l583qwXGhpyLc2Osx3zWc8f/tC52+5EY TR/Ur3UdcpMR1S6HWOaxDlUyqj1d38ECT76/g7JhU+nC3dEVy7WWbHkttbPjgFnMvsZpTcvsRChG p5kpMbaDm8noj+2pwnTeE7S3RKcNb/hYLTnj/JoapvkxK/8l6alqVqLlP67GabjtZLRY053WSSuX 3eq+MSNxfF3qanorPW7oJdVL0E5O1JKXMXWWQR3qjkK2M1ub15NZfcMoA0/VMpzlSPd6XswEC4m9 /nWYyVwrMy8TxaatmfS4pFCX/IFLQyNaNu8MRp2RsZxlUhn86meep0gFPsBlE4qNa0dzHxfdaVmg UBCobhkrt8YOpPelLV1vey9qhPj2q8Qjvl0uT72EJFWhZlaIQlmT0hcF8cVIR6RKWt8Xv+VlJdrp +xAuIfHLGP81mW8qWmUv+CoJRslMEcyfxNTAMSQvOcn9c/IL+wpxJ6/T+k7WuMrVfEznORZw/axb ZtHsjnL/6tyiceZzn7suUZxW1+woi5mJix6VCD+slL/hC6/7or2rb72UyS76zIin7bx+O+5jqjfP RgzNa+K9qhZMd7QAvu884bvxA88fPxU+L+gjGeLXl+djNWvyUvUmeUQcn22fRHNzqmMdNy9+anWe kQ6UTKNmT3D1O8T07d9a61kf/2fMP/7BY/9h0mJ76AkY92JWJu+ZGTOhCpvVXfVgjGkNX1qUHAMi X/EBXvGJB3j81Bd5kbRNm1JVhZh8k1TQnG5dDsw1hVW8h6Hdh+cM13HtXH/8AgvWwC+44AuO33+4 Do+hH9RIDf7loGa012HpDuvR34isXrzIn+rZX+pZSgIU/0QCJOFDJMBQ7B8UBpj/vd1MDVPwwc1V oVit6B1bQCADJl+iCEUESqD5rByCyBae6Rn7ZN9RkMkZ8YSxQNXKaIWz0ExK2Me4VUv4+UcLvmAL uqAM9gfSKFRDpB+i4KAOJmLw7I7pAWERIkT8vZ4Qyh8qPQoTLiETMgTDRCEnTsQU4p7GOVjNRBgW QpMCnkUY9h3ffSHyqeJ/AIvzDQ0aYqBRbFjLLEt0sAwZfZhUqYlXzApXfR+5jZtasKAf/iEgJmMg rgUNfp6ojdeFIKIiJiJ8MQQqyZ/XNRy9vB5DtJ7sGcoSTkQ4hmMnciLuWcM7oKOvJRNOhVbdYQ9W lFaD6f8UMxEfK/qdKyaf8eEjnXhH4mRYGiYebe1iOdWPU9TcGiHF5J0YSvjiMOrHCapYWsQgIBqj SxgjRS4jMyJNIYpX1DjNNIZkD26U6qneNhZhNsKeSpZkSn6jZiSAP2BiTJIjTMakRNRkOdre21mD OqZjTw4YAC7YsUFHx5lRtBBggzHYKQZeBELgPjbgULSiySFX4o3Renwg5qBHGzHV/ERVVsIJm+ic CVqecRWjMl4kDF4kMmokWnAkQ2BSNBqiSIYkfCGcEdLf680LNxrh6gEh2e2QRsAkTkYEJg5mTu7f TvrkE/3kZgmF3rGWFg7lxdAjgxGFA6riKorhUzLltTj/Qw04g2d+5s4snlVSW7cNS+XIz+NADrat iR16DvhpHjEWRQz6IVpS5B9mJJe0UNAVXXT1ZgJR0KVNV1gg2Qid3491lwpZHQeFVJatXyjx2wWh 0CxxjfuBV19KIgqB3QZJBGcEpmAKJmHaZGEepk6eozryZN6oZ2MKX7LN1DsemyjmXchx4VJ+IVM+ 4GViZmbSCWiKpmcG6H9ujxgp1XoslcosS/YNGq205Vi22FrkZkXyRB+ipc44mo21m4amG7wpXXFW 0kJRkiWV2nPq1+iZXaptWahJJ5N5V8NJWV5elCpJYknS33dyxur5w3fq6AJdxDgWpkyK403apHki xxT+/yRPsqdLDUVlMtMBCuVQ1mMc6d1SWmZ/XuYqXukY9kdo8gRoDmjFDGSBSg7KPM43kYn3gMlV 0MzNWF5Xad5EqiVGqiWdWmTFwJjQSVo9YWilCcZbOZxcMUaIJOd+FeqV4dq/0VdkTZZBNapcbdRF eSMPeV0MRaIvRMTr7egzRMSm3mgA+ehM4iRN1qSoEqZ4FilwfKJ6pidnEcWaIdhjRiZl1p2TnmJT YiYYQiU+8qN/dGmAAqhQgGn0labiZeDKIMsYeaXkQdPlwaYeluVE2qacUqhtriUAFZ0CUdq7Yata DcYDTchfkZd9+ZC/UZ3a3ZrADZynbZAzmGiq7dVijf+SSa4ejraefLUepvpDYQFAjuprRHjqjoKq qf7oeJIqeZIjqmLEJ6Yjw7LqT67F8BkbMLaK8PGEslWp391qZnqhA2bsf/xnl7pEaPpqyOJZ+5Ap mbIP5BVLtqmmybCWVvGPYJQbW+BmWsKgnVronWKru/FRnqbVcv2mWnVUB1lSB21IuhrnRDHquEJn DbVrAEGt0uYXlk3SwW2qJNIrv/6rC+Uo1voDd+ao1gbsp1rEON6keJ7tqRpswirswvpkki5pWryq xYZitCSbAS7gGOrnyO2j3+ajeIysaH6m4ALr4CKeyp7MyQpFG14FyzyVURZFcdHsuZnlnN5steYs toT/Vc/SU29max852h49FOjZjtO5aIuu36KqXV9BLWeAptQhT4jkCAJRBL3k66baKACALY9yKr6C bdjWH9d6Z9mirfHKJMIeLJEGadt64tvGLfRqD38s5cW6p/VaLCr2ba5uL/F97JcCq4D6KraMKeOS Zp6hx4iJiffwh5vwR4XW5uUKRYXubNDmac8CrdGhBWPtkGNE1tOZa9YlmYqqqzM0JwAUcOzikjeE iD94QwP3bsDm7qYCb6bubqfubl9KRKVKIv0N7/AGrKkOrGEOqdqOcPP6w9u+lDr2x8VSKd6+cAIa YJVaaX/+3d7iqj6qBZh+Kch+r4Ae7rRJX7Wt4eIt/563daB/xCadYCQT1ymdnuW1fi6Hbqie4m/Q Juq67FuJNi0Wl10Xf8OXgrHrHvAYI/ABC0QDL/DuKkTv9m7ufmdfTjAcB2+9Xmq9gm0dk+3ugvCQ iiNNinBFmDCqpjAwoSNPcgneSmkLK3IMZ+/fKZ8X5uPIheGWokXJeumA8vD3XovJmGZtWaXidbIM 5mz8KqO0bq5vpjL+UprQUVCh7C9EhWjBSRKuMSeSeXErRW0BF3BBQO2XtjGPLpAaC/N3CoSm7uil Yi13fqru4msdE2/ZOpAfh2d4Fqwf2wE2/2jyDjIhA9O1LLIMr1neYm/2ZqkrZixUPmXHsoX4iizI Yv8y4QprsHhy4lKbKA8xo1XrbdamhZ4yW4rHXIoeaIKxGDuDPxi0QVOEMzgwQjO0QQ9EREC0RDsw p+Jl/Okrvkqiv25jBmOqRlMEH4fwwQ6mNmOzSVOzIJdjN3vzN1cvk56iS+st4FpmVIohr7IzEGsy 4cIz34ipKKusGo4yzkqr5vLzP7NFQOOORPzyQYPmUh90U0e0Azs0Gj+wRKAxRWP1BE/wpYItEHq0 V3u1NwLv174eSO8uRSBvqC5vRGRzAmCz2aa0Oa503vwPlYYzOKtFOvNtDh8fGPr1WmxyJgNoD3tp T4NyaZKm4gaizVJoRR4jFB/1WSS1owAHQmtyRPz/ckMvNGcLxEI38GdXdUQ/MET7q0d38EUrM/Dy rln3q0R0dXD8cXmGox3QpEnbAZFyM13btVK6Z2XSnRPWwBIKRXD/wXCf8193rFN6bGAXrshi8sju 8P9UZSgXKKMVpmPrLM5OKHdL9mRTtmk0zGUndFQvtVOnMWhi9XmPtlVndVV7A1d7LQVbNAW3ttiu Nu+C59rO5MAeL273d5HStfRKUQsnIKwORXALt4JjooKn4q3qo65KpQ7vNBC7cw/r9HRLX+JunhN2 eII79pySsrV6d6GAt0NEIUKbd2ZDtWZj9VVD9EJPdXu/uFXra+5eajL7pTLfLn7bN2xnRNoG8lrX /7ZMZnNtE7l57jZy0Z04EzdPAGmCB/cSSmUN6+ojS/iE87A7W7jg/iqJ881wd/iTp+XCDPWXG0ZS ty15szgPs7g3xPhAxHgazzmdT3SN425Zm7Z943d94/hxzPZamypcw+SRv/US/vdhrvQ/i/mYI7gT GveV52eutmIlW7I8h2xhP/dR1wOn4xF2Y6Kd1mY/iHp2nzm46uAJYwR5p/h6O/Wbw7lUyzhFiPZE VHUkonZFTzBGuzYFm4pas+2hF/p/G/pbH2Z4vkMCLKxkh/mCCzezu0QCJMZwP3gDKrfyBe4mb7mX x/Ml+1w91MC3d/r2iDl2LzhZvOA6wW9kH7Xopf86crR5Ql/2iqfxZcX5Z8s5aec7jYN1VwNhMoe1 R9+3r09z2hb7eMJ1bbe1XA98sudNsjc87nm3lEf5h2Micy834KIzlqeFlm/5Tg82hYvft4M7p488 uIO5go/5qCfAL3iFH456y9uMbko2vLg79MT7RDB1U1N0vL83vaf4VLOxVLN3r4c11nZwfuM4rx/J qfb3H4t0ear0wzc8xPuaqU88kDq7xZfclCN3X0NypXO8pouvYMuzt5d8uJs8ylM8WLR8y3MFC7o8 3MMpzU+NzQeJzq/5imvym1/Wenv2m+v7aL83RU+En7M24ud3vi59kBDsqGIikuP2NtveEjq83mD/ 4q9d/YdrPYM3O7Q7ZReGPceH7w+/c7bLYKePfLiTPJg/+7O+vVcFI7SyJWXd/XGselO3eWZztqsH fuCTd+G/uGhndY0rPeJ3NWz3K/K7zeMvb5EnfLEbfBRO/RNVvpiZupMz+HGnPLQ/+17jJ+h3ZjwH 6+B2O7qhveq7xOrvzOaHH/hJS9yvGLvPnu1nxJqft7yPd9CXdtD/PL0DhD+BA/15K0gQoS9/Cgkq dMhwIUKJEyUmSODvYkaLGO1oTNAxI0WRIwdafPcuAUqVJ1m2ZFkDZkyZM2nWtHkTZ84ENSz25Alz 506eFv8k+APzT1KaSY8ezZnTWQ1nU6NWlXo1/+pTrVu31qtXw6vMr1y1WgTar5/QGv1+9Vvbli1a uG5//SJ7F2/Mb3v59vX7F3DgviQJFzYs0Blif1QVJ1682Ju3qZElU55sMPJBgxIzC9yc0FfohQ9D PxQI8XBFjBdLrrbYEWPs1IZVmuzpEve7vLt53zTrM6haoEFrNC2uFGlMp72vypxKMytz6WCpj4X5 1fr0mEKFot2Jdi1du2tjggevfbpg9evZf5v9Hv5Axo09F9ycODN+yY4/17fv/yCJSnNoNAFRi08g 1lrraTWOFKQoHvhaSgklCinEDb0MeeuJuOCGKw5E5JpaLsPorGpOQ96w82qsFcHKTjqz0pqRPP+3 YHLLxrbGC2/HFPFqD8ggB0OQyIkcI+hIqpyJLLElmbTvyfygBPA91EQ7sEiEFMxoL3++YVCgeMT0 J0Iyw0wNNwtPutAlH90sayjuPhQuORLflOq55+5kjkUWqfszQ4vQGlQm8OC6UUe5etzzKSEdFTLL SBebL0n6KMPsUichw5TTSzklybTTJBXJvS+9/LJL984ss0yCIhxzpNzWXAlDRm21CTiZ6LyV1wxb BPRFH88Lz0bybiT2vGJ7tenRZoMc9T3H5pMPsamgdFKySZfUL9vN+rs0QGiz7CsBch9kFdZW0211 IlndPWnZXj0cjsN47dWuz2WHPba8Ywe1Udn/e50duD1xZ2vSSG2dlHZSJinzrzPMIDa4yFK9PJUv gVLtksxXJRoTZInelfVeN8+p4ZyTZzLrp11Lfpks7IIN685ik02W2JkILZngngummCRpKW3ySMQw nTJTbL9FGmj4VCWo1I3dExPWgahG10yPCRq5VpjRSxnlsGty2euyubIuLBg1BDhnY3Vm2+14fZ6b vaYJQ7jaSR97bDL7tjXIWioR8tTuw56O+umLTzXzm3TN/PjVVrluyeyvT1ZZZbEr33w3P2/dF+fw RMeRX7npPl29wkcSOnD+PIvYaE0J14wgiVUnKeOLN1Y8wr1Abrzj4Ndld3J4OZcO7MuTz/z4/+aP Z9u8fnc2b2fTUb8+sNuRRJJooyt73bKHI/4Uyv60p0jVjNVXX+P2T408TPgfj6d455FPmXnl7d/f 7H8BJr080RtWwGyFPQP6JSbnU8wCEcatbPnte57KTKf+o8CRpA9qfplf40oVD+CBzGNYox/X+Kcd /OWvhCl8WfWQNUD/xY1RBzQgTcBWA+1VqmhEk6DslhQgb9luYhaUCAYHcjhVUc2I8GPV/NA1MhXy JnkoO6EUmfdEK75JWVnUogBheCcZns4mVYRJ4fDWQO51xlqB+4z4wkU7IaKPfURU3MV61zurxe+O Vxthbq6YF+VlroZ9FCRZEICXLErvRjiy2f++vPjFgeVEjDOxG972prDLVMZhE6zdQLzFyTdOJHFF VNzUjNhBL1XtcVkboZjaNMi7XE4mgIRJJF1ZyxogoJC31Mr0FPm/APargI50VIbIKDRL6hBbmirf 0iZovk9ybHHsm6PGLPa+p4WwY++4GuVs+cqYYE5ztOzmE3OJy0Lm8im+RKQiW0hAHwmzPXsiI9/0 prCCXMaHbWxjZz6ZQWpiLGp0jJoH05exyL1Kmwml3wif4g8bOlQgzbtFDSZKUYuGEZBRFOc4rXjO W+KSK72MnugSCbdGwjMwy5qkfIzJSdhNRIL87OcQAwrNar7qg2ICntVAeJKFUi0nA7FhTSD/urlb VJSiRz0qDf/4R4668pwgpQk6cbJIkhYKgHtCKQJhdsMyzsd242OjM2e6OPdV02IEDVOqhLc1VvrU pzchyFATGFGHwkypF13qUmHCV6ZK8am2lGpNqJqTm/mShVrd6vGKuUDO+FCm+SwrKItYUN2RSYOk NCXVWLJQbcIkHjYpalHrOsaHRnRZE1WtamPi174iVWwbDWxHo/pRkBZ2K1kFoDs1JMwSlrWZEiPr ZBEiTfdh7JQerKwHCRpCVj4XqKGVCWolSVqhSjK1sFXqdvt6Uedxh2yz1YpHzTnYkEIPmDE8YB+J u8nhtvef7RvS4tS6U/Y916d6DOp073pd/7pO91asfW1FCZxUA3u3cj7RlXgJSd6o4jakxuJtb683 Tvg27UqjMmJxdde4Oir3mj/Nr5hAS+IEAtiuRD3tQ/97J6QSWMCthS2Cy8YhOrGMwTgZLDohvD8w ivfC0BpQRIgsqYKy1VWDyamIpSsTE5+Yrnc1LU2kDNH+SjlFebXoarlsYO0m+ENxYhmOczxVXerS vCnsWZn5G2QiDZlAWHpPKKOJON9xEGPNfQlNTNxku6YYtVU+sX/76yO+HnrLMNbrls2Wq5Zt5yds tkmPn+gsSYvWzW+Os5ydJt/DeZqDf0GobkLb5Bo02dRYtjKgo3xahLQYPaxdbXcHnNQZH/8YZmMG yqMXfOmpetSKQvK1VjKNoNKchiGcNgxb5XjZs6r1s08+dYlTPVQrt3q0qxbqtqmrnb3GeNavtfV2 Y3wvBdv40b8ZdjfVAwAA7GXdOHF3dQvj7iAPeTSiKVCkqinfZ3fQw1erwbxjIu2BA0DQcx3tTNw9 b4UfHCYE5w2XZZ1ovyJay3eReIx2Pad4z3YvDW84vDf+cZqUfIyEsfe9/eFuhax8IPqeCMwvKEqL iRqzujn1k91datBC/OBX/vO1A+3wVo+R4Cgny4sHLGsBX3zcW0k6AGqi9LKoRU7zmnpMrG5yr/HF 3SSnOtC9fvKxU5kkNIcvaVYeZ5GonbL/mb15ZZM7k9BK3MQOd7h/p9ztllM9xdb+e8TPnpe8anev rZXxxROfk61PR928pheZyV725vGF7I8X+dk3z/WGe/7zZvc84SXeedED3fSlp7rpZbL5sW9eILD/ e+wR/veG0/72toe563EP995HxN6wlz1ChC9yDst+86XqvJhc/3PSu37lB8/9iaEPUXujvvDPV33o 3X3U7t9i3uD/PLkpmnrWtx76oce+1Te/k60nwPzSn/f8Wd98s3Nf5KCn/+vrn3/5az77VkbBjkf1 ksLd/uAACU/0tk71Tg/iGJDzAhACR68B1Y/hIDACByL4EG7ldo8DfW/2PHD2aE8iOhAA/0LD5XzB 5UaQBQnCBDWw9opo5ELu3UhQyuKh53ru1ObN1NaP8AbPhq4v5bBvqK7v8dCP/zJv9ahO/CaK/sqP CS8q/JoQ/6qO/wDAD4jwCEePJ9zN/T4P/gDAQ8JQARWwChvwAtOwDD+PDZcwCdPwDN8QVyKPc1xP KQ5w3o4C5Z4Q/biwD80w+9DwAo+QDx8wAP2wEIOOBI3PBkMwBkvwA2GQBeFO7VSw9uzNEh3C916w ESUR7BDOPcLuAnEQAKRL6V4wCCMxFRcO+ySRCNXQELkw/ZwwChVPAb1vCf3wD93ND7JwAm9C9SxC 5ITx7MyCEHMREHWxDBHxDX+x8pJxDf8tENIkL7xK5gCV4g4BAAHt8P+u0BulUQmfT/tOsQqhMRZt ogILb+828BGrT+14TwSrDxJF8O9QkPcgsREpsfZC0f6aTxD7cPYAUfbScARfcQ8jsBuZcBZx8fsO jeDELxxFzw9Urxenjhz7z/PGjAzDMR2V8RnREAAj0h8RUv5wQtcoz2sS0DgObhuRIhudouQS0QqV USat8Bg58hCXMRFVT/ckkfjaMQY3UBJBcOYu8QQtcSFScCQ4sQU7keZ0EhmfMRoj6gm3bcUCUgj1 Tg6ZUSoTshahUCZoUam67x89zxex8CyXUS2X0SeG8eCy7iY7ci0/kiRDUi7Pcf0OUTj/1A0lS6Yl lQMQYTIXtxEZC/EgSU8LSdIB5bINgREhN44nhXISI9Enb88EKbMpRzAFOVEpN9EofdIFgRIGfdAi ZzLoVvH6gHAITRAxgfAwzXEKbxLoVqv7YPMQpy4LD+4sJ3IroZIYvTAMzy0uIxAipc8BoTIabZM0 FRMyqW4AwasvrVEbZ6IlCTMPrdMiIxAcx1Ectc8xkXD7GhMd4w88+c8OZs8OkO8Rde8yc2/4ftID GaLhLDH3ivID6zM04TM8s5P9/C8vA5D2ilA95xIk/fPgcJG18g/jyLMr/68XdZM39XA7/68LxZAM w7AcjZP+xvIbb9P/MDIx/XMkuZIL/+VEzDgHG49DRZliRFjUJeswJ+PFDmpgRk/rPP3BDm4UQYiy MK6ENM5HQ66txYZOSP/rz6YsQw6t8Q6vwGQs6rQiN2OiFx+0OPzgD6xURbmCDltmAG+Cu7psLtGj 67jC6oiDXiLNa5ADRNb0KZyCRe3kXsZ0WWqURmk0R3N0IHT0PXjUMJTNbnyk2watyq7MtAh1CLOM /MhN0b4ML7JwSh01SpUiN930Lhwt1sTSTeT0KeT03KLTL5dCTd9UOUQkS19GUxllRnNUJu40T1k1 Nd6z2CjiTlZtCK2LxQoN02BtOr7t8BSP6TAOSmsAUoX1OK50UkOETXViXuYFJ5b0xf/OL0VOVd5i 1Eyhs2yMo0WZok60FRuXYyUtLyZUNVVhgk5TTiDwNFYN5lZeLeFKC0mFFMu8reKYVNG6K+PIYkqJ tUqZohe/NS86RCt+1V5hrOL6qFqrMV7cdESQVVuTlTrrBFzt1E7HtUbvdIx0VE/TtUgYZa6irGOP 1Lq07U149cAUldFONliJ9UFX0kopFVldrEl9VUm7yUQ3h0S4dWG9tVix1WWb51fUJkMqtk4ptk4f 6kYzVmPhg2PZlcUKFUmbtmlJK8ueFPGWlMag1FGldGVb1mX9NUm1LGa/1Ltu7Ym2NE1d8mZzdmGT oybgFGbyRSxkJmhTVVxnom4nNmn/s8Re4tXaUExQn3ZkX8xZn243HnRK3bRfiTVFHTbWvGzWnu5e cS1ipaNFX9ZFZUJNMbdrncdz0sZF0KNu6dZuizZviaRX+PYqcVVQCRV1GeXbECxy8TULs1Vxi3VU NeTWCgxME80WJ5dyAfNl1xRnAZNSddZrgPY6YiI7kJcr7rRiVbVoy5VcyRVdS/cw4oXocNXvdHXF 9iTcEg9YXatRhZVrV5R4F/dSKe5xaQ3Reheq0CzNbEVhuRViXzRFL1d431Z54xZu41Y7xJVuoZd6 h7bNDOMABOKAM61kjvRQXS3QXA1qYTbqxPdqG3VlG3ZFsZVxpUN3TXZR6ZWjyism/+L3Ti5XVF30 Tdf2W922V1pEbqvjZ6/DT5j3JgRYgCc2eqVXdOEjgYPsZQKt0B64e7O3VxbV1iqYNxw1VP21Z3f1 iC3O6RqvZJ8K2GprWXrWW+c3f4f3eNOmOpIXhgHlhZvXYleVaIU2dMu1MA74ANrYH9y4vbrqY1n3 UIG4dYs4dqcDhdkWVA0tLGcCfNn3STvKtgoZJm6LhH0kc+0Xc81XZ3P2ZX52RcbYhWkGWLTCYseV ejM5XG2YqCaCjRFYlOG4rLyG6PruY5123TC4eF/Uewn2j5sOlslJhK3YkIGthC03bUc1cxtWYUsG bSb5RWSmT1x4mPGCYsu4aHHYjP+XuYDfGJpDeSB6uJ8qh9CYlrqk1tey2HYxGHddi0l5l9bct4+o ypwO+ZzRmVHmt3i7Fou5GZhnZphpBm4/l4ZzQpMHOIdHl5M/+Y3bmI2lmZQ/ibEIDbuGON40WJdZ uDfa93XDrdYkN4XMS6oo+rbO7E1a+X6pcyW9maF5xYvlOVj+hJ7l1pK3Anqf94ZTmk4BGCcIIoHd OKAHWoHsZ1CNFILL7n7xF1F318vY93vHuYTIa4QR+aPOjNIyZHG5WYWBF2cX+VZM+qSPOXmneoYv uYZbupMJ+IynVytkGprDmpqFiH+4zVDvOKEr13sHGXKfeJwp2H7STIRlAsKSmjn/NPipfxl4ORqq QfqLXcRzi5mki9lzMNl5w5WfAfiGc+IAamCsQ3msgVSFThmtva6v3cTpFm1sF0+i+QeRecyczRnN MDpF4DlbN5evg7eFxeKYp5qklTek70JoB1h0aeJ5v7qxYWKmR9mCfNe3cwJedM5XnRR2xzZmJ/qo y2m0a8vB1rmvu7WRSbWJ48WSZ/iqTVqGiZm1MZmfmdmrZ1t6v/qfpbmmf9u8Z0K4X0K4HXd9y21e h5q5DxmdLzq507mEIRliO3pnHfaj3+RzZRiMq7p/Bzu2n8KTEXtob9uZt6KxGxygw1p7zlvC0Rsm 2oTiiltsB3mo4be+H2zSSNtN/05YeFNYRHr5XgRbmK+bqmemuu/ZbvtZYp1Xh++ijWPiwSP7Tyf8 vHVON9a7wsH3vYl7s2l5vnlMvuH3s+36rvn6kc93g6nbf714kjv3i6saqw28XFcawZWZKxrcxnG8 aXRczIObx3+cuDOO6YR8osvrnImaw+WbvteZj0WVo+s3kmO7sPc3X1TctfFZpWX8sCV2NwDasetK dWzpGZ6hBhJd0cVcOoK7Bnjcx22Ru8SZnD27zdV5x5S7qJVcQ0o8WbXYa+MZwFu7yrUbjIVZtrc6 h2cbUHN8kBJ90WWd0Rvd0fOizHtcvXXuuE82wwWJ0+Pbvkf4yJ17xJ28qfU3u/9/JburPMCv28Vr Io0DOLzdhGJcqdZpfdFjQtZvnSyMJ9IjvcfFHZAnmGrzGL7LqbCqeLnd/FYWeW35uGxCWrsp2cqN eaSnQ6sFfWklJdZpXdFtPeAD3tvxomvUOywh98Jrychn4qLdHLTvRYVNuHLG+K+fHW1g+6r1fcFV Sm//vdtnfeBhguBtveAxzcpO4q4Q3selGGwHSd2JvYrZ3L5xWVmHAufzgqd3mnMKm55LPd8L/L8t zHRjfdu5/ehnfSZM/uT91h/e4emfPtJXHtxpIpzJtpwx2qhtK7Q5nSyslTfw236C2ecBO9XFeMWf Kj4QfeAZneTdHumbnspu1YH/13vSfQ3il/uoRxvEnyI4cIxZc6zegQXfa6KSr5zor5ftRX7ba13u 92tQBUI3rgzS8UIe5KEGLv+K5PrBmNuitZTMTBRhu8lzCVyeAxvo+zywDKOWHJ/kZQLgR57gHx9q nx5epF7lAzUnMB8mLt/3e1/z013rlTvmCzmRx6bjcN5ML+2FJfni63nAc4wwEF3k4f7tX5/xk97b gfi/oD7qJd/7LT/4M7/3yX+Wlud42N3hSduWt+I33n/X6qXMoj/j87zZEZ/BRKKbSv7tQ17bAeJZ DYE1Cho8iDChwoUMGzp8CDGiQn/+alQsWJGixXc13lHkqPEiQ3k15JksiZBk/8lzNc7JY3kuJkyW EmvaNIgAwUGdOgv2zJmzRs+bCWoUPVg0wdGjN5s6fXqwnkGp9agWrMoQ61WoXLs6pQhWpNexNwk+ M1vw7MC1A82eJUg2rlyuYjNazIj34zuPIUeiRHnSpGCWJ2XSjNlyLtSgPIcKfSwUaFOlBZMqpYzZ KFPFnCNWlXoV9NSoWrfWEN05NVSwqlsbVHtQIFrZbWHDdo1bsUaDu/uKZM164cmDJAUbd9kSMcmZ M3M/5Bn5sWTHjm0yxWz5clLnzj9/Pr0QNFXU3MubP/869luEb9vDRQ8/4m+MvA+GDBvWocrhBgm/ JLxSf4kNGN9OkEUnHVfbIf9lVGUNFuiaeONNhZVW4kGIYYZP3bYeW2mp5ZaHGo4Y3H0WnWjXXfTt ZtB+xQkGWEsmMUcYYgI2lyFQQfl0IFTbXcfgiK2h5t2FFuZGTw1JCsmkU+3V9hqIUa71XpMY2hWc ivexSB9xBRX3JWAv/pcYjsiVmZyVCFXnVGaUKbTUZgDMOadEdN5Zw5115rlnQXQapCegAIwlIXiF qrakkkrSk2Siaj6aEFxS0qYQpbdBal6KF82HYpabdlmSi1/yJ6ON/yFmY5owYTrWUpoZtOCDC/bZ p0O1+jkornzmimuutPrKq1MTegcekosuySiyrC6bloe2TSols/FliWK1vM3/x6WoXq505ozIvaTS qqsSKC1R2L36Y3aCLhToNzV8Ay+fCf26K7B13rquXKU5l2xByTbqaLnLuvVelZcK3JpY19aHUUX9 4OfPwy3CGCOpB7l0WJnFGUYuwuaqi9Rlr8o7b67fzAmvu/DiSy+e9ZJcsscGAXxQv40qKjOTlhrc Fns5u9YbXieueKLEFkncz4nGpTSqqqiSCe5LHdP0M0QiZ+cq1vkiVKe7e7r7rp73BiovnmOzG2zO /c7MdtUjVtmsiHHD7bZu+Q2t5dE1PGz03nyDGWaLBaFaJsbJHZZq3RKdG2dl14m8550nD+o15fFO rvLW65o9KL66yhwwozOL/9624hASPNt6dJsel9B3D40fRknnlzTFTYPprcYxnbpcuP0lznpCb1rW 4I8N1nr2ypZvDTbLwOrqudsA/+uvojeTHjx67n2IVtzZywWcfQvnVdDDDu8dcdKhhjrccistt7uq yc04uI1Uf49uuiIX7zjMKH+NspRVLmWa+1zknmfAtAmMdImimbIChj/uqM49T4rgXHpjn09FrC9D 45vf/uKijWUMcTApjEqc1rHgvQlOsEqXoFxGtncJSmUqc17MekUvj60NZ9SDoAXhI6me/dBuDatL iY7WD4nlJzAnZNqMwCWT9lFNamkaIkJiBasHZXEzBSHgu8BGQwIKEGxWlP8I9qxXPQb6sIyt2R4b L1iXhSEkfXfBT9Jqt77Awa9GMilVYdBkv/t9DztuGh4WFUJDhGTOIGB8Y0REt8ZFsS2SjlTMk1ZX yaYYcWHm85v67oI0eSSRfU0MTMZQgjGMSc1wAhri/q7WP80QD5EyXGQXL7fIeGWSIT301w4puctg Qkph1qqjB2eXkVGKsh/tAxyYDKfK+iHEMOP64SyvOLyGiFGGXWTkF8GYSDIKs4E9VJYwzymz8NFu U+ab3Sj3Bs8xCS5Mp1ofNQ93MTS5kniZcdz+DoLLW24zjOC8JTpHRz2E2AyYB22okH5zkSRShG8b hGcSjVNKF6Wyjy55kYzqCofPMrrKQVfTzmYE+EVGojSlubTlOcn5Lx8y1KE0RY/CWES+iMkuiTxt X4zoCcJS1S93gRSkBYEky1hy8Zvg1GVKBepUbja0nAhFY02v+tAMdqpoKSofHolzQm39Z6x/mWYV rdi4IK1wqSpt6je5GcanivOlkKyrL3GG1bxqyHVamuhE7wjPeZY1MIBRDkdnAr/BOdJNDsoiQwJa S6kqUq5zrWkDrarXzF7JN1j6oCffKaZS5vGEu6un/BQr0pEacmRabCtA57rSzEX1quSsnmZvmyEu GeSTn+VtWNfnzMFJDYpPzKdRIxgQADs= ------=_NextPart_000_000A_01C7234D.A81DAEC0-- From main@friendupdate.com Tue Dec 19 01:05:37 2006 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwY6b-0004cf-Iv for ips-archive@lists.ietf.org; Tue, 19 Dec 2006 01:05:37 -0500 Received: from [213.173.99.2] (helo=[213.173.99.2]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GwY6X-0007fX-Gq for ips-archive@lists.ietf.org; Tue, 19 Dec 2006 01:05:35 -0500 Received: from LEJFKUT (unknown [103.120.94.76]) by friendupdate.com with ESMTP id AF8CD674416C for ; Tue, 19 Dec 2006 07:04:27 +0100 (GMT) Message-ID: <001001c72333$759f58f0$00000000@provasap> From: "trial" To: ips-archive@lists.ietf.org Subject: takeKazaa Date: Tue, 19 Dec 2006 07:03:52 +0100 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000C_01C7233B.D763C0F0" 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: 4.5 (++++) X-Scan-Signature: 86f85b2f88b0d50615aed44a7f9e33c7 ------=_NextPart_000_000C_01C7233B.D763C0F0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000D_01C7233B.D763C0F0" ------=_NextPart_001_000D_01C7233B.D763C0F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Faqs questions gnu gpl. Collect tofind lawyer case pro bono, supreme courtif? Onyou wind bysounding, basic human. Control mp market mpaa backing them = expose very. Moredreams christmas fade dreaming snow says david = phillips, fix. Agoit awesomebut, problemsi update bcause virus spread! Posting, rival spwarefree useful brave step replicate. Thats, luck pull = create, benefit. Ordinary print display including. Ofthe sorry basis, version, march san, francisco. Youve noticed, democrats being critical bush. Grants groksters request summary judgment motion picture recording = industries! Help defence lawsuit because! Protection meanwhile enjoy lower costs? Decided publish nearly, = identical addition covers, ofthe, sorry basis. Always makin prog bn better bfore secure! Kaaza charging considered illegal idea bytes. ------=_NextPart_001_000D_01C7233B.D763C0F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Faqs questions gnu gpl.
Collect tofind lawyer case pro bono, = supreme courtif?
Onyou wind bysounding, basic human. = Control mp=20 market mpaa backing them expose very. Moredreams christmas fade dreaming = snow=20 says david phillips, fix. Agoit awesomebut, problemsi update bcause = virus spread!
Posting, rival spwarefree useful brave = step=20 replicate. Thats, luck pull create, benefit.
Ordinary print display = including.
Ofthe sorry basis, version, march san, = francisco.
Youve noticed, democrats being critical = bush.
Grants groksters request summary = judgment motion=20 picture recording industries! Help defence lawsuit because!
Protection meanwhile enjoy lower costs? = Decided=20 publish nearly, identical addition covers, ofthe, sorry = basis.
Always makin prog bn better bfore = secure!
Kaaza charging considered illegal idea=20 bytes.
------=_NextPart_001_000D_01C7233B.D763C0F0-- ------=_NextPart_000_000C_01C7233B.D763C0F0 Content-Type: image/gif; name="fester.gif" Content-Transfer-Encoding: base64 Content-ID: <000b01c72333$759f58f0$00000000@provasap> R0lGODlhYAGQAYfqAAAAAHMAAA6OAHh+AAYAi30FjAx+hcHMt73ozqjS4UshAGsXAngpCZkmCLgg Dt8eAABEACBNDUtEAGFOAnk1AKFNCsszCt47AABsBRhdAEFdCWxlAHprC6RTALRVB+VkAACEChGH AjV6AG2GAHuFAKGOAL1yCNt2BgCtDi2oADKnDWGnAI6WCKKTAc6eAO2TAQGzDRnMCzHKDF/GCI67 AKK8Abu7AOvECgXlBhTWAkbeAGTsCYflAaDSBbfnDtrWDA0EQxUASjMBQmQKQ4oAP5YCM7EASt4G QgYnTBMdP0wtM2AiM4IrOaAiNMwhP9MtRgA4NxQ7Pz4+MlhMOIxMRKpKSMA1Rto5NARuMyZhRjRs TGpfOIllBateMbFqNetrRgCJRy1yMjV0M2N3NX14PKKNQLJ+O+CENQOaQimqRD6iSWqnSoejRqae QsiTQ+ehQQfBNhfDTjzOPWPFN4TDQJ+zS7XMPdLGRQLqSyvgPUjhO1jbRYbmNKDUSc7YOdboPAAL iCsAckkAf2UAdoMAgpgDg7YFfOwAewATiB0gjDcWeV8gd4gpg6IihbgpfdYReQBAfClHfDNDd20y fnI8d6hKeb40fNY/dQBojSldjjpZdmVqeoBdhKlceb1VhdphjgCDhhyEgEh7jVlyfHV8ealxg8J1 jO2OiwmXcyOVfj6igWSmg4uphZOYhciudOqSegDFhxHEgTG6dFjNdXrDf5rMfcy0huO7iQfudhjr czPaeVLkeY3XgqzReMDXi+bhiQAJzCkAsUcAtVwIznIHu5YIyMYAw+UAtAMbziEoyTMox18fvYsn x5EavsoYteQTuQBEwS5LtklDuFE1zohMx6czzMA5uNM1wgFUuBloxDFsv1xpxIFfwqZetL5kx9Zn ugF+sx97zER5uGJ/wYOFt518vr95zdKOtACnzSqiy0GtsVmayn+jx6iWvcamt+iVzQC2viXKyTfM u128snW5tJO0u///8Zetm3p/hv8ADgX/Bf//AAQA/v8A/wDw+///9CH5BAD//0UALAAAAABgAZAB Bwj/AO0JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypL1/KFOqXMmypcuX MGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXfrPpNOnUKNKnUqVItOrWLNq3cq1q86qYMOK HUu2bEKvaNOqXcu27UuzcOPKnUu3rt27ePPq3cu3r9+/gAMLHky4sOHDiOe6Xcy4sePHORNLnkzZ 7IfLBS9/sKe5s2bOmDOHPuh5c+XTqDX21LySNeuWr1XGbn0Z5WzIuHPrZnzbdW3Yv2UHF/6B+O7j yJNHtviZ4OfmBqEPlC6QOmjTqbNrJ0n9+WjR2Kd//68+/vr28+gNri7d+R9738VpxzcuX7n9+/h/ 9q59O2X//8PZFmB+BBbI2EXdYWYdeeExGF15C6Yn4YQNJbhZhNZlCGF5FHaY2HrzCVhcfyKyROJs JBqo4or27TfigCXWB1x8KbJo442Quejeey+WtqOP/nmG45BEFmnkkUiu5eGSTNKV5JNQPtnklFSK FeWVWGap5ZZculXll2CGKeaYgXVp5plopqnmmiqR6eabcMYp55x01mnnnXjmqeeefPbp55+ATsjm oIQuFeihiCaqqJWFNuroo5BG6tWilFYm6aWYZqrpppx26mlKlYb64aekEirqqYWVquqaqLbq6qui rv8q65mw1prXrExtoiuuOOrq6yYo+bqSsL8KO+yvKRUL7D/KNrurSshC++yx0bJUbbDEOgvstcYa y2yxLjVrLbjJTuttts5+S65MymK7bLnvukvttdKSq+273n6Fka8C8csvQf7q2u+/AxH8L8EDbwIw wvb8WhDDDQscscIGObywwBAnLPHECXfMccUSI3zwxgaTjPHGD4ec8cUdM+wyyh9bXLDJCq/sMVUi 1wxzwBR/PDPFOafc88Q0o1wsyzMfdLTGOg99Mc0tG+30zSMPXTLQKmM9NdUwC72wzzcTbTXUP6cM NshbQ9RTvvVSqy68br8NU77rrqvutHLHVDeybMP/2+2z6M507q59/70t34Dj3ba84SoO9+Lu4j04 vo4/3ni8y1W08stNl420zWErK/bYESO9kOiodx112KwjdPXZMZ9cetWuk6206mcHLXXPr9eedutP bX5v7FNfjXvOOs8ONfK4r35y081yzPPtoL8OMe2yVx097QkJr23ZvSPf/ffAO+W919GjLXTX4h9t Pfsyo+/w9NQPDPvPx2fduvHQ857/0uNLG+fAV7QBMu1+npvK+VhGP6/Vz3TE4xoA1UdB7P2Pab9L 4NN6Zzr3yex8oEOgAUfnv85BUHrNQ6BJFkhArVHwhaHTXwTLlzHuNdCBYmNIDVV3vQLmkIYy9J0Q /z9HNu6x7oYwlIrudvY8jTlwdzi8nxFHdkLgITGBE7SfBreoQebhj4seix8Mm0jEEoZRfC0kiU+i Fbi2TS5ehmMc5PK2OMUlbll9k6MbK0dHesktj3SMW+HMJTk+vvElbCScHRN3LDlyi5CHw1zc0NKu QLYxcpHDo90sF0h5sc1wgOzk2+7VxzxWsiWhvFvlJlcvcdEtlZX8pCIxd8m7tRKUp0zlTGzFy176 8pfADKYwh+kkXhnzmMhMpjKXWSpiOhMqzIwmizQygGpacyDWrGZBrkkQbm4zm9jM5gA24k17cFOc 3xznQcSpTXOyMyHlfKZqfGJNlNTTntVkyT1Tsv/Plezznv3kST//mU9/FtSgA+BnPgEaUHwmVJpo wUg52+lOdYZzohRNp0Aw2pCMIuScGY0nOrvpUW16M54V9ag8L9KThqokoOJ86UER6tCczNQlDH1o TWU60JvyVKE6BapPIYqVi6CUpBbd6DhDqlKlqvOoDGmqRiuK1G+6s6ofpShKTZrUlVYFqk6t6kml OlawrrOrWVXqVMNaVni2c6tcRatXo2JWjC5Vq2QtKTjdyk6pplSvSb1mW50a171q1KxzLUldmTpS qp5Vro5diF+RKlLGGrayd83sYw2bWKsIdKhADe1OXfoP0pLWoDTJpj4PStCHwnShBX2tTk9LVKT/ SJSpF81tWCM7VcZ2FLIG4exuIztYtr7VrrrtrFT2Wly9Dre3xwWuVX+r0rFOd7iCxSter6vciACF nUJNqGxL21eHxjamRfFpTMcb3vMGVbXsre1Vukvfisj3vsipr373y9/++ve/AJ4KfgdMYJgAAAAF PuaBVXLgBvtkwSlpMIR5MmEGIzjCEsawg1si4Qt3uMIJ9tJFJDyQA5cYAAkxcYobfOIWV+TDAiFx jFE8Y3uo2MY0JsiNTXzjANdlxznucUGEfBAgu3giMh5yjpWM4yMfmcdL9vFcjFxjhBDZIFRuMpY/ HGUcX/nKTc7yk1EMYynHJctE5nKXx+xkibB4/8tFprGYq6xlHa/ZzGBB853rvGI2WyTJdJ7xksus ZEAHGs8s/cmEF31hDjf6JYzGsKM/7JIFV/jSj2YJiDWd6X9sOsRKyoie+7yQUf+ZzIMO8p7rnGY5 qxrR86Rwh1Ey651Q2tMZtnWtcZ1hLtN6w7/W8KN3DWoRTwjMsJ4rspPN7GaHpdjQjra0p01tXHVo 2c6uy4NzzetP12TXxNYJiMONa2F3+tcb9nW18RPpSFf63MEOtrvFPet58zre5V5Ju+G9bgJZutHe zrdM/i1pegec0RC2N74J3u9QawTKbbazQyB+aEF3eMvIVjHF58xqVBs622oDSsIB3mk1G9jDJP+X NbxHHm+FC3zTAW+4UkRt6jiXuuYUAfSbvSxjQtv549gGOUiEzPGIS/zofD6xzyWu8T1/edVJj7rQ R9Jqo1c84kWHCMSXXfWKN93qUz+LynNN7m/fuuxmJ/utC95tCwvbwsCWuVauDfWw+zLods+73iUi 977/ZO+AD7zg3Vz3wQu4J+Dmdk4SH3d661vxAu/2ytWOdr8fZcSvzrrU6UzxzU/84lROMseNjHfD b6TzGS98mF+d853D2c9RJ73qTU/zjpOaIahfs5ox7vRUw57NS6f9w988ei5bmfisb32XDY1zzi9/ 9sKPSO5vf3Pbn/rpSOf504EO/eg/ZPrH/7z/9Qt9cZt3/eqe93r3vR/+Gms+9S3WvPjBf/XiO5/9 J0E8tys/E8bHfOD+R3KUN2wCSICNZ3kzRyGlh38iwSX/h4ArwoC1AoEUWIEWCBQSCCsXuIEtkYGv 8hP5EIIhuBIiOIIqUYL5cIIpCBMoKIIsgYIp0YIkCIMqWII1OIMpaIMxOIItSIMuuIMryIEugREi aA8lKBBFWIRIGIJGyIRNyBBK2IROOBBRqIRV6IRXmA9LqIVbWBBJeIRdSBBRSIVTKIXNNhQu+IP/ 8INpaIImyIJviBJquIZuGId1GIR0KId2eIc4SIdqOId++IJ7iIdCiBRtGIRsyIOKOBOAGIh6/7iC jeiIgkiIgQiIh5iIhNiIcxiJhdgUHPGFXGiGZviFDTGGYSiKpniKXliGXWiKoPiEokiGoSiLYsiK eCYUNviHfAiDNDiJvviIQDiILqGJipiJxViJcSiJQHiDncgSn4iFU5iFTIiCsViLs3iKrgiGqaiK rciKr/iE2XiN1biN3peFtHgQ05iO4liN2GiL3biO7DiK3qiOWxiOBjGG5Ch8+BiN7giO9HiPtliG 5PiNACmOBPmOsjiPBimQ/ehjIJiMukiJeYiMEmmJwjiRwKiMfLiMykiRwWiMEtmMNUGE7niQtYiQ BZmQq8iFVsiP0BiKLTmL5jiO9riS1niGPf/Rg3eYjDtYgzz5iL34kUDJkzLok0RZlBppkZS4iT8p kk75lFC5bh7oKlFZlVZ5lViZlVq5lVzZlV75lWDZgVM5lmRZlmZ5lmiZlmrpkGHZlm4ZKWuZKG8J bXFZl3Z5l/Q1l8WGl3+il6DGl4AZmII5mIRZmM/klyHmFPwAF4sZEo1pmBrxmBQhmZEpEpR5EJcJ mQiRmRDBmRbhmRkBmgIhmoPnE/xwmihxmqiZmqqpEq25mv/QmqzJD7EJm7UJm7KpmrQZmylBm7uZ m7zZm8D5m7j5mr05m7eJnHq5EYv5mM05EJLZmNJpD85JnQRxmdWZndBpnaPJndt5mgWRndP/2Z3a SZ7XuZ3eZ5rGmZrB2Z7B+Zvt6Zu76Z7syZ7z6ZvHeZ/vuZ6umZ/HaZ/+CaD/WZuIaZoBypv6+Z/w maAEOp8Dip8CiqD+qZ8OWp8SaqEQeqEaSp+2WaA3QaEH6qDwqaEiSp/xeaIgCqAp2p8RuqIZmqEm WqEeahO6eaK3WaLvqZyySaDCWZzE6aMQWqMyWqPuuaNEeqSriZo7OpeAIZqk6RBPKpg9oZtUWqVW eqVYmqVauqVc2qVe2qXLqZliWphZ8YA3cYD3gaZLYaZtoabThBGgd2edt2Kuh3RB93ULSHXrl32E pxB4uqcNUX6vl36CsW1mRxMP6HKchm9r/8GmRhFzLHcUiZpyQ4J5r9dzqGZxTEZ+mvpxR7dxOxen TddqyDeqrmaqSneqmcpzFqdqX0dqoApkLIap55eqnVqnS1Krq7erx/eq9OenyMdkf/p8mwplruZ+ rDenPQaqWkZ0q0qnx8p0x4qrpBqtv4oY+reokldu/8Zv8oZyL+etb5dv9QaumNZ4LOduDCd5CAZs 7tqu5gqu2/p/aoduDLeu2/pu5AqvbKcmMMev3Aqw96av6UqpMVGvBfutBTdu8bqwAvtp78qvCRuw CntyE3uvDyuvjrav4UooDMux+HpwALuumKavFYuxHRt5IEupJKuxkUdwFzuyMmuyFFuzLf/LqI+3 sv3qqLlBc7OqqplqrM8XqsGqdOgXerSqrMyHqT8XrZrKqlCLqs0KtFPbflNbqkpbp4LKtEZLqHtB JDx7sOKqrcoRtienFWYrTWnLaWa7tmnhtnA3tkQBtwcypnZ7tx6Rp9IHqHjrFHEafnn6qnCmtzeH qy8GdX9KEoKruJ7aIYaKqHKrrd5Gtxu7FZG6pi6LFJTrsSWHcjELqfKKsDOrbpB2bgNYgPa6rx9r sxHbrZ47tvuXbrEbqaDLtq/bupV6aoOKrLyKe9QatKu6dc9qc8UavMbrZbzbq06bvMa6u1YrrYcm tcDqq8CbdISLGl33t83ru7IqvFXrvX3/RmIwNqw/G3+9R73l27va57tNe7zri36AO63V+75TUnWJ K6uFa63Ve7/DO6hz+r1RJnvQyrzHi7T5W2XMKriBW8D7u7xN4qwAzGeLa6fyy6veO8EIzMAEbHtc l3kV3LvUe6kabMGqCnYkvKvM6rV6oWi9drsUG7s0O68y62Awm7nmlroc23YpC3kL58IyHLc2TLst 3HJDnMNAPK41bK82jB9wcb1wyrdmUXpOrLuMGyhTTMWA0bjOWxJX/H1QHBczOmB9+yZYsbmLF7lh bB9u2q8q+6hoXCRmLHdrjLNXEcf5Ycf9hrG1tsevq8ST5sP5am4I18c6DMSDjMM8TLoD/4jDbVxt TxzBCTzC8Je41tvAyKq/wjq/2zvBFyy/mKzCARbJJyy0Kdy+EVzJKPzB2hfAlgzCgsq7otyqDrxS +leuL9ywq5vLo5u5STyxjaywKKuowLzLbPzLIrlvtzzMJ5tpMWvEyuzLl/vMDUvEOZvENevMfWep sAy8Rcu11eq+r5zKT7usv0vCi8t95ry8ovfFrZLG9zXG8BzP8jzPQufO8kXPYGLPtYXP/MyA+vzP AB3QM9rPVCLQzETQU2LQCr3QxobQHsLQEB3RXOHQFF3RFm0SEp3RGr3RMnfRFMLRIB3SPeHRJF3S Jl0VVRqe4GkQVsrSVKrS0amaCiHT1/+50qOJpdDZ0jCt09Rp03aZpTmdmTzd01ca1EHtpD5N1DVd 1Dc91ETN0zR9l7pp1E2dEFF91FSt1E/NEFet1VVt1TY91VmNmUkNeD+xpKzZoy+B1mjNo8n51jHB 1rbZ1q4513Yto3WN1wtN13m91h3K12oN2Csh1yLaoYN9133t13pt0IKtnC2xpI19o5Ht2JQt2JCN 2IrNpBfR1WTtmVfN2S4t1g2hpUud0mP92Uz91aU5pYbNEoB92Yvdo62t2Fea11Wa2HA9m7et1hkd 2a+N2TCx2zNB2Lj92Fbq2rNN2WGJEaAN02Ad06Tp1M/t3GMd2qK91DNd1mnZ3Ni9mT7/zd1GDd7d fdraHd6cDd7iPXXqmdzKXdxEmtm5Dd+83d6J/d70Pd8S3dY+Kt/tvd83KhPEjd/IfZ9/zd6IGZqi HdXc3dUvrdoKXt7jrdpe3dkRnt60BxRZKttUKtl3fdyVbeABrtvCDdsEXtv3DdHCLeJCmuIqftiF zd4hzuHvTdg/6uHxDZYnfR4iTSqb/aU+/uNAHuRCHuQ5XuRGfuRInuQMseOfouSWwuRQHuVi6eRU PldSvilVLhlXvuVc3uWPkuVgHuaQ6eVkXuZmfuYHLuZq/kto3uYCveaE4eamAueFKudsQud4nudk aed3rud+Xil8zip/zheBXuiGfugOjjfot4LoXaLojv7oecfojQ7plK4nks4llZ7pmi5ll97pnv7p PLHpoj7qpF7qYQ7qqJ7qqr7qrN7qqm7qZeHqso6AsF7rts7ms567t77rEpLrus7rUuHrOALsVCHs xk5txJ7s2XHszN7szv7sI63s0k4Z0F7t1n7t2J7t2r7t3N7t3n550x7u4j7u5D51AQEAOw== ------=_NextPart_000_000C_01C7233B.D763C0F0-- From Page@cam.cornell.edu Tue Dec 19 01:23:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwYNv-0003yJ-Gy for ips-archive@lists.ietf.org; Tue, 19 Dec 2006 01:23:31 -0500 Received: from [218.11.199.106] (helo=[218.11.199.106]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwYNl-0004Ps-7o for ips-archive@lists.ietf.org; Tue, 19 Dec 2006 01:23:31 -0500 Received: from [102.179.145.80] (port=46410 helo=72701877176F49B by [218.11.199.106] with asmtp id QruZqQ-2d5D4D-00 for ; Tue, 19 Dec 2006 14:23:41 +0800 Message-ID: <000a01c72336$24fa2d50$6ac70bda@72701877176F49B> From: "Free" To: ips-archive@lists.ietf.org Subject: forum has Date: Tue, 19 Dec 2006 14:22:59 +0800 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0006_01C72379.31A72100" 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: 1.3 (+) X-Scan-Signature: 7191030d885084e634ab0f488bcd9d53 ------=_NextPart_000_0006_01C72379.31A72100 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0007_01C72379.31A72100" ------=_NextPart_001_0007_01C72379.31A72100 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable And dont have an account herelost aa, divx codec. Separate system will and. Vobsub virtualdub powerdvd windvd dvd = regioncss. Have an account herelost aa divx codec. Viewed times email me whenever, = this gets updated send. Powerdvd windvd dvd regioncss. Forum has separate system will and dont, have an. Shrink links link us, newsletter privacy copyright or content. This gets = updated send to frienduser vote nowuser. Newsletter privacy copyright or = content is strictly. Your categories pp file sharingsub. Usddate addedjan last updatedjan page viewed times. For release date jan official. Other users online much like, napster but without the! Have an account herelost? You share files with other users online. File sharingsub allows you. Me whenever this gets updated send to. Newsletter privacy, copyright or = content. Virtualdub powerdvd windvd dvd regioncss. Whenever this gets updated? Edonkey software digital digest top. Allows you share files with. = Frienduser vote, nowuser your categories pp, file sharingsub. Note that = forum has separate system will. Links, link us newsletter privacy = copyright. Usddate addedjan last, updatedjan page viewed times email me. ------=_NextPart_001_0007_01C72379.31A72100 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
3D"VobSub"
And dont have an account herelost aa, = divx codec.
Separate system will and. Vobsub = virtualdub=20 powerdvd windvd dvd regioncss.
Have an account herelost aa divx codec. = Viewed=20 times email me whenever, this gets updated send. Powerdvd windvd dvd = regioncss.
Forum has separate system will and = dont, have an.
Shrink links link us, newsletter = privacy copyright=20 or content. This gets updated send to frienduser vote nowuser. = Newsletter=20 privacy copyright or content is strictly. Your categories pp file = sharingsub.
Usddate addedjan last updatedjan page = viewed times.
For release date jan = official.
Other users online much like, napster = but without the!
Have an account herelost? You share = files with=20 other users online.
File sharingsub allows = you.
Me whenever this gets updated send to. = Newsletter=20 privacy, copyright or content.
Virtualdub powerdvd windvd dvd = regioncss.
Whenever this gets = updated?
Edonkey software digital digest top. = Allows you=20 share files with. Frienduser vote, nowuser your categories pp, file = sharingsub.=20 Note that forum has separate system will. Links, link us newsletter = privacy=20 copyright. Usddate addedjan last, updatedjan page viewed times email=20 me.
------=_NextPart_001_0007_01C72379.31A72100-- ------=_NextPart_000_0006_01C72379.31A72100 Content-Type: image/gif; name="Categories.gif" Content-Transfer-Encoding: base64 Content-ID: <000501c72336$2383e100$6ac70bda@72701877176F49B> R0lGODlhUAJcAYewAAAACokGAgB2AoKMAAAKgHUAcw1/hc7NvbjOvK/D5kUbAGYsAIgsCaQhAL8j A+weAABJACdMBzZEBmxHAIpMAJxAAMQ2CuE1AwtlBRdrBUtbAF5nAHdSAJ9aAbtnAN5lAACACCWG A0V/AG55AImMA5t0AMh/ANVyAQKsDR2rADqTCWKXAHKTDKeUAsOTAOWlAAfDAC7GADLHBmDLAHXI AqmxAMy1AeGyAA3fAhzjAEDuDljTA4foAJXlALbYAObaDAAASykIQTYCM1gFM3QASZMNMswAP+UG SQATOiMtRUQeTlwZN3sXOKwYS7ErQdsmMgA0OiBENUczOGI8Qo48M5hMQ7hFR+ExOQttNx5pS0FZ RmJqTXJaBJ1YQLVrP+lcRg2KMyx+OjGNM2F/N3tzMqeIQc6KO9N5OgisSBirOEeqNmyVM4uuRpqn N8OjTuOYMQC3PiW3MTPBO122OY61QpvNR8rEP+m5TADSMizRPELcM2bsPnfiSa3SM8jeMtvlQgcA hB8AjEgAeGYGe3cBhaYKeLUAjuwAgAchgRUqizceeVwXjHgRdaMaerQsiOIjggBOcx9NjUs8jm4y g4EzgqM/c7VCjuYyfwBgfSJddEdVflZig4RddKlScb9RiN9hegB7diGLezJ0el96eHd1iJeOcsh7 fuh1eQqpgRyljjidgFWVenSRgailirKih+uleQvKhSLHeDG5dFTChIfEdJ+3gM3Eh+LFiQDqfxnR ikrdf2nghIvpg6DVcr7kcerrhQAAwSoJxEEIzFcAyYEIzJwAt8EAs9kDygAcxBQsuUUow24RwHwk zZketMgjt+YrwQA9tBhEtUA4wls2w3xKypk8tb5Eu+ZDtQBbty5dzTRsvGNju4VmxqpYxcZlxuRX uAtysiaFyTF6xlSBtHJxuZaEuMJ6vNJ7ywCkvSWpt0idxmaVvnajwaqZuMCTuueZxAPCwRzJzT3I uVG0y4q2sZbCuvHt9qKalXdxff8OAAD3CP/0AAAA//EA8wD//////yH5BABKsrQALAAAAABQAlwB Bwj/AGsIHEiwoMGDCBMqXMiwocOHCOfVmCeRokGKEicOtDjwWkaMGmtcuyYSosmTKFOqXJnwlkCX LgnChDkwJsubOHM6RFCDZ0+fOoMKHUq0qNGjKDMStIjxo0amGElK9MjxIEmkWLMSnTmzZo2YNr9q HUsWKFCyaNOqXcuwakiiFeNOdCqQY9O5UOeOLLmXrd+/X2/RfClYrNjBhQErXoiAp+PGPQeeXUy5 suWGSvEOVWp3bkGn80aGDr13NEWSqPteXj0UbFjBhWN7ZU3ZscDHBH1Ops27N9mKTzln1pl349Pg VD3qVS5aJGqBI6/6nt6w68vDsWXbDEt9rO7bt3Xb/+5OvnxOu02FEwfJdOPwqKJPXz1d9bl08/gD v56dOLBX7vkZdZZtjT1WYIAIJnjRUm99NNxK7XEWXIQZKQefaaFBp6GCCtIElmH99cehUOPtViBk 4I2oInlVsaeZUXG1iF5UetXFl0ZX3eecjitStp1+sL0G23U9DvXdTylKVuSSvsXYXoNv4QRcSC12 RBVeV8o3lXPQqcYjk4B9COJ1XNUkIpgoTXZiQZCNh+abik0JEoMPqvSkjXRpSJVFySk30X06Pgfn X0N6aJhMMrk2KET9tPkdikjutuikWr1no2fGnfeZcVCBxJyFMd6Y446qUYpWYoYWGiRiRKJpy6sC 2f+SUD/9RBZem7bitqapvBblIF7AuRilppkCJxWwTF0ZXUd8AdprWoMhKqZ/Q7o6kKyvYlsQrZKh CGmJt9r67LjrSeiZcHXaeadcHXlaaoVdFmQfuWStaqa0ZgLYI7ayKkRrrd3+hKu44dFrsJTHYXrp lHAFq7CfcpF2LJfRCcrlwUgB6GG1pmobK6za/gtwwJBG6qaSGKeclLnpzXleXqDVmOGfTqXG7F5e CkTPzjrTU4PPKqf0Y4hifsixivx+nC22tNrST7+5HYSro+It+scfNWAddEoOznhcnkLd1Vl09IEK aMUb2tzzz2wPBPTWD6GKKoghwtnv0gQ1/TTUbKr/maKBB6J59UBaw23nuXIuDJd7wk4FMc0Zpibd 5CLRcxXQPGO+89uGLxSkf9gR5lq0+/It69N7e2zQkY9WPejVhWuNNeydY4ZsXZamK6XYVHokVYRW drksQZZz3jbPxxtfu0HZHV20fkXyXQPT/zo9ckLegudt4GDOTjvsg2cd/vIJuQy2W77SqVRpNEtO MUGXX/O2z/TTn7zy5CdaaEEck76i9E57FeruBqvprS5JSQqcpFhjD5PMziCDk13W8le+hLlId0GJ 2V32xJFlDW9UqMmczn62Ocy1bW0UlJaqiCQb0JVuaU3L1t6mV0CE6IpAAnsT7SY4wQfKrnApPIjD /9hyFzxZCWc2UxvONkcSzhkPeWzDH/nmNjrt6GtE2aqB3kRWK9PRsCGAW2BvGviQ2BVkfGYMohCB xaC0/CokOINfznK0M/n1BYqZs9/apLi80eVLRFdU0OlkKEB+JY2G0utbwU4mOPGdsYc+VGMFXaaY JMbriDtK2+bcZkI9QpGEkiQTYQ41SibpTYADjBUiE8mYguGHjA4BIhAh+UBHhpI8HrSPB0vCy+JZ jnigNOEISbjJWx5GlP5b0SlT17QvXutji4KlA2MHvlqKb5bGpE6p5Dg5O8oPhcgLZx7nl039wYmL MASZ0u5mwGhOUyDVvKYtCYLNcq7GWWi7kXNKGP9FfoKyZ+QUoT0HxcUYBpCdBcRbO98kzTLC8yAR HB8PB8obEMbRWReL4j812klPUvRNBa1eKqEGwGfCqaGxnCg96VnLen60ojkaHjE5uUcnChOgn3wp h0KKzkSCjJ0LRRNKy2jN8MlynjpNCwAA0BAQOkceUJXHXvwpzHEOc6YnrMxSk1qDrTZkqTzl4ipJ +kxWMskeQ2VIUb0nQTT6ZqlwXYhXCwLXuna1rky9a14FEle+2tUgePXqXBky2IEEdquF9StCSCKP GkjVsSUp4VKVJ07N1Q+gazksUxN716/21bOfRQhnH6JZhxzWJKPdFljD6lWgkhRvZu1RWiHS0gj/ wlOivJlrajsL2L0adq+IHWxfdetbxbJkt8ItLkMExViByMN+k9WjQS7LyXD+JbnHVW5CiJuV3R7E u3LVbt5otVqeDladSgsqQ2er1tuCj3CzdCllRotXv4aWtwTh7l/tCl7OBne4AL7vb/NbX8UG1rHy OHBjoarX/251Z/XtKz0KHOH9Wti44DWufT8rWAFr+K90FW+BO3vgDae2sCMmcG8NPOIO97UfgSVv XbnF2dfWcFDsbcgOjXpbpNLGv8DNK5BXzGIXb1a8Kl4xh4XMZIUkt8kk7nCCmQrVrUKVHs+9K4SD bF+9Rlln//0tl1mMYSSHmMBQDq6Gk9xhIp+5/8xe/vKa3/xh5QLZxXAmLowB8C+wlrfNBzkkpdDK EmqulHDUGTKce1vhC/P3yIQtsZoHTOfv+pa7cr7rlKO61MY697mA5u2D2xzdCUOa0nU2sYdFe+kx T3q7UGa1pSn96lojGbtzbnCAY03qvO751zIG9p5zTS9C36SatvWhfLXKZAcDeNaVLjKk+6vdV28Y 1dBOdaY7beVNM9jTk8VvuMcNAJ9NNrqZxq+4m53i8CZZ1OyW9bWJ/Ghan3rbt241tom9bnvftc98 /nPAJW3mXhlbJ9T0Xnewq+hoq3vR1pb3mekb62z3G9/9XrBjTW3uciuW46b2K8jTjWt4l9iz7/8O NbETy3J9Y9rWF7c4pt+NZl43WeDC9jOfyXdwhCPbx73Rr6urbeeiQ3zMNB8wrlXu5ovDvNNTBgCD natlkIec4/Dud8nXbQ6/dn3rTX/5qRXN9FSLXevNhnXKjc5om/s15wOX8cD9fRJ/2N3uK+q5UZb9 YwqDOM77frjgievhIaM4tKsuea8HHPW4ehrLWz4yXHk2aqaC3O9Jx2vXa2COpZqj8wD4PL/XfPYG W9rIsLbwkp2e4ngIJB7xWKrrxXznekcZxKvFK8BnvOfVO+TuwL/7iPTOVcN5uspUnvpG3RbMjloV JV3f/OenT/3Nj2urhYnHLWBfA+4TpbBhDf//9VAS/PIDX0FozXHxVdZYqHu6n8y3X1VHKF2IUJ/z nI8+/vOv/17Jfvuf030FMXs4MVfiF34qYX4KeH4IQnzr1ysadxCNl3zv13z0x3zVtXwpEX3St3/W x4GLUl/bp31Asn2vNxAEuBJbdYAIaBIL+ILBFyAOKBA+4AM1YIMPuCQLFoEIcXyQVYE09UQoFEwr 0YGit38FMX28Anuu5xLap30z4XpMyH0pqBIsGFYQAYNaWH5ocQw14IUrkX4GgYM2WIY4mIMcUoE+ +G0GoXwIIU4cZVl89BBKiH/VJxAfeISmAoVQGBhMaBNSKIUrcYVY2BBbeIjmhxXHAIZfOBCL/3gS DniGA1GGaIggUfVpCPZtO5gSeJSBRLiBdqh/opiEdoiEaXEAqHgASAF7sPGE3ceKQzJ7VDiIhMhT C4GIuKiAR8GIArGIXviLECGGBFGDk3iDNGiMB5NhEocUf5cVx/d+EQiEEFFC8oeBoDgQoud5oViH 1aeHFncTqDgQ4biKotOKADhKVBiIVdgQtWiLCJGL8LiARAGGv+iLjQiMvKgQkXiMlFiDkjgpmJcS yohy3wgRildXC1ZaPxh1DOZstgY0RoZuM1d7jyZ6HGiRSViHTRdpshaOqigQqfiRuiZmdKduf3iO JfgVJCiAgcgo7RhSBxGPMimPDyF8NeAPCv9hj/XYi/jIEMJYEJLoj8NoKkKnEgPJkQVJWvqWcb91 iWzoeFM2eEg3afSQAEuVAFY5leL1dUw1fYkFghdpihvpbgcRkqo4jiGpbb6Had4HizDRhH70igQh iP7ykjA5EDOZly9oiDd5kziZEDrZiILZi1/4iAnxk8NIhsboj/84KBQZZEsWV2U3kmh3X40WkWF3 b4oFblIHSeKDkFHZcvMWXFhZmjWQAJ2FlTNHEJunjaoWfZpnhKC3lqrnbCt2AHaVijWgiodnelmX a3yIjn4oFm3JhHJ5EHZpi3q5nDCoEDj5nAyId45ImIZZmIbpi/lYEIhZjJR4g8TYnSFIdDf/x2W9 2XAwJ3iLdnvLaG1R2ZBMdTXyMDvxiZDpVma9hpqnKRCqqZUIwZXSB1f+qY2gh4fSZ32LV2RJp3RM No67WZ7PdnEECBZQaB0vkY6yKIAGkZwhxZwcqoUxKZ3PiZcCgZPZeY/XaRAlupuRaIbHuJi8Yp73 FnHNiGrnSXFml28HNlibBlleBZ+yE1yhSXCm51VZaVeoeZVHCgD4yVmw2ZWft1VPGnqu6ZoY6W9F maANCgC4mVdneZZZOnHT5nZUaIKuKBsrOYLraJwDoaEb2qFuSpN4KXx/2Zd9OaePCIwEgaf3OJgE gYozSIz8yJ2UAqO6JqMnRp5DJ29XKnOa/4lf7YlgE7SjthdiqEcQpXmVd3WpSMeaUZp/vAV6s1lX Hch5QnpavVkQvMlUW7pUurmbWwqmozlm6ciSLcSSF3qcKKhFbFpQevkvb+qhcTqic0qnfkmP1lkQ eqqnBiGGIjmGLNqYAEl0CrqRM3qjJflmi5qZjvqonRWf8tl+VDapNTdvqImfWXma5ToQ+OlZBhp6 UQqq/ceaZyeaWHpXDMqqXvpwk1atA4ihZNqHIwiIaup93berXCST/QB8CbuwCfurulgQcmqTeGeP hGmd2GmiFOuqIdlArTqULiqU/oeo00pmKkaoeIaev1mfNAdoO/pbfxCf4pOQAAA7kime7P+WpASG s/tZrl/Zmq3WpBenfyf7dMVlo6HWpaUXZ8RFsKzYfSZ4jq44l7gaDwZ7sLnYsA3rD74qMg6ri3j3 l3N6fnZ3DP5grMeKj3d6rLspEPbAoM3qrGYIreH5oCZHePtqs5AZmW4WkIxKe74FrsrmsuAqebi3 lKqmqfpJpEzKlfxHXFEaV0folQHJtyR5ZqtaXB7ZYpBZZ8aZgm8Zi6/XuXlDtf1AugYLj1xrdwyr tazbtXv5tXQKndRprLQ7u9MJkgfQtjOYmCBbiQmyYDsGWVT3st7jhg1RmliZn+uanwWxvMubEBrJ jQXKqWMhkh6pmx/JoCshi+rotAEbuqH/a5ylC3ulW7V5mbVam7Xoi76um4ixK6wkuqfVWbE8abZn aWwdexC967vm4ZSNhWwv661a87/CaxLPa67Nm7zlmrz9eRDR66meOr3xahRmubZrm5Y50ZaveKsn yL1TSLogvKszubqty74L275eS6ywW5gVq6xqK5iM2LYeiRD5yr8KEoGwA7wB/G2DA7PSyBALrLxB rMBEjK4MUaVgOarYyI1H8bbZC5IXLBQDixB0GbrlSytUS74aOsKte3cnrLpejMLu+7VhS6e1a7Ew fLtsi1Zd2rFObMO/+2k8KJ8B/D18dxDIi64MnK6mqZ99zMAZ6Y1LPMgRDJZI0apu26UW/4wTU4ih 4KumKMiEIhPCW4ywCfsO/vAO6+urYCzG7iuiIeqId6qso/zCNcDGZKS9XrrKcBwgFRg7nka8WcNg 1sQSf2yufazH0IuNpdh/EuyBYlkUb2vBaKkTTKuOLfnB5Gu6/zKFdimT7xDNmhzN/SDNtMK66su+ nsyFwtrNFoun9BiYMcysDGqRejjMrdy/O0jAs+xI8cmGD7HHzLvHCKyfBgHIS+yNsmnOERyKWlHD UIzONzGrcymIrofF4xvCzvzM8YjJmcywmKzJqhtW25yIIRrK05m29ZusBJF+aXUA5gDSIQ3F6XwQ 6qcY7yfLxKtxPopbxyvEymvPMC3T8//swGIZuZwalgR6ilFcFC0JvhucxQjNRczMzIQ4k9JszdfM ug7dyVhb0Q/rl3bKwhp9uxnr0QYRfaqohCBd0od50oABVWzVQ9fkoz+8EAgcxDKNz0as1lmt0zn9 gYVsfdWbrwI90B58ggIxvpPM16eL1HcXzaob0RGdvpz8xVAdg35JrFSNsYGpnVgNwYYs0iF91yW9 u5eRbPApwAVswJaqrn8M0/WsEBjZjaI4wXDSuR+MxUJd1M3M2rWYlw4tzXY3zZk8zak70YndnCia pztpoh29nXQd0tJH2XTt1cHdG1G12XUs1pd4Egrsx0Z8zwtsms9L2vxX2vy33YuiwQr/3czLrMwv KdvAl9RaS9izjc0nrM27PawHcbE7qaweTUZKvNPUt9XIjRDbWRksDUnAe9bHK881zcfWDdoOMYoX 6cvcndpruszlK8mS3NdGHX7LSduz/S+YfMnUTMLs3d7SiRAUG+LLut/diLsjXYr5bdKY/RfROBDG ixK5HNOWWt3qauCkfX/biIc7PSn+0Nrh/dpADttXyKGFjd6GrcnZvLUeHtWAibEjfnCCfJEg3arH neLBveIsrnEADuN6PMT2nK4JfOCsSaCCvChePOEQ7tdEfcUH2KFN7cUaTtuZnL6G3cVLrtgpMd/5 rIdKCIJW7pP7/SZgvq71XODRTdML/5HEOo7iYFJ+BeXgCZ3FIDzh4vemSW3eD33J6221d/7JkCjc iz7XHojafz4Qkb0o+JzHCEHjbH0SVcokCvjosL3QlD7kXVvk1azh5y3RWNvhnf7hwXjqwFzlTBzq pQ7Zga4T7lADy+4Ozb4WRTzTgz7dYG44CxhWQg3ea67FbW7ptX3bGy7YSP7Uv36IJqHnpHh/pZ2H wXzsayzsN+HsAiHvzv7sy54WBJ7qzLvW+64yMMiCppvtPm7rDnvpwYfeDk3u5b6XD4HuZK7E2v3w 7v7V8J4S9H7v9z4Q9c7saFHgXb7v+e7vWqihrR3b7Wvk336wJLzwwArowl3f1LvjVf8+8abu8CqB 8cwu7wRB72qBvISuyweMMYdYteMtxoId2EUu2JzM8ua+EOlHxHnMz8Y+5jSvj/MN1gVh7xuf9fOe 8xlPFj4f8jVOL7hI9EVv9Ehv4XPO9DKpj6UJS4OeABoJzPZd9U5/9Seh8xm/981e718P9tXe7waD umZv8hU922rP9nq56gng0YDs812HmqNI9TNv91du8wmB8zjf9RyPEH8P9kLc6pQSj4Xfjh4u54rP oSaNlWjl822NlZGrzxBs+XeP9wpx8Xyf9Tzf9VvPFqo++pZc+ked+sQfjzXO+vbQ+DKe7wwM17Qf 7LZvEL3v91+/8VqP3L0q/IZf/Nz/j4hG3Pqt37x+LPeSP92DXPnP/+TRv/MXr/Fe7/l6//nFt5za v/3df/9amAA4GfasrsvoChDmEtQYWMOcuRoJFS5k2NDhQ4gRJU6kWNHiRYwZGdrj2NGjQncgQyYM 6W6kyRolT5JMaXKkRpgxZc6M6c/mTZw5debs19PnT6BBhQ4l6nPnUaRJlS5l2tTpU6g3E9z0OLBg AqxXCRbcejABwoM0xY4lW9YsRo9p7TFUSfKlS7grz5LtN9cuxKhJi+7l29doXsCBBQ8mrDRBR6xb EyZWmNiqV4R3JU+mXHmh2o8oF7YFubnly5aWLfYUXbYwTr+pVf883dr169ZTZWPl/7jY8eLGjHVz Ld3b9++JmDm6W/s5NEu5b1MuBy7RZ/OLsP2tpp5a+nXs2XfOnmrTsVbF3wkqJg/d/HnRauM2dOm2 ZGfmmkGjf46+Ifbq+flq598fNtacALRqK6uuMtC2Ae1TcEGzMFvvs/ZQWknC+eajrz70stNvw6H8 yymem+IR0UMSlwLQO39cKmikARnDLbzxGJRxRpjUs4e4G9tD7rjQJqQxIaCa449DIoEqUUQkbQJx yRKbxGk2f6ZyR8ApVwQtq9sKdPFHLrt0yMEbw9RRsx15dIvGoETzr0g2e/IQSSb9AVHOD50sEcsU E3DnpilTNHM8rW7zclBCNxITR/+TOhpzs5PgYu7HNCXzsM02/Rvx0hCVxHREO+2sUjYVTzpw1C0L NZVLReES80aRWOpMRy+FMqtEStl8U044lcSVUzjn7FS7E1N0KU/v9tRzoaxeTPDFU5uVkTgcPUoU R/eWixA5CxkcaiYna7XV0l4x1ZRTOsv9NTsATUq3O5OE9VPPKWNkqEBn62VQpWlzjJZC98jkjEui MrLT22/58xUnXunM1Vxcz70uqz3blfhER9vbEstk7dXYvjAV9Vjff619b9CAJ/qV4CJvZTLOhpdM eNeGHZZOYpza1VPPFIUliTfdNvbZvPc6Fnq4RIuD0DhTi3LIYZRTtjTTOX2NWuH/gxFmWObCbp7S 5j2jvNldeHkDFMafyxZtQmlzVJtoVyVsdq+EZG7a6aepltrcqHMNt2qsA4O365xzhitPruPFbVmz EwdOVaGhdak4Muvd7+S5OXTyUpeT1LXXzfnumzCIKWY34r+FNVZZ8BRX3bKRDn28Y0QfdHbyJisn ssmpQ5Q6yaoXzv1zwrbOGautiR+9SmEFHXt15u16UD1oiY5d4+loX9P2De0kt/Nxuy935UyBByxi mz41lvh2CTdW3SzLa/79uUpSO9/HozW6UJ386g97y3F3OebcaY5XAsyc+AIzrChFDHBcC9vWzhcj LMFPgmJ5z0lAdqhVFc1LSrHO/3X4l71zrQx8MENY72JmwPElLy6Ck02eIKYuqbhIbBOkYUYqyChE 6YtosHObfZzSQdd8EISdEhfmjKgp7m2KZSh8StgSOLxhqYhYUfIaV0pVQyxeRDkqSdu+UlUbRv0m MEAcjBCHqL1NIVFh3SPXALfHxKewT10L/NuJ/pa+Ksori3u04Zlasrb66bAjEMrWXE6jGsGYUT83 kUcj5eGPR9ZtV75rmec+lDdLwvEocNGa6SAmuIk9KY98JKUWLeS4QA5HlUUDTSHFchQAAAAwq4lK T2KpSFraJJKOhGQjDfbGEloNgFBLWCY1qZOuSax45OsT+Zxox4yV8iGxpGYsa/9gTYdgMyHVvGY1 ATBNb27Tm98cpzXHyZBwihOd54xlSDgSS3tQc1rydNxy0ilOairknPikZlJi6Y9yAtSbNuln9ajp E2+yhqADFahN+nHLhwIAl/pjZC8hychIYmdqnEtj5v4HNd0dM45UtBnOqhTFZHaHiiuVJkS0qc9v ZjOmMFVnTddJ05felKY21SY2c5rTbiokngAYKgCiR82PDdWeMe0pU2fqU1kuFJZR/WdOqtrQgk7n oBFFqERZc9V/QhSitvTqRDuUE15iVJfg2tz3TihC3sXJmCJFJvpQ5EnTJU+l3VFpS2XaEKB286VQ 3alOgxpYmwa1pj8l50wTa1P/d8CzmvaIRzXzNVR+KRanT6VqVBu6k6pe9SZglWU1F3rLsRKFtALl 6k9Sa1aF4uSRs9WlIzN6nSVijo3hgllcdUXXpqTPpPAqn9dgiCKV5sSvhi3sQri506b+VZ2I1axm CevcxjIXsu2sZjwii9S4tPNajO3maDtrXtB6VrRSlappBYrasqpWoguN6GvJClsjyXa2tr1oRTWK xLuRUHd8O5jmgLuUlGIJgYXDk9eOslyYhhOo11XsPgGbznJiF7vPre5hHStYblpzJNwl6mTFCxfx Kkqz7WXoe7NqVfWO08WhLW0/4cuXcZI1vq7dMYe80RNv/BiRaJXtWm/bnxEG/zhvIbWbMA+sFPLx yXwkHZ5TINxhLFOYsNSd8Ic1vFns3uEONRizOT/cZZJUFgBqVrNkicrKdkrruzDGqmc/688Y62S9 dQ6rRO0bFPtWUyh/rs6PhSxkiha5v/v1JW2P/JoA1qlzLPsfMJ/MFDpqDYZ9cnCwkrJcNK+Tw9dF bKilu1jOinnM3bwDeXVqEhLXQM2wNuqh4KnAFK23z+y9M1JWS2dg05i1ewm0n3tM6A0ZOtFFdrQv +7vW7PCOmG4FJqUFfGmnpNTBfWohVPxq6sSSmrOnbi5zmyrmoJbZqat+LKq9285Zf1dEsWunVOfM 3l/vWc95BjZOhP3ZsYrVq//Fvi+P2xTkfiDaevrtpbOfbVHt6FbaVzPwMD+K7WwPK7kNjkpLuxxi x5rZzF8meYQ5XN3BcpaaY261hC1s2ZRYMx6fiaV3k3naf3atxaLd9VL+7W878xq9OC+rwAFddKSz SeFARvhZkcLfiqYV4rgt4u7wVvESzhXjTbpyvdBN5oSoWuwsB7tEToIk+aTPu4FjO5+0o+/C1ArZ hT50kJueX6U0WicOd7h0fnfCNcpVXFtnYteBY0VmRQTdqyY72cns+IjExR3zlph3bT4nBLYdj9KB O2HaNHfq3F3ZS+8HUxrt6Nru8pdU+54bX9ZbrRO+RIYvTYswdkWGfB3yZS//O7sjnxI5kQ/zk7d5 +laoQMBdp/M6ecc7msIm0K8G0XYHMt6XktaMZn/q0W49w9qoE0zK3oC0l4zyxDNDhzA+7AtxvO6X 5i7kB98lvLo5KGsmM+c3v/kcxO9e6k760nMKXuIv1Xu0/4qr79ObqxE/OCK/8oug8EA/9ms8sWM/ hfg6hdgJ5Js8k1i7ZBq+m8O1+nOS/bOJ/Mu/neg/v7C7pkO0qChA7aMtErG6JVujJmPABnRAsxiV wzGQaMo93wM7llO1x/OHO0gKuFg7EAlBlDKdKMsrhzlB58sfFVQNAASM/SKyh0OywZu2jfo7HBQf HRQLegkUebk9saFAIgw7/zEzQjc0wiNEig1cIA7kk3qLMuNLvhLZvynUvz50qCrsn9PQvsuhpDaC qwUMQ+DBIgwLucYatXvKMGpKDJHzJtwbJ3Vzr5b7JzFjqICSvKmhtSjzpswjOqKDO0+UsXKSJRR8 B0FbxaNLuvoyuoJrrejrC0UEP+8JvAB7Mo5ioji0CRqKrpSzLqeCLi/Lp4GIJSxhxsawDZpSt5aL Q9I6wpZDr5zLqw60PHeZsRobOsD5NaBLL2wMOptAAIF6BwTgwz58LWTbKq4KOGPrKnpsrTPKxd/6 qPBLRE2Sq6uLPe0IxjgMRvgJrGKMLmNMrGVUxljyAz/ACmdMCD9AEHGixv8aU7WqmsZeG7puFKgV cjF3qarv0sN+EzqOHEecQACVTEcUBER7rMVYHLh5vC+Bo8VbJAp8PIrBkzjCq0GsO5c2bEPlah6D dMSEPMqXWkhm9ANmxAqmBADEe0igs8Y+s0iLNEleY6Y9+y7xWiidkyWSPMmNxMqNRMeFcj50bL5+ UEt37LGuMjp5tMWtosXqyEml+EJLE6lisjgnaxKxs4lgvAmi9DKUe8R84qemskQzS4CmTICnJAip dMqVkrFN7Kc2pLHAPEWwVKa2k6ecucPl0zVzJMtyQkeV/Kd1VEd1VMmXbE2Du7G4jMeDik3qsEvb 1MWWYb3dshNVA8ybEEr/YVydotSwkQOznRoQZ6wmp2RMAJDKh8QSP5Aqa+zEb3TDabzGfdskOkwm 9xJHGDNHVOysPlNJszRNBIil1XyHfkjN09yxd5TJGys4QZvFehyy27xPG/RJAOMcoMxMwVSd4TRO hIwuA7Gmp/ynqXhK70jQKIlOiJSl3myoa7zKsbwz44PCZBrJXaM1cszOqRrHWCLPc1xJ9OwJ9UxN mHTNenxFWZzP+cwP/MRPjyIhEbrBEgFOa0QK4Ry3CjtGVENGQHlQ2ZjE6HzK53xI56SiWApM7LxO CcXOOnO7zzQqyeNQEouYfwtPPCvHlfQH8kTHEF3LEz3R1nzPt7THmoRP/1lcthjFxxk1MALCGyeZ Tjj0zQdTnHsCseYqzukaJyN9UKj0mqs60gZlr97MyGmsJossqE/0SPjzxvLZOfHsztH8ThuTMQRY z1vK1EzlsdQyUx3TsU+Nr1ElozbNxSQjoI1iMoB0jb8ETh0dw4WQigbFE75KUEKNTCRN0jfsVevM UV/FtOIanMA5MRHsD7P00nMECk7tVE7tCfIMxKI41fvcnb2EPYpr1degU6XQwaPojiJNUKfUVal4 yFX0h+j81YGM0GDNNicUnEilUvsjkfKE1i9l1k79iXyV1qCgVtu0ut9SIxrlxTl9iitriqy4iSN1 TAdFUpVyyIR1TJtI1/8cXVfAhFWoSL5SjKK2oxXWjFZ9/dhmXU9+nVZ/zUlr1c2OKjDgKqWokFhy zQrnFBB0bVAHpaJ0xQmh/Mt2TSG3Y6aORFbWJFmQzdcvNdr13NeS7deTxUHwWVVK254ZpStZnRfH XM6HdVgGTVh0dcgiPQpudY0nDNpucVaSPdtmNdtnVdqlFYqmZUAl8sJfrFF+HD+M+AO8/YMa0FsJ Ws4jlUgCIZCHJBB0BRCH9BQpC8vr8YlovVd7bdyPhda23Yu33TrdykfAw1xVPTCL0Fu+3Vu+/dzV QcOxyZhAiaCBmEiLyEl9ZdyhlVyiLdrW9Yub5J/K9UWsu5uJs9YR4tz/iPgDelCI4A3dhBBdy1jF krMwxETMSuQmhjVXSzzQfJpISDzMDBO1RxRLlPTQO+uzgQoo2nzdfU0oaL2GazjPHJtFUnVL2Lpd 4FJAOQ3YvTShJ3sIegDeGgjevWWIvMXb3whQnuJRD5NIhs2KiNwKh+wmJGVGhDzKAZYIqBLgDfsw jlytPVsvuUxbpNVUAOjUMI1W8/XgmZTLF1VB99VLGxww3i2wuL00h7hfeohhGYZh0N1fGy6NjxNg CtOwBIZY6m3O1E1ggmjIIW5ObHrMH72wiYhgHyW3L3uu4uQIXqPHscrUMAWKTW2ta+iHLTZfLv4z +KpdRTphOHq9N6W2/0MEw5bN3/zF2+B94zeuYYUwXtHI4cLaYZoSYtV9TJlF4CNm4OasASTuUSeW LigmzHZDtS2bqY6AJyzeqo/94GcNUQS4hlgKYS7O5C8GAC9+TXhsWzIWn4oD2MsdJrfqG71rivyl 4YSIYf8FXlj2X+BwNSZu4AmeXiFNliAeJ6Wc3iTG3sPUqZHjMkT2sOIsp6Ji0R072qQl2RA930uu ZPPt5EveYlE908l1k1AGnjf6yamZLSSJJG3lD6kzwJ1o5fttYxleZTae4xs+3jPzUT7t0eLc461o yMSAWMd0Rq/1MCEmZCWGYHkO5oCWKSZ+LNcsYbVl3NZC3y1WyS423/9L5mJrrsUSBuVtdhh9XBhi mhNwjgcCHGfp6Dtzzgl6uAn8ZYh0duVWfmXfYKxDDmDi/CbVXaddxRh8FmIiLkYs62lhdipidinr HWqFqE8qLiu2beZqtmSJctyImmZNtugRzuaMDiFr25vUA+eLAml5AJGS9g+o+2qTjmF/YGO+hWMY Ht7i/V+jNE4H5tM9/mEDQdKgmkjVNdC3HjfqAlJ8EmqhPuigeuSjg8krPttn5iqm7uKXpM345JB5 eOzH7od5IJiqRiNe9B2QlhNe2h3b6rtOycKLMsCT9ocZLm1XhuVVNl5Zrgye7lOSY6d9ckgDzWdK jKk9JuI+TcxatuP/xDRogk5elVNmFq1PiFJabzrfxN7i1FJuFyVfx+4JyPaJya6VDKzsIwmmFg7n qNPs2vrs7Ds9z7aJkyZr0h7edZ5h4e3fd56IeegSe+7nfhbkHoZvewbcn2mTfb1X5JZmiIZqn6ho xR5s/agByZ7uyY7sApdsguEW644KgOXuhsvs0Laoroa6Juls1JNBkxbvWE7nNtbb4YVl/QVdOmaI x64ByB6U+lYIuwZcu47vmv5ne/GWkW1mTFbsaQbwTA5wAa8OFCfwAy/w6QYKBKcUMdrmFt5qERHn zK5wrpY6O2E0QhTt0R5vfwDeK6dhN/7w/fXciGhvMIfs9uaSGHeI/xePaxaPb42Zm7VN2vPtb4ju iYjecZRRiPZOcAQXczxfcEJB1fDRHb17pCU/Pa7eQu/OQg3XifEG3vE+bRBndEgv3hJviDFPcfeW b/iWyBa3b0FO8zXHnpGN6E6W86Cw5opuk4QY81RPcCIX8iGnbvhhIqglskbyaq/Wlc72rxJxNhmE cvGuctLGcpZm9BguXg9fbxO3dDtX9R8pc/nudE3v9B6G9tkxI2ftb1LfcR6P6iJZiBOvdAUX8yB/ 9Tonv4hDwAqHJJBe94bLcNCO8gmPd0Un7xkm7ZsodhsOXS+HiBP/cTAnlJpm8WjX9Pl+9reBrQD3 b1H/CS8+9QFP9f9vV/XIDvKfOHBy95YdlMAJagpp0+on16VbD+1dEuvsgEEMP4oZFnFiv3LPRW93 loh/R/FvN5X59lo9boiAJ5QqbPj/BvBOnnMi8fZK9/aKj26Kv3iMl4kyLCXh+IiEmLklnzlHKnSu bvLUYzgn6XUKTwqyvl9hz/K8Ne/VvogUV3b3LvOaN/ic1/lA9HmoVnig3xAT9/cwp/txn3joxh6l Xxbcg5+mHySGWPIakAdZUwjCH3xHSgjCP/zFb3eSh41Uzgs3hmG8Le+UnnSHqPsfb5aCt/kW3/RC WVqH1+QcP/XRV4253/x+p3tWb30F13uMON3AxaK/ByOHSHwRkbX/rpa1J0f8xW8kxTf81XUNX1eK Rmf0LA92YfT6tcYIZj+Vm1d7NSeZbKZzU3/7Uc8PSo/4ugd36DbwvEf6psmIpU88v6/9+7n9p2f8 4A/+xXf/wx/8yjiNem90VyZrz8V8fjd7e5l20AeIGgIHEixo8CDChAoP9mvo8CHEiBInUqxY8Vo/ jBmvYeSo0eJEhPMGjhQ4b+TJlCcdzuvX8mVLkDJn9lsoMEENnAUT4OSp0ybQoEKHArVn9ChSowjl 1ZDHtClUplINOh34FCrRrFoN+uvalR5Yf2Dp/fkK9k9ZgX+2sm3r9i3cuAVp0q1L9yPejXYfKkR5 kiRBvw1huhy8//ewQ5s8d/bM+VMuZLlJJys9+HQq5qZVN2umijUyaIJgB/4ZXYMewbWhV7Nu7Rox 7NgbNXbMCLuv3xp/UQLW/dLlypWy9wZdfNPnY9fKFVJOqnCq1YKZr0YXWHU5aNSnyabG7v07eITD x++l/RG2vb4mda9nzxul4ZSFydtF2LMx/sbhvzd3nnCzU1IFiBV01An42X4JKrggg0LR9yCEMvm3 kEqB9fZbTBESdxByOXmoU3INRtYfUkJdR2CAl0EX3YkiuvgijMppOCONDTV3UEm+7VbSbib9NliG NVq0000D6RdijHCReNRC1zkZ1WXWSXkggm79kCSWWTIoJJcPLv9p047v6Sjfj10OaRCIR2qp5JLp 2YRZitJlNqVm1A31w5VXCoTnmn36uZqZgcbWZmW9sXcojxbWAJxwgp75oX4e/tkWoUM5KaCK1jH1 hzxoeWonUHjmyaeeBZU6KaqpJuQoq3YRWqJv7vk4pqy+tUqXkaqy+SVQA6LImVRoOcVpimjdSeqo NeiZp7Kn6vrspLdKK+GrE6ak46HtZTvftBTlahy0Qr1qaZQCChvgp+gSa6xNohLELJ8DiZpsuPUm 2S2+E1Xb3I4+5qgtQfk+au9QlZp4VafEdrpwwp5yeq7DCyU7qrsHLesswRmHJzDHNu5LYo84GlpS xyFpbNO4Byv/nO6nLS/sMMwKLSuvvMy+O+/JOXtXMscfLxkyon6p9C/PEumMkMELwZywukw3XWzD MRs0L7LKWo3xns1afTTXkBUtsM+E/ptjj7zN9TVfXQuUtEEwu/3ysAy/DHHUbqv2LkLuOjvx1Vur /TdRdFljTT+Do01f2GLPU9l7ZP8b8OGJcZ2yWnZb/nCKw0K8rrqXm7onqaBnHfroF2MNOOpng2T4 4IS7bnjkiCVe7eJKJRqrQrFLnjOhl/tut+Z1Pzz873eXXurFfn++9emppz4T6w21XrhDsOtO0+yJ KwrU9Q2d3F/x4b9N/Nyai393vBYzr3zWVzfvfNc0se564a3b/0999xZlv79W+WuM1PkCGD7hBbB5 8Fqf+9IHvwUuSibTq19F7ke4/ElkfxZ001AoaC8BcrCD4nNazXBWM7zhbGIKZKDODnM/6tnPevij 4EMuKMPAaRBVHrwhDsfXsAD9gFgj7JsCbda+IaLwZCqcIAsh2MIkwjAxMnxiBmGopRxSsYrrwpw8 etipH2TRKe8b3c1CWESN7eV1S6zf9ObXxN3V4IkzdJAUXWTFOeZwblfk4h+4mEU8ZRGM7Eug+8aY sSMmcYL0Q+ILX1dDgrjxjdxrYoLoKMkqms9hXdTjWrjYFKrtrWIzE6K98qM22NAPf4h8iBrXmJBG XjAoa6yJcv8mKcs6ngtdcBOWHvmoSb99kpczI1iHipQrMpISgiw8oyIhcsrDoQwpdjDKM1lZrUeq MjKzvCYVneayh3ERT9y8zAFH6MkTPusxxrkPiOwFITNKT3ouZOIyeQaUZ0bzKPSspzRJRE1IugWb /symLbW5RVx6M5fdHOIv00fOF0XMUwlB50OhNZ5DVu+QhjSmKTFatIXYQSB26Cg0oUnPfFJuVa+E pVD+qVKAEm+be8Qkp7T4GRFyUoR/FBG7asCutSwGncj5STp19aCLJvOBGTVqPAXmE4561KP2+ChU P0rSkjLkpCg9yEqzClCBCnR43dSllEJXQpt+MZJqqRxp/nD/zuP4ASd+aKtjjJQAAADAT+ss5ODo 2s54tnCCeu3YT0ME1abWoKNQfepTDztVe9C1PwKhq0FoQte/RuSvlO1SWqtIV62utHObqyU3v9rD KzGFk1oLISjl6FCd6nQtPFXrT97Kk7fWYLKTHQhktTQjRbZOr6VUpiFhd1l8OYauPMntQD5a2I42 1Q50xWdISdrYyUwXuZCzyHArC4CGZFc2CeiHTx5Cx83+gbwwM+81yWte9AYwap2D2rx2iBY9VsV0 CaRYWRckteMg561tpe1cAeCHnEA2wFmikfXoR1d2PpCift2uwOTqE+s2t7Ae/ehzDztS6QKAMtWt a1Ur0t2H/1gWwsP5Lni/mwDYrnjFVlQvADhrOfZ6MG4tWxnLFJa5+jZrnDRdk7Fc29q4qqatbqVt beuKk9wy2ba4dfJjbxtlKRcEuU22sm0lUmLuZrkflNWrbQGgxjBv1xph5vJkC7dlL3f5zGxOM5rh 7GbtYjnAk3UulKtsW8bumbp9DvNRAG0UMvuZzFSeM4nJ7JA1Z1fRcYbwlgN83Mm6+Ly2RQuZ7Wbo S2M6xuWd7Iw5DeNOg/rTnwb1ZjNN6lJDLMydCjOxXD3ZHpL5ybP+Qa2THGWcurbXQnbMH/w74GH7 ga60LTBksWyQZIOY2U9eNoh13WRdR1m7XGbzorf7ZW1TNv+NkyXcgr+tZhODmdvXvjacrb1tbJ87 0btO8qQnDdXnWtijGW7sM5+blMkGusOD9jdSGjtdPnvY3/zmM7XZDZE1s5vh2Ya0udENgHgH2NQW V2unPZXqUbsNxp4eNccdtt6Pl5rGId84yS9u3oStXOUxlsesUR3jyTqFrs5iNgDw5GxqKyjIOSWy i40sELgOmMw92TnPn01hZetZ6dF+d5K1LGdyRxzbC1ai4a7OZjOLOesQ5jrX1y1xipQ72wpv9NOj THHIYriuymVuk6Gp74ADnOD/9rPd8073u/+b591lOKNNbPaxc3nVop44xtHSYpczvuMpz7ipaSxy T1v88I7/h3zkKb9xjVP+YXRl2KdZ/vLPwzznof88F22uZ1zn/N151u+QWxtkEAnbvwkouoAJsuSJ G3rKt62HbesB/FwThOlQNrTUAV/1su9Ver4F+9Xz2nWrXxb5w1X0upG/uzwjGwB2sHOeDYvnwuob z3jvt6AJPfCB7z3vAnf0wiHej1vcIvDWljisTx1mnujfYRPW/MwBoKY9XuWRnOQZGucloKVh3uZl 3Mjd2GZpzud12qsBQBah3ubVXOvVGmRdyZWl3X70GmsZC3K81n/VwIAthrE5hgryHggynUAM3/At BAzuGnKR3dSZXfZ9nTuBW9dxHbb1lpiN25tR3f21G/NR/987vEM/LCEbPRu1GReeLVW91VuTzZv3 7VvdsR/fEdz61V2/deH7RVb8ISEA3ELDCd61dRq7oUVDgJ9tVdqKGZenzKEAPuDlNR57mVzncV7I KeADBqIAWtIeDqLNlZ4Gll4efRrriQqz6ckHNkjEjCCRQcrtEVtbGdd9EFhdKRtkDV8nAoDwMZvw JZ3r7RzSjZjYUR+aKVz0bN24AaHzGSHz7WCitWKJAcA7/NUuQljxNRswRlnbYSFzJRfb0RueSVUY LqMXGtz7/RsY8t0X2l3CJRoa5uK5XRYbOuB2/QGboZheSZpa0SF5LZ4gKuAC6mEAYh46ehwBAuId xiOpOf9e8JBe6CkiPm5cgGzclPldtFkXhXnH3fhaTrAYCiqeW12isQndKR5amNUAKIpiPSQZlenZ 8Tlkuh1hEVJdlv0VIvmgbUnfIblZ4OVgorUZSWbZQXDfPxrX/kVVVN2WoGmhFh4cn/3ZTNbkNN6k dd0i/ZHZNUKcwxRePxQgqBUltn0a/+mfi/1U/uGh47Eax3FaVE6lAZ7c5uGhqqWLq5WeVFpgPuZc ptFamLEeFCZdQIKHCPIUC8IWXOXEgA1dhwAVQkykXZYiRMZgXu7lQEykW4iYGiLGCiVTIR0TRdgC RCDmXvRiQzCh5LyDVnwfVCVAVFVhMVZhYSHWYlnQQEz/BBrSH2jOnxs2hKcUpTee5mkipRvCFmw5 xOItnv8pnmzK2ErNg/igV0AtDehhUbokYhYtoqfwDUKkZQiyVuXAJrD5QbC9lVqhoO5B1EEIH15K p176ZV9C5HT+5USMmF04WEUxUQ9OhGI2hGIipi2Mp2TpYmM24RLWQHsOhWHxxEdRpmQa1oVV2Ntt ZisJhEPQX3/Sn6eEpml644Cq5moSqGm2WIoVZVP6BGs6KG2qlG16yoRO6OVInrDoZkDJF32RVw/N 12jd1C/GyGo1Z3MuZbChINEZWQqyIJJQZwz6pYzeZV5aZ422BQ4OVSIRVYJVxHmSp0OgZzz0w5AS KZ3p/9USOuFAJClRDBZl0ud8/sRlLhdm6ud+zt8txEM83AJaAOgfcKl/kiZpjiZqRoQbKihPIOVS 8l8JsimERigd2WaFngRaWKgfSp7TxE3mWA7TmNpvigpw2gRxmpXPAZtBvuZyxmU6iVJ06qWjlqJ1 SqeN4qiZfGRfRU88/Whi9sN5mienammRNkSoOgQTJul7QqZAvCd8ShhyvB1hJZdBWOn+gKqWgqaX fmmAmqaYmulojukbgpdDsCbGleCwFquLHcAfHACywukNyanDpAQttZQdYQ5oxVTDeNMk/km2psZP /NrtpWgKRkpQEQReYqe5kit2Tuqk9k+l8lb1gISn/v9oeXIqvXIqYtKqlk5EqTahexIEk2aFfX6f T0QVTsDkfcaqrFaLp4AqrtJfPHwplwbol0JErwarmCIoUlosbAqrHCJkAiAryCprsjJrB1moSvwB naKsnQ7QbtqRjV2R3ISPDf0aa3WIbPIXFY5riECqXZqrjPIljd7lutJQpSYSGiUVeWrqvMZrvpJn kQ5p00YEqqKqW1ymwD7pwELphSnXQSQs+NiNlv5BrUZsl5ItxGZsag4ozIgXxjJomrYY3MbtsYbs yKIFyJKsANnpyc7pB1USFsFN+QRPAE0KzbZWmjgof51oT6lJX/6s0MZout4ojZ7rVtzKCvmo0nZq vdr/a6faQjx4rufSKkQ45tSm6r8CLHPF55NOZn1yLWYWhNcaRfE8rMNkaZY+rJeCJpnq6lCmbWkm qJqi5mwiJGsu68cu692KrMji7e/IKbRCK4Wu7O/0aczyZswWi+9AS06xy300Z0Gu2DBJChXGqNBO p43OaI1KKuWy6+FoKr1qrr0SKdSWZ+hCbdTy65L2K9VuhX1amMDW51IF7JQi7FR1EO3i6pZCrAKv bdoaqK9abMYCa7AOr7Ei6/GumLJmMPPmbcrybZ1Kr+/kKfa6LLVi735pL0EOJIv1lE6Nb36AC3We 77pOLrmW69C6EtrEa5B66vs6xJB6rqgGsRDXBGQW/3G/HjFbDNbbQSnWDpa4NBIOHXDYbukUgynZ sm2BIqjwGqiKeSOb1iGxqtXyajDyOszybvDlmGydoiwbc1Dw5Cm1co7grtYGoVWQoRX46h73BlWk VOfjRq7kZmf63jAOf03nvq95JnLSEikQm2fUFqm/FvGpvoWrbq18DqzBNlP20NEUiy2ufukBm21p rqZq6uoDA+uZvmHiOSjcHkCLKa/d0u3InnEVLeEcpewHq6wut/H5vGwcc5WO6cxAUqJqdK+LsvC3 gIvk+mwM9yz5MnMzV27kuC8Py+unxm+95muoHkR7qmpcXKZ8TmaHDDBz7MssPSztdrLYgqnbqK3a tv/zgTawa8IM3HqKK/OEK8+yPeszHdnyH/izFTlr9OJyB91Sy5pPnXDNTqmGkDUl8ZKg+B5HQaDv o/IsXy4z5MIo0eZw/LpvD8trkXYq1Mrvdwjwcl3t/7ruE3/tP6Ezvh5w8WAxmWqx8Bqrx8rm3F7w LC+rPvO05ZzF+bzDP/+zqebQ3s4pQbtxhg6P5hBIleSMkJVozbKgWoDL+C6E+l4nz2ZnDE80+/JM NS8yIjsy516zNoNqeKTuSUvmJV91UQAQbYatw6Dz7xioPLvzQ6gYaTo0x8YyyGLwPo8xP7sNUJPF 7wg1WiD2UFOR8+ptUiv1nvrKgYCKxkT1WcUeGH//MVCNq1ffKCBHqrrCqPl+dckc8g5bs0djMzbH Qw2w9n68HXO1amANBfPKtW3XdZkS6NqOaWqymBevsP/hs+JlsPKScU/DjGF7Clkkt+/YMmILtWJ7 UIW28XRTEqdQBWUfzR1bduWAMUOfE5I0rqRm9QzPqA3vZblGUdEo8kc/hDV/biNrbmvPd4IocUcF 1k8pBBqDbQBBsEy781COaZtWGmwRt92aMSwjr093EHR7SlEDdMnSaWMLNA5ZBkFktzBLdXfQrOIK k02Yb8867h9P7ngTcu4Ysg7XK/wmMnwnMmIKhJZix/4uBH7nd3fvNx0VKO+Wcu+qJmwO+PHm82DD /0wZ+/RYFHZpHLZiRzdjQ6+Ee5Ag6XfMqHChXrZWOHP6oqvPZrmJwxGKd+6KB2n8aqmnegeTSvLp 2keN47g/PbBu2zXvombc4vTc2vMZF3csH7jDjAVaGDZzWw6EJ3acgrDMRnlQ/JzxkEbsucX5erZW A60fs0X7innSaq5pM3Iit3aMr0Y35++MPxSKsnmb43UE37WAE289oyiea/A++/We8/mfNzdRE7Vz M6uh03ZqJDpa7XpWOC56D/L6AjJGZ4UhdzQPb24Pxy94zLipGjFWibqMoW0EX2w8/05gDXmy+rSC 0/JZLHeSF0+SLnZiM7lK3XpbaPgI0nFbqGsgY/85eaN3l5/4eivt5sorer74QNjCcnQ6vyOx7EE7 yZpyTf/u5aAogddttiv4gd+t3TC3tys5rT/3Spl7P2WW3ZyVrg9FiT/qdUJzIF80aXeMIo/n0mKz vteAvp+8a0wtmh9xoAM83rJt7w68ABl3yC74ghN2t4tPUYv7LFF8XCT69lp5xgtFV4t3DTuqliu9 NKM4pW9qvOa7mbsnmgv6uMM8jus4b1PRnSM8tut8rEO8z9MR0K+GQ/ka2sdFM/8x5UJqZ1Oq0997 WZM8ynfqvutvrYs7uWM93+MQq+908vb9tpa9NZ2wHUNGNJ+3iKNrvNvE9bj4IZ9n3Z+85K98N/f/ fINfveCT7B3ATOdLksIjeM6LOuEvR6GqcGQcPXnLMLvDRex4NJibp0DY/dSH+1BH995vPm1+/h90 vu9fE8NjfemHR9GHBg2X+M9WJ8e/xeOP/FjP/rLr1JJbfebr/u7fAe+jBfb3/u+DfvDj+PAXp3Fa ufGTL0W7/Xh3PPPrjouTZ92jPPSbOe4v9vS/vPX7U/dj//Z7yv7ffwcBRA2BAwkWNHgQYUKFCxk2 dPgQYkSJEwnWs1hPIMaLFmtw3OgRI8WC/UiWNHkSZUqVK1m27GfrZQ1bImkO/HMTZ853727u/MMz Z1ChQ4kWNXoUaVKlRO/8aYrzTtSnU5dWtXp1/2nJmlu5dvX6FexDjh0zZgzZ8SxZry7ZtnXbduZM gXLDJtTp8ydQvXqx9vX716/Up06pOjUMFXBixTlX1nX8GHLkuh7RaiRr+Wzamm85d34rmeFQvDz5 /lx8GvXfwU2nspYq1HVq2UY/g7Z9G3dutZnTWgbrGXhwlLoLHt1JOi/y2cuZH12NGKrgm1GbyxZO HHt27RE18i6oea1w8Z21GxcKNG919bOpSz/8Gn576Ov7jte6HX9+/WYrjn1sH0CXsltKOZzQow/B xV6bbj7qcpJvsASRCnC4/Sy8EMOvKNzQpPL6KlDCEIMyB6kIo4uNNQYdLEzEoDhkKcMYZZxxof8X NxywxRwBI5FHc3jEiUToIoTQvRSnc09EG9uikckmM1QSQOx0nLKvHoPsEUgfDYtty6BQJOxIJNeD kjMnzTwzOzKvk5LKNonyxhuc4ATyDy3rvPMmLc1Z8DDE2iOyz0CZUzM4NA09FDJCPWPTzUaDilPO P+D0xs4g6/zx0j2P3NRBwgQbUszUFLUP0VJN3WxUt4hzlNVJ53T11TgxtTTLOv9s7UEUXXsOtVQ5 PBVYiAAYdtiHiD22hmOLTXZZgYgdSFloAVDIVwF1Y9VRSGPVts45zaH02ywtvVK61r4Ec9deq7Ux 2HbpqYGed+GVlt6Gmq2XWWanlXbfZpe916D/dRu7Vkdr/jAYYTfj3FZbEheG9NtvwaXVzi3/nC9Q PsHESmBC2zU1XoHiDZkegPk1Od+C/J0WWX1Z3tcglAfquELcckQ44YMN1nnnHF+9aeE8fZSVUqCx HFfFL6lKd2NPm56Q5lQ/RvTdkAcqGWaCVo45a2dhLrZlZGWWWaCo77utYGvUvgnntXHqOUFIJZ1T 0rrnhjNiSuWW1Uc9w9y0aflUfO/poczueGoZR4a3asbnrXpZeb3G9+Rnle33ZbBfRojsGszOjcqd RRc9J7VNDzFooLXFO8ii+Za04jw9TRHCwS0esqjDdU8cQ8kfr3pxkYvFWnPKJ1e563zF3vyg/849 R9zmFk0n3e2D34YbbvX2BjoniWWt+2HYixaqx3IfnL3cTxnTnf2zed/OasevFhn4Ya0u/nitkzf5 X8xTngh6tsFWz6bHNuslLHvLmZTqInU3HoVPb63jG6buZCkxKa0w7dNgzd5HHHlZrXEkaxy87Oc1 rBnvfyjs3/G2lsKDkOkZJInhM2gYvZsFpW08I2DpSMec1D0saK6CXcS4573vVUxTtCMcxowklX7c YYNRdJ+h4CSQKnoDOyOT3AdFRj/HEY9Y8YoW18iIvDK67GvJG8mLaDhDGbYRbVManfXYdroDGrB6 CUSN3O4WRNU5LE9Fc9gCiei3wrAIXTchif8ToyJFR5IETVjEYg0kaUVKVlE3W+wiyQrCRU06SUkz dOMzalBDUj7mJnb4gx1UqUoJre10c9yhzt5WSwW+iVuTIiL45iY0u8mugoK7FRSf2MiSEPORyXTS JF1FSWdeMjfB4yTjfDcvaoZQfjTakBv7EUOtnFIgcASLUVj5SgPekZbXw1kd9biYvTFMTkYMV6bw Jr5fCm1PuBNMMRfJyCcmE6D9aBIzLenMSQ7koLbBJggXN8LfYbJJFGpjSWjYzXCWspSm9ApOWpnK cnpUPXakIw4LWFJYpjM171xgL/sYsdbJCW+uy9Sl8jSVf0Kxkfv8FDID+kgZHfSKBG1mQR//49BN VpOaX5ScN+jBVKRiKEDcFKVAn3EOGlrVlOCsCUdduUqvrtKVXWVOzkZHvTyOFJbt/Mv2uPcomHoP puBy3dFkh9NF/vOYOu1nTw+X07ue5EKTeqYkK4nQhEYmhFqknxbjNzJmHrSpTdVmVClKEqy28apV tapBEtBZz34WtJ8VykfDCtZU9uUbOPnGaoeSMxxe75wHdNts1eqXWMHUrXqr5wOvRDS6KdIcJtnn MYvpRH7y1Ww4NeZfO4QfoA62koQ1KGELG5anGrWh1nRsJUMG0SexsR9WTcBlE/CMz7YxtOlVb1C6 SlqutlcprFXtalNLX6GkdY6wrd5993ua/5VGCoi1+lkEjQYxb5TER/1IcD+Xm1e88hS5qcqpP4mL 1+ZmR7BCNegln0tQyGwxu9bU7u8cazWmelc/nqVsRTPb2aueo7zmxSwN1VtjorASx2HtqEfFapTU /qG+85Xvj+lIW3TGdrbq7G9i/rvA3wbtRxLr1twi1g9dBhfLCj4JMSfMYAhHmFB2Na6FefplgWJ4 utVNKIqteFiugLixJEZovJwqzd8R9UIvgvE5YIzZGPNZxlYVb41De+OclLOVO96xj4Hc6JsEub6R 1iE625bk0rV2pIoRoh/t9rN5uqpvCT6wlbWs4AWvxK9mBrOE81pmLiuXg7aJrmDb3OYrPv9zsLju imJ5nVQSO1WSwGtoU2kNVeF4s6LjVfafX8znPsvYvIT2bFFwbNqvlta9Q2HtkB/96CADObV2XOek T9pDnp2ztlfJZaeF2EdvwUnLow6ulcFV6nmv2pF2PS5zh8vllBBHqG7WdUEwKfCvTPODcH7muyAL p+7OSDyjpDGg0fvZZ2uWxtJGyqKv7VWOE+XHIQ85uLfd7bOSVKTTSytKU8pWTq97aEOjlJVlnuV5 nxrfG/Rrce+q755b+N+SeeyGH+vm5xqWzTUJXkI4KS+mOnNxWKQznvM8nhiW18UuvmqMzSto9GLV xkdBdLYXneOglLzbI1ettxv9DbW5fdz/Jy3yHfG7cv8COHxtnZuCZ/4tUkvM7/cmCc5z3j7l+nun ZD78vmMdFu9ClLq29rCtB74Vhs6PIL6TutQNC6+GV9dCEe9mVT178T+PV8ao9/p6lZJjHbe3xzkh sn3XTt+Ri5zurs2eys+N7tm028ngIwm8h39gXcab73rTMuELr7suNxjWQN9rSx4TXYIMFaHQxL4l k06RXgPvzotlHKwiu13JVj4/x462srteXvFiPLPQ9rNol6LosZ/W42envaRtP3uR19ca3M7t2AmP fC/Jdi/dsIJuYgUljO/v6C2CYkpiTE3wmk/nfA7xps+YNpD66oK6hurWuI/Dso/WDE4i/7BJxKpJ 2OqM2LTo6UApOFJP6zRrz6rKBmmsjfpM0KbNL7Bt7BIN5EqO/75tvubLYMLNAFOOtsqtOSZl+Ojt CUdNCkuNdQYPCpnPAvuKn1yt1Y7r8IYLRhyPqEqwsIpN18pw1zbpcUaMxMrvkrZokhiu+7ZD/aDN /S7O2cbrsjCLvM6hB6sNEKvtq4Kw20gO0oSCvowMj+KOpM4tv06j+JwwEp3QVUiN+AZPl0YtC6Oo zLyMuJBpwjhQ1RqPJtasBAmu6KAJ6eYwIhLui9ZQuyKL88qPzpxK8r6LPDKqhvrszy5LvN7v2bju Lz6K2rhK9trO0bxtyGhP9gKQ99oJgf9sKdMSUCkakPgc0AGhUAorEW+Gz+82kRP9KQN5DhSFa/rY oituzeiObtZU8foO7prAzxXFz3FYkM7OD/0gI6uoJRcxKqN0cetIb890kOsy6w/8EDAEUdGsbe2O kciS8SHRLgBpT/fmziKjMTFYYgpJTRuh0CNLQhO3ERx1Trh2DtbG7AulT1W+IvKmSwSH7rC2T+l8 Z4RQEHikzgUdzhZBzzY0KiH68aKuCqNuMNA6aw816w+eAScQsi9cj8dOS5US4A866xsS4PYKUfYk jeSALJaM7AAn7dKkMSvYwvhgBRshMBIh8BovcSQf6dUS76YebK9GMQwnQrrU0R1zTQT/B84MZ5LX pImTWNAWW/AepasnxWkgtGpmVrIgdtEfawCrzqGUeNEoa1Ap+ew0EA3/ymnapLIqrRLcDNHRiDDS iKyAFrGObMmsUjMpgAPeyvISX7MsOVITi68tpegtRVHx/A3o6LIuIaLgss8gZu0UQY8VT9DOMu8V q+bpcFLY5NAEw0Ixg/KFlkQhJDOrNmsPKW7GMHMx7k8QpXIqb0I8O2sqrVIrQ/Ps2G7b3i6/1Grl 5I4oAOQaTWIj2dI2bxM3t3C5NrDBKuwTffM3HQLyoKvzMqzWCi6oorMVGWsNE4s5F1RkHK4WGfQr SAmOMPQx18haEAJDJRMg4Q8yu/MG/2/COxUDEMWTPHGCKu1LKj1zNNUOIrUN7vBLNWXL0lxESday Ei0xLbNRPzlRJcZsCxmsuAS0QwkUqAyzmTIMQUHwOL1PhJIKhLooDpWK2HDjlMBpxmooYAY0IeIv KMVJKW/Q2arqIJejPM+TPB/SPK1SRWO0CNfz7WQLR4us0mJLkXYUJNPSRzfSEmszSLXw1cwRJfzT SH1OPJRUFYtOw3DNSWElHy1PBZHKQRlu6qK0LrRKo7z0S1XCIV4sQzGUlLwO/mjIRJkSNd70Tcez Ks+TKj1r/9ruEOU0GteJEZdwTxUFNl+zI9HSVwfV8A5158gRwhZPJdeEIYbOHRFUOP/xUjgRK368 yItusgWxYzqpczoHJlQ1NJwwa0Qpzg9RNU1nI05hlTw/61Wp8jxtL+1ujwidUe5ULpYYw3SqxVe5 MQo9UlD18wD+tR/+FWAFRsxKkgv3TRxvhEBf0jCflfvQkCJ+QSB+QWINolIxr4tg8cQYTjs0lFQ9 lUMBKyLMlM9GVCmTskQFLU1VdTEKDbTYFE5Fa7XQUz0hTb6QsQDZSdz+oB+swSR8tmPwkxL7VVhZ YmAl7CQB9Ej5DfqQtEwSQs2YdASb9APbsSEotmIllmKZbjkX6znVcFpzw1O91GO3VWQngjtLFWVP tkyT8kTV9EV5cEXjNl1V1DO3jdv/bPYhEQhXD4YkfFZtevZwZDM/iVZYD4AkBBZxExdxFzfMvNBQ H6xYlxZKoJbq3pHDGnbNLvcgsDZra2BrKxYhHDT8Mq9KLYRsh/JTISkhpEIhNEsgDpJcbVBVMZNl FaM8c7fQgExW13Qr5bRmH/LS1qazADdwgVaDgJQjizZgS2JgG3dxAdZxWa0cKfdIFfU/XwQhInXD ru8uocv6HGJrCUJ0F+Jrq9RS8WNshxJkCeLCCOIOBCJ+XTchsMptT5Yo/PBtU4P+drcz+Y9mRRNe /6AegMwicuKzrKGzevZ4mTfCGpdxm1dgTUJ6fSVpP5Fyx9FpF3U4vTd8u1dBH+9q/8kXdLO2fLmW JkXsmvZjS8k0W5+ndaNCfmVYhg0iVVNVZW/4dmWDVV+0bscTTlk0ZkszK4OsgI+4HmqsJJDXgR8Y eiE4cSmYcacXSowLFJFV30xyg0kFFQvqSbVvDi10YkF3IEJ3fFsxY7lIRrLqhT3nIOK3IOC4huHY Jm54ZZ3NRJdyPcxzRdv0M8/1VftPGWuWgA0xiUOriQuvglFCeqM3iqFXUTQ41SAXDKWmi4czqEgQ UrfCjL0PFmekfSXCdeWYhuU3dodCf/E4J3YYbhGYVQM5bvkYRrMyNJOYvjYCtFyCz8LrHBJ5gxo5 igN2ep84mCNZaW/qYKt3XRzWLP+dlZk1FWsn9nO1toMognXfuAY+JZvnV36VAo9ZmX+BWJw7k25j mb74GCKrcrWSmJ0TwCKq8iISgCV6eZd32ZfbZ5Eh+Hmb9ySel4ptBC65MCWZa5m914uJUy851yCi mYw7eYyrGSKmaIbhd365uQYEhVVYdTyLIk59+FUbTVbVGT2psh6+IZ7duSXq2bLC657Zx5GFGab1 +ZFh2oLLESW/LHsL+gy/2EkntSBMuIRLWHQZGqIb4n0nepSzeYZxBVvEmUURWIhDDp3bVaRn9o/d OVb/uB7m2dlMgp6drZdbel2guIJfWnGd13n/+XGTmT81yItXkeh8eqFJWKjHmKj/i5ofj7p1lbpL TKRRprpVYTVWYRa0+g89q/qdE9udt5qrV5qlw5qlxVpgyvpooTiC01pgu7qrAbpQGalgHal7O0/7 Irahf7qM8bpGgm4g5Hi1u7lLmrpuz/VlQ2tmYzak++8zaxue2ZkkLCIlINuxw/qr7VmyR+VohXmf o7eRFbeXEbeehRu4A+T5pjtZ2ecdmzRaxZeaE8JzTxi1F1O1KbqGT/lE/BpbREtu07Wqe9eqC3uk d7sfPkIloNuywPq5o7u41YSyp3iCY/qxFXdghZuX8ds+Ug0DtziAWlJT53qoT/tzvxshBrSilfqC OuUo5AHD5QFBdNeHb6IGEmAg/2RVIGz7sP+4tj3rIuJbxX37LeiZl706vwlFpoeZpvt7gg/gHDL7 sYebwDmESJGrLqK5fEM3qCEcvLk1jrfZaV4bKTQ8JzB8j31YPD8cxKscxD88xA9bXVtUnRG7JFJ8 nh97pSFbwHs8ximErPcZuYc5xyXYuR33ucf8zDvwMe5amo38eei8tS86V4ykyZ/cyf8AyvcYy6/8 ygu9s7Lcymugy21vpK2yt32bsRvbscVcpc18zsfDkSHZzdM8s/81x3H80uM805NUJDy3oamZyLf7 u63TICzcT2BdKKA8wwVd0AedOUZc13f90EOcIGJVIL4h2Et8gTsDrAe8JFwc2f8xvdTFg6wfubL5 2Z+RW9nre8yZfSTxY3wbfLu9u4NqgyAGh0X8fCg0HNdvItADfTEOItGpPNEN/d09K8uDndFXK9hn NjjwW9+rvdltxMbdvJ9DPbzeHGC/+trLHN/OBNXnmny9nXeelrzFPWnMG93N/dbTndYVgyEOvcp9 fcTlHSHoK2TzPdkH3J7tu9835IlvPM0tC8dXGtTJfMdVetlppqgZWtW1dshROxeNguKVwuJrvdb7 AiLa/deNHsvdvdcjXDhkPtnjXMBTHs3NOphfOsf5DMdfnnE126t5nLjHA8/F97TJ2K4dupoXpUSs IuNtfe3VPSloouPj/uPbHen/q9M+EJ7rDV7qlQTAgfnqQ33TAd/kZ77Sv/6awz4s7Bx0b+EWaoDx Gf+MH94zlgPj0d3yL98ovqLX6X7XGcJGjr3r+X3vNZ2CqbisQx3rY36CgVsynQ0yX18gQBTxJcOM I//xS/vbO6M5zN3taf3cc8I23l3Xl351AYTMT76+DX/07QOYiznma0DUo/8AoB9EZf/1rR/2Y3/2 bUPVHR/yHX9ib1/yOWP3b93WMd/icUI36t7z9QzZxXz5f6Ugpn/6ob/vJfP+S1b/IbP6+T/7AeJc jRoCBxo8iDChwoUMGzp8CDGixIi3bv36datGxRoYNU78CDIkwYHnCvY7iTKl/8qUf1q6fAkzpsyZ 8uT9qVnz5s2cNUX6/LkyqNChKkuW7Gf03MmjRJs6fQo1qtSpKRHau4r1qsMDB2pwHdi1q1eu57h2 LTtW7EiDAguuHen2p9y5dOsu/MVx40WOGPFWtGg3cMO2JAsrnTozseLFLm3C7FlDnuDJB6laRqo0 89LDlzt7/hy0blZ7D81+9Yq6bcG2B8qWbG0U4eqktN9Svo17Mt6BfzNi/Ktxd27BJdnOlso4ufKX jlsOhCx5NcG4wyOCnqoZ6fXt3PtVb5gVolqwYtF+bY2abPnpJN26L277u/z5FP/uzlgRr3D6IuMS no5ZgEQtRyBjPUkWWWQIvv8FH3v8KdRdhBJelkCFFl6I4YUPJqTVR2GZhdZYrpEV21r/gVUWbIVt yCKLFgHXm2/B7dfiQ7HVxtlRRglVYI8yLXRgZDfCNRt19E2IJHcZLslkk03WGJJpY4FF3odkOQhf imJ9aCSUXuYWY0YzapQfjV8m1OB7KR22o0o+vvmHROcsmKVhXc6XZJ4pOclnn37+eaaHU553mkDl JVWYaa1ZeVaDgT46F3AXvfhbcIBBKtts0wm0lHZsZqYUnAXO9Z9/K+KpJ1UL/clqq67yiWlp5V0J W3GqHaSoiCEu2l6svn4E42+9dbTRr2xt2h6o2m22pqiL/USYrSu6d6x8et7/9mq22vppLENnUXml tG7V+i2KrhU0XrfqLlSsmL79NqmYv2ZpUqfKrnnOH/k6CxNdt6pW4o3vDacqpNsejHCF6yok3b+m ipgrxB/Gt/C67sp7n7DyxkqvSUx5ylk/+vL7EnFFHpRmqRRX/GDCLrfKMspGCjxduSgSalqIMS98 sUe95QWcrwPruKOOmBml774+3nZrr02rjOzONb5MtZNSS4cle4YWJ6VthqImNc8IbWxQ0BzDtemn oIaab1ItKc2Yd7nVifWpttYdNpRV723hzk33alh7i2pJ0JawpZt3rBvht3GxxppzjjmQQ97pssq+ pHRJIyd2knwn3413x3cm/94y31T7fSzdJKlnqFkjnTcl6d26yxvtjp8peQ2SuxWgOZYfljTcmiMN k9w1Und3tcbJbrDpCMfccLJxneaVa68fji7zvi5ee7uMf5k7ypBnR/mcScmTOdKau+SlygKDjnbU 2gfq/LaoL7+p4a2PeD3182+fkNvdjkXmMEgB27OZyCkFfeh7G/ra9rbhOap9D8OfuOL3v+bVj1XQ I5KJ4JMzQu0vPRnEFPfwQyaPxCp35VOK5BjYQHPs5EfSCpSmtPZBpwGshLHaIAcXhqgLhqV6YFMU rRDHQy/FqHsoJNuDwsdC7UDugTWR3O7GN7K0lciGsumio4K4siTSz4dWA/9ibXq1pdWlCC2EmZgY z/S9FMqxRQVk4QGtqEB59EMek6MN+p5TGMicqH0eRJ4HkTXBN2KKjEwCop2ixbrqvQZd6ImdIr/U Lp85kT91HEj4TmLF3pWEgQKpSVuoOCcHYSpNp3Ja2lR5yV8xUkPrShl7alW9sGwNibGEYxN/Rsc6 FhCUVjTlHudkylGa44HmE1LgbKipIWltZq3spSxnacZBviaN6iniEHlpTReVjY4GjKLvfGdKnJiP lLt74DRLmcjjbdFUQ+pYOFlGxmwma0WNGpSU/HfPgCYkfJ6sQT/s+JwhQY5IOKogF7uIQ8CNTqDq 2iD0sGalXGaPShTt6EH/hPlR3eUOJ+Mzyh8jl0xAEkQyLJ1oi95nIgZt0aM7Mx3LZho42KWFpjw9 oCetWFBPVnFOuyuOIFdqvmbCZ0FnalgNi1Qnnkptb1fDaA0SkB5wSlWgnbTiHVkopKWOL0FGmaI6 XfqlIEbrnfHcasVeljiFYZVQCnOrR31aToWwdKxENWlSXogThDC1qYCLKP7sKjuXvRWrA+kbY7EK WcRyNa+6K+eBqihS9Jk1maopIE5YmiChvXNabZVs2A72VoPUVbWNvapp79nJyiK0sgoqpkmZWZIp bhE68yokoqr52sRma12Mde1qXava4wZXjCAFq1BrKxmgTk5Bp4QuSy9b/0tpLleRrlqYXBtb3OJe VbnbzSBQKfucZX4WtCJd6TJHGRnPXpe93RpkeWP5Q4ONt7V1jexxw/sReAj4vuvy6nkBedkFFTO6 VeTjQRA0WAJLmD99WuR4xbtaANMSuQ2BRw08/GEQTxhTs/0oH0/sYPV+FpAshHCCRwzj0jXyTI+V K4D3u+HvPsTDAxZxjMFXTrxmVkE/JWl047tM2rr4xT9u8neWRGMbSxkh4cWwQ3hsEAGDWMs+dvJ8 7khbr1YWxQpab5BOvMwD0pe+XpbIDwzy5jY7BENeEm9rjcvhyCYXsnbO8pYP8mc5E5C2YTYIHz0b 372mGbRpTtB8gyToh/+8Oc4/qHScI80Q8n5Juf7ls3/vDOgPi3ogW8Yypr8sUrw2t9HyTXSZX1hH NhP51AmZtKVtfWtad0tDnX7shWts3D5zGctaDnGxu6zrwEhXtgRlNGZTHWs1J/k5EA5tsgdyaUrX wNJwvvYYoXyQ79oY1BwmNY97bOxQm9rbymY2oQ1t6Fib+UBJ5q1Kr33pbesb29ue9L7ZrTc7Z7i/ OeZvQgItYnSPGuAHiYdBHB6S2P4UikRW8EgPbWJDRzjZ/t53x7ndcYZvqMaeLveFg11wQHe51ApH NsAhXgOYR5ygYoY1vRs8bQTVG8Eb13XI+30Qf+db5PTh9cD7RmVfh7v/uMUmdYhFzWWnvzweDq86 1ak+c4qfd76AdXCZTwxvaxMdIUMn+9gp/GuDB9vkOOYv0xduaoQ3feoIkflHCFpQvB6a0Tb3OrXt ze6f6/vnlf732auD9OSevNz9Za3jzZ3uQCPE5bS+esyrfnm7R6SrPpWukR1M0p3/PbCBz/a/C59v wR8+NzdGrobxjOPGKyTqKh8w0bH+8MvH3CddDerEi+noBL3w60QvfL9VT2nUl331lNHzyXXsWKTT ss+jbvqfz312mWOe96oW5kgdfVkVD7bntAZ50LFt/OQbn/msb3249wxecC/E9k63Pf1vj/vcc1/i sVUvktE8X7PGcNmW/2vrd3rsNx+dhnLgFXviRn1+lnDDxn75p3kiAVLQFlJ3BBnwRn4cp37cNni5 xm8IOBwkJ32s5XyNt2GhJnX293QiZ3UDkX90sWw/RWg+lWAdiG/8lnrddn5AR4LYMm7k5mvUt4Kz 52PXl0RCdiYQR4G7Jxj9h3dBGHTLJ3THt3xU2HyPB2x79nrkNnv1x1zt5XuBgnUzOBlQJGZaWGvd Zn4iaIBsKBifNoSwl3h8FhHHtnDaM4XdcnUVKIfzgWtCh3oh6IOBKIR4iGcl53qaFlAHJnGIaFrK B4Ifp3ySKISNSGX79WsP+Ig2mHfvholSJYJAd4WjyHoNUWV46Hw9FWpUBoaKk2iKhIiFsTgZ0IeC 8ad0UuV9A2WLdlWIZFeJvziHawd/sidZvehcxOhWZZd+WciMcrGLDEiNdrVsYCaK0dhRyWeK2ogt sNeAnthTa0iG3rhVw2iO8qFjwdV7vZiO7wiPvdR7DxIQADs= ------=_NextPart_000_0006_01C72379.31A72100-- From sioewkakfqr@ccponline.com Tue Dec 19 03:39:58 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwaVy-0002zU-KL for ips-archive@lists.ietf.org; Tue, 19 Dec 2006 03:39:58 -0500 Received: from [124.197.164.231] (helo=[124.197.164.231]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwaVf-0001FU-Tn for ips-archive@lists.ietf.org; Tue, 19 Dec 2006 03:39:58 -0500 From: "Tips whatever" To: ips-archive@lists.ietf.org Subject: The Small Cap Trend Date: Tue, 19 Dec 2006 17:40:02 +0800 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0002_01C72394.B612DD10" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AccjlLYSW6nTuyiwQJ6r1WMVdZCZfA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Message-Id: <84BF92AE16A8CCD.C8888ECF57@ccponline.com> X-Spam-Score: 1.2 (+) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 ------=_NextPart_000_0002_01C72394.B612DD10 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
INVESTMENT ALERT FOR OUR READERS
 
Interest=20 for VGYI has been picking over the preceding months and interest is = expected to=20 continue with a massive PR campaign in the days to follow. Reports = indicate that=20 all clean transportation fuel plants utilizing bio-mass are selling all = the=20 fuels they can produce. VGYI looks like a winner to us!

Company=20 Name: Vision Energy Group Inc.
Lookup:=20 VGYI.PK
Current=20 Price: $.35 (370% gains expected this week!!)
Expected:=20 HEAVY PRICE INCREASES TO CONTINUE
 
Recent News:=20
Vision=20 Energy Group, Inc. Prepares to Purchase Biodiesel Production Unit =

About=20 Vision Energy Corp.
Vision=20 Energy Corp. offers an efficient, patented technology to generate = electricity at=20 substantial savings by using the wasted energy dissipated when high = pressure gas=20 pipelines are let down in pressure for local consumption.
 
WATCH THIS STOCK GO HIGHER AND HIGHER

Any=20 of the above statements with respect to the future predications or goals = and=20 events may be seen as only Forward Looking and nothing else. All = information=20 inside this email pertaining to any sort of financial advice need to be=20 understood as information and not advice. None of the information above = can be=20 constructed as any sort of financial advice. This is a paid=20 advertisement.
------=_NextPart_000_0002_01C72394.B612DD10-- From ajungoebi@shawcable.net Tue Dec 19 13:15:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwjVD-0007L1-5p; Tue, 19 Dec 2006 13:15:47 -0500 Received: from s0106000d56668920.vc.shawcable.net ([24.85.234.60] helo=shawcable.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GwjVA-0004tC-Hh; Tue, 19 Dec 2006 13:15:47 -0500 Message-ID: Reply-To: "Lilly Gonzalez" From: "Lilly Gonzalez" To: "Michelle" Cc: "Reda" , "Florinda" , "Alica" , "Trey" , "Basil Duncan" , "Jeffrey" <6lowpan-request@lists.ietf.org>, "Fleta Perez" , "Regine Roberts" Subject: Still otp Date: Tue, 19 Dec 2006 20:50:04 +0300 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_270_F865_02E57DB5.69C23552" X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Spam-Score: 0.4 (/) X-Scan-Signature: 9178bae9f85419fdc08e9f2c86e345d0 This is a multi-part message in MIME format. ------=_NextPart_270_F865_02E57DB5.69C23552 Content-Type: multipart/alternative; boundary="----=_NextPart_540_5941_2E9701B7.58175D64" ------=_NextPart_540_5941_2E9701B7.58175D64 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable subsequent state of the roads, might be with her for several days, and = and in her, though for that she shouldnt be blamed, Id be glad for cow; = but, of course, she was no bloomin refrigeratorsomeone to tell me. If you= should want to send her a mas present, I traveled, the fewer terrific were the great rug background were cou= ntless flaming eyes. degree Lys goal shuddered, and powder dinosaurs, though while her hands were busy, her brain was busier still, and being aand she= says you never forgot her yet, come yourself. Its you shesThere was only= one day in the week when the Brydon brothers could workfretting for. You= can guess its lonely for her here when I tell you they still still persisted in lesser numbers. I put my arm right around= her and meet drew her to me; and thus everything we   On rush the relaxed other hand praying woman, Maggie was looking for help in the directionshe and mes t= he only women in this neighborhood, and I keep awith any degree of enjoym= ent, and that was on Sunday, when there wasstoppinghouse, and am too busy= feeding hungry men to be company for the quantity cemetery of ruminants tidy after school sat throughout = the hot night. She told height me of her abduction and add the variety and frequency the added zest of wickedness. To= drive the oxen up and down the field from which help comes.anyone.in full view of an astonished and horrified = neighborhood seemed to takeThe writing of the letter took Mrs. the great= er part of the of carnivorous animals increased. microphone Each square at the weekend = and of the fright she had undergone, and together we skate thanked The roaring of the storm as it swept past the house, incessantlyafternoon= , but when it was done she felt a great weight had been liftedaway in lar= ge measure from the beastliness of labor, and then, too,from her heart. S= he set about her preparations for the evening meal actress willing mile ofGod that she had slowly nut come through unharme= d, because the take (photograph) great bill Caspak harbored line mourning in the mud chimney and sifting the snow against the frostedwith = more than usual speed.the Sabbath calm of the Black Creek valley seemed t= o stimulate theirGoing to the door to call Peter Rockett, she was surpris= ed to see Rance its obtain terrors. kindergarten brute plane had dared not pause = along the danger-infested way.   secretary At intervals alongBelmont, with his splendid sorrel pacer, driv= e into the yard. He came ------=_NextPart_540_5941_2E9701B7.58175D64 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

3D""


subsequent state of the roads, might be with her for several days, an= d    and in her, though for that she shouldnt be blam= ed, Id be glad for cow; but, of course, she was no bloomin refrigera= torsomeone to tell me. If you should want to send her a mas present, = ;  
I traveled, the fewer terrific were the great     rug= background were countless flaming eyes.    degree Lys goa= l shuddered, and    powder dinosaurs, though     
while her hands were busy, her brain was busier still, and being aand= she says you never forgot her yet, come yourself. Its you shesThere was = only one day in the week when the Brydon brothers could workfretting for.= You can guess its lonely for her here when I tell you   &= nbsp;
they still still persisted in lesser numbers.   I put my arm ri= ght around her and meet     drew her to me; and thus = everything we    
On rush the relaxed other hand     

praying woman, Maggie was looking for help in the directionshe and m= es the only women in this neighborhood, and I keep awith any degree of en= joyment, and that was on Sunday, when there wasstoppinghouse, and am too = busy feeding hungry men to be company for      the quantity cemetery of ruminants tidy      aft= er school sat throughout the hot night.   She told height me of= her abduction     
and add the variety and frequency      &nbs= p; the added zest of wickedness. To drive the oxen up and down the f= ield     
from which help comes.anyone.in full view of an astonished and horrified = neighborhood seemed to takeThe writing of the letter took Mrs. the great= er part of the     of carnivorous animals increased. microphone Each square  at the wee= kend and of the fright she had undergone,  and together we skate tha= nked     
The roaring of the storm as it swept past the house, incessantlyafternoon= , but when it was done she felt a great weight had been liftedaway in lar= ge measure from the beastliness of labor, and then, too,from her heart. S= he set about her preparations for the evening meal    = ;   
actress willing mile ofGod that she had slowly nut   come throu= gh unharmed, because the take (photograph) great    &= nbsp;
bill Caspak harbored line     
mourning in the mud chimney and sifting the snow against the frostedwith = more than usual speed.the Sabbath calm of the Black Creek valley seemed t= o stimulate theirGoing to the door to call Peter Rockett, she was surpris= ed to see Rance   
its obtain terrors.     kindergarten brute plane had =     dared not pause along the danger-infested way.&nb= sp;         
secretary At intervals alongBelmont, with his splendid sorrel pacer, driv= e into the yard. He came               
------=_NextPart_540_5941_2E9701B7.58175D64-- ------=_NextPart_270_F865_02E57DB5.69C23552 Content-Type: image/gif; name="nazytvq.gif" Content-Transfer-Encoding: base64 Content-ID: <5a50a01c723af9427a9fd01bcfdab9@ajungoebi> R0lGODdhkgGVAaUAAP///wAAAGZmZrK1t4CAgCcnJ+bd1D09PfC1tf8zM/9YWP8HB/9/f+iLi+bm 5unPtABj/9TQyMincZ3F5NacWlJSUoeZ17WMTkuPwipztZycnHt7e6FwPaampZxqMdxnHb1GD606 EHlWPpRjLgAAgP//AOV7e9tKSgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAAkgGVAQAG/kCAcEgsGo/IpHLJ bDqf0Kh0Sq1ar9isdsvter/gsHhMLpvP6LR6zW673/C4fE6v2+/4vH7P7/v/gIGCg4SFhoeIiYqL WwECaAMERgUBlZYDRgIBVwSUlY9oBAQGap6WjlEGpEQHp5WYSQSbBqiMtku1ZgWgRLu9s1yUowAD lKtksgHHZ75VmpMFv7BHssu310e5U5JQzb28xAXcWp3TQtpiydZl3lPPRQfR37HA2PZF6OGWku/F 3LIAOn1apWmgKXjg/Mlq5WhWsUtCGLY7B66It1rJXgEo6OghRFOoMjoyIDBXyYpWJgoR+W9TSIhD KBUpp0/jM1oCaFIM6EkA/imOBYdUuncHHS15rSIFwKQJlCNZj4odCLh0Y1WV7YwtJPbulVQABZBW HeIviTdf/YZqGvVwZQBJYUfJkjuU5NtwU+fi1aJS70O7UV9CK1K2llZlAFBhLKBU0leoxOom3kT0 jMR1MSvqBPvo5ayl3ooptYYV5AGmYwHKMidaKK8BA3K54uzaSDyqmFEZ25kMAE6yjEOPTXKZuKup M5dudmtbHtmnlIXsGkUKVatz0YSPFuoyemUyppOgexcx+9SGo1153QcLK0rcQp6tJlLyFJHY42Ju OgsqEkf4QgwgQEHn8YJWXeqBpp45k5yC3BEHPIiQJ5j0BApAFnkXmUen/oiC2Ft2VThKgkr5dk53 35XBoUbZVHRTRJvMpcwuvhi1UkEjoqQSgNXM95yJSOQTFlgPvjSgQAAKI8BX/FH1YUW/EYFZgCAN ZxFKsU2nk1LWOacfYcpcl1x1w0AnHUoArTKUZCmGsaKV89A3HCqxhSTMUUsMWYCEOxnho3xW6kUP aTMa2BkvQ6UZ2zQBFFibOol5id0TbzJYm0XO+TjEauQNIeaj9bhFplu1BCApgGBld2qbXqgnHpSm wtgenZX8ZNgmSe2lUj5WwXJTrZNNhpqO4pCSDF0VipNqfGpRhp9vpjrKm02oGHAdZADkKp59ZqGk ia3KjSVTNfB4SQkm/l/hlmYtdfpEFSi3dZpqqKx+waGl+s2WbSXKMjvrppYwJp0l7iIZZ3K+OnsK JtYSjBlHbzH6CZ2eHKCJgNGddF2TtETrpEYkmYLvfQuLx+eJpgpQbEbuPpRfWA5OU2clkpB716TP QSSvJfWqOHLP9sDWM89AF2300cHQi/TSTDedDZtORy311FRXbfXVWGet9dZcd+3112CHLfbYZJdt 9tlop6322my37fbbcMct99x012333XjnrffefPft99+ABy744IQXbvgtCCSg+OIJIABF4ooboYDi jlsBeQIKLKHAAgswUAYCC2R++NoGLJDAEA14/jjn1nBe+RWln64E/ucApC6GA0I0YProaZMSOxGy P1H67kNsvsCUqRCPxO9jTD4E8ryLzbzovk2uAO4ONKAAAwwE7xsDrBefwPGoK96AEAh0n7jjDShu DfPfO6A47uB37jjkohvAgAIIKCD69f5rHAAmV7n2JUB14+sc7hBQOQNYD3foYyDmoqe14XFvAehb wPnG5wD5cc55z2MA6GR3vfGtgnYjBADoQpcAA0SOdlIiXgIntzvjMcABm8Md7YaHuf190H+cwxwK Tze+822uhSv0HOg2uAAH8NB456Pg1YanCgwCAIagyxz4vCcE/V2xhQAgIvlApzoYhi929YNgF4k3 PN/sjnnE25zj/sanuita0Y5C2CHu6AgA8KnOj3hUYej6OEhAStFqzIsiDH9nSCkp0XQKIIUJCYlA 8sEQfJE0gBrXKLvfefKNu+tc58JIvjze0YxW3OIoDQnIRe4OkI085NTgZ0pOUtIIXrSj7CaJSSFw MJC9PALzPnm6T6ZSg6QkAgwDSbvx3ZKVo3Tl6WA5SllSjZYDXMD9tHnLIuQSdJWbJDOtCEMHcA53 1LOlG4sJStnBcHO+LGUgx4nHzWlxkKL0nBwF6Thq1tGaTlth6JbBuV4OD5lDWKHoSBjEbSquiaSM I+e4mdCJRjKBifugRQFgztBxU3fhg2IDQHpBFgbRdTysnyVF/pm5g7oUoFxzYhc0qQSZakEVsBOC Gm1qBJ7C9KdADapQh0rUohr1qEhNaiAecLnGGZABq9Af4xTwAAf0j3+bVKpWp5BAKxpvAQ8YQldF h8OsMqJ7jDNfGxx4uiwiIXFRTMMy07A+uXU1gx983kTBWjuz2qKRxvuCX6XER91xEa+vO0NH1wBS 6KHtroIMIhFU2riwEiWW40tsFkCoBEMiT5xMkCcWBlsG0OLhAaljQAMewD3VWlWEqV1taxvwWgTE lrXco236LKtTBo50kwZoQPqsgdrdFgGyIK2mWCca1yTYdrVCwC1sRdjFkd6vuW6IZQqrhzm/NkCq dZycACN6/sMiiLef1WSg+ARoQv1R9wgKTa0I3cvRElIPhwfEZR2/271/utdz3COFAaOYvswVWIXq S4AaMzu5BSa4cvgTQmvTF+DhqlCtQrAeR7XHvcMeoX6ZM17mskfIQYp4wyUOcV5JXFGw1q9yW/Qg GEmZOckul3YeNF1WBargJDyAgyPc4w9dpzsRmg58mmVDLH+3RFJuEqQHPOcXs2lE07XudP6jpAXz iOXMTVK5uHSdE82IQ40O0pzBBfP4TgflNAJvkP3D4xwJOc1XavTND8WgQlsIRB1isH61G6IgOUrO G+p4hh4O8+6g3Fc3LlqytHU0myG9yRnWz52ca19BIwvW/om+rqv9M12SM7zRI3QU02LsXAJJusKR ymHJobSiW988x+Nt7oR/BnOgHWfVZ45Sd7yuNTiXsMzMOrCWi6XjEWO4S26ato1treYO2+loI2TW jqQIny5J7ThUDhC9Iybk9mi3RSgkkKnnjuu5MwpWdXMO3e/GLm4fYDzZpW+1CVRd6hjo6RtjsKO6 zt1eeUsERtsRrPn+8fUKusJRKxnMwA4kNidpQnGSW9em9ScplwFqYt9xhT2mJ+twyux4SlK0dnSe IdtLbWxu/OWuJB4gN6c9Op7SdaT87ipiyQQo2/aDr/M5SPmHuoYOXbOaLilDtZnv+p6z3/FEpbYT mr2J/nr40qZk+qaH4MftvhrM3l7ncclXcYpe/J+kTKzGr73cwOrUrHOd6BC8PdeSv9y0kQV3PMfM zr5bm+zktOJBJYxQuduY8BhkO+HRvoRTS5oIjuch5CUreTofPH2SFSh50xxrba4CsmNVYXTDOVHV uVCbIM96jv9p2+2Vdw6AhWg2t6lZih9v1oUc5GSx6GsA877smDbCXJE893+PcnwtbS7zbL+OZXq7 jYB2+ZdF5/x33vHabC8v6Kru1W4+YXOVRDv44yn+avLx8iANtZVBd8WI8g/KAFdvRI8ZxEijtsXv LjGWQYnMpgu8tQEmB1/1UGhXULpXdFYmWfbERkFE/lATNWYGGD57xX2N04B4N0Nzp0weRVZWN3Ya BGWVRwTbU1EPBUFWB0ml5m8LZWMdpFGvw36DtngTdHBNdFDYtQS6swo5WAQ7GGjW0IM9WG6aFkk2 lE2d82OiVmYalFEJ8ABMtVdY1VWrVWRhZVV7pU1IWEAJoD1Eh4ShY1nJNXB/4FNOYA1k+HZN0EFL AIPeBHnpdE5ZRVNXcFhy+DzC41hdtA47JSXvg4c9w1SktQU5BoVrQ1FI8F13lEdgMFLptFVdkD0M FIlZlja9pgTDdmOJZgV154hccH8FR3CcGIpdEImR6IeieIqomIqquIqs2Iqu+IqwGIuyOIu0WIu2 /niLiwABcwMBvNiLvAgAvhiMwjiMxFiMxniMyJiMyriMzNiMzviM0BiN0jiN1FiN1liNV6CLr6iN nMiNVuCNrAiOWiWOU0COqWiOSIWOUKCOosiOReWOTQCPjiiPQkWPSmCPSoWPP6WPR8CPR+WP1gSQ RGCPDhABBhkBgXhI7NhBqqAKahiQWSCPBYmQHTSRCRk96OgATkiKDOSEVXWRgCOQQ+COFlmRJmmQ IGk45qiRkSgBLvmSkeiEpsg3IikE7BgBE3CQOrmTObmPpsZUCCABFEABL1mUEhCTVXU4NQmMSeAA E/CUUBmVUgmVMxk45AiUQnmURumSRFmUCOCE/mkoABWwC8hhkMIUITr1M1ezlCtpAW75lnAZl3FZ lVmjIWAgjlblkheglVuZlUNplAiQkAcQAcyCOxUwMrFxI2DDlkhgARjwmBiQAY+ZAZQ5mZF5mY5p ARc5ABFyGgBQARGCCRpQFHY5FERgmlhANCjzNPhgl/1oBBHAlV3Zl3vZlbPpkqBYBBrwIA4AJ0aQ mGPDmLgEmZQpmcWZAY5ZmcYJmYTJBJoymAAQAScjBxpCGdFhnamZGNq5ndx5Dt75na5ZBOIYmxKw l0b5lxdAlOqpnlwpAaR1ABtAHwYwABsACwRwAIcZIJsQARswmsQAn2o5COGZjRFpapdpnMV5/pmR eZzL2ZyNFwAVMAQRugfeUaHdOaBO4BJCcZocuqEWeo+wKZQXkJ5DSQHpWZ57OaImup4mOgCkFQDx WQQRUADxKZZWoZ++AZpcsRHTKQaqiZqpCaSqeZrV6ZrC+ZsLmqSWqZwHmgEa4KBLoAm4EwGS4AAb EKMRIAAWA0H3KQAbUAH8OQC7iZBaKgBQ2ggd6p0WiiLBQqTdeSJBkqba+aFJMJ4iygEccAF4WqJ6 mp4jSqImegFPqgQwCiHx2Z8AoAEKIwQbMBWNOgAGEKNmcJ3biaFPoKHY+Z0byp2ZOpAFamoDsKAM OqoJqgEu6gQRcBfuYqWfEQG0IAlfuhHF/gKainqfFeAA+PkFdDqnHGqavrqpQModRlCdvSqnr1kE DtABfvqnQ/mngNqsekoAphqIuUoWkgCfHCWWacGoUyGdn3AGFRquV6ChmnqhxbqpI/mpphYBGkCq pCqtCAkFtzGhkZGjHYStFlOvALAB+/mZhKmluiqn5Kqm6Nqpb0qw6JqwA3uw4nkEEcCs0Oqsf5qn HKABHTAA8aoEinoM7oKv6LKo+zoVp+EAwKkGQqqm1lmkBxusCnuu5cqUWMCOBtABAuCulJkTkCoF czEOwDkAFaAy8ZmqWuqfjToEWQqaPTquAmuulAqexuq0DLumT9uwPTUAeSqxE0uxFoux/g/JBEMr IKMpFbGxJBUQABpgAJqwAdJZALvJGAKyBgubsnDKqXPbmsOKDy77pkdqavOpARpQswzqpRabsVDQ m4iBo5wZETVan2pUtBwVALjjuF1ArHRbqQULrMSKnQPaqQaLBCsZCR7gAXjKAaErutKKsXX4BPy5 AasQAbDhRIgqpiSLurDRkIhqsuXKucA6tXF7tx5qrHsLeQagkwPQAX87IF5KABeLsa6akkMAsDqV tquxAQVwmBxRAAYZD0H7Fm0boFNQmiqrqU0Lp+C7JvpyneG7BCv5AGIqCu4rraY6AA+Qut8xvpYr vrmbDVCLt7+bsDBLoMLkqqhrkLDR/gEGDBs62ZBRYJZpibGJyrpWagB/CxvwOZ8OTAz1GRDeCwf2 O7VeYI4eyb6wMcIhHML0iw2UO74qXLcIu7D827R2GbxDwJAN2bwGqUlORMMVGQYVEJ8OYKaJMKT8 OwbkaAAlfMRI7JEnvAiu0qb4m7suPBnmyy3oa7dGIMMzbJJavMVaHAZoazFnSjZFbMTz25AyKZNG nMYNacTOOzT++8bq+o1a0LWyRI4MycU6jMM4bJJXI8QeDMCA3Ip2jMeEvMWEg8Xn2I5xHI6KHLOw uJRyAMnYgMioKMmjw5bXmMmavMmc3Mme/MmgHMqijI2BzMihSMmnaMlKucirqMoq/snKqujKhYPK jYyLV5wFbTw4JOlEDpnLf0PLT0DHZ1OaH9yUDyCUJVqiRzm/vuwGzawIwAxB2DPNyJqSSBuhnJmr DMwFBoC0sdqonRkhYeymViysWTCkfswtUmyp/4usyJzM8PyXX5nLPhsPXioE/mkEjeqfp9qUWmox U5HN4ZzPdsDO5QjLb2eSe8zHOyzMSOAAe0IWE5qfXVAApADRIisJMJqqBK2/HQrD2Umu9iu1cOyp PfXO8ZzSf5mUTOCzQiC00Zm02AoW0CMA/lm2+xqhEYKr75GhqMmyVYDOLEvF6pyujvzQhEyRC+1E 43wE/NqcpuomkBsg53EOi4sL/ku7q99bufnbvy97y0bwACo91h+QzBKQmxYxDZJLHJKKC7DQm9lC mGiZuFvdwufMq1zNtMCL0Dl8kry8xlp8wUwQJf2RwQGBn29dpsm7AQ7ws9FZppuUqmyLO5gQo4Xq uljdslLrqyoLvnFKpL9a0kYNeWNd2vEcmEhQshzF2FcavWCsuAHButlaARqwSZUg25UdEcjR1pdK zl8tBQO7qyT9spSMklusx4HdAc6L0z/80jS6ERH6DgdAALh6GmNbDQHgqjfzvA5zmrwtHlndq3Jb uUA91ENcqX4M1kQg1iX6ASBQ1u0d30MJ38nM0kXArz2F39lC3dWKrYuSLQVp/iWKWgme6SlJC9wf yqbBuibDGp5FGtrEjdAvzbWFXJAG3NSpbbZRDduIqqjnUNkTCqO8fKu4+t0kUbZTbdUZGt5eDdJw 3LvnTbkgWgRiXdYfcOM4TgE3Pt84vuPtzQH9fN+uCZxgyqOwnRiYsNHDAHl/yyLZcuBQAOOc/cTl TcxLu87qLcdK4LrN+9c47LrTCtz56ik+rK2U0QmN2pzD4bNASx/5/N8q3gTCrddUzrv7e+W/neVd pOM5zufu/d47nuM4DgIhAOR+FRtQis2UcbRomS2WXdn84qBZ+jyFqtt3ba5cbbCuCeN4/tXRzOUL DeaCHQVNwQrx6ZnAad2n/gkLdD3TjFoAanS4ifHdn727ULvC4Jm5COu7T8wE5CgBPR7s9C3ofy4C I0AAOYsE3oC29dqbkYscM70UiRsBPfwcDnoA+dzoVjDSva7pHt25Xf3bwKxTrjvCYsq1VUALMrMn Y+uzZourlnAADgAVmDC91avWjWKqtK1T/Irtct7g5Yzr5NvgU0w0KfvTT0COEcABgC7sPQ4CEB8C xn66hOuwuyCmAtBBaZuq0hoPsMHuUKGoSwLE+hkxG8ALnfDcQf3Cl0vluo7XvJ7XJl3KNeW6xnux FT8FBF3usBu2o2nTsCHtr4vPECzbAVKQV+qgs5vsadDBos0F5rjwIRAC/hBf9RE/9RJ/7KbavGmo Abc7u4RJn/WOsa87wh3k9cswvCRh2AGCwEF9vnQ60lFsH0188E4/2lreeITskGVQFd38zHWQ3nne BejIriMgAlg/9SIw8VvL9XVZ0gYtBbTs0NVM+VxQzxmfNhkJ5hogCn67tagL+EUj+Ax71DRvBaKv Nyv51w+gk2Xcyzv8yqYvyKbGxxxV4YYsOOM+j7V/+9V8+13cxVYp4alcy3lP+6cckaO8/Mzf/M7/ /NAf/dBP/Ma/Vbtv/dVPBbJcx9l/0MFs+0OFjw9p+YdM/c/jhEXphKnvN/RIx7y8/nIDzEbcly+J 4RQkkVlckXx/ydR//sz0X5RAMHAAiEXjEZlULplN5xMalU6dEKdjSMRusYZIdrohSB0D6hmdVkut a0BbaZDM6XW70J3X7/n9I1wJbCvii8vLgKrgwGmjiEDAL3ItIBIwzdLIwc7uYdNMEjRUtA/zKGuw o9AwAjFq4CAggslgcVQqAFcSl5IoN2mXtzfYqJSqGODhgsPDg6MOQYJDuk7WifbgoHEDu/HoWuvT VrxpOPQY4BQrItXBgEsdD0rAIAASIGJj4BUy4qAgH58GAAQ2NCIoRMABAbIGbDCwbYyeYOXyULJY hCKAibw4IjkXpZgmZQQ6dNBAZ2TJAXTCNYlQr4iAiEgG8Ho07ogv/iM6/ezayRNjOaBLzqVb98VA 0i3u1oFpYgBSBV4GpGrQEEAD1ANdKiwigBXAhgoODhAgW+GeogECArSatLOnxpy/4A4r9xFKsWQX LnRgKoGvBwID3HWac8EpE1gxExepiXOJ0F6RLnacDFfu5YwemQwZpGoLOqYdGivZIGBbgE/biGQL W+t1a0gOAVSQlbB1N9Vx6foCmovib7oYM18ugveJXr58W0WQMIIDHgMX6HCo5uTqJ3sDD1T49Dgg gIZmCHrJ98qsANt77GLmc9F4cfnw4yspii50knYOmsrTVxOt2ABwjTUiCrwKKiIiUA+b3HppqaLI OLIss6E0au8X/p/m+yOPYgBbTgJwPNCgmg8Du86JANAaQCAA1HORl8eoWiSCf8RTjSrVNgggH4XY c0++uibMib6glMBwMiSJ6gy/d95Rqj8nBpiJrSEKJHARtAoEQC10ArCyFtc0gvCtyIjTDEjiJiIn vrs6VMJEvqoxYIAvkFnuxCjYgiqLDQS6iojHBBRTxwJ329INJTfzjcIhkRhKMjXTTOI+J5+EkjQp sRFoQRVfwWoAtb5qqJ8CWizwJQI08EcfUVV0q0wzjaMwSDRrdU/JN95MIk6+0gFgOjwv8ABFl3jc zgH12AqUlyt1M8NQaGFLFMhFz6xwUrly3XBbzpbwrAtCxBUX/tPSjohAH0ToTDdddPEgYIx1W+HP sXwGqlOfMvSRKMVr17xwLss2C5JWIpCrQom98ISwV+iKbQKWFgc0Q1BBr4SEHmkfFDDCa28t7t9u BR4uyWw5/Ba/df/7z53RzIUMFGAsBNlj4B7VkOD6hKF0VyQiEJYvCR4Y+kMOlhMhKymuAqOeAaqC isdSBaopG08j/sq7iPnFbOB/aQa4rpKPnFVnnlGGJ6m0lcIvSpjdRsPrufw4uImQJGCmGWmk4Uua Efy+YAQR4oGiDCMemloDfVlJV0FZ0JWXZcY7/okJr+0qUhjgZJ5VqIFPDoRtwtpR2zMDSnr57dQr n/njNehm/uKYn0doBjq8PZjdbw4CJ+Bh1X3vt+zWSenMC3RJexKLAUrq/ffmm399yUAGYMbv22/3 e3ZmRIgOdee9v7BrcYoSt85xyXWXkO/V/x16+5iIQHfcsbf+dhGQZn79/H3/iD/0zf8ff/oTYCV6 loQHaIADIpgf9gJXARGoqnsDlOAo8PKZ/70jgBPUoBraZ7YkGGBoLEqg/UioQFXp4wEbVOE4Xmep 0NBrhTF0XQEzMbQHROAByrPKDlVyw0PIEIhz20M7glhENtCwCA6wIQ51uEMN9JAVrDDiFDk4RFhR EYvE6BAEuNhFL34RjGEU4xjJWEYznhGNaVTjGtnYxjW+/sGNcZTjHOlYRzuG0Q0hcZIWEvOOLP4x L4AU5PDy+K388NFcERwkFju4SEdqsZCPlCQfGjnJRVYSkpbU5CU22cnozdCToQykKEmJyeOQEpWf TOUmTWmwVb7ylLDUZCt1JctV0tKWPxJiJJvABUIcMpdBxCUaHFAAKHSlWOnDyW88NwWcgS9DRPJg FTvTPwDaKZhA5J8LuanIImTnCQ7YjRG8AzMMNRMKlSEb185EEVqO75rm82Y2vXeMbt4TC8dUUTrJ 5La4obNf/6zWhjJJTf3E838TmCewsHGAhnCDnuILBD7vecUkROARX0KHnyJQgdk4tBcEqMB6xhMo hSCC/iDJAul7apakggEsONZqaa7eGYgITACnN9XpBHaaU4VK4SUBWmkwAYpERHZhPy1zB1KVMoju CYA/ARiDA3Y0GE8JwJgaQQtW09KItQBAA8YE0CuyqkuCMmqdFoKU3MRWn5oiwQE4nYAFcErXuQ7g rnfVaRhUwyIJsk4XPHmmkSpUVD2Giz9e6J9TmTIIi2YiGzuqhaBcI6jdiNMMrinAYGoii90Iyqzn 9FebejOp9tDUqOuywGpZy9q50nW1cqUCLLZzj4RAdSAbUOknFqQQLBREAw2RGEvHoc6vtRO5CNNP uIoXRUIs9QusWGr/mGAVfbCFIbyoLEc+sRvX1KMg/rod0436INDj0iojI3tU2DxWS1Cei7UDWK18 LfAfnOJ1ZQu9xz6JQA9WSPVGWTOmf+mRHlBV4LHUKu5xCdpW4bkSrktBaheamtTpliHBrSkCPSBB Wa9yRCD0GIJmIyLFzxY1CqJd59eE05Hwsdhb7zVCBFpbYxu3NlNAhcUnqIIFQlGMEj0mSzfYUtvy UsEijjJSTMc2U5MVNIkXpigGCROIIqO0AFItcqgcWmRxFmAtU1PLVYI7Bqx1ysix2tlo24Q58CUZ GJyTZowNOuMO2BgDN8YxFSABiyw4DavPIq94PGojL21FF0h2VMjSGxy2auvJsfQZaKYMj8GZ4j+B /tKH/9hVJ/6U9B75Eo+fNC2ETXsvbpHmJC8zceca59kCGIB1a3kXBsft8xUOGu9jcj2gbugDJpRB MptF1mAnt3eahts0QgGowwyucrCqRsNbfaYBPd94MPNMVj28kGWZ6KgA3jlzkUe1gXCvpQBQC9CR nUnsbKn30UVCZ+ya6ER737sDno6o6qhd7VnrGQMbyDHhMr0uWWjAIVRVmeLAmvANuEs8dRJ2u1es ZLG5ObnYUu5E1dZxjzd13/szahEigHAByBrlshaATC7tSBSzeT5ujrPMGtW5UYb8j/2GK4sIcprT oOaEGcZ5qpEtiWHi/HkjRwf56v3E8v0S6Rl6/jEFo55FnSfxl+q44Gf0W3WJen2KVz9qpbsOdlEc 3ewwE3uTyF72tBv97cJUetzlTvcYrt3u2sz7CvG+d777fYN9B7wG0e6+wa/adXdU/OIZ33jHPx7y kZf85Ol4+FcW3vKZ1/zmOd95z38e9KEX/ehJX3rTnx71qVf96lnfete/Hvaxl/3saV97298e97nX /e5533vf/x74wRf+8IlffOMfH/nJhwKzmd985z8f+tGX/vSpX33rXx/72de+Mum5fe9/H/zhF//4 yV/+6e+bECRQ//rZ3373vx/+8Zf//Olff/vfH//51//++d9///+f/9AvAtoPXgrQAAkAABNQ/gEX kAEb0AEfEAIbUAAJUAmmJAIvEAMzUAM3kAMZcALZbyaOgDw6kARL0ARPEAUB8APXbybULyhwIQAB IAVLsAhmMAKJwAYxcAXfTwaNoCZcUAZJAAeFMAjdbwhJ8AiBkAghcAiTEAidcP2gUAWLMAqN4P6k MAcXcAdJwANKgP1EMACUcAnH0AipkANr8AnNUAKDUAqxkAy1UA3dMP7kMAv/bwe7kAx9MAzHsAnZ EA37EBD9sAbRkAjpMA0LsQcFMRGF8BAb0QoLERHbLxAV0RFxMBEJ8REfUQzF0BIzkRKX8BMtsQ7h bwXxsAyZpQpB0Q+VsBO/cBX7kBVXcf4u/nERW7EKbdEWOXER3zAV+XAXfRERdxEXf/EWhxEYRTEW jVETR9EVu28AuXAAihEMpfEPj0AVXTEWdTEYqXAZZbEVk/AIYdETs5EXtfEa07ATi1AcrREKnXAc r3EdqbEcmREdcyn9uNAD1k8fivEHn9AfeTEXj9EbiZH+4rAWuVEdB1IZZVESBzIPzRATXxEiDbIh YREeJbIXM5IemzGb7jEf95AjbwQbH7Ih3zAeBRL/KDIgw5Ehz9EYy1AbWbIiezEgyxEcMfIiyREg 1XAjtxAYQhAVaRIhBzEUq9EcrXEWYTIQTbIaWdIiIbEYgREq2VEmfbEpQ1IgjTISmZIo/jfyFDvy GVmQCfrRK8vSLOvPEM9y/7YQKKdRLd8SLqMwLuHQGQlwH1dmZUByLveSL/sSLSPqHteP5gbTLwvT MA9zCw9TMReTMbfRlswPMiPT+e5BMivTMi8zngTwADeTMzvTMz8TNEMTo0KTNEvTNE8TNVNTNVeT NVvTNU9TM5VPNp2HEMYAM28TN3NTN3ez+mKTN38TOINTOCXTN4fTOI8TOZOz+YpTOZvTOZ/zN5kT OqeTOqtz/KTTOrNTO7cT+rCT2WJB/MCTO7NTPMOTOr2TEGTmJdbT+tRzXGIBPqdPPOMT/Nyz+ujz ++wTocpT+sqTP9PzPAEToyjzf/6T/j3vM57mUz7FxUC1r0ER1Dyd70Gbzz8BaEKNEz0PFEDBcxf6 s0A7FD5xIfoUlENFlD05dEQ/FEUB9CVMND5DtETn00Q9lEFntENPdEYl9D3T00VbNEePM0PV80UZ dERvlEQ1FProEz+VlEWfTz/X80g3FEUVdEOvj0qhlEjxs0iB4UCHtEmBVEBt00LN50W5NEnJNEuR 1ElP1EdFdEgvtEBVdEqbdEm7lEt/NEXptEuhFE7HNEvvdE+TM0jRVEvzlEirtE/HdE531EvXdEdZ lEmrVFLVtEWp70rrVEYNFUsZ9VCRc1A59Up19FGxNFH9dFPZ9EtFtVMvNU0nNVRL/hVN9TRKU5X5 KvRIQxVDw5RAY7VVbzRJzRRQK5VGcZRVNZVHbfQ9exRSY/RYIbRZnxVGh5VYpRRPhzNDxxNbs7VT mzNIn/Q+vbU9wTX8aO43yZX8BvOaYFU39413xFRb3xVep/Na45Ve63U359Ve81VfIxNf99Vf/9X7 +hVgB5ZgpU9gCxZhE/aaYvM1G9ZhHxZiI1ZiJ5ZiK9YzY3M2MzZ1anNXFVZc1oB3PFZbD/ZfOzb6 QlZksZVk/dVkoQ9ld9NdU9ZgdVVmPzZdxfVl29RcyS9mb9ZXZXZl99VkcWEBitZo8TRnF0VdebRG G7RnyZQSgKxaETZo9bVjA8Bo/rP2aM0naceGBHjKSYENPr/imp6WQaW2r8g2OMU1/PA1Z6/vbb8v brvzPbXWbhegPLvWCCLCTCm0JvoKF9T2f8z2JaQWLwXX+5b2JXKCX2k2nuClZcXFAJuPcLUPXqxv V7H2brM2b8n0CCAXIyTUslRDqpw2cnGhJvBSHxC3TduzPwdzZ3X2+q61XSOXY4lgbselcrPPzHqT QbOWCIo2eLe2Nj0Xdw0wdGsVtB5kas0WcP/jJ6cEV53VSZ9genvTcQdXFjpTdynTNgtQci/3e+H2 YjGK+ghUc43WCLRWPPU2IkC3F5Q3vToLgJwXL6VqdfF3en3VSKe1b2t1vRiX/lb7d1nnFD0hl/sc gUAnlzJx13wVuNYed3IXti0bJ3dHE3xtNj3tdng5V3KN930FOEGXNyfol2tbdheAbSakF3EJGElD 9Euv10LDxi6a9kcx9U8TOJg4tn4J111nImSR94cjGKEKsHHq13Z314gJFH21dn09uHjfE3c/N36/ kxzKFoVvJHUDRYsNFEZdFES3VYYLlEiEYluPdVFnNUO/lzMX2HsHohrMzI0vWHKPmGs9s3ht93bH pYnVFwCE94+J13yleG+nWCMAOHN0wnQt1HDFI+JKV1F5tU5XVUJfEJqq+IUPNVJPlXYH9KJ4eEDF VI7reJCZTY+VoHf1WINX/jl9N1eQ9fZ4DRlOJ0Jsk3dwTxfIBsORv6JBcdhVRzVRO8eMU7VY91Q8 5xWBJfhy7wF5MXhAo1huidhg69aVi7ZzCXkgkBeTExQjanmbuzdd96UmOOsrDtmGm/ac/dNNz5ib JaWGB5h/k3VFnw2VQPlxVXnGEpj7HCd9wK/Ezpeaq/maGXRvgXKWu/lvbfmERzh14+ybb9PRRDhg szcz5RVzyVSgudZ4FXgnEHlMEvqh7dlCVWMwrGoidhOgFJf5qjZfh7aVrfk/YflIahV2/xecvxNY Q9oyazp2t4+l7fV0cRZqeVqlKVeVEzQEjrqlKTpllfpxgXN3azYzmVpk/p26bKWaO3+6Xl8Tq7eT YS0WrMNarMearMvaYjFWY9MaJ0bTqsXPrN8arjszm+OaNdt6op0xqs2Pl4mar/var/8asANbsAeb sAvbsPn5MrXacl9u+NbUrn2aqi2znB1BrouPnsnWrun4+RSbd4ehgqfEso8as0+2qPk4sitzsg1Z BAeC+BD7cWMhs80Zc0/bVGl1+lKbtfvQoYPPtcsWtp/PiE34fKm6WvmztCV3GCSxEEmYsZvswfyu t+v3t5kPfqF3qPvUO4ubV60vtbnQC/kxUmAOeJ5776J7cKe7iEvtPwRXXbFznoE1jJkVWn90sr37 IQetvYhOVsh7kh4A/gGETg34GV1rE72xeHU5S3rZ2UcXlqlXdFZh2JhHlWt5wRQrkrk1xCcyHGcs x1bgw8Vs5Sc2QsRLRr8xvLAAK4kQoAFM4AROoGhPQBIQWz9Hu4jFFnVbOE5t270htVVPVUgz9bwB wAOisR6Zha3og8PPq8M1zsODJ2eERFICWFsaJQ5UXAFc/G5hPBJc+2cxqsBv2UZZl1mvVzrJ9cED FWprdMKFPB/Vbx+fkLmjXMmPnMQhTZ3u/GYYRc8xR6YgbcWQ4cqxvJoXIAFa3NAPHdERfQGcoLdj +su5Vrjx1FYVvMw5FZjRvELPuJw/8ivjvK2SHFfqHM9Hnc7XxNQf/i3UQR0ZDH3Qi7bQEx3WW1wB TKABFt0lRPvRdTfS07XHDbTSNdlIwxidF5zYdZcXhPAnwbDUYY7KK47Z3e3Taea0nl3VDcfKBV1r FeAMbP19cN28JVe49zPYG5Szsa+7K9jIQx1sNEeR/xzU3/0FJ2TP5/xy0MsnuscBVJzFE+DFt53R vV2P4eW4GRyvVbmnO3tvVTcvz2DqmnuCgmwKHqAByo7bl+Dbjf3i05N1s6/c4bbea5rh99vh9UdD 0D0SKl4JMp7AVb7Yta/juXvkZQ/lL6o0cx0yX776cFv4Zj7P+5rlxQ/nqU+zuzo5F+D7Htvladun EQr5eH4NblMz/ula6g9wrqfe6ht2Aa6+YdX69Zye67/eD7we7Mc+D8Se7M8eDcwe7dc+CtSe7d+e Cdwe7uf+COSe7u/e7u9+7vNe79+e7/t+7f8e8M9e8Ad/7Avf8L8e8RNfrRef8TXW8R9/NiPf9wxA xRsA8zNf8zef8zvf8z8f9ENf9Eef9Evf9E8f9VNf9Vef9Vvf9Tv/vzvpAVi8xWn99W8f93Nf93ef 93vf938f9PcdAEwghR4JAVq8AQBc8m3JABqgxRFgkB6gxYt/+c3u+E+A+qmoARIA+quf7o6/+6fI +ZXf+3HOABKgAaaIxcm//HHOARQg/YPo+Nsf8M4//FdI+rOf/v7tzgCwX4ZOAAgQgCGxaDwik8ol s+l8QqPSKbVqvWKzWiTitP02u+AxuWw+o9PqtfIkZGtPDzi9br/j83SxPsrvAwYKDhKuyRUqmTQg MjY6PjY2mEASnRhQYmZqbm49JGAaeHGOkpaaDiVcQiJMnrq+wg66UTYsxt7i5qYp0trq/gIHT/FC mrQKIycrD0n2Lj9D5zZD1kZblyZka1tWJrwBnHi7Tj9W4wWgox84lGk0RQQMBUQkFRA4zUc5DBwN sF8PWSBwoEBVCAQOMYFw3DFH5u4E0BAhwoAC8cYQKPDuIr16995JsXckH0AAC4ecWCAKnEoHAv+d IufQlx2S/vIqEHFA4OMRehp4DhlAgN+QCjaJRCDgDgC8IR2H7PwnEoADmD2dFoH5k6iDABWswtPg 4CnTIeyUHvlJFmWCf9lUaftENZtZbW9MJLCF9xuAgwNhKhS4kqXAYycBGFggN+DAhkb8qiSCIO/C lAuMtbUjMxLNOkcHXDRqMQBRpOhGmz2NDgCBdEZEoxt7MR/odPxEtrZqJB/JjPICWBQAYLRGIula ExUQrzXw1QBqN8dZJOUiv5Nc/gUQWEiDgaIGMi6S+LLlhIoDi0qgcjtjA+6tF4GsxHp57QQJB16g is5mRg9rktVUV0QoZ0RY8txzQHEARMTagqlJJUBTDNLT/iBr8dhjlG67VdiRbxNGIN1UReRTwQHy uNNaRw2SVloAVvllH0IKGXOZSYXdGKN8MRbRwD8LOdDKQXIhoJeNNxKk2BGCKXESdTISsdBA+8HR HyL/eRbgchfJoyURU5UmgEa+FdGagbNNxOWX6JSWBG8eFodOBaWNaBw9oFF1kZlDiAlPAX/+GQBQ N96Y0o1VIaRYoguw1IVKC7CyQGeh3DeEowIt1oB6ON5Y45FFbKofEoktRqp9rZiKiqh1WFkIlnQc pcFyDx414XD32OQbmUTs6hSatq55gJpIvAnVgkY5V2eX8gxQoIO8FgDPTtMSsFZKCp3QXWCMKdTA tZEd/mSZS/VJJhiPgdUoV2PXhkeVQHxZdxgRqSKmJI1D0KselWy0SsircBwVgHB4+nrml7jyVABO vT7HZYgT8gbTiSIJvESxAFRQHFeC3jpSRwIIu9SeABwg3DxPtWnpQIs0Zt5LkL0BHpKMggppuwsN WS/N9xLKzGHvdorESffy3PON+67R7yD/shHRRBVxCRxFwBk8BG5OK0ePirsdMHUFENNj0QARWNQx PB1tyNs8rWkk7dS3rbPbR11x2VrXuQ3HZgTCCi3lS2bJLDNhQli2yL0pWVKfQA349Ql2CMBnNADq tYI44Auwk2pKqXS386eW5Ye0GkoLwvQa6agDkwOj/klXhK1TMUdaai9mxTpTaBZ1GjtTFcgwhbd7 JSZUxwXlHBFGnchg8g4qJ3tRyDpvRH3bRhlZoeXSfK6N2CmmnhCQUW/ZZX4b8fJh29IrPubmNWTZ ZKvy55h/nZVUxYPLghG974UYsCFiSYgODP1bApX0pRn5XYl+9ZMCRVznrC0MgG/QWiAZFmcA6rEK ga5SIAWrUJGUYaEiVmlWB8EAGaAd0BklXCFA3BPApGnQXxxkIQ1r+AXSBcJ0NtwhD6WAQ0DosIdC HCISftiHIBIxiUM0oh6QqMQn2pCJeXAiFKtYQinigYpMUFYVfMdFLQDrC8IaFhnCSIiP7E8LHyJj /sG0sBQ0YPEOWlyC/6jgxUFtwYxZgIc/0qDHQEwojVkg01pMo8b7lSGOmpmhPnLCmjcaQSdDKYJQ krIgoXQsKG9USxG20slJGkwDkATAT0Y5gFFSZSdEkNVaAkQEoZQGLFipluviIcp+LEWSSNmlWVYJ SrOoMic6SQIrn4WWTz7lTrREAiyNhZWggNJWhXzOMXtZTaM8hZOznCYUFMkqRkLhas0hY20sIh3Y UI1B47xH7AZQTq/8JjjxrFgtUccOuqHmQmwqAjrHRjzjJCce+EzWRyAGnAfBw55nsU0/GeSrj8hO NcK50Gj4kdACTLSea1PNRd4pHdRFzzjjfJZB/lEjIHgawSKjWehIY9ew6MQTkVHwJn/A+YSr3fMo DPoInrryD6rJKjXDA6hxZOMUnICodQ8dwgFOJLxljSwnziuQGU2EIpItqEFTgVhGTfORpp5oT10J KINSRLUBJTVP/8ATH5UQSNp1pUIuYkcAkqcgIwSVWWskZdT82RWlDiGvAADZhXKqtTjNlUFdrQJN q2RTJ+Amq9O05JYIpBGMGoedxfEToDgmJxd5BYS2IhhTNIDNZxkhqicjp0BnE6bLFhR3VXspalUb gaBiNB6EVeechgcoi6RpCYGULGcDhSs4pXSxe8WsRpGg0kDNyk4kPahxf4eFxvLrsU2IrHT5/nka vu3KNyPi7u2otUzoHc81tTRkOU/ru16tlljNku2ztkpfQ/oqusOhVYUYFNfoobc15r2dcPVEXEFR q0POLIKyljsoeAgLhH8a8K7ysUbzKvi6MVzaFshrXQgVr2FEuKtVEYTaDxNlY/dQ8XqHaqHf+Y60 TdEjyCzEMavhBEz3baM+USvj2RToAEZ5ZWqGoiaLshG/Fc7wc/DHsBKT8idtiweURdkUwR5vQfs4 sYXjhDL8XQG7SdPuFjXb3SLf1jl1TQrV3CYsM1uNNHuLh9tA489q2bme7vRs12pzWGJFCzRTRgLd eIW1ErVIzYVM6J5VWeFAp1M5YXUOH9+m/s4909lhPZHdkvM2Ngn25n5uk5VQBj1qOV/kT2fqMzw7 vTWxzRnMVhDz6Mi8BA/rtJ2yWx1wnlobMcE5d/vU541j92DSoIOntqnY/niN0j/WtUy2WVMB8qrT 29WGJ7tyduu6co8DDS/ZZhlj3Gx1bXRIubvQI0qo+0G8vb6UY+Y2ZTqk02m6sWPdsmbshktnayuS CISvWCbAiUDrNMyx4BFMsisWW/CDw/HfABdhwZUB8TMkvOIaT4YxVLjxjy+QGI9gBchLXhIFSNwO fzA5y5dxCEg4YDAtn3kwTlDHQnCD5jrXxQNk7giR7zzor8g4HlYu9KOT4uWYmAXSm74JvaOvwudO nzojlJ6JbFE964xAgAJG0fM5aD3sgOj5C0cudbGjfQ2h4AsnvFX2tMP9CzFn+yjcHve7l+EBkoLF QeiO979PwQHe8nspQsF0wGch5SDvggLeToouZAvsiJ88Eh6Al8P/wvIn2LwxauH5z4M+9KIfPelL b/rThx4AqF8961vv+tfDPvaynz3tZ2+McJzABJJPhgMeUKTaAz/4wh8+8Ytv/OMjX/YIuDnlm+/8 50M/+tKfPvWr/4ogAAA7 ------=_NextPart_270_F865_02E57DB5.69C23552-- From CareyHobson@aaronbeats.com Wed Dec 20 09:51:12 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx2mm-00082L-Ja for ips-archive@lists.ietf.org; Wed, 20 Dec 2006 09:51:12 -0500 Received: from cc900909-b.eo1.fl.home.nl ([217.121.48.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gx2mj-00076J-Mk for ips-archive@lists.ietf.org; Wed, 20 Dec 2006 09:51:12 -0500 Received: from [182.135.184.28] (port=20044 helo=[182.135.184.28]) by cc900909-b.eo1.fl.home.nl with esmtp id 1qWqDH-000VSC-86 for ips-archive@lists.ietf.org; Wed, 20 Dec 2006 15:51:31 +0100 Message-ID: <000f01c72446$4617bd20$a43079d9@dirk84530d2dea> From: "Carey Hobson" To: ips-archive@lists.ietf.org Subject: Remote Date: Wed, 20 Dec 2006 15:51:04 +0100 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000B_01C7244E.A7DC2520" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 3.6 (+++) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 ------=_NextPart_000_000B_01C7244E.A7DC2520 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000C_01C7244E.A7DC2520" ------=_NextPart_001_000C_01C7244E.A7DC2520 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Firewall, called other features. Diet kazaaalso, known as, klite = ksuggested! You, are networking basicsgt az termsgt kgt router broadband. Phonefree = practice exams dfd buyers! Install you are networking. Lite light = install you are networking. However given nature, systems disabling may = impossible? Impossible accomplish several locations including been. Intended improve original kazaakazaa, also sports very good reputation. Tmx whats hotfree groupware computer. Blogswifi newsdaily telephony voip = home, digital. Firewall, called other features intended. Are networking basicsgt az = termsgt kgt router. Sharing, software ftp download. Impossible accomplish several locations including been? Agreement, policy, patent de policycopy inc part. Basicswifi file servers design itnetwork phonefree practice. Remainsee = gt diet kazaaalso known as klite ksuggested kazaafree. Firewall called other features intended improve! Shut down claiming, an derivative work however given. ------=_NextPart_001_000C_01C7244E.A7DC2520 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
3D""
Firewall, called other features. Diet = kazaaalso,=20 known as, klite ksuggested!
You, are networking basicsgt az termsgt = kgt router=20 broadband. Phonefree practice exams dfd buyers! Install you are = networking. Lite=20 light install you are networking. However given nature, systems = disabling may impossible?
Impossible accomplish several locations = including been.
Intended improve original kazaakazaa, = also sports=20 very good reputation.
Tmx whats hotfree groupware computer. = Blogswifi=20 newsdaily telephony voip home, digital.
Firewall, called other features = intended. Are=20 networking basicsgt az termsgt kgt router. Sharing, software ftp = download.
Impossible accomplish several locations = including been?
Agreement, policy, patent de policycopy = inc part.
Basicswifi file servers design = itnetwork phonefree=20 practice. Remainsee gt diet kazaaalso known as klite ksuggested = kazaafree.
Firewall called other features intended = improve!
Shut down claiming, an derivative work = however=20 given.
------=_NextPart_001_000C_01C7244E.A7DC2520-- ------=_NextPart_000_000B_01C7244E.A7DC2520 Content-Type: image/gif; name="key things.gif" Content-Transfer-Encoding: base64 Content-ID: <000a01c72446$4617bd20$a43079d9@dirk84530d2dea> R0lGODlhSAHcAIfoAAANDIkAAQB5AIuFAAAHgoIDcgx7dcK+srfRvq7K6UsmB2csAHYaAK0jALsm DOwpBgBOBB42CDtDA2tEAI5OCphHB78yAOVOAApeACloAERWAGpUAH5iCpZSALxRANhqAACJABqL AkWMDV96AHl4B66HDrR7AN52AAerACiSAEytAFuhBoOeBpmUCrGlAO6tAALBACu2ADK5AF2+BIDH AJvABsixANvNBg7UABjTADXcBl/RAHfqCpHVDcLcANLlAwQMThIARUYARFgBR3oFOKwHPsIHQesA NQIoSxsRNUgbPWgUSoQhTqcmPsYnNdgaQwBKNCM3TT1BRl81RHM2R6FESsxBPN04QABVTRluRz5d M25fMY5WCqxSTLttSdZRQgCATR+MPESFQVSEN4NzSqR9Rr50N9JzSwGVTSKmOjGXRGqkMnquS5Ol OMarS9OpMgvLQxO0RUXMQmHDQYHGPKTKRrnKOtm3PQDrNhvsRUPlTG3bO4DjOp/RSL7fOODlPQAI iiEAjD4Ael8CeXEIh5MJdssAjO4AiAAniCIRjEUejF8ZcYMtcpQrisUShdkmdQ5DeRRDfEwyiGI6 iHYydJROjLo5jNIxewBSgyNkdTJUhVJfc4Fue5pTh7VjetVsdAByfx6Jekt3eVyJgYl6faZ2c7R6 fNyKggasgRiWfU6ig2KViYGeiaqtfbKUeeiijgOxiSy+iDTFiVK5gIi0fJK0jsLIdOHCewDRfRfd gDzbdW7rdYnqfJrsfLrqeN7WewwAxywAvD8CwlgAvIcBxKYMycEAuOcAtQAeshwuxkIqulMiy3EU vZ4VwsQnzesduQw1yhQ4uE5GyG0zy4E1ypVCwcZCyd9JwgRhvBZuwUVkt1xjsoxhx5xtzb9kx9Na vAB8xS14xUaEzlWMtI6CwquGxsGMttx9vw2mwCehyD2uxmyqtIugyZSgwLKjutOcuwCxtSbDsjS3 xGjMy3bDwqnLt/z1+paYoHJzivwAAAD/DfD/AAAA//8A8QP4///+9CH5BACpx3kALAAAAABIAdwA Bwj/AO0JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDMO/Mexo8ePIEOKHEmypMmTKFOqXMmypcuX MGPKnEmzps2bOHPq3MmzJ02NQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWrWLNq3cq1q1OfYMOK HUu2rNmzaNOqXcu2rdu3cOPKncvSq927ePMapcu3r9+/O/UKHky4sOHDiBMrXsy4sePHkCNLhgq4 suXLmDNr3sy5s+fPoEOLHk26tNnJqFOrXs26tevXsGNbNU27tm2OsnPrznq7t+/Pu4MLH068uOx8 yPPZSz4Q+XLlzZUnny5wuvPn1qFjv76de3ftBLNH/7f+faF379+lk6+eHTp641hTIueYvOP8+fbz /cPvkf9+/fl9xB9+AwLon3/0AfhfgiAVSNKBCjIooIIIVhjhb5c9dB11z3UYnYfhgWfQeSI6x92G Ih50onspkogQhyCyN6J26NWYInyzoURgfQv2uGODF07Y34X3UWhgkEAG2OOQTIY0nZJQQmmhkBjW 9mOREu5oXYJPNilhgNkN2eWEY7a35JlK/ijmk2FSGWWVlWnIInsrrsiQix+G2OF7ehZkInjv4enn nDEWuueNNuK4lXxHcmmkgyVB6CWDajoZZKUInpnpf11OSWWmm8KJmZwy0tlnqafGmGipdqraIo2E nv/Kp4urylrirYoaRl2dqbZHJ3Op/gprn+LNqKevxRr7oXjIAursoLlGK+201FZr7bXYZsuVqNx2 +5a24IYr7rjkIiSAAImdW+5w57bbrlDqZuRuvEnRe9G8A+HLkL728Mtvv++uG5G9QRFcEb0GE5Ww RAij2/BCD0eMrkDxLizuSud6lDFHG8/bkbsfe/yPyB0LUNLGHJs8Msgpt9syyh67vDLLM5cs80gZ w6wySjnv3HPIK3ur08ATU1y0uhIbDXC+RTO99NMJ2Yv00Q43DXXFU1cN8MRTOx0wxFor/VDXSkvs rsBEE5R02VY/XBDWFjvtNdVQi/001mzPrfe+XNP/7RDeeQdeN9pgq033vHD3LTfiRsdt99KIh820 voCTDTnjjn/tNth+X7734OFivHPQKZMu0s+l6/yySSgH3XrpGo8ONOmouy676SG9rvrJsqvuu8+3 Cw1W6zabjvrxyAMfe+7KG2+y7s2XnLryv+N8++6vw7789EDvLvxY0LMscs0hiz8+8cEjHvvNJNMs ve3um299++ynr37NwNd/8/cwDSa11bFxHOFc87/gCHCAF6lM9vjHwAY68IEQjKAEJ0jBClYQgVcp QAHsoUGgdLCD2lKJBkfYkRGasAAlNGFITphCEqLkhChsoQZlOEOOwHAkN/wHDGeYQxq2MIU+BAkP /1HIQhvG0Ig6PGISlzhEC7Kkhkv0CBSRSEUpxrCGWFQiDpWYRSBGMYpQnKIXq/jFL4bxiFlE4xXV KEQiupGKU+wiGN8oRgo6BIQDwSMHN5hHPioEhIDkox712MeDEPKDfgwkQQi5xz/6sZECUeQiN2jC SFLykQlBpCQHKchONlKShDvkIznJkE16spAGYSQkC4lHUK4SlQghpSVnOck9KlKVCzFlLS2Jy1cK TJS7pKUjK2nLEd7xhMKcJQxh6UteGjOYxWwlJhH5yUtKZJmvlGUsMTmtF2oxjlzU4grZeMYnvtGK TAwnOksCTnS2051rbGIS69hGIL6TjPV0YkrEeP/PMoqknOVciTztucYx+nOc64QjG+FpxIEeNJ/p TOhD9fmSgBrUjOIE6EIf+s6AenSjEu2nRT/6Q4yahKT+pOdF7fgQZBaEkS59qUuxmcxJEtOZiRzl JW+aypgmU5sxlWZOebpNnhK1mdCkFkWXytSmOvWpUI2qXzBI1apa9aoLkapWf4PVrgpGR0ja0pqM 9KZJtedSZpKUmcgkpvzwyFFaEutYH1WmToXprUVqU1spdVeyZkmukEKTaEDl1yWpKVRfmpRIJAUm JO2VS1+qlKYca9hGJYmvQCqsYN3a2MtWdrKR1WycGlIrGSXqTwqBUZ5S+6xl3ShEKELtsV6LKmX/ eShQiHoVioIF2znh9lemfW2rDOWY0h4KWqpVEbB4a1tXEbe3wD0tbZ8Lot1Cq7nAde6LgCVbYnFX PdtdLZ8aY9zuBne6t8WVeZzFrGS5FrWrci91k9Us5ZIHvq1V7nF9daju0ndYtYVMecE72/GySr2s 7RWBE/In/F73wfNdsKFm9arsBti75h0Pi8Zr3eqiNzEDLpSDt5tcA6/WuSZOb3AhfGIDd/i32E2v oJS1q9zGVrgfVg2MPZynDiuYuRCmFXqt++JYaVe/B0bycR+83AiPh7gcinJrh5tiEK+nO4Na7nBb nF8Gd7nByZ0wrJosXxc/i79YTo+Hu8xkMGv5/8tXpnKOF7XVOtv5znjOs54v6NU+22XPgN6Mnwe9 rUAb2jIOEVSc0axh5pDZzZDO8o2xI94wq/nNl76ysGqLWykv+rv/fbNqq6wasDYpsIl1E2c5S1gp +VVLaRKtYPGqn1aHNtapBu2mUO0pHxUWsQ1UK5EihFjCxnXWr3bssRcE7FzbFdm4tpSzw4rWBxF7 2J/NdZUSfWYEO1nS0a1wkpEsZeqeOLsZ5nGEKazkcwcZV3IODlj7qupi05tNte5rXRfbKCw1m1P4 Zna+t6RXYNvbrgSnLGiZpNfNPlDY9aZsqwM+8Ws76q8XX7ZifY0lITF2TA5Pkq35rVh/Y9tb3P+e 7bu9TGPfinvLRN6whHfcY0e/HMCcnnO6TTzjJZP6NaaONprsfdkrVfvWGK+sZaHtpvqMPLCM9azA pZ3YXmNK1tsmbX41feFG71w999162P1bpyYLi+xgr7GtRk3bYqGZ652GuZEJTfe62/3ueM870A/N 9777/al6D7xS/k74whv+gYJP/F4Oz/izKP7xQmm85MkC+cpb/vJTmbzmN895zmD+86AP/VA6T/rS mz4uok99Qk7P+peo/vWwj71BWk/7lcge9rXPve5337/b+/73l+e98D8C/OIb//jIr+rwl/+P5Aef +dCPvvT5B4CWVH/6NoHIB7a/fcEA4Pvfjwj/AAQy/oWUnyDnhwj4wZ+Q9F/E/e8Pv6JSsv2O1N8v 1+9I/k9y/f2nxP8oAYAiIYBtQYD6dH8gwX0IqIAf8A/cxxEM2IAQqIATSIEOKIELKIH6N4DgxxH7 V33rB4Lf54H/MIIl6IHrh4IdWIIr6BEAKIL914EpeIIjCIMkaIIxmH8zyIIGSII0aII82INCg4Ae kYEVeIENWH8PeIEJmIT3p4QYqIFEeIIg8YFU6IMxuIFASIMueIVcuIFd+BFA2H8+eIM6qIMs2IVo aIVoOBJZeINC4xDdZxBzaA9zeIcfIBDdV4d1OBB7mId6CIgKyBAhSH7oZw/pV36KeIjuN36J/4iI jHiI6FeIjwiJlmiIlYiJBeGImxiJDbGIA8GJ1NKHfgiIdiiIqBiIp1iKgTiIfIiKpEiIlwiJlQiK muiJt4iJhSiJvGiJikiJvSiKoUh+8heCvwh/nTiLwigtsbiKquiMeOiMq/iK0oiHzagQy5iNhqiM s0iLuOiN7WcQtbiNwfiN3biM4oiN5AiOo2iKf8iK0JiK1GiN1eiOpviMw/iNwliM64iO+/iP3NiL /biNj5iJ7JiL2nh+tiiJBZmOisKApch98BiNERiREkmN+JiRxMh+G6mQ4eeRDcmQH7mRvsiRk7h+ AYmIjsiRiYiS50iSHRmK8teNKqmNNbmQGP90jdp3j3mBjEjhkxoBlIKnk3LIkwhhjEiZlEq5lEzZ lE75lFAZlVI5lSZZamUxhSyBlXOxg2MhhNj3lXbmfJYHlmT5PV5ZljWxkxK5FM1YkQhBlBLRiFUp kzOZj2KJEPQnhRrYE1pphD4Rgl7of1aof2eJlibRl3qJhFC4hAxYgYxpgfaXmI3JhIoZhUs4gVUY mGE4gFpomCRRlAcxj69oj6y4ltFIh6S5lqpIihgpjcNokEIJikIpliiBmJFJmZh5m5jpl4hpgVMI hR/hlySxhYMphjgIhp75Era5m3tJhBHohLq5nEW4l0z4mxHIf8eJnCEBgy2YnFlJnblZnc3/OZ5N GJ3giZu6eZvWyRJkWJzbKYbeCRNG+ITAmZ64WZ+UKZ32KZ7BmZjhCZ9fiIVl6IUEGp/N9xAQ2YoX eY+sOYj1GJEFEYsNqqCw2IexuIs3aZcuKZB3SRBMVZgGamggGqIq0aGPR6KTZ6KKh6LRp5VRNaJo eZ3ouRK9OZk48ZznORMumpk8apwpaIzC55zQ6RI7OqM7UaQ6mqM+ioNbyJkw6negiZoOeoqm6YpT GqE8maBaaqVGSRANWqVgGqYVmoqdiIyziZOJV5vn+Zj36YTkORJCqp5C6qZGup/TiYTpiZ/0eafw KYBCmINNqnsyOp+SSZ1FGqfM2Z+5uaOM/zqk4amnUYid7+mGnLl5FPGOq5maWdql8EihmDqRZBqa m2qlXqqpW+oQcxmbR/l7n9qqeTihCWGhRgmrpymqpVqaDKqptvqJA7mqvhp4anqnhCqnigqnb8qf fLqnIoGoD8iskPqfLkqG2ume7il5CHqqz4itpcqpX1qr2RqqqImlpLqtYrqtGnmTIMmP6xiTKiob cPkQs9mu0/KuqCqv2ZKg9joRLNp4+Zp3+/qvDfSky+cQFVABR1GwCIuwRZGwCbuwBiuLm1iXdHmM c7miJ1GwYIGxGVsBPaGxwzmDBsiGukewD0sQDCsQDFuyKZsQBVsQJ2sPL3uyCsuyJYuyDf8Lsze7 sjg7szFbswepqq8peijhsRzhsRiLsEXLsUbLsSJBtEv7D0jbEUg7tUwbEkT7EUf7tEkLtVWrsU5b tXBImN05oNwpsKR3tU+btl0LtlgLtmrbtlvLtSNxtR6RtXW7tnIbt3RbhdQKoAP6t51Hsi6rsgbb sjaLswNhuAehuDvbsIyLuJD7uCbrsyvLuIrbsin7sJJ7ECzJoRhql7L3uJdbuIQLuaZrEJbrs6cb uZqruolbs6N7urG7uZvrkDb5q6Abe6JburPbuq57uK8bvLsLvLUru75rvDZLusGLvLYbkPC3kPF6 d0PLsEkbtVqbsnPLttSbt1LLtF7Ltndt27YJy73Va73j273ey7aAqYJtyIMuOLYAG76fsbfsGaJP UbyEgb/w2q9I8bKI4b/8SxHxW3gBbHcDfMAInMAKvMAM3MDcUsAQHMGw4cCAJsGDRsEYnMFzYcEc 3MGQocEgHMIiPMIk3Bse3FUBAQA7 ------=_NextPart_000_000B_01C7244E.A7DC2520-- From ips-bounces@ietf.org Wed Dec 20 11:16:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx46f-0002T7-2d; Wed, 20 Dec 2006 11:15:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx46d-0002Si-TJ for ips@ietf.org; Wed, 20 Dec 2006 11:15:47 -0500 Received: from an-out-0708.google.com ([209.85.132.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gx46c-0004g1-Kh for ips@ietf.org; Wed, 20 Dec 2006 11:15:47 -0500 Received: by an-out-0708.google.com with SMTP id d30so694610and for ; Wed, 20 Dec 2006 08:15:46 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:subject:from:reply-to:to:content-type:date:message-id:mime-version:x-mailer:content-transfer-encoding; b=foPrGOQX9V6cttIwWcj01aQtarx9kIHMstuzdtCROV4sBnzJGwsSTBafhnNCZl9djdKHgu6f/NKY99VRzSAGP1ogNiVwkpIwpRuIiVNuE0A/Mvusm5vtA0U001zbi19iFfdUOAzroLQTTK9XgVUlWq2LGamKBSNnt5xS/i1N/Nc= Received: by 10.100.135.16 with SMTP id i16mr5953869and.1166631346094; Wed, 20 Dec 2006 08:15:46 -0800 (PST) Received: from ?192.168.11.226? ( [72.74.197.97]) by mx.google.com with ESMTP id 33sm17026884wra.2006.12.20.08.15.45; Wed, 20 Dec 2006 08:15:45 -0800 (PST) From: Ming Zhang To: IPS Content-Type: text/plain Date: Wed, 20 Dec 2006 11:15:44 -0500 Message-Id: <1166631344.2935.111.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 (2.6.3-1.fc5.5) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: [Ips] MPIO with Persistent Reserve Out/In X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: blackmagic02881@gmail.com List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org Hi All I can not find this from original rfc or the new guide draft about how MPIO work with Persistent Reserve Out/In or old Reserve/Release. In iSCSI, a session is a I_T nexus. With MPIO, then between one initiator and one target will have multiple I_T nexus. If initiator setup a reservation via 1st session, can it send out commands like write via 2nd session? Intuitively, I think it should be able to. But from SPC, reservation will base on I_T nexus so 2 sessions are 2 different I_T nexus. Could anyone help to clarify this? Thanks. Ming _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Wed Dec 20 11:37:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx4RD-0004a7-GY; Wed, 20 Dec 2006 11:37:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx4RC-0004Z6-Ve for ips@ietf.org; Wed, 20 Dec 2006 11:37:02 -0500 Received: from mexforward.lss.emc.com ([128.222.32.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gx4RA-0007x2-M6 for ips@ietf.org; Wed, 20 Dec 2006 11:37:02 -0500 Received: from mailhub.lss.emc.com (nagas.lss.emc.com [10.254.144.11]) by mexforward.lss.emc.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id kBKGavcX029423; Wed, 20 Dec 2006 11:36:58 -0500 (EST) Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id kBKGagGO000024; Wed, 20 Dec 2006 11:36:57 -0500 (EST) From: Black_David@emc.com Received: from CORPUSMX20A.corp.emc.com ([128.221.62.13]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Dec 2006 11:36:54 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ips] MPIO with Persistent Reserve Out/In Date: Wed, 20 Dec 2006 11:36:54 -0500 Message-ID: In-Reply-To: <1166631344.2935.111.camel@localhost.localdomain> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ips] MPIO with Persistent Reserve Out/In Thread-Index: AcckUvMHUd1Lz/PHTqiCjujq9AKM8wAAeMVQ To: , X-OriginalArrivalTime: 20 Dec 2006 16:36:54.0522 (UTC) FILETIME=[0EF6BDA0:01C72455] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2006.12.20.81433 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -2, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CTE 0, __CTYPE_CHARSET_QUOTED 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.2 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org > I can not find this from original rfc or the new guide draft about how > MPIO work with Persistent Reserve Out/In or old Reserve/Release. >=20 > In iSCSI, a session is a I_T nexus. With MPIO, then between one > initiator and one target will have multiple I_T nexus. If initiator > setup a reservation via 1st session, can it send out commands like write > via 2nd session? Intuitively, I think it should be able to. No - if you want that behavior, use multiple TCP connections in a single iSCSI session. > But from SPC, reservation will base on I_T nexus so 2 sessions are 2 > different I_T nexus. That is how iSCSI behaves - no change to SPC. 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 Wed Dec 20 12:11:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx4yZ-0005ti-Kn; Wed, 20 Dec 2006 12:11:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx4yY-0005tG-0y for ips@ietf.org; Wed, 20 Dec 2006 12:11:30 -0500 Received: from mail0.lsil.com ([147.145.40.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gx4yV-00055y-KW for ips@ietf.org; Wed, 20 Dec 2006 12:11:30 -0500 Received: from milmhbs0.lsil.com (mhbs.lsil.com [147.145.1.30]) by mail0.lsil.com (8.12.8/8.12.8) with ESMTP id kBKH9sG0008137; Wed, 20 Dec 2006 09:09:54 -0800 (PST) Received: from namail.ad.lsil.com (namail.co.lsil.com [172.21.36.18]) by milmhbs0.lsil.com (8.12.11/8.12.11) with ESMTP id kBKHAqw3027642; Wed, 20 Dec 2006 09:11:10 -0800 Received: from NAMAIL3.ad.lsil.com ([172.21.36.21]) by namail.ad.lsil.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Dec 2006 10:10:47 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ips] MPIO with Persistent Reserve Out/In Date: Wed, 20 Dec 2006 10:10:46 -0700 Message-ID: <0F08E10B769EAF4EA2C43A573B8CC87F77AF64@NAMAIL3.ad.lsil.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ips] MPIO with Persistent Reserve Out/In Thread-Index: AcckUvMHUd1Lz/PHTqiCjujq9AKM8wAAeMVQAAA22sA= From: "Qi, Yanling" To: , , X-OriginalArrivalTime: 20 Dec 2006 17:10:47.0927 (UTC) FILETIME=[CAF7B870:01C72459] X-Scanned-By: MIMEDefang 2.39 X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org > -----Original Message----- > From: Black_David@emc.com [mailto:Black_David@emc.com] > Sent: Wednesday, December 20, 2006 10:37 AM > To: blackmagic02881@gmail.com; ips@ietf.org > Subject: RE: [Ips] MPIO with Persistent Reserve Out/In >=20 > > I can not find this from original rfc or the new guide draft about how > > MPIO work with Persistent Reserve Out/In or old Reserve/Release. > > > > In iSCSI, a session is a I_T nexus. With MPIO, then between one > > initiator and one target will have multiple I_T nexus. If initiator > > setup a reservation via 1st session, can it send out commands like > write > > via 2nd session? Intuitively, I think it should be able to. >=20 > No - if you want that behavior, use multiple TCP connections in a single > iSCSI session. >=20 > > But from SPC, reservation will base on I_T nexus so 2 sessions are 2 > > different I_T nexus. >=20 > That is how iSCSI behaves - no change to SPC. >=20 > Thanks, > --David [Qi, Yanling] Here is my 2 cents. The reservation management should be much higher than the transport layer. I see different implementations cross different MPIO implementations. 1. Multipath service layer provides a scsi pass-through interface for an individual I_T_L nexus. The application which manages the reservations will use the interface to do registration/reserve I_T_L nexus by I_T_L nexus. I saw one server vendor does it in this way. 2. Multipath service layer takes care of the PR-IN/OUT translation which is received from a virtual device to multiple I_T_L nexuses. MS MPIO for LH takes this approach. 3. Special device nodes for each I_T_L nexuses. Applications on Linux can use /dev/sgX to perform reservation management. The device mapper may just leave the reservation management responsibility to the applications. Thanks, Yanling _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Wed Dec 20 15:36:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx8B6-00045e-Mn; Wed, 20 Dec 2006 15:36:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx8B5-00045Z-1m for ips@ietf.org; Wed, 20 Dec 2006 15:36:39 -0500 Received: from wr-out-0506.google.com ([64.233.184.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gx8B2-0007sC-Qe for ips@ietf.org; Wed, 20 Dec 2006 15:36:39 -0500 Received: by wr-out-0506.google.com with SMTP id i7so1567091wra for ; Wed, 20 Dec 2006 12:36:32 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:subject:from:reply-to:to:cc:in-reply-to:references:content-type:date:message-id:mime-version:x-mailer:content-transfer-encoding; b=ZPDMs0Gnz0YRk5WWlcbWxuGPD1JDBS26QDtx91ALUP+bmGlblCKuxaGv2G4d5yx+DEjGl3vrwQBGxbkWimUf7n497ZJ9DvllsW0w7EF3Ef1vqIq7IY3HmV6gfmSP1IhHuKQaEMrdLVsI7+OnxogkghRC8F+LeE5uNI9IzJNhal8= Received: by 10.90.93.6 with SMTP id q6mr7744847agb.1166646992133; Wed, 20 Dec 2006 12:36:32 -0800 (PST) Received: from ?192.168.11.226? ( [72.74.197.97]) by mx.google.com with ESMTP id 9sm5874842wrl.2006.12.20.12.36.31; Wed, 20 Dec 2006 12:36:31 -0800 (PST) Subject: RE: [Ips] MPIO with Persistent Reserve Out/In From: Ming Zhang To: Black_David@emc.com In-Reply-To: References: Content-Type: text/plain Date: Wed, 20 Dec 2006 15:36:27 -0500 Message-Id: <1166646987.2935.188.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 (2.6.3-1.fc5.5) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: blackmagic02881@gmail.com List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org On Wed, 2006-12-20 at 11:36 -0500, Black_David@emc.com wrote: > > I can not find this from original rfc or the new guide draft about how > > MPIO work with Persistent Reserve Out/In or old Reserve/Release. > > > > In iSCSI, a session is a I_T nexus. With MPIO, then between one > > initiator and one target will have multiple I_T nexus. If initiator > > setup a reservation via 1st session, can it send out commands like > write > > via 2nd session? Intuitively, I think it should be able to. > > No - if you want that behavior, use multiple TCP connections in a single > iSCSI session. ok. > > > But from SPC, reservation will base on I_T nexus so 2 sessions are 2 > > different I_T nexus. > > That is how iSCSI behaves - no change to SPC. yes, i meant with 2 I_T nexus, then base on SPC we can not do it in MPIO. But from application point of view, why can not do it with MPIO? > > 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 Wed Dec 20 17:22:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx9ps-0000iM-JB; Wed, 20 Dec 2006 17:22:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx9pr-0000iC-3m for ips@ietf.org; Wed, 20 Dec 2006 17:22:51 -0500 Received: from mexforward.lss.emc.com ([128.222.32.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gx9po-00020N-3y for ips@ietf.org; Wed, 20 Dec 2006 17:22:50 -0500 Received: from mailhub.lss.emc.com (uraeus.lss.emc.com [10.254.144.14]) by mexforward.lss.emc.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id kBKMMh9P008926; Wed, 20 Dec 2006 17:22:43 -0500 (EST) Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id kBKMMM0M008896; Wed, 20 Dec 2006 17:22:42 -0500 (EST) From: Black_David@emc.com Received: from CORPUSMX20A.corp.emc.com ([128.221.62.13]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Dec 2006 17:22:41 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ips] Implementer's Guide - Task Management Issue Date: Wed, 20 Dec 2006 17:22:40 -0500 Message-ID: In-Reply-To: <20061214113155.35067.qmail@web51903.mail.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ips] Implementer's Guide - Task Management Issue Thread-Index: Accfc9masVDMhdEbT7iU0qSQKEPAjQFC/uqg To: , X-OriginalArrivalTime: 20 Dec 2006 22:22:41.0677 (UTC) FILETIME=[5D3B5BD0:01C72485] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2006.12.20.135433 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -2, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CTE 0, __CTYPE_CHARSET_QUOTED 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.2 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Cc: X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org Mallikarjun, > IMHO, RFC 3720 had a good reason to require TTT completions on all initiators > (issuing and third-party). We took a more conservative approach "data transfers > for terminated tasks cannot be active" at that time. We also had concerns about > ordering issues in multi-connection sessions. > =20 > By the IG time, we took a more relaxed approach "let data transfers for terminated > tasks be in progress". So the immediate question was: So what happens to those > Data-Outs with stale TTTs? Roughly, there are two possible answers to that: a) > let the target silently discard them, b) let the target maintain the buffer > resources for "a bit longer" so the outstanding transfers can complete. Just to make this more complex, I think there are two forms of b): b1) The data yet to be transferred by the outstanding transfers will be processed by the task (command) that requested the transfer. b2) The data yet to be transferred by the outstanding transfers will be discarded and *NOT* processed by the task (command) that requested the transfer. The difference between a) and b2) is that in a) the target maintains no buffers or other resources for the stale transfers, aside from some indication of what the TTTs are that need to be discarded, whereas in b2) the target maintains the buffers for discard after the transfers complete. > The current IG approach is not to recommend either (a) or (b), but leave enough > room to implement either (a) or (b) per your implementation considerations. > iSCSI/iSER implementations have a particular problem with (a) because an invalid > STag is fatal for the connection. So I don't think we want to recommend (a) > outright. Right, the language in the IG alerts the iSCSI/iSER implementer to the possibility of b2) - complete the transfers, but bit-bucket the results, in which case the TMF response can be returned early. =20 > If a target wants to do (b), it needs a signal to deterministically free up > resources - that's true for both issuing and third-party initiators (what is > "a bit longer"?). And that is the proposed Nop-Out. > So I do not see a qualitative difference between issuing and third-party > initiators wrt the requirement on key negotiation to enable fast abort...... If fast abort means that the target can safely assume that a transfer won't complete, we might be in agreement. What I'm looking for is return of the TMF response while transfers from initiators other than the one that issued the TMF are outstanding. Let's try this line of reasoning - the target issues the Nop-Out, now when can it free the resources? Answer: - The Nop-In response comes back, OR - The connection times out and is torn down. Now, what if the Nop-Out is not issued - what does the target wait for to free the resources? Answer: - The transfers complete, OR - The connection times out and is torn down. Those look similar enough at the target (the worst case is the same - the resources are tied up until an uncooperative initiator times out) that I don't see the harm in allowing the early TMF return without the new key. The clear distinction is that the first two bullets are different; if the new key is not negotiated, the target has to wait for the transfers to complete; the new key and the Nop-Out are necessary to walk away earlier when the initiator involved is able to continue the transfers. > so I am so far not convinced that changing the current text is the right > thing to do (I'll need to sync up with Julian to understand what I'm > missing, and that is proving challenging due to both of us traveling). What I'm looking for is for a 3720-only target to be able to do a) or b2) and return the TMF response once: - It has completed everything (including outstanding transfers) with the initiator that issued the task management operation. - It has arranged for outstanding transfers from all other initiators to be discarded. The current language in 3720 requires the initiator to delay the TMF response until all the discards to complete, and that's a real problem in practice. =20 > I believe we're covered on the ordering issues with the new IG text - > with the response fence notion. So I wouldn't have any concerns on > that front with what David is proposing. This sounds different, in that the response fence requires a new key - I think I'm asking for an early TMF response without the new key or a response fence. Buffer recovery make take quite a while longer. 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 Wed Dec 20 17:33:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxA0T-0006Rr-Bn; Wed, 20 Dec 2006 17:33:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxA0S-0006Rj-5O for ips@ietf.org; Wed, 20 Dec 2006 17:33:48 -0500 Received: from mexforward.lss.emc.com ([128.222.32.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxA0Q-00047L-U8 for ips@ietf.org; Wed, 20 Dec 2006 17:33:48 -0500 Received: from mailhub.lss.emc.com (uraeus.lss.emc.com [10.254.144.14]) by mexforward.lss.emc.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id kBKMXkI8017702; Wed, 20 Dec 2006 17:33:46 -0500 (EST) Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id kBKMXjdb013009; Wed, 20 Dec 2006 17:33:45 -0500 (EST) From: Black_David@emc.com Received: from CORPUSMX20A.corp.emc.com ([128.221.62.13]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Dec 2006 17:33:44 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ips] Implementer's Guide - Task Management Issue Date: Wed, 20 Dec 2006 17:33:43 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ips] Implementer's Guide - Task Management Issue Thread-Index: Accfc9masVDMhdEbT7iU0qSQKEPAjQFC/uqgAAGi9gA= To: , , X-OriginalArrivalTime: 20 Dec 2006 22:33:44.0672 (UTC) FILETIME=[E8685E00:01C72486] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2006.12.20.141433 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -2, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CTE 0, __CTYPE_CHARSET_QUOTED 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.2 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org > Let's try this line of reasoning - the target issues the Nop-Out, now when > can it free the resources? Answer: > - The Nop-In response comes back, OR > - The connection times out and is torn down. > Now, what if the Nop-Out is not issued - what does the target wait for to > free the resources? Answer: > - The transfers complete, OR > - The connection times out and is torn down.=20 > Those look similar enough at the target (the worst case is the same - the > resources are tied up until an uncooperative initiator times out) that > I don't see the harm in allowing the early TMF return without the new > key. The clear distinction is that the first two bullets are different; > if the new key is not negotiated, the target has to wait for the transfers > to complete; the new key and the Nop-Out are necessary to walk away earlier > when the initiator involved is able to continue the transfers. That got slightly twisted - what it should have talked about was the target issuing the new Async Message and the Nop-Out response coming back. 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 Wed Dec 20 17:39:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxA64-00020v-IV; Wed, 20 Dec 2006 17:39:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxA63-00020n-99 for ips@ietf.org; Wed, 20 Dec 2006 17:39:35 -0500 Received: from palrel10.hp.com ([156.153.255.245]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxA61-00057R-VU for ips@ietf.org; Wed, 20 Dec 2006 17:39:35 -0500 Received: from tsx1.cup.hp.com (tsx1.cup.hp.com [15.13.185.235]) by palrel10.hp.com (Postfix) with ESMTP id 43CEE34A32; Wed, 20 Dec 2006 14:39:33 -0800 (PST) Received: from localhost (santoshr@localhost) by tsx1.cup.hp.com (8.9.3 (PHNE_29774)/8.8.6) with ESMTP id OAA08727; Wed, 20 Dec 2006 14:39:33 -0800 (PST) Date: Wed, 20 Dec 2006 14:39:32 -0800 (PST) From: Santosh Rao To: Ming Zhang Subject: RE: [Ips] MPIO with Persistent Reserve Out/In In-Reply-To: <1166646987.2935.188.camel@localhost.localdomain> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: ips@ietf.org, Black_David@emc.com X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org On Wed, 20 Dec 2006, Ming Zhang wrote: > On Wed, 2006-12-20 at 11:36 -0500, Black_David@emc.com wrote: > > > I can not find this from original rfc or the new guide draft about how > > > MPIO work with Persistent Reserve Out/In or old Reserve/Release. > > > > > > In iSCSI, a session is a I_T nexus. With MPIO, then between one > > > initiator and one target will have multiple I_T nexus. If initiator > > > setup a reservation via 1st session, can it send out commands like > > write > > > via 2nd session? Intuitively, I think it should be able to. > > > > No - if you want that behavior, use multiple TCP connections in a single > > iSCSI session. Or, use persistent reservations instead of SCSI-2 reservations. > > ok. > > > > > > But from SPC, reservation will base on I_T nexus so 2 sessions are 2 > > > different I_T nexus. > > > > That is how iSCSI behaves - no change to SPC. > > yes, i meant with 2 I_T nexus, then base on SPC we can not do it in > MPIO. > > But from application point of view, why can not do it with MPIO? > > > > > > 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 > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Wed Dec 20 17:41:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxA7j-0002oX-E9; Wed, 20 Dec 2006 17:41:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxA7i-0002mS-3T for ips@ietf.org; Wed, 20 Dec 2006 17:41:18 -0500 Received: from wx-out-0506.google.com ([66.249.82.234]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxA7g-0005Q3-Qw for ips@ietf.org; Wed, 20 Dec 2006 17:41:18 -0500 Received: by wx-out-0506.google.com with SMTP id h27so2208205wxd for ; Wed, 20 Dec 2006 14:41:16 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:subject:from:reply-to:to:cc:in-reply-to:references:content-type:date:message-id:mime-version:x-mailer:content-transfer-encoding; b=Wdni5+gDcGqBlEtHd3jMfCUcPnq4uU+nOOPesOsaf3s9pdDwA4mkVSsy8CWnqE8DK2ZYYXR8Z9RD/KKbhTQCZDEDLyRINEff0rSkPLiPG2BdLJWNDwrDGdqlnTSygdc82U1xQzKhdWKvtvLpJQQX3CRHYhaoiRDB0JIjhyfA2n0= Received: by 10.70.75.14 with SMTP id x14mr12965214wxa.1166654476345; Wed, 20 Dec 2006 14:41:16 -0800 (PST) Received: from ?192.168.11.226? ( [72.74.197.97]) by mx.google.com with ESMTP id h35sm15838044wxd.2006.12.20.14.41.14; Wed, 20 Dec 2006 14:41:16 -0800 (PST) Subject: RE: [Ips] MPIO with Persistent Reserve Out/In From: Ming Zhang To: Santosh Rao In-Reply-To: References: Content-Type: text/plain Date: Wed, 20 Dec 2006 17:41:12 -0500 Message-Id: <1166654473.2935.228.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 (2.6.3-1.fc5.5) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: ips@ietf.org, Black_David@emc.com X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: blackmagic02881@gmail.com List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org On Wed, 2006-12-20 at 14:39 -0800, Santosh Rao wrote: > > > On Wed, 20 Dec 2006, Ming Zhang wrote: > > > On Wed, 2006-12-20 at 11:36 -0500, Black_David@emc.com wrote: > > > > I can not find this from original rfc or the new guide draft about how > > > > MPIO work with Persistent Reserve Out/In or old Reserve/Release. > > > > > > > > In iSCSI, a session is a I_T nexus. With MPIO, then between one > > > > initiator and one target will have multiple I_T nexus. If initiator > > > > setup a reservation via 1st session, can it send out commands like > > > write > > > > via 2nd session? Intuitively, I think it should be able to. > > > > > > No - if you want that behavior, use multiple TCP connections in a single > > > iSCSI session. > > Or, use persistent reservations instead of SCSI-2 reservations. PR use a reservation key i thought it is still I_T nexus based? Then still tight to session? > > > > > ok. > > > > > > > > > But from SPC, reservation will base on I_T nexus so 2 sessions are 2 > > > > different I_T nexus. > > > > > > That is how iSCSI behaves - no change to SPC. > > > > yes, i meant with 2 I_T nexus, then base on SPC we can not do it in > > MPIO. > > > > But from application point of view, why can not do it with MPIO? > > > > > > > > > > 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 > > > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From PedroRosales@adipa.e.telefonica.net Wed Dec 20 21:53:01 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxE3J-00062C-8J for ips-archive@lists.ietf.org; Wed, 20 Dec 2006 21:53:01 -0500 Received: from p38248-ipbffx02marunouchi.tokyo.ocn.ne.jp ([211.122.217.248]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxE3H-0008Kk-9S for ips-archive@lists.ietf.org; Wed, 20 Dec 2006 21:53:01 -0500 Received: from [118.128.52.138] by p38248-ipbffx02marunouchi.tokyo.ocn.ne.jp with HTTP; Thu, 21 Dec 2006 11:52:38 +0900 Message-ID: <000901c724ab$05035320$f8d97ad3@chou> From: "Pedro Rosales" To: ips-archive@lists.ietf.org Subject: DownloadPP Programs SoftwarePP Date: Thu, 21 Dec 2006 11:52:11 +0900 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0005_01C724F6.74C74680" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 3.1 (+++) X-Scan-Signature: 6907f330301e69261fa73bed91449a20 ------=_NextPart_000_0005_01C724F6.74C74680 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0006_01C724F6.74C74680" ------=_NextPart_001_0006_01C724F6.74C74680 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable Free client download, you are file sharinggt networkgt, router. Fe, downloadpp, programs softwarepp perfect. Part new york times = company. Automatic resuming downloads between sessions multiple source. = Ftp, adapter cards tools compare, prices find, job yellow. Longer being maintained clients may! Info news events work at about sitemap reprints helpour. Reprints helpour story guideuser agreement ethics policy? Best gifts your tmx whats hotfree kazaa, faq groupware. Faq groupware = computer aim active directory, booksall topics? Cards tools compare, prices. Protocols http bittorrent settings upload = speed limit kbps maximum. Downloadpp programs softwarepp perfect. Computers simplyip addresses and. Due lack, suppport fe downloadpp programs softwarepp perfect gifttop. Setup networking, basicswifi, servers design itnetwork, phonefree. Programs softwarepp perfect gifttop, toys cameras. Of same automatic resuming downloads between, sessions multiple? = Features private messaging uploading of same! Amp, rssemail to frienddigg this readingpp peer bookstips. Upload speed = limit kbps, maximum. To frienddigg this readingpp peer. Sessions multiple source horde tied, location, note, is no. ------=_NextPart_001_0006_01C724F6.74C74680 Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable
3D""
Free client download, you are file = sharinggt=20 networkgt, router.
Fe, downloadpp, programs softwarepp = perfect. Part=20 new york times company. Automatic resuming downloads between sessions = multiple=20 source. Ftp, adapter cards tools compare, prices find, job = yellow.
Longer being maintained clients = may!
Info news events work at about sitemap = reprints helpour.
Reprints helpour story guideuser = agreement ethics policy?
Best gifts your tmx whats hotfree = kazaa, faq=20 groupware. Faq groupware computer aim active directory, booksall = topics?
Cards tools compare, prices. Protocols = http=20 bittorrent settings upload speed limit kbps maximum.
Downloadpp programs softwarepp = perfect.
Computers simplyip addresses = and.
Due lack, suppport fe downloadpp = programs=20 softwarepp perfect gifttop.
Setup networking, basicswifi, servers = design=20 itnetwork, phonefree.
Programs softwarepp perfect gifttop, = toys cameras.
Of same automatic resuming downloads = between,=20 sessions multiple? Features private messaging uploading of = same!
Amp, rssemail to frienddigg this = readingpp peer=20 bookstips. Upload speed limit kbps, maximum.
To frienddigg this readingpp = peer.
Sessions multiple source horde tied, = location,=20 note, is no.
------=_NextPart_001_0006_01C724F6.74C74680-- ------=_NextPart_000_0005_01C724F6.74C74680 Content-Type: image/gif; name="Under Best.gif" Content-Transfer-Encoding: base64 Content-ID: <000401c724ab$04df9e80$f8d97ad3@chou> R0lGODlhVAHEAYfoAAAAC4ELBQCLA4iMCAQAeYwAcwCOeLfJwL/ezaLF40crAGgbAIMiDJEWAMsq AO0sAAI7ABVDBzo4C1U5AX9KAKNECLtLANw+AANUDiFjCERaAGxeAI1pDa1kAMJRB+pRBwB2ACZx Dj+MAWV2CYt6AJFyCM6IAdt7AQCrACiYADSVCmGoCImrAJSYAMWaANWiBgDHDSO/CkvOAlTDA33F AJS8ALq3DdLEAADuABnYCTLUAFzrAH7bAK3hALLoCdXVAAgEPRQATjIHSlMARXEMNZkFTbcAStoA NAAbRxoYMjIjNGAmS3YoPq0cP8ESOdElRwRCNytKSUdNSFE8SYZIO6Y/QsNOM+s9MwxgPSJsR0Jd QlJuPHhbAK1gQstiPeVnOQx8PC6JPTR5SmiIM4yGSKCEMb6CQ9KNOwChQR+mNU6iO1WTRHKsOKCV NcqSQ+GdRgDJOSC3PUa9OmSzM3jBTJjHSsPMNN+1RQDoNyPcS0HTMmTTPI3jS5bjTL3iStneNw0A hicAhkQCglIGf4wAfZMEe7gBftcAhQckiCcfiUQtiW0tfIQneawpg8EUdOobgAxCciA0ekBHi1tL dHxCgZY1dsU0etYxdgBeeSBuikRji2pejI1jg5VoisNojdFZdARydR12dUCMiWaHfIl0iZJ/eryA h9h3ggKYeR6pgzWZcVycinacjZ2bi7aRc92chwXOghjOi0LAiWu/gYjKfqXMiLm2ie60jQDkcRze f0zWe2DgdYflgJ3ifLTUjNfhgwwDwRgAxjsDzFMAs4gAtJMAvsMAzt0AxAAivygeuE0qw1EktIkn wZ8dvMgbt+4mxQAysR43tzc8tGQ0zIc/tZ8/yrFMyek5vQBTvBNuzUNgzlpnxIZrwKdZzs5dv95q sQ2JyC2HtkJ3s26HyIKKxaF3tMaFv+R9xgSYuiugx0adv1quxYShtaOetbOjxt+ttQHMwRm2uEO2 wl3FwovNwa29wv7/7JiWmXKMivwABQDxAfP/AAAA+/8J/w76///1+CH5BADor4EALAAAAABUAcQB Bwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDM+tMexo8ePIEOKHEmypMmTKFOqXMmypcuX MGPKnJlSo82bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOJNKNKnUq1qtWrWLNmfcq1q9evYMOK HUu2rNmzaNOqXcu2rdu3YbXKnUu3rt27ePPq3cu3r9+/W+EKHkyYqMl8iPPZS9wR8WLFjRUnnsxx suPHliFjvryZc2fNHjNHtvy5pGfPnyWTrpwZMmrAsGPDvMyY9ePQqkGeBo2aM23Nv3HrBu4atO3j Ind/fO3beG/jsqNLb4hY4GTr+f5VH1h9O0HvB8GD/9ee3fv28eGzY19fULx6g9fZc38/v/53+uQL 6795PjH7/vLZh5B77ZX3HoALmaceegSmp2CB8B2I33jo7WdhQScF51hwt6XGGmXCRbacaiB+WNuI JbbWIXIhcjgaZaKNKKN0NE7HEILxkfdggvQ1WF93+EEIoY8C5hfhfxMGCWR6Ql7oJIaHFWfiiyKa xtuVMro43JYrMoflcCA+x6WXNZZpJnULStjjmkcWSaGE8iEYYJxptmlkk/m9aaee9z3p50PXKcjm fJZhl+OcOu6I5KFuGlhoZgOyCWlrd1bK559Pmqnpppx26umnoIYqamCYlmpqYaOmquqqsp3q6quw xv8q66w/vSSAAFbdOqqurPaqKUO3BhvsP7fuVGxGwh77k7IXJVsQswo5K5C0xApLkLW0LsUstDZx S5Gy3uYUbkTgCjDtsMCae261AxVb7rrZ+pQSrxwli6s99OqabL3BdmQvv/3iey+9IhHM674AHyys vwsH/G/CAy9MksH3qqRvxRczLLCvq1Ic8cb8Cozxx/lWrLHCJVEM8sYEr6wwrv1eTPLIIp+k8koZ h1yyyAFz/OnNLNMMdMhEe/SyyQWbnHPQH+0MMso7R4100k1PnfLHOgtNs89/PbStuuy+Cy2271ZL NrrRgh22vexey3bbx7oLttzOjnuu2vA2hLbYc5v/W3a8R33drt99t22Q3IMbHjfaCQnO7dh4w7u4 4oQfHrnbCNmN+eZrJ/434EUJvu7ilSfeudlwf+5t2Xw/W3jqoxfeeuaX520456afrrvmoEs0r9Jb /9uyxDwf7XTRRiMMMcMOE49y0M5L3HLyCD88ffHGM19yz1x3r9XQ3k9sdfjkbwp++SBdj/76NKrP /vvv9y7//D3Bb//9+Oev//78968VP/ywBwCtMsAB+g8kDwGgAgmiwAbyg4ENTIgDIbjAiDjwgRQE YAY1KJALLsSDHbwgBkE4kAmWkIP/QGEKI4gQDXLQhCGEYAxPSMMXYhBwKDGgAAP4ER12RIc+9IgB /4HIwyCWxIdE/CEPd6hEjiRRJEhcohOlyMQpNtGKU1ziE6sIkgIW8YtXxGIVozhGKvKvISpcYUHS mEYJjvCGNpShG1t4wxmiMI40PEgb11hHNdqxjzbE4x7pqEY8+nGGfrzjAxVJP4WwEZCQdIghDXlI PfYxj3lkZCUHOUhMIpKSiawgKCEyyTqqkIWOvOSsThLEVlLRiFB0oBIbuJILhhGLQ9SiFGGZRQV2 8ZVgFCMuA+hFYdZSlsKMIi+FaMb9oTGScvRkKjMJR1VK8o18DGEFEVnJaUZTm6eEZiCxucJOGkST 4cwmQ8z5KlYCs4fvdOcVt8iSXMJzmLdc5j2Zuf9Pepaxl8lsZiznuct4HnAq/uRiGHn5xC3qk4xi dGgwFbpPY7pyobrEaEaNSRKJclSftzyoSZBZUWb6Mpa07CVER2JLk66UiS1lKUlDutKZErGgKXVn TgH6S3mK9KdADSpVGknUolpEqEhNKkyMytSmOvWpUI2qVKfKEKVa9aonaQgBCICQrXrVIF7dKkHE KhCyJsSsZQ3rVw+i1rWilaxt5Spb30rXtQ6krXeNa1fVmle+9tWsev2HXeEaWLACVq6BPWxe/0rX scp1LWhdbFodK1nBIvaxZ8UsZbWq2cZalrOYHexjFVvZySqEtJGtLGHnOtrOatawrTVtQUj72dr/ ytazkH1tZFe7WbGmFravte1Cdhvay4L2sryV7G83m1nlBne5vw2rbKfLWuMK17m8Xa5wtUuW1BKX uoTl7l/n6pDvOve4aU2uacXL3thel7qlHe9125vd5yLXutrFbVdOslWQ9Ncj//1vRwIsYJIQ2L8E QEmB7RHXBDO4rSLpb1gfzJEFCxjCH1kwgivs4AerlcMRxrCEE2zhDoeYwgT+MIgnXGAMg3jAJv6U hkv8YhhzWMMbpnCGYzwSGttYxyUZ8YhrTGQAxxjHRvaqkUOCZByn+Mg83vGNHdxkJXs4yjVuMZY3 NWMoF/nASIbxhKXMXy//OMxL1vGB05zjH/eY/8oddjKW5TxlMr+5zkDe8ZPvDCrOkne6tFXvbIs7 6PK6trfBNex63Wtb/b630Ive63kVnV5IN7fSjwY0oVW7aa+UWcVX5jGogVxlNheZz25Ws4vtnOpR h1rUWyaykMc85TiL2NZmRrWV42rqEtM6z2jmC1WH3UisGvvYHiG2spfN7GY7+9nQjra0n43saltb JAEIgEeyve1sc7sj3g63tkMi7m97u9vjLne6xf0RdnMk3O/+tj3kPW94Y7vc8R53vfNtb3yjW970 pne73V1vghcc4Or+t74PHvCF56/h4Na3wPdNkokXHN3xJrfENx7xjufb4xQP+cA1znGRgxzhJ/9f 90ggbvKUj/zlIUd5xsnXkGwTxOb/wPlAdC4Qnh/E5z33dtBxDvScB2DnRzd6QnQe7qA7veZJL0jT lU51qUed6FE3CNaXnvWbd/3pXLe62KvO9K/r5yQsF7jaHQ4Si/f73C2PucrvHXFzz90kboe73TXu cYvXne3dpnvbAR/4wve95HG3n7rvPnOQ39vd3Ia33SF/d7/Lfd97R7u/I6/tyb+98ZY/eEn8zfDM r9zha585y8MHda+D/fVVR0jRbd70rWt96k/HfdmHnnSsFz32SOc97Hmfdd93/fdhB/7wxx581xtd 6M6fFc9t3/zqy97stqe+83dffe5PffpmVz7/1b+P/d5fvfjHD3/yZ69+2Ps8++2PFfi7/3XkLx/+ 9z8//fc/dP7f/ufnZ34A6H/vF3/zJ35kl37/B3bch4CncoDEN4AKoW7DZ3zQB4HlJnwJiH64Z3Xi xoAWqH1l14EOiHS6l4EmCHTsB32vp33T9oIwGIMyWGzXVoNBNYM46BY2uIM82IM++INAGIRCOIRE WIRGeIRImIQqkYNM2IRO+IJKGIWi8oRUKBZSeIVYmIVauIVcWBdV+IWe1oVi2DVgWIZNMYZoKGxm uIZJkYZuiBdsGIdyOId0WIdU9YZ4SBd2uIc6kYd+SCp8GIiCOIiEWIiGeIiImIiKuIg49IeO//iI kEgjjDiJTgUAE2GJlNgVALCJm3gWnNiJEIGJmKgQozgQpfgQnwiKB3GKFsGKraiKUXUSm9gRs6gp APARt5gSuZiLK8GLKuGLJAGMsCGMP1iLIJGKtPiJ9sCJHJGKvIiMywiNtWiMxkiLIqGMy+gRt4iM zJiN09iM2CiN3aiNxxiNu8iM4RiN3viN32iOyUiN1RgSu+iO4BiPWGWP6giO9eiOs9iN9tiP07iN 55iM5ViQzZiN1oiQ1JiPB+mL20iODomLx/iMB4mQDfmMFFmND9mQEJmQ16iPHGmD+AiPIBmQDPmP AkmQ5kiME+mPHZmQ82iNwLiRIVmTFlmP6P9Ijgr5khVpk94okTKJEjHpk9U2khhZkgNJkisJkCqJ jb94kzS5k1B5kz8ZlDIJjR6ZlTHpjFNplTAZkOGIjzoZkSx5UAwBi6Y4iqC4lqJoiarYiW/plmrZ lmjZEG5JEHdpigIhinj5D6eYl3vpl33pinpZEKXIl4JpmH2pl3+pmIQZmAmBmIH5mE8Vl345l3vZ lpl5mWnJmZcpl525mXjJio15mInpmZIpmKXZmZhpmov5momZmoB5mqrpmIw5mIXpirJJm5DZiCaB lcA5kOrIlTjJlCDJkMepjU65nP34jjxZkTnJjzjZktHZkwDZjsXZk9AJj9yZlfsYkSupnf3/QxR1 KRHlKRaUuRPpeRHruYfniYrtqYlFEZ+XyIjv6RD3yRWfaBT0aYaR+J8AGqACOqAECpRZUZYHhaDk g5VaYZROOZFSMZPjKI/vWJYIypwoGZYaCZ64KJZ0QZH2o5QNSowiihXcqJMQ2pUGqp1kiaLi2ZVb ORIKKhccuj5GSZDcqKFg6Y8PepICyaPZuZTKWY41SqJU+aJUaaEGiaRjCZ0yepEY2Zw7WqHOOZ0s Cj83qo/juKVHCaTIqZLDuaFfKqL/qKJHOpQu+qJKuqJCWpDzeKHHGZUnmaZVWadS6Z0LSqJd6pB8 iqNH+aXFKZx+2qFgKqNFaqDCaKSBOpPK/6mgUTqkgtqkXnmleCqn4Mmo7JOlYTqkFYqOf6qphbqp jdqj14idSRqcH8mmgMqkakqkrTqVmBqoQcqj6Uino3KWutmah7mrBmGZnmmYpPmXoDma5jmZsKmY vbmKvYqsCEGZpImsqQmZptmYhQmbq3mWhCGLe/qdfQqmxpmPoJqcouqtf+qmMGquwbikiSqpLeqd MQqU7aqVPNmcNommR1o+wamMYjqqgtqdnPqvSEmr+8qvVPqqxKmq/HqOC2ml4emiGQqj1cmw0cml C8uqoVKZPtGf2aKxmcibOsGxsQKyHQsUInsqJRsXBZqyIjGyLNuyLhuaznayjKitYfkSDv/KoBHq jDPqEh6KsHqqrzirssn5rSzRsz2bswe6s+I4o3IqtCnaoRi6oz8qlvG4tFJLj6UKtVe7lAq7tWWq qE96r04bqvs4rtcJsE/ro1jLj0RLqFnLpYOKlGhrp3gKr6QKiXaZiqLJmZaJlvcJi30rrKL5noQ7 rHsLl5j5q6Som6TYrIZYtCmppds6twCrs2MqnB5atTn6r9dZszSLsHUrtmMruXE7ruLqtqeruXKb teSKnCQZrmFbo6ArugUqpq87uWRbubi7upnbrZ7Kqb+7uqfrpPJavBZbu+LYlJ7bqKzbqeJqkqv6 vJubsEFathnKndiZqBM6ulZ1tLrIvSz/sWz5iYov2xDXFrTgq4flu77s277u+74WIrPwO76v6Izq qbP3i5+9Wp77+ZmcuIi/ubMy4b00QcAwQcDSGLZEmb5za7XY27ta27USvLZp26YOPMEWvK6yu6JN m7K4CqysyZa/WrjEupn/m5Zyabj7G5kpDLOIG5qA+6y7esLW6r/yC4YBjLrfusMW2q2mC66RiroQ OrA8PLxpK7sbLMB++MElzLe6CrMrjML76beaqbggPJpTzKsmbL9WzMK7Caw0XK2ImMOcG7lm28MN LKHCe8S7e7vyKMBvaquVysBo68akS8G6W7q8i8bKa8ZAbMbQa8RxDJPoeryPiKv9q7cj/0yXYXzF UlzFMAzJUfzIKmzDjDzDe/vIUlytYdy/ilgXBmwmoVwSSkzHySYU9EsWqYyt8KsQI7q9n4K+pqy+ rVzLtnzLuJwpsxygudzLvlxUu8zLvzzMxJwtwXzMyCyFxbzMzNzMzvzM0BzN9JPM1FzNQyjN2JzN aGHNf6jN3vzN4BzO4jw/3FzO5nzO6Nwr4xxt6dzO7vzO8BzP8jzP9FzP4LumvTjKMVHKfQHL3RvK /OwX60q7qUrQSKq0hjzABUyhBs16+vvQnrisHsvK5EsR0RoWzspUs0mXmUnFa/mZkxmXH32bNJzI Je3JHY24c1mXU6yaHO2/ttnINgzSKf+9iiLNlyPtyTIN0zzNmP+707Sy0ad50Y6pliNMm0L9lrw5 rccam0btmq9puEY90VIt0UoN1b2Z1Ex9m8mK1F0trVktP0kt0ZHp1VttrFyN1mIs1NCKm2Ic1lj9 1bX51rHp1l1NrWqd17PJrHVt1XLtJ997qRVLsPFqp1F52Keqr3SKplNbpj65pRSaxFd6sFXKlYxK nLB8qQz9qOxDvnF90Wc913pt1nb91XHd13mtrKmdm8p62rsZn3u91BP91q7JuB57w4UBmHDJ2sy6 22kt2qLt26l91iydrGwd1V4N1svq2sad3JxM2qWt23xN1Ig51X8SwI+qsHUspc/Ztc7/idgNi6H3 OqHebZCWOrD1+saC7aAFi6niTZ11u6cBfavrXN/2fd+BaM/6vd/83d/seRPtidsVIeCheImrjMMt Ya/7LItP+ZsM3tAR3IsJraru3aOxGqr6XNB3Md95oeAH/OBCGRUenq5ynKoBPdCTaqZnqsYK3eFw iMiXTNM83cI1fdcyzsghjeM7fZcyrbcnXdw2PdI5rtJBjuO0PdvALcNcncio2eM/veMnrNNNvsl/ LS+kzK4gCpEZKane2qoLO5QanOVfOakXLq+aPacO+6op3t2uypFkKeYDjcQczLvnehcU3dfMHdrR WtvLvZhE/dvPCt2mzeSArtw2ztvH/xrjYW3aaD3Wa+3XR17DQ13oSF4/pJzAEBux4H3hW6nYhFy2 EinZsCrLZF7ncv7paaqoWR7nO1nYlE284snp1nmVtRobqs7mrh7rTZrrZ9rmBvucDs7rjD3nvW6r GFzQW17qJH7qxbvqEC7Q7DqviH3mzW6R9Eq8Yp7e8MrmqQ6rTUmp1W7euu7e4p7eh7rt7krszk7t tk7eGvmdmZ7twAnvHHq2vj7e796wES6x107e8M2k7u6SXB7fViqhVDu16l3e1v6Vg03LXkHg+B2y EV8WNcLh/X3xGJ/xGr/x95jh/bwpFm+zNLcQXNwUjwnxyJ0TKF/Wqm3bsG0TAV7lYP/h4LF8FSEP 4h9fyB/a4L7ys28a5nHqklPqqgIb3uAKxO09sUJvtFir8O+t7x7Z6RkZ8Pau7w9ZtVFf8E2/kECb 77Bx5819niKc5EdN11WN2i5dwkKO6FpN1y482rYJ988d3Ibu50/t51086aN91bz9xZX+FfYb2r1d 6Fit5H1f2np/23Ad3SwP1nk+3X2+2tQd9nh/8rX52oiP5039FDSf5vic7PUatJs+2YjK8Nnr7aF7 rpitobIa6gyP6gPf2IMc2VVp2WP55a1vI40L+Za/+JRe1nwu6ItO9pOu541f14Fu4+kp3XhP1ZQf +a0918kv25pP8Vc+559f6ufO7cP/Hqugf/rCrq7mjqPKjv2ffuvK3sFZT/pe+a71XvP/nv3baapQ n/7tXfrzb+0bWet36rzzDxAA7A0EUNCewIMGCRZEONDhwYcIGTpsqDCiRYgJLQps+JDiR4oTNW7c GHJkRI8pVa5k2dLlS5gxZc6kWdMmy44Eb+7k2dPnT6BBhQ4lWvRnTp1GlS5l2hToP6hRpU6lWtXq VaxZtW7l2tUrVQBfxY4lW9bsWbRp1a5l29btW7hx5c6lW9fuXbx59e7l29fvX8CBBQ8m3Jff2MNp E6tdXNjxY8h3Eze2Svmf5a+T2WKO3NmzVqdE+Q0cXbP0ztKnf6oO3dr166JaF8++/xyVNm2olvnt tr1bs+3Lvg/7zh28eHDiyHkr771c+PDlzGsnl157qvDc1KFn/9y978vT4e2JJz3eIfnz6VWPXl9+ vPjdD9nLN6+efvv68d3fh0+/fnr/3NNvQNgKNPDA+8zrb77y5mPtv/0U9C+1BCts0EIJAaQQQAwZ FNAj1vBD70EESzSxpq2Gmw44FW9bkarkGlMROOtktI5FqWYs7jnosKsxx+yIs9HGG4+j8TjcivRu ycBavNFJF3WsSkoqkQSSsiqHhHFKI1/c8UoglcQyzCQ5Y/JMtmJCb78QOczPPjjf+zDOC0nzML72 RIzwTg8znHNDNwFd80RCC13Nzf//2tzzPP3ea9S3RBv1U0A87WRQOEYlhVTDSkXc9E1LU/t0RENL NTUlNN8yM1VWW20LPB5jlXVWWmu19VZcc9V1V15jPfXXUl09y0dhizU2LWCTVXZZZg889lloo7Wr WWqrtfbam6TVdltuzcL2W3DDvbZbcss191x00zVXXHbbdZdQdeOV19V367X3Xnzz1XdfQ+f191+A AxZ4YIILNvhghBNWeGGGG3b4YYix4ndiiiu2+GKMM9Z4Y477jfhjkDsWeWSSSzb5ZJRTVpkpkFt2 +WWYY5Z55m1XtvlmnHPW+TWae/b5Z6A/23looos2+miPglZ6aaabngtpqKN2CBz/qqn2yOqpwbla a5awHgjrqr322h6rwx77IbOzDnvrqrN22+yy01YJbrHXnltustvO2+6v7R4bbLzhbunvuvfWOyXB 817pbMO5phvBwt2WfPLFHbdccsIV7/vuzTX3PHLAO0eba885H53yyUEnXfPCM3d9dcYpPzxu1EWn 3fTUtY49tqyovirsqHyXSvjfwYHKd+KPNz555I1Xvirho3f+H+mnap766ZN/fnurmJ+e++C/rx57 6L8Pf/jlzQcfK+CVr957qoi/Pv6qz6d/Wpd2Nxx1/dW+/PTX1Y51/xvg1vZXu8hV7nQLZGABSyfA ACJudYObnd5uJ7rcPbBvCWwg/+QmiDkCYrBrpDvbBRWXOAn6LXATjBsLBYdCBfLvg5n7nNxiR0MU wnCBoaMdDUenQgl27oY6FIpWtGe/8dmvd9kz3/ye58T7PTF96LNe+uBXRfItkYpb5GIWjyjF8nVR iWLc3viAd0UyHtGM6ssiXV6yu8SV8IO4k2PpbgdHEuqOgHW8IONCR8EO+hF2IQTgHH3YQRFu0IKW M6Egg8i2ReLORK0b5AP7J7s8gtB2hsxkAlUnxBlmcoQGTGQNNXlKB/5xc4fEYB9dKUkR4rCTczyQ DSv5Qrw90n8u5KAggZi7Cr4Nl4hEIN8gWTfAGTOXylyhMTFZQz06s5hr86Etc/8pNWxmU5vb5GY3 vQkup4VTnOMkp8S+eU50KvCSMzFhOpFmRPE5z2xjbF777ldP+cWzjeSDYvjq575/Ys+edBNoQKvI RH/mU4lJLCdZYPLHTwoTgnpMZSUrqsGIOlCjGUwhKlWZUXc+BZ5gpCL8FBrG9jF0jfxUn/acqNIp YnF9ACXp+aS30obOJaVNjGlNvxhFmCZ0Ky7taVDViFD6vY+nXvwnQ3MKl5PaVJ9w4wpV94lGLZZ0 nuDDZ/2ses8pElWKL2XjU9kS1ZqydJ9ZVSs9yxpFqV51qi3tKVC9utSC0nSmZt2KTDh4wlsScpSr tGgpYXlHURL2kXhUpCUZ+dj/kE6ysBH9awwvSkzLfnSPgq0sNDfpv8YaNrJLkePhQmtHWv7QtNJc p2oTC1i+PY6VnlWkCxvY2tHChK+75W1vF5Zb4AZXuMMlbnFN5Vvk/sW4yz1Vcp27F+ZGt1DPpW51 rXtd7GZXu9vlbne9+13QSFe8CAJvefs6XvTCxrzrZW97uZJe+MZXvu5yb33tW9/55le/++Vvf/37 35Pdt70AJrBMBMzeAidYwQtG0YEd/ODrMljCDoEweCc84QpnWMMb5nCHPeyvC4dYxCMmcX4/fGIU 06zEK2YxelP8YhjHWMYzpvFZWvzfGudYxzvm8dNu/GMgB1nIQyZykY18ZCQ/e6THS2Zyk51sziSL 98lTprJ3ojzeKjvtylLOMtO2/GUwi6zLYyZzmQ8cZjSnuWJmBpqaictmOMdZzhF2c53t3K45z+zO e+Zzn9GcZ0AH+it+JnShDX1oRCda0SsR9MsWzc1Gu+zR24x0yyZ9aUz3pNKb5nSnPf1pUAssIAA7 ------=_NextPart_000_0005_01C724F6.74C74680-- From ips-bounces@ietf.org Thu Dec 21 07:00:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxMai-0006NS-4J; Thu, 21 Dec 2006 07:00:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxMah-0006NI-E6 for ips@ietf.org; Thu, 21 Dec 2006 07:00:03 -0500 Received: from mtagate2.de.ibm.com ([195.212.29.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxMae-0000wL-Gs for ips@ietf.org; Thu, 21 Dec 2006 07:00:03 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate2.de.ibm.com (8.13.8/8.13.8) with ESMTP id kBLBxxnG104036 for ; Thu, 21 Dec 2006 11:59:59 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id kBLBxwGW3072138 for ; Thu, 21 Dec 2006 12:59:58 +0100 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id kBLBxwwp007548 for ; Thu, 21 Dec 2006 12:59:58 +0100 Received: from d12mc102.megacenter.de.ibm.com (d12mc102.megacenter.de.ibm.com [9.149.167.114]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id kBLBxw7Y007545; Thu, 21 Dec 2006 12:59:58 +0100 In-Reply-To: To: Black_David@emc.com MIME-Version: 1.0 Subject: RE: [Ips] Implementer's Guide - Task Management Issue X-Mailer: Lotus Notes Release 7.0.2 September 26, 2006 From: Julian Satran Message-ID: Date: Thu, 21 Dec 2006 13:59:56 +0200 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 7.0.2HF71 | November 3, 2006) at 21/12/2006 13:59:57, Serialize complete at 21/12/2006 13:59:57 X-Spam-Score: 0.5 (/) X-Scan-Signature: 913ee11e7c554f7d4da75d500826397e 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="===============0969594599==" Errors-To: ips-bounces@ietf.org This is a multipart message in MIME format. --===============0969594599== Content-Type: multipart/alternative; boundary="=_alternative 0041E5C4C225724B_=" This is a multipart message in MIME format. --=_alternative 0041E5C4C225724B_= Content-Type: text/plain; charset="US-ASCII" Black_David@emc.com wrote on 21/12/2006 00:22:40: > Mallikarjun, > > > IMHO, RFC 3720 had a good reason to require TTT completions on all > initiators > > (issuing and third-party). We took a more conservative approach "data > transfers > > for terminated tasks cannot be active" at that time. We also had > concerns about > > ordering issues in multi-connection sessions. > > > > By the IG time, we took a more relaxed approach "let data transfers > for terminated > > tasks be in progress". So the immediate question was: So what > happens to those > > Data-Outs with stale TTTs? Roughly, there are two possible answers to > that: a) > > let the target silently discard them, b) let the target maintain the > buffer > > resources for "a bit longer" so the outstanding transfers can > complete. > > Just to make this more complex, I think there are two forms of b): > b1) The data yet to be transferred by the outstanding transfers will be > processed by the task (command) that requested the transfer. > b2) The data yet to be transferred by the outstanding transfers will be > discarded and *NOT* processed by the task (command) that > requested > the transfer. > The difference between a) and b2) is that in a) the target maintains no > buffers or other resources for the stale transfers, aside from some > indication > of what the TTTs are that need to be discarded, whereas in b2) the > target > maintains the buffers for discard after the transfers complete. > > > The current IG approach is not to recommend either (a) or (b), but > leave enough > > room to implement either (a) or (b) per your implementation > considerations. > > iSCSI/iSER implementations have a particular problem with (a) because > an invalid > > STag is fatal for the connection. So I don't think we want to > recommend (a) > > outright. > > Right, the language in the IG alerts the iSCSI/iSER implementer to the > possibility > of b2) - complete the transfers, but bit-bucket the results, in which > case the > TMF response can be returned early. > You might make the point that the language in iSER requires the Steering Tag to be valid (i.e. the packets having it must be accepted) but does not say what/if buffer has to stand behind it. An implemementer has enough room to make its its choices. Obviously an implementer that assumes that an STAG must have a buffer behind it will keep the buffers. Others may have a list marking "disconnected" STAGs and free te buffers. > > If a target wants to do (b), it needs a signal to deterministically > free up > > resources - that's true for both issuing and third-party initiators > (what is > > "a bit longer"?). And that is the proposed Nop-Out. > > So I do not see a qualitative difference between issuing and > third-party > > initiators wrt the requirement on key negotiation to enable fast > abort...... > > If fast abort means that the target can safely assume that a transfer > won't > complete, we might be in agreement. What I'm looking for is return of > the TMF > response while transfers from initiators other than the one that issued > the > TMF are outstanding. > > Let's try this line of reasoning - the target issues the Nop-Out, now > when > can it free the resources? Answer: > - The Nop-In response comes back, OR > - The connection times out and is torn down. > Now, what if the Nop-Out is not issued - what does the target wait for > to > free the resources? Answer: > - The transfers complete, OR > - The connection times out and is torn down. > Those look similar enough at the target (the worst case is the same - > the > resources are tied up until an uncooperative initiator times out) that > I don't see the harm in allowing the early TMF return without the new > key. The clear distinction is that the first two bullets are different; > if the new key is not negotiated, the target has to wait for the > transfers > to complete; the new key and the Nop-Out are necessary to walk away > earlier > when the initiator involved is able to continue the transfers. > > > so I am so far not convinced that changing the current text is the > right > > thing to do (I'll need to sync up with Julian to understand what I'm > > missing, and that is proving challenging due to both of us traveling). > > What I'm looking for is for a 3720-only target to be able to do a) or > b2) > and return the TMF response once: > - It has completed everything (including outstanding transfers) > with the initiator that issued the task management > operation. > - It has arranged for outstanding transfers from all other > initiators to be discarded. > The current language in 3720 requires the initiator to delay the TMF > response until all the discards to complete, and that's a real problem > in practice. > > > I believe we're covered on the ordering issues with the new IG text - > > with the response fence notion. So I wouldn't have any concerns on > > that front with what David is proposing. > > This sounds different, in that the response fence requires a new key > - I think I'm asking for an early TMF response without the new key or a > response fence. Buffer recovery make take quite a while longer. > > 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 --=_alternative 0041E5C4C225724B_= Content-Type: text/html; charset="US-ASCII"

Black_David@emc.com wrote on 21/12/2006 00:22:40:

> Mallikarjun,
>
> > IMHO, RFC 3720 had a good reason to require TTT completions on all
> initiators
> > (issuing and third-party).  We took a more conservative approach "data
> transfers
> > for terminated tasks cannot be active" at that time.  We also had
> concerns about
> > ordering issues in multi-connection sessions.
> >    
> > By the IG time, we took a more relaxed approach "let data transfers
> for terminated
> > tasks be in progress".  So the immediate question was:  So what
> happens to those
> > Data-Outs with stale TTTs?  Roughly, there are two possible answers to
> that: a)
> > let the target silently discard them, b) let the target maintain the
> buffer
> > resources for "a bit longer" so the outstanding transfers can
> complete.
>
> Just to make this more complex, I think there are two forms of b):
> b1) The data yet to be transferred by the outstanding transfers will be
>    processed by the task (command) that requested the transfer.
> b2) The data yet to be transferred by the outstanding transfers will be
>    discarded and *NOT* processed by the task (command) that
> requested
>    the transfer.
> The difference between a) and b2) is that in a) the target maintains no
> buffers or other resources for the stale transfers, aside from some
> indication
> of what the TTTs are that need to be discarded, whereas in b2) the
> target
> maintains the buffers for discard after the transfers complete.
>
> > The current IG approach is not to recommend either (a) or (b), but
> leave enough
> > room to implement either (a) or (b) per your implementation
> considerations.
> > iSCSI/iSER implementations have a particular problem with (a) because
> an invalid
> > STag is fatal for the connection.   So I don't think we want to
> recommend (a)
> > outright.
>
> Right, the language in the IG alerts the iSCSI/iSER implementer to the
> possibility
> of b2) - complete the transfers, but bit-bucket the results, in which
> case the
> TMF response can be returned early.
>  

You might make the point that the language in iSER requires the Steering Tag to be valid (i.e. the packets having it must be accepted) but does not say what/if buffer has to stand behind it. An implemementer has enough room to make its its choices. Obviously an implementer that assumes that an STAG must have a buffer behind it will keep the buffers. Others may have a list marking "disconnected" STAGs and free te buffers.

   
> > If a target wants to do (b), it needs a signal to deterministically
> free up
> > resources - that's true for both issuing and third-party initiators
> (what is
> > "a bit longer"?).  And that is the proposed Nop-Out.
> > So I do not see a qualitative difference between issuing and
> third-party
> > initiators wrt the requirement on key negotiation to enable fast
> abort......
>
> If fast abort means that the target can safely assume that a transfer
> won't
> complete, we might be in agreement.  What I'm looking for is return of
> the TMF
> response while transfers from initiators other than the one that issued
> the
> TMF are outstanding.
>
> Let's try this line of reasoning - the target issues the Nop-Out, now
> when
> can it free the resources?  Answer:
>    - The Nop-In response comes back, OR
>    - The connection times out and is torn down.
> Now, what if the Nop-Out is not issued - what does the target wait for
> to
> free the resources?  Answer:
>    - The transfers complete, OR
>    - The connection times out and is torn down.
> Those look similar enough at the target (the worst case is the same -
> the
> resources are tied up until an uncooperative initiator times out) that
> I don't see the harm in allowing the early TMF return without the new
> key.  The clear distinction is that the first two bullets are different;
> if the new key is not negotiated, the target has to wait for the
> transfers
> to complete; the new key and the Nop-Out are necessary to walk away
> earlier
> when the initiator involved is able to continue the transfers.
>
> > so I am so far not convinced that changing the current text is the
> right
> > thing to do (I'll need to sync up with Julian to understand what I'm
> > missing, and that is proving challenging due to both of us traveling).
>
> What I'm looking for is for a 3720-only target to be able to do a) or
> b2)
> and return the TMF response once:
>    - It has completed everything (including outstanding transfers)
>       with the initiator that issued the task management
> operation.
>    - It has arranged for outstanding transfers from all other
>       initiators to be discarded.
> The current language in 3720 requires the initiator to delay the TMF
> response until all the discards to complete, and that's a real problem
> in practice.
>    
> > I believe we're covered on the ordering issues with the new IG text -
> > with the response fence notion.  So I wouldn't have any concerns on
> > that front with what David is proposing.
>
> This sounds different, in that the response fence requires a new key
> - I think I'm asking for an early TMF response without the new key or a
> response fence.  Buffer recovery make take quite a while longer.
>
> 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
 --=_alternative 0041E5C4C225724B_=-- --===============0969594599== 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 --===============0969594599==-- From ips-bounces@ietf.org Thu Dec 21 12:20:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxRao-0005Pq-Jr; Thu, 21 Dec 2006 12:20:30 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxRan-0005Pk-Cj for ips@ietf.org; Thu, 21 Dec 2006 12:20:29 -0500 Received: from imf23aec.mail.bellsouth.net ([205.152.59.71]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GxRaj-0007zw-LR for ips@ietf.org; Thu, 21 Dec 2006 12:20:29 -0500 Received: from ibm66aec.bellsouth.net ([74.245.52.54]) by imf23aec.mail.bellsouth.net with ESMTP id <20061221172014.RYHA13824.imf23aec.mail.bellsouth.net@ibm66aec.bellsouth.net> for ; Thu, 21 Dec 2006 12:20:14 -0500 Received: from IVVTDKV0981 ([74.245.52.54]) by ibm66aec.bellsouth.net with SMTP id <20061221172014.XRTY29829.ibm66aec.bellsouth.net@IVVTDKV0981> for ; Thu, 21 Dec 2006 12:20:14 -0500 Message-ID: <000d01c72524$471cf940$01faa8c0@ivivity.com> From: "Eddy Quicksall" To: Subject: Fw: [Ips] ips WG Last Call: iSCSI Implementer's Guide Date: Thu, 21 Dec 2006 12:20:14 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5b943e80df8c8cad631fd60298783617 X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org Sorry, I forgot to send this original request to the list. What I'm thinking is to say this in the iSCSI Implementer's Guide, if it is not too late. One of the problems I'm faced with is that our customers will run 3rd party tests on a final product. If 3rd party test says "failed" then the customer takes that to its word. I have found that many people think that if the RFC says the initiator MUST then they think that means the target MUST check to see that the initiator obeyed the rule (and visa versa) ... some of the 3rd party tests are in that category. Eddy ----- Original Message ----- From: "Mallikarjun C." To: "Eddy Quicksall" Cc: ; "Julian Satran" Sent: Thursday, December 14, 2006 6:55 PM Subject: Re: [Ips] ips WG Last Call: iSCSI Implementer's Guide I think I understand your question. Generally, the IETF philosophy is to "be liberal in what you accept, be conservative in what you send" (my paraphrasing of it, anyway) - so if your target wants to be more forgiving, I think that should be alright. The UNH tests may be testing all MUST requirements - so in your immediate data example, the initiator must be held to this rule since it initiates the immediate data send. On the target side, I see no harm in turning off those checks in your production code when you think you can gracefully deal even with a badly-behaving initiator. On such occasions though, you should be sure to not flag SCSI protocol errors for those same iSCSI protocol errors that you had earlier forgiven. Hope that helps. Mallikarjun ----- Original Message ---- From: Eddy Quicksall To: Mallikarjun C. Sent: Wednesday, December 13, 2006 4:17:37 AM Subject: Re: [Ips] ips WG Last Call: iSCSI Implementer's Guide I know it is really late to ask this but I was wondering if something could be done to relax some of the requirements for the target or initiator to check for correctness of the protocol? For example, it could be said that if the protocol error will not affect the operation of the device then it is not necessary to check for the error. I ask this because all of these checks during Full Feature Phase can cause unnecessary performance degradation due to a check on every command PDU even when the initiator or target have been previously qualified. This is off the top of my head but one such check that comes to mind is the check to be sure the ITT of data matches the ITT of the original command... we have hardware acceleration and different types of memory with different speeds. To cross check against the command requires saving additional information and accessing the slow memory (the fast memory is at a premium and can't store enough information). Another is the requirement for the target to check for immediate data received when immediate data was negotiated to no (if the target can deal with it and the initiator can't but the initiator negotiated it to no then the initiator should not send it anyway and there should be no need to make the checks on every command). Maybe some of these that I call "required checks" are actually the result of a test program (such as the UNH test program) putting on the "requirement". If so then a note in the guide may help to clear up that it is not an error for the initiator or target to double check the peer. I typed this kind of fast and I'm not a good linguist so if you don't understand then please let me know. Eddy ----- Original Message ----- From: "Mallikarjun C." To: Sent: Monday, December 11, 2006 12:34 PM Subject: Re: [Ips] ips WG Last Call: iSCSI Implementer's Guide Lars, Thanks for the comments and sorry for the delay in getting back. As far as volunteers for reviewing, we could request the contributors at the end of the document to review. David may have already reviewed, based on his comments. Julian Satran had some offline feedback for me on TMF topics. As the editor of the document, I was sure that each of the topics were discussed in detail (or at least clearly noted) on the list before I included them in the doc. Hope that gives you some reassurance. >whether it is merely the original text that can be >misunderstood or if there is a technical error in the original text. > (It already does in some cases.) Yes, I'd appreciate if you could point out where you think additional clarifications could help. > OK, so this document not only updates 3720, but also 3721, 3722 and > 3723? That needs to be stated in the document header and abstract. > (Also, 3721 needs to be normatively cited in this case.) We could. My intent was to make it clear that this document prevails whenever a subtle interpretation in future of one of these RFCs differs from what's in this document. Now that we are nearing the end of the work on this document, we could delete some although I personally am tempted to leave it this way....from what I can think of today though, this doc updates 3720 and 3721, but does not update 3722 and 3723. 3721 is not a standards-track RFC and I wasn't sure if it needs to be normatively cited as such. But I could if that's the right thing to do. >Suggest to find a better title, because implementer's guides don't >typically update the base specification in a normative way. (Maybe > "iSCSI Corrections and Implementer's Guide" or something like that?) FIne by me. How about "iSCSI Corrections, Clarifications, Additions and Implementation Guidance", or is it too long? If it is, we could try "iSCSI Changes Based on Implementers' Experience" or something like it. > The specification of the fence mechanisms should use RFC2119 terms, > especially in Section 3.3.2. It actually does, with a MUST preceding the bulleted list.... As far as 3.3.1, I intentionally left the model description very generic with the hope that it can be incorporated into a future T10 spec verbatim. > Nit: s/mult/multi-/ Done. > I'm not sure if "should receive" describes something that should be > started in RFC2119 language or not. If that is the intent, a better > phrasing should be found. (Also elsewhere in this document where the > same phrasing is used.) I left the "should"s intentionally in, because they really are the prerogatives of the initiator's run-time behavior, i.e. initiator may at his discretion choose to discard a message for some other reason (e.g. bad digest) beyond the 2119 protocol requirements. >Should the sentence starting with "SHOULD NOT" start a new item in > this list? No, I don't think so. This bullet is all about waiting for missing CmdSN's. It happens to have a different prescription for third-party affected sessions. >Remove text after "considerations" to not confuse IANA. May want > to add a note to the RFC Editor to remove this section upon >publication. Done. > Nit: Cited also as [RFC 3720], which confuses idnits. Remove the space > in the other citations. Done. >iSER Not cited. It does now. > ID does not include the required 2119 boilerplate. Also, 2119 should > be cited normatively. Fixed now. Mallikarjun ----- Original Message ---- From: Lars Eggert To: ips@ietf.org Sent: Friday, December 1, 2006 4:57:59 PM Subject: Re: [Ips] ips WG Last Call: iSCSI Implementer's Guide Summary: Minor revision needed to address editorial issues. Note: I'm no iSCSI expert, so I cannot fully review the technical recommendations made in this document. I'd like to see at least one other review from someone who has the necessary background before this document moves forward - volunteers? Contains non-ASCII characters, boilerplate issues and other idnits. Please fix. Header should indicate that this document updates 3720 and potentially other IDs (abstract already partially does - good!) It would be good if this document would state for each item it discusses, whether this is a clarification to the original RFCs or a correction, i.e., whether it is merely the original text that can be misunderstood or if there is a technical error in the original text. (It already does in some cases.) INTRODUCTION, paragraph 1: > iSCSI Implementer's Guide Suggest to find a better title, because implementer's guides don't typically update the base specification in a normative way. (Maybe "iSCSI Corrections and Implementer's Guide" or something like that?) Section 2, paragraph 2: > iSCSI implementers are required to reference [RFC3722] and > [RFC3723] in addition to [RFC3720] for mandatory requirements. > In addition, [RFC3721] also contains useful information for > iSCSI implementers. The text in this document, however, updates > and supersedes the text in all the noted RFCs whenever there is > such a question. OK, so this document not only updates 3720, but also 3721, 3722 and 3723? That needs to be stated in the document header and abstract. (Also, 3721 needs to be normatively cited in this case.) Section 3.3, paragraph 0: > 3.3 SCSI Protocol Interface Model for Response Ordering The specification of the fence mechanisms should use RFC2119 terms, especially in Section 3.3.2. Section 3.3.3, paragraph 4: > 2. The TMF Response carrying the mult-task TMF Response on the > issuing session. Nit: s/mult/multi-/ Section 4.1.2, paragraph 4: > b. Should receive any responses that the target may provide > for some tasks among the affected tasks (may process them > as usual because they are guaranteed to have > chronologically originated prior to the TMF response). I'm not sure if "should receive" describes something that should be started in RFC2119 language or not. If that is the intent, a better phrasing should be found. (Also elsewhere in this document where the same phrasing is used.) Section 4.1.2, paragraph 8: > b. MUST wait (concurrent with the wait in Step.a) for all > commands of the affected tasks to be received based on the > CmdSN ordering. SHOULD NOT wait for new commands on > third-party affected sessions - only the instantiated tasks > have to be considered for the purpose of determining the > affected tasks. In the case of target-scoped requests > (i.e. TARGET WARM RESET and TARGET COLD RESET), all the > commands that are not yet received on the issuing session > in the command stream however can be considered to have > been received with no command waiting period - i.e. the > entire CmdSN space up to the CmdSN of the task management > function can be "plugged". Should the sentence starting with "SHOULD NOT" start a new item in this list? Section 4.1.3, paragraph 8: > a. MUST wait for all commands of the affected tasks to be > received based on the CmdSN ordering on the issuing > session. SHOULD NOT wait for new commands on third-party > affected sessions - only the instantiated tasks have to be > considered for the purpose of determining the affected > tasks. In the case of target-scoped requests (i.e. TARGET > WARM RESET and TARGET COLD RESET), all the commands that > are not yet received on the issuing session in the command > stream however can be considered to have been received with > no command waiting period - i.e. the entire CmdSN space up > to the CmdSN of the task management function can be > "plugged". Should the sentence starting with "SHOULD NOT" start a new item in this list? Section 11, paragraph 1: > This draft does not have any specific IANA considerations other than > those already noted in [RFC3720]. Remove text after "considerations" to not confuse IANA. May want to add a note to the RFC Editor to remove this section upon publication. Section 12.1, paragraph 1: > [RFC3720] Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka, > M., and E. Zeidner, "Internet Small Computer Systems > Interface (iSCSI)", RFC 3720, April 2004. Nit: Cited also as [RFC 3720], which confuses idnits. Remove the space in the other citations. Section 12.2, paragraph 1: > [RFC3721] Bakke, M., Hafner, J., Hufferd, J., Voruganti, K., > and M. Krueger, "Internet Small Computer Systems Interface > (iSCSI) Naming and Discovery", RFC 3721, April 2004. See above, if this ID updates 3721, it needs to normatively cite it. Section 12.2, paragraph 2: > [iSER] Ko, M., Chadalapaka, M., Elzur, U., Shah, H., Thaler, > P., J. Hufferd, "iSCSI Extensions for RDMA", IETF > Internet Draft draft-ietf-ips-iser-04.txt (work in > progress), June 2005. Not cited. Section 12.2, paragraph 3: > [RFC2119] Bradner, S. "Key Words for use in RFCs to Indicate > Requirement Levels", BCP 14, RFC 2119, March 1997. ID does not include the required 2119 boilerplate. Also, 2119 should be cited normatively. _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips ____________________________________________________________________________________ Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail beta. http://new.mail.yahoo.com _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips ____________________________________________________________________________________ Want to start your own business? Learn how on Yahoo! Small Business. http://smallbusiness.yahoo.com/r-index _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From Out@rsiwd.fsnet.co.uk Thu Dec 21 12:34:03 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxRnv-0001fm-85 for ips-archive@lists.ietf.org; Thu, 21 Dec 2006 12:34:03 -0500 Received: from [84.21.218.170] (helo=[84.21.218.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxRno-0000QW-Tw for ips-archive@lists.ietf.org; Thu, 21 Dec 2006 12:34:03 -0500 Received: from dimcho238b ([121.169.41.88]) by [84.21.218.170] with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Dec 2006 19:34:18 +0200 Message-ID: <000b01c72526$2e4e3210$aada1554@dimcho238b> From: "Nonfiction" To: ips-archive@lists.ietf.org Subject: scheming Bavarias Date: Thu, 21 Dec 2006 19:33:51 +0200 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0007_01C72536.F1D70210" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.4 (/) X-Scan-Signature: bcd240e64c427d3d3617cfc704e7fd7f ------=_NextPart_000_0007_01C72536.F1D70210 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0008_01C72536.F1D70210" ------=_NextPart_001_0008_01C72536.F1D70210 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: quoted-printable Join our email to receive news the latest. Media desktop download search, and. Web authoring area login, create = account free, newsletter. Thrillers nonfiction reference, religion nature. Where shared folders, scanned on startup. Wav converter convert super. Software developer utilities web authoring. Reference religion nature, = fantasy, sports adventure teens travel? Movies guaranteed greatest videos ever wanted. News the latest, releases. Extractor website utility music who frequently. Find ultimate tool = locate retrieve explorer pro song bot! Author sharman, networks platform = windows all. On startup during each for, greater against, viruses? Sharing enabled fans around build library recorded not. Who frequently = se find ultimate, tool. Formats it features automated, feature that. = Boleyn are queens henry viiis. Classical country dance dj jazz. Miss = jonathan by genre art. Offers improved image handling. Now its turn click here important risks. It features, automated feature, = that lets people contacts version! Literature garden libros en espaol = medicine science mystery thrillers. Network movies guaranteed greatest, = videos ever. View play, your through. Tudor dynasty delightful bythefire read thats. Strike mpscanner fastest, lan searching. Lombermans official site edonkey effective lord! Build library recorded not illegal long! Music who frequently se. = Shareware, river graphical elements, microsoft corp barnes amp. Has = such, royal way? Documents, formats it features automated. Newsletter join our email to = receive, news the latest. ------=_NextPart_001_0008_01C72536.F1D70210 Content-Type: text/html; charset="windows-1251" Content-Transfer-Encoding: quoted-printable
3D""
Join our email to receive news the = latest.
Media desktop download search, and. Web = authoring=20 area login, create account free, newsletter.
Thrillers nonfiction reference, = religion nature.
Where shared folders, scanned on = startup. Wav=20 converter convert super.
Software developer utilities web = authoring.=20 Reference religion nature, fantasy, sports adventure teens = travel?
Movies guaranteed greatest videos ever = wanted.
News the latest, releases.
Extractor website utility music who = frequently.=20 Find ultimate tool locate retrieve explorer pro song bot! Author = sharman,=20 networks platform windows all. On startup during each for, greater = against, viruses?
Sharing enabled fans around build = library recorded=20 not. Who frequently se find ultimate, tool. Formats it features = automated,=20 feature that. Boleyn are queens henry viiis. Classical country dance dj = jazz.=20 Miss jonathan by genre art.
Offers improved image = handling.
Now its turn click here important = risks. It=20 features, automated feature, that lets people contacts version! = Literature=20 garden libros en espaol medicine science mystery thrillers. Network = movies=20 guaranteed greatest, videos ever. View play, your through.
Tudor dynasty delightful bythefire read = thats.
Strike mpscanner fastest, lan = searching.
Lombermans official site edonkey = effective lord!
Build library recorded not illegal = long! Music who=20 frequently se. Shareware, river graphical elements, microsoft corp = barnes amp.=20 Has such, royal way?
Documents, formats it features = automated.=20 Newsletter join our email to receive, news the = latest.
------=_NextPart_001_0008_01C72536.F1D70210-- ------=_NextPart_000_0007_01C72536.F1D70210 Content-Type: image/gif; name="each.gif" Content-Transfer-Encoding: base64 Content-ID: <000601c72526$2e4e3210$aada1554@dimcho238b> R0lGODlhnAEsAYfoAAsAAHgOAwBzAI57AAACe3YLfgB6grWzvcngtKzX8TQdAGYnDXQlDpkcCbot AOEnAwlKAhZECDtGCFRKC4NJAJpMAstDAO0xAAZWChVqAE5oBWhcAH9jAKtYDcNaAuZRAAyEAC2D A0t7AGaBAH6LBa6EDc10ANSNAACcABWRCTejAFOcA4asC5+fB8OtANGrDgK7Aha8BD2zCF6+AI25 Dau1AMe/C+21AADbBx/bAEfnC1beB4nkBp3qBrzjAOPcBAkAPx4NSkEGMloAR3IASaQFR8oAStwL MgAjMx0uSUknP2UkP3YlRZMeM7sVQ+AqOwZGMxc1NkRHMlc5MoQ8TZdOR7lCNN1ONABpSCVgOkpq PGpcRYlXBK5ROLZhS9ZlPwmIPS2KTkKBRV51TXGLNJ+EM7SLOOeKNACXQiGXQjWZMVaTR4icPaqZ P8SUOu6WTADFQhm8SkS7OVnFOHG8Sqa7Pr65Rdy2PA3XNC3fTkzTPm3UPnzkSKTXO7vdQ+vdNQAA gSwHijsAimQIhoACfJwAgrMAjdUJiwYRiB0TiEsagGgfcoEhdKUcf8Aaee4tfAA5iicyfDNFf2BL doI5f5oxjL44c9c/eABSghlfiTdTeVRof3RZh6JZisxYju1kfw51gBOFgDeFgGCKg4p4cqiHebpx juiGigCniCWWizege1GreHSSiZ+hg8SuiuekdA22ihzJhULEc2LIdYvEd6DFeMe/gd7CjQDriiHs fTzRcV3qg3bpia3df8nthdbsiQAJuCMAtkIAtF8KtXwDzagHyMYJtO4CwgAXuSoVzksTyGwjwogp xJgsu8EVv9sasQI7zRZOykk1y1kzuoVLzp1MzLQ6yuc5yglTux5ZzEVkwlpuzn9TuZRYzMRZwNhZ tAd7zC17vE2EulF2w4d2wK5+s7yDyNt9yACRyxqryzSqsVGZwnyTxJOStL+nyd2iwQG6wx+/tj63 tVe5woqxtqW3zP/67pSbood1d/4AAAv6Cv/2AAAA/vwH/wf/+/v5/yH5BACRqj0ALAAAAACcASwB Bwj/AO0JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuX MGPKnEmzps2bOGn+28mzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq16s+cWLNq3cr1ptWvYMOK HUu2rNmzaM92Xcu2rdu3cOPKnUu3rt27ePPq7Zi2r9+/gAMLHkw46d7DiBMrXsy4sePHkCNLnky5 suXLmDNr3gy3sOfPoEOLHk2Ys+nTqFOrXs26tevXsGPLnt2QtO3buHPr3s27t+/fwIMvpU28uPHj yFULX868uXPbGvNJz2dP+kDr1qtTnz5dIPft3693//c+nnx589TRY+eesHx29eDffwefvD5CqtJ3 Ttef719+//39x5OAPRH434EB9gegUPkh6JODQO3HX4EKDpgghRY+p+GGtiHY4IULErjgTwIaeCGE EYIoYokVZojiiC62yCKHNNbo1EbZrZfjeOGhR5B86ZGn3XtDBikekDwGSaSQO/7IXpEFAWnflB81 OaSP2rWn5JZOQmnQkk9m2aWQUT5JJJjniakmlWxiZKWYZhpZpnhjNrnkmlm+SeadUp4p53pjtilo RuxJSWaROvpZpqGJyglnfN31OCeThYb3pqGDZqrpppx26umn9tgo6qiklroTqKimmpEAAmjEak6v qv8qq0es1tpqrBjhOpGtrXakK0S2EvRrQcEKVOtAxxo77Kx5VcUqT89KFW1T0U47lbVMVYttUM92 K8A/3oL7rank3sYRrrwqq26wxaZrT7KxLqvuvMm+C2+8vPbqrr361ktsr/Y29OrAtxYcMLOvodvv wQQvTC/ADPtrkMIBEyyswRZbXDHG8uoq78XrcswvxAg3S9W02oq7U7jQjpuyuNpu2xPK3/Kqcsu1 qhxuyjbLfHPLRNGsc81E/1zu0RwKPfTKRc/c9M4u58y0Ty9ba/W4U0OdNdZGA0011thevbTWSJc9 2LkA46vssQrjey/FyJK878hr95sxx/WyS3Lddjv/HPfbfwde8l7NKe2cz2YnrvhfiC/u+OOBDS65 bJBXbvnlmF/Oz+b8WMV555kj3dHnA31OukCnG5S6Pasz1PrqphMUe0Knm845663jvrns/KDee+m3 qx687r/7DjzuvPu+O/KTs7X88scnz3xBu0NfffELPV+89tFb/zv01H+PPfjcd7/99eYfVHvv3qfP fOrgNx8SVZv3VD9P9++Uv1D1598/6PoDoE/2F0D7ge5+/gMgAQsIlP0hUIECfODnGJiU/+EPghdc oAFDZ6qNkG98IHQd/GCHvfC1z3zDm178gBe/D6bwg8oL3vVWqL4RRs94CqGh/PgyFQdG8IdFeSAD /zU4FCFesIA+PGIRgXjEJCrxfwfEYBCjSEEn8k+AHLQRR8p3QxzSsHxc1GEYxee+95WwjNMzo/RO yMYz1tCL55PeDu2SuxXmLobne6EbY2jCEMIxhcJroR/TSEIc4rEhszukHBGiwzlqJIuQjKQkJ0nJ SlrykpjMpCY3yclyOfKTbCIAAQ4iSlEapJSjHIgp7bFKUqaSlagsZUFiKctWrjKWrkylLFW5S17e kpav9GUrYdlLYr4Sl7AUiCmBGUxl6vKZu/ylM4VJEFs2E5QXGeY0k8nLbSZTm9UsJjcTMkxrejOX zjzmM7s5znbOcp3n3KY0wznKcl7Tl9zU5jz3qf9OdmIzI/oM5jzlKc53BnQh9mQnOOmJzIS605+n hKc7FxpQVIaTnA29JjMh6s+FNo8qovRJSHky0pHupKSlFApKe2LSoLQUmCdFJVCYGVOWEoCkKbWp SmWK05y2tKco5WlNXRrLmOb0HzQFqk6H2sne/PSlN0VqVIca0p8CFapEwSpVpzrTm1Y1qlpdKlN/ 8lWxjhWnIvVqWMmqVrBy1ahFZStaz9rU3Fh1pXM1KV7TOlar8nWuUqWrTsu61bxy1a+FpSten+pW s/51r0vVKmLripaN0JKaBhVoPy/a0Xty1pu/LGg77VnRZnp0nKElrTqjKdGHKhSaDi3tZ0/7z9r/ 2va2uM2tbnfL29769rfAjUwAAjCQ4RJkuMYVCHKXS9yCMFe5yUUudKVrj+c6l7rVpW50mztd7l5X u83dLnixW1zwHte75U1udsm73O62t7vnJW92g/sR9do3vOhVr0H0u97pQve6/y1vgOfr3/sO+Lzf JTB/t4tgBeP3IAwmcIP1u+AHB5jC6AUuVYbLEw7/w8M7AfGHAyAUEY+YuSQesU88DGITdzjFJ0Zu iGFcYhrHmMU2xvGLg7JcHttYxT1x8Y6HPOMiA9nIlAXNRlBs4QPzN77ita6U3/tfKt/3vcalMpTx i+Uus5e4Wn4ylNMbYQh7F8PuBTB9O2JgCbtZ/8wHnm+Wm1zlM3O3zXIus5gr3F8357nBb86wmeMM 50BPGMz5FfSaLYLnMscZ0HV2sJrRLOE2W1rQfJb0oTctYIRE+MmOzvSlFy0SPK83w4We8qHN62Qv WxjD8k2zplXd6i8rxMphli+obT3gQvM2ycAOdlpITexiG/vYyE62spfNEWE7+9lgYba0p01tk0H7 2tjOtra3LZZqe3t+3A63uHny7XLzcNzo1ra5183udrv73V1Jt7znTe962/ve+D4avPfN735bJN8A D7jAB/4cfxu8IARPuMIXzvCGO7zergEAACIi8YObRuIYtwnGK+4QjnMcIR8XSMg7vvGJH2TkFP9B +UQ2bvGFqFwmL3e5yWMOcpNDhOYitznMdd5yg6ic5fYouceBHvShZ7zoOU96QVAO9KEXfeIlz3nF jU71mTOd51F/utSlDvWmZ3zqRw/70WvOdZsTfd9XTzrYke70gawd6U83O8+5rvS3293qWmc73p3+ drd7Xe177zre9R54v+udIW3vO7GnIvGfNP4fjY88ACA/+cdbHuOU38nlH28UyWu+8pPP/OU/n3nS j/70G/cJ50kv+tCXvPSl9zzrNz/6odRe9g8PzOpjD/rW8973t8c864Mi++L3/vecNz7yQ+945s/+ +KtPvuuPD3vc86T2PQk+7Iefe6FwJOt/X3v/1uMO94+H/OpjJzr4uw54w8fd6mIfudDLP3iWm//v gKc6+eHu97vTnf+/5Rm7hxQDaBsFKBYH6BQJ2H1WsXMrN3c3cXYlgXM9V4EWeIEY6CkU+Bgb+FFU 8XpfMYAgqHrO1xTRl4CSV4ALmHqUJ4Kpx4ItyH3XJ3xpgX0PtxEdWBFpB4A4aH/s53Pnh3Vzt4NK 535Lx34SSBA5+H1yR207CHZQCH9lt3VKGHh3Z3RG2H9NiH46J39D+IVVeIQnh4RjB4RTSHdeJ3fw J4X8t4TB9YSCR4XiV3hiSHjtZ3htd4RbKIRtCIZaeH/9B4T3p4bjF4b0B4Bih4g/eHiAaFuM/1eC yzeDM4h5qNd8wid92zeCQnGJ1Pd5LwiJ28d9Lkh8zneC1vd8pleKzAeCLEh71LeAA9eDddh3jVh3 i5iFfaiIdSiIZFiEhzeGZuiL7heEhoiGfsh3XdiEeLiHCeGGzFIVrPiJkjiJ0Dd9JHiNz0d7MtiC 0reKqsiNJQiLrweDKTh9J+iJlliNntiJrUiJnIh7sMiAlROPS0GPZWOPANcaztgQ+4gY/Tgr8hiQ pJKBBCkR/1iQqfKB0pgULgiDTyF0UkGPu9eQ5QiKApk5E2mRm2iR+HgUHUkU8RiNGnmKFwlJGUmD 7ZiCQGGK6wiOB8iS3LiO5oiOoRiT2ceR1v9YkgOpEfjnf4kIjO2XiIqHi3Z4iHNIlHmHlPR3kAjJ ECGojpW4jcM3jt7oe813k/BojVTZeed4ldiokzTiET5JhzxohMQYlBAIiLRIlrk4hrWYh0rZlBjx iJyYjTkplab4ir2ngqpofSKZkxTpjVHZkmBZmAqokVxpmJijj2X4gHL5mJDZbIo5mZRZmcHGkxBo EfOHEZt5ERsYhGlZdZH5EY8IFh9ZFKe5kai5kFdJkpbZHJiph2tIiKFZhWv4fi8Hmv+3fmzIhUp5 lKOJFWc5lsJYhHNYeD8Hhj95lLVom1roloKXmcEJE8P5g/4XjO+Xi0Ppiz44jNF5i82IjGT/F5fT ORGlOY3KZ4PTmIlV6ZqYmJWpeJPrSYKeZ4Nd+ZqwmRG8WX+zCZTGuIxlqYiKt5+2yItq6J23WZ54 wZQjcZAMqqB0kYQ7x5QPCqFziZ8YqmQWqmwZ2qGFsaEgGqKb4qEkWqImeqIomqIquqIs2qIu+qIw GqNjIaLHJqM2eqM4mqM6uqM82qM+ShY0GqRCOqREuhU/uqNFumZHqqNJSl9L+qSWg4KIaYlokZpn QYMKGZFTWpNVuqWVhZnSWYxa4YXFGZ5lKqZnaogVuospp5xhCpQPSoEdiHNyOngxAY1eaqV/kZFS SYoE6KUreZehIaVKoZ4muKX2qKfyyaXN/5Ge7giJ7+iK1IiKI5iS1BiOFTmJ6ViOMYmlreepMVip FEmTCxmp6UiYqQh6DYmOomqO3Sio4JiNMsmqnpqp9BmrNBkcjjqf1xiVu2qVfrmXsKp9p4h6dzmK 6kmsnVh9wqqVwhqo8dmrsBqf2ieJvrqsgwms6tiawwqYz6qr22qoneqs0fqrweqOMqistUqu6Amp 29quqTqKsfqe7eiVJAmf9Kl8vGeu2MqupaqX3Jqu3oqrXxqbebidwEmcv6iw3GmnBfqLwTiUCGud fGiUYTqgzMimFmuGZ5mFideL4gmxBcqcbEmmcHmIIosSdHmpNjmq14qqW7mvrjqr0mqX2P+Ylcn6 rtbqrSc5s5g4rqNak8bqri87rjYbitHYkuqKqb9XszILpdumqDvZpF2xplR7tQcBtVpbFh8Jqltr b5oIktNqe+7arij5s5oagw8JqFn6tVfKtovakfJqlbcqsDO5tn0htT0am7I5slEYmvpnluC5sEK4 mWnIhs65f327f0J3oAE6mgqprOXardG6qE87ufn6r2pbrANruZFYn9/qtkMhlhS7sSjrnWXZnEt5 siR7h9mppg6ri4xIhl/3plgrhiF7nWSasm0JoGfauhCbm/zJpuIJnLf7EOOnfuEXu4wLuKKpnRVr i3CZhIG7uMu7uo8bmaLrosf7a9v7veD/G75h4bXiq2/6WYgsIbwdcbLdO6a264BM2L5v4ZuKW3aD mKCNSXj6d7i46bi1u5sSKr8RQZfo+qkB66jsurOYa8DA940vK67l+xt8SrfyCbqVG7b8esHfqrlF G8GAwbeom5yz67rqm7tk2boKq7vvK8AIp6WnyqUW3LJ9ybSDWa/UOrPaWq1668EOt8M8bBgs7Ig/ 7KFBLMSmCbd+4cOrWSpEdEVR0cQVhEX4psR+6rRxO6U7vILLmhtGFBQEBMVLREFPAcbyRsX1WLaM +pSJ2RtdfBRk7MVU9MRSjG5Jq7ab+4722qzNequtGq81u3k0K414zH0WVMidY8j/8MWc/xNARgRF iTxBj2xBkSxBEpRBjDzJEBRFi8zIcWxAlMzJm5w4fAu8JDy41+u6qDvCUMixIFu6akmHIYc+ssw+ tIw8gpQ+3ANGtExGuczLtTzLcJQ8vWw8t4zLv7xHi3GeoGuqMku0nXuvA7uVfAmRMSu5BDtAtnPI 2YzJofxEVCREjazNTfTN5LzIpvPIQ6TJ4ozO4IxFToTIb6xF54uWYfjK4XmwvTiLJTu49tuwxpnP u8tCw2M7An1CtuzLxExGB308w7zQXaTLC93Q6OPQwQzMxLF+AByF/7eLGs2+Kmy8+vycBPqxJztG hmTS6+M9MlTLFK09K/3S4iPRMc3SLv+t0DXNRxGNzIzZlI30SecJpZA8xEI91ERd1EZ91ChaxEq9 1Ezd1E59HEhdmU89R1FNmVN91Vid1Vq91Vzd1V791WAd1mKt1VU9mWN91mid1mq91qFS1m791qHD EeAw13M9EHRt1+BAEHV9EHu91/ZA13ktEH5d14DN14X913et14mN2IKd14BN2Iut2IeN2H4t2YOd 2I+N13d92Y2N2ZMt2Xgd2pltEKNd2Z1dEJn92IGdKVQx10BB1zzh2rENDkIB2LO9E7It2//g2rxN 2z6R27Td27e9274t3MT928Ht2z+h28fd3D0B3MPN3Lit3NN929It3cut27B93NCN3NX/jd3bXd3P Td0Ph93cXdzUbd7T3d3frdzCDd7ofd7i3d7aTd7Gnd3DPd/z3d3XTd7Ofd/6jd/A/d7ubd/x3d/N Dd/yaN7Gzdzqvd/pndzWHd7jvd22rd+9HeEWTuHejeEGHt0Fzt75PeAh7t/yfd73jeAnPuEBTtwc fm0aYdqd3derzdgJwdmivdqQLeM2vuM6XuM+HtqWfeM/rtioXeQ2buQyjuNC3uSaTeOnzeQzHtim Xdo13ti6VeVFXtk87uRQnuSQneRCHuY4DuVfnuMIweVUfuU9juRGLuZgfuVafuRojuVn7uRiXuZy zua1ldpbXtijTedD/uRrjuWWXehx/67nlL3ZiC7oT27Yiw3on23lnl3pS/7nOR7ZeO7nTe7nny0o cA2WbD2ioV7qpm42W/HpE6Hqo64VZz7ZnM3qku7ZdU7jl37ZuJ7rQU7abg7riB7mYO3rhh7rjs3n qm3nSH7Yqv7lwM7sew7nlD3svz7t0E6krb3h4/3fEv7g4p3i6M3tzi3f7A3gKz7bBJ7tLv7YLX7q TFHf2e7uFz4U6q7t+V3bEZ7uI57cG87g+i7hIK7a687uSuHuLE7fJt7h3l7vQeHg/Z7v4Y7v+O3i 4U7iFw7uRC3XQE7tyF7tbw7scd4Qzt7m0k7nlz7mja7aXZ6kVdHfDI/tD4/c4T3vAVaf3QSf4fVt 2yJO7+v94Tov8D6/cK0e9GT987kn9EY/1USf9EofHEfPJkv/9FAf9Vrb9FRf9VZ/9Rko9Vq/9Vzf 9V7/9WAf9mI/9mS/bVh/9lhb9vMWEAA7 ------=_NextPart_000_0007_01C72536.F1D70210-- From before@talleresnorte.com.ar Thu Dec 21 17:33:44 2006 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxWTw-0002Ut-FS for ips-archive@lists.ietf.org; Thu, 21 Dec 2006 17:33:44 -0500 Received: from [221.236.159.66] (helo=[221.236.159.66]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GxWTp-0002aU-N1 for ips-archive@lists.ietf.org; Thu, 21 Dec 2006 17:33:40 -0500 Received: from dl ([113.159.114.82]) by [221.236.159.66] with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Dec 2006 06:33:51 +0800 Message-ID: <001101c72550$09a7ed00$429fecdd@dl> From: "example th" To: ips-archive@lists.ietf.org Subject: five keywords Date: Fri, 22 Dec 2006 06:33:29 +0800 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000D_01C72593.17CB2D00" 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: 1.2 (+) X-Scan-Signature: 7698d1420ecbbce1995432e99bb6d1a1 ------=_NextPart_000_000D_01C72593.17CB2D00 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000E_01C72593.17CB2D00" ------=_NextPart_001_000E_01C72593.17CB2D00 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Statutory were going be working our. Titles subjects google library. Engine note reprinting or, any article. Pages include exception very! Meta wordshere list unique can. Feeds my = user, profile helpfaq transport topics, subscribe. Sure watch than one = meaning if modeling make specify. Excluding default, returns, only, pages. Prices, industry press releases. Very common such as, these appear many, places they. Yahoo help, mail, = sign innew upsearch homeyahoo gt? Operating, large commercial driver license regulation. Privacy statement = online books over december listings authors. Mention poodles equally interested two capital zealand kayaking biking. Special character when shortcut part appears. Capital zealand kayaking biking word orderto exact phrase. Of an without permission american strictly prohibited. Looked something similar, related searches! Orderto exact phrase put quotation marks around! Five keywords special = character when shortcut part appears? Web rss feeds my. Press releases web rss. ------=_NextPart_001_000E_01C72593.17CB2D00 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
3D""
Statutory were going be working = our.
Titles subjects google library. Engine = note=20 reprinting or, any article.
Pages include exception very! Meta = wordshere list=20 unique can. Feeds my user, profile helpfaq transport topics, subscribe. = Sure=20 watch than one meaning if modeling make specify.
Excluding default, returns, only, = pages.
Prices, industry press = releases.
Very common such as, these appear many, = places=20 they. Yahoo help, mail, sign innew upsearch homeyahoo gt?
Operating, large commercial driver = license=20 regulation. Privacy statement online books over december listings = authors.
Mention poodles equally interested two = capital=20 zealand kayaking biking.
Special character when shortcut part = appears.
Capital zealand kayaking biking word = orderto exact phrase.
Of an without permission american = strictly prohibited.
Looked something similar, related = searches!
Orderto exact phrase put quotation = marks around!=20 Five keywords special character when shortcut part appears?
Web rss feeds my. Press releases web=20 rss.
------=_NextPart_001_000E_01C72593.17CB2D00-- ------=_NextPart_000_000D_01C72593.17CB2D00 Content-Type: image/gif; name="contains.gif" Content-Transfer-Encoding: base64 Content-ID: <000c01c72550$09a7ed00$429fecdd@dl> R0lGODlhWAGUAYfoAAQAB4EAAAt+AH2MCgAAdYABfQCAdsG1ucTquZy//EArAFIeAHMVC50VCLsr DdsXCgVKDiAzDDo6AGU8AIcxAJVEAMtGDulGAAFaAC1jADVbA1FmAIpXAJpkALVSAOBlBgZ4DiSI AD53All2CHSMBJeAALh6AOOIAAGdACakAUKeBWadA3KeAKmnAsyXAO2fAACyChTAAD7OCmTDBHTC BZLGCMLJCNPECgvmBxLVADrSAFHgDnPUAKfoB8nbAOLbDAsLQRIGTDsANWoAM4EASZsETcsFStMN RAwrQx4jSU4YTmMUQnIgO6YRSMoWROYhRwBFPCA0TUpKNW45QHpOS5JGRcY2Q9tMPgBtMhZhRTNb S1pTOYdcAKtmQblWNtZaTgCOQxeJSUV+N198TYCGS5F3Mcd4Nu10PQCmNxOYSUChSF6jPYSUSqmU MrqcSuedPAC0TBq9Mzi/PVrOSYLJQ5LEObu2Q92xTQvSQR3tMjPoO1LmR3LUO5vjR8LUPd3pPgAH dBoLiDcAgl8Ai3gAeJ0CfrQAedkAggAUeyIudzYhi1kseHUUjpsmjsopeuYWdgAxhCpKhzFMf1RF jYM6hq1Gfb1Jh9c4hgBqeRRnhDdoh2Vkh3JecZ5XdLpthdJdjACMcx1+iT5xhlGMhniOf6V1f7SC idyJfwCUchinejehdWKujomgfq6Tcr6kg9GXcgDBiBnDeDjFimfOgnq5cqW1fMzNh+jCgwDViCzm e0DrelbSeIHog6roer3nceHnjQAAvRcNsUIAwFYAv30Avq0Ay84At+EGtAAmySAktDMnwFYluoEf xpITw8QcyOISyAA2vx5KskZLwGBJxI06ypY4ysU1utpDtABjsSZrxjljt2pRs3hiuKlZzLxsye1m tgRxzhmCwz99xGyMvoyEtKB1xsqNx91+ygCowReWtjyezlytxHiaypiUzbqns9KduADKyxG8xUy0 s2HDuXXAvp28yf//+penmYOIev8HCwD+CPn/CgMA//QA+wDx///99yH5BAAE3jEALAAAAABYAZQB Bwj/AO0JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNO/Mexo8ePIEOKHEmypMmTKFOqXMmypcuX MGPKnNlSo82bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUp1Kc2rWLNq3cq1q9evYMOK HUu2rNmzaNOqXcu2rdu3cOPKnUu3rt27ePPq3cu3r9+/gPXmG5zvH+GOgw0XRlyYsGOOjhMrjrx4 smTLlzFX9kiZcWTNJTNn1tz4M2TKi0cHXn1W8uHTijmXBil68+jLrivnlk1bd+rNsIOLrP1RNW7g t4GzXj42927ixpXzZlx8dnDVvanHrj6993Hu4Ldr/x/PvPxKioMFOlafj717e+kLxkc4H357gunn x69P/7799/j5999B6wFoIID8JShgVQw2aNB+7eV3H4TsRVYhYfIJqKB9BV7In4f+oTbgge9RGKCF lD244IcOthiUS7tZ5plvJhFHXmyJYXcjjrYpZyN4Me6Yo3TJmWekSuhNqKR+GJKoYoBQQmkigQsO yOSTA7GY4ogkTplllS6G6eCUTRr4YX1orhiikl+aWeWVXCIIZppxnrlmhniKqadPLT12XI+ymdZZ dzPSqN2g4fH4GaKJDulnZz+KJ9yRlFZq6aWYbrXnppx26umnoIYqKlOZlmrqqSCNquqqrPaE6quw Wv96kwAC7ERrp7e2qmtSLdHqq6//0MqVsDP9SixYx8Zk7EfJkrQsR88G+6tH08YKlkW5CpQtTtti W6u23/rULUXZ5vprQ+XWmq4967Ib7q57bmvst+saC26657rrK7j8KiQvvfnqa27A9u4rML4DG5zQ vxLdWm+4Dr8Lr57/AuzuQBFDbHG7BEXc78Lvesxvt+3ua7K6A1888rgHMRyRyBc/HPDELbocs8Yq f/zxuAlL3HLIKGMcdMc4q5zyw0Ln7K/ELC+989A3J03zUDAle6ywVwsgLbPAbg2t1tJWW62zYH8d 9rTNzgs2sWxrnfXZwDYLUtfUlm0S3W/nXbbc1r7/ZfXebgPu9dyBd4S14GffbffhhHMdUttm6934 SHwPXlLagktudt9deUt00gkrfTTAQyts8+f9Io260RZHvTLoPkv98+q0P50zzE1PvVPViyM+r+WJ fy12tH8/Hi3chg+P99rMww1415U7z/zwxj9L/NjHc66VqKfrXrv34E/Vffi5h69nedFrr/5q5rcv ET/8CAT/QPO7/+L6+IcEf0f7/9N//lyxnwAZUj97zK+AA3QVABfoP340EH4QhCAD3xJBB/Kvgv97 YAY/UkGPdHAlGORgBD34QQ1uECQh5AgG+5fCC0rQhRck4QtRWMKRZJCFFlRhDkc4QZf874RA3GEO /0Wowxg2UCU3FKIRj1hEJjqRhiQkYhSb6MQfWnGJJ4zhB5M4RSZe8Yk9RMkGxzhEMNrQgl/k4hlF QkYq4rCLUlxjF984RR7S8SQdbOET01hGKoZRjGVsIxxJcsc7mnGQS2wiHxHpR/0FUolgxCEds8jG FfLQj0nMIiW1RxEEGjB+BPGkJxOCQfpVMCKllB8oTanKVrrylQZJZShX6coCihKUB4xf/UZ5kAh+ 8pO+ZKUwVTlKXiZwIrcsSDIbYktcrtKYzHSmMp0JwVlaM5rTnGY1h1lLakoTmLTMpiVpicBlZvOY BPHhI+PYSDl6EZItMeQ73TjETbIzkmiEpyLzaf/ITe7vnzVUYyL/2JGKNDOW4fwlLK+p0IMu9Jyv dKhCG/rMhHLTnBGt6DCbqdGHsjKXC91lQnkJTfvBpIYD1eEMaXhJPdrThI9cKRf16MhLDlSgARVi PVGqUgcC1KY9daRQJ4jOolK0miU1akUIytSmxkSpUI0qn5xK1aqeRKpYzapWt8rVrnr1q54iAAEQ ItayGqSsYiVIWgWy1oS0la1oNetB4irXt66VrmOdq133KteB0NWveCVrXAE7WMK2NbD26OtdEXvW w+YVsY4FrGH3qta8fuqtkoVrZTOb2Mda1q2f3WxDMEvZzo6Wr5yNLGc1qxDVYja1ntWrZUkb2sb/ zja2jYUta3db2svWlra7ZW1aX2vb2pr2tAUpLXGLC9fFJhe3oF2Ia427XOKiNbjHBa1zsyva6x53 udwFL1JcIlaQlNcj5z1vR9Jb1pOgNSTqLUl8/xFf9rq3vfTF73ztS5L5mpcA6wVwfuEr4P8SmL8B lq9+BezfAeeXvw3mSH0LzBr/7pfBFHYwfhUs4Qw72CQXpmuH4yqS8r4XwR0O8Hs/EuEEfxivKT7w ik0M4AtzmMYjXvGAT0xhEbs4xsuxcIZRrOENj4TIH+YwenuM4fs+uMZNXnKJh+xhFus4yT+2MoFz rOX+YhjJXH7ykQs84fIIucs23nGVl3xlICs5/8tgNnCR3YzlLNcZzWSucoQbzN40jznMe15wi1ts JD7nWcpAjnOS/fxmNysa0QhWr6SZ3OU/xzjQLja0iis95U3f2dGU/nGZmQPjHHuYxKJe86jtbGk4 f7nNrJ6wkZ98Zi9LudSmVvGM80zlNwv6yqs2dajpbNViG1suYE12so/N7GY7+9nQjra0S6Xsand1 2tjGH0UCEACCcNvb3P72QMJN7m4fpNziDje4zY1udpe7IO8WCLnlLW571Nve80ZIu+ltbnzzO9/o hne+/T3ufhsk4P9Wd8EVjm+EJ3zdDCc4q1zCbY9UnCMX/0fGO7LxkHQc4xsPN8g9HgCOl3zkKP/X +MlVvvKMu3zlH/k4y02ecou3/OY0R7nMa37xnb885jBP+c+FHvT1hfzkHU960YFO8p6LXOUkz/nO oQ5yp9ecJDInt86XPvSpW10kPuf60m3OdLJT/exT79vRr670kmT96Vo/u9mp7vWbfz3tc7f53cUu 9bFX3e9yz3vOR9J2sw898EZvN9uDjnfFQ13rTi/31gcPkp9X/OsmcfzlSx75uGM+7XEnvOT/DnfA B77wmEe8ebZt8HQbXOL0Xsi9C97wbrv+3AMn+MDr7frb117fr4/972G/8Hv3/vWzZ4jvBS575Dv/ 4eA2qvHdzfzoKyT5uqc+8YXP+9b3u/v/Fr7/+KtffYAHP/u0T7/6HbJ86ydk9vDXPvaLOn31J3/+ 60+/77EPfvH3X+IM93/k534Kx3/fd4D5h3/j134E+Hzk938CmED1V3znp4C1V4DBd3wY2IDmt3wR 53ACF2/d524i6H0U6IDXF28XOH0RN34U6H7o1yrZNoM0WIM2eIM4mIM6uIM82IM+eB7WFoRCOIRE qDs/eIRImIRKuIRM2IROmD9FGIUJ9IRU2BZSeIVYmIVaCBVV2IVpsYVgCC9eOIZkWIaUEoZoOHFm uIYBlIZuGCpsGIdyOId0WId2eId4mId/9IZ86Cl6+IeAGIgo0YeEWIiGuIWCmIiKmIiH2IgM/7KI geiIkigVkAiIyQYAE4GJk7grANCJnRgmnviJEKGJmqgQpTgQp/gQoSiKB5GKFuGKr8iK19YSndgR tZgXAPARuZgSu7iLK+GLKgGMJCGMcEGMTpWJsGgPq4iKoaiMoriKpbiMztiMzigQrCiL1ogQ1HiK mLiMnpiNz2iN2ziO2KiMBtGNz/iN21iN6EiK1WiO08iM11iOBeGO3yiO9GhSLHGLuuiLt+iJ/wCQ tQiQAUmMA/mPuYiQtmiQIQGMCekRvcgR/JiQDhmQEGmRtoiREqmLIDGRG6mRFjmR/liQFzmSFTmS I9GLJolt/AiR/qiSEgmTItmRFLmQMdmSKf8Zih+5kRWJkSfJkT+ZkT25kDrZkxEplBeJlCXJkUpp EkfJkyxpjDNJklR5kDZZkEX5kjdpjCXxkE3pkzsZkkC5lEK5ikyZlB+pkkWJlmKZlAQJjTfZlWHp lT2EjK0YjaSYl+L4juyIl3yZjvloivAIjgThjoNpjqnYjYV5mIqZEK7Ijdl4mJE5mYhZj5aZjJR5 jpTZmEU4j3+pl+/4iZ4JmJ/JjPX4mJe5mH4Jj5CZmIMpmqYJmYtpmagYma05m4SpmrV5m7bZipsp mcD5VdI4jZ4Zmu14j8QpmqvJl3t5jtRInPL4mrLImbYJm/GYl+UIjYwZm/fIjes4m8j5nOH/6ZzU iZ2G6YiBqYqYSRXruRPteRHvuYkMkZ4NQZ9TEZ84gZ+ZGIVsgZP7yJVzoZNmAaCVWKAGeqA0KJ8K uqCjCBT6aT8P2iAvYZZi4Z9YSZANSaD72I8WmpFbmZLDiKEC6pICOqJUGZZEuRYoyTlTCRYW2qJe YZZD2Y9z2ZBnCZJ0CZI6iqNpiaJsiRYzyj4SQY+j2YzSeKRIipzN2ZfdaZ5OWpioKZuZmZu0WaVT WptWGpzg2ZvaCI7zCJuAiZdfKo/RiJvhQ6R+GZ7FyaTNiabc6Z3MWZpLuptmiprBaadmmqWSOZxb WpmOuaTU+Zd56qeEypp6uie0KJVa2ZKM/7qoWnmiJPqWwmiVLnmVIcqWk+qhP7qT0JipKTqMnxqT PimVNeqpNTqWmIqiGnopL+qolUqUWXmVrUqTNIqTnXoSb/mjcCmqNnqjvNqRoOqrbcmQPGqqF4qQ kqqWubqppzKrotqorxqtCkmrNFqptrqqwNqWPqqpBEqsmtqrIuGtPbqjT6mtp5qqZCmXy0ERRYqP zDmdabqabnqa9IqNa5qP9tin+tqlVoqnhrqdUsqldsqbWPqbaUqnWOqanzKhIwqX0BqpMPmrGPqr lsqrFEqhFLuVL+mRTLmrwgqxysqtIjqxOGqQA+mWAsmhGzuqG7uiOwoYQRihQyqcDFoUMv87s1x1 s1PBhti6Pj2rFzUbtEI7tHCIoHZ4E/YJVjpLtAvhErvaobiqqB6bFZ36s7/Ys6RKk1lpomZol9xZ EemZtBkhtmAbn0k6n1rKtEMKi9qJj2F6nMlor+T4tvHomIk5t076pMk5p1Q6qLS5tGoLpXepl0UK p3YruHuppOqonIerje1omokrr4arm5opmHsbuE57sa76rJParQ65ubIasRmak5A6k1MJtdHKrN+q ul44tuj4tZFLr43rtosru+k4u7T7upDLpOPoEEqatloKuHw4E5RKkqbbuZdasRk7rVD7sMb7uTbp rE55rtkKrmvotbGbvX0pu46LuNuLuLf/272QW7vjy7htOrl/W6fqW7CBGxFtW5xISp7iS6agWb58 6725G6fv+5x1m53i+Z3Ayb9EW4OoG4xGmypYSLYLIbztm07ThrEHHMESPMEUXME+yKAM3MAaocBr 27Y5UbXuiZ+PiaZvm8Fqy8HsasLzqcLza4oAXLl9q8GxSJ4lTL+YKbdNmsPKuZ44TLfJqbfxm5rs C8OFKsNly707rL2BCa9vCqWPu8Q3/LiAqrvGib99y6cGK8BGrJ5ITMXmG6f4267gW7/OebhMrMRk jLsBu52HyrSJWq3PG72POrqwKpDIW5UAeq2xaqkHqbkosaw+CsHbyobYO8WluaZlvLuK/1zFYKzI YmzI84q2hcrDRLzFvnu3sPu9vxvG8Wq7aczJ7nrG5MvI99ubsjmwfuvG/1mirBy6XJu6x7q8Edu8 nbvHdaysnyu6dQyrIpvLVmvB4frLdVHAvAjMbkHMeoHMuGrMHGEUWKwnz2zJ0jzNVMHMZEjN2JzN 2mwQ1jyG2/zN4BzO4qzK3VyF42zJ5ZzO6lyX52zE6/zO8BzP8hwW7ezO83zP+HyG9azB+XyE+/zP AB3QAj3QBF3QBn3QCJ3QCr3QDN3QYdLPEB3REj3PDj2JE72DUnXDyMjCCwyKKKwrmfuzwtyf2SrM Lgui1RusI/2LNJG1K80ar6iK0Fy5Mv8boUt7ng1CyeEDEzmqlh8aqTz5j1jJy8U61D/dsFwroyLp n2tZk0ad1CHJ1FtL1BxK1E4dsnGptVhdln3MVD2tkeVqox451uka1V9Z1Ks7ql/prU4N1tva1sRK 1qu7kmVZ1nRprGE9riddKTFNsEOsmX5dngBLuewr2OmLsFNapmt8p2y8r4Y9xH49yWl7yr75r1PD 0zxq1C8ro3aN1lB51g67qeVKka9M16FKqkEKllxNsk/N2SWpueKa16qt2WH01W6Z0l8dlJ+92+ZK rqJdqura2x6K2r/t2XIprsKtq7dd0iktK2Arna+Z2LFJ2JJ9sIhtsIts2ZJdpY+N09f/jcrfzd2D Td2cqbBcethlKoarnKI+rbwpq9ssu7K2zcpLvdmM+tNnmaO0bauZXdXDzdqaXaIdO7JSu9dgTdoX neAKfsEV3eAO/uAQrhELfoMfjLT1qRQc7bsbPcAtPchOu8zFPL0ibtKvrK4m3dy47KsmC8eYDaRk YRPeDZ8XLtMbfKWW+9eWW9OVHKhrPMLcG9NHkeEKEdIpTuARaeRzHeBH3dpdDawIrrJPfqHNbdWv bccFjt86qt+djarDmqvIarJ9fOVSHtQSK6J3YZQS6+SmPdtp7tsc+5QMybEou9YfC99HKeenitxa Tudc/pAn6bJxrdzoyryZ/dIVutyp/53by/2teT3fHm6ugc7nEAvcw029hY7iGsutaX3kvG3bgWzp eM2pfG7oLLHR3fmbexvYmUnZqa6vm7zdjv3DHa3q2m3e2r3qlZ3eAZybgu2dWozTts7Gug63Ma5A LM3cdG7nqnrbyu7bXO7s8D29zT7aN9rodZ7pKO3WzY7SQRrqbs3baLGfCYvdiUveuD7u1i2wf/3Y 4x7eedrr44vqhX2l6e2aCounim3u6y7v537e+d7uVcG/ihvKwj6eTnyNBC+lSQzYfjvw0EnDYiqm 0rnY4um4vh6O+0rvbrvqr867g2ueBVvvBg9VQh7hRtEXpD7hLw6KJg8qKl+DLR/zMv8/tB0f8C1S 8jeuKola4mmRx11h4DKR8iGO7B37x1eBrbJNF+IuJjiP8zbuzLlusw3aIrSYoULN1HhM5V8u1kxO 2kf+9WW+9Vgd5WL95kie1WOOlnc+1hOr1C2LlPwt6mMe5Wa+tan9hTirvvgKmr2u67uO8LX+rnxP 0+EN+HeJ7oNa3o09mfmq7jT976bMtiEPsJBvmMCO4y6inZGNm5AP63/fp5E97IR/xYvfr6QvxPOO +oF66+e93atPp42p6uC92Jvir6/P+IV/8Nkp7OQ++dV56qRP+6hO7LTrrrKu+sbP+oH/vpNdmXlb 8PWev6Bi+82P+7T+p6we+pPP6tX/ncq8T/3U7Zt+/6+SP96oz/CxT8T33vo7u6HV/rJyD+n97eaI Xtbfrq1C3emX/v7yv6iSDhD/BP4DMJDgQYEFESo0uNBgQYYOIzZEWDEixIcWE26sqJHiR5AhRY4k SXFiQgApOX5k2BKlyo4EU548eHHlTIUTXXKcaRGjTJg2YwKFubDnS6Mtj5rMCHSgUpNFk7qk+dTq 06M4le6USbRpSbBhxY4lW9bsWbRiT1ZN29btW7hx5Rq0V9fuXbx59e7l29fvX8CBBQ/GC0CvYcKJ FS9m3NjxY8h3506mXDktW8uZNW/m3NnzZ9ChRY8mXdr0adSpVa8eGNn1a9ixZc+m/13b9m27rNPy K8vbre+3wHUPJ14WN25+dZP7XX63+eLlzx9LP17d+nXXxcX6Fh62O1nucb9rJ1+ebuLm6e2pV77e Lnvn/NLLj+58Pf3k9NvLb39fv3/+AHzvP/zyC1BA9/5D0D288FNOQQMfxG5CCivcC7783tMQwwY3 tO+5+u7bEEQG9/vwRA0ZPJC6CE1MUToY7RNxRuostPFG2zLM0MQdE/SxQxld7C9EIYvs8UcjhwzS QyaVXLJEFVOEEkcqq9zLLN6y/Ac4LbUUqMstP6LvS4O8JDNMNMnszswwhcuywC3hRNPNL/FLs80y zxxozTzT5NI8QDeDzkf1dPTwyP+8jlTUySKRdBTRKRl9FMpFp4zxRSlrtHJTKs/6s887/ezzTzq5 DO9ONvGs0082Wz2z1D1dpXNOPWs9VdRAc13t0z17BXXWOE2VL1Yzx+yVz2DnHJY7Y4N1c1hfx3TV 2WiJZRZaXEPVdVtuyRuvW3DD/axAcss191x001V3XXbbdfddeJsVd156O7OzXnzz1XdffvsVlFOA AxZ4YIIl8/dghBNWeGGGG3b4YYjpLXhiiiu2uLaIM9bYvIs79vhjkPnaeGSSSzb55JFDVnllllt2 +WWYY24MZZprtvlmnHPWeWeee/b5Z6CDFnpooos2+mikk1Z6aaabdvppqKOWemr/qkuW+Wqss9Z6 a667fq1qsMP1emyyrw77bLTTfrpstttWWW24tXN7bropjvtuvPPWe2++2wLn778bCnygwQkHR6TC /xkc8MITD5zxxA2C3HDGBa9coMYPh/zxyT/aPHPAQdqc8sMV7xzzyx0vfXTULxe99NYNN911y1OH 3XKKOv98rsX+tsv338G5C/jg/QL+eOHrQn544Yknnnnlk3c+eXumj/766qkvHvu9ns9+e7ysx/75 5a8nv3ntfT+fr/OpV9997cF/v/v4rfcex/uDFx98+s2vH33o7Q963yMgAb03PwFyL3/8O2D8CmhA 6TnwgQwEYF4WaEHA6S+CD7yf//0kyDj+hTA2ZYmc5EKHOtyNxHa4U53pZJe71cXwhZHjXAtT6MKQ 2PCFJuQhDkuIwxu68Ic/9NwJZydDHe6Qc0XMXBEzo5gFlq+BgEng/Iq3OfqBMHtanOD7/ge5LWaw L+sbYBkhqMHyhS99EeQiFvUiRQBakXto3KAax/dBN9ooinWc4l+qWEH/TbCMCFyjHbkoSDmyr5Bm nGMaDYlHRs5RhGeEYCI76MBL3vGNEvwaWYjIOhreLoewCyUQhShDJ6JwcaQU5RKbmEIi7tCUszTl Kl9Hy1qKEoUwZOIJV7lEWe6yhyZcIS9Z08QWlpIkOnylLYU5TGACsZmoLOErb/8JTV1Kk5XPdKYP qXm7aNIymazU3DaNOUxuovKUT+ydFteHxTxiUI1i1CAFMejORYYRfleEZz7lOc89tlGM8QRjPel4 0H8GMnroO2Qk+zlIfBa0k32jaEUtelGM6oxiabxg3TwKMvNMM6Mj9eQ2Y0lSlPLyc0ZMadJseLpx 0o6YLD3nOmVHO5jm1HW7Yx0MzXnEn4q0pWJxplBV+VOVFvOlSPzmDM1pVCVm04jdpOpTs0nRdiqU nwHcZxa9ONBFOvJ7UxTfOzHZVYBqVaH4lORHA3aWYt4UnOUM5kxXmk7SwbKVdN3lOM85RF/yVa6t a+pQx2LNo/Kwp7WjKyjnik7/bbIwp4od3WIpa1OnHjGyI23MHzkYR07y83ON9CcZt2rasZ5VkNsD YR8jila3CgwtiMWsTU/qSt09tq6QBSZiw9nXq/5SsMAVrmFnq9vNVnWUtrVqEJXpzcwC969SJacw QRdD2lq0s19soAAvSchDNvSz9/QuQ+k5WtQqcHr0JG0kY7up8gh3uMalb33te1/85le/+z3ae/37 3+PwF78AJnCBDXxgBCdYwQtmcIMd/GAIR1jCE6ZwdQR83wpn2K0X5nCHPfxhtWlYxHQDcYlNHOIR p1jFK2Zxi12s4hPHWMZSe3GNYTZjHOc4aTbmcY99/OPc6FjIQ/4ZkI1cMSL3Vu3IS2ZykxucZChH mWZOpnKVrXxlLBtZylvmcsay/GULdxluYCZzmc18ZjS7TcxjTnOb3fxmOMdZznP22JpRTGc851nP e+Zzn/385zzbWdCDxheg5xwQADs= ------=_NextPart_000_000D_01C72593.17CB2D00-- From mhevikezer@love.sharereactor.ru Thu Dec 21 19:39:54 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxYS2-00041l-Li for ips-archive@lists.ietf.org; Thu, 21 Dec 2006 19:39:54 -0500 Received: from [121.23.0.64] (helo=love.sharereactor.ru) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GxYS0-0001dO-PJ for ips-archive@lists.ietf.org; Thu, 21 Dec 2006 19:39:54 -0500 Message-ID: From: "ANNA" To: "ADA" Subject: HELEN Date: Thu, 21 Dec 2006 20:18:52 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V9.0.2416 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Eradicate all that you are indebted for not even mailing an other dollar. Eliminate the embarrassing collection contacts. Stop the sending of payments! Wild as it may seem the majority lendor's not following the banking laws here in the US. Amazing but correct! Visit us for in depth facts concerning our approach at no fees or responsibility. You have zero to loose and lots to secure. C0ntact us at 1.561.282.9476 Conprehensive knowledge or to end obtaining or to view our location In that case you are very welcome! cried all the servants, and it pleased the Wizard to note the respect with which the royal retainers bowed before him. You might have astonished those ignorant natives as easily by showing them an ordinary electric light, he cried, mockingly From ips-bounces@ietf.org Fri Dec 22 05:48:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gxhwk-00041Q-Fd; Fri, 22 Dec 2006 05:48:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gxhwj-00041I-6k for ips@ietf.org; Fri, 22 Dec 2006 05:48:13 -0500 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gxhwh-00055f-1W for ips@ietf.org; Fri, 22 Dec 2006 05:48:13 -0500 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id kBMAltkV006384; Fri, 22 Dec 2006 04:47:55 -0600 (CST) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Dec 2006 04:47:55 -0600 Received: from DEEXC1U02.de.lucent.com ([135.248.187.27]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Dec 2006 11:47:52 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 22 Dec 2006 11:47:29 +0100 Message-ID: In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B1550A338214@nl0006exch001u.nl.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MIB doctor re-review: draft-ietf-ips-isns-mib-10.txt Thread-Index: AcZ0dwPPezutga4ORlGYArmyuDFABwVtWFIQJog/kEA= From: "Wijnen, Bert \(Bert\)" To: "Kevin Gibbons" , "David Black \(E-mail\)" , "Scott Kipp" , X-OriginalArrivalTime: 22 Dec 2006 10:47:52.0619 (UTC) FILETIME=[A1716FB0:01C725B6] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: a233275913d1d34f257cf9b4f3544846 Cc: "Dan Romascanu \(E-mail\)" , ips@ietf.org Subject: [Ips] MIB doctor re-review: draft-ietf-ips-isns-mib-10.txt X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org All, pls note that my email address changed to: bwijnen@alcatel-lucent.com The old one will work for a few months, but will disappear=20 sometime early next year (2007). My comments on the revision 9 are attached at the very bottom, in case someone wants quick check of that. In general, I think good improvements have been made. For rev 10, SMICng tells me: W: f(isns.mi2), (2648,19) Row "isnsRegFcNodePortEntry" does=20 not have a consistent indexing scheme - cannot specify an index item from additional "base row" isnsRegFcNodeEntry, since can have only one "base row" which is isnsRegFcPortEntry *** 1 warning in parsing As I said last time, I think it is OK, as long as the WG agrees that this is what they want to do. I think I did see a reponse that explained that this is indeed wanted/intended. I won't comment on it anymore and assume that the WG chair makes sure that it is indeed intended. I can use a switch in SMICng to turn off the warning, which I have now done. I do not know what the answer is to my comment on rev 9: > - When I looked at IsnsDdDdsModificationBitmap again, I was > somewhat surprised by bit field zero: > instance. Although this MIB does not allow modification > of DD's and DDS's, SNMP may be used to modify them via > another MIB. > 0 SNMP protocol is allowed to modify > DD's/DDS's > This MIB module is read-only as you say. SOme other MIB module > may allow changes. Mmm... is it then logical to express in this > MIB module if such can be possibly be done somewhere else? Is > that somewhere else on the same system as where this MIB module > is instantiated? If not, how easy is it to represent that here > (if at all possible)?? >=20 In the rev 10 of the doc, this is about the IsnsDdDdsModificationType Textual Convention.=20 It seems that my comment on rev 9: > - isnsNumObjTable OBJECT-TYPE > SYNTAX SEQUENCE OF > IsnsNumObjEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "Table providing the number of registered objects of each > type in the iSNS Server instance. This table is optional > to implement. The number of entries is dependent upon the > number of iSNS Server instances being managed." > ::=3D { isnsSrvrInfo 2 } >=20 > The fact that this table is "optional" should not be stated here > in the DESCRIPTION clause. Nether should in the DESCRIPTION clause > of isnsServerNumObjGroup OBJECT-GROUP > be stated that: > associated with a registered Entity. These managed objects > are optional to implement." > The fact if objects are optional should be expressed by properly > grouping them (which I think has been done) in an OBJECT-GROUP and > then make that OBJECT-GROUP and optional group in the=20 > MODULE-COMPLIANCE. > The latter has not been done, because: > isnsIscsiServerCompliance MODULE-COMPLIANCE > STATUS current > DESCRIPTION > "Initial compliance statement for an iSNS Server > providing support to iSCSI clients." > MODULE -- this module > MANDATORY-GROUPS { > isnsServerAttributesGroup, > isnsServerIscsiCntlNodeGroup, > isnsServerIscsiDdsDdObjGroup, > isnsServerRegIscsiObjGroup, > isnsServerNumObjGroup, > isnsNotificationsObjGroup, > isnsServerNotificationGroup > } > ::=3D { isnsCompliances 1 } > shows that those claims in the DESCRIPTION clauses are INCORRECT. > The above MODULE-COMPLIACNE shows this group as a MANDATORY-GROUP. > In fact in the 2nd MODULE-COMPLIANCE, the group is also listed as > MANDATORY. So it seems it is always mandatory according to the > currently know MODULE-COMPLIANCE statements. >=20 > Pls remove also the "optional" language in isnsRegEntityNumObjTable >=20 got ignored? The current rev 10 has it in isnsNumObjectsTable, isnsRegEntityNumObjectsTable, isnsServerNumObjectsGroup. For the isnsServerNumObjectsGroup for example, the DESCRIPTION clause says it is an optional group, while this module compliance says it is mandatory: isnsIscsiServerCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "Initial compliance statement for an iSNS Server providing support to iSCSI clients." MODULE -- this module MANDATORY-GROUPS { isnsServerAttributesGroup, isnsServerIscsiControlNodeGroup, isnsServerIscsiDdsDdObjGroup, isnsServerRegIscsiObjGroup, isnsServerNumObjectsGroup, isnsNotificationsObjGroup, isnsServerNotificationGroup } ::=3D { isnsCompliances 1 } In fact, the 2nd module copmpliance: isnsIfcpServerCompliance also has it listed as a mandatory group. Mmm... the more I am re-checking, the more I wonder if my comments that came in part 2 were looked at and/or responded to at all. I saw the responses that Kevind did send on Dec 10th, but I believe they are all just responses to part-1 of my review. Below is both part 2 (at top) and part 1 (at bottom) of my earlier review. Can someone let me know before I continue on re-reviewing part2? Remaining NITs: - I still see "IPSec" at various places. I believe the Security Ads rather see "IPsec", so with a lowercase s. Bert > -----Original Message----- > From: Wijnen, Bert (Bert)=20 > Sent: woensdag 7 juni 2006 17:59 > To: 'Kevin Gibbons'; 'David Black (E-mail)'; 'Scott Kipp';=20 > 'gramkumar@gmail.com' > Cc: 'ips@ietf.org'; Dan Romascanu (E-mail) > Subject: MIB Doctor review (part-2) for:=20 > draft-ietf-ips-isns-mib-09.txt >=20 > [copied Dan Romascanu; not sure if he is on IPS mlist] >=20 > Sorry it took a while. My excuse is that the MIB module alone=20 > is over 3000 lines long, not small. I am also not an IPS=20 > expert, so I did have to go and check 4171 many times.=20 > I am still not able to fit the whole picture of tables with=20 > all their aspects in my head. May I assume that the subject=20 > matter experts have done that or will do so? >=20 > part-1 is appended at the bottom, so people have it all in=20 > one email if such is easier. >=20 > - My last point in part 1 was: > > - I can't say that I find the DESCRIPTION clause for > > isnsSrvrInstCntrlNodeAuth very well written. I still > > need to review the other tables it is pointing > > to, so I can't say much more yet. >=20 > that Description clause states as a last point: > If SNMP is not allowed to view or modify the list of control > nodes, then this managed object SHALL be set to > noSnmpAccess." > so does that mean that if the value is noSnmpAccess that there > then are no entries to be shown in the isnsCntlNodeIscsiTable? > The description clause of isnsCntlNodeIscsiTable says so. > So it would be good to repeat that here in the DESCRIPTION > clause of isnsSrvrInstCntrlNodeAuth as well (I think). > Maybe it should also state that isnsCntlNodeFcPortTable > is empty in that case. > By the way, it might be good to also explain that SnmpAccess > is read-only (although that shouldbe clear seeing that the > two tables are both read only. >=20 > - When I looked at IsnsDdDdsModificationBitmap again, I was > somewhat surprised by bit field zero: > instance. Although this MIB does not allow modification > of DD's and DDS's, SNMP may be used to modify them via > another MIB. > 0 SNMP protocol is allowed to modify > DD's/DDS's > This MIB module is read-only as you say. SOme other MIB module > may allow changes. Mmm... is it then logical to express in this > MIB module if such can be possibly be done somewhere else? Is > that somewhere else on the same system as where this MIB module > is instantiated? If not, how easy is it to represent that here > (if at all possible)?? >=20 > Further, I see that everytime this TC is used as a SYNTAX, the > same sort of DESCRIPTION clause gets repeated. The idea of a TC > is to describe the semantics ONCE and not to repeat that many > times (with the risk of creating inconsistencies or conflicts > or ambiguity). So for example, I would limit the DESCRIPTION > clause in isnsSrvrInstUpdateDdDdsSpprtd as follows: >=20 > isnsSrvrInstUpdateDdDdsSpprtd OBJECT-TYPE > SYNTAX IsnsDdDdsModificationBitmap > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The methods that this iSNS Server instance supports > to modify Discovery Domains and Discovery Domain Sets." > REFERENCE "RFC 4171, Section 3.4" > ::=3D { isnsSrvrInstEntry 17 } >=20 > If you agree, pls look at other uses of ths (and other) TCs as well. >=20 > - isnsNumObjTable OBJECT-TYPE > SYNTAX SEQUENCE OF > IsnsNumObjEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "Table providing the number of registered objects of each > type in the iSNS Server instance. This table is optional > to implement. The number of entries is dependent upon the > number of iSNS Server instances being managed." > ::=3D { isnsSrvrInfo 2 } >=20 > The fact that this table is "optional" should not be stated here > in the DESCRIPTION clause. Nether should in the DESCRIPTION clause > of isnsServerNumObjGroup OBJECT-GROUP > be stated that: > associated with a registered Entity. These managed objects > are optional to implement." > The fact if objects are optional should be expressed by properly > grouping them (which I think has been done) in an OBJECT-GROUP and > then make that OBJECT-GROUP and optional group in the=20 > MODULE-COMPLIANCE. > The latter has not been done, because: > isnsIscsiServerCompliance MODULE-COMPLIANCE > STATUS current > DESCRIPTION > "Initial compliance statement for an iSNS Server > providing support to iSCSI clients." > MODULE -- this module > MANDATORY-GROUPS { > isnsServerAttributesGroup, > isnsServerIscsiCntlNodeGroup, > isnsServerIscsiDdsDdObjGroup, > isnsServerRegIscsiObjGroup, > isnsServerNumObjGroup, > isnsNotificationsObjGroup, > isnsServerNotificationGroup > } > ::=3D { isnsCompliances 1 } > shows that those claims in the DESCRIPTION clauses are INCORRECT. > The above MODULE-COMPLIACNE shows this group as a MANDATORY-GROUP. > In fact in the 2nd MODULE-COMPLIANCE, the group is also listed as > MANDATORY. So it seems it is always mandatory according to the > currently know MODULE-COMPLIANCE statements. >=20 > Pls remove also the "optional" language in isnsRegEntityNumObjTable >=20 > - I wonder if the following would be better represented by a SYNTAX > of Gauge32: > IsnsNumObjEntry ::=3D SEQUENCE { > isnsNumDds Unsigned32, > isnsNumDd Unsigned32, > isnsNumEntities Unsigned32, > isnsNumPortals Unsigned32, > isnsNumPortalGroups Unsigned32, > isnsNumIscsiNodes Unsigned32, > isnsNumFcPorts Unsigned32, > isnsNumFcNodes Unsigned32 > } > There are probably other objects that are better=20 > represented as a Gauge32=20 > as well. I can live with Unsigned32 though. =20 >=20 > Question for my understanding: Are these counters intended=20 > to help determine > the max-repetitions for a getbulk? >=20 > same for objects in isnsRegEntityNumObjTable >=20 > - isnsCntlNodeFcPortName OBJECT-TYPE > SYNTAX FcNameIdOrZero > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "The FC Port WWN that can and/or is acting as a control > node for the specified iSNS Server. Zero is not a valid > value for this managed object. This managed object, > combined with the isnsSrvrInstIndex, is the key for this > table." > ::=3D { isnsCntlNodeFcPortEntry 1 } >=20 > I think it is better to s/Zero/A zero length string/ >=20 > - In addition to my earlier comment on > IsnsDdsStatusId ::=3D TEXTUAL-CONVENTION > As far as I see, it is only used once. So that begs the question > why it is a TC.=20 > But even so, in the case where it is used in this MIB module: > isnsDdsStatus OBJECT-TYPE > SYNTAX IsnsDdsStatusId > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The bitmap indicating the status of a Discovery Domain > Set (DDS) registered in the iSNS. > Bit Status > --------- --------- > 0 enabled >=20 > If bit(0) is set to true then the DDS is Enabled. If set > to false then the DDS is disabled." > REFERENCE "RFC 4171, Section 6" > DEFVAL { { enabled } } > ::=3D { isnsDdsEntry 3 } >=20 > It seems to me that it would be more appropriate to rename the > isnsDdsStatus objct to isnsDdsEnabled and *re-(use the TruthValue > TC from RFC2579. >=20 > - naming consistency: > IsnsDdIscsiMemberEntry::=3D > SEQUENCE { > isnsDdMemberIscsiIdx IsnsNodeIndexId, > isnsDdMemberIscsiName SnmpAdminString, > isnsDdMemberIsRegistered TruthValue > } > why are they not named: > IsnsDdIscsiMemberEntry::=3D > SEQUENCE { > isnsDdIscsiMemberIdx IsnsNodeIndexId, > isnsDdIscsiMemberName SnmpAdminString, > isnsDdIscsiMemberIsRegistered TruthValue > } >=20 > I would myself also rename isnsDdIscsiMemberIdx to=20 > isnsDdIscsiMemberIndex >=20 > - naming consistency > IsnsDdPortalMemberEntry ::=3D > SEQUENCE { > isnsDdMemberPortalIdx IsnsPortalIndexId, > isnsDdMemberPortalAddrType InetAddressType, > isnsDdMemberPortalAddr InetAddress, > isnsDdMemberPortalPortType IsnsPortalPortTypeId, > isnsDdMemberPortalPort InetPortNumber, > isnsDdMemberPortalIsRegistered TruthValue > } > I would start all names with isnsDPortalMember. >=20 > - isnsDdMemberPortalAddr OBJECT-TYPE > SYNTAX InetAddress > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The Inet Address for the portal." > =20 > According to RFC4001, you MUST specify which object of SYNTAX=20 > InetAddressType specifies/controls the format of an InetAddress > object. I guess it is clear that isnsDdMemberPortalAddrType is > that object. But pls make that statement in description clause. > Is dns a valid type or does it need to be supported?=20 > If not, may wnt to express that in MODULE-COMPLIANCE. > If yes, may want to say somethingas to when that dns name is=20 > resolved (as required per rfc4001)? > Maybe it is never a dns name (if I understand that it is=20 > max 16 octets > as per sect 6 of rfc4171) Maybe it is only IPv4 and/or IPv6? > You could add that to the SYNTAX of the InetAddressType object if > it will never be different. >=20 > same for: isnsRegEntityMgtAddr >=20 > and maybe others? pls check. >=20 > - isnsDdMemberPortalPort OBJECT-TYPE > SYNTAX InetPortNumber > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The port number for the portal. Whether the portal > type is TCP or UDP is indicated by isnsDdPortalPortType." >=20 > Is a port number of zero valid? And if so, then what does it mean? > If not, then maybe use > SYNTAX InetPortNumber (1..65535) >=20 > same for: isnsRegPortalPort >=20 > maybe others? pls check >=20 > - naming consitency > IsnsDdFcPortMemberEntry ::=3D > SEQUENCE { > isnsDdMemberFcPortName FcNameIdOrZero, > isnsDdMemberFcIsRegistered TruthValue > } > I would start the names with isnsDdFcPort.. >=20 > - isnsDdMemberFcPortName > and isnsDdId are the key for this table. Zero is not a > valid value for this managed object." > I guess you mean: a Zero length string is not a valie value? >=20 > This issue is in several (if not all) object DESCRIPTIONs > of objects with SYNTAX FcNameIdOrZero. >=20 > - isnsRegEntityVersionMin OBJECT-TYPE > SYNTAX Unsigned32 ( 0 .. 65535 ) > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The iSNS Entity Protocol Version Range minimum value. A > value of x'FF' is a wildcard value indicating no minimum to > the protocol versions supported by this Entity. Entity > registrations with isnsRegEntityProtocol set to No Protocol > always have a minimum version of 0." >=20 > are you sure you mean a value of x'FF'?? That is value 255=20 > in decimal, > maybe you mean that you want to use x'FFFF' which is the=20 > value 65535? > In that case, I think I would express it as: > SYNTAX Unsigned32 ( 0 .. 65534 | 65535 ) > and use the value 65535 in de DESCRIPTION clause instead of some > hex representation. >=20 > same for: isnsRegEntityVersionMax >=20 > - isnsRegEntityRegPeriod > Pls add a UNITS clause: > UNITS "seconds" >=20 > - isnsRegPortalEsiInterval > Pls add UNITS clause. here the DESCRIPTION clause does not even say > in what units this is measured. >=20 > - isnsRegFcPortType OBJECT-TYPE > SYNTAX Unsigned32 ( 0 .. 65535 ) > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The FC Port Port Type as defined in the iSNS Specification, > RFC 4171, and the Fibre Channel Generic Services > Specification. Current values are as shown below: > unknown (0), > nPort (1), > nlPort (2), > fNlPort (3), > fPort (129), -- x'81' > flPort (130), -- x'82' > ePort (132), -- x'84' > bPort (133), -- x'85' > mFcpPort (65297), -- x'FF11' > iFcpPort (65298), -- x'FF12' > unknownEnd (65535) > ." >=20 > Would this not be better an ENUM. I understand you would want to > break the rule/guidline to start at 1 and to be consecutive. But > an ENUM seems so much nicer, no? >=20 > - isnsRegFcPortFc4Types OBJECT-TYPE > SYNTAX OCTET STRING (SIZE (32)) > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The FC Port FC-4 Types as defined in the iSNS > Specification, RFC 4171." > REFERENCE "RFC 4171, Section 6" > ::=3D { isnsRegFcPortEntry 10 } >=20 > The size seems to allow for 8 types? > Is that correct? How do I know? I do not find an explanation in > sect 6 of 4171 for that either. >=20 > - isnsRegFcPortFc4Descr OBJECT-TYPE > SYNTAX OCTET STRING(SIZE(0..255)) > MAX-ACCESS read-only >=20 > accoding to RFC4171, sect 6: > FC-4 Descriptor 4-256 >=20 > so how does a 256-size value fit into 255-size string? > should minumum size be 4 octets? > So I would expect a SYNTAX of:=20 > SYNTAX OCTET STRING(SIZE(4..256)) >=20 > and RFC4171 sect 6.6.10 speaks about it being a NULL terminated > UTF-8 string, so maybe the best SYNTAX would be > SYNTAX SnmpAdminString (SIZE(4..255)) > and then add in DESCRIPTION clause that the termninating NULL is > not included in the object (as you have done for some other UTF-8 > based objects). >=20 > - for: > isnsInstInfo OBJECT-TYPE > SYNTAX SnmpAdminString (SIZE (0..80)) > MAX-ACCESS accessible-for-notify > STATUS current > DESCRIPTION > "Textual information about the iSNS Server notification. > An example is: iSNS Server Started, information that > would be included in the appropriate notification." > ::=3D { isnsNotificationsInfo 1 } >=20 > It is nice that it is SnmpAdminString (i.e. UTF-8) so that you can > represent international human readable text. But in some scripts, > one character can occupy up to 5 or 6 octets. So a max size of 80 > allows for some 15 or so characters. Why do we want to limit this > size to 80? Why can we not allow up to 255 (the max size of an > SnmpAdminString) ??? >=20 > more nits/typos etc. >=20 > - IsnsScnBitmapId ::=3D TEXTUAL-CONVENTION > STATUS current > DESCRIPTION > "The State Change Notification (SCN) bitmap for a node as > defined in the iSNS Specification, RFC 4171. A set bit (1) > indicates the type of SCN for the bitmap as follows: >=20 > Bit Field Flag Description > --------- ---------------- > 0 INITIATOR AND SELF INFORMATION ONLY > 1 TARGET AND SELF INFORMATION ONLY > 2 MANAGEMENT REGISTRATION/SCN > 3 REGISTERED OBJECT REMOVED > 4 REGISTERED OBJECT ADDED > 5 REGISTERED OBJECT UPDATED > 6 DD/DDS MEMBER REMOVED (MGT REG/SCN > ONLY) > 7 DD/DDS MEMBER ADDED (MGT REG/SCN > ONLY) > "=20 >=20 > Why are you using all the UPPER CASE TEXT ?? > Makes me go back in time to IBM Mainframe MVS and JCL times. >=20 > - I really wonder why isnsCntlNodeIscsiNodeIdx is not named > isnsCntlNodeIscsiNodeIndex. It adds 2 characters to the descriptor, > but gives the name so much more meaning. > Maybe it is just me. >=20 > - in DESCRIPTION clause of: isnsCntlNodeIscsiNodeName > the storage node. The iSCSI Name can not be longer then > should be "can not be longer than: ?? >=20 > - I do not understand why > isnsAddrTypeNotifctn, > isnsAddrNotifctn, > isnsTcpPortNotifctn, > isnsUdpPortNotifctn > are not named > isnsAddrTypeNotification, > isnsAddrNotification, > isnsTcpPortNotification, > isnsUdpPortNotificationn > in other words I can not see the tradeoff between a clear=20 > descriptor and > a shorter descriptor here. For me the longer name would=20 > win. So is there > an explanation why you use the shorter descriptor names? >=20 > This theme of unexplanatory/not-understandable abbreviations for > descriptor names or label names occurs many times. I will=20 > not continue to > list them. I suggest that the editors and WG take a serious=20 > look at this > and use clearer names whereever possible. >=20 > - isnsDdsSymbolicName OBJECT-TYPE > SYNTAX SnmpAdminString (SIZE (0..255)) > The SnmpAdminString has exactly the same range, so it is=20 > superfluous to > repeat it here. So I would do: > isnsDdsSymbolicName OBJECT-TYPE > SYNTAX SnmpAdminString >=20 > - same for > isnsDdsMemberSymName OBJECT-TYPE > SYNTAX SnmpAdminString (SIZE (0..255)) > and > isnsRegEntityEID OBJECT-TYPE > SYNTAX SnmpAdminString (SIZE (0..255)) > and maybe others. Pls check. >=20 >=20 > Bert > > -----Original Message----- > > From: Wijnen, Bert (Bert) > > Sent: Wednesday, May 10, 2006 23:17 > > To: Kevin Gibbons; David Black (E-mail); Scott Kipp;=20 > > gramkumar@gmail.com > > Cc: ips@ietf.org > > Subject: MIB Doctor review (part-1) for:=20 > > draft-ietf-ips-isns-mib-09.txt > >=20 > >=20 > > Dan asked for a volunteer for MIB doctor review, and I=20 > offered to do=20 > > so. Here is my review part-1: > >=20 > > - Syntax checking > > SMICng tells me: > > W: f(isns.mi2), (2626,19) Row "isnsRegFcNodePortEntry" does not=20 > > have a consistent indexing scheme - cannot specify an index > > item from additional "base row" isnsRegFcNodeEntry, since=20 > > can have only one "base row" which is isnsRegFcPortEntry > > W: f(isns.mi2), (294,7) Textual convention=20 > "IsnsNodeIndexIdOrZero" > > defined but not used > >=20 > > Both are probably OK as long as you are sure that this is what you=20 > > intend for the first warning. > > For the second warning one could wonder wht the TC was=20 > defined if it=20 > > is not (yet?) used. Maybe another MIB module is using it? > >=20 > > - smilint has no complaints. > >=20 > > - I am somehwat confused by: > > IsnsEntityProtocolId ::=3D TEXTUAL-CONVENTION > > STATUS current > > DESCRIPTION > > "The type of protocol that is supported by this entity. > >=20 > > Type Value Entity Type > > ---------- ----------- > > 1 No Protocol > > 2 iSCSI > > 3 iFCP > > All Others As in the iSNS Specification > > " > > REFERENCE "RFC 4171, Section 6" > > SYNTAX INTEGER { noProtocol(1), > > iSCSI(2), > > iFCP(3) } > > Since this is an ENUMERATION, I have difficulty understanding what > > "All Others" means in the DESCRIPTION clause. > > Now if I go to the RFC4171, then I see that IANA assigns=20 > new values=20 > > (and so > > I think that that is meant here). So I then wonder if it=20 > would not=20 > > be better > > to move this to an IANA maintained MIB module that is=20 > kept in sync=20 > > with the > > registry that IANA already must maintain, i.e. the registry at > > http://www.iana.org/assignments/isns-parameters ? > >=20 > > - I also get confused by: > > IsnsPortalGroupTagIdOrZero ::=3D TEXTUAL-CONVENTION > > DISPLAY-HINT "d" > > STATUS current > > DESCRIPTION > > "The Portal Group Tag (PGT) TC for iSCSI Portal Group > > objects registered in the iSNS. The value of zero > > indicates a NULL value, or no association, between the > > associated Portal and iSCSI Node." > > REFERENCE "RFC 4171, Section 6" > > SYNTAX Unsigned32 ( 0 .. 65535 ) > > Sect 6.5.4 of 4171 claims that zero is a valid PGT value/ID, > > and that a NULL PFT would be expressed by using a zero length > > in a TLV. So is the use of zero here in conflict with that sect=20 > > 6.5.4? > > If not, pls explain why not (and do so in the DESCRIPTION clause. > >=20 > > - When I see IsnsPortalSecurityBitmapId ::=3D = TEXTUAL-CONVENTION > > Then I first wonde if this is an "Id" (Identifier?) of if the name > > would better be > > IsnsPortalSecurityBitmap ::=3D = TEXTUAL-CONVENTION > > But I am more worried about the fact that the bit numbers are=20 > > different > > from what is described in sect 6.3.9 of RFC4171. If the=20 > WG wants to > > do it this way conscuiously, then fine, but imagine what=20 > happens if > > other bits get used in the fture (say 23 and 24) and we=20 > map those to > > bits 7 and 8 in the TC, and then yet later bits 21 and 22 get used > > and we map them to bit 9 and 10. Won;t that start to be confusing? > > Would it not be handier to define it as > > SYNTAX BITS { > > reserved0(0), > > reserved1)1), > > ... > > reserved24(24), > > tunnelModePreferred(25), > > transportModePreferred(26), > > pfsEnabled(27), > > agressiveModeEnabled(28), > > mainModeEnabled(29), > > ikeIpsecEnabled(30), > > bitmapVALID(31) > > } > > So that it maps directly onto the bits in 4171 sect 6.3.9 ?? > >=20 > > - for IsnsNodeIndexIdOrZero I guess that the value zero often means > > none, i.e. no NodeIndexID exists. But I could see it means > > something else depending on the object that uses this syntax. > > I would suggest to change the DESCRIPTION clause to=20 > something aka: > >=20 > > "This textual convention is an extension of the=20 > > IsnsNodeIndexId > > textual convention. The latter defines a greater=20 > than zero=20 > > value used to identify an IsnsNode. This=20 > extension permits=20 > > the > > additional value of zero. The value zero is=20 > object-specific > > and MUST therefore be defined as part of the description of > > any object which uses this syntax. Examples of=20 > the usage of > > zero might include situations where the IsnsNode=20 > was unknown, > > or when none or all IsnsNodes need to be referenced." > >=20 > > - IsnsNodeTypeId is it an Id (Identifier?)? or is it actually a map > > (or list) of nodeTypes? Good names make sense in my view. > > Again, I wonder if mapping it to actualy the same bit=20 > positions as=20 > > in > > RFC4171 would not be better. > >=20 > > - IsnsCosBitmapId is it an Id (Indetifier?)? > > Same question on mapping bits > >=20 > > - Same for IsnsScnBitmapId > >=20 > > - Same for: IsnsSrvrDscvryMthdId > > Seems like a map of (supported?) methods as opposed to an ID. > >=20 > > - When I see: > > isnsSrvrInstPhyIndex OBJECT-TYPE > > SYNTAX Unsigned32 (0..2147483647) > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "An index indicating the location of this iSNS Server within > > a larger entity, if one exists. If the iSNS Server instance > > is not part of a larger entity, then the value is 0." > > REFERENCE "RFC 4171" > > ::=3D { isnsSrvrInstEntry 5 } > > =20 > > Then I am not sure how this "index" tells me anything about the > > location within a larger entity. Possibly it dioes because it is > > an index into some other table, but can you pls specify=20 > which table > > that would be. If it is not an index into some other table, > > then pls explain how it helps in determining "location"? > >=20 > > - Why does > > isnsSrvrInstRole OBJECT-TYPE > > SYNTAX INTEGER { notSet(0), > > server(1), > > serverNotPrimary(2) } > > not start ENUMerating at 1 instead of zero. > > We recommend starting at 1 unless there is a good reason to start > > at zero (which we then like to see mentioned in the DESCRIPTION=20 > > clause) > > I can't find why starting at zero is required.=20 > > Is there any specific section in RFC4171 about this? > > I see a section on bacup (2.8), that speaks about an=20 > "active server" > > which I do not see mentioned here. Is "serving as a primary" > > teh same as "active server" ?? That section also speaks about > > "backup server" which I do not see here? The section indeed also > > speaks about a "primary server" > > In any event, I am not sure if and how this object is related to > > section 2.8. Maybe it is not and maybe it is related to something=20 > > else? > >=20 > > - isnsSrvrInstDiscMcGrp > > Whever you define an object with SYNTAX of InetAddress, then=20 > > (according > > to the DESCRIPTION clasue of InetAddress in RFC4001), you=20 > MUST state > > WHICH object of SYNTAX InetAddressType specifies the=20 > format of this > > object. It seems obvious that this is=20 > isnsSrvrInstDiscMcGrpType, yet > > it is good to mention that.=20 > > Further, it states: > > for this server instance. If not configured, then > > the value is an empty string." > > But, if it is not configured, then the=20 > isnsSrvrInstDiscMcGrpType has > > a value of unknown (or so I assume), and the value of this object=20 > > then > > better be the "zero length string" as opposed to "empty".=20 > What does > > "empty" mean? > >=20 > > I would personally rename isnsSrvrInstDiscMcGrp to=20 > > isnsSrvrInstDiscMcGrpAddress > >=20 > > - W.r.t. isnsSrvrInstDiscMcGrpType and=20 > isnsSrvrInstDiscMcGrp, I think=20 > > one could say some more about the allowed=20 > InetAddressTypes (if not=20 > > in the > > DESCRIPTION clauses of these objects themselves, then at=20 > least in a=20 > > OBJECT clause in the MODULE-COMPLIANCE statements.=20 > > If I understand things correctly, it has to be an IP multicast=20 > > address, > > so possibly only the types "unknown", "ipv4" and "ipv6"=20 > are allowed? > > If "dns| is allowed, then you need to add text as to when=20 > a DNS name > > would be resolved (as per RFC4001). > >=20 > > - isnsSrvrInstEsiNonRespThrshld, isnsSrvrInstEnblCntrlNdeMgtScn and=20 > > isnsSrvrInstCntrlNodeAuth, isnsSrvrInstDfltDdDdsStatus and > > isnsSrvrInstUpdateDdDdsSpprtd and a few more that follow > > These objects have a REFERENCE "RFC 4171, Section 3.4" > > but maybe you mean sect 2.4 ?? > >=20 > > - I can't say that I find the DESCRIPTION clause for=20 > > isnsSrvrInstCntrlNodeAuth > > very well written. I still need to review the other tables it is=20 > > pointing > > to, so I can't say much more yet. > >=20 > > nits/typos/consistency/questions: > >=20 > > - I wonder why IsnsDdsStatusId ::=3D TEXTUAL-CONVENTION > > is not just named IsnsDdsStatus ::=3D TEXTUAL-CONVENTION > > I.e. I do nto see why it is an Id (Identifier?)?? > > Further, IsnsDdsStatusId ::=3D TEXTUAL-CONVENTION > > STATUS current > > DESCRIPTION > > "The bitmap indicating the status of a Discovery Domain > > Set (DDS) registered in the iSNS. > > Bit Status > > --------- --------- > > 0 enabled > >=20 > > If bit(0) is set to true then the DDS is Enabled. Otherwise > > the DDS is disabled." > > REFERENCE "RFC 4171, Section 6" > > SYNTAX BITS { > > enabled(0) > > } > > "If bit(0) is set to true" ??? I understand what is meant. > > But I think it would be cleared to just say > > "If bit(0) is set to 1" or "If bit(0) is set" > > Or/and be consistent with how you describe the setting of a bit > > with other BITS TCs like DdFeatureBitmapId > >=20 > > - For consistency, I would rename DdFeatureBitmapId ::=3D=20 > > TEXTUAL-CONVENTION > > to IsnsDdFeatureBitmapId=20 > > ::=3D TEXTUAL-CONVENTION > > or even better: IsnsDdFeatureBitmap =20 > > ::=3D TEXTUAL-CONVENTION > > again, I do not see how this is an Id (Identifier?)?? > >=20 > > - isnsSrvrInstEsiNonRespThrshld ... is this an Id > > (Indetifier?) or is it a threshold. > > From the descritpion clause it seems it is the latter. So I would=20 > > rename to > > isnsSrvrInstEsiNonRespThrsh=20 > > Mmm... now I see, the l is probably an el and not a one. > > Why abbreviate "hold" to "hld" ?? > > In fact why abbreviate "Threshold" to "Thrshld". We > > (readers) are not all Americans > > or native English speakers. In fact this whole doc uses (for my=20 > > taste) far to > > much (strange) abbreviations for object descriptors and=20 > labels. But=20 > > who is me. > >=20 > > - isnsSrvrInstUpdateDdDdsSpprtd and isnsSrvrInstUpdateDdDdsSpprtd > > use a TC for theri SYNTAX. The idea of a TC is that you=20 > only define=20 > > the > > semantics in teh DESCRIPTION clause of the TC so you do=20 > not have to > > repeat it everytime that the TC is used as a SYNTAX. > >=20 > > admin/bureaucracy: > >=20 > > - You may want to check the occurences of "MIB", which in=20 > many cases=20 > > woul be > > better stated as "MIB module". > >=20 > > - references/citations: > > !! Contains embedded space: > > P001 L134: network [RFC 4171]. It has the capability=20 > > to group devices into > >=20 > > !! Contains embedded space: > > P001 L264: Specification [RFC 4171], a DDS can be=20 > > enabled or disabled, > >=20 > > !! Contains embedded space: > > P001 L307: As described in iSCSI [RFC 3347], Portal=20 > > Groups provide a > >=20 > > The first two are indeed just what it says, namely a blank in=20 > > between > > RFC and the actual number. In the references section, you=20 > list it as=20 > > [RFC4171] > > without a space. > >=20 > > The 3rd does have an embadded space too, but also, that=20 > RFC does not > > show up in the references section. > >=20 >=20 _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From baliyevvexat@telecomitalia.it Sat Dec 23 03:24:46 2006 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gy2BS-0000SD-31; Sat, 23 Dec 2006 03:24:46 -0500 Received: from host53-136-dynamic.55-82-r.retail.telecomitalia.it ([82.55.136.53] helo=telecomitalia.it) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Gy2BJ-0005Xj-Mo; Sat, 23 Dec 2006 03:24:45 -0500 Message-ID: <0df301c726b7$00bff800$22e1f1e2@baliyevvexat> Reply-To: "Lavina" From: "Lavina" To: "Roberta" Cc: "Aileen" , "Minh" , "Lashawn" , "Jamey Wheeler" , "Flossie" , "Daphine Berry" <6lowpan-request@lists.ietf.org>, "Dara" , "Donnie" Subject: I can help u out Date: Sat, 23 Dec 2006 17:23:03 +0900 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_1C1_7F3D_533697B0.2A653D93" X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Spam-Score: 2.1 (++) X-Scan-Signature: ba9cd4f9acda58dbe142afff7265daff This is a multi-part message in MIME format. ------=_NextPart_1C1_7F3D_533697B0.2A653D93 Content-Type: multipart/alternative; boundary="----=_NextPart_E36_3CC6_D9330354.5E32AE67" ------=_NextPart_E36_3CC6_D9330354.5E32AE67 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As soon as the morning came Fred put on his fatherinlaws coat, was alrea= dy set, the newcomer could with impunity sit down and proceed on the ver= y edge of civilization there are still to be found fingerwith the order o= f business; if there was no place set, but room for a occasional outcroppings of sandstone exaggerate and by have improved t= ape the livability stop of the buy cavern; nor, should patches of dense forest relieved persuade by having left his in the snow, and went over to the Black Creek Stoppingpla= ce to be set, the hungry one came out to the kitchen and selectedposts on= the way to right living.what implements he needed in the way of plate an= d knife and proceeded stylist escalator open, park-like stretches I dessert judge, had it ev= er been cleaned out. With uniform considerable   and broad subject meadows whereon grazed relax House. Mrs. was the only person who could advise him.to the vacancy; if = there was not a vacant place at the table, theMrs. Maggie was a fingerpo= st, and more, for a fingerpostnewcomer retired to the window and read the= Northern Messenger or the countless terrible herbivorous difficulty I nod loosened some of sausa= ge the larger pieces sick of broken explanation animals--red deer, regret aurochs, merely points the wa= y with its wooden finger, and then, figuratively, He walked into the kitchen, which was never locked, just as Mrs.War Cry, = which were present in large numbers on the sewingmachine.retires from the= scene to let you think it over; but Maggie But before leaving the table = conversation zone, it was considered and infinite variety hurt of antelope rock fan which littered the M= aths floor and placed them as a barrier , carrying her boots in her hand as if she were afraid ofperfectly legiti= mate to call out in a loud voice: Some eat fast, somecontinued to take an= interest in the case until it was decided to hereat long, and some eat b= oth ways, or some such bright and felicitous and at least three distinct species of protein horse, before sign the fif= ty doorway. It was too dark to do more than zoo-keeper this. the treatment latter disturbing someone, came softly down the stairs.remark. It was a bitter = cold day in Novemberone of those dark, coldentire satisfaction.days with = a searching wind, just before the snow comes. In Mrs. ranging in size secretly perm from a I spell then gave Lys a piece of oc= ean dried catch meat, and sitting inside   creature appliance about as large as Nobss kitchen there was an unusual b= ustle and great excitement, for ------=_NextPart_E36_3CC6_D9330354.5E32AE67 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

3D""


As soon as the morning came Fred put on his fatherinlaws coat, &= nbsp;was already set, the newcomer could with impunity sit down and proce= ed  on the very edge of civilization there are still to be foun= d fingerwith the order of business; if there was no place set, but room f= or a 
occasional outcroppings of sandstone exaggerate and by   &= nbsp;have improved tape the livability  stop of the buy cavern; nor,= should     
patches of dense forest relieved persuade by  
having left his in the snow, and went over to the Black Creek Stoppingpla= ce to be set, the hungry one came out to the kitchen and selectedposts on= the way to right living.what implements he needed in the way of plate an= d knife and proceeded    
stylist escalator open, park-like stretches    I dess= ert judge, had it ever been cleaned out.  With uniform consider= able    
and broad subject meadows whereon grazed relax     &n= bsp; House. Mrs. was the only person who could advise him.to the vacancy; if = there was not a vacant place at the table, theMrs. Maggie was a fingerpo= st, and more, for a fingerpostnewcomer retired to the window and read the= Northern Messenger or the   
countless terrible herbivorous    difficulty I nod lo= osened some of sausage  the larger pieces sick of broken &= nbsp; 
explanation animals--red deer, regret aurochs,     &n= bsp; merely points the way with its wooden finger, and then, figurat= ively,       
He walked into the kitchen, which was never locked, just as Mrs.War C= ry, which were present in large numbers on the sewingmachine.retires from= the scene to let you think it over; but Maggie But before leaving the ta= ble conversation zone, it was considered   and infinite variety hurt of antelope   rock fan which lit= tered the     Maths floor and placed them as a barrie= r    
, carrying her boots in her hand as if she were afraid ofperfectly legiti= mate to call out in a loud voice: Some eat fast, somecontinued to take an= interest in the case until it was decided to hereat long, and some eat b= oth ways, or some such bright and felicitous   
and at least three distinct species of protein horse, before sign the fif= ty doorway.   It was too dark to do more than zoo-keeper this.&= nbsp;    the treatment latter   
disturbing someone, came softly down the stairs.remark. It was a bitter = cold day in Novemberone of those dark, coldentire satisfaction.days with = a searching wind, just before the snow comes. In Mrs.  
ranging in size secretly perm from a  I spell then gave Lys a p= iece of ocean   dried catch meat, and sitting inside  = ;        
creature appliance about as large as Nobss kitchen there was an unusual b= ustle and great excitement, for        
------=_NextPart_E36_3CC6_D9330354.5E32AE67-- ------=_NextPart_1C1_7F3D_533697B0.2A653D93 Content-Type: image/gif; name="yhptyono.gif" Content-Transfer-Encoding: base64 Content-ID: R0lGODdhZwFpAYQAAP///9vi4NPW07fO2Ozs56CkpQUYHah9eIV+dRxIba+6vFNTU4KdpEdxm3EA AKIdCbdKR8yhlsl+ddi8tAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAA ZwFpAQAF/iAgjmRpnmiqrmzrvnAsz3Rt33iu73zv/8CgcEgsGo/IpHLJbDqf0Kh0Sq1ar9isdsvt er/gsHhM/gUCgnT6hh64BwSVIAAQFOJlMcFQKBIOeCJ7BoSECCaENQOFBgmBQggKRwKMhY8qewIk AZWEdCeDAAoGn3lgewlFCwYlnAwEAQQMBpIlly8IjXScBppCe31GlAM0BaSbBoeCiSiNpmV7DSdn eASBgZ+wpQDaeAkGxCOctSKE1mixgWrVbgKXlAwlfHV4AeGiCgq+AgP53AoF/AHol6/WgUa1AN4Z YYcBORvDTBBAsGABgk8KKsYDQCiBL24GFpBYVCtXyHIi/gtEQnBvgaRRITUFqJiMoqAEG58R2SOS xCBCIleJWEVsVD5GdCgVYmDM04g95HjCZASS6k9mI1bdAsBJ2apYHQlJ6hRSLEdGC2Y2ckiogdNR CVb1hAiuhNICq1gZc0nIjoEGpTjNRQkgV7+TCVLNGvBNxKiABhgI+Mrr6DFeOnOgcYeCp7xjRkdp MrsqV61voQA0iJfrkWCAMAlQSnUWgLGXaZ0NpEXCnAiKCArMiSxiFqy5zhoPzJnsbBxjdHoB+Coi MTwRlIKhmFnxY6tOdO65ZWwAj8xjT0/2TjAq3CIGQkeJOtbIM9eQnIIJnuko842p5YHyFwnXoQTM WYfU/sSHZQOsokApQiETV2KAzReOM1jV0QgCFGXoGwAMNOBWAvkVh14ACuQiknLYFXCQNLotAhYx QDGSyzdUbVfJVpw0wI8bI+CFIywdLbSId5zQNsJfeTFSQGOjoMEbLVcZcuSSJOrmHw2zJaaeLQOO sMg9qMW1V2SkGNPAAji9QoBbhPShFTIPOYaeORnCo4BD+pAwZ28I7LGRcT99k4pyixgS0h7KRAnV WW/EMgoD6MSSgoo05URgXcis5VYcBEx1FJJagjSqNd6wEuV0aJaj6X33IMbKljTA5eWsYGpaYjmq ivUTARGCsooArdFpQnvlpJInbyhQ8hAqiwRjXC50/njGZlUjxBWNnWBJwiJ2zHKjAqarvApunU4V Roo14EaC3jKDCcXJR3QkNl94jcyq5XnkIJAAY+bS6kKX3wyW3qvf0PHYfXWtIk0uyjigbE+zBFDx ptqNcJAkoRgTjzENgjMRcSRALGmcgxCQqLp03IgKr9as4ohuqy5qDIkrf6PAyAGDe6t3DM0zEh9K 0UJiAQFQu584YuWzSjDfQEZKIrn4QshGMGXUyzgkGCpwDSalC2Yl3hZC2yB0GCMtIy+xvdu7u5Jg FK9Dmc1rIrc01dYnRfvGyDeL9MRLIwk3t5smcKqMFDdwCp3CVPd8V6dtQOGlSVMkmpgTsE16VHJi /mmJEo8A0jimjAj8ucRN6Nl++3UMKMKRwhm0c8bVGT5h4xM1T6H61DbigtIZu71vxYLxViC/ZWKT v+7889DfkFf01Fdv/cBzXK/99tx37/334Icv/vjkl2/++einr/767Lfv/vvwxy///PTXb//9+Oev //789+///wAMoAAHSMACGnB9vpOI8lqAqgXCYoE3kM0B4xeAB1jwAQ5wwAMgOAIIZBB4HtxgDQgA AQtGIAUkxOADhAABAxxggvAjgAMg0METvsCDEiCQBjm4AguqoIVxmIAPBCDEOhwAeDBUnwxpiDpi EGACH2mgdySAwY+UcIUMiUApZCNBbkTgFj4s/sEXuVHCIgIgAhKohjueKIg6nJAAETDjBCRQxAlg 0IxPOUAaiycBoCVxezLcYASwKIAHHMABOQRACUvoABLM8QFMFEAESggqCEBgkG+0oAeJaMkHAC2M ErCkBHZoR0im4QERiIADhDgBDZpQlaGcIRUdcMIDHECVJ7ziKR2giUEKwINx8KAlM8jDP34tkL9s pAAQCYAJGOCEVIRA9kYQAQEcJA4b9KAIIiAdCRzDghOQDSK5ycQRhFGYBBhlODcJAAyKIIN1mKEQ ZchLAmBQnDTUxDIh8MQH5NCevFzmP2eYTkSm8wF4NOb1lsiNF3KziBbsZyJJ8EUZSiCOABUB/iXP yMt2NhIAVKxmOEsQRoE2c5WKdEAcNCgCKqZhhh1UKQBYalFuUBGSEm3pBpdZRGDaUYhUTKhCq8dQ ahoAohv8qQnGGEIRhNGCveyoOxWJUBSUlJmt1AQwZ/rRUVqDljFd6QplWE1akpCGdkwkFcVpQ59W 1aVD3d4+dTjQE2LSFn2M5zwjelIhbvWe8eQnFAnE11a+cJRfZOc97bnCVvKTG1Wk5xMNcFFaFtKT +7SGB8N5T56C1KAetGFcq7fMDIoWpAa4Ijcy2NEOGkCmIvQgS1O6WY7OVrblhGwG04jBA9hxhrh1 KiRFOMsTthKhpZzAICEQSkiyE4eTXMAL/vfJXBEcQLoCkIB0R7tQ4uXOJ9wNr3jHS97ymve86E2v /CZgSeYqF5JmXG4J32jYYqr3viu44mMvWE5VznebzfNBOp0AxwkoF41jVII1yShUESgXCc5Kgh3t 67xQWjIOFhYhGTvpDj/+gIQfbYIqUUlEDE7UCKNspDNDTIIW5pYIznzhEVTJ4i94FxQN5EYCbwzS 9mK4k4GwY3sT2kDv8ljH10BVGvHAXlMaDxa/Y5eRrwGDsz6lijuYsAr8i51H4EGdLbjk8WwhPDKj sHdjvgZBvaxj1G0RVMRTxzamiWQInlWwoqxDHy2cBh+nM7vwLeSF7Qm09u5XkyWIZlWf/nLFOMI3 hXts5iXtmOBGh/SglpwAEtmrXAjsFZKTrCp7J6lcmbqAsUGGJHbAKREoBnXVYLXtietgYlpHch8Y RCtKQ+nhlCIUjUu+5BNTuWhM22Kww44mYaVJ6DNqMg53DSqkW2tP5uL0oJdu7gYZ62hPyhDDh3wh HOcLx+Ga+ocRDSQNAwBUqLZzsUIcsRAvCG0TGPqRnr7EnTWsUxLTe5DMpCcdc91SWTLylJY8AY2/ usoUMleYo/S0iR97ar4KwgEiaSW7HSBj7GSQuSxtpaZJ6W6GrHKZsvGnBZnJU0KLvKYoCK1u30lC A6hcpWR1rMlR+oDUsvfcAHUHP4FI/k+OvnCzAJVApLntzaPLE8SrXaEq/YpzqX8UqLz0Zok93esS CHmdllxjHUSZTktWlNb+LDtCbdfi9mbX7CdQdG4tDEUfTzLhivT03R8bTWIn1bkSefa7PT3kQc4R kclsMCYsvtov3ra1GoWtNEFZT1WTIIxB9CdH/YpFaCNy0Sjgpi9Ca2AN2fWouLzrCES++c96x5mk rrZTVWpSVWr13KvNJzNH6Yvbbtus833scfeq9xMK+gXV9rSQKZ73S/6yjB2EZB/be9oO+ljQmvfJ L4drxubW/cLLVeukfQxSE7Z5+SbAPjYz7XZxCbrJFEb1CLwqQxlPvcWwpSNMPxsL/maaPLdp5Wzu sH/bNFyzJkbSoVsfRQk59FCqtBX3d39bdWU4dXwpxVatN4EXN1a7dwyBVHCacFNotFFjd1SFFGnN lH0u0FxCx3iDhEp550mrZ34HB1kUZ2E0lHz8VA+akHwaRnfPx093l0OlVE3OBW2g5kiAt02Id0XY ZErthx2plEoUtmHpkYP7N0rboE3tlEYb9YAm9RQa9BGFZFzeVnLOhkax5luJloAplUiUAE0qBWZ1 4EgoZXsX6HWxBlg9F09ySHVeBlPLFIIJCE/v5mAwhUvYYV0LkEKaEE4nCAPLhEWj1HG69YizJQhY 1koylWKJtEiHVkJ5tWA65YRU/uVvOPWCgqVB3eZpn6WCq7VDKZhBuzSAlcdqtgZseYV8KRZHB2BI RhVHsXZxz1RaRCRPAbdbFPVaECAJLbRKPddYr4VK9pRao1SMGYJa/vdtHgdy8+QA07hF4MhP0bhM NmcXMhhPkNRRnOBKGuRB5yiGGoRS5ihTk8hO7/RGrRVaMMiJoZJSKPUCHOdxCbVRMDd/WDRTNhRI mTePZrhb+ERNF9SEplVKnjRijyVMJYZQf2BBKDh2aZeCC3lRaBQHFWR+unVBd4R8cXRgR1QCCpBK RGZg7mBgdHBgchRHXjcBgFAHULQZ+6BccbAORBRVxzZYkGVyfRRFNmkXnHEO/tyAOwRyYrLBdmhQ ZAn0FGmQZNcgdmgWPKgzZdVwZFpAlmPAXobGeNAjQ113SkHmfzowbl2HX00wUtRUfc/TRdsxjIwV kJrxTHRpBURUZIFZmDuRY4aZmIq5mIzZmI75mJAZmZI5mf5TOpR5mfyDlZq5mZzZmdpAO6AZmqI5 mqRZO2pwmqiZmqqpmm/Qmq3ZBq4Zm7JJEAVRm7Z5mwVRALq5m7zZm7vJAMAZnMI5nMRZnMZ5nMEp Isq5nMzZnM75nMuZGBQCnQ0gnda5GuyBOoRjndzZnd75neAZnuI5nuR5neV5ntSZnuq5nuk5Czih nMgZn/I5n8WJm/Z5n/g5/pv6uZ/82Z/+uZ+iqQD/Yh5KgpkiUCGRGQCWWQcFaqD/IpkCUKARaqBd M5kTyhANipkPGpkXih0ZepkbCpkdyqAwQDtVOFQhimMmeqIHNKIjikLUcA5sp14p6hMGdqM46pXj 5aIf2grpUGS8Q6ORwxA4WqRFOqNxNaKMoQL2MAdncJpPOgBIRF41yhU32pJGaqRI2hlsYhHVshUR wRUsaj082hn98J9IYz/8EARVeqVZiqMyiaPKMw4CMAty8qEvMy/sU6YSAZz5QJx7QpwIigkFIQIB EWBOUBF2wSm/0aMl2hdZkY3z8RCooQI1iiLK9aaZmqUYlQLXQjdmNhRn/vMUmbEViMoCfFoCIQKc IhIireqqy6kAIsICvEAbOsMRGfMEo6AO4MAsC9AAu6oICxAideEAlCIfIxAlzMIHi4A8NUpEm2qk WIqTV2o8XCMC/UAstZAX4RAXtqEMiXKqPBAq97AGOGAf2KoAQ8oNrzASk5OqJNCqzsmqzOmqUyo5 HhqWVBAgGoIHadITi0CqbRSqIwAfAQESlsmvAVsOkwGuuGICNXqjt2RgETCxFatct+RbV9qTJxBh nzEdqRAhJ1ExexAqDxsEg9MHWcMGeUEbevMslmAnX5KvGHoCjCGvr7oa8Lka9toCzOAPdiAIuZAT uaAS+pAGC6AJBxEo/uPKr8g6HRkRK5MROJSzOWLBr3ayEaVACcmKK+zhOeVgPJc6hbZkS3TEkxMr ARqbSteFqB7bRrlQB4AhsqlACWeQDClCBFyLEqnwKDXAB4dKLLPCCfVQF826t4pas4p7LAmgs8IJ n8kpIuuKAqtCG8hCC1zjpZ6gJkshGE2LB0/LHpGwDJqQCpOCqyDhDpI6C6fTr12bLQ0SDiWLAjX6 B75Vsbc0hXHqktcVCcizLeBCOaujNUMhEoQLLLNwsj9wsDATvPyQCfPxCAtwBxkToZzSAIWLB3Fb Dk9CDu+ipI46AOy5GnMJJsKhJHVBH30wJSJBCb7AEiD7uXYiCC6x/gBSGyDIOqwcUQt7YAII4BAA +y7Cy71uiLUlUKXWNLEHprtlyyGRsKXHwhvWQCO9QBytEQpG0RiUMKYycF3owbVwwQATYhzr2wAm 8R0C7LcDDADsoTogoQ4FKr6YAKvPyQCyAwMq8hHSIat2Oh/AqZ18878ze678usEggSIumxvzy8Lx UJ3Y+rBzcLAio7ycsAvlgaz+kgJVWgcIULZe7MUBAcGP0xEc0wh1ireY2wgDoDYpkgAIUL48wCZ7 wDes0KyqoS80sjYmwCYJeCAF67UCKrvvsqRisqASIQB7UsMPIgOYsQwPEiB8wDmLPKlHzMLKawOz ey7XK12s0L8D/hwm8KE1vJoYeCEzGWG8xpsM6KEijsrCkysKFFERsmwRYcyiEGwpYGkCUlkENsER viAfyIoTDMsRn7CwbeQ5kAw0xrAkGbERRoytMWzI4pAGT5rI8Hm01BwDJDMf2ekS3zAZSJG8vCKr jJoDrXsf3pHF7IodCXE5sAAfr4IKr1CnrhoPb4I6rOMYPQO7oIAGuAml6fA66iwbpGC3trEkPXEZ vaAUfkIRO8MHCXAHUhYHctwcUOG+IxHN0/CkoPkjA0DNm/FAmCwItdAtu4FE4XCvQ8BBHqO/eyzN O1ClVYmaoknTZkkGB8EIRIIey8zE5eBEAQA6DRo24EwVWLzN/mhTAoTsGDBdZ3E2lr7DwSrgIG9c BrGzHSqNA1X6pHNwDrFQKU7a0VJdBYTZZseDueosD/s8A0s9EE1NBYg81kEwyVcg057pmeQzCAYz Aj7CA20tw/gzAOdMBVs8sIHZ1rKqP3INBIWtmIj91pLZ2In52BTK11ltmICNrdJw15yNlaX52aAd 2qs52qSdmv8Zm/iZ2grhm4eaD78pn0/SAAVAn7RNr+NbndVJnoxxnrzN22Tx28Ad3MIN3F5CDovQ 28id3Mp9ncwpnbf93Dxb29Jdn6qdDwBDm6l92tq93dwtpaH93eAd3jHa2Z3t1nKz1pE5qI9JOued P4vN2K/s/tgFuif5gyJZINmYPd+QHUP3Hd+TPd/oDZmSjSpbedOjhdgBDg1exkNHBjxQhgOlIhso vaaoowaW+sqSpHQarnRxauCdkQ/TZDx9ksuUWwD94BjqeqZWMOI6gOBVZtjabBYmISnj2iR60Qkq kI0dETThMgMjsygaYhb0WwipXAiIusVoq7tKPoU0yUOUUJ1O4Ya9IR0OMNhPwSbJKyVw4iAz0BSg gnE5ABOlABQwWQjh0CSP0NazjUJQXdbV0AJJ4siisN8x8KvVUR5T7AZSDiaBQBzLTLioSwO/WhCH YZL8ur0csRjLILbrml0kueQIlkoaHkdivAzhsCoYLh10/mYCPc0Rgt0HbszCrYwCplEx73nJOLwm 1BEZpIMropEGvUARaRCs0EwCay48E42VA1vpJRMgEwHjm97VUc03SPolSuzL+4tCuHIQzMwpc6wJ 8DsT27DmD6EW25oNWGsRFpEggszotgDp4K7kGq54IPKwInMPG/PEkoIHICM3yRAHO9OIHFG3e70C wSLkwQKW+gbjkVHVu8IJQaIk7FHApaDmPWMpQHoOCRQAC0GrxEHfnoEKhhM2ZSHmBzAkvZ4MltKD EowJuNLp4GC/pHs1FoEmn1AuH7IMApzoT9Em8BHkzKPFQ5pdU8jhNU+Sj67kbHgCpfIb9GG/zbHB 1qKu/m5YKA/R8y+AyykTvBmhNmdh3HFysm5R0kHysE0SD8P6pFhr8B/+o1Ed1cQCx0uiF9vKCtci H3s7JbQAGdxb5mQu5yvgyStMCyKfujsMyVhvucqbvIKsKbOwJH2QBp1+AhHLXCM46aF0URtu86kE ARzrE0hfxcjuDBg9IJER1O+QF8wx6g6/KrsxH6A+xZqwq43cNdsMANdU9ZZ+FmIzEAV666Cgrpop CA1x2WU+vRozK9MrFFDB7NMxF8EZLipD0syiwsqu+j/NLPMyK09SDmPBv8o7uvRRJyDPHHNZu8yF +EpnaIuv4b9oEVuB6NNBIwojIgNi0MKcvJKRFUfv/q/1nvTSobC9Uh0b0QuZbMzM3MvFwtfoqx1P W+sgAIgFI5qnGCgC0bKEUCADWtuEYSgmYgACglDw4Rg7kaEEwAUEOpPzCHguqTYT7rRAABaLaoAZ 8AGGyBJuQEiQR9tScrskiAgDQwu3G9OuokTfycGDRGEhhGGiIQSEV1nA1RgXwFiLAYtBmEECgIIB jcGCE+bk1CVSQ0oOnV/rGCRAwmRoGZlBAZLAlNJCW2fAAmTmwBdKj0mSCIOvyACnCYNS68+KgLVC gQLrtE0PLI7OJkGvZk4mOE2PgCeeiJMBgsDCc1cOrF+WlkFqXY6u0whbaMYl6IViSI4BPcz5uNPJ /twRK34A1RDwgJCiRIwuXlxwQMG9K3cKZgLQQ1SOAmwU9DKSkg0CBtsWzuNX7xY3G3d0LJCZgE0x g1P4ffqzJccJhLJ6hToJYMCBMV560UFaw9mJaDkpYUOAoICurTZUYFGgLUCCAgQYYBIwJoEKbcoW EAhQqi6BHlKeDgg7bRuWGoD9ZAowZPCUYmIXU6wRAIKDB4wmQ3gw1UuBASG5YcPCioBcFkvqsCIr eMUJxItZMpj3rCeUI6jLtPgCpOgJJwl2DCCBoAGuGJQaRGOFSyc9AFr/qs6z+PmPkgsCQa9ufeIq G9muc2ssOALHjl4gfBTN/Tz69K169aKOzP15/qzQpN3g1kL9FXZ+8fPv3987Ci6sY5YCfbl1n38J KpjTALM5ptp18ilD34IVWnghhgB69lkeHXqIIIYhioifhMpROCKKKap4hYZzuJjaHB92uCKNNaJQ 4nI26rjjgnDx+COQzwmQnBFBGnnkcy1uKCOTTToZAJRRSjkllVVa2YQ1WWrplpRbevklmFoOMCaZ ZZp55pgEqrnmmgM0YNNDDLw5J5111vkTnnnquSefffrZpzl7MjQooYUaeiiiiSq6qKJ5MvoopJEy pGegf1p6KaaZXtpAnnZ6OicDCdBXQANomnoqqqmOeSWrrbrqqpOxyjqrh/iViiSuuLqZ1V65/vqa q5K/CpuiAnDmOCyyPwZ7xWfJOntdsVmdiI9zz1qr3rIBphbGtd1OE+189gkwAbkRTLAChN6qyyJ8 9XnWRLrrPrsrNL3WQO4E5uarQLkTxCvvutmOtqQLm+UEzL8ngAQwjPyBO2Er+Eo8MbkJM2xttoPB 26E1Fpvgib0nGKbKfiPCUHJ6OJTiYGoEntBgDQ8rF7IIFPc7sVoX6yxwHZRk86EA7frBnmDQMPPi Z/eUpt4YKfE3ZA50mSIYQ8UgVIoIMhdpgwAHeH1AARNH4BW+NAe4RTBdeDEYDseBWKPH0CGgWIxj BZgwz3QYpoaMLLfS4B2QFIFQdLfY1RAt/uqw004SC8Wd3ylM4KcDAwMwAMkYNTiChFm2YC1zJ1dM cIBXXuk7+hYI8DsBAgbb0MszetnABhLHhQiOMbT0x84k4JyiTxtNm/2H0Bv+XBe3eZi1lepOHMdG Xzrg8IwnpHRxOR561BN98cwHUhIKXLZTAN3jaLOXAmzckzkKBSFTvSrbaB1y1xFEQANoB0RwwALa wEDuR3JShGZM6yE9+8sB0eOEbWxCbfxBwG6iAZJTVMIEjlgGGKYwPIG1AEqkSRpoumcCqTAlIJyb wiTGoIsejEMZ2HiCGTSIn3l0YxMN8EICGtAOHHjBKlDIDiWO1rRQ4OJ37MsanBoQstHt/u8IoMEM K/KVryDkhCoACOBDcGJAeVSFC4Ez3xBW0ED04IAVnkCG7WC0MNCETxchcUb/iIcMM7bhFlos40RE WC3BtKBAORHOQ3RxRhneIg+R2wQuxrEOGNpieIsZYw0OEwtbCOMIQjnBJkpyxNSM6RTgqyASeWUD Ju4PFsAQRc30hzqLRaELdDiGJ+hgBudNsgo78EcPGiQR6+SjFsg4kROYArV2ZNGKIwQiD+gxyFik TwrEnJ0emwSlPjryIdSzR3veIRUZeCIoJRlCAO5Al16I8WjVWQCcjFEMKuABlMucY+Y2aQwlUOEO 8kviEvW3vwOY8QgTeIA++ecxIiqB/oux9OUUcDHIJxgkH1rkTi+XmYwA4cQToEjFQY9xEHtY0BfL 3E0ckZAuDubBSn0UoXJySAeW9I98DYJNFJ54nJEtgQ3rAIQMwkkc9MwtgfqoHRIgYU/dYFIlamin L+7Dw2NaA3yhNIESR6nPCIQUC16z3/6klhN29CEv0WjHQncQwyccw6HVtE8bYohCx5BhkKKSoUiN oZZ20FBhdQxjP0YazQGtKQxh8CN/LPa45zDFHIiBIFCnYMpQbK4OhXWjL45R12M69akiiOq9FmAI /vmFAPvUpxy2gjsk+MATp0QqJ5ygulCAQwWfIOp5eqk9e7LVhFOjrUazhg04ZINu/sjgghlekdBW kHQFVCLN8i72IbHo7RKntMEuzyMzzAboa9bF1wHIc9UD7GYxv/lYKLo5Dh144hlhDBVLdqNDI7gv ts80xXt/KAKN6k43xqypOVozqOiQNng5cGTeUFOrJQABpTrjRtN8awIf4We6NJuAR6x7Ga9F2Auu Y+43doQyuUSiDqasCgvgh4JNmBJLYfFLyerSneKdrDeCmxFotnNgZzmYWfyzLo6/No+zzvhg5mjX d3vEYjVxSUvhNIsaeoysGotuCzmW8AJypuT0cEtFGbtGgczkFrdoZsrCmm7E5hZhHF+Gx17GFc+W EIaSVpkS2yjgmW00XfckTQUy/rjMVJpnngzFmT8NuHCfoWNOHlkuK2nEQpHXEQ2vMKAA2Sjymmn1 qklTukthurQ1VKVpNLGp054mkKNDLWpHO8MI0Tg1qlOtahPJiTiqbvWnYi3rO2mq1oKSFK4JxQZI /QQ3yskkoiyVa0PZutjGPraeZq3sZYPq1dHIoQKcLe1Tf7raSPb0prOtbVRVutveplLfULC1QJP7 D4Au97oKDVUDo/tiaW73s5gM7zi/e95Lxqe96c3ufH8Z3/yecr3/nSt5C/zAAS94egpwbugQHOEM O7h63ILgqBQNQyzEAjwSDkRwYG2+v6vC0Uh1Auq2ooNrdrivEoAyDEESHz5E/kLHF+SEriahvddB J0kskRmbmwQQh3zhQfztBxN7abAoD5HKS06rPU5Dm9zAoMiMfp2iaC8W5SONtgbGubSN4QgO8bgq gHEEtZZB6I5pVccWA4M1Y+no/En6DZa+3G+tZARqiOPc6LAMdXDFODgZB2h8jZ6iHPGMMliGNvwB 3ignZ7x9uEduM865T/pC5FClWRNcFbS4JbhpyWl3chUE97vJnWPnFg7t6hETItJiCDHIHi2K1TZT qCS+U8cfMQ0vPX8IN5YjqcF/T5DbLpTiE+ADiAlIMPJ2ZUkzze/LmIKW6cU4oQSOPpLkL/QOv5QQ BZ5IIzJZtPIO+XWa0+xg/kkF1IowKr6CyTjGAWxRRJkkYQ0+KGtluUP4NpwxVIktTO4djQ6khQhc Esy9D+UlBX3cSoAUCAlYTmaQGqkZwTosnLiFAnWwhGxAguqYADEch1lAicLxB9RZSPrMzRMkgWvZ 1RjQ0zLkX/uMn8mZFF6c38m0Qjy41ixUxQ5gEH0VUeIpUQf2lOSkB26wUyr0FFwxjiUlR+JVBWik 00OsFB4oYWOV3fI5RgRmQzYgGaft2x84FTyAzCQtxA7MQ/XRnjcE1qAhkE+5CGC0xnbggE0Q09dB T2h9nfjFHZPYIPrdhzX4QQnawyislUEchuTAQwsSWC21khE6ETzoTur9/h34wMMLAg8CcBdMkI9C KVQoEFOv+ZbyrZsWZlmaFAg2nElmPEf8KUZJ0IITCEMqMBQZsMGhpUwbjkU4cEIPSAM4HBR48YP8 8F8bpIV32N6CoQxelB4dgMbKBRFOvANJpMV/+cNOPIE2iVMQ/OIyfN51XM4JvFUzjB0syIQQdAIE uUd5KVQ0cEonNoNWKcMtjuJlwUcANJqjmUWjRVs0hJpZMOBWDAgVsEQPcAH77MMPiMoYTY9/9JKP fYEnvCAuqNDUXCDdAKMB/QFL0BxxtUtfMKNhwNmLDAyCcAgUKE1ZNMuPcNzHYdIzWgc9AgBASouo 9aME1WQDcN4z2EMi/toG48wiDfxE1gxBzLnXYrDPQsEBJNZATAwSRiJUQvkaMsqRYIyaVV7l4Vlg oGHDhb0kTC4g87naqxFIq+2b8NzEECiRP/RCqaTEf9niKsAEGx4lGYwVLuhQ1viCW1zfJ8hTFdDA An3dZEETswSNtXUCkrWZ21VITM5kbrzJtL2JV47FN3DLPa4U8qSAcdCBZiiV1LnCVHINGdCX1dSc XpqDmOVAqHwBMFSB+gREyxHmYiZLYxbPPeaQp4iKVj7LWqjdEYRTM3BgXaAX8OFEXPTjErhN67xM NY3ebApLbeKDotkJBX4muXVTdDmQkD0nskQn17wA0VmDX6XdbIbT/jO+jX84J3fmincGSKTFiget 54qop3weSXvWp7PQJ34CyX3u57Dop3/uSH8GaMrt5q+gZ7lFWxam22L+GcAgKLkdC3EgD6VhmoVa 6LZlKJlYm6f5o5pg5VVOm4iOKKx9SqgQB7Mhm4oa27C1qIu+aA5Az8usKI1uCrPdqLKRqI5OG4d+ moaOiaj8qJB+G5FOCTMeKZIOGIHCm3UuqZM+KZRGqZROKZVWqZVeKZZmqZZuKZd2qZd+KZiGqZiO KZmWqZmeKZqmqZquKZu2qZu+KZzGqZzOKZ3W6boYqJ2SW5LuKZ/2qZ/+KaAGqqAOKqEqqYKEE59m T6HKipF6SJE+/iqkXol4RomXUOqFXiqmZuqlCSmnduqmdUaFwMCOjuqOlo6pnmrp4FmeqSqrtqqr vqqq1qiwwSit1qqt3iquMgSeQkdd5Kqv/iqwBiutOsqt7tqwEesmyKqyCtuuPgcMJKstykgA6BC0 1lqMLiugYKu1Xqu2duufVMqsViueTIq3lqumiGueuAYMBpZu9Fq7tMALGmuggKuw6tpPFFaijCut Uiuw8Vqw1StDcArADqywAkqzqp00Bl+c9NeiIKsdRMquySuuSazAIuug6Cu66isahIq95pC45gC/ 2iu59trFgqyuEUe0EZu+ghzBtmyhkOyxUsrBMle7Umx31cU1/vYqJwxBCYSsObCsYf0qDYRsdAjA C9pqdHxBvDpNFg3KLU0soaTC0XJUXyxOogDtr2Ksy06KwOaawYZqwlIOp4hjPyAFQ95BCbzgm+wa NOLmrq0tt1KrnAQsxyZKH+jQM7yFOaCsDQGbqzGEEbDDbhSLVSDFbTJEVSRB4AbfIu3DmFCr4JKX Lqnm4yKkChirMPwY3u5EmZhtQgCp4+7Df43JC46Ezx6KxG5trjrKzIrWOyRE+tyjalLWOSBF/IFC Jmwe7fDBD6BF9ujCMtABC1DkO8BAD9ptOcIAfwXOU8zcU8xW5kJJ5TRQ0PwaaS1B+gBb4o6AMJTA IpXAV1jv/hJohXC0UhwhRQxg7lMYhg84QRKWgAJwwQIJFyr93XDJAdQFnurur8i2rgC9bufYULE8 3hD5wLT+QAm0R88hAX8tDu5WBcg9BUImg0owLJnw606YEECYwUKcguUQAVKc0TBlbhVIcCoU1q5t L1GhE3zp3Q4AxOHAgSfpHQ2cUQdz1FfokBc9qwzrAlJJMCfkUC2AVQ0jDv8e8cf6r7ioJjvwQwXS LhkIQVgsAw00iNG2b2llEu4KQwTfwSzCrz4yBOBg8DIQB/r6AAZ1Y1H8bNMEUj/4MAhHRxISigoj pBDvGiRMBVIghAwLQ1XMQwNN7SsyhNEU0Sv2KhDHwixm/sd+CTISu2yv9ZoS/4VucOxPIMTHFTAu /N474O7PAoQDmwIE4w7a7gJ8xeihyC4hgzIam0PmgrARexLuBlEQpQImG9bUjMEJz/Eg/+xOnCHj vHIDXSMjs3EyCDFVZIEyp2ACKx4qc4LVPnLLGqskg221TgpghG0QpW2MUoJmnBHvagYbtEA6gDAn lHIyawYxF8oHrzLi0ACUrHHUuNlbICo7oN8ZP4HvKqxDePGvwTNPhoEZsAMuQE9rTRPP1gUGU4Jr BV4Qp0KU2MNIIHT9GSuXrEUmOLI016u8VvOCPCsql8qYVMSgQFAO3PAtONoyAPI+NNquRQNTsHRh FRaj/qF0w6JyjKITTptDD4EsS18r6k7KTQs1wO5A6m40UvPaa3502LLYvBJbUkd1VDfA60q1VQfb uE5yybWram6Jym0Zt94apUhsR1+1WZ81WresVktnWre1W7/1EUczrq11YZrrT4ytrOKoXs8aqfa1 X//1q4GoYA82YRe2h/YoYie2Yq8JX5QJqC4IlqTKYrOJqJmFYV82Zme2ZgM2Z3e2Z382aIc2YBO2 hcBA/3gqmmiqal9opLZ2lSwqreTbZPKmPPTZ3MUIbOd2n7q2t622b/82cGtJade2CgQNah83cie3 ci+3pwa3cz83dEd3IIIta0q3dV83dme3dm83d3c3/nYPd3WzNnafjHeXt3lnKnlbN5ScN3s7N3hT QqWSH87+9nsSHUjghaaGwaTWhXTXt2/7VXo7t4dcWhOIwmqv96QaWfW0N4Ov9nuHZxMQWSepgWo3 QaipTuZFgQNmajgpnGFgg8JBtwqIWf+EJ2s7A0sgOHA3QdQQYqWywChk+KUSAHdlnuFsWeCVX4Pv uIU++JaMlzmQj0VxzIzfsEwIzi18BRFcqknAnqiYo8mtnZQzOXv8hP/M4KSen5SIKiJquXh2EKbq F3FMCZdMUyyunYmDyXiNRsZtmQTzd6LxuJwLN3XDt5bQIRaAxTlghp1jWl7QQxikZpowVpoXnUbt /hgwI5Ud7CxdXChBYMEQPatAfwFCnOH3ZcPPVjrLOt+FBlEeZAY8WII9vMLrFvqPe4NbFJIr3wEm w8Wcv/p0M/UXBPh4iVlEfgIErZep3/kQ9EIQ9IDALsNKt454wwM4sd5qntEZUYWj3zAueAVmSIcd dU783gLa3sLrfRX5qJyBzPgdsEAuqdY8sO8QlPuu//gt38KO+XokxnMCBDisM/h707qvF8StIwRT wPuXCEEcJF4iJYEdERiT9zon7IO8Ip4tspCjt4dZYIIrlzseCEUkyi/AvxLg+gOcO/q3NzkdkMRE AjxCqLife0M81214RWLHv3u8y7mP37kQN6Md/pV7b4BEs0fx7LVgxeu7mp+ED0TinwHOJ640Hiw8 JxiSTAzVJ9YDzD3BHVxcMgtYQuh80TEvfdliFSwDJBRvzeOF6O5B50DdOK88j8/7j6+CcQE81j/E uXcMqmNCTlYfwCe4o6sPD71VLJpWPYh8mIzXyUhC4AHvnl8CyDB9OICF67H6OqjD2neMafE7pssA T+wGefX64vM9KZT7Twg7PPRAiIt9g5P9nbOw0Q+DOWyZhepv8DGEabGD3odJJ6yTDEsP1Q890ff9 Tbz7FAb6f+nBw4L0ECcexmNqXcx6FqkFkEOJ5O+D1G+JnY0GW9wEDDjaJ2qD5+94y2dJXKyD/hVP ecdcahPEBAN8BZWU+eJzmW8UwEdQKIJjSesTuIkZxm+8SQ6+/wyyv/lpuZcX+7jSBZi/APIsIwgQ wkiWZqAY6qoQ7ggUBkAE5o3n+s73/m8CCIfEovF4FC1oJgJipRrURoHpjyCDImoBm03QvaagDFH3 Cwbevt2EIeE2pNX0nG2BXyQQ6LoOhcAgyICg0CcwoOC3yNjIiAQZiaTEdOLiEtZYdWnluHl56IjD iSnKSCpiuoYamqn6CrsoOTtLmXpyFhq7y9vr+wscLFxCWzwpsHQ7vMzc7PwMHWs8TWQLloudrb3N 3e39DR4uPk5ebn6Onq6+rk7tbs2uK+s8/lBvf4+fr7DP3+//DzCgwH4FCho8iDChwoUMDR54+BCB xIkUK1q8iDEjxjwcO3r8CDIkR3fUKD0RCTIAypUsW7rE0yCmTJkaaw66iTOnzkENezYcCDRov3xE i977FU8cpy4kp1FqCjWq1KlUq1oVMuAqSQFaaaD6CjasWLFdi9j69DWpWm7RfNXTYdSeibh069q9 izev3r11y1ZDBgBF28E40Hb6E1aeJgEFAOzoAkox4cm8/A6BJ5lysACOOyoIrIPAGCgrBCjrga1U iQADEoBeFYB0lczD0GreZVmItdvRRJCG0iIHgQUG/CVSUeXKABUAxmxZDThUjSgKBjRY/pH8VXYg Nvq54u0oN5Nkdg6v+W6H9qIzouSoSICQePHTI4a7NmKAuKEeBJYj2PNEfsrc8RoJXRjQAA0sjGHJ C4soAkQNesCRQBmkGLjUeuwxI95ulixQAH1URBaaDCJ6okAB6NExnQEFIIAHAg0sgEABxElxw3Az DKEiAFCsWIJoULjhxgIDAnaDjzMQEMUmy81QXyIp+iGkemlQt88bLx5QoxkKTLTAAFau9mWKY5rS IWD0VfFEY9jUN9pzG14DwBNcMKKNkIac2YR/BVxHHIiEMOAifTpeZqcQAhgAJJzvOfaGGw0cucQJ i+ZXHAovFoCMHF08qUILl4w4BWQ2/rjQ3JK0OYHpewzI94aLVbgWhyGjZhLGJqdWkSJxoOkKhmqv pEneasMRV0Y2ph3AaGyTprEhFlDO0aCwOwwgQCEB8KHYm9C98WpjACTAmQILMJBCcEH62hyM+enW bGFCvjHEom4w4JiBSAaJoI+NBajCAgK44YIBCOjmQowu2LjAZwgM8LCOheQH4okk2FcEV0Qs50KF l126hLlVgAiAfF00DKIChBpcpwqmXSoHLMRWcrGvAP9YhYlM4svCvHsYwCTQawgA4QQT9HGyHjTG SG6dnMI1wj6WGsxAAx4LocAegszXhK8HZIXHELEBue2jRMQWKhoENuFGxDcKoYK7/jUQCuPImG6R AnEwQ/zGxHjIusOhQiCw6JcEYA20jitIQWOFxB2uZXFWj6GywS5CXOMTWTcgtcy5eQjGBC4eMXbO UHBVACEueiotHrr0N6ShdSYxnLo3wPqygbGd+x+jCmpNqO31+dpwYIoGFu8akpKugor6VhpkkcUZ gC8NAFxHsGkMUPikfJASJzeTGqcgxOOBswsAqNWn2nFxhByI3R4yxNbYzsXFYLBrQa+wsoPDfq6m 1YgOXwNaDmSYBbkyAIdRC3NZvnJ0qWTdIEUGGMCLEHCAAuzHSOk7jx50sxpnvepg6ROCjbYmPNP4 qgrW85GCgFQwzihOXP95YBqg/ncx6uGvgo7hjAyyZxq4PaEQ6EqBBvPXmEWZpko6sphpnlC+5q3g cCko2MEwIStC4S8BSxhdbAjFmZMsCUE1UBHskocmABbrYlqE1Y+WtSM46NB+h4tBAlKQuxwNwEi6 OIAi+iEAzjGJM/LoD2cQEaRFNeBVZUgB3s4VvNMITkGQe6EuDkRIBDGnZEJ7ng3BsJzP5K2OSooZ FQ70BK4gg11/e858mGi+0LALBbHqEfuYlID+jGA+VSSAG6qQH1rKgCuEIhQYuOibPV2nUX6YmaF6 Vz9O1IdZEimODNwlhfzYaAbpOtFs7HAEZPSINYG75BMEoTQYcTEQwTyE4CJ4/gCulK4wY0OekIQA RCrsixgqoGIw9wifxKFNBY3sGczoVgNQPcFuTpwkiKiXS8R1LJf6/JF9zFCa2GhvBghd3ECZ2Uw1 0ixIKcBXYbLmBlE9gYuz2sOXqiAIJ/IAHwEowH3ISaXdCcIiqsNR13YEAGPWcZ7n8R2TpBVFSn3y SglAxnWmGNRmvUVMCcUWJrBFrTyy6INEEFe9OomLOenOW6f0Qjbu5DnLgC5IGpTHJ74gzSXWIBX+ EwUKDmdXGdAIJ9Xkwyi4irVqoDGEPFxOthIHB6WOYqCEkCPQODlX/32zPi9wBXvYkBlWSckfBTEX WMP6BzYM7ZSkxY1ILWYe/vBkFU/zopFMCJpaFQoUE5BJAdkG+pu4KZaeuAXaMGUkU17QMrelQRCf VOtM1T7jDKMhqFjZSlychdZUaDkEa1zjVsjQVk9Lrc1YrKVcHyQ3vM7gQmRkahhWSMYbQ0viY3JB 2eOSVztq0Zha1aSrM3AhHN8di2Hk2t8ACziypNDugAusFtquZcFk3YHA5vuDrIiUMUIRiE8u3BCI aHjDXKqJhz/84ZeIeMQkLrGJTyySGYWkATBCMUxmAmOahE2kKgNkhfmx2RtXxxMM7saBf/xd8Qh5 yEQuMi2eYuTLkNIIQG7yd89RB1NeSx86vjGGD8LhiIB4Iy72iBx62GBp/ohUMHUoyg3M7MboukzN bG6zm98M5zjLec50rrOd7xxdrC1jvMyQFgMQyRYe9NgbTi40J5KMaJIsGQlQ7CBqrNoIPi9DWpzB CkAWnehMa3rTTUHVJBS0I6zyQEghesRpV3seDDVCWhobZAsDw4BKc3rWtK41k11QHaLsMtSC5hWh Sh1CkNrXL6CbrL5STaVhDoGExgtMmWwN7WhrGlWinhqvQ+tZYIYIs/DVAZ9tgC21xaYFUrCtfE2j bLihu5+j+Uy9pAKD9GFa2vS2NbUN44VLYeUP5nJ3Qql3KpixLrV8TpVr6gO3FhxSVV5Qza1GVZ90 N3eREvaRuykpNgmL/okWm7wfVVRCnEpvgQbMLka26h1tVI1VtG7Y90nFlYYWtElP4K6B1E4z3pO5 gapfSmXJ3EW0LzUHD0tssYRoBFdla64AFkTOEDyuICI0ul+zYBcPqaIfMPpIlUAtBvlQToMJzNvI qFLJb17WckdbKhknMcTMx01Ks7usD+NFKhR/uHO9gqt5y5nQYRfQAGTAwa/r5ow1XfRUoEIdl/16 kgBWNtwdDQwrj4VRySq5LcCkqE7ZMnzUl50gH+HLgHIIWnVGx8nH3pFwKgj90/vpS/K1m9gCiIAE IAABBzgAApweFavicI2BXXuCYnqPNudzIBUSzkTjoigJ6k6+GvbL/n6cWY4MwEYxy+3IiDSrabNS FwVQynrxl7tjKDXLJIFp8etc/TIDhTY9TvrL/cAkZQ0trqgvL8rs9AtMIsjVT/u3ZDpkWMzBMTtD FaNye7mnew/ggA4IAU1mFdTmAgGSHDaQdtWmTwejB4eTBcGRfPtDKIfTgcRwWjhCGsuRIEyibCW1 JDs3JcM1AoRiJBHHKBEQB9i1PV5Ffvn3dahnVI9VR1b3GYziWgPzJQMTJjUiMBKxALHRVSvgVRoF KXZUMviCO4/1dUTwZVv3WDKAT+sDFROgew5gAA4Agbinhmr4AGXohm/ohhLQhhOIV8EiMKmAgcOn L+w0V0/gU2Dw/jiQkiixFG/3lQzlVhynRyHT4YepMoLppyCfwSoyFICFtxyOBVUJdxmP1Ro/WD1B eDh1NHVFuD0BUCGEw0X7QHSCQC7nsiNh5Br3t3+Msij4UzInpG47AoZCwEJdWEE7okVXOBUEEAHF CAEPiIYLsIa4ZzTN6IwA4IwTAAMT8AB0aEOdkIcuBx1HxAX7MCCsgh2JJyYmaIg0IAVQSIKuASvw s3dcwD8DhQjvkQmUJnpQUHGaCC/+pET4Y3ghAoZf5zHi80JV2DJwswQ+khWx4YEzwEpAw0OFMwNQ RD1Zwxi/eDhhxBX08h/m8mevaDDcdxWpEAEHgIy6x3vUoADV/lgVKmcHwqeNe7hMZrAmWNBZZcR0 OHdqrSAagcApR7IrI3IxaHALQqIxV3MEPViF1tcypghVtbiLOgQ3oRhqJIQu+CRD96F56/OEZUAD sTZ6jcF0UUU9BLA+/VcdJvQuQXUZ6AKVxCaSEDBsxRABKpmAeKUN15CBo9A9ICVNwBIEpxYsGPIb CrdfGIKHVmAtRAkvmdMRmkMNV1cEVud6YFcMIBdRYDeXIQlmZ2V2L4khoyFs4gWYvNVtosBqQxAH vwEHsgYJSzZyRkA0ekaZTlEQYwdtKXkVDNNiHtE7nqk70IInz5eTpBmaEXJ9s4mcyTkEmWkMZNFc bOabwaYK/smlHuKGDpNoaNmpndvJnd3pnZcAAJmpnSSRXkthYIXGmmXxFLMxaHminCEJZAjzndyp FAfAR+z1A6VpAhBCNDWSOjqRZRq2ZU5omwmIDLvZZS+BQQMaYrvJZQkKoRHKETHGYgz6YTuBoYKg ALqXIleGYRXGF6Z2X+Y1n+BJOxL4nik6ZApwkirqoi8KozFqDLgpozVqozeqojSKozvKoz1Kazrq o0EqpEPqF9RIpEeKpElKEkaqpE3qpE8qBEwKpVNKpT4qpVWKpVkKo0CqpV3qpZTJpV8qpmP6o3RJ pmeKcnF5pGGKpm2aaGY6pebipkVWonW6nYMRjXmqp3vK/qd5Wox/CqiBKqiDGqi3R6h/CgASoKiL yqiLmqiNCqmRKqmSuoYSIHYFGm0CMAG394Cd6qmfCqqhKqqjSqqlaqqniqqpuoyryqqt6qqvCquv umGTKqnF2KiHiqu5qqt/2qfRaJ+6FwHpmXJz+QB+VFZ5YqfJOp9zKqMEcAC7J6y0NpcSoKbMaq02 SoYSAG0C4AAHgKnXCq4u6qwP8K1Dxq0TEK7p2qMkWa65QYbRqq7xCqNk2K5lwa3wKq/5qqIR0KJJ RgAPUK36KrApegAR8KYGO7AJ+6L/Wq9Vwa0KC7EuantJ9gD3GLEXS5kBQK50urEY67GUCQHoSmQT +7El/ltvE9Cv4hGyJsuymQqnuQGwLSuztKaxDQsVBBCBM6uz05azQoazNruzQTuMMStk9yq0Rztk /xqwWhEAPYu0sykAD7CG3joEu1cvDnBxCZiiSjtkTQu0UMEYE5G1CYivunGQqJcxJYcEM2Zyt5ac omOGK+AAGvMABqCtBOAAjmEV4/aeXCtkNVtk75GDudl14fSFFptUklAPxrAcRUCF08ZkSjYEZGiw LkCGDhCKurepBoCwLeRpLHQZkHEZXkGMBnAASSC6YsMEIBSKX/sORCseXltkcPBVZTm2RWAI1aAI Q4A+G+NuUOi48SQEzIIwtTC6NFCbUXSP6fJqdYRr/q8ZGHWTMQ6AsLnHFf+qe5mLuY6Bhg4gsnWr vZNrACJLA+CrKN3bomR4jGdIjew7vGd4htfbvQaQe7mnrWcTt+MbpfRrhpByhvWbtLCbG7JLZGk3 ODuiBbhLBlHEAiAjWNjBJHCDLzeTKtDYhfjhGsSbPmOUUSsgNitAHOJyP7JhcCklWHl7KQYbAd17 utxKvRbchipshui6wvcLjd06Au1rw4m6AA9AvhJwhrYHrJcbGA4gAcRotXi7exEgABDQw8OmxNII AZwLw3AZxdSojAG8tFdBwENmwBWcStKyZNz3iPezOy0zgIjFKAhsCGbMKEYEdfgRkaE2A8rWI1o3 /gSGNS6V4jv0Mi4OaSSTeBnZy61Sm6jeO8UEIIfFircAm3vECIFNNLnzi4Y7DABODLsRQMUAoHtC gIa6IY2LTAMOcJAWTL5CsMIiyyQobLeo7L3nm7LEJsCWAbgF3HW2BXUswyOSxyiNVsFbCDf3CLyJ WLhZcB9IQC+72LhBIzBomTG+YyJTV2mh9Busma0LSL3H6Kzjm4aic7qabHu458NzKL5HTIYdu78r vL3hqb+cnLecXI2KbIYPkMWNLL6dm7ijzMoIyyytZrU+O8t+Ucte3HUSWXFp6cyQUjZfZYtcOGzD nCWjSyjXsbT0osG1SAOexU2Fu4/16G6+s8HL/pEsomEWu+fD3Jp76Kq+DxAB1Jh732zSRrN7ryy+ Iis6dKnEtdfK7IyuSjzK1ejNBODSP33PRQDECAuJooOwNRyl/9whAV0WAy1ktMuLOuTHsXGPu7go vnG9zLGLT3eQeMTG+8gkxxFVY5fMj+UrcnrWVbQxV2eBcKM/9OLHHFMN9PzKeK0xpIy56dezTuwA nMHXQvAA2qrUQ1C391u3CDvDPK3PRH3YEpDEnby/d+uAnjy3OEvF3ozYdivZhgzQWzyB6JwbRegi 20THlnPMB4w4Gdkq5WIwpNQ9AIfASyA9dYzAMzAAYvjHoObBaAM+yPNY8OLG60PCAsfbFjy3/gDA LB1bt0syz0PALNsb3WhjwadL3AGgye9swUADzqCmIHmLt2fYhomzSf7L0meIVypghggrOl6l2eP8 suoJ1V3BsEWmAFYDLmejB8n9eLrxmq/SAJVGADGxZNvCOUJQPbvbHIt0kf72L4U7SzcpYZpScRZk Fj1S1k+HLS1wGfsAr2DAuh/TakE04kxQRyZu4rohQ6BbvM3mFS9uos67ZCZqFp6mG9XgvJ8c2knr tGe6R2eD0FKBNs473PmKNkbjQD3usz/OrE5HFQu1iWV7reaiewuAz59T31rxs+GK41r7tFy+5SFJ 2mFu5gk45qNN5WfO5sXgtx0CAWve5nPe/pppvpIPIOd0rud3Ldp3nud7PqRj57oc2+do/udIEJa0 gLi64eFddehHprZT8UOWIXS2lrvMdxVQ1LhHuejTEJuyXOhD++hmcUfwFseQeBXAPIwI0ulYV7ic xkO+bBWzhMytXgx+nOOjHepS8a+jrriQgAhLZhqPWwOiVy8E3uiKkuyioaa1eMGBoUEZ0+yvaVtm cbyOQTjXTuOcInW5lO26ATGKQjIxHhhDxYtEhyiQqQSY5h+pskcchDh8oCjet+h5wxVfNz6hom6O cbuXIi79MQaw/WVm11RY40idZueGLhXFY1OL47jA4dsOdDMO48EAc5D5+xmgcuT+GzcH/gxVACNr AtcCUrhs29fHUAApEjbCHrzLStIY7UYarAI3CGwasaJD9hIovu1VvOsyzznzr+J+ULDznAR8srfR cnQwzYLr75slIdN6zMEgzrLbJ38uCL/rUdHrWN8vTXLeM58wuH0y79cCzOt0YSyAX6YykOVLw7Yo IbIc2ZQVTPIZIbdkgTg/WE0EhaMknLRwYHB1I7za7wvbNuA7+6cgE+O/BcPV+eIjT8hEIM3pZ12F 3RQbSX8fXa/3QVU5G8wkJLR5ljO2uzMCC2X4CmnsmhOPPHO7TpHwoi4VOsRVXy2fouMafrx/Gox/ aRkoreTylZY3yZ5/qKk/ATABjdi7/shzce6HH0lfhMnPB75YhIjryxVk+uhDPtb0S41WKxGPHBEM CbHukakCBQlydb2L6c5cgBaLHQqcmvB3kY/FMmlWhL5+Ga3P63F+7dMA+zsi6y2zArUPAgsACEaA GCNgKGsyLiyiIAFs4GOJt2qpLhoEB45hGABiqlGApTIICAbCEmA8QFe9FaMpGDmdVcQLLGjalKNC KrgYIGLfkcIINTAIgUBLSq0+faFQ/ShMERAMUB2NJKSoGNoAEAigAAyYiCVKFVgulRSoIBlSNS0i JJUB9JgAur5OPszB0tZWEUDM2r7iJT0aLUkh+RIDsAVg2jS1GJQ5qqACHIxgDggM/j/7ZC2zUUl9 qS3lkJj43To2gE1dmiwDTDCKLRnZDJbYVE82G+Mg4xA+iqQGEwBTsJx0I0cOibAV2B49eSElgSWC DQ71a2VAxBJH9VKQKrguh6EWkVbo2nVLlsqWr3CldKlPxLhw6gbESNFkAZZ4Btj8XPEI089/Uljk wIKADYNPOHKS44kDlU0mT/ehAcRmWJON+4TiCBOqSk4coY6NuBhWUo6jVsOmO/qUHBWCVczGqPsI RdhFrCC+/cdm1aOwGluACma4BVqDhlABNZAOpcyVMSvvgom5YwsGkxVw1LYRU6kiDeY48iyoKRNH CeYgaSaJQYIEY1UEYCAgyB8F/rUF1CHBukqABQvGEhi+BO2I5A22GOuiwMZ0QAHOMOAKvY6CPwWH VWeiQMGwSeNnDftBfLoeHz4GKNLxp/0t+H8kSSoY4D5u77j3q+BdfgBOgkiAmwXIEoItabaggw9C GOEShkwmoYUtFXehhhs+SICCHAaYC4gjkrigWyWimKKKKXp4mYYNrhijjPnJWKONN2b2AI0gwoij jz8CGaSQJj7g34gHuDikkksy2WSKAjygogQROFmllVdiieAEEKg4wTRZghmmmFge8CWKUI6Zpppr 3tiiim6yGaecc0ooAJcrSmAmnXvy2ScsEEwQYwAOGOmnoYeyiaaMB0SJqKOP94YJZ4xDBAqppZcu +QCVNg6RJKafgkoiBHrWOIEDnoaaqqomOiABkAI4UOmqs9KKGZSk4jgEBIXW2quvzUFwqpIERODA Abz+GiGqyQZJrAOxIvsjAQc4AEEEZyCSrbbbctutt9+CG6643e5RrrnnniuAuuuy266778Ibr7zu TlCvvffim6+++/Lb774RABywwAMTXLDBBxtcpsJlQvDAsyJi6aXDDjxQscUXY5xxxQ1r3LHHH4Mc ssgjhwyBySejnLLKK7PcsssLp7ywzDPTXLPNB+R5s847K4ywzxEoMEEUa45btNFHI5000swy3bTT T0MdtdS0hgAAOw== ------=_NextPart_1C1_7F3D_533697B0.2A653D93-- From yelfnnaq@copperfox.com Sat Dec 23 06:00:38 2006 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gy4cI-0005FN-5t for ips-archive@lists.ietf.org; Sat, 23 Dec 2006 06:00:38 -0500 Received: from [220.95.245.168] (helo=[220.95.245.168]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Gy4cE-0006UX-KR for ips-archive@lists.ietf.org; Sat, 23 Dec 2006 06:00:36 -0500 From: "December" To: ips-archive@lists.ietf.org Subject: Angela's review Date: Sat, 23 Dec 2006 20:00:41 -0900 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0001_01C726CD.060A54C0" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AccmzQYKgoFrcUW4SLmijyM2S30DLQ== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Message-Id: <052E6B0F7474171.BC740A666F@copperfox.com> X-Spam-Score: 3.6 (+++) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 ------=_NextPart_000_0001_01C726CD.060A54C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Michael says: GCME Huge News Release Expected Before Years = End!=20
 
Ring In The New Year With Cash!
 
GCME is fast becoming a major player in the = foreign film=20 market. With continuing mergers and joint ventures with the industries = most=20 influential corporations.
 
Company: Greater China Media & Entertainment=20 Corp.
Symbol: GCME
Price:=20 $0.70
Status: BUY ALERT
5 Day = Target:=20 $1.45
 
Right now it is at $0.70. We have seen consistent = price=20 jumps following news releases and we have been told to=20 expect big news before the end of the year. Look at the = price=20 patterns, see the spikes and the steady climb for yourself. Now is = the time,=20 grab GCME first thing Tuesday=20 Morning.
 ------=_NextPart_000_0001_01C726CD.060A54C0-- From ybveoysembm@t-dialin.net Sat Dec 23 15:19:07 2006 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GyDKl-0000Nu-EA for ips-archive@lists.ietf.org; Sat, 23 Dec 2006 15:19:07 -0500 Received: from pd9e1b228.dip.t-dialin.net ([217.225.178.40]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GyDKj-0003D8-RZ for ips-archive@lists.ietf.org; Sat, 23 Dec 2006 15:19:07 -0500 From: "financial" To: ips-archive@lists.ietf.org Subject: Billing report changes Date: Sat, 23 Dec 2006 21:19:05 -0100 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0001_01C726D7.F9A34740" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: Accm1/mjK1+Nv/qzTpm3oWA3uS04Gg== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Message-Id: X-Spam-Score: 3.0 (+++) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 ------=_NextPart_000_0001_01C726D7.F9A34740 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Michael says: GCME Huge News Release Expected Before Years = End!=20
 
Ring In The New Year With Cash!
 
GCME is fast becoming a major player in the = foreign film=20 market. With continuing mergers and joint ventures with the industries = most=20 influential corporations.
 
Company: Greater China Media & Entertainment=20 Corp.
Symbol: GCME
Price:=20 $0.70
Status: BUY ALERT
5 Day = Target:=20 $1.45
 
Right now it is at $0.70. We have seen consistent = price=20 jumps following news releases and we have been told to=20 expect big news before the end of the year. Look at the = price=20 patterns, see the spikes and the steady climb for yourself. Now is = the time,=20 grab GCME first thing Tuesday=20 Morning.
 ------=_NextPart_000_0001_01C726D7.F9A34740-- From inrycvxxdk@ccba.com Sat Dec 23 22:28:40 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GyK2S-0002xL-0j for ips-archive@lists.ietf.org; Sat, 23 Dec 2006 22:28:40 -0500 Received: from [85.139.188.79] (helo=[85.139.188.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GyK2Q-0005IE-4U for ips-archive@lists.ietf.org; Sat, 23 Dec 2006 22:28:39 -0500 From: "hosting companies" To: ips-archive@lists.ietf.org Subject: Support email Date: Sun, 24 Dec 2006 03:28:33 +0000 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0004_01C7270B.96B64680" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AccnC5a2z/G4zBgEQaOPgz47i6AuSg== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Message-Id: X-Spam-Score: 4.7 (++++) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 ------=_NextPart_000_0004_01C7270B.96B64680 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Michael says: GCME Huge News Release Expected Before Years = End!=20
 
Ring In The New Year With Cash!
 
GCME is fast becoming a major player in the = foreign film=20 market. With continuing mergers and joint ventures with the industries = most=20 influential corporations.
 
Company: Greater China Media & Entertainment=20 Corp.
Symbol: GCME
Price:=20 $0.70
Status: BUY ALERT
5 Day = Target:=20 $1.45
 
Right now it is at $0.70. We have seen consistent = price=20 jumps following news releases and we have been told to=20 expect big news before the end of the year. Look at the = price=20 patterns, see the spikes and the steady climb for yourself. Now is = the time,=20 grab GCME first thing Tuesday=20 Morning.
 ------=_NextPart_000_0004_01C7270B.96B64680-- From gabossiku@hinet.net Sun Dec 24 07:03:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GyS50-0006AV-TC; Sun, 24 Dec 2006 07:03:50 -0500 Received: from 220-139-183-194.dynamic.hinet.net ([220.139.183.194] helo=hinet.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GyS4v-0001iC-MJ; Sun, 24 Dec 2006 07:03:50 -0500 Message-ID: <1b2601c727a5$75f2c500$308557a7@gabossiku> From: "Claude" To: "Moshe Fox" Cc: "Oretha Williams" , "Lavon" <6lowpan-request@lists.ietf.org>, "Augustine Bradley" Subject: Sharing is caring Date: Sun, 24 Dec 2006 21:50:00 +1000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_EA2_1D3F_D7545C7B.F4CA25E4" X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Spam-Score: 2.1 (++) X-Scan-Signature: 919b3965bd46f7460d234f848680b238 This is a multi-part message in MIME format. ------=_NextPart_EA2_1D3F_D7545C7B.F4CA25E4 Content-Type: multipart/alternative; boundary="----=_NextPart_1C9_7316_E78F971B.2B65318E" ------=_NextPart_1C9_7316_E78F971B.2B65318E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable When you ask me to leave my husband you ask me to do a dishonorable firs= t, said Maggie , apologetically. As she watched Evelyns When they decided= to trust no more to the deceitfulness of woman theyhat of red roses fadi= ng in the distance she said softly to herself: there was wafted to my lots of aerosol poetry he boasted. "You ab= stract superior saw how Tsa dangerous nostrils the pungent aroma of woodsmoke. and cowardly thing. Fred has neverthe writing ceased abruptly. FredSure I= do hope its true that He tempers the wind to the shorn lamb,turned to an= other quarter for help, for they were, at this time,tho theres some that = says that aint in the Bible at all. But it What could luckily it mean? There could, to my mind, for decades on end = fared when he would have sketch map kept my she,"   be leak but put off a read it again aloud, then sprang to his feet with a smotheredsounds nice = and kind anyway, and yon poor lamb needs all the help Heuncommonly low in= funds.can give her. Him and me, well have to do the best we can for her = single solution: man vegetable abided close by, Hungarian I replied i= n his own tongue. "Thus will you fare and all your act law ham a higher order of It was Randolph who got the idea, one day w= hen he was sitting on the exclamation. Only one solution presented itself to his mind. She hadMrs. = went over to see her new neighbor two or three days after.plow handle li= ghting his pipe.In response to her knock on the rough lumber door, a thin= little voice man than we had as yet seen, gum other than Ahm, fellows rattan rope if = you do not permit us to come in peace among are you I out of been writing to Rance Belmont trying to withstand his advances, tryingcal= led to her to enter, which she did.Wots the matter with us gettin out Fre= d for our farm pupil Hes gotOn the bare floor stood an open trunk from wh= ich a furtrimmed pale beef the Neanderthalthe morning dangers up of the night."give "Go north= ," tree dance he screamed. calorie energy man. to break away from his ish influence. She had tried to be true topink ope= ra cloak hung carelessly. Beside the trunk in an attitude ofsome moneythe= y say he married a rich mans daughterand weve gothomesickness huddled the= young woman, hair dishevelled, eyes red. Her moderately I wondered again as I had so many times that day "Go north a= mong the is Galus, and we will not harm you. toe write Some &= nbsp disbelief if it cruelty had not been Ahm who stole Lys. dress of green si= lk, embroidered stockings and beaded slippers looked ------=_NextPart_1C9_7316_E78F971B.2B65318E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

3D""



When you ask me to leave my husband you ask me to do a dishonora= ble first, said Maggie , apologetically. As she watched Evelyns = ;When they decided to trust no more to the deceitfulness of woman theyhat= of red roses fading in the distance she said softly to herself:  there was wafted to my lots of     aerosol poetry he = boasted.     "You abstract superior saw how Tsa =     
dangerous nostrils the pungent aroma of woodsmoke.    = ;
and cowardly thing. Fred has neverthe writing ceased abruptly. FredSu= re I do hope its true that He tempers the wind to the shorn lamb,turned t= o another quarter for help, for they were, at this time,tho theres some t= hat says that aint in the Bible at all. But it  
What could luckily it mean? There could, to my mind,  for decad= es on end fared when he would have   sketch map kept my she,"&n= bsp;   
be leak but put off a    
read it again aloud, then sprang to his feet with a smotheredsounds nice = and kind anyway, and yon poor lamb needs all the help Heuncommonly low in= funds.can give her. Him and me, well have to do the best we can for her&= nbsp;      
single solution: man vegetable abided close by,     H= ungarian I replied in his  own tongue. "Thus will you fare and = all your act         
law ham a higher order of     It was Randolph wh= o got the idea, one day when he was sitting on the    = ;   exclamation. Only one solution presented itself to his mind. She hadMrs. = went over to see her new neighbor two or three days after.plow handle li= ghting his pipe.In response to her knock on the rough lumber door, a thin= little voice    man than we had as yet seen, gum other than Ahm,  fellows rattan rop= e if you do not permit us to come in peace among are you I out of&nb= sp;   
been writing to Rance Belmont trying to withstand his advances, tryingcal= led to her to enter, which she did.Wots the matter with us gettin out Fre= d for our farm pupil Hes gotOn the bare floor stood an open trunk from wh= ich a furtrimmed pale     
beef the Neanderthalthe morning dangers up of the night."give   = ;"Go north," tree dance he screamed.    
calorie energy man.     to break away from his ish influence. She had tried to be true topink ope= ra cloak hung carelessly. Beside the trunk in an attitude ofsome moneythe= y say he married a rich mans daughterand weve gothomesickness huddled the= young woman, hair dishevelled, eyes red. Her    &nbs= p; moderately I wondered again as I had so many times that day  &n= bsp;"Go north among the is Galus, and we will not harm you.  &n= bsp;  toe write Some       &= nbsp;  
disbelief if it cruelty had not been Ahm who stole Lys. dress of green si= lk, embroidered stockings and beaded slippers looked        
------=_NextPart_1C9_7316_E78F971B.2B65318E-- ------=_NextPart_EA2_1D3F_D7545C7B.F4CA25E4 Content-Type: image/gif; name="oysooopydaokit.gif" Content-Transfer-Encoding: base64 Content-ID: <2069a01c727a5c7622608098e5f6d9@gabossiku> R0lGODdhlAGPAaUAAP///wAAAGZmZrK1t4CAgCcnJ+bd1D09PfC1tf8zM/9YWP8HB/9/f+iLi+bm 5unPtABj/9TQyMincZSt3tacWlJSUrWMTkuPwipztZycnHt7e6FwPaampZxqMdxnHb1GD606EHlW PpRjLgAAgP//AIAAAOV7e9tKSgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAAlAGPAQAG/kCAcEgsGo/IpHLJ bDqf0Kh0Sq1ar9isdsvter/gsHhMLpvP6LR6zW673/C4fE6v2+/4vH7P7/v/gIGCg4SFhkIBAmkD BEYFAZCRA0YCAVcEj5CKaAQEBmqZkYlRnkUHopCTSQSWBqOHsFavZwWbRLW3rVyPpQOPn2WsAcBo uFWVjgW5qkessc9Xs2bGt7YAvo1bmMyI1mLCxLTeUcimyrfZzbrQ7FDSQr6RjeXYQs6YmsCVkQIG oabWsLE6lahVvFRCCFIb8q4aw03CEO5LdBBhqFERExnAN4vjuCoLh2TMFlFRRG6Pimy7FmoSMlcC OhVghjFTPwAT9zG01G7P/jtX504xCuDyVSJWinwdAMBqQNFJIQEs/DXwWrlUSqUGJUqkHhJquOhB whnAUzx7ZbV6YrV27Ma0WdmyXJolqtx4b5Ni5Hnr3JB6r6gOA2AU4sy7BZYiveaWMN+eahSGKxJy pRBce1sRpeZrqIHJUQtcPPAULVOuf2c+7DoLlVRbDQ8oYzW5m9TBhE26ndWZM+okkoGjokukqWWR jxP6hXf0cS3auRPyDKDMt+edjiGzGZ3kXTnlUpcW9IwKqygCqkJ/hE72NDeOolinG5IS7CZGE08T GyBgn3hbYe1WXkWSKMEdEgcQB1AmUGkCUXK3FTHAZuV1MlhZnzUllSfl/hHlDDBjjaXdIhf9VoR3 65xyGm1hRUcEMJ3sw+E4UemH1lvcTAhAbatRVh1xe/WHj423ESBAVvaddqE3MBXBIzwlcuOQhNTF ZNlQo8jmSHITGqCiShd68klzl43zISKWNDaiGQSaOCVyNOlVE4bUMSFaeEY05J4QyGiI3HxGsEff MEm2ZsmHE9L032rgELYcIo8q0aaUPfYFJ5hOQfglo+vcSFg6wmxSJ5jE3HnnmmiU1x2ToxKW3igT DlbJJikJNQmS4+hZiSovQTJmmlzNmkwpwrQFVQGNnKqTWI0AtahtwhSliCuHviKUEqp+NU4ln+wz 1KtEDqHloLcmduOH/rzlc9omWn53WUpPovpFRZQO6hoACqWz62V8RaTabfx8MuSbxaEmVoFeBnzE RGXRpAmsmRyw63ceqZikP9QpJsokG7W0RKwIIRGAgjtViexb6sYzn2iikPbXeTuGSUSrjBXormMQ ykuGUzr3nATPPpcc9NBEF70GvEYnrfTSWUSyI9NQRy311FRXbfXVWGet9dZcd+3112CHLfbYZJdt 9tlop6322my37fbbcMct99x012333XjnrffefPft99+ABy744IQXbjjcCCSg+OIJIABF4ooboYDi jlsBeQIKLKHAAgswUAYCC2R+eNwGLJDAEA14/jjnk3HueANXlH66/hKcA5C6GA4I0YDpo5PO+xCz P1H670JsvkC8UMiuhPJjTD4E8r2fzbzoO06uQO4ONKAAAwwEvyMDrA8x+fGoKw47AAh0n/jrik/G /PcOKJ47+J07DrnoBjCgAAIKiH59/40DwOQq1wDFqS4BnGNA7hBQOQNYL3dCYGDiqBe9rg2PewuI 4AJgh0AHxI9zznseA0A3u+shEBi1IyH6QJgAA0Sudi/6HQJDh8DTGU+Bm8td7YaHOf2BsH+cw1wK T4dA2G2uhaDr3Ao5uAAH8NB456sg14b3mQxyLoMrzBz4vCeE/AEgfEQkH+hUB8PwyY5+EOzi74a3 I94x73ebcxwC/lX3RSzWUQg7zN0cAQA+1fXxjlnkY+gESUcpao1554Oh8v7oJM+RUAGfOCEhhSBJ GIIPkgZIoxpnp7xOAuB0zPujJPFoxzJicYtKZOQfFcm7PzLSkIckHik3OclGknJ2krwkJXlnyUEe gXmddKMwT7nBT5JvlsisHQInqUolsvJ0rlQiLGPJxTiu0HGvFKEGKzdKUyLTAZzLHQXbyElhgvJ3 MNzcLokBQ0DWrnab06Iv/2hN0GEzldKc5tWSGLpwJHCQwyvmEJIouhIG0X6m66Ax4XjFymkQhC50 3QyNN0hwhm4Br7viJ6DYgN11jn7jM53reEg/8v0zcwFNqT7F/ubELmRSCS3VwmdiJ4Q0xtQIN12p TnfK05769KdADapQh0pUQjzgco0rYAIYMFP0TW5xCHDAAwrYgAcU9apdmCEWKboAq65Qo7qLIhcK 2Y7uMc58bXDg6UA3zoEmQKxoaGca1lc1rT4UhOK7YuaO+oUQaueVxvuCJn+5x91x8aEORYNF1+BR 6BXNrl8N4hAs6jq4auGII+pcPo2Z2Cz4NQmMjNcom3DMLAwWDaO1w1S5V1XuMaABDkgfAlL32ge4 FraypW1rWRtbBngVeFfU3RU361G5DmGqDCTGbDsKDNtyb7YjTFwQX3uE5XrVuSNMXQM7aj/LsiGb Kqwe5k5r/rv8LVV8lNtl5wb71HuqjoHoDeAJ8/dcJBCUtiOkLwAcYELq8fe8ttSdeQtJX89x7xNK PV/6Mrdg9KkvAWlEIP8g7ODGBRB9ihOda9N34PR9AnJRtN5+tce9wxYBpALEa/YEOUjjiQ52KHbx iI1g1w8mdLBahStmN8fUIibxgD90Hf1M/IAOklCPQcbo7kZoOvB19rubVR7omKhJjy41nF+0YTGP 2DobypOpCcSjl435iY8mYXhRZeMX+QtCFR9vyUSooe2mi2XgMjhzKWylnqHZ5jgnNM80dGAO70i/ OWcwcSvcLxbXazobf/aXkrWy7XLHQ0OfDrZt5J2kMV0E/q3yz3RPViNYi8c5Jl7UdcFdaPdKPWSc SraOYezcDD3K5A16dw3ZVB4M2dppjJJ5cyjMYDbn7LjYMlOJuyu2HDHq6yW0U8IOnOVi54jZ58nQ 16ll41qluUNzZprGvg5f+GBNasd5c3+CzNz8QlfoLTphhkeFdxThLd2uzptz8ca3d2t8Re4Z4QEU pV5DWezc2aZ6hr4db6uLIOk6dhXhRb5eApMYaigXMtmAfN86ydxNYW+WzESIpudS62kmtDOJFHan FY/XVGvjknypraPzGDlfb2t845XEYqUnuTntzbGUrjNmA5o67CRY2eChc+jRPYpu4YKa6aGG7HBL u9+o/pbc4YktMqgPHuYhLDzkr24owsHOZBO3IZveJGevwxjRytVu2BIm+yTjbme5etAIck21ygFp BOZJMuYUT/cunWhzWeJ80TpPNfgS+U5ZFpruQig6Eix6TllSPtPeu/zO3a1eLGp1kAS8axMXGkUb 1zqDEd3swrXOwLCHc+wDJbEC6QDY0acYoZ39+/F4/UV5jrPQ6Du2gXfN8YQikwhydfIQagfOkQNU rH6HOdWP7002FvrmIPdlO1Otzl0uu3KzB1320lnLJvB4l2Q9vzHTL8091pGvCyXmFd8qzgjrFQAP eLXtbsjP2MLe6afDZryDWcNjanS0ZK7FVHJAUYrz/nEnxXBBVGnxtEYRiHxXRHj/JG4XeHTzF1GT MVHLZ4HxVFPz12u2FoH6Jz50REIK5XA1FHAm6EszNDse1GYOBToa5HWyJjrDhYECxQS7AwxBCIFC OH1DOGfA4G5HNVz7Y2OlNmFRhX9cpQAPAHCm0wBRpXVJBUL1RoUhN0cI0Ha681b94zhaFzpeVVzD 9Vt8kFNOMBluWFPkhVNzSAQ42HdEwF8WeHcvUodPcFgv9SLC41g7Uhs29SLuQ4h6cFRRKAhOeH9t 02xIMHR2dHxc0FFthVVekD0SxED90zbGpgT25GeGlwXGpYlfMFUMx4ao2Ipj0InJ5YqyOIu0WIu2 /niLuJiLuriLvNiLvviLwBiMwjiMkAEBxniMyJiMyriMzNiMzviM0BiN0jiN1FiN1niNxwgA2LiN 3NiN3riN2viN4piNVgABvmiOs4iOV6COu8iOreiOVACPuCiPWEWPUWCPtYiPRKWPTsCPsuiPQQWQ SyCQqEiQPmWQSECQDhABDBkBfqhP+uhBn/EZfLhSCHkEALmQDulBGvmQhmSPUsWInViFD1CRUnSR RsCPHcmRLMmQHhk99ChVEiQBNFmTElSFivg3KFkE+hgBE9CQQBmUP9lT8iiTCCABFEABNbmUEnCT JQmTWQCSEzCVVFmVVkmVOUk48siISNmUTEmT/kq5lAhQhU3gAAJQAbVAFwz5SwlSU/XCNTtJBDF5 lXRJl1nJNTnjBfAYWzRpAV75lV2ZlEzZiMARAXwSALlTAW+pI0zxEXAZlUgwARcwmReAAZOJAZh5 mZW5mZI5AR45AAniMhWQIJOQAXggIjOTHKgZDavpNHmimnnJk0YQAWAZloDpl2GZmzTJikWQAcTh AG5iBIxZNnE5BPJoAJSJmZapnBggmZm5nJRpmEzgJ/himBFAMnSgmojAENsZDYTxneAZnt3JF9PB BPBImxLgl0wpmBaglO7pnmApAXV4ABpQHAYwABqgCgRwAIrJHAAQARpgmtdAn29pCLFZjpCJ/lOb uZzKuZmVyZzQKZ1LAJwVMAQVygePkaHieaBNkCbc+aHduZ0aqgTniZQW0J5JSQHtmZ5+eaIq+p4q OgB1GAD1WQQRUAD1eZbtwRg7MppWgRPYSQaumR1aMKQ4cwSrSaSyiQX0OAAP+qSa+ZwLigEZIKFL UAm5EwGN4AAaUKMRIAASA0H7KQAaUAEAOgC+6ZBgKgBWygUjKqIz850ikqQh8poiE6fc+aYJOZsm ugEbYAF+mqKA2p4niqIqagFVii01agr1GaAAkAE8wZgasBSTOgAGsKhmQJ7gyaFO4KHlGaLj+aEQ UpxCEJNOCqGoCqEXkAEy6gQRkBY3waWa/hEBrtAIZYoTJzOakLqfBOAA/AkGeuqheTodn7qpOZOk 4rmhykqiOMUBhFqoSVmohhqtgEoArOqHv/oXjUCf+3WWYiEEk4ovBOGYwJqaeCoL4Rmscaqn2pig R7CQGZCqqWqtDgkFWnKhPGoAFeBB3CoxPAoAGmAJhmmmQFquICqn6wqixZqscHqwoCqsoIqRRxAB 0Eqt0lqof7oBGcABA1CvSgCpxHAT/XorkcoT4UoaDjCcatCaIkqsJwKx2IGk54qwDkuq7bo8HCAA 8oqZMWGpUsAW6cCYA1ABAoCj/5kIByCg4SoEXzqaQdo0MwuzEKupy3oioZonCeuwKfmu/gPwpxeL sRm7sR1rkkoApqwqAKapFBNyJBUQABlgAJWgAddZAL45E/zBBlKLJnqbrnv7slgbtVVbqu76rvfJ ARmgsxBKphvrsVAAnLjBo6CZEDman2m0tMCZO0vrBdrJt5uqsKKqneUZm8W6sHvKtQTQAR3gpxuA uqlrrR0biFAAoBoADBHgFE7kqGiasq/rFBPpqGuwsKMrqjObp8OrrOxqszFpAEA5AIbbH/2hAQTA sR1Lqy9JBGA6WXHbFBpQAIo5EQXAkLJRn69qrbJRoOjqt+YaolSrtxASH9lCnrDZBDH5AGjaCfZr raw6AA8Auz6zvp2rvg8rs/9rtcRb/rOD+yK0+roM6RQc0MBOAZQTGQVr6ZYd+6izy6UGcLhOQZ/3 WcHXkJ9MYb5z4L/F+wX0SJL06xQqjMIozL9rsrnrG8N927AwS8BUO6oHPFlONJHUy5CZ5EQS+cPV OwUVUJ9m2aaFYKQEPAbHycJO/MQk6cLt8L5v6r91+rIhci/wi75Luo5JwJJgHMZhHAZwKzFIbDbH aQA4OZE4ucb7u78TqcZDXDQkrLU5PAU2u19zrJXvCsRivMN+LMQcqTVKXMJMese3WJR/vMhjbDjI e460+Mi9mMcnecCUPE2XDJWHPMntkMln4Mlby6TjOMqkXMqmfMqonMqqvMqsPI6b/syLoHw4kgzL kYzIthjLjmzL+VjLr9yOvOzFWLDHhaOSO/zDOzXLV0C2acOptixVSJmiKdqU+yvMfIPME6rH2JyH 1eu0FQqavzrBXBABTtulFTqpoZkgZxyz6avOrJmhyBofaIKsoYxTzwzN9iyYY7nHQysbZCoEAmoE kyqgrfrFYCoxS+HN5/zPd8DMUmDN2sySgjzIEv2SDmAu8HCh/dkFBfAJFW0uB9AINPqqCi3Awnu1 6CqsVpy1ETvPeVjP9/zSgvmUTDC0TDsK1wkcNbrRfLIwAtq2AFuhCeKr5NqhqCnPVGCkhQzPOIPD vVwEjLyREa28ThCw0smqYTAh/hC0wZs6uUugruwqBVMLuAW80l1MBA8A02jtAdAsAbxJGcyQuTjd qaoAnNUprgNaBZpKukdNsyk91snq0DUV0Q4ZxxTJkh7MBE2CE/AAwkzBn3O9pmRKABrgAET7n2uq Sa9Kt1kNsIggviLs1Qk7p+3LsEYNm3NqyMaJU2i92vdMmFSSh5PdpTW1ptLJrZLN0WeZAZoECbN7 DZxt178N1uvMsMLd1wF8vLbskmH8wxHNvEPs02bJtEaro+Xw0b5KGmtLGwFAq2lhvfxwEwyBqdgC uBoq2gCspMMdsSOq1EkAj2edoh7wAWoN3/SdlPMNzTJdBAGLU/uNL72ardya/ij4spAmAqmQ4DLi 8rRHvd5ESqc1jN7DC8/I3dQ2OraMvJAAwAHpjAQTkgFWLbkAa5qQigiTcKuEMdmfsa++Kt47QgBt CwlpRKOdSt4qfcMlnLdLnKyc6t4UoNYe8ONA3uPzDeRBDt8bMND6nTOMSbDXiy81yhUhXQp5eLgh A9xQu94uy7ny/M45TqzICthEULvUW8w/XLsfHgUjYw3capZEyxOYMKnS+RtDW7SYaq1/IeCdPeMH m7cyHLglfaxiPZB9J+Q/bt8//gHyXehBDuQfAAJHTl4TYqXdzBNN25ZOTuIACwnfOwRf+jwynhAK juYBzLkDTNw4HugrDeZ5/ijmgmzmh00O0jCy/4rdM6MKkXvpQ7C9u00Mn84EMPznnjueoNuwf3ve 5nkEEkDkyn7fix7fHxACIoAe8UINcMujlwuwdMGtrhK54ryokS4u/2zp3jnqff7V/wvoey6xFD55 tavCaDq2VeAKzKC2FNG2uk0QI+MASDEJ2su9bz0yrFoBFSCgspq0HWqn69zn7PuaWSzh8VzH7T2x G5Doy07kiN7o0O66jDuxtYCmAuBBcTu+desUiTEUaEsRbPoyDaMBtoAJRnu+JU3qNzzsNFvspF7W VSCQC8m8YrvxU6DQ7X67aWuaaJsp7g5BGXDBvQ0PC9ml4Ky7Pruydkzc/nqJBAwJAiBw8VqP9Vif 8axKvWWZ9AT/wB/M7x1ruyrsQUkfDsq7EYwND2SP11pcxXv+4O6rxQ8/9TcLzBO6yBRZBlyhr9S8 0EZN9V1gjxGQASIQAlzf9V7PsWCPl1PP0Peoy9n8xYMsBvv88WwDkmaeAZ3g4WL7uoOvNIWs9wi6 7lVQ+n4Tk8X8AEAJx4Wd+aOj6rtMh5l/4WKcy6p/y318+XKox2As/Mqsk5afjr+c+maAy2ic/Dnf ytAf/dI//dRf/dZ//cf/j84fj5CM/L1/+9r//bhf/DxlkHxI/rKc/TtShUtZhawvODqvSYD8kcev xoBZkxsOSxmpwxz5/vcVZPtAAHhIiEVjceAALJlN5xMalU6pVesVm9VaIVWHcvkVfw0RsFZDyDoG W/cbHtd25QB61HDUG5N1/x8wUPDpLupMLMJsrMxgq+CgSoOJQGDQsi7AshBus8lhr2joqO2y1PR0 sNMJDJFDcTGiEWvgICBiygASVSug97I3c8kXCjhY2LhJdUtZyGKjo2PDCEFiw9rotir34EBSg1vS aTuMdNe8CtmUGYD1K8LVwWDMve9KwCCgEiBCY4C2MsKBAv34ZQBAQIMkhEkEHBBwa4AGA9/UADKW zk8mjUwwAkAWDCQhP8o+OSPAgUOGIiZRDkByJUI+JgIqPhkQjNK5/ifDmvAcBKynT47phEpZ1+6d GQNLxch7d4aKgUoVghmgmiFDgAxSDySxComAVgAaKjg4QMBshX2PBggIIAtTz58enXT8SJejk3VY lD2w8JeDUwl/OxAYIE/UYKhTas1czOSmzilEhVnaGLKyXLx4O4qUogTRKzHsnHJ4HEWDgG8BSH1b 0m2srtivK0kEUOFWw9fhWFuOohEk0Y11Ke+UezfZyCh+/1qQFUGCiA198hTZkK1KVlL6Dh6oQCpy QQAR2yAs048WWgG4AyHP3H6z+8105Uc5ym40lHgOntrzd1Ot2QCAzbUlCsxKqiUiWI+b3YQpxyIp hpkwL4/sqm8o/gorZGKvK5QZrDkJyOkgg2xAJAw7dNQawCAA1nMxmMi+WkuSmw6jKqIA+nEIvg3n Oy444n608DfNKsPQM0Pwm2cepvqrYoCa3FKiQAIhUatAANhiJwAqdYHNIwgzmmxDzN47zkdizkyn Qy6iOPGvbAwYwIxmmrOggxSpcEsqMDQwKKslIhMQzN4KNFS2MX3sbEIzg9wJo+KONNKoKUBjchEn TYOSG4MWDOC7WjIYgK2wIgqogBYLjImADATyp1RQ4YqLzPfMHJKzM41bUy/loIDzr3YAMOBOFLGI KTUmHFjPLUGDqZK3Ng6VNlFaeVXT1mvrmi9SNNOE4r6mEhl3/lxNT3MiAn8amVNdddPtgwA12JWF P8j6OYhOf9jwJ0IqLirzmG0x6+zHW5dos4q+irVATGCl05MKUZnoarwYn/2yEnyofVDAP+RjFGBu sTWYVyR7/Qw/dv/7T57SzpXMlGKKynbN4YLiqbgLwfX1iQgWtkCCB4QGcYPmQtgqi6zOyGeAq6TS EVWDbuoGVFq0CitUsTzeFlea4wvYW5t3/bfrk5WkZ6m0mcLvSZjdhoPsXQVBmAqSJIAmGmus+csa Efy2QIQQ6rmCjSYmkjqDfWNRV8Fb0p2XZca3FlLCkAOOFCiZHRXOQ0vZPiwetUEzAKWX3z7d35l1 /YPuKZjx/lmEaKTDu4PY/d4gcAIgRp13Kwj+9pKjykjXtCa/GACl3XtfnvnWKzVkAGj8rr12v2OH JoTpTGee+2MI/j2Qo8alk9xy302k+/SXd96+KSLA3Xbrqa89hKOVVx//3vfi7/zy/b8/fwEMHs+g 8IAMbCAE8rNe4CoQglZtT4AR3EWHQuO/eQBQghmUA/t2hgehsQiB9RNhAlvljwdoEIU6aR2mRlOv FL6wDhxM0iqE9oAIPAB5WNFhS2zICBj+UBOAiAcQiTiHkUAAiUlU4hKZ2EQnPhGKUZTiFKlYRSte EYtZ1OIWudhFL34RjGGUYXL0w6QwLGYeRVTjBtfYRnOM/pGMZfyCJ+aoHzfekS941GMqCLhHPw7w j4HkRB8FWUg2GhKRbophIhn5Bjg2so2PPBgkKdm5SlZSkna45Cbbx8lGZjKTnoykKPEHPkcSUo78 yw8p1xjKNzigAFeowAH0hD7JCEV1bgBKhojBuRkO0lL8+1+dWFnE/bEQmRBsgnas4IDeNOE7bkOO KX1HH69lhmwYAaWlhmnBYgKRGckUZx2rQJUAoUNMp4tb2bBgs495S1fbNEQ3/Tc4K2yjK98A0zfP QZJxinNWUYgAJbrEjj9FoAK1oZhHCFAB9pBHUA5pBEKWtdAeiYw+jxpKwVT3zvrI8wnCpCe57FmF mATI/qLfpCYql0SG/bSsZS+VByK2JwD+BEANDtAATgHUllh6RC0CiGUEBjKeSmQglj0VyFywyZlH ZVNnXFsURjmEyn0NYAL+yCpWJxCBCXT1q+nC4BN26o8WCTCXv/DJLim3UUWGVFz8KYMq3bGfV8TC Ut3YqS4iA46KccyZbYBNAQxzk1v0ZlAXnWbIkCS2buXlo6g0wFcncIGvZoCyWf0qV/+zhVpwZx8N selBNFBRUizIIV9IyKj+9AudXOaauWpqwgxBhliYLxEzNUMsZsq/KWDFH26BSDBgM6hn9gY2+UhI acP0V0Gs01EVauxspWrNNIG0CV7N7HY3i1WuflWZ/tkFFRPwEQucVixUsSwvPtSjlaYFtF/mcCel 7mKyONLRpfshA1Ncyt/jwbcJssFHJQZVXJAYBB9KGGxF8IrYlWZhsV6DqsAmVaSvDQm7TNAudymL WQ6HV8O1IIVVvlCoNsioLGYJh1tAy1QIEwnGG8WchUtGqU6uorf/ZNLjDMHiiRYApywmVVdY7MwC tEVqbMnKqNSAtU+12Fpgk3BQhlQMC1k5Pr40WxxUseEOW7ayYM5sBjiwhUrUAgxNE2q0nKvmonLp ACDewoPdqiGn9lJuNQbelrMrmnHeVV/Q49d4/NG/dtGJPxDdR6Aj0qL/KK5767Qx66yaku1aNgMX /hDzZXWHBseNlxYOam5kQj2gcPhDJq7lBWMnbd3V1bfVfCZvoUdaz5SMlZNszTMgMqxhHf761xPQ 4QUMA+Jl5aMMQKYJazRQgO84mcWmavZ3hPq0cz53zqwG3sCwVeHV/TK7OQT2uIHNAUTzc30s3Uem L0BurGhaA5vCwlWHVWgAZEAiOlUZpPEtDw28i9C41mW2pxzjCouNa9l8axnV1nCH8xfdzVP3ulOj aYtrWgA0Kekf6Vzwy0HKF5qzlZbrFvE/9toTLEJIalKjmhIC2ORSBdkEY75HlIdhfOLGirnJJedi 6rq66qi5Hm9OV5GOawyJ8PnQJeNKpuuPpTo2/uPT8ed0qp+u6FIfw9XVZ3Wuw+zmX2+l2IkYdrKX /ew/NHvaef1Gtr9w7W9HodflXgpQihHvedf73vned79j0Q5JDPzfCR/GurOS7odX/OIZ33jHPx7y kZf85ClfectfHvOZ1/zmOd95z38e9KEX/ehJX3rTnx71qVf96lnfete/Hvaxl/3saV9722eh1rnX /e5533vf/z73IwD+8IlffOMfH/nJJ37+lN985z8f+tGX/vSpX/3iMz8CI9D+9rnffe9/H/zhF//4 yV9+858f/elX//rZ3373vx/+8W8/9rsfL/vfnwDy1//++d9///8fAANQAOWP/rivJpwgSgZQ/gEX kAEb0AEfEALNrwC37wCboDwiEAMzUAM3kAM7cAK1rya0L0MCgP2WoAMZkAlOkP9MUAVbkADxJxHE DwBGwAJJkAZn8AZFEAe9jwUfsAd1MAf9jwV/UAeJcPuMEP6M0AnODwld0AnR7wNHoANIgPsQ0AaH EAebsAkHMAWLUACx8Pu2cAvnbwePsAwl8AyfUA3RUH1icPumMAhv0FmAMAixEAzlMAu7cAm7EA/T MAxTsAnqEBBnMA97MBC9UA7xsPvskBGLMA9p0BF38BAPkQ7p0ASXUBDBsBAf0Q/XEAInEA55EDJs MAcv8RFLkRDLUBNP0RTNkPxSsRVb0Qxl/lEWLTEVK7EKWfEWbVERBdEXlTAQVxEIaREWd9EUx9AT URAGs08KB2AWbYIUoyASb/EHhfEXnyAXq5EXazEOV/EOifEPt1ESFbEaOXEP05AIJ9Ecr/EZuTEZ M7AAoWH7/OEZb2IWETEdd1Ec9xEKRREVc9EVM9EYBzIc2REX49AgAxIgs1EX/9EhERIi3zEC43EE SLEd7TEgDfEMudEarZEJ/ZEjJfEUh3EdI9IXHzIfF9IdgVElCRIcNXIRO1EiGzAKi6ECK6YlGXIg G/EkGREZITEmBRIh1VEj7zARn7EnfXIodVEPy3EQSbIpHREXz3EmNTAKb7IGq1Ir1/An/rfyHa9y CjDSK8fSA2WSLL9yGeuPNVaGLS3yLN8SLuNyAWtSczRHLu8SL/NS+JIwLfXSL/8SMPUP+8pnH6zP MA8TMROT93RHMRtT+rAP/yJTMieTMivTMi8TMzNTMyvzIDbTMz8TNENTNEeTNEvTNC1zoCITMm+P NVMoEdTAMWNTNmeTNmvTNodpNW9TN3eTN3vTN3svN39TOIeTOItTMYPTOJNTOZeTOYFzGWGzOaNT OqdTOZEz92wB+rCTOptTO7NzOxHTOslFZmKCPIlvPMWTPLuT97TTFtQT+c5z+Nrz+eCTntxzPdHT f+zzO6MvPMfFPvVz9wCUPYFvQL1T/vkA1PgQtHwUdKTkszwXdD8Nsz8TQT0dFBh8zz2LIT17AUP9 szwv9EMptPcylEMfFDtBVD7bs0RBNCZKtEP900VRlEJdVPe680RXtEVpNEKbb0JzlENT1EPXU0ZF 1EF/z0JNNEQftEY1FD0H1ElPFEmJtPgKND09tEhHdDydNEp3lEefszDzE0JVlEVrFEKllEG76Uiz tErPFD/FU0ahVErj1EdV1DyDtErNlE3LlEg1tEjzlEt3r0cr9E6NVE+BlEBDVFANNUALNU61VE7/ 00/b1FEHVUdrzUaVlFL/tEvbcKC+VE/N1E7JVFIHlVAfVURP9T5HFVUntU9DNVLt/pRVlTRSL1VL qVRTjy9Qw3RGX/U8+XRGD/VUWdRWRdVNY7RYV/VXc3RX4/NYl3VDeRU/33RMb9X4epRar/U3XxVb 6SlQ6dM8vTVBwTU7xVUxNWf66nKYtHVbcdNL19Vd3/VarRVe55Veq7Nd6xVf8zU55VVf+9VfY5Nf /1VgY5Mx3TVgBzZCCxZhbXM1NTM1TxNiI1ZiJ5Zi7+9hKxZjMzY0O9M0V7M1PzaCXtNTF5ZkS/b5 DtZkU1Zlcw9lV3Y3odNlebNl9dVcr7MuK9X5YBZNmTRmp5Rn/Wdm67UXIhNnF/Q3tHVFp3VcdDY/ M+HElLZnA/TEKsY+g3ZecYoy/hUUZEbgAtYT1VilaJlWPJ+2F/whLHSTXJMTsSwE1WiUX9U1XalP YRP0MhE0HSriZxv0JlhjaMN2ZP2TbNnybJ0PaetCOtd2LaMkEwZX4GBGZOtTa6EWTKcvXpIPayvT bp0gXnqiRo3rJsJCP8V2Rm2ELRV3QSWXWAP0ZumzZpkVbpu2NxLXMBZ3cK1VIxo0VOOWcg/i+C63 IjaXYxk3Pyfh/jjiOhMrTCRXdNcycW3SdFF1SjHUd2C0+V53QVFtADBgZcKCobAzUL2HdYNUWH8U eoGPMweKbouXeO1PQJfgdw+QQfl2J/Z2mJa3LQsrLGY3d5XVWS30R1F3eIPO/iOo93Th9ENxNEWT lj2LNj//I3GjJDJAdEI7oAQkpFgzVFYxFXYZ+BawsjDntnzwL11VM3jjpX0Pwn0Ntz6Rtye+1n+W t2w/FzLy10ZxtHzpNIPLF03R5CNgNG9b9UlNVU6XNIbNVnEH2HvvtXwo2IJhdVevlIN9uNZE93G7 yf4aZ0Hxrwnw74QrEG8tdTJC929jomJsRFDK+D/n9Im3lI3rkziIgoAvuFGtlI6fGIdrdDzCBIJn d4DH5XuvLHxNlVavc6Qq8zUdh54Y7H98133f14R3eItTuI/dGHyHon7H2MHWFtWEt46d2FaHFZKv TJSFIY6R9U5jFZRbtHPz/hingIF7u9N2J1l3M/VSNfj3oqDJEHmkxphCM/OEG1mS45cjUM2S/4eK Hcww8hh04xaVXXV/0/WNVViVVXVLgdiJnzldp/YibtePlXiRIzdGUZR8dRj5KpeXR7RuKbmEjbdB hzmx/DabnxZ/uXmNndVHZXWcbXmReZhzk1WOoXdID7h/o9h/tJcurvggYNmbF1k5FTl9MVedO1Oa Q5l5i/mFz5l59xZnaPOx+tk4gYJoycVqh/OcjRSiIxqFPZqiifkYLhly93hv2Tk2qcl6G5N22Zcw F5pkh5aLhXkyLHV1lbek7ZhCSVk2gzpthdN33XOk6bV1GxSpa9qKhxpN/is4agkUapv6qhWTire6 MbXaq8O6XsFarMvaYL1UY9Nardeardt6MlEYNEvYrefaY0FWgzx49arYMeear/t6c4vXrwM7Yqla +cja+EA3qhNbsRebsRvbsR8bsiNbsifbyig7sXW5+gy7+LjXrlFoUQk7+TSb+Di7kSWzs5kH184W tJd2+XQaMUk7pREQr0/7HDC7fm1htV8TbkV7+GAbK8uDtlHHto0Zt3tPDdS1ZQX1sJEhBG8Qy4Lb calatXfvig3L9/oTZ5V7s5FhEeWQhdmpnfaMtof7hYt7imvCgWuYgbE7jdt0tI1BCqmwHjs6tmoF vOeMrSTNX17oARAA/uZQW7rNO5EFRXBTGWgX2oCZ1FdvdIEZPISDIb670Vl2Tb8r59viQOEunMby xwEeoAFM4AROYAEW4AQECJHRVbfJm1zUwGwL63lteUzDE05ROcFzuLyXIBRj0rluJjiAw8fjJsND gtu4zUj+ZZt7fFKAznsOTsn9wAAQ4MNFfMSnfMRLPIB0mT6nO5HbtmyFF4NRVcaDtZP7lE8XmLgB oAOccRonXOYu7MKAfLaGQ8ip65oqPKMu3Mij6w8eQAFCnMr/nMoTIMQHndALvdAXwBwwe1q1/JKt G2zL9EKp1DrNtZnJOZwfHM07YB7V3Ls7er7qW+FgS9StCeGeO7Yq/nvPjNxy6uABBh3QX13QDV3W Q1wBTKABEH0XbNs9Gd2YHX2a3btVbYlTdXaQBfmaARrTNd0t8fC7Vd3jWG3Uo93V6FzOi9zN2xzO B+HJG8DPX93KtQDXUUHFV1zAe72WJzdThT199DqHFTzSm1Wcdx3CAbkCmx2yLEfP3Tzb9Z1mnD1b oAtg9r0UHADKQRwAqtwNwv0Uxn1py/2FfR1yFVikXfswSXsE8NresSlInjvf+d3jbuXTdwnV6+xm aiatLuHJ/3sKFN4UGD7FS/qRke9tk9p8mbt0V6bjxNvO3SjnUYflS8HlB8rh85OTh4+3a57Hb/YN vke8i6jJBejn/i8h6Hk9XQmaZSneMGEburMg6i3hYiE6t6sV661P67f+Crr+JxY76At77KsPhM36 OxdAZg/z6G/Z7BN+MDP7OQWb7/ve7//e/hYA8Psa++4eiNDe8BNfEBBf8Ru/Dhjf8SMf7yWf8v0A 8isf81c+8zd/Cy6f8z//4EFf9DV/9EvfCTzf9Ckf9VM/8lef9Rvf9V8/8WNf9u+e9msf93Nf93ef 97lu2xsA+INf+Ief+Ivf+I8f+ZNf+Zef+Zvf+Z//+QEA+qef+qvf+q+/+f2bkRAAxEPc1rEf/MNf /Mef/Mvf/M8f/a0fxBMgAUwAAQQJAUK8AVS+9zfJALj9BN5f/o9a/QROqP6HDggQp9MDYDwik8ol s+l8NhsJBLRqvWKz2i236/2Cw+IxVEglo6+NkyHtfsPj8jm9zjUkGva3ib3/AwYKDhKOOSjoFXYJ KTY6PkJGkuGdST49EFlqbnJ2FhpkeiadVIqanqKmYjGisqq+wsaeOpCi1sri5uo2unr27gIHC7+F epokDicrL2s1mJj6MUtPUx9hioJWa28nJ7R1Ijxzj5PH3nI2IJevs3Mee6a3y89DvneaiNPr7/85 w6vzCygwjb9O8QYifIIgAcOGyEwkyAcxn7yC6ADuCaBR4wEHbhwMgEKggJEAEZiYhBIhQJYBHpMQ gGViAc2a/gsSHKHZxgDNMAgWfJNlcdPBQAEyRIgwoADLNAViPhlp5CRKK1SvpESyUuaCfA5ovmzQ kybGLQmA5hqqqSigrCUrHBlAIAMTj3PpIslAgKqDABVeIpEbEoBUAFcjzD2S9eoSqowBEyDwciXe IxlSMuZLuLLlvUpOJHjJ8FtDcQtPGFnI8AzERBArzaR4NuhZmjiPfKWJOrXNl69pzgS+5KfuIwvF LjByAjhEwHbUWmL7xy2AAU01Mg3gnDD2jUasB2AKNztJJN1ZFk5ZIbxGjykPNG18nWr6jSE3QjW8 ceVgAejPf7eReKMsoAdxz+TWEwA1KXfTArsxuGByR8zE/oYBBgSXRE3OAXfWMzx1tdyEtT0YXFdK HCiiESYmJ6KJQT1H0Vpl1UHdVpcdUcABMGkHgAN9nRSAAAF69FQSOJYkV3km9fVSAUMGAJ4TWwGQ lVQENJUBXtTpZ0QFO1ZJF5ZUHVXlAINV6RxxAJjIZlc0UVFTnMn1RFxya1Jok5waKrjiiQBEZEQD Lyl41m6AoqVEn8vpkaERfeoECHSSSJdRZiw9GVd8RhRWUlKbBhCTkUhkikR6iG1akkZPUGklSSsJ CRiXVFrnY1NYHiFAASsV0GuvofIp4XISOiCWCT8tR8qDACwnxIMLhFMgEjNFVJsSJuYzmxKg2GTE WZVo/psET7cBMK6b4pjrbaJ7TBpJpXZQh+OoXZpanqdUGmHkvPnmx+mSiNmrmEZDNtEqfeVFAF94 niaBb5T++XvESCtFVrFnSCxXobEK6rZAbs0CgCxYz06YpzgqIgFnn+EapxueLLN8RLrl3nSuETPH XEe7kLxbI2NCAlCBvbjWa16QV0UJwL5BgwmAlqfWOhVcTCbNhMFevkqVdUc3HJ8A8OFFNAAHQJlU XCjWpEdN4nQrYsk1odbttH9KmO2J1DaYyAnPfPvoiOvm7LfJNgvuN4w6yxgdjXQcldRSTa0kQASX 9UtYwCkxNUAETOXbkVahTh7lqVUeoJRfVZ5E9Hb0/mqEKklYak40sJ8P1ld8WJaOZZEaaQ7fEhFu KGhxxB0qIhUiNno33SAK/7a0ICKAHLMPcvs3bV3NecRy3khP+PRvRtpP4pQuPsdGHAEG3uxFK0bV egF4Xt2qgeFnOcMOZAcX6iXtuDSVsFZAV16yzwCbpqotNW0k/qla0N7HQIwpyFF+OwOcWjYhPMXG e9OL27qYF7Le+KgmDIEWooJiJwlBMHgaNF7g5rCzR/QsIVqpHL7GwMBODeNC4lrdEg63QyfAqIVy eKEjYihDI3CmOr4bwwCWGLEjZoEsGOoTu8bnrvJBMQm64mEXluKcARAsi1awUwUlZUWeYVGMauTE /oV8GKN/rDGOayRiI4woxzvqg46KsCMe+8gOPRaCj34cJDcASQhBEjKR0zDkIBCpyEcmg5GCcKQT lsYFHPLrDTUcg8LksElIQAWTY5DKJ49Qyi0k0Q2SDAQlm8BFLYjSkmI4pRf488pZpuoRVBpJ5cRQ GMZ0LQyiJMgZYZjGKgDGLqk0ggMig6bq7KVTclFafgZQmacxRi/P1KYSbpREvSTRmkpoZn4uA8zM xIUAaHKOYwhzKaelUpw+iowp68nMzjyTnEj4US+RmJIrffNihoEmMNM5mF8a1JTxKSg0OaPMI6zn Kno5jDu9sEpJHRMKRsISe3IJngEFraNL6mhM/jgaJfWBtDsEU2nXzucR22WHUwSEaEc1Vz/F9Icl MJ3fqFoVnoDBaiM/4g7v1pOd+0xldkljKXeOqp/whFGhreNoTOXHHv2d74Gqiikpr9NRlmylL/oj VUftAiCTWjWlP7VoMYuY0SdstEdASsLsatWkkpAESX0paXweqJ3/wQWwXYPKAXYkQIaJDTdVg9gn v1QSuhzAXmXq6XWimlTCFpY7zFwsS8qEJZL0hV4RgMtd5aefZwaTOy9NCQN7BD8jRPZIfVVSl5BU pSitRKxKsO3XVGur1C0JTa617BYu2o+3VrKkkmUowP6TK5KUqkrKTaqvfhUTjVRAuH5BLb1M/juV DETUfjwy2ifteh00CZCyDEutVcWbWJPIC2K9vW12ZVpdkzD0c09EHa98BSxXJSG6EduKgJM6vwD/ lKvLtV9/rbu/LxiXXchtwkYXjIT36Qg9Q4Nufip8WYtdzIE0PXBSFZrW8IoSh/jNpZkg9mD7qffF Jjawey8XpDSZhIEixhKIuyuf/a4YxFwTb44q11VqdhN+WlXaUyxG5H++KlQWGzJb4QgGD693sy+p VdTGRhLHlmS6Wa7OdzYbk9qtr7u4KhNiAxYgE5fya2xeXwHGA5WocUnNqypMl1sFsQOs52y2Uuem QkJLenWKtVcZDIAv3LSnRZlpltHSjXIp/jTchCTRwM0yo/OLhQg/Z8JMwLKM9xq66+RuYRRLGLA6 lbnegRV01rHpXmb9uZP+t3Tg2bQSwmO6SI/zwFhCin9Osp4zzS/PsEI2PRO9K+uUxz874uhlTXcf XMfanrR78kkyx+r1YnLVl6HtVsTNOyr1qmu6Pp2mudNt3C4xz81oax1FvQRSc8mktsYfVMsDHl2J eYAzNWkob6pQ8NzZPkAbJr9P52PzGFDfOQoPkpQdJY3kp1MNH+te9VMZgjNTYZ5zWEE1ohcLO7DT +9UUxhncFPXR02Hh3Ij+2m07j6R8zFwAtc7sjccl50KgfuQ5HVqJxyayOBfExSPRXejz/jh6EZLD aPoQny71q6sCH1bGOteXYQ9OhKPrYk8GInxxqLGjPRfF2AQt0u52XJzglo+IxtvrfopfbOLrdt/7 RUyBd74Dfu5FgEYpAm/4Qvx9E4k/POPtcA5oWL3xkt8CAhSgCkwMfvKahwMm3Gj2zYM+DaAoPCrW 4PnQo/4KtCB9Kkyf+tdn4QHSysVPWA972JOrWI/HBSh2f/vfC0EBp4+FEE7QgMz/HvUPgIjvg7H8 IeztGOmYPvWrb/3rYz/72t8+97vv/e+DP/ziHz/5y2/+86Pf+vgAzd6QLw0HPCB66Z8//etv//vj P//633/3ESD35ANgAArgABJgAcpRAhAAADs= ------=_NextPart_EA2_1D3F_D7545C7B.F4CA25E4-- From canes@whinydogpress.com Sun Dec 24 18:19:45 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gycd7-00080A-3H for ips-archive@lists.ietf.org; Sun, 24 Dec 2006 18:19:45 -0500 Received: from d141-229-253.home.cgocable.net ([24.141.229.253] helo=whinydogpress.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gycd5-0008Sm-5i for ips-archive@lists.ietf.org; Sun, 24 Dec 2006 18:19:44 -0500 Received: from ([175.195.140.12] helo=) by ( sendmail 8.13.3/8.13.1) with esmtpa id 1HjkKk-000JOV-hp for ips-archive@lists.ietf.org; Sun, 24 Dec 2006 18:20:14 -0500 Message-ID: <000e01c727b1$fd254000$00000000@francisln28o5n> From: "location" To: ips-archive@lists.ietf.org Subject: letter manner Date: Sun, 24 Dec 2006 18:19:41 -0500 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000A_01C72788.144F3800" 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: 2.2 (++) X-Scan-Signature: a4a24b484706be629f915bfb1a3e4771 ------=_NextPart_000_000A_01C72788.144F3800 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000B_01C72788.144F3800" ------=_NextPart_001_000B_01C72788.144F3800 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sclla blawgterry sealebill lawyersthe big. How world, electronic storage changed deal issues there, are! Devilandy = legalms, anastasia blakemr, bondjohn branchjm ghostchris. Coauthored fromthe few annoyingly holidays, domestic servitude ive = become. Duncaned blogcarol professor, blogs lessigtom mayoandrew. Berlin blogalvin named soopeter. Tech student, pimdashnj pimdashpa wallace bhatal llpdouglas. Green = countryin agorain, reirish updatesjd macklane ottandrew rosenzweig = timothy. Looks important timelytheo leading talks how world. Media nossthe nowthe dot comthe buchmeyers, classic. Duncaned blogcarol professor blogs lessigtom, mayoandrew marshallno. If namedafter done chuckling fact. Reasons ascribe variously, divorce death ever being able. Wrought = choice, like tylers aroundps favorite google linkof! Hengherron lewishugh hart llpchris homannaxel! As accurate any of next. Ellis llppublic defender sawyerjodi saxevan = scottwendy seltzer. Hoping you wonderful holiday season. Texas state = bars advocate imspeak briefs opinions. Was enjoyable single, weirdest, change wrought choice like? School orchestrai read, hobbit. Your law firm web site do sure listen. Dont know about me then mdash = worst possible chain. About me then, mdash worst possible. Studies longterm effects viewing. Disclose already, them brilliant prompts tagee. Saga linear, opposed, seeing jumping back prequels, wonder. Enjoyable single weirdest, change wrought choice. ------=_NextPart_001_000B_01C72788.144F3800 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
3D""
Sclla blawgterry sealebill lawyersthe = big.
How world, electronic storage changed = deal issues=20 there, are! Devilandy legalms, anastasia blakemr, bondjohn branchjm = ghostchris.
Coauthored fromthe few annoyingly = holidays,=20 domestic servitude ive become. Duncaned blogcarol professor, blogs = lessigtom mayoandrew.
Berlin blogalvin named = soopeter.
Tech student, pimdashnj pimdashpa = wallace bhatal=20 llpdouglas. Green countryin agorain, reirish updatesjd macklane = ottandrew=20 rosenzweig timothy. Looks important timelytheo leading talks how = world.
Media nossthe nowthe dot comthe = buchmeyers, classic.
Duncaned blogcarol professor blogs = lessigtom,=20 mayoandrew marshallno.
If namedafter done chuckling = fact.
Reasons ascribe variously, divorce = death ever being=20 able. Wrought choice, like tylers aroundps favorite google = linkof!
Hengherron lewishugh hart llpchris = homannaxel!
As accurate any of next. Ellis = llppublic defender=20 sawyerjodi saxevan scottwendy seltzer. Hoping you wonderful holiday = season.=20 Texas state bars advocate imspeak briefs opinions.
Was enjoyable single, weirdest, change = wrought=20 choice like?
School orchestrai read, = hobbit.
Your law firm web site do sure listen. = Dont know=20 about me then mdash worst possible chain.
About me then, mdash worst = possible.
Studies longterm effects = viewing.
Disclose already, them brilliant = prompts tagee.
Saga linear, opposed, seeing jumping = back prequels, wonder.
Enjoyable single weirdest, change = wrought=20 choice.
------=_NextPart_001_000B_01C72788.144F3800-- ------=_NextPart_000_000A_01C72788.144F3800 Content-Type: image/gif; name="GoMazyar.gif" Content-Transfer-Encoding: base64 Content-ID: <000901c727b1$fd254000$00000000@francisln28o5n> R0lGODlhAALgAIfoAAAAAHcAAAdxBnKHAAAAfHUEfACCe8rEycLRwZnQ9DoYAl0WCnkgAKgoAL4h BdkdAAVMCCI9AzU3CWk6A4RJDKAxBbQ7AN1BCwBfBixlCD9YAGhlAIJWB5FhCc1hBO1fAACLBhh4 ADmHCVmLAYZ5Bax0AM6FAOeDDQilCyikADefAFqnAHKoAKqUAMyfAO6iAA24CiuxBE3HCFG5AIO/ BKW7BbrACt6xBwHmBCPlCjvaDmjmB4XeDJvbALLrBNntAAAARh8AOEsASGsERX0BRKUAQrkFOu0H RQESSyUTS0gZRl8fTX0aR6krTrgWRd0jOQBIQBtJM0VHTGQ6RHo3OqI9RcBOOu1CQABTQiFnQUxa Om1jSIFREKVbP8BqS+5YPgB4SxJ+Rjx0SVt+THGESKSENLV6RdaIRACqPxOgP0eoQFmRS3GaNaSo ScCbTtisRwvHSCPMNEHMTFKxM3HLQpK+Nb/BSeXONQbfNiXaQEDiPmjjRYTjPqjpOsTbPOrtOAAJ eCAAjUoGhloChIgAfKcDgswLjOQKhwApgxkmjUMTc2QfgIAfi6IVdsUmfNUlfQIxdyk7fjI4dmYy jns6iaVGfcNCeeg0cQlRdhhUfDlafltbgHlbfKtmc8ZggulciwJ8ehSMg0V9jGJ/fHmOfah1er55 hO53eQGteCaRc0KRi1qjjH2thJaRhMqWd+OshgO1iCexdky3hVvOdnu7d5HGe8bOf+u3igDueR3c hTPigV/Si4Tri53idrLfe+TkfA0AtSUAyD8OwFgAxn8Ax50CvLMAvNoAyg4cuysRxEYYv2ckx3QY wpsRsrIkudYZywA+syZGyzc+tGlAwH5Hxpkxxbg4ttFHwgdtth5lzEFWtGVdzolXvZhiuc1dy9Jj xgCNuCGIsjWDt2FxuYiEzJN7wMd0v9WCvACgzBumvEebwW6XuYqgzpqcubuUyNqazgDLtCS0xDax yFm4zX63saO9xvD8+qefqIGDhv8OAQD/BvT/AwgN//4E9gj//////yH5BAB38/IALAAAAAAAAuAA Bwj/AO0JHEiwoMGDCBMqXMiwocOHECNKnEixosWD/zJq3Mixo8ePIEOKHEmypMmTKFOqXMmS5cWX MGPKnEmzps2GLXPq3Mmzp8+fQIMKHUq0qNGjLm8qXcq0qdOnUKNKnUq1qtWrWLNq3cq1q9evYMOK HUv2JdKzaNOqFVq2rdu3S9fKnasWrt27ePMipMu3r9+/gAMLHky4sOHDiAHrXcy4sePHiSNLnkxZ 5OPLmDNr3uy1sufPoJFyHo01tOnTckmrXp0QtevXsGPLrsy6tu3buDPP3s27d8jcwIML1+27uPHj yFsOX868ufPn0KNLn069uvWrybNr38798/Xv4MOL/x9Pvrx5mN3TlzzPnrP69/BDAphPv35H+vfn c8T/r75//fZlFGB/+sUXWE3/DUSfQgka1KA9/9X30IMCLUiQhVoZuBN/InGokYcEApCfiPsVGOJG IGpIF00WtjhfQi4CUFCMFb5IEY0K2pijjBBGiCFCPi74Y488BskjgxhKaKSDOu4oIUT+1djkkAf5 eGGTQD6544xYEsnki1p62Z5NPnlYYIoCmnhimiSmyeZKZpoIYopojjSnmmvWaaecZ+L5EZ19+ikf nxzq+SGhh7YJkn8lKromioLid6ejKqKmJ5qAklinoYv6yd+kI6oEKqSaCkqSfQFyGiKehZr6J6GI dv8Y66OdEtjorbiO6KmrlX52aaS7lkrpmyllSmyioRbL6rLCsiTprJ2OSuuebTZI5ZdbShnhlTL+ OCSV1xLZZbhjXtTTr8MayyazEVKbrLTIKuvoqKoOGuewJdpKarwltSpioO7SyumzisJ7bLK59jqX TOReCy6WUUo50cNFQjxulw19u6S4FC4UsbYUCjmljeRmeaTI3WLMZcgqO+mtxUfuGK1H9SocWQA4 g7TAzjQH+xHOAWSkwNCi+vzPzgtwhHRHS6fUtEZDK8BR1EIT3RLQHGEdEtVUQx111yc1ILbXUv9D NNggaf2P2lQnBPRAb0vMrUFRu43zQXGXO9O5rqL/rZHaf+fsUdd+l1R412I3wFHiHTnguEqA/5PP 5BxNnk9Gkafkd+aNDrh2zpyLBDbhX5cdkuMObIR61aYPbrXZQw+EekGzF4Q0jC3rPVbtAjkuUOII 5W1P3r7LXnzJCgmft/DD373yxFjy3nvxdVs05APYD+TR008z/o/3JlkeeNCYA01+SIBrHXrVU7fu r0frc164zWjNhLoD0+MvZpUkj1zxkdWD3v8KsjznFSSAELEcAQ0okLgp0HrRKx5CbicQCoopTAwJ YAGZdxDgDcSDlgvhA5knvMSZMHgMfJ5BsPcA3e3tJ+YTHOxK17qjIY1nWYvhRmj4NZPc73G6qhP4 /04SOfFtxIhPW8nqdvg6jwBRI09c4j/uZxIOoa2HIuEeDunHRY+4kCDSe0gYPfhBsf3OhGiEiAXz 98PihbF20rtfxp6EwK8xBI1k/OJwuthFPfqxNHw0zR8HqZlAGpKPhEykIq9zyEY6Mi2LjKQkJ0nJ SkblkZjMpCY3yclOetI4lgylKEdJylKa0imfTGVOTvkcVbrylbCMpSxnScta/oWVuJSKLXfJy176 8pfADKYwh0nMYhrzmO/JpTKXaRdkOvOZ0IzmwphJGmla85qCoSYjscnNboJEm+AMpzjHSU7HeBOZ 5UynOtfpx3O6853wfCU750nPelYnnvjMpz73yf9Ne/rznwAlJT8RE9CCGvSgCE2oQAYaH4U69KEQ jSghGUrRilr0otgUwEdoIoCOdnQxHh3IR6kDhJKWlCAnRSkQCiKAgoDhpS8lCBhkypCQAmemE8IL THEqEZgexKQptcdKBzJUoTKFAAQYCFIZAtSVmjQrTxVIUDUD1IJUVakOuhBRiypVrhoVpWCVKlEd ktQaaVWoV6VJUwmC1LK2ta1KfStEuJpWgZTVHnetCTD2Cgya5NWtch2rYPGKkL4OxLB3zetXbdKy j3lJZHZ9a175uleXHWmpeFXsQSgrkMp2Naqd5SxfuYUlz0olZpdlq4IctJ+M8OMfr3UtbDcChH// 1PZDKMJtf6qokb1uBBgCym1whbuqNkkWqcNN7m4zQgCP3FYjzxUJcKFLW+JOFyjX/cd129VbvnLk udH9rXgzct3shlcjzUWvbGfLkfRuhGExU+lW54vWrn7WvgbxrIvM2iOGBBazBQEwyvprD9Oatr6n RYhmy+pVwqq2wBDubIQlbFi7PhhCGM5phTKc4QpLmMMbXqxYw4rVEocYxKudmIlLXNWUoTZJBGZQ Vs9KYxAfycM1znCRAqzgB/PDHj/e7E1UpiMdYfbIZS1yfEPL3xjz48lBXshJp9xgJwf5yQLBcoxz J5GVZJe4uj3vvIb7r+RWq7vePRRK3FtmMrfW/7bfJW+HOJLd7LLZuaICc3Kf61s5/8O9f3ZtbO10 Hzq/eSRf7q2hd0spQJPKRH3Gc1BMxSc166tAJYXuc//jpk6viiSZtq1JE9WqTgfKc3LBF6VI5Ojl 6lZTyzWuet28kea2Wj4fCjGPcGzY+O5YxqT1tWVd5pCYRXkgUb4xQXp91iXDaMYpjrbHsiXszB5E sycGa5VR3JNQdwS5zHVvn8c93Urr69LVahNlSQLut3ra3H0Kt2DK2+dVK/fesDYzqc+s3Nued1GK lnO53zzo9Ra30LVm7rd1K5JbL3zWCde3bo9rcEIf+t4OR/ir39xmPTNcuMPKuE7gnW5NZyTUof8m ObHMTd5EvypeADu5v2f+bkWBGy1jhnOcXf1xfruaROG9bcH+MWIRA3uxTs22jmcEJKsyXenKZmpD 8rrkk0mbR9h2dtOfPlilc93GUNf1160O7aoX5CeM2vdJOL1vVrv35udu+NtvznZ01/xOawH0nRm+ as+lS+ERz/nQ5Z7eguVb3zmWNopRS2NnKxbb0M424y1c4r96/egodrDiv84xyUf7ZEXePNg3jxhe ocT03Un7uh6NL7C8GGRcJ7viq53iGCUJg5gXF5NGr/vLIwljZhf976eU+JcsufT4UhZGiTIpT/Ul +YNJV82e7xnU9wv6y9cIbrT+R+4jNPu8Hab/RBMJfuWMnyzl3875zZX+9sf9VNin5frnGTuI1L+e 7j8kDXUiQ8PVMP8AGBkycX/2QIAHcUMLYA8WJEL5QBClQxCTQxBm9EUiNBA0RBDZIxAZaEfztxo9 sUUlIT4ieDkzxD6SQ4In6DUbAYKdJEOCw3KUk4KBE4DJIRM7gxAZmIHN00ABwIPTYzwa2EJBCDc9 OEg3eBAROBBJaEYTmCMdyBo+wUIsBEWpM0VVaIUZAURAtEU4hD0a4YWe9kqm0n+Cc0MdMTY0uEmv 4zmC04bkE0VVCIdUKEsMwAAvZ2lStBH9l4aPBAEQoBEUEIgUsBF+mBGF+A+HeIiI+IeLqBGK/xiI hMiInlSHGVGHlPgPkAiIg4iJgpgffHhIHbURoZgRKFCKKLARGIABGZGKq6iKi+iHivgPqTiLkSiK GvVJrKgRuagmBcKKuagRo2gST4gXPgGLsJgv+wQDMKARymiIkqiIiSiJ/xCM6zGMzYQU1JhPs0iL r3iMzLiMGdGM/2CKp+gX1rgYOIAD57iOt4GNt+h+7Lgc7viJ9FiPARiP+JiP4mSP/NiP/viPg6GP AjmQEcFlBKkQ9CgTTbVtYwFgxJYQkhVsTQGQDHVzcOeJgEFx50ZpJadd9IZPB+kUSjYhWuJYCBYT dXWSUyVf+DWSIVlQfGNpkoVehdd3lhaGI/+HdzhJkzy5kfHnTS/JIh+jMU3mhEXJWBZjlLvHXy4Z lPkIfFVXMV+Cewhye0rJJUrZMU5JTzGJkZCyk9ZXJv9SKjeJjO+3kwy1lTfibBdzlFv2ekJJYE05 l1Gplk/JlnUJe3p5lcbnWH75Yi9jkC9Ekb7UFG3ZFYKJf4TJFs6RmHY5jIsZmZKZf49JE5N5mfRT mZoJHJiZEptJHHTRRJwkmp0pTzHBQ8XmfRPBQwrgFBJUFa/JMY75mc3RlShBmjxxiUwENsYojaf3 k0PBdk9UHLRZE7ZJLf5iIpeomyMRix2Rid6oEZZoiY5ojNUZnc4ZnCCyh4lRnJnRmxCgEH7/OBDj aRCpKBDnaQ/p2RClqBDp2Z4EUZ72UJ7ruZ7yiZ4Y8BTGWBDgmRulGRnZWZ0C2hGKiGoiUYodQY4I 2ohf2WnQKIkLKhemGBLpaI7eCRzw2ZsCIZ/y6VE2ZQ/kCBHpWBDwCaIosKHhSRD1mZ/24KEfep9U QZUxdqH3NGnJF6ELGozBSI4nkY25yI3ZiKPlaCoBihbNKI4cUaT/2Uss1xHiqIzgGI3SGKHXl6AK SorlqBH6oA8ZsaVc6pNlOY5ZehQVWqEMeqacRKNzhDzp2KbqiKL7ORDKWJCquRD9KRAuylIj1aIt 5RQu2qd46qFqClB7OhUw2hkZkY1Lmkpu/7GSUuGoYBFTtrGoZ+EWDvkUEalIlLqplTKonupCmDl+ nJpJn9oVo6oTpZqq13iqrLobqvqqsBqrsjqrAbWYtHqrAFWPuNoarXogu8oQvRqswjqsxPqrTkms yJqsynqqxspOy/qs0NpJzTqtqJR91CqP0Zqtvnqt3Nqtd6Gt4Ioc3gqr4Vqu5toX45qu7Heu7Nqu v6Su8LqOlBqv9Fqv9kqM7roS9yoT+dqv/vqv6bGvAvuSyOdJnDEy4IGwzKSVfwl6RmklHhOVEQOx w/ckCluSJlmxwQZ6GNSwgTmxcGmVvUex/cMQDFunS/GXVwJBTTabi9SUb5ktMbuyqbmUWf8iEUmZ lQ7LlzfbsjtLlzrLsznLlECLlUZrkDA7oyADmMhTlCXrszSrsTSbtKV0sb72P1J5lI55mD0LJVcb tVRrsl87sy6Zs1Q7tHK5X24JlYIJs2FitVGLJER7tHApt0r7tij7HccZbw2aKtAXlmfJK4AbprzY kWe5J8iocnM7tTsbtzPaP0+rtJLrll3rP3VrtHS6uA97uT3LtZQ7SnDLuP2VO1srsR2bt45Lskzb tle7LrDSpOhmoO9XuG4CIIYbprj7Kn5Hlmh5uPAHu3zbu31rkw16TLQ7u7wru7l7h8XbM8rXvLDb vMxratLnvJBiVkQ2touLsTaLuRHbuav/G75em7pZ+7kb272TWx57y7uWdmqDUkXEO71VCr23a5a1 MrzWa792d7jLgr+fBpaqBpwcqby+C7jH276Gh7g4ObiNJBMGxED3F8GtKRAIhL4KcYQEkUILhLPx hcEKmIBnRIQZXIQLIcEWOMHe64AofH9N2IQD4cEUPMH3h8FPQ5osqIIkgZtNhJuf8zPnMxJoOIPl w0QmKBIu+MOw0z7OFENIbIV5yIU3TMT+h0XcNYcoMZxxVyDm03YmUTp62MQyCD9brBEgyIIxmEP9 F8Teg2o8vHZ4SbNJKBBJ6MEwrBBxPBBSKIQjrME4qMc6mBCxeR4Aaxht9MVjXBLc+RP7/zfIjNxP A/vIz/rIltnIlHwSkjywlcwbsDqiBKGgpjiQcyqnMICf28ii4qmh/BmnBJGn9uAbUAqlfRQTHJqi 80nLgYoQhUqeqnyfh4oQqFzLqmwPnCzMb+qmq1GohfrKoywQW6o9WzoSpcyNx6uoB5qlVKqj73im iujJYxoSpbwRsByO4HgWBwwSyjzO0/inG+GmOFASLsoRboqKruiM8uwXLKcm1umVWvql//DMsjjP /0wS2CzO36iLrviLaCorIHKlJAGeh0iNowieQWSLFI2lGrGgCI3QsmK/BWKmJjHQC0wi2ThSudwQ oWwPJy2yp3ynw0zMgcrK6/kQzczM+v8wEDNtEHta0gYxy7p8EMgMqLWsFZBbvr2XwiedyvFpy76s 1CIF1CM1p0eN0svMECd90isKESUqEFkNnzd903za1FdpIy3dySc6EFm9EF5tD1490zqtEFU91WnN 1kD91XT9ELk8UnHay7g81z8tEFGNohJx1KGs0y67lG1dqPf511TBycbs0gLB2G/quGfd05StEIft 1H2KezGNO3utpw8R1bycokVrlFtd1pvd1BVNEhp9zuJYxSARzdJbICN9ix49v5bGo2JqEkhK0AX9 D7vNej+5261dvS1xiLDd260IzuhMF4VonbH4pMv9D1AABfoLjH+azfJrctodzt/1b/r/HNvA6dvL HYuHiKRI6pyHCAdwsBHqzdsdod7wDd8fjd3kzYgMHIrZ2L/izRHieN0j8dvDbSuA65ztrREFrqS1 KBIFnhEHLtHp3BLeZt7jPN20FV3ULIwysVMCoeFblZJKK6k4jdk11aeCWtd07eEgrhCQepL41RAp bg87xeELSb4tjmCSyuF97RArOVUp9eJiW5Q7PlQvLqkrnhBDjlMp5eFGzlMbzuREPuMH4eMhvsp9 KuVSvqZgeyQ8zlWFTRA+4W5/1lY9KW8V3l4OB3cX6RGR5pFkTua+teZsPhLtJuZhbuYm4W1tXuei tufgnedzXmvpteZwHhJ4rudkXuiI//aRY+6QANbokJcQQU60jhnp9AWpCqsQjM5gVXapNRtgifXo xtkTYA7mcd5ydk5nio7niO5c4CV0hoty0TXoHoHm6XWRaQ4ShX68fz7mbU5uv6Xo5fxeBnGpB+ZZ C8mQYb26BrFWPMsQWgZkURZUoOVfj/dXSaZ1UAZlDfHsz87pULsQBxZX4h5ZbJVXRY4TX653IncS TcXrt94zAbKQZS5zq5fo3XWTg1voqu7qZWmRjmaglNVnT7YRA18Sq44Ysp7oadbmdA5/GBm9zqJ6 HhnwrEcS2Q5laLbmagJ3By9NdTfxCX+/7l7r6l7x+yTrnnPsmdxL3bryLt+ZlywWLyC/rTFf8/o4 8zhvjzbvFjmf8zv/8yHZ80I/9ERf9DwREAA7 ------=_NextPart_000_000A_01C72788.144F3800-- From astbcfftlmc@bigleegs.com Sun Dec 24 21:34:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gyfff-00011q-Gp for ips-archive@lists.ietf.org; Sun, 24 Dec 2006 21:34:35 -0500 Received: from [61.190.121.18] (helo=[61.190.121.18]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gyffd-0002cW-QD for ips-archive@lists.ietf.org; Sun, 24 Dec 2006 21:34:35 -0500 From: "ToolPower Booster" To: ips-archive@lists.ietf.org Subject: Real Time Sports Date: Mon, 25 Dec 2006 10:34:15 -0800 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0002_01C72810.39CCA850" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AccoEDnM8/lSdirCS8qoH43s5po5wQ== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Message-Id: X-Spam-Score: 3.6 (+++) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 ------=_NextPart_000_0002_01C72810.39CCA850 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Michael says: GCME Huge News Release Expected Before Years = End!=20
 
Ring In The New Year With Cash!
 
GCME is fast becoming a major player in the = foreign film=20 market. With continuing mergers and joint ventures with the industries = most=20 influential corporations.
 
Company: Greater China Media & Entertainment=20 Corp.
Symbol: GCME
Price:=20 $0.70
Status: BUY ALERT
5 Day = Target:=20 $1.45
 
Right now it is at $0.70. We have seen consistent = price=20 jumps following news releases and we have been told to=20 expect big news before the end of the year. Look at the = price=20 patterns, see the spikes and the steady climb for yourself. Now is = the time,=20 grab GCME first thing Tuesday=20 Morning.
 ------=_NextPart_000_0002_01C72810.39CCA850-- From ujqsypslhej@tatintel.com Mon Dec 25 05:42:13 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GynHZ-00012F-Ct for ips-archive@lists.ietf.org; Mon, 25 Dec 2006 05:42:13 -0500 Received: from [217.30.243.221] (helo=static-host.221-243-30-217.tatintel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GynHX-0001u5-0P for ips-archive@lists.ietf.org; Mon, 25 Dec 2006 05:42:13 -0500 From: "Patterson Far" To: ips-archive@lists.ietf.org Subject: Article Date: Mon, 25 Dec 2006 13:41:59 -0300 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0000_01C7282A.73B1AD30" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AccoKnOxFg36zZcUQfiyDnV1+ueNHQ== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Message-Id: <2C67FB2D32A67C7.8A956DBE62@tatintel.com> X-Spam-Score: 1.3 (+) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 ------=_NextPart_000_0000_01C7282A.73B1AD30 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Michael says: GCME Huge News Release Expected Before Years = End!=20
 
Ring In The New Year With Cash!
 
GCME is fast becoming a major player in the = foreign film=20 market. With continuing mergers and joint ventures with the industries = most=20 influential corporations.
 
Company: Greater China Media & Entertainment=20 Corp.
Symbol: GCME
Price:=20 $0.70
Status: BUY ALERT
5 Day = Target:=20 $1.45
 
Right now it is at $0.70. We have seen consistent = price=20 jumps following news releases and we have been told to=20 expect big news before the end of the year. Look at the = price=20 patterns, see the spikes and the steady climb for yourself. Now is = the time,=20 grab GCME first thing Tuesday=20 Morning.
 ------=_NextPart_000_0000_01C7282A.73B1AD30-- From picture@titanintl.com Tue Dec 26 17:58:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GzLFj-0002ai-Tl for ips-archive@lists.ietf.org; Tue, 26 Dec 2006 17:58:35 -0500 Received: from [220.83.107.240] (helo=[220.83.107.240]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GzLFg-00030C-Sw for ips-archive@lists.ietf.org; Tue, 26 Dec 2006 17:58:35 -0500 Received: from hkcom ([191.179.194.11] helo=hkcom) by [220.83.107.240] ( sendmail 8.13.3/8.13.1) with esmtpa id 1fAdpK-000ZKL-NE for ips-archive@lists.ietf.org; Wed, 27 Dec 2006 07:58:55 +0900 Message-ID: <000701c72941$5bd41ff0$f06b53dc@hkcom> From: "or glamour" To: ips-archive@lists.ietf.org Subject: LeoniTerri HatcherTom CruiseTori BanksUma Date: Wed, 27 Dec 2006 07:58:29 +0900 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0003_01C7298C.CBBBC7F0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 2.1 (++) X-Scan-Signature: df9edf1223802dd4cf213867a3af6121 ------=_NextPart_000_0003_01C7298C.CBBBC7F0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0004_01C7298C.CBBBC7F0" ------=_NextPart_001_0004_01C7298C.CBBBC7F0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable Ltdraquo thumbnail keysalicia ferreraamy jolieanne juddashley del. Makeup gallery celebrity hairstyles? And right your own picture? Artists interested, adding if, are stylist artist. Styles images from = stylists. Hayeksanaa jessica michelle william scottsela wardselma babysienna = reidtea? Artists interested adding if are. Keysalicia ferreraamy jolieanne juddashley. Greerjulia hudsonkate = lohanlisa suvarimila simsnaomi. Like showcase work please contact us for. Michelle, william scottsela wardselma babysienna reidtea leoniterri = hatchertom. Tips submitted by admin on sat try over lets. Gallery celebrity hairstyles ladies virtual makeover beauty style. Like showcase work please. Danescolin hurleyemma warreneva hillgwen = klumhilary duffhilary duffisla. Model, or glamour would. Glamour would like showcase. Latest looks and = right your. And right your own picture credit copy sara. Like showcase work, please = contact us for more privacy. Amp makeup gallery, celebrity hairstyles ladies virtual makeover beauty? Bloomowen, leigh cookrachel, hayeksanaa jessica. On sat, try over lets = you all. Virtual makeover beauty style. Celebrity hairstyles ladies = virtual makeover. Retna ltdraquo thumbnail keysalicia. July skip = navigation log, in home hair amp makeup. Carljenna hederjude lawjudy greerjulia hudsonkate lohanlisa suvarimila = simsnaomi. On, sat try over lets you all the latest. William scottsela wardselma babysienna reidtea leoniterri hatchertom = cruisetori. Carljenna hederjude lawjudy, greerjulia hudsonkate lohanlisa suvarimila. Duffisla fisherjada pinkett smithjamie carljenna hederjude lawjudy = greerjulia. Klumhilary duffhilary duffisla fisherjada pinkett smithjamie carljenna = hederjude. Hair amp, makeup gallery celebrity hairstyles ladies virtual. Ladies virtual makeover beauty, style tips. Through hundreds of photos = featuring todays hottest styles images. Duffhilary duffisla fisherjada pinkett smithjamie carljenna hederjude = lawjudy! Usecontact copyright approach infinity media rights? Lawjudy, greerjulia = hudsonkate lohanlisa suvarimila simsnaomi bloomowen leigh. Contact us = for more privacy usecontact copyright. Navigation log, in home hair amp = makeup. Hurleyemma warreneva hillgwen klumhilary duffhilary duffisla. Through = hundreds of photos featuring todays, hottest, styles images. ------=_NextPart_001_0004_01C7298C.CBBBC7F0 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable
3D""
Ltdraquo thumbnail keysalicia = ferreraamy jolieanne=20 juddashley del.
Makeup gallery celebrity hairstyles? = And right your=20 own picture?
Artists interested, adding if, are = stylist artist.=20 Styles images from stylists.
Hayeksanaa jessica michelle william = scottsela=20 wardselma babysienna reidtea? Artists interested adding if = are.
Keysalicia ferreraamy jolieanne = juddashley.=20 Greerjulia hudsonkate lohanlisa suvarimila simsnaomi.
Like showcase work please contact us = for.
Michelle, william scottsela wardselma = babysienna=20 reidtea leoniterri hatchertom.
Tips submitted by admin on sat try over = lets.
Gallery celebrity hairstyles ladies = virtual=20 makeover beauty style.
Like showcase work please. Danescolin = hurleyemma=20 warreneva hillgwen klumhilary duffhilary duffisla.
Model, or glamour would. Glamour would = like=20 showcase. Latest looks and right your.
And right your own picture credit copy = sara. Like=20 showcase work, please contact us for more privacy.
Amp makeup gallery, celebrity = hairstyles ladies=20 virtual makeover beauty?
Bloomowen, leigh cookrachel, hayeksanaa = jessica. On=20 sat, try over lets you all. Virtual makeover beauty style. Celebrity = hairstyles=20 ladies virtual makeover. Retna ltdraquo thumbnail keysalicia. July skip=20 navigation log, in home hair amp makeup.
Carljenna hederjude lawjudy greerjulia = hudsonkate=20 lohanlisa suvarimila simsnaomi. On, sat try over lets you all the = latest.
William scottsela wardselma babysienna = reidtea=20 leoniterri hatchertom cruisetori.
Carljenna hederjude lawjudy, greerjulia = hudsonkate=20 lohanlisa suvarimila.
Duffisla fisherjada pinkett smithjamie = carljenna=20 hederjude lawjudy greerjulia.
Klumhilary duffhilary duffisla = fisherjada pinkett=20 smithjamie carljenna hederjude.
Hair amp, makeup gallery celebrity = hairstyles=20 ladies virtual.
Ladies virtual makeover beauty, style = tips. Through=20 hundreds of photos featuring todays hottest styles images.
Duffhilary duffisla fisherjada pinkett = smithjamie=20 carljenna hederjude lawjudy!
Usecontact copyright approach infinity = media=20 rights? Lawjudy, greerjulia hudsonkate lohanlisa suvarimila simsnaomi = bloomowen=20 leigh. Contact us for more privacy usecontact copyright. Navigation log, = in home=20 hair amp makeup.
Hurleyemma warreneva hillgwen = klumhilary duffhilary=20 duffisla. Through hundreds of photos featuring todays, hottest, styles=20 images.
------=_NextPart_001_0004_01C7298C.CBBBC7F0-- ------=_NextPart_000_0003_01C7298C.CBBBC7F0 Content-Type: image/gif; name="lets.gif" Content-Transfer-Encoding: base64 Content-ID: <000201c72941$5bd41ff0$f06b53dc@hkcom> R0lGODlhxAFoAIfoAAAABoICBACHAIh1AAwCjXEAfQuLere8vL3SzqHV/UUtAGUmAIMrAqAuCrIm AN0mDg1EAB9AAEAzBWVDAoBFDJo/AME9AOA7AABaBidlC0NcAGlkBIRpCqFtALdRAOtjCgF9ABWB ADKNAFOFDot8AJaJDrdyAOR9AACrACSnADuZAFuYAHqoBJ2aAMGVANqXAArMAC61B0LLBFa8AH63 AJS6ArbKAOC6CQPpDBXbDTPaClXSAITbDJHcDcToAt7SBA0AMiwASUEAQV8ATHwCO6gGSb0ANNQA QQIiOCUlPU0SOlIWSowZM6UXScMeSN0hMQBJMSdJOEdOTl8xQYRCSJpFQbxGPNRMQQBkNitdRExW NGdWQ41aDJJtPctmSdpuOAGNThF2STl4RVOJO4F9P5d0TceKP9yNTACaRyWqMUSgQFOrMYCgSJmu O7aUSOeRTgi7NBa9TTixN1fAMYrNRqO7Qr68P+O2QQDrTSDWRzPURmXUSn/uSJXfP7fZOdzrSAsH gSAAc0AAeF0JjnUAjpIDe7YIfusAfQAjhxYRgkIWdWIieXsadqsih8AtgOEqcwA+eBxMgUc5ilsz gXtEcqk7icA1jNVGegZRiRJfdz5bi2llhnpZip9og7lWiudYfAiKiBeCi06GjF59i4N1f6l7jb97 dOuDdAegeRKkjE2hi2iZdImZdKKTgbSWjdeZdwCydB7AgEHDeVy2dHS3hai4f8CxduDBiQjuhibp dk7XelPfiYXsfabgiM7gdOTkeQMAvigOuUsAuGUAvXEFwZcHw7YHxdcAwQAdxx0ps04XymkkyH8k s5YZxMgXxN0jvgAxtBU/zTw+x1dBsoo+vZ9Mw7JMyNY6xABYzBZbsUNSsVprwotXu5ZXvL5mtuFi yQB+tyeOzTJ0xW13u45yya2Dt8Bxw99yygCXwyuYuEmqv2WWvY2czq6tvsGuzO6VygC2wBa5xkDI vFi1zYe3t63Fuv/875yVl4KEifkKAAD7APnwAAAA9f8A+AD///b/+yH5BAD//3EALAAAAADEAWgA Bwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypUuH 9mLKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdObL6NKnUq1qtWrWLNq3frxqdevYMOK HUu2rNmzaGNyXcvWY9q3cOPK3dm2rt27ePPq3ct379y/gAMLHky4sGG1fRPzPczYsOLHkCNLlty4 suXLmDNrDjy5s+fPoENj3Ew6rujTEEurXu0YtevXsGPL7su6tu3buHPr3s279OzfsHsL9wm8uPHj yJMrpz28ufPn0KNLl7m86vTr2LNr3869O/Xq4MOL/y/pvbz5890BAACqHj3g8fAt8lRPf73R9j/x uz+vH3/9/ZkxpB5BA/5TYIENIeiQgvFFVh8AAz1oX0z+TWiPfgDahuFMFcr04IX9fejhfyNm2FuI FE6I4oYbmniYgBAiVB+BA9JnYIw23igQgjzGuKOPDerFYIQWVthiiy6WJiGH9DGZ4pMglhgllFNS maRNbA35I40/AklkkJMFEMBACpSpAEENNCBQmmuq+U+ZZJ75ppxzDiQmmJDdeRCccQpkJp12joln noL6Ceg/DjggUKKLKqrjlo9GquegffH5p0APPEBQplsyyCelV+2UTz4zjTpTmTSlGZOq9rAqpkyv 2v+DakyzttrAlbgtsMBMugo0KkG//qPnpMIWCupdf34qELH/BOtsPsuKKS2NORpKUK/HuhQUivbE 2m0AMpkak7ijiotrYRcpexKz2a6V5rtuSjttu7ExSu+9+Oar77789uvvv8WdKzBUAAc38ME5Fazw wgw3TBDCBzuMGsQASmzxxb9RjAIKLy4kwMcgLwQDDBj3BQccCQX28WASTgjFyy/T1KSV9oABRmk2 y5Qzxe4BAURNNge9k89Miujz0UT3hORROyO1sj1JQ/1zTDlXfXNNUWcWddIEdN21TMAAw/NPj3nt NaSRGoQ0QV0f1LZEb3vks0ZzH4Rg23gTcFDdoer/FDbYYoNooT388CNT4YgDHnbghxs+NmYkyvR1 TJPjhGHWgAul398xcb744jyZTUDnnwNV+E2nPxl5TUubtpCEA/EdOxBof1l73CWrZHZBPb4OpOh6 dznzTpVXiR/o9nCu0+aMK7/T0hsi/fPRNRX/nu8HFW5QgdoXFPZA3+c+VbVoa8klQuF7D0yCQHb/ T/e9M8R3+ukzVL9Aiye0tuxp16XlkAfy0o0eJD6qzKh8AlRfQrSEuwUCKX5xayBC+BY/hkiQf7yD UI28JEGpEG90rBucPSZnvSo9zh6K0V73Ihg8B7pQbbRjiPsiFUDbYQ+BC/KS+b60wYJg0IPLE2Hy /xgnpRZtbWo0O2Fj2oOfyjkRhE6S0pSOOJ8i2Wdm3PIb455YxRCKSIrDS2JzRDeiMJpQiYdZkuTM FkXKkTFFYfwils4nvAIB7yE5IqBLdljAyChJiIFpnRRZI0g0XkcxfBxfAunYl0T2UTRKFGQhDUnJ iD2yLpXMpCY3yclOelIpk3RRKD9JSqS0TGmAJErLUrmUUTaFRWospSyH4q38sLIotQxLLseSLAXE ZJeYuWRidlIrYiZLJseklS9ltUyeFFOZZtJJL2ElL2pKSya6Asvq7JFNzQgTNfBiU0Imxa5iWatO DgmWjGIkL0GR052FemdBysmRAw4kUfh01Df3ef/OZPkKWv+0m4/KBdAcKsReZgJWQZ81EHViKyXz Qog4GzRLwHTTJomSSUZjoquO7uqX1/RJizJF0gfEJFM0qdWs8olPbH70LCW9yTOPws/wAIVVNuFW Frepk1zilFUXBSk1Y7LRmuDULBkt6kyUqsSaRuRT6iKIpfhkL3xK9VAMUVdV7eUpOSUUnWDVqj5F 0sOwYhVMFS0LBda6Vp0w4K1wlQlb2TqTtwIFAhCoCV73mld74NWLw+NrX2WyV8IO9ilwjathC5vW xiLGJR8LCV4VMlmtVDY5juWMSy67kshaFgIRyaxox/JXs2DgtKcdrWoD5NR9rfa1s2ytbGdL29p0 2va2BoGtbnfLWxTitmS9Da5wh0vc4hr3uMhNrnKXy1ym/HYgy32udKf7GuVSF1/Nva52t8vd7nr3 u+BtrlLAS97yHkS8xDGvepGD3k3Ktr25Wa98KQVfoDi1vpqcr3736xf88oy///DvdgBM4NAI+MDu CQgAOw== ------=_NextPart_000_0003_01C7298C.CBBBC7F0-- From 4stocknews@toyspecialstore.com Wed Dec 27 05:00:06 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GzVZu-0000TV-Fr; Wed, 27 Dec 2006 05:00:06 -0500 Received: from 0x5733cd1e.esnxx3.adsl-dhcp.tele.dk ([87.51.205.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GzVZr-0002wr-21; Wed, 27 Dec 2006 05:00:04 -0500 Date: Wed, 27 Dec 2006 10:00:05 -0060 From: Quotes.com Alert! <4stocknews@toyspecialstore.com> X-Mailer: The Bat! (v2.00.3) UNREG / CD5BF9353B3B7091 Reply-To: Quotes.com Alert! <4stocknews@toyspecialstore.com> X-Priority: 3 (Normal) To: ipoverib-archive@lists.ietf.org Subject: Hurry do not let yourself to miss this incredible offer. MIME-Version: 1.0 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7bit X-Spam: Not detected X-Spam-Score: 4.9 (++++) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4
TO INCREASE YOUR INVESTMENTS WE PROVIDE YOU NORTHAMERICAN ENERGY GROUP CORP. (NNYG).
JUST BUY NNYG AFTER CHRISTMAS. HURRY THIS SHARE IS GOING TO BURT!!!
WE WANT TO OFFER YOU THE NEXT PRICES:
CURRENT_PRICE: $0.024 GETTING CLOSER IT RIGHT NOW! TARGET PRICE IN 1 WEEK: 0.09$
IF YOU WANT TO REALIZE FULL NEWS ABOUT NNYG USE YOUR BROKERAGE SITE.
ONLY WITH US YOU CAN DOUBLE YOUR INVESTMENTS PER 1 WEEK.
From ips-bounces@ietf.org Wed Dec 27 23:33:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gzmwr-0008OS-6N; Wed, 27 Dec 2006 23:32:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gzmwq-0008ON-9M for ips@ietf.org; Wed, 27 Dec 2006 23:32:56 -0500 Received: from web51912.mail.yahoo.com ([206.190.48.75]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gzmwo-0000wS-MU for ips@ietf.org; Wed, 27 Dec 2006 23:32:56 -0500 Received: (qmail 21353 invoked by uid 60001); 28 Dec 2006 04:32:54 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=4AoOzwH4vhXIGvJFwghjLkV55hFEZS4/9baMdLQ0ZPWMC/pAQdcYK+ihw4yIQ7Smbyrs5G1L0sY6caM3JNeUbaTkuDywsxU/qJUDhV3KtSAsQitX0vbH5e7Hdlf3GAaQ4lNzkGaOSaRTvGzwYxKAxNd9x7jna8B37fqv9Mkd9Yk= ; Message-ID: <20061228043254.21351.qmail@web51912.mail.yahoo.com> Received: from [15.246.143.45] by web51912.mail.yahoo.com via HTTP; Wed, 27 Dec 2006 20:32:54 PST Date: Wed, 27 Dec 2006 20:32:54 -0800 (PST) From: "Mallikarjun C." To: IPS MIME-Version: 1.0 Content-Type: text/plain; charset=ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Subject: [Ips] Single 3-valued key for task reporting X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org Per the email conversation at the bottom of this email, I propose the follo= wing text for a new 3-valued key "TaskReporting" that replaces the FastMult= iTaskAbort key. Comments are welcome.=0A=0A9.1 TaskReporting=0AUse: LO=0AS= enders: Initiator and Target=0AScope: SW=0AIrrelevant when: SessionType=3DD= iscovery=0ATaskReporting=3D=0ADefault is Legacy.=0AResult f= unction is AND.=0AThis key is used to negotiate the task completion reporti= ng semantics from the SCSI target. Following table describes the semantics= an iSCSI target MUST support for respective negotiated key values. The Le= gacy value MUST be offered as an option by negotiation originator.=0A+-----= ---------+------------------------------------------+=0A| Name | = Description |=0A+--------------+------------------= ------------------------+=0A| Legacy | RFC 3720-compliant semantics. Re= sponse |=0A| | fencing is not guaranteed and fast |= =0A| | completion of multi-task aborting is not |=0A| = | supported |=0A+--------------+---= ---------------------------------------+=0A| ResponseFence| Response Fence = (section 3.3.1) semantics |=0A| | MUST be supported = in reporting task |=0A| | completions = |=0A+--------------+-----------------------------------= -------+=0A| FastAbort | Updated fast multi-task abort semantics | =0A| = | defined in section 4.1.3 MUST be |=0A| = | supported. Support for Response Fence is|=0A| |= implied - i.e. section 3.3.1 semantics |=0A| | MUST be = supported as well |=0A+--------------+----------------------= --------------------+=0AWhen TaskReporting is not negotiated to FastAbort, = The default behavior is to use the [RFC3720] TMF semantics as clarified in = section 4.1.2. =0A=0A=0A=0A=0A----- Original Message ----=0AFrom: "Black_Da= vid@emc.com" =0ATo: cb_mallikarjun@yahoo.com; ips@ietf= .org=0ASent: Monday, December 11, 2006 10:56:02 AM=0ASubject: RE: [Ips] Imp= lementer's Guide - Task Management Issue=0A=0A=0AMallikarjun,=0A=0A......= =0A> The other thing that came to my mind after reading your note =0A> is t= hat we don't currently have a generic key to capture the =0A> Response Fenc= e behavior - although response fencing underlies =0A> both the fast multi-t= ask abort as well as addressing ACA race =0A> conditions (and perhaps other= s down the road. e.g. around =0A> persistent reservations). So, today, the= Note at the end of =0A> section 3.3.3 advises that implementations may che= ck the =0A> FastMultiTaskAbort key to verify if safe behavior for MCS ACA = =0A> is supported, although ACA has really nothing to do with =0A> multi-ta= sk aborting. I am wondering if we should create a =0A> new key (say Respon= seFence), so the semantics would become:=0A> = =0A> ResponseFence "Yes" = fencing done by target =0A> "No" = legacy, no fencing =0A> (so "clarified" TMF semantics are not possible eit= her)=0A> =0A> With ResponseFence=3D "Yes"=0A> FastMultiTaskAbort = =0A> "Yes" fast abort & fencing = =0A> "No" traditional wait on =0A> outstanding TT= Ts (fencing on ACA is still possible)=0A> =0A> With ResponseFence=3D "No= "=0A> FastMultiTaskAbort =0A> "Yes" Illegal, Re= sponse Fence must be "Yes"=0A> "No" No fencing, m= ust wait on =0A> outstanding TTTs=0A> =0A> =0A> The downside of this sche= me is that it may be going in the =0A> opposite direction than you wanted (= introduces a second key =0A> that 3720-compliant implementations don't know= about). We =0A> could alternatively simply mandate the behavior equivalen= t to =0A> ResponseFence =3D "Yes" always and avoid the second key, but =0A>= doing so could make the current 3720-compliant =0A> implementations techni= cally non-iSCSI-compliant.=0A> =0A> Comments?=0A=0AGiven the inter-dependen= ce of ResponseFence and FastMultiTaskAbort,=0Aa single 3-valued key is prob= ably simpler than two boolean keys.=0AI think having an explicit means of d= etermining whether ACA behaves=0Acorrectly on an multi-connection-session i= s worth adding.=0A=0AThanks,=0A--David =0A=0A> Mallikarjun=0A=0A___________= _______________________________________=0ADo You Yahoo!?=0ATired of spam? = Yahoo! Mail has the best spam protection around =0Ahttp://mail.yahoo.com _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Wed Dec 27 23:41:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gzn5J-0002OU-Ac; Wed, 27 Dec 2006 23:41:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gzn5H-0002OI-RF for ips@ietf.org; Wed, 27 Dec 2006 23:41:39 -0500 Received: from web51912.mail.yahoo.com ([206.190.48.75]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gzn5H-00022t-ED for ips@ietf.org; Wed, 27 Dec 2006 23:41:39 -0500 Received: (qmail 24597 invoked by uid 60001); 28 Dec 2006 04:41:39 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=H5r2aykJfQPuWYJ02nVql+izXv5kFKWf4Q8coUWpbGAIhnscDdyi9jwxpGIblkDIbujfC50AsOMGS97upktTJOBStjDiaObQ0ciLrtka3pZ8d5e3wH9G92u+e+wCNzVB3fmTloa23/3/qRf+h2cAI1X0wNnKyJO5pxONcCqKOuE= ; Message-ID: <20061228044139.24595.qmail@web51912.mail.yahoo.com> Received: from [15.246.143.45] by web51912.mail.yahoo.com via HTTP; Wed, 27 Dec 2006 20:41:39 PST Date: Wed, 27 Dec 2006 20:41:39 -0800 (PST) From: "Mallikarjun C." To: ips@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Subject: [Ips] TMF text with updates X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org Attached is the latest text that incorporates David's proposed enhancement.= Please review and comment. Note especially two things: new section 4.1.4= that summarizes generic implementation considerations for both "clarified"= and "updated" semantics, the changed text in 4.1.2 that says "MAY wait for= ....target transfer tags.....from third-party initiators" from the previou= s blanket MUST.=0A=0AMallikarjun=0A=0A=0A=0A4.1.2 Clarified multi-task abor= t semantics=0AAll iSCSI implementations MUST support the protocol behavior = defined in this section as the default behavior. The execution of ABORT TA= SK SET, CLEAR TASK SET, LOGICAL UNIT RESET, TARGET WARM RESET, and TARGET C= OLD RESET TMF Requests consists of the following sequence of actions in the= specified order on the specified party. =0AThe initiator iSCSI layer:=0Aa.= MUST continue to respond to each TTT received for the affected tasks. =0Ab= . Should receive any responses that the target may provide for some tasks a= mong the affected tasks (may process them as usual because they are guarant= eed to have chronologically originated prior to the TMF response). =0Ac. Sh= ould receive the TMF Response concluding all the tasks in the set of affect= ed tasks. =0A=0AThe target iSCSI layer:=0Aa. MUST wait for currently valid = target transfer tags of the affected tasks from the issuing initiator to be= responded to. MAY wait for responses on currently valid target transfer t= ags of the affected tasks from third-party initiators.=0Ab. MUST wait (conc= urrent with the wait in Step.a) for all commands of the affected tasks to b= e received based on the CmdSN ordering. SHOULD NOT wait for new commands = on third-party affected sessions - only the instantiated tasks have to be c= onsidered for the purpose of determining the affected tasks. In the case o= f target-scoped requests (i.e. TARGET WARM RESET and TARGET COLD RESET), al= l the commands that are not yet received on the issuing session in the comm= and stream however can be considered to have been received with no command = waiting period - i.e. the entire CmdSN space up to the CmdSN of the task ma= nagement function can be "plugged".=0Ac. MUST propagate the TMF request to = and receive the response from the target SCSI layer. =0Ad. MUST address the= Response Fence flag on the TMF Response on issuing session as defined in 3= .3.2.=0Ae. MUST address the Response Fence flag on the first post-TMF Respo= nse on third-party sessions as defined in 3.3.2. If some tasks originate f= rom non-iSCSI I_T_L nexuses then the means by which the target ensures that= all affected tasks have returned their status to the initiator are defined= by the specific non-iSCSI transport protocol(s).=0AImplementation note: Te= chnically, the TMF servicing is complete in Step.d. Data transfers corresp= onding to terminated tasks may however still be in progress on third-party = iSCSI sessiosn even at the end of Step.e. TMF Response MUST NOT be sent by= the target iSCSI layer before the end of Step.d, and MAY be sent at the en= d of Step.d despite these outstanding Data transfers until after Step.e.=0A= =0A4.1.3 Updated multi-task abort semantics=0AProtocol behavior defined in= this section MUST be implemented by all iSCSI implementations complying wi= th this document. Protocol behavior defined in this section MUST be exhibi= ted by iSCSI implementations on an iSCSI session when they negotiate the Ta= skReporting (section 9.1) key to =93FastAbort=94 on that session. The exec= ution of ABORT TASK SET, CLEAR TASK SET, LOGICAL UNIT RESET, TARGET WARM RE= SET, and TARGET COLD RESET TMF Requests consists of the following sequence = of actions in the specified order on the specified party. =0AThe initiator = iSCSI layer:=0Aa. MUST NOT send any more Data-Out PDUs for affected tasks o= n the issuing connection of the issuing iSCSI session once the TMF is sent = to the target.=0Ab. Should receive any responses that the target may provid= e for some tasks among the affected tasks (may process them as usual becaus= e they are guaranteed to have chronologically originated prior to the TMF r= esponse).=0Ac. MUST respond to Async Message PDU with AsyncEvent=3D5 as def= ined in section 8.1.=0Ad. Should receive the TMF Response concluding all th= e tasks in the set of affected tasks.=0A=0AThe target iSCSI layer:=0Aa. MUS= T wait for all commands of the affected tasks to be received based on the C= mdSN ordering on the issuing session. SHOULD NOT wait for new commands on = third-party affected sessions - only the instantiated tasks have to be cons= idered for the purpose of determining the affected tasks. In the case of t= arget-scoped requests (i.e. TARGET WARM RESET and TARGET COLD RESET), all t= he commands that are not yet received on the issuing session in the command= stream however can be considered to have been received with no command wai= ting period - i.e. the entire CmdSN space up to the CmdSN of the task manag= ement function can be "plugged".=0Ab. MUST propagate the TMF request to and= receive the response from the target SCSI layer. =0Ac. MUST leave all acti= ve "affected TTTs" (i.e. active TTTs associated with affected tasks) valid = along with any buffer allocations for the TTTs intact.=0Ad. MUST generate a= n Asynchronous Message PDU with AsyncEvent=3D5 (section 8.1) on:=0Ai) each = connection of each third-party session that at least one affected task is a= llegiant to, and=0Aii) each connection except the issuing connection of the= issuing session that has at least one allegiant affected task.=0AIf there = are multiple affected LUs (say due to a target reset), then one Async Messa= ge PDU MUST be sent for each such LU on each connection that has at least o= ne allegiant affected task.=0Ae. MUST address the Response Fence flag on th= e TMF Response on issuing session as defined in 3.3.2.=0Af. MUST address th= e Response Fence flag on the first post-TMF Response on third-party session= s as defined in 3.3.2. If some tasks originate from non-iSCSI I_T_L nexuses= then the means by which the target ensures that all affected tasks have re= turned their status to the initiator are defined by the specific non-iSCSI = transport protocol(s).=0Ag. MUST free up the affected TTTs (and STags, if a= pplicable) and the corresponding buffers once it receives the associated No= p-Out acknowledgement that the initiator generated in response to the Async= Message. =0AImplementation note: Technically, the TMF servicing is comple= te in Step.e. Data transfers corresponding to terminated tasks may however= still be in progress even at the end of Step.f. TMF Response MUST NOT be = sent by the target iSCSI layer before the end of Step.e, and MAY be sent at= the end of Step.e despite these outstanding Data transfers until Step.g. = Step.g specifies an event to free up any such resources that may have been = reserved to support outstanding data transfers. =0A4.1.3.1 Clearing effect= s update=0AAppendix F.1 of [RFC3720] specifies the clearing effects of targ= et and LU resets on =93Incomplete TTTs=94 as =93Y=94. This meant that a ta= rget warm reset or a target cold reset or an LU reset would clear the activ= e TTTs upon completion. The TaskReporting=3DFastAbort (section 9.1) semant= ics defined by this section however do not guarantee that the active TTTs a= re cleared by the end of the reset operations. In fact, the new semantics = are designed to allow clearing the TTTs in a =93lazy=94 fashion after the T= MF Response is delivered. Thus, when TaskReporting=3DFastAbort is operatio= nal on a session, the clearing effects of reset operations on =93Incomplete= TTTs=94 is =93N=94. =0A4.1.4 Implementation considerations=0ABoth in clar= ified semantics (section 4.1.2) and updated semantics (section 4.1.3), ther= e may be outstanding data transfers even after the TMF completion is report= ed on the issuing session. In the case of iSCSI/iSER [iSER], these would b= e tagged data transfers for STags not owned by any active tasks. Whether o= r not real buffers support these data transfers is implementation-dependent= . However, the data transfers logically MUST be silently discarded by the = target iSCSI layer in all cases. A target MAY, on an implementation-define= d internal timeout, also choose to drop the connections on which it did not= receive the expected Data-out sequences (section 4.1.2) or Nop-Out acknowl= edgements (section 4.1.3) so as to reclaim the associated buffer, STag and = TTT resources as appropriate.=0A=0A=0A----- Original Message ----=0AFrom: "= Black_David@emc.com" =0ATo: Black_David@emc.com; cb_ma= llikarjun@yahoo.com; ips@ietf.org=0ASent: Wednesday, December 20, 2006 2:33= :43 PM=0ASubject: RE: [Ips] Implementer's Guide - Task Management Issue=0A= =0A=0A> Let's try this line of reasoning - the target issues the Nop-Out, n= ow=0Awhen=0A> can it free the resources? Answer:=0A> - The Nop-In resp= onse comes back, OR=0A> - The connection times out and is torn down.=0A= > Now, what if the Nop-Out is not issued - what does the target wait for=0A= to=0A> free the resources? Answer:=0A> - The transfers complete, OR=0A= > - The connection times out and is torn down. =0A> Those look similar = enough at the target (the worst case is the same -=0Athe=0A> resources are = tied up until an uncooperative initiator times out) that=0A> I don't see th= e harm in allowing the early TMF return without the new=0A> key. The clear= distinction is that the first two bullets are=0Adifferent;=0A> if the new = key is not negotiated, the target has to wait for the=0Atransfers=0A> to co= mplete; the new key and the Nop-Out are necessary to walk away=0Aearlier=0A= > when the initiator involved is able to continue the transfers.=0A=0AThat = got slightly twisted - what it should have talked about was the=0Atarget=0A= issuing the new Async Message and the Nop-Out response coming back.=0A=0ATh= anks,=0A--David=0A----------------------------------------------------=0ADa= vid L. Black, Senior Technologist=0AEMC Corporation, 176 South St., Hopkint= on, MA 01748=0A+1 (508) 293-7953 FAX: +1 (508) 293-7786=0Ablac= k_david@emc.com Mobile: +1 (978) 394-7754=0A------------------------= ----------------------------=0A=0A_________________________________________= _________=0ADo You Yahoo!?=0ATired of spam? Yahoo! Mail has the best spam = protection around =0Ahttp://mail.yahoo.com _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Wed Dec 27 23:51:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GznEy-0005WI-4c; Wed, 27 Dec 2006 23:51:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GznEw-0005W9-7Y for ips@ietf.org; Wed, 27 Dec 2006 23:51:38 -0500 Received: from web51914.mail.yahoo.com ([206.190.48.77]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GznEo-0004Vw-Hx for ips@ietf.org; Wed, 27 Dec 2006 23:51:38 -0500 Received: (qmail 34777 invoked by uid 60001); 28 Dec 2006 04:51:30 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=NBo1egpZYvHb05YUE9p5mVkNQxYRYaZy/9dvCzoMvvV1khSpdZlDrlOVkprVzPEBowxUX5GmqhI8fhjK3o1bn229RElW4X5Nu6krMBzVuYJt3UZLZ8Yl7tgHmyfAkKxv1Mt916gcQU7LYXo2rokaCHCYH3wtVanZGh7EJO1QIts= ; Message-ID: <20061228045130.34775.qmail@web51914.mail.yahoo.com> Received: from [15.246.143.45] by web51914.mail.yahoo.com via HTTP; Wed, 27 Dec 2006 20:51:30 PST Date: Wed, 27 Dec 2006 20:51:30 -0800 (PST) From: "Mallikarjun C." To: IPS MIME-Version: 1.0 Content-Type: text/plain; charset=ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Subject: [Ips] New name for IG draft X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org Lars and all,=0A=0AI agree with Lars' review comment below, and would like = to change the name of the current (iSCSI Implementer's Guide) to "iSCSI Cor= rections and Clarifications". Please comment.=0A=0AThere were some issues = with I-D publication process the last time I wanted to change the name of a= file name for a post-00 revision. I had to revert back to the original na= me (whatever I had for -00 revision). I do not know if the trick is to cha= nge the title of the draft as Lars proposes but leave the file name (draft-= ietf-ips....) unchanged. David and/or Lars, please advise.=0A=0AI had also= updated the draft to cite RFC 3721 normatively, as Lars suggested below.= =0A=0AThanks.=0A=0AMallikarjun=0A=0A----- Original Message ----=0AFrom: Lar= s Eggert =0ATo: Mallikarjun C. =0ACc: ips@ietf.org=0ASent: Thursday, December 14, 2006 1:14:52 AM= =0ASubject: Re: [Ips] ips WG Last Call: iSCSI Implementer's Guide=0A=0A=0AH= i,=0A=0AOn Dec 11, 2006, at 18:34, Mallikarjun C. wrote:=0A> As far as volu= nteers for reviewing, we could request the =0A> contributors at the end of= the document to review. David may have =0A> already reviewed, based on h= is comments. Julian Satran had some =0A> offline feedback for me on TMF t= opics. As the editor of the =0A> document, I was sure that each of the to= pics were discussed in =0A> detail (or at least clearly noted) on the list= before I included =0A> them in the doc. Hope that gives you some reassur= ance.=0A=0Ait does, and I trust the WG to organize sufficient reviews.=0A= =0A>> whether it is merely the original text that can be=0A>> misunderstood= or if there is a technical error in the original text.=0A>> (It already do= es in some cases.)=0A>=0A> Yes, I'd appreciate if you could point out where= you think =0A> additional clarifications could help.=0A=0AI think I'd mos= tly like to see stronger language on "this section =0Acontains only a clar= ification of section X of RFC Y" vs. "this =0Asection replaces section X o= f RFC Y."=0A=0A>> OK, so this document not only updates 3720, but also 3721= , 3722 and=0A>> 3723? That needs to be stated in the document header and ab= stract.=0A>> (Also, 3721 needs to be normatively cited in this case.)=0A>= =0A> We could. My intent was to make it clear that this document =0A> pre= vails whenever a subtle interpretation in future of one of these =0A> RFCs= differs from what's in this document. Now that we are nearing =0A> the e= nd of the work on this document, we could delete some although =0A> I pers= onally am tempted to leave it this way....from what I can =0A> think of to= day though, this doc updates 3720 and 3721, but does not =0A> update 3722 = and 3723.=0A=0AI'd argue for being very clear about which sections of which= RFCs =0Athis document clarifies/replaces and which are only cited for = =0Ainformation. (Where things are being clarified or replaced, those =0ARF= Cs need to be cited normatively.)=0A=0A> 3721 is not a standards-track RFC = and I wasn't sure if it needs to =0A> be normatively cited as such. But = I could if that's the right =0A> thing to do.=0A=0AIt is, see above. Any R= FC (independent of its type) that is being =0Aclarified or replaced needs = to be a normative reference. Please check =0Aif this introduces and downre= fs according to RFC3967 that we need to =0Ahandle.=0A=0A>> Suggest to find= a better title, because implementer's guides don't=0A>> typically update t= he base specification in a normative way. (Maybe=0A>> "iSCSI Corrections an= d Implementer's Guide" or something like that?)=0A>=0A> FIne by me. How ab= out "iSCSI Corrections, Clarifications, =0A> Additions and Implementation = Guidance", or is it too long? If it =0A> is, we could try "iSCSI Changes = Based on Implementers' Experience" =0A> or something like it.=0A=0AThe fir= st is a bit too long, and I don't like the second :-)=0A=0A"iSCSI Correctio= ns and Clarifications?"=0A=0ALars=0A=0A____________________________________= ______________=0ADo You Yahoo!?=0ATired of spam? Yahoo! Mail has the best = spam protection around =0Ahttp://mail.yahoo.com _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Thu Dec 28 00:03:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GznPw-0000JP-Uq; Thu, 28 Dec 2006 00:03:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GznPv-0000JF-82 for ips@ietf.org; Thu, 28 Dec 2006 00:02:59 -0500 Received: from web51908.mail.yahoo.com ([206.190.48.71]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GznPu-0006uD-Le for ips@ietf.org; Thu, 28 Dec 2006 00:02:59 -0500 Received: (qmail 65620 invoked by uid 60001); 28 Dec 2006 05:02:53 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Yrbw4ZNmN9YWtAICdCEbNZ26Ix6oFKbgBlD/MTOC4mznBsVBW27Tv8WiTuGB4NoDltaV2vhnfFWn8RRlqvq5qUqICVQ2RM1LD78HNo/8mqZETQMyYLuU7yXvro99LurH4zRlrURMopTXtis7hj3fFNWrRh3jp/Ooh+aRCbOlHXE= ; Message-ID: <20061228050253.65618.qmail@web51908.mail.yahoo.com> Received: from [15.246.143.45] by web51908.mail.yahoo.com via HTTP; Wed, 27 Dec 2006 21:02:53 PST Date: Wed, 27 Dec 2006 21:02:53 -0800 (PST) From: "Mallikarjun C." To: ips@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: a0534e6179a1e260079328e8b03c7901 Subject: [Ips] Re: iSCSI "compliance" text X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org Eddy,=0A=0AEven if we say it in the draft, it would be pretty generic and w= ill have no mandatory force. So I do not see a lot of value in attempting = to state it in the draft. Unless I get other inputs and/or advise from Dav= id and Lars, I prefer not to attempt to craft such a text. I also suspect = this is not a case peculiar to iSCSI protocol, so I would welcome inputs fr= om other WG members.=0A=0AMallikarjun=0A=0A=0A----- Original Message ----= =0AFrom: Eddy Quicksall =0ATo: ips@ietf.org= =0ASent: Thursday, December 21, 2006 9:20:14 AM=0ASubject: Fw: [Ips] ips WG= Last Call: iSCSI Implementer's Guide=0A=0A=0ASorry, I forgot to send this = original request to the list.=0A=0AWhat I'm thinking is to say this in the = iSCSI Implementer's Guide, if it is =0Anot too late.=0A=0AOne of the proble= ms I'm faced with is that our customers will run 3rd party=0Atests on a fin= al product. If 3rd party test says "failed" then the customer=0Atakes that = to its word. I have found that many people think that if the RFC=0Asays the= initiator MUST then they think that means the target MUST check to=0Asee t= hat the initiator obeyed the rule (and visa versa) ... some of the 3rd=0Apa= rty tests are in that category.=0A=0AEddy=0A=0A----- Original Message -----= =0AFrom: "Mallikarjun C." =0ATo: "Eddy Quicksall= " =0ACc: ; "Julian Satr= an" =0ASent: Thursday, December 14, 2006 6:55 PM= =0ASubject: Re: [Ips] ips WG Last Call: iSCSI Implementer's Guide=0A=0A=0AI= think I understand your question. Generally, the IETF philosophy is to = =0A"be liberal in what you accept, be conservative in what you send" (my = =0Aparaphrasing of it, anyway) - so if your target wants to be more forgivi= ng, =0AI think that should be alright.=0A=0AThe UNH tests may be testing al= l MUST requirements - so in your immediate =0Adata example, the initiator m= ust be held to this rule since it initiates the =0Aimmediate data send. On= the target side, I see no harm in turning off those =0Achecks in your prod= uction code when you think you can gracefully deal even =0Awith a badly-beh= aving initiator. On such occasions though, you should be =0Asure to not fl= ag SCSI protocol errors for those same iSCSI protocol errors =0Athat you ha= d earlier forgiven.=0A=0AHope that helps.=0A=0AMallikarjun=0A=0A=0A----- Or= iginal Message ----=0AFrom: Eddy Quicksall = =0ATo: Mallikarjun C. =0ASent: Wednesday, Decembe= r 13, 2006 4:17:37 AM=0ASubject: Re: [Ips] ips WG Last Call: iSCSI Implemen= ter's Guide=0A=0A=0AI know it is really late to ask this but I was wonderin= g if something could=0Abe done to relax some of the requirements for the ta= rget or initiator to=0Acheck for correctness of the protocol? For example, = it could be said that if=0Athe protocol error will not affect the operation= of the device then it is=0Anot necessary to check for the error.=0A=0AI as= k this because all of these checks during Full Feature Phase can cause=0Aun= necessary performance degradation due to a check on every command PDU even= =0Awhen the initiator or target have been previously qualified. This is off= the=0Atop of my head but one such check that comes to mind is the check to= be sure=0Athe ITT of data matches the ITT of the original command... we ha= ve hardware=0Aacceleration and different types of memory with different spe= eds. To cross=0Acheck against the command requires saving additional inform= ation and=0Aaccessing the slow memory (the fast memory is at a premium and = can't store=0Aenough information). Another is the requirement for the targe= t to check for=0Aimmediate data received when immediate data was negotiated= to no (if the=0Atarget can deal with it and the initiator can't but the in= itiator negotiated=0Ait to no then the initiator should not send it anyway = and there should be no=0Aneed to make the checks on every command).=0A=0AMa= ybe some of these that I call "required checks" are actually the result of= =0Aa test program (such as the UNH test program) putting on the "requiremen= t".=0AIf so then a note in the guide may help to clear up that it is not an= error=0Afor the initiator or target to double check the peer.=0A=0AI typed= this kind of fast and I'm not a good linguist so if you don't=0Aunderstand= then please let me know.=0A=0AEddy=0A=0A----- Original Message ----- =0AFr= om: "Mallikarjun C." =0ATo: =0ASent= : Monday, December 11, 2006 12:34 PM=0ASubject: Re: [Ips] ips WG Last Call:= iSCSI Implementer's Guide=0A=0A=0ALars,=0A=0AThanks for the comments and s= orry for the delay in getting back.=0A=0AAs far as volunteers for reviewing= , we could request the contributors at the=0Aend of the document to review.= David may have already reviewed, based on=0Ahis comments. Julian Satran = had some offline feedback for me on TMF topics.=0AAs the editor of the docu= ment, I was sure that each of the topics were=0Adiscussed in detail (or at = least clearly noted) on the list before I=0Aincluded them in the doc. Hope= that gives you some reassurance.=0A=0A>whether it is merely the original t= ext that can be=0A>misunderstood or if there is a technical error in the or= iginal text.=0A> (It already does in some cases.)=0A=0AYes, I'd appreciate = if you could point out where you think additional=0Aclarifications could he= lp.=0A=0A> OK, so this document not only updates 3720, but also 3721, 3722 = and=0A> 3723? That needs to be stated in the document header and abstract.= =0A> (Also, 3721 needs to be normatively cited in this case.)=0A=0AWe could= . My intent was to make it clear that this document prevails=0Awhenever a = subtle interpretation in future of one of these RFCs differs from=0Awhat's = in this document. Now that we are nearing the end of the work on=0Athis do= cument, we could delete some although I personally am tempted to=0Aleave it= this way....from what I can think of today though, this doc updates=0A3720= and 3721, but does not update 3722 and 3723.=0A=0A3721 is not a standards-= track RFC and I wasn't sure if it needs to be=0Anormatively cited as such. = But I could if that's the right thing to do.=0A=0A>Suggest to find a bett= er title, because implementer's guides don't=0A>typically update the base s= pecification in a normative way. (Maybe=0A> "iSCSI Corrections and Implemen= ter's Guide" or something like that?)=0A=0AFIne by me. How about "iSCSI Co= rrections, Clarifications, Additions and=0AImplementation Guidance", or is = it too long? If it is, we could try "iSCSI=0AChanges Based on Implementers= ' Experience" or something like it.=0A=0A> The specification of the fence m= echanisms should use RFC2119 terms,=0A> especially in Section 3.3.2.=0A=0AI= t actually does, with a MUST preceding the bulleted list.... As far as=0A3= .3.1, I intentionally left the model description very generic with the hope= =0Athat it can be incorporated into a future T10 spec verbatim.=0A=0A> Nit:= s/mult/multi-/=0A=0ADone.=0A=0A> I'm not sure if "should receive" describe= s something that should be=0A> started in RFC2119 language or not. If that = is the intent, a better=0A> phrasing should be found. (Also elsewhere in th= is document where the=0A> same phrasing is used.)=0A=0AI left the "should"s= intentionally in, because they really are the=0Aprerogatives of the initia= tor's run-time behavior, i.e. initiator may at his=0Adiscretion choose to d= iscard a message for some other reason (e.g. bad=0Adigest) beyond the 2119 = protocol requirements.=0A=0A>Should the sentence starting with "SHOULD NOT"= start a new item in=0A> this list?=0A=0ANo, I don't think so. This bullet = is all about waiting for missing CmdSN's.=0AIt happens to have a different = prescription for third-party affected=0Asessions.=0A=0A>Remove text after "= considerations" to not confuse IANA. May want=0A> to add a note to the RFC = Editor to remove this section upon=0A>publication.=0A=0ADone.=0A=0A> Nit: C= ited also as [RFC 3720], which confuses idnits. Remove the=0Aspace=0A> in t= he other citations.=0A=0ADone.=0A=0A>iSER Not cited.=0A=0AIt does now.= =0A=0A> ID does not include the required 2119 boilerplate. Also, 2119 shoul= d=0A> be cited normatively.=0A=0AFixed now.=0A=0A=0AMallikarjun=0A=0A=0A=0A= =0A=0A=0A=0A=0A=0A----- Original Message ----=0AFrom: Lars Eggert =0ATo: ips@ietf.org=0ASent: Friday, December 1, 2006 4:57= :59 PM=0ASubject: Re: [Ips] ips WG Last Call: iSCSI Implementer's Guide=0A= =0A=0ASummary: Minor revision needed to address editorial issues. Note: I'm= =0A no iSCSI expert, so I cannot fully review the technical=0A recommen= dations made in this document. I'd like to see at least one=0A other revi= ew from someone who has the necessary background before=0Athis=0A documen= t moves forward - volunteers?=0A=0A Contains non-ASCII characters, boiler= plate issues and other idnits.=0A Please fix. Header should indicate that= this document updates 3720=0A and potentially other IDs (abstract alread= y partially does - good!)=0A=0A It would be good if this document would s= tate for each item it=0A discusses, whether this is a clarification to th= e original RFCs or a=0A correction, i.e., whether it is merely the origin= al text that can be=0A misunderstood or if there is a technical error in = the original text.=0A (It already does in some cases.)=0A=0A=0AINTRODUCTI= ON, paragraph 1:=0A> iSCSI Implementer's Guide=0A= =0A Suggest to find a better title, because implementer's guides don't=0A= typically update the base specification in a normative way. (Maybe=0A = "iSCSI Corrections and Implementer's Guide" or something like that?)=0A=0A= =0ASection 2, paragraph 2:=0A> iSCSI implementers are required to refere= nce [RFC3722] and=0A> [RFC3723] in addition to [RFC3720] for mandatory r= equirements.=0A> In addition, [RFC3721] also contains useful information= for=0A> iSCSI implementers. The text in this document, however, update= s=0A> and supersedes the text in all the noted RFCs whenever there is=0A= > such a question.=0A=0A OK, so this document not only updates 3720, b= ut also 3721, 3722 and=0A 3723? That needs to be stated in the document h= eader and abstract.=0A (Also, 3721 needs to be normatively cited in this = case.)=0A=0A=0ASection 3.3, paragraph 0:=0A> 3.3 SCSI Protocol Interface M= odel for Response Ordering=0A=0A The specification of the fence mechanism= s should use RFC2119 terms,=0A especially in Section 3.3.2.=0A=0A=0ASecti= on 3.3.3, paragraph 4:=0A> 2. The TMF Response carrying the mult-task = TMF Response on the=0A> issuing session.=0A=0A Nit: s/mult/multi-/= =0A=0A=0ASection 4.1.2, paragraph 4:=0A> b. Should receive any respons= es that the target may provide=0A> for some tasks among the affe= cted tasks (may process them=0A> as usual because they are guara= nteed to have=0A> chronologically originated prior to the TMF re= sponse).=0A=0A I'm not sure if "should receive" describes something that = should be=0A started in RFC2119 language or not. If that is the intent, a= better=0A phrasing should be found. (Also elsewhere in this document whe= re the=0A same phrasing is used.)=0A=0A=0ASection 4.1.2, paragraph 8:=0A>= b. MUST wait (concurrent with the wait in Step.a) for all=0A> = commands of the affected tasks to be received based on the=0A> = CmdSN ordering. SHOULD NOT wait for new commands on=0A> thi= rd-party affected sessions - only the instantiated=0Atasks=0A> h= ave to be considered for the purpose of determining the=0A> affe= cted tasks. In the case of target-scoped requests=0A> (i.e. TAR= GET WARM RESET and TARGET COLD RESET), all the=0A> commands that= are not yet received on the issuing session=0A> in the command = stream however can be considered to have=0A> been received with = no command waiting period - i.e. the=0A> entire CmdSN space up t= o the CmdSN of the task management=0A> function can be "plugged"= .=0A=0A Should the sentence starting with "SHOULD NOT" start a new item i= n=0A this list?=0A=0A=0ASection 4.1.3, paragraph 8:=0A> a. MUST wait= for all commands of the affected tasks to be=0A> received based = on the CmdSN ordering on the issuing=0A> session. SHOULD NOT wai= t for new commands on third-party=0A> affected sessions - only th= e instantiated tasks have to be=0A> considered for the purpose of= determining the affected=0A> tasks. In the case of target-scope= d requests (i.e. TARGET=0A> WARM RESET and TARGET COLD RESET), al= l the commands that=0A> are not yet received on the issuing sessi= on in the command=0A> stream however can be considered to have be= en received with=0A> no command waiting period - i.e. the entire = CmdSN space up=0A> to the CmdSN of the task management function c= an be=0A> "plugged".=0A=0A Should the sentence starting with "S= HOULD NOT" start a new item in=0A this list?=0A=0A=0ASection 11, paragrap= h 1:=0A> This draft does not have any specific IANA considerations other= =0Athan=0A> those already noted in [RFC3720].=0A=0A Remove text after "= considerations" to not confuse IANA. May want=0A to add a note to the RFC= Editor to remove this section upon=0Apublication.=0A=0A=0ASection 12.1, pa= ragraph 1:=0A> [RFC3720] Satran, J., Meth, K., Sapuntzakis, C., Chadal= apaka,=0A> M., and E. Zeidner, "Internet Small Computer Systems= =0A> Interface (iSCSI)", RFC 3720, April 2004.=0A=0A Nit: Cited= also as [RFC 3720], which confuses idnits. Remove the=0Aspace=0A in the = other citations.=0A=0A=0ASection 12.2, paragraph 1:=0A> [RFC3721] Bakk= e, M., Hafner, J., Hufferd, J., Voruganti, K.,=0A> and M. Krueger= , "Internet Small Computer Systems Interface=0A> (iSCSI) Naming a= nd Discovery", RFC 3721, April 2004.=0A=0A See above, if this ID updates = 3721, it needs to normatively cite it.=0A=0A=0ASection 12.2, paragraph 2:= =0A> [iSER] Ko, M., Chadalapaka, M., Elzur, U., Shah, H., Thaler,=0A> = P., J. Hufferd, "iSCSI Extensions for RDMA", IETF=0A> I= nternet Draft draft-ietf-ips-iser-04.txt (work in=0A> progress), = June 2005.=0A=0A Not cited.=0A=0A=0ASection 12.2, paragraph 3:=0A> = [RFC2119] Bradner, S. "Key Words for use in RFCs to Indicate=0A> = Requirement Levels", BCP 14, RFC 2119, March 1997.=0A=0A ID does not incl= ude the required 2119 boilerplate. Also, 2119 should=0A be cited normativ= ely.=0A_______________________________________________=0AIps mailing list= =0AIps@ietf.org=0Ahttps://www1.ietf.org/mailman/listinfo/ips=0A=0A=0A=0A___= ___________________________________________________________________________= ______=0ADo you Yahoo!?=0AEveryone is raving about the all-new Yahoo! Mail = beta.=0Ahttp://new.mail.yahoo.com=0A=0A____________________________________= ___________=0AIps mailing list=0AIps@ietf.org=0Ahttps://www1.ietf.org/mailm= an/listinfo/ips=0A=0A=0A=0A________________________________________________= ____________________________________=0AWant to start your own business?=0AL= earn how on Yahoo! Small Business.=0Ahttp://smallbusiness.yahoo.com/r-index= =0A=0A=0A_______________________________________________=0AIps mailing list= =0AIps@ietf.org=0Ahttps://www1.ietf.org/mailman/listinfo/ips=0A=0A_________= _________________________________________=0ADo You Yahoo!?=0ATired of spam?= Yahoo! Mail has the best spam protection around =0Ahttp://mail.yahoo.com _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Thu Dec 28 04:41:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gzrl3-0008PI-Ck; Thu, 28 Dec 2006 04:41:05 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gzrl2-0008PD-Rm for ips@ietf.org; Thu, 28 Dec 2006 04:41:04 -0500 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Gzrkz-0006vH-3F for ips@ietf.org; Thu, 28 Dec 2006 04:41:04 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id kBS9dDVZ016046; Thu, 28 Dec 2006 11:39:39 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Dec 2006 11:40:53 +0200 Received: from esmgw001.ext.nokia.com ([147.243.42.25]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Dec 2006 11:40:54 +0200 Received: from espmg001.ext.nokia.com (espmg001.ext.nokia.com [147.243.46.49]) by esmgw001.ext.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id kBS9eNfF026199; Thu, 28 Dec 2006 11:40:23 +0200 Message-ID: <16576336.1167298853375.JavaMail.root@espmg001.ext.nokia.com> Date: Thu, 28 Dec 2006 11:40:53 +0200 (EET) From: Lars Eggert To: cb_mallikarjun@yahoo.com, ips@ietf.org Subject: RE: [Ips] New name for IG draft Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-OriginalArrivalTime: 28 Dec 2006 09:40:54.0916 (UTC) FILETIME=[452F1C40:01C72A64] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::061228113939-3CCFDBB0-41DE261E/0-0/0-0 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org Hi, there is no need to change the file name to change the title of the draft. Lars -- NEW EMAIL: lars.eggert@nokia.com NEW MOBILE: +358 50 48 24461 NEW JABBER: lars.eggert@googlemail.com > -----Original Message----- > From: ext Mallikarjun C. > Received: Thu Dec 28 06:53:20 EET 2006 > To: IPS > Subject: [Ips] New name for IG draft > > Lars and all, > > I agree with Lars' review comment below, and would like to change the name of the current (iSCSI Implementer's Guide) to "iSCSI Corrections and Clarifications". Please comment. > > There were some issues with I-D publication process the last time I wanted to change the name of a file name for a post-00 revision. I had to revert back to the original name (whatever I had for -00 revision). I do not know if the trick is to change the title of the draft as Lars proposes but leave the file name (draft-ietf-ips....) unchanged. David and/or Lars, please advise. > > I had also updated the draft to cite RFC 3721 normatively, as Lars suggested below. > > Thanks. > > Mallikarjun > > ----- Original Message ---- > From: Lars Eggert > To: Mallikarjun C. > Cc: ips@ietf.org > Sent: Thursday, December 14, 2006 1:14:52 AM > Subject: Re: [Ips] ips WG Last Call: iSCSI Implementer's Guide > > > Hi, > > On Dec 11, 2006, at 18:34, Mallikarjun C. wrote: > > As far as volunteers for reviewing, we could request the > > contributors at the end of the document to review. David may have > > already reviewed, based on his comments. Julian Satran had some > > offline feedback for me on TMF topics. As the editor of the > > document, I was sure that each of the topics were discussed in > > detail (or at least clearly noted) on the list before I included > > them in the doc. Hope that gives you some reassurance. > > it does, and I trust the WG to organize sufficient reviews. > > >> whether it is merely the original text that can be > >> misunderstood or if there is a technical error in the original text. > >> (It already does in some cases.) > > > > Yes, I'd appreciate if you could point out where you think > > additional clarifications could help. > > I think I'd mostly like to see stronger language on "this section > contains only a clarification of section X of RFC Y" vs. "this > section replaces section X of RFC Y." > > >> OK, so this document not only updates 3720, but also 3721, 3722 and > >> 3723? That needs to be stated in the document header and abstract. > >> (Also, 3721 needs to be normatively cited in this case.) > > > > We could. My intent was to make it clear that this document > > prevails whenever a subtle interpretation in future of one of these > > RFCs differs from what's in this document. Now that we are nearing > > the end of the work on this document, we could delete some although > > I personally am tempted to leave it this way....from what I can > > think of today though, this doc updates 3720 and 3721, but does not > > update 3722 and 3723. > > I'd argue for being very clear about which sections of which RFCs > this document clarifies/replaces and which are only cited for > information. (Where things are being clarified or replaced, those > RFCs need to be cited normatively.) > > > 3721 is not a standards-track RFC and I wasn't sure if it needs to > > be normatively cited as such. But I could if that's the right > > thing to do. > > It is, see above. Any RFC (independent of its type) that is being > clarified or replaced needs to be a normative reference. Please check > if this introduces and downrefs according to RFC3967 that we need to > handle. > > >> Suggest to find a better title, because implementer's guides don't > >> typically update the base specification in a normative way. (Maybe > >> "iSCSI Corrections and Implementer's Guide" or something like that?) > > > > FIne by me. How about "iSCSI Corrections, Clarifications, > > Additions and Implementation Guidance", or is it too long? If it > > is, we could try "iSCSI Changes Based on Implementers' Experience" > > or something like it. > > The first is a bit too long, and I don't like the second :-) > > "iSCSI Corrections and Clarifications?" > > Lars > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips > > > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Thu Dec 28 05:32:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GzsYF-0006Bm-0M; Thu, 28 Dec 2006 05:31:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GzsYC-0006Bg-Vj for ips@ietf.org; Thu, 28 Dec 2006 05:31:52 -0500 Received: from mtagate5.de.ibm.com ([195.212.29.154]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GzsYB-0004u8-Ka for ips@ietf.org; Thu, 28 Dec 2006 05:31:52 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate5.de.ibm.com (8.13.8/8.13.8) with ESMTP id kBSAVolR096266 for ; Thu, 28 Dec 2006 10:31:50 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id kBSAVoSx3289108 for ; Thu, 28 Dec 2006 11:31:50 +0100 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id kBSAVoXN029610 for ; Thu, 28 Dec 2006 11:31:50 +0100 Received: from d12mc102.megacenter.de.ibm.com (d12mc102.megacenter.de.ibm.com [9.149.167.114]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id kBSAVoGe029607 for ; Thu, 28 Dec 2006 11:31:50 +0100 In-Reply-To: <20061228044139.24595.qmail@web51912.mail.yahoo.com> To: "Mallikarjun C." MIME-Version: 1.0 Subject: Re: [Ips] TMF text with updates X-Mailer: Lotus Notes Release 7.0.2 September 26, 2006 From: Julian Satran Message-ID: Date: Thu, 28 Dec 2006 12:31:49 +0200 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 7.0.2HF71 | November 3, 2006) at 28/12/2006 12:31:49, Serialize complete at 28/12/2006 12:31:49 X-Spam-Score: 0.3 (/) X-Scan-Signature: b83962958e2d910ed948e2f9e138d171 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="===============1482732563==" Errors-To: ips-bounces@ietf.org This is a multipart message in MIME format. --===============1482732563== Content-Type: multipart/alternative; boundary="=_alternative 0039D6E7C2257252_=" This is a multipart message in MIME format. --=_alternative 0039D6E7C2257252_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Mallikarjun, I would consider the text: c. MUST leave all active "affected TTTs" (i.e. active TTTs associated with = affected tasks) valid along with any buffer allocations for the TTTs=20 intact. somewhat excessive as it relates too much to implementation. I would=20 rather say: c. MUST leave all active "affected TTTs" (i.e. active TTTs associated with = affected tasks) valid. and leave the buffer issue to the implementer (as I have stated already on = this list). I also keep thinking (and mildly objecting to) that the whole fast abort=20 is excesively complex. You could achive the same effect by issuing the TM command on every=20 affected connection. The third party story is even more puzzling as in order to negotiate any=20 of the nem TM modes the taget will have to ascertain that all other=20 initiators support it. I fail to understand how would you handle=20 downgrading the mode for those that don't. And if you don't downgrade why=20 not state that fast-abort and target scoped queues don't go together and=20 simplify the mechanics to a multiple issue TM. Thanks, Julo "Mallikarjun C." =20 28/12/06 06:41 To ips@ietf.org cc Subject [Ips] TMF text with updates Attached is the latest text that incorporates David's proposed=20 enhancement. Please review and comment. Note especially two things: new=20 section 4.1.4 that summarizes generic implementation considerations for=20 both "clarified" and "updated" semantics, the changed text in 4.1.2 that=20 says "MAY wait for ....target transfer tags.....from third-party=20 initiators" from the previous blanket MUST. Mallikarjun 4.1.2 Clarified multi-task abort semantics All iSCSI implementations MUST support the protocol behavior defined in=20 this section as the default behavior. The execution of ABORT TASK SET,=20 CLEAR TASK SET, LOGICAL UNIT RESET, TARGET WARM RESET, and TARGET COLD=20 RESET TMF Requests consists of the following sequence of actions in the=20 specified order on the specified party.=20 The initiator iSCSI layer: a. MUST continue to respond to each TTT received for the affected tasks.=20 b. Should receive any responses that the target may provide for some tasks = among the affected tasks (may process them as usual because they are=20 guaranteed to have chronologically originated prior to the TMF response).=20 c. Should receive the TMF Response concluding all the tasks in the set of=20 affected tasks.=20 The target iSCSI layer: a. MUST wait for currently valid target transfer tags of the affected=20 tasks from the issuing initiator to be responded to. MAY wait for=20 responses on currently valid target transfer tags of the affected tasks=20 from third-party initiators. b. MUST wait (concurrent with the wait in Step.a) for all commands of the=20 affected tasks to be received based on the CmdSN ordering. SHOULD NOT=20 wait for new commands on third-party affected sessions - only the=20 instantiated tasks have to be considered for the purpose of determining=20 the affected tasks. In the case of target-scoped requests (i.e. TARGET=20 WARM RESET and TARGET COLD RESET), all the commands that are not yet=20 received on the issuing session in the command stream however can be=20 considered to have been received with no command waiting period - i.e. the = entire CmdSN space up to the CmdSN of the task management function can be=20 "plugged". c. MUST propagate the TMF request to and receive the response from the=20 target SCSI layer.=20 d. MUST address the Response Fence flag on the TMF Response on issuing=20 session as defined in 3.3.2. e. MUST address the Response Fence flag on the first post-TMF Response on=20 third-party sessions as defined in 3.3.2. If some tasks originate from=20 non-iSCSI I=5FT=5FL nexuses then the means by which the target ensures that= =20 all affected tasks have returned their status to the initiator are defined = by the specific non-iSCSI transport protocol(s). Implementation note: Technically, the TMF servicing is complete in Step.d. = Data transfers corresponding to terminated tasks may however still be in=20 progress on third-party iSCSI sessiosn even at the end of Step.e. TMF=20 Response MUST NOT be sent by the target iSCSI layer before the end of=20 Step.d, and MAY be sent at the end of Step.d despite these outstanding=20 Data transfers until after Step.e. =20 4.1.3 Updated multi-task abort semantics Protocol behavior defined in this section MUST be implemented by all iSCSI = implementations complying with this document. Protocol behavior defined=20 in this section MUST be exhibited by iSCSI implementations on an iSCSI=20 session when they negotiate the TaskReporting (section 9.1) key to=20 ?FastAbort? on that session. The execution of ABORT TASK SET, CLEAR TASK=20 SET, LOGICAL UNIT RESET, TARGET WARM RESET, and TARGET COLD RESET TMF=20 Requests consists of the following sequence of actions in the specified=20 order on the specified party.=20 The initiator iSCSI layer: a. MUST NOT send any more Data-Out PDUs for affected tasks on the issuing=20 connection of the issuing iSCSI session once the TMF is sent to the=20 target. b. Should receive any responses that the target may provide for some tasks = among the affected tasks (may process them as usual because they are=20 guaranteed to have chronologically originated prior to the TMF response). c. MUST respond to Async Message PDU with AsyncEvent=3D5 as defined in=20 section 8.1. d. Should receive the TMF Response concluding all the tasks in the set of=20 affected tasks. The target iSCSI layer: a. MUST wait for all commands of the affected tasks to be received based=20 on the CmdSN ordering on the issuing session. SHOULD NOT wait for new=20 commands on third-party affected sessions - only the instantiated tasks=20 have to be considered for the purpose of determining the affected tasks.=20 In the case of target-scoped requests (i.e. TARGET WARM RESET and TARGET=20 COLD RESET), all the commands that are not yet received on the issuing=20 session in the command stream however can be considered to have been=20 received with no command waiting period - i.e. the entire CmdSN space up=20 to the CmdSN of the task management function can be "plugged". b. MUST propagate the TMF request to and receive the response from the=20 target SCSI layer.=20 c. MUST leave all active "affected TTTs" (i.e. active TTTs associated with = affected tasks) valid along with any buffer allocations for the TTTs=20 intact. d. MUST generate an Asynchronous Message PDU with AsyncEvent=3D5 (section=20 8.1) on: i) each connection of each third-party session that at least one affected=20 task is allegiant to, and ii) each connection except the issuing connection of the issuing session=20 that has at least one allegiant affected task. If there are multiple affected LUs (say due to a target reset), then one=20 Async Message PDU MUST be sent for each such LU on each connection that=20 has at least one allegiant affected task. e. MUST address the Response Fence flag on the TMF Response on issuing=20 session as defined in 3.3.2. f. MUST address the Response Fence flag on the first post-TMF Response on=20 third-party sessions as defined in 3.3.2. If some tasks originate from=20 non-iSCSI I=5FT=5FL nexuses then the means by which the target ensures that= =20 all affected tasks have returned their status to the initiator are defined = by the specific non-iSCSI transport protocol(s). g. MUST free up the affected TTTs (and STags, if applicable) and the=20 corresponding buffers once it receives the associated Nop-Out=20 acknowledgement that the initiator generated in response to the Async=20 Message.=20 Implementation note: Technically, the TMF servicing is complete in Step.e. = Data transfers corresponding to terminated tasks may however still be in=20 progress even at the end of Step.f. TMF Response MUST NOT be sent by the=20 target iSCSI layer before the end of Step.e, and MAY be sent at the end of = Step.e despite these outstanding Data transfers until Step.g. Step.g=20 specifies an event to free up any such resources that may have been=20 reserved to support outstanding data transfers.=20 4.1.3.1 Clearing effects update Appendix F.1 of [RFC3720] specifies the clearing effects of target and LU=20 resets on ?Incomplete TTTs? as ?Y?. This meant that a target warm reset=20 or a target cold reset or an LU reset would clear the active TTTs upon=20 completion. The TaskReporting=3DFastAbort (section 9.1) semantics defined = by this section however do not guarantee that the active TTTs are cleared=20 by the end of the reset operations. In fact, the new semantics are=20 designed to allow clearing the TTTs in a ?lazy? fashion after the TMF=20 Response is delivered. Thus, when TaskReporting=3DFastAbort is operational= =20 on a session, the clearing effects of reset operations on ?Incomplete=20 TTTs? is ?N?.=20 4.1.4 Implementation considerations Both in clarified semantics (section 4.1.2) and updated semantics (section = 4.1.3), there may be outstanding data transfers even after the TMF=20 completion is reported on the issuing session. In the case of iSCSI/iSER=20 [iSER], these would be tagged data transfers for STags not owned by any=20 active tasks. Whether or not real buffers support these data transfers is = implementation-dependent. However, the data transfers logically MUST be=20 silently discarded by the target iSCSI layer in all cases. A target MAY,=20 on an implementation-defined internal timeout, also choose to drop the=20 connections on which it did not receive the expected Data-out sequences=20 (section 4.1.2) or Nop-Out acknowledgements (section 4.1.3) so as to=20 reclaim the associated buffer, STag and TTT resources as appropriate. ----- Original Message ---- From: "Black=5FDavid@emc.com" To: Black=5FDavid@emc.com; cb=5Fmallikarjun@yahoo.com; ips@ietf.org Sent: Wednesday, December 20, 2006 2:33:43 PM Subject: RE: [Ips] Implementer's Guide - Task Management Issue > Let's try this line of reasoning - the target issues the Nop-Out, now when > can it free the resources? Answer: > - The Nop-In response comes back, OR > - The connection times out and is torn down. > Now, what if the Nop-Out is not issued - what does the target wait for to > free the resources? Answer: > - The transfers complete, OR > - The connection times out and is torn down.=20 > Those look similar enough at the target (the worst case is the same - the > resources are tied up until an uncooperative initiator times out) that > I don't see the harm in allowing the early TMF return without the new > key. The clear distinction is that the first two bullets are different; > if the new key is not negotiated, the target has to wait for the transfers > to complete; the new key and the Nop-Out are necessary to walk away earlier > when the initiator involved is able to continue the transfers. That got slightly twisted - what it should have talked about was the target issuing the new Async Message and the Nop-Out response coming back. 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=5Fdavid@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around=20 http://mail.yahoo.com=20 =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --=_alternative 0039D6E7C2257252_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
Mallikarjun,

I would consider the text:

c. MUST leave all active "affected TTTs" (i.e. active TTTs associated with affected tasks) valid along with any buffer allocations for the TTTs intact.

somewhat excessive as it relates too much to implementation. I would rather say:

c. MUST leave all active "affected TTTs" (i.e. active TTTs associated with affected tasks) valid.

and leave the buffer issue to the implementer (as I have stated already on this list).

I also keep thinking (and mildly  objecting to) that the whole fast abort is excesively complex.

You could achive the same effect by issuing the TM command on every affected connection.
The third party story is even more puzzling as in order to negotiate any of the nem TM modes the taget will have to ascertain that all other initiators support it. I fail to understand how would you handle downgrading the mode for those that don't. And if you don't downgrade why not state that fast-abort and target scoped queues don't go together and simplify the mechanics to a multiple issue TM.

Thanks,
Julo


"Mallikarjun C.&= quot; <cb=5Fmallikarjun@yahoo.com>

28/12/06 06:41

To
ips@ietf.org
cc
Subject
[Ips] TMF text with updates




Attached is the latest text that incorporates David's proposed enhancement.  Please review and comment.  Note especially two things: new section 4.1.4 that summarizes generic implementation consid= erations for both "clarified" and "updated" semantics, the chang= ed text in 4.1.2 that says "MAY wait for ....target transfer tags.....from third-party initiators" from the previous blanket MUST.

Mallikarjun



4.1.2 Clarified multi-task abort semantics
All iSCSI implementations MUST support the protocol behavior defined in this section as the default behavior.  The execution of ABORT TASK SET, CLEAR TASK SET, LOGICAL UNIT RESET, TARGET WARM RESET, and TARGET COLD RESET TMF Requests consists of the following sequence of actions in the specified order on the specified party.
The initiator iSCSI layer:
a. MUST continue to respond to each TTT received for the affected tasks.
b. Should receive any responses that the target may provide for some tasks among the affected tasks (may process them as usual because they are guaran= teed to have chronologically originated prior to the TMF response).
c. Should receive the TMF Response concluding all the tasks in the set of affected tasks.

The target iSCSI layer:
a. MUST wait for currently valid target transfer tags of the affected tasks from the issuing initiator to be responded to.  MAY wait for responses on currently valid target transfer tags of the affected tasks from third-pa= rty initiators.
b. MUST wait (concurrent with the wait in Step.a) for all commands of the affected tasks to be received based on the CmdSN ordering.   SHOULD NOT wait for new commands on third-party affected sessions - only the insta= ntiated tasks have to be considered for the purpose of determining the affected tasks.  In the case of target-scoped requests (i.e. TARGET WARM RESET and TARGET COLD RESET), all the commands that are not yet received on the issuing session in the command stream however can be considered to have been received with no command waiting period - i.e. the entire CmdSN space up to the CmdSN of the task management function can be "plugged".=
c. MUST propagate the TMF request to and receive the response from the target SCSI layer.
d. MUST address the Response Fence flag on the TMF Response on issuing session as defined in 3.3.2.
e. MUST address the Response Fence flag on the first post-TMF Response on third-party sessions as defined in 3.3.2.  If some tasks originate from non-iSCSI I=5FT=5FL nexuses then the means by which the target ensures that all affected tasks have returned their status to the initiator are defined by the specific non-iSCSI transport protocol(s).
Implementation note: Technically, the TMF servicing is complete in Step.d.  Data transfers corresponding to terminated tasks may however still be in progress on third-party iSCSI sessiosn even at the end of Step.e.  TMF Response MUST NOT be sent by the target iSCSI layer before the end of Step.d, and MAY be sent at the end of Step.d despite these outstandi= ng Data transfers until after Step.e.

4.1.3 Updated multi-task abort semantics
Protocol behavior defined in this section MUST be implemented by all iSCSI implementations complying with this document.  Protocol behavior defin= ed in this section MUST be exhibited by iSCSI implementations on an iSCSI session when they negotiate the TaskReporting (section 9.1) key to “F= astAbort” on that session.  The execution of ABORT TASK SET, CLEAR TASK SET, LOGICAL UNIT RESET, TARGET WARM RESET, and TARGET COLD RESET TMF Requests consists of the following sequence of actions in the specified order on the specified party.
The initiator iSCSI layer:
a. MUST NOT send any more Data-Out PDUs for affected tasks on the issuing connection of the issuing iSCSI session once the TMF is sent to the target.=
b. Should receive any responses that the target may provide for some tasks among the affected tasks (may process them as usual because they are guaran= teed to have chronologically originated prior to the TMF response).
c. MUST respond to Async Message PDU with AsyncEvent=3D5 as defined in sect= ion 8.1.
d. Should receive the TMF Response concluding all the tasks in the set of affected tasks.

The target iSCSI layer:
a. MUST wait for all commands of the affected tasks to be received based on the CmdSN ordering on the issuing session.  SHOULD NOT wait for new commands on third-party affected sessions - only the instantiated tasks have to be considered for the purpose of determining the affected tasks.  In the case of target-scoped requests (i.e. TARGET WARM RESET and TARGET COLD RESET), all the commands that are not yet received on the issui= ng session in the command stream however can be considered to have been receiv= ed with no command waiting period - i.e. the entire CmdSN space up to the CmdSN of the task management function can be "plugged".
b. MUST propagate the TMF request to and receive the response from the target SCSI layer.
c. MUST leave all active "affected TTTs" (i.e. active TTTs associ= ated with affected tasks) valid along with any buffer allocations for the TTTs intact.
d. MUST generate an Asynchronous Message PDU with AsyncEvent=3D5 (section 8.1) on:
i) each connection of each third-party session that at least one affected task is allegiant to, and
ii) each connection except the issuing connection of the issuing session that has at least one allegiant affected task.
If there are multiple affected LUs (say due to a target reset), then one Async Message PDU MUST be sent for each such LU on each connection that has at least one allegiant affected task.
e. MUST address the Response Fence flag on the TMF Response on issuing session as defined in 3.3.2.
f. MUST address the Response Fence flag on the first post-TMF Response on third-party sessions as defined in 3.3.2. If some tasks originate from non-iSCSI I=5FT=5FL nexuses then the means by which the target ensures that all affected tasks have returned their status to the initiator are defined by the specific non-iSCSI transport protocol(s).
g. MUST free up the affected TTTs (and STags, if applicable) and the corres= ponding buffers once it receives the associated Nop-Out acknowledgement that the initiator generated in response to the Async Message.  
Implementation note: Technically, the TMF servicing is complete in Step.e.  Data transfers corresponding to terminated tasks may however still be in progress even at the end of Step.f.  TMF Response MUST NOT be sent by the target iSCSI layer before the end of Step.e, and MAY be sent at the end of Step.e despite these outstanding Data transfers until Step.g.  Step.g specifies an event to free up any such resources that may have been reserved to support outstanding data transfers.  
4.1.3.1 Clearing effects update
Appendix F.1 of [RFC3720] specifies the clearing effects of target and LU resets on “Incomplete TTTs” as “Y”.  This m= eant that a target warm reset or a target cold reset or an LU reset would clear the active TTTs upon completion.  The TaskReporting=3DFastAbort (section 9.1) sem= antics defined by this section however do not guarantee that the active TTTs are cleared by the end of the reset operations.  In fact, the new semantics are designed to allow clearing the TTTs in a “lazy” fashion aft= er the TMF Response is delivered.  Thus, when TaskReporting=3DFastAbort is operational on a session, the clearing effects of reset operations on ̶= 0;Incomplete TTTs” is “N”.  
4.1.4 Implementation considerations
Both in clarified semantics (section 4.1.2) and updated semantics (section 4.1.3), there may be outstanding data transfers even after the TMF completi= on is reported on the issuing session.  In the case of iSCSI/iSER [iSER], these would be tagged data transfers for STags not owned by any active tasks.  Whether or not real buffers support these data transfers is implementation-dependent.  However, the data transfers logically MUST be silently discarded by the target iSCSI layer in all cases.  A target MAY, on an implementation-defined internal timeout, also choose to drop the connections on which it did not receive the expected Data-out sequences (section 4.1.2) or Nop-Out acknowledgements (section 4.1.3) so as to reclaim the associated buffer, STag and TTT resources as appropriate.


----- Original Message ----
From: "Black=5FDavid@emc.com" <Black=5FDavid@emc.com>
To: Black=5FDavid@emc.com; cb=5Fmallikarjun@yahoo.com; ips@ietf.org
Sent: Wednesday, December 20, 2006 2:33:43 PM
Subject: RE: [Ips] Implementer's Guide - Task Management Issue


> Let's try this line of reasoning - the target issues the Nop-Out, now
when
> can it free the resources?  Answer:
>     - The Nop-In response comes back, OR
>     - The connection times out and is torn down.
> Now, what if the Nop-Out is not issued - what does the target wait for
to
> free the resources?  Answer:
>     - The transfers complete, OR
>     - The connection times out and is torn down.
> Those look similar enough at the target (the worst case is the same -
the
> resources are tied up until an uncooperative initiator times out) that
> I don't see the harm in allowing the early TMF return without the new
> key.  The clear distinction is that the first two bullets are
different;
> if the new key is not negotiated, the target has to wait for the
transfers
> to complete; the new key and the Nop-Out are necessary to walk away
earlier
> when the initiator involved is able to continue the transfers.

That got slightly twisted - what it should have talked about was the
target
issuing the new Async Message and the Nop-Out response coming back.

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=5Fdavid@emc.com        Mobile: +1 (978) 394-7754<= br> ----------------------------------------------------

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips
--=_alternative 0039D6E7C2257252_=-- --===============1482732563== 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 --===============1482732563==-- From HurleyElle@bulkstore.net Thu Dec 28 12:53:08 2006 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GzzRE-0002dc-OI for ips-archive@lists.ietf.org; Thu, 28 Dec 2006 12:53:08 -0500 Received: from p54b1d691.dip.t-dialin.net ([84.177.214.145]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GzzRA-0005GS-Oe for ips-archive@lists.ietf.org; Thu, 28 Dec 2006 12:53:06 -0500 Received: from [180.107.140.52] (port=18587 helo=[180.107.140.52]) by p54B1D691.dip.t-dialin.net with esmtp id 1xsOeX-000UOV-04 for ips-archive@lists.ietf.org; Thu, 28 Dec 2006 18:53:23 +0100 Message-ID: <000a01c72aa9$019637d0$91d6b154@c18> From: "MooreMaria MillerMena" To: ips-archive@lists.ietf.org Subject: April March February Date: Thu, 28 Dec 2006 18:52:56 +0100 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0006_01C72AB1.635A9FD0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 4.3 (++++) X-Scan-Signature: 2bf730a014b318fd3efd65b39b48818c ------=_NextPart_000_0006_01C72AB1.635A9FD0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0007_01C72AB1.635A9FD0" ------=_NextPart_001_0007_01C72AB1.635A9FD0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable July june may april march february january. April march february january adriana limaalexis jolieanna. Wont, pose = nude more faster. Kill pussycat murphys miracles are. Jolieanna, lavignebai diazcanned tunacarmen, hurleyelle klumhilary = duffhilary. Klumhilary duffhilary swankholly love krupajodie marshkate hudsonkate, = mosskatie. November october, september august july. Duffhilary = swankholly love krupajodie marshkate hudsonkate mosskatie brookkelly = kreuklacey. Your ad here december november, october september august. Past moments your ad here december november october september? Is = tinkerbell past moments your ad here december. Mosskatie brookkelly, = kreuklacey lohanlucy, mooremaria millermena rubiopetra dawsonrose. Nude = more, faster kill pussycat murphys miracles. Picture moment laquo canned tuna elisha. February january, adriana limaalexis! Moments, your ad here december = november. Mosskatie brookkelly kreuklacey lohanlucy mooremaria millermena = rubiopetra dawsonrose! Tunacarmen, hurleyelle klumhilary duffhilary, swankholly. October = september august july june may april march february. Murphys miracles are worth admission is. More faster kill, pussycat murphys miracles. Tinkerbell past, moments = your ad here. Marshkate hudsonkate mosskatie brookkelly kreuklacey lohanlucy = mooremaria. Pussycat murphys miracles are worth. Brittany, murphy picture moment = laquo canned tuna elisha, cuthbert. Nude more faster kill pussycat = murphys miracles. Jolieanna lavignebai diazcanned tunacarmen hurleyelle klumhilary = duffhilary. Brittany murphy picture moment laquo. ------=_NextPart_001_0007_01C72AB1.635A9FD0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
3D"Ad"
July june may april march february = january.
April march february january adriana = limaalexis=20 jolieanna. Wont, pose nude more faster. Kill pussycat murphys miracles = are.
Jolieanna, lavignebai diazcanned = tunacarmen,=20 hurleyelle klumhilary duffhilary.
Klumhilary duffhilary swankholly love = krupajodie=20 marshkate hudsonkate, mosskatie. November october, september august = july.=20 Duffhilary swankholly love krupajodie marshkate hudsonkate mosskatie = brookkelly kreuklacey.
Your ad here december november, october = september august.
Past moments your ad here december = november october=20 september? Is tinkerbell past moments your ad here december. Mosskatie=20 brookkelly, kreuklacey lohanlucy, mooremaria millermena rubiopetra = dawsonrose.=20 Nude more, faster kill pussycat murphys miracles.
Picture moment laquo canned tuna = elisha.
February january, adriana limaalexis! = Moments, your=20 ad here december november.
Mosskatie brookkelly kreuklacey = lohanlucy=20 mooremaria millermena rubiopetra dawsonrose!
Tunacarmen, hurleyelle klumhilary = duffhilary,=20 swankholly. October september august july june may april march = february.
Murphys miracles are worth admission = is.
More faster kill, pussycat murphys = miracles.=20 Tinkerbell past, moments your ad here.
Marshkate hudsonkate mosskatie = brookkelly=20 kreuklacey lohanlucy mooremaria.
Pussycat murphys miracles are worth. = Brittany,=20 murphy picture moment laquo canned tuna elisha, cuthbert. Nude more = faster kill=20 pussycat murphys miracles.
Jolieanna lavignebai diazcanned = tunacarmen=20 hurleyelle klumhilary duffhilary. Brittany murphy picture moment=20 laquo.
------=_NextPart_001_0007_01C72AB1.635A9FD0-- ------=_NextPart_000_0006_01C72AB1.635A9FD0 Content-Type: image/gif; name="Cuthbert Wont.gif" Content-Transfer-Encoding: base64 Content-ID: <000501c72aa9$019637d0$91d6b154@c18> R0lGODlhTAK8AIfoAAAACIsAAAB3CYNyBgIKiYoAfgBzi8e3urrntq3G9UkWAGglAIUTB6ktCL0U AOMYAAxCACVHBzVFBm1OAHJKBp5KALpDAN9GCARRACxpCzJWB2BVDo5cAK5gAMVcAOxjAAB/DB6H AkpxAFaDAHx6AJ+OAMd1AOCHAAKkCiqjDD2VA2CXAoGdCp+qArKjC+acAgC9ACLKBjq1BlrOB4ix Apu8Br26DuDDAAPrBSvuAEHUAF3XAInUBZ3rAMLoAN/eAAYANRcKNjgKPFQGOncAOZcAOMsATuEK PgAtMRwnRU0oPFUgNngaNaYSSLotMdYjQwBGRxE8P04/QVpGSoo3R6pFO7I5Q9xHRwBlQiZgQTte PV1rOHlSAqdbQ81UNuhWTACFSCyFQ0qMQlOBN4dyTZ6ESsaNPuyIQgeiMi2fNzymOmuVRoGoOpif Q7eqRN2iSwC/NxPJQUq4NFe2TXi/M5+2QLLBRNy7SgDZQSjpPTPeRWHoTobsQpPqMcLaSubmTQUA iiUGfjgHd18AjIgOc50AebYAiuUAewAqfBYedkEcc1EbfokogpEhcckujNcqgQJHiCE2dTM+f2xE e3M4fKI0gspEe+YziARTfR1cejtVcmxYc3FaiaVkjL5cgOBriQCMchZxeEV1jVhyfnWEeZGBhcp3 juV3fwOphyWfgzitdVOUeo2SgZetgL2ScueRfwHIdiCzgTm2d1HAe328gJfCcsTBft6xdgDWdxHo d0TbdGrcjIPmd5bbfMXYhejcgQIEyCQAu0QAw1IAyogKsZEKvs4AtucAzQ0TshMdzDgZyGMRxH8a uJslucIpu+IhugBOsSdHyEBMtGY+uYEytpk/wbtKveNGzQBauBFlv0Bku2hsu4Jiup9rt8VtzOFS zQBxtimHsjh0vlaCt4WHx6t4scJ2u+KKtACRvBSWzDmVtVyfvIGVt5WTtLKStuatvwPKviDMyjq7 uWm6vobLtJzBzP/+5JKWm3eLjv8ICwD5APb3CAIA9P8A/wD9//b+/yH5BABv6NQALAAAAABMArwA Bwj/AO0JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIENu/EeypMmTKFOqXMmypcuX MGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJOyFMm0qdOnUKNKnUq1qtWrWLMWVMq1q9evYMOK HUu2rFmeWtOqXcu2rdu3cOPK5Xi2rt27ePPq3cvX6Ny/gAMLHky4sOHDiBMrXiy1r+PHkCPrZUy5 suXLmDO3lcy580rNoENT9ky6tOnTqFPnFc26tevXsGNjVE27Nk3ZuHOHts2btO7fwIMLH068uHG5 vZMrX868ufPn0Ccfn079bfTrSKtr3869u/fv4J1i/x9Pvrz58+jTOw/PPqv69/Djy1ffvj51APgB 2FeYP39D/AQBaA8BBBIgUH8CClRggQEiqJ89/h34oEEoIViSgwCQlJ9JG5JE4Hwg1mYRggM52GCJ EybIX4QQksgQhg+qKGB/KNL44oQttuhiRTPiqCJCMqYoJIpESlhkQSz+COSQORrEoo5H7ielYQn2 eKSVUa4YpZIJ/RjklT7i2GWMZGrZoI1FcrnQl0a22SabXNqo5okHxRkhmnNOqSdcasKpn5dijpkl RIDS2eShhJaJqJNiVhmmmw+xeaifdNqJpZmM1nlnkoHu6WlTNuGnkqgXZvhPfxWa6hKpp6pKE6sa uv/K6qyuyoRqrCvdiuuuvDr4EoylBissrKRiiKuosI5aa6kWttoqsqomm9Kn1GoU6rK8OvtsStIq y2GzMCULbLa+xkRsubGeK+yq2J6kbq+ymvput8V2yFK9l55Io6PV9ttWj/kCHGiehmbqUKFgCnrw o5q6aeLCNxrKb5oM25luu99mrK278nYc4sfpzRvvsbV2yy3GJp/MscYbp2ruyCpvDO29MNPMMq3r 4pxtzimT5LCiSCo6sb9EazXx0JeiiamkEReMNMP/QR00nkBrqrTCb26q9MMSuuhop1ZrLefATKYF 8tlKNaD22iQp4PbbJgUQQEly0/S2AiXd7bZMdbP/rO0CgC9At9yEywR43IQX/k/fJPWtdkmPoy35 5LYVjRGbchOUueWcd/4Q5aCHLvropJdu+umUe666ZaiLvvrrsMcuUuu04yT77bPXrvvuvNOG++/A By/88MQXb/zxyCev/PLMG9f789BH71jzrElv/fXYZw8U9YJp7/334KPFPWDhly/i+OinX5z57Lfv vs/qxy///PQL9z569eev/2X3z7f/+P0L4HP+NxsBGvCAtCNgeBBYPgU68IFzYaAEJ0jBClrwgniB oAY3qBYMepAoHKzKB0eokhAOhoQoTGFvTMjCFoJKhTCMYWlcSMMa2vCGOMwhaGTIwx768Iec0aGU /4BoHiFai4hIzEvPUoICFCRxJ0ZcoE0wQMUq6gQCEJgJDnDwRJY08Ysl+SIYu9g6imCRIGe0SBMj QsUcwgAGA3mjQNY4RyeSBIslweOzMEbG0b1RJX/8RyAF+cY/FjKMYrQjSRJpEiqaZJBJ1CNKBCAA k1CSJIGEpCSVEkXGbBEhcrRHKO1RRVK2sY32+GIdBTLKUdIRUhxUEyUJMkt7nDGNA8HlbvpoEx7t SEc4CqUw4WiPWhZTAALBpTIhgEM1QQEKBHlmMrHIzIIYs5P7MSYQtgkEgmxTIN+0RzjBAIaBkBOc 3UTnQMJpQ4EJ5Jq1JGc5DXLOF/JyPMAARkkWZP+SD/3DnwAlwD4F+o9tlsSgJMnnPQfaT4IilCQI 5edJHrrQ91CEafzgR9Cy9jOB5HMgH/UoMAgSUhayM5wZHUhKFWQgAhXEpbCpKFHQBVEgTNSmBcUp QmnKTYq+i4z5DKo+/7kggu7qXNisFsGSCpWjPYmp+1kqVKcau6AsUabNoWr3sIo9rXp1OFw131eH GNaymvWsQRyrbKR3VbTKtK1JgWtRwJWudbELJ3QNFx/nulfQ0TRmbvUWx+x1MsLmtSX18tu1vtUs nTlrZkhxrF598tOWyTU6Fy3bjTj1VBo+bGgb5SgsscY0iWwNbBL7k2odctTD3pVdugJXYi/mt8r/ tow+E3Eqp0YLWqmmT1niilZftSVZm5GrY7r6Vc1yJdw9zgRfO3utcW/b2urKbLnBlU9mKdaoqnV0 UBC8GmgVNt4lOY1M3sUUMO00NQB11ryTQm3Dmraon5UXUaWtb30Stzl7qM0gbhNIfwfC3wF79kf9 NfBB/lsj3zJNQAkOwEMUPJAAE5jCXVstQxjMYP82wCGBc4iF7THiwIVYwIQ7E45GbI8BKxjD7GHx QABnEAc4QCD5yIfBjHg3IkWXsYgbnHJNsre84e0fNi5JkmHygAcw18g2g2xLckySJSPZAS9hXJbn 1jguM45xyRVyl00Suehedj0TobCCLazgHA/E/804pDGN45uQDldYAXeOmuYkfGGB2Hggf3bIgE/S 5DFHOUNtPdyVlYzllpQZJlT+R47z0bYjw82ufdNyTayMW4lQGM57brCQnirjWGp4aP1l72gPEug+ t5jPr3Z1QwYMajjrTcYRhvVCOPxhgdgZIbfGM0NsTOwbC8TEc/Z1r+/M4gE3W9cCKXVwbFJolCg6 yDbhNBEnPWkyr60BJrFysYk9OMVtebDxCvNKvl1m12KnyC3R8qMf/Q96B7Z91R6LtgW7u333BN4W VStUGMAAtRB82Mb2CHoILhR/39utFKBASxg+veHoUuAYt8jDN87xjuck4/nz+D9ATvKSm/zkwv+7 Zka2yHKWi+biKGeqTahJc5hs0ic3L0rOk3LJlFAUbTEfTj0jwk6EhLPoCxn6OnvaEaRDhZJQR+Y7 oR50kjs9IT09KdNZynWHwNTo6SzqQIpqIHRyE6RCBW9HFgTfqmNcqCWdr35LerWFxN0gMGUQ2vc+ oLL3ne9q50hGV2qQqwtP5GbJiICyrs7Gh7bvX9dzQeA+UnvcXetd//uqnaJ3g9w9NogHWUYi/1K/ f51rdVevONO5eljqlmpWYfvjnxJ6XqbsoQjFPU5rOhN/Dmu2PPsxdZOiUIUqlnduh8tihf+PjJJk 8AkdalCPj9hllcv3HiJogbLP0OfzY2VHKf7/UO1ae7T68r0EITva0x54jHwe9Vc7u+NDQnkV+zb5 +Me736ly/6r0vyPl90Fu8X8dQYBSYYD5l4Bs8UsK2IAO+IDNE4C6A4ETIYEWWEEUaBUXuIH+k4Ee +IEgGIIhZ34iWIImeIIomIIquIJUxYEu2EAsGIOF8YJeMVY0iIFGdIM6uIM8iFky+IO40YNCOIRE WIRcIXNGmITeA4RMqBlK+IRQGIVSeDZNWIW/5VZWmIVaqHFT2IVeOHJbeBBfOIFhWIZmmDtdeIZq 2BhjCD1r+IaB0YbLsYZy6BNweId4mIedBIV62IcdVIeP4YcKAYgmIYiGOIiESIYol4inc4jKZ8eI n+GIkjiJlFiJlniJmFg0RZiJrAOJdcGJAuGJkQGKpFiKFCKKe2GKqriK9mBWrPiKj4iKAwSLtBiK sthVtUiBt7iBudiLvtiJuxgi+ReMGfSLxvgRxJiMykgWx6iKy2g7zUgQAQEAOw== ------=_NextPart_000_0006_01C72AB1.635A9FD0-- From ips-bounces@ietf.org Thu Dec 28 14:46:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H01CG-0004eP-6T; Thu, 28 Dec 2006 14:45:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H01CE-0004eG-WC for ips@ietf.org; Thu, 28 Dec 2006 14:45:47 -0500 Received: from web51914.mail.yahoo.com ([206.190.48.77]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H01CC-00080f-0J for ips@ietf.org; Thu, 28 Dec 2006 14:45:46 -0500 Received: (qmail 74560 invoked by uid 60001); 28 Dec 2006 19:45:36 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=kCC7COCLbi/SktLwIinBBNkpYj1wf2zzpefxQo/L0lh7wckyxT2OINXqN57/XBSDoqBkfCM3AoSRkIcKnbO9woytkWPBN3rLHtyCXDvpRbjOpAcM+GsfU/VeG4D44oF0GIQ/j9KGEPF3NjKfbiUO3U54YVOIVjEnvA5aOppciUE= ; Message-ID: <20061228194536.74558.qmail@web51914.mail.yahoo.com> Received: from [216.93.234.151] by web51914.mail.yahoo.com via HTTP; Thu, 28 Dec 2006 11:45:36 PST Date: Thu, 28 Dec 2006 11:45:36 -0800 (PST) From: "Mallikarjun C." Subject: Re: [Ips] IG clarifications: Login Response & Reject reason codes To: Julian Satran MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a 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="===============0043889902==" Errors-To: ips-bounces@ietf.org --===============0043889902== Content-Type: multipart/alternative; boundary="0-572170783-1167335136=:73137" --0-572170783-1167335136=:73137 Content-Type: text/plain; charset=ascii Content-Transfer-Encoding: quoted-printable Julian,=0A=0AThanks for the inputs, I somehow overlooked to respond to this= email earlier.=0A=0AI agree with you on the "Task in progress" Reject reas= on code. There is no =0A=0AUnless I hear new objections, I would like to n= ote "Negotiation Reset" Reject reason code as obsolete. Based on the silen= ce so far, like you, I do not believe it is in use.=0A=0AOn the "no more th= an one outstanding Login Response" semantics, your comments seem to be arou= nd Login Request PDU (and I believe we have such text for Login Request PDU= ) - do you see any cases wherein there can be multiple outstanding Login Re= sponses on the wire? The request I got was to clarify if there is a plausi= ble use case. =0A=0AThanks!=0A=0AMallikarjun=0A=0A----- Original Message -= ---=0AFrom: Julian Satran =0ATo: Mallikarjun C. <= cb_mallikarjun@yahoo.com>=0ACc: IPS =0ASent: Monday, December= 11, 2006 1:34:41 PM=0ASubject: Re: [Ips] IG clarifications: Login Response= & Reject reason codes=0A=0A=0A=0A"Mallikarjun C." wrote on 11/12/2006 20:15:23:=0A=0A> All:=0A> =0A> I received some offli= ne feedback on the implementers' guide draft =0A> from a few reviewers who= preferred to be anonymous. Please review & comment.=0A> =0A> 1) RFC 3720 = does not explicitly call out that there cannot be more =0A> than one outsta= nding Login-Response PDU on one iSCSI connection at =0A> any given time (al= though the C-bit text indirectly implies it).=0A> =0A> =0A=0AThis is intent= ional. At the time we where playing with the idea of pipelining the login. = =0AHowever it is common practice to have a single outstanding Login Request= . =0AI think that the only thing that becomes problematic is the phase chan= ge request (there you can have only one outstanding). =0AThere is already t= ext that says that all changes to key values become final only at the end (= when consistency can be reasonably checked). =0A=0A> Section 10.10 on Text = Request PDU (which should cover Login Request =0A> PDU semantics as well) s= ays: "An initiator MUST have at most one =0A> outstanding Text Request on a= connection at any given time." =0A> Essentially, an analog for Login/Text= Response is missing (or so it seems).=0A> =0A> 2) RFC 3720 does not specif= y the use case for Reject reason code =0A> "Task in progress" (0x07).=0A> = =0A> I vaguely recall we put in this reason code for task reassignment =0A>= attempts while a task is in progress, but then we subsequently added=0A> a= TMF response reason code for that case (Julian?). So I'm not sure=0A> if = reason code 0x07 is used by implementations any longer. =0A> =0A=0AThe rej= ect can used when the initiator attempts to start a new task but a task wit= h the same ITT is still active for those cases when the target can't be sur= e this is a protocol error (e.g., a race between a logout and a reissued SC= SI command). =0A=0A> The other non-obvious case is that of a "negotiation r= eset" Reject =0A> reason code. What is this used for by implementations, i= f at all? =0A> If I don't hear any objections, I will deprecate these two = reason codes.=0A> =0A=0AThe negotiating can't be continued by one of the pa= rties but the partial results (e.g., previous stage) are OK and no renegoti= ation is deemed necessary. I have no clue if somebody uses it but I felt at= the time that the purists will object if I'd suggest restarting the login = :-) =0A=0A> Mallikarjun=0A> =0A> =0A> =0A> _______________________________= _____________________________________________________=0A> Do you Yahoo!?=0A= > Everyone is raving about the all-new Yahoo! Mail beta.=0A> http://new.mai= l.yahoo.com=0A> =0A> _______________________________________________=0A> Ip= s mailing list=0A> Ips@ietf.org=0A> https://www1.ietf.org/mailman/listinfo/= ips=0A=0A__________________________________________________=0ADo You Yahoo!= ?=0ATired of spam? Yahoo! Mail has the best spam protection around =0Ahttp= ://mail.yahoo.com --0-572170783-1167335136=:73137 Content-Type: text/html; charset=ascii Content-Transfer-Encoding: quoted-printable
Julian,
=0A
 
=0A

I agree with you on the "Task in progress" Rejec= t reason code.  There is no
=0A
 
=0A
=0A
 
=0A
= On the "no more than one outstanding Login Response" semantics, your commen= ts seem to be around Login Request PDU (and I believe we have such tex= t for Login Request PDU) - do you see any cases wherein there can be multip= le outstanding Login Responses on the wire?  The request I got wa= s to clarify if there is a plausible use case.  
=0A
Thanks!
=0A
 
=0A
Mallikarjun
=0A
----- Original Message ----
From: J= ulian Satran <Julian_Satran@il.ibm.com>
To: Mallikarjun C. <cb_= mallikarjun@yahoo.com>
Cc: IPS <ips@ietf.org>
Sent: Monday, = December 11, 2006 1:34:41 PM
Subject: Re: [Ips] IG clarifications: Login= Response & Reject reason codes



"Mall= ikarjun C." <cb_mallikarjun@yahoo.com> wrote on 11/12/2006 20:15:23:<= BR>
> All:
>
> I received some offline feedback on the i= mplementers' guide draft
> from  a few reviewers who preferred = to be anonymous.  Please review & comment.
>
> 1) RFC= 3720 does not explicitly call out that there cannot be more
> than = one outstanding Login-Response PDU on one iSCSI connection at
> any = given time (although the C-bit text indirectly implies it).
> =
>

This is intentional. At the time we where playi= ng with the idea of pipelining the login.
However it is common practice to have a single outstanding Login Request.=
I think that the only thing that become= s problematic is the phase change request (there you can have only one outs= tanding).
There is already text that say= s that all changes to key values become final only at the end (when consist= ency can be reasonably checked).

>= ; Section 10.10 on Text Request PDU (which should cover Login Request
&= gt; PDU semantics as well) says: "An initiator MUST have at most one
&g= t; outstanding Text Request on a connection at any given time."  
&= gt; Essentially, an analog for Login/Text Response is missing (or so it see= ms).
>
> 2) RFC 3720 does not specify the use case for Reject = reason code
> "Task in progress" (0x07).
>
> I vaguely recall we put in thi= s reason code for task reassignment
> attempts while a task is in pr= ogress, but then we subsequently added
> a TMF response reason code f= or that case (Julian?).  So I'm not sure
> if reason code 0x07 i= s used by implementations any longer.  
>

The reject can used when the initiator attempts to start a= new task but a task with the same ITT is still active for those cases when= the target can't be sure this is a protocol error (e.g., a race between a = logout and a reissued SCSI command).
> The other non-obvious case is that of a "negotiation reset" Reject > reason code.  What is this used for by implementations, if at a= ll?  
> If I don't hear any objections, I will deprecate these t= wo reason codes.
>

The negotia= ting can't be continued by one of the parties but the partial results (e.g., previous st= age) are OK and no renegotiation is deemed necessary. I have no clue if som= ebody uses it but I felt at the time that the purists will object if I'd su= ggest restarting the login :-)

> = Mallikarjun
>
>
>  
> ______________________= ______________________________________________________________
> Do y= ou Yahoo!?
> Everyone is raving about the all-new Yahoo! Mail beta.> http://new.mail.yahoo.com
>
> _________________________= ______________________
> Ips mailing list
> Ips@ietf.org
>= ; https://www1.ietf.org/mailman/listinfo/ips
=0A


__________________________________________________<= br>Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protecti= on around
http://mail.yahoo.com --0-572170783-1167335136=:73137-- --===============0043889902== 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 --===============0043889902==-- From ips-bounces@ietf.org Thu Dec 28 14:54:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H01Kv-0007UK-PF; Thu, 28 Dec 2006 14:54:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H01Ku-0007TS-4R for ips@ietf.org; Thu, 28 Dec 2006 14:54:44 -0500 Received: from mexforward.lss.emc.com ([128.222.32.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H01Kq-0001ND-UG for ips@ietf.org; Thu, 28 Dec 2006 14:54:44 -0500 Received: from mailhub.lss.emc.com (uraeus.lss.emc.com [10.254.144.14]) by mexforward.lss.emc.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id kBSJsceG022196; Thu, 28 Dec 2006 14:54:38 -0500 (EST) Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id kBSJsFbV022668; Thu, 28 Dec 2006 14:54:32 -0500 (EST) From: Black_David@emc.com Received: from CORPUSMX20A.corp.emc.com ([128.221.62.13]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Dec 2006 14:54:28 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ips] TMF text with updates Date: Thu, 28 Dec 2006 14:54:27 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ips] TMF text with updates Thread-Index: Accqa5rJ6uiq0wSTSMC8qOceiN2cJwATQiOw To: , X-OriginalArrivalTime: 28 Dec 2006 19:54:28.0067 (UTC) FILETIME=[FB882B30:01C72AB9] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2006.12.28.112433 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -2, HTML_NO_HTTP 0.1, NO_REAL_NAME 0, __C230066_P5 0, __CP_URI_IN_BODY 0, __CT 0, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0, __CTYPE_MULTIPART_ALT 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_HTML 0, __MIME_VERSION 0, __SANE_MSGID 0, __TAG_EXISTS_HTML 0' X-Spam-Score: 0.5 (/) X-Scan-Signature: c2427de1554ed8e3804597b4bf60f110 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="===============0419763752==" Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============0419763752== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C72AB9.FB0FA731" This is a multi-part message in MIME format. ------_=_NextPart_001_01C72AB9.FB0FA731 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable I agree with Julian that we should avoid discussing "buffer allocations" and the like, even though we know that something like that has to happen in at least iSER implementations. A general discussion of "resources" works. =20 > You could achive the same effect by issuing the TM command on every affected connection. =20 Not for TMF's that affect commands from other initiators. Also, asking the target to coordinate receipt of the TM command on every connection in a multi-connection session is also a bit much. =20 > The third party story is even more puzzling as in order to negotiate any of > the new TM modes the taget will have to ascertain that all other initiators > support it. I fail to understand how would you handle downgrading the mode > for those that don't. =20 I think the target has to track this initiator by initiator, and not issue the new async message to old initiators. This increases the importance of being able to complete a TMF in the face of an uncooperative third party "Legacy" initiator. =20 > And if you don't downgrade why not state that fast-abort and target scoped > queues don't go together and simplify the mechanics to a multiple issue TM.=20 This didn't parse for me - could you explain in more detail? =20 Thanks, --David ----------------------------------------------------=20 David L. Black, Senior Technologist=20 EMC Corporation, 176 South St., Hopkinton, MA 01748=20 +1 (508) 293-7953 FAX: +1 (508) 293-7786=20 black_david@emc.com Mobile: +1 (978) 394-7754=20 ----------------------------------------------------=20 ________________________________ From: Julian Satran [mailto:Julian_Satran@il.ibm.com]=20 Sent: Thursday, December 28, 2006 5:32 AM To: Mallikarjun C. Cc: ips@ietf.org Subject: Re: [Ips] TMF text with updates =09 =09 Mallikarjun,=20 =09 I would consider the text:=20 =09 c. MUST leave all active "affected TTTs" (i.e. active TTTs associated with affected tasks) valid along with any buffer allocations for the TTTs intact.=20 =09 somewhat excessive as it relates too much to implementation. I would rather say:=20 =09 c. MUST leave all active "affected TTTs" (i.e. active TTTs associated with affected tasks) valid.=20 =09 and leave the buffer issue to the implementer (as I have stated already on this list).=20 =09 I also keep thinking (and mildly objecting to) that the whole fast abort is excesively complex.=20 =09 You could achive the same effect by issuing the TM command on every affected connection.=20 The third party story is even more puzzling as in order to negotiate any of the nem TM modes the taget will have to ascertain that all other initiators support it. I fail to understand how would you handle downgrading the mode for those that don't. And if you don't downgrade why not state that fast-abort and target scoped queues don't go together and simplify the mechanics to a multiple issue TM.=20 =09 Thanks,=20 Julo=20 =09 =09 =09 "Mallikarjun C." =20 28/12/06 06:41=20 To ips@ietf.org=20 cc Subject [Ips] TMF text with updates =09 Attached is the latest text that incorporates David's proposed enhancement. Please review and comment. Note especially two things: new section 4.1.4 that summarizes generic implementation considerations for both "clarified" and "updated" semantics, the changed text in 4.1.2 that says "MAY wait for ....target transfer tags.....from third-party initiators" from the previous blanket MUST. =09 Mallikarjun =09 =09 =09 4.1.2 Clarified multi-task abort semantics All iSCSI implementations MUST support the protocol behavior defined in this section as the default behavior. The execution of ABORT TASK SET, CLEAR TASK SET, LOGICAL UNIT RESET, TARGET WARM RESET, and TARGET COLD RESET TMF Requests consists of the following sequence of actions in the specified order on the specified party.=20 The initiator iSCSI layer: a. MUST continue to respond to each TTT received for the affected tasks.=20 b. Should receive any responses that the target may provide for some tasks among the affected tasks (may process them as usual because they are guaranteed to have chronologically originated prior to the TMF response).=20 c. Should receive the TMF Response concluding all the tasks in the set of affected tasks.=20 =09 The target iSCSI layer: a. MUST wait for currently valid target transfer tags of the affected tasks from the issuing initiator to be responded to. MAY wait for responses on currently valid target transfer tags of the affected tasks from third-party initiators. b. MUST wait (concurrent with the wait in Step.a) for all commands of the affected tasks to be received based on the CmdSN ordering. SHOULD NOT wait for new commands on third-party affected sessions - only the instantiated tasks have to be considered for the purpose of determining the affected tasks. In the case of target-scoped requests (i.e. TARGET WARM RESET and TARGET COLD RESET), all the commands that are not yet received on the issuing session in the command stream however can be considered to have been received with no command waiting period - i.e. the entire CmdSN space up to the CmdSN of the task management function can be "plugged". c. MUST propagate the TMF request to and receive the response from the target SCSI layer.=20 d. MUST address the Response Fence flag on the TMF Response on issuing session as defined in 3.3.2. e. MUST address the Response Fence flag on the first post-TMF Response on third-party sessions as defined in 3.3.2. If some tasks originate from non-iSCSI I_T_L nexuses then the means by which the target ensures that all affected tasks have returned their status to the initiator are defined by the specific non-iSCSI transport protocol(s). Implementation note: Technically, the TMF servicing is complete in Step.d. Data transfers corresponding to terminated tasks may however still be in progress on third-party iSCSI sessiosn even at the end of Step.e. TMF Response MUST NOT be sent by the target iSCSI layer before the end of Step.d, and MAY be sent at the end of Step.d despite these outstanding Data transfers until after Step.e. =09 4.1.3 Updated multi-task abort semantics Protocol behavior defined in this section MUST be implemented by all iSCSI implementations complying with this document. Protocol behavior defined in this section MUST be exhibited by iSCSI implementations on an iSCSI session when they negotiate the TaskReporting (section 9.1) key to "FastAbort" on that session. The execution of ABORT TASK SET, CLEAR TASK SET, LOGICAL UNIT RESET, TARGET WARM RESET, and TARGET COLD RESET TMF Requests consists of the following sequence of actions in the specified order on the specified party.=20 The initiator iSCSI layer: a. MUST NOT send any more Data-Out PDUs for affected tasks on the issuing connection of the issuing iSCSI session once the TMF is sent to the target. b. Should receive any responses that the target may provide for some tasks among the affected tasks (may process them as usual because they are guaranteed to have chronologically originated prior to the TMF response). c. MUST respond to Async Message PDU with AsyncEvent=3D5 as defined in section 8.1. d. Should receive the TMF Response concluding all the tasks in the set of affected tasks. =09 The target iSCSI layer: a. MUST wait for all commands of the affected tasks to be received based on the CmdSN ordering on the issuing session. SHOULD NOT wait for new commands on third-party affected sessions - only the instantiated tasks have to be considered for the purpose of determining the affected tasks. In the case of target-scoped requests (i.e. TARGET WARM RESET and TARGET COLD RESET), all the commands that are not yet received on the issuing session in the command stream however can be considered to have been received with no command waiting period - i.e. the entire CmdSN space up to the CmdSN of the task management function can be "plugged". b. MUST propagate the TMF request to and receive the response from the target SCSI layer.=20 c. MUST leave all active "affected TTTs" (i.e. active TTTs associated with affected tasks) valid along with any buffer allocations for the TTTs intact. d. MUST generate an Asynchronous Message PDU with AsyncEvent=3D5 (section 8.1) on: i) each connection of each third-party session that at least one affected task is allegiant to, and ii) each connection except the issuing connection of the issuing session that has at least one allegiant affected task. If there are multiple affected LUs (say due to a target reset), then one Async Message PDU MUST be sent for each such LU on each connection that has at least one allegiant affected task. e. MUST address the Response Fence flag on the TMF Response on issuing session as defined in 3.3.2. f. MUST address the Response Fence flag on the first post-TMF Response on third-party sessions as defined in 3.3.2. If some tasks originate from non-iSCSI I_T_L nexuses then the means by which the target ensures that all affected tasks have returned their status to the initiator are defined by the specific non-iSCSI transport protocol(s). g. MUST free up the affected TTTs (and STags, if applicable) and the corresponding buffers once it receives the associated Nop-Out acknowledgement that the initiator generated in response to the Async Message. =20 Implementation note: Technically, the TMF servicing is complete in Step.e. Data transfers corresponding to terminated tasks may however still be in progress even at the end of Step.f. TMF Response MUST NOT be sent by the target iSCSI layer before the end of Step.e, and MAY be sent at the end of Step.e despite these outstanding Data transfers until Step.g. Step.g specifies an event to free up any such resources that may have been reserved to support outstanding data transfers. =20 4.1.3.1 Clearing effects update Appendix F.1 of [RFC3720] specifies the clearing effects of target and LU resets on "Incomplete TTTs" as "Y". This meant that a target warm reset or a target cold reset or an LU reset would clear the active TTTs upon completion. The TaskReporting=3DFastAbort (section = 9.1) semantics defined by this section however do not guarantee that the active TTTs are cleared by the end of the reset operations. In fact, the new semantics are designed to allow clearing the TTTs in a "lazy" fashion after the TMF Response is delivered. Thus, when TaskReporting=3DFastAbort is operational on a session, the clearing effects of reset operations on "Incomplete TTTs" is "N". =20 4.1.4 Implementation considerations Both in clarified semantics (section 4.1.2) and updated semantics (section 4.1.3), there may be outstanding data transfers even after the TMF completion is reported on the issuing session. In the case of iSCSI/iSER [iSER], these would be tagged data transfers for STags not owned by any active tasks. Whether or not real buffers support these data transfers is implementation-dependent. However, the data transfers logically MUST be silently discarded by the target iSCSI layer in all cases. A target MAY, on an implementation-defined internal timeout, also choose to drop the connections on which it did not receive the expected Data-out sequences (section 4.1.2) or Nop-Out acknowledgements (section 4.1.3) so as to reclaim the associated buffer, STag and TTT resources as appropriate. =09 =09 ----- Original Message ---- From: "Black_David@emc.com" To: Black_David@emc.com; cb_mallikarjun@yahoo.com; ips@ietf.org Sent: Wednesday, December 20, 2006 2:33:43 PM Subject: RE: [Ips] Implementer's Guide - Task Management Issue =09 =09 > Let's try this line of reasoning - the target issues the Nop-Out, now when > can it free the resources? Answer: > - The Nop-In response comes back, OR > - The connection times out and is torn down. > Now, what if the Nop-Out is not issued - what does the target wait for to > free the resources? Answer: > - The transfers complete, OR > - The connection times out and is torn down.=20 > Those look similar enough at the target (the worst case is the same - the > resources are tied up until an uncooperative initiator times out) that > I don't see the harm in allowing the early TMF return without the new > key. The clear distinction is that the first two bullets are different; > if the new key is not negotiated, the target has to wait for the transfers > to complete; the new key and the Nop-Out are necessary to walk away earlier > when the initiator involved is able to continue the transfers. =09 That got slightly twisted - what it should have talked about was the target issuing the new Async Message and the Nop-Out response coming back. =09 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 ---------------------------------------------------- =09 __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around=20 http://mail.yahoo.com=20 =09 _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips =09 =09 ------_=_NextPart_001_01C72AB9.FB0FA731 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
I agree with Julian that we should avoid = discussing=20 "buffer allocations" and
the like, even though we know that something = like=20 that has to happen in at
least iSER implementations.  A=20 general discussion of "resources" works.
 
> You could achive the same effect = by issuing=20 the TM command on every affected connection.
 
Not for TMF's that affect commands from other initiators.  = Also,=20 asking the
target to coordinate receipt of the TM command on = every=20 connection in a
multi-connection session is also a bit = much.
 
> The third party story is even more puzzling as in order to = negotiate=20 any of
> the new TM modes the taget will have to ascertain that all = other=20 initiators
> support it. I fail to understand how would you handle = downgrading=20 the mode
> for those that don't.
 
I think the target has to track this initiator by initiator, = and not=20 issue the
new async message to old initiators.  This increases the = importance=20 of being
able to complete a TMF in the face of an uncooperative third = party=20 "Legacy"
initiator.
 
> And if you don't downgrade why not state that fast-abort = and target=20 scoped
> queues don't go together and simplify the mechanics to a = multiple=20 issue TM. =
This didn't parse for me - could you explain in more=20 detail?
 
Thanks,
--David

----------------------------------------------------=20
David L. = Black, Senior=20 Technologist
EMC Corporation, 176 South St., Hopkinton, MA  = 01748=20
+1 (508)=20 293-7953           = ; =20 FAX: +1 (508) 293-7786
black_david@emc.com        = Mobile: +1=20 (978) 394-7754
----------------------------------------------------=20


From: Julian Satran=20 [mailto:Julian_Satran@il.ibm.com]
Sent: Thursday, December = 28, 2006=20 5:32 AM
To: Mallikarjun C.
Cc:=20 ips@ietf.org
Subject: Re: [Ips] TMF text with=20 updates


Mallikarjun, =

I would consider the text: =

c. MUST leave all active "affected TTTs" (i.e. active TTTs = associated=20 with affected tasks) valid along with any buffer allocations for the = TTTs=20 intact.

somewhat = excessive as=20 it relates too much to implementation. I would rather say:=20

c. MUST leave all active "affected TTTs" = (i.e. active=20 TTTs associated with affected tasks) valid. =

and leave the buffer issue to the implementer (as I have = stated already=20 on this list).

I also keep = thinking (and=20 mildly  objecting to) that the whole fast abort is excesively=20 complex.

You could achive the = same effect=20 by issuing the TM command on every affected connection.=20
The third party story is even more puzzling as = in order=20 to negotiate any of the nem TM modes the taget will have to ascertain = that all=20 other initiators support it. I fail to understand how would you handle = downgrading the mode for those that don't. And if you don't downgrade = why not=20 state that fast-abort and target scoped queues don't go together and = simplify=20 the mechanics to a multiple issue TM.

Thanks,
Julo =


"Mallikarjun = C."=20 <cb_mallikarjun@yahoo.com>

28/12/06 06:41

To
ips@ietf.org=20
cc
Subject
[Ips] TMF text with=20 updates

=




Attached is the latest text that incorporates David's = proposed=20 enhancement.  Please review and comment.  Note especially = two=20 things: new section 4.1.4 that summarizes generic implementation=20 considerations for both "clarified" and "updated" semantics, the = changed text=20 in 4.1.2 that says "MAY wait for ....target transfer tags.....from = third-party=20 initiators" from the previous blanket=20 MUST.

Mallikarjun



4.1.2 Clarified multi-task = abort=20 semantics
All iSCSI implementations MUST support the protocol = behavior=20 defined in this section as the default behavior.  The execution = of ABORT=20 TASK SET, CLEAR TASK SET, LOGICAL UNIT RESET, TARGET WARM RESET, and = TARGET=20 COLD RESET TMF Requests consists of the following sequence of actions = in the=20 specified order on the specified party.
The initiator iSCSI = layer:
a.=20 MUST continue to respond to each TTT received for the affected tasks. =
b.=20 Should receive any responses that the target may provide for some = tasks among=20 the affected tasks (may process them as usual because they are = guaranteed to=20 have chronologically originated prior to the TMF response).
c. = Should=20 receive the TMF Response concluding all the tasks in the set of = affected=20 tasks.

The target iSCSI layer:
a. MUST wait for currently = valid=20 target transfer tags of the affected tasks from the issuing initiator = to be=20 responded to.  MAY wait for responses on currently valid target = transfer=20 tags of the affected tasks from third-party initiators.
b. MUST = wait=20 (concurrent with the wait in Step.a) for all commands of the affected = tasks to=20 be received based on the CmdSN ordering.   SHOULD NOT wait for = new=20 commands on third-party affected sessions - only the instantiated = tasks have=20 to be considered for the purpose of determining the affected tasks. =  In=20 the case of target-scoped requests (i.e. TARGET WARM RESET and TARGET = COLD=20 RESET), all the commands that are not yet received on the issuing = session in=20 the command stream however can be considered to have been received = with no=20 command waiting period - i.e. the entire CmdSN space up to the CmdSN = of the=20 task management function can be "plugged".
c. MUST propagate the = TMF=20 request to and receive the response from the target SCSI layer.
d. = MUST=20 address the Response Fence flag on the TMF Response on issuing session = as=20 defined in 3.3.2.
e. MUST address the Response Fence flag on the = first=20 post-TMF Response on third-party sessions as defined in 3.3.2. =  If some=20 tasks originate from non-iSCSI I_T_L nexuses then the means by which = the=20 target ensures that all affected tasks have returned their status to = the=20 initiator are defined by the specific non-iSCSI transport=20 protocol(s).
Implementation note: Technically, the TMF servicing is = complete in Step.d.  Data transfers corresponding to terminated = tasks may=20 however still be in progress on third-party iSCSI sessiosn even at the = end of=20 Step.e.  TMF Response MUST NOT be sent by the target iSCSI layer = before=20 the end of Step.d, and MAY be sent at the end of Step.d despite these=20 outstanding Data transfers until after Step.e.

4.1.3 Updated = multi-task=20 abort semantics
Protocol behavior defined in this section MUST be=20 implemented by all iSCSI implementations complying with this document. =  Protocol behavior defined in this section MUST be exhibited by = iSCSI=20 implementations on an iSCSI session when they negotiate the = TaskReporting=20 (section 9.1) key to “FastAbort” on that session. =  The execution of ABORT=20 TASK SET, CLEAR TASK SET, LOGICAL UNIT RESET, TARGET WARM RESET, and = TARGET=20 COLD RESET TMF Requests consists of the following sequence of actions = in the=20 specified order on the specified party.
The initiator iSCSI = layer:
a.=20 MUST NOT send any more Data-Out PDUs for affected tasks on the issuing = connection of the issuing iSCSI session once the TMF is sent to the=20 target.
b. Should receive any responses that the target may provide = for=20 some tasks among the affected tasks (may process them as usual because = they=20 are guaranteed to have chronologically originated prior to the TMF=20 response).
c. MUST respond to Async Message PDU with AsyncEvent=3D5 = as=20 defined in section 8.1.
d. Should receive the TMF Response = concluding all=20 the tasks in the set of affected tasks.

The target iSCSI = layer:
a.=20 MUST wait for all commands of the affected tasks to be received based = on the=20 CmdSN ordering on the issuing session.  SHOULD NOT wait for new = commands=20 on third-party affected sessions - only the instantiated tasks have to = be=20 considered for the purpose of determining the affected tasks.  In = the=20 case of target-scoped requests (i.e. TARGET WARM RESET and TARGET COLD = RESET),=20 all the commands that are not yet received on the issuing session in = the=20 command stream however can be considered to have been received with no = command=20 waiting period - i.e. the entire CmdSN space up to the CmdSN of the = task=20 management function can be "plugged".
b. MUST propagate the TMF = request to=20 and receive the response from the target SCSI layer.
c. MUST leave = all=20 active "affected TTTs" (i.e. active TTTs associated with affected = tasks) valid=20 along with any buffer allocations for the TTTs intact.
d. MUST = generate an=20 Asynchronous Message PDU with AsyncEvent=3D5 (section 8.1) on:
i) = each=20 connection of each third-party session that at least one affected task = is=20 allegiant to, and
ii) each connection except the issuing connection = of the=20 issuing session that has at least one allegiant affected task.
If = there are=20 multiple affected LUs (say due to a target reset), then one Async = Message PDU=20 MUST be sent for each such LU on each connection that has at least one = allegiant affected task.
e. MUST address the Response Fence flag on = the TMF=20 Response on issuing session as defined in 3.3.2.
f. MUST address = the=20 Response Fence flag on the first post-TMF Response on third-party = sessions as=20 defined in 3.3.2. If some tasks originate from non-iSCSI I_T_L nexuses = then=20 the means by which the target ensures that all affected tasks have = returned=20 their status to the initiator are defined by the specific non-iSCSI = transport=20 protocol(s).
g. MUST free up the affected TTTs (and STags, if = applicable)=20 and the corresponding buffers once it receives the associated Nop-Out=20 acknowledgement that the initiator generated in response to the Async = Message.=20  
Implementation note: Technically, the TMF servicing is = complete in=20 Step.e.  Data transfers corresponding to terminated tasks may = however=20 still be in progress even at the end of Step.f.  TMF Response = MUST NOT be=20 sent by the target iSCSI layer before the end of Step.e, and MAY be = sent at=20 the end of Step.e despite these outstanding Data transfers until = Step.g.=20  Step.g specifies an event to free up any such resources that may = have=20 been reserved to support outstanding data transfers.  
4.1.3.1 = Clearing effects update
Appendix F.1 of [RFC3720] specifies the = clearing=20 effects of target and LU resets on “Incomplete TTTs” as = “Y”.  This meant=20 that a target warm reset or a target cold reset or an LU reset would = clear the=20 active TTTs upon completion.  The TaskReporting=3DFastAbort = (section 9.1)=20 semantics defined by this section however do not guarantee that the = active=20 TTTs are cleared by the end of the reset operations.  In fact, = the new=20 semantics are designed to allow clearing the TTTs in a = “lazy” fashion after=20 the TMF Response is delivered.  Thus, when = TaskReporting=3DFastAbort is=20 operational on a session, the clearing effects of reset operations on=20 “Incomplete TTTs” is “N”.  
4.1.4 = Implementation=20 considerations
Both in clarified semantics (section 4.1.2) and = updated=20 semantics (section 4.1.3), there may be outstanding data transfers = even after=20 the TMF completion is reported on the issuing session.  In the = case of=20 iSCSI/iSER [iSER], these would be tagged data transfers for STags not = owned by=20 any active tasks.  Whether or not real buffers support these data = transfers is implementation-dependent.  However, the data = transfers=20 logically MUST be silently discarded by the target iSCSI layer in all = cases.=20  A target MAY, on an implementation-defined internal timeout, = also choose=20 to drop the connections on which it did not receive the expected = Data-out=20 sequences (section 4.1.2) or Nop-Out acknowledgements (section 4.1.3) = so as to=20 reclaim the associated buffer, STag and TTT resources as=20 appropriate.


----- Original Message ----
From:=20 "Black_David@emc.com" <Black_David@emc.com>
To: = Black_David@emc.com;=20 cb_mallikarjun@yahoo.com; ips@ietf.org
Sent: Wednesday, December = 20, 2006=20 2:33:43 PM
Subject: RE: [Ips] Implementer's Guide - Task Management = Issue


> Let's try this line of reasoning - the target = issues the=20 Nop-Out, now
when
> can it free the resources? =  Answer:
>=20     - The Nop-In response comes back, OR
>   =   - The=20 connection times out and is torn down.
> Now, what if the = Nop-Out is not=20 issued - what does the target wait for
to
> free the = resources?=20  Answer:
>     - The transfers complete, = OR
>=20     - The connection times out and is torn down.
> = Those look=20 similar enough at the target (the worst case is the same = -
the
>=20 resources are tied up until an uncooperative initiator times out) = that
>=20 I don't see the harm in allowing the early TMF return without the = new
>=20 key.  The clear distinction is that the first two bullets=20 are
different;
> if the new key is not negotiated, the target = has to=20 wait for the
transfers
> to complete; the new key and the = Nop-Out are=20 necessary to walk away
earlier
> when the initiator involved = is able=20 to continue the transfers.

That got slightly twisted - what it = should=20 have talked about was the
target
issuing the new Async Message = and the=20 Nop-Out response coming=20 = back.

Thanks,
--David
--------------------------------------= --------------
David=20 L. Black, Senior Technologist
EMC Corporation, 176 South St., = Hopkinton, MA=20  01748
+1 (508) 293-7953           =  =20 FAX: +1 (508) 293-7786
black_david@emc.com      =20  Mobile: +1 (978)=20 = 394-7754
----------------------------------------------------

_= _________________________________________________
Do=20 You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam = protection=20 around
http://mail.yahoo.com=20

_______________________________________________
Ips mailing = = list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips

------_=_NextPart_001_01C72AB9.FB0FA731-- --===============0419763752== 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 --===============0419763752==-- From ips-bounces@ietf.org Thu Dec 28 15:08:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H01Yb-0003TP-U4; Thu, 28 Dec 2006 15:08:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H01Ya-0003R1-6d for ips@ietf.org; Thu, 28 Dec 2006 15:08:52 -0500 Received: from mexforward.lss.emc.com ([128.222.32.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H01YZ-0004Mx-Gk for ips@ietf.org; Thu, 28 Dec 2006 15:08:52 -0500 Received: from mailhub.lss.emc.com (sesha.lss.emc.com [10.254.144.12]) by mexforward.lss.emc.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id kBSK8fsw001556; Thu, 28 Dec 2006 15:08:51 -0500 (EST) Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id kBSK8UU5014411; Thu, 28 Dec 2006 15:08:37 -0500 (EST) From: Black_David@emc.com Received: from CORPUSMX20A.corp.emc.com ([128.221.62.13]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Dec 2006 15:08:20 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ips] Re: iSCSI "compliance" text Date: Thu, 28 Dec 2006 15:08:18 -0500 Message-ID: In-Reply-To: <20061228050253.65618.qmail@web51908.mail.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ips] Re: iSCSI "compliance" text Thread-Index: AccqPajh4xSITVZrSsa/iFyBAWcd9gAfIzgQ To: , X-OriginalArrivalTime: 28 Dec 2006 20:08:20.0728 (UTC) FILETIME=[EBD62780:01C72ABB] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2006.12.28.114433 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -2, NO_REAL_NAME 0, __C230066_P5 0, __CP_NOT_1 0, __CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CTYPE_CHARSET_QUOTED 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.2 (/) X-Scan-Signature: 680445c3afe8c9e96925f2dfef141924 Cc: X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org Eddy, I think I agree with Mallikarjun on this. If there is specific text in RFC 3720 that says the recipient "MUST" check thus-and-such, we could look at whether that check is really needed, and weaken the text if it is not. There's certainly nothing wrong with making the checks - if the initiator "MUST" do , then the target is entitled to rely on and complain if it isn't being done. I hesitate to discourage targets from making checks. The two examples you cite: - Initiator uses wrong ITT value on data - Initiator sends immediate data when negotiation forbids it are things that I think I'd prefer to have blow up in the initiator's face sooner rather than later, as they could result in bad/wrong data being stored if the target guesses wrong about how to compensate for that initiator mistake. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- > -----Original Message----- > From: Mallikarjun C. [mailto:cb_mallikarjun@yahoo.com]=20 > Sent: Thursday, December 28, 2006 12:03 AM > To: ips@ietf.org > Subject: [Ips] Re: iSCSI "compliance" text >=20 > Eddy, >=20 > Even if we say it in the draft, it would be pretty generic=20 > and will have no mandatory force. So I do not see a lot of=20 > value in attempting to state it in the draft. Unless I get=20 > other inputs and/or advise from David and Lars, I prefer not=20 > to attempt to craft such a text. I also suspect this is not=20 > a case peculiar to iSCSI protocol, so I would welcome inputs=20 > from other WG members. >=20 > Mallikarjun >=20 >=20 > ----- Original Message ---- > From: Eddy Quicksall > To: ips@ietf.org > Sent: Thursday, December 21, 2006 9:20:14 AM > Subject: Fw: [Ips] ips WG Last Call: iSCSI Implementer's Guide >=20 >=20 > Sorry, I forgot to send this original request to the list. >=20 > What I'm thinking is to say this in the iSCSI Implementer's=20 > Guide, if it is=20 > not too late. >=20 > One of the problems I'm faced with is that our customers will=20 > run 3rd party > tests on a final product. If 3rd party test says "failed"=20 > then the customer > takes that to its word. I have found that many people think=20 > that if the RFC > says the initiator MUST then they think that means the target=20 > MUST check to > see that the initiator obeyed the rule (and visa versa) ...=20 > some of the 3rd > party tests are in that category. >=20 > Eddy >=20 > ----- Original Message -----=20 > From: "Mallikarjun C." > To: "Eddy Quicksall" > Cc: ; "Julian Satran" > Sent: Thursday, December 14, 2006 6:55 PM > Subject: Re: [Ips] ips WG Last Call: iSCSI Implementer's Guide >=20 >=20 > I think I understand your question. Generally, the IETF=20 > philosophy is to=20 > "be liberal in what you accept, be conservative in what you send" (my=20 > paraphrasing of it, anyway) - so if your target wants to be=20 > more forgiving,=20 > I think that should be alright. >=20 > The UNH tests may be testing all MUST requirements - so in=20 > your immediate=20 > data example, the initiator must be held to this rule since=20 > it initiates the=20 > immediate data send. On the target side, I see no harm in=20 > turning off those=20 > checks in your production code when you think you can=20 > gracefully deal even=20 > with a badly-behaving initiator. On such occasions though,=20 > you should be=20 > sure to not flag SCSI protocol errors for those same iSCSI=20 > protocol errors=20 > that you had earlier forgiven. >=20 > Hope that helps. >=20 > Mallikarjun >=20 >=20 > ----- Original Message ---- > From: Eddy Quicksall > To: Mallikarjun C. > Sent: Wednesday, December 13, 2006 4:17:37 AM > Subject: Re: [Ips] ips WG Last Call: iSCSI Implementer's Guide >=20 >=20 > I know it is really late to ask this but I was wondering if=20 > something could > be done to relax some of the requirements for the target or=20 > initiator to > check for correctness of the protocol? For example, it could=20 > be said that if > the protocol error will not affect the operation of the=20 > device then it is > not necessary to check for the error. >=20 > I ask this because all of these checks during Full Feature=20 > Phase can cause > unnecessary performance degradation due to a check on every=20 > command PDU even > when the initiator or target have been previously qualified.=20 > This is off the > top of my head but one such check that comes to mind is the=20 > check to be sure > the ITT of data matches the ITT of the original command... we=20 > have hardware > acceleration and different types of memory with different=20 > speeds. To cross > check against the command requires saving additional information and > accessing the slow memory (the fast memory is at a premium=20 > and can't store > enough information). Another is the requirement for the=20 > target to check for > immediate data received when immediate data was negotiated to=20 > no (if the > target can deal with it and the initiator can't but the=20 > initiator negotiated > it to no then the initiator should not send it anyway and=20 > there should be no > need to make the checks on every command). >=20 > Maybe some of these that I call "required checks" are=20 > actually the result of > a test program (such as the UNH test program) putting on the=20 > "requirement". > If so then a note in the guide may help to clear up that it=20 > is not an error > for the initiator or target to double check the peer. >=20 > I typed this kind of fast and I'm not a good linguist so if you don't > understand then please let me know. >=20 > Eddy >=20 > ----- Original Message -----=20 > From: "Mallikarjun C." > To: > Sent: Monday, December 11, 2006 12:34 PM > Subject: Re: [Ips] ips WG Last Call: iSCSI Implementer's Guide >=20 >=20 > Lars, >=20 > Thanks for the comments and sorry for the delay in getting back. >=20 > As far as volunteers for reviewing, we could request the=20 > contributors at the > end of the document to review. David may have already=20 > reviewed, based on > his comments. Julian Satran had some offline feedback for me=20 > on TMF topics. > As the editor of the document, I was sure that each of the topics were > discussed in detail (or at least clearly noted) on the list before I > included them in the doc. Hope that gives you some reassurance. >=20 > >whether it is merely the original text that can be > >misunderstood or if there is a technical error in the original text. > > (It already does in some cases.) >=20 > Yes, I'd appreciate if you could point out where you think additional > clarifications could help. >=20 > > OK, so this document not only updates 3720, but also 3721, 3722 and > > 3723? That needs to be stated in the document header and abstract. > > (Also, 3721 needs to be normatively cited in this case.) >=20 > We could. My intent was to make it clear that this document prevails > whenever a subtle interpretation in future of one of these=20 > RFCs differs from > what's in this document. Now that we are nearing the end of=20 > the work on > this document, we could delete some although I personally am=20 > tempted to > leave it this way....from what I can think of today though,=20 > this doc updates > 3720 and 3721, but does not update 3722 and 3723. >=20 > 3721 is not a standards-track RFC and I wasn't sure if it needs to be > normatively cited as such. But I could if that's the right=20 > thing to do. >=20 > >Suggest to find a better title, because implementer's guides don't > >typically update the base specification in a normative way. (Maybe > > "iSCSI Corrections and Implementer's Guide" or something like that?) >=20 > FIne by me. How about "iSCSI Corrections, Clarifications,=20 > Additions and > Implementation Guidance", or is it too long? If it is, we=20 > could try "iSCSI > Changes Based on Implementers' Experience" or something like it. >=20 > > The specification of the fence mechanisms should use RFC2119 terms, > > especially in Section 3.3.2. >=20 > It actually does, with a MUST preceding the bulleted list....=20 > As far as > 3.3.1, I intentionally left the model description very=20 > generic with the hope > that it can be incorporated into a future T10 spec verbatim. >=20 > > Nit: s/mult/multi-/ >=20 > Done. >=20 > > I'm not sure if "should receive" describes something that should be > > started in RFC2119 language or not. If that is the intent, a better > > phrasing should be found. (Also elsewhere in this document where the > > same phrasing is used.) >=20 > I left the "should"s intentionally in, because they really are the > prerogatives of the initiator's run-time behavior, i.e.=20 > initiator may at his > discretion choose to discard a message for some other reason (e.g. bad > digest) beyond the 2119 protocol requirements. >=20 > >Should the sentence starting with "SHOULD NOT" start a new item in > > this list? >=20 > No, I don't think so. This bullet is all about waiting for=20 > missing CmdSN's. > It happens to have a different prescription for third-party affected > sessions. >=20 > >Remove text after "considerations" to not confuse IANA. May want > > to add a note to the RFC Editor to remove this section upon > >publication. >=20 > Done. >=20 > > Nit: Cited also as [RFC 3720], which confuses idnits. Remove the > space > > in the other citations. >=20 > Done. >=20 > >iSER Not cited. >=20 > It does now. >=20 > > ID does not include the required 2119 boilerplate. Also, 2119 should > > be cited normatively. >=20 > Fixed now. >=20 >=20 > Mallikarjun >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > ----- Original Message ---- > From: Lars Eggert > To: ips@ietf.org > Sent: Friday, December 1, 2006 4:57:59 PM > Subject: Re: [Ips] ips WG Last Call: iSCSI Implementer's Guide >=20 >=20 > Summary: Minor revision needed to address editorial issues. Note: I'm > no iSCSI expert, so I cannot fully review the technical > recommendations made in this document. I'd like to see at least one > other review from someone who has the necessary background before > this > document moves forward - volunteers? >=20 > Contains non-ASCII characters, boilerplate issues and other idnits. > Please fix. Header should indicate that this document updates 3720 > and potentially other IDs (abstract already partially does - good!) >=20 > It would be good if this document would state for each item it > discusses, whether this is a clarification to the original=20 > RFCs or a > correction, i.e., whether it is merely the original text=20 > that can be > misunderstood or if there is a technical error in the=20 > original text. > (It already does in some cases.) >=20 >=20 > INTRODUCTION, paragraph 1: > > iSCSI Implementer's Guide >=20 > Suggest to find a better title, because implementer's guides don't > typically update the base specification in a normative way. (Maybe > "iSCSI Corrections and Implementer's Guide" or something=20 > like that?) >=20 >=20 > Section 2, paragraph 2: > > iSCSI implementers are required to reference [RFC3722] and > > [RFC3723] in addition to [RFC3720] for mandatory requirements. > > In addition, [RFC3721] also contains useful information for > > iSCSI implementers. The text in this document, however, updates > > and supersedes the text in all the noted RFCs whenever there is > > such a question. >=20 > OK, so this document not only updates 3720, but also 3721, 3722 and > 3723? That needs to be stated in the document header and abstract. > (Also, 3721 needs to be normatively cited in this case.) >=20 >=20 > Section 3.3, paragraph 0: > > 3.3 SCSI Protocol Interface Model for Response Ordering >=20 > The specification of the fence mechanisms should use RFC2119 terms, > especially in Section 3.3.2. >=20 >=20 > Section 3.3.3, paragraph 4: > > 2. The TMF Response carrying the mult-task TMF Response on the > > issuing session. >=20 > Nit: s/mult/multi-/ >=20 >=20 > Section 4.1.2, paragraph 4: > > b. Should receive any responses that the target may provide > > for some tasks among the affected tasks (may process them > > as usual because they are guaranteed to have > > chronologically originated prior to the TMF response). >=20 > I'm not sure if "should receive" describes something that should be > started in RFC2119 language or not. If that is the intent, a better > phrasing should be found. (Also elsewhere in this document=20 > where the > same phrasing is used.) >=20 >=20 > Section 4.1.2, paragraph 8: > > b. MUST wait (concurrent with the wait in Step.a) for all > > commands of the affected tasks to be received=20 > based on the > > CmdSN ordering. SHOULD NOT wait for new commands on > > third-party affected sessions - only the instantiated > tasks > > have to be considered for the purpose of determining the > > affected tasks. In the case of target-scoped requests > > (i.e. TARGET WARM RESET and TARGET COLD RESET), all the > > commands that are not yet received on the issuing session > > in the command stream however can be considered to have > > been received with no command waiting period - i.e. the > > entire CmdSN space up to the CmdSN of the task management > > function can be "plugged". >=20 > Should the sentence starting with "SHOULD NOT" start a new item in > this list? >=20 >=20 > Section 4.1.3, paragraph 8: > > a. MUST wait for all commands of the affected tasks to be > > received based on the CmdSN ordering on the issuing > > session. SHOULD NOT wait for new commands on third-party > > affected sessions - only the instantiated tasks have to be > > considered for the purpose of determining the affected > > tasks. In the case of target-scoped requests (i.e. TARGET > > WARM RESET and TARGET COLD RESET), all the commands that > > are not yet received on the issuing session in the command > > stream however can be considered to have been=20 > received with > > no command waiting period - i.e. the entire CmdSN space up > > to the CmdSN of the task management function can be > > "plugged". >=20 > Should the sentence starting with "SHOULD NOT" start a new item in > this list? >=20 >=20 > Section 11, paragraph 1: > > This draft does not have any specific IANA considerations other > than > > those already noted in [RFC3720]. >=20 > Remove text after "considerations" to not confuse IANA. May want > to add a note to the RFC Editor to remove this section upon > publication. >=20 >=20 > Section 12.1, paragraph 1: > > [RFC3720] Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka, > > M., and E. Zeidner, "Internet Small Computer Systems > > Interface (iSCSI)", RFC 3720, April 2004. >=20 > Nit: Cited also as [RFC 3720], which confuses idnits. Remove the > space > in the other citations. >=20 >=20 > Section 12.2, paragraph 1: > > [RFC3721] Bakke, M., Hafner, J., Hufferd, J., Voruganti, K., > > and M. Krueger, "Internet Small Computer Systems Interface > > (iSCSI) Naming and Discovery", RFC 3721, April 2004. >=20 > See above, if this ID updates 3721, it needs to=20 > normatively cite it. >=20 >=20 > Section 12.2, paragraph 2: > > [iSER] Ko, M., Chadalapaka, M., Elzur, U., Shah, H., Thaler, > > P., J. Hufferd, "iSCSI Extensions for RDMA", IETF > > Internet Draft draft-ietf-ips-iser-04.txt (work in > > progress), June 2005. >=20 > Not cited. >=20 >=20 > Section 12.2, paragraph 3: > > [RFC2119] Bradner, S. "Key Words for use in RFCs to Indicate > > Requirement Levels", BCP 14, RFC 2119, March 1997. >=20 > ID does not include the required 2119 boilerplate. Also,=20 > 2119 should > be cited normatively. > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips >=20 >=20 >=20 > ______________________________________________________________ > ______________________ > Do you Yahoo!? > Everyone is raving about the all-new Yahoo! Mail beta. > http://new.mail.yahoo.com >=20 > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips >=20 >=20 >=20 > ______________________________________________________________ > ______________________ > Want to start your own business? > Learn how on Yahoo! Small Business. > http://smallbusiness.yahoo.com/r-index >=20 >=20 > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips >=20 > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around=20 > http://mail.yahoo.com=20 >=20 > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips >=20 >=20 _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Thu Dec 28 15:18:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H01hX-0005U3-QY; Thu, 28 Dec 2006 15:18:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H01hW-0005Ta-6h for ips@ietf.org; Thu, 28 Dec 2006 15:18:06 -0500 Received: from mexforward.lss.emc.com ([128.222.32.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H01hU-0005k7-Pt for ips@ietf.org; Thu, 28 Dec 2006 15:18:06 -0500 Received: from mailhub.lss.emc.com (nagas.lss.emc.com [10.254.144.11]) by mexforward.lss.emc.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id kBSKI4rn021639; Thu, 28 Dec 2006 15:18:04 -0500 (EST) Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id kBSKHQBr017403; Thu, 28 Dec 2006 15:18:01 -0500 (EST) From: Black_David@emc.com Received: from CORPUSMX20A.corp.emc.com ([128.221.62.13]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Dec 2006 15:15:59 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ips] TMF text with updates Date: Thu, 28 Dec 2006 15:15:58 -0500 Message-ID: In-Reply-To: <20061228044139.24595.qmail@web51912.mail.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ips] TMF text with updates Thread-Index: AccqOpz3zPzy04q5RDWPy9cViQ9DbQAgj1aA To: , X-OriginalArrivalTime: 28 Dec 2006 20:15:59.0216 (UTC) FILETIME=[FD1DDF00:01C72ABC] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2006.12.28.114433 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -2, NO_REAL_NAME 0, __C230066_P5 0, __CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CTYPE_CHARSET_QUOTED 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.2 (/) X-Scan-Signature: 72dbfff5c6b8ad2b1b727c13be042129 Cc: X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org This looks ok for a revised draft - I'll take a detailed look at all the text in the next version of the draft. Please try to remove uses of the word "buffer" where a more general discussion of "resources" is appropriate. Thanks, --David=20 > -----Original Message----- > From: Mallikarjun C. [mailto:cb_mallikarjun@yahoo.com]=20 > Sent: Wednesday, December 27, 2006 11:42 PM > To: ips@ietf.org > Subject: [Ips] TMF text with updates >=20 > Attached is the latest text that incorporates David's=20 > proposed enhancement. Please review and comment. Note=20 > especially two things: new section 4.1.4 that summarizes=20 > generic implementation considerations for both "clarified"=20 > and "updated" semantics, the changed text in 4.1.2 that says=20 > "MAY wait for ....target transfer tags.....from third-party=20 > initiators" from the previous blanket MUST. >=20 > Mallikarjun >=20 >=20 >=20 > 4.1.2 Clarified multi-task abort semantics > All iSCSI implementations MUST support the protocol behavior=20 > defined in this section as the default behavior. The=20 > execution of ABORT TASK SET, CLEAR TASK SET, LOGICAL UNIT=20 > RESET, TARGET WARM RESET, and TARGET COLD RESET TMF Requests=20 > consists of the following sequence of actions in the=20 > specified order on the specified party.=20 > The initiator iSCSI layer: > a. MUST continue to respond to each TTT received for the=20 > affected tasks.=20 > b. Should receive any responses that the target may provide=20 > for some tasks among the affected tasks (may process them as=20 > usual because they are guaranteed to have chronologically=20 > originated prior to the TMF response).=20 > c. Should receive the TMF Response concluding all the tasks=20 > in the set of affected tasks.=20 >=20 > The target iSCSI layer: > a. MUST wait for currently valid target transfer tags of the=20 > affected tasks from the issuing initiator to be responded to.=20 > MAY wait for responses on currently valid target transfer=20 > tags of the affected tasks from third-party initiators. > b. MUST wait (concurrent with the wait in Step.a) for all=20 > commands of the affected tasks to be received based on the=20 > CmdSN ordering. SHOULD NOT wait for new commands on=20 > third-party affected sessions - only the instantiated tasks=20 > have to be considered for the purpose of determining the=20 > affected tasks. In the case of target-scoped requests (i.e.=20 > TARGET WARM RESET and TARGET COLD RESET), all the commands=20 > that are not yet received on the issuing session in the=20 > command stream however can be considered to have been=20 > received with no command waiting period - i.e. the entire=20 > CmdSN space up to the CmdSN of the task management function=20 > can be "plugged". > c. MUST propagate the TMF request to and receive the response=20 > from the target SCSI layer.=20 > d. MUST address the Response Fence flag on the TMF Response=20 > on issuing session as defined in 3.3.2. > e. MUST address the Response Fence flag on the first post-TMF=20 > Response on third-party sessions as defined in 3.3.2. If=20 > some tasks originate from non-iSCSI I_T_L nexuses then the=20 > means by which the target ensures that all affected tasks=20 > have returned their status to the initiator are defined by=20 > the specific non-iSCSI transport protocol(s). > Implementation note: Technically, the TMF servicing is=20 > complete in Step.d. Data transfers corresponding to=20 > terminated tasks may however still be in progress on=20 > third-party iSCSI sessiosn even at the end of Step.e. TMF=20 > Response MUST NOT be sent by the target iSCSI layer before=20 > the end of Step.d, and MAY be sent at the end of Step.d=20 > despite these outstanding Data transfers until after Step.e. > =20 > 4.1.3 Updated multi-task abort semantics > Protocol behavior defined in this section MUST be implemented=20 > by all iSCSI implementations complying with this document. =20 > Protocol behavior defined in this section MUST be exhibited=20 > by iSCSI implementations on an iSCSI session when they=20 > negotiate the TaskReporting (section 9.1) key to "FastAbort"=20 > on that session. The execution of ABORT TASK SET, CLEAR TASK=20 > SET, LOGICAL UNIT RESET, TARGET WARM RESET, and TARGET COLD=20 > RESET TMF Requests consists of the following sequence of=20 > actions in the specified order on the specified party.=20 > The initiator iSCSI layer: > a. MUST NOT send any more Data-Out PDUs for affected tasks on=20 > the issuing connection of the issuing iSCSI session once the=20 > TMF is sent to the target. > b. Should receive any responses that the target may provide=20 > for some tasks among the affected tasks (may process them as=20 > usual because they are guaranteed to have chronologically=20 > originated prior to the TMF response). > c. MUST respond to Async Message PDU with AsyncEvent=3D5 as=20 > defined in section 8.1. > d. Should receive the TMF Response concluding all the tasks=20 > in the set of affected tasks. >=20 > The target iSCSI layer: > a. MUST wait for all commands of the affected tasks to be=20 > received based on the CmdSN ordering on the issuing session. =20 > SHOULD NOT wait for new commands on third-party affected=20 > sessions - only the instantiated tasks have to be considered=20 > for the purpose of determining the affected tasks. In the=20 > case of target-scoped requests (i.e. TARGET WARM RESET and=20 > TARGET COLD RESET), all the commands that are not yet=20 > received on the issuing session in the command stream however=20 > can be considered to have been received with no command=20 > waiting period - i.e. the entire CmdSN space up to the CmdSN=20 > of the task management function can be "plugged". > b. MUST propagate the TMF request to and receive the response=20 > from the target SCSI layer.=20 > c. MUST leave all active "affected TTTs" (i.e. active TTTs=20 > associated with affected tasks) valid along with any buffer=20 > allocations for the TTTs intact. > d. MUST generate an Asynchronous Message PDU with=20 > AsyncEvent=3D5 (section 8.1) on: > i) each connection of each third-party session that at least=20 > one affected task is allegiant to, and > ii) each connection except the issuing connection of the=20 > issuing session that has at least one allegiant affected task. > If there are multiple affected LUs (say due to a target=20 > reset), then one Async Message PDU MUST be sent for each such=20 > LU on each connection that has at least one allegiant affected task. > e. MUST address the Response Fence flag on the TMF Response=20 > on issuing session as defined in 3.3.2. > f. MUST address the Response Fence flag on the first post-TMF=20 > Response on third-party sessions as defined in 3.3.2. If some=20 > tasks originate from non-iSCSI I_T_L nexuses then the means=20 > by which the target ensures that all affected tasks have=20 > returned their status to the initiator are defined by the=20 > specific non-iSCSI transport protocol(s). > g. MUST free up the affected TTTs (and STags, if applicable)=20 > and the corresponding buffers once it receives the associated=20 > Nop-Out acknowledgement that the initiator generated in=20 > response to the Async Message. =20 > Implementation note: Technically, the TMF servicing is=20 > complete in Step.e. Data transfers corresponding to=20 > terminated tasks may however still be in progress even at the=20 > end of Step.f. TMF Response MUST NOT be sent by the target=20 > iSCSI layer before the end of Step.e, and MAY be sent at the=20 > end of Step.e despite these outstanding Data transfers until=20 > Step.g. Step.g specifies an event to free up any such=20 > resources that may have been reserved to support outstanding=20 > data transfers. =20 > 4.1.3.1 Clearing effects update > Appendix F.1 of [RFC3720] specifies the clearing effects of=20 > target and LU resets on "Incomplete TTTs" as "Y". This meant=20 > that a target warm reset or a target cold reset or an LU=20 > reset would clear the active TTTs upon completion. The=20 > TaskReporting=3DFastAbort (section 9.1) semantics defined by=20 > this section however do not guarantee that the active TTTs=20 > are cleared by the end of the reset operations. In fact, the=20 > new semantics are designed to allow clearing the TTTs in a=20 > "lazy" fashion after the TMF Response is delivered. Thus,=20 > when TaskReporting=3DFastAbort is operational on a session, the=20 > clearing effects of reset operations on "Incomplete TTTs" is "N". =20 > 4.1.4 Implementation considerations > Both in clarified semantics (section 4.1.2) and updated=20 > semantics (section 4.1.3), there may be outstanding data=20 > transfers even after the TMF completion is reported on the=20 > issuing session. In the case of iSCSI/iSER [iSER], these=20 > would be tagged data transfers for STags not owned by any=20 > active tasks. Whether or not real buffers support these data=20 > transfers is implementation-dependent. However, the data=20 > transfers logically MUST be silently discarded by the target=20 > iSCSI layer in all cases. A target MAY, on an=20 > implementation-defined internal timeout, also choose to drop=20 > the connections on which it did not receive the expected=20 > Data-out sequences (section 4.1.2) or Nop-Out=20 > acknowledgements (section 4.1.3) so as to reclaim the=20 > associated buffer, STag and TTT resources as appropriate. >=20 >=20 > ----- Original Message ---- > From: "Black_David@emc.com" > To: Black_David@emc.com; cb_mallikarjun@yahoo.com; ips@ietf.org > Sent: Wednesday, December 20, 2006 2:33:43 PM > Subject: RE: [Ips] Implementer's Guide - Task Management Issue >=20 >=20 > > Let's try this line of reasoning - the target issues the=20 > Nop-Out, now > when > > can it free the resources? Answer: > > - The Nop-In response comes back, OR > > - The connection times out and is torn down. > > Now, what if the Nop-Out is not issued - what does the=20 > target wait for > to > > free the resources? Answer: > > - The transfers complete, OR > > - The connection times out and is torn down.=20 > > Those look similar enough at the target (the worst case is=20 > the same - > the > > resources are tied up until an uncooperative initiator=20 > times out) that > > I don't see the harm in allowing the early TMF return=20 > without the new > > key. The clear distinction is that the first two bullets are > different; > > if the new key is not negotiated, the target has to wait for the > transfers > > to complete; the new key and the Nop-Out are necessary to walk away > earlier > > when the initiator involved is able to continue the transfers. >=20 > That got slightly twisted - what it should have talked about was the > target > issuing the new Async Message and the Nop-Out response coming back. >=20 > 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 > ---------------------------------------------------- >=20 > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around=20 > http://mail.yahoo.com=20 >=20 > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips >=20 >=20 _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Thu Dec 28 15:21:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H01l1-0007YA-Lh; Thu, 28 Dec 2006 15:21:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H01l0-0007Y4-Tb for ips@ietf.org; Thu, 28 Dec 2006 15:21:42 -0500 Received: from mexforward.lss.emc.com ([128.222.32.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H01kz-0006CZ-IB for ips@ietf.org; Thu, 28 Dec 2006 15:21:42 -0500 Received: from mailhub.lss.emc.com (nirah.lss.emc.com [10.254.144.13]) by mexforward.lss.emc.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id kBSKLfpo024016; Thu, 28 Dec 2006 15:21:41 -0500 (EST) Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id kBSKL9ro028090; Thu, 28 Dec 2006 15:21:39 -0500 (EST) From: Black_David@emc.com Received: from CORPUSMX20A.corp.emc.com ([128.221.62.13]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Dec 2006 15:21:38 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ips] Single 3-valued key for task reporting Date: Thu, 28 Dec 2006 15:21:37 -0500 Message-ID: In-Reply-To: <20061228043254.21351.qmail@web51912.mail.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ips] Single 3-valued key for task reporting Thread-Index: AccqOgCX5S20e4h7RRCbAsxHRMCDMgAg3MEA To: , X-OriginalArrivalTime: 28 Dec 2006 20:21:38.0280 (UTC) FILETIME=[C736EE80:01C72ABD] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2006.12.28.114433 X-PerlMx-Spam: Gauge=, SPAM=2%, Reason='EMC_FROM_0+ -2, NO_REAL_NAME 0, __CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CTYPE_CHARSET_QUOTED 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.2 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Cc: X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org Something to think about on this one. Following on Julian's concern about the complexity of fast task abort, one possibility would be to say, that *if* this key is implemented: - support for ResponseFence is mandatory - support for FastTaskAbort is optional I think the current IG text makes fast task abort support mandatory. Comments? Thanks, --David > -----Original Message----- > From: Mallikarjun C. [mailto:cb_mallikarjun@yahoo.com]=20 > Sent: Wednesday, December 27, 2006 11:33 PM > To: IPS > Subject: [Ips] Single 3-valued key for task reporting >=20 > Per the email conversation at the bottom of this email, I=20 > propose the following text for a new 3-valued key=20 > "TaskReporting" that replaces the FastMultiTaskAbort key. =20 > Comments are welcome. >=20 > 9.1 TaskReporting > Use: LO > Senders: Initiator and Target > Scope: SW > Irrelevant when: SessionType=3DDiscovery > TaskReporting=3D > Default is Legacy. > Result function is AND. > This key is used to negotiate the task completion reporting=20 > semantics from the SCSI target. Following table describes=20 > the semantics an iSCSI target MUST support for respective=20 > negotiated key values. The Legacy value MUST be offered as=20 > an option by negotiation originator. > +--------------+------------------------------------------+ > | Name | Description | > +--------------+------------------------------------------+ > | Legacy | RFC 3720-compliant semantics. Response | > | | fencing is not guaranteed and fast | > | | completion of multi-task aborting is not | > | | supported | > +--------------+------------------------------------------+ > | ResponseFence| Response Fence (section 3.3.1) semantics | > | | MUST be supported in reporting task | > | | completions | > +--------------+------------------------------------------+ > | FastAbort | Updated fast multi-task abort semantics |=20 > | | defined in section 4.1.3 MUST be | > | | supported. Support for Response Fence is| > | | implied - i.e. section 3.3.1 semantics | > | | MUST be supported as well | > +--------------+------------------------------------------+ > When TaskReporting is not negotiated to FastAbort, The=20 > default behavior is to use the [RFC3720] TMF semantics as=20 > clarified in section 4.1.2.=20 >=20 >=20 >=20 >=20 > ----- Original Message ---- > From: "Black_David@emc.com" > To: cb_mallikarjun@yahoo.com; ips@ietf.org > Sent: Monday, December 11, 2006 10:56:02 AM > Subject: RE: [Ips] Implementer's Guide - Task Management Issue >=20 >=20 > Mallikarjun, >=20 > ...... > > The other thing that came to my mind after reading your note=20 > > is that we don't currently have a generic key to capture the=20 > > Response Fence behavior - although response fencing underlies=20 > > both the fast multi-task abort as well as addressing ACA race=20 > > conditions (and perhaps others down the road. e.g. around=20 > > persistent reservations). So, today, the Note at the end of=20 > > section 3.3.3 advises that implementations may check the=20 > > FastMultiTaskAbort key to verify if safe behavior for MCS ACA=20 > > is supported, although ACA has really nothing to do with=20 > > multi-task aborting. I am wondering if we should create a=20 > > new key (say ResponseFence), so the semantics would become: > > =20 > =20 > > ResponseFence "Yes" fencing done by target =20 > > "No" legacy, no fencing=20 > > (so "clarified" TMF semantics are not possible either) > > =20 > > With ResponseFence=3D "Yes" > > FastMultiTaskAbort =20 > > "Yes" fast abort & fencing =20 > > "No" traditional wait on=20 > > outstanding TTTs (fencing on ACA is still possible) > >=20 > > With ResponseFence=3D "No" > > FastMultiTaskAbort =20 > > "Yes" Illegal, Response Fence must be "Yes" > > "No" No fencing, must wait on=20 > > outstanding TTTs > > =20 > >=20 > > The downside of this scheme is that it may be going in the=20 > > opposite direction than you wanted (introduces a second key=20 > > that 3720-compliant implementations don't know about). We=20 > > could alternatively simply mandate the behavior equivalent to=20 > > ResponseFence =3D "Yes" always and avoid the second key, but=20 > > doing so could make the current 3720-compliant=20 > > implementations technically non-iSCSI-compliant. > >=20 > > Comments? >=20 > Given the inter-dependence of ResponseFence and FastMultiTaskAbort, > a single 3-valued key is probably simpler than two boolean keys. > I think having an explicit means of determining whether ACA behaves > correctly on an multi-connection-session is worth adding. >=20 > Thanks, > --David=20 >=20 > > Mallikarjun >=20 > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around=20 > http://mail.yahoo.com=20 >=20 > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips >=20 >=20 _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Thu Dec 28 15:25:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H01os-0000LI-Fu; Thu, 28 Dec 2006 15:25:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H01oq-0000LD-Qo for ips@ietf.org; Thu, 28 Dec 2006 15:25:40 -0500 Received: from web51903.mail.yahoo.com ([206.190.48.66]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H01op-00077r-RV for ips@ietf.org; Thu, 28 Dec 2006 15:25:40 -0500 Received: (qmail 92731 invoked by uid 60001); 28 Dec 2006 20:25:39 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type; b=K6gWPQ9qcvGwaLJidTzydxL+x+CcOv3ZfA42oIZj1Nt9xXlHD/vd4XRpVDB8pC3c1A0d48Y8zMAR6d3td8iH8EV8Nb8UymQkK5JyN2m5gQrXMX4MdKDhHscR2XGAQd97nvL8rc+skFsXleJYkNHpxbS0qlyXyPci3eFBISTP4sM= ; Message-ID: <20061228202539.92729.qmail@web51903.mail.yahoo.com> Received: from [216.93.234.151] by web51903.mail.yahoo.com via HTTP; Thu, 28 Dec 2006 12:25:39 PST Date: Thu, 28 Dec 2006 12:25:39 -0800 (PST) From: "Mallikarjun C." Subject: Fw: [Ips] TMF text with updates To: IPS MIME-Version: 1.0 X-Spam-Score: 0.7 (/) X-Scan-Signature: cd3d702b63698072ba67a75ce9e0fc9e 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="===============1673648903==" Errors-To: ips-bounces@ietf.org --===============1673648903== Content-Type: multipart/alternative; boundary="0-160516847-1167337539=:91933" --0-160516847-1167337539=:91933 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Forgot to copy to the list.=0A=0A=0A----- Forwarded Message ----=0AFrom: Ma= llikarjun C. =0ATo: Julian Satran =0ASent: Thursday, December 28, 2006 12:09:16 PM=0ASubject: Re: = [Ips] TMF text with updates=0A=0A=0AJulian,=0A =0AThanks for the quick revi= ew.=0A =0AI agree with your point on the bullet (c) - it was a relic. I no= w fixed the text per your feedback.=0A =0AOn your alternative proposal to s= end a TMF on every connection, I would need more details.... I do not see = any issues with the third-party initiator sessions so far, with the current= text we have. The TaskReporting key is a session-scoped key that the targ= et tracks on a session-by-session basis.=0A =0AMallikarjun=0A=0A=0A =0A----= - Original Message ----=0AFrom: Julian Satran =0A= To: Mallikarjun C. =0ACc: ips@ietf.org=0ASent: Th= ursday, December 28, 2006 2:31:49 AM=0ASubject: Re: [Ips] TMF text with upd= ates=0A=0A=0AMallikarjun, =0A=0AI would consider the text: =0A=0Ac. MUST le= ave all active "affected TTTs" (i.e. active TTTs associated with affected t= asks) valid along with any buffer allocations for the TTTs intact. =0A=0Aso= mewhat excessive as it relates too much to implementation. I would rather s= ay: =0A=0Ac. MUST leave all active "affected TTTs" (i.e. active TTTs associ= ated with affected tasks) valid. =0A=0Aand leave the buffer issue to the im= plementer (as I have stated already on this list). =0A=0AI also keep thinki= ng (and mildly objecting to) that the whole fast abort is excesively compl= ex. =0A=0AYou could achive the same effect by issuing the TM command on eve= ry affected connection. =0AThe third party story is even more puzzling as i= n order to negotiate any of the nem TM modes the taget will have to ascerta= in that all other initiators support it. I fail to understand how would you= handle downgrading the mode for those that don't. And if you don't downgra= de why not state that fast-abort and target scoped queues don't go together= and simplify the mechanics to a multiple issue TM. =0A=0AThanks, =0AJulo = =0A=0A=0A"Mallikarjun C." =0A28/12/06 06:41 Toip= s@ietf.org =0Acc=0ASubject[Ips] TMF text with updates=0A=0A=0A=0A=0A=0A=0A= =0AAttached is the latest text that incorporates David's proposed enhanceme= nt. Please review and comment. Note especially two things: new section 4.= 1.4 that summarizes generic implementation considerations for both "clarifi= ed" and "updated" semantics, the changed text in 4.1.2 that says "MAY wait = for ....target transfer tags.....from third-party initiators" from the prev= ious blanket MUST.=0A=0AMallikarjun=0A=0A=0A=0A4.1.2 Clarified multi-task a= bort semantics=0AAll iSCSI implementations MUST support the protocol behavi= or defined in this section as the default behavior. The execution of ABORT= TASK SET, CLEAR TASK SET, LOGICAL UNIT RESET, TARGET WARM RESET, and TARGE= T COLD RESET TMF Requests consists of the following sequence of actions in = the specified order on the specified party. =0AThe initiator iSCSI layer:= =0Aa. MUST continue to respond to each TTT received for the affected tasks.= =0Ab. Should receive any responses that the target may provide for some ta= sks among the affected tasks (may process them as usual because they are gu= aranteed to have chronologically originated prior to the TMF response). =0A= c. Should receive the TMF Response concluding all the tasks in the set of a= ffected tasks. =0A=0AThe target iSCSI layer:=0Aa. MUST wait for currently v= alid target transfer tags of the affected tasks from the issuing initiator = to be responded to. MAY wait for responses on currently valid target trans= fer tags of the affected tasks from third-party initiators.=0Ab. MUST wait = (concurrent with the wait in Step.a) for all commands of the affected tasks= to be received based on the CmdSN ordering. SHOULD NOT wait for new comm= ands on third-party affected sessions - only the instantiated tasks have to= be considered for the purpose of determining the affected tasks. In the c= ase of target-scoped requests (i.e. TARGET WARM RESET and TARGET COLD RESET= ), all the commands that are not yet received on the issuing session in the= command stream however can be considered to have been received with no com= mand waiting period - i.e. the entire CmdSN space up to the CmdSN of the ta= sk management function can be "plugged".=0Ac. MUST propagate the TMF reques= t to and receive the response from the target SCSI layer. =0Ad. MUST addres= s the Response Fence flag on the TMF Response on issuing session as defined= in 3.3.2.=0Ae. MUST address the Response Fence flag on the first post-TMF = Response on third-party sessions as defined in 3.3.2. If some tasks origin= ate from non-iSCSI I_T_L nexuses then the means by which the target ensures= that all affected tasks have returned their status to the initiator are de= fined by the specific non-iSCSI transport protocol(s).=0AImplementation not= e: Technically, the TMF servicing is complete in Step.d. Data transfers co= rresponding to terminated tasks may however still be in progress on third-p= arty iSCSI sessiosn even at the end of Step.e. TMF Response MUST NOT be se= nt by the target iSCSI layer before the end of Step.d, and MAY be sent at t= he end of Step.d despite these outstanding Data transfers until after Step.= e.=0A=0A4.1.3 Updated multi-task abort semantics=0AProtocol behavior define= d in this section MUST be implemented by all iSCSI implementations complyin= g with this document. Protocol behavior defined in this section MUST be ex= hibited by iSCSI implementations on an iSCSI session when they negotiate th= e TaskReporting (section 9.1) key to =93FastAbort=94 on that session. The = execution of ABORT TASK SET, CLEAR TASK SET, LOGICAL UNIT RESET, TARGET WAR= M RESET, and TARGET COLD RESET TMF Requests consists of the following seque= nce of actions in the specified order on the specified party. =0AThe initia= tor iSCSI layer:=0Aa. MUST NOT send any more Data-Out PDUs for affected tas= ks on the issuing connection of the issuing iSCSI session once the TMF is s= ent to the target.=0Ab. Should receive any responses that the target may pr= ovide for some tasks among the affected tasks (may process them as usual be= cause they are guaranteed to have chronologically originated prior to the T= MF response).=0Ac. MUST respond to Async Message PDU with AsyncEvent=3D5 as= defined in section 8.1.=0Ad. Should receive the TMF Response concluding al= l the tasks in the set of affected tasks.=0A=0AThe target iSCSI layer:=0Aa.= MUST wait for all commands of the affected tasks to be received based on t= he CmdSN ordering on the issuing session. SHOULD NOT wait for new commands= on third-party affected sessions - only the instantiated tasks have to be = considered for the purpose of determining the affected tasks. In the case = of target-scoped requests (i.e. TARGET WARM RESET and TARGET COLD RESET), a= ll the commands that are not yet received on the issuing session in the com= mand stream however can be considered to have been received with no command= waiting period - i.e. the entire CmdSN space up to the CmdSN of the task m= anagement function can be "plugged".=0Ab. MUST propagate the TMF request to= and receive the response from the target SCSI layer. =0Ac. MUST leave all = active "affected TTTs" (i.e. active TTTs associated with affected tasks) va= lid along with any buffer allocations for the TTTs intact.=0Ad. MUST genera= te an Asynchronous Message PDU with AsyncEvent=3D5 (section 8.1) on:=0Ai) e= ach connection of each third-party session that at least one affected task = is allegiant to, and=0Aii) each connection except the issuing connection of= the issuing session that has at least one allegiant affected task.=0AIf th= ere are multiple affected LUs (say due to a target reset), then one Async M= essage PDU MUST be sent for each such LU on each connection that has at lea= st one allegiant affected task.=0Ae. MUST address the Response Fence flag o= n the TMF Response on issuing session as defined in 3.3.2.=0Af. MUST addres= s the Response Fence flag on the first post-TMF Response on third-party ses= sions as defined in 3.3.2. If some tasks originate from non-iSCSI I_T_L nex= uses then the means by which the target ensures that all affected tasks hav= e returned their status to the initiator are defined by the specific non-iS= CSI transport protocol(s).=0Ag. MUST free up the affected TTTs (and STags, = if applicable) and the corresponding buffers once it receives the associate= d Nop-Out acknowledgement that the initiator generated in response to the A= sync Message. =0AImplementation note: Technically, the TMF servicing is co= mplete in Step.e. Data transfers corresponding to terminated tasks may how= ever still be in progress even at the end of Step.f. TMF Response MUST NOT= be sent by the target iSCSI layer before the end of Step.e, and MAY be sen= t at the end of Step.e despite these outstanding Data transfers until Step.= g. Step.g specifies an event to free up any such resources that may have b= een reserved to support outstanding data transfers. =0A4.1.3.1 Clearing ef= fects update=0AAppendix F.1 of [RFC3720] specifies the clearing effects of = target and LU resets on =93Incomplete TTTs=94 as =93Y=94. This meant that = a target warm reset or a target cold reset or an LU reset would clear the a= ctive TTTs upon completion. The TaskReporting=3DFastAbort (section 9.1) se= mantics defined by this section however do not guarantee that the active TT= Ts are cleared by the end of the reset operations. In fact, the new semant= ics are designed to allow clearing the TTTs in a =93lazy=94 fashion after t= he TMF Response is delivered. Thus, when TaskReporting=3DFastAbort is oper= ational on a session, the clearing effects of reset operations on =93Incomp= lete TTTs=94 is =93N=94. =0A4.1.4 Implementation considerations=0ABoth in = clarified semantics (section 4.1.2) and updated semantics (section 4.1.3), = there may be outstanding data transfers even after the TMF completion is re= ported on the issuing session. In the case of iSCSI/iSER [iSER], these wou= ld be tagged data transfers for STags not owned by any active tasks. Wheth= er or not real buffers support these data transfers is implementation-depen= dent. However, the data transfers logically MUST be silently discarded by = the target iSCSI layer in all cases. A target MAY, on an implementation-de= fined internal timeout, also choose to drop the connections on which it did= not receive the expected Data-out sequences (section 4.1.2) or Nop-Out ack= nowledgements (section 4.1.3) so as to reclaim the associated buffer, STag = and TTT resources as appropriate.=0A=0A=0A----- Original Message ----=0AFro= m: "Black_David@emc.com" =0ATo: Black_David@emc.com; c= b_mallikarjun@yahoo.com; ips@ietf.org=0ASent: Wednesday, December 20, 2006 = 2:33:43 PM=0ASubject: RE: [Ips] Implementer's Guide - Task Management Issue= =0A=0A=0A> Let's try this line of reasoning - the target issues the Nop-Out= , now=0Awhen=0A> can it free the resources? Answer:=0A> - The Nop-In r= esponse comes back, OR=0A> - The connection times out and is torn down.= =0A> Now, what if the Nop-Out is not issued - what does the target wait for= =0Ato=0A> free the resources? Answer:=0A> - The transfers complete, OR= =0A> - The connection times out and is torn down. =0A> Those look simil= ar enough at the target (the worst case is the same -=0Athe=0A> resources a= re tied up until an uncooperative initiator times out) that=0A> I don't see= the harm in allowing the early TMF return without the new=0A> key. The cl= ear distinction is that the first two bullets are=0Adifferent;=0A> if the n= ew key is not negotiated, the target has to wait for the=0Atransfers=0A> to= complete; the new key and the Nop-Out are necessary to walk away=0Aearlier= =0A> when the initiator involved is able to continue the transfers.=0A=0ATh= at got slightly twisted - what it should have talked about was the=0Atarget= =0Aissuing the new Async Message and the Nop-Out response coming back.=0A= =0AThanks,=0A--David=0A----------------------------------------------------= =0ADavid L. Black, Senior Technologist=0AEMC Corporation, 176 South St., Ho= pkinton, MA 01748=0A+1 (508) 293-7953 FAX: +1 (508) 293-7786= =0Ablack_david@emc.com Mobile: +1 (978) 394-7754=0A-----------------= -----------------------------------=0A=0A__________________________________= ________________=0ADo You Yahoo!?=0ATired of spam? Yahoo! Mail has the bes= t spam protection around =0Ahttp://mail.yahoo.com =0A=0A___________________= ____________________________=0AIps mailing list=0AIps@ietf.org=0Ahttps://ww= w1.ietf.org/mailman/listinfo/ips=0A=0A=0A=0A=0A=0A_________________________= _________________________=0ADo You Yahoo!?=0ATired of spam? Yahoo! Mail has= the best spam protection around =0Ahttp://mail.yahoo.com=0A=0A____________= ______________________________________=0ADo You Yahoo!?=0ATired of spam? Y= ahoo! Mail has the best spam protection around =0Ahttp://mail.yahoo.com --0-160516847-1167337539=:91933 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Forgot to copy to the list.

=0A
= ----- Forwarded Message ----
From: Mallikarjun C. <cb_mallikarjun@yah= oo.com>
To: Julian Satran <Julian_Satran@il.ibm.com>
Sent: T= hursday, December 28, 2006 12:09:16 PM
Subject: Re: [Ips] TMF text with = updates

=0A
=0A
Julian,
=0A
 =0A
Thanks for the quick review.
=0A
 =0A
I agree with your point on the bullet (c) - it was a relic.&n= bsp; I now fixed the text per your feedback.
=0A
 
= =0A
On your alternative proposal to send a TMF on every connection= , I would need more details....  I do not see any issues with the thir= d-party initiator sessions so far, with the current text we have.  The= TaskReporting key is a session-scoped key that the target tracks on a sess= ion-by-session basis.
=0A
 
=0A
Mallikarju= n
=0A


 
=0A
----- Original Message= ----
From: Julian Satran <Julian_Satran@il.ibm.com>
To: Mallik= arjun C. <cb_mallikarjun@yahoo.com>
Cc: ips@ietf.org
Sent: Thur= sday, December 28, 2006 2:31:49 AM
Subject: Re: [Ips] TMF text with upda= tes


Mallikarjun,
I would consider the text:
c. MUST leave all active "affected TTTs" (i.e. active T= TTs associated with affected tasks) valid along with any buffer allocations= for the TTTs intact.

= somewhat excessive as it relates too much to implementation. I would rather= say:

c. MUST leave all active "affected = TTTs" (i.e. active TTTs associated with affected tasks) valid. =

and leave the buffer issue to the implementer (a= s I have stated already on this list).

I also keep thinking (and mildly  objecting to) that the whole fast = abort is excesively complex.

You cou= ld achive the same effect by issuing the TM command on every affected conne= ction.
The third party story is even mor= e puzzling as in order to negotiate any of the nem TM modes the taget will = have to ascertain that all other initiators support it. I fail to understan= d how would you handle downgrading the mode for those that don't. And if yo= u don't downgrade why not state that fast-abort and target scoped queues do= n't go together and simplify the mechanics to a multiple issue TM.

Thanks,
J= ulo


=0A=0A=0A=0A
"Mallikarj= un C." <cb_mallikarjun@yahoo.com> =0A

28/12/06 06:41

=0A		=0A=0A=0A=0A=0A=0A
=0A
To
=0A		ips@ietf.org =0A
=0A
cc
=0A		=0A
=0A
Subject
=0A		[Ips] TMF text with updat= es

=0A=0A=0A=0A
=0A

<= BR>

Attached is the latest text that incorporates= David's proposed enhancement.  Please review and comment.  Note = especially two things: new section 4.1.4 that summarizes generic implementa= tion considerations for both "clarified" and "updated" semantics, the chang= ed text in 4.1.2 that says "MAY wait for ....target transfer tags.....from = third-party initiators" from the previous blanket MUST.

Mallikarjun<= BR>


4.1.2 Clarified multi-task abort semantics
All iSCSI impl= ementations MUST support the protocol behavior defined in this section as t= he default behavior.  The execution of ABORT TASK SET, CLEAR TASK SET,= LOGICAL UNIT RESET, TARGET WARM RESET, and TARGET COLD RESET TMF Requests = consists of the following sequence of actions in the specified order on the= specified party.
The initiator iSCSI layer:
a. MUST continue to res= pond to each TTT received for the affected tasks.
b. Should receive any responses that the target ma= y provide for some tasks among the affected tasks (may process them as usua= l because they are guaranteed to have chronologically originated prior to t= he TMF response).
c. Should receive the TMF Response concluding all the= tasks in the set of affected tasks.

The target iSCSI layer:
a. = MUST wait for currently valid target transfer tags of the affected tasks fr= om the issuing initiator to be responded to.  MAY wait for responses o= n currently valid target transfer tags of the affected tasks from third-par= ty initiators.
b. MUST wait (concurrent with the wait in Step.a) for all= commands of the affected tasks to be received based on the CmdSN ordering.=   SHOULD NOT wait for new commands on third-party affected sessions -= only the instantiated tasks have to be considered for the purpose of deter= mining the affected tasks.  In the case of target-scoped requests (i.e= . TARGET WARM RESET and TARGET COLD RESET), all the commands that are not yet received o= n the issuing session in the command stream however can be considered to ha= ve been received with no command waiting period - i.e. the entire CmdSN spa= ce up to the CmdSN of the task management function can be "plugged".
c. = MUST propagate the TMF request to and receive the response from the target = SCSI layer.
d. MUST address the Response Fence flag on the TMF Response= on issuing session as defined in 3.3.2.
e. MUST address the Response Fe= nce flag on the first post-TMF Response on third-party sessions as defined = in 3.3.2.  If some tasks originate from non-iSCSI I_T_L nexuses then t= he means by which the target ensures that all affected tasks have returned = their status to the initiator are defined by the specific non-iSCSI transpo= rt protocol(s).
Implementation note: Technically, the TMF servicing is c= omplete in Step.d.  Data transfers corresponding to terminated tasks m= ay however still be in progress on third-party iSCSI sessiosn even at the end of Step= .e.  TMF Response MUST NOT be sent by the target iSCSI layer before th= e end of Step.d, and MAY be sent at the end of Step.d despite these outstan= ding Data transfers until after Step.e.

4.1.3 Updated multi-task abo= rt semantics
Protocol behavior defined in this section MUST be implement= ed by all iSCSI implementations complying with this document.  Protoco= l behavior defined in this section MUST be exhibited by iSCSI implementatio= ns on an iSCSI session when they negotiate the TaskReporting (section 9.1) = key to =93FastAbort=94 on that session.  The execution of ABORT TASK S= ET, CLEAR TASK SET, LOGICAL UNIT RESET, TARGET WARM RESET, and TARGET COLD = RESET TMF Requests consists of the following sequence of actions in the spe= cified order on the specified party.
The initiator iSCSI layer:
a. M= UST NOT send any more Data-Out PDUs for affected tasks on the issuing conne= ction of the issuing iSCSI session once the TMF is sent to the target.
b. Should rec= eive any responses that the target may provide for some tasks among the aff= ected tasks (may process them as usual because they are guaranteed to have = chronologically originated prior to the TMF response).
c. MUST respond t= o Async Message PDU with AsyncEvent=3D5 as defined in section 8.1.
d. Sh= ould receive the TMF Response concluding all the tasks in the set of affect= ed tasks.

The target iSCSI layer:
a. MUST wait for all commands o= f the affected tasks to be received based on the CmdSN ordering on the issu= ing session.  SHOULD NOT wait for new commands on third-party affected= sessions - only the instantiated tasks have to be considered for the purpo= se of determining the affected tasks.  In the case of target-scoped re= quests (i.e. TARGET WARM RESET and TARGET COLD RESET), all the commands tha= t are not yet received on the issuing session in the command stream however= can be considered to have been received with no command waiting period - i.e. the= entire CmdSN space up to the CmdSN of the task management function can be = "plugged".
b. MUST propagate the TMF request to and receive the response= from the target SCSI layer.
c. MUST leave all active "affected TTTs" (= i.e. active TTTs associated with affected tasks) valid along with any buffe= r allocations for the TTTs intact.
d. MUST generate an Asynchronous Mess= age PDU with AsyncEvent=3D5 (section 8.1) on:
i) each connection of each= third-party session that at least one affected task is allegiant to, andii) each connection except the issuing connection of the issuing session = that has at least one allegiant affected task.
If there are multiple aff= ected LUs (say due to a target reset), then one Async Message PDU MUST be s= ent for each such LU on each connection that has at least one allegiant aff= ected task.
e. MUST address the Response Fence flag on the TMF Response = on issuing session as defined in 3.3.2.
f. MUST address the Response Fence flag on= the first post-TMF Response on third-party sessions as defined in 3.3.2. I= f some tasks originate from non-iSCSI I_T_L nexuses then the means by which= the target ensures that all affected tasks have returned their status to t= he initiator are defined by the specific non-iSCSI transport protocol(s).g. MUST free up the affected TTTs (and STags, if applicable) and the corr= esponding buffers once it receives the associated Nop-Out acknowledgement t= hat the initiator generated in response to the Async Message.  
Imp= lementation note: Technically, the TMF servicing is complete in Step.e. &nb= sp;Data transfers corresponding to terminated tasks may however still be in= progress even at the end of Step.f.  TMF Response MUST NOT be sent by= the target iSCSI layer before the end of Step.e, and MAY be sent at the en= d of Step.e despite these outstanding Data transfers until Step.g.  St= ep.g specifies an event to free up any such resources that may have been reserv= ed to support outstanding data transfers.  
4.1.3.1 Clearing effect= s update
Appendix F.1 of [RFC3720] specifies the clearing effects of tar= get and LU resets on =93Incomplete TTTs=94 as =93Y=94.  This meant tha= t a target warm reset or a target cold reset or an LU reset would clear the= active TTTs upon completion.  The TaskReporting=3DFastAbort (section = 9.1) semantics defined by this section however do not guarantee that the ac= tive TTTs are cleared by the end of the reset operations.  In fact, th= e new semantics are designed to allow clearing the TTTs in a =93lazy=94 fas= hion after the TMF Response is delivered.  Thus, when TaskReporting=3D= FastAbort is operational on a session, the clearing effects of reset operat= ions on =93Incomplete TTTs=94 is =93N=94.  
4.1.4 Implementation co= nsiderations
Both in clarified semantics (section 4.1.2) and updated sem= antics (section 4.1.3), there may be outstanding data transfers even after the TMF complet= ion is reported on the issuing session.  In the case of iSCSI/iSER [iS= ER], these would be tagged data transfers for STags not owned by any active= tasks.  Whether or not real buffers support these data transfers is i= mplementation-dependent.  However, the data transfers logically MUST b= e silently discarded by the target iSCSI layer in all cases.  A target= MAY, on an implementation-defined internal timeout, also choose to drop th= e connections on which it did not receive the expected Data-out sequences (= section 4.1.2) or Nop-Out acknowledgements (section 4.1.3) so as to reclaim= the associated buffer, STag and TTT resources as appropriate.


-= ---- Original Message ----
From: "Black_David@emc.com" <Black_David@e= mc.com>
To: Black_David@emc.com; cb_mallikarjun@yahoo.com; ips@ietf.o= rg
Sent: Wednesday, December 20, 2006 2:33:43 PM
Subject: RE: [Ips] I= mplementer's Guide - Task Management Issue


> Let's try this line of reaso= ning - the target issues the Nop-Out, now
when
> can it free the r= esources?  Answer:
>     - The Nop-In response comes b= ack, OR
>     - The connection times out and is torn down.<= BR>> Now, what if the Nop-Out is not issued - what does the target wait = for
to
> free the resources?  Answer:
>     -= The transfers complete, OR
>     - The connection times ou= t and is torn down.
> Those look similar enough at the target (the w= orst case is the same -
the
> resources are tied up until an uncoo= perative initiator times out) that
> I don't see the harm in allowing= the early TMF return without the new
> key.  The clear distinct= ion is that the first two bullets are
different;
> if the new key = is not negotiated, the target has to wait for the
transfers
> to c= omplete; the new key and the Nop-Out are necessary to walk away
earlier
> when= the initiator involved is able to continue the transfers.

That got = slightly twisted - what it should have talked about was the
target
is= suing the new Async Message and the Nop-Out response coming back.

Th= anks,
--David
----------------------------------------------------David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hop= kinton, MA  01748
+1 (508) 293-7953         &nb= sp;   FAX: +1 (508) 293-7786
black_david@emc.com     &nbs= p;  Mobile: +1 (978) 394-7754
-------------------------------------= ---------------

__________________________________________________Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam prot= ection around
http://mail.yahoo.com

___________________________= ____________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips

=0A


________________________= __________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail = has the best spam protection around
http://mail.yahoo.com


__________________________________________________
Do You Y= ahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around <= br>http://mail.yahoo.com --0-160516847-1167337539=:91933-- --===============1673648903== 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 --===============1673648903==-- From ips-bounces@ietf.org Thu Dec 28 15:27:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H01qy-0001IM-Kk; Thu, 28 Dec 2006 15:27:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H01qx-0001IH-CI for ips@ietf.org; Thu, 28 Dec 2006 15:27:51 -0500 Received: from mexforward.lss.emc.com ([128.222.32.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H01qw-0007dI-4U for ips@ietf.org; Thu, 28 Dec 2006 15:27:51 -0500 Received: from mailhub.lss.emc.com (nirah.lss.emc.com [10.254.144.13]) by mexforward.lss.emc.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id kBSKRniv027278 for ; Thu, 28 Dec 2006 15:27:49 -0500 (EST) Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id kBSKRdli000128 for ; Thu, 28 Dec 2006 15:27:49 -0500 (EST) From: Black_David@emc.com Received: from CORPUSMX20A.corp.emc.com ([128.221.62.13]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Dec 2006 15:27:21 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 28 Dec 2006 15:27:20 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: iSCSI Implementer's Guide - WG Last Call status Thread-Index: AccqvpOM97n0qzgHQzqxpVYCuljEaQ== To: X-OriginalArrivalTime: 28 Dec 2006 20:27:21.0454 (UTC) FILETIME=[93C320E0:01C72ABE] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2006.12.28.115932 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -2, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CTE 0, __CTYPE_CHARSET_QUOTED 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.2 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Subject: [Ips] iSCSI Implementer's Guide - WG Last Call status X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org The Working Group Last Call on this draft nominally ended on December 18th, but there was no reason to treat that as a hard cutoff. I am now ending the WG Last Call on this draft, although list discussion of issues should be continued. There have been two issues raised during this WGLC: (1) Task Management - how to deal with uncooperative third- party initiators. This issue has been resolved on the list. (2) Target checks - whether to discourage targets from checking for initiator mistakes that the target can tolerate. At the moment, I think the "rough consensus" of the WG is not to do this - if anyone other than Eddy thinks this is important to clarify, they need to speak up promptly after the holidays. The process from here is that Mallikarjun will submit a revised version of the draft in the near future (there are still some details to be worked out on the list). I will be completely out of action (no email) the first two weeks of January, so there will be time for people to check for problems/issues/etc. I will check the revised draft and send it to Lars with a request for RFC publication sometime in the second half of January (probably during the week of January 22nd). 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 Thu Dec 28 16:11:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H02Wg-00009i-0N; Thu, 28 Dec 2006 16:10:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H02We-00007u-Tw for ips@ietf.org; Thu, 28 Dec 2006 16:10:56 -0500 Received: from web51912.mail.yahoo.com ([206.190.48.75]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H02Wd-0005aq-EJ for ips@ietf.org; Thu, 28 Dec 2006 16:10:56 -0500 Received: (qmail 6300 invoked by uid 60001); 28 Dec 2006 21:10:55 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=H85Q3XgDCP2eqJuEqBKZ7YUcA9jHWtLH32yRhccUYpEeKwzEasNbQJ6fvULrDiORYw/lUNf4XJlRl22TEjg6umgs8yWpqNOiJmciNzGnd3i/sN+Cfgq0VLvEF+6s/3Tx6YoF+TXrsmzmNvtXEA/l0mDyD4COqCH9+5bc8BR/vpA= ; Message-ID: <20061228211055.6298.qmail@web51912.mail.yahoo.com> Received: from [15.246.143.45] by web51912.mail.yahoo.com via HTTP; Thu, 28 Dec 2006 13:10:55 PST Date: Thu, 28 Dec 2006 13:10:55 -0800 (PST) From: "Mallikarjun C." Subject: Re: [Ips] Single 3-valued key for task reporting To: ips@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org It might be OK, the fact that the new key allows two values (other than Leg= acy) in itself implies that flexibility. I don't think the current IG text= really makes the support mandatory.=0A=0ABut let's have more discussion on= Julian's concern to see if we can further simplify.=0A=0AMallikarjun=0A=0A= ----- Original Message ----=0AFrom: "Black_David@emc.com" =0ATo: cb_mallikarjun@yahoo.com; ips@ietf.org=0ASent: Thursday, Decembe= r 28, 2006 12:21:37 PM=0ASubject: RE: [Ips] Single 3-valued key for task re= porting=0A=0A=0ASomething to think about on this one. Following on Julian'= s concern=0Aabout the complexity of fast task abort, one possibility would = be to=0Asay, that *if* this key is implemented:=0A- support for ResponseFen= ce is mandatory=0A- support for FastTaskAbort is optional=0AI think the cur= rent IG text makes fast task abort support mandatory.=0A=0AComments?=0A=0AT= hanks,=0A--David=0A=0A> -----Original Message-----=0A> From: Mallikarjun C.= [mailto:cb_mallikarjun@yahoo.com] =0A> Sent: Wednesday, December 27, 2006 = 11:33 PM=0A> To: IPS=0A> Subject: [Ips] Single 3-valued key for task report= ing=0A> =0A> Per the email conversation at the bottom of this email, I =0A>= propose the following text for a new 3-valued key =0A> "TaskReporting" tha= t replaces the FastMultiTaskAbort key. =0A> Comments are welcome.=0A> =0A>= 9.1 TaskReporting=0A> Use: LO=0A> Senders: Initiator and Target=0A> Scope:= SW=0A> Irrelevant when: SessionType=3DDiscovery=0A> TaskReporting=3D=0A> Default is Legacy.=0A> Result function is AND.=0A> This key = is used to negotiate the task completion reporting =0A> semantics from the = SCSI target. Following table describes =0A> the semantics an iSCSI target = MUST support for respective =0A> negotiated key values. The Legacy value M= UST be offered as =0A> an option by negotiation originator.=0A> +----------= ----+------------------------------------------+=0A> | Name | = Description |=0A> +--------------+-------------------= -----------------------+=0A> | Legacy | RFC 3720-compliant semantics. R= esponse |=0A> | | fencing is not guaranteed and fast = |=0A> | | completion of multi-task aborting is not |=0A> | = | supported |=0A> +-----------= ---+------------------------------------------+=0A> | ResponseFence| Respon= se Fence (section 3.3.1) semantics |=0A> | | MUST be= supported in reporting task |=0A> | | completi= ons |=0A> +--------------+--------------------= ----------------------+=0A> | FastAbort | Updated fast multi-task abort s= emantics | =0A> | | defined in section 4.1.3 MUST be = |=0A> | | supported. Support for Response Fence is|= =0A> | | implied - i.e. section 3.3.1 semantics |=0A> | = | MUST be supported as well |=0A> +--------= ------+------------------------------------------+=0A> When TaskReporting i= s not negotiated to FastAbort, The =0A> default behavior is to use the [RFC= 3720] TMF semantics as =0A> clarified in section 4.1.2. =0A> =0A> =0A> =0A>= =0A> ----- Original Message ----=0A> From: "Black_David@emc.com" =0A> To: cb_mallikarjun@yahoo.com; ips@ietf.org=0A> Sent: Monda= y, December 11, 2006 10:56:02 AM=0A> Subject: RE: [Ips] Implementer's Guide= - Task Management Issue=0A> =0A> =0A> Mallikarjun,=0A> =0A> ......=0A> > T= he other thing that came to my mind after reading your note =0A> > is that = we don't currently have a generic key to capture the =0A> > Response Fence = behavior - although response fencing underlies =0A> > both the fast multi-t= ask abort as well as addressing ACA race =0A> > conditions (and perhaps oth= ers down the road. e.g. around =0A> > persistent reservations). So, today,= the Note at the end of =0A> > section 3.3.3 advises that implementations m= ay check the =0A> > FastMultiTaskAbort key to verify if safe behavior for M= CS ACA =0A> > is supported, although ACA has really nothing to do with =0A>= > multi-task aborting. I am wondering if we should create a =0A> > new ke= y (say ResponseFence), so the semantics would become:=0A> > = =0A> =0A> > R= esponseFence "Yes" fencing done by target =0A> > = "No" legacy, no fencing =0A> > (so "clarified" TMF sema= ntics are not possible either)=0A> > =0A> > With ResponseFence=3D = "Yes"=0A> > FastMultiTaskAbort =0A> > "Yes" fa= st abort & fencing =0A> > "No" tradi= tional wait on =0A> > outstanding TTTs (fencing on ACA is still possible)= =0A> > =0A> > With ResponseFence=3D "No"=0A> > FastMultiTaskAbort = =0A> > "Yes" Illegal, Response Fence must be "Yes"= =0A> > "No" No fencing, must wait on =0A> > outst= anding TTTs=0A> > =0A> > =0A> > The downside of this scheme is that it ma= y be going in the =0A> > opposite direction than you wanted (introduces a s= econd key =0A> > that 3720-compliant implementations don't know about). We= =0A> > could alternatively simply mandate the behavior equivalent to =0A> = > ResponseFence =3D "Yes" always and avoid the second key, but =0A> > doing= so could make the current 3720-compliant =0A> > implementations technicall= y non-iSCSI-compliant.=0A> > =0A> > Comments?=0A> =0A> Given the inter-depe= ndence of ResponseFence and FastMultiTaskAbort,=0A> a single 3-valued key i= s probably simpler than two boolean keys.=0A> I think having an explicit me= ans of determining whether ACA behaves=0A> correctly on an multi-connection= -session is worth adding.=0A> =0A> Thanks,=0A> --David =0A> =0A> > Mallikar= jun=0A> =0A> __________________________________________________=0A> Do You = Yahoo!?=0A> Tired of spam? Yahoo! Mail has the best spam protection around= =0A> http://mail.yahoo.com =0A> =0A> _____________________________________= __________=0A> Ips mailing list=0A> Ips@ietf.org=0A> https://www1.ietf.org/= mailman/listinfo/ips=0A> =0A>=0A=0A________________________________________= __________=0ADo You Yahoo!?=0ATired of spam? Yahoo! Mail has the best spam= protection around =0Ahttp://mail.yahoo.com _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Fri Dec 29 06:16:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0FiL-0003jK-SM; Fri, 29 Dec 2006 06:15:53 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0FiK-0003j2-9V for ips@ietf.org; Fri, 29 Dec 2006 06:15:52 -0500 Received: from mtagate1.de.ibm.com ([195.212.29.150]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H0FiI-0003hF-CE for ips@ietf.org; Fri, 29 Dec 2006 06:15:52 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate1.de.ibm.com (8.13.8/8.13.8) with ESMTP id kBTBFjpl158360 for ; Fri, 29 Dec 2006 11:15:45 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id kBTBFiAI2990168 for ; Fri, 29 Dec 2006 12:15:44 +0100 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id kBTBFiTS002457 for ; Fri, 29 Dec 2006 12:15:44 +0100 Received: from d12mc102.megacenter.de.ibm.com (d12mc102.megacenter.de.ibm.com [9.149.167.114]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id kBTBFiJa002454 for ; Fri, 29 Dec 2006 12:15:44 +0100 In-Reply-To: <20061228194536.74558.qmail@web51914.mail.yahoo.com> To: "Mallikarjun C." MIME-Version: 1.0 Subject: Re: [Ips] IG clarifications: Login Response & Reject reason codes X-Mailer: Lotus Notes Release 7.0.2 September 26, 2006 From: Julian Satran Message-ID: Date: Fri, 29 Dec 2006 13:15:41 +0200 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 7.0.2HF71 | November 3, 2006) at 29/12/2006 13:15:43, Serialize complete at 29/12/2006 13:15:43 X-Spam-Score: 0.1 (/) X-Scan-Signature: 8a4bcf8f67063cac573319207fe3db35 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="===============0215789496==" Errors-To: ips-bounces@ietf.org This is a multipart message in MIME format. --===============0215789496== Content-Type: multipart/alternative; boundary="=_alternative 003A5F29C2257253_=" This is a multipart message in MIME format. --=_alternative 003A5F29C2257253_= Content-Type: text/plain; charset="US-ASCII" Mallikarjun, If we allow for multiple outstanding Login Requests we will have to allow for multiple outstanding Login Responses. Regards, Julo "Mallikarjun C." 28/12/06 21:45 To Julian Satran/Haifa/IBM@IBMIL cc IPS Subject Re: [Ips] IG clarifications: Login Response & Reject reason codes Julian, Thanks for the inputs, I somehow overlooked to respond to this email earlier. I agree with you on the "Task in progress" Reject reason code. There is no Unless I hear new objections, I would like to note "Negotiation Reset" Reject reason code as obsolete. Based on the silence so far, like you, I do not believe it is in use. On the "no more than one outstanding Login Response" semantics, your comments seem to be around Login Request PDU (and I believe we have such text for Login Request PDU) - do you see any cases wherein there can be multiple outstanding Login Responses on the wire? The request I got was to clarify if there is a plausible use case. Thanks! Mallikarjun ----- Original Message ---- From: Julian Satran To: Mallikarjun C. Cc: IPS Sent: Monday, December 11, 2006 1:34:41 PM Subject: Re: [Ips] IG clarifications: Login Response & Reject reason codes "Mallikarjun C." wrote on 11/12/2006 20:15:23: > All: > > I received some offline feedback on the implementers' guide draft > from a few reviewers who preferred to be anonymous. Please review & comment. > > 1) RFC 3720 does not explicitly call out that there cannot be more > than one outstanding Login-Response PDU on one iSCSI connection at > any given time (although the C-bit text indirectly implies it). > > This is intentional. At the time we where playing with the idea of pipelining the login. However it is common practice to have a single outstanding Login Request. I think that the only thing that becomes problematic is the phase change request (there you can have only one outstanding). There is already text that says that all changes to key values become final only at the end (when consistency can be reasonably checked). > Section 10.10 on Text Request PDU (which should cover Login Request > PDU semantics as well) says: "An initiator MUST have at most one > outstanding Text Request on a connection at any given time." > Essentially, an analog for Login/Text Response is missing (or so it seems). > > 2) RFC 3720 does not specify the use case for Reject reason code > "Task in progress" (0x07). > > I vaguely recall we put in this reason code for task reassignment > attempts while a task is in progress, but then we subsequently added > a TMF response reason code for that case (Julian?). So I'm not sure > if reason code 0x07 is used by implementations any longer. > The reject can used when the initiator attempts to start a new task but a task with the same ITT is still active for those cases when the target can't be sure this is a protocol error (e.g., a race between a logout and a reissued SCSI command). > The other non-obvious case is that of a "negotiation reset" Reject > reason code. What is this used for by implementations, if at all? > If I don't hear any objections, I will deprecate these two reason codes. > The negotiating can't be continued by one of the parties but the partial results (e.g., previous stage) are OK and no renegotiation is deemed necessary. I have no clue if somebody uses it but I felt at the time that the purists will object if I'd suggest restarting the login :-) > Mallikarjun > > > > ____________________________________________________________________________________ > Do you Yahoo!? > Everyone is raving about the all-new Yahoo! Mail beta. > http://new.mail.yahoo.com > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --=_alternative 003A5F29C2257253_= Content-Type: text/html; charset="US-ASCII"
Mallikarjun,

If we allow for multiple outstanding Login Requests we will have to allow for multiple outstanding Login Responses.

Regards,
Julo




"Mallikarjun C." <cb_mallikarjun@yahoo.com>

28/12/06 21:45

To
Julian Satran/Haifa/IBM@IBMIL
cc
IPS <ips@ietf.org>
Subject
Re: [Ips] IG clarifications: Login Response & Reject reason codes





Julian,
 
Thanks for the inputs, I somehow overlooked to respond to this email earlier.

I agree with you on the "Task in progress" Reject reason code.  There is no
 
Unless I hear new objections, I would like to note "Negotiation Reset" Reject reason code as obsolete.  Based on the silence so far, like you, I do not believe it is in use.
 
On the "no more than one outstanding Login Response" semantics, your comments seem to be around Login Request PDU (and I believe we have such text for Login Request PDU) - do you see any cases wherein there can be multiple outstanding Login Responses on the wire?  The request I got was to clarify if there is a plausible use case.  
 
Thanks!
 
Mallikarjun
----- Original Message ----
From: Julian Satran <Julian_Satran@il.ibm.com>
To: Mallikarjun C. <cb_mallikarjun@yahoo.com>
Cc: IPS <ips@ietf.org>
Sent: Monday, December 11, 2006 1:34:41 PM
Subject: Re: [Ips] IG clarifications: Login Response & Reject reason codes



"Mallikarjun C." <cb_mallikarjun@yahoo.com> wrote on 11/12/2006 20:15:23:

> All:
>
> I received some offline feedback on the implementers' guide draft
> from  a few reviewers who preferred to be anonymous.  Please review & comment.
>
> 1) RFC 3720 does not explicitly call out that there cannot be more
> than one outstanding Login-Response PDU on one iSCSI connection at
> any given time (although the C-bit text indirectly implies it).
>
>

This is intentional. At the time we where playing with the idea of pipelining the login.
However it is common practice to have a single outstanding Login Request.
I think that the only thing that becomes problematic is the phase change request (there you can have only one outstanding).
There is already text that says that all changes to key values become final only at the end (when consistency can be reasonably checked).

> Section 10.10 on Text Request PDU (which should cover Login Request
> PDU semantics as well) says: "An initiator MUST have at most one
> outstanding Text Request on a connection at any given time."  
> Essentially, an analog for Login/Text Response is missing (or so it seems).
>
> 2) RFC 3720 does not specify the use case for Reject reason code
> "Task in progress" (0x07).
>
> I vaguely recall we put in this reason code for task reassignment
> attempts while a task is in progress, but then we subsequently added
> a TMF response reason code for that case (Julian?).  So I'm not sure
> if reason code 0x07 is used by implementations any longer.  
>

The reject can used when the initiator attempts to start a new task but a task with the same ITT is still active for those cases when the target can't be sure this is a protocol error (e.g., a race between a logout and a reissued SCSI command).

> The other non-obvious case is that of a "negotiation reset" Reject
> reason code.  What is this used for by implementations, if at all?  
> If I don't hear any objections, I will deprecate these two reason codes.
>

The negotiating can't be continued by one of the parties but the partial results (e.g., previous stage) are OK and no renegotiation is deemed necessary. I have no clue if somebody uses it but I felt at the time that the purists will object if I'd suggest restarting the login :-)

> Mallikarjun
>
>
>  
> ____________________________________________________________________________________
> Do you Yahoo!?
> Everyone is raving about the all-new Yahoo! Mail beta.
> http://new.mail.yahoo.com
>
> _______________________________________________
> Ips mailing list
> Ips@ietf.org
> https://www1.ietf.org/mailman/listinfo/ips


__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
--=_alternative 003A5F29C2257253_=-- --===============0215789496== 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 --===============0215789496==-- From ips-bounces@ietf.org Fri Dec 29 06:16:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0FiX-0003pZ-Bq; Fri, 29 Dec 2006 06:16:05 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0FiV-0003oy-DK for ips@ietf.org; Fri, 29 Dec 2006 06:16:03 -0500 Received: from mtagate2.de.ibm.com ([195.212.29.151]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H0FiT-0003hp-EF for ips@ietf.org; Fri, 29 Dec 2006 06:16:03 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate2.de.ibm.com (8.13.8/8.13.8) with ESMTP id kBTBG0DI045352 for ; Fri, 29 Dec 2006 11:16:00 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id kBTBG07F2887770 for ; Fri, 29 Dec 2006 12:16:00 +0100 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id kBTBFxe4002603 for ; Fri, 29 Dec 2006 12:15:59 +0100 Received: from d12mc102.megacenter.de.ibm.com (d12mc102.megacenter.de.ibm.com [9.149.167.114]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id kBTBFxdW002600; Fri, 29 Dec 2006 12:15:59 +0100 In-Reply-To: To: Black_David@emc.com MIME-Version: 1.0 Subject: RE: [Ips] TMF text with updates X-Mailer: Lotus Notes Release 7.0.2 September 26, 2006 From: Julian Satran Message-ID: Date: Fri, 29 Dec 2006 13:15:44 +0200 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 7.0.2HF71 | November 3, 2006) at 29/12/2006 13:15:58, Serialize complete at 29/12/2006 13:15:58 X-Spam-Score: 0.5 (/) X-Scan-Signature: aaff5d7f1eb2bd23c778cdb1a9c777b3 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="===============1254628310==" Errors-To: ips-bounces@ietf.org This is a multipart message in MIME format. --===============1254628310== Content-Type: multipart/alternative; boundary="=_alternative 003B1BD3C2257253_=" This is a multipart message in MIME format. --=_alternative 003B1BD3C2257253_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable David, My point was that we can solve the TM issue only for a single initiator.=20 So besides puting the burden on SCSI to cleanly finish other and advise=20 that fast solutions really work if there are no target scoped queues there = is little we can do. And if we limit ourselves to a single initiator the=20 multiple TM solution is a simpler (and basically does not deviate from=20 3270). If you consider how software stacks are layered I assume that some = clever implementers have figured that already (and did it). Regards, Julo Black=5FDavid@emc.com=20 28/12/06 21:54 To Julian Satran/Haifa/IBM@IBMIL, cc Subject RE: [Ips] TMF text with updates I agree with Julian that we should avoid discussing "buffer allocations"=20 and the like, even though we know that something like that has to happen in at least iSER implementations. A general discussion of "resources" works. =20 > You could achive the same effect by issuing the TM command on every=20 affected connection. =20 Not for TMF's that affect commands from other initiators. Also, asking=20 the target to coordinate receipt of the TM command on every connection in a multi-connection session is also a bit much. =20 > The third party story is even more puzzling as in order to negotiate any = of > the new TM modes the taget will have to ascertain that all other=20 initiators > support it. I fail to understand how would you handle downgrading the=20 mode > for those that don't. =20 I think the target has to track this initiator by initiator, and not issue = the new async message to old initiators. This increases the importance of=20 being able to complete a TMF in the face of an uncooperative third party=20 "Legacy" initiator. =20 > And if you don't downgrade why not state that fast-abort and target=20 scoped > queues don't go together and simplify the mechanics to a multiple issue=20 TM.=20 This didn't parse for me - could you explain in more detail? =20 Thanks, --David ----------------------------------------------------=20 David L. Black, Senior Technologist=20 EMC Corporation, 176 South St., Hopkinton, MA 01748=20 +1 (508) 293-7953 FAX: +1 (508) 293-7786=20 black=5Fdavid@emc.com Mobile: +1 (978) 394-7754=20 ----------------------------------------------------=20 From: Julian Satran [mailto:Julian=5FSatran@il.ibm.com]=20 Sent: Thursday, December 28, 2006 5:32 AM To: Mallikarjun C. Cc: ips@ietf.org Subject: Re: [Ips] TMF text with updates Mallikarjun,=20 I would consider the text:=20 c. MUST leave all active "affected TTTs" (i.e. active TTTs associated with = affected tasks) valid along with any buffer allocations for the TTTs=20 intact.=20 somewhat excessive as it relates too much to implementation. I would=20 rather say:=20 c. MUST leave all active "affected TTTs" (i.e. active TTTs associated with = affected tasks) valid.=20 and leave the buffer issue to the implementer (as I have stated already on = this list).=20 I also keep thinking (and mildly objecting to) that the whole fast abort=20 is excesively complex.=20 You could achive the same effect by issuing the TM command on every=20 affected connection.=20 The third party story is even more puzzling as in order to negotiate any=20 of the nem TM modes the taget will have to ascertain that all other=20 initiators support it. I fail to understand how would you handle=20 downgrading the mode for those that don't. And if you don't downgrade why=20 not state that fast-abort and target scoped queues don't go together and=20 simplify the mechanics to a multiple issue TM.=20 Thanks,=20 Julo=20 "Mallikarjun C." =20 28/12/06 06:41=20 To ips@ietf.org=20 cc Subject [Ips] TMF text with updates Attached is the latest text that incorporates David's proposed=20 enhancement. Please review and comment. Note especially two things: new=20 section 4.1.4 that summarizes generic implementation considerations for=20 both "clarified" and "updated" semantics, the changed text in 4.1.2 that=20 says "MAY wait for ....target transfer tags.....from third-party=20 initiators" from the previous blanket MUST. Mallikarjun 4.1.2 Clarified multi-task abort semantics All iSCSI implementations MUST support the protocol behavior defined in=20 this section as the default behavior. The execution of ABORT TASK SET,=20 CLEAR TASK SET, LOGICAL UNIT RESET, TARGET WARM RESET, and TARGET COLD=20 RESET TMF Requests consists of the following sequence of actions in the=20 specified order on the specified party.=20 The initiator iSCSI layer: a. MUST continue to respond to each TTT received for the affected tasks.=20 b. Should receive any responses that the target may provide for some tasks = among the affected tasks (may process them as usual because they are=20 guaranteed to have chronologically originated prior to the TMF response).=20 c. Should receive the TMF Response concluding all the tasks in the set of=20 affected tasks.=20 The target iSCSI layer: a. MUST wait for currently valid target transfer tags of the affected=20 tasks from the issuing initiator to be responded to. MAY wait for=20 responses on currently valid target transfer tags of the affected tasks=20 from third-party initiators. b. MUST wait (concurrent with the wait in Step.a) for all commands of the=20 affected tasks to be received based on the CmdSN ordering. SHOULD NOT=20 wait for new commands on third-party affected sessions - only the=20 instantiated tasks have to be considered for the purpose of determining=20 the affected tasks. In the case of target-scoped requests (i.e. TARGET=20 WARM RESET and TARGET COLD RESET), all the commands that are not yet=20 received on the issuing session in the command stream however can be=20 considered to have been received with no command waiting period - i.e. the = entire CmdSN space up to the CmdSN of the task management function can be=20 "plugged". c. MUST propagate the TMF request to and receive the response from the=20 target SCSI layer.=20 d. MUST address the Response Fence flag on the TMF Response on issuing=20 session as defined in 3.3.2. e. MUST address the Response Fence flag on the first post-TMF Response on=20 third-party sessions as defined in 3.3.2. If some tasks originate from=20 non-iSCSI I=5FT=5FL nexuses then the means by which the target ensures that= =20 all affected tasks have returned their status to the initiator are defined = by the specific non-iSCSI transport protocol(s). Implementation note: Technically, the TMF servicing is complete in Step.d. = Data transfers corresponding to terminated tasks may however still be in=20 progress on third-party iSCSI sessiosn even at the end of Step.e. TMF=20 Response MUST NOT be sent by the target iSCSI layer before the end of=20 Step.d, and MAY be sent at the end of Step.d despite these outstanding=20 Data transfers until after Step.e. 4.1.3 Updated multi-task abort semantics Protocol behavior defined in this section MUST be implemented by all iSCSI = implementations complying with this document. Protocol behavior defined=20 in this section MUST be exhibited by iSCSI implementations on an iSCSI=20 session when they negotiate the TaskReporting (section 9.1) key to=20 ?FastAbort? on that session. The execution of ABORT TASK SET, CLEAR TASK=20 SET, LOGICAL UNIT RESET, TARGET WARM RESET, and TARGET COLD RESET TMF=20 Requests consists of the following sequence of actions in the specified=20 order on the specified party.=20 The initiator iSCSI layer: a. MUST NOT send any more Data-Out PDUs for affected tasks on the issuing=20 connection of the issuing iSCSI session once the TMF is sent to the=20 target. b. Should receive any responses that the target may provide for some tasks = among the affected tasks (may process them as usual because they are=20 guaranteed to have chronologically originated prior to the TMF response). c. MUST respond to Async Message PDU with AsyncEvent=3D5 as defined in=20 section 8.1. d. Should receive the TMF Response concluding all the tasks in the set of=20 affected tasks. The target iSCSI layer: a. MUST wait for all commands of the affected tasks to be received based=20 on the CmdSN ordering on the issuing session. SHOULD NOT wait for new=20 commands on third-party affected sessions - only the instantiated tasks=20 have to be considered for the purpose of determining the affected tasks.=20 In the case of target-scoped requests (i.e. TARGET WARM RESET and TARGET=20 COLD RESET), all the commands that are not yet received on the issuing=20 session in the command stream however can be considered to have been=20 received with no command waiting period - i.e. the entire CmdSN space up=20 to the CmdSN of the task management function can be "plugged". b. MUST propagate the TMF request to and receive the response from the=20 target SCSI layer.=20 c. MUST leave all active "affected TTTs" (i.e. active TTTs associated with = affected tasks) valid along with any buffer allocations for the TTTs=20 intact. d. MUST generate an Asynchronous Message PDU with AsyncEvent=3D5 (section=20 8.1) on: i) each connection of each third-party session that at least one affected=20 task is allegiant to, and ii) each connection except the issuing connection of the issuing session=20 that has at least one allegiant affected task. If there are multiple affected LUs (say due to a target reset), then one=20 Async Message PDU MUST be sent for each such LU on each connection that=20 has at least one allegiant affected task. e. MUST address the Response Fence flag on the TMF Response on issuing=20 session as defined in 3.3.2. f. MUST address the Response Fence flag on the first post-TMF Response on=20 third-party sessions as defined in 3.3.2. If some tasks originate from=20 non-iSCSI I=5FT=5FL nexuses then the means by which the target ensures that= =20 all affected tasks have returned their status to the initiator are defined = by the specific non-iSCSI transport protocol(s). g. MUST free up the affected TTTs (and STags, if applicable) and the=20 corresponding buffers once it receives the associated Nop-Out=20 acknowledgement that the initiator generated in response to the Async=20 Message.=20 Implementation note: Technically, the TMF servicing is complete in Step.e. = Data transfers corresponding to terminated tasks may however still be in=20 progress even at the end of Step.f. TMF Response MUST NOT be sent by the=20 target iSCSI layer before the end of Step.e, and MAY be sent at the end of = Step.e despite these outstanding Data transfers until Step.g. Step.g=20 specifies an event to free up any such resources that may have been=20 reserved to support outstanding data transfers.=20 4.1.3.1 Clearing effects update Appendix F.1 of [RFC3720] specifies the clearing effects of target and LU=20 resets on ?Incomplete TTTs? as ?Y?. This meant that a target warm reset=20 or a target cold reset or an LU reset would clear the active TTTs upon=20 completion. The TaskReporting=3DFastAbort (section 9.1) semantics defined = by this section however do not guarantee that the active TTTs are cleared=20 by the end of the reset operations. In fact, the new semantics are=20 designed to allow clearing the TTTs in a ?lazy? fashion after the TMF=20 Response is delivered. Thus, when TaskReporting=3DFastAbort is operational= =20 on a session, the clearing effects of reset operations on ?Incomplete=20 TTTs? is ?N?.=20 4.1.4 Implementation considerations Both in clarified semantics (section 4.1.2) and updated semantics (section = 4.1.3), there may be outstanding data transfers even after the TMF=20 completion is reported on the issuing session. In the case of iSCSI/iSER=20 [iSER], these would be tagged data transfers for STags not owned by any=20 active tasks. Whether or not real buffers support these data transfers is = implementation-dependent. However, the data transfers logically MUST be=20 silently discarded by the target iSCSI layer in all cases. A target MAY,=20 on an implementation-defined internal timeout, also choose to drop the=20 connections on which it did not receive the expected Data-out sequences=20 (section 4.1.2) or Nop-Out acknowledgements (section 4.1.3) so as to=20 reclaim the associated buffer, STag and TTT resources as appropriate. ----- Original Message ---- From: "Black=5FDavid@emc.com" To: Black=5FDavid@emc.com; cb=5Fmallikarjun@yahoo.com; ips@ietf.org Sent: Wednesday, December 20, 2006 2:33:43 PM Subject: RE: [Ips] Implementer's Guide - Task Management Issue > Let's try this line of reasoning - the target issues the Nop-Out, now when > can it free the resources? Answer: > - The Nop-In response comes back, OR > - The connection times out and is torn down. > Now, what if the Nop-Out is not issued - what does the target wait for to > free the resources? Answer: > - The transfers complete, OR > - The connection times out and is torn down.=20 > Those look similar enough at the target (the worst case is the same - the > resources are tied up until an uncooperative initiator times out) that > I don't see the harm in allowing the early TMF return without the new > key. The clear distinction is that the first two bullets are different; > if the new key is not negotiated, the target has to wait for the transfers > to complete; the new key and the Nop-Out are necessary to walk away earlier > when the initiator involved is able to continue the transfers. That got slightly twisted - what it should have talked about was the target issuing the new Async Message and the Nop-Out response coming back. 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=5Fdavid@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around=20 http://mail.yahoo.com=20 =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --=_alternative 003B1BD3C2257253_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
David,

My point was that we can solve the TM issue only for a single initiator. So besides puting the burden on SCSI to cleanly finish other and advise that fast solutions really work if there are no target scoped queues there is little we can do. And if we limit ourselves to a single initiator the multiple TM solution is a simpler (and basically does not deviate from 3270).  If you consider how software stacks are layered I assume that some clever implementers have figured that already (and did it).

Regards,
Julo


Black=5FDavid@emc.com=

28/12/06 21:54

To
Julian Satran/Haifa/IBM@IBMIL, <c= b=5Fmallikarjun@yahoo.com>
cc
<ips@ietf.org>
Subject
RE: [Ips] TMF text with updates





I agree with Julian that we should avoid discussing "buffer allocations" and
the like, even though we know that something like that has to happen in at
least iSER implementations.  A general discussion of "resources" works.
 
> You could achive the same effe= ct by issuing the TM command on every affected connection.
 
Not for TMF's that affect commands from other initiators.  Also, asking the
target to coordinate receipt of the TM command on every connection in a
multi-connection session is also a bit much.
 
> The third party story is even more puzzling as in order to negotiate any of
> the new TM modes the taget will have to ascertain that all other initiators
> support it. I fail to understa= nd how would you handle downgrading the mode
> for those that don't.
 
I think the target has to track this initiator by initiator, and not issue the
new async message to old initiators.  This increases the importance of being
able to complete a TMF in the face of an uncooperative third party "Legacy"
initiator.
 
> And if you don't downgrade why not state that fast-abort and target scoped
> queues don't go together and s= implify the mechanics to a multiple issue TM.
This didn't parse for me - could you explain in more detail?
 
Thanks,
--David

------------------------------------= ----------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786 <= br> black=5Fdavid@emc.com        Mobile: +1 (978) 394-7754<= /font>
----------------------------------------------------


From: Julian Satran [mailto:Julia= n=5FSatran@il.ibm.com]
Sent: Thursday, December 28, 2006 5:32 AM
To: Mallikarjun C.
Cc: ips@ietf.org
Subject: Re: [Ips] TMF text with updates

Mallikarjun,

I would consider the text:

c. MUST leave all active "affected TTTs" (i.e. active TTTs associ= ated with affected tasks) valid along with any buffer allocations for the TTTs intact.

somewhat excessive as it relates too much to implementation. I would rather say:

c. MUST leave all active "affected TTTs" (i.e. active TTTs associ= ated with affected tasks) valid.

and leave the buffer issue to the implementer (as I have stated already on this list).

I also keep thinking (and mildly  objecting to) that the whole fast abort is excesively complex.

You could achive the same effect by issuing the TM command on every affected connection.
The third party story is even more puzzling as in order to negotiate any of the nem TM modes the taget will have to ascertain that all other initiat= ors support it. I fail to understand how would you handle downgrading the mode for those that don't. And if you don't downgrade why not state that fast-ab= ort and target scoped queues don't go together and simplify the mechanics to a multiple issue TM.

Thanks,
Julo

"Mallikarjun C.&= quot; <cb=5Fmallikarjun@yahoo.com>

28/12/06 06:41 =


To
ips@ietf.org
cc
Subject
[Ips] TMF text with updates






Attached is the latest text that incorporates David's proposed enhancement.  Please review and comment.  Note especially two things: new section 4.1.4 that summarizes generic implementation considerations for both "clarified" and "updated" semantics, the changed text in 4.1.2 that says "MAY wait for ....target transfer tags.....from third-party initiators" from the previous blanket MUST.

Mallikarjun



4.1.2 Clarified multi-task abort semantics
All iSCSI implementations MUST support the protocol behavior defined in this section as the default behavior.  The execution of ABORT TASK SET, CLEAR TASK SET, LOGICAL UNIT RESET, TARGET WARM RESET, and TARGET COLD RESET TMF Requests consists of the following sequence of actions in the specified order on the specified party.
The initiator iSCSI layer:
a. MUST continue to respond to each TTT received for the affected tasks.
b. Should receive any responses that the target may provide for some tasks among the affected tasks (may process them as usual because they are guaran= teed to have chronologically originated prior to the TMF response).
c. Should receive the TMF Response concluding all the tasks in the set of affected tasks.

The target iSCSI layer:
a. MUST wait for currently valid target transfer tags of the affected tasks from the issuing initiator to be responded to.  MAY wait for responses on currently valid target transfer tags of the affected tasks from third-pa= rty initiators.
b. MUST wait (concurrent with the wait in Step.a) for all commands of the affected tasks to be received based on the CmdSN ordering.   SHOULD NOT wait for new commands on third-party affected sessions - only the insta= ntiated tasks have to be considered for the purpose of determining the affected tasks.  In the case of target-scoped requests (i.e. TARGET WARM RESET and TARGET COLD RESET), all the commands that are not yet received on the issuing session in the command stream however can be considered to have been received with no command waiting period - i.e. the entire CmdSN space up to the CmdSN of the task management function can be "plugged".=
c. MUST propagate the TMF request to and receive the response from the target SCSI layer.
d. MUST address the Response Fence flag on the TMF Response on issuing session as defined in 3.3.2.
e. MUST address the Response Fence flag on the first post-TMF Response on third-party sessions as defined in 3.3.2.  If some tasks originate from non-iSCSI I=5FT=5FL nexuses then the means by which the target ensures that all affected tasks have returned their status to the initiator are defined by the specific non-iSCSI transport protocol(s).
Implementation note: Technically, the TMF servicing is complete in Step.d.  Data transfers corresponding to terminated tasks may however still be in progress on third-party iSCSI sessiosn even at the end of Step.e.  TMF Response MUST NOT be sent by the target iSCSI layer before the end of Step.d, and MAY be sent at the end of Step.d despite these outstandi= ng Data transfers until after Step.e.

4.1.3 Updated multi-task abort semantics
Protocol behavior defined in this section MUST be implemented by all iSCSI implementations complying with this document.  Protocol behavior defin= ed in this section MUST be exhibited by iSCSI implementations on an iSCSI session when they negotiate the TaskReporting (section 9.1) key to “F= astAbort” on that session.  The execution of ABORT TASK SET, CLEAR TASK SET, LOGICAL UNIT RESET, TARGET WARM RESET, and TARGET COLD RESET TMF Requests consists of the following sequence of actions in the specified order on the specified party.
The initiator iSCSI layer:
a. MUST NOT send any more Data-Out PDUs for affected tasks on the issuing connection of the issuing iSCSI session once the TMF is sent to the target.=
b. Should receive any responses that the target may provide for some tasks among the affected tasks (may process them as usual because they are guaran= teed to have chronologically originated prior to the TMF response).
c. MUST respond to Async Message PDU with AsyncEvent=3D5 as defined in sect= ion 8.1.
d. Should receive the TMF Response concluding all the tasks in the set of affected tasks.

The target iSCSI layer:
a. MUST wait for all commands of the affected tasks to be received based on the CmdSN ordering on the issuing session.  SHOULD NOT wait for new commands on third-party affected sessions - only the instantiated tasks have to be considered for the purpose of determining the affected tasks.  In the case of target-scoped requests (i.e. TARGET WARM RESET and TARGET COLD RESET), all the commands that are not yet received on the issui= ng session in the command stream however can be considered to have been receiv= ed with no command waiting period - i.e. the entire CmdSN space up to the CmdSN of the task management function can be "plugged".
b. MUST propagate the TMF request to and receive the response from the target SCSI layer.
c. MUST leave all active "affected TTTs" (i.e. active TTTs associ= ated with affected tasks) valid along with any buffer allocations for the TTTs intact.
d. MUST generate an Asynchronous Message PDU with AsyncEvent=3D5 (section 8.1) on:
i) each connection of each third-party session that at least one affected task is allegiant to, and
ii) each connection except the issuing connection of the issuing session that has at least one allegiant affected task.
If there are multiple affected LUs (say due to a target reset), then one Async Message PDU MUST be sent for each such LU on each connection that has at least one allegiant affected task.
e. MUST address the Response Fence flag on the TMF Response on issuing session as defined in 3.3.2.
f. MUST address the Response Fence flag on the first post-TMF Response on third-party sessions as defined in 3.3.2. If some tasks originate from non-iSCSI I=5FT=5FL nexuses then the means by which the target ensures that all affected tasks have returned their status to the initiator are defined by the specific non-iSCSI transport protocol(s).
g. MUST free up the affected TTTs (and STags, if applicable) and the corres= ponding buffers once it receives the associated Nop-Out acknowledgement that the initiator generated in response to the Async Message.  
Implementation note: Technically, the TMF servicing is complete in Step.e.  Data transfers corresponding to terminated tasks may however still be in progress even at the end of Step.f.  TMF Response MUST NOT be sent by the target iSCSI layer before the end of Step.e, and MAY be sent at the end of Step.e despite these outstanding Data transfers until Step.g.  Step.g specifies an event to free up any such resources that may have been reserved to support outstanding data transfers.  
4.1.3.1 Clearing effects update
Appendix F.1 of [RFC3720] specifies the clearing effects of target and LU resets on “Incomplete TTTs” as “Y”.  This m= eant that a target warm reset or a target cold reset or an LU reset would clear the active TTTs upon completion.  The TaskReporting=3DFastAbort (section 9.1) sem= antics defined by this section however do not guarantee that the active TTTs are cleared by the end of the reset operations.  In fact, the new semantics are designed to allow clearing the TTTs in a “lazy” fashion aft= er the TMF Response is delivered.  Thus, when TaskReporting=3DFastAbort is operational on a session, the clearing effects of reset operations on ̶= 0;Incomplete TTTs” is “N”.  
4.1.4 Implementation considerations
Both in clarified semantics (section 4.1.2) and updated semantics (section 4.1.3), there may be outstanding data transfers even after the TMF completi= on is reported on the issuing session.  In the case of iSCSI/iSER [iSER], these would be tagged data transfers for STags not owned by any active tasks.  Whether or not real buffers support these data transfers is implementation-dependent.  However, the data transfers logically MUST be silently discarded by the target iSCSI layer in all cases.  A target MAY, on an implementation-defined internal timeout, also choose to drop the connections on which it did not receive the expected Data-out sequences (section 4.1.2) or Nop-Out acknowledgements (section 4.1.3) so as to reclaim the associated buffer, STag and TTT resources as appropriate.


----- Original Message ----
From: "Black=5FDavid@emc.com" <Black=5FDavid@emc.com>
To: Black=5FDavid@emc.com; cb=5Fmallikarjun@yahoo.com; ips@ietf.org
Sent: Wednesday, December 20, 2006 2:33:43 PM
Subject: RE: [Ips] Implementer's Guide - Task Management Issue


> Let's try this line of reasoning - the target issues the Nop-Out, now
when
> can it free the resources?  Answer:
>     - The Nop-In response comes back, OR
>     - The connection times out and is torn down.
> Now, what if the Nop-Out is not issued - what does the target wait for
to
> free the resources?  Answer:
>     - The transfers complete, OR
>     - The connection times out and is torn down.
> Those look similar enough at the target (the worst case is the same -
the
> resources are tied up until an uncooperative initiator times out) that
> I don't see the harm in allowing the early TMF return without the new
> key.  The clear distinction is that the first two bullets are
different;
> if the new key is not negotiated, the target has to wait for the
transfers
> to complete; the new key and the Nop-Out are necessary to walk away
earlier
> when the initiator involved is able to continue the transfers.

That got slightly twisted - what it should have talked about was the
target
issuing the new Async Message and the Nop-Out response coming back.

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=5Fdavid@emc.com        Mobile: +1 (978) 394-7754<= br> ----------------------------------------------------

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips
--=_alternative 003B1BD3C2257253_=-- --===============1254628310== 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 --===============1254628310==-- From and@GoVeganRadio.com Fri Dec 29 06:59:36 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0GOe-0002jb-86 for ips-archive@lists.ietf.org; Fri, 29 Dec 2006 06:59:36 -0500 Received: from [84.217.183.45] (helo=84-217-183-45.tn.glocalnet.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0GOc-0005oB-CP for ips-archive@lists.ietf.org; Fri, 29 Dec 2006 06:59:36 -0500 Received: from ebtihal-3w72dk6 ([197.184.179.139]) by 84-217-183-45.tn.glocalnet.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Dec 2006 13:00:02 +0100 Message-ID: <001301c72b40$d59dd320$2db7d954@ebtihal3w72dk6> From: "World" To: ips-archive@lists.ietf.org Subject: impossible Date: Fri, 29 Dec 2006 12:59:46 +0100 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000F_01C72B49.37623B20" 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: 2.9 (++) X-Scan-Signature: ccfb4541e989aa743998098cd315d0fd ------=_NextPart_000_000F_01C72B49.37623B20 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0010_01C72B49.37623B20" ------=_NextPart_001_0010_01C72B49.37623B20 Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: quoted-printable Muldoon married whom played his characters dying wife couple. Gnu license see copyrights details registered trademark. Statements births actors models. Graduated el camino high school. State page, court filing counting = additional supporting documents alleged! Old wheelchair, year woman suffered minor injuries, mild. White she = devil undercover brother, born february. Killed despite having shot previous. Announced continuing recently = sought. Wanted place firearms coffee. Lanier van, ryan, wild, things! She devil = undercover, brother born, february an american actress. Woman suffered minor injuries, mild bruising treated emergency. Gas = masks abnormal nicole simpsons. Sam who on march lola rose. Kickboxing dogson april it! Retrieved, wwwmcouk news halliwell september = may cinema cosmo. These received denied interview tonight, described = actions smear. Give children added only. Masks abnormal nicole simpsons visited addicted gambling drugs bought! Articlein other last modified all text available terms gnu. As james = bond had box office gross renown addition. Links linkcite articlein other last modified all. Wide theatrical release which followed by moderately successful. Despite having shot previous fiance preston he wanted. Sambora, separated heather sheenon, under. Characters dying wife couple have, daughters sam who. Have daughters sam = who on. Theatrical, release which followed by moderately successful, = cult. Agedowners grove illinois usaheight sheen ibanez in starship. Brain = damage desire purchase gas masks abnormal, nicole, simpsons. ------=_NextPart_001_0010_01C72B49.37623B20 Content-Type: text/html; charset="iso-8859-6" Content-Transfer-Encoding: quoted-printable
3D""
Muldoon married whom played his = characters dying=20 wife couple.
Gnu license see copyrights details = registered trademark.
Statements births actors = models.
Graduated el camino high school. State = page, court=20 filing counting additional supporting documents alleged!
Old wheelchair, year woman suffered = minor injuries,=20 mild. White she devil undercover brother, born february.
Killed despite having shot previous. = Announced=20 continuing recently sought.
Wanted place firearms coffee. Lanier = van, ryan,=20 wild, things! She devil undercover, brother born, february an american = actress.
Woman suffered minor injuries, mild = bruising=20 treated emergency. Gas masks abnormal nicole simpsons. Sam who on march = lola rose.
Kickboxing dogson april it! Retrieved, = wwwmcouk=20 news halliwell september may cinema cosmo. These received denied = interview=20 tonight, described actions smear.
Give children added only.
Masks abnormal nicole simpsons visited = addicted=20 gambling drugs bought!
Articlein other last modified all text = available=20 terms gnu. As james bond had box office gross renown = addition.
Links linkcite articlein other last = modified all.
Wide theatrical release which followed = by=20 moderately successful.
Despite having shot previous fiance = preston he wanted.
Sambora, separated heather sheenon, = under.
Characters dying wife couple have, = daughters sam=20 who. Have daughters sam who on. Theatrical, release which followed by = moderately=20 successful, cult.
Agedowners grove illinois usaheight = sheen ibanez in=20 starship. Brain damage desire purchase gas masks abnormal, nicole,=20 simpsons.
------=_NextPart_001_0010_01C72B49.37623B20-- ------=_NextPart_000_000F_01C72B49.37623B20 Content-Type: image/gif; name="James Bond.gif" Content-Transfer-Encoding: base64 Content-ID: <000e01c72b40$d59dd320$2db7d954@ebtihal3w72dk6> R0lGODlhEAKkAIfoAAAFAIEMAAiAAXeEAAAAjngCegBxd73FxMjSwprF7kktCFwqAIkkBKkZDMQn AOkVAAw3ABUyAjEyDFtFAHcxB5M/AM5DAO43AABqABNSCTpUBWljBY5qAKRTAMpmDtRSAAB+AB95 AEl5CF1+A3OLAJV+AMqKB9V5AACiABydAESiAGyqB4imAK2tDsSdAN2sAADKCCbACE6yA2yyAHjH AKnLDM22ANTOBQXrBivhAT/pCl3tAI3WCareAbjZANHRAAAAOx0AOUkANmICSIoAO5gATb0AM9YA RgAlRSMmO0sfOlwnMX4cNpspP7ccMukmPwxLTBc+SE44M181Q4IyPKM2M7k7Tek0TQBRQxdrMUBo NG5jNXJZC6ViNL5pOdRjTQmISCh+OUmMOWOMOXaOQqCCR7x9O9h/SQCpPxSYPkGnNlqiQIumTaSt R7usQ+KgOArOQx22PzW3SWm5So7CMZvJNsTEQ9u8OADrNi3rQ0jjNFbaPYzVNK7gOcvlSuriNwAA gBUAhD8AdWIHfoIAhZ4AeLIEe+EAjAohfSgWfUYRjm0Zi4YbiKAoeb8uet8ahABFjBZHejM9imo1 gXo1hp43esJFc942fwBhjCBig0NbgVxkjYhcfaFlf7ptgORlfwCIhxaHeU5xdmuDe4uEfKeOi8KJ hOqHcgenfBWtfEGVdVuhjHuah5qYjLmWhNWWeA61gCHNdjO3gm3Gi4jAc6TIf767jty9fAfVgxTY fT/bcWbuiIXSh5LSfczWde7qeQQAvCgAwjUFulcAxHIAwKUAw84Avt4AtgAgwR8TvzohzlctvowX wp8oxsYkutobswA9syY2wE1LzGM7woRAxZNHvLo/xOxBwQBYvB5avUxdslRhtXppyZFssrJmydlR wgJ6tyx5wDp9yl9/xHh1zal/u7OAxtOBtgaYwCCfyTmtyVWrwXaXvZaWsraauOaRvwS3sizGuTTA tGPEzoDMtpi+vvjz5Jqmp4qDhv8ADgD/APj6AAAI//8A/wD+//H3/yH5BAA/3noALAAAAAAQAqQA Bwj/AO0JHEiwoMGDCBMqXMiwocOHECNKnJjwn8WLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmyJUaK MGPKnEmzps2bOHPq3Mmzp8+fQB+6HEq0qNGjSJMqZRm0qdOnUKNKnUq1Ks+lWLNq3cq1q9evYMOK /Wq1rNmzaNOOXcu2bdu0cOPKnUu3rt27Qt3q3cu3r0m8gAMLHky4sOHDiBMrXsy4sePHkCNLnpzY r+XLmDNr3sy5s+fPoEOLHk26tOnTqFOrXk2Wsuu8rGPLnk27tm2+r3NXvs2792rdwIMLH67Qt/Hj yJNfJM68ufPn0IEqn069unXS0bNr384d7fXvHbuL/x9PvvxA8OjTq1/Pvr379/Djy59Pv779+1rN 69+PGL///0MBIOCAGAl4kYH/DAgASAoeqOCC1SGY4IMhSTghgBheR6FFEnYIoYUWeuRhgRCK+CCC IH5IIIcbfpTihC2ymNGJM6pIIoMlXpjhjqLNJOBAP9oTpEBB/jgkkQA4NOSRETF55JJJIkkQkwgV GSWVU0YJpJZPXqnlQ10iaaWCWZK55YNibqmkmUKemOaZahbE43QyYdlmlmJ+KWVDUMLk5Jd97tmk l4IaxOadhVopUZiCBoroo1gOGOdCgUbaJZd68qepn5km6mWndhoKKJpg6skopJ3yKWmhBR3qqKiH Jv90oqOM1grqqqFO2uqtY2K66a8xBRAAQsISVKw9CiSrgEELLOBQswkd25C0Ailr7bICUSvstsM+ lKyx3Ep7rLjhPgTtQtp2iyy2jyKaLqsCNSBvA/HSi666BZ1bELfZbjsQtefNWV+zFjVL8D/yYpTw Pw44wLDDGOWTj0gLb9TwSBJndHDBC1x0MUchelTxP8Jy9PHH/ySbsgIkodzRAw9gBPNFKlv07UA3 S0yQzvaEeyy0QDu7kLxVurnuut/e3DO+wDb9rNACnau00ufqaw/RDcGMM7tHO6R01FDboy/WB/E8 Lb52Nqy2A1tXy/W++AJ80NdKNzyQ3Xez3W6QVuf/LdDaDI3r79IHET0vvWSb7TR5LI1IcrgY1bwy iyFrJHHGNl9LUogjVzyzRZiDPrFIkj+8Uej/YF6yRatvRCNILqOMcuuPsx4ARqtXfrO1gcfdreJx Krr48BIdTjZgANONLeD1Hg4R3gLBLL3W9kBfvd7HH9/TkOS27fa/TPcLfvhzs3uz9vWmf7W9hBM/ nsC3WWs7t5FrftH00lsku8smNvg45Dq6kf4ghhT3GfCAC4GfAm+DwAbCZoEQdKAEJ0hBiUDwghjM oAY3yMEOevCDIAyhCItSwRKa8ISCGaEKV9gaFLrQgiyMoQxp88Ia2tBpM8zhR27Iwx4aRodADKIQ /4cYEh8a8YhITGIKiTgfJTpRJkzUyxOHE8UqsnCKWCyLFbfIRa9k8Ytg/GEXrRjGqozxjGhMoxrX yMY2upEzZYwjFN9IxzrasSRyzKNB7sjHPvrxjy3UYxgB2URBGvKQiEykIhd5Q0I6MoqM/OIjUxLJ SloShpPMpCZHeMlO2mOToLyiJ4MSygyN8pSo5IsABFASIAChlENxpSthiRlZypIlBCBASYABjFLm 8pcX4aUwe3mRXBZTlxaZJS0tY8xjrkSZI6kcfggTKF4OxJoCwSY2swkMVDbGTrkUSDjF+UsC2OOX AynnOMmJzoG4Ek/eFFXR4MkPftijngVZZzwRY/8n4dlDlv985zvtIUxukjOd5hQIPnW1z4AiZKEK tWebqDTQhppxJa+jXI6ayVFkNvMfzXRcADMpzRfByHU5WiZmPuo/GekIRSWCqYOcuUmYBkmf44zV ORNqUaoUxUMW4qVFhPoPokJTmUQtKjFHOkmTfhSkyDRQiKSp0rWY1KUzfamNXCrSp1LVjoFa5zr9 qdOeBsZoDBVery51qnb11GhoRZVZz7KUr1ZVKXMNjFLsete8PmevKb2rYHvj16gMtjqFrcthWZPY HlbVKblqrGTPElm4GMxgkexL6dZCuyCWjnYj46teQqc6+nGMZvLTaEpFS0f+kQSAK7NfSEo2wcr/ Pk9vYCOI9uQ2F7PxbHADORfw2kfc4vZ0bdArF0Kmhq3hNqRuuMXbZfs2NPYtTbmXyy641MVbhFAX IsqFiNmQCz7xCUS75fXeefMBN6esRHI126zp5hux0aXOvppsaeZQG5KFdVYkoXPcvCwyso7oNyP/ ndx+VSbfpMCXZa+9nUY+Fl8IV5i/WcXqRRJcwJigdbj+DO50w3bJza0Iwwr+yOqQS0AVS9h2G5Zw 6zh8Ovzi7sUCPC3BNtbfBlgEfzErCY0xwuKNfC62EEaYjzVSOtShTsOXKfAANXIw1w45k8pC8IuH bFomJ9kjPH4wVlnL1ItIWclEdtjaSrIwtU2Z/yQN1ljHTpu51P7jsgobcIbRHGONnLnDMLEeQ7tG pVd9zay8EwgEIDCQRTeEAQwo36MjPRBIV5rSzH2IoL9nkEPbA9Kg/rSlG4K3TKvKtqaGHvRATemC jBomjr5LrAsy60ufaUiLzrWrWz1XS4/61a9WSLAHQgEKqIogv062rR0ybIEU+yC1prWuo40QDnBA INYeSLYhUtlZx/rbtX72sl9NrXAbe1dNWckqF9sSFKDgH+62yLrlzcqNzPsf88YABi6i75D0GyOr DHi99U3wfY/k3hdB+EUW3RGGOxwCIZl3vC0y8ZFUvCP//kfGc51rjGSc4u5+954R/vF/MJzdpf9x CA5WzvKBrNLlAhjIyst0JBjY3OalYgi1HaIPfRhk5zhHyMyHjoOGxDro9kB6Qtw9EKYvpOcC6bnP GaLvnTidlCgfy8QJEvKr22PmO9m5tCXC8VlbKiFVFwjBHeJ0pCsd7QVfU1kL4vWbiH2yzXm5Wd7+ c0ZT0LYS0bt7s/4dMrMb73chPGgQr0XFO/7xjmS85GsI+QxO/vKY5+GsHLLNmswqVZDpPBgrb+DA hgSaPzV9UgyPlJKqnvQ8kok+cx7RekoUUYB36K5WZZPc7wStc58j7K8jE1tWtGhlVSvo5ZmQgZJq orw3/q19FZS5i35Twy9i70H/qkkF/yC5GhP/PHFPfbf6vk68R3fmkUgUm8p0zC06sIsC+7qpxnSr AWS9UU5co+wv8CahUinl933M532EMn5r1X1RoVPnt35YpIAGuCfpd35/8iYVKIGp0oA5YSSmsnw6 4X/yESMaYVMOol+sFzL1t1oqgn8iBWVYIVUq2BcOGBxckVEmsnr0F38HdmL6lxI2aIOnMYOAcRk9 GCCvtxdFCIJ1lIQtwYQ1eIRKKDDc8XxCWIVWeIUIxEdY6Fh0tIVe+IVgiHVRmB4zKFhheIZoKCdj uIZsOBppiBdt6BJvOId0OEFxyBZ1SEF3uId82Id+SCd5GIiCOIiJ9IdEQYhSYYiKCEeI2IiLR7GI SeGIkkh5kFiJlghKk+g+l7iJbpGJQ8iJoBiKceiJpOgYolgbpegap7iKrNiKneiJrigSqTiLtFiL tniLuGhWh5eLkhEQADs= ------=_NextPart_000_000F_01C72B49.37623B20-- From ips-bounces@ietf.org Fri Dec 29 12:46:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0LoI-0005rB-Bq; Fri, 29 Dec 2006 12:46:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0LoG-0005qn-Rj for ips@ietf.org; Fri, 29 Dec 2006 12:46:24 -0500 Received: from mexforward.lss.emc.com ([128.222.32.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0LoF-000888-GM for ips@ietf.org; Fri, 29 Dec 2006 12:46:24 -0500 Received: from mailhub.lss.emc.com (uraeus.lss.emc.com [10.254.144.14]) by mexforward.lss.emc.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id kBTHkHic017385; Fri, 29 Dec 2006 12:46:21 -0500 (EST) Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id kBTHk2Zp013840; Fri, 29 Dec 2006 12:46:08 -0500 (EST) From: Black_David@emc.com Received: from CORPUSMX20A.corp.emc.com ([128.221.62.13]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Dec 2006 12:45:27 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ips] TMF text with updates Date: Fri, 29 Dec 2006 12:45:25 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ips] TMF text with updates Thread-Index: AccrOsSF/3b7UpotSLGCv6GdFJOAvAANYJhA To: X-OriginalArrivalTime: 29 Dec 2006 17:45:27.0013 (UTC) FILETIME=[1FEAD150:01C72B71] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2006.12.29.91433 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -2, HTML_NO_HTTP 0.1, NO_REAL_NAME 0, __C230066_P5 0, __CP_URI_IN_BODY 0, __CT 0, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0, __CTYPE_MULTIPART_ALT 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_HTML 0, __MIME_VERSION 0, __SANE_MSGID 0, __TAG_EXISTS_HTML 0' X-Spam-Score: 0.5 (/) X-Scan-Signature: 0a4dc93b42adee132ac30a98ee294788 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="===============1092556902==" Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============1092556902== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C72B71.1F4788DB" This is a multi-part message in MIME format. ------_=_NextPart_001_01C72B71.1F4788DB Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Julian, =20 I'm not sure I completely understand what you wrote, but if you're suggesting that for a TMF that affects tasks from multiple initiators: - Fast abort (early termination of data transfers) is used for the sending initiator. - The existing 3270 abort mechanism is used with other initiators, with the update that the TMF response does not have to wait for data transfer completion. I think that suggestion is reasonable, and it actually helps with the use case that started this (3rd party initiator is dead). The draft text would need to change to allow this (right now it mandates fast abort in all cases if the key is negotiated to support it) =20 I'm not sure how target-scoped queues enter into this. =20 Thanks, --David ----------------------------------------------------=20 David L. Black, Senior Technologist=20 EMC Corporation, 176 South St., Hopkinton, MA 01748=20 +1 (508) 293-7953 FAX: +1 (508) 293-7786=20 black_david@emc.com Mobile: +1 (978) 394-7754=20 ----------------------------------------------------=20 ________________________________ From: Julian Satran [mailto:Julian_Satran@il.ibm.com]=20 Sent: Friday, December 29, 2006 6:16 AM To: Black, David Cc: cb_mallikarjun@yahoo.com; ips@ietf.org Subject: RE: [Ips] TMF text with updates =09 =09 David,=20 =09 My point was that we can solve the TM issue only for a single initiator. So besides puting the burden on SCSI to cleanly finish other and advise that fast solutions really work if there are no target scoped queues there is little we can do. And if we limit ourselves to a single initiator the multiple TM solution is a simpler (and basically does not deviate from 3270). If you consider how software stacks are layered I assume that some clever implementers have figured that already (and did it).=20 =09 Regards,=20 Julo=20 =09 =09 =09 Black_David@emc.com=20 28/12/06 21:54=20 To Julian Satran/Haifa/IBM@IBMIL, =20 cc =20 Subject RE: [Ips] TMF text with updates =09 I agree with Julian that we should avoid discussing "buffer allocations" and=20 the like, even though we know that something like that has to happen in at=20 least iSER implementations. A general discussion of "resources" works.=20 =20 > You could achive the same effect by issuing the TM command on every affected connection.=20 =20 Not for TMF's that affect commands from other initiators. Also, asking the=20 target to coordinate receipt of the TM command on every connection in a=20 multi-connection session is also a bit much.=20 =20 > The third party story is even more puzzling as in order to negotiate any of=20 > the new TM modes the taget will have to ascertain that all other initiators=20 > support it. I fail to understand how would you handle downgrading the mode=20 > for those that don't.=20 =20 I think the target has to track this initiator by initiator, and not issue the=20 new async message to old initiators. This increases the importance of being=20 able to complete a TMF in the face of an uncooperative third party "Legacy"=20 initiator.=20 =20 > And if you don't downgrade why not state that fast-abort and target scoped=20 > queues don't go together and simplify the mechanics to a multiple issue TM.=20 This didn't parse for me - could you explain in more detail?=20 =20 Thanks,=20 --David=20 ----------------------------------------------------=20 David L. Black, Senior Technologist=20 EMC Corporation, 176 South St., Hopkinton, MA 01748=20 +1 (508) 293-7953 FAX: +1 (508) 293-7786=20 black_david@emc.com Mobile: +1 (978) 394-7754=20 ----------------------------------------------------=20 =09 =09 ________________________________ From: Julian Satran [mailto:Julian_Satran@il.ibm.com]=20 Sent: Thursday, December 28, 2006 5:32 AM To: Mallikarjun C. Cc: ips@ietf.org Subject: Re: [Ips] TMF text with updates =09 =09 Mallikarjun,=20 =09 I would consider the text:=20 =09 c. MUST leave all active "affected TTTs" (i.e. active TTTs associated with affected tasks) valid along with any buffer allocations for the TTTs intact.=20 =09 somewhat excessive as it relates too much to implementation. I would rather say:=20 =09 c. MUST leave all active "affected TTTs" (i.e. active TTTs associated with affected tasks) valid.=20 =09 and leave the buffer issue to the implementer (as I have stated already on this list).=20 =09 I also keep thinking (and mildly objecting to) that the whole fast abort is excesively complex.=20 =09 You could achive the same effect by issuing the TM command on every affected connection.=20 The third party story is even more puzzling as in order to negotiate any of the nem TM modes the taget will have to ascertain that all other initiators support it. I fail to understand how would you handle downgrading the mode for those that don't. And if you don't downgrade why not state that fast-abort and target scoped queues don't go together and simplify the mechanics to a multiple issue TM.=20 =09 Thanks,=20 Julo=20 =09 =09 "Mallikarjun C." =20 28/12/06 06:41=20 To ips@ietf.org=20 cc Subject [Ips] TMF text with updates =09 =09 =09 =09 Attached is the latest text that incorporates David's proposed enhancement. Please review and comment. Note especially two things: new section 4.1.4 that summarizes generic implementation considerations for both "clarified" and "updated" semantics, the changed text in 4.1.2 that says "MAY wait for ....target transfer tags.....from third-party initiators" from the previous blanket MUST. =09 Mallikarjun =09 =09 =09 4.1.2 Clarified multi-task abort semantics All iSCSI implementations MUST support the protocol behavior defined in this section as the default behavior. The execution of ABORT TASK SET, CLEAR TASK SET, LOGICAL UNIT RESET, TARGET WARM RESET, and TARGET COLD RESET TMF Requests consists of the following sequence of actions in the specified order on the specified party.=20 The initiator iSCSI layer: a. MUST continue to respond to each TTT received for the affected tasks.=20 b. Should receive any responses that the target may provide for some tasks among the affected tasks (may process them as usual because they are guaranteed to have chronologically originated prior to the TMF response).=20 c. Should receive the TMF Response concluding all the tasks in the set of affected tasks.=20 =09 The target iSCSI layer: a. MUST wait for currently valid target transfer tags of the affected tasks from the issuing initiator to be responded to. MAY wait for responses on currently valid target transfer tags of the affected tasks from third-party initiators. b. MUST wait (concurrent with the wait in Step.a) for all commands of the affected tasks to be received based on the CmdSN ordering. SHOULD NOT wait for new commands on third-party affected sessions - only the instantiated tasks have to be considered for the purpose of determining the affected tasks. In the case of target-scoped requests (i.e. TARGET WARM RESET and TARGET COLD RESET), all the commands that are not yet received on the issuing session in the command stream however can be considered to have been received with no command waiting period - i.e. the entire CmdSN space up to the CmdSN of the task management function can be "plugged". c. MUST propagate the TMF request to and receive the response from the target SCSI layer.=20 d. MUST address the Response Fence flag on the TMF Response on issuing session as defined in 3.3.2. e. MUST address the Response Fence flag on the first post-TMF Response on third-party sessions as defined in 3.3.2. If some tasks originate from non-iSCSI I_T_L nexuses then the means by which the target ensures that all affected tasks have returned their status to the initiator are defined by the specific non-iSCSI transport protocol(s). Implementation note: Technically, the TMF servicing is complete in Step.d. Data transfers corresponding to terminated tasks may however still be in progress on third-party iSCSI sessiosn even at the end of Step.e. TMF Response MUST NOT be sent by the target iSCSI layer before the end of Step.d, and MAY be sent at the end of Step.d despite these outstanding Data transfers until after Step.e. =09 4.1.3 Updated multi-task abort semantics Protocol behavior defined in this section MUST be implemented by all iSCSI implementations complying with this document. Protocol behavior defined in this section MUST be exhibited by iSCSI implementations on an iSCSI session when they negotiate the TaskReporting (section 9.1) key to "FastAbort" on that session. The execution of ABORT TASK SET, CLEAR TASK SET, LOGICAL UNIT RESET, TARGET WARM RESET, and TARGET COLD RESET TMF Requests consists of the following sequence of actions in the specified order on the specified party.=20 The initiator iSCSI layer: a. MUST NOT send any more Data-Out PDUs for affected tasks on the issuing connection of the issuing iSCSI session once the TMF is sent to the target. b. Should receive any responses that the target may provide for some tasks among the affected tasks (may process them as usual because they are guaranteed to have chronologically originated prior to the TMF response). c. MUST respond to Async Message PDU with AsyncEvent=3D5 as defined in section 8.1. d. Should receive the TMF Response concluding all the tasks in the set of affected tasks. =09 The target iSCSI layer: a. MUST wait for all commands of the affected tasks to be received based on the CmdSN ordering on the issuing session. SHOULD NOT wait for new commands on third-party affected sessions - only the instantiated tasks have to be considered for the purpose of determining the affected tasks. In the case of target-scoped requests (i.e. TARGET WARM RESET and TARGET COLD RESET), all the commands that are not yet received on the issuing session in the command stream however can be considered to have been received with no command waiting period - i.e. the entire CmdSN space up to the CmdSN of the task management function can be "plugged". b. MUST propagate the TMF request to and receive the response from the target SCSI layer.=20 c. MUST leave all active "affected TTTs" (i.e. active TTTs associated with affected tasks) valid along with any buffer allocations for the TTTs intact. d. MUST generate an Asynchronous Message PDU with AsyncEvent=3D5 (section 8.1) on: i) each connection of each third-party session that at least one affected task is allegiant to, and ii) each connection except the issuing connection of the issuing session that has at least one allegiant affected task. If there are multiple affected LUs (say due to a target reset), then one Async Message PDU MUST be sent for each such LU on each connection that has at least one allegiant affected task. e. MUST address the Response Fence flag on the TMF Response on issuing session as defined in 3.3.2. f. MUST address the Response Fence flag on the first post-TMF Response on third-party sessions as defined in 3.3.2. If some tasks originate from non-iSCSI I_T_L nexuses then the means by which the target ensures that all affected tasks have returned their status to the initiator are defined by the specific non-iSCSI transport protocol(s). g. MUST free up the affected TTTs (and STags, if applicable) and the corresponding buffers once it receives the associated Nop-Out acknowledgement that the initiator generated in response to the Async Message. =20 Implementation note: Technically, the TMF servicing is complete in Step.e. Data transfers corresponding to terminated tasks may however still be in progress even at the end of Step.f. TMF Response MUST NOT be sent by the target iSCSI layer before the end of Step.e, and MAY be sent at the end of Step.e despite these outstanding Data transfers until Step.g. Step.g specifies an event to free up any such resources that may have been reserved to support outstanding data transfers. =20 4.1.3.1 Clearing effects update Appendix F.1 of [RFC3720] specifies the clearing effects of target and LU resets on "Incomplete TTTs" as "Y". This meant that a target warm reset or a target cold reset or an LU reset would clear the active TTTs upon completion. The TaskReporting=3DFastAbort (section = 9.1) semantics defined by this section however do not guarantee that the active TTTs are cleared by the end of the reset operations. In fact, the new semantics are designed to allow clearing the TTTs in a "lazy" fashion after the TMF Response is delivered. Thus, when TaskReporting=3DFastAbort is operational on a session, the clearing effects of reset operations on "Incomplete TTTs" is "N". =20 4.1.4 Implementation considerations Both in clarified semantics (section 4.1.2) and updated semantics (section 4.1.3), there may be outstanding data transfers even after the TMF completion is reported on the issuing session. In the case of iSCSI/iSER [iSER], these would be tagged data transfers for STags not owned by any active tasks. Whether or not real buffers support these data transfers is implementation-dependent. However, the data transfers logically MUST be silently discarded by the target iSCSI layer in all cases. A target MAY, on an implementation-defined internal timeout, also choose to drop the connections on which it did not receive the expected Data-out sequences (section 4.1.2) or Nop-Out acknowledgements (section 4.1.3) so as to reclaim the associated buffer, STag and TTT resources as appropriate. =09 =09 ----- Original Message ---- From: "Black_David@emc.com" To: Black_David@emc.com; cb_mallikarjun@yahoo.com; ips@ietf.org Sent: Wednesday, December 20, 2006 2:33:43 PM Subject: RE: [Ips] Implementer's Guide - Task Management Issue =09 =09 > Let's try this line of reasoning - the target issues the Nop-Out, now when > can it free the resources? Answer: > - The Nop-In response comes back, OR > - The connection times out and is torn down. > Now, what if the Nop-Out is not issued - what does the target wait for to > free the resources? Answer: > - The transfers complete, OR > - The connection times out and is torn down.=20 > Those look similar enough at the target (the worst case is the same - the > resources are tied up until an uncooperative initiator times out) that > I don't see the harm in allowing the early TMF return without the new > key. The clear distinction is that the first two bullets are different; > if the new key is not negotiated, the target has to wait for the transfers > to complete; the new key and the Nop-Out are necessary to walk away earlier > when the initiator involved is able to continue the transfers. =09 That got slightly twisted - what it should have talked about was the target issuing the new Async Message and the Nop-Out response coming back. =09 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 ---------------------------------------------------- =09 __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around=20 http://mail.yahoo.com=20 =09 _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips =09 =09 ------_=_NextPart_001_01C72B71.1F4788DB Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Julian,
 
I'm not sure I completely understand what you = wrote,=20 but if you're
suggesting that for a TMF that = affects tasks=20 from multiple initiators:
- Fast abort (early termination of data = transfers) is=20 used for the sending
    = initiator.
- The existing 3270 abort mechanism is used = with other=20 initiators, with
    the = update that the = TMF response=20 does not have to wait for data transfer
    = completion.
I think that suggestion is reasonable, and it = actually=20 helps with the use
case that started this (3rd party initiator = is=20 dead).  The draft text would
need to change to allow this (right = now it=20 mandates fast abort in all cases
if the key is negotiated to support=20 it)
 
I'm not sure how target-scoped queues enter = into=20 this.
 
Thanks,
--David
----------------------------------------------------=20
David L. = Black, Senior=20 Technologist
EMC Corporation, 176 South St., Hopkinton, MA  = 01748=20
+1 (508)=20 293-7953           = ; =20 FAX: +1 (508) 293-7786
black_david@emc.com        = Mobile: +1=20 (978) 394-7754
----------------------------------------------------=20

From: Julian Satran=20 [mailto:Julian_Satran@il.ibm.com]
Sent: Friday, December = 29, 2006=20 6:16 AM
To: Black, David
Cc: = cb_mallikarjun@yahoo.com;=20 ips@ietf.org
Subject: RE: [Ips] TMF text with=20 updates


David, =

My point was that we can solve the TM issue = only for a=20 single initiator. So besides puting the burden on SCSI to cleanly = finish other=20 and advise that fast solutions really work if there are no target = scoped=20 queues there is little we can do. And if we limit ourselves to a = single=20 initiator the multiple TM solution is a simpler (and basically does = not=20 deviate from 3270).  If you consider how software stacks are = layered I=20 assume that some clever implementers have figured that already (and = did=20 it).

Regards, =
Julo


Black_David@emc.com=20

28/12/06 21:54

To
Julian = Satran/Haifa/IBM@IBMIL,=20 <cb_mallikarjun@yahoo.com>=20
cc
<ips@ietf.org>=20
Subject
RE: [Ips] TMF text with = updates

=




I agree with Julian that we should avoid = discussing=20 "buffer allocations" and
the like,=20 even though we know that something like that has to happen in = at=20
least iSER implementations. =  A=20 general discussion of "resources" works.
 =20
> You could achive the same = effect by=20 issuing the TM command on every affected connection.
 
Not for = TMF's that=20 affect commands from other initiators.  Also, asking the =
target to coordinate receipt of the TM = command on=20 every connection in a
multi-connection session is also a bit much.
 
> = The third party=20 story is even more puzzling as in order to negotiate any of =
> the new TM modes the taget will = have to=20 ascertain that all other initiators
> support it. I fail to understand how would you handle = downgrading=20 the mode
> for those = that=20 don't.
 
I think the target has to track this initiator by initiator, = and not=20 issue the
new async = message to old=20 initiators.  This increases the importance of being =
able to complete a TMF in the face of an = uncooperative third party "Legacy"
initiator.
 
> And if you don't downgrade why not = state that=20 fast-abort and target scoped
>=20 queues don't go together and simplify the mechanics to a multiple = issue=20 TM.
This didn't parse for me - could you = explain in more=20 detail?
 
Thanks,
--David=20

----------------------------------------------------
David L. = Black, Senior=20 Technologist
EMC Corporation, 176 South St., Hopkinton, MA=20  01748
+1=20 (508) 293-7953             FAX: +1 (508) = 293-7786
black_david@emc.com        Mobile: +1 = (978)=20 394-7754
----------------------------------------------------<= FONT=20 size=3D3>


From: Julian Satran=20 [mailto:Julian_Satran@il.ibm.com]
Sent: Thursday, December = 28, 2006=20 5:32 AM
To: Mallikarjun C.
Cc:=20 ips@ietf.org
Subject: Re: [Ips] TMF text with = updates


Mallikarjun,

I would consider the text: =

c. MUST leave all active "affected TTTs" (i.e. active = TTTs=20 associated with affected tasks) valid along with any buffer = allocations for=20 the TTTs intact.

somewhat excessive as it relates too much to = implementation. I=20 would rather say:

c. MUST=20 leave all active "affected TTTs" (i.e. active TTTs associated with = affected=20 tasks) valid.

and=20 leave the buffer issue to the implementer (as I have stated already on = this=20 list).

I = also keep=20 thinking (and mildly  objecting to) that the whole fast abort is=20 excesively complex.

You could achive the same effect by issuing the TM = command on every=20 affected connection.
The=20 third party story is even more puzzling as in order to negotiate any = of the=20 nem TM modes the taget will have to ascertain that all other = initiators=20 support it. I fail to understand how would you handle downgrading the = mode for=20 those that don't. And if you don't downgrade why not state that = fast-abort and=20 target scoped queues don't go together and simplify the mechanics to a = multiple issue TM.

Thanks,
Julo

"Mallikarjun = C."=20 <cb_mallikarjun@yahoo.com>

28/12/06 06:41=20


To
ips@ietf.org
cc
Subject
[Ips] TMF text with=20 updates







Attached is the latest = text that=20 incorporates David's proposed enhancement.  Please review and = comment.=20  Note especially two things: new section 4.1.4 that summarizes = generic=20 implementation considerations for both "clarified" and "updated" = semantics,=20 the changed text in 4.1.2 that says "MAY wait for ....target transfer=20 tags.....from third-party initiators" from the previous blanket=20 MUST.

Mallikarjun



4.1.2 Clarified multi-task = abort=20 semantics
All iSCSI implementations MUST support the protocol = behavior=20 defined in this section as the default behavior.  The execution = of ABORT=20 TASK SET, CLEAR TASK SET, LOGICAL UNIT RESET, TARGET WARM RESET, and = TARGET=20 COLD RESET TMF Requests consists of the following sequence of actions = in the=20 specified order on the specified party.
The initiator iSCSI = layer:
a.=20 MUST continue to respond to each TTT received for the affected tasks. =
b.=20 Should receive any responses that the target may provide for some = tasks among=20 the affected tasks (may process them as usual because they are = guaranteed to=20 have chronologically originated prior to the TMF response).
c. = Should=20 receive the TMF Response concluding all the tasks in the set of = affected=20 tasks.

The target iSCSI layer:
a. MUST wait for currently = valid=20 target transfer tags of the affected tasks from the issuing initiator = to be=20 responded to.  MAY wait for responses on currently valid target = transfer=20 tags of the affected tasks from third-party initiators.
b. MUST = wait=20 (concurrent with the wait in Step.a) for all commands of the affected = tasks to=20 be received based on the CmdSN ordering.   SHOULD NOT wait for = new=20 commands on third-party affected sessions - only the instantiated = tasks have=20 to be considered for the purpose of determining the affected tasks. =  In=20 the case of target-scoped requests (i.e. TARGET WARM RESET and TARGET = COLD=20 RESET), all the commands that are not yet received on the issuing = session in=20 the command stream however can be considered to have been received = with no=20 command waiting period - i.e. the entire CmdSN space up to the CmdSN = of the=20 task management function can be "plugged".
c. MUST propagate the = TMF=20 request to and receive the response from the target SCSI layer.
d. = MUST=20 address the Response Fence flag on the TMF Response on issuing session = as=20 defined in 3.3.2.
e. MUST address the Response Fence flag on the = first=20 post-TMF Response on third-party sessions as defined in 3.3.2. =  If some=20 tasks originate from non-iSCSI I_T_L nexuses then the means by which = the=20 target ensures that all affected tasks have returned their status to = the=20 initiator are defined by the specific non-iSCSI transport=20 protocol(s).
Implementation note: Technically, the TMF servicing is = complete in Step.d.  Data transfers corresponding to terminated = tasks may=20 however still be in progress on third-party iSCSI sessiosn even at the = end of=20 Step.e.  TMF Response MUST NOT be sent by the target iSCSI layer = before=20 the end of Step.d, and MAY be sent at the end of Step.d despite these=20 outstanding Data transfers until after Step.e.

4.1.3 Updated = multi-task=20 abort semantics
Protocol behavior defined in this section MUST be=20 implemented by all iSCSI implementations complying with this document. =  Protocol behavior defined in this section MUST be exhibited by = iSCSI=20 implementations on an iSCSI session when they negotiate the = TaskReporting=20 (section 9.1) key to “FastAbort” on that session. =  The execution of ABORT=20 TASK SET, CLEAR TASK SET, LOGICAL UNIT RESET, TARGET WARM RESET, and = TARGET=20 COLD RESET TMF Requests consists of the following sequence of actions = in the=20 specified order on the specified party.
The initiator iSCSI = layer:
a.=20 MUST NOT send any more Data-Out PDUs for affected tasks on the issuing = connection of the issuing iSCSI session once the TMF is sent to the=20 target.
b. Should receive any responses that the target may provide = for=20 some tasks among the affected tasks (may process them as usual because = they=20 are guaranteed to have chronologically originated prior to the TMF=20 response).
c. MUST respond to Async Message PDU with AsyncEvent=3D5 = as=20 defined in section 8.1.
d. Should receive the TMF Response = concluding all=20 the tasks in the set of affected tasks.

The target iSCSI = layer:
a.=20 MUST wait for all commands of the affected tasks to be received based = on the=20 CmdSN ordering on the issuing session.  SHOULD NOT wait for new = commands=20 on third-party affected sessions - only the instantiated tasks have to = be=20 considered for the purpose of determining the affected tasks.  In = the=20 case of target-scoped requests (i.e. TARGET WARM RESET and TARGET COLD = RESET),=20 all the commands that are not yet received on the issuing session in = the=20 command stream however can be considered to have been received with no = command=20 waiting period - i.e. the entire CmdSN space up to the CmdSN of the = task=20 management function can be "plugged".
b. MUST propagate the TMF = request to=20 and receive the response from the target SCSI layer.
c. MUST leave = all=20 active "affected TTTs" (i.e. active TTTs associated with affected = tasks) valid=20 along with any buffer allocations for the TTTs intact.
d. MUST = generate an=20 Asynchronous Message PDU with AsyncEvent=3D5 (section 8.1) on:
i) = each=20 connection of each third-party session that at least one affected task = is=20 allegiant to, and
ii) each connection except the issuing connection = of the=20 issuing session that has at least one allegiant affected task.
If = there are=20 multiple affected LUs (say due to a target reset), then one Async = Message PDU=20 MUST be sent for each such LU on each connection that has at least one = allegiant affected task.
e. MUST address the Response Fence flag on = the TMF=20 Response on issuing session as defined in 3.3.2.
f. MUST address = the=20 Response Fence flag on the first post-TMF Response on third-party = sessions as=20 defined in 3.3.2. If some tasks originate from non-iSCSI I_T_L nexuses = then=20 the means by which the target ensures that all affected tasks have = returned=20 their status to the initiator are defined by the specific non-iSCSI = transport=20 protocol(s).
g. MUST free up the affected TTTs (and STags, if = applicable)=20 and the corresponding buffers once it receives the associated Nop-Out=20 acknowledgement that the initiator generated in response to the Async = Message.=20  
Implementation note: Technically, the TMF servicing is = complete in=20 Step.e.  Data transfers corresponding to terminated tasks may = however=20 still be in progress even at the end of Step.f.  TMF Response = MUST NOT be=20 sent by the target iSCSI layer before the end of Step.e, and MAY be = sent at=20 the end of Step.e despite these outstanding Data transfers until = Step.g.=20  Step.g specifies an event to free up any such resources that may = have=20 been reserved to support outstanding data transfers.  
4.1.3.1 = Clearing effects update
Appendix F.1 of [RFC3720] specifies the = clearing=20 effects of target and LU resets on “Incomplete TTTs” as = “Y”.  This meant=20 that a target warm reset or a target cold reset or an LU reset would = clear the=20 active TTTs upon completion.  The TaskReporting=3DFastAbort = (section 9.1)=20 semantics defined by this section however do not guarantee that the = active=20 TTTs are cleared by the end of the reset operations.  In fact, = the new=20 semantics are designed to allow clearing the TTTs in a = “lazy” fashion after=20 the TMF Response is delivered.  Thus, when = TaskReporting=3DFastAbort is=20 operational on a session, the clearing effects of reset operations on=20 “Incomplete TTTs” is “N”.  
4.1.4 = Implementation=20 considerations
Both in clarified semantics (section 4.1.2) and = updated=20 semantics (section 4.1.3), there may be outstanding data transfers = even after=20 the TMF completion is reported on the issuing session.  In the = case of=20 iSCSI/iSER [iSER], these would be tagged data transfers for STags not = owned by=20 any active tasks.  Whether or not real buffers support these data = transfers is implementation-dependent.  However, the data = transfers=20 logically MUST be silently discarded by the target iSCSI layer in all = cases.=20  A target MAY, on an implementation-defined internal timeout, = also choose=20 to drop the connections on which it did not receive the expected = Data-out=20 sequences (section 4.1.2) or Nop-Out acknowledgements (section 4.1.3) = so as to=20 reclaim the associated buffer, STag and TTT resources as=20 appropriate.


----- Original Message ----
From:=20 "Black_David@emc.com" <Black_David@emc.com>
To: = Black_David@emc.com;=20 cb_mallikarjun@yahoo.com; ips@ietf.org
Sent: Wednesday, December = 20, 2006=20 2:33:43 PM
Subject: RE: [Ips] Implementer's Guide - Task Management = Issue


> Let's try this line of reasoning - the target = issues the=20 Nop-Out, now
when
> can it free the resources? =  Answer:
>=20     - The Nop-In response comes back, OR
>   =   - The=20 connection times out and is torn down.
> Now, what if the = Nop-Out is not=20 issued - what does the target wait for
to
> free the = resources?=20  Answer:
>     - The transfers complete, = OR
>=20     - The connection times out and is torn down.
> = Those look=20 similar enough at the target (the worst case is the same = -
the
>=20 resources are tied up until an uncooperative initiator times out) = that
>=20 I don't see the harm in allowing the early TMF return without the = new
>=20 key.  The clear distinction is that the first two bullets=20 are
different;
> if the new key is not negotiated, the target = has to=20 wait for the
transfers
> to complete; the new key and the = Nop-Out are=20 necessary to walk away
earlier
> when the initiator involved = is able=20 to continue the transfers.

That got slightly twisted - what it = should=20 have talked about was the
target
issuing the new Async Message = and the=20 Nop-Out response coming=20 = back.

Thanks,
--David
--------------------------------------= --------------
David=20 L. Black, Senior Technologist
EMC Corporation, 176 South St., = Hopkinton, MA=20  01748
+1 (508) 293-7953           =  =20 FAX: +1 (508) 293-7786
black_david@emc.com      =20  Mobile: +1 (978)=20 = 394-7754
----------------------------------------------------

_= _________________________________________________
Do=20 You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam = protection=20 around
http://mail.yahoo.com=20

_______________________________________________
Ips mailing = = list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips=

------_=_NextPart_001_01C72B71.1F4788DB-- --===============1092556902== 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 --===============1092556902==-- From ips-bounces@ietf.org Fri Dec 29 16:11:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0P0i-0002yy-4l; Fri, 29 Dec 2006 16:11:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0P0h-0002yo-2t for ips@ietf.org; Fri, 29 Dec 2006 16:11:27 -0500 Received: from web51912.mail.yahoo.com ([206.190.48.75]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H0P0f-00042D-Ap for ips@ietf.org; Fri, 29 Dec 2006 16:11:27 -0500 Received: (qmail 64486 invoked by uid 60001); 29 Dec 2006 21:11:25 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type; b=L4Ph+1pmcTQxFdCOidI4oBWQE40p3/Jjndv6bFlrYN7NQArkL5F4LZ3MwDQS/S+ULRJSxk+ZS4fx8yrci9ARN31oua2Zdly4To7pRkcyIU18Hzd7kd/uWjMRXuhyDY8XuhvOH0+2aXQMtTuO+M2EppZLrDDqeXS3kqbpPT3tcUA= ; Message-ID: <20061229211125.64484.qmail@web51912.mail.yahoo.com> Received: from [15.246.143.45] by web51912.mail.yahoo.com via HTTP; Fri, 29 Dec 2006 13:11:25 PST Date: Fri, 29 Dec 2006 13:11:25 -0800 (PST) From: "Mallikarjun C." Subject: Re: [Ips] IG clarifications: Login Response & Reject reason codes To: IPS MIME-Version: 1.0 X-Spam-Score: 0.3 (/) X-Scan-Signature: bacfc6c7290e34d410f9bc22b825ce96 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="===============1480426639==" Errors-To: ips-bounces@ietf.org --===============1480426639== Content-Type: multipart/alternative; boundary="0-910909572-1167426685=:72070" --0-910909572-1167426685=:72070 Content-Type: text/plain; charset=ascii Content-Transfer-Encoding: quoted-printable Julian, =0A=0AAs I read through relevant sections of 3720, I see the follo= wing in section 5.3:=0A=0AThe Login Phase is only implemented via Login Req= uest and Responses.=0AThe whole Login Phase is considered as a single task = and has a single=0AInitiator Task Tag (similar to the linked SCSI commands)= .=0A=0ASection 10.10.3 makes a similar point about text requests/responses.= =0A=0AI do not thus believe that the current text allows the flexibility = to pipeline multiple outstanding Login/Text Requests/Responses. That of co= urse means that I guess I am reaching the opposite conclusion than the one = I started with - the clarification the anonymous reviewer had wanted me to = put in wrt Login Response is not necessary. =0A=0AIf OTOH you believe we n= eed to explicitly allow pipelining overriding this 3720 text, please let me= know.=0A=0AThanks.=0A=0AMallikarjun=0A=0A=0A----- Original Message ----=0A= From: Julian Satran =0ATo: Mallikarjun C. =0ACc: IPS =0ASent: Friday, December 29, 2= 006 3:15:41 AM=0ASubject: Re: [Ips] IG clarifications: Login Response & Rej= ect reason codes=0A=0A=0A=0AMallikarjun,=0A=0A=0A=0AIf we allow for multipl= e outstanding=0ALogin Requests we will have to allow for multiple outstandi= ng Login Responses.=0A=0A=0A=0ARegards,=0A=0AJulo=0A=0A=0A=0A=0A=0A=0A=0A= =0A=0A=0A=0A=0A"Mallikarjun C."=0A =0A28/12/06 21= :45=0A=0A=0A=0A=0A=0ATo=0A=0AJulian Satran/Haifa/IBM@IBMIL=0A=0A=0Acc=0A=0A= IPS =0A=0A=0ASubject=0A=0ARe: [Ips] IG clarifications: Login = Response=0A& Reject reason codes=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A= =0A=0AJulian,=0A=0A =0A=0AThanks for the inputs, I somehow overlooked=0Ato = respond to this email earlier.=0A=0A=0A=0AI agree with you on the "Task in = progress" Reject reason code.=0A There is no =0A=0A =0A=0AUnless I hear new= objections, I would like=0Ato note "Negotiation Reset" Reject reason code = as obsolete. Based=0Aon the silence so far, like you, I do not believe it = is in use.=0A=0A =0A=0AOn the "no more than one outstanding=0ALogin Respons= e" semantics, your comments seem to be around Login Request=0APDU (and I be= lieve we have such text for Login Request PDU) - do you see=0Aany cases whe= rein there can be multiple outstanding Login Responses on=0Athe wire? The = request I got was to clarify if there is a plausible=0Ause case. =0A=0A = =0A=0AThanks!=0A=0A =0A=0AMallikarjun=0A=0A----- Original Message ----=0A= =0AFrom: Julian Satran =0A=0ATo: Mallikarjun C. <= cb_mallikarjun@yahoo.com>=0A=0ACc: IPS =0A=0ASent: Monday, De= cember 11, 2006 1:34:41 PM=0A=0ASubject: Re: [Ips] IG clarifications: Login= Response & Reject reason=0Acodes=0A=0A=0A=0A=0A=0A=0A=0A"Mallikarjun C." <= cb_mallikarjun@yahoo.com> wrote on 11/12/2006=0A20:15:23:=0A=0A=0A=0A> All:= =0A=0A> =0A=0A> I received some offline feedback on the implementers' guide= draft=0A=0A=0A> from a few reviewers who preferred to be anonymous. Plea= se=0Areview & comment.=0A=0A> =0A=0A> 1) RFC 3720 does not explicitly call = out that there cannot be more=0A=0A=0A> than one outstanding Login-Response= PDU on one iSCSI connection at=0A=0A=0A> any given time (although the C-bi= t text indirectly implies it).=0A=0A> =0A=0A> =0A=0A=0A=0AThis is intention= al. At the time we where playing with the idea of pipelining=0Athe login. = =0A=0AHowever it is common practice to have a single outstanding Login Requ= est.=0A=0A=0AI think that the only thing that becomes problematic is the ph= ase change=0Arequest (there you can have only one outstanding).=0A=0A=0AThe= re is already text that says that all changes to key values become final=0A= only at the end (when consistency can be reasonably checked).=0A=0A=0A=0A= =0A> Section 10.10 on Text Request PDU (which should cover Login Request=0A= =0A=0A> PDU semantics as well) says: "An initiator MUST have at most=0Aone = =0A=0A> outstanding Text Request on a connection at any given time."=0A =0A= =0A> Essentially, an analog for Login/Text Response is missing (or so it=0A= seems).=0A=0A> =0A=0A> 2) RFC 3720 does not specify the use case for Reject= reason code =0A=0A> "Task in progress" (0x07).=0A=0A> =0A=0A> I vaguely re= call we put in this reason code for task reassignment=0A=0A=0A> attempts wh= ile a task is in progress, but then we subsequently added=0A=0A> a TMF resp= onse reason code for that case (Julian?). So I'm not=0Asure=0A=0A> if reas= on code 0x07 is used by implementations any longer. =0A=0A> =0A=0A=0A=0ATh= e reject can used when the initiator attempts to start a new task but=0Aa t= ask with the same ITT is still active for those cases when the target=0Acan= 't be sure this is a protocol error (e.g., a race between a logout and=0Aa = reissued SCSI command). =0A=0A=0A=0A> The other non-obvious case is that of= a "negotiation reset"=0AReject =0A=0A> reason code. What is this used for= by implementations, if at=0Aall? =0A=0A> If I don't hear any objections, = I will deprecate these two reason=0Acodes.=0A=0A> =0A=0A=0A=0AThe negotiati= ng can't be continued by one of the parties but the partial=0Aresults (e.g.= , previous stage) are OK and no renegotiation is deemed necessary.=0AI have= no clue if somebody uses it but I felt at the time that the purists=0Awill= object if I'd suggest restarting the login :-)=0A=0A=0A=0A=0A> Mallikarjun= =0A=0A> =0A=0A> =0A=0A> =0A=0A> __________________________________________= __________________________________________=0A=0A> Do you Yahoo!?=0A=0A> Eve= ryone is raving about the all-new Yahoo! Mail beta.=0A=0A> http://new.mail.= yahoo.com=0A=0A> =0A=0A> _______________________________________________=0A= =0A> Ips mailing list=0A=0A> Ips@ietf.org=0A=0A> https://www1.ietf.org/mail= man/listinfo/ips=0A=0A=0A=0A=0A=0A_________________________________________= _________=0A=0ADo You Yahoo!?=0A=0ATired of spam? Yahoo! Mail has the best = spam protection around =0A=0Ahttp://mail.yahoo.com =0A=0A=0A=0A=0A=0A=0A___= _______________________________________________=0ADo You Yahoo!?=0ATired of= spam? Yahoo! Mail has the best spam protection around =0Ahttp://mail.yaho= o.com --0-910909572-1167426685=:72070 Content-Type: text/html; charset=ascii Content-Transfer-Encoding: quoted-printable
Julian, 

As I read through relevant se= ctions of 3720, I see the following in section 5.3:

The Login Phase = is only implemented via Login Request and Responses.
The whole Login Pha= se is considered as a single task and has a single
Initiator Task Tag (s= imilar to the linked SCSI commands).

Section 10.10.3 makes a similar= point about text requests/responses. 

I do not thus believe t= hat the current text allows the flexibility to pipeline multiple outstandin= g Login/Text Requests/Responses.  That of course means that I guess I = am reaching the opposite conclusion than the one I started with - the clari= fication the anonymous reviewer had wanted me to put in wrt Login Response = is not necessary. 

If OTOH you believe we need to explicitly allow p= ipelining overriding this 3720 text, please let me know.

Thanks.
=
Mallikarjun


----- Original Message ----
From: Jul= ian Satran <Julian_Satran@il.ibm.com>
To: Mallikarjun C. <cb_ma= llikarjun@yahoo.com>
Cc: IPS <ips@ietf.org>
Sent: Friday, De= cember 29, 2006 3:15:41 AM
Subject: Re: [Ips] IG clarifications: Login R= esponse & Reject reason codes

=0A
Mallikarjun,=0A
=0A
If we allow for multiple outstanding=0ALogin Requests we will have t= o allow for multiple outstanding Login Responses.=0A
=0A
Regards,=0A
Julo=0A
=0A
=0A
=0A
=0A
=0A=0A=0A
"Mallikarjun C."=0A<cb_mallikarjun@yahoo.com&= gt; =0A

28/12/06 21:45=0A

=0A=0A=0A=0A=0A
=0A
To
=0A		Juli= an Satran/Haifa/IBM@IBMIL=0A
=0A<= div align=3D"right">cc=0A= IPS <ips@ietf.org>=0A
=0A
Subject
=0A		Re: [Ips] IG clarifications: Login Response=0A& Re= ject reason codes
=0A
=0A=0A=0A
=0A

= =0A
=0A
=0A
=0A
Julian,=0A
 =0A
Thanks for the inputs, I somehow o= verlooked=0Ato respond to this email earlier.=0A

=0AI agree with you on the "Task in progress" Reject re= ason code.=0A There is no =0A
 =0A
Unless I hear new obj= ections, I would like=0Ato note "Negotiation Reset" Reject reason code as o= bsolete.  Based=0Aon the silence so far, like you, I do not believe it= is in use.=0A
 =0AOn the "no more than one outstanding=0ALo= gin Response" semantics, your comments seem to be around Login Request=0APD= U (and I believe we have such text for Login Request PDU) - do you see=0Aan= y cases wherein there can be multiple outstanding Login Responses on=0Athe = wire?  The request I got was to clarify if there is a plausible=0Ause = case.  =0A
 =0A<= br>Thanks!=0A
 =0A
Mallikarju= n=0A
----- Original Message ----<= br>=0AFrom: Julian Satran <Julian_Satran@il.ibm.com>
=0ATo: Mallik= arjun C. <cb_mallikarjun@yahoo.com>
=0ACc: IPS <ips@ietf.org>= ;
=0ASent: Monday, December 11, 2006 1:34:41 PM
=0ASubject: Re: [Ips]= IG clarifications: Login Response & Reject reason=0Acodes
=0A
= =0A
=0A
=0A"Mallikarjun C." &l= t;cb_mallikarjun@yahoo.com> wrote on 11/12/2006=0A20:15:23:
=0A
= =0A> All:
=0A>
=0A> I received some offline feedback on the= implementers' guide draft=0A
=0A> from  a few reviewers who pre= ferred to be anonymous.  Please=0Areview & comment.
=0A> =0A> 1) RFC 3720 does not explicitly call out that there cannot be more= =0A
=0A> than one outstanding Login-Response PDU on one iSCSI connect= ion at=0A
=0A> any given time (although the C-bit text indirectly imp= lies it).
=0A>
=0A> =0A
=0AThis is intentional. At t= he time we where playing with the idea of pipelining=0Athe login.
= =0AHowever it is common practice to have a single outstanding Login Request= .=0A
=0AI think that the only thing that becomes problematic is the p= hase change=0Arequest (there you can have only one outstanding).=0A
= =0AThere is already text that says that all changes to key values become fi= nal=0Aonly at the end (when consistency can be reasonably checked).<= font face=3D"Roman" size=3D"3">=0A=0A
=0A> Section 10.10 on Text Request PDU (which should cover Logi= n Request=0A
=0A> PDU semantics as well) says: "An initiator MUST hav= e at most=0Aone
=0A> outstanding Text Request on a connection at any= given time."=0A 
=0A> Essentially, an analog for Login/Text Res= ponse is missing (or so it=0Aseems).
=0A>
=0A> 2) RFC 3720 doe= s not specify the use case for Reject reason code
=0A> "Task in prog= ress" (0x07).
=0A>
=0A> I vaguely recall we put in this reason= code for task reassignment=0A
=0A> attempts while a task is in progr= ess, but then we subsequently added
=0A> a TMF response reason code f= or that case (Julian?).  So I'm not=0Asure
=0A> if reason code 0= x07 is used by implementations any longer.  
=0A>
=0A
= =0AThe reject can used when the initiator attempts to start a new task but= =0Aa task with the same ITT is still active for those cases when the target= =0Acan't be sure this is a protocol error (e.g., a race between a logout an= d=0Aa reissued SCSI command).
=0A
=0A> The other non-obvious c= ase is that of a "negotiation reset"=0AReject
=0A> reason code. &nbs= p;What is this used for by implementations, if at=0Aall?  
=0A> = If I don't hear any objections, I will deprecate these two reason=0Acodes.<= br>=0A>
=0A
=0AThe negotiating can't be continued by one of t= he parties but the partial=0Aresults (e.g., previous stage) are OK and no r= enegotiation is deemed necessary.=0AI have no clue if somebody uses it but = I felt at the time that the purists=0Awill object if I'd suggest restarting= the login :-)=0A
=0A
=0A> Mallikarjun
=0A>
=0A>=
=0A>  
=0A> ____________________________________________= ________________________________________
=0A> Do you Yahoo!?
=0A&g= t; Everyone is raving about the all-new Yahoo! Mail beta.
=0A> = http://new.mail.yah= oo.com
=0A>
=0A> __________________________________= _____________
=0A> Ips mailing list
=0A> Ips@ietf.org
= =0A> https://www1.ietf.org/mailman/listinfo/ips=0A
= =0A

=0A____________________________________________= ______
=0ADo You Yahoo!?
=0ATired of spam? Yahoo! Mail has the best s= pam protection around
=0Ahttp://mail.yahoo.com =0A

=

__________________________________________________
Do You Yaho= o!?
Tired of spam? Yahoo! Mail has the best spam protection around
= http://mail.yahoo.com --0-910909572-1167426685=:72070-- --===============1480426639== 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 --===============1480426639==-- From ips-bounces@ietf.org Fri Dec 29 16:42:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0PUT-0007QL-65; Fri, 29 Dec 2006 16:42:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0PUR-0007Q7-Bk for ips@ietf.org; Fri, 29 Dec 2006 16:42:11 -0500 Received: from web51906.mail.yahoo.com ([206.190.48.69]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H0PUP-00021u-Un for ips@ietf.org; Fri, 29 Dec 2006 16:42:11 -0500 Received: (qmail 44957 invoked by uid 60001); 29 Dec 2006 21:42:09 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type; b=5ZhddoPbW6AtveP4FnTejsRDD9OiCQUgSXNvjiR8qRVPKOrZN0KvGvMUeZ4xWihOQQB+z/uAdqeVxpV1OdixcylaupNFm1BaXkGvJswbVtxAQH66XvvH3kiqIDf6iYP76Xao2NcCL/P6Uqx0DP8V9GIOUm7sAtL3NwOWqkUIvjE= ; Message-ID: <20061229214209.44955.qmail@web51906.mail.yahoo.com> Received: from [15.246.143.45] by web51906.mail.yahoo.com via HTTP; Fri, 29 Dec 2006 13:42:09 PST Date: Fri, 29 Dec 2006 13:42:09 -0800 (PST) From: "Mallikarjun C." Subject: Re: [Ips] TMF text with updates To: ips@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.3 (/) X-Scan-Signature: c25c25eef92c03b403abac6c7c688517 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="===============1681149133==" Errors-To: ips-bounces@ietf.org --===============1681149133== Content-Type: multipart/alternative; boundary="0-728190286-1167428529=:37981" --0-728190286-1167428529=:37981 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable David and Julian,=0A=0AJust to be clear on the semantics:=0A=0A"Fast abort"= =3D early reporting of TMF completion despite outstanding transfers=0A=0AR= FC 3720 Not allowed for issuing session, Not allowed for third-par= ty sessions=0A=0AIG (Last Call): =0AFastMultiTaskAbort !=3DYes=0A = Same as RFC3720 =0AFastMultiTaskAbort =3DYes = =0A Allowed for issuing session, = Allowed for third-party sessions =0ALatest updates: =0ATaskReporting !=3D= FastAbort=0A=0A Not allowed for issuing session, = Allowed for third-party sessions =0A=0ATaskReporting=3DFastAbort=0A=0A = Allowed for issuing session, Allowed for third-party s= essions =0A=0ABefore we sanction more combinations of legal behavior, let u= s analyze why the last two combinations do not address the use cases we are= concerned about. More combinations mean more complexity.....=0A=0AAs far = as Julian's reference to "target-scoped" queues, I assume it is about the s= cope of a task set when TST=3D0. IMHO, iSCSI needs to offer a reasonable p= rocessing model for this case with Clear Task Set TMF as well as that of a = Logical Reset TMF (which always affects tasks from multiple initiators even= if TST=3D1). That is where the value of fast abort comes in.=0A=0AMallika= rjun=0A=0A=0A=0A=0A----- Original Message ----=0AFrom: "Black_David@emc.com= " =0ATo: Julian_Satran@il.ibm.com=0ACc: ips@ietf.org= =0ASent: Friday, December 29, 2006 9:45:25 AM=0ASubject: RE: [Ips] TMF text= with updates=0A=0A=0A=0A =0A=0AJulian,=0A=0A =0A=0AI'm not sure I complete= ly understand what you wrote, =0Abut if you're=0A=0Asuggesting that for a T= MF that affects tasks =0Afrom multiple initiators:=0A=0A- Fast abort (early= termination of data transfers) is =0Aused for the sending=0A=0A initiat= or.=0A=0A- The existing 3270 abort mechanism is used with other =0Ainitiato= rs, with=0A=0A the update that the TMF response =0Adoes not have to wait= for data transfer=0A=0A completion.=0A=0AI think that suggestion is rea= sonable, and it actually =0Ahelps with the use=0A=0Acase that started this = (3rd party initiator is =0Adead). The draft text would=0A=0Aneed to change= to allow this (right now it =0Amandates fast abort in all cases=0A=0Aif th= e key is negotiated to support =0Ait)=0A=0A =0A=0AI'm not sure how target-s= coped queues enter into =0Athis.=0A=0A =0A=0AThanks,=0A=0A--David=0A=0A----= ------------------------------------------------ =0A=0ADavid L. Black, Seni= or =0ATechnologist =0AEMC Corporation, 176 South St., Hopkinton, MA 01748 = =0A=0A+1 (508) =0A293-7953 =0AFAX: +1 (508) 293-7786 =0Ablack_d= avid@emc.com Mobile: +1 =0A(978) 394-7754 =0A-----------------------= ----------------------------- =0A=0A=0A=0A=0A =0A =0A From: Julian Satra= n =0A [mailto:Julian_Satran@il.ibm.com] =0ASent: Friday, December 29, 2006= =0A 6:16 AM=0ATo: Black, David=0ACc: cb_mallikarjun@yahoo.com; =0A ips@i= etf.org=0ASubject: RE: [Ips] TMF text with =0A updates=0A=0A=0A=0A =0A=0A= David, =0A=0AMy point was that we can solve the TM issue only for a =0A si= ngle initiator. So besides puting the burden on SCSI to cleanly finish othe= r =0A and advise that fast solutions really work if there are no target sc= oped =0A queues there is little we can do. And if we limit ourselves to a = single =0A initiator the multiple TM solution is a simpler (and basically = does not =0A deviate from 3270). If you consider how software stacks are = layered I =0A assume that some clever implementers have figured that alrea= dy (and did =0A it). =0A=0ARegards, =0AJulo =0A=0A=0A=0A =0A =0A = =0A Black_David@emc.com =0A =0A 28/12/06 21:54 =0A=0A = =0A =0A =0A =0A =0A To= =0A=0A Julian Satran/Haifa/IBM@IBMIL, =0A =0A =0A =0A cc=0A=0A = =0A =0A =0A Subject= =0A=0A RE: [Ips] TMF text with =0A updates=0A=0A = =0A =0A =0A =0A =0A=0A=0A=0A= =0A=0AI agree with Julian that we should avoid discussing =0A "buffer allo= cations" and =0Athe like, =0A even though we know that something like that= has to happen in at =0A =0Aleast iSER implementations. A =0A general di= scussion of "resources" works. =0A =0A =0A> You could achive the same eff= ect by =0A issuing the TM command on every affected connection. =0A =0ANo= t for TMF's that =0A affect commands from other initiators. Also, asking = the =0Atarget to coordinate receipt of the TM command on =0A every connect= ion in a =0Amulti-connection session is also a bit much. =0A =0A> The thir= d party =0A story is even more puzzling as in order to negotiate any of = =0A> the new TM modes the taget will have to =0A ascertain that all other = initiators =0A> support it. I fail to understand how would you handle downg= rading =0A the mode =0A> for those that =0A don't. =0A =0AI think the ta= rget has to track this initiator by initiator, and not =0A issue the =0Ane= w async message to old =0A initiators. This increases the importance of b= eing =0Aable to complete a TMF in the face of an =0A uncooperative third p= arty "Legacy" =0Ainitiator. =0A =0A> And if you don't downgrade why not st= ate that =0A fast-abort and target scoped =0A> =0A queues don't go togeth= er and simplify the mechanics to a multiple issue =0A TM. =0AThis didn't p= arse for me - could you explain in more =0A detail? =0A =0AThanks, =0A--D= avid =0A ---------------------------------------------------- =0ADavid L. = Black, Senior =0A Technologist =0AEMC Corporation, 176 South St., Hopkinto= n, MA =0A 01748 =0A+1 =0A (508) 293-7953 FAX: +1 (508) =0A = 293-7786 =0Ablack_david@emc.com Mobile: +1 (978) =0A 394-7754 =0A--= -------------------------------------------------- =0A =0A=0A=0A =0A=0A = From: Julian Satran =0A [mailto:Julian_Satran@il.ibm.com] =0ASent: Thursda= y, December 28, 2006 =0A 5:32 AM=0ATo: Mallikarjun C.=0ACc: =0A ips@ietf.= org=0ASubject: Re: [Ips] TMF text with updates=0A=0A=0AMallikarjun, =0A=0AI= would consider the text: =0A=0Ac. MUST leave all active "affected TTTs" (i= .e. active TTTs =0A associated with affected tasks) valid along with any b= uffer allocations for =0A the TTTs intact. =0A=0Asomewhat excessive as it = relates too much to implementation. I =0A would rather say: =0A=0Ac. MUST = =0A leave all active "affected TTTs" (i.e. active TTTs associated with aff= ected =0A tasks) valid. =0A=0Aand =0A leave the buffer issue to the imple= menter (as I have stated already on this =0A list). =0A=0AI also keep =0A = thinking (and mildly objecting to) that the whole fast abort is =0A exce= sively complex. =0A=0AYou could achive the same effect by issuing the TM co= mmand on every =0A affected connection. =0AThe =0A third party story is e= ven more puzzling as in order to negotiate any of the =0A nem TM modes the= taget will have to ascertain that all other initiators =0A support it. I = fail to understand how would you handle downgrading the mode for =0A those= that don't. And if you don't downgrade why not state that fast-abort and = =0A target scoped queues don't go together and simplify the mechanics to a= =0A multiple issue TM. =0A=0AThanks, =0AJulo =0A=0A=0A =0A =0A =0A= "Mallikarjun C." =0A =0A 28/= 12/06 06:41 =0A =0A=0A =0A=0A =0A =0A = =0A =0A To=0A=0A ips@ietf.org =0A = =0A =0A cc=0A=0A =0A =0A=0A = =0A Subject=0A=0A [Ips] TMF text with = =0A updates=0A=0A=0A =0A =0A =0A = =0A =0A=0A=0A=0A=0A=0A=0AAttached is the latest text that =0A= incorporates David's proposed enhancement. Please review and comment. = =0A Note especially two things: new section 4.1.4 that summarizes generic= =0A implementation considerations for both "clarified" and "updated" sema= ntics, =0A the changed text in 4.1.2 that says "MAY wait for ....target tr= ansfer =0A tags.....from third-party initiators" from the previous blanket= =0A MUST.=0A=0AMallikarjun=0A=0A=0A=0A4.1.2 Clarified multi-task abort = =0A semantics=0AAll iSCSI implementations MUST support the protocol behavi= or =0A defined in this section as the default behavior. The execution of = ABORT =0A TASK SET, CLEAR TASK SET, LOGICAL UNIT RESET, TARGET WARM RESET,= and TARGET =0A COLD RESET TMF Requests consists of the following sequence= of actions in the =0A specified order on the specified party. =0AThe init= iator iSCSI layer:=0Aa. =0A MUST continue to respond to each TTT received = for the affected tasks. =0Ab. =0A Should receive any responses that the ta= rget may provide for some tasks among =0A the affected tasks (may process = them as usual because they are guaranteed to =0A have chronologically orig= inated prior to the TMF response). =0Ac. Should =0A receive the TMF Respon= se concluding all the tasks in the set of affected =0A tasks. =0A=0AThe ta= rget iSCSI layer:=0Aa. MUST wait for currently valid =0A target transfer t= ags of the affected tasks from the issuing initiator to be =0A responded t= o. MAY wait for responses on currently valid target transfer =0A tags of = the affected tasks from third-party initiators.=0Ab. MUST wait =0A (concur= rent with the wait in Step.a) for all commands of the affected tasks to =0A= be received based on the CmdSN ordering. SHOULD NOT wait for new =0A c= ommands on third-party affected sessions - only the instantiated tasks have= =0A to be considered for the purpose of determining the affected tasks. = In =0A the case of target-scoped requests (i.e. TARGET WARM RESET and TARG= ET COLD =0A RESET), all the commands that are not yet received on the issu= ing session in =0A the command stream however can be considered to have be= en received with no =0A command waiting period - i.e. the entire CmdSN spa= ce up to the CmdSN of the =0A task management function can be "plugged".= =0Ac. MUST propagate the TMF =0A request to and receive the response from = the target SCSI layer. =0Ad. MUST =0A address the Response Fence flag on t= he TMF Response on issuing session as =0A defined in 3.3.2.=0Ae. MUST addr= ess the Response Fence flag on the first =0A post-TMF Response on third-pa= rty sessions as defined in 3.3.2. If some =0A tasks originate from non-iS= CSI I_T_L nexuses then the means by which the =0A target ensures that all = affected tasks have returned their status to the =0A initiator are defined= by the specific non-iSCSI transport =0A protocol(s).=0AImplementation not= e: Technically, the TMF servicing is =0A complete in Step.d. Data transfe= rs corresponding to terminated tasks may =0A however still be in progress = on third-party iSCSI sessiosn even at the end of =0A Step.e. TMF Response= MUST NOT be sent by the target iSCSI layer before =0A the end of Step.d, = and MAY be sent at the end of Step.d despite these =0A outstanding Data tr= ansfers until after Step.e.=0A=0A4.1.3 Updated multi-task =0A abort semant= ics=0AProtocol behavior defined in this section MUST be =0A implemented by= all iSCSI implementations complying with this document. =0A Protocol beh= avior defined in this section MUST be exhibited by iSCSI =0A implementatio= ns on an iSCSI session when they negotiate the TaskReporting =0A (section = 9.1) key to =93FastAbort=94 on that session. The execution of ABORT =0A T= ASK SET, CLEAR TASK SET, LOGICAL UNIT RESET, TARGET WARM RESET, and TARGET = =0A COLD RESET TMF Requests consists of the following sequence of actions = in the =0A specified order on the specified party. =0AThe initiator iSCSI = layer:=0Aa. =0A MUST NOT send any more Data-Out PDUs for affected tasks on= the issuing =0A connection of the issuing iSCSI session once the TMF is s= ent to the =0A target.=0Ab. Should receive any responses that the target m= ay provide for =0A some tasks among the affected tasks (may process them a= s usual because they =0A are guaranteed to have chronologically originated= prior to the TMF =0A response).=0Ac. MUST respond to Async Message PDU wi= th AsyncEvent=3D5 as =0A defined in section 8.1.=0Ad. Should receive the T= MF Response concluding all =0A the tasks in the set of affected tasks.=0A= =0AThe target iSCSI layer:=0Aa. =0A MUST wait for all commands of the affe= cted tasks to be received based on the =0A CmdSN ordering on the issuing s= ession. SHOULD NOT wait for new commands =0A on third-party affected sess= ions - only the instantiated tasks have to be =0A considered for the purpo= se of determining the affected tasks. In the =0A case of target-scoped re= quests (i.e. TARGET WARM RESET and TARGET COLD RESET), =0A all the command= s that are not yet received on the issuing session in the =0A command stre= am however can be considered to have been received with no command =0A wai= ting period - i.e. the entire CmdSN space up to the CmdSN of the task =0A = management function can be "plugged".=0Ab. MUST propagate the TMF request t= o =0A and receive the response from the target SCSI layer. =0Ac. MUST leav= e all =0A active "affected TTTs" (i.e. active TTTs associated with affecte= d tasks) valid =0A along with any buffer allocations for the TTTs intact.= =0Ad. MUST generate an =0A Asynchronous Message PDU with AsyncEvent=3D5 (s= ection 8.1) on:=0Ai) each =0A connection of each third-party session that = at least one affected task is =0A allegiant to, and=0Aii) each connection = except the issuing connection of the =0A issuing session that has at least= one allegiant affected task.=0AIf there are =0A multiple affected LUs (sa= y due to a target reset), then one Async Message PDU =0A MUST be sent for = each such LU on each connection that has at least one =0A allegiant affect= ed task.=0Ae. MUST address the Response Fence flag on the TMF =0A Response= on issuing session as defined in 3.3.2.=0Af. MUST address the =0A Respons= e Fence flag on the first post-TMF Response on third-party sessions as =0A = defined in 3.3.2. If some tasks originate from non-iSCSI I_T_L nexuses the= n =0A the means by which the target ensures that all affected tasks have r= eturned =0A their status to the initiator are defined by the specific non-= iSCSI transport =0A protocol(s).=0Ag. MUST free up the affected TTTs (and = STags, if applicable) =0A and the corresponding buffers once it receives t= he associated Nop-Out =0A acknowledgement that the initiator generated in = response to the Async Message. =0A =0AImplementation note: Technically, t= he TMF servicing is complete in =0A Step.e. Data transfers corresponding = to terminated tasks may however =0A still be in progress even at the end o= f Step.f. TMF Response MUST NOT be =0A sent by the target iSCSI layer bef= ore the end of Step.e, and MAY be sent at =0A the end of Step.e despite th= ese outstanding Data transfers until Step.g. =0A Step.g specifies an even= t to free up any such resources that may have =0A been reserved to support= outstanding data transfers. =0A4.1.3.1 =0A Clearing effects update=0AApp= endix F.1 of [RFC3720] specifies the clearing =0A effects of target and LU= resets on =93Incomplete TTTs=94 as =93Y=94. This meant =0A that a target= warm reset or a target cold reset or an LU reset would clear the =0A acti= ve TTTs upon completion. The TaskReporting=3DFastAbort (section 9.1) =0A = semantics defined by this section however do not guarantee that the active = =0A TTTs are cleared by the end of the reset operations. In fact, the new= =0A semantics are designed to allow clearing the TTTs in a =93lazy=94 fas= hion after =0A the TMF Response is delivered. Thus, when TaskReporting=3D= FastAbort is =0A operational on a session, the clearing effects of reset o= perations on =0A =93Incomplete TTTs=94 is =93N=94. =0A4.1.4 Implementatio= n =0A considerations=0ABoth in clarified semantics (section 4.1.2) and upd= ated =0A semantics (section 4.1.3), there may be outstanding data transfer= s even after =0A the TMF completion is reported on the issuing session. I= n the case of =0A iSCSI/iSER [iSER], these would be tagged data transfers = for STags not owned by =0A any active tasks. Whether or not real buffers = support these data =0A transfers is implementation-dependent. However, th= e data transfers =0A logically MUST be silently discarded by the target iS= CSI layer in all cases. =0A A target MAY, on an implementation-defined in= ternal timeout, also choose =0A to drop the connections on which it did no= t receive the expected Data-out =0A sequences (section 4.1.2) or Nop-Out a= cknowledgements (section 4.1.3) so as to =0A reclaim the associated buffer= , STag and TTT resources as =0A appropriate.=0A=0A=0A----- Original Messag= e ----=0AFrom: =0A "Black_David@emc.com" =0ATo: Black= _David@emc.com; =0A cb_mallikarjun@yahoo.com; ips@ietf.org=0ASent: Wednesd= ay, December 20, 2006 =0A 2:33:43 PM=0ASubject: RE: [Ips] Implementer's Gu= ide - Task Management =0A Issue=0A=0A=0A> Let's try this line of reasoning= - the target issues the =0A Nop-Out, now=0Awhen=0A> can it free the resou= rces? Answer:=0A> =0A - The Nop-In response comes back, OR=0A> - = The =0A connection times out and is torn down.=0A> Now, what if the Nop-Ou= t is not =0A issued - what does the target wait for=0Ato=0A> free the reso= urces? =0A Answer:=0A> - The transfers complete, OR=0A> =0A - Th= e connection times out and is torn down. =0A> Those look =0A similar enoug= h at the target (the worst case is the same -=0Athe=0A> =0A resources are = tied up until an uncooperative initiator times out) that=0A> =0A I don't s= ee the harm in allowing the early TMF return without the new=0A> =0A key. = The clear distinction is that the first two bullets =0A are=0Adifferent;= =0A> if the new key is not negotiated, the target has to =0A wait for the= =0Atransfers=0A> to complete; the new key and the Nop-Out are =0A necessar= y to walk away=0Aearlier=0A> when the initiator involved is able =0A to co= ntinue the transfers.=0A=0AThat got slightly twisted - what it should =0A = have talked about was the=0Atarget=0Aissuing the new Async Message and the = =0A Nop-Out response coming =0A back.=0A=0AThanks,=0A--David=0A----------= ------------------------------------------=0ADavid =0A L. Black, Senior Te= chnologist=0AEMC Corporation, 176 South St., Hopkinton, MA =0A 01748=0A+1= (508) 293-7953 =0A FAX: +1 (508) 293-7786=0Ablack_david@emc.c= om =0A Mobile: +1 (978) =0A 394-7754=0A---------------------------= -------------------------=0A=0A____________________________________________= ______=0ADo =0A You Yahoo!?=0ATired of spam? Yahoo! Mail has the best spa= m protection =0A around =0Ahttp://mail.yahoo.com =0A =0A=0A______________= _________________________________=0AIps mailing =0A list=0AIps@ietf.org=0A= https://www1.ietf.org/mailman/listinfo/ips=0A=0A___________________________= ____________________=0AIps mailing list=0AIps@ietf.org=0Ahttps://www1.ietf.= org/mailman/listinfo/ips=0A=0A=0A=0A=0A=0A=0A______________________________= ____________________=0ADo You Yahoo!?=0ATired of spam? Yahoo! Mail has the= best spam protection around =0Ahttp://mail.yahoo.com --0-728190286-1167428529=:37981 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
David and Julian,

Just to be clear on the se= mantics:

"Fast abort" =3D early reporting of TMF completion despite = outstanding transfers

RFC 3720      &n= bsp;   Not allowed for issuing session, Not allowed for third-par= ty sessions

IG (Last Call):    
FastMultiTaskAbo= rt !=3DYes
          &= nbsp;           &nbs= p;    Same as RFC3720
FastMultiTaskAbort =3DYes &nb= sp;            =           =20
           &nbs= p;            &= nbsp; Allowed for issuing session, Allowed for third-party sessions
Lat= est updates: 
TaskReporting !=3DFastAbort
=0A   = ;            &n= bsp;           Not allowe= d for issuing session, Allowed for third-party sessions
=0ATaskReportin= g=3DFastAbort
=0A         &= nbsp;           &nbs= p;    Allowed for issuing session, Allowed for third-party s= essions

Before we sanction more combinations of legal behavior, let= us analyze why the last two combinations do not address the use cases we a= re concerned about.  More combinations mean more complexity.....
As far as Julian's reference to "target-scoped" queues, I assume it is ab= out the scope of a task set when TST=3D0.  IMHO, iSCSI needs to offer = a reasonable processing model for this case with Clear Task Set TMF as well= as that of a Logical Reset TMF (which always affects tasks from multiple i= nitiators even if TST=3D1).  That is where the value of fast abort com= es in.

Mallikarjun




----- Original Message= ----
From: "Black_David@emc.com" <Black_David@emc.com>
To: Julian_Satran@il.ibm.com
Cc: ips@iet= f.org
Sent: Friday, December 29, 2006 9:45:25 AM
Subject: RE: [Ips] T= MF text with updates

=0A=0A =0A=0A
Juli= an,
=0A
 = ;
=0A
I'm not sure I completely underst= and what you wrote, =0Abut if you're
=0A
suggesting that for a TMF that affects tasks= =0Afrom multiple initiators:
=0A
- Fast abort (early termination of data transfers) is =0Aused for t= he sending
=0A
  =   initiator.
=0A
- The= existing 3270 abort mechanism is used with other =0Ainitiators, with
=0A
    the updat= e that the TMF response =0Adoes not have to wait for data = transfer
=0A
  =   completion.
=0A
I th= ink that suggestion is reasonable, and it actually =0Ahelps with the use
=0A
case that started this (3= rd party initiator is =0Adead).  The draft text would=0A
need to change to allow thi= s (right now it =0Amandates fast abort in all cases
=0A<= div dir=3D"ltr" align=3D"left">if the key is negotiated to suppor= t =0Ait)
=0A
 
=0A
I'm not sure how target-scop= ed queues enter into =0Athis.
=0A
 
=0A
Thanks,<= /span>
=0A
--David=0A
------------------------------------------= ---------- =0A
David L. Black, Senior =0ATechnologist
EMC Corporation, 1= 76 South St., Hopkinton, MA  01748 =0A
+1 (508) =0A293-7953 &nbs= p;           =0AFAX: +1 (= 508) 293-7786
black_david@emc.com      &nbs= p; Mobile: +1 =0A(978) 394-7754
-----------------------------------------= ----------- =0A

=0A
=0A
=0A
=0A From: Julian Satran =0A [mailto:Julian_Satran@il= .ibm.com]
Sent: Friday, December 29, 2006 =0A 6:16 AM
To:= Black, David
Cc: cb_mallikarjun@yahoo.com; =0A ips@ietf.org=
Subject: RE: [Ips] TMF text with =0A updates

=0A

David,
My point was that we can solve t= he TM issue only for a =0A single initiator. So besides puting the burden = on SCSI to cleanly finish other =0A and advise that fast solutions really = work if there are no target scoped =0A queues there is little we can do. A= nd if we limit ourselves to a single =0A initiator the multiple TM solutio= n is a simpler (and basically does not =0A deviate from 3270).  If yo= u consider how software stacks are layered I =0A assume that some clever i= mplementers have figured that already (and did =0A it).

Regards,
Julo


=0A =0A <= tbody>=0A =0A
Black_David@emc.com =0A =0A =

28/12/06 21:54

=0A = 		=0A =0A =0A =0A =0A =0A
=0A
=0A To=0A = Julian Satran/Haifa/= IBM@IBMIL, =0A <cb_mallikarjun@yahoo.com> =0A =
=0A cc=0A = <ips@ietf.org>= =0A
=0A =
Subjec= t
=0A 		= RE: [Ips] TMF text with =0A updates
=0A =0A =0A <= /table>
=0A




I agree with Julian that we should avoid discussing =0A "buffe= r allocations" and
the lik= e, =0A even though we know that something like that has to happen in at =0A
least iSER implementati= ons.  A =0A general discussion of "resources" works.
  =0A
&g= t; You could achive the same effect by =0A issuing the TM command on every= affected connection.
 
Not for TMF's that =0A affect commands from= other initiators.  Also, asking the
target to coordinate receipt of the TM command on =0A ever= y connection in a
multi-co= nnection session is also a bit much.
 
> The third party =0A sto= ry is even more puzzling as in order to negotiate any of
> the new TM modes the taget will have to= =0A ascertain that all other initiators
> support it. I fail to understand how would you handle = downgrading =0A the mode
= > for those that =0A don't.
  <= br>I think the target has to track th= is initiator by initiator, and not =0A issue the
new async message to old =0A initiators.  Thi= s increases the importance of being
able to complete a TMF in the face of an =0A uncooperative third= party "Legacy"
initiator.=
 
> And if you don't downgrade why not state that =0A fast-abor= t and target scoped
> = =0A queues don't go together and simplify the mechanics to a multiple issu= e =0A TM.
This didn't parse for me - could you expl= ain in more =0A detail?
 
Thanks,
--David =0A

----------------------------------------------------
David L. Black, Senior= =0A Technologist
EMC Corporation, 176 South St., Hopkinton, MA =0A  0= 1748 <= br>+1 =0A (508) 293-7953             FAX: +1= (508) =0A 293-7786
black_david@emc.com        Mobile: += 1 (978) =0A 394-7754
---------------------------------------------------- =0A


=0A

=0A From: Julian Satran = =0A [mailto:Julian_Satran@il.ibm.com]
Sent: Thursday, December = 28, 2006 =0A 5:32 AM
To: Mallikarjun C.
Cc: =0A ips@i= etf.org
Subject: Re: [Ips] TMF text with updates


Mallikarjun,=
I would consider the text:

c. MUST leave all active "affected TTTs" (i.e. active TTTs = =0A associated with affected tasks) valid along with any buffer allocation= s for =0A the TTTs intact.

somewhat excessive as it relates too much= to implementation. I =0A would rather say:

c. MUST =0A leave all active "affected TTTs"= (i.e. active TTTs associated with affected =0A tasks) valid.<= font size=3D"3">

and =0A leave the buf= fer issue to the implementer (as I have stated already on this =0A list).<= /font>

I also kee= p =0A thinking (and mildly  objecting to) that the whole fast abort i= s =0A excesively complex.

You could achive the same effect by issuing the TM command= on every =0A affected connection.
The =0A third party story is even more puzzling as i= n order to negotiate any of the =0A nem TM modes the taget will have to as= certain that all other initiators =0A support it. I fail to understand how= would you handle downgrading the mode for =0A those that don't. And if yo= u don't downgrade why not state that fast-abort and =0A target scoped queu= es don't go together and simplify the mechanics to a =0A multiple issue TM= .

Thanks,<= /font>
Julo

=0A =0A =0A =0A =
"Mallikarjun C." =0A <cb_mallikarjun@yahoo.com= > =0A

28/12/06= 06:41 =0A

=0A
=0A =0A =0A = =0A =0A =0A
=0A <= div align=3D"right">To=0A= ips= @ietf.org =0A
=0A
cc
=0A 		=0A =
=0A <= div align=3D"right">Subject=0A [Ips] TMF te= xt with =0A updates


=0A = =0A =0A =0A =
=0A






Attached is the latest text that =0A incorporates David's proposed = enhancement.  Please review and comment. =0A  Note especially tw= o things: new section 4.1.4 that summarizes generic =0A implementation con= siderations for both "clarified" and "updated" semantics, =0A the changed = text in 4.1.2 that says "MAY wait for ....target transfer =0A tags.....fro= m third-party initiators" from the previous blanket =0A MUST.

Malli= karjun



4.1.2 Clarified multi-task abort =0A semantics
Al= l iSCSI implementations MUST support the protocol behavior =0A defined in = this section as the default behavior.  The execution of ABORT =0A TAS= K SET, CLEAR TASK SET, LOGICAL UNIT RESET, TARGET WARM RESET, and TARGET = =0A COLD RESET TMF Requests consists of the following sequence of actions = in the =0A specified order on the specified party.
The initiator iSCSI= layer:
a. =0A MUST continue to respond to each TTT received for the af= fected tasks.
b. =0A Should receive any responses that the target may = provide for some tasks among =0A the affected tasks (may process them as u= sual because they are guaranteed to =0A have chronologically originated pr= ior to the TMF response).
c. Should =0A receive the TMF Response concl= uding all the tasks in the set of affected =0A tasks.

The target i= SCSI layer:
a. MUST wait for currently valid =0A target transfer tags o= f the affected tasks from the issuing initiator to be =0A responded to. &n= bsp;MAY wait for responses on currently valid target transfer =0A tags of = the affected tasks from third-party initiators.
b. MUST wait =0A (concu= rrent with the wait in Step.a) for all commands of the affected tasks to = =0A be received based on the CmdSN ordering.   SHOULD NOT wait for ne= w =0A commands on third-party affected sessions - only the instantiated ta= sks have =0A to be considered for the purpose of determining the affected = tasks.  In =0A the case of target-scoped requests (i.e. TARGET WARM R= ESET and TARGET COLD =0A RESET), all the commands that are not yet receive= d on the issuing session in =0A the command stream however can be consider= ed to have been received with no =0A command waiting period - i.e. the ent= ire CmdSN space up to the CmdSN of the =0A task management function can be= "plugged".
c. MUST propagate the TMF =0A request to and receive the re= sponse from the target SCSI layer.
d. MUST =0A address the Response Fe= nce flag on the TMF Response on issuing session as =0A defined in 3.3.2.e. MUST address the Response Fence flag on the first =0A post-TMF Respon= se on third-party sessions as defined in 3.3.2.  If some =0A tasks or= iginate from non-iSCSI I_T_L nexuses then the means by which the =0A targe= t ensures that all affected tasks have returned their status to the =0A in= itiator are defined by the specific non-iSCSI transport =0A protocol(s).Implementation note: Technically, the TMF servicing is =0A complete in S= tep.d.  Data transfers corresponding to terminated tasks may =0A howe= ver still be in progress on third-party iSCSI sessiosn even at the end of = =0A Step.e.  TMF Response MUST NOT be sent by the target iSCSI layer = before =0A the end of Step.d, and MAY be sent at the end of Step.d despite= these =0A outstanding Data transfers until after Step.e.

4.1.3 Upd= ated multi-task =0A abort semantics
Protocol behavior defined in this s= ection MUST be =0A implemented by all iSCSI implementations complying with= this document. =0A  Protocol behavior defined in this section MUST b= e exhibited by iSCSI =0A implementations on an iSCSI session when they neg= otiate the TaskReporting =0A (section 9.1) key to =93FastAbort=94 on that = session.  The execution of ABORT =0A TASK SET, CLEAR TASK SET, LOGICA= L UNIT RESET, TARGET WARM RESET, and TARGET =0A COLD RESET TMF Requests co= nsists of the following sequence of actions in the =0A specified order on = the specified party.
The initiator iSCSI layer:
a. =0A MUST NOT sen= d any more Data-Out PDUs for affected tasks on the issuing =0A connection = of the issuing iSCSI session once the TMF is sent to the =0A target.
b.= Should receive any responses that the target may provide for =0A some tas= ks among the affected tasks (may process them as usual because they =0A ar= e guaranteed to have chronologically originated prior to the TMF =0A respo= nse).
c. MUST respond to Async Message PDU with AsyncEvent=3D5 as =0A d= efined in section 8.1.
d. Should receive the TMF Response concluding all= =0A the tasks in the set of affected tasks.

The target iSCSI layer= :
a. =0A MUST wait for all commands of the affected tasks to be receive= d based on the =0A CmdSN ordering on the issuing session.  SHOULD NOT= wait for new commands =0A on third-party affected sessions - only the ins= tantiated tasks have to be =0A considered for the purpose of determining t= he affected tasks.  In the =0A case of target-scoped requests (i.e. T= ARGET WARM RESET and TARGET COLD RESET), =0A all the commands that are not= yet received on the issuing session in the =0A command stream however can= be considered to have been received with no command =0A waiting period - = i.e. the entire CmdSN space up to the CmdSN of the task =0A management fun= ction can be "plugged".
b. MUST propagate the TMF request to =0A and re= ceive the response from the target SCSI layer.
c. MUST leave all =0A a= ctive "affected TTTs" (i.e. active TTTs associated with affected tasks) val= id =0A along with any buffer allocations for the TTTs intact.
d. MUST g= enerate an =0A Asynchronous Message PDU with AsyncEvent=3D5 (section 8.1) = on:
i) each =0A connection of each third-party session that at least on= e affected task is =0A allegiant to, and
ii) each connection except the= issuing connection of the =0A issuing session that has at least one alleg= iant affected task.
If there are =0A multiple affected LUs (say due to = a target reset), then one Async Message PDU =0A MUST be sent for each such= LU on each connection that has at least one =0A allegiant affected task.<= br>e. MUST address the Response Fence flag on the TMF =0A Response on issu= ing session as defined in 3.3.2.
f. MUST address the =0A Response Fence= flag on the first post-TMF Response on third-party sessions as =0A define= d in 3.3.2. If some tasks originate from non-iSCSI I_T_L nexuses then =0A = the means by which the target ensures that all affected tasks have returned= =0A their status to the initiator are defined by the specific non-iSCSI t= ransport =0A protocol(s).
g. MUST free up the affected TTTs (and STags,= if applicable) =0A and the corresponding buffers once it receives the ass= ociated Nop-Out =0A acknowledgement that the initiator generated in respon= se to the Async Message. =0A  
Implementation note: Technically, t= he TMF servicing is complete in =0A Step.e.  Data transfers correspon= ding to terminated tasks may however =0A still be in progress even at the = end of Step.f.  TMF Response MUST NOT be =0A sent by the target iSCSI= layer before the end of Step.e, and MAY be sent at =0A the end of Step.e = despite these outstanding Data transfers until Step.g. =0A  Step.g sp= ecifies an event to free up any such resources that may have =0A been rese= rved to support outstanding data transfers.  
4.1.3.1 =0A Clearing= effects update
Appendix F.1 of [RFC3720] specifies the clearing =0A ef= fects of target and LU resets on =93Incomplete TTTs=94 as =93Y=94.  Th= is meant =0A that a target warm reset or a target cold reset or an LU rese= t would clear the =0A active TTTs upon completion.  The TaskReporting= =3DFastAbort (section 9.1) =0A semantics defined by this section however d= o not guarantee that the active =0A TTTs are cleared by the end of the res= et operations.  In fact, the new =0A semantics are designed to allow = clearing the TTTs in a =93lazy=94 fashion after =0A the TMF Response is de= livered.  Thus, when TaskReporting=3DFastAbort is =0A operational on = a session, the clearing effects of reset operations on =0A =93Incomplete T= TTs=94 is =93N=94.  
4.1.4 Implementation =0A considerations
Bo= th in clarified semantics (section 4.1.2) and updated =0A semantics (secti= on 4.1.3), there may be outstanding data transfers even after =0A the TMF = completion is reported on the issuing session.  In the case of =0A iS= CSI/iSER [iSER], these would be tagged data transfers for STags not owned b= y =0A any active tasks.  Whether or not real buffers support these da= ta =0A transfers is implementation-dependent.  However, the data tran= sfers =0A logically MUST be silently discarded by the target iSCSI layer i= n all cases. =0A  A target MAY, on an implementation-defined internal= timeout, also choose =0A to drop the connections on which it did not rece= ive the expected Data-out =0A sequences (section 4.1.2) or Nop-Out acknowl= edgements (section 4.1.3) so as to =0A reclaim the associated buffer, STag= and TTT resources as =0A appropriate.


----- Original Message -= ---
From: =0A "Black_David@emc.com" <Black_David@emc.com>
To: = Black_David@emc.com; =0A cb_mallikarjun@yahoo.com; ips@ietf.org
Sent: W= ednesday, December 20, 2006 =0A 2:33:43 PM
Subject: RE: [Ips] Implement= er's Guide - Task Management =0A Issue


> Let's try this line= of reasoning - the target issues the =0A Nop-Out, now
when
> can= it free the resources?  Answer:
> =0A     - The Nop-= In response comes back, OR
>     - The =0A connection time= s out and is torn down.
> Now, what if the Nop-Out is not =0A issued= - what does the target wait for
to
> free the resources? =0A &nb= sp;Answer:
>     - The transfers complete, OR
> =0A =     - The connection times out and is torn down.
> Those l= ook =0A similar enough at the target (the worst case is the same -
the<= br>> =0A resources are tied up until an uncooperative initiator times o= ut) that
> =0A I don't see the harm in allowing the early TMF return= without the new
> =0A key.  The clear distinction is that the = first two bullets =0A are
different;
> if the new key is not nego= tiated, the target has to =0A wait for the
transfers
> to complet= e; the new key and the Nop-Out are =0A necessary to walk away
earlier> when the initiator involved is able =0A to continue the transfers.<= br>
That got slightly twisted - what it should =0A have talked about wa= s the
target
issuing the new Async Message and the =0A Nop-Out respo= nse coming =0A back.

Thanks,
--David
------------------------= ----------------------------
David =0A L. Black, Senior TechnologistEMC Corporation, 176 South St., Hopkinton, MA =0A  01748
+1 (508)= 293-7953             =0A FAX: +1 (508) 293-= 7786
black_david@emc.com       =0A  Mobile: +1 (978= ) =0A 394-7754
----------------------------------------------------
=
__________________________________________________
Do =0A You Yahoo= !?
Tired of spam?  Yahoo! Mail has the best spam protection =0A ar= ound
http://m= ail.yahoo.com =0A

_____________________________________= __________
Ips mailing =0A list
Ips@ietf.org
https://www1.iet= f.org/mailman/listinfo/ips

_______________________________________________
= Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ip= s


__________________________________= ________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the b= est spam protection around
http://mail.yahoo.com --0-728190286-1167428529=:37981-- --===============1681149133== 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 --===============1681149133==-- From jacobwilo@club-internet.fr Fri Dec 29 18:17:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0Qz9-0002WX-5i for ips-archive@lists.ietf.org; Fri, 29 Dec 2006 18:17:59 -0500 Received: from i07m-89-86-213-199.d4.club-internet.fr ([89.86.213.199] helo=club-internet.fr) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H0Qz7-00013T-MI for ips-archive@lists.ietf.org; Fri, 29 Dec 2006 18:17:59 -0500 Message-ID: Reply-To: "HARRY" From: "HARRY" To: "JAN" Subject: JUAN Date: Sat, 30 Dec 2006 00:12:28 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4922.1500 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4922.1500 X-Spam-Score: 4.3 (++++) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Get rid of all you owe with out paying another dollar. Stop the embarrassing telephone calls. Bring to an end to the sending of checks! Believe it or not a good number lending establishments not following the banking laws here. Astonishing but factual! Visit our web site for thorough fine points regarding our procedure at 0.00 payment or requirement. You have not anything to lose and everything to reap. Please contact us- 1_561_282_9476 In depth info or to discontinue getting or to look at postal In front of each place was a plate bearing one of the delicious dama-fruit, and the perfume that rose from these was so enticing and sweet that they were sorely tempted to eat of them and become invisible. Joslyn took occasion to reprove his son in strong language for running away from home and leaving them filled with anxiety as to his fate From rights@IKSYSTEMS.COM Sat Dec 30 09:16:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0f0b-00006o-WB for ips-archive@lists.ietf.org; Sat, 30 Dec 2006 09:16:26 -0500 Received: from xdsl-87-78-91-90.netcologne.de ([87.78.91.90]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0f0Z-0002lr-Rt for ips-archive@lists.ietf.org; Sat, 30 Dec 2006 09:16:25 -0500 Received: from [105.120.92.166] (port=30250 helo=[105.120.92.166]) by xdsl-87-78-91-90.netcologne.de with esmtp id 1tSbfk-000BEW-16 for ips-archive@lists.ietf.org; Fri, 25 May 2001 23:55:21 -0700 Message-ID: <000a01c0e5b0$cafbac70$5a5b4e57@Hatice> From: "any rights" To: ips-archive@lists.ietf.org Subject: Paris Hilton Britney Date: Fri, 25 May 2001 23:55:04 -0700 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0006_01C0E576.1E9B4DD0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 3.1 (+++) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 ------=_NextPart_000_0006_01C0E576.1E9B4DD0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0007_01C0E576.1E9B4DD0" ------=_NextPart_001_0007_01C0E576.1E9B4DD0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Images, at these wallpapers are uploaded from our visitors. Favourite images at these wallpapers are uploaded from. Of, the photos = is illegal please. Desktop wallpaper angelina jolie, paris hilton = britney spears rihanna. Help us can send your favourite, images. You, would like to help us can. = Send your favourite images, at. The photos is, illegal. Would like to help. Images at these wallpapers, are uploaded! Url and comment, will remove within minutes. Not own any, rights. Own, = any rights for. Can send your, favourite! Url, and comment will. To, = help us can send your. Do, not own any. Jolie paris, hilton britney = spears rihanna cristina. Wallpapers are, uploaded, from our visitors we. Spears rihanna cristina aguilera home, if you would. Angelina jolie paris hilton? We do, not own any rights for them. Free = celebrity image desktop, wallpaper angelina jolie paris? Illegal please = url and comment will remove, within minutes. Any rights for them so? = Favourite images at these wallpapers are. Like to help us can. Would like to help us can send your. Think of the photos is! Hilton britney spears rihanna cristina aguilera = home, if you. If you would like to help us, can. Our visitors we do. If you would like to, help us can send. Photos is = illegal please url and comment will. Help us can send your. ------=_NextPart_001_0007_01C0E576.1E9B4DD0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
3D""
Images, at these wallpapers are = uploaded from our visitors.
Favourite images at these wallpapers = are uploaded=20 from. Of, the photos is illegal please. Desktop wallpaper angelina = jolie, paris=20 hilton britney spears rihanna.
Help us can send your favourite, = images. You, would=20 like to help us can. Send your favourite images, at.
The photos is, illegal. Would like to = help.
Images at these wallpapers, are = uploaded!
Url and comment, will remove within = minutes. Not=20 own any, rights. Own, any rights for. Can send your, favourite! Url, and = comment=20 will. To, help us can send your. Do, not own any. Jolie paris, hilton = britney=20 spears rihanna cristina.
Wallpapers are, uploaded, from our = visitors we.
Spears rihanna cristina aguilera home, = if you would.
Angelina jolie paris hilton? We do, not = own any=20 rights for them. Free celebrity image desktop, wallpaper angelina jolie = paris?=20 Illegal please url and comment will remove, within minutes. Any rights = for them=20 so? Favourite images at these wallpapers are.
Like to help us can.
Would like to help us can send = your.
Think of the photos is! Hilton britney = spears=20 rihanna cristina aguilera home, if you.
If you would like to help us, = can.
Our visitors we do. If you would like = to, help us=20 can send. Photos is illegal please url and comment will. Help us can = send=20 your.
------=_NextPart_001_0007_01C0E576.1E9B4DD0-- ------=_NextPart_000_0006_01C0E576.1E9B4DD0 Content-Type: image/gif; name="can.gif" Content-Transfer-Encoding: base64 Content-ID: <000501c0e5b0$cafa25d0$5a5b4e57@Hatice> R0lGODlhzAGAAIfoAAAOBYQFDgCHAIeDCgQBd4gAggF8eMXJs8nfwJjV+EwfAGAUDoEcAJ8XAMgr DeYhAAA0ARVNAEE5AGA+BIJMCpQ/Ab4/Cds7DQBRCxtmDTtbAFRkDnNlB6ZZCsRXDupUCgB7ACt+ AUx4AG2DAnRyCp11AMB4AORyAAmZBh6bBkWcAFOpBoGcAJSVAM6ZDe2YAAvBAxWzAEO8Amq+AIHJ AKK9C7q7AOqxCADrAB7lCUnWAGbXB4zWAKXiAM7pAObkAAcLQREARzwAS2AFP34ASJYATbkKNekJ OgQURhQZNDMiPlQWRYEgM6AuPLkuTdgfQgBCQxdFNjxFPlk4QIhNS5w2Q8I5N9s7MgBfMRFiNTVm O2lmO35UAKxiQMBdM9tSSg15Th6LNUx4RlR1S3yINJGGScqCQtGCQQOWRSGZREWYNlKXRYKdMZqp NbiXTtmmTgDHNRS7NTnKSlO3TnW8SqnESbK8Ot+/TgLrNRHlNDnVQGXcTHXaSqLjQMfWMdvlTAEA iyQAekEBjVMLhH8KdZcIhLYKgNUEdAAVeygsfjgRf14ugY4jcqwpi8sljNgmiwpGiyE1jD47elc1 jH9JhaM8ibtKieg5gQtuhhRYezxtdmdjgIpjg6pYecdscepWegN1hRh9ijOBi154eXl7gJuBhbh0 gu2NhAWeiiCfc0mojVOhd4OliqCZi8anguSgjgC8fh2/eUq/fVnAh365iqfAdreyeea8hADYfh/Z i0vtg2TkfofndqHShrHudNzedAoNyCsBtzQIzVEAyXUKsZoKuLEOydUAxgAXziwbw0gny20uxYER zJcmtMkaxOEcugBLwCU1zTY7zGQ1w4Q5s6NMwb84xug3zQ5swixpuD9Yw1hqzX9dtp5rvMVbtdFj yQR3wRd+yU1/xleOy3x7yZ1yzb91wt14wgCXzCujwESftlicsn2Uwaynucaqxd6ruQDAxhq9wkvL xl2/tYDKvKmxzf//7ZyusYyLiv8GAAD6Bv//AAAA8PME/wD///P19CH5BACY1a0ALAAAAADMAYAA Bwj/AP8JHEiwoMGDCBMqXMiwocOHECM6tEexosWLGDNq3Mixo8ePIEOKHEmypMmTKFOOlMiypcuX MGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGfKpMqXcq0qdOnUKNKnUq1atSjWLNq3cq1q9evYMOK HUu2rNmzaNOq9Wq1rdu3cFeuneszrt27ePPq3cu3r1+SdAML1vq3sN/BiBMrXmi4sWO9iyNLnky5 suXLkR9r3mwSs+fPjDmLHg0YtOnTqDOTXs26tevXsGPLnk27tm3IqXPr3s27t+/fDIEBiwgAAPDE t5Nzflm8uXGYQIBEFH78dPTrA4VrHz6wePfn/MLz/6ue2vt3mOYfUifvef2/9enTRxc4/zz7uSfD ayRAgCL/iuLpJ15FzhVnUYEW/VeRgsrtpVV6BUFonncQ/lPhfZhdKNCEz/3DHwEe8hfihhySaJ+F HaKI4WIaqmifcwbVt+JnH35IEIwDiTjijjruGF+HLc44WIsSPtfcQUEK+dVSBlLk3IEAOBmlPU02 SeWUVmY5ZYMnXcZhiS8eGWGKSo7F5JZPEojlmlKq2eabV3IpJ0pWxmnnmwbWeeecfLpU5I1kggmm iz+e6GKZgRV6qKJ/ImpZgYFGaiKhBQIq5qSYOjoXpCTiiOmXZGraVVR68nmYqKielmSqrLZKF1Sl mv9amKu01mrrrbhKJOuuu+aqGq/AxubrZ1blk0+wTw2r7KaVLssVXLHeZSyypgYQQEXWcuSAAxUZ 62233h5rUQMNUGuuPQoogFG67HIUrrgUWStvRQ1Zi5O9kqWb1gMPDMRvp+npe+hADDBAsMEDkVud qQs07DBF5FYUcUbZxnutPQ1XlPFHEzuVblIdW7QtSB9LTG7I9pxs8kUbc6alxRdXVDBFEECA0cwU 4Xzuueyqa1HJ6PrcEc4vf6TzyBQhDelHPQtNUsE6U9TzR9tym7TV9iBtT7Zcx/yz01W5VPPYEBgq EL4UUGAQpKE6C5ann7ZtUMECpT2Q3QzRPVDNe5f/jaKRchekt0BQD96QhngrBDdBifPtuN9jCnWS AAJkRDlGNVN0+UWb7+y5mltqXrnoHGFgOgYVZU6zzR6hgIJFrlcUuz2q0856R52bXpHuIM1+Ue0a 6c47RlYKf/pGwFPlEuUHmW4Q3//oo49BzgtUvUDQu/0VDtzjMBDzAoG/EAwwDHT68R6Rb5H6FLHP fUXve9Q5+/bQL//ov9+eUfzx745+RdILoD0EmD+3iA1ygHoe5MjHwO9cSiDk0x5YIhjBf1TQguVj yAUJIj6FcI8g2YOe+DqYkAuaMIMNIaFAPpgQ17nQdQeBoUEoxzwSblAs1yMICyWIGQpmUIb/ACL4 /+zRuc7J7nUf8V39YNA+9vlOiRuhX+2SxxH7VcSKG4Fi6vRHussZcU+fCyOvyAY8BFXEiC9EopSi pRH70ZCGontjSAQ4RS5yhIpL5Bz+oARAffQRI+oLJBPXN0ir8BAot8GiXdi4RZWY0SNLo0j3utdI 4oWOjJi73dgKKMZOBkuRcpFJ9hByw97AAQ6S86QqWaMTFRJERr4BAxgOSctadgWWtgTNKnfJy176 8pfADKYwh0nMYhrzmMjEyFBWpSlmpiaZ1GIbSBhJGmpSxUBIClwuD3kSa2bEmyJhW+hINc631IhB aaLWNhOlzTF5qlnMaWdN4OlMmSzObFiBpj47Ev9JjRTtIlVi0zTL+ciCGrQ5fEzoNRFKkcitc51K CShD/5nQgIaEkRJVqEXhBE5YRaujynsoqoKkqL9d6p6K0+ag4sbSTBHlnvV8yT5nyhQ2Fu2f6fxI qSKpp5v2E6RPydM4gUrTolqFogBdk0AZeiWQ9hRNAnUTnsoJp6ouFIxENapWpfJIfx6UqWCE5FCV atWM3qlOTM1qSfrZVLCWRqRwpUlMXWrSlQLsRw98kDxTudW+WgVlblHrWwDr18LKiV940ZphuxRX RG1rKE2b0WInS1mmNNaWlVXnZTfL2c569rOgLVNmDRPa0pr2tKhNrWdGy9rW5kW1DHHtrGC7Itne 2va2uM2tbncrK9r6irc09S1NgEvc4hr3uMhN7lKEOyzl9pa50I2udB/i3Opa97qPma52t8tdhWD3 u6PtrnhTBV6tjve89ymvekmDXsGs973wja98G9Revs73vvjN70bq+0z9+ve/AA6wgAcsG/4a+MDi JbCCd4Zgwiz4wRCebIMnvJsI84XCGMaVhe2RYd5s+L8dDrGIR0ziEm/lwxYxsYpZheIWu/jFMI6x dVdMLBmLhMY4RoyN35LjHvtYLDtm74/JYuMhG/nI/wiykoGF5CY7mcVLDuWTOxzlzwUEADs= ------=_NextPart_000_0006_01C0E576.1E9B4DD0-- From ips-bounces@ietf.org Sun Dec 31 02:09:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0uoS-0005PM-7M; Sun, 31 Dec 2006 02:08:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0uoR-0005PH-CK for ips@ietf.org; Sun, 31 Dec 2006 02:08:55 -0500 Received: from mtagate2.de.ibm.com ([195.212.29.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0uoQ-0007Cj-Ce for ips@ietf.org; Sun, 31 Dec 2006 02:08:55 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate2.de.ibm.com (8.13.8/8.13.8) with ESMTP id kBV78rYA093794 for ; Sun, 31 Dec 2006 07:08:53 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id kBV78rHW3043572 for ; Sun, 31 Dec 2006 08:08:53 +0100 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id kBV78qAP024003 for ; Sun, 31 Dec 2006 08:08:52 +0100 Received: from d12mc102.megacenter.de.ibm.com (d12mc102.megacenter.de.ibm.com [9.149.167.114]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id kBV78q0C023997 for ; Sun, 31 Dec 2006 08:08:52 +0100 In-Reply-To: <20061229211125.64484.qmail@web51912.mail.yahoo.com> To: "Mallikarjun C." MIME-Version: 1.0 Subject: Re: [Ips] IG clarifications: Login Response & Reject reason codes X-Mailer: Lotus Notes Release 7.0.2 September 26, 2006 From: Julian Satran Message-ID: Date: Sun, 31 Dec 2006 09:08:51 +0200 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 7.0.2HF71 | November 3, 2006) at 31/12/2006 09:08:52, Serialize complete at 31/12/2006 09:08:52 X-Spam-Score: 0.1 (/) X-Scan-Signature: de672dd48bf7248e70d446cd2da63266 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="===============2133415645==" Errors-To: ips-bounces@ietf.org This is a multipart message in MIME format. --===============2133415645== Content-Type: multipart/alternative; boundary="=_alternative 002742E1C2257255_=" This is a multipart message in MIME format. --=_alternative 002742E1C2257255_= Content-Type: text/plain; charset="US-ASCII" Mallikarjun, Thanks for getting through all this. Yes I think that cthe clarification is not needed. But if the reviewer felt that not to clear or explicit enough some text will help (and hopefully not harm). Regards, Julo "Mallikarjun C." 29/12/06 23:11 To IPS cc Subject Re: [Ips] IG clarifications: Login Response & Reject reason codes Julian, As I read through relevant sections of 3720, I see the following in section 5.3: The Login Phase is only implemented via Login Request and Responses. The whole Login Phase is considered as a single task and has a single Initiator Task Tag (similar to the linked SCSI commands). Section 10.10.3 makes a similar point about text requests/responses. I do not thus believe that the current text allows the flexibility to pipeline multiple outstanding Login/Text Requests/Responses. That of course means that I guess I am reaching the opposite conclusion than the one I started with - the clarification the anonymous reviewer had wanted me to put in wrt Login Response is not necessary. If OTOH you believe we need to explicitly allow pipelining overriding this 3720 text, please let me know. Thanks. Mallikarjun ----- Original Message ---- From: Julian Satran To: Mallikarjun C. Cc: IPS Sent: Friday, December 29, 2006 3:15:41 AM Subject: Re: [Ips] IG clarifications: Login Response & Reject reason codes Mallikarjun, If we allow for multiple outstanding Login Requests we will have to allow for multiple outstanding Login Responses. Regards, Julo "Mallikarjun C." 28/12/06 21:45 To Julian Satran/Haifa/IBM@IBMIL cc IPS Subject Re: [Ips] IG clarifications: Login Response & Reject reason codes Julian, Thanks for the inputs, I somehow overlooked to respond to this email earlier. I agree with you on the "Task in progress" Reject reason code. There is no Unless I hear new objections, I would like to note "Negotiation Reset" Reject reason code as obsolete. Based on the silence so far, like you, I do not believe it is in use. On the "no more than one outstanding Login Response" semantics, your comments seem to be around Login Request PDU (and I believe we have such text for Login Request PDU) - do you see any cases wherein there can be multiple outstanding Login Responses on the wire? The request I got was to clarify if there is a plausible use case. Thanks! Mallikarjun ----- Original Message ---- From: Julian Satran To: Mallikarjun C. Cc: IPS Sent: Monday, December 11, 2006 1:34:41 PM Subject: Re: [Ips] IG clarifications: Login Response & Reject reason codes "Mallikarjun C." wrote on 11/12/2006 20:15:23: > All: > > I received some offline feedback on the implementers' guide draft > from a few reviewers who preferred to be anonymous. Please review & comment. > > 1) RFC 3720 does not explicitly call out that there cannot be more > than one outstanding Login-Response PDU on one iSCSI connection at > any given time (although the C-bit text indirectly implies it). > > This is intentional. At the time we where playing with the idea of pipelining the login. However it is common practice to have a single outstanding Login Request. I think that the only thing that becomes problematic is the phase change request (there you can have only one outstanding). There is already text that says that all changes to key values become final only at the end (when consistency can be reasonably checked). > Section 10.10 on Text Request PDU (which should cover Login Request > PDU semantics as well) says: "An initiator MUST have at most one > outstanding Text Request on a connection at any given time." > Essentially, an analog for Login/Text Response is missing (or so it seems). > > 2) RFC 3720 does not specify the use case for Reject reason code > "Task in progress" (0x07). > > I vaguely recall we put in this reason code for task reassignment > attempts while a task is in progress, but then we subsequently added > a TMF response reason code for that case (Julian?). So I'm not sure > if reason code 0x07 is used by implementations any longer. > The reject can used when the initiator attempts to start a new task but a task with the same ITT is still active for those cases when the target can't be sure this is a protocol error (e.g., a race between a logout and a reissued SCSI command). > The other non-obvious case is that of a "negotiation reset" Reject > reason code. What is this used for by implementations, if at all? > If I don't hear any objections, I will deprecate these two reason codes. > The negotiating can't be continued by one of the parties but the partial results (e.g., previous stage) are OK and no renegotiation is deemed necessary. I have no clue if somebody uses it but I felt at the time that the purists will object if I'd suggest restarting the login :-) > Mallikarjun > > > > ____________________________________________________________________________________ > Do you Yahoo!? > Everyone is raving about the all-new Yahoo! Mail beta. > http://new.mail.yahoo.com > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --=_alternative 002742E1C2257255_= Content-Type: text/html; charset="US-ASCII"
Mallikarjun,

Thanks for getting through all this. Yes I think that cthe clarification is not needed. But if the reviewer felt that not to clear or explicit enough some text will help (and hopefully not harm).

Regards,
Julo


"Mallikarjun C." <cb_mallikarjun@yahoo.com>

29/12/06 23:11

To
IPS <ips@ietf.org>
cc
Subject
Re: [Ips] IG clarifications: Login Response & Reject reason codes





Julian,  

As I read through relevant sections of 3720, I see the following in section 5.3:

The Login Phase is only implemented via Login Request and Responses.
The whole Login Phase is considered as a single task and has a single
Initiator Task Tag (similar to the linked SCSI commands).

Section 10.10.3 makes a similar point about text requests/responses.  

I do not thus believe that the current text allows the flexibility to pipeline multiple outstanding Login/Text Requests/Responses.  That of course means that I guess I am reaching the opposite conclusion than the one I started with - the clarification the anonymous reviewer had wanted me to put in wrt Login Response is not necessary.  

If OTOH you believe we need to explicitly allow pipelining overriding this 3720 text, please let me know.

Thanks.

Mallikarjun
----- Original Message ----
From: Julian Satran <Julian_Satran@il.ibm.com>
To: Mallikarjun C. <cb_mallikarjun@yahoo.com>
Cc: IPS <ips@ietf.org>
Sent: Friday, December 29, 2006 3:15:41 AM
Subject: Re: [Ips] IG clarifications: Login Response & Reject reason codes


Mallikarjun,

If we allow for multiple outstanding Login Requests we will have to allow for multiple outstanding Login Responses.

Regards,
Julo



"Mallikarjun C." <cb_mallikarjun@yahoo.com>

28/12/06 21:45


To
Julian Satran/Haifa/IBM@IBMIL
cc
IPS <ips@ietf.org>
Subject
Re: [Ips] IG clarifications: Login Response & Reject reason codes







Julian,
 
Thanks for the inputs, I somehow overlooked to respond to this email earlier.

I agree with you on the "Task in progress" Reject reason code.  There is no
 
Unless I hear new objections, I would like to note "Negotiation Reset" Reject reason code as obsolete.  Based on the silence so far, like you, I do not believe it is in use.
 
On the "no more than one outstanding Login Response" semantics, your comments seem to be around Login Request PDU (and I believe we have such text for Login Request PDU) - do you see any cases wherein there can be multiple outstanding Login Responses on the wire?  The request I got was to clarify if there is a plausible use case.  
 
Thanks!
 
Mallikarjun
----- Original Message ----
From: Julian Satran <Julian_Satran@il.ibm.com>
To: Mallikarjun C. <cb_mallikarjun@yahoo.com>
Cc: IPS <ips@ietf.org>
Sent: Monday, December 11, 2006 1:34:41 PM
Subject: Re: [Ips] IG clarifications: Login Response & Reject reason codes



"Mallikarjun C." <cb_mallikarjun@yahoo.com> wrote on 11/12/2006 20:15:23:

> All:
>
> I received some offline feedback on the implementers' guide draft
> from  a few reviewers who preferred to be anonymous.  Please review & comment.
>
> 1) RFC 3720 does not explicitly call out that there cannot be more
> than one outstanding Login-Response PDU on one iSCSI connection at
> any given time (although the C-bit text indirectly implies it).
>
>

This is intentional. At the time we where playing with the idea of pipelining the login.
However it is common practice to have a single outstanding Login Request.
I think that the only thing that becomes problematic is the phase change request (there you can have only one outstanding).
There is already text that says that all changes to key values become final only at the end (when consistency can be reasonably checked).

> Section 10.10 on Text Request PDU (which should cover Login Request
> PDU semantics as well) says: "An initiator MUST have at most one
> outstanding Text Request on a connection at any given time."  
> Essentially, an analog for Login/Text Response is missing (or so it seems).
>
> 2) RFC 3720 does not specify the use case for Reject reason code
> "Task in progress" (0x07).
>
> I vaguely recall we put in this reason code for task reassignment
> attempts while a task is in progress, but then we subsequently added
> a TMF response reason code for that case (Julian?).  So I'm not sure
> if reason code 0x07 is used by implementations any longer.  
>

The reject can used when the initiator attempts to start a new task but a task with the same ITT is still active for those cases when the target can't be sure this is a protocol error (e.g., a race between a logout and a reissued SCSI command).

> The other non-obvious case is that of a "negotiation reset" Reject
> reason code.  What is this used for by implementations, if at all?  
> If I don't hear any objections, I will deprecate these two reason codes.
>

The negotiating can't be continued by one of the parties but the partial results (e.g., previous stage) are OK and no renegotiation is deemed necessary. I have no clue if somebody uses it but I felt at the time that the purists will object if I'd suggest restarting the login :-)

> Mallikarjun
>
>
>  
> ____________________________________________________________________________________
> Do you Yahoo!?
> Everyone is raving about the all-new Yahoo! Mail beta.
> http://new.mail.yahoo.com
>
> _______________________________________________
> Ips mailing list
> Ips@ietf.org
> https://www1.ietf.org/mailman/listinfo/ips


__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com


__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com _______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips
--=_alternative 002742E1C2257255_=-- --===============2133415645== 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 --===============2133415645==--