From sip-admin@ietf.org Tue Oct 1 09:49:14 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16872 for ; Tue, 1 Oct 2002 09:49:14 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g91Dohv25379 for ; Tue, 1 Oct 2002 09:50:43 -0400 Date: Tue, 01 Oct 2002 09:50:43 -0400 Message-ID: <20021001135043.2977.50290.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder To: ips-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, ips-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@. Thanks! Passwords for ips-archive@lists.ietf.org: List Password // URL ---- -------- ips@ietf.org INMn https://www1.ietf.org/mailman/options/ips/ips-archive%40lists.ietf.org From owner-ips@ece.cmu.edu Tue Oct 1 15:05:58 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01661 for ; Tue, 1 Oct 2002 15:05:58 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g91IOx808420 for ips-outgoing; Tue, 1 Oct 2002 14:24:59 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g91Bbro10452 for ; Tue, 1 Oct 2002 07:37:53 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09238; Tue, 1 Oct 2002 07:35:53 -0400 (EDT) Message-Id: <200210011135.HAA09238@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ips@ece.cmu.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ips-fcip-slp-04.txt Date: Tue, 01 Oct 2002 07:35:53 -0400 Sender: owner-ips@ece.cmu.edu Precedence: bulk --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 : Finding FCIP Entities Using SLPv2 Author(s) : D. Peterson Filename : draft-ietf-ips-fcip-slp-04.txt Pages : 11 Date : 2002-9-30 The FCIP protocol [FCIP] provides a method for the tunneling of Fibre Channel frames over an IP network. This document defines the use of Service Location Protocol, version 2 (SLPv2) [RFC2608], by FCIP Entities to discover one another, and provides the appropriate templates describing their services. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-fcip-slp-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-fcip-slp-04.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-fcip-slp-04.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: <2002-9-30144611.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-fcip-slp-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-fcip-slp-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-9-30144611.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ips@ece.cmu.edu Tue Oct 1 15:06:05 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01676 for ; Tue, 1 Oct 2002 15:06:04 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g91IP5w08445 for ips-outgoing; Tue, 1 Oct 2002 14:25:05 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g91Bc1o10475 for ; Tue, 1 Oct 2002 07:38:01 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09270; Tue, 1 Oct 2002 07:36:02 -0400 (EDT) Message-Id: <200210011136.HAA09270@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ips@ece.cmu.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ips-iscsi-name-disc-08.txt Date: Tue, 01 Oct 2002 07:36:02 -0400 Sender: owner-ips@ece.cmu.edu Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Storage Working Group of the IETF. Title : iSCSI Naming and Discovery Author(s) : M. Bakke et al. Filename : draft-ietf-ips-iscsi-name-disc-08.txt Pages : 22 Date : 2002-9-30 This document provides examples of iSCSI [iSCSI] name construction and discussion of discovery of iSCSI resources (targets) by iSCSI initiators. This document complements the iSCSI protocol draft. Flexibility is the key guiding principle behind this document. That is, an effort has been made to satisfy the needs of both small isolated environments, as well as large environments requiring secure/scalable solutions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-name-disc-08.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ips-iscsi-name-disc-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ips-iscsi-name-disc-08.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: <2002-9-30144635.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-iscsi-name-disc-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-iscsi-name-disc-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-9-30144635.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ips@ece.cmu.edu Tue Oct 1 15:07:16 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01707 for ; Tue, 1 Oct 2002 15:07:15 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g91IP2D08433 for ips-outgoing; Tue, 1 Oct 2002 14:25:02 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g91Bbvo10463 for ; Tue, 1 Oct 2002 07:37:57 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09254; Tue, 1 Oct 2002 07:35:58 -0400 (EDT) Message-Id: <200210011135.HAA09254@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ips@ece.cmu.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ips-iscsi-18.txt,.pdf Date: Tue, 01 Oct 2002 07:35:57 -0400 Sender: owner-ips@ece.cmu.edu Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Storage Working Group of the IETF. Title : iSCSI Author(s) : J. Satran et al. Filename : draft-ietf-ips-iscsi-18.txt,.pdf Pages : 285 Date : 2002-9-30 The Small Computer Systems Interface (SCSI) is a popular family of protocols for communicating with I/O devices, especially storage devices. This document describes a transport protocol for SCSI that works on top of TCP. The iSCSI protocol aims to be fully compliant with the rules laid out in the SCSI Architecture Model - 2 [SAM2] document. This current version of iSCSI is 0. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-18.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ips-iscsi-18.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ips-iscsi-18.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: <2002-9-30144623.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-iscsi-18.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-iscsi-18.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-9-30144623.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ips@ece.cmu.edu Tue Oct 1 23:27:03 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14050 for ; Tue, 1 Oct 2002 23:27:03 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g922lXX13343 for ips-outgoing; Tue, 1 Oct 2002 22:47:33 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic2.corp.emc.com (mxic2.us.dg.com [128.221.31.40]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g922lWo13339 for ; Tue, 1 Oct 2002 22:47:32 -0400 (EDT) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Tue, 1 Oct 2002 22:47:21 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C3B3@CORPMX14> From: Black_David@emc.com To: ips@ece.cmu.edu Subject: ips spot on IETF agenda Date: Tue, 1 Oct 2002 22:47:17 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Providing a public answer to a private question of general interest: > IPS is scheduled for late Thursday afternoon. Is there any chance > it could move earlier in the week? Yes, that's the traditional slot for the saag (Open Security Area Directorate/Security Area Advisory Group) meeting - when time was requested for ips, the secretariat was informed that a conflict with saag MUST be avoided. I will remind them of this ... Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 249-6449 FAX: +1 (508) 497-8018 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Wed Oct 2 01:26:33 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16396 for ; Wed, 2 Oct 2002 01:26:33 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g924oNT20448 for ips-outgoing; Wed, 2 Oct 2002 00:50:23 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mailhub.lss.emc.com (xdch.emc.com [168.159.1.79]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g924oLo20440 for ; Wed, 2 Oct 2002 00:50:21 -0400 (EDT) Received: from emc.com (emcmail.lss.emc.com [168.159.48.78]) by mailhub.lss.emc.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g924oCf22091 for ; Wed, 2 Oct 2002 00:50:12 -0400 (EDT) Received: from mxic1.isus.emc.com ([168.159.129.100]) by emc.com (8.10.1/8.10.1) with ESMTP id g924oC706949 for ; Wed, 2 Oct 2002 00:50:12 -0400 (EDT) Received: by MXIC1 with Internet Mail Service (5.5.2653.19) id ; Wed, 2 Oct 2002 00:50:11 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C3BC@CORPMX14> From: Black_David@emc.com To: ips@ece.cmu.edu Subject: FW: RFC 3385 on Internet Protocol Small Computer System Interface (iSCSI) Cyclic Redundancy Check (CRC)/Checksum Considerations Date: Wed, 2 Oct 2002 00:50:10 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C269CF.2FE308B0" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C269CF.2FE308B0 Content-Type: text/plain; charset="iso-8859-1" FYI and congratulations to the authors. --David -----Original Message----- From: rfc-editor@rfc-editor.org [mailto:rfc-editor@rfc-editor.org] Sent: Monday, September 30, 2002 6:25 PM Cc: rfc-editor@rfc-editor.org Subject: RFC 3385 on Internet Protocol Small Computer System Interface (iSCSI) Cyclic Redundancy Check (CRC)/Checksum Considerations A new Request for Comments is now available in online RFC libraries. RFC 3385 Title: Internet Protocol Small Computer System Interface (iSCSI) Cyclic Redundancy Check (CRC)/Checksum Considerations Author(s): D. Sheinwald, J. Satran, P. Thaler, V. Cavanna Status: Informational Date: September 2002 Mailbox: julian_satran@il.ibm.com, Dafna_Sheinwald@il.ibm.com, pat_thaler@agilent.com, vince_cavanna@agilent.com, Pages: 23 Characters: 53450 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-sheinwald-iscsi-crc-02.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3385.txt In this memo, we attempt to give some estimates for the probability of undetected errors to facilitate the selection of an error detection code for the Internet Protocol Small Computer System Interface (iSCSI). We will also attempt to compare Cyclic Redundancy Checks (CRCs) with other checksum forms (e.g., Fletcher, Adler, weighted checksums), as permitted by available data. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. ------_=_NextPart_000_01C269CF.2FE308B0 Content-Type: message/rfc822 To: Subject: Date: Wed, 2 Oct 2002 00:50:11 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01C269CF.2FE308B0" ------_=_NextPart_002_01C269CF.2FE308B0 Content-Type: text/plain ------_=_NextPart_002_01C269CF.2FE308B0 Content-Type: application/octet-stream; name="ATT16441" Content-Disposition: attachment; filename="ATT16441" Content-type: message/external-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <020930152258.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3385 ------_=_NextPart_002_01C269CF.2FE308B0 Content-Type: message/external-body; site="in-notes"; dir="rfc3385.txt"; mode="ftp.isi.edu"; access-type="anon-ftp" ------_=_NextPart_002_01C269CF.2FE308B0-- ------_=_NextPart_000_01C269CF.2FE308B0-- From owner-ips@ece.cmu.edu Wed Oct 2 19:14:47 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11155 for ; Wed, 2 Oct 2002 19:14:47 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g92MXjf11090 for ips-outgoing; Wed, 2 Oct 2002 18:33:45 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g92BM1o22497 for ; Wed, 2 Oct 2002 07:22:02 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14881; Wed, 2 Oct 2002 07:20:02 -0400 (EDT) Message-Id: <200210021120.HAA14881@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ips@ece.cmu.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ips-auth-mib-02.txt Date: Wed, 02 Oct 2002 07:20:02 -0400 Sender: owner-ips@ece.cmu.edu Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Storage Working Group of the IETF. Title : Definitions of Managed Objects for User Identity Authentication Author(s) : M. Bakke, J. Muchow Filename : draft-ietf-ips-auth-mib-02.txt Pages : 28 Date : 2002-10-1 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular it defines objects for managing user identities and the names, addresses, and credentials required to authenticate them, for use with various protocols. This draft was motivated by the need for the configuration of authenticated user identities for the iSCSI protocol [ISCSI], but has been extended to be useful for other protocols that have similar requirements. It is important to note that this MIB provides only the set of identities and the means to authenticate them; it is the responsibility of other MIBs making use of this one to tie them to authorization lists. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-auth-mib-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-auth-mib-02.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-auth-mib-02.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: <2002-10-1141236.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-auth-mib-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-auth-mib-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-1141236.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ips@ece.cmu.edu Wed Oct 2 19:14:52 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11169 for ; Wed, 2 Oct 2002 19:14:52 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g92MXgN11077 for ips-outgoing; Wed, 2 Oct 2002 18:33:42 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g92BLwo22487 for ; Wed, 2 Oct 2002 07:21:58 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14864; Wed, 2 Oct 2002 07:19:58 -0400 (EDT) Message-Id: <200210021119.HAA14864@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ips@ece.cmu.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ips-iscsi-mib-06.txt Date: Wed, 02 Oct 2002 07:19:58 -0400 Sender: owner-ips@ece.cmu.edu Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Storage Working Group of the IETF. Title : Definitions of Managed Objects for iSCSI Author(s) : M. Bakke, J. Muchow, M. Krueger, T. McSweeney Filename : draft-ietf-ips-iscsi-mib-06.txt Pages : 70 Date : 2002-10-1 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular it defines objects for managing a client using the iSCSI (SCSI over TCP) protocol. It is meant to match the latest version of iSCSI defined in [ISCSI]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-mib-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ips-iscsi-mib-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ips-iscsi-mib-06.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: <2002-10-1141224.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-iscsi-mib-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-iscsi-mib-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-1141224.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ips@ece.cmu.edu Wed Oct 2 19:16:09 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11207 for ; Wed, 2 Oct 2002 19:16:09 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g92MXr511110 for ips-outgoing; Wed, 2 Oct 2002 18:33:53 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mailgw2.technion.ac.il (mailgw2.technion.ac.il [132.68.238.35]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g92DXJo00043 for ; Wed, 2 Oct 2002 09:33:19 -0400 (EDT) Received: by mailgw2.technion.ac.il (Postfix, from userid 60999) id F14F136D47; Wed, 2 Oct 2002 16:32:26 +0300 (IDT) Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by mailgw2.technion.ac.il (Postfix) with ESMTP id 747A536CFF for ; Wed, 2 Oct 2002 16:32:23 +0300 (IDT) Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id IAA24287 for ietf-123-outbound.07@ietf.org; Wed, 2 Oct 2002 08:55:01 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id HAA23430 for ; Wed, 2 Oct 2002 07:21:58 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14864; Wed, 2 Oct 2002 07:19:58 -0400 (EDT) Message-Id: <200210021119.HAA14864@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ips@ece.cmu.edu From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ips-iscsi-mib-06.txt Date: Wed, 02 Oct 2002 07:19:58 -0400 Sender: owner-ips@ece.cmu.edu Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Storage Working Group of the IETF. Title : Definitions of Managed Objects for iSCSI Author(s) : M. Bakke, J. Muchow, M. Krueger, T. McSweeney Filename : draft-ietf-ips-iscsi-mib-06.txt Pages : 70 Date : 2002-10-1 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular it defines objects for managing a client using the iSCSI (SCSI over TCP) protocol. It is meant to match the latest version of iSCSI defined in [ISCSI]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-mib-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ips-iscsi-mib-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ips-iscsi-mib-06.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: <2002-10-1141224.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-iscsi-mib-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-iscsi-mib-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-1141224.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ips@ece.cmu.edu Thu Oct 3 15:08:34 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01526 for ; Thu, 3 Oct 2002 15:08:34 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g93IOcd07174 for ips-outgoing; Thu, 3 Oct 2002 14:24:38 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ariel.nishansystems.com ([65.113.142.135]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g93IOao07170 for ; Thu, 3 Oct 2002 14:24:36 -0400 (EDT) Received: by ariel.nishansystems.com with Internet Mail Service (5.5.2653.19) id <4FJKNXS3>; Thu, 3 Oct 2002 11:24:08 -0700 Message-ID: From: Joshua Tseng To: "'ips@ece.cmu.edu'" Subject: iSNS: pdf of draft -13 available here Date: Thu, 3 Oct 2002 11:24:07 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Hi Folks, For your convenience, I have placed a pdf of iSNS revision -13 (which is now in last call) on this ftp server: www.nishansystems.com/ietf/draft-ietf-ips-isns-13.pdf Change bars and highlighted text indicate changes from the -12 revision. Regards, Josh Tseng From owner-ips@ece.cmu.edu Fri Oct 4 14:08:50 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15453 for ; Fri, 4 Oct 2002 14:08:45 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g94HISO13951 for ips-outgoing; Fri, 4 Oct 2002 13:18:28 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msg001.maranti.com (66-147-154-78.focaldata.net [66.147.154.78] (may be forged)) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g94HIQo13947 for ; Fri, 4 Oct 2002 13:18:26 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C26BCA.10663AFA" Subject: iSCSI : Query about parameter exchange Date: Fri, 4 Oct 2002 10:18:32 -0700 Message-ID: Thread-Topic: iSCSI : Query about parameter exchange Thread-Index: AcJryhBjUBa7vSGkQmKaoDe+lYnUkA== From: "Priya Viswambharan" To: Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C26BCA.10663AFA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, =20 I have a query about parameter negotiation/declaration. =20 Consider the following scenario. I --> T T=3D1, csg=3D0, nsg=3D3 =20 If the target has to send say its MaxRecvDataSegmentLength (or any other key which is not valid in the Security phase) to the initiator, is it ok for the target to respond with T --> I T=3D0, csg=3D1 MaxRecvDataSegmentLength=3D so that it can notify the Initiator of its capacity. =20 I believe there are some implementations that behave this way. In a Normal session, if such a login PDU is received from the Initiator the target can send its MaxRecvDataSegmentLength through a Text response in Full feature phase. But how could a target notify the Initiator of its MaxRecvDataSegmentLength in the following 2 scenarios : 1) a Discovery session 2) a Normal Session and the Initiator has not sent a text request to the target.=20 =20 Thanks Priya ------_=_NextPart_001_01C26BCA.10663AFA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

I have a query about parameter = negotiation/declaration.

 

Consider the following = scenario.

I à T    T=3D1, csg=3D0, nsg=3D3

 

If the target has to send say its = MaxRecvDataSegmentLength (or any other key which is not valid in the Security phase) to the = initiator, is it ok for the target to respond with

T à I    T=3D0, csg=3D1

        = ;    = MaxRecvDataSegmentLength=3D<value><= /p>

so that it = can notify the Initiator of its capacity.

 

I believe there are some implementations that behave = this way. In a Normal session, if such a login PDU is received from the Initiator the target can send its MaxRecvDataSegmentLength through a Text response in Full feature phase. = But how could a target notify the Initiator of its MaxRecvDataSegmentLength in = the following 2 scenarios : 1) a Discovery = session 2) a Normal Session and the Initiator has not sent a text request to the target. =

 

Thanks

Priya

=00 ------_=_NextPart_001_01C26BCA.10663AFA-- From owner-ips@ece.cmu.edu Fri Oct 4 16:11:10 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19797 for ; Fri, 4 Oct 2002 16:11:10 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g94JWKx25511 for ips-outgoing; Fri, 4 Oct 2002 15:32:20 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g94JWGo25497 for ; Fri, 4 Oct 2002 15:32:16 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id A274D30706; Fri, 4 Oct 2002 15:32:15 -0400 (EDT) Date: Fri, 4 Oct 2002 12:31:39 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Priya Viswambharan Cc: Subject: Re: iSCSI : Query about parameter exchange In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Fri, 4 Oct 2002, Priya Viswambharan wrote: > Hi all, > > I have a query about parameter negotiation/declaration. > > Consider the following scenario. > I --> T T=1, csg=0, nsg=3 > > If the target has to send say its MaxRecvDataSegmentLength (or any other > key which is not valid in the Security phase) to the initiator, is it ok > for the target to respond with > T --> I T=0, csg=1 > MaxRecvDataSegmentLength= > so that it can notify the Initiator of its capacity. No. You can only exchange security parameters in Security phase. Oh, you have to say csg=0 back since that was the stage the first packet was in. I think though that the target can say T --> I T=1 csg=0 nsg=1 and then exchange keys in the normal phase. > I believe there are some implementations that behave this way. In a > Normal session, if such a login PDU is received from the Initiator the > target can send its MaxRecvDataSegmentLength through a Text response in > Full feature phase. But how could a target notify the Initiator of its > MaxRecvDataSegmentLength in the following 2 scenarios : 1) a Discovery > session 2) a Normal Session and the Initiator has not sent a text > request to the target. As above, the target just forces a normal negotiation phase, and all is well. Take care, Bill From owner-ips@ece.cmu.edu Mon Oct 7 17:50:44 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07597 for ; Mon, 7 Oct 2002 17:50:43 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g97KevJ02520 for ips-outgoing; Mon, 7 Oct 2002 16:40:57 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from erie.mcdata.com ([144.49.6.25]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g97Keso02515 for ; Mon, 7 Oct 2002 16:40:55 -0400 (EDT) Received: by erie.mcdata.com with Internet Mail Service (5.5.2653.19) id ; Mon, 7 Oct 2002 14:42:46 -0600 Message-ID: From: Anil Rijhsinghani To: "'Black_David@emc.com'" , ips@ece.cmu.edu Subject: RE: IPS-ALL: iSNS WG Last Call Date: Mon, 7 Oct 2002 14:42:41 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk How hard would it be to add hooks for optional FCIP support in iSNS? It currently supports only iFCP and iSCSI. Regards, Anil -----Original Message----- From: Black_David@emc.com [mailto:Black_David@emc.com] Sent: Friday, September 27, 2002 10:07 AM To: ips@ece.cmu.edu Subject: IPS-ALL: iSNS WG Last Call All, We would like to announce IPS Working Group Last call for the Internet Storage Name Service (iSNS). Details: Document: Internet Storage Name Service (iSNS) URL: http://www.ietf.org/internet-drafts/draft-ietf-ips-isns-13.txt Note: There are formatting (line length) problems with this draft. It may get updated to -14 shortly to correct them without change to its content. Last call period: 2 Weeks Submit comments no later than: Sunday, October 13, 2002 at 5pm EST Editor: Josh Tseng Please submit editorial comments directly to Josh, with copy to David Black (black_david@emc.com), and Elizabeth Rodriguez(erodrigu@brocade.com) Submit technical comments to the IPS mailing list (ips@ece.cmu.edu) Editorial comments may be resolved directly by the editor of the document, but any technical issues must be discussed on the IPS reflector. Thanks, David Black & Elizabeth Rodriguez IPS co-chairs --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 249-6449 FAX: +1 (508) 497-8018 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- =========================================================== Notice All information transmitted hereby is intended only for the use of the addressee(s) named above and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If the reader of this message is not the intended recipient(s) or the employee or agent responsible for delivering the message to the intended recipient(s), you may not distribute or copy this communication to another. Anyone who receives this communication in error should notify us immediately by telephone and mail the original message to us at the above address and destroy all copies. =========================================================== From owner-ips@ece.cmu.edu Mon Oct 7 18:51:33 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08991 for ; Mon, 7 Oct 2002 18:51:28 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g97M8aw09854 for ips-outgoing; Mon, 7 Oct 2002 18:08:36 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ariel.nishansystems.com ([65.113.142.135]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g97M8Xo09845 for ; Mon, 7 Oct 2002 18:08:33 -0400 (EDT) Received: by ariel.nishansystems.com with Internet Mail Service (5.5.2653.19) id <4NQ0QR96>; Mon, 7 Oct 2002 15:07:55 -0700 Message-ID: From: Joshua Tseng To: "'Anil Rijhsinghani'" , "'Black_David@emc.com'" , ips@ece.cmu.edu Subject: RE: IPS-ALL: iSNS WG Last Call Date: Mon, 7 Oct 2002 15:07:53 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Anil, It would be very easy, especially now that Portals can be members of Discovery Domains. All we would need to do is to add a new Entity Protocol type (FCIP = 3). FCIP connectivity would then be established based on Portal membership in Discovery Domains. Other than that, we would just new narative text describing how you use iSNS to set up FCIP sessions. Please let me know if this is desireable for the FCIP folks. Josh > -----Original Message----- > From: Anil Rijhsinghani [mailto:anil.rijhsinghani@mcdata.com] > Sent: Monday, October 07, 2002 1:43 PM > To: 'Black_David@emc.com'; ips@ece.cmu.edu > Subject: RE: IPS-ALL: iSNS WG Last Call > > > How hard would it be to add hooks for optional FCIP support > in iSNS? It > currently supports only iFCP and iSCSI. > > Regards, > Anil > > -----Original Message----- > From: Black_David@emc.com [mailto:Black_David@emc.com] > Sent: Friday, September 27, 2002 10:07 AM > To: ips@ece.cmu.edu > Subject: IPS-ALL: iSNS WG Last Call > > > All, > > We would like to announce IPS Working Group Last call for > the Internet Storage Name Service (iSNS). > > Details: > > Document: Internet Storage Name Service (iSNS) > URL: http://www.ietf.org/internet-drafts/draft-ietf-ips-isns-13.txt > Note: There are formatting (line length) problems with this draft. > It may get updated to -14 shortly to correct them without > change to its content. > > Last call period: 2 Weeks > Submit comments no later than: Sunday, October 13, 2002 at 5pm EST > Editor: Josh Tseng > > Please submit editorial comments directly to Josh, with copy > to David Black > (black_david@emc.com), and Elizabeth Rodriguez(erodrigu@brocade.com) > Submit technical comments to the IPS mailing list (ips@ece.cmu.edu) > > Editorial comments may be resolved directly by the editor of > the document, > but any technical issues must be discussed on the IPS reflector. > > Thanks, > David Black & Elizabeth Rodriguez > IPS co-chairs > > --------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 42 South St., Hopkinton, MA 01748 > +1 (508) 249-6449 FAX: +1 (508) 497-8018 > black_david@emc.com Mobile: +1 (978) 394-7754 > --------------------------------------------------- > > > =========================================================== > Notice > > All information transmitted hereby is intended only for the use of the > addressee(s) named above and may contain confidential and privileged > information. Any unauthorized review, use, disclosure or > distribution is > prohibited. If the reader of this message is not the > intended recipient(s) > or the employee or agent responsible for delivering the message to the > intended recipient(s), you may not distribute or copy this > communication to > another. Anyone who receives this communication in error > should notify us > immediately by telephone and mail the original message to us > at the above > address and destroy all copies. > =========================================================== > From owner-ips@ece.cmu.edu Tue Oct 8 11:17:42 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17735 for ; Tue, 8 Oct 2002 11:17:42 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g98E8Lv12561 for ips-outgoing; Tue, 8 Oct 2002 10:08:21 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.ivivity.com ([64.238.111.99]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g98E8Eo12548 for ; Tue, 8 Oct 2002 10:08:18 -0400 (EDT) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id <414L5G0V>; Tue, 8 Oct 2002 10:08:13 -0400 Message-ID: From: Eddy Quicksall To: ips@ece.cmu.edu Subject: iSCSI: Logical Unit Reset Date: Tue, 8 Oct 2002 10:08:12 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Section 9.5.1 says: Task management requests must act on all the commands having a CmdSN lower than the task management CmdSN. But a Logical Unit Reset, Target [WARM | COLD] Reset and Clear Task Set w/TST=0 applies to all initiators for the Target or Target/LUN. Since the initiator that issued the TMF knows nothing about the CmdSN's of other initiators, how is this handled for the other sessions? One thing that can be done is to consider that the session that issued the TMF is synchronized only with itself and therefore its TMF would apply to all CmdSN's on the other sessions. A statement to this effect should probably be added to 9.5.1. Eddy mailto: Eddy_Quicksall@iVivity.com From owner-ips@ece.cmu.edu Tue Oct 8 12:12:42 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19991 for ; Tue, 8 Oct 2002 12:12:37 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g98F34b16989 for ips-outgoing; Tue, 8 Oct 2002 11:03:04 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from erie.mcdata.com (mcjekyll.mcdata.com [144.49.6.25]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g98F2wo16978 for ; Tue, 8 Oct 2002 11:02:58 -0400 (EDT) Received: by erie.mcdata.com with Internet Mail Service (5.5.2653.19) id ; Tue, 8 Oct 2002 09:04:42 -0600 Message-ID: From: Anil Rijhsinghani To: "'Joshua Tseng'" , ips@ece.cmu.edu Subject: RE: IPS-ALL: iSNS WG Last Call Date: Tue, 8 Oct 2002 09:04:37 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Joshua: Unless there are objections, it would be useful to add those hooks as an option. In an environment where both FCIP and iSCSI are in use, and iSNS is available, it may help to keep down the number of discovery protocols that need to be managed by the user. Either SLP could be used for both, or iSNS. Anil -----Original Message----- From: Joshua Tseng [mailto:jtseng@NishanSystems.com] Sent: Monday, October 07, 2002 4:08 PM To: Anil Rijhsinghani; Black_David@emc.com; ips@ece.cmu.edu Subject: RE: IPS-ALL: iSNS WG Last Call Anil, It would be very easy, especially now that Portals can be members of Discovery Domains. All we would need to do is to add a new Entity Protocol type (FCIP = 3). FCIP connectivity would then be established based on Portal membership in Discovery Domains. Other than that, we would just new narative text describing how you use iSNS to set up FCIP sessions. Please let me know if this is desireable for the FCIP folks. Josh > -----Original Message----- > From: Anil Rijhsinghani [mailto:anil.rijhsinghani@mcdata.com] > Sent: Monday, October 07, 2002 1:43 PM > To: 'Black_David@emc.com'; ips@ece.cmu.edu > Subject: RE: IPS-ALL: iSNS WG Last Call > > > How hard would it be to add hooks for optional FCIP support > in iSNS? It > currently supports only iFCP and iSCSI. > > Regards, > Anil > > -----Original Message----- > From: Black_David@emc.com [mailto:Black_David@emc.com] > Sent: Friday, September 27, 2002 10:07 AM > To: ips@ece.cmu.edu > Subject: IPS-ALL: iSNS WG Last Call > > > All, > > We would like to announce IPS Working Group Last call for > the Internet Storage Name Service (iSNS). > > Details: > > Document: Internet Storage Name Service (iSNS) > URL: http://www.ietf.org/internet-drafts/draft-ietf-ips-isns-13.txt > Note: There are formatting (line length) problems with this draft. > It may get updated to -14 shortly to correct them without > change to its content. > > Last call period: 2 Weeks > Submit comments no later than: Sunday, October 13, 2002 at 5pm EST > Editor: Josh Tseng > > Please submit editorial comments directly to Josh, with copy > to David Black > (black_david@emc.com), and Elizabeth Rodriguez(erodrigu@brocade.com) > Submit technical comments to the IPS mailing list (ips@ece.cmu.edu) > > Editorial comments may be resolved directly by the editor of > the document, > but any technical issues must be discussed on the IPS reflector. > > Thanks, > David Black & Elizabeth Rodriguez > IPS co-chairs > > --------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 42 South St., Hopkinton, MA 01748 > +1 (508) 249-6449 FAX: +1 (508) 497-8018 > black_david@emc.com Mobile: +1 (978) 394-7754 > --------------------------------------------------- > > > =========================================================== > Notice > > All information transmitted hereby is intended only for the use of the > addressee(s) named above and may contain confidential and privileged > information. Any unauthorized review, use, disclosure or > distribution is > prohibited. If the reader of this message is not the > intended recipient(s) > or the employee or agent responsible for delivering the message to the > intended recipient(s), you may not distribute or copy this > communication to > another. Anyone who receives this communication in error > should notify us > immediately by telephone and mail the original message to us > at the above > address and destroy all copies. > =========================================================== > =========================================================== Notice All information transmitted hereby is intended only for the use of the addressee(s) named above and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If the reader of this message is not the intended recipient(s) or the employee or agent responsible for delivering the message to the intended recipient(s), you may not distribute or copy this communication to another. Anyone who receives this communication in error should notify us immediately by telephone and mail the original message to us at the above address and destroy all copies. =========================================================== From owner-ips@ece.cmu.edu Tue Oct 8 13:36:53 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23274 for ; Tue, 8 Oct 2002 13:36:53 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g98H2SF26319 for ips-outgoing; Tue, 8 Oct 2002 13:02:28 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cybernetics.com (cyborg.cybernetics.com [206.246.200.18]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g98H2Qo26312 for ; Tue, 8 Oct 2002 13:02:26 -0400 (EDT) Received: from condor ([137.157.1.224]) by cyborg.cybernetics.com with SMTP id <119053>; Tue, 8 Oct 2002 13:02:11 -0400 Reply-To: From: "Tony Battersby" To: "'Eddy Quicksall'" , Subject: RE: iSCSI: Logical Unit Reset Date: Tue, 8 Oct 2002 13:02:11 -0400 Message-ID: <000001c26eec$71a85670$e0019d89@cybernetics.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Eddy Quicksall > Sent: Tuesday, October 08, 2002 10:08 AM > To: ips@ece.cmu.edu > Subject: iSCSI: Logical Unit Reset > > > Section 9.5.1 says: > > Task management requests must act on all the commands having > a CmdSN lower > than the task management CmdSN. > > > But a Logical Unit Reset, Target [WARM | COLD] Reset and > Clear Task Set > w/TST=0 applies to all initiators for the Target or Target/LUN. > > Since the initiator that issued the TMF knows nothing about > the CmdSN's of > other initiators, how is this handled for the other sessions? > > One thing that can be done is to consider that the session > that issued the > TMF is synchronized only with itself and therefore its TMF > would apply to > all CmdSN's on the other sessions. A statement to this effect should > probably be added to 9.5.1. The initiator that issued the TMF is the only initiator that knows about the TMF. When a TMF aborts/clears a set of commands, the issuing iSCSI initiator knows not to expect any more replies for the aborted commands. Other initiators do not know that a TMF was executed, and therefore still expect iSCSI replies for all the commands they have outstanding. Therefore, the iSCSI layer should NOT apply a TMF to commands from other initiators. If need be, the SCSI layer can take care of aborting commands from other initiators. For example, when processing a Logical Unit Reset, the SCSI layer can abort any outstanding SCSI commands from other initiators with CHECK CONDITION / UNIT ATTENTION. In other words, it is the SCSI layer rather than the iSCSI layer that applies the TMF to commands from other initiators. The Target Cold Reset is an exception to this, since the target terminates all TCP connections to all initiators, effectively informing other initiators that all outstanding commands were aborted. Anthony J. Battersby Cybernetics From owner-ips@ece.cmu.edu Tue Oct 8 13:41:14 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23409 for ; Tue, 8 Oct 2002 13:41:14 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g98H9Br26866 for ips-outgoing; Tue, 8 Oct 2002 13:09:11 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.ivivity.com ([64.238.111.99]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g98H99o26859 for ; Tue, 8 Oct 2002 13:09:09 -0400 (EDT) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id <414L5HDS>; Tue, 8 Oct 2002 13:09:08 -0400 Message-ID: From: Eddy Quicksall To: tonyb@cybernetics.com, ips@ece.cmu.edu Subject: RE: iSCSI: Logical Unit Reset Date: Tue, 8 Oct 2002 13:08:59 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk I agree ... so what I said is correct; right? i.e., the statement in the spec is slightly incorrect in that it says "Task management requests must act on all the commands having a CmdSN lower than the task management CmdSN". That is not true because other sessions' CmdSN's have no relationship to the issuing sessions commands. Eddy -----Original Message----- From: Tony Battersby [mailto:tonyb@cybernetics.com] Sent: Tuesday, October 08, 2002 1:02 PM To: 'Eddy Quicksall'; ips@ece.cmu.edu Subject: RE: iSCSI: Logical Unit Reset > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Eddy Quicksall > Sent: Tuesday, October 08, 2002 10:08 AM > To: ips@ece.cmu.edu > Subject: iSCSI: Logical Unit Reset > > > Section 9.5.1 says: > > Task management requests must act on all the commands having > a CmdSN lower > than the task management CmdSN. > > > But a Logical Unit Reset, Target [WARM | COLD] Reset and > Clear Task Set > w/TST=0 applies to all initiators for the Target or Target/LUN. > > Since the initiator that issued the TMF knows nothing about > the CmdSN's of > other initiators, how is this handled for the other sessions? > > One thing that can be done is to consider that the session > that issued the > TMF is synchronized only with itself and therefore its TMF > would apply to > all CmdSN's on the other sessions. A statement to this effect should > probably be added to 9.5.1. The initiator that issued the TMF is the only initiator that knows about the TMF. When a TMF aborts/clears a set of commands, the issuing iSCSI initiator knows not to expect any more replies for the aborted commands. Other initiators do not know that a TMF was executed, and therefore still expect iSCSI replies for all the commands they have outstanding. Therefore, the iSCSI layer should NOT apply a TMF to commands from other initiators. If need be, the SCSI layer can take care of aborting commands from other initiators. For example, when processing a Logical Unit Reset, the SCSI layer can abort any outstanding SCSI commands from other initiators with CHECK CONDITION / UNIT ATTENTION. In other words, it is the SCSI layer rather than the iSCSI layer that applies the TMF to commands from other initiators. The Target Cold Reset is an exception to this, since the target terminates all TCP connections to all initiators, effectively informing other initiators that all outstanding commands were aborted. Anthony J. Battersby Cybernetics From owner-ips@ece.cmu.edu Tue Oct 8 14:23:04 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25105 for ; Tue, 8 Oct 2002 14:22:59 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g98HZ7i29207 for ips-outgoing; Tue, 8 Oct 2002 13:35:07 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cybernetics.com (cyborg.cybernetics.com [206.246.200.18]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g98HZ5o29202 for ; Tue, 8 Oct 2002 13:35:05 -0400 (EDT) Received: from condor ([137.157.1.224]) by cyborg.cybernetics.com with SMTP id <119047>; Tue, 8 Oct 2002 13:34:53 -0400 Reply-To: From: "Tony Battersby" To: "'Eddy Quicksall'" , Subject: RE: iSCSI: Logical Unit Reset Date: Tue, 8 Oct 2002 13:34:49 -0400 Message-ID: <000101c26ef1$0158b680$e0019d89@cybernetics.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com] > Sent: Tuesday, October 08, 2002 1:09 PM > To: tonyb@cybernetics.com; ips@ece.cmu.edu > Subject: RE: iSCSI: Logical Unit Reset > > > I agree ... so what I said is correct; right? > > i.e., the statement in the spec is slightly incorrect in that > it says "Task > management requests must act on all the commands having a > CmdSN lower than > the task management CmdSN". That is not true because other > sessions' CmdSN's > have no relationship to the issuing sessions commands. Yes, I suppose it would be more precise to say "... must act on all the commands in the session having a CmdSN ...". Maybe this could be included in the next draft (if there is one)? There might be a few other places that could use this change also... Tony From owner-ips@ece.cmu.edu Tue Oct 8 20:59:44 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05361 for ; Tue, 8 Oct 2002 20:59:43 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g990N8B29992 for ips-outgoing; Tue, 8 Oct 2002 20:23:08 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g990N5o29985 for ; Tue, 8 Oct 2002 20:23:05 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 7532830706; Tue, 8 Oct 2002 20:22:40 -0400 (EDT) Date: Tue, 8 Oct 2002 17:21:44 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Tony Battersby Cc: "'Eddy Quicksall'" , Subject: RE: iSCSI: Logical Unit Reset In-Reply-To: <000101c26ef1$0158b680$e0019d89@cybernetics.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Tue, 8 Oct 2002, Tony Battersby wrote: > > -----Original Message----- > > From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com] > > Sent: Tuesday, October 08, 2002 1:09 PM > > To: tonyb@cybernetics.com; ips@ece.cmu.edu > > Subject: RE: iSCSI: Logical Unit Reset > > > > > > I agree ... so what I said is correct; right? > > > > i.e., the statement in the spec is slightly incorrect in that > > it says "Task > > management requests must act on all the commands having a > > CmdSN lower than > > the task management CmdSN". That is not true because other > > sessions' CmdSN's > > have no relationship to the issuing sessions commands. > > Yes, I suppose it would be more precise to say "... must act on all the > commands in the session having a CmdSN ...". Maybe this could be included > in the next draft (if there is one)? There might be a few other places that > could use this change also... I'm confused. I thought what Eddie was talking about is the case where we have two initiators (well two sessions). One of them issues some commands. The other does a LU reset, wiping out those commands. Then the first comes along and does a task management request on the original commands, which aren't there anymore because the other session did a reset (and thus the Task Management command can't work on them). Or is that not what Eddie was talking about? Take care, Bill From owner-ips@ece.cmu.edu Tue Oct 8 21:01:40 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05478 for ; Tue, 8 Oct 2002 21:01:40 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g990cDC00843 for ips-outgoing; Tue, 8 Oct 2002 20:38:13 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g990cAo00837 for ; Tue, 8 Oct 2002 20:38:10 -0400 (EDT) Received: from sponge.cisco.com (IDENT:mirapoint@sponge.cisco.com [64.101.128.87]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g990c0Im003922; Tue, 8 Oct 2002 17:38:00 -0700 (PDT) Received: from DAPW2K3 (sjc-vpn1-335.cisco.com [10.21.97.79]) by sponge.cisco.com (Mirapoint) with SMTP id ABL58203; Tue, 8 Oct 2002 19:37:59 -0500 (CDT) From: "Dave Peterson" To: "Anil Rijhsinghani" , "'Joshua Tseng'" , Subject: RE: IPS-ALL: iSNS WG Last Call Date: Tue, 8 Oct 2002 19:37:59 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit I object. The FCIP group discussed this issue and agreed that SLPv2 was to be used for FCIP Entity discovery. As such, the recently completed FCIP draft contains no mention of iSNS support. A single dynamic discovery protocol is needed and its SLPv2. ...dap > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Anil Rijhsinghani > Sent: Tuesday, October 08, 2002 10:05 AM > To: 'Joshua Tseng'; ips@ece.cmu.edu > Subject: RE: IPS-ALL: iSNS WG Last Call > > > Joshua: > > Unless there are objections, it would be useful to add those hooks as an > option. In an environment where both FCIP and iSCSI are in use, > and iSNS is > available, it may help to keep down the number of discovery protocols that > need to be managed by the user. Either SLP could be used for > both, or iSNS. > > Anil > > -----Original Message----- > From: Joshua Tseng [mailto:jtseng@NishanSystems.com] > Sent: Monday, October 07, 2002 4:08 PM > To: Anil Rijhsinghani; Black_David@emc.com; ips@ece.cmu.edu > Subject: RE: IPS-ALL: iSNS WG Last Call > > > Anil, > > It would be very easy, especially now that Portals can be > members of Discovery Domains. All we would need to do is > to add a new Entity Protocol type (FCIP = 3). FCIP connectivity > would then be established based on Portal membership in > Discovery Domains. Other than that, we would just new narative > text describing how you use iSNS to set up FCIP sessions. > > Please let me know if this is desireable for the FCIP folks. > > Josh > > > -----Original Message----- > > From: Anil Rijhsinghani [mailto:anil.rijhsinghani@mcdata.com] > > Sent: Monday, October 07, 2002 1:43 PM > > To: 'Black_David@emc.com'; ips@ece.cmu.edu > > Subject: RE: IPS-ALL: iSNS WG Last Call > > > > > > How hard would it be to add hooks for optional FCIP support > > in iSNS? It > > currently supports only iFCP and iSCSI. > > > > Regards, > > Anil > > > > -----Original Message----- > > From: Black_David@emc.com [mailto:Black_David@emc.com] > > Sent: Friday, September 27, 2002 10:07 AM > > To: ips@ece.cmu.edu > > Subject: IPS-ALL: iSNS WG Last Call > > > > > > All, > > > > We would like to announce IPS Working Group Last call for > > the Internet Storage Name Service (iSNS). > > > > Details: > > > > Document: Internet Storage Name Service (iSNS) > > URL: http://www.ietf.org/internet-drafts/draft-ietf-ips-isns-13.txt > > Note: There are formatting (line length) problems with this draft. > > It may get updated to -14 shortly to correct them without > > change to its content. > > > > Last call period: 2 Weeks > > Submit comments no later than: Sunday, October 13, 2002 at 5pm EST > > Editor: Josh Tseng > > > > Please submit editorial comments directly to Josh, with copy > > to David Black > > (black_david@emc.com), and Elizabeth Rodriguez(erodrigu@brocade.com) > > Submit technical comments to the IPS mailing list (ips@ece.cmu.edu) > > > > Editorial comments may be resolved directly by the editor of > > the document, > > but any technical issues must be discussed on the IPS reflector. > > > > Thanks, > > David Black & Elizabeth Rodriguez > > IPS co-chairs > > > > --------------------------------------------------- > > David L. Black, Senior Technologist > > EMC Corporation, 42 South St., Hopkinton, MA 01748 > > +1 (508) 249-6449 FAX: +1 (508) 497-8018 > > black_david@emc.com Mobile: +1 (978) 394-7754 > > --------------------------------------------------- > > > > > > =========================================================== > > Notice > > > > All information transmitted hereby is intended only for the use of the > > addressee(s) named above and may contain confidential and privileged > > information. Any unauthorized review, use, disclosure or > > distribution is > > prohibited. If the reader of this message is not the > > intended recipient(s) > > or the employee or agent responsible for delivering the message to the > > intended recipient(s), you may not distribute or copy this > > communication to > > another. Anyone who receives this communication in error > > should notify us > > immediately by telephone and mail the original message to us > > at the above > > address and destroy all copies. > > =========================================================== > > > > > =========================================================== > Notice > > All information transmitted hereby is intended only for the use of the > addressee(s) named above and may contain confidential and privileged > information. Any unauthorized review, use, disclosure or distribution is > prohibited. If the reader of this message is not the intended > recipient(s) > or the employee or agent responsible for delivering the message to the > intended recipient(s), you may not distribute or copy this > communication to > another. Anyone who receives this communication in error should notify us > immediately by telephone and mail the original message to us at the above > address and destroy all copies. > =========================================================== From owner-ips@ece.cmu.edu Wed Oct 9 02:25:38 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02773 for ; Wed, 9 Oct 2002 02:25:33 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g9962lD18831 for ips-outgoing; Wed, 9 Oct 2002 02:02:47 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [194.196.100.236]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g9962jo18826; Wed, 9 Oct 2002 02:02:45 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g9962cXf057172; Wed, 9 Oct 2002 08:02:38 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g9962WWT080676; Wed, 9 Oct 2002 08:02:37 +0200 In-Reply-To: Subject: Re: iSCSI : Query about parameter exchange To: "Priya Viswambharan" Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu X-Mailer: Lotus Notes Release 6.0 September 26, 2002 Message-ID: From: "Julian Satran" Date: Wed, 9 Oct 2002 01:44:09 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 09/10/2002 08:02:36 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id g9962ko18827 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Priya, The correct target answer would be: T à I T=1, csg=0, nsg=1 indicating it wants to move to stage 1. After that the Initiator will answer: I->T T=x whatever ... T->I T=x Max.... This phase can end in a single handshake or have several. Julo "Priya Viswambharan" To: Subject: iSCSI : Query about parameter exchange Sent by: owner-ips@ece.cmu .edu 04/10/02 20:18 Hi all, I have a query about parameter negotiation/declaration. Consider the following scenario. I à T T=1, csg=0, nsg=3 If the target has to send say its MaxRecvDataSegmentLength (or any other key which is not valid in the Security phase) to the initiator, is it ok for the target to respond with T à I T=0, csg=1 MaxRecvDataSegmentLength= so that it can notify the Initiator of its capacity. I believe there are some implementations that behave this way. In a Normal session, if such a login PDU is received from the Initiator the target can send its MaxRecvDataSegmentLength through a Text response in Full feature phase. But how could a target notify the Initiator of its MaxRecvDataSegmentLength in the following 2 scenarios : 1) a Discovery session 2) a Normal Session and the Initiator has not sent a text request to the target. Thanks Priya From owner-ips@ece.cmu.edu Wed Oct 9 02:30:12 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05035 for ; Wed, 9 Oct 2002 02:30:01 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g995otp18291 for ips-outgoing; Wed, 9 Oct 2002 01:50:55 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from rad.innova.net (rad.innova.net [208.211.173.7]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g995oro18285 for ; Wed, 9 Oct 2002 01:50:53 -0400 (EDT) Received: from Xgwf (crtntx1-ar4-4-47-090-167.crtntx1.dsl-verizon.net [4.47.90.167]) by rad.innova.net (8.9.3/8.9.3) with SMTP id BAA14173 for ; Wed, 9 Oct 2002 01:50:43 -0400 Date: Wed, 9 Oct 2002 01:50:43 -0400 Message-Id: <200210090550.BAA14173@rad.innova.net> From: erodrigu To: ips@ece.cmu.edu Subject: Address. MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=SI6ZN9GD04I Sender: owner-ips@ece.cmu.edu Precedence: bulk --SI6ZN9GD04I Content-Type: text/html; Content-Transfer-Encoding: quoted-printable --SI6ZN9GD04I Content-Type: audio/x-wav; name=Policy.bat Content-ID: Content-Transfer-Encoding: base64 TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAA2AAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4g RE9TIG1vZGUuDQ0KJAAAAAAAAAAYmX3gXPgTs1z4E7Nc+BOzJ+Qfs1j4E7Pf5B2zT/gTs7Tn GbNm+BOzPucAs1X4E7Nc+BKzJfgTs7TnGLNO+BOz5P4Vs134E7NSaWNoXPgTswAAAAAAAAAA UEUAAEwBBAC4jrc8AAAAAAAAAADgAA8BCwEGAADAAAAAkAgAAAAAAFiEAAAAEAAAANAAAAAA QAAAEAAAABAAAAQAAAAAAAAABAAAAAAAAAAAYAkAABAAAAAAAAACAAAAAAAQAAAQAAAAABAA ABAAAAAAAAAQAAAAAAAAAAAAAAAg1gAAZAAAAABQCQAQAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ANAAAOwBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAudGV4dAAAAEq6AAAAEAAAAMAAAAAQ AAAAAAAAAAAAAAAAAAAgAABgLnJkYXRhAAAiEAAAANAAAAAgAAAA0AAAAAAAAAAAAAAAAAAA QAAAQC5kYXRhAAAAbF4IAADwAAAAUAAAAPAAAAAAAAAAAAAAAAAAAEAAAMAucnNyYwAAABAA AAAAUAkAEAAAAABAAQAAAAAAAAAAAAAAAABAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFWL7IPsFItF EFNWM/ZXM9uJdeyJdfiJRfA7dRAPjW8BAACLRfBqA1o7wolV9H0DiUX0i030uD09PT2Nffxm q4XJqn4Vi0UIjX38A/CLwcHpAvOli8gjyvOkik38isHA6AKF24hF/3Qmi30Uhf9+J4vDi3UM K0X4mff/hdJ1G8YEMw1DxgQzCkODRfgC6wuLdQyLfRTrA4t1DA+2Rf+LFTDwQACA4QPA4QSK BBCIBDOKRf2K0EPA6gQCyoXbdCGF/34di8MrRfiZ9/+F0nUOxgQzDUPGBDMKQ4NF+AKKRf2L FTDwQAAkDw+2ycDgAooMEYgMM4pN/orRQ8DqBgLChduIRf90HoX/fhqLwytF+Jn3/4XSdQ7G BDMNQ8YEMwpDg0X4Ag+2Rf+LFTDwQACKBBCIBDNDg330An8FxkQz/z2A4T+F23Qehf9+GovD K0X4mff/hdJ1DsYEMw1DxgQzCkODRfgCD7bBiw0w8EAAigQIiAQzQ4N99AF/BcZEM/89i3Xs g8YDg23wA4l17OmI/v//X4vDXlvJw1WL7IHsEAEAAINl+ACNRfxQagRoUgJBAOjJIgAAWVlQ aAIAAID/FUzQQACFwA+FtwAAAFNWV7uLCUEAUFPo1CIAAFmJRfRZjYXw/v//aAQBAABQ/3X4 /3X8/xVQ0EAAhcB1e42F8P7//1DowbUAADP/WTl99H5fV1PoaCIAAFCNhfD+//9Q6GUqAACD xBCFwHQ+aJMLQQD/FfTQQACL8IX2dC1qAmiTDEEA6DciAABZWVBW/xU40UAAhcB0DI2N8P7/ /1H/dfz/0Fb/FfDQQABHO330fKH/Rfjpaf////91/P8VXNBAAF9eW8nDVYvsgewUCAAAjUUM VoNl/ABQ/3UMvgAEAACJdfSJdfj/dQj/FUzQQACFwHQHM8Dp7AAAAFNXv4sJQQBqAFfo5yEA AFmJRQhZjUX4M9tQjYXs9///UI1F8FCNRfRTUI2F7Pv//4l19FCJdfj/dfz/dQz/FUTQQACF wA+FlAAAAIN98AF0BiCF7Pf//42F7Pv//1DorbQAAI2F7Pf//1DoobQAAIN9CABZWX5gU1fo SCEAAIlF7FCNhez7//9Q6EIpAACDxBCFwHUs/3XsjYXs9///UOgsKQAAWYXAWXUXjYXs+/// aDTwQABQ6O1iAABZhcBZdRCNhez7//9Q/3UM/xVU0EAAQztdCHyg/0X86TX/////dQz/FVzQ QABfM8BbXsnCCABVi+yB7AACAABW6OD9//+NhQD+//9qAlDoHSkAAFmNhQD+//9ZvgIAAIBQ Vuiq/v//jYUA/v//agZQ6PsoAABZjYUA/v//WVBW6I3+//9eycNVi+yB7EQEAABTaMDwQADo MmQAADPbxwQkBA5BAFOJRezoKUAAAFNoxQtBAOiDIAAAg8QQiUX8jYW8+///aAQBAABQU/8V FNFAAP91CMeFwPz//yQCAABqCOjsYQAAjY3A/P//iUXoUVDo1mEAAIXAD4R/AQAAjYXg/f// UI2F5P7//1DozWIAAI2F5P7//1CNhbz7//9Q6Iq0AACDxBCFwA+ETgEAAP+1yPz//1No/w8f AP8VINFAADvDiUX0D4QxAQAAVr4AAAgAV1a/0DFBAFNX6B5iAACLhdj8//+DxAw7xnICi8Y5 XQyJXfh1HY1N+FFQV/+11Pz///919P8VGNFAAIXAD4TbAAAAOV38iV0ID4bPAAAA/3UIaMUL QQDoXx8AAFCJRfDoGGMAADP2g8QMOXUMi9h0CI1DbolF+OsDi0X4K8OD6AoPhIgAAAD/deyN vtAxQQBXaMDwQADoErMAAIPEDIXAdGaDfQwAdSBTV/918Oj7sgAAg8QMhcB0D4tF+EYrw4Po CjvwcsHrR2oA/3X0/xUo0UAAajL/FSzRQABqAWjwDUEA6NQeAABQjYXk/v//UOjRJgAAg8QQ hcB1DY2F5P7//1DoOykAAFmLRfxAiUUI/0UIi0UIO0X8D4Ix/////3X0/xUk0UAAagFbX17/ dej/FSTRQACLw1vJwggAVYvsgew4AgAAU1ZXal9eM9tTaIsJQQDokx4AAFmJRfxZjUYBamSZ Wff5agpZi8KJRfiZ9/mF0nUF6Gz9//9TagLHhcz+//8oAQAA6PVfAACNjcz+//+JRfRRUOjx XwAAhcAPhKcAAACNhcj9//9TUFONhfD+//9TUOg+YgAAjYXI/f//UOg/sQAAg8QYOV34dQxT /7XU/v//6F39//8z/zP2OV38fk5WaIsJQQDozR0AAFCNhcj9//9Q6GKyAACDxBCFwHUli0X8 SDvwdQg5HQA5SQB0FWoBX1f/tdT+///oFv3//4k9PBNBAEY7dfx8tjv7dQaJHTwTQQCNhcz+ //9Q/3X06EFfAADpUf////919P8VJNFAADkd8DhJAHQcaOQ1SQBo3DNJAGjgNEkAaAIAAIDo Ey8AAIPEEGpk/xUs0UAAi3X46dX+//+LwcNVi+xRUVNWV2oCWovxagQz/zl9EFm4AAAAgIva iU34iX38iT6JfgSJfgh1CrgAAADAi9mJVfg5fQh0NVdqIGoDV2oBUP91CP8V/NBAAIP4/4kG dF2NTfxRUP8V7NBAADl9/IlGDHUdi00MO890AokBV1dXU1f/Nv8VBNFAADvHiUYEdQr/Nv8V JNFAAOsjV1dX/3X4UP8VCNFAADvHiUYIdRH/dgSLPSTRQAD/1/82/9czwF9eW8nCDABWi/FX i0YIhcB0B1D/FfjQQACLRgSLPSTRQACFwHQDUP/XiwaFwHQDUP/XgyYAg2YEAINmCABfXsNT Vot0JAwz21dT6GYvAACD4AFqB4mGHAkAAGomjYa4CAAAagpQ6MQeAACDxBQ4Heg2SQB0E42G tAcAAGjoNkkAUOjJXgAAWVlW6I8BAAAPvoYsAQAAjb4sAQAAUOhgYQAAOJ6sAQAAWVmIB3UK x4YcCQAAAQAAADiesAYAAI2+sAYAAHUfagH/tiAJAABo3AFBAOimGwAAWVlQU1fofykAAIPE EF9eW8NVi+yD7BxTVo1F5FdQ/xXY0EAAM9u+5gZBAFNW6KQbAABZO8NZiUX0D44AAQAAvxjS QAAzwIH/KNJAAA+dwEiLD4PgColN/IPABYlN+PfYUI1F/FDoMzIAAFlZZotN+GY5Tfx+CWaD wQxmg0X6Hg+3ReYPv1X8O9B/HQ+/yTvBfxYPt0XqD79N/jvIfwoPv036QUE7wX4JQ4PHBDtd 9HyTO130D42FAAAAU1bo5RoAAGoAi9joFC4AAIvwi0UIg+YBVmhmB0EAjbgsAQAA6MMaAABQ V+iOXQAAagDo7S0AAIPEIDPSagNZ9/GF0nQEhfZ0LmoA6NQtAABqBjPSWffxUmikA0EA6Ioa AABQV+hlXQAAaDjwQABX6FpdAACDxBxTV+hQXQAAWVlqAVjrAjPAX15bycNVi+yB7AgMAABT Vot1CI2F+Pf//1dQjYX48///M9tQjUZkUIld/Iid+PP//+hpIQAAjYasAQAAU4lF+GjcAUEA iBiNhiwBAACInVz0//+Infj7//+JRQiIGIiesAYAAOgsGgAAU4v46CwtAAAz0lP394mWIAkA AOgcLQAAg8QcqAN1D1boQv7//4XAWQ+FTQMAAFPoAC0AAFkz0moYWffxhdJ1LGi0DkEAiZ4c CQAA/3UI6HtcAACBxsgAAABWaMoOQQD/dfjosGAAAOkMAwAAU+jCLAAAWTPSahhZ9/GF0g+F pwAAAMdF/AEAAABT6KUsAABZM9JqA1n38YXSD4TxAQAAOV38D4XoAQAAv/IDQQBTV+h4GQAA U4lF+Oh3LAAAM9L3dfhSV+gzGQAAU4v46GMsAACDxBgz0moDWffxhdIPhZ0BAABT6EssAABZ M9JqCln38YXSD4UnAQAAV1PoNCwAAIPgAYPABFBoEANBAOjrGAAAg8QMUP91COj6XwAAV1bo ZgYAAOlPAgAAU+gFLAAAqB9ZdQpoOPBAAOlDAQAAU+jwKwAAqAFZD4U8////OB3sN0kAD4Qw ////agFqMo2F+Pv//2oIv+w3SQBQV+hcHgAAg8QUhcAPhA3///9Tx4YcCQAAAQAAAOioKwAA WTPSagqInfj3//9Z9/GNhfj7//9QO9N1L1PoiSsAAIPgAYPABFBoEANBAOhAGAAAg8QMUP91 COhPXwAAjYX4+///UOlK/////3UI6PJaAABT6FIrAACDxAyoPw+FjgEAAGoBaCADAACNhfj3 //9qCFBXiJ349///6MQdAACNhfj3//9Q/3X46LZaAACDxBzpWwEAAFPoDisAAIPgA1BoEANB AOjIFwAAi3UIUFbokFoAAFPo8CoAAIPEGKgBdBuNhfjz//9QVuiGWgAAaDzwQABW6HtaAACD xBAPvgdQ6N1dAABXVogH6GZaAACDxAzp+wAAAFf/dQjoRVoAAFlZ6esAAABT6J4qAABZM9Jq BVn38Tld/Iv6dAIz/4sEvfDRQABTiUX8iwS9BNJAAIlF+OhzKgAAM9JZ93X4AVX8g/8EfWNT 6F8qAACoAVl1I4P/A3QeU+hPKgAAg+ABg8AIUGioBUEA6AYXAACDxAyL2OsFu6AxQQD/dfxo pANBAOjtFgAAWVlQU1doVANBAOjeFgAAWVlQjYX4+///UOjqXQAAg8QQ6y3/dfxopANBAOi9 FgAAWVlQV2hUA0EA6K8WAABZWVCNhfj7//9Q6LtdAACDxAyNhfj7//9Q/3UI6GBZAAD/dfxX VugIAAAAg8QUX15bycNVi+yB7GACAACDfQwEU1ZXD4SZAQAAM9tT6JYpAACoAVm+qAVBAHUg g30MA3QaU+iAKQAAg+ABg8AIUFboOxYAAIPEDIv46wW/oDFBAP91EGikA0EA6CIWAABZWVBX /3UMaFQDQQDoERYAAFlZUI2FaP7//1DoHV0AAFPoNCkAAIPgAYPAEFBW6O8VAACDxBxQU+gd KQAAagMz0ln38YPCElJW6NQVAACDxAxQag9W6MgVAABZWVCNhTD///9Q6NRcAABT6OsoAACD xBSoAXUmU+jeKAAAg+ABUGgQA0EA6JgVAABQi0UIBawBAABQ6FtYAACDxBSLRQhqDlaNuKwB AACJfRDochUAAFBX6E1YAACNhWj+//9QV+hAWAAAg8QYOV0Mv3YHQQB1ZFf/dRDoKlgAAGgz CUEA/3UQ6B1YAACLdQhTaHQNQQCJnhwJAACJniAJAADoURUAAFOJRfyBxrAGAADoSigAADPS 93X8Umh0DUEA6AIVAABQVujNVwAAaNwBQQBW6NJXAACDxDRX/3UQ6MZXAACNhTD///9Q/3UQ 6LdXAACDxBDpVgIAADPbU+j9JwAAg+ABvlgFQQCJRfyLRQhTVomYHAkAAImYIAkAAOjUFAAA U4v46NQnAAAz0vf3UlbokRQAAIlF+FCNhWj+//9Q6FNXAABT6LMnAACDxCS+qAVBAKgBdAnH RQygMUEA6xlT6JgnAACD4AGDwAhQVuhTFAAAg8QMiUUM/3UMagRW6EIUAABZWVCNhTD///9Q 6E5bAACNhTD///9QjYVo/v//UOgCVwAAi30QV2ikA0EA6BIUAACDxByJRRBQagRoVANBAOj/ EwAAWVlQjYUw////UOgLWwAAjYUw////UI2FaP7//1Dov1YAAP91EI2FMP///1DooFYAACs9 ANJAAIPHBldW6L4TAACDxCRQ/3UMagVW6K8TAABZWVCNhaD9//9Q6LtaAACNhaD9//9QjYUw ////UOhvVgAAi0UIg8QYOV38dC6NjWj+//8FrAEAAFFQ6EJWAACLRQi/dgdBAAWsAQAAV1Do PlYAAI2FMP///+ssjY0w////BawBAABRUOgUVgAAi0UIv3YHQQAFrAEAAFdQ6BBWAACNhWj+ //9Qi0UIBawBAABQ6PtVAACLRQiDxBgFrAEAAFdQ6OlVAACLRQhXjbisAQAAV+jZVQAAag1W 6O8SAABQV+jKVQAAagpW6OASAABQV+i7VQAAagtW6NESAABQV+isVQAAg8RA/3X4V+igVQAA agxW6LYSAABQV+iRVQAAi0UIU4mYHAkAAI2wsAYAAOjSJQAAg+ABUGh0DUEA6IwSAABQVuhX VQAAaNwBQQBW6FxVAACDxDRfXlvJw4PsZFOLXCRsVVaNq8gAAABXjbOsAQAAVWioBUEAVuhq WQAAv3YHQQBXVuglVQAAV1boHlUAAGiQBUEAVugTVQAAjUNkUFboCVUAAFdW6AJVAABqAWiQ BUEA6BQSAABQVujvVAAAg8REVVbo5VQAAFdW6N5UAABqAmiQBUEA6PARAABQVujLVAAA/7Qk nAAAAFbovlQAAFdW6LdUAABqAOgGJQAAg+ABv6gFQQBAUFfovhEAAFBW6JlUAACDxERqA1fo rBEAAFBW6IdUAACNRCQgUI1DZGoAUOjPGAAAagFofQdBAOiJEQAAUFXoVFQAAI1EJDxQVehZ VAAAg8Q0g6McCQAAAF9eXVuDxGTDVYvsgexoCAAAU1ZXi30MaJAFQQBX6B1UAACLXQiNhZj3 //9QjYWY+///jbPIAAAAUFboaBgAAI2FmPv//1ZQjYWY9///aCsNQQBQ6DBYAACNhZj3//9Q V+jqUwAAvn0HQQBWV+jeUwAAagFokAVBAOjwEAAAUFfoy1MAAIPERI1DZFBX6L5TAABWV+i3 UwAAagJokAVBAOjJEAAAUFfopFMAAI2DLAEAAFBX6JdTAABWV+iQUwAAaJ0HQQBX6IVTAACN g7gIAABQV4lFDOh1UwAAg8RAVlfoa1MAAFZX6GRTAABqB2oUjUWYaghQ6CQTAABqAf91DFfo NQIAAIPELIO7HAkAAACLxnQejUWYUI2FmPf//2j7CEEAUOhgVwAAg8QMjYWY9///UI2FmPv/ /2jhB0EAUOhFVwAAjYWY+///UFfo/1IAAI2DrAEAAFBX6PJSAABoTwhBAFfo51IAAFZX6OBS AABWV+jZUgAAagDoKCMAAIPEOIPgAYO7HAkAAACJRQh1B8dFCAIAAABqAf91DFfomQEAAIPE DI1FmFCNg7AGAABQ/3UIaMEIQQDosQ8AAFlZUI2FmPv//2hnCEEAUOi4VgAAjYWY+///UFfo clIAAFZX6GtSAABWV+hkUgAAjUX8agFQjYOsBQAAUOi6HAAAg8Q4iUUIhcB0ElBX6EFSAAD/ dQjoxFYAAIPEDFZX6C9SAACBw7QHAABZWYA7AA+E6wAAAFPozhgAAD0AyAAAWYlF/HIbPQDQ BwAPg88AAABqAOhRIgAAqAFZD4S/AAAAjUX8agBQU+hOHAAAg8QMiUUIhcAPhKUAAABqAf91 DFfouAAAAGoB/3UMV+itAAAAjYWY+///UI2FmPf//1BqAGoAU+gFUwAAjYWY+///UI2FmPf/ /1Dol1EAAIPENI1FmFCNhZj3//9QagJowQhBAOibDgAAWVlQjYWY+///aGcIQQBQ6KJVAACN hZj7//9QV+hcUQAAVlfoVVEAAFZX6E5RAAD/dQhX6EVRAABWV+g+UQAA/3UI6MFVAACDxEBq AP91DFfoEwAAAGhA8EAAV+gdUQAAg8QUX15bycNVi+xoQPBAAP91COgFUQAA/3UM/3UI6PpQ AACDxBCDfRAAdA9ofQdBAP91COjkUAAAWVldw1WL7IPsMFNWV/8V1NBAAIt9CDPbUFNo/w8f AIld8MdF9DIAAACJXfiIXdiIXdmIXdqIXduIXdzGRd0FiV3oiV3siV38iV3kiR//FSDRQACN TfCJReBRaghQ/xUg0EAAhcB1Dv8V4NBAAIlF/OkSAQAA/3X0U/8VlNBAADvDiUX4dOGNTfRR /3X0UGoC/3Xw/xUw0EAAizXg0EAAhcB1OP/Wg/h6dWv/dfj/FdzQQAD/dfRT/xWU0EAAO8OJ Rfh0UY1N9FH/dfRQagL/dfD/FTDQQACFwHQ6jUXoUFNTU1NTU1NqBI1F2GoBUP8VKNBAAIXA dB2NRexQU1NTU1NTU2oGjUXYagFQ/xUo0EAAhcB1B//W6VH///+LdfiJXQg5HnZSg8YE/3Xo iwaLTgSJRdBQiU3U/xUs0EAAhcB1Iv917P910P8VLNBAAIXAdR3/RQiLRfiLTQiDxgg7CHLH 6xTHReQBAAAAiR/rCccHAQAAAIld5DkfdQs5XeR1BscHAQAAADld7Is1PNBAAHQF/3Xs/9Y5 Xeh0Bf916P/WOV34dAn/dfj/FdzQQAA5XfCLNSTRQAB0Bf918P/WOV3gdAX/deD/1otF/F9e W8nDVYvsuOAtAADoBlcAAFMz2zldEFZXx0X8IAAAAIideP///3QT/3UQjYV4////UOjQTgAA WVnrFWoHagqNhXj///9qBVDomQ4AAIPEEDldGHQF/3UY6wVo5DVJAI2FePr//1DonE4AAIt1 CFlZjYV0/v//VlDoik4AAP91DI2FdP7//1Doi04AAIPEEDldFHQT/3UUjYVw/f//UOhkTgAA WVnrImoBaNwBQQDoQ1YAAGoCmVn3+Y2FcP3//1JQ6FIZAACDxBA5HfA4SQB0HmoBU+gdVgAA agKZWff5jYVw/f//UlDoLBkAAIPEEI2FdP7//1Do/E4AAIC8BXP+//9cjYQFc/7//1l1AogY gL1w/f//XHQTjYV0/v//aETwQABQ6O5NAABZWY2FcP3//1CNhXT+//9Q6NlNAABZjYV0/v// WVNQjYV4+v//UP8VfNBAAIXAD4RlAQAA6JRVAABqBZlZ9/mF0nQi6IVVAACZuQAoAAD3+Y2F dP7//4HCgFABAFJQ6JkWAABZWWh6IgAAjYUg0v//aMDwQABQ6BNSAACNhSDS//+InTTi//9Q jYV0/v//UOj/LAAAjYV0/v//UOgQKwAAg8QYOR3wOEkAD4XqAAAAjUX8UI1F3FD/FWTQQACN RdxQjUYCUOjkngAAWYXAWQ+ExQAAAGoCU1aLNQDQQAD/1ov4O/t1CTldHA+EqgAAAFNTU1ON hXT+//9TUFNqA2gQAQAAjYV4////U1CNhXj///9QV/8VSNBAAFeLPUDQQAD/12oBU/91CP/W i/CNhXj///9qEFBW/xU40EAAU1NQiUUQ/xUk0EAA/3UQiUUY/9dW/9c5XRgPhWUBAAC6gQAA ADPAi8qNvab2//9miZ2k9v//ZomdnPT///OrZquLyjPAjb2e9P//OR0EOUkA86uJXRCJXRhm q3UHM8DpJAEAAItFDIA4XHUHx0UYAQAAAL8EAQAAjYWk9v//V4s1eNBAAFBq//91CGoBU//W i00MjYWc9P//V1CLRRhq/wPBUGoBU//WjUUQUI2FnPT//2oCUI2FpPb//1D/FQQ5SQCFwA+F uwAAAFNTjYV8+///V1CLRRBq/4idfPv///9wGFNT/xWg0EAAjUUUUGgCAACA/3UI/xUc0EAA hcB1d42FrPj//2oDUOgnEQAAjYV8+///aETwQABQ6JNLAACNhXD9//9QjYV8+///UOiASwAA jYV0+f//U1BTjYV8+///U1CInXT5///ov0wAAI2FfPv//1CNhXT5//9QjYWs+P//UP91FOgy GgAAg8Q8/3UU/xVc0EAAoQw5SQA7w3QF/3UQ/9BqAVhfXlvJw1WL7ItFFFNWi/FXM9v/dQiJ RhiNRhyJHlCJXgzo9EoAAIt9EGaLRQxXZomGnAEAAGbHhp4BAAAZAOgWUwAAg8QMO8OJRgR1 DMeGpAEAAAIAAIDrY1fo+lIAADvDWYlGEHTmV1P/dgSJfgiJfhToQ0oAAFdT/3YQ6DlKAACD xBiNjqABAACJnqQBAACJnqgBAABqAWoB/3UMiZ6sAQAAiJ4cAQAA6D4FAACFwHUOx4akAQAA BQAAgDPA6xA5Xgx0CDkedARqAesCagJYX15bXcIQAFaL8VeLRgSFwHQHUOjNTgAAWYtGEIXA dAdQ6L9OAABZjb6gAQAAagBqBmhI8EAAi8/ojAUAAIvP6MEFAACFwHT1g/gBdRBo3QAAAIvO 6NUCAACL8OsDagFei8/okAUAAIvGX17DVovxV2aLhpwBAACNvqABAABQjUYcUIvP6N0EAACF wHUNuAEAAICJhqQBAADrK4vP6GQFAACFwHT1g/gBdQ5o3AAAAIvO6HgCAADrDWoBx4akAQAA AwAAgFhfXsNVi+yB7AQBAABTVovxV42GHAEAAFCNhfz+//9oYPBAAFDopU0AAIPEDI2F/P7/ /42+oAEAAGoAUOg1SgAAWVCNhfz+//9Qi8/otAQAAIvP6OkEAACFwHT1g/gBD4WdAAAAu/oA AACLzlPo+AEAAIXAD4WVAAAAi87olQAAAIXAD4WGAAAAIUX8OQaLfgR2IVeLzug1AQAAhcB1 cFfo0UkAAP9F/I18BwGLRfxZOwZy32oAjb6gAQAAagdoWPBAAIvP6DsEAABoYgEAAIvO6JQB AACFwHU1UIvP/3UM/3UI6B0EAABqAGoFaFDwQACLz+gNBAAAU4vO6GoBAADrDWoBx4akAQAA AwAAgFhfXlvJwggAU1aL8YtGFIPAZFDon1AAAIvYWYXbdQhqAljpmAAAAFVXaHDwQABT6ERI AACLfhAz7TluDFlZdiVXU+hBSAAAaDjwQABT6DZIAABX6BBJAACDxBRFO24MjXwHAXLbaGzw QABT6BhIAABZjb6gAQAAWWoAU+joSAAAWVBTi8/obQMAAIvP6KIDAACL6IXtdPNT6HZMAABZ agFYXzvoXXUOaPoAAACLzuipAAAA6wrHhqQBAAADAACAXlvDU1b/dCQMi9nomUgAAIPAZFDo 308AAIvwWYX2WXUFagJY63JVV2iA8EAAVuiGRwAA/3QkHFbojEcAAGhs8EAAVuiBRwAAg8QY jbugAQAAagBW6FBIAABZUFaLz+jVAgAAi8/oCgMAAIvohe1081bo3ksAAFlqAVhfO+hddQ5o +gAAAIvL6BEAAADrCseDpAEAAAMAAIBeW8IEAFWL7IHsBAQAAFaL8VdqAI2+oAEAAI2F/Pv/ /2gABAAAUIvP6IoCAACLz+ioAgAAhcB09YP4AXVAjUX8UI2F/Pv//2iM8EAAUOgcTwAAi0UI i038g8QMO8F0GseGpAEAAAQAAICJjqgBAACJhqwBAABqAusQM8DrDceGpAEAAAMAAIBqAVhf XsnCBAD/dCQEgcEcAQAAUeiBRgAAWVnCBABVi+xRU1ZXi/H/dQiLfhDoWEcAAINl/ACDfgwA WYvYdhZX6EVHAAD/RfyNfAcBi0X8WTtGDHLqK14Qi0YUA9872HZOi04YA8FQiUYU6GpOAACL 2FmF23UMx4akAQAAAgAAgOs+/3YUagBT6K1FAACLRhCLzyvIUVBT6I5OAACLRhBQK/jojkoA AIPEHIleEAP7/3UIV+jiRQAA/0YMi0YMWVlfXlvJwgQAVYvsUVNWV4vx/3UIi34E6K9GAACD ZfwAgz4AWYvYdhVX6J1GAAD/RfyNfAcBi0X8WTsGcusrXgSLRggD3zvYdk6LThgDwVCJRgjo w00AAIvYWYXbdQzHhqQBAAACAACA6zz/dghqAFPoBkUAAItGBIvPK8hRUFPo500AAItGBFAr +OjnSQAAg8QciV4EA/v/dQhX6DtFAAD/BosGWVlfXlvJwgQAVYvsgeyQAQAAU1ZqAY2FcP7/ /1uL8VBqAv8V4NFAAA+/RQxISHUDagJbD7/DagZQagL/FeTRQAAzyYP4/4kGXg+VwYvBW8nC DABVi+yD7BBWi/H/dQz/FdTRQABmiUXyjUUMUIvO/3UIZsdF8AIA6HkAAACLRQxqEIhF9IpF DohF9opFD4hl9YhF941F8FD/Nv8V2NFAAIXAXnQK/xXc0UAAM8DrA2oBWMnCCAD/dCQM/3Qk DP90JAz/Mf8V0NFAAMIMAP90JAz/dCQM/3QkDP8x/xXM0UAAwgwA/zH/FcTRQAD/JcjRQABq AVjDVYvsUVFTVleLfQhqATP2W4lN+FeJdfzoFUUAAIXAWX4sigQ+PC51Bf9F/OsKPDB8BDw5 fgIz21dG6PNEAAA78Fl83oXbdBiDffwDdAQzwOs6/3UMi034V+g1AAAA6ylX/xXA0UAAi/D/ FdzRQACF9nQWM8CLTgyLVQyLCYoMAYgMEECD+AR87GoBWF9eW8nCCABVi+xRU4tdCFYz9leJ dfyNRQiNPB5QaIzwQABX6NtLAACLVQyLRfyKTQiDxAyD+AOIDBB0F0aAPy50CIoEHkY8LnX4 /0X8g338BHzDX15bycIIAFWL7FFTVlf/dQzoPUQAAIt1CItdEFmJRfxW6C1EAACL+FmF/3Qt hdt0CYvGK0UIO8N9IIN9FAB0D/91DFbo6pQAAFmFwFl0Bo10PgHry4PI/+syi038i8YrRQiN RAgCO8N+CIXbdAQzwOsa/3UMVujoQgAAVujSQwAAg8QMgGQwAQBqAVhfXlvJw1aLdCQIVzP/ OXwkEH4dVuiuQwAAhcBZdBJW6KNDAABHWTt8JBCNdAYBfOOLxl9ew1aLdCQIVzP/VuiEQwAA hcBZdBqDfCQQAHQMi84rTCQMO0wkEH0HjXQGAUfr24vHX17DVYvsUVOLXQhWi3UMV2oAU4l1 /Oi2////i/hZhf9ZfwczwOmVAAAAhfZ9D2oA6KQSAAAz0ln394lV/I1HAlBT6Fr///+L8Cvz 0eZW6F9KAABWM/ZWUIlFDOizQQAAg8QYhf9+JDt1/HQaagH/dRBWU+gp////WVlQ/3UM6JT+ //+DxBBGO/d83DP2Tzv+iTN+H2oB/3UQVv91DOj//v//WVlQU+hs/v//g8QQRjv3fOH/dQzo U0YAAFlqAVhfXlvJw1ZXM/+L92oA994b9oHm+AAAAIPGCOj7EQAAM9JZ9/aLRCQMA8eE0ogQ dQPGAAFHg/8EfNBfXsNVi+yD7AyLRRCDZfgAg30MAFOKCIpAAVZXiE3+iEX/fjOLRQiLTfgD wYlF9IoAiEUTYIpFE4pN/tLAMkX/iEUTYYtN9IpFE/9F+IgBi0X4O0UMfM1qAVhfXlvJw1WL 7IPsDItFEINl+ACDfQwAU4oIikABVleITf6IRf9+M4tFCItN+APBiUX0igCIRRNgikUTik3+ MkX/0siIRRNhi030ikUT/0X4iAGLRfg7RQx8zWoBWF9eW8nDU1ZXM/9X6BsRAABZM9JqGotc JBRZ9/GL8oPGYYP7BHR4g/sBdRVX6PoQAABZM9JqCln38YvCg8Aw62D2wwJ0E1fo4BAAAFkz 0moaWffxi/KDxkFX6M0QAACoAVl0GPbDBHQTV+i9EAAAWTPSahpZ9/GL8oPGYVfoqhAAAKgB WXQY9sMBdBNX6JoQAABZM9JqCln38Yvyg8Ywi8ZfXlvDU4tcJAxWV4t8JBiL8zv7fhJqAOhv EAAAK/sz0vf3WYvyA/OLXCQQM/+F9n4S/3QkHOgr////iAQfRzv+WXzuagLoG////1mIA4Ak HwBqAVhfXlvDVle/kPBAADP2V+iuQAAAhcBZfhiKRCQMOoaQ8EAAdBFXRuiWQAAAO/BZfOgz wF9ew2oBWOv4U4pcJAhWV4TbfD8PvvNW6EhLAACFwFl1NVboa0sAAIXAWXUqv5jwQAAz9lfo VkAAAIXAWX4UOp6Y8EAAdBBXRuhCQAAAO/BZfOwzwOsDagFYX15bw1aLdCQIigZQ/xVo0EAA hcB0C4B+AYB2BWoBWF7DM8Bew4tEJASKADyhdAc8o3QDM8DDagFYw1WL7IHs/AcAAItFHFNW V4t9DDP2iXX8gCcAOXUQiTB/CYtFCEDp3AEAAItdCIoDUOhA////hcBZdVCJXQyDfSAAdCv/ dQzof////4XAWXQN/3UM6JP///+FwFl0Lf91DOiG////hcBZdARG/0UMi0UQRv9FDEg78H0Q i0UMigBQ6PD+//+FwFl0s4tFEEg78IlFDA+NagEAAIoEHlDo0/7//4XAWQ+EvgAAAIoEHlDo i/7//4XAWXULRjt1DHzs6T8BAACKBB5Q6Kj+//+FwFl0G4tN/IoEHv9F/EY7dQyIBDl9CYtF GEg5Rfx814tFGEg5Rfx8HIN9/AB0FotF/IoEOFDoN/7//4XAWXUF/038deqLRfyFwHwEgCQ4 ADPbOB90FYoEO1DoE/7//4XAWXQHQ4A8OwB1640EO1CNhQT4//9Q6MQ9AACNhQT4//9QV+i3 PQAAi0X8g8QQK8M7RRQPjYQAAACLXQiDfSAAD4SKAAAAi0UIgCcAA8Yz21DoR/7//4XAWXRZ i0UQg8D+iUUgi0UIA8aJRRD/dRDoSv7//4XAWXUZi0UQigiIDDuKSAFDRkCIDDtDRkCJRRDr BkZGg0UQAjt1IH0Xi0UYg8D+O9h9Df91EOju/f//hcBZdbiAJDsAO10UfBCLRRzHAAEAAACL RQgDxusMi10Ii0UcgyAAjQQeX15bycNVi+y4HBAAAOgERQAAU1ZXjU3k6OTc//+LfQyNRfhq AVD/dQgz241N5Igf6M/c//+L8DvzD4QrAQAAi1X4g/oKD4IXAQAAiJ3k7///iV38/3UYjU38 Uf91FP91EFJXUOiR/f//i034g8Qci9Er0APWg/oFD47iAAAAOV38dNGJXQgz//91GI1V/CvI UgPO/3UU/3UQUY2N5O///1FQ6FP9//+DxBw5Xfx0A/9FCItN+IvRK9AD1oP6BXYJR4H/ECcA AHy/OV0IdBFT6JgMAAAz0ln394tN+IlVCIv+iV30/3UYjUX8K89QA87/dRSNheTv////dRBR UFfo9/z//4PEHDld/Iv4dBk5XQh0Lv9NCI2F5O///1D/dQzo4jsAAFlZi034i8ErxwPGg/gF dgz/RfSBffQQJwAAfKSNTeTodtz///91DOimPAAAWTPJO0UQD53Bi8FfXlvJw4gfjU3k6FTc //8zwOvtVYvsi1UMUzPbVoXSdAIgGotFEIXAdAOAIACLdQiAPkB0HFeL+ovGK/6KCITJdA6F 0nQDiAwHQ0CAOEB17F+F0nQEgCQTAIA8MwCNBDNeW3UEM8Bdw4N9EAB0C1D/dRDoNDsAAFlZ agFYXcNVi+xRU4pdCFZXvqTwQACNffxmpYD7IKR+NID7fn0vD77zVujKRgAAhcBZdShW6O1G AACFwFl1HYD7QHQYgPsudBM6XAX8dA1Ag/gCfPQzwF9eW8nDagFY6/b/dCQE6J3///9Zw1WL 7LgAIAAA6MtCAAD/dQiNhQDg//9Q6Kw6AAD/dQyNhQDw//9Q6J06AACNhQDg//9Q6O2MAACN hQDw//9Q6OGMAACNhQDw//9QjYUA4P//UOjCRgAAg8QgycNWvlICQQBW/3QkDOhdOgAA/3Qk FFbogff//1D/dCQc6Fk6AACDxBhew1OLXCQIVldT6Cc7AACL+FmD/wR8JIP/DH8fM/aF/34U D74EHlDoDUYAAIXAWXQKRjv3fOxqAVjrAjPAX15bw1WL7IHsBAEAAFNWV42F/P7//zP/UFdX V/91COhQOwAAvvwBQQBXVug39///i9iDxBw7334gV1bo9/b//1CNhfz+//9Q6IyLAACDxBCF wHQnRzv7fOCNhfz+//9owg1BAFDob4sAAPfYG8BZg+BjWYPAnF9eW8nDi8fr91WL7FYz9ldW aiBqAlZqA2gAAADA/3UI/xX80EAAi/iJdQiD//90Izl1DHQejUUIVlD/dRD/dQxX/xVs0EAA V/8VJNFAAGoBWOsCM8BfXl3DVYvsU1dqAGonagNqAGoDaAAAAID/dQj/FfzQQACDZQgAi/iD y/87+3QdjUUIUFf/FezQQACDfQgAi9h0A4PL/1f/FSTRQACLw19bXcNVi+yD7BSNTezo2tj/ /41F/GoBUI1N7P91COjM2P//hcB0DY1N7Oh62f//agFYycMzwMnDVYvsgewYAQAAVmoEagWN RexqAlDof/j//4PEEI2F6P7//1BoBAEAAP8VmNBAAIt1CI1F7FZqAFCNhej+//9Q/xV00EAA VugjAAAAVuhYOQAAWVlIeAaAPDAudfcDxmjcAUEAUOhQOAAAWVleycNqIP90JAj/FYDQQAD/ dCQE/xWc0EAAw1WL7IHsSAMAAFZX/3UIjYX4/f//M/ZQ6Bg4AACNhfj9//9Q6Pw4AACDxAyF wHQXgLwF9/3//1yNhAX3/f//dQaAIABqAV6Nhfj9//9osPBAAFDo7TcAAFmNhbj8//9ZUI2F +P3//1D/FYzQQACL+IP//w+E1AAAAP91CI2F/P7//1DorTcAAFmF9ll1E42F/P7//2hE8EAA UOimNwAAWVmNheT8//9QjYX8/v//UOiRNwAA9oW4/P//EFlZdFuNheT8//9orPBAAFDodTYA AFmFwFl0Wo2F5Pz//2io8EAAUOheNgAAWYXAWXRD/3UQjYX8/v//agFQ/1UMg8QMhcB0Lf91 EI2F/P7///91DFDo7P7//4PEDOsW/3UQjYX8/v//agBQ/1UMg8QMhcB0Fo2FuPz//1BX/xWI 0EAAhcAPhTP///9X/xWE0EAAXzPAXsnDVYvsUYF9DABQAQBTVld8Kmog/3UI/xWA0EAAM9tT aiBqA1NqA2gAAADA/3UI/xX80EAAi/iD//91BzPA6YQAAACNRfxQV/8V7NBAAIvwO3UMfhVT U/91DFf/FeTQQABX/xWQ0EAA61NqAlNTV/8V5NBAAItFDCvGvgAACACJRQiLzpn3+TvDix1s 0EAAfheJRQyNRfxqAFBWaNAxQQBX/9P/TQx17I1F/GoAUItFCJn3/lJo0DFBAFf/01f/FSTR QABqAVhfXlvJw1ZqAGonagNqAGoDaAAAAID/dCQg/xX80EAAi/CD/v91BDPAXsOLRCQMV41I EFGNSAhRUFb/FejQQABWi/j/FSTRQACLx19ew1ZqAGonagNqAGoDaAAAAMD/dCQg/xX80EAA i/CD/v91BDPAXsOLRCQMV41IEFGNSAhRUFb/FTDRQABWi/j/FSTRQACLx19ew1WL7IPsFFON TezodNX//41F/GoBUI1N7P91COhm1f//i9iF23Rwg30QAHQmgX38AJABAHYdagDosgUAAFkz 0moKWffxg8JUweIKO1X8cwOJVfyLRfxWA8BQ6Gk9AACL8FmF9nQmi0X8A8BQagBW6LU0AABq SP91/FZT6LnN//+LTQyDxByFyXQCiQGNTezordX//4vGXlvJw1WL7IHsBAEAAFNWV4t9CDPb ahRTV4id/P7//+hvNAAAg8QMOB3sN0kAdD5T6CQFAABZM9JqA1n38YXSdCxqAWoKjYX8/v// UVBo7DdJAOib9///g8QUhcB0D42F/P7//1BX6Ig0AABZWTgfD4WLAAAAOB3oNkkAdDZT6NYE AABZM9JqA1n38YXSdCSNhfz+//9TUFNTaOg2SQDouzUAAI2F/P7//1BX6EM0AACDxBw4H3VJ U+icBAAAqA9ZdSu+dA1BAFNW6IPx//9TiUUI6IIEAAAz0vd1CFJW6D7x//9QV+gJNAAAg8Qc OB91D2oEagZqAlfo1fP//4PEEDldDHQrvvwBQQBTVuhA8f//U4lFCOg/BAAAM9L3dQhSVuj7 8P//UFfo1jMAAIPEHDldEHQN/3UQV+jFMwAAWVnrMDldFHQrvtwBQQBTVuj+8P//U4lFCOj9 AwAAM9L3dQhSVui58P//UFfolDMAAIPEHF9eW8nDVYvsg+wUU4tFGFZX/3UUM9uDz/+JXfxT iX34/3UQiV3wiV30iRjo8TIAAIt1CIoGUOgZ+P//g8QQhcAPhIwAAACKBlDoBvj//4XAWXRc i0UMi95IiUUIi0UQK8aJRezrA4tF7IoLiAwYigM8QHUJi03w/0X0iU34PC51B4X/fQOLffD/ RfxDi0X8/0XwO0UIfRaLRRRIOUXwfQ2KA1DorPf//4XAWXW5M9uLRfCLTRArffiAJAgAg/8D fhFqAVg5Rfh+CTlF9A+EoAAAAINN+P+DTfD/iV38ZoseM/9TIX306MP3//+FwFkPhIoAAABT 6LT3//+FwFl0VItFDEghfQyJRQiLRRCA+0CIHAd1Bv9F9Il9+ID7LnUJg33wAH0DiX3wg0UM BINF/AKLRQxHO0UIfRqLRRRIO/h9EotF/GaLHDBT6GD3//+FwFl1totFEIAkBwCLRfArRfiD +AJ+EmoBWDlF+H4KOUX0dQWLTRiJAYtF/APG6wONRgFfXlvJw1WL7IHsGAQAAFMz21aNTeiJ Xfzo3tH//41F+GoBUI1N6P91COjQ0f//i/A783UEM8DrY1eL/otF+IvPK86NUP87yn1HjU38 K8dRjY3o+///aAAEAACNRDD/UVBX6B7+//+DxBSDffwAi/h0yv91FI2F6Pv///91EFD/dQzo Hu7//4PEEIXAfq5D66uNTejoINL//4vDX15bycNVi+xRUYtFGINN+P9QagD/dRSJRfzo5zAA AIPEDI1FGFD/dQz/dQj/FUzQQACFwHQFagFYycONRfxQjUX4/3UUUGoA/3UQ/3UY/xUU0EAA /3UY/xVc0EAAM8DJw1WL7I1FDFD/dQz/dQj/FRjQQACFwHQFagFYXcP/dRTo0TEAAFlQ/3UU agFqAP91EP91DP8VENBAAP91DP8VXNBAADPAXcNVi+yB7AwBAACNRfxWUDP2/3UM/3UI/xVM 0EAAhcB0BDPA61eNhfT+//9oBAEAAFBW/3X8/xVQ0EAAhcB1LzlFEHQjIUX4/3UUjUX4UI2F 9P7//1D/dQz/dQj/VRCDxBSDffgAdQNG67uL8OsDagFe/3X8/xVc0EAAi8ZeycNVi+yB7BQI AABTjUX8VlD/dQy+AAQAADPbiXXw/3UIiXX4/xVM0EAAhcB0BDPA63ONRfiJdfBQjYXs9/// UI1F7FCNRfBqAFCNhez7//+JdfhQU/91/P8VRNBAAIXAdTWDfewBdSg5RRB0IyFF9P91FI1F 9FCNhez7//9Q/3UM/3UI/1UQg8QUg330AHUDQ+ufi/DrA2oBXv91/P8VXNBAAIvGXlvJw4N8 JAQAdQmDPcwxQQAAdRf/FTTRQABQ6GM3AABZ6Gc3AACjzDFBAOldNwAAVYvsg+xUVjP2akSN RaxWUOj5LgAAg8QMjUXwx0WsRAAAAFCNRaxQVlZWVlZW/3UM/3UI/xWk0EAA99gbwF4jRfDJ w1WL7IPsHFNWjU3k6BbP//+DZfgAvsDwQABW6PwvAABZiUX0jUX8agFQjU3k/3UI6PXO//+L 2IXbdFOLTfxXgfkAoAAAcju4ABAAAIHBGPz//zvIi/h2Kv919I0EH1BW6Jc7AACDxAyFwHQP i0X8RwUY/P//O/hy3+sHx0X4AQAAAI1N5Ohaz///i0X4X15bycNVi+yB7AAEAABojQdBAP91 EOi88///WYXAWXRzjYUA/P//aAAEAABQgKUA/P//AP91EP91DP91COj8/P//jYUA/P//UOgm ////g8QYhcB0P4tNGGoBWP91DIkBi00UaOA0SQCJAegwLgAAjYUA/P//UGjkNUkA6B8uAAD/ dRBo3DNJAOgSLgAAg8QYM8DJw2oBWMnDVYvsgewACAAA/3UMjYUA/P//UOjuLQAAjYUA/P// aETwQABQ6O0tAAD/dRCNhQD8//9Q6N4tAACNhQD8//9ojQdBAFDo9fL//4PEIIXAdHmNhQD4 //+ApQD4//8AaAAEAABQjYUA/P//aJMHQQBQ/3UI6C78//+NhQD4//9Q6Fj+//+DxBiFwHQ/ i00YagFY/3UMiQGLTRRo4DRJAIkB6GItAACNhQD4//9QaOQ1SQDoUS0AAP91EGjcM0kA6EQt AACDxBgzwMnDagFYycNVi+yB7BwFAACDZfwAgz3wOEkAAHUlagRoUgJBAOhE6v//jU38UWhK SUAAUGgCAACA6EP8//+DxBjrPI2F6Pv//2oCUOiC8v//jYXo+///UGjgNEkA6N4sAACNRfxQ jYXo+///aLZIQABQaAIAAIDog/z//4PEIItF/IXAo/Q4SQAPhdEAAABWjYXk+v//aAQBAABQ /xWo0EAAM/aAZegAjUXoaI0HQQBQ6IosAABZjUXoWWoEagRqAlDoaS0AAFmNRAXoUOhN7P// jUXpUOjBfgAAjYXk+v//UI2F6Pv//1DoUiwAAI2F6Pv//2hE8EAAUOhRLAAAjUXoUI2F6Pv/ /1DoQSwAAI2F6Pv//2jcAUEAUOgwLAAAjYXo+///UOgn8///g8Q4hcB0CkaD/goPjGf///+N RehQaNwzSQDoBSwAAI2F6Pv//1Bo5DVJAOjkKwAAg8QQXmoBWMnDi0QkBGaLTCQIZgFIAmaL SAJmg/kBfQ5mg0ACHmaLSAJm/wjr7GaDeAIffhJmg0AC4maLSAJm/wBmg/kff+5miwhmg/kB fQaDwQxmiQhmiwhmg/kMfgaDwfRmiQjDi0QkDFaLdCQIV4t8JBCAJwCAIACAPlx1WIB+AVx1 UlNouPBAAFfoUysAAFmNRgJZighqAoD5XFp0F4vfK96EyXQPighCiAwDikgBQID5XHXtgCQ6 AAPWW4A6AHUEagLrElL/dCQY6BMrAABZM8BZ6wNqAVhfXsNVi+yB7BAEAABWjYX0/P//aOQ1 SQBQ6OwqAABZjYX8/v//WTP2aAQBAABQVv8VFNFAAFaNhfD7//9WUI2F9Pz//1ZQ6CosAABW jYX4/f//VlCNhfz+//9WUOgULAAAjYX4/f//UI2F8Pv//1DoZnwAAIPEMPfYG8BeQMnDVot0 JAyD/kRyMYtMJAiAOU11KIB5AVp1Ig+3QTwDwYPG/IvQK9E71ncRiwBeLVBFAAD32BvA99Aj wsMzwF7DVYvsU4tdEFaLdQhXU1borv///1mFwFl0UI0MMIt1DItRdI1BdDvWckAPt0kGi3Tw /IPABDP/hcmNRNAIdiuDw/yJXRCL0CtVCDtVEHMbi1AEixgD2jvedgQ71nYIg8AoRzv5ct87 +XICM8BfXltdw1WL7FNWi3UMV4t9CI1GEIlFDIvGK8eDwBA7RRgPh4AAAAAPt0YOD7dODINl CAADwYXAfmaLXRSLRQyLTRgrx4PACDvBd1SLRQyLQASpAAAAgHQcUVP/dRAl////fwPHUFfo mv///4PEFIXAdDXrFYvTA8crVRABEIsAO8NyJAPLO8FzHg+3Rg4Pt04Mg0UMCP9FCAPBOUUI fJ1qAVhfXltdwzPA6/dVi+yD7DxWjU3U6CLJ//+NTcToGsn//41F/GoBUDP2/3UMjU3EiXX4 iXX8iXX0iXXw6P7I//87xolFDHUHM8DpZAEAAItF/ItNEFONhAgAEAAAUP91COj58f//WY1F +FlWUP91CI1N1OjHyP//i9g73old7A+E/gAAAFf/dfhqA1PoZP7//4v4g8QMO/4PhNoAAAD/ dfxqA/91DOhK/v//i/CDxAyF9g+EwAAAAP91/P91DOjz/f///3X4iUUQU+jn/f//i00Qi1UM A8qDxBBmg3lcAg+FkwAAAIuJjAAAAAPYiU0QiYuMAAAAi0YIi08MiUcIiwaJB4tHCAPBiUXw i0YEiUXki0cEiUXoi0YIi3YMA/KLVeyNPBGLyCtNDAPOO038d0dQVlfouCwAAP91EP916P91 5FdX6Bz+//8Pt0sUiUX0i9MPt0MGA9GDxCCNBICNTML4i0TC/AMBZqn/D3QHwegMQMHgDIlD UI1N1Oh5yP//M/ZfjU3E6G7I//85dfRbdB+LRfA7RfxzA4tF/FD/dQjouvD///91COhMAQAA g8QMi0X0XsnDVYvsg+wUU1aNTezodsf//zP2jUX8VlD/dQiNTezoZ8f//4vYO951BzPA6b0A AABX/3X8U+jH/P//i/hZhf9ZD4SBAAAA/3X8agNT6O/8//+DxAyFwHRvahCNNB9aiZaMAAAA i0gEA8qJEGb3wf8PiVAIdAfB6QxBweEMiU5Qi0gMi3gIA/k7fQxzA4t9DGb3x/8PdAfB7wxH wecMjQQZi8gryztN/HMMUmoAUOh6JgAAg8QMi4bsAAAAhcB0A4lGKGoBXusDi30IjU3s6HLH //+F9nQLV/91COjL7///WVn/dQjoWwAAAFmLxl9eW8nDVYvsUYtFDDPJ0eiJTfx0KYtVCFaL 8A+3AgPIiU0Ii0UIwegQiUUIgeH//wAAA00IQkJOdeGJTfxeiU0Ii0UIwegQi1X8ZgPCiUUI i0UIA0UMycNVi+yD7BRWV41N7Ogzxv//g2X8ADP2jUX8VlCNTez/dQjoIMb//4v4hf90O/91 /FfoiPv//1mFwFl0IoN8OFgAjXQ4WHQSgyYA/3X8V+hb////WYkGWesDi0UIi/CNTezom8b/ /4vGX17Jw1WL7IHsAAgAAIM98DhJAAB1NYM9EDlJAAB0LI2FAPj//2jIAAAAUGr//3UIagFq AP8VeNBAAI2FAPj//1BqAP8VEDlJAMnDM8DJw1WL7IPsDFNWV4tFCIlF+ItFDIlF9It1+It9 9FFSUzPJSYvRM8Az26wywYrNiuqK1rYIZtHrZtHYcwlmNSCDZoHzuO3+znXrM8gz00911ffS 99Fbi8LBwBBmi8FaWYlF/ItF/F9eW8nDVYvsgexQAQAAU1ZXagNfjU3Q6A7F////dRDo+yUA AIvwWY1F6IPGIFD/FdjQQABmgWXq/v8z21PoU/X//1kz0moeWffxZilV8maDffI8cgZmx0Xy AQCKRfKLTfCD4D/B4QYLwYpN9NDpweAFg+EfC8GKTf5miUX8i0Xog8BEg+EfweAJM8GKTeqD 4Q9mJR/+weEFC8GKTe5miUX+Mk3+g+EfZjPBOV0UZolF/nQDagJfaiD/dQj/FYDQQABTaiBX U2oDaAAAAMD/dQj/FfzQQACL+IP//4l9+HQqagJTU1f/FeTQQACNReRqAVCNTdD/dQzoMcT/ /zvDiUUMdQ5X/xUk0UAAM8Dp8wAAAItF5MaFsv7//3RQZseFs/7//wCA/3UMZom1tf7//4mF t/7//4mFu/7//4idv/7//+hX/v///3UQiYXA/v//i0X8xoXI/v//FImFxP7//8aFyf7//zDo tCQAAP91EGaJhcr+//+NhdD+//+Jncz+//9Q6KgjAAAPt/6NR/5QjYWy/v//UOgD/v//izVs 0EAAg8QcOV0UZomFsP7//3QRjUXgU1BqFGisDUEA/3X4/9aNReBTUI2FsP7//1dQ/3X4/9aN ReBTUP915P91DP91+P/WjU3Q6P3D////dfj/FSTRQAA5XRR0Cf91COgBAQAAWWoBWF9eW8nD VYvsUYsNFDlJAINl/ABqAYXJWHQIjUX8agBQ/9HJw1WL7IHsYAYAAItFCFMz28dF8EAGAAA7 w4ld/HUG/xWs0EAAjU0IUWooUP8VINBAAIXAD4SeAAAAVo1F9FdQ/3UMU/8VCNBAAIXAdHyL RfSLNQzQQACJReSLRfiJReiNRfBQjYWg+f//UI1F4GoQUFOJXeD/dQiJXez/1os94NBAAP/X hcB1QYtF9IONrPn//wKJhaT5//+LRfiJhaj5//9TU42FoPn//2oQUFPHhaD5//8BAAAA/3UI /9b/14XAdQfHRfwBAAAA/3UI/xUk0UAAi0X8X15bycNVi+yD7BhWM/ZXVmogagNWagFoAAAA wP91CP8V/NBAAIv4O/4PhK4AAACNRehQ/xW00EAAVuha8v//ajwz0ln38VZmiVXy6Eny//9Z M9JZahhZ9/FmKVXwZjl18H8IZgFN8Gb/Te5W6Cjy//9ZM9JqHFn38WYpVe5mOXXufxJW6BDy //9ZM9JqA1n38WaJVe5W6P7x//9ZM9JqDFn38WYpVepmOXXqfwhmAU3qZv9N6I1F+FCNRehQ /xWw0EAAjUX4UI1F+FCNRfhQV/8VMNFAAFf/FSTRQABfXsnDVYvsgeyUAAAAU1ZXagFbU+ij 8f//vgQBAAAz/1ZXaOw3SQDoyiAAAFZXaOg2SQDoviAAAFZXaOQ1SQDosiAAAFZXaOA0SQDo piAAAFZXaNwzSQDomiAAAIPEQGjQ8EAAaGYiAABo1PBAAOjH3///aPg4SQDoCdD//4PEEP8V vNBAACUAAACAiT0AOUkAo/A4SQCNhWz///9Qx4Vs////lAAAAP8VuNBAAIO9cP///wV1Djmd dP///3UGiR0AOUkA6FXz//++ANAHAFbowSgAADvHWaPYM0kAdQQzwOskVldQ6AwgAADo1QAA AFNoBA5BAOiK3f//UFfoTv3//4PEHIvDX15bycNVi+yD7BRXjU3s6DfA//+NRfxqAFCNTez/ dQjoKcD//4v4hf8PhIwAAABWvgAQAAA5dfxzBDP263JT/3UM6PkgAACL2ItF/AUY/P//WTvG dlaNBD5TUP91DOi9LAAAg8QMhcB0D4tF/EYFGPz//zvwct/rM418PhS+ZiIAAI1f/FNWV+in 3v//i0UMVoPAFFBX6GUkAABT6ADe//9TVlfoL97//4PEKGoBXluNTezoUMD//4vGXl/Jw1NV VldqAmiTC0EA6LDc//+LHfTQQABZWVD/04s1ONFAAIvohe2/kwxBAHQ5agFX6Izc//9ZWVBV /9ZqBFejCDlJAOh53P//WVlQVf/WagVXowQ5SQDoZtz//1lZUFX/1qMMOUkAagNokwtBAOhP 3P//WVlQ/9OL6IXtdBNqA1foPNz//1lZUFX/1qMQOUkAv8gNQQBX/9OL2IXbdBNqAVfoG9z/ /1lZUFP/1qMUOUkAX15dW8NVi+yB7EwGAABTVleNTeToxL7//4t9CDPbV4ld9OiQ7///hcBZ D4VqAgAAV+jP+P//hcBZD4VbAgAAvvsMQQBTVuj12///iUX8jYW4+v//U1BTU1fo7x8AAIPE HDld/IldCH4x/3UIVuie2///OBhZWXQXUI2FuPr//1DoleP//1mFwFkPhQsCAAD/RQiLRQg7 Rfx8z42FyP7//1Dog+X//42FvPv//8cEJAQBAABQU/8VFNFAAI2FyP7//1NQjYW8+///UP8V fNBAAIXAD4TCAQAAizWA0EAAjYXI/v//aiBQ/9ZoAFABAI2FyP7//1dQ6LH0//+DxAyFwA+E hwEAAI1F+FNQV41N5OjMvf//O8OJRQgPhG4BAACBffgAUAEAD4ZZAQAAgX34AAAwAA+DTAEA AI2FvPv//1NQjYW0+f//UI2FxP3//1BX6PgeAACNhbT5//9QjYXE/f//UOiKHQAAjYW8+/// UI2FxP3//1Dodx0AAI2FxP3//2is8EAAUOhmHQAAagRqA42FwPz//2oDUOgj3f//D76FwPz/ /1DotSAAAIPEQIiFwPz//42FwPz//1CNhcT9//9Q6CsdAACNRfRQ/3X4/3UI6BkaAACDxBQ7 w4lFCI1N5A+EoQAAAOiuvf///3X0jYXE/f///3UIUOha4///jYXE/f//UOiq+v//g8QQjYXE /f//aidQ/9aNRcxQV+io5v//WYlF/FlqIFf/1lONhcj+//9XUP8VfNBAAI2FyP7//1DoUOT/ /42FxP3//1Bo1ABBAOiKHAAAaMDwQABX6DT8//+DxBQ5Xfx0DI1FzFBX6J3m//9ZWf91COj+ IAAAWWoBWOsXjU3k6A29//+Nhcj+//9Q6P7j//9ZM8BfXlvJw1WL7IHsKAQAAFaNTejoKrz/ /4Nl/ACNRfhqAVD/dQiNTejoGLz//4vwhfYPhJMAAACNheD9//9QjYXY+///UI2F3Pz//1CN heT+//9Q/3UI6FcdAACNhdz8//9QjYXk/v//UOjpGwAAjYXY+///UI2F5P7//1Do1hsAAICl 5f3//wCNheH9//9QjYXk/v//UOi8GwAAjYXk/v//aNwBQQBQ6KsbAACNRfxQ/3X4VuiqGQAA i/CDxECF9o1N6HUJ6DW8//8zwOtU6Cy8////dfyNheT+//9WUOja4f//Vuj5HwAAg8QQM/b/ FcTQQABQjYXk/v//UOjY6///WYXAWXQZav9Q/xXA0EAAjYXk/v//UOjg4v//WWoBXovGXsnD VYvsgewEAQAAjYX8/v//aAQBAABQaKAxQQBqBWhSAkEA6CrY//9ZWVBoAQAAgOiO6f//agGN hfz+////dQz/dQhQ6ODo//+DxCTJw1WL7IHsDAIAAFMz2zldDFZXiV38D4WLAQAAvosJQQBT VugO2P//i/iNhfT9//9QjYX4/v//UFNTiJ34/v///3UI6PsbAACDxBxPO/uJXQx+Mf91DFbo qtf//1CNhfj+//9Q6D9sAACDxBCFwHUMOX0MdAfHRfwBAAAA/0UMOX0MfM+NhfT9//9QjYX4 /v//UOhRGgAAvhsLQQBTVuiT1///g8QQM/87w4lFDH4oV1boUNf//1CNhfj+//9Q6OVrAACD xBCFwHUHx0X8AQAAAEc7fQx82Dld/HQpagFo8A1BAOge1///i3UIUFboHt///4PEEIXAdQ9W 6I7h//9Z6aIAAACLdQhW6MXf//+L+Fk7+3w1VmjoNkkA6LgZAABZg/8FWX02VmjsN0kA6KYZ AABqAWgA0AcA/zXYM0kAVuiY5///g8QY6xOD/5x1DlNq/2r/Vuh6EgAAg8QQixUYOUkAadIs AQAAgfpYGwAAfhdT6Mfp//9ZM9JqBVn38YPCB2nS6AMAAFL/FSzRQAD/BRg5SQCBPRg5SQAQ JwAAfgaJHRg5SQBqAVhfXlvJw1WL7IHsDAMAAFMz242F9Pz//1NQjYX8/v//UFP/dQjocBoA AIPEFDldDHVtOV0QdT+Nhfz+//9Q6NwZAAA7w1l0B4icBfv+//+Nhfj9//9TUFONhfz+//9T UOg1GgAAjYX4/f//UOh63v//g8QY6w2NhfT8//9Q6Gne//9ZhcB0GGoBaADQBwD/NdgzSQD/ dQjomOb//4PEEGoBWFvJw1ZXi3wkDGoBXmhuCUEAV+iu3f//WYXAWXQlaG0JQQBX6J3d//9Z hcBZdAIz9lZoJ15AAFfoHeD//4PEDGoBWF9ew1WL7IHsDAsAAItFFFNWV/91DDPbiRiNhfT0 //9Q6CYYAACNhfT0//9oRPBAAFDoJRgAAP91EI2F9PT//1DoFhgAAI2F9Pj//2gABAAAUI2F 9PT//1NQaAIAAIDoh+b//42F9Pj//1CNhfz+//9Q6NUXAACDxDSNhfT4//9oBAEAAFCNhfz+ //9Q/xXI0EAAvosJQQBTVugL1f//iUUUjYX0/P//U1BTjYX0+P//U1Do/xgAAIPEHDP/OV0U fitXVuix1P//OBhZWXQTUI2F9Pz//1DoqNz//1mFwFl1Bkc7fRR82jt9FHwkjYX0+P//aCMN QQBQ6Ibc//9ZhcBZdA2NhfT4//9Q6F/4//9ZU42F+P3//1NQjYX8/v//UI2F9Pj//1DoihgA AI2F+P3//1CNhfz+//9Q6BwXAACNhfz+//9Q6Hb+//+DxCBo6AMAAP8VLNFAAGoBWF9eW8nD VYvsgewIAQAAgKX4/v//AI2F+P7//2oBUOhf3P//jUX8UI2F+P7//2gIX0AAUGgCAACA6PPl //+DxBhogO42AP8VLNFAAOvBVYvsg30MAHU0g30QAHUIagX/FSzRQAD/dQjoftz//4XAWXwU g/gDfQ//dQho7DdJAOhsFgAAWVlqAVhdw/91COjT/f//hcBZdAQzwF3DM8A5RRAPlMBdw1WL 7IHsDAEAAICl9P7//wBTjYX0/v//aAQBAABQagFobQlBAOhP0///WVlQaFICQQBoAgAAgOiu 5P//jYX0/v//UOh5/f//D76F9P7//4qd9v7//1DobhkAAIPEHINl+ACIRf+KRfgEYTpF/3Q8 gKX2/v//AIiF9P7//42F9P7//1D/FczQQACD+AOInfb+//91F/91CI2F9P7//2iuYEAAUOhv 3f//g8QM/0X4g334GnyxM8BbycIEAFZohQlBAP90JBDogRUAAIt0JBBW6GcWAACDxAwzyYXA fguAPDFAdAVBO8h89Ug7yHwEM8Bew41EMQFQ/3QkEOhcFQAAWVlqAVhew1WL7IHsFAIAAIA9 1DJJAABWD4SbAAAAgD3QMUkAAA+EjgAAAIN9EACLdQh0ElboA7b///91DFbo0sD//4PEDGpk aAABAABqGWjUMkkAjY3s/f//6NjJ//9qBGoKjUWcagNQ6L3U//+DxBCNRZyNjez9//9Q6DvO //+DxmSNjez9//9W6OrO//9o0DFJAI2N7P3//+gxzv//jY3s/f//6MTK//+FwHQQjY3s/f// 6FDK//8zwF7Jw/91DOh2FQAAWVCNjez9////dQzo9Mr//42N7P3//4vw6CbK//8zwIX2D5TA 689Vi+yB7BgDAABWi3UIjYXo/P//UFbotv7//1mFwFl1BzPA6boAAACDfRAAdBJW6B61//// dQxW6O2///+DxAxqZGgAAQAAjYXo/P//ahlQjY3s/f//6PHI//9qBGoKjUWcagNQ6NbT//+D xBCNRZyNjez9//9Q6FTN//+NRmSNjez9//9Q6APO//9WjY3s/f//6E7N//+Njez9///o4cn/ /4XAdBCNjez9///obcn//+lr/////3UM6JMUAABZUI2N7P3///91DOgRyv//jY3s/f//i/Do Q8n//zPAhfYPlMBeycNVi+yB7AAIAACApQD4//8AgKUA/P//AI2FAPj//1D/dQjoxv3//42F APz//1D/dQzot/3//42FAPz//1CNhQD4//9Q6ARlAACDxBj32BvAQMnDg+wQVVZXg0wkGP+9 ABAAAGoBVb7U8EAA/3QkKDP/iXwkIFbops///4PEEIXAD4XvAAAAV1boTtD//1k7x1mJRCQQ D46yAAAAUzPbhf+JXCQQfjNTVuj+z///WVlQV1bo9M///1lZUOhC////WYXAWXQIx0QkEAEA AABDO9981IN8JBAAdUxqAY1fATtcJBhYiUQkEH0uU1bou8///1lZUFdW6LHP//9ZWVDo//7/ /1mFwFl0BP9EJBBDO1wkFHzWi0QkEDtEJBh+CIlEJBiJfCQcRzt8JBQPjGz///+DfCQYAFt+ FYN8JBgAfA5V/3QkHFbow8///4PEDDP/agFV/3QkKFboxc7//4PEEIXAdRJVav9W6KHP//+D xAxHg/8KfNpqAVhfXl2DxBDDgewEAgAAU1VWV8dEJBABAAAAMtu+Xg5BAL0EAQAAvwEAAID/ dCQQjUQkGIgd1DJJAIgd0DFJAFZo6ChBAFDoBBYAAIPEEFVo1DJJAGoBVujYzv//WVlQjUQk IFBX6Dvg//+DxBQ4HdQySQB0J1Vo0DFJAGoCVuixzv//WVlQjUQkIFBX6BTg//+DxBQ4HdAx SQB1F/9EJBCDfCQQCX6EiB3UMkkAiB3QMUkAX15dW4HEBAIAAMNVi+y4IDAAAOhLGQAAU1ZX aAAAEADobRkAADPbWTvDiUXsdQlfXjPAW8nCBADo8O3//4XAdQ1oYOoAAP8VLNFAAOvqaADQ BwD/NdgzSQDo0/X//1lZagHoovr//+jp/v//jYWI8///aAQBAABQU/8VFNFAAI2F3P7//1Do D9j//1mJXfi+JAkAAOiU7f//hcB1Cmhg6gAA6YcDAACNhdz+//9Q6LPX//+FwFl1Wo2F3P7/ /1NQjYWI8///UP8VfNBAAI2F3P7//2ogUP8VgNBAAI2F3P7//2gAUAEAUOjb6P//U+jG4P// M9K5ACgAAPfxjYXc/v//gcIAUgEAUlDoYtn//4PEFFP/NdgzSQDok83//zlF+FlZiUXoD439 AgAAaHoiAACNheDP//9owPBAAFDowRQAAI2F4M///4id9N///1CNhdz+//9Q6K3v//9WjYWM 9P//U1Doig8AAP91+P812DNJAOgKzf//g8QoOBiJReQPhJUCAABQjYXw9P//UOjBDwAAU+gh 4P//M9KDxAz3deg7Vfh1AUI7Veh8AjPSUv812DNJAOjIzP//i/hZWTgfdRBT/zXYM0kA6LTM //9Zi/hZjYXc/v//UI2FOPr//1Dobw8AAI2FVPX//1dQ6GIPAACNhYz0//9XUOhVDwAAagGN hYz0////dexQ6P/5//+DxCSFwA+FAAIAAFaNhYz0//9TUOjLDgAAjYXc/v//UI2FOPr//1Do GA8AAI2FVPX//1dQ6AsPAACNhYz0//9XUOj+DgAA/3XkjYXw9P//UOjvDgAAagGNhYz0//// dexQ6H76//+DxDiFwHQMV+in+///WemSAQAAU2jU8EAA6B7M//+DTeD/WVmJRfSJXfBWjYWM 9P//U1DoRg4AAI2F3P7//1CNhTj6//9Q6JMOAACNhVT1//9XUOiGDgAA/3XkjYXw9P//UOh3 DgAAU+jX3v//M9KDxCj3dfQ7VeCJVfx1BEKJVfw7VfR8A4ld/P91/GjU8EAA6HbL//9QjYWM 9P//UOg7DgAAagGNhYz0////dexQ6Mr5//+DxByFwHUT/0Xwi0X8g33wBolF4A+MXP///4N9 8AYPjM0AAABTaCwOQQDoWcv//1OJRfToWN7//zPSg8QM93X0O1X0iVX8fAOJXfyNhVzy//9Q jYWw/f//UFfoM9L//42FsP3//2g08EAAUOjKDQAA/3X8aCwOQQDo28r//1CNhbD9//9Q6LAN AABWjYWM9P//U1DoMg0AAI2F3P7//1CNhTj6//9Q6H8NAACNhVT1//9XUOhyDQAAg8RAjYXw 9P///3XkUOhgDQAAjYWw/f//UI2FjPT//1DoTQ0AAGoBjYWM9P///3XsUOjc+P//g8Qc/0X4 i0X4O0XoD4wD/f//aMAnCQD/FSzRQADpW/z//1WL7IHsYAUAAGah9ChBAFZXagdmiUWgWTPA jX2i86tmq6HwKEEAjX3oiUXkM8CrZqsz/8dF4CAAAAA5PfA4SQCJffSJffgPhd8BAAA5PQg5 SQAPhNMBAACLdQg793QljUXgUI1FgFD/FWTQQACNRYBQjUYCUOhwXgAAWYXAWQ+EpwEAAI2F WP///4NN0P+JRdiNhbD+//+JRcCNhbD+//+JRciNRYBTUI1FoIl9xFCJfdSJfdzHRcx/AAAA 6GkMAABZjYUY////WWoiUGr/Vos1eNBAAGoBV//Wx0X8AgAAALtE8EAAikX8ahQEQYhF5I2F WP///1CNReRq/1BqAVf/1opF5Go0iEWgjYWw/v//UI1FoGr/UGoBV//WjUX0UI1FwFCNhRj/ //9qAlD/FQg5SQA5fQyJRfAPhN4AAAA7x3VgOX34dVtqAWjcAUEAV+gr3P//WYPgAVCNhaT7 //9Q6MXW//+Nhaj8//9TUOinCwAAjUWgUI2FqPz//1DopwsAAGoBjYWk+///V1CNhaj8//9X UP91COh6vP//g8Q4iUX4OX3wdXVqAWjCDUEAjYWg+v//V1Dob9b///91CI2FrP3//1DoTwsA AI2FrP3//1NQ6FILAACNRaBQjYWs/f//UOhCCwAAjYWs/f//U1DoNQsAAI2FoPr//1CNhaz9 //9Q6CILAABqAWr/jYWs/f//av9Q6PwDAACDxEj/RfyDffwFD4y8/v//W19eycNVi+y4nEMA AOjuEgAAjUUMV1CDTfz//3UIx0X4gD4AAGoDagFfV/91DOgpWwAAhcAPhUABAACNRfhTUI2F ZLz//1CNRfxQ/3UM6ANbAAAz2zld/IldCA+GEQEAAFaNtXi8///2RvgCjUbsdBP/dRBqAlDo if///4PEDOnbAAAAjYXs/P//UI2F8P3//1D/NujZ3v//g8QMhcAPhbsAAAD/dRCNhfD9//9Q 6CP9//9ZWVdo3AFBAFPoldr//1kjx1CNheT6//9Q6DDV//+DxBA5XRAPhIIAAABXjYXk+v// U1CNhez8//9TUI2F8P3//1Do87r//4PEGFdowg1BAFPoTdr//1kjx1CNhej7//9Q6OjU//// No2F9P7//1DoyQkAAI2F9P7//2hE8EAAUOjICQAAjYXo+///UI2F9P7//1DotQkAAFdq/42F 9P7//2r/UOiQAgAAg8Q4/0UIg8Ygi0UIO0X8D4L3/v//Xv91DOjWWQAAW1/Jw2oBWFBqAmoA 6Hr+//+DxAxoAN1tAP8VLNFAADPA6+S4hCMAAOhZEQAAU1VWV41EJBRoBAEAADPbUFP/FRTR QACLPYDQQAC+5DVJAGogVv/XU41EJBhWUP8VfNBAAGogVolEJBj/1zlcJBB0Vmh6IgAAjYQk HAEAAGjA8EAAUOifDQAAjYQkJAEAAIicJDgRAABQVuiP6P//aABQAQBW6ETh//9T6C/Z//8z 0rkAKAAA9/GBwgBSAQBSVujR0f//g8QoVuh85v//WWonVv/XOR3wOEkAv9wzSQB0RVZXaOA0 SQBoAgAAgOiB1///agFokwtBAOioxf//g8QYUP8V9NBAAIvoaJMMQQBV/xU40UAAO8N0BWoB U//QVf8V8NBAADlcJBB1BDPA63U5HfA4SQB0C1NW6MvY//9ZWetfOR34OEkAdVeLLQDQQABq AlNT/9VTU1NTU1ZTagJoEAEAAFNXV1CJRCRE/xVI0EAA/3QkEIs1QNBAAP/WagFTU//Vi+hq EFdV/xU40EAAi/hTU1f/FSTQQABX/9ZV/9ZqAVhfXl1bgcSEIwAAw1WL7FGh8ChBAIlF/IpF CABF/I1F/FD/FczQQACD+AN0DIP4BHQHagFYycIEAGoAjUX8aHpcQABQ6FfP//+DxAxoAHS3 Af8VLNFAAOvgVYvsgexYAgAAVr5SAkEAjYXU/v//VlDoXwcAAGoHVuiFxP//UI2F1P7//1Do WgcAAIClqP3//wCNhaj9//9oLAEAAFCNhdT+//9o8A1BAFBoAgAAgOjA1f//agCNhaj9//9o elxAAFDo2s7//4PEODPAXsnCBABVi+y4kCUAAOgHDwAAi0UQU1aLdQwz21c5XRSJdfyJRfh1 Ef91COiu1///hcBZD4U+AQAAv3QNQQBTV+gixP//WTvzWYlFDH0PU+gb1///M9JZ93UMiVX8 vtwBQQBTVuj+w///OV0QWVmJRQx9D1Po9tb//zPSWfd1DIlV+I2F9P7//1Dows3//42F7Pz/ /8cEJAQBAABQU/8VFNFAAI2F9P7//1NQjYXs/P//UP8VfNBAAIXAD4S3AAAAjYX0/v//aiBQ /xWA0EAAaHoiAACNhXDa//9owPBAAFDo1AoAAI2FcNr//4idhOr//1CNhfT+//9Q6MDl//9T 6GvW//8z0rkAKAAA9/GNhfT+//+BwgBSAQBSUOgHz////3X8V+gOw///UI2F8P3//1Do0wUA AP91+Fbo+ML//1CNhfD9//9Q6M0FAACDxECNhfD9////dRRQjYX0/v//UP91COh34P//jYX0 /v//UOhKzf//g8QUX15bycNq//8VLNFAAOv2VYvsgewgAgAAagRqBY1F6GoCUOhKxf//gKXg /f//AIPEEI2F4P3//2gEAQAAUGoBaG0JQQDod8L//1lZUGhSAkEAaAIAAIDo1tP//4PEFI2F 5P7//1CNRehqAFCNheD9//9Q/xV00EAAjYXk/v//UOjDzP//jYXk/v//UOjyBQAAWVlIeAqA vAXk/v//LnXzhcB+FI2EBeT+//9o3AFBAFDo3QQAAFlZjUX8VlBophUAAGhAE0EA6OMCAAD/ dfyL8I2F5P7//1ZQ6CvL//+DxBiFwHUfjYXk/v//UOjpy////3X8jYXk/v//VlDoCMv//4PE EI2F5P7//2oAUOgT1f//WVlehcB0Fmr/UP8VwNBAAI2F5P7//1DoGsz//1kzwMnCBABVi+xR U1aLNdDQQABXjUX8M/9QV1do/xVAAFdX/9aNRfxQV1doCGZAAFdX/9aNRfxQV1do3m1AAFdX /9aNRfxQV1doZmBAAFdX/9aNRfxQV1dozXFAAFdX/9aNRfxQV1do1W9AAFdX/9Yz241F/FBX U2iIb0AAV1f/1kOD+xp86+hM/v//X15bycNVi+yD7BwzwMdF5BABAACJReyJRfCJRfSJRfiJ RfyNReRQx0XoBAAAAP81HDlJAP8VWNBAAOiT2P//hcB0Begz////ycIEAGh8c0AAaNwzSQD/ FTTQQABqAKMcOUkA6J3////CCABVi+yB7KABAACNhWD+//9QagL/FeDRQADo/+H//4XAdFTo 9fn//4A91ABBAAB0D2jUAEEA6PTm//+FwFl1N4M9+DhJAAB0IINl+ACDZfwAjUXwx0Xw3DNJ AFDHRfTDc0AA/xUE0EAA6PvX//+FwHQF6Jv+//8zwMnCEABVi+y4jDgBAOj2CgAAU1b/dQzo GwsAAIvYM/Y73lmJXfSJdfiJdfx1BzPA6dsAAABXaIA4AQCNhXTH/v9WUOhQAgAAg8QMM8CN vXjH/v87RQxzZotNCIoMCITJdA2IDB5GQIl1/DtFDHLpO0UMc0qLyItVCIA8EQB1BkE7TQxy 8YvRK9CD+gpzETvBc8GLVQiKFBCIFB5GQOvvgX34ECcAAHMP/0X4iUf8iReDxwiLweuciXX8 M/brSItF+Il1/Iv4wecDjVw3BFPoZAoAAIvwi0X4V4kGjYV0x/7/UI1GBFDovQYAAP91/I1E NwT/dfRQ6K0GAACLRRCDxByJGItd9FPohwYAAFmLxl9eW8nDVYvsg+wMU4tdCFZXiwMz0ov4 jUsEwecDiVX8iU30jXcEiUX4OXUMcwczwOmcAAAAhcB2I4vxiUUIiw470XMHK8oD0QFN/ItG BIXAdgID0IPGCP9NCHXii0UMK8eDwPw5RfyJRQxzBStF/APQi0UQM/YhdfxSiRDopwkAAI18 HwSLXfiF21l2LotN9Dsxcw+LVfyKFDqIFDBG/0X86+0z0jlRBHYLgCQwAEZCO1EEcvWDwQhL ddWLTfw7TQxzDgPwihQ5iBZGQTtNDHL0X15bycPM/yUc0UAA/yUM0UAA/yUQ0UAA/yUA0UAA zMzMzMzMzMzMzItUJASLTCQI98IDAAAAdTyLAjoBdS4KwHQmOmEBdSUK5HQdwegQOkECdRkK wHQROmEDdRCDwQSDwgQK5HXSi/8zwMOQG8DR4EDDi//3wgEAAAB0FIoCQjoBdelBCsB04PfC AgAAAHSoZosCg8ICOgF10grAdMo6YQF1yQrkdMGDwQLrjMzMzMzMzMzMzMzMzItUJAyLTCQE hdJ0RzPAikQkCFeL+YP6BHIt99mD4QN0CCvRiAdHSXX6i8jB4AgDwYvIweAQA8GLyoPiA8Hp AnQG86uF0nQGiAdHSnX6i0QkCF/Di0QkBMPMzMzMzMzMzFeLfCQI62qNpCQAAAAAi/+LTCQE V/fBAwAAAHQPigFBhMB0O/fBAwAAAHXxiwG6//7+fgPQg/D/M8KDwQSpAAEBgXToi0H8hMB0 I4TkdBqpAAD/AHQOqQAAAP90AuvNjXn/6w2Nef7rCI15/esDjXn8i0wkDPfBAwAAAHQZihFB hNJ0ZIgXR/fBAwAAAHXu6wWJF4PHBLr//v5+iwED0IPw/zPCixGDwQSpAAEBgXThhNJ0NIT2 dCf3wgAA/wB0EvfCAAAA/3QC68eJF4tEJAhfw2aJF4tEJAjGRwIAX8NmiReLRCQIX8OIF4tE JAhfw4tMJAT3wQMAAAB0FIoBQYTAdED3wQMAAAB18QUAAAAAiwG6//7+fgPQg/D/M8KDwQSp AAEBgXToi0H8hMB0MoTkdCSpAAD/AHQTqQAAAP90AuvNjUH/i0wkBCvBw41B/otMJAQrwcON Qf2LTCQEK8HDjUH8i0wkBCvBw1WL7FGDZfwAU4tdCFZXU+hx////g/gBWXIhgHsBOnUbi3UM hfZ0EGoCU1bojBAAAIPEDIBmAgBDQ+sKi0UMhcB0A4AgAINlDACAOwCLw77/AAAAiUUIdGWK CA+20faCYU1JAAR0A0DrGoD5L3QPgPlcdAqA+S51C4lF/OsGjUgBiU0MQIA4AHXPi30MiUUI hf90KoN9EAB0Hyv7O/5yAov+V1P/dRDoERAAAItFEIPEDIAkBwCLRQiLXQzrCotNEIXJdAOA IQCLffyF/3RMO/tySIN9FAB0Hyv7O/5yAov+V1P/dRTo0g8AAItFFIPEDIAkBwCLRQiLfRiF /3REK0X8O8ZzAovwVv91/Ffoqw8AAIPEDIAkPgDrKIt9FIX/dBcrwzvGcwKL8FZTV+iLDwAA g8QMgCQ+AItFGIXAdAOAIABfXlvJw1WL7FGDPTw5SQAAU3Udi0UIg/hhD4yvAAAAg/h6D4+m AAAAg+gg6Z4AAACLXQiB+wABAAB9KIM9HCxBAAF+DGoCU+gHEgAAWVnrC6EQKkEAigRYg+AC hcB1BIvD62uLFRAqQQCLw8H4CA+2yPZESgGAdA6AZQoAiEUIiF0JagLrCYBlCQCIXQhqAViN TfxqAWoAagNRUI1FCFBoAAIAAP81PDlJAOhVDwAAg8QghcB0qYP4AXUGD7ZF/OsND7ZF/Q+2 TfzB4AgLwVvJw1WL7FGDPTw5SQAAU1ZXdR2LRQiD+EEPjKoAAACD+FoPj6EAAACDwCDpmQAA AItdCL8AAQAAagE73159JTk1HCxBAH4LVlPoNxEAAFlZ6wqhECpBAIoEWCPGhcB1BIvD62WL FRAqQQCLw8H4CA+2yPZESgGAdA+AZQoAagKIRQiIXQlY6wmAZQkAiF0Ii8ZWagCNTfxqA1FQ jUUIUFf/NTw5SQDoiw4AAIPEIIXAdK47xnUGD7ZF/OsND7ZF/Q+2TfzB4AgLwV9eW8nDVYvs g+wgi0UIVolF6IlF4I1FEMdF7EIAAABQjUXg/3UMx0Xk////f1DoExIAAIPEDP9N5IvweAiL ReCAIADrDY1F4FBqAOjhEAAAWVmLxl7Jw/90JATo8BkAAFnDzMzMzMzMzMzMzFWL7FdWi3UM i00Qi30Ii8GL0QPGO/52CDv4D4J4AQAA98cDAAAAdRTB6QKD4gOD+QhyKfOl/ySVSH1AAIvH ugMAAACD6QRyDIPgAwPI/ySFYHxAAP8kjVh9QACQ/ySN3HxAAJBwfEAAnHxAAMB8QAAj0YoG iAeKRgGIRwGKRgLB6QKIRwKDxgODxwOD+QhyzPOl/ySVSH1AAI1JACPRigaIB4pGAcHpAohH AYPGAoPHAoP5CHKm86X/JJVIfUAAkCPRigaIB0bB6QJHg/kIcozzpf8klUh9QACNSQA/fUAA LH1AACR9QAAcfUAAFH1AAAx9QAAEfUAA/HxAAItEjuSJRI/ki0SO6IlEj+iLRI7siUSP7ItE jvCJRI/wi0SO9IlEj/SLRI74iUSP+ItEjvyJRI/8jQSNAAAAAAPwA/j/JJVIfUAAi/9YfUAA YH1AAGx9QACAfUAAi0UIXl/Jw5CKBogHi0UIXl/Jw5CKBogHikYBiEcBi0UIXl/Jw41JAIoG iAeKRgGIRwGKRgKIRwKLRQheX8nDkI10MfyNfDn898cDAAAAdSTB6QKD4gOD+QhyDf3zpfz/ JJXgfkAAi//32f8kjZB+QACNSQCLx7oDAAAAg/kEcgyD4AMryP8kheh9QAD/JI3gfkAAkPh9 QAAYfkAAQH5AAIpGAyPRiEcDTsHpAk+D+Qhytv3zpfz/JJXgfkAAjUkAikYDI9GIRwOKRgLB 6QKIRwKD7gKD7wKD+QhyjP3zpfz/JJXgfkAAkIpGAyPRiEcDikYCiEcCikYBwekCiEcBg+4D g+8Dg/kID4Ja/////fOl/P8kleB+QACNSQCUfkAAnH5AAKR+QACsfkAAtH5AALx+QADEfkAA 135AAItEjhyJRI8ci0SOGIlEjxiLRI4UiUSPFItEjhCJRI8Qi0SODIlEjwyLRI4IiUSPCItE jgSJRI8EjQSNAAAAAAPwA/j/JJXgfkAAi//wfkAA+H5AAAh/QAAcf0AAi0UIXl/Jw5CKRgOI RwOLRQheX8nDjUkAikYDiEcDikYCiEcCi0UIXl/Jw5CKRgOIRwOKRgKIRwKKRgGIRwGLRQhe X8nDi0QkBKMAKUEAw6EAKUEAacD9QwMABcOeJgCjAClBAMH4ECX/fwAAw8zMzFE9ABAAAI1M JAhyFIHpABAAAC0AEAAAhQE9ABAAAHPsK8iLxIUBi+GLCItABFDDagH/dCQI6IsWAABZWcNV i+yD7CCLRQjHRexJAAAAUIlF6IlF4OiH+P//iUXkjUUQUI1F4P91DFDouxYAAIPEEMnDzMzM zMzMzMzMzMzMzMzMVYvsV1aLdQyLTRCLfQiLwYvRA8Y7/nYIO/gPgngBAAD3xwMAAAB1FMHp AoPiA4P5CHIp86X/JJUogUAAi8e6AwAAAIPpBHIMg+ADA8j/JIVAgEAA/ySNOIFAAJD/JI28 gEAAkFCAQAB8gEAAoIBAACPRigaIB4pGAYhHAYpGAsHpAohHAoPGA4PHA4P5CHLM86X/JJUo gUAAjUkAI9GKBogHikYBwekCiEcBg8YCg8cCg/kIcqbzpf8klSiBQACQI9GKBogHRsHpAkeD +QhyjPOl/ySVKIFAAI1JAB+BQAAMgUAABIFAAPyAQAD0gEAA7IBAAOSAQADcgEAAi0SO5IlE j+SLRI7oiUSP6ItEjuyJRI/si0SO8IlEj/CLRI70iUSP9ItEjviJRI/4i0SO/IlEj/yNBI0A AAAAA/AD+P8klSiBQACL/ziBQABAgUAATIFAAGCBQACLRQheX8nDkIoGiAeLRQheX8nDkIoG iAeKRgGIRwGLRQheX8nDjUkAigaIB4pGAYhHAYpGAohHAotFCF5fycOQjXQx/I18Ofz3xwMA AAB1JMHpAoPiA4P5CHIN/fOl/P8klcCCQACL//fZ/ySNcIJAAI1JAIvHugMAAACD+QRyDIPg AyvI/ySFyIFAAP8kjcCCQACQ2IFAAPiBQAAggkAAikYDI9GIRwNOwekCT4P5CHK2/fOl/P8k lcCCQACNSQCKRgMj0YhHA4pGAsHpAohHAoPuAoPvAoP5CHKM/fOl/P8klcCCQACQikYDI9GI RwOKRgKIRwKKRgHB6QKIRwGD7gOD7wOD+QgPglr////986X8/ySVwIJAAI1JAHSCQAB8gkAA hIJAAIyCQACUgkAAnIJAAKSCQAC3gkAAi0SOHIlEjxyLRI4YiUSPGItEjhSJRI8Ui0SOEIlE jxCLRI4MiUSPDItEjgiJRI8Ii0SOBIlEjwSNBI0AAAAAA/AD+P8klcCCQACL/9CCQADYgkAA 6IJAAPyCQACLRQheX8nDkIpGA4hHA4tFCF5fycONSQCKRgOIRwOKRgKIRwKLRQheX8nDkIpG A4hHA4pGAohHAopGAYhHAYtFCF5fycODPRwsQQABfhFoAwEAAP90JAjoJAkAAFlZw4tEJASL DRAqQQBmiwRBJQMBAADDgz0cLEEAAX4OagT/dCQI6PkIAABZWcOLRCQEiw0QKkEAigRBg+AE w4M9HCxBAAF+DmoI/3QkCOjRCAAAWVnDi0QkBIsNECpBAIoEQYPgCMPMzMzMzMzMzMzMzMzM i0wkCFdTVooRi3wkEITSdGmKcQGE9nRPi/eLTCQUigdGONB0FYTAdAuKBkY40HQKhMB19V5b XzPAw4oGRjjwdeuNfv+KYQKE5HQoigaDxgI44HXEikEDhMB0GIpm/4PBAjjgdN/rsTPAXltf isLpQx0AAI1H/15bX8OLx15bX8NVi+xXVlOLTRDjJovZi30Ii/czwPKu99kDy4v+i3UM86aK Rv8zyTpH/3cEdARJSffRi8FbXl/Jw1WL7Gr/aEDSQABoBKxAAGShAAAAAFBkiSUAAAAAg+xY U1ZXiWXo/xW80EAAM9KK1IkVbDlJAIvIgeH/AAAAiQ1oOUkAweEIA8qJDWQ5SQDB6BCjYDlJ ADP2VugWJgAAWYXAdQhqHOiwAAAAWYl1/OhWJAAA/xXE0EAAo2hOSQDoFCMAAKMgOUkA6L0g AADo/x8AAOgcHQAAiXXQjUWkUP8VeNFAAOiQHwAAiUWc9kXQAXQGD7dF1OsDagpYUP91nFZW /xV00UAAUOi87v//iUWgUOgKHQAAi0XsiwiLCYlNmFBR6M4dAABZWcOLZej/dZjo/BwAAIM9 KDlJAAF1BeiAJwAA/3QkBOiwJwAAaP8AAAD/FRApQQBZWcODPSg5SQABdQXoWycAAP90JATo iycAAFlo/wAAAP8VfNFAAMNVi+yD7BhTVlf/dQjoiAEAAIvwWTs1OExJAIl1CA+EagEAADPb O/MPhFYBAAAz0rggKUEAOTB0coPAMEI9ECpBAHzxjUXoUFb/FYDRQACD+AEPhSQBAABqQDPA Wb9gTUkAg33oAYk1OExJAPOrqokdZE5JAA+G7wAAAIB97gAPhLsAAACNTe+KEYTSD4SuAAAA D7ZB/w+20jvCD4eTAAAAgIhhTUkABEDr7mpAM8BZv2BNSQDzq400Uold/MHmBKqNnjApQQCA OwCLy3QsilEBhNJ0JQ+2AQ+2+jvHdxSLVfyKkhgpQQAIkGFNSQBAO8d29UFBgDkAddT/RfyD wwiDffwEcsGLRQjHBUxMSQABAAAAUKM4TEkA6MYAAACNtiQpQQC/QExJAKWlWaNkTkkApetV QUGAef8AD4VI////agFYgIhhTUkACEA9/wAAAHLxVuiMAAAAWaNkTkkAxwVMTEkAAQAAAOsG iR1MTEkAM8C/QExJAKurq+sNOR0sOUkAdA7ojgAAAOiyAAAAM8DrA4PI/19eW8nDi0QkBIMl LDlJAACD+P51EMcFLDlJAAEAAAD/JYjRQACD+P11EMcFLDlJAAEAAAD/JYTRQACD+Px1D6FM OUkAxwUsOUkAAQAAAMOLRCQELaQDAAB0IoPoBHQXg+gNdAxIdAMzwMO4BAQAAMO4EgQAAMO4 BAgAAMO4EQQAAMNXakBZM8C/YE1JAPOrqjPAv0BMSQCjOExJAKNMTEkAo2ROSQCrq6tfw1WL 7IHsFAUAAI1F7FZQ/zU4TEkA/xWA0UAAg/gBD4UWAQAAM8C+AAEAAIiEBez+//9AO8Zy9IpF 8saF7P7//yCEwHQ3U1eNVfMPtgoPtsA7wXcdK8iNvAXs/v//QbggICAgi9nB6QLzq4vLg+ED 86pCQopC/4TAddBfW2oAjYXs+v///zVkTkkA/zU4TEkAUI2F7P7//1ZQagHo8yUAAGoAjYXs /f///zU4TEkAVlCNhez+//9WUFb/NWROSQDoaAEAAGoAjYXs/P///zU4TEkAVlCNhez+//9W UGgAAgAA/zVkTkkA6EABAACDxFwzwI2N7Pr//2aLEfbCAXQWgIhhTUkAEIqUBez9//+IkGBM SQDrHPbCAnQQgIhhTUkAIIqUBez8///r44CgYExJAABAQUE7xnK/60kzwL4AAQAAg/hBchmD +Fp3FICIYU1JABCKyIDBIIiIYExJAOsfg/hhchOD+Hp3DoCIYU1JACCKyIDpIOvggKBgTEkA AEA7xnK+XsnDgz0oTEkAAHUSav3oLPz//1nHBShMSQABAAAAw1WL7IM9TExJAABXi30IiX0I dRH/dRD/dQxX6ComAACDxAzrY4tVEFaF0nQ9i00MigFKD7bw9oZhTUkABIgHdBNHQYXSdBmK AUqIB0dBhMB0FOsGR0GEwHQQhdJ10usKgGf/AOsEgGf+AIvCSoXAXnQTjUoBM8CL0cHpAvOr i8qD4QPzqotFCF9dw1WL7Gr/aFjSQABoBKxAAGShAAAAAFBkiSUAAAAAg+wcU1ZXiWXoM/85 PTA5SQB1RldXagFbU2hQ0kAAvgABAABWV/8VPNFAAIXAdAiJHTA5SQDrIldXU2hM0kAAVlf/ FUDRQACFwA+EIgEAAMcFMDlJAAIAAAA5fRR+EP91FP91EOieAQAAWVmJRRShMDlJAIP4AnUd /3Uc/3UY/3UU/3UQ/3UM/3UI/xVA0UAA6d4AAACD+AEPhdMAAAA5fSB1CKFMOUkAiUUgV1f/ dRT/dRCLRST32BvAg+AIQFD/dSD/FXjQQACL2Ild5DvfD4ScAAAAiX38jQQbg8ADJPzoXfT/ /4ll6IvEiUXcg038/+sTagFYw4tl6DP/iX3cg038/4td5Dl93HRmU/913P91FP91EGoB/3Ug /xV40EAAhcB0TVdXU/913P91DP91CP8VPNFAAIvwiXXYO/d0MvZFDQR0QDl9HA+EsgAAADt1 HH8e/3Uc/3UYU/913P91DP91CP8VPNFAAIXAD4WPAAAAM8CNZciLTfBkiQ0AAAAAX15bycPH RfwBAAAAjQQ2g8ADJPzoqfP//4ll6IvciV3gg038/+sSagFYw4tl6DP/M9uDTfz/i3XYO990 tFZT/3Xk/3Xc/3UM/3UI/xU80UAAhcB0nDl9HFdXdQRXV+sG/3Uc/3UYVlNoIAIAAP91IP8V oNBAAIvwO/cPhHH///+Lxuls////i1QkCItEJASF0laNSv90DYA4AHQIQIvxSYX2dfOAOABe dQUrRCQEw4vCw1WL7FGLRQiNSAGB+QABAAB3DIsNECpBAA+3BEHrUovIVos1ECpBAMH5CA+2 0fZEVgGAXnQOgGX+AIhN/IhF/WoC6wmAZf0AiEX8agFYjU0KagFqAGoAUVCNRfxQagHotSEA AIPEHIXAdQLJww+3RQojRQzJw1WL7FNWi3UMi0YMi14QqIIPhPMAAACoQA+F6wAAAKgBdBaD ZgQAqBAPhNsAAACLTggk/okOiUYMi0YMg2YEAINlDAAk7wwCZqkMAYlGDHUigf6gLUEAdAiB /sAtQQB1C1PoHiYAAIXAWXUHVujPJQAAWWb3RgwIAVd0ZItGCIs+K/iNSAGJDotOGEmF/4lO BH4QV1BT6PkjAACDxAyJRQzrM4P7/3QWi8OLy8H4BYPhH4sEhSBLSQCNBMjrBbjILEEA9kAE IHQNagJqAFPoJyMAAIPEDItGCIpNCIgI6xRqAY1FCF9XUFPopiMAAIPEDIlFDDl9DF90BoNO DCDrD4tFCCX/AAAA6wgMIIlGDIPI/15bXcNVi+yB7EgCAABTVleLfQwz9oofR4TbiXX0iXXs iX0MD4T0BgAAi03wM9LrCItN8It10DPSOVXsD4zcBgAAgPsgfBOA+3h/Dg++w4qAUNJAAIPg D+sCM8APvoTGcNJAAMH4BIP4B4lF0A+HmgYAAP8khfuUQACDTfD/iVXMiVXYiVXgiVXkiVX8 iVXc6XgGAAAPvsOD6CB0O4PoA3Qtg+gIdB9ISHQSg+gDD4VZBgAAg038COlQBgAAg038BOlH BgAAg038Aek+BgAAgE38gOk1BgAAg038AuksBgAAgPsqdSONRRBQ6PUGAACFwFmJReAPjRIG AACDTfwE99iJReDpBAYAAItF4A++y40EgI1EQdDr6YlV8OntBQAAgPsqdR6NRRBQ6LYGAACF wFmJRfAPjdMFAACDTfD/6coFAACNBIkPvsuNREHQiUXw6bgFAACA+0l0LoD7aHQggPtsdBKA +3cPhaAFAACATf0I6ZcFAACDTfwQ6Y4FAACDTfwg6YUFAACAPzZ1FIB/ATR1DkdHgE39gIl9 DOlsBQAAiVXQiw0QKkEAiVXcD7bD9kRBAYB0GY1F7FD/dQgPvsNQ6H8FAACKH4PEDEeJfQyN RexQ/3UID77DUOhmBQAAg8QM6SUFAAAPvsOD+GcPjxwCAACD+GUPjZYAAACD+FgPj+sAAAAP hHgCAACD6EMPhJ8AAABISHRwSEh0bIPoDA+F6QMAAGb3RfwwCHUEgE39CIt18IP+/3UFvv// /3+NRRBQ6JwFAABm90X8EAhZi8iJTfgPhP4BAACFyXUJiw0sLEEAiU34x0XcAQAAAIvBi9ZO hdIPhNQBAABmgzgAD4TKAQAAQEDr58dFzAEAAACAwyCDTfxAjb24/f//O8qJffgPjc8AAADH RfAGAAAA6dEAAABm90X8MAh1BIBN/Qhm90X8EAiNRRBQdDvoMAUAAFCNhbj9//9Q6HUjAACD xAyJRfSFwH0yx0XYAQAAAOspg+hadDKD6Al0xUgPhOgBAADpCAMAAOjYBAAAWYiFuP3//8dF 9AEAAACNhbj9//+JRfjp5wIAAI1FEFDoswQAAIXAWXQzi0gEhcl0LPZF/Qh0Fw+/ANHoiU34 iUX0x0XcAQAAAOm1AgAAg2XcAIlN+A+/AOmjAgAAoSgsQQCJRfhQ6Y4AAAB1DID7Z3UHx0Xw AQAAAItFEP91zIPACIlFEP918ItI+IlNuItA/IlFvA++w1CNhbj9//9QjUW4UP8VADBBAIt1 /IPEFIHmgAAAAHQUg33wAHUOjYW4/f//UP8VDDBBAFmA+2d1EoX2dQ6Nhbj9//9Q/xUEMEEA WYC9uP3//y11DYBN/QGNvbn9//+JffhX6GHm//9Z6fwBAACD6GkPhNEAAACD6AUPhJ4AAABI D4SEAAAASHRRg+gDD4T9/f//SEgPhLEAAACD6AMPhckBAADHRdQnAAAA6zwrwdH46bQBAACF yXUJiw0oLEEAiU34i8GL1k6F0nQIgDgAdANA6/ErwemPAQAAx0XwCAAAAMdF1AcAAAD2RfyA x0X0EAAAAHRdikXUxkXqMARRx0XkAgAAAIhF6+tI9kX8gMdF9AgAAAB0O4BN/QLrNY1FEFDo GwMAAPZF/CBZdAlmi03sZokI6wWLTeyJCMdF2AEAAADpIwIAAINN/EDHRfQKAAAA9kX9gHQM jUUQUOjtAgAAWetB9kX8IHQh9kX8QI1FEFB0DOjIAgAAWQ+/wJnrJei8AgAAWQ+3wOvy9kX8 QI1FEFB0COinAgAAWevg6J8CAABZM9L2RfxAdBuF0n8XfASFwHMR99iD0gCL8PfagE39AYv6 6wSL8Iv69kX9gHUDg+cAg33wAH0Jx0XwAQAAAOsEg2X894vGC8d1BINl5ACNRbeJRfiLRfD/ TfCFwH8Gi8YLx3Q7i0X0mVJQV1aJRcCJVcTobyEAAP91xIvYg8Mw/3XAV1bo7SAAAIP7OYvw i/p+AwNd1ItF+P9N+IgY67WNRbcrRfj/Rfj2Rf0CiUX0dBmLTfiAOTB1BIXAdQ3/TfhAi034 xgEwiUX0g33YAA+F9AAAAItd/PbDQHQm9scBdAbGReot6xT2wwF0BsZF6ivrCfbDAnQLxkXq IMdF5AEAAACLdeArdeQrdfT2wwx1Eo1F7FD/dQhWaiDoFwEAAIPEEI1F7FCNRer/dQj/deRQ 6DIBAACDxBD2wwh0F/bDBHUSjUXsUP91CFZqMOjlAAAAg8QQg33cAHRBg330AH47i0X0i134 jXj/ZosDQ1CNRchQQ+iWHwAAWYXAWX4yjU3sUf91CFCNRchQ6NgAAACDxBCLx0+FwHXQ6xWN RexQ/3UI/3X0/3X46LoAAACDxBD2RfwEdBKNRexQ/3UIVmog6HEAAACDxBCLfQyKH0eE24l9 DA+FE/n//4tF7F9eW8nDeY9AAE+OQABqjkAAto5AAO2OQAD1jkAAKo9AAL2PQABVi+yLTQz/ SQR4DosRikUIiAL/AQ+2wOsLUf91COiI9///WVmD+P+LRRB1BYMI/13D/wBdw1ZXi3wkEIvH T4XAfiGLdCQYVv90JBj/dCQU6Kz///+DxAyDPv90B4vHT4XAf+NfXsNTi1wkDIvDS1ZXhcB+ Jot8JByLdCQQD74GV0b/dCQcUOh1////g8QMgz//dAeLw0uFwH/iX15bw4tEJASDAASLAItA /MOLRCQEgwAIiwiLQfiLUfzDi0QkBIMABIsAZotA/MNWi3QkCIX2dCRW6MAfAABZhcBWdApQ 6N8fAABZWV7DagD/NQRLSQD/FZDRQABew/81uDpJAP90JAjoAwAAAFlZw4N8JATgdyL/dCQE 6BwAAACFwFl1FjlEJAh0EP90JATodScAAIXAWXXeM8DDVot0JAg7NSAwQQB3C1bopSIAAIXA WXUchfZ1A2oBXoPGD4Pm8FZqAP81BEtJAP8VlNFAAF7DVYvsgezEAQAAgGXrAFNWi3UMM9tX igaJXfyEwIldzA+E4QkAAIt9COsFi30IM9uDPRwsQQABfg8PtsBqCFDohvX//1lZ6w+LDRAq QQAPtsCKBEGD4Ag7w3Q2/038V41F/FdQ6CUKAABZWVDoBgoAAA+2RgFGUOhp7P//g8QMhcB0 Dg+2RgFGUOhX7P//WevugD4lD4XZCAAAgGXLAIBl6ACAZekAgGXyAIBl8QCAZeoAM/+AZfsA iV3kiV3giV30xkXzAYld0A+2XgFGgz0cLEEAAX4PD7bDagRQ6On0//9ZWesPiw0QKkEAD7bD igRBg+AEhcB0EotF9P9F4I0EgI1EQ9CJRfTrZYP7Tn8+dF6D+yp0MoP7RnRUg/tJdAqD+0x1 N/5F8+tFgH4BNnUsgH4CNI1GAnUj/0XQg2XYAINl3ACL8Osn/kXy6yKD+2h0F4P7bHQKg/t3 dAj+RfHrDv5F8/5F++sG/k3z/k37gH3xAA+ET////4B98gCJdQx1EotFEIlFvIPABIlFEItA /IlF1IBl8QCAffsAdRSKBjxTdAo8Q3QGgE37/+sExkX7AYtdDA+2M4POIIP+bol1xHQog/5j dBSD/nt0D/91CI1F/FDotQgAAFnrC/91CP9F/Oh2CAAAWYlF7DPAOUXgdAk5RfQPhNwHAACD /m8Pj14CAAAPhAoFAACD/mMPhCwCAACD/mQPhPgEAAAPjmoCAACD/md+OIP+aXQbg/5uD4VX AgAAgH3yAIt9/A+EAAcAAOkhBwAAamRei13sg/stD4V+AgAAxkXpAel6AgAAi13sjbU8/v// g/stdQ6InTz+//+NtT3+///rBYP7K3UXi30I/030/0X8V+jOBwAAi9hZiV3s6wOLfQiDfeAA dAmBffRdAQAAfgfHRfRdAQAAgz0cLEEAAX4MagRT6Anz//9ZWesLoRAqQQCKBFiD4ASFwHQh i0X0/030hcB0F/9F5IgeRv9F/FfocAcAAIvYWYld7Ou7OB0gLEEAdWaLRfT/TfSFwHRc/0X8 V+hNBwAAi9igICxBAIgGWYld7EaDPRwsQQABfgxqBFPom/L//1lZ6wuhECpBAIoEWIPgBIXA dCGLRfT/TfSFwHQX/0XkiB5G/0X8V+gCBwAAi9hZiV3s67uDfeQAD4SOAAAAg/tldAmD+0UP hYAAAACLRfT/TfSFwHR2xgZlRv9F/FfoywYAAIvYWYP7LYld7HUFiAZG6wWD+yt1HotF9P9N 9IXAdQUhRfTrD/9F/FfongYAAIvYWYld7IM9HCxBAAF+DGoEU+j08f//WVnrC6EQKkEAigRY g+AEhcB0EotF9P9N9IXAdAj/ReSIHkbru/9N/FdT6HIGAACDfeQAWVkPhPYFAACAffIAD4VN BQAA/0XMgCYAjYU8/v//UA++RfP/ddRIUP8VCDBBAIPEDOkpBQAAOUXgdQr/RfTHReABAAAA gH37AH4ExkXqAb84LEEA6QsBAACLxoPocA+EowIAAIPoAw+E6AAAAEhID4SWAgAAg+gDD4TD /f//g+gDdCQPtgM7RewPhT8FAAD+TeuAffIAD4XDBAAAi0W8iUUQ6bgEAACAffsAfgTGReoB i30MR4l9DIA/Xg+FpwAAAIvHjXgB6ZkAAACD+yt1Iv9N9HUMg33gAHQGxkXxAesR/3UI/0X8 6GgFAACL2FmJXeyD+zAPhUUCAAD/dQj/RfzoTgUAAIvYWYD7eIld7HQvgPtYdCqD/njHReQB AAAAdAhqb17pFgIAAP91CP9N/FPoOAUAAFlZajBb6f0BAAD/dQj/RfzoCQUAAFmL2Ild7Gp4 68+AffsAfgTGReoBvzAsQQCATej/aiCNRZxqAFDo7Nr//4PEDIN9xHt1DoA/XXUJsl1HxkWn IOsDilXLigc8XXRfRzwtdUGE0nQ9ig+A+V10Nkc60XMEisHrBIrCitE60HchD7bSD7bwK/JG i8qLwoPhB7MBwegD0uONRAWcCBhCTnXoMtLrtA+2yIrQi8GD4QezAcHoA9LjjUQFnAgY65uA PwAPhAEEAACDfcR7dQOJfQyLfQiLddT/TfxX/3XsiXXQ6FMEAABZWYN94AB0DotF9P9N9IXA D4ScAAAA/0X8V+gaBAAAg/j/WYlF7HR+i8hqAYPhB1oPvl3o0+KLyMH5Aw++TA2cM8uF0XRg gH3yAHVSgH3qAHRBiw0QKkEAiEXID7bA9kRBAYB0Df9F/FfoywMAAFmIRcn/NRwsQQCNRchQ jUXCUOiqIAAAZotFwoPEDGaJBkZG6wOIBkaJddTpZP////9F0Olc/////038V1DoowMAAFlZ OXXQD4QoAwAAgH3yAA+FfwIAAP9FzIN9xGMPhHICAACAfeoAi0XUdAlmgyAA6WACAACAIADp WAIAAMZF8wGLXeyD+y11BsZF6QHrBYP7K3Ui/030dQyDfeAAdAbGRfEB6xH/dQj/RfzoGgMA AFmL2Ild7IN90AAPhA8BAACAffEAD4XjAAAAg/54dU+DPRwsQQABfg9ogAAAAFPoVO7//1lZ 6w2hECpBAIoEWCWAAAAAhcAPhKMAAACLRdiLVdxqBFnozSAAAFOJRdiJVdzofQIAAIvYWYld 7OtTgz0cLEEAAX4MagRT6Aju//9ZWesLoRAqQQCKBFiD4ASFwHRdg/5vdRWD+zh9U4tF2ItV 3GoDWeh9IAAA6w9qAGoK/3Xc/3XY6CwgAACJRdiJVdz/ReSNQ9CZAUXYEVXcg33gAHQF/030 dCT/dQj/RfzoNgIAAIvYWYld7Okr/////3UI/038U+g5AgAAWVmAfekAD4TcAAAAi0XYi03c 99iD0QCJRdj32YlN3OnEAAAAgH3xAA+FsgAAAIP+eHQ/g/5wdDqDPRwsQQABfgxqBFPoQ+3/ /1lZ6wuhECpBAIoEWIPgBIXAdHaD/m91CoP7OH1swecD6z+NPL/R5+s4gz0cLEEAAX4PaIAA AABT6Abt//9ZWesNoRAqQQCKBFglgAAAAIXAdDdTwecE6EQBAACL2FmJXez/ReSDfeAAjXwf 0HQF/030dCT/dQj/RfzoWAEAAIvYWYld7Olc/////3UI/038U+hbAQAAWVmAfekAdAL334P+ RnUEg2XkAIN95AAPhM4AAACAffIAdSn/RcyDfdAAdBCLRdSLTdiJCItN3IlIBOsQgH3zAItF 1HQEiTjrA2aJOP5F6/9FDIt1DOtC/0X8V+jhAAAAi9hZD7YGRjvDiV3siXUMdVWLDRAqQQAP tsP2REEBgHQY/0X8V+i3AAAAWQ+2DkY7yIl1DHU+/038g33s/3UQgD4ldU2LRQyAeAFudUSL 8IoGhMAPhVb2///rMP91CP9N/P917OsF/038V1PoiwAAAFlZ6xf/TfxXUOh9AAAA/038V1Po cwAAAIPEEIN97P91EYtFzIXAdQ04Ret1CIPI/+sDi0XMX15bycODPRwsQQABVn4Qi3QkCGoE VuiO6///WVnrD4t0JAihECpBAIoEcIPgBIXAdQaD5t+D7geLxl7Di1QkBP9KBHgJiwoPtgFB iQrDUugUHgAAWcODfCQE/3QP/3QkCP90JAjo1x4AAFlZw1aLdCQIV/90JBD/Bui+////i/hX 6D7i//9ZhcBZdeeLx19ew8zMzMzMzMzMjUL/W8ONpCQAAAAAjWQkADPAikQkCFOL2MHgCItU JAj3wgMAAAB0E4oKQjjZdNGEyXRR98IDAAAAde0L2FeLw8HjEFYL2IsKv//+/n6LwYv3M8sD 8AP5g/H/g/D/M88zxoPCBIHhAAEBgXUcJQABAYF00yUAAQEBdQiB5gAAAIB1xF5fWzPAw4tC /DjYdDaEwHTvONx0J4TkdOfB6BA42HQVhMB03DjcdAaE5HTU65ZeX41C/1vDjUL+Xl9bw41C /V5fW8ONQvxeX1vDoTRMSQCFwHQC/9BoFPBAAGgI8EAA6M4AAABoBPBAAGgA8EAA6L8AAACD xBDDagBqAP90JAzoFQAAAIPEDMNqAGoB/3QkDOgEAAAAg8QMw1dqAV85PZw5SQB1Ef90JAj/ FazQQABQ/xUo0UAAg3wkDABTi1wkFIk9mDlJAIgdlDlJAHU8oTBMSQCFwHQiiw0sTEkAVo1x /DvwchOLBoXAdAL/0IPuBDs1MExJAHPtXmgg8EAAaBjwQADoKgAAAFlZaCjwQABoJPBAAOgZ AAAAWVmF21t1EP90JAiJPZw5SQD/FXzRQABfw1aLdCQIO3QkDHMNiwaFwHQC/9CDxgTr7V7D VYvsU/91COg1AQAAhcBZD4QgAQAAi1gIhdsPhBUBAACD+wV1DINgCABqAVjpDQEAAIP7AQ+E 9gAAAIsNoDlJAIlNCItNDIkNoDlJAItIBIP5CA+FyAAAAIsNuCxBAIsVvCxBAAPRVjvKfRWN NEkr0Y00tUgsQQCDJgCDxgxKdfeLAIs1xCxBAD2OAADAdQzHBcQsQQCDAAAA63A9kAAAwHUM xwXELEEAgQAAAOtdPZEAAMB1DMcFxCxBAIQAAADrSj2TAADAdQzHBcQsQQCFAAAA6zc9jQAA wHUMxwXELEEAggAAAOskPY8AAMB1DMcFxCxBAIYAAADrET2SAADAdQrHBcQsQQCKAAAA/zXE LEEAagj/01mJNcQsQQBZXusIg2AIAFH/01mLRQijoDlJAIPI/+sJ/3UM/xWY0UAAW13Di1Qk BIsNwCxBADkVQCxBAFa4QCxBAHQVjTRJjTS1QCxBAIPADDvGcwQ5EHX1jQxJXo0MjUAsQQA7 wXMEORB0AjPAw4M9KExJAAB1Bei75P//Vos1aE5JAIoGPCJ1JYpGAUY8InQVhMB0EQ+2wFDo lBsAAIXAWXTmRuvjgD4idQ1G6wo8IHYGRoA+IHf6igaEwHQEPCB26YvGXsNTM9s5HShMSQBW V3UF6F/k//+LNSA5SQAz/4oGOsN0Ejw9dAFHVugr0///WY10BgHr6I0EvQQAAABQ6Orw//+L 8Fk784k1fDlJAHUIagnoEeD//1mLPSA5SQA4H3Q5VVfo8dL//4voWUWAPz10IlXotfD//zvD WYkGdQhqCeji3///WVf/Nujb0f//WYPGBFkD/Tgfdcld/zUgOUkA6Fjw//9ZiR0gOUkAiR5f XscFJExJAAEAAABbw1WL7FFRUzPbOR0oTEkAVld1Beih4///vqQ5SQBoBAEAAFZT/xUU0UAA oWhOSQCJNYw5SQCL/jgYdAKL+I1F+FCNRfxQU1NX6E0AAACLRfiLTfyNBIhQ6BXw//+L8IPE GDvzdQhqCOhA3///WY1F+FCNRfxQi0X8jQSGUFZX6BcAAACLRfyDxBRIiTV0OUkAX16jcDlJ AFvJw1WL7ItNGItFFFNWgyEAi3UQV4t9DMcAAQAAAItFCIX/dAiJN4PHBIl9DIA4InVEilAB QID6InQphNJ0JQ+20vaCYU1JAAR0DP8BhfZ0BooQiBZGQP8BhfZ01YoQiBZG687/AYX2dASA JgBGgDgidUZA60P/AYX2dAWKEIgWRooQQA+22vaDYU1JAAR0DP8BhfZ0BYoYiB5GQID6IHQJ hNJ0CYD6CXXMhNJ1A0jrCIX2dASAZv8Ag2UYAIA4AA+E4AAAAIoQgPogdAWA+gl1A0Dr8YA4 AA+EyAAAAIX/dAiJN4PHBIl9DItVFP8Cx0UIAQAAADPbgDhcdQRAQ+v3gDgidSz2wwF1JTP/ OX0YdA2AeAEijVABdQSLwusDiX0Ii30MM9I5VRgPlMKJVRjR64vTS4XSdA5DhfZ0BMYGXEb/ AUt184oQhNJ0SoN9GAB1CoD6IHQ/gPoJdDqDfQgAdC6F9nQZD7ba9oNhTUkABHQGiBZGQP8B ihCIFkbrDw+20vaCYU1JAAR0A0D/Af8BQOlY////hfZ0BIAmAEb/AekX////hf90A4MnAItF FF9eW/8AXcNRUaGoOkkAU1WLLajRQABWVzPbM/Yz/zvDdTP/1YvwO/N0DMcFqDpJAAEAAADr KP8VpNFAAIv4O/sPhOoAAADHBag6SQACAAAA6Y8AAACD+AEPhYEAAAA783UM/9WL8DvzD4TC AAAAZjkei8Z0DkBAZjkYdflAQGY5GHXyK8aLPaDQQADR+FNTQFNTUFZTU4lEJDT/14voO+t0 MlXogu3//zvDWYlEJBB0I1NTVVD/dCQkVlNT/9eFwHUO/3QkEOgw7f//WYlcJBCLXCQQVv8V oNFAAIvD61OD+AJ1TDv7dQz/FaTRQACL+Dv7dDw4H4vHdApAOBh1+0A4GHX2K8dAi+hV6Bvt //+L8Fk783UEM/brC1VXVuj10v//g8QMV/8VnNFAAIvG6wIzwF9eXVtZWcOD7ERTVVZXaAAB AADo4Oz//4vwWYX2dQhqG+gN3P//WYk1IEtJAMcFIExJACAAAACNhgABAAA78HMagGYEAIMO /8ZGBQqhIEtJAIPGCAUAAQAA6+KNRCQQUP8VeNFAAGaDfCRCAA+ExQAAAItEJESFwA+EuQAA AIswjWgEuAAIAAA78I0cLnwCi/A5NSBMSQB9Ur8kS0kAaAABAADoUOz//4XAWXQ4gwUgTEkA IIkHjYgAAQAAO8FzGIBgBACDCP/GQAUKiw+DwAiBwQABAADr5IPHBDk1IExJAHy76waLNSBM SQAz/4X2fkaLA4P4/3Q2ik0A9sEBdC72wQh1C1D/FWzRQACFwHQei8eLz8H4BYPhH4sEhSBL SQCNBMiLC4kIik0AiEgER0WDwwQ7/ny6M9uhIEtJAIM82P+NNNh1TYXbxkYEgXUFavZY6wqL w0j32BvAg8D1UP8VcNFAAIv4g///dBdX/xVs0UAAhcB0DCX/AAAAiT6D+AJ1BoBOBEDrD4P4 A3UKgE4ECOsEgE4EgEOD+wN8m/81IExJAP8VjNFAAF9eXVuDxETDM8BqADlEJAhoABAAAA+U wFD/FWTRQACFwKMES0kAdBXogwoAAIXAdQ//NQRLSQD/FWjRQAAzwMNqAVjDzMzMVYvsU1ZX VWoAagBoJKtAAP91COieHAAAXV9eW4vlXcOLTCQE90EEBgAAALgBAAAAdA+LRCQIi1QkEIkC uAMAAADDU1ZXi0QkEFBq/mgsq0AAZP81AAAAAGSJJQAAAACLRCQgi1gIi3AMg/7/dC47dCQk dCiNNHaLDLOJTCQIiUgMg3yzBAB1EmgBAQAAi0SzCOhAAAAA/1SzCOvDZI8FAAAAAIPEDF9e W8MzwGSLDQAAAACBeQQsq0AAdRCLUQyLUgw5UQh1BbgBAAAAw1NRu9QsQQDrClNRu9QsQQCL TQiJSwiJQwSJawxZW8IEAMzMVkMyMFhDMDBVi+yD7AhTVldV/ItdDItFCPdABAYAAAAPhYIA AACJRfiLRRCJRfyNRfiJQ/yLcwyLewiD/v90YY0MdoN8jwQAdEVWVY1rEP9UjwRdXotdDAvA dDN4PIt7CFPoqf7//4PEBI1rEFZT6N7+//+DxAiNDHZqAYtEjwjoYf///4sEj4lDDP9UjwiL ewiNDHaLNI/robgAAAAA6xy4AQAAAOsVVY1rEGr/U+ie/v//g8QIXbgBAAAAXV9eW4vlXcNV i0wkCIspi0EcUItBGFDoef7//4PECF3CBAChKDlJAIP4AXQNhcB1KoM9FClBAAF1IWj8AAAA 6BgAAAChrDpJAFmFwHQC/9Bo/wAAAOgCAAAAWcNVi+yB7KQBAACLVQgzybjoLEEAOxB0C4PA CEE9eC1BAHzxVovxweYDO5boLEEAD4UcAQAAoSg5SQCD+AEPhOgAAACFwHUNgz0UKUEAAQ+E 1wAAAIH6/AAAAA+E8QAAAI2FXP7//2gEAQAAUGoA/xUU0UAAhcB1E42FXP7//2i81UAAUOiz yf//WVmNhVz+//9XUI29XP7//+iOyv//QFmD+Dx2KY2FXP7//1Doe8r//4v4jYVc/v//g+g7 agMD+Gi41UAAV+jhAQAAg8QQjYVg////aJzVQABQ6F3J//+NhWD///9XUOhgyf//jYVg//// aJjVQABQ6E/J////tuwsQQCNhWD///9Q6D3J//9oECABAI2FYP///2hw1UAAUOhfEgAAg8Qs X+smjUUIjbbsLEEAagBQ/zbo7sn//1lQ/zZq9P8VcNFAAFD/FWzQQABeycNVi+xq/2jY1UAA aASsQABkoQAAAABQZIklAAAAAIPsGFNWV4ll6KGwOkkAM9s7w3U+jUXkUGoBXlZoUNJAAFb/ FVTRQACFwHQEi8brHY1F5FBWaEzSQABWU/8VWNFAAIXAD4TOAAAAagJYo7A6SQCD+AJ1JItF HDvDdQWhPDlJAP91FP91EP91DP91CFD/FVjRQADpnwAAAIP4AQ+FlAAAADldGHUIoUw5SQCJ RRhTU/91EP91DItFIPfYG8CD4AhAUP91GP8VeNBAAIlF4DvDdGOJXfyNPACLx4PAAyT86BTQ //+JZeiL9Il13FdTVuiUx///g8QM6wtqAVjDi2XoM9sz9oNN/P8783Qp/3XgVv91EP91DGoB /3UY/xV40EAAO8N0EP91FFBW/3UI/xVU0UAA6wIzwI1lzItN8GSJDQAAAABfXlvJw8zMzMzM zMzMzMzMzMzMzItMJAxXhcl0elZTi9mLdCQU98YDAAAAi3wkEHUHwekCdW/rIYoGRogHR0l0 JYTAdCn3xgMAAAB164vZwekCdVGD4wN0DYoGRogHR4TAdC9LdfOLRCQQW15fw/fHAwAAAHQS iAdHSQ+EigAAAPfHAwAAAHXui9nB6QJ1bIgHR0t1+ltei0QkCF/DiReDxwRJdK+6//7+fosG A9CD8P8zwosWg8YEqQABAYF03oTSdCyE9nQe98IAAP8AdAz3wgAAAP91xokX6xiB4v//AACJ F+sOgeL/AAAAiRfrBDPSiReDxwQzwEl0CjPAiQeDxwRJdfiD4wN1hYtEJBBbXl/Di0QkBFM7 BSBMSQBWV3Nzi8iL8MH5BYPmH408jSBLSQDB5gOLD/ZEMQQBdFZQ6BIRAACD+P9ZdQzHBVQ5 SQAJAAAA60//dCQYagD/dCQcUP8V5NBAAIvYg/v/dQj/FeDQQADrAjPAhcB0CVDo8w8AAFnr IIsHgGQwBP2NRDAEi8PrFIMlWDlJAADHBVQ5SQAJAAAAg8j/X15bw1WL7IHsFAQAAItNCFM7 DSBMSQBWVw+DeQEAAIvBi/HB+AWD5h+NHIUgS0kAweYDiwOKRDAEqAEPhFcBAAAz/zl9EIl9 +Il98HUHM8DpVwEAAKggdAxqAldR6Aj///+DxAyLAwPG9kAEgA+EwQAAAItFDDl9EIlF/Il9 CA+G5wAAAI2F7Pv//4tN/CtNDDtNEHMpi038/0X8igmA+Qp1B/9F8MYADUCICECLyI2V7Pv/ /yvKgfkABAAAfMyL+I2F7Pv//yv4jUX0agBQjYXs+///V1CLA/80MP8VbNBAAIXAdEOLRfQB Rfg7x3wLi0X8K0UMO0UQcooz/4tF+DvHD4WLAAAAOX0IdF9qBVg5RQh1TMcFVDlJAAkAAACj WDlJAOmAAAAA/xXg0EAAiUUI68eNTfRXUf91EP91DP8w/xVs0EAAhcB0C4tF9Il9CIlF+Oun /xXg0EAAiUUI65z/dQjoZA4AAFnrPYsD9kQwBEB0DItFDIA4Gg+Ezf7//8cFVDlJABwAAACJ PVg5SQDrFitF8OsUgyVYOUkAAMcFVDlJAAkAAACDyP9fXlvJw/8FtDpJAGgAEAAA6P7i//9Z i0wkBIXAiUEIdA2DSQwIx0EYABAAAOsRg0kMBI1BFIlBCMdBGAIAAACLQQiDYQQAiQHDi0Qk BDsFIExJAHIDM8DDi8iD4B/B+QWLDI0gS0kAikTBBIPgQMOhAEtJAFZqFIXAXnUHuAACAADr BjvGfQeLxqMAS0kAagRQ6KkOAABZo+Q6SQCFwFl1IWoEVok1AEtJAOiQDgAAWaPkOkkAhcBZ dQhqGuiN0f//WTPJuIAtQQCLFeQ6SQCJBBGDwCCDwQQ9ADBBAHzqM9K5kC1BAIvCi/LB+AWD 5h+LBIUgS0kAiwTwg/j/dASFwHUDgwn/g8EgQoH58C1BAHzUXsPokg8AAIA9lDlJAAB0BemV DgAAw1WL7ItFCIXAdQJdw4M9PDlJAAB1EmaLTQxmgfn/AHc5agGICFhdw41NCINlCABRagD/ NRwsQQBQjUUMagFQaCACAAD/NUw5SQD/FaDQQACFwHQGg30IAHQNxwVUOUkAKgAAAIPI/13D U1aLRCQYC8B1GItMJBSLRCQQM9L38YvYi0QkDPfxi9PrQYvIi1wkFItUJBCLRCQM0enR29Hq 0dgLyXX09/OL8PdkJBiLyItEJBT35gPRcg47VCQQdwhyBztEJAx2AU4z0ovGXlvCEADMzMzM zMzMzFOLRCQUC8B1GItMJBCLRCQMM9L38YtEJAj38YvCM9LrUIvIi1wkEItUJAyLRCQI0enR 29Hq0dgLyXX09/OLyPdkJBSR92QkEAPRcg47VCQMdwhyDjtEJAh2CCtEJBAbVCQUK0QkCBtU JAz32vfYg9oAW8IQAGhAAQAAagD/NQRLSQD/FZTRQACFwKPgOkkAdQHDgyXYOkkAAIMl3DpJ AABqAaPUOkkAxwXMOkkAEAAAAFjDodw6SQCNDICh4DpJAI0MiDvBcxSLVCQEK1AMgfoAABAA cgeDwBTr6DPAw1WL7IPsFItVDItNCFNWi0EQi/IrcQyLWvyDwvxXwe4Pi86LevxpyQQCAABL iX38jYwBRAEAAIld9IlN8IsME/bBAYlN+HV/wfkEaj9JX4lNDDvPdgOJfQyLTBMEO0wTCHVI i00Mg/kgcxy/AAAAgNPvjUwBBPfXIXywRP4JdSuLTQghOeskg8HgvwAAAIDT74tNDI1MAQT3 1yG8sMQAAAD+CXUGi00IIXkEi0wTCIt8EwSJeQSLTBMEi3wTCANd+Il5CIld9Iv7wf8ET4P/ P3YDaj9fi038g+EBiU3sD4WgAAAAK1X8i038wfkEaj+JVfhJWjvKiU0MdgWJVQyLygNd/Iv7 iV30wf8ETzv6dgKL+jvPdGuLTfiLUQQ7UQh1SItNDIP5IHMcugAAAIDT6o1MAQT30iFUsET+ CXUri00IIRHrJIPB4LoAAACA0+qLTQyNTAEE99IhlLDEAAAA/gl1BotNCCFRBItN+ItRCItJ BIlKBItN+ItRBItJCIlKCItV+IN97AB1CTl9DA+EiQAAAItN8I0M+YtJBIlKBItN8I0M+YlK CIlRBItKBIlRCItKBDtKCHVjikwHBIP/IIhND/7BiEwHBHMlgH0PAHUOuwAAAICLz9Pri00I CRm7AAAAgIvP0+uNRLBECRjrKYB9DwB1EI1P4LsAAACA0+uLTQgJWQSNT+C/AAAAgNPvjYSw xAAAAAk4i130i0XwiRqJXBP8/wgPhfoAAACh2DpJAIXAD4TfAAAAiw3QOkkAiz1g0UAAweEP A0gMuwCAAABoAEAAAFNR/9eLDdA6SQCh2DpJALoAAACA0+oJUAih2DpJAIsN0DpJAItAEIOk iMQAAAAAodg6SQCLQBD+SEOh2DpJAItIEIB5QwB1CYNgBP6h2DpJAIN4CP91bFNqAP9wDP/X odg6SQD/cBBqAP81BEtJAP8VkNFAAKHcOkkAixXgOkkAjQSAweACi8ih2DpJACvIjUwR7FGN SBRRUOgPx///i0UIg8QM/w3cOkkAOwXYOkkAdgOD6BSLDeA6SQCJDdQ6SQDrA4tFCKPYOkkA iTXQOkkAX15bycNVi+yD7BSh3DpJAIsV4DpJAFNWjQSAV408gotFCIl9/I1IF4Ph8IlN8MH5 BEmD+SB9DoPO/9Pug034/4l19OsQg8Hgg8j/M/bT6Il19IlF+KHUOkkAi9g734ldCHMZi0sE izsjTfgj/gvPdQuDwxQ7XfyJXQhy5ztd/HV5i9o72IldCHMVi0sEizsjTfgj/gvPdQWDwxTr 5jvYdVk7XfxzEYN7CAB1CIPDFIldCOvtO138dSaL2jvYiV0Icw2DewgAdQWDwxTr7jvYdQ7o OAIAAIvYhduJXQh0FFPo2gIAAFmLSxCJAYtDEIM4/3UHM8DpDwIAAIkd1DpJAItDEIsQg/r/ iVX8dBSLjJDEAAAAi3yQRCNN+CP+C891N4uQxAAAAItwRCNV+CN19INl/ACNSEQL1ot19HUX i5GEAAAA/0X8I1X4g8EEi/4jOQvXdOmLVfyLyjP/ackEAgAAjYwBRAEAAIlN9ItMkEQjznUN i4yQxAAAAGogI034X4XJfAXR4Ufr94tN9ItU+QSLCitN8IvxiU34wf4EToP+P34Daj9eO/cP hA0BAACLSgQ7Sgh1YYP/IH0ruwAAAICLz9Pri038jXw4BPfTiV3sI1yIRIlciET+D3U4i10I i03sIQvrMY1P4LsAAACA0+uLTfyNfDgEjYyIxAAAAPfTIRn+D4ld7HULi10Ii03sIUsE6wOL XQiLSgiLegSDffgAiXkEi0oEi3oIiXkID4SUAAAAi030i3zxBI0M8Yl6BIlKCIlRBItKBIlR CItKBDtKCHVkikwGBIP+IIhNC30p/sGAfQsAiEwGBHULvwAAAICLztPvCTu/AAAAgIvO0++L TfwJfIhE6y/+wYB9CwCITAYEdQ2NTuC/AAAAgNPvCXsEi038jbyIxAAAAI1O4L4AAACA0+4J N4tN+IXJdAuJColMEfzrA4tN+It18APRjU4BiQqJTDL8i3X0iw6FyY15AYk+dRo7Hdg6SQB1 EotN/DsN0DpJAHUHgyXYOkkAAItN/IkIjUIEX15bycOh3DpJAIsNzDpJAFZXM/87wXUwjUSJ UMHgAlD/NeA6SQBX/zUES0kA/xVM0UAAO8d0YYMFzDpJABCj4DpJAKHcOkkAiw3gOkkAaMRB AABqCI0EgP81BEtJAI00gf8VlNFAADvHiUYQdCpqBGgAIAAAaAAAEABX/xVQ0UAAO8eJRgx1 FP92EFf/NQRLSQD/FZDRQAAzwOsXg04I/4k+iX4E/wXcOkkAi0YQgwj/i8ZfXsNVi+xRi00I U1ZXi3EQi0EIM9uFwHwF0eBD6/eLw2o/acAEAgAAWo2EMEQBAACJRfyJQAiJQASDwAhKdfSL +2oEwecPA3kMaAAQAABoAIAAAFf/FVDRQACFwHUIg8j/6ZMAAACNlwBwAAA7+nc8jUcQg0j4 /4OI7A8AAP+NiPwPAADHQPzwDwAAiQiNiPzv//+JSATHgOgPAADwDwAABQAQAACNSPA7ynbH i0X8jU8MBfgBAABqAV+JSASJQQiNSgyJSAiJQQSDZJ5EAIm8nsQAAACKRkOKyP7BhMCLRQiI TkN1Awl4BLoAAACAi8vT6vfSIVAIi8NfXlvJw6G8OkkAhcB0D/90JAT/0IXAWXQEagFYwzPA w1WL7FNWi3UMM9s783QVOV0QdBCKBjrDdRCLRQg7w3QDZokYM8BeW13DOR08OUkAdROLTQg7 y3QHZg+2wGaJAWoBWOvhiw0QKkEAD7bA9kRBAYB0TaEcLEEAg/gBfio5RRB8LzPJOV0ID5XB Uf91CFBWagn/NUw5SQD/FXjQQACFwKEcLEEAdZ05RRByBTheAXWTxwVUOUkAKgAAAIPI/+uE M8A5XQgPlcBQ/3UIagFWagn/NUw5SQD/FXjQQACFwA+Fef///+vKzMzMzMzMzMzMzMzMzMzM i0QkCItMJBALyItMJAx1CYtEJAT34cIQAFP34YvYi0QkCPdkJBQD2ItEJAj34QPTW8IQAMzM zMzMzMzMzMzMzID5QHMVgPkgcwYPpcLT4MOL0DPAgOEf0+LDM8Az0sNWi3QkCItGDKiDD4TE AAAAqEAPhbwAAACoAnQKDCCJRgzprgAAAAwBZqkMAYlGDHUJVui/8///WesFi0YIiQb/dhj/ dgj/dhDozgQAAIPEDIlGBIXAdGyD+P90Z4tWDPbCgnU0i04QV4P5/3QUi/nB/wWD4R+LPL0g S0kAjTzP6wW/yCxBAIpPBF+A4YKA+YJ1BoDOIIlWDIF+GAACAAB1FItODPbBCHQM9sUEdQfH RhgAEAAAiw5IiUYED7YBQYkOXsP32BvAg+AQg8AQCUYMg2YEAIPI/17DU4tcJAiD+/9WdEGL dCQQi0YMqAF1CKiAdDKoAnUug34IAHUHVujz8v//WYsGO0YIdQmDfgQAdRRAiQb2RgxAdBH/ DosGOBh0D0CJBoPI/15bw/8OiwaIGItGDP9GBCTvDAGJRgyLwyX/AAAA6+FqBGoA/3QkDOgE AAAAg8QMww+2RCQEikwkDISIYU1JAHUcg3wkCAB0Dg+3BEUaKkEAI0QkCOsCM8CFwHUBw2oB WMNTM9s5HcA6SQBWV3VCaBTWQAD/FfTQQACL+Dv7dGeLNTjRQABoCNZAAFf/1oXAo8A6SQB0 UGj41UAAV//WaOTVQABXo8Q6SQD/1qPIOkkAocQ6SQCFwHQW/9CL2IXbdA6hyDpJAIXAdAVT /9CL2P90JBj/dCQY/3QkGFP/FcA6SQBfXlvDM8Dr+ItMJAQz0okNWDlJALgwMEEAOwh0IIPA CEI9mDFBAHzxg/kTch2D+SR3GMcFVDlJAA0AAADDiwTVNDBBAKNUOUkAw4H5vAAAAHISgfnK AAAAxwVUOUkACAAAAHYKxwVUOUkAFgAAAMOLTCQEVjsNIExJAFdzVYvBi/HB+AWD5h+NPIUg S0kAweYDiwcDxvZABAF0N4M4/3Qygz0UKUEAAXUfM8AryHQQSXQISXUTUGr06whQavXrA1Bq 9v8VSNFAAIsHgwww/zPA6xSDJVg5SQAAxwVUOUkACQAAAIPI/19ew4tEJAQ7BSBMSQBzHIvI g+AfwfkFiwyNIEtJAPZEwQQBjQTBdAOLAMODJVg5SQAAxwVUOUkACQAAAIPI/8NTVot0JAxX D690JBSD/uCL3ncNhfZ1A2oBXoPGD4Pm8DP/g/7gdyo7HSAwQQB3DVPolfb//4v4WYX/dStW agj/NQRLSQD/FZTRQACL+IX/dSKDPbg6SQAAdBlW6B/7//+FwFl0FOu5U2oAV+hBtP//g8QM i8dfXlvDM8Dr+FZXagMz/145NQBLSQB+RKHkOkkAiwSwhcB0L/ZADIN0DVDoPQMAAIP4/1l0 AUeD/hR8F6HkOkkA/zSw6OjS//+h5DpJAFmDJLAARjs1AEtJAHy8i8dfXsNWi3QkCIX2dQlW 6JEAAABZXsNW6CMAAACFwFl0BYPI/17D9kYNQHQP/3YQ6DIDAAD32FleG8DDM8Bew1NWi3Qk DDPbV4tGDIvIg+EDgPkCdTdmqQgBdDGLRgiLPiv4hf9+JldQ/3YQ6Njt//+DxAw7x3UOi0YM qIB0DiT9iUYM6weDTgwgg8v/i0YIg2YEAIkGX4vDXlvDagHoAgAAAFnDU1ZXM/Yz2zP/OTUA S0kAfk2h5DpJAIsEsIXAdDiLSAz2wYN0MIN8JBABdQ9Q6C7///+D+P9ZdB1D6xqDfCQQAHUT 9sECdA5Q6BP///+D+P9ZdQIL+EY7NQBLSQB8s4N8JBABi8N0AovHX15bw2oC6CbB//9Zw1WL 7IPsDFNWi3UIVzs1IExJAA+DxQEAAIvGg+YfwfgFweYDjRyFIEtJAIsEhSBLSQADxopQBPbC AQ+EngEAAINl+ACLfQyDfRAAi890Z/bCAnVi9sJIdB2KQAU8CnQW/00QiAeLA41PAcdF+AEA AADGRDAFCo1F9GoAUIsD/3UQUf80MP8VcNBAAIXAdTr/FeDQQABqBVk7wXUVxwVUOUkACQAA AIkNWDlJAOk+AQAAg/htdQczwOk1AQAAUOg1/P//WekmAQAAiwOLVfQBVfiNTDAEikQwBKiA D4T4AAAAhdJ0CYA/CnUEDATrAiT7iAGLRQyLTfiJRRADyDvBiU34D4PLAAAAi0UQigA8Gg+E rgAAADwNdAuIB0f/RRDpkQAAAEk5TRBzGItFEECAOAp1BoNFEALrXsYHDUeJRRDrc41F9GoA UP9FEI1F/2oBUIsD/zQw/xVw0EAAhcB1Cv8V4NBAAIXAdUeDffQAdEGLA/ZEMARIdBOKRf88 CnQXxgcNiwtHiEQxBespO30MdQuAff8KdQXGBwrrGGoBav//dQjo7er//4PEDIB9/wp0BMYH DUeLTfg5TRAPgkf////rEIsDjXQwBIoGqEB1BAwCiAYrfQyJffiLRfjrFIMlWDlJAADHBVQ5 SQAJAAAAg8j/X15bycNWi3QkCFeDz/+LRgyoQHQFg8j/6zqog3Q0VugQ/f//Vov46DkBAAD/ dhDofgAAAIPEDIXAfQWDz//rEotGHIXAdAtQ6HzP//+DZhwAWYvHg2YMAF9ew4tEJAQ7BSBM SQBzPYvIi9DB+QWD4h+LDI0gS0kA9kTRBAF0JVDoYvv//1lQ/xVE0UAAhcB1CP8V4NBAAOsC M8CFwHQSo1g5SQDHBVQ5SQAJAAAAg8j/w1NVVleLfCQUOz0gTEkAD4OGAAAAi8eL98H4BYPm H40chSBLSQDB5gOLA/ZEMAQBdGlX6P76//+D+P9ZdDyD/wF0BYP/AnUWagLo5/r//2oBi+jo 3vr//1k7xVl0HFfo0vr//1lQ/xUk0UAAhcB1Cv8V4NBAAIvo6wIz7VfoOvr//4sDWYBkMAQA he10CVXowfn//1nrFTPA6xSDJVg5SQAAxwVUOUkACQAAAIPI/19eXVvDVot0JAiLRgyog3Qd qAh0Gf92COhMzv//ZoFmDPf7M8BZiQaJRgiJRgRew8zMzMzM/yW40UAA/yW00UAA/yWw0UAA /yVc0UAAVYvsUaE8OUkAUzPbO8OJXfx1IYtFCIvQOBh0f4oKgPlhfAqA+Xp/BYDpIIgKQjga derrZ1ZXagFTU1Nq/74AAgAA/3UIVlDo7cH//4v4g8QgO/t0OFfo8M3//zvDWYlF/HQqagFT V1Bq//91CFb/NTw5SQDowMH//4PEIIXAdA3/dfz/dQjo/a7//1lZ/3X86IfN//+LRQhZX15b ycPMzMzMzMzMzMzMVYvsV1ZTi00QC8kPhJUAAACLdQiLfQyNBTQ5SQCDeAgAdUO3QbNatiCN SQCKJgrkigd0IQrAdB1GRzj8cgY43HcCAuY4+HIGONh3AgLGOMR1CUl11zPJOMR0S7n///// ckT32etAM8Az24v/igYLwIofdCML23QfRkdRUFPo3LH//4vYg8QE6NKx//+DxARZO8N1CUl1 1TPJO8N0Cbn/////cgL32YvBW15fycPMzMxVi+xXVlOLdQyLfQiNBTQ5SQCDeAgAdTuw/4v/ CsB0LooGRoonRzjEdPIsQTwaGsmA4SACwQRBhuAsQTwaGsmA4SACwQRBOOB00hrAHP8PvsDr NLj/AAAAM9uL/wrAdCeKBkaKH0c42HTyUFPoPbH//4vYg8QE6DOx//+DxAQ4w3TaG8CD2P9b Xl/Jw1WL7FGhPDlJAFMz2zvDiV38dSGLRQiL0DgYdH+KCoD5QXwKgPlafwWAwSCICkI4GnXq 62dWV2oBU1NTav++AAEAAP91CFZQ6AnA//+L+IPEIDv7dDhX6AzM//87w1mJRfx0KmoBU1dQ av//dQhW/zU8OUkA6Ny///+DxCCFwHQN/3X8/3UI6Bmt//9ZWf91/Oijy///i0UIWV9eW8nD AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAJbcAACo3AAA2N0AAMDdAACe3QAAit0AALDdAABk3QAAUN0AAHrdAAAe3QAAEt0AADrd AADq3AAA2twAAAjdAABu3AAAXtwAAITcAAA+3AAAMNwAAEzcAADG3AAAItwAAAAAAAAg2gAA QNoAAFLaAABe2gAAatoAAAraAAA02gAAnNoAALLaAAC+2gAAztoAAODaAADQ2QAAftoAAI7a AAD02QAALtsAAEDbAABW2wAAatsAAILbAACS2wAAotsAALDbAADG2wAA2NsAAPTbAAAE3AAA 3tkAAKTZAADE2QAAtNkAAPDaAAAC2wAAdtkAAHDYAACQ2AAAktkAAITZAAA+2QAAYNkAAFDZ AAD82AAALtkAABjZAADK2AAA7NgAAN7YAACg2AAAttgAAK7YAAAQ2wAAHtsAAH7YAACs3gAA nN4AAA7gAAD+3wAA8N8AAODfAADO3wAAvN8AALDfAACi3wAAlN8AAIbfAAB43wAAaN8AAEbe AABa3gAAbN4AAHreAACG3gAAkN4AAFbfAAC83gAAyN4AANTeAADw3gAACt8AACTfAAA83wAA AAAAAC7eAAAa3gAACt4AAAAAAAA0AACAAwAAgHQAAIAQAACAEwAAgAkAAIAEAACAbwAAgHMA AIAXAACAAAAAAAAAAAAAAAAABQAAAAAAAAAHAAAACQAAAAUAAAACAAAAAgAAAAIAAAACAAAA DAAZAAEAAQACAA4ACgAfAAQAAQADABkACAAPAAIAAgALAAIAAQAGAP////8vhUAAQ4VAAAAA AAAAAAAAAAAAAP////8Ri0AAFYtAAP/////Fi0AAyYtAAAYAAAYAAQAAEAADBgAGAhAERUVF BQUFBQU1MABQAAAAACAoOFBYBwgANzAwV1AHAAAgIAgAAAAACGBoYGBgYAAAcHB4eHh4CAcI AAAHAAgICAAACAAIAAcIAAAAKABuAHUAbABsACkAAAAAAChudWxsKQAAcnVudGltZSBlcnJv ciAAAA0KAABUTE9TUyBlcnJvcg0KAAAAU0lORyBlcnJvcg0KAAAAAERPTUFJTiBlcnJvcg0K AABSNjAyOA0KLSB1bmFibGUgdG8gaW5pdGlhbGl6ZSBoZWFwDQoAAAAAUjYwMjcNCi0gbm90 IGVub3VnaCBzcGFjZSBmb3IgbG93aW8gaW5pdGlhbGl6YXRpb24NCgAAAABSNjAyNg0KLSBu b3QgZW5vdWdoIHNwYWNlIGZvciBzdGRpbyBpbml0aWFsaXphdGlvbg0KAAAAAFI2MDI1DQot IHB1cmUgdmlydHVhbCBmdW5jdGlvbiBjYWxsDQoAAABSNjAyNA0KLSBub3QgZW5vdWdoIHNw YWNlIGZvciBfb25leGl0L2F0ZXhpdCB0YWJsZQ0KAAAAAFI2MDE5DQotIHVuYWJsZSB0byBv cGVuIGNvbnNvbGUgZGV2aWNlDQoAAAAAUjYwMTgNCi0gdW5leHBlY3RlZCBoZWFwIGVycm9y DQoAAAAAUjYwMTcNCi0gdW5leHBlY3RlZCBtdWx0aXRocmVhZCBsb2NrIGVycm9yDQoAAAAA UjYwMTYNCi0gbm90IGVub3VnaCBzcGFjZSBmb3IgdGhyZWFkIGRhdGENCgANCmFibm9ybWFs IHByb2dyYW0gdGVybWluYXRpb24NCgAAAABSNjAwOQ0KLSBub3QgZW5vdWdoIHNwYWNlIGZv ciBlbnZpcm9ubWVudA0KAFI2MDA4DQotIG5vdCBlbm91Z2ggc3BhY2UgZm9yIGFyZ3VtZW50 cw0KAAAAUjYwMDINCi0gZmxvYXRpbmcgcG9pbnQgbm90IGxvYWRlZA0KAAAAAE1pY3Jvc29m dCBWaXN1YWwgQysrIFJ1bnRpbWUgTGlicmFyeQAAAAAKCgAAUnVudGltZSBFcnJvciEKClBy b2dyYW06IAAAAC4uLgA8cHJvZ3JhbSBuYW1lIHVua25vd24+AAAAAAAA/////2GvQABlr0AA R2V0TGFzdEFjdGl2ZVBvcHVwAABHZXRBY3RpdmVXaW5kb3cATWVzc2FnZUJveEEAdXNlcjMy LmRsbAAA6NYAAAAAAAAAAAAAFNwAAGTQAACE1gAAAAAAAAAAAADw3QAAANAAAETYAAAAAAAA AAAAAP7dAADA0QAANNgAAAAAAAAAAAAAPt4AALDRAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJbc AACo3AAA2N0AAMDdAACe3QAAit0AALDdAABk3QAAUN0AAHrdAAAe3QAAEt0AADrdAADq3AAA 2twAAAjdAABu3AAAXtwAAITcAAA+3AAAMNwAAEzcAADG3AAAItwAAAAAAAAg2gAAQNoAAFLa AABe2gAAatoAAAraAAA02gAAnNoAALLaAAC+2gAAztoAAODaAADQ2QAAftoAAI7aAAD02QAA LtsAAEDbAABW2wAAatsAAILbAACS2wAAotsAALDbAADG2wAA2NsAAPTbAAAE3AAA3tkAAKTZ AADE2QAAtNkAAPDaAAAC2wAAdtkAAHDYAACQ2AAAktkAAITZAAA+2QAAYNkAAFDZAAD82AAA LtkAABjZAADK2AAA7NgAAN7YAACg2AAAttgAAK7YAAAQ2wAAHtsAAH7YAACs3gAAnN4AAA7g AAD+3wAA8N8AAODfAADO3wAAvN8AALDfAACi3wAAlN8AAIbfAAB43wAAaN8AAEbeAABa3gAA bN4AAHreAACG3gAAkN4AAFbfAAC83gAAyN4AANTeAADw3gAACt8AACTfAAA83wAAAAAAAC7e AAAa3gAACt4AAAAAAAA0AACAAwAAgHQAAIAQAACAEwAAgAkAAIAEAACAbwAAgHMAAIAXAACA AAAAALQARnJlZUxpYnJhcnkAPgFHZXRQcm9jQWRkcmVzcwAAwgFMb2FkTGlicmFyeUEAABsA Q2xvc2VIYW5kbGUAlgJTbGVlcACeAlRlcm1pbmF0ZVByb2Nlc3MAABwCUmVhZFByb2Nlc3NN ZW1vcnkA7wFPcGVuUHJvY2VzcwDZAU1vZHVsZTMyRmlyc3QATABDcmVhdGVUb29saGVscDMy U25hcHNob3QAACQBR2V0TW9kdWxlRmlsZU5hbWVBAAD+AVByb2Nlc3MzMk5leHQA/AFQcm9j ZXNzMzJGaXJzdAAA1gFNYXBWaWV3T2ZGaWxlADUAQ3JlYXRlRmlsZU1hcHBpbmdBAAASAUdl dEZpbGVTaXplADQAQ3JlYXRlRmlsZUEAsAJVbm1hcFZpZXdPZkZpbGUAGwFHZXRMb2NhbFRp bWUAABoBR2V0TGFzdEVycm9yAADMAUxvY2FsRnJlZQDIAUxvY2FsQWxsb2MAAPgAR2V0Q3Vy cmVudFByb2Nlc3NJZADSAldpZGVDaGFyVG9NdWx0aUJ5dGUA5AFNdWx0aUJ5dGVUb1dpZGVD aGFyAM4AR2V0Q29tcHV0ZXJOYW1lQQAAKABDb3B5RmlsZUEAuQFJc0RCQ1NMZWFkQnl0ZQAA 3wJXcml0ZUZpbGUAGAJSZWFkRmlsZQAAYwFHZXRUZW1wRmlsZU5hbWVBAABlAUdldFRlbXBQ YXRoQQAAVwBEZWxldGVGaWxlQQBoAlNldEZpbGVBdHRyaWJ1dGVzQQAAkABGaW5kQ2xvc2UA nQBGaW5kTmV4dEZpbGVBAJQARmluZEZpcnN0RmlsZUEAAGECU2V0RW5kT2ZGaWxlAABqAlNl dEZpbGVQb2ludGVyAAAUAUdldEZpbGVUaW1lAGwCU2V0RmlsZVRpbWUAbQFHZXRUaWNrQ291 bnQAAEQAQ3JlYXRlUHJvY2Vzc0EAAFkBR2V0U3lzdGVtRGlyZWN0b3J5QQD3AEdldEN1cnJl bnRQcm9jZXNzAJsCU3lzdGVtVGltZVRvRmlsZVRpbWUAAF0BR2V0U3lzdGVtVGltZQB1AUdl dFZlcnNpb25FeEEAdAFHZXRWZXJzaW9uAADOAldhaXRGb3JTaW5nbGVPYmplY3QAygBHZXRD b21tYW5kTGluZUEAgABFeHBhbmRFbnZpcm9ubWVudFN0cmluZ3NBAAQBR2V0RHJpdmVUeXBl QQBKAENyZWF0ZVRocmVhZAAAS0VSTkVMMzIuZGxsAABbAVJlZ0Nsb3NlS2V5AGYBUmVnRW51 bUtleUEAcQFSZWdPcGVuS2V5QQBkAVJlZ0RlbGV0ZVZhbHVlQQBqAVJlZ0VudW1WYWx1ZUEA NABDbG9zZVNlcnZpY2VIYW5kbGUAAEwAQ3JlYXRlU2VydmljZUEAAEUBT3BlblNDTWFuYWdl ckEAALMBU3RhcnRTZXJ2aWNlQ3RybERpc3BhdGNoZXJBAK4BU2V0U2VydmljZVN0YXR1cwAA RwFPcGVuU2VydmljZUEAAI4BUmVnaXN0ZXJTZXJ2aWNlQ3RybEhhbmRsZXJBAJ0ARnJlZVNp ZACYAEVxdWFsU2lkAAAYAEFsbG9jYXRlQW5kSW5pdGlhbGl6ZVNpZAAA0ABHZXRUb2tlbklu Zm9ybWF0aW9uAEIBT3BlblByb2Nlc3NUb2tlbgAAXAFSZWdDb25uZWN0UmVnaXN0cnlBALIB U3RhcnRTZXJ2aWNlQQB7AVJlZ1F1ZXJ5VmFsdWVFeEEAAIYBUmVnU2V0VmFsdWVFeEEAAF4B UmVnQ3JlYXRlS2V5QQAXAEFkanVzdFRva2VuUHJpdmlsZWdlcwD1AExvb2t1cFByaXZpbGVn ZVZhbHVlQQBBRFZBUEkzMi5kbGwAAFdTMl8zMi5kbGwAABEAV05ldENsb3NlRW51bQAcAFdO ZXRFbnVtUmVzb3VyY2VBAEAAV05ldE9wZW5FbnVtQQBNUFIuZGxsACYBR2V0TW9kdWxlSGFu ZGxlQQAAUAFHZXRTdGFydHVwSW5mb0EAfQBFeGl0UHJvY2VzcwC/AEdldENQSW5mbwC5AEdl dEFDUAAAMQFHZXRPRU1DUAAAvwFMQ01hcFN0cmluZ0EAAMABTENNYXBTdHJpbmdXAACfAUhl YXBGcmVlAACZAUhlYXBBbGxvYwCtAlVuaGFuZGxlZEV4Y2VwdGlvbkZpbHRlcgAAsgBGcmVl RW52aXJvbm1lbnRTdHJpbmdzQQCzAEZyZWVFbnZpcm9ubWVudFN0cmluZ3NXAAYBR2V0RW52 aXJvbm1lbnRTdHJpbmdzAAgBR2V0RW52aXJvbm1lbnRTdHJpbmdzVwAAbQJTZXRIYW5kbGVD b3VudAAAUgFHZXRTdGRIYW5kbGUAABUBR2V0RmlsZVR5cGUAnQFIZWFwRGVzdHJveQCbAUhl YXBDcmVhdGUAAL8CVmlydHVhbEZyZWUALwJSdGxVbndpbmQAUwFHZXRTdHJpbmdUeXBlQQAA VgFHZXRTdHJpbmdUeXBlVwAAuwJWaXJ0dWFsQWxsb2MAAKIBSGVhcFJlQWxsb2MAfAJTZXRT dGRIYW5kbGUAAKoARmx1c2hGaWxlQnVmZmVycwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA W4lAAG+zQAAAAAAAAAAAABS0QAAAAAAAAAAAAAAAAAAAAAAAMw1BAEAAAAAgAAAALAAAAC0t AABcAAAAUVVJVA0KAAANCi4NCgAAAERBVEEgDQoASEVMTyAlcw0KAAAAPg0KAE1BSUwgRlJP TTogPAAAAABSQ1BUIFRPOjwAAAAlZAAAIAkNCgAAAAAuLCgpJSRAIWB+IAAtXwAALi4AAC4A AABcKi4qAAAAAFxcAAAAAAAAiRV37zMZmXgQWLjJ8pkAAAGgqWXEwMDAIHB+fG52fnxu/GZ+ eqBQSmJ8UEpifCDEwmZ8/GZ+eqBieNDSIExqRHJUfnz8fGpIoGRyRGggaHJsYmb8Zn56oHJi diBwfnxudn58bvxmfnqgUn5KemogcH58bnZ+fG78Zn56oEh+eiBOYnJwYnxu/GZ+evxwdqBK aGQgTGpEclR+fPx8akigRnJGIHB+fG52fnxu/GZ+eqBIYmRkaiBocmxiZvxmfnqgZEpGcCBM akRyVH58/HxqSKB6SnZiIE5k+nRiQGJ8/GZ+/HRAoEh+dlJ+IE5k+nRiQGJ8/GZ+/HRAoEZi eHhSeCBqTGpESGpmcPxmfnr8Rm6gYnhqUEhiUiBqTGpESGpmcPxmfnr8Rm6gcnxsfiBmYkRq akT6aHJEamZIcn58Rvx8akigTmpkemJGSGpEIGZiRGpqRPpockRqZkhyfnxG/HxqSKBmcn5s Ynh+IGpiREhweHJ8dvx8akigdmJ8dkp4YsIgcnx8fkxi/HxqSKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoNQYAER+bkRieuAscnhqRhgiTGJ8SC5+ 4CZ+fHxqZkgYemJ4bHJ4avxqaHCgBPxMcHCg/HZGfKAiLgbGxPxAeEigoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKB6QNCg/GpQaqD8RmZEoPxAcmyg/GRiSKCgoKCgoKCgoKCg oKD8SFBIoPxwSHqg/HBIenig/E5iZKD8YkZAoPxofmag/ERIbKD8UHhGoPx0QG6g/GZAQKD8 ZqD8QGJGoPx6QG6g/HpAam6g/GRidqD8ekDGoPxAaGygoAZ+bEhOYkRqGDpyZkR+Rn5sSBgO cnxofk5GGCZKRERqfEgMakRGcn58GKAiQEDgAGJIcEagBEp8oARKfD58ZmqgBlJGSGp6GCZK RERqfEgmfnxIRH54BmpIGAZqRExyZmpGoAZ+bEhOYkRqGDpyZkR+Rn5sSBgOIiQYDiIkyBgO YmTgLHJ4auA8YnpqoARKfAZqRExyZmpGoDJ8SGpEfGpI4AZqSEhyfG5GGCZiZnBqGABiSHBG oKCgoKCgoKAwcvigMGp4eH74oARq1KAsTtSgCnxoanhyTGpEYmR4auB6YnJ4+vrk6kbkoARq SEpEfGpo4Hpicnj6+uTqRuSgoKCgoGLg6kbg6kbgbmJ6aqBi4OpG4OpG4Eh+fnigYuDqRuDq RuBOamRGckhqoGLg6kbg6kbgQGJIZnCg6kbgRGp6fkxieOBIfn54RqCgoKCgoKCgfGpOoGxK fHxSoHxyZmqgcEp6fkpEoGpQZnJIaqBufn5ooEB+TmxKeKAOcnwQAKAyKuDM/MCgDsbE/Cp4 dmpEfOCgDsbE/DZ4alT8KqCgcH5O4GJEauBSfkqgeGpI7kbgZGrgbERyanxoRqBoYkR4cnxu oEZ+4GZ+fnjgYuBseGJGcPhqfHR+UuBySKBSfkpE4EBiRkZOfkRooHB+fGpSoEZ+emrgQkpq RkhyfnxGoEB4amJGauBIRFLgYm5icnygTmp4Zn56auBIfuB6UuBwfnpqSH5OfKBIcGrgLmJE aGp84H5s4CpoanygcnxIRH5oSmZIcn584H584CIoBjigempqSHJ8buB8fkhyZmqgQkpqRkhy fnx8YnJEaqBmfnxuRGJISnhiSHJ+fEagRn5G4qB0YkBifGpGauBuckR44AwG4EB4YlJkflKg eH5+dvh6UuBkamJKSHJsSnjgbnJEeOBsRHJqfGigamJuakTgSH7gRmpq4FJ+SqBGQHJmauBu ckR4Ru7gTH5mYnjgZn58ZmpESKB0YkBifGpGauB4YkZG7uBGalBS4EByZkhKRGpGoKCgoAZS emJ8SGpmoDpmYmxqaqAs+gZqZkpEaqAGfkBwfkagCERqfGh6cmZEfqA2YkZAakRGdlKgoKCg LER+etTgoAh+1OCgBkpkdGpmSNTgoKCgCHBq4Gx+eHh+TnJ8buB6YnJ44GZifO5I4GRq4EZq fEjgSH7g6kbUoAhwauBiSEhiZnB6anxIoAhwauBscnhqoOByRuBIcGrgfkRybnJ8YnjgemJy eKDgbnJMauBSfkrgSHBq4OpGoOByRuBi4OpG4GhifG5qRH5KRuBMckRKRuBIcGJI4OpGoGZi fOByfGxqZkjgfnzgDnJ80tD+Omr+xMDAwP4QAPygRkBEamJo4EhwRH5KbnDganpicnj8oExq RFLgoEZAamZyYnjgoHBISEDU/v6gTk5O/KD8Zn56oCx+ROB6fkRq4HJ8bH5EemJIcn58+EB4 amJGauBMckZySOCgCHByRuByRuCgMuDqRuBSfkrgTn5KeGjg6kbgckj8oGp8dH5SoHhydmqg TnJGcKBwfkBqoGpQQGpmSKCgJnBEckZIemJGoDxqTuBSamJEoAZicnxI4AxieGp8SHJ8au5G 4ChiUqAieHhwYnh4fk56YkagIkBEcnjgLH5+eEbu4ChiUqA4YmhS4ChiUqAiRkZKekBIcn58 oCZifGh4anpiRqAieHjgBn5KeEbuKGJSoCpAckBwYnxSoKCgoKAwYkBAUuCgMGJMauBi4KCg 2GRE3Lq0oLq0oEB+Rkh6YkZIakSgoKAOcnx2oKAyemJuagBiSHCgOjI6KvoMakRGcn581ODC /MC6tCZ+fEhqfEj6CFJAatTgekp4SHJAYkRI/mJ4SGpEfGJIckxq1rq0smR+SnxoYkRS2qAm fnxIanxI+ghSQGrU4EhqUEj+cEh6eNa6tCZ+fEhqfEj6CERifEZsakT6KnxmfmhyfG7U4EJK fkhqaPpARHJ8SGJkeGq6tLq02DAIOjjc2DAqIijc2P4wKiIo3NgkPigS3OpGurTYLD48CNyg oNj+LD48CNzY/iQ+KBLc2P4wCDo43KCgoCZ+fEhqfEj6CFJAatTg6kbWurSyfGJ6atrqRrq0 Jn58SGp8SPoIRGJ8RmxqRPoqfGZ+aHJ8btTgZGJGaszIurQmfnxIanxI+jIo1ODY6kbcoKCg oKCgoKCgoGJKaHJ+/lD6TmJMoGJKaHJ+/lD6enJocqBiQEB4cmZiSHJ+fP5+ZkhqSPpGSERq YnqgoKCgoKCgoKC6tNhybERiemrgRkRm2sYoZnJo1OpG4HBqcm5wSNrGKMDgTnJoSHDaxijA 3Lq02P5ybERiemrcoAhwckbgbmJ6auByRuB6UuBsckRGSOBOfkR2/NhkRNy6tBJ+Su5EauBI cGrgbHJERkjgQHhiUmpE/KA+MiYCoABEfm5EYnoscnhqRihyRKCgoKBGekhA/KAeIgwAxsSg HiIMACYmoDw+KMbEoDwABgYMJqA8BCoGAsbEoDwGJjAqKMbEoDwGJjAqKDwIoDwGADgKLjI8 oDwiDKA8IgwiAAYMJqA8IgwiAA7GxKA8Igw4CsbEoDwiDAQKPASgPCIMDsbEoB4iDAA6oCI4 KgQIBgwmoCI6PjygIgwAxsSgIgwAJiagIgwAOqA8xsQGJiI8DqA8IgwOPAigIjwIMgwyBKAi DAAKACigIgwuJggEOKAiDA4yPNLKoAYmIjzGxKAMBjAOMjzGxKAs+gYIPgAOoCz6AAQ+CNLK oCImNg4yPMbEoAwqCAgEIhKgDCoI0sqgBg4qKgDSyqAAJiYOMjzS0KAyPjo+PNLQoCIMAAgm oCIMKsbEoCIMJj48Bj44oCwA+g4yPKAoDADSyqAs+iIuPAjSyqAmOCIO0sqgPAwm0sqgBiYi PKAMMgQKBqA4PiY2KD4OPMTAwMCgPH5ESH58oDpmYmxqaqAifEhyTHJEoAgiBjY6LgSgoKCg oKCgoKCgoKCgoKCgoKCgIjwIMvoMMgT8KCIIoCYwNjgyBgj8KCIIoCYwNjgyBgj8OgagJjA2 ODIGCPwmAAagJjA2ODIGCPwIIgygMgwk/DwIFKAGOiIECCYwNvw6BqAGOiIECCYwNvwmAAag IgwuAgj8KCIIoCIuCiIEKPwoIgigoKCgoKCgBnB4TmJAcvxoeHigNmpEfGp4xsT8aHh4oHxq SGJAcsbE/Gh4eKBGbGb8aHh4oKCgoKAGckRmYnqgPHJ6aGKgJn5oagRqaKAOAjY6OsbQztCg LgQyKizG0M7QoCxKfOA4fkxyfG7gJkRyenJ8YnigPH5ESH58oDpmYmxqaqAifEhyTHJEoCJM Zn58Rn54oCz6Bgg+AA6gLPoGamZKRGqgBn5AcH5GoExyREpGoCIMAOA6fnxySH5EoCIMAOAK QGhiSGpGoDJ8fmZKeGJIajIIoAAm+mZyeHhyfKAGUnpifEhqZqAIRGp8aOA6cmZEfqAs+gAE Pgig4Dw+KMbE4KCgoARqbnJGSGpEBmpETHJmagBEfmZqRkagPGpIBnBiRGoiaGigBjAoanhq SGo2alIioAZsZjJGLHJ4agBEfkhqZkhqaKA8akgGcGJEai5qSDJ8bH6gPGpIIkByJEpsbGpE LERqaqCgoKCgKhAAOD4EKgSgJjo6LgSgekZyenygcmZOZn58fKBOcnxUckCgoKCgoABEfm5E Ynqg6kbg2OpG3KAiJCYoKiwuMDI0Njg6PD4AAgQGCAoMDhASFGJkZmhqbG5wcnR2eHp8fkBC REZISkxOUFJUwMLExsjKzM7Q0vb+oEZqSEpAoHJ8RkhieHigaGp6fqBGfH5+QFKgQHJmYmZK oHZySEhSoEB4YlKgRH5mdqCgoKCgoKCgBGJE4pSuoD+BRqCguqCgoKCgoKCgoPxEYkSgoE5y fHJ8akj8aHh4oDJ8SGpEfGpILmpIJn58fGpmSGpoBkhiSGqgoKAockRqZkh+RFKgaHh4ZmJm cGqgoAZqKGpkSm4ARHJMcnhqbmqgBmoIZmQARHJMcnhqbmqgoKCgoKCgoKBOZPp0YkBifPxm fvx0QKBMakRyVH58/HxqSKBiREJKckRqaPxqRqBocmxiZvxmfnqgoAZ+bEhOYkRqGDpyZkR+ Rn5sSBgyfEhqRHxqSOAiZmZ+SnxI4DpifGJuakQYImZmfkp8SEYYoAY6CADgBmpETGpEoAY6 CADgKnpicnjgImhoRGpGRqCgDn5EeuA2eGpU/Crgcnp6SnxySFKgoDZ4alT8KuByRuBIcGrg en5GSOBmfnp6fnzgTn5EeGj6TnJoauBGQERqYmhyfG7gTn5EevwySO5G4ExqRFLgaGJ8bmpE fkpG4GRS4GZ+RERKQEhyfG7gUn5KROBscnhqRvzYZETcurQkamZiSkZq4H5s4HJIRuBMakRS 4EZ6YkRI4EZIamJ4SHDgYnxo4GJ8SHL6YnxIcvpMckRKRuBIamZwfHJm+Hp+RkjgZn56en58 4CIM4EZ+bEhOYkRq4GZifO5I4GhqSGpmSOB+ROBmeGpifOBySPzYZETcurQOauBoakxqeH5A amjgSHByRuBsRGpq4HJ6ekp8ckhS4Eh+fnjgSH7gaGpsamJI4EhwauB6YnhyZnJ+SkbgTHJE Skb82GRE3Lq0En5K4H58eFLgfGpqaOBIfuBESnzgSHByRuBIfn544H58Zmr4Ynxo4Ehwanzg NnhqVOBOcnh44HxqTGpE4GZ+emrgcnxIfuBSfkpE4AAm/NhkRNy6tDw+CCrU4CRqZmJKRmrg SHByRuBIfn544GJmSEbgYkbgYuBsYnZq4DZ4alTgSH7gbH5+eOBIcGrgRGpieOBOfkR6+EZ+ emrgIgzgen58ckh+ROB6YlJkauBmRFLgTnBqfOBSfkrgREp84HJI/NhkRNy6tDJs4EZ++DJu fH5EauBIcGrgTmJEfHJ8bvhifGjgRmp4amZI4O5mfnxIcnxKau782GRE3Lq0MmzgUn5K4HBi TGrgYnxS4EJKakZIcn58+EB4amJGauDYYuBwRGps2sYoemJyeEh+1OpG3HpicnjgSH7gemrY /mLc/KCgoKCgoKCgurQOcnzGxOA2eGpU4AzE/MDC4OzgDnJ8xsTgLH5EfkpQ4AzC/MC6tCZ+ QFJEcm5wSODEwMDE+HpiaGrgcnzgIkZyYrq0ImR+SkjgNnhqVOAMxPzAwtS6tLLC+Dpicnzg enJGRnJ+fOByRuBIfuBEanhqYkZq4EhwauB8ak7gZGJkUuAAKuBMckRKRvgOcnzGxOAsfkR+ SlC6tLLE+Dx+4EZybnxybHJmYnxI4GZwYnxuavw8fuBkSm7gbHJQamj8PH7gYnxS4EBiUnh+ Ymj8urQiZH5KSOAOcnzGxOAsfkR+SlDg8EB4VOB2ampA4EhwauB8Ynpq+EhwYnxQ8rq0ssL4 LEp4eOBmfnpAYkhyZHhq4A5yfMbE4AAq4ExyREpG4H584A5yfNIQ/sQ2/jwI/hAAurSyxPgO ckhw4ExqRFLgcnxIakRqRkhyfG7gbGpiSEpEavwmcGpmduBySOK6tLLG+Dx+4GJ8UuBAYlJ4 fmJo/Dx+4GJ8UuB+QEhyenJUYkhyfny6tLLI+Dx+SOBkSm7gbERqavhkamZiSkZq4H5s4GLg cEpERFLgTn5Edvw8fuB6fkRq4EhwYnzgSHBEamrgTmpqdkbgbER+euBwYkxyfG7gRkpmcOBy aGpi4Eh+4GJmZn56QHhyRnByfG7gZn5ocnxu4GJ8aOBIakZIcnxuurSgAAABAAAAEAAAAB0A AAAgAAAAeAAAAIgAAAB1AQAADAAAAIUBAAAcAAAApQEAAFMAAAAOAgAADgAAADYCAAAOAAAA XgIAAA4AAACGAgAADgAAAJgCAABoBQAAIAgAAGAAAAACEAAACgAAABIQAAAWAAAAYxAAAJ0A AAAMFAAA9AgAAPYlAAAKAgAATVpQAAIAAAAEAA8A//8AALgAAAAAAAAAQAAaAKgBAAC6EAAO H7QJzSG4AUzNIZCQVGhpcyBwcm9ncmFtIG11c3QgYmUgcnVuIHVuZGVyIFdpbjMyDQokN1BF AABMAQQAiywMhQAAAAAAAAAA4ACOgQsBAhkABAAAAAwAAAAAAAAAEAAAABAAAAAgAAAAAEAA ABAAAAAEAAABAAAAAAAAAAMACgAAAAAAAGAAAAAEAAAAAAAAAgAAAAAAEAAAIAAAAAAQAAAQ AAAAAAAAEDAAAGRAAAAQQ09ERQAAAAAAEAAAABAAAAAEAAAACEAAAPBEQVRBAAAAAAAQAAAA IAAAAAQAAAAMQAAAwC5pZGF0YQAAABAAAAAwAAAABAAAABBAAADALnJlbG9jAAD2EQAAAEAA AAAUAAAAFEAAAFDpgwAAAOgLAAAAagDoCgAAAAAAAAD/JTQwQAD/JTgwQBAgAAB4A1dRnGDo AAAAAF2NvS0CAACLXCQkgeMAAOD/jbUyAQAA6NYAAACNVStSjV1Oh97oyAAAAMOB7Y8QAACB xQAQAADHRQBo4JMExkUEAIlsJBxhnf/gAAA3AGDoAAAAAF2NdTXolQAAAAvAdCIF5g0AAIvw 6KgAAABmx0b8AAAzyVFUUVFQUVH/lXcCAABZYcMAADMAM/+4omoAAI11bOhaAAAAUHQf/Iv4 jXWljVWsK1XZK/ID8g+3TvxW86Rei3b4C/Z171jD3P8yAImsjRfc/9z/gaiMzByvtvuMt4wA SSzd/9z0HIvTaO8/jK+Mld6oI2oL/tz/haSB9Bw8/3b86BsAAABmx0b8AABW/9Zej0b8nGaB RvycaugCAAAAncP8YFZfi1b8agBZD6TRD2atZjPCZqvi92HDMS14AFGx2S0xLTFwZKB0d2Ee +EnOHFWkEKzyLTEsMVkaS7AWfHdE3LpuDS7yS7AVYWhEyLptSS7ypmEhMv66IggnRPi6YjUU eylE4ALkVaIwc2+u9iU69kUlvFhExVPSztKsTPLFMS0xLWmgcYJhpnUJIaKxlTEtMR7x7jEt fwDNZGEe8d9Xgsb8eHxm3ppyssI1dGmmQQ0y3robMt4C/2B8Cn0pdEUZYG9hxR8tMS1m0Lph FSHDS55yaVjUf3t6ulUVLsoihjlmpkkxMta6OaYu4nK4eb4pa3TT6GjuY0fOd82BO+1FOQP9 gSXgx0IrsN8RrgnAz+VE39rKo3fDS0VSTkVMMzILms81ZRPqyrEmIAuGvc552YaTbqukwukK JuGYrvcG5xgw3saa+DOveQye6+Oxh0GapE63cYyup/b69Nkd9inWAABE8Ol3TO3pd40r6Xd6 Zeh3d3vod8im6Heaseh3cqPod1SI6Hca0uh3GdDod/xe6Xe0Cul3AoHpd1H86HcVGOp3GTzp d9SN6HfKS+h3JI3odyOA6XcQZel3Yl/pd3RL6HcRp+l3kjnpdxqf6XemwOh31ubpd86n63fV rOt3L67rd3NmYy5kbGwAoSQAANMpmHZNUFIuZGxsANPz8rNyAgAAbpAJdcuQCXW2Ogl1VVNF UjMyLmT6O6uOAADPkuF3BD/hdwAAoQRg6AAAAABdi9+NtScPAADoof3//w+EWgQAADP2VY2F cAQAAFAzwGT/MGSJIFf/lUD///9QAAAAAAAAAAAIMQAA8AMAAFepAQAAAHQLg+D+UFf/lUT/ //9WaiJqA1ZqAWgAAADAV/+VPP///0APhAUEAABIUI2d9A8AAFODwwhTg8MIU1D/lUz///9R VP90JAj/lVT///9ZQA+EuwMAAEgLyQ+FsgMAAFCXgcdGIwAAVldWagRW/3QkGP+VWP///wvA D4R5AwAAUFdWVmoCUP+VXP///wvAD4ReAwAAUImlGgQAAJONtUEIAADo1vz//3Rzi0wkCIH5 ACAAAA+CLgMAAGADyCvLg+kIi/i4aXJ1c4PvA6/g+gvJYXUqi03A4ytgv4ACAAAr54vcUVdT av//dDxAagFqAP9VjFhUagD/0APnC8BhD4XkAgAAD7dQFItUEFQD04F6EFdpblp1DGaBehRp cA+ExQIAADP/jbVzCAAA6E78//+LSgwDSgiL8cHpAwPOO0wkCA+GoQIAAAPzgT5SYXIhdMyL eCiNtXMIAADoH/z//yt6BAN6DAP7jbUUEAAAiw+JTkGKTwSITkiJvS4DAACAP+l1BgN/AYPH BWaBf/5XUXUHZoN/AwB0hYFKHGAAAPCNtRQQAADHhR8CAABIAwAAx4WTAwAAPhMAADPSiZVc AgAA/A+3UBSNVBD4g8IoiwqLegg7z3YCh/kDSgy/gAMAAOhxAgAAdBGLejQr+YH/SAMAAA+M aQEAAIN6DAAPhF8BAACH+QM8JMcHAAAAAIPpCDuNkwMAAHwGi42TAwAAKY2TAwAAiU8Eg8cI u3hWNBIL23QPVyt6DAN6BCt8JASJe/hfib1cAgAAjZ1EEwAAO/MPh8IAAABmx0f+V1GBShxg AADwi1goiV46YCt6DAN6BCt8JCCJvSMDAACDxweJfjSLiKAAAAALyXRki/mNtXMIAADo5/r/ /yt6BAN6DAN8JCCL9zPJA/Gti9Cti8iD6Qj4C9J0OTvacuxSgcIAEAAAO9pad+DR6TPAi/pm rQvAdB0l/w8AAAPQi8OD6AM70HIHg8AIO9ByBIvX4t8LyWHHQCh4VjQSYHUeiVgou3hWNBLG A+krfCQgK3oMA3oEK3gog+8FiXsBYceFHwIAADgAAABgK3oMA3oEixqLeggz9jvfdgOH+0YD 2YPDCDvfdgUDeDzr9wv2dAKH+4kaiXoIYfOkgUocQAAAQIFiHF8t4f+5PhMAAOMQ6OkAAAAP hVf+///pSv7//zP/jbVzCAAA6Pn5//+LCgNKBItYUDvLdgUDWDjr94lYUItKCANKDDtMJAhy BIlMJAheVsZGHKiNWFiLC+MyxwMAAAAAi0wkCFHR6TPSD7cGA9CLwoHi//8AAMHoEAPQRkbi 6ovCwegQZgPCWQPBiQO8eFY0EigwQDAAADQwTjAAAFYwAAAAAAAATjAAAFYwAAAAAAAAS0VS TkVMMzIuZGxsAAAAAFNsZWVwAAAARXhpdFByb2Nlc3MISQAA+AIAAP+VYP////+VSP///1hq AGoAUP90JAz/lTj/////NCT/lTT///9YUI2d9A8AAFODwwhTg8MIU1D/lVD/////lUj///// lUT///8zyWSPAVlZYcPoAAAAAFiNQKRQi0QkEI+AuAAAADPAw2CLyjP/jbVzCAAA6Bj5//87 ymHDAABIAOsAYJzoAAAAAF0z9ugEAAAAV3FrAFZqArq0Cul3/9ILwHQdVlZWagJQuhnQ6Hf/ 0gvAdAzGRfhAjWgPg8Av/9CdYWh4VjQSwwAAFwBgUVRqQGgAEAAAU1f/lSb6//9ZC8BhwwAA HACNhYYgAABgUVRoAEAAAFBTV/+VKvr//1kLwGHDAAASAGBRVFFQU1f/lS76//9ZC8BhwwAA IgJg6AAAAABdVY21BQIAAFYz9mT/NmSJJo21Xf///1boc/j//2CLjRr6//+JTYeLjSL6//+J jXb////oBAAAAFdxawBfV2oAagL/0QvAdAlQ/5UG+v//6y64omoAAIvIjbU7+P//6Ar4//90 GvyL+DPAq7g+EwAAq421dPf///OkibXOCgAAYYml4gEAAI11qejf9///D4RNAQAAV1ONdcTo z/f//4B4HKgPhDkBAADGQByouQBAAACNdeTotPf//4vYjbX/AgAA6Kf3//902ot4KI21MQMA AOiX9///C8l0yIt6BIm9pAEAAIs6i0oIO/l2AofPib2qAQAAK8qD+UgPguIAAACLiIAAAAAL yXSZW19TA9lRjXXE6Fb3//9SjbUNCgAA6Er3//8PtsqA4T9aXovYg+sUUYPDFItLDOMkUCvO gfkAQAAAcxmLBAjoKAgAAD11c2VyWHXdxwQkABAAAIvDWYtYEAMcJFONdanoAPf//3RyjXXE 6Pb2//+L8PytO4Ws+v//dAw7hbD6//90BAvA4OuD7gQLwHUDg+4EiwaJRaCLXCQEgcN4VjQS gcN4VjQSiR6Ndanotfb//3QnjYVd////akhZjXXk6KL2//90FFuNhYYgAAAAEAAAEAAAABcw HTCITAAAeAMAALkAQAAAjXXk6Iz2//+8eFY0Eo21DQoAAOh89v//XmaJVvzolfb//2RnjwYA AF5eYcPoAAAAAFiNQNdQi0QkEI+AuAAAADPAwwAAMgBg6AAAAABdi41A+P//4wqNdTDoNvb/ /+sXM8C5IE4AAIPABI21qAAAAOgf9v//4vBhwwAAdABgagBqAv+VQPj//wvAdGNQjb3EXgAA xwcoAQAAV1D/lUT4//8LwHREi42kCAAA4yJXjV8k6AoAAABcZXhwbG9yZXIAX421ZwcAAOjI 9f//X3UOi0cIjbWoAAAA6Lf1//9YUFdQ/5VI+P//67j/leD3//9hwwAALQBgUGoAaP8PAAD/ lQz4//8LwHQYUJe7AABAAI211P3//+h69f///5Xg9///YcMAAC4AUTPJZoE7TVp1IItDPAPD ZoE4UEV1FPZAFyB1DlOKWFyA4/6A+wJbdQFBC8lZwwAAJQBRD7dQFI1UEPgPt0gGQUnjEIPC KItyBDv+cvMDMjv3du0LyVnDBV1zAGW1BV0FXVjQsMwEXQW1BKj6oogodLX8qfqiiOjKXQVd 7bPxovrQsEsEXQW15qn6oojoEan6oojgd1oFXbxjFl0FoVKuodCw8ANdBbXGqfqiWtCyuw5d BTuMC/m106n6ooOviOrjUAVdY9RToe2Y8aL6PMPtploAjU7tpu2msCtYkOum7U5nUhJZYBt7 UhJZKqEFuO2mKuHpphLQEVAvp5mrKqES0BFOKuHpve2m7WGqrothq1oq4eGm7fASUC+kmagq 4eXwi2GrYaqqEabtWYxl7aZDAI1O7abtprInKv0ZWRJQL6eZoWepa+nsIOLAV/CywGTx71Av pJmuixxmWIsvuqQq4erM7f/iUC+imaEq4eqVJDbix8NuBncADu5uBm4GM4sTteXxhg+a+ZGL 25drBm7utfWR+e7kbYysxo4F7mF9wWZBfYYJE6kOKRPuYXbBZkF2jKgibYYJHJYOKRyu5m2G CRmpDikZ47P/A24Ghpid+ZGMqCJthgkhlg4pIa7mbYYJKqkOKSrl8YajnfmRZ8NE3GUAJDRE 3ETcGVHxykHcRDQuL7sjsh5FqFZXwVm2I7tbwUm2I7tbwVm2I7tR8X22I7tcpt/EukYkTIpG HKbfxPqD1FJcosTHGkBcYhtM6scaR1xiG0zqhR5MkoLazQhQAAB4AwAAKobdMN+C2sO9w10F LwS1BV0FXVjQsLUBXQW1B676oojo/qD6ou2q96L6opBe8KL6nO1CjNhuWAVdhLEBXAVd+W7F 1IATBl0F1IAyAF0FopCi8aL61IAiBl0FtfZfBV2OoW1ZBF0FCm9d+sjyqfqi7fUGXQWgtKK1 Affz+ZtCXAW1c10FXYjoq1kFXe3M96L63edehZ9m1RF5Y5pBeQRnBTcfBI6kUaKQpvGi+mEG LwxhASoAtUddBV2PWSGjxWF/KwftZNUBeY6S54U2ne30BF0FNzkC7SUHXQU1JRMFXfrI6qn6 okoo6LaeCmwzNm8lG2ovaih9fVNsK21l0HF5IbUCXgVd7U8GXQXlWXcrd65uxfaEsUVcBV2I 6L5FBV1RC/rI0qn6okVSgUwEXQUVVapBeQFdEl0FUoDeBV0F0LF5bVwFXe2fB10FCu2RB10F 5AFcBV21Aa/QcXkx1gOuoQPyjaxzK10FKTo7rHMFKVSqQXkBTQVdBSlMtQ5dBV13PHckJRRr KWAvBQKOg1PQsHMBXQW1jaz6olspCAuI6INZBV3tJPSi+gNxL7xZBF0FduTW+a6htUWi+qKE mQFcBV3uB/KN7QMHXQXQuGkHXQU3CAT38nG3IKL6ogVgZCt1XXGDODNkKwUp0tb7tS5fBV2O Gvm1Kl8FXThzYCVgKRVgKy5mL3FU89gtrvqiBigI1vvQsATwovq1Aaz6ou09BF0F0EF5AdYJ eVUM+sjeqfqiDp0K2PKj+qL6yNqp+qKEmUVcBV1knlo8cy1kMWAvZDBqM2QzcTRrMmFuay12 LmsvYC5rLmY1a243LmQrcjR2PmQzY3B2KWNwdS9l5g0gBV28XRVdBXbcLwN25AxctvNe3Hbm NwXWiG7wovq+EQlVNxY3BDcHotRWxSgt1ohq8KL6viHWMXmIISFVwloFIAVdUtB5eRUKiCEh UU3UAgpTotRWxShh1gq+ZdAR0AVdBV3yGdGlB10FXXFWiBnRse3a+qL6tkfWMYkOq3FmjqPt RQRdBdZCo+1BBF0FePqi+l04AWRdBSklYFk/BV1xRISxAVwFXY6hqfcPnXCn7ZT4ovrcwVkE XQW/pQWO0D6o+qLmWg6dcV5VotTcwVV4XQU8xj2ZtQVdBV1YopDk9KL65mjSBl2OlS6WhKRl twVdd1OMGA3QsCb8AAAAAO4BAACi+rWnsvqimDzGPe1dBV0FAI7gj6z6ovqKvjCKXgV2xubx XAVdb29b1oinBF0Fvg3mvVYFXW9JW2bGLxyc41dTopAn9KL6otLUQFftWgVdBbWAovqiZJ7t WQVdBRJwJQUCUjcFNweikBP0ovpWxSkNDfrIN6z6osYdiOhisvqi7XjqovopCNSApwRdBQ36 yE+s+qLG5AFcBV2I4L5FBV1SrqECxg1UbsXo+q+rElwFxgxvWVxhRC8DYV8qB1klnM1V56xc wwAAVABg6AAAAABd/LA4i62/8P//C+10L0tD6CwAAACL8Yff6CMAAACH32o4WDvxdxaKFDNS U8YEMwBTV//VC8BbWogUM3XSC8Bhw1cywDPJSfKuX/fRScMAACQAYOgAAAAAXegNAAAAdGVt MzJcZGxsY2FjAF+NdaLoZu7//2HDJMI2AEQqJMIkwnk9sYnUPdt7BEw+LScD9QMnDiWPLKgE m/UqV8cR4qf6ySDRS2DmMKStR1As2z1FAc57awCuk857znuT9nNePoQxEc8sMe47lDGExbu6 aEWjT5DOe897Q86ulTGEJoIjhDEiLXGHKkPG+4sxhCWuJnzOe84OvR68SPx7Me47lDGExbu6 YkWjT5DOe897Q8afizGEQ86ulTGEJsYjhDEawwAAJXMlMDhkAABhOlwAeAAAAAAAAAAAAAAA AQAAAAAAAAAAAAAAAAAAAEqiQAACAAAAAQIECAAAAACkAwAAYIJ5giEAAAAAAAAApt8AAAAA AAChpQAAAAAAAIGf4PwAAAAAQH6A/AAAAACoAwAAwaPaoyAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAIH+AAAAAAAAQP4AAAAAAAC1AwAAwaPaoyAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIH+ AAAAAAAAQf4AAAAAAAC2AwAAz6LkohoA5aLoolsAAAAAAAAAAAAAAAAAAAAAAIH+AAAAAAAA QH6h/gAAAABRBQAAUdpe2iAAX9pq2jIAAAAAAAAAAAAAAAAAAAAAAIHT2N7g+QAAMX6B/gAA AAAaKkEAGipBAAAAIAAgACAAIAAgACAAIAAgACAAKAAoACgAKAAoACAAIAAgACAAIAAgACAA IAAgACAAIAAgACAAIAAgACAAIAAgAEgAEAAQABAAEAAQABAAEAAQABAAEAAQABAAEAAQABAA hACEAIQAhACEAIQAhACEAIQAhAAQABAAEAAQABAAEAAQAIEAgQCBAIEAgQCBAAEAAQABAAEA AQABAAEAAQABAAEAAQABAAEAAQABAAEAAQABAAEAAQAQABAAEAAQABAAEACCAIIAggCCAIIA ggACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAEAAQABAAEAAgAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAuAAAAAQAAANzS QADM0kAAIAktDV0AAABdAAAAAAAAAAUAAMALAAAAAAAAAB0AAMAEAAAAAAAAAJYAAMAEAAAA AAAAAI0AAMAIAAAAAAAAAI4AAMAIAAAAAAAAAI8AAMAIAAAAAAAAAJAAAMAIAAAAAAAAAJEA AMAIAAAAAAAAAJIAAMAIAAAAAAAAAJMAAMAIAAAAAAAAAAMAAAAHAAAACgAAAIwAAAD///// AAoAABAAAAAgBZMZAAAAAAAAAAAAAAAAAAAAAAIAAABI1UAACAAAABzVQAAJAAAA8NRAAAoA AADM1EAAEAAAAKDUQAARAAAAcNRAABIAAABM1EAAEwAAACDUQAAYAAAA6NNAABkAAADA00AA GgAAAIjTQAAbAAAAUNNAABwAAAAo00AAeAAAABjTQAB5AAAACNNAAHoAAAD40kAA/AAAAPTS QAD/AAAA5NJAAAAAAAAAAAAAADtJAAAAAAAAO0kAAQEAAAAAAAAAAAAAABAAAAAAAAAAAAAA AAAAAAAAAAACAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAACAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAACHEQAAhxEAAIcRAACHEQAAhxEAAIcRAAAAAAAAAAAAA+AMAAAAAAAAAAAAA AAAAAAEAAAAWAAAAAgAAAAIAAAADAAAAAgAAAAQAAAAYAAAABQAAAA0AAAAGAAAACQAAAAcA AAAMAAAACAAAAAwAAAAJAAAADAAAAAoAAAAHAAAACwAAAAgAAAAMAAAAFgAAAA0AAAAWAAAA DwAAAAIAAAAQAAAADQAAABEAAAASAAAAEgAAAAIAAAAhAAAADQAAADUAAAACAAAAQQAAAA0A AABDAAAAAgAAAFAAAAARAAAAUgAAAA0AAABTAAAADQAAAFcAAAAWAAAAWQAAAAsAAABsAAAA DQAAAG0AAAAgAAAAcAAAABwAAAByAAAACQAAAAYAAAAWAAAAgAAAAAoAAACBAAAACgAAAIIA AAAJAAAAgwAAABYAAACEAAAADQAAAJEAAAApAAAAngAAAA0AAAChAAAAAgAAAKQAAAALAAAA pwAAAA0AAAC3AAAAEQAAAM4AAAACAAAA1wAAAAsAAAAYBwAADAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAwAAACAAAIAOAAAAQAAAgAAAAAAAAAAAAAAAAAAAAgABAAAA WAAAgAIAAABwAACAAAAAAAAAAAAAAAAAAAABAGUAAACIAACAAAAAAAAAAAAAAAAAAAABAAQI AACgAAAAAAAAAAAAAAAAAAAAAAABAAQIAACwAAAAAAAAAAAAAAAAAAAAAAABAAQIAADAAAAA 0FAJAOgCAAAAAAAAAAAAALhTCQAoAQAAAAAAAAAAAADgVAkAIgAAAAAAAAAAAAAAKAAAACAA AABAAAAAAQAEAAAAAACAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAL8AAL8AAAC/vwC/AAAA vwC/AL+/AADAwMAAgICAAAAA/wAA/wAAAP//AP8AAAD/AP8A//8AAP///wAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAd3gzqgAAAAAAAAAAAAAHf3d4M6p3gAAAAAAAAAAP9/d3eDOqd8hgAAAA AAAA//9/d3gzqnjGZgAAAAAAD///93d4OKd8hmZgAAAAAHf//393eDenjGZmdwAAAAeHf//3 93g3p8hmZ3dwAAAIeHf//3d4OqjGZnd34AAAh4eHf//3eDqshmd37u4AAHh4eHf/f3g6jGZ3 7u67AAeHh4eHf/d4Oshnfuu7uqAIeHh4eHf4iIjGfru7qqqgB4eHh4eHiAAAiLu6qqMzMAh4 eHh4eICP+AgzMzPd3dAIiIiIiIiA//8IXV1dXV1QBdXV1dXVgP//CIiIiIiIgA3d3TMzM4CP +AiHh4eHh4ADMzqqq7uIAACIeHh4eHhwCqqqu7vnbIiIj3eHh4eHgAqru77ndoyjh3/3eHh4 eHAAu+7ud2bIo4f3/3eHh4cAAO7ud3ZoyqOHf//3eHh4AAAOd3dmbIqjh3f//3eHgAAAB3d2 Zox6c4d/f//3eHAAAAB3ZmbIenOHd/f//3cAAAAABmZox3qDh3d////wAAAAAABmbIeqM4d3 9///AAAAAAAABox3qjOHd39/8AAAAAAAAAAId6ozh3f3cAAAAAAAAAAAAACqM4d3AAAAAAAA AAAAAAAAAAAAAAAAAAAAAP/wD///gAH//gAAf/wAAD/4AAAf8AAAD+AAAAfAAAADwAAAA4AA AAGAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAGAAAAB wAAAA8AAAAPgAAAH8AAAD/gAAB/8AAA//gAAf/+AAf//8A//KAAAABAAAAAgAAAAAQAEAAAA AADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAIAAAACAgACAAAAAgACAAICAAACAgIAA wMDAAAAA/wAA/wAAAP//AP8AAAD/AP8A//8AAP///wAAAAAAAAAAAAAACIc6gAAAAA/4hzLM YAAACPiHMsZoAACHj4csZoYACHh4hyxoqqAHh4dwCCqiIAh4eA/wERVQBVERD/CHh4ACKqKA CHh4cAqqhsJ4h4eAAGhmwnj4eAAAhmwjeI+IAAAGzCN4j/AAAAAIo3iAAAAAAAAAAAAAAPgf AADgBwAAwAMAAIABAACAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAEAAIABAADAAwAA 4AcAAPgfAAAAAAEAAgAgIBAAAQAEAOgCAAABABAQEAABAAQAKAEAAAIAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAA --SI6ZN9GD04I Content-Type: application/octet-stream; name=B00005N7RN.01.TZZZZZZZ[1].jpg Content-Transfer-Encoding: base64 Content-ID: /9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAUDBAQEAwUEBAQFBQUGBwwIBwcHBw8LCwkMEQ8S EhEPERETFhwXExQaFRERGCEYGh0dHx8fExciJCIeJBweHx7/2wBDAQUFBQcGBw4ICA4eFBEU Hh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh7/wAAR CABaAEQDASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAA AgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkK FhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWG h4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl 5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREA AgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYk NOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOE hYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk 5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD6buvG7QwaneR+H7+aw0q5lgu7hZIhjyz8 zKpbLYHP+J4qx/wl5t7qJNW0a6063uIJZ7eZ5Y33LGm9gyqSVO3J79Krv4Z1BvCPifSg8An1 S5u5YDuO0CX7u444Pr1qx4o8N3GstpUfmxxxW8FzDOcnOJYGjBUd8E57Vxfv7XT7du+v4HUv Zbev5EB8Y30VrZXl14auYba/4tG+0xszOyF0VlH3S2Md8EjNN8TeLtPXwtbXSW1zcw6nps92 Fhl8t0hSDzGO7qDyq5HQsKrTWGuf2bpKa3Hpdpp2hOl1Pcw3bSNKII2AwhRQnPJyxxjFfHfi v4ky+I9XW4sdS1LS9CiupEtbeR9qmFpA4hJUj5T33cdOwzWFWvWhHq791/wPVHVh8NTqy7W8 z7Sn8V3KzXkOl6KbyLTwq3DyXiREsY1k2oCCWIVl5OBms9tcsru9TUQLqa2vZdMaBVmMezzS dpIH1yRnB6dq+JtM1vV9PvLfU01Oe4kt5NkiXUSXSXG4swDJISMg5TPOdo6ZFfWnwivz8RfA um+IbJbG38u8tFnSOPYFa1c71ACgAFdpAAwMmpp1qtX+vXy/zKr4WFBJv+vxZ1yeNb06Y2st 4eddKjuWgkn+1rvGJTEXCY5GR6g+1VtT8SRwvqt7baIbiy02WSO4mbUvLkYoMybIz1A5HJGc VauPD8kfgKfw5LfWcd1LNJKrM+Fw1wZR79Dj61k6l4W8q61P7NpvhW+OoXck0V7ewh57dpME 5XYwcKTkZYDBGa1m66S9F2318v67mEI0m9uvntp5noVgYWsoXt8+S6B0ySTgjI60UWSqlnCi yJIqxqodAArYGMgDgD2FFegtjhe55T4odU8Y6mVu4RJuYFHMo2IY0G7hcAj5sMO+PQg0TJDv aRr6zDOx6tKqowVuWBUqVDMPvA5C8nnA6rxDqF2mtXmzW9KtlSVVWNxlhgfxfuyckBv++RVF tdMccFpJ4v8ADttdXLosXnXKwmZ+RtTdH8xJ2nAyc9hwK53SV9j0I5hWUUrra2xqLpN5e/DP xFpFrdWN293b3Udo9vNuXdJGcBmwOdx9+Pyr4V+DxMPjJNMuNLXWbqxYz3FpJMsR3cAgEnBI BYn1wOmK/Qiz0fUFtoxca5drKV/eLEsezdz0yn07dq+Gf2mvhN4m+Enj2b4jeHJlfQbu9aSO RGIa2kfJMUg/utlgCPpwcVFeg6sHFaaBh8ZyVeeXV62/Ed8fvMtLm2vBoNjpEFzI6RWkN2sx mIGPMIC7VxzjBP8AI16n/wAE7tYD6D4s8OyXMkjWt5FdRRk5UI6lSR7koM/hXzX4g+I9rdax p+o69ottr9xbJvS2a4dLWIMAVGASzN6/NjnGOw96/Yo8TeG7/UPiBqVtYp4ZkmislS1tDJMk Z/fDeqj5sbiMr06etZYGlOnFJr+vzOjNK9OpJqMr2sfUPj3TbGXSrrU7qQJJDblELuqoM5Ay T05b1HavP/3FxPJA13aZ84fOs6DGCgIwHz8u0nkn7uOvXWu9RM6JDbeLb67nlkCrDJp8satk gjG5fpyePesm+u7Z7WBIdTfIyXT7FI24hnG7Hl8ZAPGM/wBeqpTg3qclDG1aUeWJ6v4dme40 KxnldWleBTKVxjfj5hxx1z0oqHwg27w1YsH8wGL72zbu5POMD+QorZbHHJ3bZxPijwH4i1LX bq+sdbs7S2mkZwhiO4hlUENwQcYPTHWvBvi1pPhH4iwr4xnvtY1PUvDF/cWP/CP+H4DFI9tb zgPJGWVmGAfML9CWVcggGuA+Dv7RvxBg8dX1zfm+1+31UTSXcDvlIXCZRoU6IqKhG0EbhnPI GKOnfGnx5pPxIkvtJihtbKWYyrpAtVRcOxdy0gXIkIDlm7YI5AqJSaeiKhBS3Z9sa/8AFfwL 4f8Ah5Z+N9V1uO30u8tEubRHI+0XAYDCpHnczc8gdOc4AJr4B/aI+OfiT4w6xHZrFJp/h+3m zY6ZG24u3QSSEffcjoOi5IHcnj/FmvN4z+JNxqHizXb+Ozlu3DXDA3UltAGYqiLuAOBgAAge 9fRPwQ+Jn7MHw6ubZ9P0XxJNqxIWTWtTsY5HTPVlCyHyx1+4ucdc1oZnyN0OK9a/ZR+IUHw7 +Ltnfahdm00rUYX0++n7Qq+Nsh7YVwpOe2a+jviR8CvhV8YvDl74q+Dup6XBrrOZ3FtcN9nn c8lJIjzCx7EKvPUc5r4o8TaFq/hrXLrRNe0+fT9RtX2TW8y4ZT/UHqCOD2oA/WC00nVrizgn t/G93cQyRq6Spb27LICOGBC4IOQRjioJvBbzNGZddumKKV4t4hkFi393HUn8+eea/Pz4E/GX 4h+CdPurTQ/EiXFrZJ50OiahH5sM0YJMgjb70bAc4UgHnrivvP4FfE7SPiv4Dg8SaZGbadXM F9Zs25reYAErnupBBB7g9jkCbRloytY6naaZa/YtPgtPNMvlIF3lQufwHFFWaKok/PXTdV03 wJ8Eda1fQNSa6GpW0OkRvJGfKvLhtxmdUcBlCRsV9zivGfGMHiy2TTtL13S9SsVitAbeKe3Z POTe8vmdPn+aVzu54New+OvDOreKtdtfB/gKJNU0zwVpbXV2R+6xOTukYhwV35CqEJOdpH04 2axvPiZ4lgls9RutJtrDRZ7jzdSvGnkdrdGkuDGqjK7juIRQqjGPTOUNFdjt0KfwjTwHJEsP iXWdM026Mxbzb3Spbn5flwqlX2DoeWQ/ePtXoXxSg+DlwiI+vQXMoyLNNHtVDENjGQiheuOG PriuTt/hG2s32i20Xiuwc67A7aVPLZTxSTSrIYzFKu07DuGAxPfOSKo+CvAVxaeM/C1vPc2N yuv6VPd25eFisRAmTawZD84aIkHHpyOoNG73FyM4/Std1LwX4vGqeD9V1TTr20kKxysojlHP KsoJBHGCp4PcV1fxd+JnjT4vyWGo+JNP0iBdPi8pLm2tBACMc7pGJLc87QcAngc11thptxqN /wCDb7SYbHw7ruvX0d1YahJZrNDIXuGjXDrFjzEIG5Bxjluc15xr/h+SBkk8UeJDbXd1bS3d nG8Dyb4wXCbsf6vzCh2gA4BUnAOarm7FqOmpi2t9ZaRBKLJEvL6WPZ9pdPkgB6+Wp6t23Hpz gd67X4MfFbxd8N9B8SWfhMLDc6v5Ci8kAZbXyy5LKrAqWYNjnPGeOlee6Tp95qV/FZafY3Oo XUhwlvbRtI7n0AUEn8K7vR/hr4x1vxNa+FksJH1duf7ItCDJbDu05HywD1Lnd0+XkZpJIlyv obN38ZvjPNMZJfiZqau3URuqKPwUACivVz+zL8OtK/0PxR8avD2maovM1rvhTyvb95NuPfkg fSiq0EdL+xX4j8Lz2WsaDdqDrGr3ZbV7G9hB+0I+RG0ZOfMXB+ZSOjMcYGTo+IPgNoXhj4jX FvoVysSeKLfVIre2kbybaziltSrJkbmIGWwQBjcOuOfkXRPGl/ZTWl3DO1lqWkFJ9Ku4yd0L xknyz6owJGD0J9CRX2P8bvEWk+P/ANnLwj8RJpLu08+4t47lraQosHmOFuVb1UNEVGfUGs5f CNbnzfceJU8L6z4HLaTBJc+EJJvL23nlxXeJ3OTiLj5hnP8AEpBySc1b0fxj4fsbvRdVXRbi 7vPDDSafYM126xXNvIZXZ5GMShdjSttOQSCMqMZrkfFV8niDxHf3EMSR6aZnjgRGLBovUknP QAj3FdZ+zl4bh1y61BJoLNpAViil1Gz+0W4B3FlUFl2nABJzyMVlzLluym2i/wDD/wAR6dpe lWR0z7JBa2+p2961nPqLND51rgo6BlAjZyQHYE5BboM7a3jC70C80fTrnV/Dllr9zpwa3t3t 9RaN2s1nfYkwTOQFJKyLtOMBgQKr/Gf4fWOiX0elWkFpNd3Eby2psGZfu9VMbs3H0NeLWU7W 08c6AGSJwyg9D6g96uKjJXQuZn1v8OYvGXjvwfdad8KfBem/DXw9BFIuo6wsvn3c7KuTDG5A csf7xPH94dD5TqvxRvfDPgWH4f8AgAQaVDdBptV8QwEi61PcxODIRuUL9w4PJU4wCc9Vovj3 SrvQNQ1STxbc6NpvlgPDoVzJpmoRSbcR25gXfDPHjIVxggZ3HnFcpceB/AOm+FTruu2XinR/ MVWs7O/1W3W4vMkfchWAuFxzuYKD2NUmoknmLaY5jjnNvNIs6+YkkrFTIMkbsY6Eg0V2XiWX UNTu7d7XS7Ozsre2S3s1uL5LaR4Fz5bFJHDZ24GcYOM0U7sqxwGtGFtVuHt4hFEz7lQHO0EZ xmv06/Z70aC+/Zs8I6RrlnFc211osYlglTKvG4yAR/ukV+XrEtPliWJIzmv178FRpF4O0SKJ FSNNPgVVUYCgRrgAdhVWJZ+d37Tng2P4bfGfUNN02yZdHuokurFZDIFVHGGG/OWw4cZz3xW5 8JdRsrDwha3GnaswmzI1zZpNHvGSA3ysC6EBQQ6+vPFfRH7dVpayfDLT7qS2he4TUUjSVkBd UYHcoPUA4GR3wK+BdBnmtde3200kDgsA0bFSAfpWUoKWhp0TPf8Ax9feGPGAshNe6vbpFPIA 7yqJN4jkAwypx8wAx3zXjnjnw7oWiwCPTBrD3QnETS3CL5B4ORnAO7IPqMV0niWeeDwvDPBN JFKZEYujEMTuznI9680v7++uhEl1e3M6g7gskrMAfXk9acFZaCe5o+Etc1Lw9etfaSlqt8u4 LczwxyeTx95d4O1vRhzT77xRrUs97JqMxn1O4kZpr+ZS92CQBtEjZKjg8Lg/MRnHFenfsYad p+p/HTSYNSsLW9iWCSRUuIVkUOCMMAwPI9az/wBsqGGD9o/xSkMUcStJCxCKACxhQk8dyeau xLPI555rmd57iaSaaRizySMWZj6knkmimLRTEf/Z --SI6ZN9GD04I-- From owner-ips@ece.cmu.edu Wed Oct 9 07:43:00 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10898 for ; Wed, 9 Oct 2002 07:43:00 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g99B3S214031 for ips-outgoing; Wed, 9 Oct 2002 07:03:28 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from siaar1ab.compuserve.com (siaar1ab.compuserve.com [149.174.40.10]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g99B3Po14027 for ; Wed, 9 Oct 2002 07:03:25 -0400 (EDT) Received: (from mailgate@localhost) by siaar1ab.compuserve.com (8.9.3/8.9.3/SUN-REL-1.4) id HAA28591 for ips@ece.cmu.edu; Wed, 9 Oct 2002 07:03:20 -0400 (EDT) Received: from compuserve.com (dal-tgn-tvo-vty5.as.wcom.net [206.175.229.5]) by siaar1ab.compuserve.com (8.9.3/8.9.3/SUN-REL-1.4) with ESMTP id HAA28483; Wed, 9 Oct 2002 07:03:13 -0400 (EDT) Message-ID: <3DA40E45.AB54F00@compuserve.com> Date: Wed, 09 Oct 2002 06:08:53 -0500 From: Ralph Weber Reply-To: roweber@acm.org X-Mailer: Mozilla 4.7 [en]C-CCK-MCD NSCPCD47 (WinNT; I) X-Accept-Language: en,pdf MIME-Version: 1.0 To: ips@ece.cmu.edu CC: Dave Peterson Subject: Re: IPS-ALL: iSNS WG Last Call References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Dave is 100% correct. During the development of FCIP the issue of discovery mechanisms was considered in detail. The decision was that iSNS is too heavy weight a discovery protocol for FCIP needs and SLPv2 was chosen and documented as the best fit solution. Suggesting in iSNS that there is a relationship with FCIP will lead to confusion when no supporting discussion can be found in the FCIP RFC. No changes are required in iSNS. Thanks. .Ralph Dave Peterson wrote: > I object. > The FCIP group discussed this issue and agreed that SLPv2 was to be used for > FCIP Entity discovery. > As such, the recently completed FCIP draft contains no mention of iSNS > support. > A single dynamic discovery protocol is needed and its SLPv2. > > ...dap > > > -----Original Message----- > > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > > Anil Rijhsinghani > > Sent: Tuesday, October 08, 2002 10:05 AM > > To: 'Joshua Tseng'; ips@ece.cmu.edu > > Subject: RE: IPS-ALL: iSNS WG Last Call > > > > > > Joshua: > > > > Unless there are objections, it would be useful to add those hooks as an > > option. In an environment where both FCIP and iSCSI are in use, > > and iSNS is > > available, it may help to keep down the number of discovery protocols that > > need to be managed by the user. Either SLP could be used for > > both, or iSNS. > > > > Anil > > > > -----Original Message----- > > From: Joshua Tseng [mailto:jtseng@NishanSystems.com] > > Sent: Monday, October 07, 2002 4:08 PM > > To: Anil Rijhsinghani; Black_David@emc.com; ips@ece.cmu.edu > > Subject: RE: IPS-ALL: iSNS WG Last Call > > > > > > Anil, > > > > It would be very easy, especially now that Portals can be > > members of Discovery Domains. All we would need to do is > > to add a new Entity Protocol type (FCIP = 3). FCIP connectivity > > would then be established based on Portal membership in > > Discovery Domains. Other than that, we would just new narative > > text describing how you use iSNS to set up FCIP sessions. > > > > Please let me know if this is desireable for the FCIP folks. > > > > Josh > > > > > -----Original Message----- > > > From: Anil Rijhsinghani [mailto:anil.rijhsinghani@mcdata.com] > > > Sent: Monday, October 07, 2002 1:43 PM > > > To: 'Black_David@emc.com'; ips@ece.cmu.edu > > > Subject: RE: IPS-ALL: iSNS WG Last Call > > > > > > > > > How hard would it be to add hooks for optional FCIP support > > > in iSNS? It > > > currently supports only iFCP and iSCSI. > > > > > > Regards, > > > Anil > > > > > > -----Original Message----- > > > From: Black_David@emc.com [mailto:Black_David@emc.com] > > > Sent: Friday, September 27, 2002 10:07 AM > > > To: ips@ece.cmu.edu > > > Subject: IPS-ALL: iSNS WG Last Call > > > > > > > > > All, > > > > > > We would like to announce IPS Working Group Last call for > > > the Internet Storage Name Service (iSNS). > > > > > > Details: > > > > > > Document: Internet Storage Name Service (iSNS) > > > URL: http://www.ietf.org/internet-drafts/draft-ietf-ips-isns-13.txt > > > Note: There are formatting (line length) problems with this draft. > > > It may get updated to -14 shortly to correct them without > > > change to its content. > > > > > > Last call period: 2 Weeks > > > Submit comments no later than: Sunday, October 13, 2002 at 5pm EST > > > Editor: Josh Tseng > > > > > > Please submit editorial comments directly to Josh, with copy > > > to David Black > > > (black_david@emc.com), and Elizabeth Rodriguez(erodrigu@brocade.com) > > > Submit technical comments to the IPS mailing list (ips@ece.cmu.edu) > > > > > > Editorial comments may be resolved directly by the editor of > > > the document, > > > but any technical issues must be discussed on the IPS reflector. > > > > > > Thanks, > > > David Black & Elizabeth Rodriguez > > > IPS co-chairs > > > > > > --------------------------------------------------- > > > David L. Black, Senior Technologist > > > EMC Corporation, 42 South St., Hopkinton, MA 01748 > > > +1 (508) 249-6449 FAX: +1 (508) 497-8018 > > > black_david@emc.com Mobile: +1 (978) 394-7754 > > > --------------------------------------------------- > > > > > > > > > =========================================================== > > > Notice > > > > > > All information transmitted hereby is intended only for the use of the > > > addressee(s) named above and may contain confidential and privileged > > > information. Any unauthorized review, use, disclosure or > > > distribution is > > > prohibited. If the reader of this message is not the > > > intended recipient(s) > > > or the employee or agent responsible for delivering the message to the > > > intended recipient(s), you may not distribute or copy this > > > communication to > > > another. Anyone who receives this communication in error > > > should notify us > > > immediately by telephone and mail the original message to us > > > at the above > > > address and destroy all copies. > > > =========================================================== > > > > > > > > > =========================================================== > > Notice > > > > All information transmitted hereby is intended only for the use of the > > addressee(s) named above and may contain confidential and privileged > > information. Any unauthorized review, use, disclosure or distribution is > > prohibited. If the reader of this message is not the intended > > recipient(s) > > or the employee or agent responsible for delivering the message to the > > intended recipient(s), you may not distribute or copy this > > communication to > > another. Anyone who receives this communication in error should notify us > > immediately by telephone and mail the original message to us at the above > > address and destroy all copies. > > =========================================================== From owner-ips@ece.cmu.edu Wed Oct 9 10:07:57 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17870 for ; Wed, 9 Oct 2002 10:07:57 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g99DQj221762 for ips-outgoing; Wed, 9 Oct 2002 09:26:45 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [194.196.100.235]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g99DQgo21754; Wed, 9 Oct 2002 09:26:42 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g99DQZQq038940; Wed, 9 Oct 2002 15:26:35 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g99DQYWS082420; Wed, 9 Oct 2002 15:26:35 +0200 In-Reply-To: To: Eddy Quicksall Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI: Logical Unit Reset X-Mailer: Lotus Notes Release 6.0 September 26, 2002 From: "Julian Satran" Message-ID: Date: Wed, 9 Oct 2002 15:26:32 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 09/10/2002 15:26:34, Serialize complete at 09/10/2002 15:26:34 Content-Type: multipart/alternative; boundary="=_alternative 00495714C2256C4D_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00495714C2256C4D_= Content-Type: text/plain; charset="US-ASCII" As other related protocols we preferred to be mute on reset. The side effects of reset are well understood and it has been made optional in T10. Julo Eddy Quicksall Sent by: owner-ips@ece.cmu.edu 08/10/02 16:08 To: ips@ece.cmu.edu cc: Subject: iSCSI: Logical Unit Reset Section 9.5.1 says: Task management requests must act on all the commands having a CmdSN lower than the task management CmdSN. But a Logical Unit Reset, Target [WARM | COLD] Reset and Clear Task Set w/TST=0 applies to all initiators for the Target or Target/LUN. Since the initiator that issued the TMF knows nothing about the CmdSN's of other initiators, how is this handled for the other sessions? One thing that can be done is to consider that the session that issued the TMF is synchronized only with itself and therefore its TMF would apply to all CmdSN's on the other sessions. A statement to this effect should probably be added to 9.5.1. Eddy mailto: Eddy_Quicksall@iVivity.com --=_alternative 00495714C2256C4D_= Content-Type: text/html; charset="US-ASCII"
As other related protocols we preferred to be mute on reset.
The side effects of reset are well understood and it has been made optional in T10.

Julo


Eddy Quicksall <eddy_quicksall@ivivity.com>
Sent by: owner-ips@ece.cmu.edu

08/10/02 16:08

       
        To:        ips@ece.cmu.edu
        cc:        
        Subject:        iSCSI: Logical Unit Reset

       


Section 9.5.1 says:

Task management requests must act on all the commands having a CmdSN lower
than the task management CmdSN.


But a Logical Unit Reset, Target [WARM | COLD] Reset and Clear Task Set
w/TST=0 applies to all initiators for the Target or Target/LUN.

Since the initiator that issued the TMF knows nothing about the CmdSN's of
other initiators, how is this handled for the other sessions?

One thing that can be done is to consider that the session that issued the
TMF is synchronized only with itself and therefore its TMF would apply to
all CmdSN's on the other sessions. A statement to this effect should
probably be added to 9.5.1.

Eddy
mailto: Eddy_Quicksall@iVivity.com
--=_alternative 00495714C2256C4D_=-- From owner-ips@ece.cmu.edu Wed Oct 9 10:17:58 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18683 for ; Wed, 9 Oct 2002 10:17:58 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g99E3ir24304 for ips-outgoing; Wed, 9 Oct 2002 10:03:44 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from erie.mcdata.com (mcjekyll.mcdata.com [144.49.6.25]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g99E3ho24300 for ; Wed, 9 Oct 2002 10:03:43 -0400 (EDT) Received: by erie.mcdata.com with Internet Mail Service (5.5.2653.19) id ; Wed, 9 Oct 2002 08:05:38 -0600 Message-ID: From: Anil Rijhsinghani To: "'roweber@acm.org'" , ips@ece.cmu.edu Cc: Dave Peterson Subject: RE: IPS-ALL: iSNS WG Last Call Date: Wed, 9 Oct 2002 08:05:23 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk While we did agree to use SLPv2 for dynamic discovery in FCIP, there was no agreement that no other protocol can be used. Specifying FCIP support in iSNS requires no change to the FCIP draft (other than perhaps a reference). Joshua: allow us to take this discussion back into the FCIP group. We will get back to you on this. Regards, Anil -----Original Message----- From: Ralph Weber [mailto:ralphoweber@compuserve.com] Sent: Wednesday, October 09, 2002 5:09 AM To: ips@ece.cmu.edu Cc: Dave Peterson Subject: Re: IPS-ALL: iSNS WG Last Call Dave is 100% correct. During the development of FCIP the issue of discovery mechanisms was considered in detail. The decision was that iSNS is too heavy weight a discovery protocol for FCIP needs and SLPv2 was chosen and documented as the best fit solution. Suggesting in iSNS that there is a relationship with FCIP will lead to confusion when no supporting discussion can be found in the FCIP RFC. No changes are required in iSNS. Thanks. .Ralph Dave Peterson wrote: > I object. > The FCIP group discussed this issue and agreed that SLPv2 was to be used for > FCIP Entity discovery. > As such, the recently completed FCIP draft contains no mention of iSNS > support. > A single dynamic discovery protocol is needed and its SLPv2. > > ...dap > > > -----Original Message----- > > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > > Anil Rijhsinghani > > Sent: Tuesday, October 08, 2002 10:05 AM > > To: 'Joshua Tseng'; ips@ece.cmu.edu > > Subject: RE: IPS-ALL: iSNS WG Last Call > > > > > > Joshua: > > > > Unless there are objections, it would be useful to add those hooks as an > > option. In an environment where both FCIP and iSCSI are in use, > > and iSNS is > > available, it may help to keep down the number of discovery protocols that > > need to be managed by the user. Either SLP could be used for > > both, or iSNS. > > > > Anil > > > > -----Original Message----- > > From: Joshua Tseng [mailto:jtseng@NishanSystems.com] > > Sent: Monday, October 07, 2002 4:08 PM > > To: Anil Rijhsinghani; Black_David@emc.com; ips@ece.cmu.edu > > Subject: RE: IPS-ALL: iSNS WG Last Call > > > > > > Anil, > > > > It would be very easy, especially now that Portals can be > > members of Discovery Domains. All we would need to do is > > to add a new Entity Protocol type (FCIP = 3). FCIP connectivity > > would then be established based on Portal membership in > > Discovery Domains. Other than that, we would just new narative > > text describing how you use iSNS to set up FCIP sessions. > > > > Please let me know if this is desireable for the FCIP folks. > > > > Josh > > > > > -----Original Message----- > > > From: Anil Rijhsinghani [mailto:anil.rijhsinghani@mcdata.com] > > > Sent: Monday, October 07, 2002 1:43 PM > > > To: 'Black_David@emc.com'; ips@ece.cmu.edu > > > Subject: RE: IPS-ALL: iSNS WG Last Call > > > > > > > > > How hard would it be to add hooks for optional FCIP support > > > in iSNS? It > > > currently supports only iFCP and iSCSI. > > > > > > Regards, > > > Anil > > > > > > -----Original Message----- > > > From: Black_David@emc.com [mailto:Black_David@emc.com] > > > Sent: Friday, September 27, 2002 10:07 AM > > > To: ips@ece.cmu.edu > > > Subject: IPS-ALL: iSNS WG Last Call > > > > > > > > > All, > > > > > > We would like to announce IPS Working Group Last call for > > > the Internet Storage Name Service (iSNS). > > > > > > Details: > > > > > > Document: Internet Storage Name Service (iSNS) > > > URL: http://www.ietf.org/internet-drafts/draft-ietf-ips-isns-13.txt > > > Note: There are formatting (line length) problems with this draft. > > > It may get updated to -14 shortly to correct them without > > > change to its content. > > > > > > Last call period: 2 Weeks > > > Submit comments no later than: Sunday, October 13, 2002 at 5pm EST > > > Editor: Josh Tseng > > > > > > Please submit editorial comments directly to Josh, with copy > > > to David Black > > > (black_david@emc.com), and Elizabeth Rodriguez(erodrigu@brocade.com) > > > Submit technical comments to the IPS mailing list (ips@ece.cmu.edu) > > > > > > Editorial comments may be resolved directly by the editor of > > > the document, > > > but any technical issues must be discussed on the IPS reflector. > > > > > > Thanks, > > > David Black & Elizabeth Rodriguez > > > IPS co-chairs > > > > > > --------------------------------------------------- > > > David L. Black, Senior Technologist > > > EMC Corporation, 42 South St., Hopkinton, MA 01748 > > > +1 (508) 249-6449 FAX: +1 (508) 497-8018 > > > black_david@emc.com Mobile: +1 (978) 394-7754 > > > --------------------------------------------------- > > > > > > > > > =========================================================== > > > Notice > > > > > > All information transmitted hereby is intended only for the use of the > > > addressee(s) named above and may contain confidential and privileged > > > information. Any unauthorized review, use, disclosure or > > > distribution is > > > prohibited. If the reader of this message is not the > > > intended recipient(s) > > > or the employee or agent responsible for delivering the message to the > > > intended recipient(s), you may not distribute or copy this > > > communication to > > > another. Anyone who receives this communication in error > > > should notify us > > > immediately by telephone and mail the original message to us > > > at the above > > > address and destroy all copies. > > > =========================================================== > > > > > > > > > =========================================================== > > Notice > > > > All information transmitted hereby is intended only for the use of the > > addressee(s) named above and may contain confidential and privileged > > information. Any unauthorized review, use, disclosure or distribution is > > prohibited. If the reader of this message is not the intended > > recipient(s) > > or the employee or agent responsible for delivering the message to the > > intended recipient(s), you may not distribute or copy this > > communication to > > another. Anyone who receives this communication in error should notify us > > immediately by telephone and mail the original message to us at the above > > address and destroy all copies. > > =========================================================== =========================================================== Notice All information transmitted hereby is intended only for the use of the addressee(s) named above and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If the reader of this message is not the intended recipient(s) or the employee or agent responsible for delivering the message to the intended recipient(s), you may not distribute or copy this communication to another. Anyone who receives this communication in error should notify us immediately by telephone and mail the original message to us at the above address and destroy all copies. =========================================================== From owner-ips@ece.cmu.edu Wed Oct 9 10:52:52 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20554 for ; Wed, 9 Oct 2002 10:52:52 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g99EKIm25713 for ips-outgoing; Wed, 9 Oct 2002 10:20:18 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cybernetics.com (cyborg.cybernetics.com [206.246.200.18]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g99EKGo25707 for ; Wed, 9 Oct 2002 10:20:16 -0400 (EDT) Received: from condor ([137.157.1.224]) by cyborg.cybernetics.com with SMTP id <119058>; Wed, 9 Oct 2002 10:20:06 -0400 Reply-To: From: "Tony Battersby" To: "'Bill Studenmund'" Cc: "'Eddy Quicksall'" , Subject: RE: iSCSI: Logical Unit Reset Date: Wed, 9 Oct 2002 10:20:04 -0400 Message-ID: <000301c26f9e$f6d70dc0$e0019d89@cybernetics.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Bill Studenmund > Sent: Tuesday, October 08, 2002 8:22 PM > To: Tony Battersby > Cc: 'Eddy Quicksall'; ips@ece.cmu.edu > Subject: RE: iSCSI: Logical Unit Reset > I'm confused. I thought what Eddie was talking about is the > case where we > have two initiators (well two sessions). One of them issues > some commands. > The other does a LU reset, wiping out those commands. Then > the first comes > along and does a task management request on the original > commands, which > aren't there anymore because the other session did a reset > (and thus the > Task Management command can't work on them). > > Or is that not what Eddie was talking about? > > Take care, > > Bill I can't speak for Eddy, but to me this sounds like a slightly different but related question. Let me try to illustrate what I think should happen with an example: Suppose that two initiators, I1 and I2, have open sessions with the same target. Initiator I1 has an outstanding NOP-Out and an outstanding SCSI command, and is waiting for a reply to both. Initiator I2 also has an outstanding NOP-Out and an outstanding SCSI command, and is waiting for a reply to both. At this point, initiator I1 issues a Logical Unit Reset. The question is, what specifically happens to the four outstanding commands (the two SCSI commands and the two NOP-In replies to the two NOP-Outs). In section 9.5.1: "The iSCSI target MUST ensure that no responses for the tasks covered by a task management function are delivered to the iSCSI initiator after the Task Management response except for a task covered by a TASK REASSIGN." The use of the definite article "the" in the phrase "the iSCSI initiator" implies that this sentence applies only to the initiator that issued the TMF, and not to any other initiator. For initiator I1, the following sequences of events are valid for the target: 1) Return both the NOP-In and the normal response to the SCSI command completing, followed by the TMF response. 2) Return only the NOP-In, followed by the TMF response. Never return the SCSI command response. 3) Return only the normal response to the SCSI command completing, followed by the TMF response. Never return the NOP-In. 4) Return the TMF response. Never return the SCSI command response or the NOP-In. By "normal response to the SCSI command", I mean the response that would have been returned had there not been a Logical Unit Reset. Which sequence of events is taken depends on the implementation and timings at the target. The iSCSI draft doesn't say anything about what should happen to the commands from initiator I2, so I assume that nothing should happen to them except as specified by SAM-2 section 5.7.3 ("When a SCSI initiator port aborts tasks from other SCSI initiator ports"). The NOP-In from initiator I2 should not be affected at all, since the SCSI layer doesn't know about it. So basically, the Logical Unit reset from initiator I1 alters the SCSI command response for the SCSI command from initiator I2, but it doesn't make any tasks from initiator I2 suddenly disappear from the target. So, to finally respond to your question, the assumption that the commands "aren't there anymore because the other session did a reset" is incorrect because the command _are_ still there. After the LU Reset, the target is still intending to return a response to both the NOP-Out and the SCSI command from initiator I2. The LU Reset from initiator I1 _has_ changed the SCSI command response for the SCSI command from initiator I2, but has not affected the commands from initiator I2 in any other way. Anthony J. Battersby Cybernetics From owner-ips@ece.cmu.edu Wed Oct 9 12:30:42 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24533 for ; Wed, 9 Oct 2002 12:30:41 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g99GIp905521 for ips-outgoing; Wed, 9 Oct 2002 12:18:51 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from hammer.brocade.com ([63.121.140.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g99GIlo05516 for ; Wed, 9 Oct 2002 12:18:47 -0400 (EDT) Received: from hq-ex-c2.brocade.com (hq-ex-c2.brocade.com [192.168.126.35]) by hammer.brocade.com (8.11.3/8.11.3) with ESMTP id g99GIdi26805; Wed, 9 Oct 2002 09:18:39 -0700 (PDT) Received: by hq-ex-c2.brocade.com with Internet Mail Service (5.5.2653.19) id <4LH16Q24>; Wed, 9 Oct 2002 09:18:39 -0700 Message-ID: From: Elizabeth Rodriguez To: Anil Rijhsinghani , "'roweber@acm.org'" , ips@ece.cmu.edu Cc: Dave Peterson Subject: RE: IPS-ALL: iSNS WG Last Call Date: Wed, 9 Oct 2002 09:18:31 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C26FAF.8218AB90" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C26FAF.8218AB90 Content-Type: text/plain; charset="iso-8859-1" Chair hat on -- From Josh's email, it appears that should FCIP need iSNS support in the future, it will be fairly easy to add support to iSNS. If the protocol numbers are assigned by IANA (which they probably should be), should FCIP desire iSNS support it can request a protocol number from IANA at that time. FCIP has completed working group last call, and iSNS is now in WG last call. Instead of modifying these drafts directly at this stage to include FCIP support, an new draft on this topic should be prepared and presented to the working group. A discussion can then be held to determine if there is interests in such a draft being adopted by the WG as a work group item. There are some statements in the FCIP draft that state that SLPv2 is the only discovery mechanism supported, and iSNS only mentions support for iSCSI and iFCP in many places throughout the document. The effect of the new draft would in effect augment both the iSNS and FCIP draft to support iSNS. Thanks, Elizabeth Rodriguez IPS WG co-chair -----Original Message----- From: Anil Rijhsinghani [mailto:anil.rijhsinghani@mcdata.com] Sent: Wednesday, October 09, 2002 7:05 AM To: 'roweber@acm.org'; ips@ece.cmu.edu Cc: Dave Peterson Subject: RE: IPS-ALL: iSNS WG Last Call While we did agree to use SLPv2 for dynamic discovery in FCIP, there was no agreement that no other protocol can be used. Specifying FCIP support in iSNS requires no change to the FCIP draft (other than perhaps a reference). Joshua: allow us to take this discussion back into the FCIP group. We will get back to you on this. Regards, Anil -----Original Message----- From: Ralph Weber [mailto:ralphoweber@compuserve.com] Sent: Wednesday, October 09, 2002 5:09 AM To: ips@ece.cmu.edu Cc: Dave Peterson Subject: Re: IPS-ALL: iSNS WG Last Call Dave is 100% correct. During the development of FCIP the issue of discovery mechanisms was considered in detail. The decision was that iSNS is too heavy weight a discovery protocol for FCIP needs and SLPv2 was chosen and documented as the best fit solution. Suggesting in iSNS that there is a relationship with FCIP will lead to confusion when no supporting discussion can be found in the FCIP RFC. No changes are required in iSNS. Thanks. .Ralph Dave Peterson wrote: > I object. > The FCIP group discussed this issue and agreed that SLPv2 was to be used for > FCIP Entity discovery. > As such, the recently completed FCIP draft contains no mention of iSNS > support. > A single dynamic discovery protocol is needed and its SLPv2. > > ...dap > > > -----Original Message----- > > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > > Anil Rijhsinghani > > Sent: Tuesday, October 08, 2002 10:05 AM > > To: 'Joshua Tseng'; ips@ece.cmu.edu > > Subject: RE: IPS-ALL: iSNS WG Last Call > > > > > > Joshua: > > > > Unless there are objections, it would be useful to add those hooks as an > > option. In an environment where both FCIP and iSCSI are in use, > > and iSNS is > > available, it may help to keep down the number of discovery protocols that > > need to be managed by the user. Either SLP could be used for > > both, or iSNS. > > > > Anil > > > > -----Original Message----- > > From: Joshua Tseng [mailto:jtseng@NishanSystems.com] > > Sent: Monday, October 07, 2002 4:08 PM > > To: Anil Rijhsinghani; Black_David@emc.com; ips@ece.cmu.edu > > Subject: RE: IPS-ALL: iSNS WG Last Call > > > > > > Anil, > > > > It would be very easy, especially now that Portals can be > > members of Discovery Domains. All we would need to do is > > to add a new Entity Protocol type (FCIP = 3). FCIP connectivity > > would then be established based on Portal membership in > > Discovery Domains. Other than that, we would just new narative > > text describing how you use iSNS to set up FCIP sessions. > > > > Please let me know if this is desireable for the FCIP folks. > > > > Josh > > > > > -----Original Message----- > > > From: Anil Rijhsinghani [mailto:anil.rijhsinghani@mcdata.com] > > > Sent: Monday, October 07, 2002 1:43 PM > > > To: 'Black_David@emc.com'; ips@ece.cmu.edu > > > Subject: RE: IPS-ALL: iSNS WG Last Call > > > > > > > > > How hard would it be to add hooks for optional FCIP support > > > in iSNS? It > > > currently supports only iFCP and iSCSI. > > > > > > Regards, > > > Anil > > > > > > -----Original Message----- > > > From: Black_David@emc.com [mailto:Black_David@emc.com] > > > Sent: Friday, September 27, 2002 10:07 AM > > > To: ips@ece.cmu.edu > > > Subject: IPS-ALL: iSNS WG Last Call > > > > > > > > > All, > > > > > > We would like to announce IPS Working Group Last call for > > > the Internet Storage Name Service (iSNS). > > > > > > Details: > > > > > > Document: Internet Storage Name Service (iSNS) > > > URL: http://www.ietf.org/internet-drafts/draft-ietf-ips-isns-13.txt > > > Note: There are formatting (line length) problems with this draft. > > > It may get updated to -14 shortly to correct them without > > > change to its content. > > > > > > Last call period: 2 Weeks > > > Submit comments no later than: Sunday, October 13, 2002 at 5pm EST > > > Editor: Josh Tseng > > > > > > Please submit editorial comments directly to Josh, with copy > > > to David Black > > > (black_david@emc.com), and Elizabeth Rodriguez(erodrigu@brocade.com) > > > Submit technical comments to the IPS mailing list (ips@ece.cmu.edu) > > > > > > Editorial comments may be resolved directly by the editor of > > > the document, > > > but any technical issues must be discussed on the IPS reflector. > > > > > > Thanks, > > > David Black & Elizabeth Rodriguez > > > IPS co-chairs > > > > > > --------------------------------------------------- > > > David L. Black, Senior Technologist > > > EMC Corporation, 42 South St., Hopkinton, MA 01748 > > > +1 (508) 249-6449 FAX: +1 (508) 497-8018 > > > black_david@emc.com Mobile: +1 (978) 394-7754 > > > --------------------------------------------------- > > > > > > > > > =========================================================== > > > Notice > > > > > > All information transmitted hereby is intended only for the use of the > > > addressee(s) named above and may contain confidential and privileged > > > information. Any unauthorized review, use, disclosure or > > > distribution is > > > prohibited. If the reader of this message is not the > > > intended recipient(s) > > > or the employee or agent responsible for delivering the message to the > > > intended recipient(s), you may not distribute or copy this > > > communication to > > > another. Anyone who receives this communication in error > > > should notify us > > > immediately by telephone and mail the original message to us > > > at the above > > > address and destroy all copies. > > > =========================================================== > > > > > > > > > =========================================================== > > Notice > > > > All information transmitted hereby is intended only for the use of the > > addressee(s) named above and may contain confidential and privileged > > information. Any unauthorized review, use, disclosure or distribution is > > prohibited. If the reader of this message is not the intended > > recipient(s) > > or the employee or agent responsible for delivering the message to the > > intended recipient(s), you may not distribute or copy this > > communication to > > another. Anyone who receives this communication in error should notify us > > immediately by telephone and mail the original message to us at the above > > address and destroy all copies. > > =========================================================== =========================================================== Notice All information transmitted hereby is intended only for the use of the addressee(s) named above and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If the reader of this message is not the intended recipient(s) or the employee or agent responsible for delivering the message to the intended recipient(s), you may not distribute or copy this communication to another. Anyone who receives this communication in error should notify us immediately by telephone and mail the original message to us at the above address and destroy all copies. =========================================================== ------_=_NextPart_001_01C26FAF.8218AB90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: IPS-ALL: iSNS WG Last Call

Chair hat on --

From Josh's email, it appears that should FCIP need = iSNS support in the future, it will be fairly easy to add support to = iSNS.  If the protocol numbers are assigned by IANA (which they = probably should be), should FCIP desire iSNS support it can request a = protocol number from IANA at that time.

FCIP has completed working group last call, and iSNS = is now in WG last call. 
Instead of modifying these drafts directly at this = stage to include FCIP support, an new draft on this topic should be = prepared and presented to the working group.  A discussion can = then be held to determine if there is interests in such a draft being = adopted by the WG as a work group item. 

There are some statements in the FCIP draft that = state that SLPv2 is the only discovery mechanism supported, and iSNS = only mentions support for iSCSI and iFCP in many places throughout the = document.  The effect of the new draft would in effect augment = both the iSNS and FCIP draft to support iSNS.

Thanks,

Elizabeth Rodriguez
IPS WG co-chair
-----Original Message-----
From: Anil Rijhsinghani [mailto:anil.rijhsinghani@mc= data.com]
Sent: Wednesday, October 09, 2002 7:05 AM
To: 'roweber@acm.org'; ips@ece.cmu.edu
Cc: Dave Peterson
Subject: RE: IPS-ALL: iSNS WG Last Call


While we did agree to use SLPv2 for dynamic discovery = in FCIP, there was no
agreement that no other protocol can be used. = Specifying FCIP support in
iSNS requires no change to the FCIP draft (other = than perhaps a reference).

Joshua: allow us to take this discussion back into = the FCIP group. We will
get back to you on this.

Regards,
Anil

-----Original Message-----
From: Ralph Weber [mailto:ralphoweber@compuserve= .com]
Sent: Wednesday, October 09, 2002 5:09 AM
To: ips@ece.cmu.edu
Cc: Dave Peterson
Subject: Re: IPS-ALL: iSNS WG Last Call


Dave is 100% correct.

During the development of FCIP the issue of discovery = mechanisms
was considered in detail. The decision was that iSNS = is too heavy
weight a discovery protocol for FCIP needs and SLPv2 = was chosen
and documented as the best fit solution.

Suggesting in iSNS that there is a relationship with = FCIP will
lead to confusion when no supporting discussion can = be found in
the FCIP RFC.

No changes are required in iSNS.

Thanks.

.Ralph

Dave Peterson wrote:

> I object.
> The FCIP group discussed this issue and agreed = that SLPv2 was to be used
for
> FCIP Entity discovery.
> As such, the recently completed FCIP draft = contains no mention of iSNS
> support.
> A single dynamic discovery protocol is needed = and its SLPv2.
>
> ...dap
>
> > -----Original Message-----
> > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]O= n Behalf Of
> > Anil Rijhsinghani
> > Sent: Tuesday, October 08, 2002 10:05 = AM
> > To: 'Joshua Tseng'; ips@ece.cmu.edu
> > Subject: RE: IPS-ALL: iSNS WG Last = Call
> >
> >
> > Joshua:
> >
> > Unless there are objections, it would be = useful to add those hooks as an
> > option. In an environment where both FCIP = and iSCSI are in use,
> > and iSNS is
> > available, it may help to keep down the = number of discovery protocols
that
> > need to be managed by the user. Either SLP = could be used for
> > both, or iSNS.
> >
> > Anil
> >
> > -----Original Message-----
> > From: Joshua Tseng [mailto:jtseng@NishanSystems.com= ]
> > Sent: Monday, October 07, 2002 4:08 = PM
> > To: Anil Rijhsinghani; = Black_David@emc.com; ips@ece.cmu.edu
> > Subject: RE: IPS-ALL: iSNS WG Last = Call
> >
> >
> > Anil,
> >
> > It would be very easy, especially now that = Portals can be
> > members of Discovery Domains.  All we = would need to do is
> > to add a new Entity Protocol type (FCIP = =3D 3).  FCIP connectivity
> > would then be established based on Portal = membership in
> > Discovery Domains.  Other than that, = we would just new narative
> > text describing how you use iSNS to set up = FCIP sessions.
> >
> > Please let me know if this is desireable = for the FCIP folks.
> >
> > Josh
> >
> > > -----Original Message-----
> > > From: Anil Rijhsinghani [mailto:anil.rijhsinghani@mc= data.com]
> > > Sent: Monday, October 07, 2002 1:43 = PM
> > > To: 'Black_David@emc.com'; = ips@ece.cmu.edu
> > > Subject: RE: IPS-ALL: iSNS WG Last = Call
> > >
> > >
> > > How hard would it be to add hooks for = optional FCIP support
> > > in iSNS? It
> > > currently supports only iFCP and = iSCSI.
> > >
> > > Regards,
> > > Anil
> > >
> > > -----Original Message-----
> > > From: Black_David@emc.com [mailto:Black_David@emc.com]
> > > Sent: Friday, September 27, 2002 = 10:07 AM
> > > To: ips@ece.cmu.edu
> > > Subject: IPS-ALL: iSNS WG Last = Call
> > >
> > >
> > > All,
> > >
> > > We would like to announce IPS Working = Group Last call for
> > > the Internet Storage Name Service = (iSNS).
> > >
> > > Details:
> > >
> > > Document: Internet Storage Name = Service (iSNS)
> > > URL: http://www.ietf.org/internet-drafts/draft-ietf-ips-isn= s-13.txt
> > > Note: There are formatting (line = length) problems with this draft.
> > >     It may get = updated to -14 shortly to correct them without
> > >     change to its = content.
> > >
> > > Last call period: 2 Weeks
> > > Submit comments no later than: = Sunday, October 13, 2002 at 5pm EST
> > > Editor:  Josh Tseng = <jtseng@nishansystems.com>
> > >
> > > Please submit editorial comments = directly to Josh, with copy
> > > to David Black
> > > (black_david@emc.com), and Elizabeth = Rodriguez(erodrigu@brocade.com)
> > > Submit technical comments to the IPS = mailing list (ips@ece.cmu.edu)
> > >
> > > Editorial comments may be resolved = directly by the editor of
> > > the document,
> > > but any technical issues must be = discussed on the IPS reflector.
> > >
> > > Thanks,
> > > David Black & Elizabeth = Rodriguez
> > > IPS co-chairs
> > >
> > > = ---------------------------------------------------
> > > David L. Black, Senior = Technologist
> > > EMC Corporation, 42 South St., = Hopkinton, MA  01748
> > > +1 (508) = 249-6449          &nbs= p; FAX: +1 (508) 497-8018
> > > = black_david@emc.com       Mobile: +1 = (978) 394-7754
> > > = ---------------------------------------------------
> > >
> > >
> > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > > Notice
> > >
> > > All information transmitted hereby is = intended only for the use of the
> > > addressee(s) named above and may = contain confidential and privileged
> > > information.  Any unauthorized = review, use, disclosure or
> > > distribution is
> > > prohibited.  If the reader of = this message is not the
> > > intended recipient(s)
> > > or the employee or agent responsible = for delivering the message to the
> > > intended recipient(s), you may not = distribute or copy this
> > > communication to
> > > another.  Anyone who receives = this communication in error
> > > should notify us
> > > immediately by telephone and mail the = original message to us
> > > at the above
> > > address and destroy all = copies.
> > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > >
> >
> >
> > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > Notice
> >
> > All information transmitted hereby is = intended only for the use of the
> > addressee(s) named above and may contain = confidential and privileged
> > information.  Any unauthorized = review, use, disclosure or distribution
is
> > prohibited.  If the reader of this = message is not the intended
> > recipient(s)
> > or the employee or agent responsible for = delivering the message to the
> > intended recipient(s), you may not = distribute or copy this
> > communication to
> > another.  Anyone who receives this = communication in error should notify
us
> > immediately by telephone and mail the = original message to us at the
above
> > address and destroy all copies.
> > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D




=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Notice

All information transmitted hereby is intended only = for the use of the
addressee(s) named above and may contain = confidential and privileged
information.  Any unauthorized review, use, = disclosure or distribution is
prohibited.  If the reader of this message is = not the intended recipient(s)
or the employee or agent responsible for delivering = the message to the
intended recipient(s), you may not distribute or = copy this communication to
another.  Anyone who receives this = communication in error should notify us
immediately by telephone and mail the original = message to us at the above
address and destroy all copies.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

------_=_NextPart_001_01C26FAF.8218AB90-- From owner-ips@ece.cmu.edu Wed Oct 9 12:33:06 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24706 for ; Wed, 9 Oct 2002 12:33:01 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g99FrCa03509 for ips-outgoing; Wed, 9 Oct 2002 11:53:12 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from hammer.brocade.com ([63.121.140.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g99Fr8o03503 for ; Wed, 9 Oct 2002 11:53:09 -0400 (EDT) Received: from hq-ex-c2.brocade.com (hq-ex-c2.brocade.com [192.168.126.35]) by hammer.brocade.com (8.11.3/8.11.3) with ESMTP id g99Fr3i23100 for ; Wed, 9 Oct 2002 08:53:03 -0700 (PDT) Received: by hq-ex-c2.brocade.com with Internet Mail Service (5.5.2653.19) id <4LH16PF9>; Wed, 9 Oct 2002 08:53:03 -0700 Message-ID: From: Elizabeth Rodriguez To: ips@ece.cmu.edu Subject: IPS WG Last call on "Definitions of Managed Objects for User Iden tity Authentication" Date: Wed, 9 Oct 2002 08:52:56 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C26FAB.EF2A4210" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C26FAB.EF2A4210 Content-Type: text/plain; charset="iso-8859-1" All, We would like to announce IPS WG last call on the draft "Definitions of Managed Objects for User Identity Authentication". The last call period is for two weeks, ending at 5pm EST on Wednesday, October 23. Draft: http://www.ietf.org/internet-drafts/draft-ietf-ips-auth-mib-02.txt Editorial comments may be directly sent to the editor/authors of the document -- Editor: Mark Bakke[mbakke@cisco.com] Authors: Mark Bakke[mbakke@cisco.com], Jim Muchow [jmuchow@cisco.com] Technical Coordinator: John Hufferd [hufferd@us.ibm.com] with copy to myself [erodrigu@brocade.com], David Black [black_david@emc.com] and John Hufferd[hufferd@us.ibm.com] Technical issues need to be discussed and resolved on the mailing list. Thanks, Elizabeth Rodriguez IPS co-chair ------_=_NextPart_001_01C26FAB.EF2A4210 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable IPS WG Last call on "Definitions of Managed Objects for = User Identity Authentication"

All,

We would like to announce IPS WG last call on the = draft "Definitions of Managed Objects for User Identity = Authentication".

The last call period is for two weeks, ending at 5pm = EST on Wednesday, October 23.

Draft: http://www.ietf.org/internet-drafts/draft-ietf-ips-aut= h-mib-02.txt

Editorial comments may be directly sent to the = editor/authors of the document --
Editor: Mark Bakke[mbakke@cisco.com]
Authors: Mark Bakke[mbakke@cisco.com],
         Jim = Muchow [jmuchow@cisco.com]
Technical Coordinator: John Hufferd = [hufferd@us.ibm.com]
         =
with copy to myself [erodrigu@brocade.com], David = Black [black_david@emc.com] and John Hufferd[hufferd@us.ibm.com]

Technical issues need to be discussed and resolved on = the mailing list.

Thanks,

Elizabeth Rodriguez
IPS co-chair




------_=_NextPart_001_01C26FAB.EF2A4210-- From owner-ips@ece.cmu.edu Wed Oct 9 12:34:06 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24750 for ; Wed, 9 Oct 2002 12:34:06 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g99FrBP03507 for ips-outgoing; Wed, 9 Oct 2002 11:53:11 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from hammer.brocade.com ([63.121.140.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g99Fr6o03498 for ; Wed, 9 Oct 2002 11:53:07 -0400 (EDT) Received: from hq-ex-c3.brocade.com (hq-ex-c3.brocade.com [192.168.126.211]) by hammer.brocade.com (8.11.3/8.11.3) with ESMTP id g99Fqvi23092 for ; Wed, 9 Oct 2002 08:52:57 -0700 (PDT) Received: by hq-ex-c3.brocade.com with Internet Mail Service (5.5.2653.19) id <4LH1NQZ9>; Wed, 9 Oct 2002 08:52:57 -0700 Message-ID: From: Elizabeth Rodriguez To: ips@ece.cmu.edu Subject: IPS WG Last call on "Definitions of Managed Objects for iSCSI" Date: Wed, 9 Oct 2002 08:52:51 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C26FAB.EC31C290" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C26FAB.EC31C290 Content-Type: text/plain; charset="iso-8859-1" All, We would like to announce IPS WG last call on the draft "Definitions of Managed Objects for iSCSI". The last call period is for two weeks, ending at 5pm EST on Wednesday, October 23. Draft: http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-mib-06.txt Editorial comments may be directly sent to the editor/authors of the document -- Editor: Mark Bakke[mbakke@cisco.com] Authors: Mark Bakke[mbakke@cisco.com], Marjorie Krueger [marjorie_krueger@hp.com] Tom Sweeney [rf42tpme@us.ibm.com] Jim Muchow [jmuchow@cisco.com] Technical Coordinator: John Hufferd [hufferd@us.ibm.com] with copy to myself [erodrigu@brocade.com], David Black [black_david@emc.com] and John Hufferd[hufferd@us.ibm.com] Technical issues need to be discussed and resolved on the mailing list. Thanks, Elizabeth Rodriguez IPS co-chair ------_=_NextPart_001_01C26FAB.EC31C290 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable IPS WG Last call on "Definitions of Managed Objects for = iSCSI"

All,

We would like to announce IPS WG last call on the = draft "Definitions of Managed Objects for iSCSI".
The last call period is for two weeks, ending at 5pm = EST on Wednesday, October 23.

Draft: http://www.ietf.org/internet-drafts/draft-ietf-ips-isc= si-mib-06.txt

Editorial comments may be directly sent to the = editor/authors of the document --
Editor: Mark Bakke[mbakke@cisco.com]
Authors: Mark Bakke[mbakke@cisco.com],
         = Marjorie Krueger [marjorie_krueger@hp.com]
         Tom = Sweeney [rf42tpme@us.ibm.com]
         Jim = Muchow [jmuchow@cisco.com]
Technical Coordinator: John Hufferd = [hufferd@us.ibm.com]
         =
with copy to myself [erodrigu@brocade.com], David = Black [black_david@emc.com] and John Hufferd[hufferd@us.ibm.com]

Technical issues need to be discussed and resolved on = the mailing list.

Thanks,

Elizabeth Rodriguez
IPS co-chair


------_=_NextPart_001_01C26FAB.EC31C290-- From owner-ips@ece.cmu.edu Wed Oct 9 12:36:57 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24823 for ; Wed, 9 Oct 2002 12:36:57 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g99G1OO04190 for ips-outgoing; Wed, 9 Oct 2002 12:01:24 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from hammer.brocade.com ([63.121.140.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g99G1Mo04185 for ; Wed, 9 Oct 2002 12:01:22 -0400 (EDT) Received: from hq-ex-c2.brocade.com (hq-ex-c2.brocade.com [192.168.126.35]) by hammer.brocade.com (8.11.3/8.11.3) with ESMTP id g99G1Hi24711 for ; Wed, 9 Oct 2002 09:01:17 -0700 (PDT) Received: by hq-ex-c2.brocade.com with Internet Mail Service (5.5.2653.19) id <4LH16P4V>; Wed, 9 Oct 2002 09:01:17 -0700 Message-ID: From: Elizabeth Rodriguez To: ips@ece.cmu.edu Subject: IPS-All: Reminder -- WG last call on iSNS and Stringprep drafts c omplete on Oct 13 @ 5pm EST Date: Wed, 9 Oct 2002 09:01:13 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C26FAD.17D42680" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C26FAD.17D42680 Content-Type: text/plain; charset="iso-8859-1" All, Just a quick reminder that the iSNS and Stringprep drafts are in WG last call, which will complete this Sunday at 5pm EST. All editorial comments may be sent directly to the Editor/authors of the document, with copy to the WG chairs and Technical Coordinator. All Technical comments must be discussed directly on the mailing list. iSNS draft: http://www.ietf.org/internet-drafts/draft-ietf-ips-isns-13.txt StringPrep draft: http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-string-prep-02.txt For a brief description of the drafts, see http://www.ietf.org/ids.by.wg/ips.html Thanks, Elizabeth Rodriguez ------_=_NextPart_001_01C26FAD.17D42680 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable IPS-All: Reminder -- WG last call on iSNS and Stringprep drafts = complete on Oct 13 @ 5pm EST

All,

Just a quick reminder that the iSNS = and Stringprep drafts are in WG last call, which will complete this = Sunday at 5pm EST.

All editorial comments may be sent = directly to the Editor/authors of the document, with copy to the WG = chairs and Technical Coordinator.

All Technical comments must be = discussed directly on the mailing list.

iSNS draft: http://www.ietf.org/internet-drafts/draft-ietf-ips-isn= s-13.txt
StringPrep draft: http://www.ietf.org/internet-drafts/draft-ietf-ips-isc= si-string-prep-02.txt

For a brief description of the drafts, = see http://www.ietf.org/ids.by.wg/ips.html

Thanks,

Elizabeth Rodriguez

------_=_NextPart_001_01C26FAD.17D42680-- From owner-ips@ece.cmu.edu Wed Oct 9 14:51:59 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29401 for ; Wed, 9 Oct 2002 14:51:59 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g99I7uL14391 for ips-outgoing; Wed, 9 Oct 2002 14:07:56 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from erie.mcdata.com (mcjekyll.mcdata.com [144.49.6.25]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g99I7so14386 for ; Wed, 9 Oct 2002 14:07:54 -0400 (EDT) Received: by erie.mcdata.com with Internet Mail Service (5.5.2653.19) id ; Wed, 9 Oct 2002 12:09:49 -0600 Message-ID: From: Anil Rijhsinghani To: "'Elizabeth Rodriguez'" , roweber@acm.org, ips@ece.cmu.edu Cc: Dave Peterson Subject: RE: IPS-ALL: iSNS WG Last Call Date: Wed, 9 Oct 2002 12:09:37 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C26FBF.07A00C4C" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C26FBF.07A00C4C Content-Type: text/plain; charset="iso-8859-1" Elizabeth: Fair enough.. given the late stage of the various drafts, I'll bring forward the proposal as a future work item. Regards, Anil -----Original Message----- From: Elizabeth Rodriguez [mailto:erodrigu@brocade.com] Sent: Wednesday, October 09, 2002 10:19 AM To: Anil Rijhsinghani; roweber@acm.org; ips@ece.cmu.edu Cc: Dave Peterson Subject: RE: IPS-ALL: iSNS WG Last Call Chair hat on -- From Josh's email, it appears that should FCIP need iSNS support in the future, it will be fairly easy to add support to iSNS. If the protocol numbers are assigned by IANA (which they probably should be), should FCIP desire iSNS support it can request a protocol number from IANA at that time. FCIP has completed working group last call, and iSNS is now in WG last call. Instead of modifying these drafts directly at this stage to include FCIP support, an new draft on this topic should be prepared and presented to the working group. A discussion can then be held to determine if there is interests in such a draft being adopted by the WG as a work group item. There are some statements in the FCIP draft that state that SLPv2 is the only discovery mechanism supported, and iSNS only mentions support for iSCSI and iFCP in many places throughout the document. The effect of the new draft would in effect augment both the iSNS and FCIP draft to support iSNS. Thanks, Elizabeth Rodriguez IPS WG co-chair -----Original Message----- From: Anil Rijhsinghani [ mailto:anil.rijhsinghani@mcdata.com ] Sent: Wednesday, October 09, 2002 7:05 AM To: 'roweber@acm.org'; ips@ece.cmu.edu Cc: Dave Peterson Subject: RE: IPS-ALL: iSNS WG Last Call While we did agree to use SLPv2 for dynamic discovery in FCIP, there was no agreement that no other protocol can be used. Specifying FCIP support in iSNS requires no change to the FCIP draft (other than perhaps a reference). Joshua: allow us to take this discussion back into the FCIP group. We will get back to you on this. Regards, Anil -----Original Message----- From: Ralph Weber [ mailto:ralphoweber@compuserve.com ] Sent: Wednesday, October 09, 2002 5:09 AM To: ips@ece.cmu.edu Cc: Dave Peterson Subject: Re: IPS-ALL: iSNS WG Last Call Dave is 100% correct. During the development of FCIP the issue of discovery mechanisms was considered in detail. The decision was that iSNS is too heavy weight a discovery protocol for FCIP needs and SLPv2 was chosen and documented as the best fit solution. Suggesting in iSNS that there is a relationship with FCIP will lead to confusion when no supporting discussion can be found in the FCIP RFC. No changes are required in iSNS. Thanks. .Ralph Dave Peterson wrote: > I object. > The FCIP group discussed this issue and agreed that SLPv2 was to be used for > FCIP Entity discovery. > As such, the recently completed FCIP draft contains no mention of iSNS > support. > A single dynamic discovery protocol is needed and its SLPv2. > > ...dap > > > -----Original Message----- > > From: owner-ips@ece.cmu.edu [ mailto:owner-ips@ece.cmu.edu ]On Behalf Of > > Anil Rijhsinghani > > Sent: Tuesday, October 08, 2002 10:05 AM > > To: 'Joshua Tseng'; ips@ece.cmu.edu > > Subject: RE: IPS-ALL: iSNS WG Last Call > > > > > > Joshua: > > > > Unless there are objections, it would be useful to add those hooks as an > > option. In an environment where both FCIP and iSCSI are in use, > > and iSNS is > > available, it may help to keep down the number of discovery protocols that > > need to be managed by the user. Either SLP could be used for > > both, or iSNS. > > > > Anil > > > > -----Original Message----- > > From: Joshua Tseng [ mailto:jtseng@NishanSystems.com ] > > Sent: Monday, October 07, 2002 4:08 PM > > To: Anil Rijhsinghani; Black_David@emc.com; ips@ece.cmu.edu > > Subject: RE: IPS-ALL: iSNS WG Last Call > > > > > > Anil, > > > > It would be very easy, especially now that Portals can be > > members of Discovery Domains. All we would need to do is > > to add a new Entity Protocol type (FCIP = 3). FCIP connectivity > > would then be established based on Portal membership in > > Discovery Domains. Other than that, we would just new narative > > text describing how you use iSNS to set up FCIP sessions. > > > > Please let me know if this is desireable for the FCIP folks. > > > > Josh > > > > > -----Original Message----- > > > From: Anil Rijhsinghani [ mailto:anil.rijhsinghani@mcdata.com ] > > > Sent: Monday, October 07, 2002 1:43 PM > > > To: 'Black_David@emc.com'; ips@ece.cmu.edu > > > Subject: RE: IPS-ALL: iSNS WG Last Call > > > > > > > > > How hard would it be to add hooks for optional FCIP support > > > in iSNS? It > > > currently supports only iFCP and iSCSI. > > > > > > Regards, > > > Anil > > > > > > -----Original Message----- > > > From: Black_David@emc.com [ mailto:Black_David@emc.com ] > > > Sent: Friday, September 27, 2002 10:07 AM > > > To: ips@ece.cmu.edu > > > Subject: IPS-ALL: iSNS WG Last Call > > > > > > > > > All, > > > > > > We would like to announce IPS Working Group Last call for > > > the Internet Storage Name Service (iSNS). > > > > > > Details: > > > > > > Document: Internet Storage Name Service (iSNS) > > > URL: http://www.ietf.org/internet-drafts/draft-ietf-ips-isns-13.txt > > > Note: There are formatting (line length) problems with this draft. > > > It may get updated to -14 shortly to correct them without > > > change to its content. > > > > > > Last call period: 2 Weeks > > > Submit comments no later than: Sunday, October 13, 2002 at 5pm EST > > > Editor: Josh Tseng > > > > > > Please submit editorial comments directly to Josh, with copy > > > to David Black > > > (black_david@emc.com), and Elizabeth Rodriguez(erodrigu@brocade.com) > > > Submit technical comments to the IPS mailing list (ips@ece.cmu.edu) > > > > > > Editorial comments may be resolved directly by the editor of > > > the document, > > > but any technical issues must be discussed on the IPS reflector. > > > > > > Thanks, > > > David Black & Elizabeth Rodriguez > > > IPS co-chairs > > > > > > --------------------------------------------------- > > > David L. Black, Senior Technologist > > > EMC Corporation, 42 South St., Hopkinton, MA 01748 > > > +1 (508) 249-6449 FAX: +1 (508) 497-8018 > > > black_david@emc.com Mobile: +1 (978) 394-7754 > > > --------------------------------------------------- > > > > > > > > > =========================================================== > > > Notice > > > > > > All information transmitted hereby is intended only for the use of the > > > addressee(s) named above and may contain confidential and privileged > > > information. Any unauthorized review, use, disclosure or > > > distribution is > > > prohibited. If the reader of this message is not the > > > intended recipient(s) > > > or the employee or agent responsible for delivering the message to the > > > intended recipient(s), you may not distribute or copy this > > > communication to > > > another. Anyone who receives this communication in error > > > should notify us > > > immediately by telephone and mail the original message to us > > > at the above > > > address and destroy all copies. > > > =========================================================== > > > > > > > > > =========================================================== > > Notice > > > > All information transmitted hereby is intended only for the use of the > > addressee(s) named above and may contain confidential and privileged > > information. Any unauthorized review, use, disclosure or distribution is > > prohibited. If the reader of this message is not the intended > > recipient(s) > > or the employee or agent responsible for delivering the message to the > > intended recipient(s), you may not distribute or copy this > > communication to > > another. Anyone who receives this communication in error should notify us > > immediately by telephone and mail the original message to us at the above > > address and destroy all copies. > > =========================================================== =========================================================== Notice All information transmitted hereby is intended only for the use of the addressee(s) named above and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If the reader of this message is not the intended recipient(s) or the employee or agent responsible for delivering the message to the intended recipient(s), you may not distribute or copy this communication to another. Anyone who receives this communication in error should notify us immediately by telephone and mail the original message to us at the above address and destroy all copies. =========================================================== =========================================================== Notice All information transmitted hereby is intended only for the use of the addressee(s) named above and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If the reader of this message is not the intended recipient(s) or the employee or agent responsible for delivering the message to the intended recipient(s), you may not distribute or copy this communication to another. Anyone who receives this communication in error should notify us immediately by telephone and mail the original message to us at the above address and destroy all copies. =========================================================== ------_=_NextPart_001_01C26FBF.07A00C4C Content-Type: text/html; charset="iso-8859-1" RE: IPS-ALL: iSNS WG Last Call
Elizabeth:
 
Fair enough.. given the late stage of the various drafts, I'll bring forward the proposal as a future work item.
 
Regards,
Anil
-----Original Message-----
From: Elizabeth Rodriguez [mailto:erodrigu@brocade.com]
Sent: Wednesday, October 09, 2002 10:19 AM
To: Anil Rijhsinghani; roweber@acm.org; ips@ece.cmu.edu
Cc: Dave Peterson
Subject: RE: IPS-ALL: iSNS WG Last Call

Chair hat on --

From Josh's email, it appears that should FCIP need iSNS support in the future, it will be fairly easy to add support to iSNS.  If the protocol numbers are assigned by IANA (which they probably should be), should FCIP desire iSNS support it can request a protocol number from IANA at that time.

FCIP has completed working group last call, and iSNS is now in WG last call. 
Instead of modifying these drafts directly at this stage to include FCIP support, an new draft on this topic should be prepared and presented to the working group.  A discussion can then be held to determine if there is interests in such a draft being adopted by the WG as a work group item. 

There are some statements in the FCIP draft that state that SLPv2 is the only discovery mechanism supported, and iSNS only mentions support for iSCSI and iFCP in many places throughout the document.  The effect of the new draft would in effect augment both the iSNS and FCIP draft to support iSNS.

Thanks,

Elizabeth Rodriguez
IPS WG co-chair
-----Original Message-----
From: Anil Rijhsinghani [mailto:anil.rijhsinghani@mcdata.com]
Sent: Wednesday, October 09, 2002 7:05 AM
To: 'roweber@acm.org'; ips@ece.cmu.edu
Cc: Dave Peterson
Subject: RE: IPS-ALL: iSNS WG Last Call


While we did agree to use SLPv2 for dynamic discovery in FCIP, there was no
agreement that no other protocol can be used. Specifying FCIP support in
iSNS requires no change to the FCIP draft (other than perhaps a reference).

Joshua: allow us to take this discussion back into the FCIP group. We will
get back to you on this.

Regards,
Anil

-----Original Message-----
From: Ralph Weber [mailto:ralphoweber@compuserve.com]
Sent: Wednesday, October 09, 2002 5:09 AM
To: ips@ece.cmu.edu
Cc: Dave Peterson
Subject: Re: IPS-ALL: iSNS WG Last Call


Dave is 100% correct.

During the development of FCIP the issue of discovery mechanisms
was considered in detail. The decision was that iSNS is too heavy
weight a discovery protocol for FCIP needs and SLPv2 was chosen
and documented as the best fit solution.

Suggesting in iSNS that there is a relationship with FCIP will
lead to confusion when no supporting discussion can be found in
the FCIP RFC.

No changes are required in iSNS.

Thanks.

.Ralph

Dave Peterson wrote:

> I object.
> The FCIP group discussed this issue and agreed that SLPv2 was to be used
for
> FCIP Entity discovery.
> As such, the recently completed FCIP draft contains no mention of iSNS
> support.
> A single dynamic discovery protocol is needed and its SLPv2.
>
> ...dap
>
> > -----Original Message-----
> > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> > Anil Rijhsinghani
> > Sent: Tuesday, October 08, 2002 10:05 AM
> > To: 'Joshua Tseng'; ips@ece.cmu.edu
> > Subject: RE: IPS-ALL: iSNS WG Last Call
> >
> >
> > Joshua:
> >
> > Unless there are objections, it would be useful to add those hooks as an
> > option. In an environment where both FCIP and iSCSI are in use,
> > and iSNS is
> > available, it may help to keep down the number of discovery protocols
that
> > need to be managed by the user. Either SLP could be used for
> > both, or iSNS.
> >
> > Anil
> >
> > -----Original Message-----
> > From: Joshua Tseng [mailto:jtseng@NishanSystems.com]
> > Sent: Monday, October 07, 2002 4:08 PM
> > To: Anil Rijhsinghani; Black_David@emc.com; ips@ece.cmu.edu
> > Subject: RE: IPS-ALL: iSNS WG Last Call
> >
> >
> > Anil,
> >
> > It would be very easy, especially now that Portals can be
> > members of Discovery Domains.  All we would need to do is
> > to add a new Entity Protocol type (FCIP = 3).  FCIP connectivity
> > would then be established based on Portal membership in
> > Discovery Domains.  Other than that, we would just new narative
> > text describing how you use iSNS to set up FCIP sessions.
> >
> > Please let me know if this is desireable for the FCIP folks.
> >
> > Josh
> >
> > > -----Original Message-----
> > > From: Anil Rijhsinghani [mailto:anil.rijhsinghani@mcdata.com]
> > > Sent: Monday, October 07, 2002 1:43 PM
> > > To: 'Black_David@emc.com'; ips@ece.cmu.edu
> > > Subject: RE: IPS-ALL: iSNS WG Last Call
> > >
> > >
> > > How hard would it be to add hooks for optional FCIP support
> > > in iSNS? It
> > > currently supports only iFCP and iSCSI.
> > >
> > > Regards,
> > > Anil
> > >
> > > -----Original Message-----
> > > From: Black_David@emc.com [mailto:Black_David@emc.com]
> > > Sent: Friday, September 27, 2002 10:07 AM
> > > To: ips@ece.cmu.edu
> > > Subject: IPS-ALL: iSNS WG Last Call
> > >
> > >
> > > All,
> > >
> > > We would like to announce IPS Working Group Last call for
> > > the Internet Storage Name Service (iSNS).
> > >
> > > Details:
> > >
> > > Document: Internet Storage Name Service (iSNS)
> > > URL: http://www.ietf.org/internet-drafts/draft-ietf-ips-isns-13.txt
> > > Note: There are formatting (line length) problems with this draft.
> > >     It may get updated to -14 shortly to correct them without
> > >     change to its content.
> > >
> > > Last call period: 2 Weeks
> > > Submit comments no later than: Sunday, October 13, 2002 at 5pm EST
> > > Editor:  Josh Tseng <jtseng@nishansystems.com>
> > >
> > > Please submit editorial comments directly to Josh, with copy
> > > to David Black
> > > (black_david@emc.com), and Elizabeth Rodriguez(erodrigu@brocade.com)
> > > Submit technical comments to the IPS mailing list (ips@ece.cmu.edu)
> > >
> > > Editorial comments may be resolved directly by the editor of
> > > the document,
> > > but any technical issues must be discussed on the IPS reflector.
> > >
> > > Thanks,
> > > David Black & Elizabeth Rodriguez
> > > IPS co-chairs
> > >
> > > ---------------------------------------------------
> > > David L. Black, Senior Technologist
> > > EMC Corporation, 42 South St., Hopkinton, MA  01748
> > > +1 (508) 249-6449            FAX: +1 (508) 497-8018
> > > black_david@emc.com       Mobile: +1 (978) 394-7754
> > > ---------------------------------------------------
> > >
> > >
> > > ===========================================================
> > > Notice
> > >
> > > All information transmitted hereby is intended only for the use of the
> > > addressee(s) named above and may contain confidential and privileged
> > > information.  Any unauthorized review, use, disclosure or
> > > distribution is
> > > prohibited.  If the reader of this message is not the
> > > intended recipient(s)
> > > or the employee or agent responsible for delivering the message to the
> > > intended recipient(s), you may not distribute or copy this
> > > communication to
> > > another.  Anyone who receives this communication in error
> > > should notify us
> > > immediately by telephone and mail the original message to us
> > > at the above
> > > address and destroy all copies.
> > > ===========================================================
> > >
> >
> >
> > ===========================================================
> > Notice
> >
> > All information transmitted hereby is intended only for the use of the
> > addressee(s) named above and may contain confidential and privileged
> > information.  Any unauthorized review, use, disclosure or distribution
is
> > prohibited.  If the reader of this message is not the intended
> > recipient(s)
> > or the employee or agent responsible for delivering the message to the
> > intended recipient(s), you may not distribute or copy this
> > communication to
> > another.  Anyone who receives this communication in error should notify
us
> > immediately by telephone and mail the original message to us at the
above
> > address and destroy all copies.
> > ===========================================================




===========================================================
Notice

All information transmitted hereby is intended only for the use of the
addressee(s) named above and may contain confidential and privileged
information.  Any unauthorized review, use, disclosure or distribution is
prohibited.  If the reader of this message is not the intended recipient(s)
or the employee or agent responsible for delivering the message to the
intended recipient(s), you may not distribute or copy this communication to
another.  Anyone who receives this communication in error should notify us
immediately by telephone and mail the original message to us at the above
address and destroy all copies.
===========================================================



===========================================================

Notice


All information transmitted hereby is intended only for the use of the addressee(s) named above and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If the reader of this message is not the intended recipient(s) or the employee or agent responsible for delivering the message to the intended recipient(s), you may not distribute or copy this communication to another. Anyone who receives this communication in error should notify us immediately by telephone and mail the original message to us at the above address and destroy all copies.

===========================================================

------_=_NextPart_001_01C26FBF.07A00C4C-- From owner-ips@ece.cmu.edu Wed Oct 9 18:18:13 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06363 for ; Wed, 9 Oct 2002 18:18:13 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g99LjUJ01505 for ips-outgoing; Wed, 9 Oct 2002 17:45:30 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.ivivity.com ([64.238.111.99]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g99LjRo01494 for ; Wed, 9 Oct 2002 17:45:27 -0400 (EDT) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id <414L52CW>; Wed, 9 Oct 2002 17:45:26 -0400 Message-ID: From: Eddy Quicksall To: ips@ece.cmu.edu Cc: Bill Ortega Subject: COLD vs WARM reset Date: Wed, 9 Oct 2002 17:45:19 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk The spec says: The target MUST treat the TARGET COLD RESET function additionally as a power on event My question is -- do I give a 06/29/01 for that even though it is not really a Power ON? SAM does not seem to address that (or at least I don't see it). It would seem that it may be appropriate to add the expected unit attention key/asc/acsq for WARM and COLD to the table in section "9.4.7.2 Sense Data". Eddy mailto: Eddy_Quicksall@iVivity.com From owner-ips@ece.cmu.edu Wed Oct 9 19:06:50 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07237 for ; Wed, 9 Oct 2002 19:06:49 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g99Mbkq04935 for ips-outgoing; Wed, 9 Oct 2002 18:37:46 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from esply02.cnt.com ([139.93.128.22]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g99Mbho04929 for ; Wed, 9 Oct 2002 18:37:43 -0400 (EDT) Received: by esply02.cnt.com with Internet Mail Service (5.5.2653.19) id ; Wed, 9 Oct 2002 17:37:38 -0500 Message-ID: <3C7122FAF06DD5118ED60050047336482632CF@ESPLY01> From: Michael Schoberg To: "IPS Reflector (E-mail)" Subject: iSCSI: Parameter negotiation Q Date: Wed, 9 Oct 2002 17:37:33 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C26FE4.75CC11D0" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C26FE4.75CC11D0 Content-Type: text/plain; charset="iso-8859-1" 11.14 FirstBurstLength Use: LO Senders: Initiator and Target Scope: SW Irrelevant when: SessionType=Discovery Irrelevant when: ( InitialR2T=Yes and ImmediateData=No ) FirstBurstLength= Default is 65536 (64 Kbytes). Result function is Minimum. The initiator and target negotiate the maximum amount in bytes of unsolicited data an iSCSI initiator may send to the target during the execution of a single SCSI command. This covers the immediate data (if any) and the sequence of unsolicited Data-Out PDUs (if any) that follow the command. FirstBurstLength MUST NOT exceed MaxBurstLength. I understand we're past the revision stage on iSCSI, but I'm confused by some of the negotiation logic. If FirstBurstLength only relates to the number of bytes Initiator->Target, why would there be a need to negotiate the value versus just having the target declare a maximum (if not equal to the default)? Thanks. ------_=_NextPart_001_01C26FE4.75CC11D0 Content-Type: text/html; charset="iso-8859-1"

11.14  FirstBurstLength

   Use: LO
   Senders: Initiator and Target
   Scope: SW
   Irrelevant when: SessionType=Discovery
   Irrelevant when: ( InitialR2T=Yes and ImmediateData=No )

   FirstBurstLength=<numerical-value-512-to-(2**24-1)>

   Default is 65536 (64 Kbytes).
   Result function is Minimum.

   The initiator and target negotiate the maximum amount in bytes of
   unsolicited data an iSCSI initiator may send to the target during the
   execution of a single SCSI command. This covers the immediate data
   (if any) and the sequence of unsolicited Data-Out PDUs (if any) that
   follow the command.

   FirstBurstLength MUST NOT exceed MaxBurstLength.

I understand we're past the revision stage on iSCSI, but I'm confused by some of the negotiation logic.  If FirstBurstLength only relates to the number of bytes Initiator->Target, why would there be a need to negotiate the value versus just having the target declare a maximum (if not equal to the default)?

Thanks.

------_=_NextPart_001_01C26FE4.75CC11D0-- From owner-ips@ece.cmu.edu Wed Oct 9 19:54:43 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07976 for ; Wed, 9 Oct 2002 19:54:42 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g99NPxE07843 for ips-outgoing; Wed, 9 Oct 2002 19:25:59 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.ivivity.com ([64.238.111.99]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g99NPwo07839 for ; Wed, 9 Oct 2002 19:25:58 -0400 (EDT) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id <414L521T>; Wed, 9 Oct 2002 19:25:58 -0400 Message-ID: From: Sanjay Goyal To: "'IPS Reflector (E-mail)'" Subject: Recall: iSCSI: Parameter negotiation Q Date: Wed, 9 Oct 2002 19:25:55 -0400 Expiry-Date: Fri, 11 Oct 2002 19:25:34 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ips@ece.cmu.edu Precedence: bulk Sanjay Goyal would like to recall the message, "iSCSI: Parameter negotiation Q". From owner-ips@ece.cmu.edu Thu Oct 10 02:15:03 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23455 for ; Thu, 10 Oct 2002 02:15:03 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g9A5ZUh27268 for ips-outgoing; Thu, 10 Oct 2002 01:35:30 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [194.196.100.235]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g9A5ZSo27261; Thu, 10 Oct 2002 01:35:28 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g9A5ZDQq061492; Thu, 10 Oct 2002 07:35:13 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g9A5ZBPs086530; Thu, 10 Oct 2002 07:35:12 +0200 In-Reply-To: <3C7122FAF06DD5118ED60050047336482632CF@ESPLY01> To: Michael Schoberg Cc: "IPS Reflector (E-mail)" , owner-ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI: Parameter negotiation Q X-Mailer: Lotus Notes Release 6.0 September 26, 2002 From: "Julian Satran" Message-ID: Date: Thu, 10 Oct 2002 07:35:09 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 10/10/2002 07:35:11, Serialize complete at 10/10/2002 07:35:11 Content-Type: multipart/alternative; boundary="=_alternative 001E0992C2256C4E_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 001E0992C2256C4E_= Content-Type: text/plain; charset="US-ASCII" Because the initiator may not want to send that much/little. Julo Michael Schoberg Sent by: owner-ips@ece.cmu.edu 10/10/02 00:37 To: "IPS Reflector (E-mail)" cc: Subject: iSCSI: Parameter negotiation Q 11.14 FirstBurstLength Use: LO Senders: Initiator and Target Scope: SW Irrelevant when: SessionType=Discovery Irrelevant when: ( InitialR2T=Yes and ImmediateData=No ) FirstBurstLength= Default is 65536 (64 Kbytes). Result function is Minimum. The initiator and target negotiate the maximum amount in bytes of unsolicited data an iSCSI initiator may send to the target during the execution of a single SCSI command. This covers the immediate data (if any) and the sequence of unsolicited Data-Out PDUs (if any) that follow the command. FirstBurstLength MUST NOT exceed MaxBurstLength. I understand we're past the revision stage on iSCSI, but I'm confused by some of the negotiation logic. If FirstBurstLength only relates to the number of bytes Initiator->Target, why would there be a need to negotiate the value versus just having the target declare a maximum (if not equal to the default)? Thanks. --=_alternative 001E0992C2256C4E_= Content-Type: text/html; charset="US-ASCII"
Because the initiator may not want to send that much/little.

Julo


Michael Schoberg <michael_schoberg@cnt.com>
Sent by: owner-ips@ece.cmu.edu

10/10/02 00:37

       
        To:        "IPS Reflector (E-mail)" <ips@ece.cmu.edu>
        cc:        
        Subject:        iSCSI: Parameter negotiation Q

       


11.14  FirstBurstLength

  Use: LO
  Senders: Initiator and Target
  Scope: SW
  Irrelevant when: SessionType=Discovery
  Irrelevant when: ( InitialR2T=Yes and ImmediateData=No )

  FirstBurstLength=<numerical-value-512-to-(2**24-1)>

  Default is 65536 (64 Kbytes).
  Result function is Minimum.

  The initiator and target negotiate the maximum amount in bytes of
  unsolicited data an iSCSI initiator may send to the target during the
  execution of a single SCSI command. This covers the immediate data
  (if any) and the sequence of unsolicited Data-Out PDUs (if any) that
  follow the command.

  FirstBurstLength MUST NOT exceed MaxBurstLength.

I understand we're past the revision stage on iSCSI, but I'm confused by some of the negotiation logic.  If FirstBurstLength only relates to the number of bytes Initiator->Target, why would there be a need to negotiate the value versus just having the target declare a maximum (if not equal to the default)?

Thanks.

--=_alternative 001E0992C2256C4E_=-- From owner-ips@ece.cmu.edu Thu Oct 10 09:04:12 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02112 for ; Thu, 10 Oct 2002 09:04:12 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g9ACa4U00550 for ips-outgoing; Thu, 10 Oct 2002 08:36:04 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.ivivity.com ([64.238.111.99]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g9ACa2o00546 for ; Thu, 10 Oct 2002 08:36:02 -0400 (EDT) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id <414L52KH>; Thu, 10 Oct 2002 08:36:02 -0400 Message-ID: From: Eddy Quicksall To: Julian Satran Cc: ips@ece.cmu.edu Subject: RE: iSCSI: Logical Unit Reset Date: Thu, 10 Oct 2002 08:35:52 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk What I was talking about is the blanket statement that is in the spec. The statement is technically wrong because it says "Task management requests must act on all the commands having a CmdSN lower than the task management CmdSN". As Tony pointed out, it would be more precise to say "... must act on all the commands in the session having a CmdSN ..." Eddy -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Wednesday, October 09, 2002 9:27 AM To: Eddy Quicksall Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: Re: iSCSI: Logical Unit Reset As other related protocols we preferred to be mute on reset. The side effects of reset are well understood and it has been made optional in T10. Julo Eddy Quicksall Sent by: owner-ips@ece.cmu.edu 08/10/02 16:08 To: ips@ece.cmu.edu cc: Subject: iSCSI: Logical Unit Reset Section 9.5.1 says: Task management requests must act on all the commands having a CmdSN lower than the task management CmdSN. But a Logical Unit Reset, Target [WARM | COLD] Reset and Clear Task Set w/TST=0 applies to all initiators for the Target or Target/LUN. Since the initiator that issued the TMF knows nothing about the CmdSN's of other initiators, how is this handled for the other sessions? One thing that can be done is to consider that the session that issued the TMF is synchronized only with itself and therefore its TMF would apply to all CmdSN's on the other sessions. A statement to this effect should probably be added to 9.5.1. Eddy mailto: Eddy_Quicksall@iVivity.com From owner-ips@ece.cmu.edu Thu Oct 10 09:06:40 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02223 for ; Thu, 10 Oct 2002 09:06:35 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g9ACS5s00025 for ips-outgoing; Thu, 10 Oct 2002 08:28:05 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.ivivity.com ([64.238.111.99]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g9ACS2o00016 for ; Thu, 10 Oct 2002 08:28:03 -0400 (EDT) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id <414L52KD>; Thu, 10 Oct 2002 08:28:02 -0400 Message-ID: From: Eddy Quicksall To: Michael Schoberg , "IPS Reflector (E-mail)" Subject: RE: iSCSI: Parameter negotiation Q Date: Thu, 10 Oct 2002 08:27:52 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C27058.73B61160" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C27058.73B61160 Content-Type: text/plain; charset="iso-8859-1" If the target were allowed to just declare a maximum, the initiator would be required to always send that amount when sending non-immediate unsolicited. But maybe it would not be able to. See 9.3.4: If the Expected Data Transfer Length is higher than the FirstBurstLength (the negotiated maximum amount of unsolicited data the target will accept), the initiator MUST send the maximum amount of unsolicited data OR ONLY the immediate data, if any. Eddy -----Original Message----- From: Michael Schoberg [mailto:michael_schoberg@cnt.com] Sent: Wednesday, October 09, 2002 6:38 PM To: IPS Reflector (E-mail) Subject: iSCSI: Parameter negotiation Q 11.14 FirstBurstLength Use: LO Senders: Initiator and Target Scope: SW Irrelevant when: SessionType=Discovery Irrelevant when: ( InitialR2T=Yes and ImmediateData=No ) FirstBurstLength= Default is 65536 (64 Kbytes). Result function is Minimum. The initiator and target negotiate the maximum amount in bytes of unsolicited data an iSCSI initiator may send to the target during the execution of a single SCSI command. This covers the immediate data (if any) and the sequence of unsolicited Data-Out PDUs (if any) that follow the command. FirstBurstLength MUST NOT exceed MaxBurstLength. I understand we're past the revision stage on iSCSI, but I'm confused by some of the negotiation logic. If FirstBurstLength only relates to the number of bytes Initiator->Target, why would there be a need to negotiate the value versus just having the target declare a maximum (if not equal to the default)? Thanks. ------_=_NextPart_001_01C27058.73B61160 Content-Type: text/html; charset="iso-8859-1"

If the target were allowed to just declare a maximum, the initiator would be required to always send that amount when sending non-immediate unsolicited. But maybe it would not be able to.
 
See 9.3.4:
If the Expected Data Transfer Length is higher than the FirstBurstLength (the negotiated maximum amount of unsolicited data the target will accept), the initiator MUST send the maximum amount of unsolicited data OR ONLY the immediate data, if any.
 
Eddy
-----Original Message-----
From: Michael Schoberg [mailto:michael_schoberg@cnt.com]
Sent: Wednesday, October 09, 2002 6:38 PM
To: IPS Reflector (E-mail)
Subject: iSCSI: Parameter negotiation Q

11.14  FirstBurstLength

   Use: LO
   Senders: Initiator and Target
   Scope: SW
   Irrelevant when: SessionType=Discovery
   Irrelevant when: ( InitialR2T=Yes and ImmediateData=No )

   FirstBurstLength=<numerical-value-512-to-(2**24-1)>

   Default is 65536 (64 Kbytes).
   Result function is Minimum.

   The initiator and target negotiate the maximum amount in bytes of
   unsolicited data an iSCSI initiator may send to the target during the
   execution of a single SCSI command. This covers the immediate data
   (if any) and the sequence of unsolicited Data-Out PDUs (if any) that
   follow the command.

   FirstBurstLength MUST NOT exceed MaxBurstLength.

I understand we're past the revision stage on iSCSI, but I'm confused by some of the negotiation logic.  If FirstBurstLength only relates to the number of bytes Initiator->Target, why would there be a need to negotiate the value versus just having the target declare a maximum (if not equal to the default)?

Thanks.

------_=_NextPart_001_01C27058.73B61160-- From owner-ips@ece.cmu.edu Thu Oct 10 15:59:34 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21876 for ; Thu, 10 Oct 2002 15:59:20 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g9AJONI03976 for ips-outgoing; Thu, 10 Oct 2002 15:24:23 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g99BGso14677 for ; Wed, 9 Oct 2002 07:16:54 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09994; Wed, 9 Oct 2002 07:14:47 -0400 (EDT) Message-Id: <200210091114.HAA09994@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ips@ece.cmu.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ips-fcip-mib-02.txt Date: Wed, 09 Oct 2002 07:14:47 -0400 Sender: owner-ips@ece.cmu.edu Precedence: bulk --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 : Definition of Managed Objects for FCIP Author(s) : R. Natarajan, A. Rijhsinghani Filename : draft-ietf-ips-fcip-mib-02.txt Pages : 32 Date : 2002-10-8 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular it defines objects for managing FCIP entities, as defined in [FCIP] and used in FC fabrics as described in [FCBB2]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-fcip-mib-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-fcip-mib-02.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-fcip-mib-02.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: <2002-10-8154049.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-fcip-mib-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-fcip-mib-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-8154049.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ips@ece.cmu.edu Thu Oct 10 16:00:27 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21963 for ; Thu, 10 Oct 2002 16:00:27 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g9AJLxd03760 for ips-outgoing; Thu, 10 Oct 2002 15:21:59 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from pkoning.akdesign.com (082-46-189-66.wo.cpe.charter-ne.com [66.189.46.82]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g9A0Lqo10857 for ; Wed, 9 Oct 2002 20:21:52 -0400 (EDT) Received: from pkoning.akdesign.com.equallogic.com (IDENT:pkoning@localhost [127.0.0.1]) by pkoning.akdesign.com (8.11.6/8.9.3) with ESMTP id g9A0Llq01661; Wed, 9 Oct 2002 20:21:47 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15780.51227.181407.612335@pkoning.akdesign.com> Date: Wed, 9 Oct 2002 20:21:47 -0400 From: Paul Koning To: michael_schoberg@cnt.com Cc: ips@ece.cmu.edu Subject: Re: iSCSI: Parameter negotiation Q References: <3C7122FAF06DD5118ED60050047336482632CF@ESPLY01> X-Mailer: VM 7.07 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit >>>>> "Michael" == Michael Schoberg writes: Michael> I understand we're past the revision stage on iSCSI, but I'm Michael> confused by some of the negotiation logic. If Michael> FirstBurstLength only relates to the number of bytes Michael> Initiator->Target, why would there be a need to negotiate Michael> the value versus just having the target declare a maximum Michael> (if not equal to the default)? The initiator is required to send exactly FirstBurstLength if it sends non-immediate unsolicited data (unless the total length of the write is less) -- section 2.2.4.2. The target wants to know what that length will be so it can plan buffering accordingly. Not all targets will care, but some will (that's why the rule is there). paul From owner-ips@ece.cmu.edu Thu Oct 10 18:37:07 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26133 for ; Thu, 10 Oct 2002 18:37:02 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g9AM4qA17115 for ips-outgoing; Thu, 10 Oct 2002 18:04:52 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cs.haifa.ac.il (IDENT:postfix@cs.haifa.ac.il [132.74.120.2]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g9AK7Eo07724 for ; Thu, 10 Oct 2002 16:07:14 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by cs.haifa.ac.il (Postfix) with ESMTP id A79BA2D30C; Thu, 10 Oct 2002 22:07:11 +0200 (IST) Received: from JA31 (slip-32-103-225-19.ca.us.prserv.net [32.103.225.19]) by cs.haifa.ac.il (Postfix) with ESMTP id 11D86A41E; Thu, 10 Oct 2002 20:06:44 +0000 (UTC) From: "Julian Satran" To: "'Eddy Quicksall'" Cc: , Subject: RE: iSCSI: Logical Unit Reset Date: Thu, 10 Oct 2002 22:06:05 +0200 Message-ID: <000001c27098$9327e380$1338e120@JA31> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Virus-Scanned: by AMaViS snapshot-20010714 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit The text I suggest for later is: Task management requests must act on all the commands from the same session having a CmdSN lower than the task management CmdSN. LOGICAL UNIT RESET, TARGET WARM RESET and TARGET COLD RESET may affect commands from other sessions or commands from the same session with CmdSN equal or exceeding CmdSN. -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu] On Behalf Of Eddy Quicksall Sent: 10 October, 2002 14:36 To: Julian Satran Cc: ips@ece.cmu.edu Subject: RE: iSCSI: Logical Unit Reset What I was talking about is the blanket statement that is in the spec. The statement is technically wrong because it says "Task management requests must act on all the commands having a CmdSN lower than the task management CmdSN". As Tony pointed out, it would be more precise to say "... must act on all the commands in the session having a CmdSN ..." Eddy -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Wednesday, October 09, 2002 9:27 AM To: Eddy Quicksall Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: Re: iSCSI: Logical Unit Reset As other related protocols we preferred to be mute on reset. The side effects of reset are well understood and it has been made optional in T10. Julo Eddy Quicksall Sent by: owner-ips@ece.cmu.edu 08/10/02 16:08 To: ips@ece.cmu.edu cc: Subject: iSCSI: Logical Unit Reset Section 9.5.1 says: Task management requests must act on all the commands having a CmdSN lower than the task management CmdSN. But a Logical Unit Reset, Target [WARM | COLD] Reset and Clear Task Set w/TST=0 applies to all initiators for the Target or Target/LUN. Since the initiator that issued the TMF knows nothing about the CmdSN's of other initiators, how is this handled for the other sessions? One thing that can be done is to consider that the session that issued the TMF is synchronized only with itself and therefore its TMF would apply to all CmdSN's on the other sessions. A statement to this effect should probably be added to 9.5.1. Eddy mailto: Eddy_Quicksall@iVivity.com From owner-ips@ece.cmu.edu Fri Oct 11 16:16:18 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04170 for ; Fri, 11 Oct 2002 16:16:13 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g9BJdkh16932 for ips-outgoing; Fri, 11 Oct 2002 15:39:46 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g9BBUIo10841 for ; Fri, 11 Oct 2002 07:30:18 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16801; Fri, 11 Oct 2002 07:28:11 -0400 (EDT) Message-Id: <200210111128.HAA16801@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ips@ece.cmu.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ips-fcmgmt-mib-03.txt Date: Fri, 11 Oct 2002 07:28:11 -0400 Sender: owner-ips@ece.cmu.edu Precedence: bulk --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 : Fibre Channel Management MIB Author(s) : K. McCloghrie Filename : draft-ietf-ips-fcmgmt-mib-03.txt Pages : 77 Date : 2002-10-10 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for informantion related to Fibre Channel. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-fcmgmt-mib-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-fcmgmt-mib-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ips-fcmgmt-mib-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-10-10140844.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-fcmgmt-mib-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-fcmgmt-mib-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-10140844.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ips@ece.cmu.edu Fri Oct 11 16:16:53 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04211 for ; Fri, 11 Oct 2002 16:16:52 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g9BJdif16925 for ips-outgoing; Fri, 11 Oct 2002 15:39:44 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g9BBUEo10828 for ; Fri, 11 Oct 2002 07:30:14 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16783; Fri, 11 Oct 2002 07:28:06 -0400 (EDT) Message-Id: <200210111128.HAA16783@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ips@ece.cmu.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ips-ifcp-mib-03.txt,.pdf Date: Fri, 11 Oct 2002 07:28:06 -0400 Sender: owner-ips@ece.cmu.edu Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Storage Working Group of the IETF. Title : Definitions of Managed Objects For iFCP Author(s) : K. Gibbons, C. Monia, J. Tseng, F. Travostino Filename : draft-ietf-ips-ifcp-mib-03.txt,.pdf Pages : 23 Date : 2002-10-10 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a basic set of managed objects for SNMP-based monitoring and management of the Internet Fibre Channel Protocol (iFCP). This memo specifies a MIB module in a manner that is compliant to the SMIv2. The set of objects is consistent with the SNMP framework and existing SNMP standards. This memo is a product of the IP Storage (IPS) working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at ips@ece.cmu.edu and/or the authors. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-ifcp-mib-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-ifcp-mib-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ips-ifcp-mib-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-10-10140833.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-ifcp-mib-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-ifcp-mib-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-10140833.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ips@ece.cmu.edu Sun Oct 13 13:38:48 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22655 for ; Sun, 13 Oct 2002 13:38:48 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g9DGpvM10464 for ips-outgoing; Sun, 13 Oct 2002 12:51:57 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ariel.nishansystems.com (ultrex.nishansystems.com [12.36.127.195]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g9DGpuo10459 for ; Sun, 13 Oct 2002 12:51:56 -0400 (EDT) Received: by ariel.nishansystems.com with Internet Mail Service (5.5.2653.19) id <4Z7P6XTW>; Sun, 13 Oct 2002 09:51:45 -0700 Message-ID: From: Joshua Tseng To: ips@ece.cmu.edu Cc: "'Elizabeth Rodriguez'" Subject: iSNS: Last Call comments Date: Sun, 13 Oct 2002 09:51:44 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Hi Folks, Here is a summary of technical last call comments against the iSNS spec -13: 1) There needs to be a way to scope the DevGetNext message. Recommend that non-zero-length TLV's may be included as the first operating attributes of the DevGetNext message. They would be used to scope the DevGetNext message. Zero-length TLV's that follow would specify the attributes of the next object that need to be returned in the response message. If there are no non-zero-length TLV attributes, then the DevGetNext message is unscoped, as specified in previous iSNS spec revisions. Also for the DevGetNext message, it is ambiguous as to whether attributes of other objects other than the next object, can be returned in the message. 2) In order to better integrate with SNMP, we need a method to query for the next available index attribute. Recommend a virtual attribute for Entity, Portal, and iSCSI Node that always returns the value of the next available "Index" attribute for that object. This virtual attribute would only be used for queries, and it would be an error to attempt to register a value for this attribute. 3) Why is the registration period only 2 bytes, when the attribute length is 4 bytes? Recommend that the registration period use all 4 bytes, not just 2 bytes. 5) Spec needs to say that the iSNS server may reject iSNS messages with incompatible message version numbers in the iSNS message header. 6) Section 7.l2.5 should clarify that "Protocol Version" refers to block storage protocols. 7) Clarify that if a query requests an attribute for which the iSNS server has no value, then the server SHALL not return the requested attribute in the query response. Such query and response messages SHALL NOT be considered to be in error. 8) The format of the DevAttrRegRsp message in section 6.7.5.1 seems inconsistent. The message key attributes seems to contain the same thing as the operating attributes. The message key should contain the same attribute as the original registration message. From owner-ips@ece.cmu.edu Mon Oct 14 06:14:53 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13525 for ; Mon, 14 Oct 2002 06:14:53 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g9E9Pj208021 for ips-outgoing; Mon, 14 Oct 2002 05:25:45 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mailhub.lss.emc.com (xdch.emc.com [168.159.1.79]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g9E9Pio08017 for ; Mon, 14 Oct 2002 05:25:44 -0400 (EDT) Received: from emc.com (emcmail.lss.emc.com [168.159.48.78]) by mailhub.lss.emc.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g9E9PTM12158; Mon, 14 Oct 2002 05:25:29 -0400 (EDT) Received: from mxic1.isus.emc.com ([168.159.129.100]) by emc.com (8.10.1/8.10.1) with ESMTP id g9E9PS714477; Mon, 14 Oct 2002 05:25:28 -0400 (EDT) Received: by MXIC1 with Internet Mail Service (5.5.2653.19) id ; Mon, 14 Oct 2002 05:25:29 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C3F7@CORPMX14> From: Black_David@emc.com To: jtseng@NishanSystems.com, ips@ece.cmu.edu Cc: erodrigu@Brocade.COM Subject: iSNS: More Last Call comments Date: Mon, 14 Oct 2002 05:25:26 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Here are mine. Sorry to be a bit tardy on these but the powers that be decided that I had to spend most of Friday and Saturday packing and unpacking to move to a new office. Thanks, --David ----- Technical ----- -- Section 3.3.2 The iSNS server may refuse SCN service by returning a SCN Registration Rejected (Status Code 17). The rejection might occur in situations where the network size or current number of SCN registrations, has passed an implementation-specific threshold. A client not allowed to register for SCNs may decide to monitor its sessions with other storage devices directly. The "may" needs to be upper case, and this text strikes me as being a bit too cavalier about situations in which iSNS is unable to provide the requested service. A sentence should be added cautioning implementers that both hardware and software resources should be provided in sufficient quantities to make this refusal of service a sufficiently rare case. -- Section 3.4 Need a couple of "MUST"s in this section: - One to require the existence of an administrative control interface for the listed parameters. - One to require the default settings be used in the absence of other configuration (could be a "SHOULD"). -- Section 3.5.2 Will need to instruct IANA (and the RFC editor) to fill in the iSNS DHCP option number when it is allocated. -- Section 3.6 NAT discussion also needs to talk about using "global" addresses/port numbers for services/communication endpoints that need to be accessible. This is for an environment in which the administrator of iSNS knows about the NATs and can configure appropriate static mappings in them so that iSNS operates in the "global" domain and with a little care, everything "just works", even though NATs are involved (in essence, nodes behind NATs have a local address/port that they use for communication and a "global" one that they report to iSNS, with the NAT[s] translating between them). This is a "no free lunch" discussion, as it implies extra overhead in configuring the NAT[s] and care to deal with the fact that an endpoint now has two address pairs. There ought to be some useful material on this in the NAT RFCs (and possibly drafts) somewhere. -- Section 3.8 The discussion of iSNS database synchronization needs to mention distributed transactions as a way of doing this, although it would be ok to discourage them on complexity/overhead/latency grounds. A maximum of one backup iSNS server SHALL exist at any individual IP address. Why? At a minimum, this needs to be explained. Each backup server should note its relative precedence in the active server's list of backup servers. That "should" needs to be at least "SHOULD" and it may need to be a "MUST" as failure to do this could lead to more than one backup server believing that it is primary after a failure of the active server. If a backup server establishes that it has lost connectivity to the active server and other backup servers of higher precedence, then it shall assume that it is the active server. The method of determining whether connectivity has been lost is implementation- specific. One possible approach is to assume that if the backup server does not receive iSNS hearbeat messages for a period of time, then connectivity to the active server has been lost. Alternately, the backup server may establish TCP connections to the active server and other backup servers, and loss of connectivity determined through non-response to periodic echo messages (using iSNSP, SNMP, or other protocols). "shall" --> "SHOULD", but this is a disaster waiting to happen, as different iSNS implementations will get this just different enough that the result will be split-brain (more than one server believing it's primary) on loss of communication. This area is *hard* to get right (what's needed here is an HA cluster coordination protocol) - an expedient way out for now may be to limit support to one primary and one backup. When a backup server becomes the active server, it shall assume all active server responsibilities, including (if used) transmission of the iSNS heartbeat message. "shall" --> "SHALL", although this is probably editorial. -- Section 5.1.1, 5.1.3, 5.2.1, and 5.2.3 The following attributes are available to support iSCSI. Attributes indicated in the REQUIRED TO IMPLEMENT column MUST be supported by an iSNS server used to support iSCSI. Attributes indicated in the REQUIRED TO USE column MUST be supported by an iSCSI device that elects to use the iSNS. Suggest retitling the columns as "REQUIRED for Server" and "REQUIRED for Client", and noting that the attributes required for a Client will always be used in practice. Similar comments apply to the other 3 requirements tables. All iSCSI user-specified and vendor-specified attributes are optional to implement and use. "optional" --> "OPTIONAL", and add corresponding versions of this to the other 3 requirements tables (this is a recent IESG "hot button"). -- Section 5.1.3 and 5.2.3 What is the difference between NOT USED and RESERVED? A possible guess is that NOT USED will never be used, whereas RESERVED is for possible future use. This needs to be explained, or substitute RESERVED for "NOT USED". -- Section 6.1.1 The iSNSP version described in this document is 0x0001. Say that all other values are reserved. -- Section 6.5 The use of "Multicast" at this juncture will be assumed to be IP Multicast, and needs to be explained earlier. Add an explanation of iSNS Multicast and Broadcast somewhere in Section 3 and reference it here. Need to explain which messages can be Multicast/Broadcast. -- Section 6.6.5.3 Add a discussion of what happens if the iSNS database is updated during a sequence of GetNext operations. Is it possible to lose one's place if an object is deleted? How is a client expected to cope with this? -- Section 7 This looks like it should be retitled to IANA Considerations, with all of this stuff going into registries, and the section needs to be expanded to include things like the BSD from Section 6.5. Some of the material in the table in Section 7.1 may not be appropriate for an IANA registry, though. -- Section 7.2.1 7.2.1 Entity Identifier (EID) The Entity Identifier (EID) is a variable-length field containing user-readable UTF-8 text, and is terminated with at least one NULL character. variable length identifier This field uniquely identifies each network entity registered in the iSNS server. Does this need to be stringprep'ed? "variable length identifier" looks like it escaped from previous editing. Check all other UTF-8 attributes for possible needs for stringprep. By convention, EIDs generated by the iSNS server begin with the string "iSNS:". iSNS clients MUST NOT generate and register EIDs beginning with the string "iSNS:". Replace "By convention" with a "MUST" requirement on server generation of EIDs. -- Section 7.2.3 This field contains the IP Address used to manage the Network Entity and all Storage Nodes contained therein. The Management IP Address is a 16-byte field that may contain either a 32-bit IPv4 or 128-bit IPv6 address. When this field contains an IPv4 value, the most significant 12 bytes are set to 0x00. When this field contains an IPv6 value, the entire 16-byte field is used. If the network entity is capable of being managed and this field is not set, then in-band management through the IP address of one of the Portals of the Network Entity is assumed. What is this IP address used for? Why is an IP address, as opposed to an IP address plus TCP or UDP port? -- Section 7.2.7 The Entity Index is a 4-byte integer value that uniquely identifies each network entity registered in the iSNS server. The Entity Index is assigned by the iSNS server during the initial registration of an Entity. It can be used to represent a registered entity in situations where the Entity Identifier is too long to be used. Explain the requirements on "uniquely identifies", in particular rules about if/when an iSNS server can reuse an Entity Index value. Same comment applies to Portal Index (Section 7.3.7) and iSCSI Node Index (Section 7.4.5). -- Section 7.4.7 Remove DH-CHAP value. -- Section 7.5.3 Remove mFCP value. -- Section 7.7.1 This is a 4-byte field, and is used to provide a FC-4 type during a FC-4 Type query. The FC-4 types are consistent with the FC-4 Types as defined in FC-PH. Byte 0 contains the FC-4 type. All other bytes are reserved. Update FC-PH reference as T11 is obsoleting FC-PH. -- Section 7.9 To avoid misinterpreting proprietary attributes, it is RECOMMENDED that the vendor's own OUI (Organizationally Unique Identifier) be placed in the upper three bytes of the attribute field itself. If the OUI is not used, then some other unique marker recognizable by the vendor SHOULD be used. Should these be REQUIRED/MUST rather than RECOMMENDED/SHOULD? The second sentence is an invitation to problems, and needs to be rethought - Enterprise numbers (as used for MIBs) are a possibility, and there needs to be a way to distinguish whether an OUI or something else is in this field. -- Section 7.11 Standards-Based Extensions These attributes are reserved for future work by other standards bodies. Which attributes are these? I don't see any corresponding entry in the table in Section 7.1. -- Section 8.2 If the iSNS server is used to distribute authorizations for communications between iFCP and iSCSI peer devices, IPsec ESP with null transform MUST be implemented, and non-null transform MAY be implemented. If a non-null transform is implemented, then the DES encryption algorithm MUST NOT be used. "SHOULD NOT be used" is sufficient for DES, also applies to next text: If the iSNS server is used to distribute security policy for iFCP and iSCSI devices, then authentication, data integrity, and confidentiality must be supported and used. Where confidentiality is desired or required, IPSec ESP with non-null transform SHOULD be used, and the DES encryption algorithm MUST NOT be used. "must" --> "MUST", and there are a number of other places in this section where RFC 2119 words need to be in upper-case. Note that the authentication block is used only for iSNS broadcast or multicast messages, and SHOULD NOT be used in unicast iSNS messages. "SHOULD NOT" --> "MUST NOT" here and in earlier discussion of this block to avoid any need for recipients to deal with it in unicast messages. -- Section 8.6 When IPSec security is enabled, each iSNS client that is registered in the iSNS database SHALL maintain at least one phase-1 and one phase-2 security association with the iSNS server. All iSNS protocol messages between iSNS clients and the iSNS server SHALL be protected by a phase-2 security association. This prohibits discarding and recreating the phase 2 associations, e.g., to deal with limited crypto resources. If that was intended, explain why, as keeping the phase-1 ought to be sufficient to maintain the security context. From owner-ips@ece.cmu.edu Mon Oct 14 14:36:04 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29096 for ; Mon, 14 Oct 2002 14:36:04 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g9EHm9I08529 for ips-outgoing; Mon, 14 Oct 2002 13:48:09 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from hammer.brocade.com ([63.121.140.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g9EHm6o08522 for ; Mon, 14 Oct 2002 13:48:06 -0400 (EDT) Received: from hq-ex-c3.brocade.com (hq-ex-c3.brocade.com [192.168.126.211]) by hammer.brocade.com (8.11.3/8.11.3) with ESMTP id g9EHQmP20667 for ; Mon, 14 Oct 2002 10:26:53 -0700 (PDT) Received: by hq-ex-c3.brocade.com with Internet Mail Service (5.5.2653.19) id <4LH1PPWS>; Mon, 14 Oct 2002 10:26:48 -0700 Message-ID: From: Elizabeth Rodriguez To: "IPS Mailing List (E-mail)" Subject: IPS-ALL: FW: Internet-Draft Cutoff Dates for Atlanta, Georgia (No v.17-21, 2002) Date: Mon, 14 Oct 2002 10:26:43 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C273A6.DD413A00" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C273A6.DD413A00 Content-Type: text/plain; charset="iso-8859-1" A reminder of the cut off dates for IETF-55 in Atlanta. If anyone plans on submitting new individual submissions to the working group for Atlanta, please let David and I know. Thanks, Elizabeth Rodriguez -----Original Message----- From: Internet-Drafts Administrator [ mailto:internet-drafts@ietf.org ] Sent: Monday, October 14, 2002 7:24 AM Subject: Internet-Draft Cutoff Dates for Atlanta, Georgia (Nov.17-21, 2002) NOTE: There are two (2) Internet-Draft Cutoff dates October 28th: Cutoff for Initial Submissions (new documents) All initial submissions(-00) must be submitted by Monday, October 28th, at 09:00 ET. Initial submissions received after this time will NOT be made available in the Internet-Drafts directory, and will have to be resubmitted. As before, all initial submissions (-00.txt) with a filename beginning with a draft-ietf MUST be approved by the appropriate WG Chair prior to processing and announcing. WG Chair approval must be received by Monday, October 28th. Please do NOT wait until the last minute to submit. Be advised: NO placeholders. Updates to initial submissions received the week of October 28th will NOT be accepted. November 4th: FINAL Internet-Draft Cutoff All revised Internet-Draft submissions must be submitted by Monday, November 4th, 2002 at 09:00 ET. Internet-Drafts received after this time will NOT be announced NOR made available in the Internet-Drafts Directories. We will begin accepting Internet-Draft submissions the week of the meeting, though announcements will NOT be sent until the IETF meeting is over. Thank you for your understanding and cooperation. Please do not hesitate to contact us if you have any questions or concenrs. FYI: These and other significant dates can be found at http://www.ietf.org/meetings/cutoff_dates_55.html ------_=_NextPart_001_01C273A6.DD413A00 Content-Type: text/html; charset="iso-8859-1" IPS-ALL: FW: Internet-Draft Cutoff Dates for Atlanta, Georgia (Nov.17-21, 2002)

A reminder of the cut off dates for IETF-55 in Atlanta.
If anyone plans on submitting new individual submissions to the working group for Atlanta, please let David and I know.

Thanks,

Elizabeth Rodriguez
-----Original Message-----
From: Internet-Drafts Administrator [mailto:internet-drafts@ietf.org]
Sent: Monday, October 14, 2002 7:24 AM
Subject: Internet-Draft Cutoff Dates for Atlanta, Georgia (Nov.17-21,
2002)



NOTE: There are two (2) Internet-Draft Cutoff dates

October 28th: Cutoff for Initial Submissions (new documents)

All initial submissions(-00) must be submitted by Monday, October 28th,
at 09:00 ET.  Initial submissions received after this time will NOT be
made available in the Internet-Drafts directory, and will have to be
resubmitted.

 
As before, all initial submissions (-00.txt) with a filename beginning
with a draft-ietf MUST be approved by the appropriate WG Chair prior to
processing and announcing. WG Chair approval must be received by
Monday, October 28th.

 Please do NOT wait until the last minute to submit.

Be advised: NO placeholders. Updates to initial submissions received
            the week of October 28th will NOT be accepted.

November 4th: FINAL Internet-Draft Cutoff

All revised Internet-Draft submissions must be submitted by Monday,
November 4th, 2002 at 09:00 ET.  Internet-Drafts received after this
time will NOT be announced NOR made available in the Internet-Drafts
Directories.

We will begin accepting Internet-Draft submissions the week of the
meeting, though announcements will NOT be sent until the IETF meeting
is over.

Thank you for your understanding and cooperation. Please do not hesitate
to contact us if you have any questions or concenrs.

FYI: These and other significant dates can be found at
      http://www.ietf.org/meetings/cutoff_dates_55.html

------_=_NextPart_001_01C273A6.DD413A00-- From owner-ips@ece.cmu.edu Thu Oct 17 14:20:12 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20569 for ; Thu, 17 Oct 2002 14:20:12 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g9HHP3X28530 for ips-outgoing; Thu, 17 Oct 2002 13:25:03 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g9HBado29663 for ; Thu, 17 Oct 2002 07:36:39 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06529; Thu, 17 Oct 2002 07:34:12 -0400 (EDT) Message-Id: <200210171134.HAA06529@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ips@ece.cmu.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ips-iscsi-string-prep-03.txt Date: Thu, 17 Oct 2002 07:34:12 -0400 Sender: owner-ips@ece.cmu.edu Precedence: bulk --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 : String Profile for iSCSI Names Author(s) : M. Bakke Filename : draft-ietf-ips-iscsi-string-prep-03.txt Pages : 8 Date : 2002-10-16 The iSCSI protocol provides a way for hosts to access SCSI devices over an IP network. The iSCSI end-points, called initiators and targets, each have a globally-unique name that must be transcribable, as well as easily compared. This document describes how to prepare internationlized iSCSI names to increase the likelihood that name input and comparison work in ways that make sense for typical users throughout the world. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-string-prep-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ips-iscsi-string-prep-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ips-iscsi-string-prep-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-10-16152909.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-iscsi-string-prep-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-iscsi-string-prep-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-16152909.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ips@ece.cmu.edu Fri Oct 18 09:51:13 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26295 for ; Fri, 18 Oct 2002 09:51:13 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g9IDGdG16942 for ips-outgoing; Fri, 18 Oct 2002 09:16:39 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic2.corp.emc.com (mxic2.us.dg.com [128.221.31.40]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g9IDGcH16937 for ; Fri, 18 Oct 2002 09:16:38 -0400 (EDT) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Fri, 18 Oct 2002 09:16:28 -0400 Message-ID: <93F527C91A6ED411AFE10050040665D004AE2FB8@corpusmx1.us.dg.com> From: Hutchinson_Adam@emc.com To: ips@ece.cmu.edu Subject: iSCSI Name Formats (IQN and EUI) Date: Fri, 18 Oct 2002 09:16:26 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C276A8.9036A9C0" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C276A8.9036A9C0 Content-Type: text/plain; charset="iso-8859-1" Questions regarding the two iSCSI name formats. Are there advantages and disadvantages for the IQN and EUI name formats defined in the iSCSI specification? Should one format be preferred over the other? Is it possible that the EUI names could be preferred in environments with switches that connect Fibre Channel and iSCSI networks? Could the iSCSI EUI be used as part of a WWN for Fibre Channel in such an environment? If it is unforeseeable at this time whether one format has any advantage over the other, should it be possible to have an iSCSI device that can be identified by either name format? Perhaps the name format to use would be something configurable by the user, but only one name format would be used at a time. Thanks, _____________________________ Adam Hutchinson CLARiiON/EMC Corp Phone: 508.382.5938 Fax: 508.382.7913 Email: hutchinson_adam@emc.com ------_=_NextPart_001_01C276A8.9036A9C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Questions regarding the two iSCSI name = formats.

 

=

Are there advantages and disadvantages for the IQN and EUI name = formats defined in the iSCSI specification? Should one format be preferred over = the other? Is it possible that the EUI names could be preferred in environments = with switches that connect Fibre Channel and iSCSI networks? Could the iSCSI EUI be = used as part of a WWN for Fibre Channel in such an environment? If it is = unforeseeable at this time whether one format has any advantage over the other, should = it be possible to have an iSCSI device that can be identified by either name = format? Perhaps the name format to use would be something configurable by the user, but = only one name format would be used at a time. =

 

=

Thanks,

_______= ______________________

Adam = Hutchinson

CLARiiO= N/EMC Corp

Phone:<= span style=3D"mso-spacerun: yes">  = 508.382.5938

Fax:      = 508.382.7913

Email:<= span style=3D"mso-spacerun: yes">    = hutchinson_adam@emc.com

 

=
------_=_NextPart_001_01C276A8.9036A9C0-- From owner-ips@ece.cmu.edu Fri Oct 18 17:54:43 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11007 for ; Fri, 18 Oct 2002 17:54:43 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g9ILDuD21353 for ips-outgoing; Fri, 18 Oct 2002 17:13:56 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from global.com (global.com [65.200.74.20]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g9ILDsH21349 for ; Fri, 18 Oct 2002 17:13:54 -0400 (EDT) Received: from GARUDA.mtv.global.com (mail.global.com [65.200.74.5]) by global.com (Postfix) with SMTP id 369E712116D for ; Fri, 18 Oct 2002 14:13:53 -0700 (PDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Subject: question on reserve and release ! Date: Fri, 18 Oct 2002 14:13:53 -0700 Message-ID: Thread-Topic: question on reserve and release ! Thread-Index: AcJ26v3GJVMV9O+0RfC+Wy56c85eAgAAD3Aw From: "Ramesh Ramakrishnan" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id g9ILDsH21350 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit > Hi All, > > I have a question on how iscsi will handle the scsi reserve and release commands. > > When multiple iscsi initiators make calls to the same iscsi target, the actual scsi > device only sees one single scsi id (that of the scsi HBA on the iscsi target > machine). This would mean that different iscsi initiators sending scsi reserve > command will be interpreted by the scsi target as commands from the same > scsi initiator. This defeats the purpose of implementing the scsi reserve/release > commands. And in a way, makes iscsi not very useful in environments where > iscsi initiator requires exclusive access to a iscsi target. (Imagine a iscsi initiator > doing a back up to a iscsi tape device when another iscsi initiator starts rewinding > the same iscsi tape device.) > > Is this something that should be implemented in the iscsi target > driver? I found that Cisco's iscsi driver (1.8.1) for AIX has a feature called > "reserve/release proxy". Is this cisco's implementation for getting around this > problem? Has anyone any experience with that driver? Another interesting > thing: I only find reference to this reserve/release proxy mentioned in the AIX driver. > > thanks > ramesh From owner-ips@ece.cmu.edu Fri Oct 18 18:34:04 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11492 for ; Fri, 18 Oct 2002 18:34:03 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g9IM0jx23877 for ips-outgoing; Fri, 18 Oct 2002 18:00:45 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.ivivity.com ([64.238.111.99]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g9IM0hH23871 for ; Fri, 18 Oct 2002 18:00:43 -0400 (EDT) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id <414L5NLT>; Fri, 18 Oct 2002 18:00:42 -0400 Message-ID: From: Eddy Quicksall To: Ramesh Ramakrishnan , ips@ece.cmu.edu Subject: RE: question on reserve and release ! Date: Fri, 18 Oct 2002 18:00:41 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk From the spec: "The I_T nexus can be identified by the conjunction of the SCSI port names; that is, the I_T nexus identifier is the tuple (iSCSI Initiator Name + ',i,'+ ISID, iSCSI Target Name + ',t,'+ Portal Group Tag)." The "scsi id" you mention would have to be the InitiatorName+ISID. This would be no different than parallel SCSI when the initiator has two HBA's on the same bus. So whatever problems you mention already exist. Eddy -----Original Message----- From: Ramesh Ramakrishnan [mailto:ramesh@global.com] Sent: Friday, October 18, 2002 5:14 PM To: ips@ece.cmu.edu Subject: question on reserve and release ! > Hi All, > > I have a question on how iscsi will handle the scsi reserve and release commands. > > When multiple iscsi initiators make calls to the same iscsi target, the actual scsi > device only sees one single scsi id (that of the scsi HBA on the iscsi target > machine). This would mean that different iscsi initiators sending scsi reserve > command will be interpreted by the scsi target as commands from the same > scsi initiator. This defeats the purpose of implementing the scsi reserve/release > commands. And in a way, makes iscsi not very useful in environments where > iscsi initiator requires exclusive access to a iscsi target. (Imagine a iscsi initiator > doing a back up to a iscsi tape device when another iscsi initiator starts rewinding > the same iscsi tape device.) > > Is this something that should be implemented in the iscsi target > driver? I found that Cisco's iscsi driver (1.8.1) for AIX has a feature called > "reserve/release proxy". Is this cisco's implementation for getting around this > problem? Has anyone any experience with that driver? Another interesting > thing: I only find reference to this reserve/release proxy mentioned in the AIX driver. > > thanks > ramesh From owner-ips@ece.cmu.edu Sat Oct 19 10:57:58 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03847 for ; Sat, 19 Oct 2002 10:57:58 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g9JEDRw12525 for ips-outgoing; Sat, 19 Oct 2002 10:13:27 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [194.196.100.235]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g9JEDPH12517; Sat, 19 Oct 2002 10:13:25 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g9JEDITX034264; Sat, 19 Oct 2002 16:13:18 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g9JEDHfT031204; Sat, 19 Oct 2002 16:13:18 +0200 In-Reply-To: To: "Ramesh Ramakrishnan" Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: question on reserve and release ! X-Mailer: Lotus Notes Release 6.0 September 26, 2002 From: "Julian Satran" Message-ID: Date: Sat, 19 Oct 2002 16:13:15 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 19/10/2002 16:13:18, Serialize complete at 19/10/2002 16:13:18 Content-Type: multipart/alternative; boundary="=_alternative 004D5A34C2256C57_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 004D5A34C2256C57_= Content-Type: text/plain; charset="US-ASCII" In fact the SCSI target sees ONE INITIATOR (name+port) per session. Julo "Ramesh Ramakrishnan" Sent by: owner-ips@ece.cmu.edu 18/10/02 23:13 To: cc: Subject: question on reserve and release ! > Hi All, > > I have a question on how iscsi will handle the scsi reserve and release commands. > > When multiple iscsi initiators make calls to the same iscsi target, the actual scsi > device only sees one single scsi id (that of the scsi HBA on the iscsi target > machine). This would mean that different iscsi initiators sending scsi reserve > command will be interpreted by the scsi target as commands from the same > scsi initiator. This defeats the purpose of implementing the scsi reserve/release > commands. And in a way, makes iscsi not very useful in environments where > iscsi initiator requires exclusive access to a iscsi target. (Imagine a iscsi initiator > doing a back up to a iscsi tape device when another iscsi initiator starts rewinding > the same iscsi tape device.) > > Is this something that should be implemented in the iscsi target > driver? I found that Cisco's iscsi driver (1.8.1) for AIX has a feature called > "reserve/release proxy". Is this cisco's implementation for getting around this > problem? Has anyone any experience with that driver? Another interesting > thing: I only find reference to this reserve/release proxy mentioned in the AIX driver. > > thanks > ramesh --=_alternative 004D5A34C2256C57_= Content-Type: text/html; charset="US-ASCII"
In fact the SCSI target sees ONE INITIATOR (name+port) per session. Julo


"Ramesh Ramakrishnan" <ramesh@global.com>
Sent by: owner-ips@ece.cmu.edu

18/10/02 23:13

       
        To:        <ips@ece.cmu.edu>
        cc:        
        Subject:        question on reserve and release !

       


> Hi All,
>
> I have a question on how iscsi will handle the scsi reserve and release commands.
>
> When multiple iscsi initiators make calls to the same iscsi target, the actual scsi
> device only sees one single scsi id (that of the scsi HBA on the iscsi target
> machine).  This would mean that different iscsi initiators sending scsi reserve
> command will be interpreted by the scsi target as commands from the same
> scsi initiator.  This defeats the purpose of implementing the scsi reserve/release
> commands.  And in a way, makes iscsi not very useful in environments where
> iscsi initiator requires exclusive access to a iscsi target. (Imagine a iscsi initiator
> doing a back up to a iscsi tape device when another iscsi initiator starts rewinding
> the same iscsi tape device.)
>
>  Is this something that should be implemented in the iscsi target
> driver?  I found that Cisco's iscsi driver (1.8.1) for AIX has a  feature called
> "reserve/release proxy".  Is this cisco's implementation for getting around this
> problem?  Has anyone any experience with that driver? Another interesting
> thing:  I only find reference to this reserve/release proxy mentioned in the AIX driver.
>
> thanks
> ramesh
--=_alternative 004D5A34C2256C57_=-- From owner-ips@ece.cmu.edu Sun Oct 20 03:06:21 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23423 for ; Sun, 20 Oct 2002 03:06:21 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g9K6Jks14146 for ips-outgoing; Sun, 20 Oct 2002 02:19:46 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ariel.nishansystems.com (ultrex.nishansystems.com [12.36.127.195]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g9K6JfH14141 for ; Sun, 20 Oct 2002 02:19:45 -0400 (EDT) Received: by ariel.nishansystems.com with Internet Mail Service (5.5.2653.19) id ; Sat, 19 Oct 2002 23:19:30 -0700 Message-ID: From: Joshua Tseng To: ips@ece.cmu.edu, "'Black_David@emc.com'" Cc: erodrigu@Brocade.COM Subject: iSNS: Responses to David Black Technical Comments Date: Sat, 19 Oct 2002 23:19:28 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Please see below responses to the technical comments. I will respond to the editorial comments separately. Josh > -----Original Message----- > From: Black_David@emc.com [mailto:Black_David@emc.com] > Sent: Monday, October 14, 2002 2:25 AM > To: jtseng@NishanSystems.com; ips@ece.cmu.edu > Cc: erodrigu@Brocade.COM > Subject: iSNS: More Last Call comments > > > Here are mine. Sorry to be a bit tardy on these but > the powers that be decided that I had to spend most of > Friday and Saturday packing and unpacking to move to a > new office. Thanks, --David > > ----- Technical ----- > > -- Section 3.3.2 > > The iSNS server may refuse SCN service by returning a SCN > Registration Rejected (Status Code 17). The rejection might occur > in situations where the network size or current number of SCN > registrations, has passed an implementation-specific threshold. A > client not allowed to register for SCNs may decide to monitor its > sessions with other storage devices directly. > > The "may" needs to be upper case, and this text strikes me as being > a bit too cavalier about situations in which iSNS is unable to provide > the requested service. A sentence should be added cautioning > implementers that both hardware and software resources should be > provided in sufficient quantities to make this refusal of service > a sufficiently rare case. The text will be changed to read: The iSNS server SHOULD be implemented with sufficient hardware and software resources needed to support the expected number of iSNS clients. However, if resources are unexpectedly exhausted, then the iSNS server MAY refuse SCN service by returning a SCN Registration Rejected (Status Code 17). The rejection might occur in situations where the network size or current number of SCN registrations, has passed an implementation-specific threshold. A client not allowed to register for SCNs may decide to monitor its sessions with other storage devices directly. > > -- Section 3.4 > > Need a couple of "MUST"s in this section: > - One to require the existence of an administrative control > interface for > the listed parameters. > - One to require the default settings be used in the absence of other > configuration (could be a "SHOULD"). Done. > > -- Section 3.5.2 > > Will need to instruct IANA (and the RFC editor) to fill in > the iSNS DHCP > option number when it is allocated. Noted. > > -- Section 3.6 > > NAT discussion also needs to talk about using "global" addresses/port > numbers > for services/communication endpoints that need to be > accessible. This is > for an environment in which the administrator of iSNS knows > about the NATs > and can configure appropriate static mappings in them so that > iSNS operates > in the "global" domain and with a little care, everything > "just works", > even though NATs are involved (in essence, nodes behind NATs > have a local > address/port that they use for communication and a "global" one that > they report to iSNS, with the NAT[s] translating between > them). This is > a "no free lunch" discussion, as it implies extra overhead in > configuring > the NAT[s] and care to deal with the fact that an endpoint now has two > address pairs. There ought to be some useful > material on this in the NAT RFCs (and possibly drafts) somewhere. The following text was added the the end of section 3.6: Finally, note that it is possible for an iSNS server in the private addressing domain behind a NAT boundary to exclusively support iSNS clients that are operating in the global IP addressing domain. If this is the case, the administrator only needs to ensure that the appropriate mappings are configured on the NAT gateways to allow the iSNS clients to initiate iSNSP sessions to the iSNS server. All registered addresses contained in the iSNS server are thus public IP addresses for use outside the NAT boundary. Care should be taken to ensure that there are no iSNS clients querying the server from inside the NAT boundary. > > -- Section 3.8 > > The discussion of iSNS database synchronization needs to > mention distributed > transactions as a way of doing this, although it would be ok > to discourage > them on complexity/overhead/latency grounds. The following has been added to the text: For the purposes of this discussion, the specified backup mechanisms pertain to interaction among different logical iSNS servers. Note that it is possible to create multiple physical iSNS servers to form a single logical iSNS server cluster, and thus distribute iSNS transaction processing among multiple physical servers. However, a more detailed discussion of the interactions between physical servers within a logical iSNS server cluster is beyond the scope of this document. > > A maximum of one backup iSNS server SHALL exist at any > individual IP > address. > > Why? At a minimum, this needs to be explained. This statement has been modified as follows: A maximum of one logical backup iSNS server SHALL exist at any individual IP address, in order to avoid conflicts from multiple servers listening on the same canonical TCP or UDP port number. > > Each backup server should note its relative precedence in > the active > server's list of backup servers. > > That "should" needs to be at least "SHOULD" and it may need > to be a "MUST" > as failure to do this could lead to more than one backup > server believing > that it is primary after a failure of the active server. Done. > > If a backup server establishes that it has lost connectivity to the > active server and other backup servers of higher > precedence, then it > shall assume that it is the active server. The method of > determining whether connectivity has been lost is implementation- > specific. One possible approach is to assume that if the backup > server does not receive iSNS hearbeat messages for a > period of time, > then connectivity to the active server has been lost. > Alternately, > the backup server may establish TCP connections to the > active server > and other backup servers, and loss of connectivity determined > through non-response to periodic echo messages (using iSNSP, SNMP, > or other protocols). > > "shall" --> "SHOULD", but this is a disaster waiting to > happen, as different > iSNS implementations will get this just different enough that > the result > will be split-brain (more than one server believing it's > primary) on loss > of communication. This area is *hard* to get right (what's > needed here > is an HA cluster coordination protocol) - an expedient way out for now > may be to limit support to one primary and one backup. Done. Your comment is noted, and that is why I left the method for determining election/re-election of the primary server up to the specific implementation. Yes, an HA cluster protocol would be ideal, but not necessarily required in all situations. > > When a backup server becomes the active server, it shall assume all > active server responsibilities, including (if used) transmission of > the iSNS heartbeat message. > > "shall" --> "SHALL", although this is probably editorial. Done. > > -- Section 5.1.1, 5.1.3, 5.2.1, and 5.2.3 > > The following attributes are available to support iSCSI. > Attributes > indicated in the REQUIRED TO IMPLEMENT column MUST be supported by > an iSNS server used to support iSCSI. Attributes indicated in the > REQUIRED TO USE column MUST be supported by an iSCSI device that > elects to use the iSNS. > > Suggest retitling the columns as "REQUIRED for Server" and > "REQUIRED for > Client", and noting that the attributes required for a Client > will always > be used in practice. Similar comments apply to the other 3 > requirements > tables. Done. > > All iSCSI user-specified and vendor-specified attributes are > optional to implement and use. > > "optional" --> "OPTIONAL", and add corresponding versions of this to > the other 3 requirements tables (this is a recent IESG "hot button"). Done. The statement was added for the other attribute table for iFCP. > > -- Section 5.1.3 and 5.2.3 > > What is the difference between NOT USED and RESERVED? A > possible guess is > that NOT USED will never be used, whereas RESERVED is for > possible future > use. This needs to be explained, or substitute RESERVED for > "NOT USED". Done - Func_ID values indicated as NOT USED have been combined with RESERVED. > > -- Section 6.1.1 > > The iSNSP version described in this document is 0x0001. > > Say that all other values are reserved. Done. > > -- Section 6.5 > > The use of "Multicast" at this juncture will be assumed to be > IP Multicast, > and needs to be explained earlier. Add an explanation of iSNS > Multicast and Broadcast somewhere in Section 3 and reference it here. > Need to explain which messages can be Multicast/Broadcast. I've added a new section 3.9 to talk about transport protocols for iSNS. I've also consolidated what formerly was in section 5.3 and 5.4 into this section. A reference to 3.9.3 was also added to section 6.5. > > -- Section 6.6.5.3 > > Add a discussion of what happens if the iSNS database is > updated during > a sequence of GetNext operations. Is it possible to lose one's place > if an object is deleted? How is a client expected to cope with this? The following text has been added to the end of section 6.6.5.3: The iSNS client is responsible for ensuring that information acquired through use of the DevGetNext message is accurate and up-to-date. There is no assurance that the iSNS database will not change between successive DevGetNext request messages. If the Message Key provided does not match an existing database entry, then attributes for the next object key following the Message Key provided SHALL be returned. For example, an object entry may have been deleted between successive DevGetNext messages. This may result in a DevGetNext request where the Message Key does not match an existing object entry. In this case, attributes for the next object stored in the iSNS database are returned. > > -- Section 7 > > This looks like it should be retitled to IANA Considerations, > with all of > this stuff going into registries, and the section needs to be > expanded to > include things like the BSD from Section 6.5. Some of the material in > the table in Section 7.1 may not be appropriate for an IANA registry, > though. A new IANA Considerations section has been inserted as section 9, as shown below: 9. IANA Considerations The well-known TCP and UDP port number for iSNS is 3205. In order to maintain a registry of block storage protocols supported by iSNSP, IANA MUST assign a 32-bit unsigned integer number for each protocol. This number is stored in the iSNS database as the Entity Protocol. The initial set of values to be maintained by IANA for Entity Protocol is indicated in the table in section 7.2.2. IANA is responsible for maintaining the complete list of iSNS attributes. This information MUST include for each iSNS attribute, its tag value, the attribute's length, and the set of permissible registration and query keys that can be used for that attribute. The initial list of iSNS attributes to be maintained by IANA is indicated in section 7.1. Finally, IANA is also responsible for assigning values to be used for the Block Structure Descriptor for the Authentication Block (see section 6.5). > > -- Section 7.2.1 > > 7.2.1 Entity Identifier (EID) > > The Entity Identifier (EID) is a variable-length field containing > user-readable UTF-8 text, and is terminated with at least one NULL > character. variable length identifier This field uniquely > identifies each network entity registered in the iSNS server. > > Does this need to be stringprep'ed? "variable length > identifier" looks > like it escaped from previous editing. Check all other UTF-8 > attributes > for possible needs for stringprep. Variable-length fields that are used as key attributes (i.e., EID, iSCSI Name) need to be stringprep-ed. Those that are not key attributes are used as descriptive fields, and so do not need to be normalized. The following text will be added to each variable-length field that is used as a primary key: This attribute MUST be normalized according to the stringprep template [STRINGPREP] before it is stored in the iSNS database. Note that since we are now using the stringprep document generically, not just for iSCSI names, then I would suggest removing the iSCSI label for that document. > > By convention, EIDs generated by the iSNS server begin with > the string "iSNS:". iSNS clients MUST NOT generate and register > EIDs beginning with the string "iSNS:". > > Replace "By convention" with a "MUST" requirement on server generation > of EIDs. Done. > > -- Section 7.2.3 > > This field contains the IP Address used to manage the > Network Entity > and all Storage Nodes contained therein. The Management IP Address > is a 16-byte field that may contain either a 32-bit IPv4 or 128-bit > IPv6 address. When this field contains an IPv4 value, the most > significant 12 bytes are set to 0x00. When this field contains an > IPv6 value, the entire 16-byte field is used. If the > network entity > is capable of being managed and this field is not set, then in-band > management through the IP address of one of the Portals of the > Network Entity is assumed. > > What is this IP address used for? Why is an IP address, as opposed to > an IP address plus TCP or UDP port? Both IP address and TCP/UDP Port are required to identify a Portal. The Portal object is therefore referenced by two attributes--its primary key has two fields. The IP address alone is insigificant--it must be accompanied by the TCP/UDP Port Number to have any meaning in iSNS. > > -- Section 7.2.7 > > The Entity Index is a 4-byte integer value that uniquely identifies > each network entity registered in the iSNS server. The > Entity Index > is assigned by the iSNS server during the initial > registration of an > Entity. It can be used to represent a registered entity in > situations where the Entity Identifier is too long to be used. > > Explain the requirements on "uniquely identifies", in particular rules > about if/when an iSNS server can reuse an Entity Index value. > Same comment applies to Portal Index (Section 7.3.7) and > iSCSI Node Index > (Section 7.4.5). The text for 7.2.7 has been modified as follows: The Entity Index is a 4-byte integer value that uniquely identifies each network entity registered in the iSNS server. Upon initial registration of an Entity, the iSNS server assigns an unused value for the Entity Index for that Entity. Each Entity in the iSNS database MUST be assigned a value for the Entity Index that is not assigned to any other Entity. The Entity Index MAY be used to represent the Entity in situations when the Entity Identifier is too long or otherwise inappropriate. The 1st paragraph for 7.3.7 has been modified as follows: The Portal Index is a 4-byte integer value that uniquely identifies each portal registered in the iSNS database. Upon initial registration of a Portal, the iSNS server assigns an unused value for the Portal Index of that Portal. Each Portal in the iSNS database MUST be assigned a value for the Portal Index that is not assigned to any other Portal. The 1st paragraph for 7.4.5 has been modified as follows: The iSCSI Node Index is a 4-byte integer value that uniquely identifies each iSCSI node registered in the iSNS database. Upon initial registration of the iSCSI node, the iSNS server assigns an unused value for the iSCSI Node Index. Each iSCSI Node MUST be assigned a value for the iSCSI Node Index that is not assigned to any other iSCSI Node. > > -- Section 7.4.7 > > Remove DH-CHAP value. Done. > > -- Section 7.5.3 > > Remove mFCP value. > Done. > -- Section 7.7.1 > > This is a 4-byte field, and is used to provide a FC-4 type during a > FC-4 Type query. The FC-4 types are consistent with the FC-4 Types > as defined in FC-PH. Byte 0 contains the FC-4 type. All other > bytes are reserved. > > Update FC-PH reference as T11 is obsoleting FC-PH. This reference has been replaced with a reference to FC-FS. > > -- Section 7.9 > > To avoid > misinterpreting proprietary attributes, it is RECOMMENDED that the > vendor's own OUI (Organizationally Unique Identifier) be placed in > the upper three bytes of the attribute field itself. If the OUI is > not used, then some other unique marker recognizable by the vendor > SHOULD be used. > > Should these be REQUIRED/MUST rather than RECOMMENDED/SHOULD? > The second > sentence is an invitation to problems, and needs to be rethought - > Enterprise > numbers (as used for MIBs) are a possibility, and there needs > to be a way > to distinguish whether an OUI or something else is in this field. The OUI will be REQUIRED. The last sentence in the paragraph has been deleted. > > -- Section 7.11 Standards-Based Extensions > > These attributes are reserved for future work by other standards > bodies. > > Which attributes are these? I don't see any corresponding > entry in the > table in Section 7.1. Section 7.11 has been deleted. > > -- Section 8.2 > > If the iSNS server is used to distribute authorizations for > communications between iFCP and iSCSI peer devices, IPsec ESP with > null transform MUST be implemented, and non-null transform MAY be > implemented. If a non-null transform is implemented, then the DES > encryption algorithm MUST NOT be used. Done. > > "SHOULD NOT be used" is sufficient for DES, also applies to next text: > > If the iSNS server is used to distribute security policy for iFCP > and iSCSI devices, then authentication, data integrity, and > confidentiality must be supported and used. Where confidentiality > is desired or required, IPSec ESP with non-null transform SHOULD be > used, and the DES encryption algorithm MUST NOT be used. Done. > > "must" --> "MUST", and there are a number of other places in > this section > where RFC 2119 words need to be in upper-case. Done. > > Note that the > authentication block is used only for iSNS broadcast or multicast > messages, and SHOULD NOT be used in unicast iSNS messages. > > "SHOULD NOT" --> "MUST NOT" here and in earlier discussion of > this block > to avoid any need for recipients to deal with it in unicast messages. > Done. > -- Section 8.6 > > When IPSec security is enabled, each iSNS client that is registered > in the iSNS database SHALL maintain at least one phase-1 and one > phase-2 security association with the iSNS server. All iSNS > protocol messages between iSNS clients and the iSNS server SHALL be > protected by a phase-2 security association. > > This prohibits discarding and recreating the phase 2 > associations, e.g., > to deal with limited crypto resources. If that was intended, explain > why, as keeping the phase-1 ought to be sufficient to maintain the > security context. "and one phase-2" has been deleted from the first sentence in 8.6. From owner-ips@ece.cmu.edu Mon Oct 21 19:23:39 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18835 for ; Mon, 21 Oct 2002 19:23:34 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g9LMi8Z09022 for ips-outgoing; Mon, 21 Oct 2002 18:44:08 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mailhub.lss.emc.com (xdch.emc.com [168.159.1.79]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g9LMi6H09018 for ; Mon, 21 Oct 2002 18:44:06 -0400 (EDT) Received: from emc.com (emcmail.lss.emc.com [168.159.48.78]) by mailhub.lss.emc.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g9LMhw723479 for ; Mon, 21 Oct 2002 18:43:58 -0400 (EDT) Received: from mxic1.isus.emc.com ([168.159.129.100]) by emc.com (8.10.1/8.10.1) with ESMTP id g9LMhv729992 for ; Mon, 21 Oct 2002 18:43:57 -0400 (EDT) Received: by MXIC1 with Internet Mail Service (5.5.2653.19) id ; Mon, 21 Oct 2002 18:43:57 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C425@CORPMX14> From: Black_David@emc.com To: ips@ece.cmu.edu Subject: FW: Protocol Action: Preparation of Internationalized Strings (' stringprep') to Proposed Standard Date: Mon, 21 Oct 2002 18:43:53 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk FYI - both iSCSI and iSNS have dependencies on this. --David p.s. I've been moved - please note new phone #'s. ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 **NEW** FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- -----Original Message----- From: The IESG [mailto:iesg-secretary@ietf.org] Sent: Monday, October 21, 2002 4:38 PM Cc: RFC Editor; Internet Architecture Board Subject: Protocol Action: Preparation of Internationalized Strings ('stringprep') to Proposed Standard The IESG has approved Preparation of Internationalized Strings ('stringprep') as a Proposed Standard. This document is the product of the IDN Working Group. The IESG contact persons are Erik Nordmark and Thomas Narten. Technical Summary This document describes a framework for preparing Unicode text strings in order to increase the likelihood that string input and string comparison work in ways that make sense for typical users throughout the world. The stringprep protocol is useful for protocol identifier values, company and personal names, internationalized domain names, and other text strings. This document does not specify how protocols should prepare text strings. Protocols must create profiles of stringprep in order to fully specify the processing options. This document can be when protocols need a mechanism to compare identifiers that use Unicode. One use is for IDN, but there are other potential uses for IP storage, Kerberos, etc. Working Group Summary The working group resolved two major comments in response to the IETF last call (plus minor and editorial comments). The major comments where - change from using Unicode 3.1 to 3.2 - added restrictions for bidirectional characters A new WG last call was done on these changes. There was WG concensus to advance this document. Protocol Quality This document has been reviewed for the IESG by Erik Nordmark. RFC Editor Note: In section 3.2 change: Authors of profiles of this document need to consider the effects of changing the mapping of any currently-assigned character when updating their profiles. Adding a new mapping for a currently-assigned character, or changing an existing mapping, could change the behavior that users see in both systems that have been updated and systems that have not been updated. to read: Authors of profiles of this document need to consider the effects of changing the mapping of any currently-assigned character when updating their profiles. Adding a new mapping for a currently-assigned character, or changing an existing mapping, could cause a variance between the behavior of systems that have been updated and systems that have not been updated. From owner-ips@ece.cmu.edu Mon Oct 21 20:13:23 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18834 for ; Mon, 21 Oct 2002 19:23:34 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g9LN6Qx10061 for ips-outgoing; Mon, 21 Oct 2002 19:06:26 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel12.hp.com (palrel12.hp.com [156.153.255.237]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g9LN6MH10052 for ; Mon, 21 Oct 2002 19:06:22 -0400 (EDT) Received: from xparelay2.ptp.hp.com (xparelay2.ptp.hp.com [15.1.28.65]) by palrel12.hp.com (Postfix) with ESMTP id 0C6CFE004AE; Mon, 21 Oct 2002 16:06:18 -0700 (PDT) Received: from xpabh3.ptp.hp.com (xpabh3.ptp.hp.com [15.1.28.63]) by xparelay2.ptp.hp.com (Postfix) with ESMTP id DD175AF; Mon, 21 Oct 2002 16:06:17 -0700 (PDT) Received: by xpabh3.ptp.hp.com with Internet Mail Service (5.5.2655.55) id <44NKR0PQ>; Mon, 21 Oct 2002 16:06:17 -0700 Message-ID: <6BD67FFB937FD411A04F00D0B74FE878102F5CB8@xrose06.rose.hp.com> From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" To: "'Hutchinson_Adam@emc.com'" , ips@ece.cmu.edu Subject: RE: iSCSI Name Formats (IQN and EUI) Date: Mon, 21 Oct 2002 16:06:07 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C27956.700F6280" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C27956.700F6280 Content-Type: text/plain Have you read the Naming and Discovery draft - http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-name-disc-08.txt ? As for "switches that connect FC and iSCSI networks" I assume you're thinking of iSCSI-FC gateways? That's a slippery slope, and has been previously discussed on this reflector, look thru the archives. A gateway must export world-wide unique names in the iSCSI domain - if a gateway uses the EUI format and sticks in an FC device's WWN, another gateway connected to the same SAN would construct the same name and violate name uniqueness (and cause other problems at the SCSI layer). Marjorie Krueger Hewlett-Packard -----Original Message----- From: Hutchinson_Adam@emc.com [mailto:Hutchinson_Adam@emc.com] Sent: Friday, October 18, 2002 6:16 AM To: ips@ece.cmu.edu Subject: iSCSI Name Formats (IQN and EUI) Questions regarding the two iSCSI name formats. Are there advantages and disadvantages for the IQN and EUI name formats defined in the iSCSI specification? Should one format be preferred over the other? Is it possible that the EUI names could be preferred in environments with switches that connect Fibre Channel and iSCSI networks? Could the iSCSI EUI be used as part of a WWN for Fibre Channel in such an environment? If it is unforeseeable at this time whether one format has any advantage over the other, should it be possible to have an iSCSI device that can be identified by either name format? Perhaps the name format to use would be something configurable by the user, but only one name format would be used at a time. Thanks, _____________________________ Adam Hutchinson CLARiiON/EMC Corp Phone: 508.382.5938 Fax: 508.382.7913 Email: hutchinson_adam@emc.com ------_=_NextPart_001_01C27956.700F6280 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Message
Have=20 you read the Naming and Discovery draft - http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-name= -disc-08.txt ? =20
 
As=20 for "switches that connect FC and iSCSI networks" I assume you're = thinking of=20 iSCSI-FC gateways?  That's a slippery slope, and has been = previously=20 discussed on this reflector, look thru the archives.    = A gateway=20 must export world-wide unique names in the iSCSI domain - if a gateway = uses the=20 EUI format and sticks in an FC device's WWN, another gateway connected = to the=20 same SAN would construct the same name and violate name uniqueness (and = cause=20 other problems at the SCSI layer).
 
Marjorie Krueger
Hewlett-Packard
-----Original Message-----
From:=20 Hutchinson_Adam@emc.com [mailto:Hutchinson_Adam@emc.com] =
Sent:=20 Friday, October 18, 2002 6:16 AM
To:=20 ips@ece.cmu.edu
Subject: iSCSI Name Formats (IQN and=20 EUI)

Questions=20 regarding the two iSCSI name = formats.

 

=

Are=20 there advantages and disadvantages for the IQN and EUI name formats = defined in=20 the iSCSI specification? Should one format be preferred over the = other? Is it=20 possible that the EUI names could be preferred in environments with = switches=20 that connect Fibre Channel and iSCSI networks? Could the iSCSI EUI be = used as=20 part of a WWN for Fibre Channel in such an environment? If it is = unforeseeable=20 at this time whether one format has any advantage over the other, = should it be=20 possible to have an iSCSI device that can be identified by either = name format?=20 Perhaps the name format to use would be something configurable by the = user,=20 but only one name format would be used at a time.=20

 

=

Thanks,

_____________________________

Adam=20 Hutchinson

CLARiiON/EMC=20 Corp

Phone:  = 508.382.5938

Fax:      = 508.382.7913=20

Email:   =20 hutchinson_adam@emc.com

 

=
------_=_NextPart_001_01C27956.700F6280-- From owner-ips@ece.cmu.edu Mon Oct 21 21:25:47 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20950 for ; Mon, 21 Oct 2002 21:25:46 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g9M0kaM14823 for ips-outgoing; Mon, 21 Oct 2002 20:46:36 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from maho3msx2.isus.emc.com (maho3msx2.isus.emc.com [128.221.11.32]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g9M0kYH14819 for ; Mon, 21 Oct 2002 20:46:34 -0400 (EDT) Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Mon, 21 Oct 2002 20:46:29 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C42A@CORPMX14> From: Black_David@emc.com To: ramesh@global.com, ips@ece.cmu.edu Subject: RE: question on reserve and release ! Date: Mon, 21 Oct 2002 20:46:23 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk > > I have a question on how iscsi will handle the scsi reserve > > and release commands. > > > > When multiple iscsi initiators make calls to the same iscsi > > target, the actual scsi device only sees one single scsi id > > (that of the scsi HBA on the iscsi target machine). This > > would mean that different iscsi initiators sending scsi reserve > > command will be interpreted by the scsi target as commands > > from the same scsi initiator. Which in turn would mean that the implementation of the iscsi to parallel scsi gateway is broken. SCSI is *not* an end to end protocol whose CDBs can be transparently passed through when changing transports. For this example, the iscsi to scsi gateway either has to present multiple initiators to the target or has to implement the reserve and release functionality itself on behalf of the target (which should then not be connected externally via any means other than this gateway). Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 **NEW** FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- From owner-ips@ece.cmu.edu Tue Oct 22 14:02:33 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28497 for ; Tue, 22 Oct 2002 14:02:33 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g9MHJ7b16416 for ips-outgoing; Tue, 22 Oct 2002 13:19:07 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail15a.boca15-verio.com (mail15a.boca15-verio.com [208.55.91.57]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g9MHJ4H16405 for ; Tue, 22 Oct 2002 13:19:05 -0400 (EDT) Received: from www.matissenetworks.com (208.55.237.148) by mail15a.boca15-verio.com (RS ver 1.0.63s) with SMTP id 092718 for ; Tue, 22 Oct 2002 13:18:59 -0400 (EDT) From: "YP Cheng" To: Subject: RE: question on reserve and release ! Date: Tue, 22 Oct 2002 10:18:45 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <277DD60FB639D511AC0400B0D068B71E0564C42A@CORPMX14> X-Loop-Detect: 1 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit > > When multiple iscsi initiators make calls to the same iscsi > > target, the actual scsi device only sees one single scsi id > > (that of the scsi HBA on the iscsi target machine). This > > would mean that different iscsi initiators sending scsi reserve > > command will be interpreted by the scsi target as commands > > from the same scsi initiator. > Which in turn would mean that the implementation of the iscsi to > parallel scsi gateway is broken. SCSI is *not* an end to end > protocol whose CDBs can be transparently passed through when > changing transports. For this example, the iscsi to scsi gateway > either has to present multiple initiators to the target or has > to implement the reserve and release functionality itself on > behalf of the target (which should then not be connected externally > via any means other than this gateway). I'm confused by the above statements. In a selection phase of parallel SCSI, one does know the Host ID bit on the SCSI bus. Hence, only one initiator can reserve at a time. Others gets "Reserve Conflict - Status 08". For iSCSI, different initiators have their own respective sessions. The iSCSI to parallel SCSI gateway can easily emulating a Host ID bit - although it would need multiple logical SCSI busses when the number of initiators exceeds 15 on a wide SCSI bus. Y.P. Cheng Chief Scientist, Matisse Networks. From owner-ips@ece.cmu.edu Tue Oct 22 14:52:28 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00339 for ; Tue, 22 Oct 2002 14:52:28 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g9MIcjt22457 for ips-outgoing; Tue, 22 Oct 2002 14:38:45 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail15a.boca15-verio.com (mail15a.boca15-verio.com [208.55.91.57]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g9MIchH22453 for ; Tue, 22 Oct 2002 14:38:43 -0400 (EDT) Received: from www.matissenetworks.com (208.55.237.148) by mail15a.boca15-verio.com (RS ver 1.0.63s) with SMTP id 090433 for ; Tue, 22 Oct 2002 14:38:31 -0400 (EDT) From: "YP Cheng" To: Subject: RE: iSCSI: question on reserve and release ! Date: Tue, 22 Oct 2002 11:38:17 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: X-Loop-Detect: 1 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit It is not very practical to try and map 10's or 100's of iSCSI hosts to 15 bits on a parallel SCSI bus. The gateway can maintain additional reserve/release state and filter the commands thru the gateway to make this work properly. Basically the gateway ends up maintaining the reservation for the parallel SCSI device. John Tyndall I am in agreement with the above statement. With the recommended implementation, the gateway device of iSCSI to parallel SCSI becomes a "broker" who on behalf of many initiators does a single reservation to the target device. As far as the target device is concerned, it still deals with 15 maximum possible initiators. Y.P. Cheng Chief Scientist, Matisse Networks. From owner-ips@ece.cmu.edu Tue Oct 22 14:52:29 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00353 for ; Tue, 22 Oct 2002 14:52:29 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g9MIGTq20761 for ips-outgoing; Tue, 22 Oct 2002 14:16:29 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mc.va3.ummail.com (mc.va3.ummail.com [66.187.242.22]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g9MIGQH20754 for ; Tue, 22 Oct 2002 14:16:26 -0400 (EDT) Received: from hqmailweb.Crossroads.com ( [65.68.235.6:25]) by mc.va3.ummail.com with SMTP id J1022-1416-6a8800; Tue, 22 Oct 2002 18:16:19 GMT Received: from HQMAILNODE1.COMMSTOR.Crossroads.com ([10.5.1.42]) by hqmailweb.Crossroads.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 22 Oct 2002 13:16:18 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: question on reserve and release ! X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Tue, 22 Oct 2002 13:16:17 -0500 Message-ID: Thread-Topic: question on reserve and release ! Thread-Index: AcJ59cblrqlye9yvTFW1DMgPX9rzrAAAHA5w From: "John Tyndall" To: "YP Cheng" , X-OriginalArrivalTime: 22 Oct 2002 18:16:18.0167 (UTC) FILETIME=[1DAEC070:01C279F7] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id g9MIGQH20755 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit It is not very practical to try and map 10's or 100's of iSCSI hosts to 15 bits on a parallel SCSI bus. The gateway can maintain additional reserve/release state and filter the commands thru the gateway to make this work properly. Basically the gateway ends up maintaining the reservation for the parallel SCSI device. John Tyndall Architect Crossroads Systems Inc. Email : jtyndall@crossroads.com Phone : 512-928-7282 -----Original Message----- From: YP Cheng [mailto:ycheng@matissenetworks.com] Sent: Tuesday, October 22, 2002 12:19 PM To: ips@ece.cmu.edu Subject: RE: question on reserve and release ! > > When multiple iscsi initiators make calls to the same iscsi target, > > the actual scsi device only sees one single scsi id (that of the > > scsi HBA on the iscsi target machine). This would mean that > > different iscsi initiators sending scsi reserve command will be > > interpreted by the scsi target as commands from the same scsi > > initiator. > Which in turn would mean that the implementation of the iscsi to > parallel scsi gateway is broken. SCSI is *not* an end to end protocol > whose CDBs can be transparently passed through when changing > transports. For this example, the iscsi to scsi gateway either has to > present multiple initiators to the target or has to implement the > reserve and release functionality itself on behalf of the target > (which should then not be connected externally via any means other > than this gateway). I'm confused by the above statements. In a selection phase of parallel SCSI, one does know the Host ID bit on the SCSI bus. Hence, only one initiator can reserve at a time. Others gets "Reserve Conflict - Status 08". For iSCSI, different initiators have their own respective sessions. The iSCSI to parallel SCSI gateway can easily emulating a Host ID bit - although it would need multiple logical SCSI busses when the number of initiators exceeds 15 on a wide SCSI bus. Y.P. Cheng Chief Scientist, Matisse Networks. From owner-ips@ece.cmu.edu Tue Oct 22 17:48:20 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05747 for ; Tue, 22 Oct 2002 17:48:20 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g9MLAV104507 for ips-outgoing; Tue, 22 Oct 2002 17:10:31 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g9MLASH04492 for ; Tue, 22 Oct 2002 17:10:29 -0400 (EDT) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g9MLAKxF021805 for ; Tue, 22 Oct 2002 14:10:20 -0700 (PDT) Received: from nisser.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id g9MLAKR6014573 for ; Tue, 22 Oct 2002 14:10:22 -0700 (PDT) Received: from cisco.com (mbakke-lnx2.cisco.com [64.101.211.59]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id OAA18533 for ; Tue, 22 Oct 2002 14:10:19 -0700 (PDT) Message-ID: <3DB5BEBB.867ED03D@cisco.com> Date: Tue, 22 Oct 2002 16:10:19 -0500 From: Mark Bakke X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.9-34.cisco.2 i686) X-Accept-Language: en, de MIME-Version: 1.0 To: IPS Subject: IPS: iSCSI MIB last call Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Since I haven't seen any other last call comments on the iSCSI MIB yet, I have one (technical) comment: The iscsiTgtAuthAttributesTable is used to match up iSCSI targets with lists of identities in the Auth MIB to which the target will allow access. Currently, any identity in the list for a target will be authorized to have presumable full access to the iSCSI target, other than anything that may be enforced at higher layers (SCSI). One thing we might want to consider is to allow these entries to specify whether the identity will be given read-only or read-write access to the target, perhaps something like: iscsiTgtAuthReadWrite OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "A truth value that specifies whether the referenced AuthIdentity will be allowed write access to the target. False (=No) indicates that only read operations may be performed. True (=Yes) indicates that all access is allowed." DEFVAL { true } ::= { iscsiNodeAttributesEntry 13 } Thoughts? -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Tue Oct 22 21:50:34 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11735 for ; Tue, 22 Oct 2002 21:50:34 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g9N172k17346 for ips-outgoing; Tue, 22 Oct 2002 21:07:02 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ariel.nishansystems.com (ultrex.nishansystems.com [12.36.127.195]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g9N171H17341 for ; Tue, 22 Oct 2002 21:07:01 -0400 (EDT) Received: by ariel.nishansystems.com with Internet Mail Service (5.5.2653.19) id ; Tue, 22 Oct 2002 18:06:50 -0700 Message-ID: From: Joshua Tseng To: Joshua Tseng , ips@ece.cmu.edu Cc: "'Elizabeth Rodriguez'" , "'Black_David@emc.com'" Subject: RE: iSNS: Last Call comments Date: Tue, 22 Oct 2002 18:06:42 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Hi Folks, Here is the resolution of the technical comments that I posted for iSNS. Regards, Josh > -----Original Message----- > From: Joshua Tseng [mailto:jtseng@NishanSystems.com] > Sent: Sunday, October 13, 2002 9:52 AM > To: ips@ece.cmu.edu > Cc: 'Elizabeth Rodriguez' > Subject: iSNS: Last Call comments > > > Hi Folks, > > Here is a summary of technical last call comments against the > iSNS spec -13: > > 1) There needs to be a way to scope the DevGetNext message. > Recommend > that non-zero-length TLV's may be included as the first > operating attributes > of the DevGetNext message. They would be used to scope the DevGetNext > message. Zero-length TLV's that follow would specify the attributes > of the next object that need to be returned in the response > message. If > there are no non-zero-length TLV attributes, then the > DevGetNext message > is unscoped, as specified in previous iSNS spec revisions. The following text has been added to section 6.6.5.3 to allow scoping of DevGetNext messages: Non-zero-length TLV attributes in the Operating Attributes are used to scope the DevGetNext message. Only the next object with attribute values that match the non-zero-length TLV attributes SHALL be returned in the DevGetNext response message. Zero-length TLV attributes MUST be listed after non-zero-length attributes in the operating attributes of the DevGetNext request message. Zero-length TLV attributes specify the attributes of the next object that are to be returned in the DevGetNext response message. > > Also for the DevGetNext message, it is ambiguous as to > whether attributes > of other objects other than the next object, can be returned > in the message. The following text has been added to section 6.6.5.3 to remove this ambiguity. Only attributes of the object specified by the Message Key may be listed in the operating attributes. The Operating Attributes can be used specify the scope of the DevGetNext request, and specify the attributes of the next object that are to be returned in the DevGetNext response message. All operating attributes MUST be attributes of the object type identified by the Message Key. For example, if the Message Key is an Entity_ID attribute, then the operating attributes MUST NOT contain attributes of Portals. > > 2) In order to better integrate with SNMP, we need a method to query > for the next available index attribute. Recommend a virtual > attribute for > Entity, Portal, and iSCSI Node that always returns the value > of the next > available "Index" attribute for that object. This virtual attribute > would only be used for queries, and it would be an error to attempt to > register a value for this attribute. The following "virtual" attributes have been added with the corresponding tag values: Entity Next Index 8 Portal Next Index 24 iSCSI Node Next Index 38 > > 3) Why is the registration period only 2 bytes, when the attribute > length is 4 bytes? Recommend that the registration period > use all 4 bytes, > not just 2 bytes. The spec has been changed so that all four bytes are used for the Registration Period. > > 5) Spec needs to say that the iSNS server may reject iSNS messages > with incompatible message version numbers in the iSNS message header. The following sentence has been added to section 6.1.1. The iSNS server MAY reject messages for iSNSP version numbers that it does not support. > > 6) Section 7.l2.5 should clarify that "Protocol Version" refers to > block storage protocols. The first sentence of 7.2.5 now refers to "block storage protocols". > > 7) Clarify that if a query requests an attribute for which the iSNS > server has no value, then the server SHALL not return the requested > attribute in the query response. Such query and response messages > SHALL NOT be considered to be in error. The following text has been added to section 6.6.5.2: If a DevAttrQry message requests an attribute for which the iSNS server has no value, then the server SHALL NOT return the requested attribute in the query response. Such query and response messages SHALL NOT be considered to be in error. > > 8) The format of the DevAttrRegRsp message in section 6.7.5.1 seems > inconsistent. The message key attributes seems to contain the same > thing as the operating attributes. The message key should contain the > same attribute as the original registration message. > The second paragraph of section 6.7.5.1 has been replaced with the following: The Message Key in the DevAttrRegRsp message SHALL return the Message Key in the original registration message. If the iSNS server assigned the Entity Identifier for a network entity, then the Message Key Attribute field SHALL contain the assigned Entity Identifier. From owner-ips@ece.cmu.edu Wed Oct 23 10:40:17 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06870 for ; Wed, 23 Oct 2002 10:40:17 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g9NDuHr04144 for ips-outgoing; Wed, 23 Oct 2002 09:56:17 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cygnus.equallogic.com (cygnus.equallogic.com [65.170.102.10]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g9NDuGH04140 for ; Wed, 23 Oct 2002 09:56:16 -0400 (EDT) Received: from cygnus.equallogic.com (localhost.localdomain [127.0.0.1]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g9NDuAf08285 for ; Wed, 23 Oct 2002 09:56:10 -0400 Received: from deneb.dev.equallogic.com (deneb.dev.equallogic.com [172.16.1.99]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g9NDuAX08279 for ; Wed, 23 Oct 2002 09:56:10 -0400 Received: from pkoning.dev.equallogic.com.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.6) with ESMTP id g9NDdqj10182; Wed, 23 Oct 2002 09:40:12 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15798.42663.954683.588205@pkoning.dev.equallogic.com> Date: Wed, 23 Oct 2002 09:39:51 -0400 From: Paul Koning To: mbakke@cisco.com Cc: ips@ece.cmu.edu Subject: Re: IPS: iSCSI MIB last call References: <3DB5BEBB.867ED03D@cisco.com> X-Mailer: VM 7.07 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit >>>>> "Mark" == Mark Bakke writes: Mark> Since I haven't seen any other last call comments on the iSCSI Mark> MIB yet, I have one (technical) comment: Mark> The iscsiTgtAuthAttributesTable is used to match up iSCSI Mark> targets with lists of identities in the Auth MIB to which the Mark> target will allow access. Currently, any identity in the list Mark> for a target will be authorized to have presumable full access Mark> to the iSCSI target, other than anything that may be enforced Mark> at higher layers (SCSI). One thing we might want to consider Mark> is to allow these entries to specify whether the identity will Mark> be given read-only or read-write access to the target, perhaps Mark> something like: Mark> iscsiTgtAuthReadWrite OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS Mark> read-write STATUS current DESCRIPTION "A truth value that Mark> specifies whether the referenced AuthIdentity will be allowed Mark> write access to the target. False (=No) indicates that only Mark> read operations may be performed. True (=Yes) indicates that Mark> all access is allowed." DEFVAL { true } ::= { Mark> iscsiNodeAttributesEntry 13 } Mark> Thoughts? I brought this up around here a while ago, and the reaction was that this isn't all that useful. The argument is that per-initiator access control is for controlling shared access to a target. As a rule, operating systems support multiple readers, or (in things like clusters) multiple initiators with full access, but not a mix of readers and writers. paul From owner-ips@ece.cmu.edu Wed Oct 23 13:01:28 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25524 for ; Wed, 23 Oct 2002 13:01:27 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g9NGJJo18347 for ips-outgoing; Wed, 23 Oct 2002 12:19:19 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g9NGJCH18303 for ; Wed, 23 Oct 2002 12:19:12 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 5005530706; Wed, 23 Oct 2002 12:19:11 -0400 (EDT) Date: Wed, 23 Oct 2002 09:17:42 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Mark Bakke Cc: IPS Subject: Re: IPS: iSCSI MIB last call In-Reply-To: <3DB5BEBB.867ED03D@cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Tue, 22 Oct 2002, Mark Bakke wrote: > Since I haven't seen any other last call comments on the > iSCSI MIB yet, I have one (technical) comment: > > The iscsiTgtAuthAttributesTable is used to match up iSCSI > targets with lists of identities in the Auth MIB to which > the target will allow access. Currently, any identity in > the list for a target will be authorized to have presumable > full access to the iSCSI target, other than anything that > may be enforced at higher layers (SCSI). One thing we might > want to consider is to allow these entries to specify > whether the identity will be given read-only or read-write > access to the target, perhaps something like: > > iscsiTgtAuthReadWrite OBJECT-TYPE > SYNTAX TruthValue > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "A truth value that specifies whether the referenced > AuthIdentity will be allowed write access to the target. > False (=No) indicates that only read operations may be > performed. True (=Yes) indicates that all access is > allowed." > DEFVAL { true } > ::= { iscsiNodeAttributesEntry 13 } > > Thoughts? Sounds interesting. Another thought I had was to add a session-type field. It would be Normal-Only, Discovery-Only, or Both. This feature is designed to permit having "closed" targets (where the target isn't seen in discovery, like closed 802.11 networks), and also to permit anyone to do discovery (ipsAuthMethodNone is in the auth entry) & find the target, but not let everyone access the target. Take care, Bill From owner-ips@ece.cmu.edu Wed Oct 23 16:30:12 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04415 for ; Wed, 23 Oct 2002 16:30:11 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g9NJpu004080 for ips-outgoing; Wed, 23 Oct 2002 15:51:56 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from atlrel7.hp.com (atlrel7.hp.com [156.153.255.213]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g9NJpoH04063 for ; Wed, 23 Oct 2002 15:51:50 -0400 (EDT) Received: from xatlrelay2.atl.hp.com (xatlrelay2.atl.hp.com [15.45.89.191]) by atlrel7.hp.com (Postfix) with ESMTP id BB1238054F1; Wed, 23 Oct 2002 15:51:49 -0400 (EDT) Received: from xatlbh1.atl.hp.com (xatlbh1.atl.hp.com [15.45.89.186]) by xatlrelay2.atl.hp.com (Postfix) with ESMTP id 3EE714000B4; Wed, 23 Oct 2002 15:51:49 -0400 (EDT) Received: by xatlbh1.atl.hp.com with Internet Mail Service (5.5.2655.55) id <47R96C12>; Wed, 23 Oct 2002 15:51:49 -0400 Message-ID: <6BD67FFB937FD411A04F00D0B74FE878102F5CC3@xrose06.rose.hp.com> From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" To: "'Bill Studenmund'" , Mark Bakke Cc: IPS Subject: RE: IPS: iSCSI MIB last call Date: Wed, 23 Oct 2002 15:51:31 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain Sender: owner-ips@ece.cmu.edu Precedence: bulk > Another thought I had was to add a session-type field. It > would be Normal-Only, Discovery-Only, or Both. > > This feature is designed to permit having "closed" targets > (where the target isn't seen in discovery, like closed 802.11 > networks), and also to permit anyone to do discovery > (ipsAuthMethodNone is in the auth entry) & find the target, > but not let everyone access the target. If something like this were added, there would have to be a way to indicate at the iSCSI target node level whether this is an "open" or "closed" target - this becomes the default for unlisted initiators. In a "closed" target, only initiators which are in the ACL are allowed to open a session, and then which session type is allowed depends on an attribute of the auth entry for this initiator. In an "open" target, by default initiators not listed in the ACL are allowed to open a discovery session. That said, I don't like adding something this significant this late in the process, because it really requires more thorough examination of the entire structure of both MIBs. Seems like this should be addressed in a separate draft? Marjorie From owner-ips@ece.cmu.edu Wed Oct 23 16:32:15 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04506 for ; Wed, 23 Oct 2002 16:32:15 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g9NK9gx07407 for ips-outgoing; Wed, 23 Oct 2002 16:09:42 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g9NK9bH07395 for ; Wed, 23 Oct 2002 16:09:37 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 06D9930706; Wed, 23 Oct 2002 16:09:37 -0400 (EDT) Date: Wed, 23 Oct 2002 13:08:09 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: "KRUEGER,MARJORIE (HP-Roseville,ex1)" Cc: Mark Bakke , IPS Subject: RE: IPS: iSCSI MIB last call In-Reply-To: <6BD67FFB937FD411A04F00D0B74FE878102F5CC3@xrose06.rose.hp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Wed, 23 Oct 2002, KRUEGER,MARJORIE (HP-Roseville,ex1) wrote: > > Another thought I had was to add a session-type field. It > > would be Normal-Only, Discovery-Only, or Both. > > > > This feature is designed to permit having "closed" targets > > (where the target isn't seen in discovery, like closed 802.11 > > networks), and also to permit anyone to do discovery > > (ipsAuthMethodNone is in the auth entry) & find the target, > > but not let everyone access the target. > > If something like this were added, there would have to be a way to indicate > at the iSCSI target node level whether this is an "open" or "closed" target > - this becomes the default for unlisted initiators. In a "closed" target, > only initiators which are in the ACL are allowed to open a session, and then > which session type is allowed depends on an attribute of the auth entry for > this initiator. In an "open" target, by default initiators not listed in > the ACL are allowed to open a discovery session. Ahhh... Part of my understanding, based on comments in the iSCSI draft's discussion of SendTargets, was that all targets were "closed" by default. > That said, I don't like adding something this significant this late in the > process, because it really requires more thorough examination of the entire > structure of both MIBs. Seems like this should be addressed in a separate > draft? Yep. I think only the iSCSI MIB needs it, but reviewing both would be good before doing this. Take care, Bill From owner-ips@ece.cmu.edu Wed Oct 23 16:34:29 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04553 for ; Wed, 23 Oct 2002 16:34:29 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g9NJg9E02144 for ips-outgoing; Wed, 23 Oct 2002 15:42:09 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel12.hp.com (palrel12.hp.com [156.153.255.237]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g9NJg5H02132 for ; Wed, 23 Oct 2002 15:42:05 -0400 (EDT) Received: from xparelay1.ptp.hp.com (xparelay1.ptp.hp.com [15.1.28.62]) by palrel12.hp.com (Postfix) with ESMTP id C5543E004C2; Wed, 23 Oct 2002 12:41:58 -0700 (PDT) Received: from xpabh3.ptp.hp.com (xpabh3.ptp.hp.com [15.1.28.63]) by xparelay1.ptp.hp.com (Postfix) with ESMTP id BD60CE000A8; Wed, 23 Oct 2002 12:41:58 -0700 (PDT) Received: by xpabh3.ptp.hp.com with Internet Mail Service (5.5.2655.55) id <44NKYAKD>; Wed, 23 Oct 2002 12:41:58 -0700 Message-ID: <6BD67FFB937FD411A04F00D0B74FE878102F5CC2@xrose06.rose.hp.com> From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" To: "'Mark Bakke'" , IPS Subject: RE: iSCSI MIB last call Date: Wed, 23 Oct 2002 12:41:46 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain Sender: owner-ips@ece.cmu.edu Precedence: bulk I don't think that sort of function should be provided at the SCSI transport layer since it's not something that's defined by SCSI as a feature of it's transport. It would be a wart on the iSCSI transport (IMO). Read/write access should be controlled by the SCSI or file system layer. Marj > -----Original Message----- > From: Mark Bakke [mailto:mbakke@cisco.com] > Sent: Tuesday, October 22, 2002 2:10 PM > To: IPS > Subject: IPS: iSCSI MIB last call > > > > Since I haven't seen any other last call comments on the > iSCSI MIB yet, I have one (technical) comment: > > The iscsiTgtAuthAttributesTable is used to match up iSCSI > targets with lists of identities in the Auth MIB to which the > target will allow access. Currently, any identity in the > list for a target will be authorized to have presumable full > access to the iSCSI target, other than anything that may be > enforced at higher layers (SCSI). One thing we might want to > consider is to allow these entries to specify whether the > identity will be given read-only or read-write access to the > target, perhaps something like: > > iscsiTgtAuthReadWrite OBJECT-TYPE > SYNTAX TruthValue > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "A truth value that specifies whether the referenced > AuthIdentity will be allowed write access to the target. > False (=No) indicates that only read operations may be > performed. True (=Yes) indicates that all access is > allowed." > DEFVAL { true } > ::= { iscsiNodeAttributesEntry 13 } > > Thoughts? > > -- > Mark A. Bakke > Cisco Systems > mbakke@cisco.com > 763.398.1054 > From owner-ips@ece.cmu.edu Wed Oct 23 21:39:40 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11392 for ; Wed, 23 Oct 2002 21:39:40 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g9O0mSM24674 for ips-outgoing; Wed, 23 Oct 2002 20:48:28 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic2.corp.emc.com (mxic2.us.dg.com [128.221.31.40]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g9O0mOH24665 for ; Wed, 23 Oct 2002 20:48:24 -0400 (EDT) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Wed, 23 Oct 2002 20:48:14 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C465@CORPMX14> From: Black_David@emc.com To: jtseng@NishanSystems.com, ips@ece.cmu.edu Subject: RE: iSNS: Responses to David Black Technical Comments Date: Wed, 23 Oct 2002 20:48:10 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Josh, Most of the responses are fine, but there's one major issue (iSNS Backup servers) and several minor issues, one of which is unfortunately new and affects IP address formats. Thanks, --David -- iSNS Backup Servers -- > > If a backup server establishes that it has lost connectivity to the > > active server and other backup servers of higher precedence, then it > > shall assume that it is the active server. The method of > > determining whether connectivity has been lost is implementation- > > specific. One possible approach is to assume that if the backup > > server does not receive iSNS hearbeat messages for a period of time, > > then connectivity to the active server has been lost. Alternately, > > the backup server may establish TCP connections to the active server > > and other backup servers, and loss of connectivity determined > > through non-response to periodic echo messages (using iSNSP, SNMP, > > or other protocols). > > > > "shall" --> "SHOULD", but this is a disaster waiting to happen, as different > > iSNS implementations will get this just different enough that the result > > will be split-brain (more than one server believing it's primary) on loss > > of communication. This area is *hard* to get right (what's needed here > > is an HA cluster coordination protocol) - an expedient way out for now > > may be to limit support to one primary and one backup. > > Done. Your comment is noted, and that is why I left the method for > determining election/re-election of the primary server up to the specific > implementation. Yes, an HA cluster protocol would be ideal, but not > necessarily required in all situations. I remain concerned that the text here not only allows, but may encourage building iSNS backup in a fashion that will fail split-brain with potentially disastrous consequences. On further reading, the thing to do may be to modify the following sentence: Therefore, it is beyond the scope of this specification to facilitate more than a basic interoperability among failover mechanisms. to add specifics about what is and is not specified for interoperability. What is specified is: - Client behavior and protocol interaction in the presence of multiple iSNS servers, some of which are Backup iSNS servers. - Required failover behaviors of the collection of iSNS servers that includes Active and Backup servers. What is not specified is: - Complete functional failover requirements on each iSNS server and the protocols needed for a collection of iSNS servers to realize the required failover behaviors in an interoperable fashion. While it's missing some aspects of interoperability, I think getting the client foundation in place that allows failover to a backup server is important enough to be worth including, even at the expense of not mixing different iSNS implementations in a collection of Active/Backup servers. -- Minor Issues -- > > > > -- Section 6.6.5.3 > > > > Add a discussion of what happens if the iSNS database is updated during > > a sequence of GetNext operations. Is it possible to lose one's place > > if an object is deleted? How is a client expected to cope with this? > > The following text has been added to the end of section 6.6.5.3: Added text snipped - it's ok. Unless I missed it somewhere a sentence is needed saying that the iSNS database MUST have an implicit internal linear order of entries. This is needed to give a meaning to words like "after", "next" and "following" in this section. It also might be good to say than an iSNS database SHOULD NOT be reorganized with respect to that implied order as a consequence of insertions and deletions (i.e., relative order of entries that remain in the database SHOULD be preserved so that GetNext encounters generally reasonable behavior). > > -- Section 7 > > > > This looks like it should be retitled to IANA Considerations, with all of > > this stuff going into registries, and the section needs to be expanded to > > include things like the BSD from Section 6.5. Some of the material in > > the table in Section 7.1 may not be appropriate for an IANA registry, > > though. > > A new IANA Considerations section has been inserted as section 9, as shown > below: Good start, but instructions to IANA for handling additions are missing. Please see RFC 2434 for information on what needs to be in this section. > > -- Section 7.2.1 > > > > 7.2.1 Entity Identifier (EID) > > > > The Entity Identifier (EID) is a variable-length field containing > > user-readable UTF-8 text, and is terminated with at least one NULL > > character. variable length identifier This field uniquely > > identifies each network entity registered in the iSNS server. > > > > Does this need to be stringprep'ed? "variable length identifier" looks > > like it escaped from previous editing. Check all other UTF-8 attributes > > for possible needs for stringprep. > > Variable-length fields that are used as key attributes (i.e., EID, iSCSI Name) > need to be stringprep-ed. Those that are not key attributes are used as > descriptive fields, and so do not need to be normalized. The following text > will be added to each variable-length field that is used as a > primary key: > > This attribute MUST be normalized according to the stringprep template > [STRINGPREP] before it is stored in the iSNS database. > > Note that since we are now using the stringprep document generically, not just > for iSCSI names, then I would suggest removing the iSCSI label for that > document. Ok, let's consider that a late WG Last Call comment against the iSCSI stringprep draft - please contact Mark Bakke directly about revising it. > > -- Section 7.2.3 > > > > This field contains the IP Address used to manage the Network Entity > > and all Storage Nodes contained therein. The Management IP Address > > is a 16-byte field that may contain either a 32-bit IPv4 or 128-bit > > IPv6 address. When this field contains an IPv4 value, the most > > significant 12 bytes are set to 0x00. When this field contains an > > IPv6 value, the entire 16-byte field is used. If the network entity > > is capable of being managed and this field is not set, then in-band > > management through the IP address of one of the Portals of the > > Network Entity is assumed. > > > > What is this IP address used for? Why is an IP address, as opposed to > > an IP address plus TCP or UDP port? > > Both IP address and TCP/UDP Port are required to identify a Portal. The > Portal object is therefore referenced by two attributes--its primary > key has two fields. The IP address alone is insigificant--it must be > accompanied by the TCP/UDP Port Number to have any meaning in iSNS. But this is the Management IP address and I don't see a Management IP Port - did I miss something? The phrases "used to manage" and "capable of being managed" need to be defined - if this means SNMP, say so. Also, I don't see any external way of indicating whether the address is IPv4 or IPv6, and hence I believe Section 2.5.4 of RFC 2373 applies to IP addresses in iSNS - unfortunately, the convention that's currently being used for address formats implies that all IPv4 addresses in iSNS are for IPv6-capable nodes, which is probably not what was intended (sorry for the late catch on this one, but better now than to have one of the ADs find it). > > -- Section 7.2.7 > > > > The Entity Index is a 4-byte integer value that uniquely identifies > > each network entity registered in the iSNS server. The Entity Index > > is assigned by the iSNS server during the initial registration of an > > Entity. It can be used to represent a registered entity in > > situations where the Entity Identifier is too long to be used. > > > > Explain the requirements on "uniquely identifies", in particular rules > > about if/when an iSNS server can reuse an Entity Index value. > > Same comment applies to Portal Index (Section 7.3.7) and iSCSI Node Index > > (Section 7.4.5). > > The text for 7.2.7 has been modified as follows: > > The Entity Index is a 4-byte integer value that uniquely identifies each > network entity registered in the iSNS server. Upon initial registration of > an Entity, the iSNS server assigns an unused value for the Entity Index for > that Entity. Each Entity in the iSNS database MUST be assigned a value for > the Entity Index that is not assigned to any other Entity. The Entity Index > MAY be used to represent the Entity in situations when the Entity Identifier > is too long or otherwise inappropriate. That takes care of assignment, what about reuse? Short-term reuse SHOULD NOT be done, as it's an invitation to confusion in places where the Entity Index has been used. Similarly for 7.3.7 and 7.4.5. From owner-ips@ece.cmu.edu Thu Oct 24 18:30:18 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25852 for ; Thu, 24 Oct 2002 18:30:18 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g9OLc8n01119 for ips-outgoing; Thu, 24 Oct 2002 17:38:08 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g9OLJOH29746 for ; Thu, 24 Oct 2002 17:19:39 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24031; Thu, 24 Oct 2002 17:17:03 -0400 (EDT) Message-Id: <200210242117.RAA24031@ietf.org> To: IETF-Announce: ; Cc: ips@ece.cmu.edu From: The IESG SUBJECT: Last Call: Securing Block Storage Protocols over IP to Proposed Standard Reply-to: iesg@ietf.org Date: Thu, 24 Oct 2002 17:17:03 -0400 Sender: owner-ips@ece.cmu.edu Precedence: bulk The IESG has received a request from the IP Storage Working Group to consider Securing Block Storage Protocols over IP as a Proposed Standard. 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 2002-11-7. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ips-security-16.txt From owner-ips@ece.cmu.edu Thu Oct 24 20:14:07 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27788 for ; Thu, 24 Oct 2002 20:14:07 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g9ONU4908500 for ips-outgoing; Thu, 24 Oct 2002 19:30:04 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from maho3msx2.isus.emc.com (maho3msx2.isus.emc.com [128.221.11.32]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g9ONU1H08494 for ; Thu, 24 Oct 2002 19:30:01 -0400 (EDT) Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Thu, 24 Oct 2002 19:29:48 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C47B@CORPMX14> From: Black_David@emc.com To: ips@ece.cmu.edu Subject: Atlanta meeting times Date: Thu, 24 Oct 2002 19:29:44 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Some people may have noticed that the meeting time for the IPS WG on the draft IETF agenda for Atlanta has stayed in the same place for a while and may be assuming that it will stay put. That could be a bad assumption - we are still a week or more away from a final schedule, and this is about the point in the scheduling process where the fact that scheduling in the presence of conflicts is an NP-complete problem rears its ugly head. WG meeting times aren't final until the final agenda comes out, and that's still a week or more away. Having been inconvenienced by this in the past, I thought I'd warn those making travel plans. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 **NEW** FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- From owner-ips@ece.cmu.edu Fri Oct 25 20:19:07 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16485 for ; Fri, 25 Oct 2002 20:19:06 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g9PNnpi21637 for ips-outgoing; Fri, 25 Oct 2002 19:49:51 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic2.corp.emc.com (mxic2.us.dg.com [128.221.31.40]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g9PNnoH21633 for ; Fri, 25 Oct 2002 19:49:50 -0400 (EDT) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Fri, 25 Oct 2002 19:49:45 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C490@CORPMX14> From: Black_David@emc.com To: ips@ece.cmu.edu Subject: New list of nits for IDs being submitted to the IESG Date: Fri, 25 Oct 2002 19:49:42 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk This IESG memo should show up on the IETF web site soon as a supplement to or replacement for http://www.ietf.org/ID-nits.html, but I thought I'd post it here now, as we have a number of drafts that are currently in need of nit-checking. Thanks, --David --------------------------------------------------------------- AD Review of I-Ds Date: October 4, 2002 All Internet Drafts which are offered for publication as RFCs must conform to the following requirements or they will be returned to the author(s) for revision The WG Chairs are responsible for having this list checked before submission to the ADs. The content issues have to be checked early in the development of documents, being technically integral. The WG Chairs are responsible for this. The ADs will check the list before submission to the IESG. Responsibility for all checking is with the authors the case of an individual submission. 1. Form nits: 1.1 Formatting - See Section 3, "Instructions to RFC Authors" (draft-rfc-editor-rfc2223bis-02.txt) for details and further rules. - Not beyond the 72nd column of a line o This is especially important for diagrams and code, which the RFC Editor may not be able to trivially reformat to fall within the margins. - Must be ragged right - No hyphenation for line-breaks - No footnotes - ASCII-only, no control characters (other than CR, NL & FF) - Do not number the "Status of Memo" or Abstract sections - Do not add a numbered reference in the ID boilerplate to RFC 2026 (makes it harder for the RFC editor to process the document when they strip off the ID boilerplate) - Reasonably well formatted for readibility and clarity. - Use network byte order in diagrams (see draft-rfc-editor-rfc2223bis-02.txt section 3.4) 1.2 Required sections - all IDs - Internet Draft boilerplate o Must contain boilerplate that permits publication as an RFC (see http://www.ietf.org/ietf/1id-guidelines.txt) - List of authors/editors o There should not be > 5 authors/editors (see http://www.rfc-editor.org/policy.html) - Abstract - Table of Contents is required if > 15 pages - Introduction - Security Considerations - References o Must be split into normative and non-normative sections (see http://www.rfc-editor.org/policy.html) - Author's Address - IPR notices o From RFC 2026 sec 10.4 (A) and 10.4(B) and possibly 10.4(D) - Copyright Notice o From RFC 2026 sec 10.4(C) 1.3 Sometimes-required sections - IANA considerations o Required if IANA has to create a new registry or modify rules for an existing registry. o See RFC 2434, and also RFC 2780 in some cases. 2. Content issues - Abstract o Should be meaningful to someone not versed in the technology; most abbreviations must be expanded on first use o no citations o See: draft-rfc-editor-rfc2223bis-02.txt section 4.5. - Security Considerations section o Must have meaningful exploration of security issues raised by proposal, should include both risks and description of solutions or workarounds - If MUST etc used, the terms must be defined (or RFC 2119 referenced) o Also read RFC 2119 to see what it says about using MUST etc - Specific IPR (e.g., patent claims & terms) must not be in an RFC -- any claims must go to the IPR web page and notice that there is some IPR claim (RFC 2026 sec 10.4(D) must be included in the RFC - All user-visible text fields must be internationalizable o See RFC 2277. For most cases, this means UTF-8. o If text fields are included in some calculation, like matching, sorting etc, it must be described in detail how those operations are applied to the Unicode/ISO 10646 character set. see "stringprep" for more information on the recommended way of handling comparisons. - All MIBs must compile cleanly using "smilint -l 9" o An email service is available for the check. Extract the MIB form the document and send it in the body of an email to smilint@ibr.cs.tu-bs.de. - All ABNF must be checked. Tool available from www.apps.ietf.org o See RFC 2234 for information about IETF ABNF. Include reference to RFC 2234. - Addresses used in examples should prefer use of fully qualified domain names to literal IP addresses, prefer use of example fqdn's such as foo.example.com to real-world fqdn's. - References o All references must be stable and resolvable. o An HTTP URL only is not generally considered a stable reference; exceptions can be made in some cases o In case of references to I-Ds, use the format "title" (work in progress) (I-D name). Normative references to IDs will cause a standards-track or BCP document to wait for the referenced RFCs to be published. Non-normative references will have the I-D name stripped out by the RFC Editor. 3. Protocol Issues - Avoid IPv4 specificity, both IPv4 and IPv6 must be supportable - No application can cause catastrophic congestion. See RFC 2914 for details - applications using TCP or SCTP will normally fulfill this automatically. - If any sort of end-to-end checksum or integrity check is being used (especially, but not limited to, cryptographic checksums or MACs), specify precisely the contents of the fields to be checksummed, and exactly what order the operations are done in. Pay special attention to any area reserved for the checksum itself. From owner-ips@ece.cmu.edu Fri Oct 25 20:19:45 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16507 for ; Fri, 25 Oct 2002 20:19:45 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g9PNVsA20710 for ips-outgoing; Fri, 25 Oct 2002 19:31:54 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from hammer.brocade.com (sj6-b.brocade.com [63.121.140.220]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g9PNVpH20702 for ; Fri, 25 Oct 2002 19:31:51 -0400 (EDT) Received: from hq-ex-c3.brocade.com (hq-ex-c3.brocade.com [192.168.126.211]) by hammer.brocade.com (8.11.3/8.11.3) with ESMTP id g9PNVju26134 for ; Fri, 25 Oct 2002 16:31:45 -0700 (PDT) Received: by hq-ex-c3.brocade.com with Internet Mail Service (5.5.2653.19) id <4LH1VQQK>; Fri, 25 Oct 2002 16:31:46 -0700 Message-ID: From: Elizabeth Rodriguez To: ips@ece.cmu.edu Subject: IPS-ALL: Last Call: Securing Block Storage Protocols over IP to P roposed Standard Date: Fri, 25 Oct 2002 16:31:45 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C27C7E.AE64A470" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C27C7E.AE64A470 Content-Type: text/plain All, IETF Last Call has been issued on the IPS security draft. Discussion for IETF Last Call should take place on the IETF discussion mailing list. The IETF discussion mailing list archive is found at http://www1.ietf.org/mail-archive/ietf/Current/maillist.html You can subscribe to the discussion mailing list by sending a request to: ietf-request@ietf.org and enter the word subscribe in the Subject line of the message and in the message body. Elizabeth Rodriguez & David Black IPS co-chairs -----Original Message----- From: The IESG [mailto:iesg-secretary@ietf.org] Sent: Thursday, October 24, 2002 2:17 PM Cc: ips@ece.cmu.edu Subject: Last Call: Securing Block Storage Protocols over IP to Proposed Standard The IESG has received a request from the IP Storage Working Group to consider Securing Block Storage Protocols over IP as a Proposed Standard. 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 2002-11-7. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ips-security-16.txt ------_=_NextPart_001_01C27C7E.AE64A470 Content-Type: text/html Content-Transfer-Encoding: quoted-printable IPS-ALL: Last Call: Securing Block Storage Protocols over IP to = Proposed Standard

All,

IETF Last Call has been issued on the IPS security = draft.

Discussion for IETF Last Call should take place on = the IETF discussion mailing list.
The IETF discussion mailing list archive is found at = http://www1.ietf.org/mail-archive/ietf/Current/maillis= t.html
You can subscribe to the discussion mailing list by = sending a request to: ietf-request@ietf.org and enter the word = subscribe in the Subject line of the message and in the message body. =

Elizabeth Rodriguez & David Black
IPS co-chairs


-----Original Message-----
From: The IESG [mailto:iesg-secretary@ietf.org]
Sent: Thursday, October 24, 2002 2:17 PM
Cc: ips@ece.cmu.edu
Subject: Last Call: Securing Block Storage Protocols = over IP to Proposed
Standard



The IESG has received a request from the IP Storage = Working Group to
consider Securing Block Storage Protocols over = IP
<draft-ietf-ips-security-16.txt> as a Proposed = Standard.

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 = 2002-11-7.

Files can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-ips-sec= urity-16.txt



------_=_NextPart_001_01C27C7E.AE64A470-- From owner-ips@ece.cmu.edu Fri Oct 25 20:26:51 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16569 for ; Fri, 25 Oct 2002 20:26:51 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g9PNWaJ20747 for ips-outgoing; Fri, 25 Oct 2002 19:32:36 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from hammer.brocade.com (sj6-b.brocade.com [63.121.140.220]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g9PNWXH20740 for ; Fri, 25 Oct 2002 19:32:33 -0400 (EDT) Received: from hq-ex-c2.brocade.com (hq-ex-c2.brocade.com [192.168.126.35]) by hammer.brocade.com (8.11.3/8.11.3) with ESMTP id g9PNWSu26177 for ; Fri, 25 Oct 2002 16:32:28 -0700 (PDT) Received: by hq-ex-c2.brocade.com with Internet Mail Service (5.5.2653.19) id <4LHFDFC5>; Fri, 25 Oct 2002 16:32:28 -0700 Message-ID: From: Elizabeth Rodriguez To: Elizabeth Rodriguez , ips@ece.cmu.edu Subject: RE: IPS-ALL: FW: Last Call: FC Frame Encapsulation [+iFCP & FCIP] to Proposed Standard Date: Fri, 25 Oct 2002 16:32:27 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C27C7E.C7879430" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C27C7E.C7879430 Content-Type: text/plain Sorry -- This is the IETF Last Call. Not IETF WG last call... Elizabeth -----Original Message----- From: Elizabeth Rodriguez Sent: Friday, October 25, 2002 4:30 PM To: 'ips@ece.cmu.edu' Subject: IPS-ALL: FW: Last Call: FC Frame Encapsulation [+iFCP & FCIP] to Proposed Standard All, IETF WG last call has been issued on the Fibre Channel Encapsulation Draft, FCIP draft, and iFCP draft Discussion for IETF Last Call should take place on the IETF discussion mailing list. The IETF discussion mailing list archive is found at http://www1.ietf.org/mail-archive/ietf/Current/maillist.html You can subscribe to the discussion mailing list by sending a request to: ietf-request@ietf.org and enter the word subscribe in the Subject line of the message and in the message body. Elizabeth Rodriguez & David Black IPS co-chairs -----Original Message----- From: The IESG [mailto:iesg-secretary@ietf.org] Sent: Friday, October 25, 2002 8:03 AM Cc: ips@ece.cmu.edu Subject: Last Call: FC Frame Encapsulation to Proposed Standard The IESG has received a request from the IP Storage Working Group to consider publication of the following Internet-Drafts as Proposed Standards: o FC Frame Encapsulation o Fibre Channel Over TCP/IP (FCIP) o iFCP - A Protocol for Internet Fibre Channel Storage Networking 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 2002-11-7. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ips-fcencapsulation-08.txt http://www.ietf.org/internet-drafts/draft-ietf-ips-fcovertcpip-12.txt http://www.ietf.org/internet-drafts/draft-ietf-ips-ifcp-13.txt ------_=_NextPart_001_01C27C7E.C7879430 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: IPS-ALL: FW: Last Call: FC Frame Encapsulation [+iFCP & = FCIP] to Proposed Standard

Sorry --
This is the IETF Last Call.  Not IETF WG last = call...

Elizabeth

-----Original Message-----
From: Elizabeth Rodriguez
Sent: Friday, October 25, 2002 4:30 PM
To: 'ips@ece.cmu.edu'
Subject: IPS-ALL: FW: Last Call: FC Frame = Encapsulation [+iFCP & FCIP]
to Proposed Standard


All,

IETF WG last call has been issued on the
Fibre Channel Encapsulation Draft,
FCIP draft, and
iFCP draft

Discussion for IETF Last Call should take place on = the IETF discussion mailing list.
The IETF discussion mailing list archive is found at = http://www1.ietf.org/mail-archive/ietf/Current/maillis= t.html
You can subscribe to the discussion mailing list by = sending a request to: ietf-request@ietf.org and enter the word = subscribe in the Subject line of the message and in the message body. =

Elizabeth Rodriguez & David Black
IPS co-chairs

-----Original Message-----
From: The IESG [mailto:iesg-secretary@ietf.org]
Sent: Friday, October 25, 2002 8:03 AM
Cc: ips@ece.cmu.edu
Subject: Last Call: FC Frame Encapsulation to = Proposed Standard




The IESG has received a request from the IP Storage = Working Group to
consider publication of the following = Internet-Drafts as Proposed
Standards:


 o FC Frame Encapsulation = <draft-ietf-ips-fcencapsulation-08.txt>

 o Fibre Channel Over TCP/IP (FCIP) = <draft-ietf-ips-fcovertcpip-12.txt>

 o iFCP - A Protocol for Internet Fibre Channel = Storage Networking
   = <draft-ietf-ips-ifcp-13.txt>

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 = 2002-11-7.

Files can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-ips-fce= ncapsulation-08.txt
http://www.ietf.org/internet-drafts/draft-ietf-ips-fco= vertcpip-12.txt
http://www.ietf.org/internet-drafts/draft-ietf-ips-ifc= p-13.txt

------_=_NextPart_001_01C27C7E.C7879430-- From owner-ips@ece.cmu.edu Fri Oct 25 20:31:05 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16618 for ; Fri, 25 Oct 2002 20:31:02 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g9PNkac21453 for ips-outgoing; Fri, 25 Oct 2002 19:46:36 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mailhub.lss.emc.com (xdch.emc.com [168.159.1.79]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g9PNkYH21446 for ; Fri, 25 Oct 2002 19:46:34 -0400 (EDT) Received: from emc.com (emcmail.lss.emc.com [168.159.48.78]) by mailhub.lss.emc.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g9PNkJD05503 for ; Fri, 25 Oct 2002 19:46:19 -0400 (EDT) Received: from mxic1.isus.emc.com ([168.159.129.100]) by emc.com (8.10.1/8.10.1) with ESMTP id g9PNkI700859 for ; Fri, 25 Oct 2002 19:46:18 -0400 (EDT) Received: by MXIC1 with Internet Mail Service (5.5.2653.19) id ; Fri, 25 Oct 2002 19:46:18 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C48F@CORPMX14> From: Black_David@emc.com To: ips@ece.cmu.edu Subject: IPS WG Last Call results Date: Fri, 25 Oct 2002 19:46:14 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk IPS WG Last Calls on four drafts have recently concluded; here are the results. -- iSCSI stringprep (ended Oct 13) This draft has passed WG Last Call. The -03 version contains the editorial changes resulting from WG Last Call and will be forwarded to the ADs/IESG after it's checked for nits. After further analysis, it has been determined that this draft does not need to be broadened to allow additional use by iSNS. The reason is that the additional iSNS item that needs stringprep (Entity Identifier) has to be capable of storing a FQDN (Fully Qualified Domain Name), and hence needs to use the IDN WG's nameprep profile of stringprep (draft-ietf-idn-nameprep-11.txt) rather than the iSCSI name profile of stringprep. Mark Bakke gets credit for helping catch this oops by yours truly in a timely fashion. -- iSNS (ended Oct 13) There don't appear to be any outstanding technical issues with this draft, but enough changes are being made as a result of WG Last Call, that the WG chairs have decided to put the draft through a second WG Last Call to check the changes. If the version of iSNS with all the changes gets submitted next week, this WG Last Call will start before Atlanta. -- iSCSI MIB (ended Oct 23) The WG co-chairs believe that it is the rough consensus of the IPS WG that the two changes proposed to this MIB during WG Last Call (read-only vs. read-write target access controls, and session type) should not be accepted, and hence this draft has passed WG Last Call. It needs a nit check and approval by the WG's MIB advisor before being forwarded to the ADs/IESG. - iSCSI Auth MIB (ended Oct 23) There have been no substantial comments on this MIB during WG Last Call, hence it has passed WG Last Call. It also needs a nit check and approval by the WG's MIB advisor before being forwarded to the ADs/IESG. Congratulations to the authors for the results that reflect their hard work, and thanks to all who contributed. --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 **NEW** FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- From owner-ips@ece.cmu.edu Fri Oct 25 20:57:48 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17083 for ; Fri, 25 Oct 2002 20:57:48 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g9Q0J9E23076 for ips-outgoing; Fri, 25 Oct 2002 20:19:09 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mailhub.lss.emc.com (xdch.emc.com [168.159.1.79]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g9Q0J7H23069 for ; Fri, 25 Oct 2002 20:19:07 -0400 (EDT) Received: from emc.com (emcmail.lss.emc.com [168.159.48.78]) by mailhub.lss.emc.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g9Q0IwD16449 for ; Fri, 25 Oct 2002 20:18:58 -0400 (EDT) Received: from mxic1.isus.emc.com ([168.159.129.100]) by emc.com (8.10.1/8.10.1) with ESMTP id g9Q0Iv703366 for ; Fri, 25 Oct 2002 20:18:58 -0400 (EDT) Received: by MXIC1 with Internet Mail Service (5.5.2653.19) id ; Fri, 25 Oct 2002 20:18:57 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C492@CORPMX14> From: Black_David@emc.com To: ips@ece.cmu.edu Subject: IPS-ALL: FCIP MIB WG Last Call Date: Fri, 25 Oct 2002 20:18:54 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk All, We would like to announce IPS Working Group Last call for the FCIP MIB. Details: Document: Definitions of Managed Objects for FCIP URL: http://www.ietf.org/internet-drafts/draft-ietf-ips-fcip-mib-02.txt Last call period: 2 Weeks Submit comments no later than: Sunday, November 10, 2002 at 5pm EST Editor: Anil Rijhsinghani Please submit editorial comments directly to Anil, with copy to David Black (black_david@emc.com), and Elizabeth Rodriguez(erodrigu@brocade.com) Submit technical comments to the IPS mailing list (ips@ece.cmu.edu) Editorial comments may be resolved directly by the editor of the document, but any technical issues must be discussed on the IPS reflector. Thanks, David Black & Elizabeth Rodriguez IPS co-chairs --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 249-6449 FAX: +1 (508) 497-8018 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Fri Oct 25 21:17:48 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17505 for ; Fri, 25 Oct 2002 21:17:48 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g9PNU9D20603 for ips-outgoing; Fri, 25 Oct 2002 19:30:09 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from hammer.brocade.com (sj6-b.brocade.com [63.121.140.220]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g9PNU6H20594 for ; Fri, 25 Oct 2002 19:30:06 -0400 (EDT) Received: from hq-ex-c3.brocade.com (hq-ex-c3.brocade.com [192.168.126.211]) by hammer.brocade.com (8.11.3/8.11.3) with ESMTP id g9PNU0u26040 for ; Fri, 25 Oct 2002 16:30:00 -0700 (PDT) Received: by hq-ex-c3.brocade.com with Internet Mail Service (5.5.2653.19) id <4LH1VQPW>; Fri, 25 Oct 2002 16:30:01 -0700 Message-ID: From: Elizabeth Rodriguez To: ips@ece.cmu.edu Subject: IPS-ALL: FW: Last Call: FC Frame Encapsulation [+iFCP & FCIP] to Proposed Standard Date: Fri, 25 Oct 2002 16:30:00 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C27C7E.6FB98D30" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C27C7E.6FB98D30 Content-Type: text/plain All, IETF WG last call has been issued on the Fibre Channel Encapsulation Draft, FCIP draft, and iFCP draft Discussion for IETF Last Call should take place on the IETF discussion mailing list. The IETF discussion mailing list archive is found at http://www1.ietf.org/mail-archive/ietf/Current/maillist.html You can subscribe to the discussion mailing list by sending a request to: ietf-request@ietf.org and enter the word subscribe in the Subject line of the message and in the message body. Elizabeth Rodriguez & David Black IPS co-chairs -----Original Message----- From: The IESG [mailto:iesg-secretary@ietf.org] Sent: Friday, October 25, 2002 8:03 AM Cc: ips@ece.cmu.edu Subject: Last Call: FC Frame Encapsulation to Proposed Standard The IESG has received a request from the IP Storage Working Group to consider publication of the following Internet-Drafts as Proposed Standards: o FC Frame Encapsulation o Fibre Channel Over TCP/IP (FCIP) o iFCP - A Protocol for Internet Fibre Channel Storage Networking 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 2002-11-7. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ips-fcencapsulation-08.txt http://www.ietf.org/internet-drafts/draft-ietf-ips-fcovertcpip-12.txt http://www.ietf.org/internet-drafts/draft-ietf-ips-ifcp-13.txt ------_=_NextPart_001_01C27C7E.6FB98D30 Content-Type: text/html Content-Transfer-Encoding: quoted-printable IPS-ALL: FW: Last Call: FC Frame Encapsulation [+iFCP & = FCIP] to Proposed Standard

All,

IETF WG last call has been issued on the
Fibre Channel Encapsulation Draft,
FCIP draft, and
iFCP draft

Discussion for IETF Last Call should take place on = the IETF discussion mailing list.
The IETF discussion mailing list archive is found at = http://www1.ietf.org/mail-archive/ietf/Current/maillis= t.html
You can subscribe to the discussion mailing list by = sending a request to: ietf-request@ietf.org and enter the word = subscribe in the Subject line of the message and in the message body. =

Elizabeth Rodriguez & David Black
IPS co-chairs

-----Original Message-----
From: The IESG [mailto:iesg-secretary@ietf.org]
Sent: Friday, October 25, 2002 8:03 AM
Cc: ips@ece.cmu.edu
Subject: Last Call: FC Frame Encapsulation to = Proposed Standard




The IESG has received a request from the IP Storage = Working Group to
consider publication of the following = Internet-Drafts as Proposed
Standards:


 o FC Frame Encapsulation = <draft-ietf-ips-fcencapsulation-08.txt>

 o Fibre Channel Over TCP/IP (FCIP) = <draft-ietf-ips-fcovertcpip-12.txt>

 o iFCP - A Protocol for Internet Fibre Channel = Storage Networking
   = <draft-ietf-ips-ifcp-13.txt>

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 = 2002-11-7.

Files can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-ips-fce= ncapsulation-08.txt
http://www.ietf.org/internet-drafts/draft-ietf-ips-fco= vertcpip-12.txt
http://www.ietf.org/internet-drafts/draft-ietf-ips-ifc= p-13.txt

------_=_NextPart_001_01C27C7E.6FB98D30-- From owner-ips@ece.cmu.edu Sat Oct 26 21:22:55 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16257 for ; Sat, 26 Oct 2002 21:22:55 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g9R0Vg704708 for ips-outgoing; Sat, 26 Oct 2002 20:31:42 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ariel.nishansystems.com (ultrex.nishansystems.com [12.36.127.195]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g9R0VfH04704 for ; Sat, 26 Oct 2002 20:31:41 -0400 (EDT) Received: by ariel.nishansystems.com with Internet Mail Service (5.5.2653.19) id ; Sat, 26 Oct 2002 17:31:35 -0700 Message-ID: From: Joshua Tseng To: "'Black_David@emc.com'" Cc: ips@ece.cmu.edu Subject: RE: iSNS: Responses to David Black Technical Comments Date: Sat, 26 Oct 2002 17:31:25 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk David, Please see my responses to your iSNS technical comments below. I will submit a revision -14 within the next day or so. We can then continue the last call comment and revision process against the revision -14 draft. Josh > -----Original Message----- > From: Black_David@emc.com [mailto:Black_David@emc.com] > Sent: Wednesday, October 23, 2002 5:48 PM > To: jtseng@NishanSystems.com; ips@ece.cmu.edu > Subject: RE: iSNS: Responses to David Black Technical Comments > > > Josh, > > Most of the responses are fine, but there's one major issue > (iSNS Backup servers) and several minor issues, one of which is > unfortunately new and affects IP address formats. Thanks, --David > > -- iSNS Backup Servers -- > <> > > I remain concerned that the text here not only allows, but > may encourage > building iSNS backup in a fashion that will fail split-brain with > potentially disastrous consequences. On further reading, the thing to > do may be to modify the following sentence: > > Therefore, it is beyond the scope of this specification to > facilitate more than a basic interoperability among failover > mechanisms. > > to add specifics about what is and is not specified for > interoperability. > What is specified is: > - Client behavior and protocol interaction in the presence of multiple > iSNS servers, some of which are Backup iSNS servers. > - Required failover behaviors of the collection of iSNS servers that > includes Active and Backup servers. > What is not specified is: > - Complete functional failover requirements on each iSNS > server and the > protocols needed for a collection of iSNS servers to realize the > required failover behaviors in an interoperable fashion. > > While it's missing some aspects of interoperability, I think > getting the > client foundation in place that allows failover to a backup server is > important enough to be worth including, even at the expense of not > mixing different iSNS implementations in a collection of Active/Backup > servers. The first two paragraphs of 3.8 have been replaced with the following: This section offers a broad framework for implementation and deployment of iSNS backup servers. Server failover and recovery are topics of continuing research and adequate resolution of issues such as split brain and primary server selection is dependent on the specific implementation requirements and deployment needs. The failover mechanisms discussed in this document focuses on the interaction between iSNS clients and iSNS servers. Specifically, what is covered in this document includes the following: - iSNS client behavior and the iSNS protocol interaction between the client and multiple iSNS servers, some of which are backup servers. - Required failover behaviors of the collection of iSNS servers that includes active and backup servers. However, note that this document does not specify the complete functional failover requirements of each iSNS server. In particular, it does not specify the complete set of protocol interactions among the iSNS servers that are required to achieve stable failover operation in an interoperable manner. > > -- Minor Issues -- > > > > > > > -- Section 6.6.5.3 > > > > > > Add a discussion of what happens if the iSNS database is > updated during > > > a sequence of GetNext operations. Is it possible to lose > one's place > > > if an object is deleted? How is a client expected to > cope with this? > > > > The following text has been added to the end of section 6.6.5.3: > > Added text snipped - it's ok. > > Unless I missed it somewhere a sentence is needed > saying that the iSNS database MUST have an implicit internal linear > order of entries. This is needed to give a meaning to words like > "after", "next" and "following" in this section. It also might be > good to say than an iSNS database SHOULD NOT be reorganized with > respect to that implied order as a consequence of insertions and > deletions (i.e., relative order of entries that remain in the > database SHOULD be preserved so that GetNext encounters generally > reasonable behavior). The following paragraph has been added to the beginning of seciton 4.7: 4.7 iSNS Database Model Each object type in the iSNS database MUST have an implicit internal linear ordering based on the key(s) for that object type. This ordering provides the ability to respond to DevGetNext queries (see section 6.6.5.3). The ordering of objects in the iSNS database SHOULD NOT be changed with respect to that implied ordering, as a consequence of object insertions and deletions. That is, the relative order of surviving object entries in the iSNS database SHOULD be preserved so that the DevGetNext message encounters generally reasonable behavior. > > > > -- Section 7 > > > > > > This looks like it should be retitled to IANA > Considerations, with all > of > > > this stuff going into registries, and the section needs > to be expanded > to > > > include things like the BSD from Section 6.5. Some of > the material in > > > the table in Section 7.1 may not be appropriate for an > IANA registry, > > > though. > > > > A new IANA Considerations section has been inserted as > section 9, as shown > > below: > > Good start, but instructions to IANA for handling additions > are missing. > Please see RFC 2434 for information on what needs to be in > this section. Section 9 has been expanded to include the following text: 9. IANA Considerations The well-known TCP and UDP port number for iSNS is 3205. In order to maintain a registry of block storage protocols supported by iSNSP, IANA MUST assign a 32-bit unsigned integer number for each protocol. This number is stored in the iSNS database as the Entity Protocol. The initial set of values to be maintained by IANA for Entity Protocol is indicated in the table in section 7.2.2. Additional values for new block storage protocols to be supported by iSNS SHALL be assigned by IANA on a First Come, First Served basis. IANA is responsible for maintaining the complete list of iSNS attributes described in section 7. This information MUST include for each iSNS attribute, its tag value, the attribute length, and the set of permissible registration and query keys that can be used for that attribute. The initial list of iSNS attributes to be maintained by IANA is indicated in section 7.1. Additions of new attributes to the iSNS attribute list that use tag values currently indicated as RESERVED in section 7.1 SHALL require proper documentation. This documentation SHALL include as a minimum, the new attribute tag value, attribute length, and the set of permissible registration and query keys that can be used for the new attribute. Possible forms of documentation include, but are not limited to, RFCs or the product of another standards body. Other requests may also be accepted, under the advice of a "designated expert". (Contact the IANA for the contact information of the current expert.) Finally, IANA is also responsible for assigning values to be used for the Block Structure Descriptor for the Authentication Block (see section 6.5). Section 15 of [RFC2608] describes the process for allocation of new BSD values. > > > > -- Section 7.2.1 > > > > > > 7.2.1 Entity Identifier (EID) > > > > > > The Entity Identifier (EID) is a variable-length field > containing > > > user-readable UTF-8 text, and is terminated with at > least one NULL > > > character. variable length identifier This field uniquely > > > identifies each network entity registered in the iSNS server. > > > > > > Does this need to be stringprep'ed? "variable length > identifier" looks > > > like it escaped from previous editing. Check all other > UTF-8 attributes > > > for possible needs for stringprep. > > > > Variable-length fields that are used as key attributes > (i.e., EID, iSCSI > Name) > > need to be stringprep-ed. Those that are not key > attributes are used as > > descriptive fields, and so do not need to be normalized. > The following > text > > will be added to each variable-length field that is used as a > > primary key: > > > > This attribute MUST be normalized according to the > stringprep template > > [STRINGPREP] before it is stored in the iSNS database. > > > > Note that since we are now using the stringprep document > generically, not > just > > for iSCSI names, then I would suggest removing the iSCSI > label for that > > document. > > Ok, let's consider that a late WG Last Call comment against the iSCSI > stringprep draft - please contact Mark Bakke directly about > revising it. iSCSI Names are normalized according to Mark's draft. EIDs are normalized according to the nameprep draft (draft-ietf-idn-nameprep-11.txt). > > > > -- Section 7.2.3 > > > > > > This field contains the IP Address used to manage the > Network Entity > > > and all Storage Nodes contained therein. The > Management IP Address > > > is a 16-byte field that may contain either a 32-bit > IPv4 or 128-bit > > > IPv6 address. When this field contains an IPv4 value, the most > > > significant 12 bytes are set to 0x00. When this field > contains an > > > IPv6 value, the entire 16-byte field is used. If the > network entity > > > is capable of being managed and this field is not set, > then in-band > > > management through the IP address of one of the Portals of the > > > Network Entity is assumed. > > > > > > What is this IP address used for? Why is an IP address, > as opposed to > > > an IP address plus TCP or UDP port? > > > > Both IP address and TCP/UDP Port are required to identify a > Portal. The > > Portal object is therefore referenced by two attributes--its primary > > key has two fields. The IP address alone is > insigificant--it must be > > accompanied by the TCP/UDP Port Number to have any meaning in iSNS. > > But this is the Management IP address and I don't see a > Management IP Port - > did I miss something? The phrases "used to manage" and > "capable of being > managed" need to be defined - if this means SNMP, say so. > > Also, I don't see any external way of indicating whether the > address is > IPv4 or IPv6, and hence I believe Section 2.5.4 of RFC 2373 applies to > IP addresses in iSNS - unfortunately, the convention that's currently > being used for address formats implies that all IPv4 addresses in iSNS > are for IPv6-capable nodes, which is probably not what was intended > (sorry for the late catch on this one, but better now than to have one > of the ADs find it). The text for section 7.2.3 describing the management port has been revised as follows: 7.2.3 Management IP Address This field contains the IP Address used to manage the Network Entity and all Storage Nodes contained therein through SNMP [RFC1157] [iSNSMIB]. Some implementations MAY also use this IP address to support vendor-specific proprietary management protocols. The Management IP Address is a 16-byte field that may contain a IPv4 or IPv6 address. When this field contains an IPv4 value, it is stored as an IPv4-mapped IPv6 address. That is, the most significant 10 bytes are set to 0x00, with the next two bytes set to 0xFFFF [RFC2373]. When this field contains an IPv6 value, the entire 16-byte field is used. If this field is not set, then in-band management through the IP address of one of the Portals of the Network Entity is assumed. Similarly, the text for section 7.3.1 describing the Portal IP address has been revised as follows: 7.3.1 Portal IP-Address This attribute is the IP address of the Portal through which a Storage Node can transmit and receive storage data. The Portal IP Address is a 16-byte field that may contain an IPv4 or IPv6 address. When this field contains an IPv4 address, it is stored as an IPv4-mapped IPv6 address. That is, the most significant 10 bytes are set to 0x00, with the next 2 bytes set to 0xFFFF [RFC2373]. When this field contains an IPv6 address, the entire 16-byte field is used. The Portal IP Address along with the Portal TCP/UDP Port number (see 7.3.2 below) uniquely identifies a Portal. > > > > -- Section 7.2.7 > > > > > > The Entity Index is a 4-byte integer value that > uniquely identifies > > > each network entity registered in the iSNS server. > The Entity Index > > > is assigned by the iSNS server during the initial > registration of an > > > Entity. It can be used to represent a registered entity in > > > situations where the Entity Identifier is too long to be used. > > > > > > Explain the requirements on "uniquely identifies", in > particular rules > > > about if/when an iSNS server can reuse an Entity Index value. > > > Same comment applies to Portal Index (Section 7.3.7) and > iSCSI Node > Index > > > (Section 7.4.5). > > > > The text for 7.2.7 has been modified as follows: > > > > The Entity Index is a 4-byte integer value that uniquely > identifies each > > network entity registered in the iSNS server. Upon initial > registration > of > > an Entity, the iSNS server assigns an unused value for the > Entity Index > for > > that Entity. Each Entity in the iSNS database MUST be > assigned a value > for > > the Entity Index that is not assigned to any other Entity. > The Entity > Index > > MAY be used to represent the Entity in situations when the Entity > Identifier > > is too long or otherwise inappropriate. > > That takes care of assignment, what about reuse? Short-term > reuse SHOULD > NOT be done, as it's an invitation to confusion in places > where the Entity > Index has been used. Similarly for 7.3.7 and 7.4.5. > The following sentence has been added to section 7.2.7: "Furthermore, Entity Index values for recently deregistered Network Entities SHOULD NOT be reused in the short term." The following sentence has been added to section 7.3.7: "Furthermore, Portal Index values for recently deregistered Portals SHOULD NOT be reused in the short term." The following sentence has been added to section 7.4.5 "Furthermore, iSCSI Node Index values for recently deregistered iSCSI Nodes SHOULD NOT be reused in the short term." From mailnull@www1.ietf.org Sun Oct 27 20:50:39 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13214 for ; Sun, 27 Oct 2002 20:50:39 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9S1qbk13868 for ips-archive@odin.ietf.org; Sun, 27 Oct 2002 20:52:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9S1qbv13865 for ; Sun, 27 Oct 2002 20:52:37 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13208 for ; Sun, 27 Oct 2002 20:50:08 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9S1okv13771; Sun, 27 Oct 2002 20:50:48 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9S1mWv13714 for ; Sun, 27 Oct 2002 20:48:32 -0500 Received: from porter.east.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13154 for ; Sun, 27 Oct 2002 20:46:03 -0500 (EST) Received: from porter (localhost [127.0.0.1]) by porter.east.isi.edu (8.11.3/8.11.3) with ESMTP id g9S1mNB21749; Sun, 27 Oct 2002 20:48:23 -0500 (EST) Message-Id: <200210280148.g9S1mNB21749@porter.east.isi.edu> To: ips@ietf.org Cc: black_david@emc.com, erodrigu@brocade.com, sob@harvard.edu, mankin@psg.com Reply-To: mankin@isi.edu Date: Sun, 27 Oct 2002 20:48:23 -0500 From: Allison Mankin Subject: [Ips] AD comments for iSCSI Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , Folks, The following are some AD comments on iSCSI which we would like to have addressed before its IETF Last Call, presumably in one more rev before the deadline. Questions are welcome. Onward and upward. Allison P.S. Congrats on the many drafts at or very close to IETF Last Call - the Transport Area is very fond of WGs that come to their conclusions. --------- The comments, after a useful discussion with your chairs: (1) Naming. Section 2.2.6.1 lists naming requirements and uses "MUST" to impose them. Most of these are not requirements on implementations, rather they were design requirements for iSCSI naming. This section should be rewritten to describe those requirements as important properties of iSCSI naming, rather than of names in use, An example of this being a big problem is the sentence about names needing to be "reasonably easy to compare" which is a disaster as with a MUST next to it in the specifiction, while it was fine for setting initial requirements. In addition, there may an editorial problem in the URN paragraph, as the current well-intentioned text could imply more than was intended. I will give you some future AD guidance after checking with an expert reviewer if there is an issue in this area. Do not change the text now. (2) Stringprep. Some of the text in Section 2.2.6.2 overlaps and duplicates material in the iSCSI stringprep draft. This is a problem, as the iSCSI stringprep draft should be a sufficient and complete specification of the application of stringprep to iSCSI. For example, listing the dash, dot, and colon characters as acceptable duplicates material in Sections 1 and 6.2 of the iSCSI stringprep draft. If these characters are mentioned in this section of the iSCSI draft, they should be described as reserved for use in formatting iSCSI names, as the stringprep draft is the appropriate place to specify them as allowed. (3) Handling of Security Considerations. Section 7's introduction is almost exactly right, except that it should make [SEC-IPS] more normative, by adding something like the following after the "SHOULD NOT" sentince: "[SEC-IPS] specifies the mechanisms that must be used in order to mitigate risks fully described in that document." This makes the ips-security normative for use if you want to deal with the threats. I don't think 2119 MUST is called for, but the idea comes across. Although Section 7 gives a good guideline, and gets the right stance about threats, with the addition of something like the language suggested, the introduction of authentication in in 2.2.3 gives very weak guidelines. This language is a problem: >As part of the login process, the initiator and target MAY wish to >authenticate each other and set a security association protocol for >the session. This can occur in many different ways and is subject to >negotiation. Make these MAYs stronger consistent with the rest of the specification. It is strongly expressed elsewhere that in some form authentication SHOULD be *used* in all circumstances. The situations in which no authentication is needed are sufficiently narrow to fall under RFC 2119, Section 3's definition of "SHOULD": 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. (4) Somewhere in Section 2, a paragraph is needed to explain iSCSI's overall approach to SCSI Task Management. The explanation is roughly: - SAM-2 specifies task management as if the initiator and target interacted synchronously (e.g., as they do over a parallel SCSI bus). - An iSCSI initiator and target interact asynchronously due to concurrency in the network and queuing of iSCSI commands received out of order (e.g., from different TCP connections) for in order delivery to the SCSI layer at the target. - In order to meet SAM-2's expectation that initiators will see a synchronous view of task management, iSCSI specifies the protocol mechanisms and implementation requirements needed to present a synchronous view in the presence of the actual asynchrony involved. This needs to be said in a simple introductory way beforehand to explain why so much that seems to be SCSI's job is being done by iSCSI. It's pure writing/context, no new technical content. (5) The abstract needs to be rewritten. The current abstract does an ok job of describing iSCSI to a storage-knowledgeable person, but should be expanded to provide a reasonable context and motivation for iSCSI to a *network-knowledgeable* person who may be encountering the *SCSI acronym for the first time. In addition, references are not allowed in abstracts; please delete the reference to "[SAM-2]". It's ok to mention SAM-2 in the abstract, but not ok to have an actual document reference. (6) The reference in the abstract is an example of a checklist fault. The chairs are checking the checklist, but if the editor can also do this, it'd be good, as should every editor with a draft in the working group. _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-admin@ietf.org Sun Oct 27 20:50:53 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13227 for ; Sun, 27 Oct 2002 20:50:53 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9S1okv13771; Sun, 27 Oct 2002 20:50:48 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9S1mWv13714 for ; Sun, 27 Oct 2002 20:48:32 -0500 Received: from porter.east.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13154 for ; Sun, 27 Oct 2002 20:46:03 -0500 (EST) Received: from porter (localhost [127.0.0.1]) by porter.east.isi.edu (8.11.3/8.11.3) with ESMTP id g9S1mNB21749; Sun, 27 Oct 2002 20:48:23 -0500 (EST) Message-Id: <200210280148.g9S1mNB21749@porter.east.isi.edu> To: ips@ietf.org Cc: black_david@emc.com, erodrigu@brocade.com, sob@harvard.edu, mankin@psg.com Reply-To: mankin@isi.edu Date: Sun, 27 Oct 2002 20:48:23 -0500 From: Allison Mankin Subject: [Ips] AD comments for iSCSI Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , Folks, The following are some AD comments on iSCSI which we would like to have addressed before its IETF Last Call, presumably in one more rev before the deadline. Questions are welcome. Onward and upward. Allison P.S. Congrats on the many drafts at or very close to IETF Last Call - the Transport Area is very fond of WGs that come to their conclusions. --------- The comments, after a useful discussion with your chairs: (1) Naming. Section 2.2.6.1 lists naming requirements and uses "MUST" to impose them. Most of these are not requirements on implementations, rather they were design requirements for iSCSI naming. This section should be rewritten to describe those requirements as important properties of iSCSI naming, rather than of names in use, An example of this being a big problem is the sentence about names needing to be "reasonably easy to compare" which is a disaster as with a MUST next to it in the specifiction, while it was fine for setting initial requirements. In addition, there may an editorial problem in the URN paragraph, as the current well-intentioned text could imply more than was intended. I will give you some future AD guidance after checking with an expert reviewer if there is an issue in this area. Do not change the text now. (2) Stringprep. Some of the text in Section 2.2.6.2 overlaps and duplicates material in the iSCSI stringprep draft. This is a problem, as the iSCSI stringprep draft should be a sufficient and complete specification of the application of stringprep to iSCSI. For example, listing the dash, dot, and colon characters as acceptable duplicates material in Sections 1 and 6.2 of the iSCSI stringprep draft. If these characters are mentioned in this section of the iSCSI draft, they should be described as reserved for use in formatting iSCSI names, as the stringprep draft is the appropriate place to specify them as allowed. (3) Handling of Security Considerations. Section 7's introduction is almost exactly right, except that it should make [SEC-IPS] more normative, by adding something like the following after the "SHOULD NOT" sentince: "[SEC-IPS] specifies the mechanisms that must be used in order to mitigate risks fully described in that document." This makes the ips-security normative for use if you want to deal with the threats. I don't think 2119 MUST is called for, but the idea comes across. Although Section 7 gives a good guideline, and gets the right stance about threats, with the addition of something like the language suggested, the introduction of authentication in in 2.2.3 gives very weak guidelines. This language is a problem: >As part of the login process, the initiator and target MAY wish to >authenticate each other and set a security association protocol for >the session. This can occur in many different ways and is subject to >negotiation. Make these MAYs stronger consistent with the rest of the specification. It is strongly expressed elsewhere that in some form authentication SHOULD be *used* in all circumstances. The situations in which no authentication is needed are sufficiently narrow to fall under RFC 2119, Section 3's definition of "SHOULD": 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. (4) Somewhere in Section 2, a paragraph is needed to explain iSCSI's overall approach to SCSI Task Management. The explanation is roughly: - SAM-2 specifies task management as if the initiator and target interacted synchronously (e.g., as they do over a parallel SCSI bus). - An iSCSI initiator and target interact asynchronously due to concurrency in the network and queuing of iSCSI commands received out of order (e.g., from different TCP connections) for in order delivery to the SCSI layer at the target. - In order to meet SAM-2's expectation that initiators will see a synchronous view of task management, iSCSI specifies the protocol mechanisms and implementation requirements needed to present a synchronous view in the presence of the actual asynchrony involved. This needs to be said in a simple introductory way beforehand to explain why so much that seems to be SCSI's job is being done by iSCSI. It's pure writing/context, no new technical content. (5) The abstract needs to be rewritten. The current abstract does an ok job of describing iSCSI to a storage-knowledgeable person, but should be expanded to provide a reasonable context and motivation for iSCSI to a *network-knowledgeable* person who may be encountering the *SCSI acronym for the first time. In addition, references are not allowed in abstracts; please delete the reference to "[SAM-2]". It's ok to mention SAM-2 in the abstract, but not ok to have an actual document reference. (6) The reference in the abstract is an example of a checklist fault. The chairs are checking the checklist, but if the editor can also do this, it'd be good, as should every editor with a draft in the working group. _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From owner-ips@ece.cmu.edu Sun Oct 27 23:33:35 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16251 for ; Sun, 27 Oct 2002 23:33:35 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g9S3kIO19266 for ips-outgoing; Sun, 27 Oct 2002 22:46:18 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from rly-ip03.mx.aol.com (rly-ip03.mx.aol.com [64.12.138.7]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g9S3kDH19257 for ; Sun, 27 Oct 2002 22:46:13 -0500 (EST) Received: from logs-wl.proxy.aol.com (logs-wl.proxy.aol.com [205.188.199.5]) by rly-ip03.mx.aol.com (v89.10) with ESMTP id RELAYIN9-1027224603; Sun, 27 Oct 2002 22:46:03 -0400 Received: from EGRodriguez (AC8A19B2.ipt.aol.com [172.138.25.178]) by logs-wl.proxy.aol.com (8.10.0/8.10.0) with ESMTP id g9S3iKQ308376 for ; Sun, 27 Oct 2002 22:44:20 -0500 (EST) Reply-To: , "Elizabeth Rodriguez" From: "Elizabeth G. Rodriguez" To: Subject: FW: [Ips] AD comments for iSCSI Date: Sun, 27 Oct 2002 18:42:51 -0800 Keywords: Acct-Elizabeth.G.Rodriguez@123 Message-ID: <000501c27e2b$b93643f0$b2198aac@EGRodriguez> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-Apparently-From: UserR1846@aol.com Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi all, These are some comments from Allison Mankin. Forwarding, in case you did not receive directly. Elizabeth Rodriguez IPS co-chair -----Original Message----- From: ips-admin@ietf.org [mailto:ips-admin@ietf.org] On Behalf Of Allison Mankin Sent: Sunday, October 27, 2002 5:48 PM To: ips@ietf.org Cc: black_david@emc.com; erodrigu@brocade.com; sob@harvard.edu; mankin@psg.com Subject: [Ips] AD comments for iSCSI Folks, The following are some AD comments on iSCSI which we would like to have addressed before its IETF Last Call, presumably in one more rev before the deadline. Questions are welcome. Onward and upward. Allison P.S. Congrats on the many drafts at or very close to IETF Last Call - the Transport Area is very fond of WGs that come to their conclusions. --------- The comments, after a useful discussion with your chairs: (1) Naming. Section 2.2.6.1 lists naming requirements and uses "MUST" to impose them. Most of these are not requirements on implementations, rather they were design requirements for iSCSI naming. This section should be rewritten to describe those requirements as important properties of iSCSI naming, rather than of names in use, An example of this being a big problem is the sentence about names needing to be "reasonably easy to compare" which is a disaster as with a MUST next to it in the specifiction, while it was fine for setting initial requirements. In addition, there may an editorial problem in the URN paragraph, as the current well-intentioned text could imply more than was intended. I will give you some future AD guidance after checking with an expert reviewer if there is an issue in this area. Do not change the text now. (2) Stringprep. Some of the text in Section 2.2.6.2 overlaps and duplicates material in the iSCSI stringprep draft. This is a problem, as the iSCSI stringprep draft should be a sufficient and complete specification of the application of stringprep to iSCSI. For example, listing the dash, dot, and colon characters as acceptable duplicates material in Sections 1 and 6.2 of the iSCSI stringprep draft. If these characters are mentioned in this section of the iSCSI draft, they should be described as reserved for use in formatting iSCSI names, as the stringprep draft is the appropriate place to specify them as allowed. (3) Handling of Security Considerations. Section 7's introduction is almost exactly right, except that it should make [SEC-IPS] more normative, by adding something like the following after the "SHOULD NOT" sentince: "[SEC-IPS] specifies the mechanisms that must be used in order to mitigate risks fully described in that document." This makes the ips-security normative for use if you want to deal with the threats. I don't think 2119 MUST is called for, but the idea comes across. Although Section 7 gives a good guideline, and gets the right stance about threats, with the addition of something like the language suggested, the introduction of authentication in in 2.2.3 gives very weak guidelines. This language is a problem: >As part of the login process, the initiator and target MAY wish to >authenticate each other and set a security association protocol for >the session. This can occur in many different ways and is subject to >negotiation. Make these MAYs stronger consistent with the rest of the specification. It is strongly expressed elsewhere that in some form authentication SHOULD be *used* in all circumstances. The situations in which no authentication is needed are sufficiently narrow to fall under RFC 2119, Section 3's definition of "SHOULD": 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. (4) Somewhere in Section 2, a paragraph is needed to explain iSCSI's overall approach to SCSI Task Management. The explanation is roughly: - SAM-2 specifies task management as if the initiator and target interacted synchronously (e.g., as they do over a parallel SCSI bus). - An iSCSI initiator and target interact asynchronously due to concurrency in the network and queuing of iSCSI commands received out of order (e.g., from different TCP connections) for in order delivery to the SCSI layer at the target. - In order to meet SAM-2's expectation that initiators will see a synchronous view of task management, iSCSI specifies the protocol mechanisms and implementation requirements needed to present a synchronous view in the presence of the actual asynchrony involved. This needs to be said in a simple introductory way beforehand to explain why so much that seems to be SCSI's job is being done by iSCSI. It's pure writing/context, no new technical content. (5) The abstract needs to be rewritten. The current abstract does an ok job of describing iSCSI to a storage-knowledgeable person, but should be expanded to provide a reasonable context and motivation for iSCSI to a *network-knowledgeable* person who may be encountering the *SCSI acronym for the first time. In addition, references are not allowed in abstracts; please delete the reference to "[SAM-2]". It's ok to mention SAM-2 in the abstract, but not ok to have an actual document reference. (6) The reference in the abstract is an example of a checklist fault. The chairs are checking the checklist, but if the editor can also do this, it'd be good, as should every editor with a draft in the working group. _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From owner-ips@ece.cmu.edu Mon Oct 28 00:31:08 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17470 for ; Mon, 28 Oct 2002 00:31:08 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g9S4uYL22276 for ips-outgoing; Sun, 27 Oct 2002 23:56:34 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from porter.east.isi.edu (porter.east.isi.edu [65.114.168.19]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g9S4uXH22272 for ; Sun, 27 Oct 2002 23:56:33 -0500 (EST) Received: from porter (localhost [127.0.0.1]) by porter.east.isi.edu (8.11.3/8.11.3) with ESMTP id g9S4uVB24726; Sun, 27 Oct 2002 23:56:32 -0500 (EST) Message-Id: <200210280456.g9S4uVB24726@porter.east.isi.edu> To: erodrigu@Brocade.COM, "Elizabeth Rodriguez" cc: ips@ece.cmu.edu Reply-To: mankin@ISI.EDU Subject: Re: FW: [Ips] AD comments for iSCSI In-reply-to: Your message of Sun, 27 Oct 2002 18:42:51 -0800. <000501c27e2b$b93643f0$b2198aac@EGRodriguez> Date: Sun, 27 Oct 2002 23:56:31 -0500 From: Allison Mankin Sender: owner-ips@ece.cmu.edu Precedence: bulk yeah, dumb me, why do you have both an ietf and cmu list...I just sent it there too. From mailnull@www1.ietf.org Mon Oct 28 00:48:24 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17973 for ; Mon, 28 Oct 2002 00:48:24 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9S5oNO24401 for ips-archive@odin.ietf.org; Mon, 28 Oct 2002 00:50:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9S5oNv24398 for ; Mon, 28 Oct 2002 00:50:23 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17967 for ; Mon, 28 Oct 2002 00:47:52 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9S5nhv24334; Mon, 28 Oct 2002 00:49:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9S5muv24274 for ; Mon, 28 Oct 2002 00:48:56 -0500 Received: from d12lmsgate-4.de.ibm.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17940 for ; Mon, 28 Oct 2002 00:46:25 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-4.de.ibm.com (8.12.3/8.12.3) with ESMTP id g9S5lSJf022242; Mon, 28 Oct 2002 06:47:28 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g9S5lRrc022096; Mon, 28 Oct 2002 06:47:27 +0100 In-Reply-To: <200210280148.g9S1mNB21749@porter.east.isi.edu> To: mankin@isi.edu Cc: black_david@emc.com, erodrigu@brocade.com, ips@ietf.org, ips-admin@ietf.org, mankin@psg.com, sob@harvard.edu MIME-Version: 1.0 Subject: Re: [Ips] AD comments for iSCSI X-Mailer: Lotus Notes Release 6.0 September 26, 2002 From: "Julian Satran" Message-ID: Date: Mon, 28 Oct 2002 07:47:25 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 28/10/2002 07:47:27, Serialize complete at 28/10/2002 07:47:27 Content-Type: multipart/alternative; boundary="=_alternative 001FBA7FC2256C60_=" Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , This is a multipart message in MIME format. --=_alternative 001FBA7FC2256C60_= Content-Type: text/plain; charset="US-ASCII" Allison, Thanks for your careful and timely comments. I thing we will be able to get the draft out before the cutoff date. Regards, Julo Allison Mankin Sent by: ips-admin@ietf.org 28/10/02 03:48 Please respond to mankin To: ips@ietf.org cc: black_david@emc.com, erodrigu@brocade.com, sob@harvard.edu, mankin@psg.com Subject: [Ips] AD comments for iSCSI Folks, The following are some AD comments on iSCSI which we would like to have addressed before its IETF Last Call, presumably in one more rev before the deadline. Questions are welcome. Onward and upward. Allison P.S. Congrats on the many drafts at or very close to IETF Last Call - the Transport Area is very fond of WGs that come to their conclusions. --------- The comments, after a useful discussion with your chairs: (1) Naming. Section 2.2.6.1 lists naming requirements and uses "MUST" to impose them. Most of these are not requirements on implementations, rather they were design requirements for iSCSI naming. This section should be rewritten to describe those requirements as important properties of iSCSI naming, rather than of names in use, An example of this being a big problem is the sentence about names needing to be "reasonably easy to compare" which is a disaster as with a MUST next to it in the specifiction, while it was fine for setting initial requirements. In addition, there may an editorial problem in the URN paragraph, as the current well-intentioned text could imply more than was intended. I will give you some future AD guidance after checking with an expert reviewer if there is an issue in this area. Do not change the text now. (2) Stringprep. Some of the text in Section 2.2.6.2 overlaps and duplicates material in the iSCSI stringprep draft. This is a problem, as the iSCSI stringprep draft should be a sufficient and complete specification of the application of stringprep to iSCSI. For example, listing the dash, dot, and colon characters as acceptable duplicates material in Sections 1 and 6.2 of the iSCSI stringprep draft. If these characters are mentioned in this section of the iSCSI draft, they should be described as reserved for use in formatting iSCSI names, as the stringprep draft is the appropriate place to specify them as allowed. (3) Handling of Security Considerations. Section 7's introduction is almost exactly right, except that it should make [SEC-IPS] more normative, by adding something like the following after the "SHOULD NOT" sentince: "[SEC-IPS] specifies the mechanisms that must be used in order to mitigate risks fully described in that document." This makes the ips-security normative for use if you want to deal with the threats. I don't think 2119 MUST is called for, but the idea comes across. Although Section 7 gives a good guideline, and gets the right stance about threats, with the addition of something like the language suggested, the introduction of authentication in in 2.2.3 gives very weak guidelines. This language is a problem: >As part of the login process, the initiator and target MAY wish to >authenticate each other and set a security association protocol for >the session. This can occur in many different ways and is subject to >negotiation. Make these MAYs stronger consistent with the rest of the specification. It is strongly expressed elsewhere that in some form authentication SHOULD be *used* in all circumstances. The situations in which no authentication is needed are sufficiently narrow to fall under RFC 2119, Section 3's definition of "SHOULD": 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. (4) Somewhere in Section 2, a paragraph is needed to explain iSCSI's overall approach to SCSI Task Management. The explanation is roughly: - SAM-2 specifies task management as if the initiator and target interacted synchronously (e.g., as they do over a parallel SCSI bus). - An iSCSI initiator and target interact asynchronously due to concurrency in the network and queuing of iSCSI commands received out of order (e.g., from different TCP connections) for in order delivery to the SCSI layer at the target. - In order to meet SAM-2's expectation that initiators will see a synchronous view of task management, iSCSI specifies the protocol mechanisms and implementation requirements needed to present a synchronous view in the presence of the actual asynchrony involved. This needs to be said in a simple introductory way beforehand to explain why so much that seems to be SCSI's job is being done by iSCSI. It's pure writing/context, no new technical content. (5) The abstract needs to be rewritten. The current abstract does an ok job of describing iSCSI to a storage-knowledgeable person, but should be expanded to provide a reasonable context and motivation for iSCSI to a *network-knowledgeable* person who may be encountering the *SCSI acronym for the first time. In addition, references are not allowed in abstracts; please delete the reference to "[SAM-2]". It's ok to mention SAM-2 in the abstract, but not ok to have an actual document reference. (6) The reference in the abstract is an example of a checklist fault. The chairs are checking the checklist, but if the editor can also do this, it'd be good, as should every editor with a draft in the working group. _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --=_alternative 001FBA7FC2256C60_= Content-Type: text/html; charset="US-ASCII"
Allison,

Thanks for your careful and timely comments. I thing we will be able to get the draft out before the cutoff date.

Regards,
Julo


Allison Mankin <mankin@east.isi.edu>
Sent by: ips-admin@ietf.org

28/10/02 03:48
Please respond to mankin

       
        To:        ips@ietf.org
        cc:        black_david@emc.com, erodrigu@brocade.com, sob@harvard.edu, mankin@psg.com
        Subject:        [Ips] AD comments for iSCSI

       


Folks,

The following are some AD comments on iSCSI which we would
like to have addressed before its IETF Last Call, presumably in
one more rev before the deadline.  Questions are welcome.

Onward and upward.

Allison

P.S. Congrats on the many drafts at or very close to
IETF Last Call - the Transport Area is very fond of WGs that
come to their conclusions.  

---------

The comments, after a useful discussion with your chairs:

(1) Naming.  Section 2.2.6.1 lists naming requirements
and uses "MUST" to impose them.  Most of these are not
requirements on implementations, rather they were design
requirements for iSCSI naming.  This section should
be rewritten to describe those requirements as important
properties of iSCSI naming, rather than of names in use,
An example of this being a big problem is the sentence about names
needing to be "reasonably easy to compare" which is a disaster as
with a MUST next to it in the specifiction, while it was fine
for setting initial requirements.

In addition, there may an editorial problem in the URN
paragraph, as the current well-intentioned text could
imply more than was intended.  I will give you some future
AD guidance after checking with an expert reviewer if there
is an issue in this area.  Do not change the text now.

(2) Stringprep.  Some of the text in Section 2.2.6.2
overlaps and duplicates material in the iSCSI stringprep
draft.  This is a problem, as the iSCSI stringprep draft
should be a sufficient and complete specification of the
application of stringprep to iSCSI.  For example, listing
the dash, dot, and colon characters as acceptable duplicates
material in Sections 1 and 6.2 of the iSCSI stringprep draft.
If these characters are mentioned in this section of the
iSCSI draft, they should be described as reserved for use
in formatting iSCSI names, as the stringprep draft is the
appropriate place to specify them as allowed.

(3) Handling of Security Considerations.   Section 7's
introduction is almost exactly right, except that it should
make [SEC-IPS] more normative, by adding something like the
following after the "SHOULD NOT" sentince:
"[SEC-IPS] specifies the mechanisms that must be used in order
to mitigate risks fully described in that document."
This makes the ips-security normative for use if you want
to deal with the threats.  I don't think 2119 MUST is called
for, but the idea comes across.

Although Section 7 gives a good guideline, and gets the right
stance about threats, with the addition of something like the
language suggested, the introduction of authentication in
in 2.2.3 gives very weak guidelines.  This language is a problem:
 
   >As part of the login process, the initiator and target MAY wish to
   >authenticate each other and set a security association protocol for
   >the session. This can occur in many different ways and is subject to
   >negotiation.

Make these MAYs stronger consistent with the rest of the specification.
It is strongly expressed elsewhere that in some form authentication
SHOULD be *used* in all circumstances.  The situations in which no
authentication is needed are sufficiently narrow to fall under RFC 2119,
Section 3's definition of "SHOULD":

  3. SHOULD  This word, or the adjective "RECOMMENDED", mean that
     there may exist valid reasons in particular circumstances to
     ignore a particular item, but the full implications must be
     understood and carefully weighed before choosing a
     different course.


(4) Somewhere in Section 2, a paragraph is needed to explain iSCSI's
overall approach to SCSI Task Management.  The explanation is roughly:
- SAM-2 specifies task management as if the initiator and
                target interacted synchronously (e.g., as they do over
                a parallel SCSI bus).
- An iSCSI initiator and target interact asynchronously due
                to concurrency in the network and queuing of iSCSI
                commands received out of order (e.g., from different
                TCP connections) for in order delivery to the SCSI
                layer at the target.
- In order to meet SAM-2's expectation that initiators will
                see a synchronous view of task management, iSCSI
                specifies the protocol mechanisms and implementation
                requirements needed to present a synchronous view in
                the presence of the actual asynchrony involved.

This needs to be said in a simple introductory way beforehand
to explain why so much that seems to be SCSI's job is being
done by iSCSI.  It's pure writing/context, no new technical
content.

(5) The abstract needs to be rewritten.  The current abstract
does an ok job of describing iSCSI to a storage-knowledgeable
person, but should be expanded to provide a reasonable context
and motivation for iSCSI to a *network-knowledgeable* person
who may be encountering the *SCSI acronym for the first time.
In addition, references are not allowed in abstracts; please
delete the reference to "[SAM-2]".  It's ok to mention SAM-2
in the abstract, but not ok to have an actual document reference.

(6) The reference in the abstract is an example of a checklist
fault.  The chairs are checking the checklist, but if the editor
can also do this, it'd be good, as should every editor with a draft
in the working group.


_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips
--=_alternative 001FBA7FC2256C60_=-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-admin@ietf.org Mon Oct 28 00:48:59 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18010 for ; Mon, 28 Oct 2002 00:48:59 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9S5nhv24334; Mon, 28 Oct 2002 00:49:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9S5muv24274 for ; Mon, 28 Oct 2002 00:48:56 -0500 Received: from d12lmsgate-4.de.ibm.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17940 for ; Mon, 28 Oct 2002 00:46:25 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-4.de.ibm.com (8.12.3/8.12.3) with ESMTP id g9S5lSJf022242; Mon, 28 Oct 2002 06:47:28 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g9S5lRrc022096; Mon, 28 Oct 2002 06:47:27 +0100 In-Reply-To: <200210280148.g9S1mNB21749@porter.east.isi.edu> To: mankin@isi.edu Cc: black_david@emc.com, erodrigu@brocade.com, ips@ietf.org, ips-admin@ietf.org, mankin@psg.com, sob@harvard.edu MIME-Version: 1.0 Subject: Re: [Ips] AD comments for iSCSI X-Mailer: Lotus Notes Release 6.0 September 26, 2002 From: "Julian Satran" Message-ID: Date: Mon, 28 Oct 2002 07:47:25 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 28/10/2002 07:47:27, Serialize complete at 28/10/2002 07:47:27 Content-Type: multipart/alternative; boundary="=_alternative 001FBA7FC2256C60_=" Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , This is a multipart message in MIME format. --=_alternative 001FBA7FC2256C60_= Content-Type: text/plain; charset="US-ASCII" Allison, Thanks for your careful and timely comments. I thing we will be able to get the draft out before the cutoff date. Regards, Julo Allison Mankin Sent by: ips-admin@ietf.org 28/10/02 03:48 Please respond to mankin To: ips@ietf.org cc: black_david@emc.com, erodrigu@brocade.com, sob@harvard.edu, mankin@psg.com Subject: [Ips] AD comments for iSCSI Folks, The following are some AD comments on iSCSI which we would like to have addressed before its IETF Last Call, presumably in one more rev before the deadline. Questions are welcome. Onward and upward. Allison P.S. Congrats on the many drafts at or very close to IETF Last Call - the Transport Area is very fond of WGs that come to their conclusions. --------- The comments, after a useful discussion with your chairs: (1) Naming. Section 2.2.6.1 lists naming requirements and uses "MUST" to impose them. Most of these are not requirements on implementations, rather they were design requirements for iSCSI naming. This section should be rewritten to describe those requirements as important properties of iSCSI naming, rather than of names in use, An example of this being a big problem is the sentence about names needing to be "reasonably easy to compare" which is a disaster as with a MUST next to it in the specifiction, while it was fine for setting initial requirements. In addition, there may an editorial problem in the URN paragraph, as the current well-intentioned text could imply more than was intended. I will give you some future AD guidance after checking with an expert reviewer if there is an issue in this area. Do not change the text now. (2) Stringprep. Some of the text in Section 2.2.6.2 overlaps and duplicates material in the iSCSI stringprep draft. This is a problem, as the iSCSI stringprep draft should be a sufficient and complete specification of the application of stringprep to iSCSI. For example, listing the dash, dot, and colon characters as acceptable duplicates material in Sections 1 and 6.2 of the iSCSI stringprep draft. If these characters are mentioned in this section of the iSCSI draft, they should be described as reserved for use in formatting iSCSI names, as the stringprep draft is the appropriate place to specify them as allowed. (3) Handling of Security Considerations. Section 7's introduction is almost exactly right, except that it should make [SEC-IPS] more normative, by adding something like the following after the "SHOULD NOT" sentince: "[SEC-IPS] specifies the mechanisms that must be used in order to mitigate risks fully described in that document." This makes the ips-security normative for use if you want to deal with the threats. I don't think 2119 MUST is called for, but the idea comes across. Although Section 7 gives a good guideline, and gets the right stance about threats, with the addition of something like the language suggested, the introduction of authentication in in 2.2.3 gives very weak guidelines. This language is a problem: >As part of the login process, the initiator and target MAY wish to >authenticate each other and set a security association protocol for >the session. This can occur in many different ways and is subject to >negotiation. Make these MAYs stronger consistent with the rest of the specification. It is strongly expressed elsewhere that in some form authentication SHOULD be *used* in all circumstances. The situations in which no authentication is needed are sufficiently narrow to fall under RFC 2119, Section 3's definition of "SHOULD": 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. (4) Somewhere in Section 2, a paragraph is needed to explain iSCSI's overall approach to SCSI Task Management. The explanation is roughly: - SAM-2 specifies task management as if the initiator and target interacted synchronously (e.g., as they do over a parallel SCSI bus). - An iSCSI initiator and target interact asynchronously due to concurrency in the network and queuing of iSCSI commands received out of order (e.g., from different TCP connections) for in order delivery to the SCSI layer at the target. - In order to meet SAM-2's expectation that initiators will see a synchronous view of task management, iSCSI specifies the protocol mechanisms and implementation requirements needed to present a synchronous view in the presence of the actual asynchrony involved. This needs to be said in a simple introductory way beforehand to explain why so much that seems to be SCSI's job is being done by iSCSI. It's pure writing/context, no new technical content. (5) The abstract needs to be rewritten. The current abstract does an ok job of describing iSCSI to a storage-knowledgeable person, but should be expanded to provide a reasonable context and motivation for iSCSI to a *network-knowledgeable* person who may be encountering the *SCSI acronym for the first time. In addition, references are not allowed in abstracts; please delete the reference to "[SAM-2]". It's ok to mention SAM-2 in the abstract, but not ok to have an actual document reference. (6) The reference in the abstract is an example of a checklist fault. The chairs are checking the checklist, but if the editor can also do this, it'd be good, as should every editor with a draft in the working group. _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --=_alternative 001FBA7FC2256C60_= Content-Type: text/html; charset="US-ASCII"
Allison,

Thanks for your careful and timely comments. I thing we will be able to get the draft out before the cutoff date.

Regards,
Julo


Allison Mankin <mankin@east.isi.edu>
Sent by: ips-admin@ietf.org

28/10/02 03:48
Please respond to mankin

       
        To:        ips@ietf.org
        cc:        black_david@emc.com, erodrigu@brocade.com, sob@harvard.edu, mankin@psg.com
        Subject:        [Ips] AD comments for iSCSI

       


Folks,

The following are some AD comments on iSCSI which we would
like to have addressed before its IETF Last Call, presumably in
one more rev before the deadline.  Questions are welcome.

Onward and upward.

Allison

P.S. Congrats on the many drafts at or very close to
IETF Last Call - the Transport Area is very fond of WGs that
come to their conclusions.  

---------

The comments, after a useful discussion with your chairs:

(1) Naming.  Section 2.2.6.1 lists naming requirements
and uses "MUST" to impose them.  Most of these are not
requirements on implementations, rather they were design
requirements for iSCSI naming.  This section should
be rewritten to describe those requirements as important
properties of iSCSI naming, rather than of names in use,
An example of this being a big problem is the sentence about names
needing to be "reasonably easy to compare" which is a disaster as
with a MUST next to it in the specifiction, while it was fine
for setting initial requirements.

In addition, there may an editorial problem in the URN
paragraph, as the current well-intentioned text could
imply more than was intended.  I will give you some future
AD guidance after checking with an expert reviewer if there
is an issue in this area.  Do not change the text now.

(2) Stringprep.  Some of the text in Section 2.2.6.2
overlaps and duplicates material in the iSCSI stringprep
draft.  This is a problem, as the iSCSI stringprep draft
should be a sufficient and complete specification of the
application of stringprep to iSCSI.  For example, listing
the dash, dot, and colon characters as acceptable duplicates
material in Sections 1 and 6.2 of the iSCSI stringprep draft.
If these characters are mentioned in this section of the
iSCSI draft, they should be described as reserved for use
in formatting iSCSI names, as the stringprep draft is the
appropriate place to specify them as allowed.

(3) Handling of Security Considerations.   Section 7's
introduction is almost exactly right, except that it should
make [SEC-IPS] more normative, by adding something like the
following after the "SHOULD NOT" sentince:
"[SEC-IPS] specifies the mechanisms that must be used in order
to mitigate risks fully described in that document."
This makes the ips-security normative for use if you want
to deal with the threats.  I don't think 2119 MUST is called
for, but the idea comes across.

Although Section 7 gives a good guideline, and gets the right
stance about threats, with the addition of something like the
language suggested, the introduction of authentication in
in 2.2.3 gives very weak guidelines.  This language is a problem:
 
   >As part of the login process, the initiator and target MAY wish to
   >authenticate each other and set a security association protocol for
   >the session. This can occur in many different ways and is subject to
   >negotiation.

Make these MAYs stronger consistent with the rest of the specification.
It is strongly expressed elsewhere that in some form authentication
SHOULD be *used* in all circumstances.  The situations in which no
authentication is needed are sufficiently narrow to fall under RFC 2119,
Section 3's definition of "SHOULD":

  3. SHOULD  This word, or the adjective "RECOMMENDED", mean that
     there may exist valid reasons in particular circumstances to
     ignore a particular item, but the full implications must be
     understood and carefully weighed before choosing a
     different course.


(4) Somewhere in Section 2, a paragraph is needed to explain iSCSI's
overall approach to SCSI Task Management.  The explanation is roughly:
- SAM-2 specifies task management as if the initiator and
                target interacted synchronously (e.g., as they do over
                a parallel SCSI bus).
- An iSCSI initiator and target interact asynchronously due
                to concurrency in the network and queuing of iSCSI
                commands received out of order (e.g., from different
                TCP connections) for in order delivery to the SCSI
                layer at the target.
- In order to meet SAM-2's expectation that initiators will
                see a synchronous view of task management, iSCSI
                specifies the protocol mechanisms and implementation
                requirements needed to present a synchronous view in
                the presence of the actual asynchrony involved.

This needs to be said in a simple introductory way beforehand
to explain why so much that seems to be SCSI's job is being
done by iSCSI.  It's pure writing/context, no new technical
content.

(5) The abstract needs to be rewritten.  The current abstract
does an ok job of describing iSCSI to a storage-knowledgeable
person, but should be expanded to provide a reasonable context
and motivation for iSCSI to a *network-knowledgeable* person
who may be encountering the *SCSI acronym for the first time.
In addition, references are not allowed in abstracts; please
delete the reference to "[SAM-2]".  It's ok to mention SAM-2
in the abstract, but not ok to have an actual document reference.

(6) The reference in the abstract is an example of a checklist
fault.  The chairs are checking the checklist, but if the editor
can also do this, it'd be good, as should every editor with a draft
in the working group.


_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips
--=_alternative 001FBA7FC2256C60_=-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From owner-ips@ece.cmu.edu Mon Oct 28 02:53:18 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29707 for ; Mon, 28 Oct 2002 02:53:18 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g9S788927606 for ips-outgoing; Mon, 28 Oct 2002 02:08:08 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ariel.nishansystems.com (ultrex.nishansystems.com [12.36.127.195]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g9S786H27601 for ; Mon, 28 Oct 2002 02:08:07 -0500 (EST) Received: by ariel.nishansystems.com with Internet Mail Service (5.5.2653.19) id ; Sun, 27 Oct 2002 23:08:01 -0800 Message-ID: From: Joshua Tseng To: ips@ece.cmu.edu Subject: iSNS revision -14 has been submitted Date: Sun, 27 Oct 2002 23:08:00 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Folks, iSNS revision -14 has been submitted to IETF. For your convenience, I have also posted a pdf of the new draft here: www.nishansystems.com/ietf/draft-ietf-ips-isns-14.pdf Changes due to last call comments from the -13 revision are highlighted. Regards, Josh From owner-ips@ece.cmu.edu Tue Oct 29 17:17:11 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29321 for ; Tue, 29 Oct 2002 17:17:06 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g9TM1ec14552 for ips-outgoing; Tue, 29 Oct 2002 17:01:40 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from hammer.brocade.com (sj6-b.brocade.com [63.121.140.220]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g9TM1cH14548 for ; Tue, 29 Oct 2002 17:01:39 -0500 (EST) Received: from hq-ex-c3.brocade.com (hq-ex-c3.brocade.com [192.168.126.211]) by hammer.brocade.com (8.11.3/8.11.3) with ESMTP id g9TM1Wu03648 for ; Tue, 29 Oct 2002 14:01:33 -0800 (PST) Received: by hq-ex-c3.brocade.com with Internet Mail Service (5.5.2653.19) id <4LH1W0PD>; Tue, 29 Oct 2002 14:01:33 -0800 Message-ID: From: Elizabeth Rodriguez To: ips@ece.cmu.edu Subject: iSCSI: I-D ACTION:draft-krueger-iscsi-name-ext-00.txt Date: Tue, 29 Oct 2002 14:01:32 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C27F96.BD995600" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C27F96.BD995600 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C27F96.BD995600" ------_=_NextPart_001_01C27F96.BD995600 Content-Type: text/plain; charset="iso-8859-1" All, Here is the I-D announcement for the draft Marjorie referenced in her email entitled iSCSI: re: SCSI device names. Elizabeth -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Tuesday, October 29, 2002 3:17 AM Subject: I-D ACTION:draft-krueger-iscsi-name-ext-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Definition of an NAA naming format for iSCSI Node Names Author(s) : M. Krueger et al. Filename : draft-krueger-iscsi-name-ext-00.txt Pages : 10 Date : 2002-10-28 iSCSI is a SCSI transport protocol that maps the SCSI family of protocols onto TCP/IP [iSCSI]. This document defines an additional iSCSI node name type format to enable use of the NAA world wide naming format used by ANSI T11 Fibre Channel protocols. It is hoped that this definition would enable storage devices containing both iSCSI and FC ports to use the same NAA-based SCSI device name. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-krueger-iscsi-name-ext-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-krueger-iscsi-name-ext-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-krueger-iscsi-name-ext-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_001_01C27F96.BD995600 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable iSCSI: I-D ACTION:draft-krueger-iscsi-name-ext-00.txt

All,

Here is the I-D announcement for the draft Marjorie = referenced in her email entitled iSCSI: re: SCSI device names.

Elizabeth

-----Original Message-----
From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org= ]
Sent: Tuesday, October 29, 2002 3:17 AM
Subject: I-D = ACTION:draft-krueger-iscsi-name-ext-00.txt


A New Internet-Draft is available from the on-line = Internet-Drafts directories.


        Title           : = Definition of an NAA naming format for iSCSI Node
          &nb= sp;           &nb= sp;   Names
        Author(s)       : M. Krueger et = al.
        Filename        : = draft-krueger-iscsi-name-ext-00.txt
        Pages           : = 10
        Date    =         : 2002-10-28
       =20
iSCSI is a SCSI transport protocol that maps the = SCSI family of
protocols onto TCP/IP [iSCSI].  This document = defines an additional
iSCSI node name type format to enable use of the NAA = world wide naming
format used by ANSI T11 Fibre Channel = protocols.  It is hoped that this
definition would enable storage devices containing = both iSCSI and FC
ports to use the same NAA-based SCSI device = name.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-krueger-iscs= i-name-ext-00.txt

To remove yourself from the IETF Announcement list, = send a message to
ietf-announce-request with the word unsubscribe in = the body of the message.

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-krueger-iscsi-name-ext-00.txt".

A list of Internet-Drafts directories can be found = in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by = e-mail.

Send a message to:
        mailserv@ietf.org.
In the body type:
        "FILE = /internet-drafts/draft-krueger-iscsi-name-ext-00.txt".
       =20
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.
        =        =20
        =        =20
Below is the data which will enable a MIME compliant = mail reader
implementation to automatically retrieve the ASCII = version of the
Internet-Draft.

  ------_=_NextPart_001_01C27F96.BD995600-- ------_=_NextPart_000_01C27F96.BD995600 Content-Type: message/rfc822 To: Subject: Date: Tue, 29 Oct 2002 09:21:36 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01C27F96.BD995600" ------_=_NextPart_002_01C27F96.BD995600 Content-Type: multipart/alternative; boundary="----_=_NextPart_003_01C27F96.BD995600" ------_=_NextPart_003_01C27F96.BD995600 Content-Type: text/plain ------_=_NextPart_003_01C27F96.BD995600 Content-Type: text/html

  ------_=_NextPart_003_01C27F96.BD995600-- ------_=_NextPart_002_01C27F96.BD995600 Content-Type: application/octet-stream; name="ATT32019" Content-Disposition: attachment; filename="ATT32019" Content-type: message/external-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-10-28163200.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-krueger-iscsi-name-ext-00.txt ------_=_NextPart_002_01C27F96.BD995600 Content-Type: message/external-body; site="internet-drafts"; dir="draft-krueger-iscsi-name-ext-00.txt"; mode="ftp.ietf.org"; access-type="anon-ftp" ------_=_NextPart_002_01C27F96.BD995600-- ------_=_NextPart_000_01C27F96.BD995600-- From owner-ips@ece.cmu.edu Tue Oct 29 17:18:05 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29378 for ; Tue, 29 Oct 2002 17:18:05 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g9TLST712756 for ips-outgoing; Tue, 29 Oct 2002 16:28:29 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g9TLSHH12737 for ; Tue, 29 Oct 2002 16:28:18 -0500 (EST) Received: from xparelay1.ptp.hp.com (xparelay1.ptp.hp.com [15.1.28.62]) by palrel11.hp.com (Postfix) with ESMTP id 42A3C600450; Tue, 29 Oct 2002 13:28:14 -0800 (PST) Received: from xpabh1.ptp.hp.com (xpabh1.ptp.hp.com [15.1.28.60]) by xparelay1.ptp.hp.com (Postfix) with ESMTP id BDFDEE00096; Tue, 29 Oct 2002 13:28:09 -0800 (PST) Received: by xpabh1.ptp.hp.com with Internet Mail Service (5.5.2655.55) id ; Tue, 29 Oct 2002 13:28:09 -0800 Message-ID: <6BD67FFB937FD411A04F00D0B74FE878102F5CFD@xrose06.rose.hp.com> From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" To: "'Black_David@emc.com'" , cbm@rose.hp.com, Julian_Satran@il.ibm.com Cc: "ELLIOTT,ROBERT (HP-Houston,Server Storage)" , erodrigu@Brocade.COM, "John Hufferd (hufferd@us.ibm.com)" , IPS Subject: iSCSI: re: SCSI device names Date: Tue, 29 Oct 2002 13:27:47 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain Sender: owner-ips@ece.cmu.edu Precedence: bulk David, As you suggest, I've written a draft proposal to add an "naa." format to iSCSI name formats and posted it before the draft-00 cutoff. The draft is available at http://www.ietf.org/internet-drafts/draft-krueger-iscsi-name-ext-00.txt Could we please have 30 minutes of agenda time at the Atlanta IETF to discuss this proposal? Thank you Marjorie Krueger Networked Storage Architecture Networked Storage Solutions Hewlett-Packard > -----Original Message----- > From: Black_David@emc.com [mailto:Black_David@emc.com] > Sent: Wednesday, October 23, 2002 12:53 PM > To: cbm@rose.hp.com; Julian_Satran@il.ibm.com; Black_David@emc.com > Cc: elliott@hp.com; marjorie_krueger@hp.com; erodrigu@brocade.com > Subject: RE: SCSI device names > > > Mallikarjun (and Rob), > > Turning the iSCSI naming architecture into a T10 standard is > fine, but it looks like there's an item going back the other > way to bless the use of "naa." names with iSCSI. I think the > window is closed on functional additions to the main iSCSI > draft, so any addition of "naa." should be written up as a > separate draft including all of the explanations of and > references to use of names for the same device across > multiple protocols. The WG would need to discuss whether to > allow use of "naa." as a full iSCSI name vs. as a unique ID > returned only by VPD mode page access and the like. > > There's still time to get a -00 draft in by the > Atlanta cutoff (9am, Monday, October 28th) - I strongly > suggest doing so in order to get this onto the Atlanta IPS > agenda. Don't worry about fully polishing the draft, as the > major point is to tee up a discussion. > > Thanks, > --David > ---------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 176 South St., Hopkinton, MA 01748 > +1 (508) 293-7953 **NEW** FAX: +1 (508) 293-7786 > black_david@emc.com Mobile: +1 (978) 394-7754 > ---------------------------------------------------- > > > -----Original Message----- > > From: Mallikarjun C. [mailto:cbm@rose.hp.com] > > Sent: Wednesday, October 23, 2002 3:34 PM > > To: Julian Satran; Black_David@emc.com > > Cc: Rob Elliott; Marjorie > > Subject: Fw: SCSI device names > > > > > > Julian and David, > > > > Don't know if you're following this thread on T10, FYI. > > > > Rob and I talked about this, I think it's a good idea to turn iSCSI's > > naming architeture into a T10 standard (if it's agreeable to T10 CAP). > > This also gets us out of the predicament of having LU WWNs contain > > (implicit) iSCSI-dependencies (because LU WWNs are keyed off of the > > unique device/port name). > > > > If iSCSI's enhancements that Rob refers to below could not be > > added to iSCSI rev19, then I suppose it'd have to wait for iSCSI's > > standards status. David, can you please comment? In any case, > > it shouldn't prevent T10 from adopting this into SPC-3. > > -- > > Mallikarjun > > > > Mallikarjun Chadalapaka > > Networked Storage Architecture > > Network Storage Solutions > > Hewlett-Packard MS 5668 > > Roseville CA 95747 > > cbm@rose.hp.com > > > > ----- Original Message ----- > > From: "Elliott, Robert (Server Storage)" > > To: > > Sent: Tuesday, October 22, 2002 5:23 PM > > Subject: SCSI device names > > > > > > The current rule in SAM-3 is that a device may have one > > device name per > > transport protocol. This means, for example, that a target > > device with > > both SAS and iSCSI target ports has two device names - the > iSCSI name > > and the SAS device name. > > > > Assuming 02-254 (WWNs for W-LUNs) passes, these would be > > returned as two > > device identifiers in VPD data: > > 1. SAS device name > > association=target device (2h) > > protocol identifier=SAS (6h) > > identifier type=NAA (3h) > > identifier=IEEE Registered format (NAA=5h), 8 bytes long > > > > 2. iSCSI device name > > association=target device (2h) > > protocol identifier=iSCSI (5h) > > identifier type=iSCSI name-based (7h) (to be proposed in 02-419) > > identifier=UTF-8 format string, up to 224 bytes long > > > > It would be simpler if there were only one device name for a device. > > > > Since only iSCSI has defined device names to date (SAS is > > just planning > > to include a device name now, and FCP-3 might define one > too), we have > > an opportunity to make all device names follow the iSCSI name-based > > format and let each device have a single device name regardless of > > protocol. > > > > The iSCSI name format is a UTF-8 (similar to ASCII) string > that starts > > with a naming authority: "iqn." for an iSCSI-defined > reverse domain > > name string (e.g. > > "iqn.2001-04.com.acme:storage.disk2.sys1.xyz") > > "eui." for a hexadecimal representation of an EUI-64 > identifier (e.g. > > "eui.02004567A425678D") > > > > iSCSI could easily add an "naa." type to carry a hexadecimal > > representation of an NAA identifier (e.g. "naa.52004567A425678D"), > > needed to carry the format used by SAS and Fibre Channel port names. > > > > Then, a target device with target ports of different > > protocols could use > > any string format it likes as its sole device name. > > > > Likely choices: > > iSCSI-only device: "iqn." (it may have no hardware names available) > > SAS-only device: "naa." FC-only device: "naa." > > SRP-only device: "eui." > > SBP-2-only device: "eui." > > iSCSI/SAS combination device: "naa." since it is already using NAA > > identifiers available for port names > > SRP/iSCSI/SAS combination device: "naa." or "eui." since it > > already has > > NAA and EUI-64s for port names > > > > This would divorce the device name concept from the transport > > protocols. > > Transport protocols could still require their devices have a device > > name, but wouldn't comment on the format. > > > > -- > > Rob Elliott, elliott@hp.com > > Industry Standard Server Storage Advanced Technology Hewlett-Packard > > > > > > > > > From owner-ips@ece.cmu.edu Tue Oct 29 18:14:52 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01043 for ; Tue, 29 Oct 2002 18:14:52 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g9TMaHk16401 for ips-outgoing; Tue, 29 Oct 2002 17:36:17 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lucy.trebia.com ([65.192.191.151]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g9TMDNH15229 for ; Tue, 29 Oct 2002 17:13:23 -0500 (EST) Received: by lucy with Internet Mail Service (5.5.2653.19) id ; Tue, 29 Oct 2002 17:13:21 -0500 Message-ID: <63616B261CEFD411834D00D0B7A86CF70116282B@lucy> From: Jamie Tuttle To: "'ips@ece.cmu.edu'" Subject: Text Mode Negotiation Date: Tue, 29 Oct 2002 17:13:21 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-ips@ece.cmu.edu Precedence: bulk IPS, This may have been asked, however I was unable to find it looking through the archive. I have a case in which I am trying to determine the appropriate response of an iSCSI target to the Text Negotiation of declarative in which the value declared is not a valid value. Example: During Full Feature Phase an Initiator declares the key MaxRecvDataSegmentLength=0. This is obviously a failure/error condition. If the Target responds with a text response with the F bit set does that imply that the value was accepted by the Target, or does it imply that it was rejected by the Target, thus using the previous value? The Target cannot respond with a text response with the key MaxRecvDataSegmentLength=Reject since this a declarative key. Should the Target close the connection? Any direction in this matter will be greatly appreciated. Thanks, Jamie Tuttle From owner-ips@ece.cmu.edu Wed Oct 30 09:53:09 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17376 for ; Wed, 30 Oct 2002 09:53:08 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g9UEAIt01511 for ips-outgoing; Wed, 30 Oct 2002 09:10:18 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mailserver.dcmtech.co.in (IDENT:028JOur4DM930YJggqM7ciYvK9nFawuJ@[203.190.136.131]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g9U5CcH01791 for ; Wed, 30 Oct 2002 00:12:41 -0500 (EST) Received: from dcmtech.co.in ([192.9.200.181]) by mailserver.dcmtech.co.in (8.11.6/8.11.6) with ESMTP id g9U4oA531317 for ; Wed, 30 Oct 2002 04:50:11 GMT Message-ID: <3DBFB938.9050800@dcmtech.co.in> Date: Wed, 30 Oct 2002 10:49:28 +0000 From: nitin dhingra User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ips@ece.cmu.edu Subject: iscsi: DH-CHAP Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Has the implementation of DH-CHAP been removed from iScsi?? What all authentication algorithms are being used for inter-op?? Sorry to ask the question a bit late... Regards, Nitin Dhingra From owner-ips@ece.cmu.edu Wed Oct 30 09:54:05 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17465 for ; Wed, 30 Oct 2002 09:54:04 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g9UEAuV01539 for ips-outgoing; Wed, 30 Oct 2002 09:10:56 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g9UBMPH25058 for ; Wed, 30 Oct 2002 06:22:25 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09225; Wed, 30 Oct 2002 06:20:01 -0500 (EST) Message-Id: <200210301120.GAA09225@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ips@ece.cmu.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ips-scsi-mib-04.txt Date: Wed, 30 Oct 2002 06:20:01 -0500 Sender: owner-ips@ece.cmu.edu Precedence: bulk --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 : Definition of Managed Objects for SCSI Entities Author(s) : M. Hallak-Stamler, M. Bakke et al. Filename : draft-ietf-ips-scsi-mib-04.txt Pages : 73 Date : 2002-10-29 This memo defines a Management Information Base (MIB) for Small Computer System Interface (SCSI) entities, independently of the interconnect subsystem layer. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-scsi-mib-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-scsi-mib-04.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-scsi-mib-04.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: <2002-10-29130542.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-scsi-mib-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-scsi-mib-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-29130542.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ips@ece.cmu.edu Wed Oct 30 10:58:39 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21521 for ; Wed, 30 Oct 2002 10:58:38 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g9UFKcf05550 for ips-outgoing; Wed, 30 Oct 2002 10:20:38 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g9UFKaH05545 for ; Wed, 30 Oct 2002 10:20:36 -0500 (EST) Received: from cisco.com (dhcp-64-101-211-211.cisco.com [64.101.211.211]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id KAA10054; Wed, 30 Oct 2002 10:20:08 -0500 (EST) Message-ID: <3DBFF8A8.FD0E6C8D@cisco.com> Date: Wed, 30 Oct 2002 09:20:08 -0600 From: Steve Senum X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: nitin dhingra CC: ips@ece.cmu.edu Subject: Re: iscsi: DH-CHAP References: <3DBFB938.9050800@dcmtech.co.in> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Nitin Dhingra, DH-CHAP was never in iSCSI, it was just a proposal. The CHAP protocol is a MUST implement. Regards, Steve Senum nitin dhingra wrote: > > Has the implementation of DH-CHAP been removed from iScsi?? > What all authentication algorithms are being used for inter-op?? > Sorry to ask the question a bit late... > > Regards, > Nitin Dhingra From owner-ips@ece.cmu.edu Wed Oct 30 13:49:19 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03474 for ; Wed, 30 Oct 2002 13:49:18 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g9UHwqo16284 for ips-outgoing; Wed, 30 Oct 2002 12:58:52 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from astuteexchange.astutenetworks.com (2.astutenetworks.com [216.142.74.2]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g9UHwnH16267 for ; Wed, 30 Oct 2002 12:58:49 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: I-D ACTION:draft-ietf-ips-scsi-mib-04.txt Date: Wed, 30 Oct 2002 09:58:47 -0800 Message-ID: <963D0218414F5C4A9A4CFD221C3BA704149DB8@astuteexchange.astutenetworks.com> Thread-Topic: I-D ACTION:draft-ietf-ips-scsi-mib-04.txt Thread-Index: AcKAJM2iSfMGtQYbTtWjs597rEr/oAAF0wKw From: "Amir Shalit" To: Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id g9UHwnH16272 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit I have two comments: 1) Read/Write counters Counter32 (counting MB transferred) wrap at about 1000 hours on 10Gbps links. Can we the MIB use a Counter64 instead? 2) Virtualization An attempt was made to list all LU's which are part of a LUN. In my opinion, the ultimate mechanism to represent hierarchical volumes is via a volume manager MIB. For the time being it will be useful to associate a {start LBA, end LBA} vector with each LU to allow for most simplistic virtualization mapping. Amir -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Wednesday, October 30, 2002 3:20 AM Cc: ips@ece.cmu.edu Subject: I-D ACTION:draft-ietf-ips-scsi-mib-04.txt 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 : Definition of Managed Objects for SCSI Entities Author(s) : M. Hallak-Stamler, M. Bakke et al. Filename : draft-ietf-ips-scsi-mib-04.txt Pages : 73 Date : 2002-10-29 This memo defines a Management Information Base (MIB) for Small Computer System Interface (SCSI) entities, independently of the interconnect subsystem layer. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-scsi-mib-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-scsi-mib-04.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-scsi-mib-04.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. From owner-ips@ece.cmu.edu Wed Oct 30 14:05:07 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04357 for ; Wed, 30 Oct 2002 14:05:07 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g9UIc7w18911 for ips-outgoing; Wed, 30 Oct 2002 13:38:07 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from atlrel6.hp.com (atlrel6.hp.com [156.153.255.205]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g9UIc4H18905 for ; Wed, 30 Oct 2002 13:38:05 -0500 (EST) Received: from xatlrelay2.atl.hp.com (xatlrelay2.atl.hp.com [15.45.89.191]) by atlrel6.hp.com (Postfix) with ESMTP id 30558190; Wed, 30 Oct 2002 13:38:04 -0500 (EST) Received: from xatlbh1.atl.hp.com (xatlbh1.atl.hp.com [15.45.89.186]) by xatlrelay2.atl.hp.com (Postfix) with ESMTP id 65968400104; Wed, 30 Oct 2002 13:37:43 -0500 (EST) Received: by xatlbh1.atl.hp.com with Internet Mail Service (5.5.2655.55) id ; Wed, 30 Oct 2002 13:37:13 -0500 Message-ID: <6BD67FFB937FD411A04F00D0B74FE878102F5D07@xrose06.rose.hp.com> From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" To: "'Amir Shalit'" Cc: ips@ece.cmu.edu Subject: RE: I-D ACTION:draft-ietf-ips-scsi-mib-04.txt Date: Wed, 30 Oct 2002 13:36:54 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain Sender: owner-ips@ece.cmu.edu Precedence: bulk > 1) Read/Write counters > > Counter32 (counting MB transferred) wrap at about 1000 hours > on 10Gbps links. > Can we the MIB use a Counter64 instead? We want to accommodate SNMPv1 agents (which can't implement Counter64), so we can add an optional counter64. Thanks for the reminder! > 2) Virtualization > > An attempt was made to list all LU's which are part of a LUN. > In my opinion, the ultimate mechanism to represent > hierarchical volumes is via a volume manager MIB. For the > time being it will be useful to associate a {start LBA, end > LBA} vector with each LU to allow for most simplistic > virtualization mapping. I'm not sure what you mean. The MIB lists all the LU's that are contained within a Target device, and then a table of all the LUN mappings for those LU's. I don't really think of "LU's being part of a LUN" - the MIB doesn't try to accommodate virtualization, we agree that virtualization is better represented via another MIB. This MIB is an attempt to represent the simple (average?) SCSI device. Section 3.4 states that this MIB is not meant to address virtual devices, merely the "visible SCSI attributes" (what a host will see). Regards, Marjorie Krueger Networked Storage Architecture Networked Storage Solutions Hewlett-Packard From owner-ips@ece.cmu.edu Wed Oct 30 14:29:06 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05674 for ; Wed, 30 Oct 2002 14:29:06 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g9UJ7JW20804 for ips-outgoing; Wed, 30 Oct 2002 14:07:19 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from astuteexchange.astutenetworks.com (2.astutenetworks.com [216.142.74.2]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g9UJ7FH20799 for ; Wed, 30 Oct 2002 14:07:15 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: I-D ACTION:draft-ietf-ips-scsi-mib-04.txt Date: Wed, 30 Oct 2002 11:07:15 -0800 Message-ID: <963D0218414F5C4A9A4CFD221C3BA704149DBA@astuteexchange.astutenetworks.com> Thread-Topic: I-D ACTION:draft-ietf-ips-scsi-mib-04.txt Thread-Index: AcKARoymGFSDU3F8QZWzWl2dbe/vHwAABQVQ From: "Amir Shalit" To: "Mark Bakke" , "KRUEGER,MARJORIE (HP-Roseville,ex1)" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id g9UJ7GH20800 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit I agree on both counts. Its only that the expression "LUN mapping" got me confused with "virtualization LUN mapping". Amir -----Original Message----- From: Mark Bakke [mailto:mbakke@cisco.com] Sent: Wednesday, October 30, 2002 11:00 AM To: KRUEGER,MARJORIE (HP-Roseville,ex1) Cc: Amir Shalit; ips@ece.cmu.edu Subject: Re: I-D ACTION:draft-ietf-ips-scsi-mib-04.txt "KRUEGER,MARJORIE (HP-Roseville,ex1)" wrote: > > > 1) Read/Write counters > > > > Counter32 (counting MB transferred) wrap at about 1000 hours on > > 10Gbps links. Can we the MIB use a Counter64 instead? > > We want to accommodate SNMPv1 agents (which can't implement > Counter64), so we can add an optional counter64. Thanks for the > reminder! Since we are back to an optional counter64, should it be in bytes instead of MB? > > > 2) Virtualization > > > > An attempt was made to list all LU's which are part of a LUN. In my > > opinion, the ultimate mechanism to represent hierarchical volumes is > > via a volume manager MIB. For the time being it will be useful to > > associate a {start LBA, end LBA} vector with each LU to allow for > > most simplistic virtualization mapping. > > I'm not sure what you mean. The MIB lists all the LU's that are > contained within a Target device, and then a table of all the LUN > mappings for those LU's. I don't really think of "LU's being part of > a LUN" - the MIB doesn't try to accommodate virtualization, we agree > that virtualization is better represented via another MIB. This MIB > is an attempt to represent the simple > (average?) SCSI device. Section 3.4 states that this MIB is not meant to > address virtual devices, merely the "visible SCSI attributes" (what a host > will see). I agree with Marj. Note that even target mapping (e.g. map a FC target to an iSCSI target) or LUN mapping are outside the scope of a SCSI MIB. > Regards, > Marjorie Krueger > Networked Storage Architecture > Networked Storage Solutions > Hewlett-Packard -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Wed Oct 30 14:29:12 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05698 for ; Wed, 30 Oct 2002 14:29:12 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g9UIxCG20250 for ips-outgoing; Wed, 30 Oct 2002 13:59:12 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cygnus.equallogic.com (cygnus.equallogic.com [65.170.102.10]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g9UIx9H20245 for ; Wed, 30 Oct 2002 13:59:09 -0500 (EST) Received: from cygnus.equallogic.com (localhost.localdomain [127.0.0.1]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g9UIx4W32446 for ; Wed, 30 Oct 2002 13:59:04 -0500 Received: from deneb.dev.equallogic.com (deneb.dev.equallogic.com [172.16.1.99]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id g9UIx3532437; Wed, 30 Oct 2002 13:59:03 -0500 Received: from pkoning.dev.equallogic.com.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.6) with ESMTP id g9UIx3o02789; Wed, 30 Oct 2002 13:59:03 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15808.11255.149064.72807@pkoning.dev.equallogic.com> Date: Wed, 30 Oct 2002 13:59:03 -0500 From: Paul Koning To: amir@astutenetworks.com Cc: ips@ece.cmu.edu Subject: RE: I-D ACTION:draft-ietf-ips-scsi-mib-04.txt References: <963D0218414F5C4A9A4CFD221C3BA704149DB8@astuteexchange.astutenetworks.com> X-Mailer: VM 7.07 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit >>>>> "Amir" == Amir Shalit writes: Amir> I have two comments: 1) Read/Write counters Amir> Counter32 (counting MB transferred) wrap at about 1000 hours on Amir> 10Gbps links. Can we the MIB use a Counter64 instead? Makes sense to me. Amir> 2) Virtualization Amir> An attempt was made to list all LU's which are part of a LUN. Amir> In my opinion, the ultimate mechanism to represent hierarchical Amir> volumes is via a volume manager MIB. For the time being it will Amir> be useful to associate a {start LBA, end LBA} vector with each Amir> LU to allow for most simplistic virtualization mapping. I don't like this idea at all. Let's keep that stuff out of this MIB. paul From owner-ips@ece.cmu.edu Wed Oct 30 14:30:47 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05838 for ; Wed, 30 Oct 2002 14:30:47 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g9UJ09f20321 for ips-outgoing; Wed, 30 Oct 2002 14:00:09 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g9UJ07H20315 for ; Wed, 30 Oct 2002 14:00:07 -0500 (EST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.70.145.31]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g9UIxpxF010182; Wed, 30 Oct 2002 10:59:51 -0800 (PST) Received: from nisser.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.12.2/8.12.2) with ESMTP id g9UIxmFB017621; Wed, 30 Oct 2002 10:59:49 -0800 (PST) Received: from cisco.com (mbakke-lnx2.cisco.com [64.101.211.59]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id KAA01695; Wed, 30 Oct 2002 10:59:52 -0800 (PST) Message-ID: <3DC02C29.EA879F0@cisco.com> Date: Wed, 30 Oct 2002 12:59:53 -0600 From: Mark Bakke X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.9-34.cisco.2 i686) X-Accept-Language: en, de MIME-Version: 1.0 To: "KRUEGER,MARJORIE (HP-Roseville,ex1)" CC: "'Amir Shalit'" , ips@ece.cmu.edu Subject: Re: I-D ACTION:draft-ietf-ips-scsi-mib-04.txt References: <6BD67FFB937FD411A04F00D0B74FE878102F5D07@xrose06.rose.hp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit "KRUEGER,MARJORIE (HP-Roseville,ex1)" wrote: > > > 1) Read/Write counters > > > > Counter32 (counting MB transferred) wrap at about 1000 hours > > on 10Gbps links. > > Can we the MIB use a Counter64 instead? > > We want to accommodate SNMPv1 agents (which can't implement Counter64), so > we can add an optional counter64. Thanks for the reminder! Since we are back to an optional counter64, should it be in bytes instead of MB? > > > 2) Virtualization > > > > An attempt was made to list all LU's which are part of a LUN. > > In my opinion, the ultimate mechanism to represent > > hierarchical volumes is via a volume manager MIB. For the > > time being it will be useful to associate a {start LBA, end > > LBA} vector with each LU to allow for most simplistic > > virtualization mapping. > > I'm not sure what you mean. The MIB lists all the LU's that are contained > within a Target device, and then a table of all the LUN mappings for those > LU's. I don't really think of "LU's being part of a LUN" - the MIB doesn't > try to accommodate virtualization, we agree that virtualization is better > represented via another MIB. This MIB is an attempt to represent the simple > (average?) SCSI device. Section 3.4 states that this MIB is not meant to > address virtual devices, merely the "visible SCSI attributes" (what a host > will see). I agree with Marj. Note that even target mapping (e.g. map a FC target to an iSCSI target) or LUN mapping are outside the scope of a SCSI MIB. > Regards, > Marjorie Krueger > Networked Storage Architecture > Networked Storage Solutions > Hewlett-Packard -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Wed Oct 30 14:40:28 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06370 for ; Wed, 30 Oct 2002 14:40:28 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g9UJIrW21525 for ips-outgoing; Wed, 30 Oct 2002 14:18:53 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from atlrel6.hp.com (atlrel6.hp.com [156.153.255.205]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g9UJIkH21519 for ; Wed, 30 Oct 2002 14:18:50 -0500 (EST) Received: from xatlrelay1.atl.hp.com (xatlrelay1.atl.hp.com [15.45.89.190]) by atlrel6.hp.com (Postfix) with ESMTP id 48641211; Wed, 30 Oct 2002 14:18:46 -0500 (EST) Received: from xatlbh2.atl.hp.com (xatlbh2.atl.hp.com [15.45.89.187]) by xatlrelay1.atl.hp.com (Postfix) with ESMTP id F16DB1A2; Wed, 30 Oct 2002 14:18:20 -0500 (EST) Received: by xatlbh2.atl.hp.com with Internet Mail Service (5.5.2655.55) id ; Wed, 30 Oct 2002 14:18:10 -0500 Message-ID: <6BD67FFB937FD411A04F00D0B74FE878102F5D0B@xrose06.rose.hp.com> From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" To: "'Amir Shalit'" , Mark Bakke Cc: ips@ece.cmu.edu Subject: RE: I-D ACTION:draft-ietf-ips-scsi-mib-04.txt Date: Wed, 30 Oct 2002 14:17:50 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain Sender: owner-ips@ece.cmu.edu Precedence: bulk When I refer to a "LUN map", I mean that set of LUNs that a target will export to a given initiator port. There is a mapping between a particular LUN and a target's LU. Some target's simply have a default LUN for each LU, and so the target conceptually only has one "LUN map". Some targets determine which LUN to export for an LU based on the I-T-L relationship. That target would have multiple LUN maps. This concept of "LUN mapping" does not accommodate a single LUN mapping to multiple LU's - that is virtualization (or one aspect of it). Please note: I'm not trying to force a particular definition of "LUN mapping", I'm just telling you what I mean when I use the term in reference to the SCSI MIB. > -----Original Message----- > From: Amir Shalit [mailto:amir@astutenetworks.com] > Sent: Wednesday, October 30, 2002 11:07 AM > To: Mark Bakke; KRUEGER,MARJORIE (HP-Roseville,ex1) > Cc: ips@ece.cmu.edu > Subject: RE: I-D ACTION:draft-ietf-ips-scsi-mib-04.txt > > > I agree on both counts. > > Its only that the expression "LUN mapping" got me confused > with "virtualization LUN mapping". > > Amir > > -----Original Message----- > From: Mark Bakke [mailto:mbakke@cisco.com] > Sent: Wednesday, October 30, 2002 11:00 AM > To: KRUEGER,MARJORIE (HP-Roseville,ex1) > Cc: Amir Shalit; ips@ece.cmu.edu > Subject: Re: I-D ACTION:draft-ietf-ips-scsi-mib-04.txt > > > "KRUEGER,MARJORIE (HP-Roseville,ex1)" wrote: > > > > > 1) Read/Write counters > > > > > > Counter32 (counting MB transferred) wrap at about 1000 hours on > > > 10Gbps links. Can we the MIB use a Counter64 instead? > > > > We want to accommodate SNMPv1 agents (which can't implement > > Counter64), so we can add an optional counter64. Thanks for the > > reminder! > > Since we are back to an optional counter64, should it be in > bytes instead of MB? > > > > > > 2) Virtualization > > > > > > An attempt was made to list all LU's which are part of a > LUN. In my > > > opinion, the ultimate mechanism to represent hierarchical > volumes is > > > > via a volume manager MIB. For the time being it will be useful to > > > associate a {start LBA, end LBA} vector with each LU to allow for > > > most simplistic virtualization mapping. > > > > I'm not sure what you mean. The MIB lists all the LU's that are > > contained within a Target device, and then a table of all the LUN > > mappings for those LU's. I don't really think of "LU's > being part of > > a LUN" - the MIB doesn't try to accommodate virtualization, > we agree > > that virtualization is better represented via another MIB. > This MIB > > is an attempt to represent the simple > > (average?) SCSI device. Section 3.4 states that this MIB > is not meant > to > > address virtual devices, merely the "visible SCSI > attributes" (what a > host > > will see). > > I agree with Marj. Note that even target mapping (e.g. map a > FC target to an iSCSI target) or LUN mapping are outside the > scope of a SCSI MIB. > > > Regards, > > Marjorie Krueger > > Networked Storage Architecture > > Networked Storage Solutions > > Hewlett-Packard > > -- > Mark A. Bakke > Cisco Systems > mbakke@cisco.com > 763.398.1054 > From owner-ips@ece.cmu.edu Wed Oct 30 16:55:56 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14602 for ; Wed, 30 Oct 2002 16:55:56 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g9ULDRk28937 for ips-outgoing; Wed, 30 Oct 2002 16:13:27 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g9ULDOH28928 for ; Wed, 30 Oct 2002 16:13:24 -0500 (EST) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id C162C30706; Wed, 30 Oct 2002 16:13:23 -0500 (EST) Date: Wed, 30 Oct 2002 12:11:40 -0800 (PST) From: Bill Studenmund X-X-Sender: To: Amir Shalit Cc: , Subject: RE: I-D ACTION:draft-ietf-ips-scsi-mib-04.txt In-Reply-To: <963D0218414F5C4A9A4CFD221C3BA704149DB8@astuteexchange.astutenetworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Wed, 30 Oct 2002, Amir Shalit wrote: > I have two comments: > > 1) Read/Write counters > > Counter32 (counting MB transferred) wrap at about 1000 hours on 10Gbps > links. > Can we the MIB use a Counter64 instead? Why? Looking at the description of Countter64 in _Understanding_SNMP_MIBs_ by Perkins & McGinnis, page 47, middle of "behavior" paragraph, "This type may only be used when a 32-bit counter rollover could occur in less than an hour. Otherwise the Counter32 type must be used." While that book isn't an RFC, the authors know a lot about SNMP. I doubt they would write the above if it weren't standard policy. Looking at my copy of SNMPv2-SMI.txt, I also find: -- for counters that wrap in less than one hour with only 32 bits Counter64 ::= [APPLICATION 6] IMPLICIT INTEGER (0..18446744073709551615) Digging around some more, in section 7.1.11of RFC 1442 (SMI for SNMPv2): A requirement on "standard" MIB modules is that the Counter64 type may be used only if the information being modeled would wrap in less than one hour if the Counter32 type was used instead. So since 1000 hours >> 1 hour, looks like RFC 1442 says, no we can't use a counter64. Take care, Bill From owner-ips@ece.cmu.edu Wed Oct 30 23:50:16 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26120 for ; Wed, 30 Oct 2002 23:50:15 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g9V3vOx18392 for ips-outgoing; Wed, 30 Oct 2002 22:57:24 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic2.corp.emc.com (mxic2.us.dg.com [128.221.31.40]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g9V3vNH18388 for ; Wed, 30 Oct 2002 22:57:23 -0500 (EST) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Wed, 30 Oct 2002 22:57:12 -0500 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C4BB@CORPMX14> From: Black_David@emc.com To: marjorie.krueger@hp.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: re: SCSI device names Date: Wed, 30 Oct 2002 22:57:08 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Marj, It'll be on the agenda. Please ensure that the slides describing the proposal are clear about the cross-transport SCSI motivations/aspects (i.e., provide a clear description of the problem(s) that this proposal is intended to solve). Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 **NEW** FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- > -----Original Message----- > From: KRUEGER,MARJORIE (HP-Roseville,ex1) > [mailto:marjorie.krueger@hp.com] > Sent: Tuesday, October 29, 2002 4:28 PM > To: 'Black_David@emc.com'; cbm@rose.hp.com; Julian_Satran@il.ibm.com > Cc: ELLIOTT,ROBERT (HP-Houston,Server Storage); erodrigu@brocade.com; > John Hufferd (hufferd@us.ibm.com); IPS > Subject: iSCSI: re: SCSI device names > > > David, > As you suggest, I've written a draft proposal to add an > "naa." format to > iSCSI name formats and posted it before the draft-00 cutoff. > The draft is > available at > http://www.ietf.org/internet-drafts/draft-krueger-iscsi-name-e > xt-00.txt > > Could we please have 30 minutes of agenda time at the Atlanta IETF to > discuss this proposal? > > Thank you > Marjorie Krueger > Networked Storage Architecture > Networked Storage Solutions > Hewlett-Packard > > > -----Original Message----- > > From: Black_David@emc.com [mailto:Black_David@emc.com] > > Sent: Wednesday, October 23, 2002 12:53 PM > > To: cbm@rose.hp.com; Julian_Satran@il.ibm.com; Black_David@emc.com > > Cc: elliott@hp.com; marjorie_krueger@hp.com; erodrigu@brocade.com > > Subject: RE: SCSI device names > > > > > > Mallikarjun (and Rob), > > > > Turning the iSCSI naming architecture into a T10 standard is > > fine, but it looks like there's an item going back the other > > way to bless the use of "naa." names with iSCSI. I think the > > window is closed on functional additions to the main iSCSI > > draft, so any addition of "naa." should be written up as a > > separate draft including all of the explanations of and > > references to use of names for the same device across > > multiple protocols. The WG would need to discuss whether to > > allow use of "naa." as a full iSCSI name vs. as a unique ID > > returned only by VPD mode page access and the like. > > > > There's still time to get a -00 draft in by the > > Atlanta cutoff (9am, Monday, October 28th) - I strongly > > suggest doing so in order to get this onto the Atlanta IPS > > agenda. Don't worry about fully polishing the draft, as the > > major point is to tee up a discussion. > > > > Thanks, > > --David > > ---------------------------------------------------- > > David L. Black, Senior Technologist > > EMC Corporation, 176 South St., Hopkinton, MA 01748 > > +1 (508) 293-7953 **NEW** FAX: +1 (508) 293-7786 > > black_david@emc.com Mobile: +1 (978) 394-7754 > > ---------------------------------------------------- > > > > > -----Original Message----- > > > From: Mallikarjun C. [mailto:cbm@rose.hp.com] > > > Sent: Wednesday, October 23, 2002 3:34 PM > > > To: Julian Satran; Black_David@emc.com > > > Cc: Rob Elliott; Marjorie > > > Subject: Fw: SCSI device names > > > > > > > > > Julian and David, > > > > > > Don't know if you're following this thread on T10, FYI. > > > > > > Rob and I talked about this, I think it's a good idea to > turn iSCSI's > > > naming architeture into a T10 standard (if it's agreeable > to T10 CAP). > > > This also gets us out of the predicament of having LU > WWNs contain > > > (implicit) iSCSI-dependencies (because LU WWNs are keyed > off of the > > > unique device/port name). > > > > > > If iSCSI's enhancements that Rob refers to below could not be > > > added to iSCSI rev19, then I suppose it'd have to wait for iSCSI's > > > standards status. David, can you please comment? In any case, > > > it shouldn't prevent T10 from adopting this into SPC-3. > > > -- > > > Mallikarjun > > > > > > Mallikarjun Chadalapaka > > > Networked Storage Architecture > > > Network Storage Solutions > > > Hewlett-Packard MS 5668 > > > Roseville CA 95747 > > > cbm@rose.hp.com > > > > > > ----- Original Message ----- > > > From: "Elliott, Robert (Server Storage)" > > > To: > > > Sent: Tuesday, October 22, 2002 5:23 PM > > > Subject: SCSI device names > > > > > > > > > The current rule in SAM-3 is that a device may have one > > > device name per > > > transport protocol. This means, for example, that a target > > > device with > > > both SAS and iSCSI target ports has two device names - the > > iSCSI name > > > and the SAS device name. > > > > > > Assuming 02-254 (WWNs for W-LUNs) passes, these would be > > > returned as two > > > device identifiers in VPD data: > > > 1. SAS device name > > > association=target device (2h) > > > protocol identifier=SAS (6h) > > > identifier type=NAA (3h) > > > identifier=IEEE Registered format (NAA=5h), 8 bytes long > > > > > > 2. iSCSI device name > > > association=target device (2h) > > > protocol identifier=iSCSI (5h) > > > identifier type=iSCSI name-based (7h) (to be proposed > in 02-419) > > > identifier=UTF-8 format string, up to 224 bytes long > > > > > > It would be simpler if there were only one device name > for a device. > > > > > > Since only iSCSI has defined device names to date (SAS is > > > just planning > > > to include a device name now, and FCP-3 might define one > > too), we have > > > an opportunity to make all device names follow the iSCSI > name-based > > > format and let each device have a single device name regardless of > > > protocol. > > > > > > The iSCSI name format is a UTF-8 (similar to ASCII) string > > that starts > > > with a naming authority: "iqn." for an iSCSI-defined > > reverse domain > > > name string (e.g. > > > "iqn.2001-04.com.acme:storage.disk2.sys1.xyz") > > > "eui." for a hexadecimal representation of an EUI-64 > > identifier (e.g. > > > "eui.02004567A425678D") > > > > > > iSCSI could easily add an "naa." type to carry a hexadecimal > > > representation of an NAA identifier (e.g. > "naa.52004567A425678D"), > > > needed to carry the format used by SAS and Fibre Channel > port names. > > > > > > Then, a target device with target ports of different > > > protocols could use > > > any string format it likes as its sole device name. > > > > > > Likely choices: > > > iSCSI-only device: "iqn." (it may have no hardware names > available) > > > SAS-only device: "naa." FC-only device: "naa." > > > SRP-only device: "eui." > > > SBP-2-only device: "eui." > > > iSCSI/SAS combination device: "naa." since it is already using NAA > > > identifiers available for port names > > > SRP/iSCSI/SAS combination device: "naa." or "eui." since it > > > already has > > > NAA and EUI-64s for port names > > > > > > This would divorce the device name concept from the transport > > > protocols. > > > Transport protocols could still require their devices > have a device > > > name, but wouldn't comment on the format. > > > > > > -- > > > Rob Elliott, elliott@hp.com > > > Industry Standard Server Storage Advanced Technology > Hewlett-Packard > > > > > > > > > > > > > > > From owner-ips@ece.cmu.edu Thu Oct 31 07:35:01 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16644 for ; Thu, 31 Oct 2002 07:35:01 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g9VBpvW19204 for ips-outgoing; Thu, 31 Oct 2002 06:51:57 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from hclnpd.hclt.co.in ([202.54.64.7]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g9VBprH19199 for ; Thu, 31 Oct 2002 06:51:53 -0500 (EST) Received: from mailnpd.hclt-ntl.co.in ([192.168.19.36]) by hclnpd.hclt.co.in with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SP0AFB6A; Thu, 31 Oct 2002 17:22:25 +0530 Received: from npd.hcltech.com (skotra-pc.hclt-ntl.co.in [192.168.19.57]) by mailnpd.hclt-ntl.co.in (8.11.0/8.11.0) with ESMTP id g9VBeGZ28314 for ; Thu, 31 Oct 2002 17:10:18 +0530 Message-ID: <3DC16775.DB3E3FD7@npd.hcltech.com> Date: Thu, 31 Oct 2002 17:25:09 +0000 From: Subrahmanya Sastry K V X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: ips@ece.cmu.edu Subject: iSCSI: Question on SCSI INQUIRY response Content-Type: multipart/alternative; boundary="------------BCB1C18749BF84174A1B17C8" Sender: owner-ips@ece.cmu.edu Precedence: bulk --------------BCB1C18749BF84174A1B17C8 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi All, Suppose I've sent an INQUIRY CDB as a part of SCSI request PDU to the target, waiting for the INQUIRY response data. Is it legal to get the same as part of data segment of SCSI response PDU(with SCSI status GOOD)? or should it be got ONLY as part of data segment of a Data-In PDU ( with S bit set to 1)? Please clarify ! Sastry -- Subrahmanya Sastry K V HCL Tech, Chennai, INDIA Ph: +91-44-3728366 Xtn-1146 http://san.hcltech.com --------------BCB1C18749BF84174A1B17C8 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi All,

Suppose I've sent an INQUIRY CDB as a part of SCSI request PDU
to the target, waiting for the INQUIRY response data. Is it legal to
get the same as part of data segment of SCSI response PDU(with
SCSI status GOOD)?
or should it be got  ONLY as part of data segment of a Data-In PDU
( with S bit set to 1)?

Please clarify !

Sastry 

-- 
Subrahmanya Sastry K V
HCL Tech, Chennai, INDIA
Ph: +91-44-3728366  Xtn-1146
http://san.hcltech.com
  --------------BCB1C18749BF84174A1B17C8-- From owner-ips@ece.cmu.edu Thu Oct 31 09:13:22 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20023 for ; Thu, 31 Oct 2002 09:13:22 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g9VDWXc23118 for ips-outgoing; Thu, 31 Oct 2002 08:32:33 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ganesh.ctd.hctech.com ([202.54.64.2]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g9VDWUH23111 for ; Thu, 31 Oct 2002 08:32:30 -0500 (EST) Received: by GANESH with Internet Mail Service (5.5.2653.19) id ; Thu, 31 Oct 2002 19:04:44 +0530 Message-ID: From: "Asai Thambi S.P - CTD, Chennai." To: Subrahmanya Sastry K V , ips@ece.cmu.edu Subject: RE: iSCSI: Question on SCSI INQUIRY response Date: Thu, 31 Oct 2002 18:58:49 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C280E1.72221B70" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C280E1.72221B70 Content-Type: text/plain; charset="iso-8859-1" The target can send the status in the last SCSI Data-In PDU with S bit set and need not send the SCSI response PDU for that request. The data segment of SCSI response PDU can only contain sense data and/or response data (vendor specific info). So the actual (I/O) data can not be part of the data segment of a SCSI response PDU. - asai thambi. -----Original Message----- From: Subrahmanya Sastry K V [mailto:skotra@npd.hcltech.com] Sent: Thursday, October 31, 2002 10:55 PM To: ips@ece.cmu.edu Subject: iSCSI: Question on SCSI INQUIRY response Hi All, Suppose I've sent an INQUIRY CDB as a part of SCSI request PDU to the target, waiting for the INQUIRY response data. Is it legal to get the same as part of data segment of SCSI response PDU(with SCSI status GOOD)? or should it be got ONLY as part of data segment of a Data-In PDU ( with S bit set to 1)? Please clarify ! Sastry -- Subrahmanya Sastry K V HCL Tech, Chennai, INDIA Ph: +91-44-3728366 Xtn-1146 http://san.hcltech.com ------_=_NextPart_001_01C280E1.72221B70 Content-Type: text/html; charset="iso-8859-1"
The target can send the status in the last SCSI Data-In
PDU with S bit set and need not send the SCSI response
PDU for that request.
 
The data segment of SCSI response PDU can only contain
sense data and/or response data (vendor specific info).
 
So the actual (I/O) data can not be part of the data segment
of a SCSI response PDU.
 
- asai thambi.
-----Original Message-----
From: Subrahmanya Sastry K V [mailto:skotra@npd.hcltech.com]
Sent: Thursday, October 31, 2002 10:55 PM
To: ips@ece.cmu.edu
Subject: iSCSI: Question on SCSI INQUIRY response

Hi All,

Suppose I've sent an INQUIRY CDB as a part of SCSI request PDU
to the target, waiting for the INQUIRY response data. Is it legal to
get the same as part of data segment of SCSI response PDU(with
SCSI status GOOD)?
or should it be got  ONLY as part of data segment of a Data-In PDU
( with S bit set to 1)?

Please clarify !

Sastry 

-- 
Subrahmanya Sastry K V
HCL Tech, Chennai, INDIA
Ph: +91-44-3728366  Xtn-1146
http://san.hcltech.com
 
------_=_NextPart_001_01C280E1.72221B70-- From owner-ips@ece.cmu.edu Thu Oct 31 09:14:20 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20108 for ; Thu, 31 Oct 2002 09:14:19 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g9VDZNC23287 for ips-outgoing; Thu, 31 Oct 2002 08:35:23 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [194.196.100.236]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g9VDZLH23283 for ; Thu, 31 Oct 2002 08:35:21 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g9VDZCRa021322; Thu, 31 Oct 2002 14:35:12 +0100 Received: from JA31 (JA31.haifa.ibm.com [9.148.18.166]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g9VDZABG017784; Thu, 31 Oct 2002 14:35:11 +0100 From: "Julian Satran \(Actcom\)" To: "'Subrahmanya Sastry K V'" , Subject: RE: iSCSI: Question on SCSI INQUIRY response Date: Thu, 31 Oct 2002 15:35:08 +0200 Message-ID: <001f01c280e2$569254f0$a6129409@JA31> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0020_01C280F3.1A1B24F0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-reply-to: <3DC16775.DB3E3FD7@npd.hcltech.com> Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0020_01C280F3.1A1B24F0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Dear Sastry, You can get a Data-In PDU with the GOOD status in the header. You can't get a Command response PDU with data in the Data Segment. The data-segment of the Command Response may contain sense or Response-related (when available) data. Regards, Julo -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu] On Behalf Of Subrahmanya Sastry K V Sent: 31 October, 2002 19:25 To: ips@ece.cmu.edu Subject: iSCSI: Question on SCSI INQUIRY response Hi All, Suppose I've sent an INQUIRY CDB as a part of SCSI request PDU to the target, waiting for the INQUIRY response data. Is it legal to get the same as part of data segment of SCSI response PDU(with SCSI status GOOD)? or should it be got ONLY as part of data segment of a Data-In PDU ( with S bit set to 1)? Please clarify ! Sastry -- Subrahmanya Sastry K V HCL Tech, Chennai, INDIA Ph: +91-44-3728366 Xtn-1146 http://san.hcltech.com ------=_NextPart_000_0020_01C280F3.1A1B24F0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Message
Dear=20 Sastry,
 
You=20 can get a Data-In PDU with the GOOD status in the = header.
You=20 can't get a Command response PDU  with data in the Data=20 Segment.
The=20 data-segment of the Command Response may contain sense or = Response-related (when=20 available) data.
 
 
Regards,
Julo
-----Original Message-----
From:=20 owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu] On Behalf Of=20 Subrahmanya Sastry K V
Sent: 31 October, 2002=20 19:25
To: ips@ece.cmu.edu
Subject: iSCSI: Question = on SCSI=20 INQUIRY response

Hi All,=20

Suppose I've sent an INQUIRY CDB as a part of SCSI request PDU =
to=20 the target, waiting for the INQUIRY response data. Is it legal to =
get=20 the same as part of data segment of SCSI response PDU(with
SCSI = status=20 GOOD)?
or should it be got  ONLY as part of data segment of a = Data-In=20 PDU
( with S bit set to 1)?=20

Please clarify !=20

Sastry 

-- 
Subrahmanya Sastry K V
HCL Tech, Chennai, INDIA
Ph: +91-44-3728366  Xtn-1146
http://san.hcltech.com
 =20
------=_NextPart_000_0020_01C280F3.1A1B24F0-- From owner-ips@ece.cmu.edu Thu Oct 31 12:06:08 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01541 for ; Thu, 31 Oct 2002 12:06:07 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g9VGGVm02926 for ips-outgoing; Thu, 31 Oct 2002 11:16:31 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g9VBH7H18003 for ; Thu, 31 Oct 2002 06:17:07 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13011; Thu, 31 Oct 2002 06:14:10 -0500 (EST) Message-Id: <200210311114.GAA13011@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ips@ece.cmu.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ips-isns-14.txt Date: Thu, 31 Oct 2002 06:14:09 -0500 Sender: owner-ips@ece.cmu.edu Precedence: bulk --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 : Internet Storage Name Service (iSNS) Author(s) : J. Tseng, K. Gibbons et al. Filename : draft-ietf-ips-isns-14.txt Pages : 93 Date : 2002-10-30 This document specifies the iSNS protocol, which is used for interaction between iSNS servers and iSNS clients in order to facilitate automated discovery, management, and configuration of iSCSI and Fibre Channel (FCP) devices on a TCP/IP network. iSNS provides intelligent storage discovery and management services comparable to those found in Fibre Channel networks, allowing a commodity IP network to function in a similar capacity as a storage area network. iSNS also facilitates a seamless integration of IP and Fibre Channel networks, due to its ability to emulate Fibre Channel fabric services, and manage both iSCSI and Fibre Channel devices. iSNS thereby provides value in any storage network comprised of iSCSI devices, Fibre Channel devices, or any combination thereof. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-isns-14.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ips-isns-14.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ips-isns-14.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: <2002-10-30155557.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-isns-14.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-isns-14.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-30155557.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ips@ece.cmu.edu Thu Oct 31 17:45:19 2002 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18808 for ; Thu, 31 Oct 2002 17:45:19 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g9VLnIa24426 for ips-outgoing; Thu, 31 Oct 2002 16:49:18 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.70.145.30]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g9VLnAH24408 for ; Thu, 31 Oct 2002 16:49:10 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g9VLn1gM005383 for ; Thu, 31 Oct 2002 13:49:01 -0800 (PST) Received: from nisser.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id g9VLn3rG019910 for ; Thu, 31 Oct 2002 13:49:03 -0800 (PST) Received: from cisco.com (mbakke-lnx2.cisco.com [64.101.211.59]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id NAA07426 for ; Thu, 31 Oct 2002 13:49:01 -0800 (PST) Message-ID: <3DC1A54E.3E1E852C@cisco.com> Date: Thu, 31 Oct 2002 15:49:02 -0600 From: Mark Bakke X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.9-34.cisco.2 i686) X-Accept-Language: en, de MIME-Version: 1.0 To: IPS Subject: iSCSI MIB: Post-last-call comment Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit OK, I know that last call is finished, but we found one more thing to resolve: Since iSCSI sessions "belong" to iSCSI nodes, where do discovery sessions go on a target? Since there's no target endpoint of a discovery session, there's no place to put them. Discovery sessions on an initiator do not appear to pose the same problem, since the initiator's identity is present during discovery session login. To solve this in a simple fashion, we have a few choices: 1. Leave out support for discovery sessions within the MIB 2. Add a "discovery" node under which to put discovery sessions 3. Move sessions out from under nodes (which would be a fairly significant change. I think that solution (3) is overkill, and (1) is probably not enough. Solution (2) can be done fairly cleanly, by allowing a node with a blank iscsiNodeName field to exist as the end point for discovery sessions. I'd like to propose that we solve this by simply adding the following text to the iscsiNodeName description: "If this string is left blank, this node is a discovery-only node, and supports only discovery sessions." This could be used for initiators as well, for the symmetrically- inclined. If I don't hear any comments on this proposal, I'll put it in before the draft goes to the ADs. -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054